Как описать процесс перед автоматизацией

Почему автоматизация ломается на описании, а не на коде

Провалившиеся проекты автоматизации почти никогда не проваливаются в разработке. Код пишется, интеграции собираются, тесты проходят - а через месяц после запуска выясняется, что система умеет не то. Люди возвращаются к таблицам и переписке, а новый сервис остаётся местом, куда раз в неделю заносят данные для отчёта.

Причина обычно одна: автоматизировали не тот процесс. Не выдуманный и не чужой - формальный. Тот, что записан в регламенте, который последний раз правили три года назад, и который в реальной работе давно обходят стороной. Настоящий порядок работы при этом никто не описывал: он живёт в головах у пяти человек, и каждый знает свой кусок.

Задача описания - не составить красивую схему, а найти расхождение между тем, как принято считать, и тем, как на самом деле происходит.

Хорошая новость в том, что описание стоит дёшево. Три встречи по полтора часа, неделя на сведение и документ, с которым можно идти за оценкой. Плохая - что пропустить этот шаг соблазнительно всегда: он не выглядит работой, у него нет демонстрации в конце, и заказчику кажется, что за это время уже могли бы что-то написать.

Автоматизировать беспорядок - значит получить быстрый беспорядок.

Правило, которое стоит проговорить на первой же встрече

Шесть шагов

Ниже - последовательность, которая работает и на процессе из трёх шагов, и на сквозном процессе через пять отделов. Порядок важен: каждый шаг опирается на результат предыдущего, и перескочить, например, через поиск владельца - значит собрать материал, который потом некому утвердить.

1. Найти владельца процессаЧеловек, чьё решение об изменении порядка работы примут остальные.
2. Собрать участников, а не согласующихНа встрече нужны те, кто делает работу руками.
3. Спрашивать о последнем случаеНе как обычно, а что именно происходило вчера.
4. Записать исключения отдельноОсновной путь описывается за полчаса, стоимость определяют исключения.
5. Нарисовать карту и показать участникамПравки на этом шаге - хороший знак: значит, читают.
6. Отметить потериВ часах, а не в словах: это разговор о деньгах.

Шаг 1. Найти владельца процесса

Владелец - не тот, кто отвечает за результат перед руководством, и не тот, кто чаще всех про процесс говорит. Владелец тот, кто может изменить порядок работы и чьё решение примут остальные. Иногда это начальник отдела, но чаще - человек на полступени ниже: старший менеджер, ведущий инженер, диспетчер.

Без такого человека описание превращается в сбор мнений. Каждый участник рассказывает свою часть, версии расходятся, и свести их некому. Разработка в этом случае начинается с компромисса, который не устраивает никого.

Шаг 2. Собрать участников, а не согласующих

На встречу приглашают тех, кто делает работу руками. Ошибка почти всех первых интервью - позвать руководителей всех задействованных отделов. Они расскажут, как должно быть, и это описание не будет иметь отношения к делу.

• Исполнитель, который выполняет основной объём работы каждый день.
• Тот, кто принимает работу и первым видит ошибки.
• Тот, к кому идут, когда случай нестандартный.
• Новичок, если такой есть: он единственный помнит, что здесь непонятно.

Четырёх человек достаточно. Больше - и встреча превращается в совещание, где половина участников молчит, а вторая обсуждает то, что к процессу отношения не имеет.

Шаг 3. Спрашивать о последнем случае

Вопрос "как вы обычно обрабатываете заявку" даёт обобщённый ответ, из которого вычищены все исключения. Вопрос "расскажите про заявку, которую вы закрыли вчера" даёт настоящий порядок действий вместе с оговорками, обходными путями и звонками в соседний отдел.

• Откуда пришла заявка и в каком виде?
• Что вы сделали первым делом? Куда записали?
• Кому передали и как узнали, что он её взял?
• Что пошло не так и как вы это чинили?
• Как поняли, что заявка закрыта?

Последний вопрос обычно самый полезный. Ответ "ну, менеджер посмотрит и закроет" означает, что признака завершения у процесса нет, и автоматизировать его в таком виде нельзя: система не сможет отличить сделанное от забытого.

Шаг 4. Записать исключения отдельно

Основной путь описывается за полчаса. Всё остальное время уходит на исключения, и именно они определяют, сколько будет стоить разработка. Срочная заявка от постоянного клиента, отгрузка без предоплаты по устному разрешению, возврат после закрытия месяца - каждый такой случай либо попадёт в систему, либо станет причиной, по которой ей перестанут пользоваться.

Исключения записывают таблицей с частотой и решением. Редкие можно осознанно оставить на ручной обработке - но именно осознанно, записав это решение, а не забыв о них.

Исключение, о котором не спросили, всплывает на приёмке. Исключение, которое записали и отложили, приёмку не ломает.

Шаг 5. Нарисовать карту и показать участникам

Карта процесса - не схема из учебника. Достаточно последовательности шагов с указанием, кто делает, что получает на входе, что отдаёт на выходе и по какому признаку переходит к следующему шагу. Ветки рисуют только там, где решение действительно принимается: если развилка всегда идёт в одну сторону, это не развилка.

Готовую карту показывают тем же людям, с которых начинали. Правки будут обязательно, и это хороший знак: значит, читают. Тревожно, когда правок нет вовсе - обычно это означает, что документ пролистали.

Шаг 6. Отметить потери

На готовой карте становятся видны места, где время уходит впустую. Их полезно отметить прямо на схеме и оценить в часах - это разговор о деньгах, а не о неудобстве, и именно он определяет, что автоматизировать первым.

• Двойной ввод: одни и те же данные вносят в двух местах.
• Ожидание: работа стоит, пока кто-то не ответит.
• Проверки, которые ничего не находят: делаются по привычке.
• Пересылка файлов вместо общего доступа к ним.
• Сверки в конце периода, нужные из-за расхождений в течение периода.

Что должно получиться на выходе

Документ на восемь-двенадцать страниц. С ним можно идти за оценкой к любой команде разработки и получать сопоставимые цифры, а не разброс в три раза.

1. Карта процесса: шаги, роли, входы и выходы, признаки перехода.
2. Список ролей с указанием, кто владелец процесса.
3. Таблица исключений с частотой и решением по каждому.
4. Перечень найденных потерь с оценкой в часах за год.
5. Список открытых вопросов, на которые ответа пока нет.

И главное: половина найденных потерь чинится без всякой разработки - перестановкой шагов, отменой лишней проверки, общим доступом к папке. Это стоит сделать до автоматизации, а не после.