Бизнес-процессы: нотификации и моделирование, что выбрать?
- Джимшер Челидзе
- 9 июн. 2022 г.
- 21 мин. чтения
Обновлено: 17 мая
Мы разобрали с Вами основные типы организационных структур, но есть еще одно ключевое направление – бизнес-процессы. Если орг. структура – скелет организации, то бизнес-процессы – центральная нервная система с заложенными рефлексами.
Возможно Вам кажется это все скучным, но на нашей практике есть одно простое правило – нет ничего хуже аргументов «это и так понятно», «это слишком просто». Они ничего хорошего не предвещают. Эти тезисы – предвестники хаоса, запущенных проблем
В целом в жизни встречается 2 крайности процессного управления - хаос и бюрократия
Содержание
Прежде чем прогрузиться в вопрос «а как описывать», сначала давайте ответим на вопрос: «А что такое бизнес-процессы?».
Бизнес-процесс – определенный алгоритм взаимосвязанных действий людей и ИТ-систем, который направлен на преобразование «сырья» в «продукт» или результат.
Например, бизнес-процесс закупки примерно включает следующие стадии: получение заявки – поиск поставщиков – сбор предложений – поставка материалов – передача заказчику. Но каждый этап также разбирается на отдельные бизнес-процессы. Поэтому надо понимать, что описание бизнес-процессов практически бесконечная задача, Вам необходимо будет выбрать уровень детализации, на котором скажете «все, хватит». И чем ниже уровень компетенций команды, тем детализированее нужно описание. Ну или надо обучать команду, но тогда нужно будет расти и вам, как руководителю. Умные кадры не потерпят обращения как с дураками.
Условно существует несколько подходов к описанию бизнес-процессов:
Подход, который позволяет описать на самом верхнем уровне ключевые направления деятельности компании и подразделений, показать взаимосвязи между ними. Здесь фокус на графическом отображении бизнес-процессов, создающих ценность для клиента.
То есть это некая «мастер» модель всей компании, чтобы дать понимание всей команде, как их работа влияет на всю компанию.
Правила построения модели процесса добавленной стоимости (VAD)
Для начала необходимо определить ключевые задачи компании или подразделения, которые характеризуют ее деятельность.
Далее выстраивается их логическая взаимосвязь
Определяются и указываются владелец и подразделение, отвечающие за процесс
Указываются ключевые документы, которые регулируют бизнес-процесс
Указывается дополнительная информация и необходимые ресурсы для выполнения бизнес-процесса
Каждому верхнеуровневому бизнес-процессу прописываются или прикрепляются ссылки на диаграммы (VAD или EPC) более низкого уровня.
Видео:
Полезные ссылки:
Подход к описанию бизнес-процессов, являющийся инструментом в бережливом производстве. Название отражает всю суть подхода, который фокусируется на:
Supplier (поставщиках) – человек или компания, которые поставляют ресурсы для выполнения бизнес-процесса (производство, деньги, материалы);
Input (входах) – ресурсы для бизнес-процесса: материалы, деньги, производственные мощности);
Process (процессах) – все те задачи, которые позволяют в результате работы бизнес-процесса преобразовать сырье в конечный продукт;
Output (выходах) – продукты деятельности бизнес-процесса;
Customer (заказчиках) – получатели услуги, те кто пользуется продуктом бизнес-процесса.
Алгоритм описания бизнес-процессов:
1. Определение заказчика бизнес-процесса;
2. Описание итогового продукта (выхода), который нужен заказчику;
3. 5-7 ключевых операций бизнес-процесса;
4. Определение необходимых ресурсов (входов) для бизнес-процесса;
5. Определение поставщиков этих ресурсов.
Видео:
Полезные ссылки:
Данный подход описывает бизнес-процессы в виде отдельных этапов/шагов процесса и событий, которые инициируют эти шаги, то есть получается структура «событие – функция – событие». Этот подход хорошо подходит для стандартизации бизнес-процессов и анализа потока документов и необходимой информации в рамках всего бизнес-процесса.
Основные элементы описания:
Событие – что-то, что создает необходимость действия.
Функция – это действие, для получение нужного результата, в ответ на событие.
Исполнители – те, кто реализуют функцию, в том числе кто утверждает, согласовывает и так далее.
Ресурсы – это все то, что необходимо для реализации функции: деньги, информационные системы или отдельные модули, документы, операционные риски.
В отличии от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.
Алгоритм описания:
Определяем, что у нас есть и чего мы хотим – граничные события.
Описываем промежуточные события, которые есть внутри этого процесса и какие необходимо выполнить задачи / реализовать функции
Добавляем всю необходимую информацию об исполнителях и ресурсах.
Анализ полноты и качества схемы, учитывает ли она все вариации и подпроцессы. При необходимости делаем дополнительные схемы для подпроцессов. Однако, тут мы рекомендуем всегда помнить простое правило – одна схема, один лист или экран.
Плюс подхода – возможность потом создать понятный регламент в виде текста или таблицы. Эта нотация довольно распространена, особенно в крупных организациях. Так как с одной стороны и стандартизует описание, а с другой стороны достаточно гибкая. Например, ее часто используют для настройки ERP-систем.
Полезные ссылки:
BPMN на сегодня некий стандарт де факто в описании бизнес-процессов с широким набором графических элементов для описания и моделирования. Если для рядовых пользователей и руководителей это может быть не самый удобный подход, то для бизнес-аналитиков это обязательный инструмент: описать в рамках этого подхода довольно большой процесс на 1 листе будет трудно, кроме того, подход довольно строг, однако здесь более высокая детализация и легче выявить локальные ошибки. Пример описания в этой нотации ниже.
Видео:
Полезные ссылки:
Нотации Flowchart используются для представления алгоритма выполнения процесса и позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. Нотации поддерживают декомпозицию на подпроцессы.
Различие между нотациями Процесс и Процедура в том, что дополнительно к графическим символам, применяемым в нотации Процесс, в нотации Процедура используются дорожки (Swim Lanes), обозначающие орг. единицы - исполнителей действий процесса. Это позволяет повысить наглядность диаграммы.
Видео:
Полезные ссылки:
IDEF — целое семейство методологий семейства ICAM (Integrated Computer-Aided Manufacturing). Исходно это семейство нотаций и методов моделирования разработаны для ВВС США, чтобы описывать рабочие процессы и проводить внедрение ИТ-систем. И если Вы общаетесь с ИТ-интеграторами или планируете проводить автоматизацию бизнес-процессов через ИТ-системы, то столкнетесь именно с этим подходом. Но естественно, если Вам удобно будет работать с этим подходом в повседневном режиме, то можно использовать ее и для других сценариев.
К семейству IDEFотносятся следующие стандарты:
IDEF0 — методология функционального моделирования (Function Modeling). Наиболее часто встречаемый подходDEF1 и IDEF1X - Информационное моделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь". Наиболее популярный подход в настоящее время
IDEF1 и IDEF1X - Информационное моделирование (Information and Data Modeling Method). В IDEF1X имеется ясный графический язык для описания объектов и отношений в приложениях, так называемый язык диаграмм "сущность-связь".
IDEF2 - Поведенческое моделирование (Simulation Modeling Method). В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри.
IDEF3 - Моделирование деятельности (Process Flow and Object Stale Description Capture Method). В методике детализируется ответ на вопрос не "что система делает", а "как система это делает".
IDEF4 - Объективно-ориентированное проектирование (Object-oriented Design Method). Модель предоставляет пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов.
IDEF5 - Систематизация объектов приложения (Ontology Description Capture Method). Модель представляет онтологической информации приложения в удобном для пользователя виде, Для этого используются символические обозначения (дескрипторы) объектов, их ассоциаций, ситуаций и схемный язык описания отношений классификации, "часть-целое", перехода и т. п. В методике имеются правила связывания объектов (термов) в предложения и аксиомы интерпретации термов.
IDEF6 - Использование рационального опыта проектирования (Design Rational Capture Method). Способствует предотвращению структурных ошибок.
IDEF8 - Взаимодействие человека и системы (Human-System Interaction Design). Модель предназначена для проектирования диалогов человека и технической системы.
IDEF9 - Учет условий и ограничений (Business Constraint Discovery). Модель предназначена для анализа имеющихся условий и ограничений (в том числе физических, юридических, политических) и их влияния на принимаемые решения в процессе реинжиниринга.
IDEF14 - Моделирование вычислительных сетей (Network Design). Модель предназначена для представления и анализа данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.
Полезные ссылки
Видео
Унифицированный язык моделирования (UML) - еще один подход моделирования процессов, который активно используется в ИТ. Это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
В языке UML есть 12 диаграмм, обуславливающих статистическую, поведенческую и физическую деятельность компонентов систем. Наиболее доступные и актуальные в настоящее время:
Диаграмма прецедентов (Use-case diagram). В основе — Actor (исполнитель), который устанавливает логические связи между ролями и прецедентами и Use case (сам прецедент), демонстрирующий какой именно процесс исполняется.
Диаграмма классов (Class diagram) представляет собой набор статических и декларативных элементов модели, имеющие общие атрибуты и операции. Диаграмма имеет наиболее полное и развернутое описание связей в программном коде, функциональности и информации об отдельных классах.
Диаграмма активностей (Activity diagram) отображает динамические аспекты поведения и общее представление о работе системы в формате блок-схемы. Диаграмма необходима для описания бизнес-процессов, взаимодействия нескольких систем, логики процедур и потоков работ, особенно при переходе от одной деятельности к другой.
Диаграмма последовательности (Sequence diagram) описывает поведенческие аспекты системы, вид сообщений и уточняет прецедентов. Необходима для отображения взаимодействия объектов в динамике и во времени, подразумевает обмен сообщениями в рамках конкретного сценария.
Диаграмма развёртывания (Deployment diagram) отображает графическое представление инфраструктуры, а именно распределение компонентов системы по узлам и маршруты их соединений. Диаграмма организовывает компоненты и решает второстепенные задачи, связанные с определенным аспектом бизнес-процесса.
Полезные ссылки:
Видео
Один из инструментов бережливого производства, наряду с SIPOC. Также Value Streams являются основополагающим компонентом SAFe® (Scaled Agile Framework®) и бывают двух типов: разработческие (Development Value Stream, DVS) и операционные (Operational Value Stream, OVS).
Value Stream Mapping — это инструмент, который визуализирует процесс превращения сырья в готовую продукцию, отпускаемую потребителям. Его объекты — материальные и информационные потоки ресурсов, а также время.
Создание Value Stream Mapping делится на три блока:
Производственный или процессный поток — традиционная блок-схема, в которой слева направо фиксируется путь создания ценности начиная закупкой сырья и заканчивая отгрузкой продукции. Если кроме основного процесса существуют дополнительные или вспомогательные, они наносятся под основным. Таким образом основные задачи отделяется от второстепенных.
Информационный или коммуникационный поток — в верхней части карты потока создания ценности стрелками изображаются потоки информации, которые происходят параллельно с производством. Учитывается и формальный и неформальный обмен данными. Информационные потоки наносятся на карту в свободной форме, так, как они протекают в действительности.
Timeline и расстояния — линии, которые рисуются в нижней части карты. Линия времени делится на верхнюю и нижнюю части. Сверху отображается lead time — время ожидания. Снизу наносится продолжительность цикла. Под линией времени может находиться еще одна линия, в самом низу, показывает расстояния, по которым продукт или персонал движутся внутри процесса.
Упрощенный алгоритм работы:
Шаг 1. Выбор процесса для систематизации потока ценности (подготовительный)
Шаг 2. Символы Value Stream Mapping
Шаг 3. Определение границ процесса
Шаг 4. Шаги процесса
Шаг 5. Добавление информационных потоков на карту
Шаг 6. Добавление данных о каждом шаге процесса
Шаг 7. Подсчет запасов
Шаг 8. Добавление хронологии процесса — Timeline
Шаг 9. Карта будущего состояния
Шаг 10. План для внедрения улучшений
Полезные ссылки:
Видео
Если Вы начинаете выстраивать процессное управление, то надо понимать, а какие вообще процессы могут быть в организации?
Классификация первая
Согласно это классификации существует 3вида процессов.
Создающие стоимость / производственные
Основные производственные процессы, которые создают ценность для конечного потребителя и влияющие на стоимость услуг, доход: продажа, производство и т.д.
Их эффективность определяет эффективность компании в целом.
Управленческие и контролирующие
Процессы, связанные со стратегическим, тактическим и оперативным управлением. В том числе подходы принятию управленческих решений.
Например, разработка стратегии, планирование производства , контроль и измерение результатов деятельности, финансовый учет и планирование, управление проектами и т.д.
Поддерживающие
Процессы, обеспечивающие выполнение создающих ценность процессов: найм персонала, его обучение и адаптация; обслуживание оборудования и ремонты; материально-техническое обеспечение и закупки; ИТ-поддержка.
Могут подразделяться на обеспечивающие, сервисные, вспомогательные и т.д. Поддерживающие бизнес-процессы связаны с определенными затратами, и чем эффективнее они протекают, тем меньше расходов несет компания.
Классификация вторая
Процессы производства и операционные процессы
Эти процессы связаны с производством товаров или предоставлением услуг. Они включают планирование, закупку ресурсов, производство, контроль качества и доставку конечного продукта или услуги. Процессы производства и операционные процессы направлены на оптимизацию производительности, снижение издержек и улучшение качества продукции или услуги.
Процессы управления персоналом
Эти процессы связаны с управлением человеческими ресурсами организации. Они включают наём, обучение, развитие, оценку сотрудников, управление производительностью, мотивацию и удержание персонала. Процессы управления персоналом направлены на создание эффективных команд, развитие потенциала сотрудников и обеспечение высокого уровня работоспособности и удовлетворённости персонала.
Процессы маркетинга и продаж
Эти процессы связаны с позиционированием продуктов или услуг на рынке, привлечением клиентов, разработкой маркетинговых стратегий, продвижением и реализацией продуктов или услуг. Процессы маркетинга и продаж направлены на удовлетворение потребностей клиентов, увеличение объёма продаж и установление долгосрочных отношений с клиентами.
Процессы финансового управления
Эти процессы связаны с управлением финансами и ресурсами организации. Они включают бюджетирование, финансовый анализ, управление инвестициями, учёт и отчётность. Процессы финансового управления направлены на обеспечение финансовой устойчивости, эффективного использования ресурсов и принятие обоснованных финансовых решений.
Процессы управления качеством
Эти процессы связаны с обеспечением высокого уровня качества продукции или услуги. Они включают планирование качества, контроль качества, анализ данных, устранение несоответствий и постоянное улучшение. Процессы управления качеством направлены на удовлетворение требований клиентов, минимизацию брака, повышение надёжности и укрепление репутации организации.
Резюме
То есть, Вам надо и описывать как устроены эти процессы, и проектировать будущее состояние исходя из этих классификаций. Отличный помощник для выстраивания процессной деятельности - ISO 9001.
Прежде чем описывать отдельные процессы, нужно понять, что именно описывать. Для этого создаётся реестр процессов — единый список всех бизнес-процессов компании с базовой атрибутикой по каждому.
Реестр — это не схема и не регламент. Это управленческий инструмент: он отвечает на вопросы «что у нас вообще есть», «кто за что отвечает» и «что уже описано, а что нет».
Когда нужен реестр:
Компания переходит от хаотичного описания отдельных процессов к системной работе
Готовится автоматизация или внедрение ERP/BPM-системы
Нужно расставить приоритеты: что описывать в первую очередь
Проводится аудит или сертификация (ISO 9001 и др.)
Минимальный состав реестра процессов:
Поле | Зачем нужно |
ID процесса | Уникальный идентификатор, нужен для связки с документами, задачами, ИТ-системами |
Название процесса | Формулировка в виде «Глагол + объект»: «Управление закупками МТР», «Подбор персонала» |
Уровень (1–4) | Позволяет сразу видеть иерархию и не путать стратегические процессы с операционными |
Вид процесса | Создающий стоимость / Управленческий / Поддерживающий |
Владелец процесса | Конкретный человек (не отдел), отвечающий за результат |
Менеджер процесса | Кто обеспечивает ежедневное исполнение |
ИТ-система | Какая система автоматизирует этот процесс или должна автоматизировать |
Нотация описания | Какой метод используется: Flow Chart, BPMN, EPC и т.д. |
Статус описания | Описан / В разработке / Требует актуализации / Не описан |
Приоритет | Высокий / Средний / Низкий — для очерёдности работ |
KPI / Метрика | Ключевой показатель эффективности процесса |
Регламент / Документ | Ссылка на действующий нормативный документ |
Дата актуализации | Когда последний раз пересматривался |
Скачать шаблон реестра процессов с примерами заполнения:
Рекомендации по ведению реестра:
Начинайте с 1–2 уровней. 10–20 строк с ключевыми процессами лучше, чем 200 строк, которые никто не поддерживает
Реестр — живой документ. Раз в квартал проверяйте: изменились ли процессы, актуальны ли владельцы
Добавляйте только те процессы, которые вы готовы реально описывать и поддерживать. Строчка в реестре без владельца создаёт иллюзию порядка, не более
Еще один вопрос, который будет возникать при запуске процессной деятельности - количество уровней процессов. Как правило, выделяют 3-5 уровней процессов.
Мы рекомендуем следующую градацию
1 уровень - общий
Общие описание деятельности компания. VAD-схема работы всей организации. Как и организационная структура позволяет увидеть общую картину организации.
2 уровень - стратегический
Внешние процессы, нацелены на решение стратегических задач предприятия, в них могут участвовать несколько подразделений. Так называемые сквозные процессы. Например, распределение сырья и материалов по производственным подразделениям компании. планирование бюджета на год, разработка стратегии, планирование портфеля проектов, управление продуктами и их развитие, принятие стратегических решений.
3 уровень – тактический
Тактические процессы достигать тактических целей. Планирование ресурсов и плана производства на месяц, управление проектами, контроль качества, схема приема заказа и запуска в производство.
4уровень – операционный
На этом уровне выполняются отдельные задачи и операции операции: прием заявок, расчет КП, передача в производство, настройка рабочего места нового сотрудника и т.д.
Резюме
Прежде чем заниматься операционными процессами, необходимо пройти верхние уровни - описать общую схему организации, также полезно описать организационную структуру, процессы верхнего уровня. И только после этого уже идти к тактике и описанию отдельных операций. Не надо спешить и сразу погружаться в детали. Операционный уровень нужно описывать в первую очередь для критичных и высокорискованных операций.
Описать процесс — необходимо. Но недостаточно. Процессное управление работает только тогда, когда у каждого процесса есть метрики: иначе непонятно, улучшился он или ухудшился, и зачем вообще его описывали.
Прежде чем выбирать конкретные показатели — важно понять, каким инструментом измерять: KPI, OKR или системой сбалансированных показателей (BSC). Это разные инструменты для разных задач, и в контексте процессного управления они используются по-разному. Подробный разбор каждого инструмента — в нашей статье OKR vs KPI →. Здесь разберём, как они применяются именно к процессам.
KPI процессов: измеряем стабильную операционку
KPI (Key Performance Indicators) — основной инструмент измерения бизнес-процессов. Ключевая логика: KPI ставятся на уже отлаженные, стабильно работающие процессы и должны выполняться на 100%. Если KPI не выполнен — значит, что-то в процессе нарушено, и это сигнал к разбору причин.
Существует четыре типа подходов к определению KPI процесса:
По затратам — сколько ресурсов потрачено на выполнение процесса. Например: стоимость обработки одной заявки на закупку, трудозатраты на закрытие одного инцидента.
По эффективности — соотношение результата к затраченным ресурсам. Например: выручка на одного сотрудника отдела продаж, количество закрытых заявок на одного специалиста Service Desk в день.
По результатам / производительности — выполнение плана. Это самый распространённый тип: % выполнения плана производства, количество обработанных заказов за период, объём выпущенной продукции.
По функционированию — соответствие фактического выполнения процесса требуемому алгоритму. Например: своевременность выплаты заработной платы (да/нет), среднее время прохождения счёта от поступления до оплаты, % заявок, обработанных в рамках регламентного срока.
💡 Оптимальное количество KPI на один процесс — не более 3–5. Больше — теряется фокус, никто реально не следит ни за чем. Количество KPI в компании в целом соответствует количеству процессов, которые вы отслеживаете.
Базовые группы метрик для большинства процессов:
Время:
Cycle Time — от триггера до результата (например, от заявки на закупку до поступления МТР на склад)
Lead Time — полное время с учётом ожидания, очередей и согласований
Processing Time — только активная работа, без ожиданий
Качество:
Процент дефектов / переделок — доля случаев, когда результат пришлось переделывать
First Pass Yield (FPY) — доля случаев, когда процесс выполнен правильно с первого раза
Количество жалоб / претензий — внутренних или от клиентов
Производительность:
Throughput — количество завершённых экземпляров процесса за период
Загрузка участников — доля рабочего времени на данный процесс
Стоимость:
Стоимость одного экземпляра процесса — ФОТ + ИТ + накладные на единицу результата
Стоимость ошибки / переделки — сколько стоит один сбой
Автоматизация:
Степень автоматизации — доля шагов без ручного участия человека
Экономия трудозатрат после автоматизации — в часах или рублях
OKR процессов: измеряем изменения и трансформацию
OKR (Objectives and Key Results) — инструмент не для стабильных процессов, а для их изменения и улучшения. Если KPI говорит «процесс работает нормально», то OKR отвечает на вопрос «как сделать процесс значительно лучше».
Принципиальное отличие в контексте процессов:
KPI процесса | OKR по процессу | |
Для чего | Отслеживать стабильную работу | Управлять трансформацией, улучшением |
Целевой результат | 100% выполнение | 70% уже считается прорывом |
Периодичность | Ежемесячно / еженедельно | Квартал / полугодие |
Связь с премией | Ежемесячная / квартальная | Квартальный / полугодовой бонус |
Пример | Срок закупки ≤ 15 дней — выполнен/не выполнен | Сократить цикл закупки с 30 до 10 дней за квартал |
Практическое правило: KPI — для процессов, которые уже описаны и стабилизированы. OKR — для процессов, которые вы активно оптимизируете или трансформируете. Например, если вы внедряете электронный документооборот и хотите перевести 100% заявок в цифровой вид — это OKR. Когда перешли и система стабилизировалась — превращается в KPI («доля электронных заявок ≥ 95%»).
💡 OKR нельзя привязывать к регулярной ежемесячной премии — это демотивирует. OKR — про амбиции и рост, KPI — про операционную стабильность. Как совмещать — подробно в статье OKR vs KPI →
BSC: откуда брать KPI для процессов на уровне компании
Если вам нужно выстроить систему метрик не для одного процесса, а для всей компании — помогает система сбалансированных показателей (BSC, Balanced Scorecard). Она задаёт четыре перспективы, в которых нужно выбирать метрики:
Финансы — каковы наши финансовые цели? (выручка, прибыль, затраты)
Клиенты — как нас оценивают клиенты? (NPS, удовлетворённость, удержание)
Внутренние бизнес-процессы — в каких процессах мы должны преуспеть, чтобы удовлетворить клиентов и достичь финансовых целей?
Обучение и рост — какие компетенции и ресурсы нужны, чтобы процессы работали хорошо?
Перспектива «Внутренние бизнес-процессы» в BSC — это прямой мост между стратегией компании и процессным управлением. Именно здесь выбираются те процессы, которые критичны для достижения стратегических целей, и именно для них в первую очередь нужны паспорта, владельцы и KPI.
Связь BSC с реестром процессов:
Стратегическая цель компании
↓
Перспектива BSC «Внутренние процессы»
↓
Приоритетные процессы в реестре (уровень 2–3, высокий приоритет)
↓
KPI в паспорте процесса
↓
Оперативный мониторинг владельцем процесса
Итоговая логика выбора инструмента измерения
Ситуация | Инструмент | Логика |
Процесс описан, стабильно работает, нужно мониторить | KPI | Измеряем регулярно, цель — 100% |
Процесс оптимизируется / автоматизируется | OKR | Амбициозная цель на квартал, 70% = успех |
Нужно выбрать, какие процессы KPI важнее всего | BSC | Приоритизируем через стратегические перспективы |
Процесс нестабильный, хаотичный | Сначала описать и стабилизировать | KPI ставить не на что — сначала AS-IS анализ |
Где брать данные для метрик:
ИТ-системы (ERP, BPM, CRM, ITSM) — основной источник при автоматизированных процессах
Журналы и реестры — для неавтоматизированных процессов
Опросы участников и клиентов — для качественных показателей (NPS, удовлетворённость)
Аудиты и контрольные проверки — для compliance-метрик
Подробнее о том, как выбирать между KPI и OKR, избегать типовых ошибок метрик и выстраивать мотивационную систему — в статье OKR vs KPI →
Если реестр — это каталог всех процессов, то паспорт процесса — это описание одного конкретного процесса в структурированном виде. Паспорт прикрепляется к схеме (нотации) и содержит всё, что нужно знать участникам, руководителям и ИТ-команде.
Паспорт отвечает на вопросы: зачем этот процесс существует, кто за него отвечает, как понять что он работает хорошо, и что нужно для его выполнения.
Структура паспорта процесса:
Блок 1. Идентификация
Код и название процесса
Уровень и вид
Версия и дата актуализации
Связь с вышестоящим и дочерними процессами
Блок 2. Цель и границы
Цель процесса: что он производит и для кого
Триггер / вход: что запускает процесс
Результат / выход: что считается завершением
Начальное и завершающее события
Блок 3. Роли и ответственность
Владелец, менеджер, исполнители, архитектор, аудитор, ИТ-владелец (подробнее — в разделе «Роли в процессном управлении»)
Блок 4. Ресурсы и инструменты
ИТ-системы, используемые в процессе
Регламентирующие документы
Нотация и ссылка на файл со схемой
Блок 5. KPI и метрики
Название метрики, формула расчёта, целевое значение, периодичность измерения
Блок 6. История изменений
Версия, дата, автор, суть изменений
Скачать шаблон паспорта процесса с примером заполнения (процесс «Управление закупками МТР»):
Практические советы:
Паспорт и схема хранятся вместе — в одной папке или одном файле. Схема без паспорта — просто картинка
Версионирование обязательно. Процессы меняются, и надо понимать, что изменилось и когда
Не нужно заполнять все поля сразу. Начните с идентификации, цели, ролей и одного KPI — этого уже достаточно для первой версии
Одна из самых частых ошибок при запуске процессного управления — описали процессы, нарисовали схемы, положили в папку и... забыли. Процесс остается живым только тогда, когда за него кто-то отвечает. Поэтому в реестр процессов и в каждое описание процесса важно сразу закладывать роли.
Ниже — ключевые роли, которые стоит выделять как в общем реестре процессов компании, так и в паспорте/описании отдельного процесса.
Владелец процесса (Process Owner)
Кто это. Руководитель, который несёт сквозную ответственность за результат процесса — от входа до выхода — вне зависимости от того, сколько подразделений в нём участвует.
Зона ответственности:
Определяет цели и KPI процесса
Инициирует изменения и оптимизацию
Согласовывает ресурсы и приоритеты
Несёт ответственность перед руководством за метрики процесса
Важно: владелец процесса и руководитель подразделения — не одно и то же. Процесс «Закупка» может принадлежать коммерческому директору, хотя в нём участвуют 3–4 отдела. Это особенно актуально для сквозных (end-to-end) процессов.
В реестре процессов: ФИО, должность, подразделение.
Менеджер / Куратор процесса (Process Manager)
Кто это. Операционный управляющий процессом — тот, кто обеспечивает его ежедневное исполнение в соответствии с описанием.
Зона ответственности:
Контролирует соблюдение регламентов и процедур
Выявляет отклонения и эскалирует проблемы владельцу
Организует обучение участников процесса
Ведёт журнал изменений и инцидентов
Отличие от владельца: владелец отвечает «за что», менеджер — «за как». В небольших компаниях или несложных процессах это может быть одна роль.
В реестре процессов: ФИО, должность, контакт.
Исполнитель процесса (Process Participant)
Кто это. Сотрудник или система, выполняющие конкретные шаги / функции внутри процесса.
Зона ответственности:
Выполняет закреплённые операции в соответствии с регламентом
Фиксирует результаты (в системе, журнале, документе)
Сообщает менеджеру об отклонениях и сбоях
В описании процесса: указывается на каждом шаге (дорожка swim lane, колонка «Исполнитель» в таблице).
💡 Один шаг процесса = один ответственный исполнитель. Если вписано «отдел» — это размытая ответственность, ведущая к хаосу.
Архитектор процессов / Бизнес-аналитик (Process Architect)
Кто это. Специалист, который моделирует, документирует и оптимизирует процессы. Может быть штатным или привлекаться под проект.
Зона ответственности:
Разработка и актуализация описаний процессов (нотации, регламенты)
Ведение реестра процессов и базы знаний
Проведение AS-IS / TO-BE анализа
Поддержка автоматизации: постановка задач ИТ на основе описания процессов
В реестре процессов: фиксируется как «Ответственный за описание» или «Автор модели».
Аудитор / Контролёр качества процесса (Process Auditor / Quality Controller)
Кто это. Роль, которая проверяет соответствие фактического исполнения процесса его описанию и заданным стандартам качества.
Зона ответственности:
Плановые и внеплановые проверки исполнения процессов
Сбор и анализ метрик (время цикла, процент отклонений, NPS и т.п.)
Формирование отчётов для владельца процесса и менеджмента
Инициирование корректирующих действий
Контекст: в крупных компаниях и промышленных холдингах эта роль обычно закреплена за Службой внутреннего контроля, ОКК или отделом процессного управления / BPM-офисом.
Спонсор процесса (Process Sponsor)
Кто это. Топ-менеджер или член правления, в зоне стратегических интересов которого находится данный процесс. Актуально прежде всего для сквозных и стратегически значимых процессов.
Зона ответственности:
Выделяет ресурсы (бюджет, люди, приоритеты) для развития процесса
Снимает организационные барьеры между подразделениями
Принимает ключевые решения при кардинальных изменениях или конфликтах
В реестре процессов: фиксируется для процессов 1–2 уровня (общий и стратегический).
ИТ-владелец процесса / Системный аналитик (IT Process Owner / System Analyst)
Кто это. Сотрудник ИТ-дирекции, ответственный за ИТ-поддержку процесса — системы, данные, интеграции.
Зона ответственности:
Обеспечивает работоспособность ИТ-систем, поддерживающих процесс
Реализует ИТ-изменения по запросу владельца/менеджера процесса
Ведёт архитектуру данных и интеграций в контексте процесса
Контекст: особенно важна эта роль при автоматизации и цифровизации процессов — именно стыковка бизнес-владельца и ИТ-владельца определяет успех внедрения ERP, BPM-систем и т.п.
Итоговая таблица ролей: что выделять в реестре и описании процессов
Роль | Реестр процессов | Описание процесса | Уровень процессов |
Владелец процесса | ✅ обязательно | ✅ в шапке | 1–3 уровень |
Менеджер процесса | ✅ для крупных процессов | ✅ в шапке | 2–4 уровень |
Исполнитель | — | ✅ на каждом шаге | 3–4 уровень |
Архитектор / бизнес-аналитик | ✅ как «автор описания» | ✅ в служебной части | все уровни |
Аудитор / контролёр качества | ✅ для регулируемых процессов | по необходимости | 2–3 уровень |
Спонсор | ✅ для стратегических | — | 1–2 уровень |
ИТ-владелец | ✅ при автоматизации | по необходимости | 2–4 уровень |
Рекомендации по внедрению ролей
Начните с реестра процессов. Для каждого процесса достаточно трёх ролей на старте: Владелец, Менеджер, Архитектор/Аналитик. Остальные добавляйте по мере зрелости.
Один процесс — один владелец. Если назначили двоих — считайте, что нет никого. Это не совместное владение, это зона безответственности.
Разделяйте роль и должность. Один человек может совмещать несколько ролей (особенно в небольших командах), но роли должны быть явно зафиксированы — это убирает «серые зоны» при конфликтах и аудитах.
Фиксируйте роли в шапке паспорта процесса. Стандартный минимум шапки: название процесса → уровень → владелец → менеджер → исполнители → ИТ-система → дата актуализации → автор описания.
При цифровизации ИТ-владелец — обязателен. Отсутствие этой роли — одна из топ-причин провалов автоматизации: процесс описан, но ИТ-система его не поддерживает, потому что никто не поставил задачу.
Ниже — наиболее частые ошибки, которые встречаются в практике. Большинство из них не технические, а управленческие.
1. Описание ради описания
Процессы описаны, схемы нарисованы, папка создана — и на этом всё. Нет метрик, нет владельцев, нет плана использования. Через полгода описания устаревают и становятся артефактами прошлого. Решение: прежде чем описывать процесс, ответьте на вопрос «Зачем? Что изменится после описания?»
2. Размытое владение
Назначили двух совладельцев, или написали «Отдел МТО» вместо конкретного человека. Итог — при любой проблеме ответственный неясен. Правило одно: один процесс — один владелец, конкретный человек с именем и фамилией.
3. Один раз описали — больше не обновляли
Процессы меняются: пришли новые сотрудники, внедрили новую систему, изменилось законодательство. Если описание не обновляется — оно вводит в заблуждение, а не помогает. Минимум раз в год нужен пересмотр; для высокоприоритетных процессов — раз в квартал.
4. Слишком детальное описание всего подряд
Команда тратит месяцы на описание каждого шага каждого процесса, включая то, что итак понятно всем опытным сотрудникам. Ресурсы заканчиваются, а реальной пользы мало. Описывайте то, что несёт риск, где есть ошибки и переделки, где часто меняются сотрудники.
5. Схема понятна только тому, кто её рисовал
Бизнес-аналитик нарисовал подробную BPMN-схему на 3 листа, показал руководителю — тот кивнул. Сотрудники открыли файл, закрыли и пошли работать «как всегда». Всегда проверяйте: может ли новый сотрудник разобраться в схеме без пояснений?
6. Автоматизация хаоса
Самая дорогостоящая ошибка: процесс сломан, но вместо того чтобы починить его, его автоматизируют в таком виде. ERP-система исправно воспроизводит неэффективную последовательность действий, только теперь это стоит в 10 раз дороже. Правило: сначала опишите процесс, оптимизируйте, потом автоматизируйте. Никак не наоборот.
7. Излишняя детализация нижних уровней без верхнего контекста
Команда сразу бросается описывать операционные процессы (уровень 4), не имея верхнеуровневой VAD-схемы. Результат: 50 подробных регламентов, которые не стыкуются между собой, и никто не понимает, как они связаны в общей системе компании.
Какую же выгоду получает бизнес, от работы с процессами?
Ну а если вы дочитали эту статью, то вероятнее всего у Вас в голове вопрос: "А какую нотацию то выбрать? Какая лучше?" Ответ довольно простой - никакая. Нужно выбирать нотацию под задачу и команду. Главный критерий - чтобы было понятно. Нужно понять, кто будет пользоваться Вашей схемой, каков уровень компетенций этих людей. Если Вы молодая команда / руководитель, то начните с "высокоуровневных" нотаций, например с VAD, VSM. Так Вы поймете, как в целом работает Ваша команда. Далее, как показывает практика, хорошо работает Flow Charting в нотации Процесс. Она проста и подходит для управления отдельном процессом. Также отличный вариант нотация Процедура в этом же подходе. Для рабочего персонала в нашей практике хорошо работает обыкновенная блок схема.
При этом наиболее типовая ошибка – рисование огромных карт. Это неправильно. Никто не будет смотреть на простыни. Выбирайте «кусок» так, чтобы он помещался на 1 экран или лист А4.
И как мы говорили ранее - думайте о том кто будет работать с этим описанием, он должен понимать описание. Поэтому можно и отступать от строгих нотаций. Вот пример ниже - описание в виде простой блок схемы и пояснения, но этого было достаточно для тех, кто должен был с ними работать, а это уже позволило привести описание того что на бумаге, к тому что в жизни.
Также пример описания работы с браком
Еще один пример - адаптация нотации Процесс
Также надо понимать, что если распечатать 1 процесс на 100 страницах, люди попросту запутаются. Да, в наш век цифры многое всё ещё приходится печатать, ведь кто-то до сих пор плохо воспринимает мониторы, это надо учитывать. Во-вторых, далеко не у всех есть хорошие большие мониторы или их связки. А в цифровизации надо думать об удобстве тех, кто в итоге всё это использует.
Для задач же бизнес-анализа и глубокого погружения уже необходимо использовать BPMN 2.0 или EPC, для проектирования ИТ-систем - IDEF.
Еще одно правило - думайте о том, какая культура в вашей компании
Преимущество стартапов ‒ в высокой гибкости и нацеленности на результат. При этом из-за тотального отказа от формализации возникают и большие проблемы с эффективностью. В больших компаниях, наоборот, стоит проблема излишней бюрократизации, которая убивает производительность.
Кроме того, чем Вы более зрелая организация, чем больше можете выделить ресурсы, тем более сложную комбинацию нотаций и более детализированное описание можете использовать. Если Вы небольшая команда, где ограничены ресурсы, и изменения довольно частые, то Вы просто утоните в этих описаниях
Итоговый список рекомендаций:
Начинать работу с процессами надо с того момента, когда вы нашли свой продукт и покупателя, начали продавать на постоянной основе, и вас больше 10-15 человек
Изначально сделайте VAD схему по всей компании и подготовьте реестр процессов с указанием владельца, а также участников
Затем воспользуйтесь продуктовым управлением и теорией ограничения систем для выбора приоритетных бизнес-процессов
Также важно описание тех бизнес-процессов, которые стабильны и являются лучшей практикой для остальных. Или же, наоборот, полезно описание проблемных бизнес-процессов
Не надо описывать каждый бизнес-процесс. Только те задачи, которые либо типовые, либо несут риски для бизнеса
Начните описывать процессы с понятных именно вам подходов и учетом того, кто ими будет пользоваться
Описывайте бизнес-процессы так, чтобы они умещались на одном листе А4
Когда принимаете нового сотрудника, то через 2 месяца спросите его о том, какие процессы показались слишком трудными и каких не хватало, н
Полезные материалы
Полезные ссылки:
