Эта статья написана для владельцев бизнеса и руководителей, которые пока не до конца понимают, что такое процессное управление: как описывать процессы, чем управлять, зачем нужны модели AS-IS и TO-BE, какие показатели отслеживать, какие инструменты использовать на старте, а к каким переходить позже. В конце приведены практические шаблоны и краткая выжимка по PMBOK для управления внедрением как полноценным проектом.
- Что такое процесс — объясняю простыми словами
Процесс — это набор повторяющихся действий, которые преобразуют то, что мы получаем на входе (сырьё, информацию, запросы клиентов), в то, что нужно получить на выходе (услуги, продукты, решения), причём с заранее известным качеством, в определённые сроки и с понятной себестоимостью.
Любой процесс состоит из нескольких элементов:
Входы — что поступает в начале: заявка от клиента, бриф, исходные данные, файлы, договор.
Шаги — кто и что конкретно делает, какие действия выполняет, в каких системах работает.
Выходы — что должно получиться в итоге: готовый продукт, отчёт, письмо клиенту с решением.
Роли и зоны ответственности — кто отвечает за конечный результат. Важно, чтобы это был конкретный человек, а не размытое «все вместе».
Правила и критерии качества — как понять, что результат действительно соответствует ожиданиям.
Показатели эффективности — как мы измеряем скорость выполнения, затраты, качество и возможные риски.
Зачем вообще нужно управлять процессами? Чтобы было меньше хаоса в работе, чтобы сроки были предсказуемыми, чтобы можно было управлять себестоимостью, и чтобы стало понятно, где именно можно внедрить автоматизацию или применить искусственный интеллект с реальной пользой.
- Базовый принцип: сначала фиксируем AS-IS, затем проектируем TO-BE
AS-IS (как есть сейчас) — это честное описание того, как процесс работает в реальности. Кто что делает, где файлы теряются, куда уходит время, где образуются узкие места и очереди.
TO-BE (как должно быть) — это целевая модель процесса: более простая, быстрая, дешёвая, без лишних шагов, с автоматизацией и внедрением AI там, где это даёт измеримую выгоду.
Почему нельзя сразу начинать рисовать идеальный процесс?
Высокий риск того, что вы придумаете что-то в отрыве от реальности и не учтёте фактические ограничения и зависимости.
Команда не примет изменения, потому что будет говорить «у нас так не работает, вы не понимаете нашей специфики».
Вы можете ошибиться с приоритетами: автоматизируете что-то ненужное, а реальное узкое место останется.
Правильная последовательность выглядит так: за одну-две недели быстро зафиксировать текущее состояние AS-IS, найти те 20% шагов, которые создают 80% проблем, наметить быстрые улучшения и целевое состояние TO-BE, запустить пилотный проект, а потом масштабировать на всю компанию.
- С чего начать: простейшие инструменты для старта
Минимальный набор инструментов на начальном этапе:
MIRO, Mural или FigJam — чтобы набросать карту процесса в виде блок-схемы. Это визуально и понятно всем участникам.
Google Sheets или Excel — для создания списка шагов, ролей, соглашений по срокам (SLA), метрик и рисков.
Google Forms или Notion — чтобы быстро создать формы для сбора информации и чек-листы как временную «автоматизацию».
Стандартные операционные процедуры (SOP) — короткие инструкции на одну-две страницы о том, как делается работа. Нужны для обучения новых сотрудников.
Когда имеет смысл переходить к более серьёзным инструментам вроде BPMN и process mining?
BPMN (нотация моделирования бизнес-процессов) нужна, когда в процессе много развилок, согласований и интеграций, и важно однозначно описать логику. Также BPMN полезна, когда с одним и тем же процессом работают разные команды и им нужен единый язык.
Process mining нужен, когда у вас есть журналы событий из ваших систем (CRM, ERP, системы учёта заявок) и вы хотите увидеть реальный поток работ, понять, где происходят отклонения от стандарта, где возникают задержки.
- Как быстро описать процесс AS-IS за одну-две рабочие недели
Шаг 1. Определите границы процесса с помощью SIPOC
SIPOC — это простой шаблон из пяти элементов:
Suppliers (поставщики) — кто предоставляет входные данные: клиенты, отдел продаж, подрядчики.
Inputs (входы) — документы, данные, материалы, которые поступают в процесс.
Process (процесс) — от пяти до двенадцати ключевых шагов, описанных крупными блоками.
Outputs (выходы) — что получается в результате: готовая поставка, отчёт, активированная услуга.
Customers (клиенты) — кому это нужно: внешний клиент или внутреннее подразделение.
Важное правило: если на вашу карту не помещается двенадцать шагов, значит вы рисуете слишком детально. Укрупните описание. Детализацию можно вынести на уровень стандартных процедур.
Шаг 2. Пройдитесь по процессу «ногами»
Проведите от трёх до пяти коротких интервью длительностью 30-45 минут с людьми, которые участвуют в процессе.
Задавайте простые вопросы: что вы делаете, чем измеряете успех, что мешает работе, где теряется время?
Соберите примеры реальных артефактов: формы, письма, шаблоны, скрипты.
Шаг 3. Зафиксируйте роли и ответственность через матрицу RACI
RACI — это способ распределить ответственность:
R (Responsible) — тот, кто выполняет работу.
A (Accountable) — тот, кто отвечает за конечный результат. Это всегда один человек.
C (Consulted) — эксперты, с которыми консультируются в процессе.
I (Informed) — те, кого держат в курсе событий.
Создайте простую таблицу RACI по шагам процесса. У каждого шага должен быть ровно один человек с буквой A.
Шаг 4. Снимите текущие показатели
Скорость: Lead time (время от получения запроса до выдачи результата), Cycle time (время активной работы над задачей).
Качество: процент переделок, показатель First Pass Yield (доля работ, выполненных сразу правильно), количество дефектов на сто случаев.
Стоимость: человеко-часы умножить на ставку, добавить стоимость инструментов, учесть потери от брака и переделок.
Надёжность и риски: где чаще всего возникают проблемы, на каких этапах образуются задержки.
Шаг 5. Найдите узкие места — три-пять главных проблем
Признаки узких мест:
Образуются очереди, долгое ожидание согласований.
Много ручного копирования и вставки данных между системами.
Множество исключений и ручной обработки нестандартных случаев.
Один человек становится «бутылочным горлышком», через него проходит всё.
- Как спроектировать TO-BE: принципы и последовательность действий
Основные принципы проектирования:
Сначала удалите всё лишнее, только потом автоматизируйте. Это принцип бережливого производства (Lean).
Стандартизируйте процессы: создайте SOP, чек-листы, шаблоны.
Автоматизируйте простое (формы, интеграции без кода), а потом переходите к сложному (BPM-системы, роботизация, AI-агенты).
Встройте измерение: метрики должны считаться автоматически, без ручной работы.
Сделайте процесс видимым: доски со статусами задач, отслеживание SLA, автоматические уведомления.
Назначьте владельца процесса (Process Owner) с реальными полномочиями принимать решения.
Последовательность действий:
Получите быстрые результаты за две-четыре недели: уберите дублирование, создайте формы, настройте уведомления.
Спроектируйте стандарт: опишите входы, шаги, выходы, критерии готовности, распределите роли по RACI.
Определите точки применения AI: где есть тексты и повторяющиеся решения — там можно применить классификацию, извлечение информации, автоматическое резюмирование, автозаполнение, подсказки.
Посчитайте экономику: рассчитайте возврат инвестиций по формуле ROI = (выгода минус затраты) делённое на затраты. Начните с одного-двух процессов с большим объёмом или высокой стоимостью.
- Где и как применять AI в процессах — без лишнего хайпа
Типовые сценарии использования:
Обработка входящих обращений (почта, заявки): автоматический разбор, категоризация, извлечение реквизитов, автозаполнение CRM или ERP.
Работа с документами: генерация черновиков, согласование по чек-листам, сравнение версий, поиск несоответствий стандартам.
Техподдержка и Service Desk: ответы на основе базы знаний, рекомендации по решению проблем, составление пошаговых инструкций для оператора.
Продажи и маркетинг: автоматическое резюмирование звонков, извлечение следующих шагов из переговоров, сегментация клиентов, персонализация писем.
Контроль качества: проверка соответствия стандартам (SOP), выявление рисков, обнаружение аномалий.
Аналитика процессов: выявление повторяющихся причин задержек на основе анализа логов.
Правила безопасности при внедрении AI:
Чётко определите границы данных: какие поля можно передавать модели, а какие нельзя.
Человек в контуре (Human-in-the-loop): критически важные решения должны приниматься с подтверждением человеком.
Ведите логи: кто, что и когда сделал — всё должно отслеживаться.
Установите критерии качества: точность, полнота, порог уверенности модели, план действий при снижении качества.
- Базовый минимум по BPMN — без перегрузки информацией
BPMN стоит использовать в следующих случаях:
Когда в процессе много ветвлений и развилок (эксклюзивные и параллельные шлюзы).
Когда есть задачи, которые выполняют как люди, так и автоматические системы.
Когда важны события: таймеры, исключения, сообщения между системами.
Достаточно знать базовые элементы:
Задача (Task) и подпроцесс (Sub-process)
События начала и конца (Start Event, End Event)
Эксклюзивные и параллельные развилки (XOR и AND гейты)
Пулы и дорожки (Pools и Lanes) для разных ролей
Сообщения и таймеры
Этого набора хватает, чтобы все понимали процесс одинаково и не спорили о смыслах.
- Что такое process mining и когда он действительно нужен
Process mining — это анализ реальных следов событий из ваших IT-систем. Для анализа нужны три минимальных поля: идентификатор случая (Case ID), активность (Activity) и временная метка (Timestamp), плюс желательно информация о пользователе. Вы видите не то, как процесс задумывался, а как он происходит по факту: все варианты путей, задержки, узкие места, нарушения установленных сроков.
Что нужно для process mining:
Сырые логи событий из систем с минимум тремя полями: Case ID, Activity, Timestamp.
Согласованный словарь шагов: как статусы из систем соответствуют активностям в процессе.
Обеспечение приватности: обезличивание персональных данных, настройка прав доступа.
Когда process mining окупается:
Большие объёмы однотипных случаев — тысячи в месяц.
Вы боретесь с просрочками по SLA и не понимаете, где именно происходит сбой.
Нужно объективно проверить эффект от внедрённых изменений, сравнив ситуацию до и после.
- Метрики: стоимость, качество, риски, сроки
Стоимость:
Cost per case (стоимость одного случая): часы работы умножить на ставку, прибавить лицензии на 1000 случаев и потери от брака, разделить на количество случаев.
Возврат инвестиций в автоматизацию (Automation ROI): экономия в часах умножить на ставку и на объём, вычесть затраты на лицензии и внедрение, разделить на затраты.
Совокупная стоимость владения (TCO): владение инструментом за 12-24 месяца, включая лицензии, интеграции, поддержку.
Качество:
FPY (First Pass Yield) — доля случаев, выполненных правильно с первого раза, без переделок.
NPS или CSAT — удовлетворённость клиентов.
Defect rate — количество дефектов на 100 случаев с разбивкой по типам ошибок.
Риски:
Операционные риски: зависимость от одного эксперта, ручные обходы систем, теневые файлы и базы данных.
Риски соблюдения требований: нарушение сроков по регуляторным требованиям, неполные записи для аудита.
Технические риски: проблемы с интеграциями, устойчивость AI-решений, дрейф качества моделей со временем.
Сроки:
Lead time — полное время от получения заявки до выдачи результата.
Cycle time по каждому шагу — время активной работы.
Процент выполнения вовремя (процент On-time по SLA).
- Управление изменениями: как не сломать бизнес в процессе
Назначьте владельца процесса, который отвечает за результат и метрики, а не коллективно «собранием».
Регулярно и коротко коммуницируйте: что меняется, зачем, когда.
Обучайте людей: одностраничные инструкции SOP плюс короткие 10-минутные видеоролики «как делать».
Запустите пилот на две-четыре недели на ограниченной выборке с целевыми метриками.
Собирайте обратную связь через форму «Что тормозит? Что можно улучшить?»
Работайте инкрементами: не внедряйте всё сразу, каждые две-четыре недели должна быть видимая польза.
- Как вести внедрение правильно — выжимка из PMBOK простым языком
В методологии PMBOK внедрение рассматривается как проект со стадиями и областями управления. Возьмём только необходимый минимум, без излишнего академизма.
Жизненный цикл проекта:
Инициация: зачем мы это делаем (бизнес-цель), кто спонсор проекта, какие есть ограничения.
Планирование: что входит и не входит в проект (Scope), сроки, бюджет, риски, план коммуникаций.
Исполнение: делаем запланированную работу, управляем командой и поставщиками.
Мониторинг и контроль: сравниваем план с фактом, управляем изменениями.
Закрытие: подводим итоги, фиксируем извлечённые уроки, передаём процесс в операционную деятельность.
Ключевые области управления (упрощённый вариант):
Содержание (Scope): список процессов и их границы. Используйте WBS (иерархическую структуру работ).
Сроки (Schedule): дорожная карта с этапами — диагностика, AS-IS, TO-BE, пилот, масштабирование.
Стоимость (Cost): бюджет внедрения, лицензии, обучение. Прозрачный расчёт ROI.
Качество (Quality): критерии «готово или не готово», тест-кейсы, целевые метрики процесса.
Ресурсы (Resources): роли — владелец процесса, аналитик, архитектор, разработчик, эксперт предметной области.
Коммуникации (Communications): кому что и когда сообщаем, еженедельные обновления статуса.
Риски (Risk): реестр рисков, план реагирования — избежать, снизить, принять или переложить.
Закупки (Procurement): выбор платформ через тендер или сравнение, соглашения об уровне обслуживания с подрядчиками.
Заинтересованные стороны (Stakeholders): карта стейкхолдеров, их ожидания и влияние на проект.
Управление изменениями (Change Control):
Любая существенная правка должна проходить через заявку на изменение: что меняется, почему, как это влияет на время, стоимость и качество. Решение принимает спонсор или комитет по управлению изменениями.
Измерение прогресса:
Еженедельно: сравнение план-факт, короткие отчёты на одну-две страницы.
Демонстрация результатов каждые две-три недели (showcase).
Критерии выхода из пилотного этапа: метрики улучшены на заданную величину, риски приняты, пользователи обучены.
- Пошаговый план внедрения — консалтинговый шаблон
Кик-офф (одна неделя):
Определяем цели, границы проекта, список процессов-кандидатов, метрики успеха, состав команды.
Диагностика AS-IS (одна-две недели):
Создаём SIPOC, рисуем карту на MIRO из 10-12 шагов, составляем матрицу RACI, собираем метрики, формируем список топ-5 узких мест.
Быстрые победы (две-четыре недели):
Создаём формы, чек-листы, настраиваем автоматические письма и уведомления, убираем дублирование и ручной ввод данных.
Дизайн TO-BE (две-три недели):
Разрабатываем стандарт процесса (SOP), рисуем целевую карту (при необходимости в нотации BPMN), определяем точки применения AI, планируем интеграции.
Пилот (четыре-восемь недель):
Запускаем на одном подразделении или сегменте, отслеживаем метрики, опрашиваем пользователей.
Масштабирование (восемь-двенадцать недель):
Раскатываем на остальные команды, проводим обучение, устанавливаем регламент поддержки.
Операционная модель:
Назначаем владельца процесса, проводим ежемесячный пересмотр метрик, ведём бэклог улучшений, внедряем квартальные инкременты.
- Мини-гайд по артефактам — копируйте как шаблоны
13.1. Чек-лист AS-IS на одну страницу:
Назначение процесса и кто его «клиент».
Входы и выходы (модель SIPOC).
От восьми до двенадцати шагов на карте.
Роли (матрица RACI), владелец процесса (ФИО, полномочия).
Текущие метрики: lead time, cycle time, FPY, cost per case.
Топ-5 проблем и их влияние на бизнес.
13.2. Карта метрик в виде таблицы:
Метрика | Определение | Источник данных | Целевое значение | Порог тревоги | Частота измерения | Ответственный
13.3. Стандарт выполнения шага (SOP):
Цель шага, что поступает на входе, что должно получиться на выходе, критерии готовности, какой инструмент используется, кто выполняет, чек-лист «что проверить», частые ошибки.
13.4. План коммуникаций:
Аудитория | Сообщение | Формат | Частота | Ответственный
13.5. Реестр рисков:
Риск | Вероятность | Влияние | Владелец риска | План реагирования | Триггеры для мониторинга
13.6. Запрос на изменение (Change Request):
Что меняется, почему, сценарий «до и после», влияние на сроки, стоимость и качество, дата принятия решения.
- Примеры типовых улучшений по отраслям
Продажи B2B: единая форма для лида, автоматическая квалификация, SLA на время ответа, автоматическое создание сделки в CRM, шаблоны писем, резюмирование звонков с помощью AI.
Сервисная поддержка: классификация тикетов, база решений с подсказками, таймеры эскалации, контроль повторных обращений.
HR-рекрутинг: стандартизированное техническое задание на вакансию, автоматический парсинг резюме, вопросы для скрининга, слоты для интервью, единая система оценки кандидатов.
Финансы: чтение счетов с помощью AI, сверка реквизитов, маршрутизация на оплату, журнал для аудита.
Закупки: заявка, трёхстороннее сопоставление (заказ-поставка-счёт), контроль отклонений, отчёты.
- Как считать эффект — быстрый экономический калькулятор
Экономия времени: (минуты на случай до внедрения минус после) умножить на объём случаев и на почасовую ставку.
Снижение брака и переделок: (дефекты до минус дефекты после) умножить на стоимость одного дефекта.
Рост выручки (если применимо): увеличение конверсии умножить на средний чек и на объём.
Затраты: лицензии, интеграции, обучение, поддержка.
Возврат инвестиций за 12 месяцев = (Выгода минус Затраты) / Затраты.
Срок окупаемости (Payback) = Затраты / Ежемесячная выгода.
- Частые ошибки и как их избежать
Сразу рисуете идеальный процесс без анализа AS-IS — пропустите реальные ограничения и зависимости.
Автоматизируете плохой процесс — сначала уберите лишнее, потом автоматизируйте.
Нет владельца процесса — никто не следит за метриками, происходит откат к хаосу.
Слишком сложная нотация BPMN — команда не читает схемы, польза теряется.
Внедрение AI без правил — путаница с данными, непредсказуемое качество, риски для бизнеса.
Нет пилота — масштабируете сырое решение и теряете доверие команды.
Не измеряете эффект — спор идёт на уровне «нравится или не нравится», а не «выгодно или не выгодно».
- Глоссарий на ладони
AS-IS / TO-BE — текущая и целевая модель процесса.
SIPOC — поставщики, входы, процесс, выходы, клиенты.
RACI — матрица распределения ответственности.
SOP — стандартная операционная процедура.
Lead time / Cycle time — полное время выполнения / время активной работы.
FPY — доля случаев без переделки.
BPMN — нотация моделирования бизнес-процессов.
Process mining — анализ фактических логов процесса.
Owner (владелец процесса) — человек, отвечающий за результат и метрики.
- Быстрый старт за 30 дней — конспект
Неделя 1: кик-офф, SIPOC, карта AS-IS, снятие метрик, выявление топ-5 проблем.
Неделя 2: разработка стандартов (SOP), создание чек-листов и форм, устранение дублирования, первые автоматические действия.
Неделя 3: дизайн TO-BE, ролевая модель, определение точек применения AI (один-два паттерна), планирование пилота.
Неделя 4: запуск пилота, обучение команды, мониторинг метрик, подготовка витрины «до и после», решение о масштабировании.
- Что добавить из PMBOK в обязательном порядке
Спонсор и чёткие цели: формально назначенные, с измеримыми бизнес-результатами.
Иерархическая структура работ (WBS) и дорожная карта: ясная разбивка работ и контрольные точки.
Управление рисками: реестр рисков плюс план реагирования, пересмотр каждую неделю.
Регламент коммуникаций: расписание обновлений статуса и демонстраций результатов.
Дисциплина управления изменениями (Change control).
Извлечённые уроки: ретроспектива в конце пилота и после масштабирования.
- Готовые мини-шаблоны — скопируйте себе
SIPOC (одна таблица):
Поставщики | Входы | Процесс (8-12 шагов) | Выходы | Клиенты
RACI (фрагмент таблицы):
Шаг | R | A | C | I
Карточка метрики:
Название | Формула | Источник данных | Целевое значение | Порог тревоги | Ответственный | Частота измерения
Шаблон SOP для шага:
Цель | Вход | Выход | Критерии готовности | Инструмент | Роль | Чек-лист действий | Частые ошибки
Запрос на изменение (Change Request):
Описание изменения | Обоснование | Влияние (Scope/Time/Cost/Quality) | Риски | Решение | Дата
Итог
Первое — опишите AS-IS простыми инструментами вроде MIRO и обычных таблиц. Зафиксируйте метрики и выявите основные проблемы.
Второе — спроектируйте TO-BE. Удалите всё лишнее, стандартизируйте оставшееся, добавьте базовую автоматизацию и одну-две точки применения AI с понятными измеримыми метриками.
Третье — запустите пилотный проект. Измерьте эффект, обучите людей, закрепите владельца процесса с чёткими полномочиями.
Четвёртое — масштабируйте решение и введите операционное управление процессами. Регулярно пересматривайте метрики, ведите бэклог улучшений, проводите ежемесячные ревью.
Пятое — ведите всё внедрение как полноценный проект по принципам PMBOK. Установите цели, составьте план, управляйте рисками, наладьте коммуникации, внедрите дисциплину управления изменениями.
Главное — не пытайтесь сделать всё идеально сразу. Работайте итерациями, получайте быстрые результаты, учитесь на ходу и постепенно наращивайте зрелость процессного управления в компании. Начните с малого, но начните правильно.