→ Первая часть тут
Следующим пунктом бизнес-анализа является описание бизнес процессов. На этом этапе, обычно, рисуют, так называемые диаграммы бизнес-процессов «As is». И вот тут-то всех и поджидают проблемы, что называется, на ровном месте. Самая большая проблема в том, что за деревьями не видно леса. Так же, как и при описании бизнес-целей, зачастую народ увлекается описанием того, как все работает прямо сейчас. При этом редко кто задается целью разобраться, а насколько текущие процессы вообще соответствуют тому, как все должно быть? Все наверняка знают одно из правил автоматизации: «автоматизируя бардак — мы получаем автоматизированный бардак, и ничего более». Так вот, чтобы не строить очередной «скайнет», который всех уничтожит, необходимо понять — «а как же все вообще должно функционировать?». И это очень интересная задача.
Конечно, далеко не все бизнес-аналитики в состоянии с ходу накидать бизнес-процессы, как все должно происходить в каждом конкретном случае. Но тут никаких тайн нет. Для решения этой задачи, надо просто позвать риск-аналитика, если он есть, ну или немного ознакомиться с профильной литературой и чуточку подумать. Это не сложно, честно.
Так вот, не будет далеко уходить от нашего прекрасного примера с почтой, и рассмотрим «простейший» процесс — «услуга доставки бандеролей». Для тех, кто знает кухню почты, сразу предупреждаю, что дальше описывается упрощенный пример в «рафинированном виде», то, каким его может увидеть бизнес-аналитик, или даже менеджер. Подробностей в стиле «привязки к существующей инфраструктуре» и прочих «исторически сложившихся условий» тут не будет. По сути, все эти детали рассматриваться уже на третьем этапе работ бизнес-аналитика, который в данной статье не рассматривается. Более того, на данном этапе нам вообще не нужны технические детали и даже скажу больше, от них надо всячески уходить, иначе мы просто затрудним себе задачу. Подробности и детали, как и описание процессов «As Is» — нужны, важны и используются именно в части анализа процессов и последующих предложений, рекомендаций и прочего
Итак, у нас есть цель – доставка ценностей от заказчика – получателю. У нас есть вариант достижения этой цели:
Как уже говорил, мы берем упрощенный процесс, чтобы показать, на что надо обращать внимание, и что нужно делать. Как видим, все достаточно просто и можно хоть сейчас чего-нибудь рисовать. Но, не будет торопиться. Как говориться «Обязательно бахнем, и не раз. Весь мир в труху. Но потом» (ц). Так вот, вернувшись в сей бренный мир из тумана грез, перед нами стоит задача, описать, как мы (компания) может обеспечить исполнение потребности (доставка бандероли), и не только ее обеспечить, но и гарантировать, что заинтересованные стороны (заказчик и получатель) будут удовлетворены. И последнее замечание, является важным, я бы сказал, определяющим. Да, я знаю, что будет много возражений в стиле «целью бизнеса является зарабатывание денег», «компаниям наплевать на клиентов» и множество других, вполне резонных. Но, повторяю еще раз, целью бизнеса – является удовлетворение потребности. А уж насколько прибыльно это занятие, это уже другой, коммерческий вопрос.
Продолжаем. Нам необходимо гарантировать удовлетворение потребности. Просто потребности, без учета затрат, объемов и прочего. Можно сказать, что если заинтересованные лица воспользовались этой услугой и остались довольны результатом, значит — мы успешно достигли цели. То есть, нам надо просто понять, а почему эти самые лица могут быть недовольными? Вариантов немного: ожидаемые события не случились, или случились не так, как ожидалось. В нашем конкретном случае имеем куст вариантов с уточняющими вопросами:
Итак, мы уже знаем о нашем процессе кое-что, но как все это сделать доступным и понятным для любого человека, без прочтения «… дцати» страниц текста? Ответ известен всем – надо просто нарисовать. И, как обычно, нас поджидает другой «сюрприз». Большинство используемых методологий графического отображения бизнес-процессов рекомендуют на диаграммах отображать именно технические детали (BPMN, UML, EPC и др.). В этом нет ничего плохого и на этапе анализа и подготовки рекомендаций диаграммы «As Is» и «To Be» именно такими и должны быть. Но когда мы описываем непосредственно сам процесс, его логику и правила, эти детали, как песок пустыни, покрывают любые сокровища. В результате, мало кто в состоянии сразу оценить корректность или ошибочность самих процессов или их понимание бизнес-аналитиком.
Вот мы плавно и подошли к вопросу изобретения очередного «велосипеда». Да, мы не будем мудрствовать лукаво, а просто применим «самопальную» нотацию для описания логики бизнес-процесса. Поскольку эта диаграмма рассчитана на неподготовленных пользователей (менеджеров, аналитиков, разработчиков) то использование какой-либо хитрой нотации будет скорее во вред.
Мой вариант такой диаграммы я называю «Сафед-диаграмма», от таджикского/персидского «сафед»- ясный, чистый, белый. По сути, Сафед-диаграммы содержат консолидированную и обобщенную информацию о логике процессе, что упрощает понимание. Сами диаграммы я «рисовал» в Excel, так что никаких магических инструментов так же не требуется. И еще небольшое пояснение, я не привожу ни текстового описания процесса, но то, почему указаны те или иные особенности и детали, ни даже пояснений к используемой нотации. На данном этапе моя цель – показать, насколько диаграмма-схема может быть понятной даже без прочтения текстового описания и без приведения расшифровки к используемой нотации.
Итак, отображение логики процесса «указания услуги доставки бандероли» будет выглядеть примерно как на рисунках ниже (я разбил сам процесс на 3 части, чтобы было удобно его рассматривать):
Часть 1 (крупнее):
Часть 2 (крупнее):
Часть 3 (крупнее):
И дополнительные схемы — движение и источники данных для процесса (крупнее):
Как можете видеть, на диаграммах явно указано, кто и что делает, откуда берет или где фиксирует данные, кто отвечает за их (данных) актуальность и заполнение. Хоть сейчас составляй должностные инструкции. Более того, видно, какие должностные обязанности можно совместись. Одним словом, мы прозрели и явно видим, что должно происходить.
При этом у схемы процесса есть места вокруг самой диаграммы, где мы вольны добавлять произвольные пояснения и детали (в моем случае я добавил пару рассшифровок и коментарии к этапам). При необходимости, можно добавить и «второй слой» для замечаний, и дать возможность заинтересованным лицам вносить свои вопросы, комментарии и/или замечания к отдельным шагам процесса.
Если просмотреть приведенную схему процесса с небольшой толикой внимания, то сразу видны и упущения и недостатки. Для примера,
Вероятно, будут также замечания на «избыточность» указания источников/наборов данных, которые присутствуют на последней схеме. Однако я их включил не просто так. В случае процессов, связанных с IT, да и вообще, для контроля над процессом и данными, это необходимая информация. Пользователь диаграммы получает возможность видеть и оперативно получить детали: кто, какую информацию и откуда ее вносит в тот или иной набор данных.
В итоге, взглянув на Сафед-диаграммы, менеджер, или другой специалист сразу видит всю необходимую ему информацию по процессу. Более того, часто будут заметны недостатки текущего процесса, его описания или же того, что предлагает бизнес-аналитик. С другой стороны, при изменении технических средств, которые мы или заказчик применяет в рамках процесса (внутренняя система электронного документооборота, физические носители данных и т.д.) сама диаграмма процесса не меняется. И это, с моей точки зрения, достаточно большой плюс, поскольку мы описываем логику процесса, а не его реализацию. Более того, в дальнейшем, при сравнении рекомендаций, всегда можно оценить, не менялась ли логика процесса, все ли связи, взаимодействия, оповещения и проверки были реализованы.
В принципе, нечто похожее можно изобразить и в рамках BPMN, EPC и UML. Однако рекомендации для этих нотаций больше ориентированы на описание конкретных реализаций процессов, а не на их логику. Я надеюсь, что все понимают, что идея в том и состоит, чтобы применять подобные Сафед-диаграммы как дополнение, как отправную точку для анализа процессов «As Is» и «To Be», а не как замену этих диаграмм.
Резюмируя все вышесказанное, основные проблемы у нас не в средствах (типах диаграмм, классификации требований и т.д. и т.п.), а в неполном понимании тех задач, которые стоят перед бизнес-анализом. В результате, вместо анализа бизнес-процессов (как мы выяснили ранее — шагов, необходимых для минимизации рисков не достижения бизнес-цели, и/или уменьшения издержек для ее достижения) коллеги занимаются анализом и документированием либо технологических процессов, либо должностных обязанностей сотрудников. В редких случаях, дополняя все это описанием документооборота.
У меня все. Надеюсь, кто-то найдет для себя что-нибудь полезное.
Всем удачи и успехов.
Источники изображений:
1. Песик и «бардак на почте» — отсюда и отсюда, соответственно.
2. Диаграмки — личное творчество.
Анализ и описание процессов
Следующим пунктом бизнес-анализа является описание бизнес процессов. На этом этапе, обычно, рисуют, так называемые диаграммы бизнес-процессов «As is». И вот тут-то всех и поджидают проблемы, что называется, на ровном месте. Самая большая проблема в том, что за деревьями не видно леса. Так же, как и при описании бизнес-целей, зачастую народ увлекается описанием того, как все работает прямо сейчас. При этом редко кто задается целью разобраться, а насколько текущие процессы вообще соответствуют тому, как все должно быть? Все наверняка знают одно из правил автоматизации: «автоматизируя бардак — мы получаем автоматизированный бардак, и ничего более». Так вот, чтобы не строить очередной «скайнет», который всех уничтожит, необходимо понять — «а как же все вообще должно функционировать?». И это очень интересная задача. Конечно, далеко не все бизнес-аналитики в состоянии с ходу накидать бизнес-процессы, как все должно происходить в каждом конкретном случае. Но тут никаких тайн нет. Для решения этой задачи, надо просто позвать риск-аналитика, если он есть, ну или немного ознакомиться с профильной литературой и чуточку подумать. Это не сложно, честно.
Так вот, не будет далеко уходить от нашего прекрасного примера с почтой, и рассмотрим «простейший» процесс — «услуга доставки бандеролей». Для тех, кто знает кухню почты, сразу предупреждаю, что дальше описывается упрощенный пример в «рафинированном виде», то, каким его может увидеть бизнес-аналитик, или даже менеджер. Подробностей в стиле «привязки к существующей инфраструктуре» и прочих «исторически сложившихся условий» тут не будет. По сути, все эти детали рассматриваться уже на третьем этапе работ бизнес-аналитика, который в данной статье не рассматривается. Более того, на данном этапе нам вообще не нужны технические детали и даже скажу больше, от них надо всячески уходить, иначе мы просто затрудним себе задачу. Подробности и детали, как и описание процессов «As Is» — нужны, важны и используются именно в части анализа процессов и последующих предложений, рекомендаций и прочего
Итак, у нас есть цель – доставка ценностей от заказчика – получателю. У нас есть вариант достижения этой цели:
- Заказчик приходит, сдает свои упакованные ценности (а упаковка — это уже отдельный процесс и бизнес, который мы игнорируем сейчас);
- Компания обеспечивают доставку бандероли (упакованных ценностей) туда, где их может получить получатель;
- Получатель, приходя в заранее согласованное место, получает отправление.
Как уже говорил, мы берем упрощенный процесс, чтобы показать, на что надо обращать внимание, и что нужно делать. Как видим, все достаточно просто и можно хоть сейчас чего-нибудь рисовать. Но, не будет торопиться. Как говориться «Обязательно бахнем, и не раз. Весь мир в труху. Но потом» (ц). Так вот, вернувшись в сей бренный мир из тумана грез, перед нами стоит задача, описать, как мы (компания) может обеспечить исполнение потребности (доставка бандероли), и не только ее обеспечить, но и гарантировать, что заинтересованные стороны (заказчик и получатель) будут удовлетворены. И последнее замечание, является важным, я бы сказал, определяющим. Да, я знаю, что будет много возражений в стиле «целью бизнеса является зарабатывание денег», «компаниям наплевать на клиентов» и множество других, вполне резонных. Но, повторяю еще раз, целью бизнеса – является удовлетворение потребности. А уж насколько прибыльно это занятие, это уже другой, коммерческий вопрос.
Продолжаем. Нам необходимо гарантировать удовлетворение потребности. Просто потребности, без учета затрат, объемов и прочего. Можно сказать, что если заинтересованные лица воспользовались этой услугой и остались довольны результатом, значит — мы успешно достигли цели. То есть, нам надо просто понять, а почему эти самые лица могут быть недовольными? Вариантов немного: ожидаемые события не случились, или случились не так, как ожидалось. В нашем конкретном случае имеем куст вариантов с уточняющими вопросами:
- Получатель не получил бандероль
- Получатель утверждает/уверен, что именно данная, конкретная бандероль им не получена (Как мы может это проверить? Кто и как ее передает, и как это фиксирует?).
- Бандероль не доставлена, когда ожидалась:
- Нет согласованных требований к срокам доставки (Почему были другие ожидания? Фиксировалось ли это каким либо образом?).
- Компания (или отдельные ее сотрудники, подрядчики) не имеют возможности выполнить работу: болеют, нет соответствующей квалификации, недоступны тех. средства (Кто за этим следит, и когда об этом стало известно?)
- Компания (или отдельные ее сотрудники, подрядчики) ничего не знают о данной бандероли. (Как это проверить?)
- Нет согласованных требований к срокам доставки (Почему были другие ожидания? Фиксировалось ли это каким либо образом?).
- Получатель утверждает/уверен, что именно данная, конкретная бандероль им не получена (Как мы может это проверить? Кто и как ее передает, и как это фиксирует?).
- Получатель не доволен тем, что и как получил. Например, вложение было повреждено. (В данном случае не понятно, проверялись ли вложения, или откуда эти «требования к бережному обращению» могли быть известны исполнителю/работнику. Более того, как исполнитель/работник может быть уверен, что требования, предъявляемые к вложению и/или обращению с отправлением, соответствует ожиданиям конкретного заказчика?)
- Отправитель отказался от услуг:
- заказчик не смог воспользоваться услугой, например, была очередь, или он не получил информации, что услуга доступна – например сотрудник не смог ее разъяснить, или же у него недостаточно квалификации чтобы ее оказать (Фиксируются ли обращения и результаты?).
- предложенная услуга не соответствует пожеланиям заказчика, например по цене, или иным условиям (Как об этом мы можем узнать?).
- заказчик не смог воспользоваться услугой, например, была очередь, или он не получил информации, что услуга доступна – например сотрудник не смог ее разъяснить, или же у него недостаточно квалификации чтобы ее оказать (Фиксируются ли обращения и результаты?).
Итак, мы уже знаем о нашем процессе кое-что, но как все это сделать доступным и понятным для любого человека, без прочтения «… дцати» страниц текста? Ответ известен всем – надо просто нарисовать. И, как обычно, нас поджидает другой «сюрприз». Большинство используемых методологий графического отображения бизнес-процессов рекомендуют на диаграммах отображать именно технические детали (BPMN, UML, EPC и др.). В этом нет ничего плохого и на этапе анализа и подготовки рекомендаций диаграммы «As Is» и «To Be» именно такими и должны быть. Но когда мы описываем непосредственно сам процесс, его логику и правила, эти детали, как песок пустыни, покрывают любые сокровища. В результате, мало кто в состоянии сразу оценить корректность или ошибочность самих процессов или их понимание бизнес-аналитиком.
Вот мы плавно и подошли к вопросу изобретения очередного «велосипеда». Да, мы не будем мудрствовать лукаво, а просто применим «самопальную» нотацию для описания логики бизнес-процесса. Поскольку эта диаграмма рассчитана на неподготовленных пользователей (менеджеров, аналитиков, разработчиков) то использование какой-либо хитрой нотации будет скорее во вред.
Мой вариант такой диаграммы я называю «Сафед-диаграмма», от таджикского/персидского «сафед»- ясный, чистый, белый. По сути, Сафед-диаграммы содержат консолидированную и обобщенную информацию о логике процессе, что упрощает понимание. Сами диаграммы я «рисовал» в Excel, так что никаких магических инструментов так же не требуется. И еще небольшое пояснение, я не привожу ни текстового описания процесса, но то, почему указаны те или иные особенности и детали, ни даже пояснений к используемой нотации. На данном этапе моя цель – показать, насколько диаграмма-схема может быть понятной даже без прочтения текстового описания и без приведения расшифровки к используемой нотации.
Итак, отображение логики процесса «указания услуги доставки бандероли» будет выглядеть примерно как на рисунках ниже (я разбил сам процесс на 3 части, чтобы было удобно его рассматривать):
Часть 1 (крупнее):
Часть 2 (крупнее):
Часть 3 (крупнее):
И дополнительные схемы — движение и источники данных для процесса (крупнее):
Как можете видеть, на диаграммах явно указано, кто и что делает, откуда берет или где фиксирует данные, кто отвечает за их (данных) актуальность и заполнение. Хоть сейчас составляй должностные инструкции. Более того, видно, какие должностные обязанности можно совместись. Одним словом, мы прозрели и явно видим, что должно происходить.
При этом у схемы процесса есть места вокруг самой диаграммы, где мы вольны добавлять произвольные пояснения и детали (в моем случае я добавил пару рассшифровок и коментарии к этапам). При необходимости, можно добавить и «второй слой» для замечаний, и дать возможность заинтересованным лицам вносить свои вопросы, комментарии и/или замечания к отдельным шагам процесса.
Если просмотреть приведенную схему процесса с небольшой толикой внимания, то сразу видны и упущения и недостатки. Для примера,
- Если мы рассмотрим этап транспортироки, то видим, что мы никак не контролируем, что происходит с бандеролью после перадачи ее в транспортный отдел или компанию. Таким образом, надо или дополнительно требовать со смежников ведение мониторинга доставки, или же на нашей стороне контролировать «журнал транспортировки», на случай задержек или «пропаданий» отправлений. По-хорошему, этот нюанс должен быть отдельно описан и отражен на схеме процесса.
- Для роли/должности «Комплектовщик» не указаны источники регламентирующих данных. С одной стороны, вся информация может быть в «наряде на доставку» и/или в «Журнале транспортировки», с другой же – это может быть результатом упущения бизнес-аналитика. В любом случае должны быть пояснения, поскольку появляется риск неверных действий сотрудника со всеми вытекающими.
- Аналогично, как и в предыдущем замечании, при получении отправлений из транспортировки и далее, на финальных стадиях, ни для одного их сотрудников не указаны регламентирующие источники
Вероятно, будут также замечания на «избыточность» указания источников/наборов данных, которые присутствуют на последней схеме. Однако я их включил не просто так. В случае процессов, связанных с IT, да и вообще, для контроля над процессом и данными, это необходимая информация. Пользователь диаграммы получает возможность видеть и оперативно получить детали: кто, какую информацию и откуда ее вносит в тот или иной набор данных.
Случай из практики
Итак, очень известная в России компания, про которую слышал каждый. И снова процесс внедрения системы для автоматизации продаж.
Представители компании каждый раз с гордостью заявляли, что в компании все процессы не только описаны, но и промоделированы в ARIS. Это не считая «полного Kaizen» во всем. При этом, к сожалению, предоставить описание процессов так и не смогли, в рузультате в спешке провели экспресс «бизнес-анализ», качество которого было ужасным.
И вот, уже на этапе внедрения системы, со всевозможными подписанными высокими сторонами планами, схемами, описаниями, готовлю команду заказчика, которая будет внедрять, поддерживать, эксплуатировать систему на головном предприятии и у дистрибьюторов. И снова чудеса случаются с «рекомендованным ассортиментом». На этот раз, из примерно 20 позиций (единых для всех), около половины отсутствуют в рабочей информационной системе. То есть, в Axapta у заказчика нет товарных позиций, которые пару месяцев назад, подписаны Генеральным Директором, как ключевые, для продаж в течение года.
Начинаем разбираться, Менеджер Проектов (ПМ) со стороны Заказчика, Генеральный, начальник Коммерческого отдела – не могут внятно сказать, откуда вообще этот список был взят. Как понимаете, в описанных бизнес-процессах, ни сам приказ, ни то, как он формируется, даже не упомянуты. На выписе, в бухгалтерии (там сидят на 1С) — этих позиций нет. На следующий день, первую половину дня все участники представления находят поводы на проблему «забить» (планерка, совещание, встреча, митинг, звонок, обед). Своими силами нашли некоторые позиции, отдаленно напоминающие те, что в приказе. Все равно порядка 5ти из них – не имеют даже отдаленных аналогов. После обеда, ставлю всех на уши, перерыли все, что только могли – нет товара такого и точка. Ни IT, ни выписка, ни бухгалтерия не сдаются, и молчат как партизаны на допросе в гестапо. И тут, после повторенного множества раз вопроса «а как эти данные в итоге появляются в системе, и кто за это отвечает» одна из девушек неуверенно предлагает, «а почему бы вам не спросить в отделе НСИ?». Говорить про то, что в схеме отделов и департаментов компании, которая приводится в отчете бизнес-аналитика, данный отдел отсутствовал – думаю, нет надобности.
На следующий день, с утра наведываюсь на задворки компании, и на второй же фразе начальник отдела спрашивает «а кто тебе дал эти товары? Мы их уже 3 года как не производим»? Занавес.
В итоге, проект первоначально запустили вообще без функционала «рекомендованных товаров», поскольку внутри компании решили все же разобраться, а как вообще они этот список формируют, и кто за что отвечает. В компании, которая гордилась полным описанием и моделированием всех бизнес-процессов.
При наличии, хотя бы, диаграммы зависимости данных, мы не потеряли бы два дня на элементарную задачу поиска источника информации. В идеале, подобной ситуации вообще не должно было случиться.
Представители компании каждый раз с гордостью заявляли, что в компании все процессы не только описаны, но и промоделированы в ARIS. Это не считая «полного Kaizen» во всем. При этом, к сожалению, предоставить описание процессов так и не смогли, в рузультате в спешке провели экспресс «бизнес-анализ», качество которого было ужасным.
И вот, уже на этапе внедрения системы, со всевозможными подписанными высокими сторонами планами, схемами, описаниями, готовлю команду заказчика, которая будет внедрять, поддерживать, эксплуатировать систему на головном предприятии и у дистрибьюторов. И снова чудеса случаются с «рекомендованным ассортиментом». На этот раз, из примерно 20 позиций (единых для всех), около половины отсутствуют в рабочей информационной системе. То есть, в Axapta у заказчика нет товарных позиций, которые пару месяцев назад, подписаны Генеральным Директором, как ключевые, для продаж в течение года.
Начинаем разбираться, Менеджер Проектов (ПМ) со стороны Заказчика, Генеральный, начальник Коммерческого отдела – не могут внятно сказать, откуда вообще этот список был взят. Как понимаете, в описанных бизнес-процессах, ни сам приказ, ни то, как он формируется, даже не упомянуты. На выписе, в бухгалтерии (там сидят на 1С) — этих позиций нет. На следующий день, первую половину дня все участники представления находят поводы на проблему «забить» (планерка, совещание, встреча, митинг, звонок, обед). Своими силами нашли некоторые позиции, отдаленно напоминающие те, что в приказе. Все равно порядка 5ти из них – не имеют даже отдаленных аналогов. После обеда, ставлю всех на уши, перерыли все, что только могли – нет товара такого и точка. Ни IT, ни выписка, ни бухгалтерия не сдаются, и молчат как партизаны на допросе в гестапо. И тут, после повторенного множества раз вопроса «а как эти данные в итоге появляются в системе, и кто за это отвечает» одна из девушек неуверенно предлагает, «а почему бы вам не спросить в отделе НСИ?». Говорить про то, что в схеме отделов и департаментов компании, которая приводится в отчете бизнес-аналитика, данный отдел отсутствовал – думаю, нет надобности.
На следующий день, с утра наведываюсь на задворки компании, и на второй же фразе начальник отдела спрашивает «а кто тебе дал эти товары? Мы их уже 3 года как не производим»? Занавес.
В итоге, проект первоначально запустили вообще без функционала «рекомендованных товаров», поскольку внутри компании решили все же разобраться, а как вообще они этот список формируют, и кто за что отвечает. В компании, которая гордилась полным описанием и моделированием всех бизнес-процессов.
При наличии, хотя бы, диаграммы зависимости данных, мы не потеряли бы два дня на элементарную задачу поиска источника информации. В идеале, подобной ситуации вообще не должно было случиться.
В итоге, взглянув на Сафед-диаграммы, менеджер, или другой специалист сразу видит всю необходимую ему информацию по процессу. Более того, часто будут заметны недостатки текущего процесса, его описания или же того, что предлагает бизнес-аналитик. С другой стороны, при изменении технических средств, которые мы или заказчик применяет в рамках процесса (внутренняя система электронного документооборота, физические носители данных и т.д.) сама диаграмма процесса не меняется. И это, с моей точки зрения, достаточно большой плюс, поскольку мы описываем логику процесса, а не его реализацию. Более того, в дальнейшем, при сравнении рекомендаций, всегда можно оценить, не менялась ли логика процесса, все ли связи, взаимодействия, оповещения и проверки были реализованы.
В принципе, нечто похожее можно изобразить и в рамках BPMN, EPC и UML. Однако рекомендации для этих нотаций больше ориентированы на описание конкретных реализаций процессов, а не на их логику. Я надеюсь, что все понимают, что идея в том и состоит, чтобы применять подобные Сафед-диаграммы как дополнение, как отправную точку для анализа процессов «As Is» и «To Be», а не как замену этих диаграмм.
Резюмируя все вышесказанное, основные проблемы у нас не в средствах (типах диаграмм, классификации требований и т.д. и т.п.), а в неполном понимании тех задач, которые стоят перед бизнес-анализом. В результате, вместо анализа бизнес-процессов (как мы выяснили ранее — шагов, необходимых для минимизации рисков не достижения бизнес-цели, и/или уменьшения издержек для ее достижения) коллеги занимаются анализом и документированием либо технологических процессов, либо должностных обязанностей сотрудников. В редких случаях, дополняя все это описанием документооборота.
У меня все. Надеюсь, кто-то найдет для себя что-нибудь полезное.
Всем удачи и успехов.
Источники изображений:
1. Песик и «бардак на почте» — отсюда и отсюда, соответственно.
2. Диаграмки — личное творчество.
