Про описание бизнес-процессов AS IS и TO BE простыми словами

Опубликовано

Если коротко, то для качественного проектирования бизнес-процессов необходимо зафиксировать имеющееся состояние («как есть», AS IS) и затем описать желаемое будущее («как должно быть или «как будет», TO BE).

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

Но сегодня обсудим исключительно описание бизнес-процессов. Давайте погрузимся в детали. To be, or not to be? Вот в чём вопрос.

Что означает AS IS и TO BE?

Этот материал не про уроки английского языка. Но именно в английском концепция звучит максимально кратко и емко, почти как аббревиатура.

AS IS & TO BE – это подход автоматизации, проектирования и оптимизации бизнес-процессов (BPI, Business Process Improvement), который основывается на двух типах моделей: «как есть» и «как должно быть».

Метод AS IS и TO BE смело можно назвать одним из подходов дисциплины управления бизнес-процессами (BPM, Business Process Management). Напомним, классическая концепция BPM предполагает четыре основных этапа: документирование, оценка, улучшение и управление. В модели AS IS и TO BE всё упрощено и фактически разбито на две фазы. Однако именно они являются ядром, отвечающим за организацию платформы (основания) для улучшений и оптимизаций.

Что такое модель AS IS

AS IS («как есть») – это модель, задача которой описать (задокументировать и отобразить все имеющиеся связи) текущее состояние существующих бизнес-процессов.

Бизнес-процессы можно отобразить любым доступным способом:

  • Построить схемы и связи.
  • Описать функции и задачи.
  • Нарисовать диаграммы и графики.
  • Указать формулы расчёта, ключевые показатели, критерии оценки и возможные допуски (допустимые отклонения).

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

В процессе анализа состояния «Как есть»:

  1. Собираются данные об имеющихся бизнес-процессах: сколько времени тратится на ту или иную операцию, какие показатели используются для оценки, какие ресурсы задействуются и прочее.
  2. Проводятся интервью и беседы с заинтересованными сторонами — всеми, кто вовлечён в бизнес-процесс, на одном конкретном этапе или сразу на нескольких, если это применимо.
  3. Рисуется блок-схема (производится картирование с визуальной иллюстрацией связей и взаимного влияния).
  4. Проводится анализ узких мест (уже на этом этапе видно, где и что можно улучшить, где и какие функции дублируются, что может мешать расширению или наращиванию производительности).

Что за модель TO BE

TO BE («как будет», «как должно быть») – это модель, задача которой описать будущее состояние бизнес-процессов, уже после всех процедур оптимизации и автоматизации.

Бизнес-процессы описываются в том же формате, что и на предыдущем этапе, при картировании состояния AS IS («как есть»). Однако перечень мероприятий немного отличается:

  1. Проводится перепроектирование существующих процессов: формулируются новые блок-схемы или схемы последовательных преобразований с изменением, переработкой или перепланированием отдельных участков.
  2. Заново описываются функции и обязанности всех участников — распределяются права и роли.
  3. Описываются новые инструменты и технические решения, выбранные на замену старым (с обязательным обоснованием и расчётами).
  4. Формулируются новые показатели эффективности (KPI), которые позволят руководству компании отслеживать и измерять уровень продуктивности обновлённых бизнес-процессов.

Обратите внимание: основная задача всех описанных мероприятий – достижение поставленных целей оптимизации.

Цели оптимизаций или перепроектирования могут быть разными. Например:

  • Повышение производительности труда.
  • Автоматизация процессов.
  • Снижение расходов.
  • Уменьшение числа ошибок.
  • Повышение качества.
  • Масштабирование (тут могут быть подцели, такие как кратное увеличение объёма производства, запуск новых производственных линий, обеспечение достаточного уровня управляемости при увеличении масштаба производства).

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

Как выглядят схемы AS IS и TO BE

Вот пара абстрактных примеров:

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

А вот так, например, выглядела схема приёма на работу в формате AS-IS («как есть»):

После оптимизации она стала визуально сложнее:

Но по факту бизнес-процесс был сильно автоматизирован (ниже разберём кейс более детально).

Как описывать схему AS IS и TO BE

Рассмотрим на примере предметной ситуации (кейса).

Представим себе некую компанию, назовём её «ООО Эдельвейс». В текущем состоянии система приёма на работу новых сотрудников показывает слабую эффективность: слишком низкая производительность труда HR-специалистов, соответственно, им некогда заниматься задачами по обучению и адаптации новичков. В результате ухудшается качество подготовки вновь прибывших специалистов, и возникает необходимость задуматься о введении новой должности в HR-отделе для повышения производительности (а это ненужные расходы и новые штатные расписания).

Целью становится исправление ситуации и повышение эффективности процесса найма сотрудников.

Сначала было проведено картирование ситуации. Описывается модель «как есть»:

  1. HR-служба отправляет формы документов и заявлений соискателю на электронную почту.
  2. Соискатель распечатывает бланки и заполняет их вручную.
  3. Затем соискатель лично приносит бумажные версии в отдел кадров и передаёт представителям HR-службы.
  4. Специалисты HR-службы изучают документы и вручную переносят данные в свою информационную систему.
  5. Далее в работу включается IT-отдел, который тоже вручную создаёт новые учётные записи для сотрудников и распределяет им права доступа.
  6. Учебные программы и занятия по адаптации планируются вручную.
  7. Некоторые отделы и службы периодически вносят свои коррективы в процесс адаптации (касательно своей сферы ответственности), что затрудняет процесс обучения и делает его несистемным.
  8. Механизмов сбора обратной связи как таковых нет. Оценка и анкетирование проводятся от случая к случаю.

Уже на этом этапе можно провести анализ и выявить потенциальные проблемы:

  • У HR-специалистов слишком высокая административная нагрузка из-за необходимости ручного ввода данных.
  • Последний является причиной большого числа ошибок и накладок, из-за которых данные приходится перепроверять несколько раз.
  • Непоследовательная программа обучения снижает мотивацию и вовлечённость новичков.
  • Процесс обучения и адаптации остается непрозрачным для руководства компании.
  • Механизмы адекватной оценки ситуации отсутствуют.

После анализа ситуации «как есть» руководство компании формулирует задачи для процесса оптимизации:

  1. Сократить срок адаптации на 50% без потери качества обучения.
  2. Устранить ручной ввод данных и сократить число операций, требующих участия специалистов HR-службы.
  3. Повысить точность проверки данных и внедрить автоматизированные системы для их проверки.
  4. Внедрить централизованный интранет-портал для обеспечения максимальной прозрачности и формирования автоматических оценок.
  5. Обеспечить доступ к базе образовательных материалов для самостоятельного обучения сотрудников.
  6. Внедрить механизмы автоматической проверки знаний и тестирования.
  7. Организовать систему сбора обратной связи.

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

Углублённый анализ состояния AS IS оформляется в виде таблицы с колонками: 

  • Этап адаптации/онбординга (его наименование и последовательность в общем алгоритме).
  • Ответственное лицо (можно указать только должность).
  • Что поступает на вход этапа.
  • Что получается на выходе.
  • Какие проблемы имеются (что нужно исправить).

На основе таблицы получилась вот такая блок-схема:

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

На основе таблицы TO BE рисуется новая блок-схема, отражающее состояние того, как должно быть:

Можно заметить, что на новой схеме роль HR-специалистов полностью исчезла. Вместо этого нагрузка легла на IT-отдел, который теперь отвечает за определение прав доступа (этот процесс при желании тоже можно автоматизировать или стандартизировать).

Самый сложный этап уже не относится к анализу AS IS / TO BE (есть / будет), это планирование внедрения и обеспечение необходимыми ресурсами. Реальное внедрение остаётся за кадром, но именно оно потребует больше всего ресурсов: на проектирование и обучение, на поиск и закупку необходимых программных продуктов, их установку, настройку и сопровождение, на перестройку систем коммуникации и мотивации, пилотное тестирование и не только.

Иногда получается так, что эффект от внедрения системы автоматизации и оптимизаций оказывается слишком дорогим, и тогда руководство отказывается от реализации идеи.

Стоит ли использовать подход AS IS и TO BE в своих проектах?

Технически описание состояния «как есть» и «как надо» («как должно быть») может занять всего пару дней. При достаточном опыте ответственные лица смогут быстро спроектировать и отразить в блок-схемах новое состояние бизнес-процессов с учётом всех требований по оптимизации.

Самая существенная работа всегда остаётся вне поля зрения – это усилия по реальному внедрению и тестированию изменений. А такие изменения в компаниях и проектах редко обходятся малой кровью.

Поэтому, резюмируем: если говорить только о методологии AS IS & TO BE, то она более чем работоспособная. Но это только вершина айсберга. Когда вы затеваете изменения в бизнес-процессах, будьте готовы к большим расходам, а также к затратам времени на переобучение сотрудников и их адаптацию к новым инструментам. Именно здесь и кроется основная сложность.

Материал по теме: Чем и как моделировать бизнес-процессы