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

Смысл стрелок в нотации IDEF0

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

1. Требования нотации.
2. Метод ее применения, в первую очередь, для описания многоуровневой архитектуры бизнес-процессов (а не абстрактных примеров для учебников).
3. Возможности конкретного программного продукта в котором вы работаете (это особенно важно).

О методах построения процессной архитектуры компании можно подробнее прочитать в моей статье «Кратко об архитектуре бизнес-процессов компании».

Если пренебрегать указанными выше аспектами, то можно, как говорится, «наломать дров». На рис. 1 слева снизу показан пример таких «дров».

Давайте начнем с обсуждения смысла стрелки, соединяющей процессы на диаграмме в нотации IDEF0. Что означает стрелка? Это – однонаправленная связь между объектами модели – двумя процессами или процессом и объектом внешней по отношению к организации среды. Можно интерпретировать стрелку, как трубу, по которой от одного процесса к другому движутся информационные и материальные объекты. Стрелка, сама по себе, — это объект модели, указывающий на связь между двумя объектами на диаграмме. Очень важно понимать, что стрелка, в общем случае, — это не конкретный документ, имеющий установленную форму (например, заявка на транспортировку или проект договора), а именно набор объектов.

В Business Studio есть справочник стрелок всех диаграмм IDEF0 — «Словарь стрелок». К стрелкам можно привязывать конкретные объекты из справочника «Функциональные объекты»: информацию, документы, материальные объекты. Другими словами, по стрелке от одного процесса к другому движется поток разных объектов.

Рассмотрим частные ошибки моделирования в IDEF0. На рис. 1 слева вверху показаны три стрелки, выходящие из «Процесса N» и входящие в «Процесс N+1». Нотация IDEF0 не ограничивает количество таких стрелок, хотя разработчики SADT рекомендуют показывать не более 6 стрелок, чтобы диаграмма не стала перегруженной. На практике, мне встречались схемы в нотации IDEF0, на которых между процессами показывали по 30-40 стрелок, именованных как конкретные документы. Причем такой подход авторы считали удобным и понятным руководителям.

Почему я считаю такой метод к моделированию некорректным (перечеркнут красным крестом)? Логика очень проста. Если мы соединили два процесса связью («трубой»), к которой в Business Studio можно прикрепить реальные документы, то зачем создавать несколько стрелок связи между двумя объектами? Из-за этого диаграмма становится чрезмерно сложной – как микросхема. Поэтому я использую способ, показанный на рис. 1 справа вверху – одна стрелка соединяет два процесса, при этом к ней можно привязать несколько документов из справочника (см. скрин).

При таком подходе нужно аккуратно называть стрелку связи. Некоторые перечисляют все объекты, которые движутся по стрелке. Но это плохой метод. Как правило, я использую относительно короткое название, отражающее суть потока объектов между процессами. В результате модель процессов на верхнем уровне получается вполне понятной для ее основных читателей – руководителей верхнего уровня.
Привязывать объекты к стрелкам в Business Studio можно, но когда это нужно делать? Только в том случае, если руководители хотят формировать паспорта процессов верхнего уровня, которые включают информацию о контексте – входы/выходы и поставщиков/клиентов процесса. Если паспорта (регламенты) процессов верхнего уровня не нужны, то на моделях 0-3 уровня можно ограничиться только стрелками.

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

«… Благодаря своим возможностям, нотация IDEF0 хорошо подходит для описания верхних уровней модели деятельности компании. Согласен с автором, что главное – помнить что данная нотация не предназначена для моделирования последовательности операций:

Стрелки не моделируют поток управления как в традиционных процессных моделях.
INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0)

Но в подавляющем количестве случаев на верхних уровнях модели деятельности это и невозможно сделать. Зато можно показать какие функции (группы процессов) есть в компании и как они взаимодействуют. А это в свою очередь можно использовать, например, для распределения ответственности между крупными орг.единицами (департамент, управление). Поток управления необходимо показывать на процессных уровнях модели деятельности (например, в нотации BPMN), связывая операции с помощью потока управления или с помощью конечных/начальных событий.
Дмитрий Пинаев, Генеральный директор ГК «Современные технологии управления».

Что происходит со стрелками при переходе с уровня на уровень?

При декомпозиции процесса стрелки в IDEF0 переходят с уровня на уровень, как показано на рис. 2. Например, «Стрелка Б», выходящая из «Бизнес-процесса А», входит в «Бизнес-процесс Б». Стрелки, как и функции, так же можно «декомопозировать»: «стрелка Б» разделяется на «Стрелку Б 1.1», «Стрелку Б 1.2» и «Стрелку Б 1.3».
Объект модели «Стрелка Б» на диаграмме верхнего уровня и объект «Стрелка Б» на диаграмме нижележащего уровня – это один и тот же объект.
Если стрелка разделяется на несколько дочерних стрелок, то поток объектов, движущихся по стрелке, так же разделяется. В качестве аналогии можно привести пример трубы большого диаметра, к которой приварен тройник, от которого идут три трубы меньшего диаметра и т.д.

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

В Business Studio вы можете проследить движение документов по стрелкам при переходе с уровня на уровень, при этом можно как объединять, так и разъединять потоки объектов (информация, документы, материальные объекты). Это важно понимать и не создавать на нижележащих диаграммах новые стрелки, которые оторваны от тех, которые приходят сверху. Но некоторые так и делают, оставляя на диаграмме стрелки с белыми кружочками и треугольниками («туннельные стрелки») – см. рис 1 слева внизу.

Пример. На контекстной диаграмме (А-0) показана внешняя ссылка «Клиенты», от которой идет стрелка «Потребность в товарах и услугах». На диаграмме категорий процессов (А0) эта стрелка разделяется на три стрелки:

1. «Информация от потенциальных клиентов» — вход в процесс «Маркетинг и реклама».
2. «Заказы на поставку товара и услуг» — вход в процесс «Продажи»;
3. «Запросы о состоянии заказа» — вход в процесс «Производство».

Документы, которые вы прикрепите к стрелке, должны будут разделиться на три потока – каждый в свой процесс.

Стрелки на модели в IDEF0 и входы/выходы на модели в BPMN

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

На рис. 3 я попытался это показать визуально. От «Процесса 1» к «Процессу 2» проведена «Стрелка А», по которой движутся «Документ А» и «Документ «Б».

«Процесс 2» декомпозирован с помощью нотации BPMN. Обратите внимание, что на этой схеме показаны два свернутых пула – «Процесс 1» и «Процесс N», с которыми «Процесс 2» взаимодействует на верхнем уровне.
Первым в «Процесс 2» заходит «Документ А» — он попадает в «Задачу 1». Потом, по ходу выполнения процесса, «Документ Б» поступает в «Задачу 2» и так далее.

По ходу процесса возникает движение документов в обратную сторону. Так «Документ В» выходит из «Задачи 2» и попадает в «Процесс 1» по стрелке обратной связи.

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

Отмечу, что использование стрелок типа Message Flow на модели в BPMN, в общем случае, не означает, что «Процесс 1» запускает на исполнение «Процесс 2». Так же и «Процесс N» не обязательно стартует сразу после получения «Документа Д» из «Задачи 4». Кстати, «Процесс 1» и «Процесс 2» могут быть связаны между собой (синхронизированы) через обмен данными в конкретной информационной системе.

Некоторые специалисты говорят об «основных входах, которые запускают процесс». Я считаю такое понятие бессмысленным, поскольку для успешного выполнения процесса в соответствии с установленными требованиями нужны все входящие документы, но каждый в свое время. Например, при формировании коммерческого предложения, менеджер запросил дополнительную информацию для уточнения требований, но не получил ее от клиента, сделал КП без этой информации. Результат – клиент не принял КП, так как оно не отражает его действительной потребности. Если какой-то процесс можно выполнить без «второстепенных» входов, то это проблема владельца процесса, а не модели в IDEF0. Например, можно произвести пельмени, но вдруг окажется, что упаковки и этикеток для этой партии на складе нет. Можно ли считать процесс производства партии успешно завершенным? Об этом и речь… Кстати, если в ваших моделях можно найти процессы без входов (слева и сверху), то вы уже приблизились к осознанию понятия Бога – создание нового из ничего, «Ex Nihilo». Даже креативная идея не рождается на пустом месте – входы есть, хотя бы их можем не осознавать.

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

