Когда компания уже видит потери от ручной работы, появляется желание быстро выбрать систему и запустить проект. Но автоматизация бизнес-процессов начинается не с платформы и не с технического задания. Сначала нужно определить, какой процесс стоит менять, какую проблему решать и по каким признакам станет понятно, что изменение сработало.
Попытка автоматизировать сразу несколько подразделений увеличивает число требований, участников и исключений. Первый проект лучше сделать ограниченным: выбрать заметную проблему, описать её границы и проверить решение на реальной работе. Такой подход быстрее даёт знания и снижает риск вложиться в систему, которая формально работает, но не используется командой.
Шаг 1. Сформулируйте проблему без названия решения
Фраза «нам нужен личный кабинет» уже содержит выбранный продукт, но не объясняет задачу. Возможно, клиентам действительно нужен кабинет. А возможно, им достаточно получать статус заказа и документы по удобной ссылке. Начинать полезнее с наблюдаемой проблемы:
клиент несколько раз запрашивает статус;
менеджер вручную собирает данные из писем;
согласование теряется между отделами;
отчёт готовится слишком долго;
сотрудники повторно вводят реквизиты;
руководитель не видит очередь и загрузку.
Хорошая формулировка описывает ситуацию, участников и последствия. Например: «После получения заявки менеджер переносит данные в три системы, поэтому обработка задерживается и часть полей заполняется с ошибками». Пока проблема описана так, остаётся пространство для разных решений.
Если вы ещё не уверены, что проблема действительно системная, вернитесь к диагностике в статье «Как понять, что бизнесу нужна автоматизация процессов».
Шаг 2. Составьте список процессов-кандидатов
Не выбирайте первый процесс только потому, что на него чаще жалуются. Соберите короткий список из трёх–пяти кандидатов и сравните их по одинаковым критериям.
Подходящие кандидаты можно искать вокруг клиентского пути и внутренних операций:
приём и распределение заявок;
подготовка коммерческого предложения;
согласование документов;
выставление и контроль счетов;
обработка обращений поддержки;
сбор управленческой отчётности;
передача заказа между подразделениями;
информирование клиента о статусе;
проверка комплектности данных.
Не включайте слишком широкие формулировки вроде «автоматизировать продажи». Продажи состоят из разных процессов, и у каждого собственные участники, правила и показатели. Кандидат должен иметь понятное начало и завершение.
Шаг 3. Оцените кандидатов по единой матрице
Для первого проекта важен баланс эффекта и реализуемости. Процесс с максимальными потерями может оказаться слишком сложным для старта, а самый простой — не дать заметного результата.
Оцените каждый кандидат по шкале от 1 до 5:
| Критерий | Низкая оценка | Высокая оценка | |---|---|---| | Частота | Возникает редко | Повторяется ежедневно | | Влияние | Локальное неудобство | Влияет на клиента, деньги или решения | | Повторяемость | Каждый случай уникален | Большая часть шагов выполняется по правилам | | Качество данных | Данные отсутствуют или неструктурированы | Основные данные уже собираются | | Число участников | Много отделов и внешних сторон | Ограниченная команда и понятный владелец | | Измеримость | Результат трудно наблюдать | Есть время, ошибки, очередь или другой показатель | | Риск пилота | Ошибка критична и необратима | Пилот можно безопасно ограничить |
Для старта часто подходит кандидат с высоким влиянием, высокой повторяемостью и умеренной сложностью. Не обязательно выбирать процесс с максимальной суммой баллов: матрица нужна, чтобы сделать причины выбора прозрачными.
Шаг 4. Назначьте владельца процесса
Проект не должен принадлежать только IT или подрядчику. Нужен человек со стороны бизнеса, который понимает работу, может принимать решения и отвечает за результат после запуска.
Владелец процесса:
согласует границы задачи;
собирает участников;
определяет правила и исключения;
помогает расставлять приоритеты;
принимает результат пилота;
отвечает за внедрение нового порядка работы.
Если владелец не определён, требования будут формироваться из пожеланий разных сотрудников, а спорные вопросы останутся без решения. Технологическая команда не может самостоятельно выбрать бизнес-правило, если у компании нет единой позиции.
Шаг 5. Опишите процесс «как есть»
Не требуется многотомный регламент. Для первого анализа достаточно схемы на одном экране и нескольких примеров реальных задач.
Зафиксируйте:
Что запускает процесс.
Какой результат считается завершением.
Кто участвует на каждом этапе.
Какие данные поступают и откуда.
Где данные сохраняются или меняются.
Какие решения принимает сотрудник.
Какие правила можно проверить однозначно.
Где возникают ожидания, возвраты и ошибки.
Какие исключения встречаются регулярно.
Отдельно отметьте неофициальные обходные пути. Если сотрудники выгружают данные из системы в таблицу, чтобы продолжить работу, это важная часть реального процесса. Описание только «правильного» регламента приведёт к решению, которое не учитывает повседневную практику.
Шаг 6. Определите целевой результат
Цель «автоматизировать процесс» ничего не говорит о пользе. Опишите, что должно измениться для конкретных участников.
Примеры направлений результата:
сотрудник вводит данные один раз;
заявка автоматически получает ответственного;
клиент видит актуальный статус без обращения к менеджеру;
руководитель видит очередь и причины задержек;
система проверяет обязательные поля до передачи дальше;
история действий сохраняется в одном месте;
исключения попадают в отдельную очередь, а не теряются.
Выберите один основной показатель и несколько защитных. Например, сокращение ожидания нельзя считать успехом, если одновременно растёт число ошибок. Показатели должны быть доступны до пилота, иначе не получится сравнить состояние до и после.
Шаг 7. Проверьте, нужна ли разработка
После описания задачи сравните несколько классов решений:
| Вариант | Когда подходит | Что проверить | |---|---|---| | Изменение процесса | Лишние шаги вызваны организацией работы | Сможет ли команда соблюдать новый порядок | | Настройка текущей системы | Возможности уже есть, но не используются | Ограничения тарифа, ролей и интерфейса | | Готовый сервис | Процесс типовой и компания готова адаптироваться | Интеграции, владение данными, стоимость изменений | | Интеграция | Системы подходят, но между ними разрыв | Надёжность API, обработка ошибок, синхронизация | | Индивидуальная разработка | Процесс создаёт конкурентное отличие или не укладывается в готовые продукты | Поддержка, безопасность, развитие и полная стоимость владения |
Заказная разработка — один из вариантов, а не исходная точка. Иногда достаточно убрать лишнее согласование или настроить уже оплаченный инструмент. Это хороший результат анализа: компания решает проблему с меньшими затратами и риском.
Шаг 8. Ограничьте первый пилот
Пилот должен проверять ключевое предположение, а не имитировать готовую систему в миниатюре. Ограничить его можно одним подразделением, одним типом заявки, одним регионом или частью маршрута.
До начала согласуйте:
кто участвует;
какие случаи входят в пилот;
какие исключения обрабатываются вручную;
сколько времени нужно для наблюдения полного цикла;
кто собирает обратную связь;
при каких условиях решение расширяется, дорабатывается или останавливается;
как команда вернётся к прежнему порядку при критической проблеме.
Особенно важно не скрывать ручные элементы пилота. На раннем этапе часть операций может выполняться сотрудником, чтобы проверить ценность сценария до сложной интеграции. Главное — отделить временное решение от целевой архитектуры.
Шаг 9. Подготовьте данные и доступы
Даже небольшой проект задерживается, если в последний момент выясняется, что нет владельца справочника, тестовой среды или доступа к API. Составьте перечень заранее:
системы и их владельцы;
способы интеграции;
тестовые данные;
правила доступа;
требования к персональным и коммерческим данным;
справочники и допустимые значения;
ответственные за проверку результата;
ограничения инфраструктуры.
Не передавайте реальные чувствительные данные до согласования безопасного способа работы. Для раннего прототипа часто достаточно обезличенных примеров.
Шаг 10. Согласуйте решение о продолжении
После пилота команда должна принять явное решение, а не оставить инструмент в промежуточном состоянии. Возможны четыре результата:
Расширить решение на другие случаи.
Доработать проблемные части и повторить проверку.
Изменить сам процесс и пересобрать подход.
Остановить проект, если предположение не подтвердилось.
Остановка пилота не всегда означает неудачу. Если компания рано выяснила, что решение не даёт достаточной ценности, она избежала более крупных расходов.
Чек-лист перед началом проекта
Проблема описана без привязки к конкретному продукту.
У процесса есть начало, завершение и владелец.
Собраны реальные примеры и исключения.
Известны участники, системы и источники данных.
Выбран основной показатель результата.
Сравнены организационные, готовые и заказные варианты.
Пилот ограничен и допускает безопасный возврат.
Определены люди, которые примут результат.
Учтены доступы и требования к данным.
Согласовано, как будет принято решение после пилота.
Как подготовить разговор с AVENIR
Для первичного обсуждения не требуется готовое техническое задание. Полезнее принести схему текущего процесса, несколько реальных примеров, список систем, ограничения и желаемый результат. На этой основе можно обсудить варианты — от изменения процесса и интеграции до отдельного цифрового продукта — и определить, какие вопросы требуют дополнительного исследования.
Следующий материал поможет перейти от выбора процесса к реализации: как автоматизировать ручные процессы в компании.
Частые вопросы
Сколько процессов брать в первый проект?
Обычно полезнее начать с одного ограниченного процесса или самостоятельного фрагмента. Несколько процессов можно объединить, если у них общие данные, владелец и измеримый результат, но рост охвата должен быть осознанным.
Нужен ли подробный регламент до старта?
Нет, но команда должна одинаково понимать границы, основные шаги, правила и исключения. Схемы и реальных примеров часто достаточно для первичной оценки; детализация появляется по мере проектирования.
С чего начинать: с простого процесса или самого болезненного?
С процесса, где сочетаются заметный эффект и управляемая сложность. Слишком простой пилот ничего не докажет, а самый сложный может утонуть в зависимостях.
Как понять, что пилот успешен?
Заранее определить основной показатель, защитные показатели и качественную обратную связь пользователей. Сравнивать нужно не только работу системы, но и весь процесс от начала до результата.
Обязательно ли писать техническое задание самостоятельно?
Нет. Бизнесу важнее чётко описать проблему, участников, ограничения и ожидаемый результат. Технические требования разумно формировать совместно с теми, кто будет проектировать и реализовывать решение.