Декомпозиция бизнес-процессов: уровни и операции

На схеме процесс «согласование договора» занимает один прямоугольник. В жизни за ним стоят регистрация проекта, юридическая проверка, правки инициатора, повторная проверка, визы нескольких руководителей и ожидание подписи. Пока руководитель видит только прямоугольник, он может спросить «почему так долго?», но не может понять, где пропадает неделя. Декомпозиция процессов на операции (process decomposition) раскладывает процесс сверху вниз на подпроцессы, задачи и шаги. Раскладывают до уровня, на котором у каждого элемента есть исполнитель, вход, выход и измеримое время.

Методическое пособие компании Blueprint «Process Decomposition Job Aid and Template» начинается с наблюдения, которое меняет отношение к методу. Автоматизируют не крупные бизнес-процессы, а их подпроцессы и задачи. Автоматизация — лишь одна из стратегий улучшения, наряду с модернизацией и стандартизацией. Декомпозиция, по словам авторов пособия, нужна именно для того, чтобы понять, какая стратегия подойдёт под поставленную цель. Там же есть честная оговорка: моделирование процесса только кажется простым упражнением. Трудным его делают объём деталей и число вложенных уровней подпроцессов и задач.

Ниже собраны все линии метода, которые есть в нашем пакете источников. Это функциональная декомпозиция из бизнес-анализа, уровневая модель из процессного моделирования, подпроцессы BPMN, разделение ответственности из архитектуры предприятия, деление бизнеса на процессы у системного архитектора и правило гранулярности из ИТ-операций. Затем разобраны ограничения, типовые ошибки и пятинедельный план. В конце показано, как вести этот план во фрейме OrgDevTools.

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

Происхождение и исследовательская база: декомпозиция процессов на операции

У метода нет одного автора и одной книги-первоисточника. Он сложился в нескольких дисциплинах, и каждая добавила своё правило: как резать процесс, где остановиться, что фиксировать на каждом уровне. Если читать только один источник, получится однобокая картина. Аналитик увидит дерево функций, архитектор увидит подпроцессы BPMN, инженер увидит перезапускаемые модули.

Линия бизнес-анализа: функциональная декомпозиция

Справочник BAwiki в статье «Decomposition — Functional and Otherwise» называет функциональную декомпозицию (functional decomposition) разновидностью декомпозиции, которую описывает большинство руководств по бизнес-анализу. Со ссылкой на IIBA (International Institute of Business Analysis) она отнесена к базовым техникам бизнес-аналитика. Статья устроена как практическое руководство и разбирает:

• типы декомпозиции (функциональная — лишь один из них);

• связность и сцепление (cohesion and coupling) как критерии качества разбиения;

• зачем вообще раскладывать работу;

• пошаговый порядок из семи шагов;

• три формы результата: диаграмму функциональной декомпозиции, иерархический план (outline) и таблицу;

• преимущества, недостатки и практические советы.

Отдельно BAwiki подчёркивает пользу для управления рамками проекта. По диаграмме функциональной декомпозиции команда прямо показывает, какие функции входят в проект, как они связаны и как мелкие функции сворачиваются в крупные наборы возможностей. Это снимает типичный спор «а это мы тоже делаем?» ещё до старта работ.

В той же статье упомянута критика функциональной декомпозиции с позиции проектирования систем. В 2003 году её высказал Мюррей Кантор (Murray Cantor) из Rational Software. Содержание этой критики в наших материалах не раскрыто, поэтому пересказывать её доводы мы не будем. Сам факт важен: метод давно обсуждается как спорный, а не как бесспорный стандарт.

Вторая опора этой линии — прикладная статья серии For Dummies о диаграммах декомпозиции процессов в отчёте бизнес-аналитика. Её автор, Пол Малви (Paul Mulvey, CBAP), директор по клиентским решениям в B2T Training, занимается бизнес-анализом с 1995 года. Статья отвечает на два вопроса: как построить диаграмму декомпозиции процесса и как задокументировать каждый процесс, попавший на неё. Из этой пары вытекает рабочее правило: диаграмма без описания элементов — не результат анализа, а эскиз.

Линия процессного моделирования: уровни и Blueprint

