Проектирование бизнес процессов с использованием функциональных моделей

1. Построение функциональной модели бизнес-процессов

Функциональные
модели оптимизированных бизнес-процессов
содержат информацию о том, как они должны
выполняться после их модификации с
учетом предложений по результатам
математического моделирования.
Функциональная модель построена в
соответствии с алгоритмом, изображенным
на рисунке 2.1.

Описание
бизнес-процессов всегда начинается с
контекстной диаграммы, на которой
присутствует только один черный ящик
– процесс, который предполагается
промоделировать. Контекстная диаграмма
показа на рисунке 2.2.

Рисунок
2.2 – Контекстная диаграмма функциональной
модели бизнес-процесса

Черным
ящиком является процесс по формированию
товарного ассортимента. На входе процесса
имеем Прайс-листы поставщиков, товарные
группы, а также впервые добавленные в
модели «как должно быть» сведения о
продажах и сведения о полученной прибыли,
на выходе – товарный ассортимент.

В
качестве механизмов выступают Руководитель
группы планирования, Информационная
система и Категорийный менеджер.

Перейдем
на один уровень ниже и заглянем внутрь
данного черного ящика (рисунок 2.3)

Рисунок
2.3 – Диаграмма декомпозиции

Процесс
состоит из следующих черных ящиков:

1. Анализ
   продаж товаров. Это процесс, впервые
   введенный мною в модели «как должно
   быть». В нем выполняется расчет количества
   потребления товаров из ассортимента.

2. Определение
   списка товаров для ассортимента.
   Видоизмененный процесс с учетом
   использования информационной системы.
   Теперь для выбора списка товаров
   используются данные расчета по матмодели
   и список товаров, ранее исключенный по
   причине низких продаж.

3. Формирование
   черновой версии ассортимента. После
   окончательного выбора списка товаров,
   которые войдут в ассортимент магазина,
   составляется его черновой вариант для
   проверки руководителем группы
   планирования.

4. Уточнение
   цен на товары. Данный процесс изменениям
   не подвергался, так как выполняется
   отделом закупок. В рамках него
   сопоставляются имеющаяся стоимостная
   оценка товаров и цены поставщиков,
   которые могли обновиться. В случае
   возникновения различий план отправляется
   на доработку.

5. Корректировка
   и утверждение ассортимента. Процесс
   не был затронут, так как относится в
   большей степени к руководителю группы
   планирования. В рамках него выявляются
   неточности и ошибки в представленном
   ассортименте. Если таковые найдены –
   он дорабатывается, если нет – ассортимент
   утверждается.

Перейдем
на один уровень ниже и заглянем внутрь
черного ящика «Определение списка
товаров для ассортимента» (рисунок
2.4). Это целиком новый процесс, внедренный
при оптимизации.

Рисунок
2.5 – Диаграмма процесса «Определение
списка товаров для ассортимента»

В
рамках процесса сначала происходит
формирование ассортиментной матрицы
на основе данных в БД информационной
системы. Для этого также могут
использоваться данные о товарах, ранее
исключенных из ассортимента по причине
падения продаж. Полученный список
сохраняется в БД и может быть использован
в дальнейшем для составления черновика
ассортимента.

1. Перечень изменений внутри бизнес-процесса оценки предпочтений покупателей и формирования ассортимента

Обобщим
достигнутые в ходе моделирования
результаты. Они отражаются в изменениях
внутри процесса и показаны в таблице
2.7

Таблица
2.4 – Изменения внутри бизнес-процесса

Также
следует отметить, что появилась
возможность руководителя группы
планирования в любой момент получить
актуальные данные по продаже того или
иного товара.

Моделирование бизнеса. Основные подходы

В этой статье я хочу поговорить об основных принципах моделирования бизнеса, о тех подходах, которые применяются в этой сфере, и на основе которых создаются языки моделирования и нотации.

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

С одной стороны, применение схем для наглядности при описании моделей бизнеса в ни у кого не вызывает вопросов. Это действительно очень удобно. С другой стороны, многие бизнесмены и даже мои коллеги недоумевают, зачем нужны специальные нотации и правила для разработки бизнес-процессов, ведь можно в любом графическом редакторе (visio) или при помощи других удобных инструментов просто нарисовать интуитивно понятную схему.

О том, почему так важна стандартизация, а также о том, в каком случае применяется тот или иной подход, я и хочу поговорить.

Основные подходы

Сегодня существует множество различных инструментов для разработки бизнес-моделей, они используют различные языки моделирования, как стандартные, так и какие-то собственные разработки. Но все их можно объединить по принципу работы в три основных подхода:

• Функциональный;
• Процессный;
• Ментальный (с применением ментальных карт).

