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

В статье Владимира Репина рассматриваются практически важные аспекты моделирования в нотации 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 справа вверху – одна стрелка соединяет два процесса, при этом к ней можно привязать несколько документов из справочника (см. скрин).

Рис. 1. Использование стрелок на диаграммах в нотации IDEF0 в Business Studio.

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

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

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

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

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

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

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

Рис. 2. Поведение стрелок при переходе с уровня на уровень модели.

Если в программном обеспечении корректно поддерживается не только декомпозиция процессов, но и декомпозиция стрелок, прослеживаются все идущие по стрелкам объекты, то это говорит о высоком уровне зрелости такого продукта. Если же на каждом уровне модели возникают новые стрелки просто как графические примитивы, то это лишь имитация метода 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» могут быть связаны между собой (синхронизированы) через обмен данными в конкретной информационной системе.

Рис.3. Входы и выходы на IDEF0 и BPMN.

Некоторые специалисты говорят об «основных входах, которые запускают процесс». Я считаю такое понятие бессмысленным, поскольку для успешного выполнения процесса в соответствии с установленными требованиями нужны все входящие документы, но каждый в свое время. Например, при формировании коммерческого предложения, менеджер запросил дополнительную информацию для уточнения требований, но не получил ее от клиента, сделал КП без этой информации. Результат – клиент не принял КП, так как оно не отражает его действительной потребности. Если какой-то процесс можно выполнить без «второстепенных» входов, то это проблема владельца процесса, а не модели в 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

Автор cтатьи
Владимир Репин
к.т.н., доцент, член ABPMP Russian Chapter, Генеральный директор ООО «Владимир Репин Менеджмент», консультант по управлению.