Как описывать бизнес-процессы?
Всем привет! Продолжаем работу с бизнес-процессами: сегодня будем разбираться, как их описывать, для чего, какими способами. Применение каждого из способов описания я буду разбирать отдельно на примерах (как было с кейсом про анализ бизнес-процесса, так будет и про описание).
Описание у нас затрагивает две важные штуки:
- фиксацию всех элементов бизнес-процесса (вход, шаги, ресурсы, ограничения, владелец, исполнитель, потребитель, выход)
- оформление в однозначно понятном, доступном для последующего хранения, изменения, обучения и масштабирования виде
При этом, по моему мнению, важно отметить, что фиксируем мы бизнес-процесс либо в состоянии «как работает сейчас» (AS IS), либо в состоянии «каким бизнес-процесс должен быть» (TO BE), при этом когда мы говорим про то, каким процесс должен быть, мы либо предполагаем изменения, улучшения текущих процессов, либо занимаемся моделированием бизнес-процессов еще не запущенного бизнеса, то есть заранее устанавливаем правила, по которым собираемся начать работать.
А вот вариантов оформления у нас есть три: текст, таблица, графика. И именно про эти варианты, конкретные инструменты реализации этих форматов я и буду сегодня рассказывать. Так что дети, встаем в круг и слушаем, что говорит старый жук))
Про то, как мы получаем информацию о бизнес-процессе я писала в статье Как анализировать бизнес-процесс? Там смотрим в пункт про сбор информации, собираем как написано и потом формируем ручками описание. Собрать можно с помощью интервью (вопросы могут быть открытыми и закрытыми, «опишите важи ежедневные действия» и «оцените от 1 до 10 эффективность действий и почему вы дали такую оценку»), наблюдения (посидеть в углу и посмотреть, что происходит в рамках бизнес-процесса, кто из сотрудников что делает, как быстро оформляется та или иная документация внутри процесса), изучения документации (посидеть, почитать уже существующее старое описание процесса, документы, которые появляются в ходе выполнения процесса и сформулировать представление о состоянии процесса).
1. Текстовое описание
Это самый базовый способ — написать словами, как все устроено.
Обычно такой формат используется в регламентах, должностных инструкциях, методичках, и он удобен для линейных, простых процессов, но неудобен для кросс-функциональных процессов.
Пример текстового описания:
При поступлении заявки с сайта менеджер по продажам в течение одного рабочего дня связывается с клиентом по телефону, уточняет потребности. По уточненным потребностям готовит коммерческое предложение. После этого он направляет его клиенту и делает пометку в CRM (переводит на соответствующий этап воронки). Если клиент заинтересован, проводится встреча, обсуждаются условия, и после согласования документов менеджер передает счет на оплату. После оплаты счета клиентом менеджер делает пометку в CRM (переводит на соответствующий этап воронки) и переводит информацию в отдел внедрения.
Этот формат быстрый, простой в реализации, но бывает сложным к восприятию, запоминанию и исполнению, а также в таком виде сложно поддерживать актуальность описания бизнес-процессов (или это становится очень дорого).
Что еще? Так часто бывает, что бизнес-процессы, описанные текстом, «расползаются» по разным документам. Например, частично фиксируются и описываются в трех разных должностных инструкциях трех разных исполнителей одного и того же процесса, а общего описания всех элементов нет.
Для контроля за текстовым описанием нужно обязательно соблюдать наличие описания всех элементов процесса (вход, шаги, ресурсы, ограничения, владелец, исполнитель, потребитель, выход) и ссылки на связанные документы (регламенты, инструкции).
Как писать? Лучше всего по формуле стараться раскладывать каждый шаг описываемого процесса:
Кто? + В каком случае? + В каких ограничениях? + Что делает? + С какими ресурсами? + Что получает в результате?
То есть давайте вернемся к нашему примеру выше и разложим предложение из текста:
Менеджер по продажам (кто?) при поступлении заявки с сайта (в каком случае?) в течение одного рабочего дня (в каких ограничениях?) связывается с клиентом по телефону, уточняет потребности (что делает?).
Тут у нас нет фиксации результата (что он получает какое-то описание потребностей клиента, зафиксированное где-то), и нет описания ресурсов четкого, например, мы знаем, что есть сайт и телефон, но ничего нет про то, где он видит поступление-то, мы догадываемся, что это CRM. Поэтому наше текстовое представление бизнес-процесса было бы лучше, если бы звучало как-то так:
Менеджер по продажам (кто?) при поступлении заявки с сайта и отображении ее в CRM в этапе воронки «Новая заявка» (в каком случае?) в течение одного рабочего дня (в каких ограничениях?) связывается с клиентом по телефону, уточняет потребности (что делает?) и фиксирует выявленные потребности в поле «Потребность клиента» (что получает в результате?).
Детали, последовательность, однозначность, понятность, — писать надо стараться с соблюдением этих принципов.
2. Табличный формат
Вариант чуточку более организованный и наглядный. Почти все элементы бизнес-процесса мы можем зафиксировать как столбцы, а строками будут выступать шаги процесса, в таком случае у нас есть вход и выход для каждого шага, исполнитель каждого шага и (при необходимости) ограничения, потребители и ресурсы каждого шага, что позволяет чуть глубже смотреть на бизнес-процесс.
Давайте на том же примере с обработкой заявки в продажах посмотрим:
Тут я остановлюсь на двух шагах, главное, чтобы вы уяснили суть.
Смотрите на важные штуки, на которые нужно обратить внимание в таблице:
- есть внешний исполнитель, тот, кто за пределами нашей организации (это клиент), но в таблице мы это никак не показываем, не отмечаем, мы просто знаем это, когда смотрим в нужную ячейку
- выход одного шага является входом для следующего шага (иногда в прямой последовательности, иногда через несколько шагов)
- появление потребителей, не связанных с функциональным линейным процессом (речь шла о продажах, а появился продукт), но в требованиях, которые сообщил клиент, может быть заинтересован Владелец продукта, и он будет использовать это как фидбэк или основание для ресерча, то есть точка появления нового потребителя выхода какого-то шага может быть входом для связанного процесса, например, обработки обратной связи, например, есть процесс, когда менеджеры регулярно собирают фидбэк от потенциальных клиентов, систематизируют его и передают в продуктовый отдел (важно: в текстовом описании тоже нужно делать ссылки по тексту на связанные процессы)
То есть какой мы вывод должны сделать по этому способу описания бизнес-процессов? Такой:
Чтобы было полное, детальное, однозначное описание, нужно чтобы у такой таблицы обязательно была шапка:
Название процесса: Продажи по заявкам с сайта
Владелец процесса: Руководитель отдела продаж
Потребители: Продажи, Маркетинг, Продукт, Финансы, Юристы
Связанные процессы: Маркетинг (реклама и трафик на сайт), Продукт (обработка обратной связи от клиентов)
И только потом уже сама таблица с заполненными данными.
Плюс подхода в том, что довольно наглядно и структурно, минус в том, что довольно громоздко. Мой любимый плюс в том, что очень удобно делать сводные таблицы с общим перечислением всех бизнес-процессов, и таким образом видеть общую картину покрытия процессами и правилами внутри компании.
3. Графическое описание
И наконец, схемы, которые многие и считают правильным «описанием процесса», а все остальное так, для тех, кто ненастоящий аналитик.
Для представления бизнес-процесса в виде диаграммы или схемы существуют определенные «языки» написания — нотации, где для каждого элемента есть свое визуальное представление (то есть особый символ / графическое изображение действия, условий, ресурсов, исполнителей и т. д.). Например, для блок-схемы ромб означает выбор / условие, а прямоугольник означает действие, и люди, которые знают значение элементов легко считывают их с общего полотна, и так на описание тратится намного меньше условных текстовых символов и пояснений, потому что остальное шифруется графическими элементами.
Самые распространенные нотации: блок-схема, BPMN, EPC, IDEF0, UML, а строить эти схемы процессов можно в Miro, Lucidchart, Draw.io, Bizagi и т. д. В профессиональном стандарте для профессии бизнес-аналитика это относится к знанию и умению использовать языки и инструменты визуального моделирования.
(я в этой статье не буду делать графическое представление процесса, но в последующих с разбором конкретных нотаций, их правил и требований, буду, так что проявите терпение, драгоценные)
Из плюсов — наглядно, понятно, красиво, из минусов — не все умеют читать схемы и знают обозначение графических элементов, актуализировать сложно без специальных инструментов / людей, которые умеют работать с этими нотациями.
Что выбрать?
Описание бизнес-процесса должно быть полным, однозначно понятным, масштабируемым, и оно должно быть удобным для вас и вашего бизнеса, поэтому подбирать нужно под цели и задачи ваши:
- если вам важно быстро зафиксировать, как работает или как должно работать — начните с текстового описания,
- если важно учесть все детали каждого процесса и потом свести воедино представление о всех бизнес-процессах — делайте таблицу,
- если работаете над автоматизацией, внедрением новых инструментов и у вас работают высококвалифицированные специалисты — графическое описание в наиболее подходящей нотации,
- если работаете над аудитом всех бизнес-процессов компании для поиска узких мест, проблем и будущих улучшений — используйте комбинированный подход (текст + графика, графика + сводная таблица и т. д.).
И напоследок
Учитывать при подборе способа описания бизнес-процессов нужно не только свой опыт, но и опыт ваших коллег: у всех разное восприятие информации и коммуникационный бэкграунд. В описании лучше всего описывать не как для себя, а так, как если бы вы хотели описать действия, результаты, участников и суть для другого человека, который никогда не видел, как это все работает.
Чем проще, понятнее и честнее вы его опишете — тем эффективнее потом будет работа с этим процессом.
Что у нас дальше по плану? Возьмем пример какого-нибудь бизнес-процесса, из небольшого количества шагов и условий, и сделаем его в разных нотациях для сравнения + сформулируем основные элементы нотаций. И в паре моментов уточним, где граница описания бизнес-процесса и простого процесса, именно с точки зрения нотаций и графики.
Следить за выходом статей и ��ихикать над мемами, общаться в комментариях можно в канале: