Когда хочешь быстро объяснить суть какого-то процесса, то обычно рисуешь на листке бумаги несколько прямоугольников с текстом и проводишь между ними связи. Этому нехитрому принципу следуют большинство методологий описания бизнес-процессов, технологических процессов и любой другой человеческой деятельности. Можно принять как данность, что подобные схемы очень важны в современной парадигме накопления знаний.
Поэтому несколько лет назад я разработал приложение, которое позволяет строить диаграммы процессов, чтобы планировать исполнение проектов или просто достигать каких-либо целей. Всё это время я тесно работал с пользователями, довольно часто и по разному поводу они присылали мне свои диаграммы. Изучая сотни различных схем, я замечал, что некоторые из них проще воспринимать и понимать, чем другие, и наоборот, отдельные схемы было чертовски сложно разобрать. Интересно то, что зачастую дело было не в сложности или простоте самого процесса, а в манере построения диаграммы. Проявив толику усердия, даже самый простой процесс можно проиллюстрировать путанной схемой, суть которой будет сложно понять без дополнительного изучения.
Анализируя свой опыт по построению диаграмм и систематизируя удачные находки и ошибки пользователей, я выработал набор принципов, которые позволяют строить хорошие диаграммы.
Пару слов о структуре статьи. Материал довольно обширный, поэтому я попробую разбить его на несколько частей и постараюсь излагать материал тезисно, избегая лишних разъяснений. Эта статья будет посвящена довольно общим принципам, вполне очевидным, но которые следует упомянуть. Последующие части будут ближе к конкретным практикам.
Итак, сначала договоримся об основном предмете статьи — диаграммах процессов (далее для лаконичности иногда просто диаграммы). Как правило, диаграмма процессов представляет собою набор графических объектов, поименованных текстом, которые связаны между собою стрелками. Объекты обозначают процессы, ресурсы, состояния и т. д. Стрелки же обозначают порядок перехода управления от одного объекта к другому. Следует отличать диаграммы процессов от внешне очень похожих структурных диаграмм, диаграммы процессов предполагают динамику, в то время когда структурные диаграммы носят статичный характер, описывая конструктивные взаимосвязи объектов, обычно это описание организационных иерархий, структур данных или “карты разума”.
Существует много нотаций описания диаграмм процессов, это IDEF0, BPMN, UML, EPC, CMMN и другие. Данная статья в равной степени относится к ним всем, в примерах использована нотация собственного приложения.
В статье словом “процесс” в зависимости от контекста может обозначаться как основной процесс, описываемый диаграммой, так и процессы, входящие в состав диаграммы. Слово “задача” может означать процесс, цель или ресурс, либо цельное сочетание ресурса, процесса и цели. В общем, смотрите по контексту.
Так как именно динамика является основной отличительной чертой рассматриваемых нами диаграмм, то, следовательно, ключевой частью такой диаграммы является её сценарий. Основные требования к сценарию — это непротиворечивость и непрерывность. Противоречия возникают при неверном порядке причин и следствий, а также в ситуации, когда один объект должен быть одновременно в разных местах (или два совмещаться в одном и том же месте). Непрерывность теряется, когда следствия не обусловлены причинами либо когда утерян существенный фрагмент повествования.
Вот здесь нужно осветить один важный момент касательно сценария и диаграммы в целом. Цель создания диаграммы не только в описании конкретного процесса, но и в передаче этого знания адресату. То есть на сюжет диаграммы влияет как описываемый ею процесс, так и её аудитория. К примеру, если вам нужно разъяснить пункт ПДД детям, вы воспользуетесь иной методикой изложения, нежели та, что использована в официально установленных правилах. Как правило, если сюжет не адаптирован к аудитории, то теряется его непрерывность, поскольку отдельные причинно-следственные связи неочевидны или непонятны адресатам.
Можно упомянуть много различных методов отладки диаграмм с целью устранения противоречий и соблюдения непрерывности. Но эффективнее будет сразу строить качественные диаграммы, и так как статья носит больше практический характер, то вместо описания методов анализа качества я просто приведу пошаговый алгоритм построения хороших диаграмм.
Шаг 1. Разместите свои цели как ресурсы в правом нижнем углу диаграммы.
Обычно процессы, которые имеет смысл описывать, имеют чётко выраженную конечную цель или группу целей. Такой целью может также служить состояние, после которого дальнейшее исполнение процесса не имеет смысла. Как правило, процессы создаются под конкретные цели, и зачастую очевидно, что написать в правом нижнем углу диаграммы. Однако иногда бывает дальновидным указать не только положительную цель, но перечислить состояния, в которых исполнение процесса прерывается, но исходная цель не достигнута или достигнута не полностью. Рекомендуется явно перечислять подобные негативные цели в случаях, если вероятность достижения основной цели ниже 60%.
Забегая вперёд, скажу, что рекомендация по размещению конечной цели справа внизу диаграммы (как и последующие подобные рекомендации) относится к композиции диаграммы, которая будет предметом рассмотрения другой статьи.
Шаг 2. Отметьте доступные ресурсы в виде объектов в верхней части диаграммы.
Очевидно, что перечислять следует не все возможные ресурсы, а только те, которые видятся полезными для достижения цели и ликвидность которых не вызывает сомнений. Перечень этих ресурсов будет являться исходными условиями начала процесса. Одним из таких ресурсов должен быть триггер, запускающий весь процесс, обычно это внешнее воздействие: заявка клиента, смена состояния индикатора, запрос от системы и т. д.
Шаг 3. Разместите предполагаемые промежуточные цели как ресурсы в средней части диаграммы.
Комплексные цели обычно состоят из набора компонентов, которые необходимо реализовать предварительно. Большие проекты удобно разбивать на этапы, результатом исполнения которых является получение одного из компонентов конечной цели. Мысленно расчлените конечную цель на такие компоненты и поместите их на диаграмму. В некоторых случаях вместо компонентов можно разбить конечный продукт на последовательность эволюций зрелости продукта или совмещать оба подхода.
Шаг 4. Перед целями, имеющимися на диаграмме, разместите процессы, которые приводят к достижению данных целей, и соедините новые процессы с их целями.
Заметьте, что пока на нашей диаграмме процессов не было ни одного процесса, это неслучайно. Специфика нашего мышления такова, что, начиная что-то делать, мы больше концентрируемся на процессах, немного забывая, что суть нашей деятельности в целях. Диаграммы процессов, состоящие из одних только процессов, — частое явление, однако следует помнить, что мы стремимся к непрерывности и ясности изложения, а зачастую указание целей исполнения процесса говорит о нём больше, нежели название процесса и его описание. Старайтесь всегда явно указывать цели процесса, на практике это означает, что стрелка от одного процесса к другому — это редкое явление, обычно между процессами располагается промежуточный ресурс, являющийся результатом исполнения одного процесса и исходным ресурсом для другого. В некоторых формализмах (например DFD) сама стрелка может являться описанием ресурса. Однако если такой промежуточный ресурс очевиден, то ради упрощения схемы его можно опустить и провести стрелку от одного процесса к другому. Например, если в прачечной после процесса “Сушка” следует процесс “Глаженье”, то в некоторых случаях промежуточный ресурс “Сухое бельё” можно пропустить.
Шаг 5. Проведите связи от имеющихся на диаграмме ресурсов к использующим их процессам; если необходимого для процесса ресурса нет на диаграмме, добавьте новую цель, вернувшись к Шагу 3 ↑.
Очевидно, что если требуемого процессом ресурса нет, то это приводит к противоречию в исполнении задачи, так как соблюдены не все причины для желаемых следствий. Следовательно, необходимо исполнить критерий полноты — всё необходимое для исполнения каждого процесса должно быть в наличии. Впрочем, не всегда оправдано явно указывать очевидные ресурсы, например, при обработке детали станком одним из очевидных ресурсов является электроэнергия, явное выделение этого ресурса, скорее всего, не сделает диаграмму понятнее, однако без значимых причин усложнит её. Помните о своей аудитории: часть диаграммы зритель всегда достраивает мысленно, это неизбежно. Старайтесь, чтобы мнимая часть диаграммы касалась очевидных всем моментов, более того, слишком явные вещи, выписанные на диаграмме, могут утомлять и даже раздражать.
Шаг 6. Проведите связи между процессами, исполнение которых зависит друг от друга.
Попарно проверьте все процессы, размещённые на диаграмме, нет ли между ними неявных зависимостей или взаимного влияния. Например, часто полезно “грязные” процессы группировать вместе, чтобы экономить на очистке рабочей области. Также если два процесса конкурентно используют ограниченный ресурс, то их следует развести во времени, проложив связь от одного из них к другому. Заметьте, что ресурсы, которые мы не отображаем на диаграмме, тоже могут быть причиной скрытых зависимостей, к примеру, когда два процесса используют энергоёмкие станки, которые не следует включать одновременно.
Шаг 7. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу.
Практика показывает, что когда диаграмма содержит более 20 объектов (ресурсов или процессов), то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути. С другой стороны, редко какой проект или бизнес-процесс уложится в такое небольшое число объектов. К счастью, то, что не вместит одна диаграмма, поместится на нескольких, не стремитесь всё изложить сразу, помните: всегда можно сделать ещё одну диаграмму.
Итак, если схема получилась громоздкой, выделите группу объектов, по возможности слабо связанных с другой частью диаграммы, и замените их одним процессом. Удалённые объекты станут основой новой диаграммы, которая будет пояснять суть нового процесса.
Такая, казалось бы, чисто техническая задача на самом деле имеет большое значение, так как подобным образом выстраивается иерархия детализации задач и разделение контекстов исполнения процессов. Теперь с точки зрения основной диаграммы не важно, как реализован новый процесс, подробности его реализации вынесены в отдельную диаграмму, они существуют как бы в отдельном пространстве, на которое основная схема имеет ограниченное влияние. Это довольно полезное свойство: чем более независимы соседние задачи, тем меньше вероятность, что ошибки и проблемы одной из них будут влиять на другие.
Другим важным аспектом детализации диаграмм является возможность развести аудитории: как правило, диаграммы верхнего уровня интересны менеджерам, а вложенные диаграммы больше полезны техническим специалистам. Разбив диаграмму на уровни, мы можем каждую новую диаграмму проектировать с учётом её аудитории, формируя сюжет, понятный и увлекательный именно для неё.
Шаг 8. Убедитесь, что объекты имеют тип, соответствующий их сути, визуально разделите информационные и физические потоки. Если диаграмма содержит несколько контекстно связанных объектов, выделите их с помощью группы. В местах, требующих пояснений, разместите объекты типа комментарий.
В зависимости от выбранной нотации описания процессов нам будут доступны различные типы графических объектов, описывающих специфические аспекты задач, внимательно изучите перечень доступных объектов и используйте наиболее подходящее описание для каждой из задач. Иногда нотация позволяет отдельно выделить область на диаграмме, внутри которой можно расположить задачи, связанные каким-то общим признаком: исполнителем, местом исполнения и т. д.
Часто такие области оформляются как горизонтальные дорожки, после чего диаграмма выглядит, как бассейн, в котором каждый исполнитель плывёт по своей дорожке вдоль своих задач. Такая организация диаграммы довольно наглядна, но может иметь свои композиционные недостатки.
Шаг 9. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1.
На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой. На этом шаге делается то же самое, но аналитически: мы пытаемся сложный объект разложить на более простые процессы и отобразить их во вложенной диаграмме. В управлении проектами этот процесс называют структурной декомпозицией работ. Разбивая задачи на более мелкие или объединяя их в более крупные, следует следить, чтобы задачи одного уровня, отображаемые в одной диаграмме, были приблизительно равны по значимости и трудоёмкости.
Шаг 10. Для отдельных ресурсов там, где это необходимо, добавьте вложенную диаграмму подготовки ресурса к использованию. Для избранных целей добавьте диаграмму по проверке требуемых качеств достигнутой цели.
Продолжаем работу по декомпозиции, но акцентируем внимание на ресурсах и целях.
Успешно завершив все десять шагов, мы должны получить набор процессных диаграмм, иллюстрирующих непротиворечивый и непрерывный сценарий по достижению запланированных целей. Однако эти диаграммы ещё не являются готовым продуктом, для каждой из них нужно найти подходящее композиционное решение и оформить их, соблюдая ряд визуальных формальностей и нюансов. Тому, как превратить нашу сырую руду в звонкий металл, будут посвящены следующие статьи, пока же подведём итог этой.
Итак, описание любого процесса начинается с составления сценария, который связывает объективную структуру процесса с аудиторией, для которой предназначено описание. В случае если адресатом является человек, удобно пользоваться компактными диаграммами процессов, организованными в иерархическую структуру, основанную на архитектуре процесса. Заметьте, что внедрённая в описание процесса иерархия может не быть частью самого процесса, она больше нужна для целей эффективного восприятия аудиторией — иногда, чтобы что-то сделать проще, сначала это нужно усложнить.
UPD
Следующая статья: «Техническая композиция диаграмм процессов»
В комментариях мне справедливо указали, что следует различать моделирование процессов и функциональное моделирование, это действительно так, однако большинство рекомендаций статьи одинаково применимо для диаграмм обоих типов. Тем не менее, это ценное замечание, подчёркивающее, насколько важно кроме статьи читать и комментарии.
Поэтому несколько лет назад я разработал приложение, которое позволяет строить диаграммы процессов, чтобы планировать исполнение проектов или просто достигать каких-либо целей. Всё это время я тесно работал с пользователями, довольно часто и по разному поводу они присылали мне свои диаграммы. Изучая сотни различных схем, я замечал, что некоторые из них проще воспринимать и понимать, чем другие, и наоборот, отдельные схемы было чертовски сложно разобрать. Интересно то, что зачастую дело было не в сложности или простоте самого процесса, а в манере построения диаграммы. Проявив толику усердия, даже самый простой процесс можно проиллюстрировать путанной схемой, суть которой будет сложно понять без дополнительного изучения.
Анализируя свой опыт по построению диаграмм и систематизируя удачные находки и ошибки пользователей, я выработал набор принципов, которые позволяют строить хорошие диаграммы.
Пару слов о структуре статьи. Материал довольно обширный, поэтому я попробую разбить его на несколько частей и постараюсь излагать материал тезисно, избегая лишних разъяснений. Эта статья будет посвящена довольно общим принципам, вполне очевидным, но которые следует упомянуть. Последующие части будут ближе к конкретным практикам.
Итак, сначала договоримся об основном предмете статьи — диаграммах процессов (далее для лаконичности иногда просто диаграммы). Как правило, диаграмма процессов представляет собою набор графических объектов, поименованных текстом, которые связаны между собою стрелками. Объекты обозначают процессы, ресурсы, состояния и т. д. Стрелки же обозначают порядок перехода управления от одного объекта к другому. Следует отличать диаграммы процессов от внешне очень похожих структурных диаграмм, диаграммы процессов предполагают динамику, в то время когда структурные диаграммы носят статичный характер, описывая конструктивные взаимосвязи объектов, обычно это описание организационных иерархий, структур данных или “карты разума”.
Существует много нотаций описания диаграмм процессов, это IDEF0, BPMN, UML, EPC, CMMN и другие. Данная статья в равной степени относится к ним всем, в примерах использована нотация собственного приложения.
В статье словом “процесс” в зависимости от контекста может обозначаться как основной процесс, описываемый диаграммой, так и процессы, входящие в состав диаграммы. Слово “задача” может означать процесс, цель или ресурс, либо цельное сочетание ресурса, процесса и цели. В общем, смотрите по контексту.
Так как именно динамика является основной отличительной чертой рассматриваемых нами диаграмм, то, следовательно, ключевой частью такой диаграммы является её сценарий. Основные требования к сценарию — это непротиворечивость и непрерывность. Противоречия возникают при неверном порядке причин и следствий, а также в ситуации, когда один объект должен быть одновременно в разных местах (или два совмещаться в одном и том же месте). Непрерывность теряется, когда следствия не обусловлены причинами либо когда утерян существенный фрагмент повествования.
Вот здесь нужно осветить один важный момент касательно сценария и диаграммы в целом. Цель создания диаграммы не только в описании конкретного процесса, но и в передаче этого знания адресату. То есть на сюжет диаграммы влияет как описываемый ею процесс, так и её аудитория. К примеру, если вам нужно разъяснить пункт ПДД детям, вы воспользуетесь иной методикой изложения, нежели та, что использована в официально установленных правилах. Как правило, если сюжет не адаптирован к аудитории, то теряется его непрерывность, поскольку отдельные причинно-следственные связи неочевидны или непонятны адресатам.
Можно упомянуть много различных методов отладки диаграмм с целью устранения противоречий и соблюдения непрерывности. Но эффективнее будет сразу строить качественные диаграммы, и так как статья носит больше практический характер, то вместо описания методов анализа качества я просто приведу пошаговый алгоритм построения хороших диаграмм.
Шаг 1. Разместите свои цели как ресурсы в правом нижнем углу диаграммы.
Обычно процессы, которые имеет смысл описывать, имеют чётко выраженную конечную цель или группу целей. Такой целью может также служить состояние, после которого дальнейшее исполнение процесса не имеет смысла. Как правило, процессы создаются под конкретные цели, и зачастую очевидно, что написать в правом нижнем углу диаграммы. Однако иногда бывает дальновидным указать не только положительную цель, но перечислить состояния, в которых исполнение процесса прерывается, но исходная цель не достигнута или достигнута не полностью. Рекомендуется явно перечислять подобные негативные цели в случаях, если вероятность достижения основной цели ниже 60%.
Забегая вперёд, скажу, что рекомендация по размещению конечной цели справа внизу диаграммы (как и последующие подобные рекомендации) относится к композиции диаграммы, которая будет предметом рассмотрения другой статьи.
Шаг 2. Отметьте доступные ресурсы в виде объектов в верхней части диаграммы.
Очевидно, что перечислять следует не все возможные ресурсы, а только те, которые видятся полезными для достижения цели и ликвидность которых не вызывает сомнений. Перечень этих ресурсов будет являться исходными условиями начала процесса. Одним из таких ресурсов должен быть триггер, запускающий весь процесс, обычно это внешнее воздействие: заявка клиента, смена состояния индикатора, запрос от системы и т. д.
Шаг 3. Разместите предполагаемые промежуточные цели как ресурсы в средней части диаграммы.
Комплексные цели обычно состоят из набора компонентов, которые необходимо реализовать предварительно. Большие проекты удобно разбивать на этапы, результатом исполнения которых является получение одного из компонентов конечной цели. Мысленно расчлените конечную цель на такие компоненты и поместите их на диаграмму. В некоторых случаях вместо компонентов можно разбить конечный продукт на последовательность эволюций зрелости продукта или совмещать оба подхода.
Шаг 4. Перед целями, имеющимися на диаграмме, разместите процессы, которые приводят к достижению данных целей, и соедините новые процессы с их целями.
Заметьте, что пока на нашей диаграмме процессов не было ни одного процесса, это неслучайно. Специфика нашего мышления такова, что, начиная что-то делать, мы больше концентрируемся на процессах, немного забывая, что суть нашей деятельности в целях. Диаграммы процессов, состоящие из одних только процессов, — частое явление, однако следует помнить, что мы стремимся к непрерывности и ясности изложения, а зачастую указание целей исполнения процесса говорит о нём больше, нежели название процесса и его описание. Старайтесь всегда явно указывать цели процесса, на практике это означает, что стрелка от одного процесса к другому — это редкое явление, обычно между процессами располагается промежуточный ресурс, являющийся результатом исполнения одного процесса и исходным ресурсом для другого. В некоторых формализмах (например DFD) сама стрелка может являться описанием ресурса. Однако если такой промежуточный ресурс очевиден, то ради упрощения схемы его можно опустить и провести стрелку от одного процесса к другому. Например, если в прачечной после процесса “Сушка” следует процесс “Глаженье”, то в некоторых случаях промежуточный ресурс “Сухое бельё” можно пропустить.
Шаг 5. Проведите связи от имеющихся на диаграмме ресурсов к использующим их процессам; если необходимого для процесса ресурса нет на диаграмме, добавьте новую цель, вернувшись к Шагу 3 ↑.
Очевидно, что если требуемого процессом ресурса нет, то это приводит к противоречию в исполнении задачи, так как соблюдены не все причины для желаемых следствий. Следовательно, необходимо исполнить критерий полноты — всё необходимое для исполнения каждого процесса должно быть в наличии. Впрочем, не всегда оправдано явно указывать очевидные ресурсы, например, при обработке детали станком одним из очевидных ресурсов является электроэнергия, явное выделение этого ресурса, скорее всего, не сделает диаграмму понятнее, однако без значимых причин усложнит её. Помните о своей аудитории: часть диаграммы зритель всегда достраивает мысленно, это неизбежно. Старайтесь, чтобы мнимая часть диаграммы касалась очевидных всем моментов, более того, слишком явные вещи, выписанные на диаграмме, могут утомлять и даже раздражать.
Шаг 6. Проведите связи между процессами, исполнение которых зависит друг от друга.
Попарно проверьте все процессы, размещённые на диаграмме, нет ли между ними неявных зависимостей или взаимного влияния. Например, часто полезно “грязные” процессы группировать вместе, чтобы экономить на очистке рабочей области. Также если два процесса конкурентно используют ограниченный ресурс, то их следует развести во времени, проложив связь от одного из них к другому. Заметьте, что ресурсы, которые мы не отображаем на диаграмме, тоже могут быть причиной скрытых зависимостей, к примеру, когда два процесса используют энергоёмкие станки, которые не следует включать одновременно.
Шаг 7. Убедитесь, что диаграмма легко читается и содержит не более 20 объектов; если это не так, сгруппируйте несколько контекстно связанных объектов в один объект подходящего типа с вложенной диаграммой, содержащей данную группу.
Практика показывает, что когда диаграмма содержит более 20 объектов (ресурсов или процессов), то схема перестаёт восприниматься цельно, а начинает выглядеть, как лабиринт, в котором зрителю нужно выискивать интересующие его пути. С другой стороны, редко какой проект или бизнес-процесс уложится в такое небольшое число объектов. К счастью, то, что не вместит одна диаграмма, поместится на нескольких, не стремитесь всё изложить сразу, помните: всегда можно сделать ещё одну диаграмму.
Итак, если схема получилась громоздкой, выделите группу объектов, по возможности слабо связанных с другой частью диаграммы, и замените их одним процессом. Удалённые объекты станут основой новой диаграммы, которая будет пояснять суть нового процесса.
Такая, казалось бы, чисто техническая задача на самом деле имеет большое значение, так как подобным образом выстраивается иерархия детализации задач и разделение контекстов исполнения процессов. Теперь с точки зрения основной диаграммы не важно, как реализован новый процесс, подробности его реализации вынесены в отдельную диаграмму, они существуют как бы в отдельном пространстве, на которое основная схема имеет ограниченное влияние. Это довольно полезное свойство: чем более независимы соседние задачи, тем меньше вероятность, что ошибки и проблемы одной из них будут влиять на другие.
Другим важным аспектом детализации диаграмм является возможность развести аудитории: как правило, диаграммы верхнего уровня интересны менеджерам, а вложенные диаграммы больше полезны техническим специалистам. Разбив диаграмму на уровни, мы можем каждую новую диаграмму проектировать с учётом её аудитории, формируя сюжет, понятный и увлекательный именно для неё.
Шаг 8. Убедитесь, что объекты имеют тип, соответствующий их сути, визуально разделите информационные и физические потоки. Если диаграмма содержит несколько контекстно связанных объектов, выделите их с помощью группы. В местах, требующих пояснений, разместите объекты типа комментарий.
В зависимости от выбранной нотации описания процессов нам будут доступны различные типы графических объектов, описывающих специфические аспекты задач, внимательно изучите перечень доступных объектов и используйте наиболее подходящее описание для каждой из задач. Иногда нотация позволяет отдельно выделить область на диаграмме, внутри которой можно расположить задачи, связанные каким-то общим признаком: исполнителем, местом исполнения и т. д.
Часто такие области оформляются как горизонтальные дорожки, после чего диаграмма выглядит, как бассейн, в котором каждый исполнитель плывёт по своей дорожке вдоль своих задач. Такая организация диаграммы довольно наглядна, но может иметь свои композиционные недостатки.
Шаг 9. Для процессов, не являющихся элементарными операциями, постройте вложенную диаграмму, начиная с Шага 1.
На Шаге 7 мы синтетически создавали новую задачу из группы объектов и детализировали её вложенной диаграммой. На этом шаге делается то же самое, но аналитически: мы пытаемся сложный объект разложить на более простые процессы и отобразить их во вложенной диаграмме. В управлении проектами этот процесс называют структурной декомпозицией работ. Разбивая задачи на более мелкие или объединяя их в более крупные, следует следить, чтобы задачи одного уровня, отображаемые в одной диаграмме, были приблизительно равны по значимости и трудоёмкости.
Шаг 10. Для отдельных ресурсов там, где это необходимо, добавьте вложенную диаграмму подготовки ресурса к использованию. Для избранных целей добавьте диаграмму по проверке требуемых качеств достигнутой цели.
Продолжаем работу по декомпозиции, но акцентируем внимание на ресурсах и целях.
Успешно завершив все десять шагов, мы должны получить набор процессных диаграмм, иллюстрирующих непротиворечивый и непрерывный сценарий по достижению запланированных целей. Однако эти диаграммы ещё не являются готовым продуктом, для каждой из них нужно найти подходящее композиционное решение и оформить их, соблюдая ряд визуальных формальностей и нюансов. Тому, как превратить нашу сырую руду в звонкий металл, будут посвящены следующие статьи, пока же подведём итог этой.
Итак, описание любого процесса начинается с составления сценария, который связывает объективную структуру процесса с аудиторией, для которой предназначено описание. В случае если адресатом является человек, удобно пользоваться компактными диаграммами процессов, организованными в иерархическую структуру, основанную на архитектуре процесса. Заметьте, что внедрённая в описание процесса иерархия может не быть частью самого процесса, она больше нужна для целей эффективного восприятия аудиторией — иногда, чтобы что-то сделать проще, сначала это нужно усложнить.
Ниже приложена диаграмма пошагового процесса, изложенного в статье, потратьте несколько минут на её изучение.
UPD
Следующая статья: «Техническая композиция диаграмм процессов»
В комментариях мне справедливо указали, что следует различать моделирование процессов и функциональное моделирование, это действительно так, однако большинство рекомендаций статьи одинаково применимо для диаграмм обоих типов. Тем не менее, это ценное замечание, подчёркивающее, насколько важно кроме статьи читать и комментарии.