На самом деле, конечно, существуют и другие подходы, их много так же, как и языков моделирования. Но они большей частью являются гибридными решениями, объединяющих перечисленные подходы. Кроме того, именно процессная и функциональная модели уже стали стандартами, по крайней мере, на западе. И у нас они получают все большее распространение. Об этих основных направлениях я и хочу поговорить подробнее.

Функциональное моделирование

Функциональное моделирование рассматривает бизнес как функцию (лат. functio — совершение, исполнение) или иными словами «черный ящик». В функциональной модели функция не имеет временной последовательности, а только точку входа и точку выхода. Функциональное моделирование помогает рассматривать бизнес-модель с с точки зрения результативности, т.е. при моделировании мы исходим из того, что имеем на входе, и того, что желаем получить на выходе.

Например, компания разрабатывает какую-то CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка входа – «входящий интерес клиента или лид», точка выхода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т.д.

Таким образом, в функциональной модели изначально известны точка входа и желаемый результат, а последовательность действий и является объектом разработки. При этом использование функциональных моделей как «черных ящиков» позволяет детализировать каждый этап по мере необходимости. А вся работа при моделировании направлена на поиск оптимального решения для достижения цели.

Функциональные модели вы можете также использовать для демонстрации своих идей и вариантов решений. Это также очень удобно, ведь в процессе демонстрации вы можете двигаться от общего к деталя, по мере необходимости разделять и декомпозировать функции. Но декомпозировать вы будете при этом именно функции, и, разделяя одну функцию на несколько, вы не получите описание процесса.

Некоторые путают описание процесса и функциональную модель. Например, в системе Business Studio функцию называют процессом, хоть это и не совсем верно. Все же описание функций и процессный подход – несколько разные вещи. И я лично считаю, что функциональное моделирование оптимально реализовано в нотации IDEFO. Сам я для такого варианта работы использую именно ее, и всем также рекомендую.

Правила работы с IDEFO вы можете подробнее изучить, прочитав мою статью накомство с нотацией IDEF0 и пример использования.

Процессное моделирование (моделирование бизнес процессов)

О процессном моделировании я буду рассказывать с точки зрения нотации BPMN, как одного из наиболее распространенных стандартов процессного моделирования. При этом я полностью согласен, что существует множество языков моделирования и различных систем. И каждый может пользоваться тем, что ему удобнее. Но все же BPMN — это уже сложившийся стандарт процессного моделирования, а потому его я и беру за основу в описании.

Процесс с точки зрения бизнес-модели — это последовательность каких-то событий и действий, которые имеют начало и конец.

В этом кроется основное отличие процессного моделирования от функционального. Функциональное моделирование рассматривает бизнес-модель с точки зрения входа и выхода (имеющихся ресурсов и желаемого результата). А процессное основано на последовательности действий в определенных границах, в случае BPMN это будут начало и конец события.

Все процессы могут разбиваться (детализироваться) на подпроцессы вплоть до детализации на уровне задач, т.е. действий, дальнейшая детализация которых невозможна. Процесс – это некая последовательность действий, которую необходимо выполнить, чтобы получить определенный результат. Необходимо отметить что в модели бизнеса как процесса результат может и не быть явным в отличии от функциональной модели.

Принципиальное отличие процессного моделирования от функционального заключается в том, что при процессном моделировании основное внимание уделяется не тому, что мы хотим получить, а тому, что нужно сделать для получения результата, т.е. не итогам той или иной деятельности, а самой последовательности действий.

Например, в BPWIN или Business Studio в процессе детализации каждой функции происходит переход от функционального подхода к процессному. Т.е. в общем, мы рассматриваем модель с точки зрения – возможностей и желаемого результата, а когда переходим к решениям для каждой функции, здесь уже практикуется явно процессный подход, т.е. пошаговый алгоритм действий для достижения результата.

Представьте себе что в функциональной модели есть «черный ящик» — функция «Принять заказ». А при декомпозировании мы уже рассматриваем ее не как функцию, а как процесс, и последовательность действий при приеме заказа – это уже процессный подход.

Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.

Ментальный подход (ментальные карты)

При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример — ментальная карта понятия “Процедура снабжения” (см. рисунок).

Такой вариант подхода применяется, прежде всего, для себя. Рисование схемы в свободной форме помогает структурировать свои знания, так сказать, “разложить по полочкам” в свободной форме полученную информацию. Также подобные ментальные карты помогают найти решение, которое уже позже, по мере необходимости, будет воплощаться в рамках строгих правил процессного или функционального подхода.

Можно применять ментальные карты и для демонстрации клиентам: и существующей ситуации, и вариантов решения поставленной задачи. Ментальные карты помогут наглядно продемонстрировать, какие методы могут быть использованы, показать в наглядной форме различные идеи.

Плюсы применения таких ментальных карт очевидны:

• Не нужно знать какие-то специальные языки;
• Нет строгих рамок и ограничений при создании схемы;
• Ментальная карта в большинстве случаев интуитивно понятна;
• Создавать такие схемы просто.

Минусом подхода является отсутствие устоявшегося подхода и стандартизированной методологии. Если в нотациях функциональных и процессных имеется некоторая вариативность, но все же она ограничена строгими рамками языков моделирования, то ментальные карты создаются в произвольной форме. И даже специализированные программы для их создания также почти не ограничивают человека в процессе моделирования. Т.е. какие-то правила могут вводиться в рамках определенного программного продукта, но стандарта не существует.

В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).

Конечно, существуют очень простые карты, которые интуитивно читаются и без дополнительных комментариев. Но при отсутствии стандартов всегда есть вероятность, что даже в этом случае автор что-то другое имел в виду или где-то недостаточно детализировал свою схему. Т.е. существует вероятность разного прочтения. А бизнес — это не философия. При всей умозрительности и разнообразии подходов к описанию бизнес-процессов, здесь очень важны однозначные решения.

Методология и языки бизнес-моделирования

Очень часто даже в профессиональной литературе возникает путаница, когда люди смешивают понятия методологии анализа работы бизнеса и описания языков бизнес-моделирования.

Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.

Здесь напрашивается сравнение с программированием вообще и применением конкретного языка программирования. Программирование включает в себя и построение алгоритма, и выбор подходящего языка программирования, и реализацию алгоритма программы в рамках того или иного языка. А, например, программирование на языке Си++ – это уже заведомо ограничение определенными рамками, так как средствами определенного языка можно решить только четко ограниченный круг задач, и, одновременно, даже если задачу можно решить средствами Си++ совсем не обязательно, что именно этот язык будет в конкретном случае оптимальным. В общем, разницу между понятием «программирование» и «программированием в рамках определенного языка», я думаю, большинство понимают даже без таких пояснений.

Отличие языков разработки бизнес-моделей в от языков проектирования систем

Существует целое семейство языков проектирования систем, которые внешне схожи с языками бизнес-моделирования, например, это Ares Studios, целое семейство языков UML и другие, которые используются для проектирования IT-систем.

Основное различие этих языков от языков разработки бизнес-процессов лежит в их предназначении. Если языки проектирования IT-систем рассматривают бизнес-процессы с точки зрения возможности их автоматизации, воплощении в IT-системах, то языки бизнес-моделирования рассматривают последовательность действий именно с точки зрения бизнеса, включая работу как IT-систем, так и сотрудников, движения товаров и т.д.

Соответственно, в языках проектирования систем нет элементов, которые помогут полноценно описать действия подразделений, сотрудников, взаимодействие между ними, работу с поставщиками, общение с клиентами и так далее. Инструменты этой группы языков помогут именно автоматизировать процессы бизнеса, которые поддаются автоматизации. А все остальное будет оставлено «за кадром», например, как некие «функции» без расшифровки.

В то же время языки разработки бизнес-процессов охватывают максимально именно работу бизнеса как такового, а вот те или иные нюансы автоматизации и алгоритмизации систем в них описать далеко не всегда возможно с достаточной степенью детализации.

Преимущества разработки моделей бизнеса

И все же, зачем применять языки бизнес-моделирования, которые налагают строгие ограничения, требуют придерживаться жестко заданных правил при моделировании? Ведь всегда можно «нарисовать схему» в графическом редакторе или даже на бумаге, используя ментальный подход, при этом изучение языков моделирования вообще не потребуется.

На самом деле, стандарты и правила – это огромный плюс:

1. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике

Лично я считаю, что бизнес-моделирование стоит применять при решении любых задач, связанных с выявлением проблем и «узких мест», с оптимизацией и модернизацией бизнеса и т.д. Как бизнес-консультант я практически всегда строю модели работы компании или ее подразделений при работе со своими клиентами. Это дает четкое понимание всех этапов работы и позволяет избежать «белых пятен» в этом вопросе.

Кроме того, наглядные схемы бизнес-моделей помогают мне в процессе взаимодействия с клиентами. Проекты у меня часто бывают сложными, и обычного текста или устной речи бывает недостаточно для понимания, в то время как использование наглядных бизнес-моделей снижает затраты времени клиента на чтение и понимание моих предложений, и практически исключает проблемы взаимопонимания в этом вопросе. И если несколько лет назад я еще сталкивался с недоумением со стороны клиентов, то сейчас вариант описания «на словах» без наглядных и удобных схем практикуется крайне редко.

