Зачем компании управлять сквозными процессами?

Спустя почти месяц тишины решила написать о сквозных процессах, часто их еще называют E2E (end to end) процессами. Мы сейчас как раз работаем над картой сквозных процессов в компании, и много рефлексировали на эту тему, захотелось поделиться.

Начнем с определения, конечно же. Итак, сквозным процессом принято считать процесс, затрагивающий несколько функциональностей (функциональных областей), несколько подразделений компании. Как и любой процесс он ограничен по времени и имеет результат. Для сквозных процессов, как правило, результатом является реализация продукта компании, то есть доставка ценности клиенту. Мне нравится объяснять сквозной процесс, как процесс "от идеи до реализации". На мой взгляд такая формулировка емко дает понять, что сквозной процесс описывает все этапы деятельности компании, направленные на создание продукта/услуги, а следовательно затрагивает все (или почти все) подразделения, в зависимости от масштаба компании.

Сквозной процесс состоит из атомарных процессов, их еще можно назвать сервисами. Атомарный процесс или сервис - это процесс, который реализуется одним подразделением, ограничен во времени и имеет результат, который "потребляет" другой процесс или подразделение компании.

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

Разберем на примере сквозного процесса доставки еды клиенту из сервиса онлайн-доставки.

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

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

Основная проблема идентификации и следовательно описания сквозных процессов состоит в том, что как правило, выполняя свою привычную рабочую деятельность исполнители не мыслят (не осознают) в рамках какого процесса они эту деятельность осуществляют. Поэтому проще идти "сверху вниз" при идентификации и описании сквозных процессов. При таком подходе вы как бы раскручиваете постепенно деятельность компании (по аналогии с матрешкой).

Начинать идентификацию сквозных процессов считаю правильным отталкиваясь от определения сквозного процесса, то есть определить какие продукты/услуги оказывает компания клиентам. В зависимости от целей и задач описания процессов можно сконцентрироваться только на внешних продуктах (тех, которые компания оказывает внешним клиентам), или и на внешних и на внутренних (например, если в компании имеются продукты для сотрудников - сервисы заботы и т.д).

После получения списка продуктов рекомендую определить ключевые вехи (контрольные точки), которые требуется обязательно пройти для создания каждого из продуктов. Имея эти вводные можно сформировать карту первого уровня сквозных процессов компании. Гранулярность этапов сквозного процесса будет в данном случае равна объему процессов, заключенных между ключевыми вехами. Этот уровень абстракции позволяет понять, чтокомпании требуется сделать для того, чтобы создать и реализовать продукт. Но этот уровень не содержит информации о том, как именно выполняется тот или иной этап.

Далее в зависимости от сложности бизнеса и устройства самих процессов сквозной процесс можно разложить на более низкие уровни (сколько уровней будет на карте определяете вы, но обычно рекомендуется остановиться на 3-4). Для второго уровня я бы предложила критерий гранулярности - результат. То есть каждый подпроцесс определяется критерием, что на вход ему поступает результат предыдущего процесса, и на выходе должен быть результат, который будет использовать последующий процесс. На этом уровне уже могут появляться различные сценарии выполнения процесса, но все еще без детализации до конкретного описания, как выполняется тот или иной процесс.

Для третьего или последнего уровня уже имеет смысл описывать процесс до конкретных действий и исполнителей, с указанием ролей и систем, а также получаемых артефактов. Как правило пользователями данного уровня будут реальные исполнители (бизнес-команды), а также ИТ-команды. занимающиеся автоматизацией процесса. На этом уровне уже четко понятно, как именно компания создает продукт, какие действия выполняет каждая роль.

Создавая карту сквозных процессов в компании, которой я сейчас работаю, мы разработали для себя отдельную нотацию для последнего уровня. Эта нотация является симбиозом нотаций BPMN и DFD. Получилось интересно, об этом, кстати расскажем на конференции Flow 2024 Autumn https://flowconf.ru/persons/97f132c7d9f247e087206273123a7dfd/

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

Но рассмотрим чуть детальнее, через различные точки зрения (View-points).

Топ-менеджерам управление сквозными процессами нужно, чтобы:

1. Видеть картину целиком, а не отдельные участки

2. Понимать как на данный момент создаются продукты

3. Видеть проблемы, риски, дублирования. Упростить адаптациюи недостатки в процессах за счет повышения прозрачности информации

Бизнес-командам управление сквозными процессами через призму карты процессов нужно, чтобы:

1. Определить границы своей деятельности

2. Видеть зависимости, точки соприкосновения с другими командами/смежными подразделениями, а следовательно понимать зависимости результата работы каждого подразделения в общем процессе создания продукта

3. Определить и зафиксировать обязанности сотрудников и SLA по их выполнению

4.Понимать в каких ИТ-системах работают сотрудники

5. Упростить адаптацию/обучение сотрудников

Наконец, ИТ-командам управление сквозными процессами через призму карты процессов нужно, чтобы:

1. Видеть какие ИТ-команды вовлечены в реализацию сквозного процесса

2. Видеть какие ИТ-системы и какую функциональность реализуют в рамках сквозного процесса

3. Понимать какие бизнес-сущности создаются, модифицируются и удаляются в рамках процесса

4. Понимать какие ключевые события происходят в процессе, и как они влияют на ход выполнения процесса

5. Видеть какие интеграции между системами существуют в рамках процесса

6. Упростить постановку задач на разработку ИТ-командам

7. Определить какие контракты должна выполнить каждая из команд в рамках интеграции

8. Определять неоптимальную реализацию интеграции или прикладной функциональности в рамках процесса

Итого, имея общую картину работы бизнеса и ИТ проще принимать взвешенные решения по инвестициям в ту или иную деятельность и автоматизацию.

Как у вас в компании с сквозными процессами - описываете их или концентрируетесь на атомарных и тушении пожаров?