Чек-лист приёмки процесса собирается так: выписываем из описания процесса все события, при которых что-то должно произойти, и на каждое пишем проверку из четырёх частей — при каком условии, что делаем, какой результат ожидаем и как убедимся, что он получен. Дальше добавляем двенадцать обязательных сценариев, которые нужны любому процессу и которых не бывает в демонстрации. Составление занимает три часа работы руководителя.
Самое сложное здесь — не список, а формулировка. Пункт «проверить, что заявки приходят в CRM» выглядит как проверка, но пройти его нельзя: непонятно, какие заявки, откуда смотреть и что считать успехом. Такой пункт всегда получает галочку. Половина этой статьи — про то, как из пожелания сделать проверку.
Речь именно о приёмке процесса, а не о приёмке этапа работ у подрядчика — это разные документы с разной целью. Как устроена вторая, разобрано в материале про чек-лист приёмки этапа. Здесь — о том, что происходит после подписания акта, когда процессом начинают пользоваться живые люди.
Чем приёмка процесса отличается от приёмки этапа
Обе приёмки нужны и не заменяют друг друга. Первая защищает от того, что подрядчик сдал не то, о чём договаривались. Вторая — от того, что сдано ровно обещанное, но ведёт себя не так, как в демонстрации. Второй риск больше: демонстрация всегда идёт по счастливому пути — заполненные поля, работающие сервисы, рабочее время, один пользователь.
| Вопрос | Приёмка этапа у подрядчика | Приёмка процесса |
|---|---|---|
| На что отвечает | Сдано ли то, что описано в требованиях | Что произойдёт с заявкой в понедельник в 21:40, когда CRM не ответит |
| Кто проводит | Заказчик проекта вместе с руководителем подразделения | Сотрудник, который будет работать в процессе каждый день |
| Что предъявляется | Результат этапа: настройка, документ, схема, доступ | Поведение процесса на заранее подготовленных данных |
| Чем закрывается | Акт, протокол, комплект документов | Журнал прогона: пункт, дата, результат, что дальше |
| Когда проводится | На границе каждого этапа проекта | Перед передачей сотрудникам и повторно через месяц эксплуатации |
| Что бывает при пропуске | Спор об объёме работ через полгода | Молча потерянные заявки, о которых узнают из отчёта о выручке |
Как из процесса получить список проверок
Нужно описание процесса хотя бы на одну страницу: проверять поведение того, чьё правильное поведение нигде не зафиксировано, невозможно. Дальше по описанию выписывают события — моменты, в которые процесс что-то делает или чего-то ждёт.
- 1Точки входа: форма на сайте, письмо, сообщение в мессенджере, выгрузка, ручное заведение. Каждая — отдельная проверка: поля и их заполненность у них разные.
- 2Точки решения — где процесс выбирает ветку: новый клиент или существующий, сумма выше порога или ниже. Проверка нужна на каждую ветку, включая ту, которую «почти не используют».
- 3Точки записи: сделка в CRM, строка в таблице, документ в учёте. Проверять надо не факт записи, а её содержимое — какие поля заполнены и какими значениями.
- 4Точки уведомления: кому и по какому каналу уходит сообщение. Половина дефектов этого класса выглядит как «уведомление ушло», но ушло не тому.
- 5Точки ожидания: согласование, оплата, ответ склада. Здесь нужны два сценария — дождались и не дождались.
- 6Точки выхода. Если процесс может закончиться неуспехом, у неуспеха тоже должен быть видимый результат, а не тишина.
У типового процесса обработки заявки получается 8–14 событий, к ним добавляются двенадцать обязательных из раздела ниже — итого около двадцати пяти пунктов и четыре часа на прогон. Если своих событий больше двадцати, вы описываете не один процесс, а два, и принимать их надо раздельно. Как довести описание до состояния, из которого извлекаются события, разобрано в материале про аудит процессов своими силами.
Формула пункта: четыре части, из которых нельзя выбросить ни одну
Пункт чек-листа, который два разных человека пройдут одинаково и получат одинаковый вывод. Состоит из четырёх частей: условие — в каком состоянии находится система и данные; действие — что именно делает проверяющий; ожидаемый результат — что должно произойти, с конкретными значениями; как убедиться — где смотреть и что там должно быть видно. Пункт без четвёртой части превращается в вопрос вкуса.
| Так пункт не проверяется | Так проверяется |
|---|---|
| Проверить, что заявки приходят в CRM | Условие: форма на сайте, все поля заполнены. Действие: отправляю заявку с телефоном +7 921 000-00-01 и текстом «тест-01». Результат: в CRM за 2 минуты появляется сделка с этим телефоном, источник «сайт», ответственный — дежурный менеджер. Как убедиться: открываю список сделок, фильтр по телефону, вижу одну запись |
| Проверить работу уведомлений | Условие: заявка на сумму выше 100 000 ₽. Действие: создаю такую заявку. Результат: руководителю отдела приходит сообщение с номером сделки и суммой в течение 5 минут. Как убедиться: спрашиваю у руководителя, что именно он получил, и сверяю номер сделки |
| Убедиться, что система устойчива к ошибкам | Условие: интеграция с CRM отключена. Действие: отправляю заявку с формы. Результат: заявка сохранена в собственном журнале со статусом «не доставлена», ответственному ушло сообщение о сбое. Как убедиться: открываю журнал заявок, вижу запись со статусом; после включения CRM сделка появляется без повторной отправки формы |
| Проверить права доступа | Условие: учётная запись менеджера Иванова. Действие: захожу под ней и открываю список сделок. Результат: видны только сделки Иванова, сделки Петрова недоступны и не находятся поиском. Как убедиться: ищу по названию заведомо чужой сделки, получаю пустой результат |
Результат должен содержать значения, а не оценки. «Сделка создаётся корректно» — оценка, «в сделке заполнены телефон, источник и комментарий, ответственный назначен» — результат. Разница видна в споре: по второй формулировке два человека придут к одному выводу, по первой — к двум разным.
Схема из четырёх соединённых стрелками блоков в ряд: «Условие», «Действие», «Ожидаемый результат», «Как убедиться». Под рядом — пример, разложенный по тем же четырём колонкам: «форма на сайте, все поля заполнены» → «отправляю заявку с телефоном +7 921 000-00-01» → «в CRM за 2 минуты появилась сделка, источник «сайт», ответственный назначен» → «список сделок, фильтр по телефону, одна запись». Четвёртый блок выделен рамкой с пометкой «без него пункт не проверяется». Слева сверху перечёркнутая серая плашка с текстом «Проверить, что заявки приходят в CRM». Чертёжный стиль, подписи по-русски.
Двенадцать проверок, которые нужны почти любому процессу
Эти сценарии не выводятся из описания — их туда никто не пишет, и восемь из двенадцати не встречаются в демонстрации никогда. Пройти их надо до передачи процесса сотрудникам и повторить через месяц эксплуатации, когда накопятся реальные данные.
| № | Сценарий | Что ловит | Ожидаемый результат |
|---|---|---|---|
| 1 | Пустые обязательные данные: заявка без телефона или без суммы | Молчаливую потерю записей, которые не прошли валидацию | Запись сохранена, помечена как неполная, ответственный уведомлён |
| 2 | Дубль: та же заявка отправлена трижды подряд | Размножение сделок и двойные звонки клиенту | Одна сделка, две отметки о повторном обращении в её ленте |
| 3 | Отказ внешней системы: CRM или почта отключены | Заявки, которые исчезают между системами | Запись в собственном журнале со статусом «не доставлена», уведомление о сбое |
| 4 | Повторная отправка после восстановления связи | Дубли, которые появляются при попытке доставить накопившееся | Каждая запись доставлена ровно один раз, повторов нет |
| 5 | Нерабочее время: заявка в 21:40 в пятницу | Уведомления в никуда и просроченные обязательства | Заявка принята, срок реакции отсчитывается с начала рабочего дня, дежурный назначен |
| 6 | Права доступа: вход под учётной записью рядового сотрудника | Видимость чужих сделок, сумм и контактов | Виден только свой участок, чужие записи не находятся поиском |
| 7 | Неверный формат: телефон буквами, дата словом, файл не того типа | Падение обработки на одной кривой записи | Запись отклонена с понятным текстом, остальные обработаны |
| 8 | Объём: 100 записей за минуту вместо трёх | Очередь, которая не разгребается, и молчаливые потери на пике | Все записи обработаны, задержка не превышает согласованной |
| 9 | Отмена и откат: заявка отозвана после запуска процесса | Действия, которые продолжают выполняться по отменённой заявке | Процесс остановлен, резервы и задачи сняты, уведомления не уходят |
| 10 | Адресат уведомления: сотрудник в отпуске или уволен | Сообщения, которые уходят на почту, которую никто не читает | Уведомление уходит замещающему, факт замещения виден в журнале |
| 11 | След в журнале: восстановить историю одной заявки за прошлый месяц | Невозможность разобраться в инциденте задним числом | По номеру заявки видно, что происходило, когда и по чьей команде |
| 12 | Ручной обход: процесс остановлен на час | Паралич подразделения при первом же сбое | Есть письменный порядок ручной работы и способ довнести данные потом |
Отказ внешней системы, повторная доставка и ручной обход не проверяют, потому что «этого же не случится». Случается регулярно: у любого стороннего сервиса бывают минуты недоступности, и вопрос только в том, что процесс делает в эти минуты. Правильный ответ — сохраняет у себя и говорит вслух; неправильный — теряет молча. Как выглядит порядок действий при недоступности чужого сервиса, разобрано отдельно в материале про сбои внешних сервисов.
Кто проходит чек-лист и что делать с найденным
Прогон делает сотрудник, который будет работать в процессе каждый день, а не тот, кто его настраивал. Это не про доверие: собравший процесс не может проверить его непредвзято — он знает, где нажимать, и обходит проблемные места раньше, чем осознаёт это. По той же причине бессмысленна приёмка руководителем, который в системе не работает.
- 1Тестовые заявки, контакты, суммы и файлы готовятся до прогона. Импровизация на ходу превращает прогон в исследование и растягивает его вдвое.
- 2Каждый пункт получает одну из трёх отметок: прошёл, не прошёл, невозможно проверить. Третья — самая ценная: значит, в процессе нет способа увидеть результат, и это дефект сам по себе.
- 3Расхождение описывается фактами: что делал, что ожидал, что получил, во сколько. «Не работает уведомление» вернётся вопросом «а что именно вы отправляли».
- 4Приоритет один — теряются ли данные. Всё, что приводит к молчаливой потере записи, чинится до передачи процесса людям; остальное ждёт следующей итерации.
- 5После исправлений прогоняются все пункты, а не только упавшие: правка одного места регулярно ломает соседнее.
Теперь про деньги. Модельная компания: 180 заявок в месяц, средний чек 45 000 ₽, валовая маржа 30 %, то есть 13 500 ₽ с заявки. Приёмку составляет руководитель подразделения, прогоняет оператор.
Полтора процента — порядок величины, который получается, когда у стороннего сервиса случаются короткие перерывы, а процесс не умеет их пережидать. Свою долю считают сверкой количеств за период: сколько записей вышло из точки входа и сколько дошло до точки записи. Методика — в инструкции про девять тестов интеграции за час.
Диаграмма из двух вертикальных столбцов на одной шкале в рублях. Левый столбец «Приёмка процесса — 12 100 ₽ разово» с разбивкой на четыре сегмента: 5 400 ₽ составление, 2 800 ₽ прогон, 2 100 ₽ разбор, 1 800 ₽ повторный прогон. Правый столбец «Один необработанный отказ внешней системы — 36 450 ₽ в месяц» с подписью «2,7 заявки из 180 по 13 500 ₽ маржи». Между столбцами горизонтальная выноска «окупаемость около десяти дней». Ось Y — рубли, все числа подписаны.
Когда двенадцати проверок мало и когда чек-лист не нужен
Есть процессы, для которых этот список — необходимый минимум, но далеко не достаточный. И есть ситуации, где составление чек-листа дороже самого процесса.
- Процесс принимает решения о деньгах или о людях. Скидка, отказ в заявке, отбраковка кандидата — здесь добавляется проверка граничных случаев по каждому правилу и точка, где решение подтверждает человек в контуре.
- В процессе участвует языковая модель. Двенадцати сценариев мало принципиально: модель на одном входе может ответить по-разному, и «прогнал один раз — прошло» ничего не доказывает. Нужен набор из нескольких десятков примеров с заранее известными ответами и повторный прогон после каждой правки промпта.
- Процесс работает с персональными данными или с маркировкой. Добавляются проверки, которых нет в списке: кто видит данные, что попадает в журналы, блокируется ли операция при расхождении кодов. Цена ошибки здесь измеряется не потерянной заявкой.
- Процесс запускается реже раза в неделю и делает один шаг. Ежемесячной выгрузке отчёта хватит трёх пунктов: файл появился, числа сходятся с источником, о неудаче кто-то узнал.
И последнее ограничение. Чек-лист ловит дефекты поведения, но не дефект замысла. Если процесс автоматизирован не там, где стоит очередь, все двадцать пять пунктов пройдут, а эффекта не будет — просто бессмысленная работа станет быстрее. Для вопроса «а то ли задумано» чек-лист бесполезен, там нужен замер до и после.
Пункт, который нельзя провалить, не является проверкой. Он является формальностью с галочкой.