А в случае автоматизации какого-либо этапа работы или создания автоматизированной системы управления бизнесом на основе проектно-ориентированного подхода качественная бизнес-модель, выполненная в том или ином языке моделирования, станет готовым руководством для технических специалистов.

Удобство, универсальность, простота восприятия – это те причины, по которым от словесных описаний в бизнес-сфере все больше переходят к бизнес-моделированию. А применение готовых языков позволяет работать с моделями быстро, избегать ошибок, и также без проблем вносить любые изменения.

Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости ссылке.

Для того чтобы сузить до разумных пределов творческую свободу проектировщика, требуются метастандарты проектирования бизнес-процессов, которые можно сформулировать в виде установочных концепций. Предлагаемые в статье семантические правила моделирования акцентированы на повышении адекватности оценок эффективности системы бизнес-процессов, получаемых средствами функционально-стоимостного анализа или имитационного моделирования. Также статья содержит предложения, которые могут пригодиться руководителям и аналитикам при создании внутренних положений предприятия, уточняющих и конкретизирующих фирменные инструкции ко многим CASE-средствам.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Чтобы приготовить блюдо, недостаточно знать его ингредиенты и их пропорции; необходимо еще овладеть навыками изготовления продукта. Объективно, современные методики организационного проектирования предлагают лишь описание ингредиентов и весьма приближенное описание технологий получения продукта, оставляя широкое поле для творчества. И это, наверное, правильно. Ведь субъективные интерпретации и детализации этих методик могут быть не менее ценными, чем сами методики.

Многообразие возможных точек зрения на принципы моделирования и содержание понятия «бизнес-процесс», с которым сталкивается проектировщик, с одной стороны, активизирует его, а с другой, существенно осложняет решение проектной задачи в заданные сроки. В [1] отстаивается точка зрения, что проектировщику следует активизировать свою креативность в максимально узких рамках. Творческую свободу проектировщика ограничивают:

1. стандарт проектирования бизнес-процессов;
2. отраслевые стандарты бизнес-процессов;
3. ранее принятые стандарты проектирования бизнес-процессов предприятия;
4. установочные концепции.

Примером стандартов проектирования бизнес-процессов может служить семейство стандартов IDEF (Госдепартамент и BBC США), RUP (компания Rational Software), Catalysis (компания Computer Associates). Отраслевыми стандартами являются модели, разрабатываемые государственными и международными общественными организациями (рекомендации ISA, APICS, ISO, TM Forum и др.). Стандарты предприятия обычно составляют подмножество стандартов (1) и (2), обогащенное процедурными правилами разработки и согласования моделей бизнес-процессов, принятых на предприятии.

Какими бы ни были жесткими нормативные ограничения, всегда найдется неопределенная ими область творчества для постановщика задачи и ее исполнителя, а также возможности интерпретации этих ограничений. Дополняющие и не противоречащие нормативным ограничениям согласованные точки зрения постановщика и исполнителя на моделируемый объект и способы его описания назовем установочными концепциями. Ими могут быть:

• цели моделирования (реинжиниринг бизнес-процессов, автоматизация бизнес-процессов и внедрения информационных систем, системные исследования бизнес-процессов и др.);
• интерпретация стандартов (1-3) как заказчиком проектных работ, так и самим проектировщиком;
• принципы формирования словаря проекта и соглашения об основных понятиях, неопределенные стандартами (1-3) или нуждающиеся в уточнении.

Апробированные установочные концепции могут являться основой для разработки предложений по совершенствованию стандартов предприятия.

Не станем ограничиваться рассмотрением одной из целей моделирования, а попытаемся сосредоточиться на аспектах моделирования бизнес-процессов, имеющих общую значимость. Исходный контекст статьи – это абстрактный проект, целью которого является разработка модели бизнес-процессов, а предмет обсуждения – задача «настройки» ограничений (3-4) на этот проект. Фактически речь идет о процессе приспособления стандарта (tailoring process) и точек зрения проектировщика, который, как правило, содержит огромные возможности для привнесения субъективных решений, как по воле проектировщика, так и по воле заказчика. Поэтому необходимы дополнительные методические рекомендации, которые сузили бы область творческого «произвола» при модификации стандартов проектирования бизнес-процессов.

Рассмотрим рекомендации по конкретизации языков моделирования бизнес-процессов в контексте методологии IDEF0. Данный выбор не является принципиальным, а лишь отражает субъективные пристрастия автора. При этом следует иметь в виду, что предлагаемые принципы формирования рекомендаций и логику их применения легко распространить на отличные от IDEF0 методики проектирования бизнес-процессов с учетом трех аспектов моделирования бизнес-процессов: функционального моделирования, моделирования событий и ресурсов и унификаций описания бизнес-процессов.

