Цитаты из книги «Разработка архитектуры бизнес-процессов компании в Business Studio»

Напомню, что в нотации IDEF0 рекомендуется использовать не более 4—5 стрелок с каждой стороны (на практике их может быть 6—8). В противном случае модель становится слишком сложной и нечитаемой.

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

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

Вообще говоря, это делать целесообразно, если мы хотим спроектировать и автоматизировать процессы управления бизнес-процессами. Некоторые этапы таких процессов могут быть автоматизированы, например, в BPMS.

Подпроцессы, представленные на диаграмме «Поиск потенциальных клиентов», являются уже достаточно простыми объектами деятельности. Декомпозиция этих блоков на диаграмму в нотации IDEF0 не представляется целесообразной. Каждый такой подпроцесс нужно описывать в нотации формата Work Flow: eEPC или BPMN. Возникает вопрос, что делать со стрелками, входящими и исходящими из блоков на диаграмме «Поиск потенциальных клиентов»? На диаграмме в нотации Work Flow можно и нужно показывать только документы (информацию), которые используются при выполнении процесса, т.е. его входы и выходы. На схеме в нотации Work Flow нецелесообразно будет показывать документы, связанные

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

Стрелки «Д» и «Ж» выделены жирным. Это означает, что по ним перемещаются материальные объекты. Введем правило:

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

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

К чему приводит такой подход к описанию процессов? Блок «Выполнение процесса» декомпозируют на подпроцессы «выполнения». Затем каждый подпроцесс декомпозируют вниз и снова описывают по циклу управления и т. д. Фактически, получается удвоение уровней иерархии, которое крайне осложняет процесс моделирования. В некоторой компании при наличии 4 уровней управления было получено 8 уровней иерархии в архитектуре. Это путь в никуда.