Когда компания подписывает договор на автоматизацию, она обычно понимает, что покупает результат, но не понимает, что покупает процесс. В календаре появляется срок «двенадцать недель», а внутри этого срока — туман: непонятно, когда можно будет что-то увидеть, сколько времени уйдёт у собственных сотрудников и в какой момент выяснится, что смета выросла.
Внутри проекта тумана нет. Есть восемь этапов, у каждого из которых свой вход, свой измеримый выход и своя точка приёмки. Порядок почти всегда один и тот же — от небольшого голосового робота до сквозной обработки документов на производстве: меняется масштаб, а не последовательность. Ниже — разбор всех восьми: сколько занимает, что делаем мы, что в это время делает заказчик, чем этап заканчивается. Плюс три вещи, о которых обычно узнают уже в процессе: сколько рабочего времени проект съедает у вашей команды, где он чаще всего встаёт и что должно быть написано в акте, чтобы приёмка была приёмкой, а не формальностью.
Восемь этапов на одном календаре
Речь о типовом проекте для компании 20–500 человек: один процесс, две-три интеграции, один пользовательский сценарий в нескольких вариантах. Сроки ниже — календарные, с учётом выходных и ожидания ответов, а не человеко-часы.
- 1Диагностика — 3–5 рабочих дней. Разбираемся, где именно теряются деньги и есть ли здесь вообще задача для автоматизации.
- 2Карта процесса — 1–2 недели. Описываем, как работа идёт сейчас и как будет идти после, со всеми правилами и исключениями.
- 3Техническое задание и смета — около недели. Сценарии с критериями приёмки, архитектура, фиксированная цена и срок.
- 4Прототип — 1–2 недели. Рабочая модель на 10–20 реальных случаях без интеграций: решение можно потрогать до того, как оно стоит основных денег.
- 5Разработка и интеграции — 3–6 недель. Недельные итерации, в конце каждой — демонстрация на ваших данных.
- 6Пилот — 2–4 недели. Боевая работа на части потока с двойным контролем и замером метрик.
- 7Запуск — 1–2 недели. Расширение на весь поток, инструкции, обучение, дежурство повышенной готовности.
- 8Поддержка — постоянно. Изменения правил, новые случаи, реакция на изменения смежных систем.
В сумме получается 9–15 недель. Чистой инженерной работы в них 7–9 недель, остальное — ожидание: доступы, ответы на вопросы, согласования, чужие отпуска. Это не пессимизм подрядчика, а нормальная арифметика любого проекта, где участвуют две организации. Крупный сквозной проект на несколько отделов живёт по той же схеме, но растягивается до 4–6 месяцев за счёт этапов 2, 5 и 6.
Этапы 1–3: пока никто не пишет код
Диагностика (3–5 рабочих дней). Четыре-шесть интервью по 40–60 минут — обязательно с теми, кто делает работу руками, а не только с руководителями: описание процесса сверху и снизу расходится почти всегда. Параллельно берём выгрузки: сколько операций в месяц за последние 3–6 месяцев, время цикла на выборке из 30–50 случаев, доля переделок. От заказчика нужны выгрузки, полтора часа времени руководителя и назначенный владелец процесса. Выход — 3–5 страниц с цифрами и список участков в порядке отдачи. Здесь же мы говорим, если автоматизировать пока нечего: при 30 операциях в месяц или процессе, который меняется каждый квартал, проект не окупится, и честнее это сказать за 40 000 ₽ диагностики, чем за 900 000 ₽ внедрения.
Карта процесса (1–2 недели). Рисуем два состояния: как есть и как будет. У каждого шага — вход, исполнитель, срок, правило принятия решения. Обычно получается 12–30 шагов, и по нашей практике четверть из них не переживает эту неделю: согласования, которые никто не читает, поля, которые никто не заполняет, отчёты, которые никто не открывает. Отдельно собираем исключения с частотой: правило, срабатывающее дважды в год, автоматизировать не нужно — его оставляют человеку, и это экономит недели разработки. От заказчика: две-три рабочие сессии по полтора часа, где владелец процесса принимает спорные решения на месте, а не выносит их в переписку.
Любая цифра, названная до третьего этапа, имеет разброс в два раза: подрядчик ещё не знает, сколько у вас исключений и в каком состоянии данные. Нормальная схема — платная диагностика и карта процесса отдельным небольшим договором (обычно 8–15% будущего бюджета), а фиксированная смета на разработку появляется после них. Если подрядчик называет точную цену на первой встрече, он либо заложил тройной запас, либо придёт за дополнительным бюджетом на пятом этапе.
Техническое задание и смета (около недели). Полезное ТЗ — это не 80 страниц, которые никто не дочитает, а перечень сценариев, у каждого из которых написан критерий приёмки в цифрах. Плюс схема интеграций, требования к доступам, список того, что в объём не входит. Здесь же фиксируются цена, срок и порядок изменений: любое новое требование после подписания оценивается отдельно и не растворяется в проекте молча. От заказчика нужны 2–3 часа на вдумчивое чтение и подпись. Это самые дешёвые три часа за весь проект: правка на бумаге стоит ноль, та же правка на седьмой неделе стоит недели работы.
Этапы 4–6: прототип, разработка, пилот
Прототип (1–2 недели). Собираем работающую модель на 10–20 ваших реальных случаях, но без интеграций: данные подкладываем вручную. Смысл в том, чтобы вы увидели решение до того, как в него вложены основные деньги. По нашей практике после прототипа меняется 20–40% требований — и это нормальный, здоровый показатель. Та же правка после разработки обходится примерно в десять раз дороже, потому что тянет за собой интеграции и тесты. От заказчика: час на просмотр и честная реакция вместо вежливой.
Отчёт о статусе можно написать про любую неделю. Демонстрацию можно показать только про ту, в которой что-то заработало.
Разработка и интеграции (3–6 недель). Работа идёт недельными итерациями, каждая заканчивается демонстрацией на 20–30 минут: показываем на ваших данных, что появилось за неделю, ведёт показ тот, кто это делал. Если показывать нечего — это и есть главная информация недели, и лучше узнать её на четвёртой неделе, чем на десятой. За двенадцать недель проекта набирается двенадцать точек контроля вместо одной приёмки в конце, и цена ошибки в каждой из них — неделя, а не проект. Красивый статус-отчёт с процентами готовности такой информации не даёт: 70% готовности может означать что угодно.
Пилот (2–4 недели). Система выходит в боевую работу, но на части потока: один филиал из пяти, один тип документа из шести, только вечерние обращения, 20–30% заявок. Первую неделю работает двойной контроль — система обрабатывает, человек проверяет, расхождения записываются с указанием причины. Считаем четыре метрики: доля операций, прошедших без человека; точность на выборке; время цикла; число ручных правок. От заказчика нужны 4–6 часов в неделю сотрудника, который делает проверку.
Пилот часто пытаются пропустить — кажется, что это лишние три недели. Он нужен по четырём причинам: на ограниченном потоке ошибка стоит дёшево и откатывается за час; тестовые примеры никогда не показывают того, что показывают живые данные; команда успевает привыкнуть без аврала; и главное — решение о полном запуске принимается по цифрам, а не по впечатлению от демонстрации. Если по итогам пилота доля автоматической обработки оказалась 60% вместо ожидаемых 85%, это повод доработать правила, а не разворачивать проблему на весь поток.
Этапы 7–8: запуск и жизнь после него
Запуск (1–2 недели). Расширяем на весь согласованный поток, пишем инструкции на 1–2 страницы (сорокастраничный регламент не читает никто), проводим обучение на час-полтора и держим дежурство повышенной готовности первые две недели — с прямым каналом связи, а не через общую почту поддержки. Старый способ работы остаётся доступным ещё 2–4 недели как страховка, но именно как страховка: если разрешить вести оба контура параллельно бессрочно, компания будет вести оба контура бессрочно, и это самая дорогая из возможных концовок проекта.
Поддержка. Ориентир по бюджету — 15–25% стоимости внедрения в год, и это деньги не на страховку от поломок, а на изменения. Меняется прайс, появляется новый склад, поставщик переделывает форму накладной, площадка меняет API, приходит сотрудник, которого никто не обучил. Без сопровождения решение начинает деградировать через 3–4 месяца: часть сценариев перестаёт срабатывать, люди возвращаются к ручному обходу, и через полгода дешевле списать, чем чинить. Со стороны заказчика нужен человек, который раз в неделю смотрит на те же четыре метрики пилота и реагирует, когда цифра поехала.
Сколько проект съедает у вашей команды
Базовая нагрузка — 2–4 часа в неделю одного человека, владельца процесса. Поверх неё есть три пиковые недели, где нужно 6–8 часов: сессии по карте процесса, приёмка прототипа и старт пилота. Плюс разовое участие смежников: интервью, доступы, проверка результатов. Эти часы редко попадают в расчёт окупаемости, хотя они настоящие и оплачиваются из того же кармана.
Цифра выглядит неприятно ровно до момента, когда её сравнивают с альтернативой. Проект, где заказчик не выделил эти часы, не становится дешевле — он становится длиннее: сроки уезжают на 3–6 недель, потому что каждый нерешённый вопрос стоит в очереди, а команда подрядчика простаивает или переключается. Простой оплачивается тем же бюджетом, только без результата.
Где встают проекты и как принимать этапы
Задержки почти никогда не связаны с технической сложностью. За несколько лет список причин практически не меняется, и все они предотвращаются заранее — при условии, что о них договорились до старта, а не после.
| Причина | Типичная потеря времени | Что снимает проблему |
|---|---|---|
| Доступы: ключи API, права в CRM, тестовый контур телефонии | 1–3 недели | список доступов приложением к договору, запрос на этапе ТЗ, а не перед разработкой |
| Согласование внутри компании через двух-трёх руководителей | 1–2 недели на каждый спорный вопрос | один владелец с правом решать и срок ответа 3 рабочих дня, записанный в договоре |
| Качество данных: дубли справочников, пустые обязательные поля | 2–4 недели | чистка вынесена в отдельный этап с отдельной приёмкой до разработки |
| Отпуск или уход ключевого сотрудника | 2–3 недели простоя | заместитель назначен с первого дня, решения фиксируются письменно, а не в голове одного человека |
| Новые требования после демонстрации | от 0 до 2+ недель | изменение оформляется отдельной задачей с ценой и сроком, а не добавляется в текущий этап |
Отдельно про отпуск: это единственная причина из списка, которую все считают уважительной и потому не готовят. Проект на 12 недель почти гарантированно накрывает чей-то отпуск, и если владелец процесса уезжает на две недели без замены, встают все открытые вопросы разом. Стоит просто посмотреть график отпусков перед стартом и назвать заместителя.
- Что именно принято: перечень сценариев с номерами из ТЗ, а не строка «этап разработки выполнен».
- Проверяемый критерий с числом: «на 100 реальных накладных система корректно извлекает 6 полей не менее чем в 92% случаев» — цифра, которую можно перепроверить самостоятельно.
- Ссылка на артефакт: адрес стенда, номер сборки, файл с результатами теста. Приёмка по устному показу оставляет обе стороны без доказательств.
- Список известных ограничений, принятых сознательно: что система пока не умеет и почему решили с этим жить.
- Что заказчик получил на руки: доступы, конфигурации, исходный код или выгрузка настроек, инструкции. Проверять это на восьмом этапе поздно.
- Срок на замечания: 5 рабочих дней, после которых этап считается принятым. Без срока приёмка висит месяцами и блокирует следующий этап.
Проект внедрения устроен скучно, и это его главное достоинство. Восемь этапов, у каждого измеримый выход, недельная демонстрация вместо ежемесячного отчёта, пилот на части потока вместо запуска сразу на всё. Ни один из пунктов не требует от заказчика технических знаний — только выделенного человека, права принимать решения и готовности потратить свои 2–4 часа в неделю. Там, где эти три условия есть, проект укладывается в срок примерно в девяти случаях из десяти. Там, где их нет, не помогает ни методология, ни смена подрядчика.
