Разработка бизнес процессов
Содержание
Разработка бизнес процессов — о том, как разрабатывать и описывать бизнес-процессы на предприятии: от границ и этапов работы до согласования с участниками и подготовки к регламентам. Мы сознательно не повторяем справочник по символам BPMN — для нотации и чтения схем есть отдельный материал. Здесь фокус на порядке работ, который снижает риск «красивой схемы», которую отделы не признают.
Зачем нужна разработка бизнес процессов
Схема или текстовое описание процесса решают не «учебные», а управленческие задачи. В практике Rezolix и в отраслевых методиках их сводят к нескольким результатам:
- прозрачность — видно, как связаны отделы, где дублируются функции и где теряется время;
- единые правила — один и тот же процесс выполняется предсказуемо, а не «как привыкли в отделе»;
- точки улучшения — «узкие места», лишние согласования и ручные обходы становятся предметом обсуждения, а не слухов;
- качество — меньше ошибок за счёт контрольных точек и явных исключений;
- основа для IT — формализованный процесс можно переложить в BPMS, CRM или 1С без бесконечных переделок;
- управление изменениями — при реорганизации или масштабировании есть эталон «как было» и модель «как должно быть».
Диаграмма сама по себе не меняет поведение людей. Ценность появляется, когда описание прошло согласование с владельцем процесса и исполнителями, закреплено в регламенте и используется в обучении и контроле.
Из чего состоит описание процесса
Полное описание — не только «стрелочки слева направо». Минимальный каркас разработка бизнес процессов, без которого модель нельзя исполнять и измерять:
- начало и результат — что запускает процесс и что считается успешным завершением для потребителя (внешнего или внутреннего);
- этапы и решения — основной маршрут и условия перехода между шагами;
- роли и подразделения — кто выполняет действие и кто принимает решение, а не только должность в штатном расписании;
- данные и документы — что поступает на вход шага и что должно появиться на выходе;
- сроки и показатели — где критично время, объём, качество или SLA;
- исключения — что делать при отказе клиента, ошибке, отсутствии данных или эскалации.
Если описывать процесс «по отделам» отдельными кусками, сквозной маршрут всё равно нужно собрать: у процесса должен быть владелец, а на стыках — явный результат передачи, получатель и срок. Иначе цели подразделений расходятся с результатом для компании.
Базовый, альтернативные и исключительные сценарии
На ранних этапах удобно рисовать «идеальный» путь — но в эксплуатации процесс живёт в трёх типах маршрутов:
- базовый («счастливый») путь — один, самый частый сценарий без сбоев;
- альтернативные пути — законные варианты (клиент выбрал другой продукт, другой канал оплаты, другой склад);
- пути исключений — ошибки, отказы, недоступность ресурса, необходимость эскалации руководителю.
Сначала фиксируют базовый маршрут, затем добавляют развилки. Пропуск исключений — одна из главных причин, почему регламент «не работает»: сотрудники в нестандартной ситуации снова действуют по привычке. Это учитывают при разработка бизнес процессов и создание бизнес процесса.
Когда пора формализовать процессы
Формализацию имеет смысл планировать, если выполняется хотя бы одно из условий:
- компания растёт, и координация «на словах» перестаёт масштабироваться;
- производственная или сервисная цепочка стала сложной (несколько систем, складов, каналов продаж);
- готовится франшиза, аудит или передача блока новому руководителю;
- нужно снижать себестоимость и убирать дублирование;
- планируется автоматизация — без модели процесса интеграции часто заканчиваются дорогим «заказным софтом под хаос».
На старте малого бизнеса достаточно коротких описаний ключевых цепочек. По мере роста те же цепочки декомпозируют: верхнеуровневая карта → отдельная детальная схема на каждый значимый процесс. Тогда организация бизнес процессов и выстраивание бизнес процессов становятся управляемыми.
Этапы: разработка бизнес процессов
Ниже — практическая последовательность для разработка бизнес процессов и создание бизнес процесса, которую можно использовать внутри компании или как ориентир при работе с консультантом. Подзаголовки в тексте совпадают с пунктами содержания — по ним можно перейти якорем, но визуально они не «ломают» страницу крупными заголовками.
Границы и место в карте процессов. Сначала отделяют один процесс от соседних: без этого модель разрастается или дублирует шаги соседних цепочек. Имеет смысл опереться на карту процессов компании — какие сквозные потоки есть и что от чего зависит. Для выбранного процесса фиксируют название, владельца (process owner), потребителя результата (клиент, отдел, регулятор) и явно перечисляют, что не входит в границы — например, не смешивают «обработку заказа» и «привлечение лида». На этом шаге достаточно согласованного текста на одной странице, без детальной нотации.
Старт, результат и основные блоки. Определяют, какое событие или факт запускает процесс (заявка, подписанный договор, наступление даты) и какой результат считается успехом для потребителя (отгрузка, подписанный акт, закрытая заявка в CRM). Между стартом и финишем выделяют 5–9 крупных блоков — не опускаются до уровня «открыть файл» или «позвонить». Пример цепочки обработки заказа: регистрация → уточнение потребности → резерв или производство → комплектация → отгрузка → закрытие в учёте. Сначала рисуют базовый («счастливый») путь; альтернативы и исключения добавят на следующем этапе.
Детализация и развилки. К каждому блоку добавляют шаги, условия перехода («если товар на складе — …, если нет — …»), сроки ожидания. Здесь же описывают альтернативные сценарии (другой продукт, канал оплаты, склад) и пути исключений: отказ, ошибка в документе, недоступность ресурса, эскалация руководителю. Уровень детализации держат единым по всей модели: смешение «шаг на минуту» и «обработать заявку» одной фразой мешает согласованию и измерению.
Роли, документы и передачи между отделами. На схеме или в таблице закрепляют роли (не только штатные должности), документы и данные на входе и выходе шага, канал передачи (CRM, почта, бумажный комплект, интеграция) и точку стыка — кто принял результат предыдущего этапа и в какой форме. Здесь часто всплывают неформальные согласования в мессенджере: их либо включают в модель явно, либо убирают как лишние, если есть регламентный путь.
Проверка с участниками. Черновик показывают владельцу процесса и тем, кто выполняет шаги каждый день. Задача — сверить схему с практикой: где реально срываются сроки, какие действия делают «мимо инструкции», какой документ появляется впервые на шаге. После сессии вносят правки и фиксируют версию (дата, автор, статус «согласовано» или «черновик»). Без этой проверки регламент часто остаётся «для аудита», а не для работы.
Модель «как есть» и целевая модель. Разработка бизнес процессов ведётся в двух слоях: AS-IS — как процесс работает сейчас, включая обходы, если они влияют на результат; TO-BE — целевая модель после снятия дублей, лишних согласований и рисков. Между слоями — анализ узких мест, противоречий и ограничений по людям и системам. Не обязательно менять всё сразу: иногда достаточно согласованного AS-IS, нескольких точечных улучшений и поэтапного плана перехода к TO-BE.
Регламент, показатели и подготовка к автоматизации. Согласованную модель переводят в регламент (текст и схема), назначают показатели — время цикла, доля ошибок, загрузка роли, SLA на стыках. Перед переносом в CRM, BPMS или 1С проверяют стабильность: если порядок работ меняется каждую неделю «на лету», автоматизация закрепит хаос. Когда правила устоялись, IT может опираться на согласованную нотацию (см. материал о BPMN); для бизнеса на этом этапе важнее ясная ответственность и исполнимые исключения.
Внедрение согласованной модели в работу
- Коммуникация. Объясните, зачем меняется порядок работ и что остаётся прежним.
- Пилот. Запустите TO-BE на одном участке, смене или типе заявок.
- Обучение. Пройдите регламент и схему с разбором исключений.
- Масштабирование. После успешного пилота распространите модель на всех участников.
- Контроль. Проверяйте выборочные кейсы и корректируйте без «тихого» отката к старой схеме.
Разработка бизнес процессов (схема) и внедрение в ежедневную работу — разные задачи: новая модель должна быть обязательной для всех, иначе эффект от оптимизации не измерить. На этом этапе часто сравнивают разработка бизнес процесса «как есть» и целевой вариант.
Типичные ошибки при разработка бизнес процессов
- моделируют «как должно быть», не «как есть» — схема не совпадает с практикой;
- неверный уровень детализации — либо «каша» из мелких шагов, либо абстракции без исполнителей;
- не описывают исключения — при сбое сотрудники снова действуют по привычке;
- размытая ответственность — непонятно, кто владелец шага и стыка;
- игнорируют документы и системы — не видно, откуда данные и что создаётся на выходе;
- смешивают нотации и «свои» символы — модель нельзя передать в IT или подрядчику;
- изолируют процесс от смежных — нет связи с закупкой, складом, финансами;
- утверждают без проверки с участниками — регламент не признают исполнители.
Чек-лист перед автоматизацией
Перед переносом результата разработка бизнес процессов в CRM, BPMS или связку 1С проверьте:
- границы процесса и точки входа/выхода определены;
- участники (роли/отделы) названы;
- этапы и развилки отражены в одной согласованной нотации;
- у шагов есть исполнитель, входные и выходные данные;
- учтены альтернативы и сценарии ошибок;
- модель проверена на реальных кейсах, противоречия сняты;
- процесс достаточно стабилен (не переписывается каждый день).
Если нужна помощь с разработка бизнес процессов, описанием AS-IS, целевой моделью и регламентами — начните с услуги описания бизнес-процессов. Для улучшения уже описанного потока смотрите оптимизацию бизнес-процессов. Отдельно закрываем построение бизнес процессов и создание бизнес процессов.
Полезные материалы по разработка бизнес процессов
Связанные информационные страницы и услуги направления — для перехода от смысла к описанию, схемам и внедрению:
В проектах Rezolix мы начинаем с текстового описания и интервью, согласуем границы процесса, строим модель AS-IS/TO-BE и связываем её с регламентами, обучением и при необходимости KPI и автоматизацией.
Нужна разработка бизнес процессов под вашу компанию? Напишите на info@rezolix.ru или перейдите в раздел консалтинговых услуг. Поможем с выстраивание бизнес процессов и организация бизнес процессов.