Функциональная модель бизнес-процессов

Любой стандарт проектирования бизнес-процессов базируется на исходных понятиях – смысловых примитивах. Так, стандарт IDEF0 использует понятие «Работа» (Activity) для обозначения действия, а также обозначения интерфейсов «Вход» (Input), «Выход» (Output), «Управление» (Control) и «Механизм» (Mechanism), которые составляют графическую конструкцию (A), изображенную на рис. 1.

Рис. 1.

К сожалению, в IDEF0 эти примитивы определяются в общем виде, поэтому пользователи стандарта обычно прибегают к интерпретациям примитивов. Например, только на первый взгляд конструкция из рис. 1 выглядит логичной, а формирование дополнительных концептуальных установок – ненужным. Как правило, у начинающего пользователя возникает недоумение, куда ему необходимо отнести понятие «Распоряжение»: к интерфейсу «Управление» или к интерфейсу «Вход»? Или куда отнести понятие «расходные материалы» при моделировании работы канцелярии: к «Входу» или «Механизму»? Дальше – больше. Стандарт IDEF0 исполнителей «Работ» (одушевленных и неодушевленных) относит к интерфейсу «Механизм». На уровне бытового сознания это не вызывает вопросов, однако, если вдуматься в суть понятия «исполнение», то становится ясным, что исполнитель «Работ» является активатором «Работ», составляющих данную «Работу» и приводящих к ее исполнению. Между тем, активатором «Работ» согласно IDEF0 является «Вход».

Подобных логико-лингвистических противоречий в интерпретациях профессиональные пользователи стандарта IDEF0 могут привести много. Приведенные примеры говорят о том, что проектировщику так или иначе придется «заузить» стандарт IDEF0, если для него важна непротиворечивость модели и собственных представлений о моделируемом объекте.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Для практического удобства можно предложить иную, зауженную интерпретацию исходных примитивов стандарта IDEF0 (графическая конструкция (Б) на рис. 1). Сформулируем основную идею предлагаемой рекомендации по конкретизации языков моделирования бизнес-процессов.

Все «Работы» принадлежат одному классу – обладают одинаковым набором свойств и поведением.

Все связи между «Работами» принадлежат классу «Ресурс». Например, электронное издание «Налогового кодекса РФ» является реализацией (или экземпляром) общедоступного информационного ресурса, а уборщица Иванова И.И. является экземпляром ресурса «Уборщица офиса 202».

На IDEF0-диаграмах изображаются классы объектов. Однако проектировщик всегда отталкивается от знания только некоторых общих свойств конкретных реализаций (экземпляров) этих классов. Назовем такое множество свойств «точкой зрения на экземпляр класса». Эту посылку можно использовать для однозначной «привязки» ресурсов к трем возможным входам бизнес-процессов. Для этого на множестве ресурсов вводится классификация, основанная на различиях «точек зрения на экземпляры ресурсов».

1. Признак изменчивости экземпляров ресурсов при исполнении «Работы»:

• ресурсы, подлежащие трансформации в другие виды ресурсов;
• нетрансформируемые ресурсы.

Нетрансформируемые ресурсы могут быть неизнашиваемыми или изнашиваемыми (устаревающими). Так, значительная часть информационных ресурсов в электронной форме являются неизнашиваемыми (библиотека нормативных документов организации и др.). Примером изнашиваемых ресурсов могут служить вспомогательные инструменты, персонал. Описанные признаки относятся к экземплярам ресурсов, а не к самим ресурсам: понятия как абстрактные классы не изнашиваются.

2. Признак блокировки экземпляра ресурса «Работой», исключающий возможность использования экземпляра ресурса другими «Работами»:

• ресурсы, которые не могут блокироваться “Работами” (ресурсы общего пользования);
• блокируемые ресурсы (например, уборщица Иванова И.И.)

Правила разводки ресурсов, классифицируемых по описанным признакам, по интерфейсам, заданным стандартом IDEF0, иллюстрируются на примере “Общая модель бизнес-процессов (В)” (рис. 1). Предлагаемая интерпретация смыслового содержания интерфейсов IDEF0-стандарта не только полностью соответствует требованиям этого стандарта, но и лишена возможных логико-лингвистических противоречий, свойственных ряду других интерпретаций.

События и ресурсы

