В начале 2025 года на полках книжных магазинов в России появилась книга Брюса Сильвера «Метод и стиль», которая широко известна западным аналитикам уже более десяти лет. Наша команда, естественно, приобрела эту книгу и детально ознакомилась с ней.
| ДО | ПОСЛЕ |
 |
 |
В этой статье мы предоставим свою обратную связь с разных точек зрения на подход и рекомендуемые правила именитого автора, чтобы задать несколько посылов:
- Не сотвори себе кумира - первый и самый важный. Критически относитесь к любой информации, которую вы изучаете. Не стоит относиться к материалам книги как к постулатам и исполнять их все безоговорочно. Даже автор в нескольких местах пишет, как с течением времени его мнение менялось, исходя из практического опыта, обратной связи на обучении и изменяющейся внешней и внутренней среды.
Брюс Сильвер говорит об этом следующее:
“However, following my Method to the letter is less important than establishing a prescriptive methodology of your own and deploying it consistently across your organization.” (“Однако следование моему Методу дословно менее важно, чем установление вашей собственной предписывающей методологии и её последовательное внедрение в вашей организации.”) - Выделить наиболее значимые аспекты, необходимые для глубокого понимания и практического применения.
- Обратить внимание на моменты, с которыми мы не согласны.
Наше мнение основывается также на практическом опыте и на изменениях, которые за эти 10 лет прошли в среде BPM и BPMS-систем.
Константин Донской
На мой взгляд, это одна из лучших, если не лучшая книга про BPMN на текущий момент. Она написана простым языком. В ней отражены достаточно интересные примеры. Она раскрывает символы не только с точки зрения графики, но и объясняет их семантику на уровне XML, постоянно подсвечивая читателю, что BPMN - это не просто картинки.
Я очень люблю производственную историю, и мне очень понравилось, как Брюс рассказывает про те моменты, когда комьюнити BPMN решала какие-то методологические задачи. Как она подходила к формату использования тех или иных элементов. Как она внедряла что-то новое с течением изменения самой нотации. Несмотря на то, что сама нотация достаточно молодая, путь был пройден тернистый и длинный, пока она стала тем эталоном и стандартом, который мы используем на текущий момент.
Радует, что объем книги небольшой и количество воды минимальное. За счет этого каждый практический совет и каждый приведённый пример смотрится гармонично и может быть использован вами ежедневно.
Но как мы отразили в начале статьи, не обошлось без некоторых спорных моментов, на которые я бы хотел обратить внимание.
Полностью поддерживаю автора
Effectively communicating the process logic requires understanding how the elements fit together, not just as isolated words but as sentences, paragraphs, a complete story.
Эффективное общение логики процесса требует понимания того, как элементы сочетаются друг с другом, не только как изолированные слова, но как предложения, абзацы, завершённая история.
Нельзя воспринимать элементы в BPMN как отдельные картинки. Мы должны чётко отдавать себе отчёт, что любое сочетание символов несет целостный смысл. И процесс — это не набор ад-хок операций и задач, а связанная логика. Не только на уровне одного процесса, но и на уровне кросс-процессного взаимодействия.
While inline expansion is useful in simple diagrams, in most cases I prefer the hierarchical style. One reason is it allows the top level of a complex process to be represented end-to-end on a single page.
Хотя встроенное развёртывание полезно в простых диаграммах, в большинстве случаев я предпочитаю иерархический стиль. Одна из причин заключается в том, что он позволяет представить верхний уровень сложного процесса на одной странице.
На своих обучениях мы часто приводим примеры альтернативного описания сквозного или кросс-функционального процесса (верхнего уровня процесса) и как это можно сделать с помощью BPMN, не прибегая к дополнительным нотациям (VAD, IDEF). И в этом подходе Брюс Сильвер нас поддерживает, единственное различие - это символы, с помощью которых мы это демонстрируем. Со своей стороны, я рекомендую Call Activity, а Брюс подпроцесс, но этот момент раскрою чуть ниже.
Actually, the Customer is external to the process, not part of it.
Фактически, клиент является внешним по отношению к процессу, а не его частью.
Клиент - это чёрный ящик для процесса организации и делать его внутренним участником в процессе некорректно. Не забывайте об этом.
A task represents an action, not a function or state. It should be labeled VERB-NOUN.
"Что сделать?" - то, что нужно спросить, перед тем, как формулировать задачу / операцию при моделировании.
| Правильно | Неправильно |
| Оформить договор | Оформление договора |
The Widget Order process is different from the Maintenance Order process, but they share a common Billing subprocess. If you use a regular subprocess, you would need to replicate the Billing definition inside both Widget Order and Maintenance Order, and maintain that synchronization whenever Billing changed. A better way is to make Billing an independent top-level process defined in a separate file, and invoke it from call activities in Widget Order and Maintenance Order. The call activity points to a process element in the called model, in this case Billing. With subprocess, the calling and called processes are defined in the same model; with call activity they are independent.
Процесс заказа виджетов отличается от процесса заказа на обслуживание, но они оба используют общий подпроцесс выставления счетов. Если использовать обычный подпроцесс, вам придется дублировать определение выставления счетов в обоих процессах и поддерживать их синхронизацию при каждом изменении. Лучший способ — сделать выставление счетов независимым верхнеуровневым процессом, определённым в отдельном файле, и вызывать его с помощью call activity в процессах заказа виджетов и заказа на обслуживание. Call activity ссылается на элемент процесса в вызываемой модели, в данном случае — на процесс выставления счетов. В случае подпроцесса вызывающий и вызываемый процессы определены в одной модели; при использовании call activity они являются независимыми.
Если часть операций или весь процесс переиспользуется, выносите его в отдельный процесс и вызывайте с помощью CallActivity.
По своему опыту, вот уже три года перестал использовать подпроцессы, а использую только Call Activity, причин несколько:
- Отсутствие возможности построить реальную кросс-функциональную взаимосвязь, подпроцесс её показывает только графически.
- Отсутствие возможности использования типизированных событий.
- Не нашёл редактора, который бы мог нормально работать с развёртыванием / свёртыванием подпроцессов - всё время после данной операции, нужно что-то править.
После прочтения книги сложилось впечатление, что Брюс Сильвер, стал заложником отсутствия нормальной функциональности в используемых продуктах и для этого в своём "Стиле" сделал дополнительные правила и рекомендации.
Наш stormbpmn.com лишен этих недостатков и позволяет формировать полноценную кросс-функциональную взаимосвязь с последующей возможностью формирования графов, что релевантно верхнеуровневой модели бизнес-процессов.
The important thing is that there is agreement on the scope before modeling begins. You don’t want your modeling efforts, after weeks of interviewing subject matter experts and other stakeholders, to break down in a dispute over when the process is actually complete. That is often a difficult question to answer, but you want to have those discussions before diving into the process details.
Важно, чтобы перед началом моделирования было достигнуто согласие по охвату. Вы не хотите, чтобы ваши усилия по моделированию, после недель интервьюирования экспертов предметной области и других заинтересованных сторон, развалились из-за спора о том, когда процесс фактически завершается. Это часто сложный вопрос, но лучше обсудить его до того, как углубляться в детали процесса.
На своих курсах и тренингах, я всегда не просто рекомендую, а призываю начинать моделирование следующим образом:
- Отобразили стартовое и завершающее событие.
- Описали их завершенное действие.
- Определили перечень ресурсов и продуктов, которые с ними связаны.
- Определили и описали в аннотации ценность, заложенную в продуктах.
- Если определены все события по результатам анализа, приступаем к моделированию операций / задач. Если не все - возвращаемся к шагу 1 и думаем дальше.
So the question becomes, what does the pool label represent?...I believe the only way this works is if the pool label also names the process.
Так возникает вопрос: что обозначает метка пула? Я считаю, что единственный способ, при котором это работает, — если метка пула также называет процесс.
Название пула = названию процесса, а не подразделению или организации. Полностью и безоговорочно поддерживаю автора.
ВАЖНО!
Это встречается в нескольких главах книги, поэтому отдельную цитату выделять не стал, но основной смысл следующий: всё, что возможно подписать: активити, шлюзы, потоки и события - должны быть подписаны, т.к. это важная часть контекста процесса, для его лучшего и однозначного понимания.
Есть над чем задуматься
One organization, called APQC, publishes a cross-industry Process Classification Framework, a hierarchy consisting of Categories, Process Groups, Processes, and Activities. Unfortunately, very few of the processes and activities listed in the PCF match BPMN’s notion of process and activity.
Одна организация, называемая APQC, публикует межотраслевой Фреймворк классификации процессов, представляющий собой иерархию, состоящую из категорий, групп процессов, процессов и действий. К сожалению, очень немногие из процессов и действий, перечисленных в PCF, соответствуют представлению BPMN о процессе и действии.
На примере PCF Брюс показывает, как популярные модели, декларируя правильный и ограниченный подход с точки зрения структуры (4 уровня иерархии), почему-то в своих моделях уходят от этого и называют процессами, то что ими не является.
A BPMN activity is a discrete action with a well-defined start and end. Once an instance of the activity has ended, it’s over, complete. It’s not just lying dormant, ready to suddenly reawaken and do a bit more if it discovers something wrong. It is possible for the process to do those things… but in a different activity, or possibly another instance of the same activity. In the broader realm of BPM architecture, the term “activity” is used more broadly, and this causes some confusion regarding BPMN. Some “activities” described by BPM architecture do not fit BPMN’s definition because they are really functions performed continuously, not discrete actions performed repeatedly. They often have names like Manage X or Monitor Y, and don’t operate on instances with a well-defined start and end.
Деятельность в BPMN — это дискретное действие с чётко определенным началом и завершением. Как только экземпляр деятельности завершился, он считается полностью выполненным. Он не находится в состоянии ожидания, готовый неожиданно возобновить работу при обнаружении ошибки. Процесс может выполнять такие действия, но в рамках другой деятельности или, возможно, в другом экземпляре той же деятельности. В более широком контексте BPM архитектуры термин «деятельность» используется в более общем смысле, что вызывает некоторую путаницу в отношении BPMN. Некоторые «деятельности», описанные в BPM архитектуре, не соответствуют определению BPMN, так как они являются функциями, выполняемыми непрерывно, а не дискретными действиями, выполняемыми повторно. Они часто имеют названия, такие как Управление X или Мониторинг Y, и не работают с экземплярами, имеющими четко определенное начало и конец.
Проблема восприятия действия, с точки зрения неоднозначности термина, обсуждается достаточно давно. Как поступать в данной ситуации на текущий момент решается только соглашением о моделировании каждой отдельной компании, чтобы хотя бы на локальном уровне синхронизировать понимание и исключить споры.
Но помнить о данной особенности основного элемента нотации просто необходимо.
A subprocess is simultaneously an activity, a step in a process that performs work, and a process, a flow of activities from a start event to one or more end events.
Подпроцесс одновременно является и активностью, шагом в процессе, выполняющим работу, и процессом, потоком активностей от начального события до одного или нескольких конечных событий.
Это ещё одна особенность подпроцесса, которая создает неоднозначность понимания элемента и, например, меня останавливает в практическом его использовании.
A Manual task, with the hand icon, should only be used in an executable process, that is, an automated workflow. In that context, a Manual task is one performed without any connection to the workflow engine, as contrasted with a User task, which is managed by the engine. If your process model is not executable, it should not include Manual tasks. For non-executable processes, just use a User task for any human task.
Ручная задача с иконкой руки должна использоваться только в исполняемом процессе, то есть в автоматизированном рабочем процессе. В этом контексте ручная задача выполняется без какого-либо подключения к движку рабочего процесса, в отличие от пользовательской задачи, которая управляется движком. Если ваша модель процесса не исполняема, в ней не должны присутствовать ручные задачи. Для неисполняемых процессов используйте пользовательскую задачу для любых действий, выполняемых человеком.
Ручная задача - в моей практике часто используемый элемент и не только в процессах с автоматизированными движками, т.к. он очень наглядно демонстрирует действия вне системы или оборудования. Я не считаю это грубым нарушением нотации и в своем кругу рекомендую именно такой подход.
Но вы можете выбрать любой вам близкий, главное закрепить его в соглашении о моделировании.
If a subprocess is followed by a gateway labeled as a question, the subprocess should have multiple end events, and one of them should match the gateway label.
Если подпроцесс следует за шлюзом, обозначенным как вопрос, подпроцесс должен иметь несколько завершающих событий, и одно из них должно соответствовать метке шлюза.
Очень спорная рекомендация, наверное, в каких-то случаях так и должно быть, но чтобы всегда - не согласен.
Категорически не допускаю в своей практике
But I recommend a different way: depicting the child-level expansion in a separate diagram. I call it hierarchical expansion, because it expresses the end-to-end process as a hierarchy of diagrams.
Но я рекомендую другой способ: изображение развёртывания нижнего уровня на отдельной диаграмме. Я называю это иерархическим развертыванием, потому что оно выражает сквозной процесс в виде иерархии диаграмм.
Если нам всё равно необходимо разворачивать процесс на сторонней диаграмме, зачем использовать для этого подпроцесс. При такой логике лучше использовать Call Activity, тем самым заранее формируя потенциально повторно используемые объекты, а главное создавая полноценную кросс-функциональную взаимосвязь.
But here’s the problem: Just a tiny fraction of the information defined by the semantic model is visible in the diagram: the basic element type, indicated by its shape and associated icons and markers, and a text label. If we are viewing a multi-page diagram within a BPMN tool, hyperlinks can indicate certain relationships between the pages, and property sheets can display various attributes of a selected shape. But we cannot assume that the diagram is always accessed through the tool. In most cases users view the BPMN diagram as a hard copy or pdf, in which the hyperlinks and property sheets do not appear.
Но вот в чём проблема: только крошечная часть информации, определённой семантической моделью, отображается в диаграмме: основной тип элемента, указанный его формой и соответствующими значками и маркерами, а также текстовая метка. Если мы рассматриваем многостраничную диаграмму в инструменте BPMN, гиперссылки могут указывать на определенные отношения между страницами, а таблицы свойств могут отображать различные атрибуты выбранной формы. Но нельзя предполагать, что диаграмма всегда просматривается через инструмент. В большинстве случаев пользователи рассматривают диаграмму BPMN в виде бумажной копии или PDF, где гиперссылки и таблицы свойств не отображаются.
Времена изменились, в настоящее время анализ производится на ПК, ноутбуках, планшетах и телефонах, и системы нацелены на совместный анализ и использования, поэтому, несмотря на то что гармонизация схем - посыл правильный, ориентация на бумажные носители, на мой взгляд, избыточна.
In order to maximize diagram clarity, a Message start event should be labeled Receive X, where X is the name of the message.
Чтобы максимально повысить ясность диаграммы, событие начала сообщения должно быть помечено как "Принять X", где X — название сообщения.Multiple end states do not always imply exceptions. They could just signify some aspect of the instance that affects the subsequent flow. For example (Figure 5-1), you might have an activity Determine customer type that identifies a buyer as either a premier customer or a regular customer, followed by a gateway labeled Premier customer? with yes and no gates leading to separate fulfillment activities. If Determine customer type is a subprocess, it should have two end events, one of which is labeled Premier customer. Any process instance reaching the Premier customer end state will, by this convention, always follow the yes path out of the gateway, and any instance reaching the other end state will follow the no path.
Множественные конечные состояния не всегда означают исключения. Они могут просто указывать на аспект экземпляра, который влияет на последующий поток. Например (Рисунок 5-1), у вас может быть активность "Определить тип клиента", которая идентифицирует покупателя как премиального или обычного клиента, после чего следует шлюз с надписью "Премиальный клиент?" с выходами "да" и "нет", ведущими к различным действиям по выполнению. Если "Определить тип клиента" является подпроцессом, он должен иметь два конечных события, одно из которых помечено как "Премиальный клиент". Любой экземпляр процесса, достигший конечного состояния "Премиальный клиент", по этому соглашению всегда следует по пути "да" из шлюза, а любой другой экземпляр - по пути "нет".
Формулировку событий как объекта (Что? Кто?) или глагола + существительное (Что сделать?) считаю неприемлемой практикой, ведущей к искажению самого понятия событие. Для меня событие - это триггер, то есть завершенное действие, мотивирующее стартовать или двигать ход процесса дальше.
Вопросы для формулировки события - Что сделано? Что произошло? - Договор подписан. Клиент оплатил заказ. Температура достигла 30 градусов.
Заключение
Безумно интересная книга, основанная на многолетних методологических и практических трудах. Её обязан прочитать каждый уважающий себя аналитик.
Даже с учётом спорных моментов, большая часть книги - это лучшие практики BPMN.
Владимир Шишкин
Считаю эту книгу полезной для тех, кто хочет освоить нотацию BPMN. В книге простым и понятным языком даны определения элементов нотации, способы и правила их применения. Многие из них проиллюстрированы не только практическими примерами, но и описанием типичных ошибок — то, как не надо применять тот или иной элемент BPMN.
Ещё более ценна она для тех, кто желает не просто рисовать, а моделировать бизнес-процессы в виде диаграмм, лаконичных и лёгких для понимания широким кругом пользователей.
Книга логично структурирована: каждая новая информация опирается на материалы предыдущих разделов. Начинается она с определения и назначения BPMN, для чего он был рождён. Это сразу задаёт читателю продуктивный фокус внимания. Затем переходит к азам нотации: стартовое и завершающее событие, задачи, развилки, потоки (стрелочки). Далее углубляется в их типы с подробным объяснением, чем один тип задачи или события отличается от другого. Разбираются типы шлюзов, их работа и правильное применение. В паттернах моделирования описаны типовые структуры процессов и разобраны сценарии их применения на практике. После этого автор рассказывает и показывает, как сделать диаграмму понятной не только для аналитиков, но и для бизнеса.
Сильные стороны книги:
- Практический подход. Автор делает акцент на практическом применении BPMN, что ценно для тех, кто использует его в реальных проектах. Каждая концепция подкрепляется примерами из реальной жизни, что помогает усвоить материал.
- Глубина анализа. Брюс Сильвер описывает тонкости BPMN, рассматривая сложные случаи использования, такие как обработка исключений, управление ресурсами и параллельные процессы. Это делает книгу полезной как для новичков, так и для опытных специалистов.
- Структура книги и оригинальный стиль подачи знаний. У Брюса своеобразный стиль повествования — беседы. Он задаёт вопросы читателю, провоцируя задумываться над ними и побуждая к критическому мышлению и анализу. Это способствует лучшему пониманию темы и делает процесс обучения увлекательным.
- Внимание к стилю моделирования. Сильвер объясняет, что для командной работы важно сформировать единый стиль создания моделей. Стиль, с помощью которого создаваемые модели будут не только формально корректны, но и легко восприниматься командой и всеми участниками процесса. Автор приводит прекрасный пример стиля моделирования — лаконичный и понятный многим.
Слабые стороны книги:
- Ненулевой порог входа. Для тех, кто слышал только слово BPMN, книга может показаться сложной из-за специфичной терминологии и большого объёма деталей.
- Не для поверхностного чтения. Это не бизнес-роман об успешном успехе. Книга требует внимательного изучения и повторения материала. Каждый раздел нужно прорабатывать тщательно — нарисовать модель, погонять симуляцию токена, подумать над ней.
- Ограниченная актуальность. С момента выхода оригинала книги минул не один год, а BPMN продолжает развиваться — некоторые части книги могут быть несколько устаревшими. В частности, возможности моделирования процессов и их архитектуры. Однако основные принципы и подходы остаются актуальными.
- Стиль моделирования процессов, изложенный в книге, прекрасный, но не истина в последней инстанции. Для многих он подойдёт идеально, а у других может вызвать разночтения. Критерием формирования стиля моделирования вашей команды является лишь одно — понятность стиля для всех читателей диаграмм: бизнеса, аналитиков, участников процессов, команд автоматизации и т. д.
Заключение:
Книга пронизана идеей о том, что BPMN — это не просто нотация, а практичный инструмент коммуникации. Она помогает обеспечить понятное представление бизнес-процесса, обеспечивая конструктивное взаимодействие между его участниками. В итоге это приводит к чёткому выполнению процессов и достижению результата, приносящего выгоду всем: бизнесу, компании и каждому работнику.
Денис Котов
Сразу заключение
Вышла долгожданная книга «BPMN: Метод и стиль» Брюса Сильвера в русском переводе – настоящее руководство по нотации BPMN и её практическому применению, созданное самим участником разработки стандарта. Автор не только детально раскрывает ключевые аспекты моделирования процессов, такие как применение событий, переходы от 1-к-N, множественное выполнение процессов и уровни моделирования, но и акцентирует внимание на иерархичности через SubProcess и Call Activity, что особенно ценно для сквозных процессов.
Брюс Сильвер написал отличную книгу, в которой систематизировано и доступно изложено большое количество информации по BPMN. Во время чтения становится очевидной важная мысль: BPMN невозможно воспринимать без качественных инструментов для его создания, поскольку каждый из них (например, Visio или Camunda Modeler) имеет свои недостатки. Таким образом, подход к моделированию отчасти формируется с целью устранения неудобства конкретных инструментов. О своем подходе мы написали в соглашении о моделировании (Ссылка) и в статье о выборе инструмента (Ссылка).
