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

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

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

Ошибка 1. Начинать без понятной цели

Одна из самых частых ошибок — запускать описание процессов, не ответив на вопрос, какую проблему должна решить архитектура.

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

Что делать

До начала моделирования сформулировать конкретную бизнес-задачу.

Например:

• сократить повторяющиеся сбои;
• связать процессы с информационными системами;
• определить причины высоких затрат;
• подготовить компанию к масштабированию.

Цель должна задавать критерий успеха. Если невозможно объяснить, какое управленческое решение будет приниматься с помощью архитектуры, проект, вероятно, начат слишком рано.

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

Ошибка 2. Пытаться охватить всю компанию сразу

Желание построить полную архитектуру вполне логично. Но на практике такое построение может длиться годами. Пока команда собирает информацию и согласует классификаторы, процессы меняются, модели устаревают, а руководители теряют интерес.

Участники дискуссии предлагали разные варианты выбора стартового контура: основные процессы, наиболее затратные функции, участки с дефицитными ресурсами или регулярными сбоями. Общий принцип один — начинать нужно не со всей компании, а с области, где можно получить и показать результат.

Что делать

Для первого этапа выбрать процесс или группу связанных процессов, где одновременно есть:

• существенная проблема;
• измеримый показатель;
• заинтересованный руководитель;
• возможность реализовать изменения;
• заметные связи с другими функциями.

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

Ошибка 3. Не иметь образа результата

Цель отвечает на вопрос, зачем компании нужны изменения. Образ результата показывает, как должна выглядеть работа после них.

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

Что делать

До проектирования зафиксировать целевое состояние:

• какой результат создает процесс;
• кто и в каком виде его получает;
• какие действия должны измениться;
• какие роли и полномочия появятся;
• какие показатели должны улучшиться;
• какие проблемы должны перестать повторяться.

Образ результата должен быть понятен не только процессным аналитикам, но и владельцу, исполнителям и внутренним потребителям процесса.

Пример: Все согласны, что заказы нужно отгружать вовремя, но по-разному представляют решение. Продажи ждут новой учетной системы, производство — дополнительного оборудования, снабжение — увеличения запасов. Целевое состояние нужно описать через работу цепочки: срок подтверждается после проверки материалов и загрузки, а изменения заказа своевременно доходят до всех участников.

Ошибка 4. Не договариваться на стыке поставщика и потребителя

Большая часть потерь возникает не внутри функций, а между ними. Поставщик считает, что передал результат. А потребитель получает неполные данные, документ в неудобном формате или ресурс, который нельзя сразу использовать. 

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

Что делать

Для каждого значимого стыка определить:

• кто является поставщиком;
• кто является потребителем;
• что именно передается;
• в каком виде и к какому сроку;
• по каким критериям результат принимается;
• кто действует при отклонении.

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

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

Ошибка 5. Не назначать реального владельца процесса

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

Оба варианта могут не работать.

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

Что делать

Оценивать кандидата по четырем критериям:

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

Для сложных процессов часть оперативной работы можно передать менеджерам отдельных этапов. Но ответственность за итоговый результат при этом не должна размываться.

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

Ошибка 6. Проектировать только основной путь

Многие процессы описывают для идеальных условий. Но реальная работа постоянно отклоняется от нормы.

Что делать

Помимо основного маршрута определить критические варианты:

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

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

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

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

Ошибка 7. Работать без заинтересованности основного стейкхолдера

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

Что делать

Перед стартом проверить:

• признает ли стейкхолдер проблему;
• готов ли он участвовать в принятии решений;
• может ли выделить ресурсы;
• связан ли его результат с изменением процесса;
• готов ли он поддерживать кросс-функциональные договоренности.

Заинтересованность команды тоже важна, но она редко возникает сама по себе. Люди должны понимать, какую проблему они решают и что изменится в их работе.

Пример: Владелец процесса предлагает подтверждать клиенту срок только после проверки материалов и загрузки производства. Руководитель продаж возражает: дополнительная проверка может замедлить заключение сделки. Если руководитель — заказчик проекта не помогает согласовать общий приоритет, договоренность остается на бумаге. Его задача — поддержать изменения и помочь разрешить конфликт между показателями подразделений.

Ошибка 8. Описывать процессы без показателей

Схема показывает последовательность действий, но не объясняет, насколько хорошо работает процесс.

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

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

Что делать

До начала изменений зафиксировать базовые показатели. В зависимости от процесса это могут быть:

• срок;
• стоимость;
• трудоемкость;
• количество ошибок;
• объем возвратов и переделок;
• уровень брака;
• простой;
• расход дефицитного ресурса;
• соблюдение требований к результату.

После изменений измерения необходимо повторить по той же методике.

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

Ошибка 9. Отрывать процессы от систем, данных и стратегии

Процессная архитектура не существует отдельно от других элементов компании.

Процессы связаны с ИТ-системами, данными, подразделениями и целями компании. Если эти связи не учитывать, трудно заранее понять, к чему приведут изменения.

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

Что делать

Для каждого значимого процесса определить:

• какие системы поддерживают его операции;
• какие данные используются и передаются;
• какие подразделения и роли участвуют;
• какие процессы находятся выше и ниже по цепочке;
• какие стратегические цели он поддерживает;
• что произойдет при его остановке.

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

Другие распространенные ошибки

Кроме девяти основных, на практике часто встречаются и другие проблемы.

Выбор инструмента раньше методологии. Компания внедряет репозиторий или платформу, не определив, какие объекты, связи и правила в них будут использоваться.

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

Разные языки описания. Подразделения используют собственные термины, обозначения и уровни детализации, поэтому модели невозможно соединить.

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

Отсутствие практической проверки. Новые правила сразу распространяют на всю компанию, хотя они еще не были проверены на ограниченном контуре.

Недостаток обучения. Пользователи получают доступ к инструменту, но не понимают смысла архитектурных объектов и связей.

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

Отсутствие актуализации. Архитектуру воспринимают как разовый проект. Через некоторое время модели расходятся с реальной работой и перестают использоваться для принятия решений.

Как начать: практическая последовательность

Рабочая последовательность может выглядеть так.

1. Сформулировать бизнес-проблему. Определить, что именно не устраивает компанию и какой результат нужно улучшить.
2. Обеспечить поддержку руководителя — заказчика проекта. Согласовать приоритет задачи, необходимые ресурсы и порядок разрешения разногласий между подразделениями.
3. Обозначить общую картину процессов и выбрать участок для первого этапа. Учитывать связи с соседними процессами, но ограничить объем подробного анализа.
4. Назначить владельца и собрать команду. Проверить полномочия владельца, привлечь представителей участвующих функций и сотрудников, которые знают реальную работу.
5. Разобрать текущее состояние и зафиксировать показатели. Выяснить, как работа выполняется на практике, где возникают ожидание, ошибки и переделки.
6. Уточнить целевое состояние и критерии успеха. Согласовать, как должна работать цепочка после изменений и по каким показателям будет оцениваться результат.
7. Определить требования на стыках. Зафиксировать, кто, что, кому и к какому сроку передает, как результат принимается и кто действует при отклонении.
8. Спроектировать основной и критические альтернативные сценарии. Определить действия при сбоях, нехватке ресурсов и изменении условий.
9. Связать процессы с системами, данными и целями компании. Проверить, какие изменения нужны в информации, инструментах, ролях и полномочиях.
10. Проверить изменения на ограниченном участке. Повторить измерения по той же методике и оценить влияние на всю выбранную цепочку.
11. Закрепить работающий подход и организовать актуализацию. Определить, кто пересматривает модели при изменении процессов, систем или требований.

После проверки результатов подход можно распространять на следующие процессы.

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