На рис. 3 показан простой пример. В общем случае, для руководителя, читающего диаграммы IDEF0, гораздо сложнее проследить поток документов, выходящий из внешней сущности на контекстной диаграмме, проходящий через 2-3 уровня декомпозиции и входящий в конкретный процесс. Но это особенность любой архитектурной процессной модели. При использовании, например, VAD ситуация может быть еще хуже, так как стрелки на диаграммах верхнего уровня вообще, как правило, не показывают. С другой стороны, отказаться от моделей верхнего уровня и делать просто одноуровневый реестр кросс-функциональных процессов в нотации BPMN – тоже не выход. В этом случае не видна вся картина бизнеса.

Проблема методического подхода IDEF0 (и не только): функциональные и кросс-функциональные бизнес-процессы

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

Допустим, на модели А0 созданы, среди прочих, две категории процессов – «Продажи» и «Закупки». Структура процессов в категории «Продажи» получилась такой:

1. Продажи.
   1.1. Поиск новых клиентов.
   1.2. Проведение переговоров.
   1.3. Формирование КП (кросс-функциональный процесс).
   1.3.1. Получение запроса на формирование КП.
   1.3.2. …
   1.3.3. …
   1.3.4. …
   1.3.5. Выбор поставщиков сырья (функциональный процесс).
   1.3.6. …
   1.3.7. Согласование КП.
   1.3.8. Отправка ПК клиенту.
   1.4. Заключение договоров с клиентами.
   1.5. Управление заказами клиентов.
   1.6. Претензионная работа с клиентами.

Обратите внимание, что при выполнении процесса «Формирование КП» (кросс-функциональный процесс) выполняется задача «Выбор поставщиков сырья». Но это делает менеджер по закупке. То есть задача (функциональный процесс) из процесса «Закупки» попала в структуру процессов «Продажи». Как быть? Если мы уберем ее из процесса «Формирование КП» (и сделаем тоже самое со всеми другими подобными задачами), то у нас получится не процессная, а структурно-функциональная модель. Мы потеряем все кросс-функциональные процессы. Это очень плохо. Но как тогда быть? Рассмотрим структуру процессов «Закупки»:

1. Закупки.
   1.1. Анализ остатков и планирование закупок.
   1.2. Поиск и выбор поставщиков сырья и материалов.
   1.2.1. …
   1.2.2. ….
   1.2.3. Выбор поставщиков сырья (функциональный процесс).
   1.2.4. …
   1.2.5. …
   1.3. Заключение договоров с поставщиками.
   1.4. Размещение заявок на сырье и материалы поставщикам.
   1.5. Управление поставками сырья и материалов.
   1.6. Претензионная работа с поставщиками.

Процесс (задача) «Выбор поставщиков сырья» выполняется в рамках процессов закупки. При каких условия выполняется процесс «Поиск и выбор поставщиков сырья и материалов»? Это штатный, повторяющийся процесс. Он запускается регулярно подразделением закупок для обеспечения производственной программы организации – закупка на склад и/или для выполнения конкретных заказов.

Мы видим также, что «Выбор поставщиков сырья» может выполнятся при формировании коммерческого предложения. Таким образом, описав один раз процесс (задачу) «Выбор поставщиков сырья» в рамках процессов закупки, мы можем использовать его в качестве типового, «повторно выполняемого» — Call activity – в понимании BPMN. То есть он будет частью одного из кросс-функциональных процессов в области продаж.

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

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

Март 2025 г.

www.bpm3.ru