Обследование бизнес-процессов легко принять за серию интервью, после которой консультант отдаёт собственнику большой отчёт и несколько красивых схем. Документ выглядит солидно, но главный вопрос остаётся без ответа: что именно теперь нужно изменить и почему это важнее остальных пожеланий?
Полезное обследование уменьшает неопределённость перед оптимизацией. Оно связывает фактическую работу компании, проблемы, управленческие решения и реалистичный план изменений. Если на выходе есть только описание текущего порядка, собственник получил фотографию процесса, но ещё не основу для проекта.
Команда компании «Первый Приятный Интегратор» | 1PI.PRO объясняет, по каким результатам можно проверить качество обследования и какие вопросы стоит задать до автоматизации.
Зачем собственнику обследование, если он и так знает бизнес
Собственник обычно хорошо понимает продукт, клиентов и общую экономику компании. Но ежедневный процесс живёт на уровне десятков передач: менеджер уточняет данные у клиента, руководитель согласует исключение, производство ждёт спецификацию, бухгалтерия получает документ с опозданием. Часть правил существует только в переписке или в памяти опытных сотрудников.
Руководители разных подразделений могут честно описывать один процесс по-разному. Каждый видит свой участок, а потери возникают между участками: работа передана без обязательных данных, следующий сотрудник не знает приоритет, решение принято, но не зафиксировано, статус в системе не соответствует реальности.
Поэтому задача обследования — не объяснить собственнику его бизнес. Нужно собрать проверяемую картину сквозной работы и превратить разрозненные версии в решения, с которыми можно проектировать изменения.
Первый результат: фактическая карта процесса
Схема «как должно быть по регламенту» не заменяет маршрут, по которому прошли реальные заказы. До оптимизации нужно установить:
- какое событие запускает процесс;
- какой проверяемый результат завершает его;
- кто участвует в каждом участке;
- какие данные и документы передаются дальше;
- где принимаются решения;
- какие системы, таблицы и чаты используются;
- где возникают возвраты, ожидания и исключения;
- кто отвечает за результат целиком.
Полезно взять несколько недавних ситуаций и пройти их от начала до конца. Если пять случаев развивались по пяти разным маршрутам, это не повод немедленно рисовать пять автоматизаций. Сначала нужно отделить основной путь от обоснованных исключений и случайных обходных решений.
В статье о готовности бизнес-процесса к автоматизации мы подробно разбирали, почему сначала нужно зафиксировать событие старта, результат, роли и исключения. В обследовании эта проверка становится основой всей дальнейшей работы.
Второй результат: карта проблем с доказательствами
Фразы «сотрудники работают медленно», «всё теряется» и «нет контроля» показывают недовольство, но не определяют задачу проекта. Для каждой проблемы нужно ответить хотя бы на четыре вопроса:
- Где именно она возникает?
- Как проявляется в реальной ситуации?
- На какой результат, риск или управленческое решение влияет?
- Какими данными можно проверить изменение после запуска?
Например, проблема не в том, что менеджер пишет сообщение в чат. Ручная передача может быть нормальной. Проблема появляется, если без сообщения следующий отдел не начинает работу, состав переданных данных каждый раз разный, срок нигде не контролируется, а собственник узнаёт о задержке от клиента.
Такой разбор отделяет причину от заметного симптома. Иногда автоматизация действительно нужна. Иногда достаточно изменить правило, убрать лишнее согласование или назначить владельца решения. Иногда проблема находится не в процессе, а в исходных данных.
Третий результат: согласованные границы и владелец
Без границ обследование разрастается до описания всей компании. Без владельца каждое подразделение защищает свой участок, но никто не принимает решение о маршруте целиком.
В результате обследования должно быть ясно:
- какой процесс меняется в текущем проекте;
- что остаётся за его пределами;
- где начинается и заканчивается ответственность команды;
- кто принимает решения по спорным правилам;
- какие подразделения подтверждают свой участок;
- какие внешние системы и интеграции влияют на результат.
Граница не обязана охватывать путь от рекламы до повторной продажи. Для первой версии можно выбрать участок от подтверждённого заказа до исполнения и фиксации оплаты. Важно честно показать, что входит в проект сейчас, а что останется следующим этапом.
Четвёртый результат: целевой контур, а не список функций
После фактической карты и проблем появляется описание будущей работы. Оно отвечает не на вопрос «какие функции включить», а на вопрос «как компания должна действовать после изменения».
В целевом контуре фиксируются:
- основной маршрут;
- роли и точки передачи ответственности;
- обязательные данные на каждом переходе;
- решения, которые принимает человек;
- типовые действия, которые можно автоматизировать;
- возвраты и исключения;
- контрольные сроки;
- информация, которую должен видеть руководитель.
Сначала согласуется эта логика, затем выбираются инструменты. Официальный дизайнер бизнес-процессов Битрикс24 позволяет настраивать действия, условия, параметры и права. Но технический дизайнер не решает за компанию, кто отвечает за результат, какое исключение допустимо и в какой момент работа действительно завершена.
Пятый результат: приоритеты и дорожная карта
У обследования редко бывает только одна находка. Поэтому собственнику нужен не перечень всех идей, а порядок решений.
Приоритет полезно определять по сочетанию факторов:
- влияние на клиента, деньги, срок или риск;
- частота проблемы;
- готовность процесса и данных;
- количество нерешённых правил;
- зависимости от других подразделений и систем;
- возможность проверить первую рабочую версию.
Дорожная карта должна показывать не только даты. В ней нужны этапы, зависимости, участники, границы первой версии и критерии результата. Если проект начинается с нескольких неподготовленных интеграций, спорных регламентов и переноса всей истории, этот риск должен быть виден до настройки.
Выбор первого сквозного процесса — отдельное управленческое решение. Самый большой или самый болезненный процесс не всегда становится лучшим стартом: ценность нужно сопоставить с готовностью.
Если границы и приоритеты пока не складываются в управляемый первый этап, можно обсудить проект с компанией «Первый Приятный Интегратор» | 1PI.PRO. Мы разберём исходную ситуацию и поможем связать процесс, ограничения и ожидаемый результат до начала настройки.
Что должно быть в итоговом комплекте
Название и формат документов зависят от масштаба проекта, но собственнику полезно проверить наличие семи смысловых частей:
- Фактическая схема процесса. Не идеальный регламент, а подтверждённый текущий маршрут с ролями, данными и исключениями.
- Карта проблем. Каждая проблема привязана к участку процесса, наблюдаемому проявлению и бизнес-последствию.
- Реестр решений и открытых вопросов. Видно, что уже согласовано, кто принимает оставшиеся решения и к какому сроку.
- Целевой контур. Описано, как должна идти работа, что автоматизируется и где сохраняется человеческое решение.
- Границы первой версии. Зафиксировано, что войдёт в запуск, а что сознательно отложено.
- Дорожная карта. Показаны этапы, зависимости, роли клиента и интегратора, риски и порядок проверки.
- Критерии результата. Понятно, по каким фактам собственник отличит работающий процесс от набора выполненных настроек.
Это не означает, что каждый проект обязан завершаться семью отдельными файлами. Несколько частей могут быть объединены. Важно содержание: после обследования должно быть можно принять решение о проекте, а не заказывать ещё одно исследование, чтобы понять первое.
Условный пример: согласование счёта
Представим компанию, где менеджер готовит счёт, руководитель проверяет условия, бухгалтерия подтверждает реквизиты, а нестандартные скидки дополнительно согласует директор. Сотрудники говорят, что процесс нужно «ускорить роботами».
Фактическая проверка показывает несколько разных маршрутов. Стандартный счёт проходит быстро, но при нестандартных условиях неясно, кто должен принять решение. Иногда менеджер отправляет документ клиенту до проверки реквизитов. Статус согласования фиксируется в чате, поэтому руководитель не видит общий объём ожиданий.
Полезный результат обследования в этом примере выглядит так:
- Определён старт: менеджер заполнил обязательные данные и запросил согласование.
- Разделены стандартный и нестандартный маршруты.
- Назначены владельцы решений по условиям и реквизитам.
- Зафиксированы причины возврата на доработку.
- Решено, какие проверки можно выполнить автоматически, а где нужен человек.
- Определён конец процесса: счёт проверен, отправлен клиенту, а решение сохранено в системе.
- Для первой версии выбран один тип счёта без редких исключений.
Только после этого имеет смысл проектировать поля, статусы, задания, уведомления и права. Схема согласования — условный пример, а не клиентский кейс компании.
Что собственник может проверить самостоятельно
Перед принятием результата обследования задайте команде десять вопросов:
- На каких недавних случаях подтверждена схема?
- Где версии сотрудников расходились и как противоречия разрешили?
- Какое событие запускает процесс и какой факт его завершает?
- Кто отвечает за результат целиком?
- Какие проблемы подтверждены, а какие остались предположениями?
- Что компания решила не автоматизировать и почему?
- Какие обязательные данные нужны для первой версии?
- Какие зависимости могут остановить запуск?
- Что сознательно перенесено на следующий этап?
- По каким наблюдаемым признакам будет принят результат?
Если на вопросы отвечают только перечнем функций, обследование ещё не доведено до проектного решения.
Признаки формального обследования
Стоит насторожиться, если результат состоит преимущественно из:
- схемы, которую не подтвердили участники процесса;
- списка пожеланий без приоритетов;
- каталога функций системы;
- обещаний «полностью исключить человеческий фактор»;
- календаря без зависимостей и критериев приёмки;
- расчёта экономии без исходных данных;
- рекомендации автоматизировать спорные правила;
- плана, где вся ответственность за решения передана интегратору.
Интегратор может собрать факты, показать противоречия и предложить варианты. Но решения о приоритетах, допустимых рисках и правилах работы остаются за компанией.
Когда можно переходить к настройке
Настройку можно начинать, когда у первой версии есть понятные границы, владелец, основной маршрут, обязательные данные, перечень исключений и критерии результата. Необязательно заранее описать всё до последней кнопки. Неопределённость должна быть управляемой: открытые вопросы зафиксированы, ответственные назначены, а риски не скрыты.
Именно после такого обследования появляется обоснованный объём работ. Поэтому стоимость внедрения Битрикс24 корректно обсуждать после анализа задач и процессов, а не как универсальную цену настройки.
Частые вопросы
Обследование и аудит бизнес-процессов — это одно и то же?
Термины часто используют как близкие, но состав работы зависит от проекта. Важно не название этапа, а его выходы: фактическая картина, подтверждённые проблемы, согласованные решения, границы и план изменений.
Достаточно ли получить BPMN-схему?
Нет. Схема помогает увидеть маршрут, роли и решения, но собственнику также нужны приоритеты, открытые вопросы, целевой контур, границы первой версии и критерии результата.
Нужно ли описывать все процессы компании?
Не всегда. Для конкретного проекта полезнее ограничить обследование процессом или группой связанных процессов, которые влияют на выбранный бизнес-результат.
Сколько реальных случаев нужно проверить?
Универсального числа нет. Как практический приём можно начать с пяти недавних ситуаций и расширить выборку, если маршруты заметно различаются или исключения встречаются часто.
Должно ли обследование сразу дать точную стоимость автоматизации?
Оно должно дать достаточно данных для обоснованной оценки состава и трудоёмкости работ. Точность зависит от количества открытых вопросов, интеграций, качества данных и согласованности правил.
Можно ли оставить часть действий ручными?
Да. В первой версии человек может принимать нестандартное решение или переносить часть данных вручную. Важно, чтобы ручной участок был явно описан, имел ответственного и не разрушал контроль процесса.
Кто принимает итоговые решения — собственник или интегратор?
Интегратор помогает собрать факты, сравнить варианты и показать последствия. Собственник и назначенные руководители определяют приоритеты, допустимые правила и ожидаемый бизнес-результат.
Что должно измениться после обследования
Хорошее обследование не обязано обещать мгновенную экономию. Его честный результат — компания понимает, как работает процесс, какие проблемы подтверждены, что нужно изменить первым, кто принимает решения и как проверить первую версию.
Если вместо этого остался только объёмный отчёт, проект ещё не подготовлен к оптимизации. Если появились согласованные границы, приоритеты, целевой маршрут и дорожная карта, собственник может принимать решение о бюджете и запуске осознанно.
Чтобы подготовить такой первый этап для реальной компании, можно обратиться в компанию «Первый Приятный Интегратор» | 1PI.PRO. Начнём с процессов и ожидаемого результата, а уже затем определим состав настройки и автоматизации.