Важнейший компонент моделирования бизнес-процессов – оценка материальных, стоимостных и временных ресурсов, необходимых для исполнения всего множества процессов. В современных инструментах проектирования, поддерживающих IDEF0, для этих целей используется функционально-стоимостной анализ, а расчеты производятся методом непосредственной имитации исполнения «Работ». Можно встретить мнение, что одним из недостатков IDEF0-моделей, в которых по тем или иным причинам не определяются моменты активации работ, является ошибка функционально-стоимостного анализа, вызванная фактором нарушения последовательности «Работ». Эта ошибка считается допустимой для приближенных расчетов. Для более точных расчетов предлагается использовать иные инструменты; так, в BPwin наличествует возможность экспорта данных в систему EasyABC. Однако это слишком дорогое решение для такой простой задачи. Что мешает нам более четко определить моменты активации «Работ» на IDEF0-диаграммах?

Считается, что основным отличием стандартов, нацеленных на функциональное или процессное моделирование, являются их возможности по описанию событий и последовательности исполнения «Работ» во времени. В известном руководстве [4] пользователям стандартов IDEF0 и IDEF3 настойчиво навязывается идея о различном их назначении, говорится об отличиях интерпретации стрелок в IDEF0 и в моделях потока работ [5]. Покажем, что это утверждение далеко от действительности.

В качестве базовой посылки примем положение о том, «что не запрещено стандартом, то разрешено». Покажем, что IDEF0 не запрещает изображать события и определять последовательность «Работ» с помощью стрелок. Будем исходить из того, что в IDEF0 активаторами работ определены стрелки [5]. К сожалению, сущность такой активации в стандарте не поясняется. Логично предположить, что активация – это принуждение к исполнению «Работы» или, как минимум, изменение состояния «Работы», которое тоже можно толковать как начало исполнения. При этом активация может толковаться широко. Например, отсутствие информации на входе «Работы» тоже может рассматриваться как активация.

Однако в стандарте, как это ни странно, синтаксически не различаются «Работы», находящиеся на различных уровнях декомпозиции. Различия же между ними существенны. Согласно положению стандарта о том, что активаторами «Работ» являются стрелки, а на нижнем уровне декомпозиции бизнес-процессов стрелки описывают последовательность исполнения «Работ» [5], можно утверждать, что каждая «Работа» на нижнем уровне декомпозиции модели активируется только при активации всех ее входов. К сожалению, из текста стандарта не следует, что считать условиями активации «Работы» более высокого уровня. Стандарт рекомендует проектировщику, по возможности, не задумываться над этой проблемой, однако не настаивает на этом определенно [5].Читатель стандарта может в этом самостоятельно убедиться, если не вырывать фразы из контекста.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Существует еще аспект времени, который стандартом замалчивается, – момент завершения «Работы». Без его знания функционально-стоимостной анализ, основанный на моделировании, не будет завершен. Можно прятать голову в песок и не определять условие активации «Работы», но момент ее завершения мы видеть обязаны. К счастью, ответ на вопрос о моменте завершения «Работы» тривиален: «Работа» не может быть завершена, пока все ее входы не будут активированы. Теперь и нематематику должно быть ясным, что известные условия активации «Работ» на диаграммах нижнего уровня и известные условия окончания «Работ» на верхних уровнях позволяют однозначно восстановить информацию об условиях активации «Работ» на всех уровнях. Иначе говоря, условия активации «Работ» в IDEF0 являются предопределенными.

Рассмотрим теперь один из возможных вариантов конкретизации описания событий в IDEF0.

Моделирование организаций невозможно без учета происходящих в ней причинно-следственных связей или событий. Стандарт IDEF0 в явном виде не позволяет отображать события на схемах, поэтому инструментарий ARIS с возможностью изображать графический примитив «Событие» часто приводит в восторг некоторых разработчиков программных продуктов, вовлеченных по тем или иным причинам в организационное проектирование. У автора существуют серьезные сомнения в необходимости использования примитива «Событие» для целей моделирования событий (но не моделирования событий самого по себе).

Это обусловлено тем, что мы имеет дело не с самими событиями, а с информацией о явлениях, воспринимаемой как событие. Информация о явлении – это информационный ресурс. Бизнес-процессы обмениваются друг с другом только ресурсами и ничем иным, поэтому ясно, что класс «Событие» является вырожденным, и в «жизни» бизнес-процессов существует только один подкласс событий – «Поступление Ресурса», а сами «События» различаются видом ресурса. Например, нормативные документы, которые в соответствии с рекомендациями IDEF0 рассматриваются как «Управление», являются неизнашиваемым информационным ресурсом общего пользования. Другими словами, стрелки на IDEF0-диаграммах соответствуют «Событиям», а включение примитива «Событие» в любой стандарт проектирования бизнес-процессов ничем не оправдано и является избыточным – по крайней мере, если придерживаться ресурсной концепции управления организацией. Этот же вывод распространяется и на объекты, называемые «перекрестками» в стандарте IDEF3.

Итак, сформулируем еще одну установочную концепцию.

