В статье Владимира Репина рассматриваются важные практические аспекты моделирования в нотации IDEF0 в программном продукте Business Studio. Такие, на первый взгляд, простые объекты модели, как стрелки, многие используют некорректно. В статье раскрывается смысл стрелок в нотации IDEF0 и даются практические рекомендации по их использованию. Также рассматривается вопрос перехода с уровня IDEF0 на уровень BPMN и некоторые аспекты моделирования кросс-функциональных процессов в общей архитектуре процессов организации.
Смысл стрелок в нотации IDEF0
О нотации IDEF0 написано множество книг и учебников. Но одно дело рассматривать какой-то упрощенный абстрактный пример, а совсем другое – построить с использованием IDEF0 сложную, комплексную архитектуру бизнес-процессов средней или крупной организации. При практическом использовании IDEF0 нужно четко понимать три аспекта:
- Требования нотации.
- Метод ее применения, в первую очередь, для описания многоуровневой архитектуры бизнес-процессов (а не абстрактных примеров для учебников).
- Возможности конкретного программного продукта, в котором вы работаете (это особенно важно).
О методах построения процессной архитектуры компании можно подробнее прочитать в моей статье «Кратко об архитектуре бизнес-процессов компании».
Если пренебрегать указанными выше аспектами, то можно «наломать дров». На рис. 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 переходят с уровня на уровень, как показано на рис. 2. Например, «Стрелка Б», выходящая из «Бизнес-процесса А», входит в «Бизнес-процесс Б». Стрелки, как и функции, так же можно «декомопозировать»: «стрелка Б» разделяется на «Стрелку Б 1.1», «Стрелку Б 1.2» и «Стрелку Б 1.3».
Объект модели «Стрелка Б» на диаграмме верхнего уровня и объект «Стрелка Б» на диаграмме нижележащего уровня – это один и тот же объект.
Если стрелка разделяется на несколько дочерних стрелок, то поток объектов, движущихся по стрелке, так же разделяется. В качестве аналогии можно привести пример трубы большого диаметра, к которой приварен тройник, от которого идут три трубы меньшего диаметра и т.д.
Рис. 2. Поведение стрелок при переходе с уровня на уровень модели.
Если в программном обеспечении корректно поддерживается не только декомпозиция процессов, но и декомпозиция стрелок, прослеживаются все идущие по стрелкам объекты, то это говорит о высоком уровне зрелости такого продукта. Если же на каждом уровне модели возникают новые стрелки просто как графические примитивы, то это лишь имитация метода IDEF0.
В Business Studio вы можете проследить движение документов по стрелкам при переходе с уровня на уровень, при этом можно как объединять, так и разъединять потоки объектов (информация, документы, материальные объекты). Это важно понимать и не создавать на нижележащих диаграммах новые стрелки, которые оторваны от тех, которые приходят сверху. Но некоторые так и делают, оставляя на диаграмме стрелки с белыми кружочками и треугольниками («туннельные стрелки») – см. рис 1 слева внизу.
Пример. На контекстной диаграмме (А-0) показана внешняя ссылка «Клиенты», от которой идет стрелка «Потребность в товарах и услугах». На диаграмме категорий процессов (А0) эта стрелка разделяется на три стрелки:
- «Информация от потенциальных клиентов» - вход в процесс «Маркетинг и реклама».
- «Заказы на поставку товара и услуг» - вход в процесс «Продажи».
- «Запросы о состоянии заказа» - вход в процесс «Производство».
Документы, которые вы прикрепите к стрелке, должны будут разделиться на три потока – каждый в свой процесс.
Стрелки на модели в 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 созданы, среди прочих, две категории процессов – «Продажи» и «Закупки». Структура процессов в категории «Продажи» получилась такой:
- Продажи.
- Поиск новых клиентов.
- Проведение переговоров.
- Формирование КП (кросс-функциональный процесс).
- Получение запроса на формирование КП.
- …
- …
- …
- Выбор поставщиков сырья (функциональный процесс).
- …
- Согласование КП.
- Отправка ПК клиенту.
- Заключение договоров с клиентами.
- Управление заказами клиентов.
- Претензионная работа с клиентами.
Обратите внимание, что при выполнении процесса «Формирование КП» (кросс-функциональный процесс) выполняется задача «Выбор поставщиков сырья». Но это делает менеджер по закупке. То есть задача (функциональный процесс) из процесса «Закупки» попала в структуру процессов «Продажи». Как быть? Если мы уберем ее из процесса «Формирование КП» (и сделаем тоже самое со всеми другими подобными задачами), то у нас получится не процессная, а структурно-функциональная модель. Мы потеряем все кросс-функциональные процессы. Это очень плохо. Но как тогда быть? Рассмотрим структуру процессов «Закупки»:
- Закупки.
- Анализ остатков и планирование закупок.
- Поиск и выбор поставщиков сырья и материалов.
- …
- ….
- Выбор поставщиков сырья (функциональный процесс).
- …
- …
- Заключение договоров с поставщиками.
- Размещение заявок на сырье и материалы поставщикам.
- Управление поставками сырья и материалов.
- Претензионная работа с поставщиками.
Процесс (задача) «Выбор поставщиков сырья» выполняется в рамках процессов закупки. При каких условия выполняется процесс «Поиск и выбор поставщиков сырья и материалов»? Это штатный, повторяющийся процесс. Он запускается регулярно подразделением закупок для обеспечения производственной программы организации – закупка на склад и/или для выполнения конкретных заказов.
Мы видим также, что «Выбор поставщиков сырья» может выполнятся при формировании коммерческого предложения. Таким образом, описав один раз процесс (задачу) «Выбор поставщиков сырья» в рамках процессов закупки, мы можем использовать его в качестве типового, «повторно выполняемого» - Call activity – в понимании BPMN. То есть он будет частью одного из кросс-функциональных процессов в области продаж.
Аналогично можно поступать и с другими процессами. Таким образом, у нас есть базовая архитектурная модель, где представлены все процессы. Часть из них может быть использована в качестве типовых на моделях кросс-функциональных бизнес-процессов организации. Процессный архитектор должен четко понимать такой методический подход и использовать его на практике.
Опубликовано по материалам:
https://bpm3.ru/
Март 2025 г.
Поделиться: