Существует множество методов и подходов, позволяющих решать специфические проблемы и итерационно проектировать процессы: бережливое производство, шесть сигм, бережливые шесть сигм, функционально-стоимостной анализ затрат (ABC), SIPOC, анализ цепочки создания ценности, кайдзен, анализ видов и последствий отказов (FMEA), соглашения об уровнях обслуживания (SLA) и т. д.[94] У каждого свои возможности, которые необходимо сопоставлять с потребностями – любой инструмент должен использоваться по назначению. Там, где применяется BPMS, мы будем говорить о единой среде BPM, поддерживаемой BPMS.
Приступая к проектированию процессов, важно определиться – будете ли вы заниматься сквозным кросс-функциональным процессом или частной проблемой на уровне потока работ. Это определит рамки, используемый подход, а также масштаб требуемых усилий, необходимого регулирования и результирующего эффекта.
5.2.1. Модель процесса не является моделью бизнес-архитектуры
Люди, участвующие в моделировании бизнеса, часто путают процессные модели с архитектурными. Действительно, бизнес-архитекторы создают модели бизнеса, но эти модели характеризуются высокой степенью абстракции, они имеют дело с бизнес-способностями, то есть со способностями компании осуществлять высокоуровневые бизнес-функции. Например, можно говорить о способности компании вывести новую продукцию на рынок в течение одного года или о способности фармацевтической компании выполнять клинические исследования для новых препаратов в соответствии со всеми требованиями закона.
Таким образом, модели способностей являются концептуальными и отвечают на вопрос, «что» такое наш бизнес. На нижних уровнях детализации модели способностей определяют все действия, которые должны быть предусмотрены, чтобы бизнес приносил результат. Процессные модели, с другой стороны, отвечают на вопрос, «как» устроен наш бизнес – они описывают то, как результат, продукция или услуга создаются и доставляются клиенту. Процессные модели концентрируются на физических действиях и на управлении ими и, таким образом, на производительности.
Сочетание моделей этих двух видов дает перекрестный взгляд. Любая работа должна быть обеспечена определенной бизнес-способностью – это вопрос результативности[95]. Затем можно проследить последовательность выполнения работ и усовершенствовать управление. Исключая ненужную работу и автоматизируя все, что возможно, проектировщик добивается максимальной производительности[96].
Путаница между этими моделями отчасти объясняется тем, что многие компании поручают разработку процессных моделей не процессным аналитикам, а бизнес-аналитикам. Эти две дисциплины рассматривают бизнес-операции под разными углами зрения.
Хорошо понимают разницу между бизнес-способностями и процессами только профессионалы, обладающие подготовкой в области и бизнес-архитектуры, и процессной архитектуры, большинство же остальных улавливают ее с трудом. В результате понятия «процесс» и «способность» размываются до того, что многие считают, что процессные модели – это нижний уровень детализации модели бизнес-способностей, тогда как в действительности это не так.
Обе дисциплины нацелены на совершенствование бизнеса, и у обеих есть для этого средства. Они не конкурируют, а дополняют друг друга. Для любого изменения масштаба предприятия или процесса нужны они обе. Но многие компании только начинают проводить это различие, а пока же наблюдается путаница как в определении ролей аналитиков, так и в используемых средствах.
5.2.2. Отправная точка
Природа проекта BPM определяется масштабом изменений или усовершенствования. Если речь идет о кросс-функциональном процессе, то это означает изменения стратегического масштаба, которые невозможны без долгосрочной решимости, так как они затронут множество бизнес-единиц. Проект такого уровня, как и любой большой проект, будет глубоким и радикальным и потребует специфических методов планирования и контроля. Здесь разумно будет исходить из того, что после создания модели «как есть» верхнего уровня процесс будет разделен на компоненты, которые будут проектироваться по отдельности, а затем собраны воедино. Чтобы быть уверенными в том, что эти компоненты стыкуются друг с другом и что они обеспечивают фундаментальное улучшение процесса, проектирование и управление должны вестись на двух уровнях. Во-первых, когда речь идет об изменениях и усилиях такого масштаба, их целесообразность должна быть обоснована соответствующим масштабом ожидаемого эффекта.
На втором уровне проекта BPM решаются специфические проблемы и достигаются конкретные результаты. Обычно это менее масштабные проекты, нацеленные не на процессы, а на потоки работ. В этом принципиальное различие между используемыми в данной главе терминами «процесс» и «поток работ».