1. Исполнение «Работы» безусловно инициируется событием «Поступление Ресурса». Это соответствует классическим представлениям о том, что любое воздействие влечет реакцию. Не бывает воздействий без рефлексии на него. Поэтому поступление любого ресурса является управляющим воздействием.

2. Необходимым (но не достаточным) условием завершения «Работы» является свершение полного набора событий «Поступление Ресурса», связанных с интерфейсами «Работы».

Приведенная установочная концепция делает изобразительные свойства стандарта IDEF0 не только достаточными для описания ситуаций и условий исполнения «Работ» при моделировании организации, но и более выразительными, простыми и эффективными.

Об унификации описания бизнес-процессов

В качестве первой установочной концепции озвучивалась идея о принадлежности «Работ» одному классу объектов, обладающих одинаковым набором свойств и поведением. Для чего это нужно? Прежде всего, для того чтобы различные «Работы» могли общаться друг с другом на одном языке. Только в этом случае бизнес-процесс может быть открытой системой. О необходимости придерживаться идеологии открытых систем при проектировании модели бизнес-процессов как необходимом условии реализации принципа последовательных модернизаций писалось не раз [1, 2]. Только открытым системам свойственен низкий уровень издержек при сопровождении и доработках.

На моделирование бизнес-процессов, согласно методологии IDEF и первым ее интерпретациям, был ориентирован стандарт IDEF3. Основным его отличием от стандарта функционального моделирования IDEF0 была возможность задавать последовательность «Работ» с помощью дуг и условия на последовательность исполнения «Работ» с помощью логики «перекрестков» (синхронные и асинхронные ИИЛИ, исключающее ИЛИ). Предполагалось, что проектировщик, не вдаваясь в описание логики взаимодействия «Работ», разработает функциональную IDEF0-модель до определенного уровня декомпозиции «Работ», а затем на нижних уровнях перейдет на моделирование бизнес-процессов в соответствии со стандартом IDEF3, отображая уже логику взаимодействия «Работ». Поскольку уровень декомпозиции IDEF0-модели, на котором осуществляется переход на стандарт IDEF3, определяется проектировщиком субъективно, то говорить о какой-либо универсальности представлений бизнес-процессов при таком подходе не приходится.

Как было показано, предлагаемая конкретизация положений IDEF0 в части описания событий и, следовательно, логики, не уступает по функциональности стандарту IDEF3. Так, в рамках ресурсной концепции управления организацией дуги в стандарте IDEF0 также могут показывать последовательность исполнения «Работ», а условия исполнения «Работ» задаются событиями «Поступление Ресурса». Возможно, это явилось одной из причин, почему в популярном инструментарии BPwin диаграммы, поддерживающие стандарт IDEF0, называются Business Process Diagram. Одно можно сказать точно: одновременное использование стандартов IDEF0 и IDEF3 в рамках одного проектного процесса никак не способствует однозначному пониманию понятия «бизнес-процесс» в системе стандартов IDEF.

Что такое «Работа», интуитивно ясно. Сложнее обстоит дело с бизнес-процессом, описываемым «Работами». В статье [3] собрано 10 различных определений бизнес-процесса и показано, насколько сложен логико-лингвистический анализ определений бизнес-процесса на смысловую непротиворечивость; там же приводится авторское определение. Для большей наглядности дадим определение бизнес-процесса, используя графическую нотацию IDEF0 и рекомендации по адаптации языка, сформулированные ранее. При разработке общей модели автором использовались установочные концепции, заимствованные из модели взаимодействия открытых систем, методических материалов ассоциаций документарной электросвязи и телекоммуникационного сообщества.

1. На вход бизнес-процесса поступают с выходов процессов-контрагентов ресурсы, которые преобразуются в бизнес-процессе в другие виды ресурсов, поставляемые контрагентам.

2. Все бизнес-процессы в организации объединены одной задачей – оказанием услуг друг другу на основе анализа запросов о поставке услуг. В частности, услугой может быть изготовление и поставка продукта.

3. Оказание услуг друг другу бизнес-процессы осуществляют согласно единой процедуре.

Рис. 2.

На Рис. 2 представлена универсальная IDEF0-модель бизнес-процесса, показывающая сущность интерфейсов «Работы»; как правило, проектировщики бизнес-процессов при их моделировании ее не раскрывают. Особенность этого графического определения – его акцентирование на интерфейсах бизнес-процессов, описываемых в виде отдельных «Работ». Часто осознание необходимости интерфейсов приходит к проектировщику с запозданием, вынуждая его переделывать модель или возлагать функции интерфейсов рассматриваемого бизнес-процесса на его контрагенты. В этом случае желательно «принудительно» создавать сначала промежуточную IDEF0-диаграмму, на которой изображены «Работы»: входные и выходные интерфейсы бизнес-процесса и «Работа», отражающая сущность бизнес-процесса (ею обычно ограничивается неопытный проектировщик). Этого можно не делать только в случае, если проектировщиком осознанно отсутствие необходимости разрабатывать интерфейсы бизнес-процессов. Структура предложенной модели бизнес-процессов соответствует современным представлениям о структуре систем, в том числе и систем управления.

Перечисленные концепции довольно жестко ограничивают множество возможных способов унификации бизнес-процессов. Один из них представляет бизнес-процессы в виде триады «Работ»: «Анализ реакции внешней среды», «Моделирование», «Воздействие на внешнюю среду». Данная идея изложена в [1] и основана на предположении, что организация – это система процессов «рефлексии». Важнейшим элементом является «Моделирование». Выбор этого термина диктуется точкой зрения автора на то, что бизнес-процессы обмениваются друг с другом не объектами «реального» мира, а представлениями о них. Такая точка зрения позволяет адекватно переходить к задаче оценки стоимости услуг или продуктов.

Моделирование – «Работа», отвечающая за непосредственное преобразование поставляемых бизнес-процессом «Ресурсов» и формирование новых «Ресурсов», поставляемых другим бизнес-процессом. Другой важнейшей функцией этой «Работы» является планирование (или программирование) поставок «Ресурсов» другим бизнес-процессом. План поставок строится для рассматриваемого бизнес-процесса с использованием модели его внешней среды (скажем, на основе заявок на поставку ресурсов). Входным интерфейсом бизнес-процесса является «Анализ реакции внешней среды» (т.е. «Работа», обеспечивающая на основе модели внешней среды и правил наблюдения «фильтрацию» поступающих «Ресурсов» и формирование необходимых спецификаций «Ресурсов», требуемых для исполнения «Моделирования»). Выходным интерфейсом бизнес-процесса является «Воздействие на внешнюю среду» (т.е. «Работа», осуществляющая поставку «Ресурсов» контрагентам на основе плана поставок, а также направляющая отчеты о поставках «Моделированию»).

Заключение

Механическое следование требованиям стандарта IDEF0 приводит, как правило, к игнорированию интерфейсов бизнес-процессов или к неполноте их описания. Беда не в том, что большая часть логики бизнес-процессов оказывается упущенной (ее можно восстановить позже), а в том, что логика операций, которые должны принадлежать одному из бизнес-процессов, часто возлагается проектировщиком на другие бизнес-процессы. Тем самым еще больше разрушается структурная однородность и универсальность представления бизнес-процессов. Следствием же является усложнение сопровождения модели на ее жизненном цикле и плохая масштабируемость модели (уникальность, неприспособленность к тиражированию и т.п.). Следование предложенному в статье способу унификации описания бизнес-процессов позволяет избежать подобных неприятностей.

Насколько предложенный подход к унификации описания бизнес-процессов будет полезен конкретному проектировщику, сильно зависит от его личных пристрастий, опыта реализованных проектов и иных обстоятельств. Большое значение имеет и область применения разрабатываемой модели. Так, для описания документооборота возможно, целесообразнее использовать Swim Lane – диаграммы, строящиеся в Bpwin на основе IFEF3-диаграмм, или сразу начинать проектирование с DFD-диаграмм. Предложенные «рецепты» являются выжимками приобретенного автором опыта при разработке процессных моделей нескольких организаций, для которого широта IDEF0 стандарта стала источником проектного «шума». Сущность приведенных рекомендаций выражается в направленном сужении стандартов организационного проектирования с целью «погружения» проектировщика в мир строгих абстракций, предлагаемых системной идеологией и общей теорией управления. Данные рекомендации окажутся полезными директорам информационных служб при постановке задач системным аналитикам и определении требований к стандартам разработки информационных систем.

!!! Полезный материал! Сборник статей по целевому управлению. Скачать >

Литература

1. С. Рубцов, Какой CASE-инструмент нанесет наименьший вред организации? // Директор информационной службы, 2002, – 1.
2. С. Рубцов, Взаимодействие открытых систем – старая концепция для новых идей. // Новые рынки, 2001, – 4.
3. С. Рубцов, Уточнение понятия ‘бизнес-процесс’. Менеджмент в России и за рубежом, 2001, – 6.
4. R. J. Mayer, C. P. Menzel, M. K. Painter, P. S. deWitte, et al. Information Integration For Concurrent Engineering (IICE). IDEF3 Process Description Capture Method Report. – Wright-Patterson Air Force Base, Ohio: Air Force Materiel Command, 1995.
5. National Institute of Standards and Technology. Integration Definition For Function Modeling (IDEF0). – Washington: Draft Federal Information, 1993.

Автор: Сергей Рубцов