Пособие Blueprint строит декомпозицию как лестницу уровней. Уровень 0 описывает только то, чего процесс добивается. Каждый следующий уровень добавляет детали: подпроцессы, затем задачи, затем шаги внутри задачи. В пособии есть пример декомпозиции реального процесса, объяснение, как присваивать подпроцессам и задачам значения (values) под выбранную стратегию улучшения, и пустой шаблон для повседневной работы. Сама работа по документированию верхнего процесса и всех связанных с ним подпроцессов и задач, по определению Blueprint, и есть декомпозиция.

В блоге Blueprint («Process Decomposition: Why It's So Important») названы три выгоды метода:

• более обоснованные решения и анализ бизнес-процессов — решения принимают по разложенной картине, а не по общему впечатлению;

• точный поиск кандидатов на автоматизацию — видно, какие именно задачи стоит отдавать роботу или системе;

• симуляция процесса и прогнозная аналитика — дерево со значениями позволяет проигрывать изменения до внедрения.

Линия методологии разработки: RUP и SOMA

Руководство по расширению RUP для бизнес-моделирования описывает то же движение языком уровней (Process Level). На вход декомпозиции поступают модели процессов уровня 1, иногда записанные просто как повествование, и связанные с ними бизнес-прецеденты уровня 1. На выходе получается набор задокументированных процессов уровня 2. Их сохраняют в модели бизнес-анализа как реализации бизнес-прецедентов. Уже на уровне 2 обычно можно построить диаграмму деятельности (activity diagram). Отсюда эмпирическое правило руководства: три уровня декомпозиции.

Там же показано, как результаты декомпозиции в методике SOMA соотносятся с уточнением прецедентов (use-case refinement) в бизнес-моделировании. Практический смысл для руководителя простой: разные методологии называют уровни по-разному, но описывают одно и то же дерево. Спорить о терминах бесполезно, договориться о числе и содержании уровней — обязательно.

Линия нотации: подпроцессы BPMN

Руководство Visual Paradigm по подпроцессам BPMN переводит декомпозицию в нотацию. Подпроцесс бывает развёрнутым (expanded), когда внутренние шаги видны прямо на схеме, и свёрнутым (collapsed), когда это блок со ссылкой на отдельную диаграмму. Руководство выделяет два основных сценария использования: декомпозицию крупного процесса и описание повторяющихся действий через повторно используемые подпроцессы. Отдельно разобраны специальные типы — событийный, транзакционный и ad-hoc.

Для BPM-дисциплины это базовая тема. В курсе «Fundamentals of Business Process Management» декомпозиции процессов посвящена отдельная лекция (FBPM-3.5). В пакете есть и статья Карло Марколи (Carlo Marcoli) о целостном подходе к моделированию бизнес-процессов, но её содержание в материалах не извлечено.

Линия архитектуры предприятия: разделение ответственности

В цифровой библиотеке Gesellschaft für Informatik опубликована работа «Business Process Decomposition — An Approach Based on the Principle of Separation of Concerns». Её идея видна из названия: резать процесс по принципу разделения ответственности (separation of concerns), чтобы каждый фрагмент отвечал за одну заботу, а не за смесь разнородных задач. В карточке работы есть ссылка на исследование Диогу Кардозу и Педру Соузы (Diogo Cardoso, Pedro Sousa) «Generation of Stakeholder-Specific BPMN Models», вышедшее в 2020 году в серии Lecture Notes in Business Information Processing. Тема этой связи — генерация BPMN-моделей под конкретных заинтересованных лиц. Одна и та же декомпозиция может давать разные представления процесса для разных стейкхолдеров. В пакете есть и статья журнала EMISA (Enterprise Modelling and Information Systems Architectures), но её текст в материалах не приведён.

Линия системной архитектуры: Геррит Мюллер

Геррит Мюллер (Gerrit Muller, USN-SE, Конгсберг, Норвегия) в статье о декомпозиции бизнеса на процессы делит компанию на четыре процесса:

• клиентоориентированный (Customer Oriented Process);

• создание продукта (Product Creation Process);

• управление людьми и технологиями (People and Technology Management Process);

• политика и планирование (Policy and Planning Process) — проактивный интегрирующий процесс.

У каждого процесса своё число экземпляров. Клиентоориентированный зависит от географии, клиентской базы и цепочки поставок. Создание продукта идёт по одному экземпляру на разрабатываемую сущность: семейство продуктов, продукт или подсистему. Управление людьми и технологиями — по одному на компетенцию, то есть на связный набор технологий и методов. Политика и планирование — по одному на бизнес.

Мюллер добавляет оговорку, полезную любому, кто проектирует процессы. Даже разработка одной новой функции для существующего продукта проходит весь процесс создания продукта целиком. Часть шагов при этом оказывается почти пустой, и это «не причиняет вреда». Он же показывает, что клиентоориентированный процесс — главный заказчик процесса создания продукта, поэтому архитектор должен его понимать, а лучше — иметь в нём опыт.

Линия ИТ-операций: оптимальная гранулярность

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

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

Линия трансформаций: способы разбиения

Статья Каджал Винаяк (Kajal Vinayak) о декомпозиции в крупных корпоративных трансформациях структурирует тему через четыре подхода: нисходящий (top-down), восходящий (bottom-up), функциональный и ценностный (value-based). Далее разобраны роль BPMN и визуальных моделей, которые помогают показывать процесс на разных уровнях, участие стейкхолдеров, типичные трудности, поддержка внедрения технологий и долгосрочная польза для компании. Эти подтемы раскрыты ниже в принципах, ошибках и плане.

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

Ключевые идеи и принципы: декомпозиция процессов на операции

1. Принцип: иерархия уровней

   Декомпозиция — это дерево, а не список. Наверху стоит уровень 0: цель процесса одной фразой («клиент получил подписанный договор»). Ниже идут подпроцессы, задачи и шаги. Каждый элемент нижнего уровня входит ровно в один элемент верхнего. Правило RUP о трёх уровнях работает как ориентир: обычно к этому моменту процесс уже можно нарисовать как диаграмму деятельности и измерить. Если для этого нужен пятый или шестой уровень, процесс, скорее всего, плохо очерчен сверху и его стоит разделить на два.

2. Принцип: операция — минимальная измеримая единица

   Операция — шаг, который выполняет один исполнитель без передачи работы другому и без смены вида деятельности. Её можно измерить: время, стоимость, частоту, долю брака. Пока внутри элемента есть передача из рук в руки или переключение между разными видами работы, его можно резать дальше. Когда ни того, ни другого нет, разбиение останавливают. Это и есть практическое понимание «оптимальной гранулярности» из BICsuite: мельче — дороже в описании и сопровождении без новой информации, крупнее — внутри прячутся передачи и ожидания.

3. Принцип: нисходящая декомпозиция

   Нисходящий подход (top-down) начинается с цели и рамок процесса и ведёт вниз. Он удобен, когда процесс описывают впервые, перестраивают под новую стратегию или готовят к внедрению системы. Сильная сторона — целостность: ничего лишнего, всё подчинено цели уровня 0. Слабая — риск описать процесс «как должен быть», а не как работает. Рамки удобно задавать через SIPOC: поставщики, входы, крупные шаги, выходы, клиенты.

4. Принцип: восходящая декомпозиция

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

5. Принцип: функциональная, процессная и ценностная логика

   Резать можно по разным признакам. Функциональная декомпозиция отвечает на вопрос «из каких функций состоит работа» и не обязательно показывает порядок. Процессная отвечает на вопрос «в какой последовательности идут шаги и что передаётся между ними». Ценностная группирует шаги по вкладу в результат для клиента. В одном дереве признак выбирают явно. Иначе рядом окажутся функция «бухгалтерия», шаг «отправить письмо» и этап «согласование», и дерево перестанет что-либо объяснять.

6. Принцип: связность и сцепление

   Хорошее разбиение даёт элементы с высокой связностью (cohesion): всё внутри относится к одной задаче. Сцепление (coupling) между элементами при этом низкое: они мало зависят друг от друга. Тот же смысл несёт принцип разделения ответственности из работы в библиотеке GI. Если операция «проверка договора» включает и юридический анализ, и поиск подписанта, у неё две заботы. Её стоит разделить: у частей разные исполнители, разное время и разные причины сбоев.

7. Принцип: явные входы, выходы и исполнитель

   У каждой операции фиксируют вход (что нужно, чтобы начать), выход (что получается) и исполнителя. Выход предыдущей операции должен совпадать с входом следующей. Если не совпадает, на стыке скрыта неописанная операция или потеря. Исполнителей и передачи между ними наглядно показывает диаграмма дорожек. Это прямое продолжение совета Малви: каждый элемент диаграммы нужно задокументировать, а не только нарисовать.

8. Принцип: значения на каждом элементе

   Пособие Blueprint советует присваивать подпроцессам и задачам значения. На практике это длительность, трудозатраты, частота, объём, число ошибок. Без значений дерево остаётся картинкой. Со значениями оно становится моделью: на ней проверяют гипотезы, симулируют изменения и выбирают кандидатов на автоматизацию — те самые три выгоды из блога Blueprint. Сумма времени операций нижнего уровня должна сходиться с наблюдаемым временем верхнего. Большое расхождение означает, что часть работы или ожидания в дерево не попала.

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

9. Принцип: стратегия улучшения выбирается после разложения

   По логике Blueprint, порядок такой: сначала декомпозиция и значения, потом выбор стратегии — автоматизация, модернизация, стандартизация. Одна операция просится в систему, потому что она повторяемая и рутинная. Другая требует стандарта, потому что каждый исполнитель делает её по-своему. Третью нужно просто убрать. Применять одну стратегию ко всему процессу целиком — значит заведомо промахнуться по части операций.

10. Принцип: разделение ценных и неценных операций

    После замера каждую операцию относят к одной из групп: создаёт ценность для клиента, необходима бизнесу (требования регулятора, учёт) или не нужна никому. В последнюю группу попадают ожидание, повторная проверка, дублирующее согласование, лишние перемещения. Классификацию удобно вести по 7 видам потерь, а долю ценного времени считать как Process Cycle Efficiency.

11. Принцип: последовательность управляется отдельно от операций

    Вывод BICsuite переносится на офисную работу напрямую. Операция не должна «знать», кому отдавать результат и что делать при отказе. Это логика маршрута, и её держат в схеме процесса, регламенте или системе. Когда маршрут живёт в головах исполнителей («потом Петрову, если он в отпуске — Ивановой»), процесс теряет прозрачность, а изменение одного шага ломает соседние.

12. Принцип: подпроцессы BPMN как форма записи

    В нотации BPMN уровни декомпозиции выражаются подпроцессами:

    • развёрнутый подпроцесс показывает внутренние шаги прямо на схеме верхнего уровня — удобно, когда шагов немного;

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

    • повторно используемый подпроцесс описывает одинаковые действия (например, «проверка контрагента») один раз и вызывается из разных процессов;

    • событийный подпроцесс запускается при наступлении события внутри процесса, например при отмене заказа клиентом;

    • транзакционный подпроцесс объединяет шаги, которые должны выполниться либо все, либо ни один, с откатом при сбое;

    • ad-hoc подпроцесс содержит действия без жёсткого порядка: исполнитель сам решает, что и когда делать.

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

13. Принцип: экземпляры процесса и «пустые» шаги

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

14. Принцип: разные представления для разных стейкхолдеров

    Из связи с работой Кардозу и Соузы следует: одна декомпозиция может давать несколько представлений. Директору нужен уровень 0–1 с ключевыми цифрами. Владельцу процесса — уровень 2 с исполнителями. Аналитику автоматизации — нижний уровень с входами, выходами и правилами. Участие стейкхолдеров в декомпозиции нужно не для согласования «красивой схемы», а для того, чтобы каждый уровень был верен для тех, кто по нему будет работать.

15. Принцип: декомпозиция как основа внедрения технологий и трансформаций

    При внедрении системы декомпозиция работает как техническое задание. Видно, какие операции система берёт на себя, какие остаются людям и где проходят передачи между человеком и системой. Долгосрочная польза в том, что дерево процесса становится общим языком: на нём обсуждают изменения, обучают новичков, ставят метрики. Карта уровней 0–2 — частный случай картирования процессов, а замеры на нижнем уровне готовят почву для картирования потока создания ценности.

Ограничения, слепые зоны и критика: декомпозиция процессов на операции

Типовые ошибки при работе: декомпозиция процессов на операции

1. Ошибка 1: резать до бесконечности.

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

   Как избежать

   заранее запишите правило остановки — операция выполняется одним исполнителем без передачи и без смены вида работы, и её можно измерить. Ориентир по глубине — три уровня, как в правиле RUP. Если нужно больше, проверьте, не слишком ли широко задан процесс на уровне 0.

2. Ошибка 2: смешивать признаки разбиения.

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

   Как избежать

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

3. Ошибка 3: дерево без значений.

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

   Как избежать

   следуйте совету Blueprint и присваивайте значения подпроцессам и задачам сразу при описании. Минимум — время выполнения, время ожидания перед операцией и частота. Сверяйте сумму нижнего уровня с наблюдаемым временем процесса.

4. Ошибка 4: описывать процесс из кабинета.

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

   Как избежать

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

5. Ошибка 5: оставлять маршрут внутри операций.

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

   Как избежать

   по принципу BICsuite отделите операции от логики последовательности. Маршруты, условия и замены зафиксируйте в схеме процесса, регламенте или системе. Описание операции должно отвечать на вопрос «что сделать», а не «кому потом отдать».

6. Ошибка 6: выбирать стратегию до декомпозиции.

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

   Как избежать

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

План внедрения: декомпозиция процессов на операции

1. Неделя 1: рамки и уровень 0. Выберите один процесс с понятной болью: долгий цикл, частые возвраты, жалобы клиентов. Сформулируйте цель одной фразой — это уровень 0. Задайте рамки: где процесс начинается, где заканчивается, кто клиент, что на входе и выходе. Определите, экземпляр чего вы описываете (продукт, регион, тип заявки). Выберите признак разбиения и запишите правило остановки. Назначьте владельца процесса и соберите 3–5 исполнителей с разных участков.

2. Неделя 2: уровни 1 и 2. Постройте каркас сверху: 4–7 подпроцессов уровня 1, затем задачи уровня 2 в каждом. Параллельно проведите наблюдение и короткие интервью с исполнителями: что они реально делают, что получают и кому отдают. Сверьте каркас с фактом и добавьте недостающие задачи — повторные проверки, ожидания, обходные пути. Проверьте связность: если у задачи две заботы, разделите её.

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

4. Неделя 4: ценность и стратегия. Разделите операции на три группы: ценные для клиента, необходимые бизнесу, ненужные. Для неценных определите вид потери. Посчитайте долю ценного времени. Каждой операции назначьте стратегию: убрать, объединить, стандартизировать, модернизировать или автоматизировать. Отдельно отметьте логику маршрута, которая живёт в головах людей, и решите, куда её перенести.

5. Неделя 5: запуск изменений и проверка. Возьмите в работу 2–3 изменения с наибольшим эффектом: устранение неценных операций и перенос маршрута в схему или регламент. Назначьте ответственных и сроки. Через 2–3 недели после изменений повторите замер на тех же операциях и сравните время цикла и долю ценного времени. Представьте результат руководству на уровне 0–1, а исполнителям — на уровне операций.

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

Как реализовать этот план с помощью фрейма «Декомпозиция процесса» в OrgDevTools

Фрейм «Декомпозиция процесса» — бесплатный тренажёр OrgDevTools. В нём процесс раскладывается деревом до операций, а время узлов и доли потерь фрейм считает сам. Этот же фрейм подключён к Инструменту «Декомпозиция процессов на операции» в базе знаний по процессам и работает с данными его записи. Фрейм открывается пустым, дерево собирается с нуля.

Книги по теме: декомпозиция процессов на операции

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

• Diogo Cardoso, Pedro Sousa — «Generation of Stakeholder-Specific BPMN Models» (2020). Работа из серии Lecture Notes in Business Information Processing; из неё взята идея разных представлений одной декомпозиции для разных стейкхолдеров.

• Gerrit Muller — «Process Decomposition of Business» (год в материалах не указан). Деление бизнеса на четыре процесса, число их экземпляров и мысль о «почти пустых» шагах, которые не вредят.

• Blueprint — «Process Decomposition Job Aid and Template» (год в материалах не указан). Лестница уровней от уровня 0, значения на подпроцессах и задачах, тезис о том, что автоматизируют задачи, а не процессы.

• Paul Mulvey — «How to Use Process Decomposition Diagrams in Your Business Analysis Report» (статья по книге серии For Dummies, год в материалах не указан). Построение диаграммы декомпозиции и документирование каждого процесса на ней.