Чек-лист аудита процессов перед автоматизацией: 23 вопроса заказчику

Зачем нужен аудит до автоматизации, а не после

Есть одна закономерность, которую я видел на десятках проектов: чем быстрее команда бежит к выбору платформы, тем дольше она потом застревает на UAT. Там, где можно было потратить неделю на разбор реального процесса, тратят месяц на переписывание технического задания, которое уже согласовано, подписано и официально считается "утверждённым".

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

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

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

Никакой BPM-движок не проглотит такую схему без предварительной работы.

ИТРП в своих методических материалах зафиксировали 14 типовых ошибок проектов автоматизации. Размытая цель, отсутствие владельца процесса, неучтённые исключения, ручные шаги "по договорённости" вместо регламента. Аудит закрывает большую часть из этих ошибок ещё до старта разработки, а не после первого ShowStopper на приёмке.

И последнее, о чём обычно не говорят вслух. Аудит защищает заказчика от подрядчика, который без лишних вопросов берёт ТЗ и идёт делать "как раньше, но на новой платформе". Это не злой умысел. Просто если никто не остановился и не спросил "а зачем именно так", никто и не остановится. Хорошему подрядчику аудит нужен так же, как заказчику: он снижает риск сдать продукт, который формально работает, но никому не нужен в таком виде.

Автоматизация хаоса только ускоряет хаос, и это главная ловушка, в которую попадают проекты ещё до старта.

Как пользоваться чек-листом: формат интервью с заказчиком

Чек-лист из 23 вопросов разбит на 6 блоков: цели, процесс, данные, люди, риски, экономика. Порядок не случайный. Начинать с экономики нельзя: заказчик уйдёт в цифры ROI раньше, чем вы поймёте, что вообще автоматизируете.

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

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

Фиксируйте три слоя. Первый: ответ дословно, без редактуры и интерпретации. Второй: наблюдение аналитика прямо в процессе, отдельным цветом или отдельной колонкой. Третий: артефакт, который подтверждает или опровергает сказанное. Скриншот системы, файл с реальными данными, регламент из папки на сетевом диске. Без артефакта ответ считается гипотезой.

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

После интервью слова надо проверить реальностью. Два способа. Process mining, если в системе есть логи с временными метками: загружаете данные и смотрите фактическую карту против рассказанной. Shadowing, если логов нет или процесс частично происходит вне систем: садитесь рядом с исполнителем на один-два рабочих дня и смотрите, что он реально делает. Расхождение между интервью и наблюдением в моей практике встречается часто, в большинстве разобранных кейсов. Люди не врут намеренно. Они просто описывают, как "должно быть", а не как "есть на самом деле".

Три человека, один процесс, и три разные версии того, как он работает на самом деле.

Блок 1. Цели и границы (вопросы 1-4)

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

Вопрос 1: Какую конкретную бизнес-метрику вы хотите изменить и на сколько процентов?

Если клиент отвечает "повысить эффективность" или "улучшить процесс", я останавливаю разговор. Это не цель, это направление взгляда. Цель выглядит иначе: "сократить срок согласования договора с 9 до 2 рабочих дней к Q4 2026" или "снизить процент ручных ошибок в счетах с 12% до менее 1% за полгода". Конкретная метрика, конкретное число, конкретный срок. Без этого нет способа проверить, сработало ли вообще что-то.

Вопрос 2: Что случится с бизнесом, если этот процесс оставить как есть на 12 месяцев?

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

Вопрос 3: Где процесс начинается и где он заканчивается?

Нужны два конкретных момента: триггер входа и критерий завершения. Триггер входа, к примеру: "контрагент отправил подписанный скан на почту юротдела". Критерий завершения: "договор загружен в CRM со статусом 'активен' и уведомление отправлено менеджеру". Без таких границ автоматизация расползается. Команда начинает тащить в скоуп смежные кейсы, потом исключения, потом исключения из исключений, и проект теряет форму уже на третьей неделе.

Вопрос 4: Какие смежные процессы вы точно не хотите трогать в этом проекте?

Это фиксация того, что остаётся за забором. Я прошу назвать явно, не намёком. Например: "процесс согласования внутри юротдела мы не трогаем, там своя специфика" или "интеграцию с 1С откладываем на следующий этап". Когда это сказано вслух и записано, у меня есть инструмент возвращать разговор в берега, когда кто-то в середине проекта скажет "а давайте заодно и это". Заодно не получается. Заодно срывает сроки.

Проверка блока простая. Читаю формулировку цели вслух. Если в ней нет числа, нет единицы измерения и нет даты, возвращаюсь к вопросу 1 и не двигаюсь дальше.

Автоматизация без конкретной измеримой цели превращается в дорогое упражнение ради упражнения.

Блок 2. Текущий процесс AS-IS (вопросы 5-9)

Здесь начинается самое интересное. До этого момента заказчик рассказывал, как процесс должен работать. Сейчас я выясняю, как он работает на самом деле.

Вопрос 5. Покажите последние 10 экземпляров процесса. Сколько из них прошли по эталонному маршруту?

Не презентацию со схемой. Не описание из Confluence. Десять конкретных заявок, договоров, заказов, тикетов, что угодно. Открываем по очереди и смотрим путь каждого. В моей практике по эталону проходит меньшинство. Остальные это вариации: возврат на доработку, ручное согласование в обход системы, исключение, "ну Петрович так всегда делает". Вот эти вариации и есть реальный процесс. Эталонный маршрут существует на бумаге, а автоматизировать вы будете живое.

Вопрос 6. Кто владелец процесса end-to-end?

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

Вопрос 7. Где узкое место по времени и где по ошибкам?

Это два разных вопроса, и почти всегда два разных места. По времени обычно тормозит согласование или ожидание данных от смежников. По ошибкам тормозит ввод руками: копипаст из почты в CRM, перенос цифр из Excel в 1С, ручная сверка реквизитов. Если заказчик называет одну и ту же точку как ответ на оба вопроса, я не верю и копаю дальше. Скорее всего, он просто не разделял эти метрики.

Вопрос 8. Какие шаги делаются на словах, в чатах, в голове сотрудника?

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

Чаты особенно опасны. "Мы там в Telegram согласовываем нюансы" означает, что у вас есть второй процесс параллельно с официальным, и он не воспроизводим.

Вопрос 9. Есть ли регламент и совпадает ли он с реальностью?

Прошу регламент. Сравниваю с тем, что увидел по вопросам 5 и 8. Считаю расхождение грубо: сколько шагов из регламента реально выполняются как написано, сколько игнорируются, сколько добавлено сверху.

Если разрыв заметный, больше трети шагов живут иначе, чем написано, ставлю стоп-флаг. Это означает одно: автоматизировать регламент бессмысленно, люди им не пользуются и не будут. Автоматизировать надо реальный процесс, тот самый с Петровичем, чатами и проверкой Лены. А регламент потом переписать под то, что получилось. Не наоборот.

И ещё. Если заказчик на этом этапе говорит "ну у нас регламент немного устарел, мы его как раз обновляем", это почти всегда значит, что регламента нет вообще или он от 2019 года. Прошу прислать файл прямо сейчас, в чат. Если за 10 минут не присылают, значит, его не существует в актуальном виде, и это надо честно записать в отчёт.

Регламент написан в 2018 году, а люди давно работают иначе, и это расхождение видно только в BPMN.

Блок 3. Данные и системы (вопросы 10-13)

Если пропустить этот блок на интервью, оценка трудоёмкости поедет. Не на 20%, а в два-три раза. Знаю это не из теории: бывало, что интеграция, оценённая командой в две недели, растягивалась на несколько месяцев. Причина вскрывалась уже в процессе: конфигурация системы оказывалась сильно доработанной под годами, документации ноль, а внешний API закрыт. Никто не спросил об этом на старте.

Вопрос 10: где живут данные и кто за них отвечает.

"Данные в 1С" и "данные в нашей 1С" разные ответы. Спрашиваю конкретно: какая система считается источником истины для каждого объекта процесса. Договор, контрагент, остаток на складе, статус заявки. И отдельно: кто хозяин этой системы. Потому что "данные в SAP" может означать, что доступ к SAP контролирует ИТ-отдел головной компании в другой стране, а согласование любого изменения идёт три месяца.

Вопрос 11: интеграции или иллюзия интеграций.

Здесь самое интересное. Прошу показать, как данные сейчас переходят между системами. Часто выясняется: Петя каждое утро выгружает Excel из системы A и вручную загружает в систему B. Формально это "интеграция". На деле это ручной процесс с задержкой в сутки и регулярными расхождениями. Копипаст между окнами браузера тоже встречается чаще, чем хотелось бы. Всё это надо зафиксировать явно, потому что автоматизация таких стыков съест значительную часть бюджета.

Вопрос 12: качество мастер-данных.

Один и тот же контрагент под тремя разными названиями в трёх системах. Поля "ИНН" заполнены в 40% записей. Справочник статусов в CRM не совпадает со справочником в ERP. Это не гипотетические примеры, это стандартная картина на проектах старше пяти лет. Спрашиваю напрямую: есть ли дубли контрагентов, есть ли незаполненные обязательные поля, проводилась ли когда-нибудь чистка данных. Если нет, в проект закладывается отдельный этап. Без него автоматизация просто ускорит распространение мусора.

Вопрос 13: API или RPA.

Это технический вопрос, но задаю его на предпроектном интервью, потому что от ответа зависит архитектура. Если у системы есть задокументированный REST API, интеграция предсказуема. Если системе двадцать лет и вендор давно исчез, работать придётся через RPA-робота поверх интерфейса. RPA в таких случаях не плохой выбор, но хрупкий: сменился экран входа, обновился браузер, поехал макет кнопки. Робот встал. Закладывать на поддержку надо отдельно и честно говорить об этом заказчику до подписания, а не после.

Четыре вопроса, один блок, час разговора. Экономит месяцы.

Если данные между системами гоняют через Excel и копипаст, автоматизация одного узла ничего не решит.

Блок 4. Люди и изменения (вопросы 14-17)

Технические вопросы из предыдущих блоков относительно комфортны. Клиент отвечает про объёмы, форматы, интеграции, и разговор идёт в привычном регистре. С людьми сложнее: здесь начинается политика.

Вопрос 14: сколько человек делает процесс сейчас и сколько останется?

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

Спрашивай прямо: "После запуска сколько FTE останется на этом процессе?" Если заказчик говорит "посмотрим" или "это зависит от HR", значит внутри ещё нет договорённости и проект будет тормозить именно здесь.

Вопрос 15: кто конкретно проиграет?

В каждой автоматизации есть тот, кому она невыгодна лично. Не компании. Лично. Руководитель отдела, у которого исчезает обоснование для трёх подчинённых. Аналитик, который "держит" процесс в голове и за счёт этого незаменим. Операционный директор, через которого сейчас идут все согласования, а после внедрения пойдут мимо него.

Я называю таких людей стоп-факторами. Они не обязательно будут открыто саботировать. Чаще они просто перестают отвечать на письма, "забывают" согласовать требования, находят причины перенести демо. Медленная смерть проекта через пассивное сопротивление.

Разговор с заказчиком должен быть конкретным: "Есть ли кто-то, чья зарплатная надбавка или зона ответственности напрямую зависит от того, что этот процесс остаётся ручным?" Хороший спонсор проекта знает ответ. Если не знает, это тоже информация.

Что делать с таким человеком: включить в проект. Дать роль. Сделать его владельцем метрики по итогам внедрения. Люди саботируют то, что с ними делают. Они поддерживают то, в чём участвуют.

Вопрос 16: есть ли аналитик и product owner со стороны бизнеса?

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

Аналитик со стороны заказчика нужен не для протокола. Он нужен, чтобы отвечать на вопросы вида "а как обрабатывается исключение, когда накладная без подписи, но сумма меньше 50 тысяч?" Таких вопросов в любом реальном процессе сотни. Без человека, который знает ответы и имеет время их дать, проект буксует на этапе детализации требований.

Product owner нужен для другого: он принимает решения о компромиссах. Автоматизировать исключение или оставить ручным? Включить в первую итерацию или в следующую? Без этой роли каждое решение эскалируется наверх, а наверху нет времени разбираться в деталях.

Если обеих ролей нет, это не блокер, но это риск, который надо назвать явно и зафиксировать в договоре как предусловие старта.

Вопрос 17: кто обучает и сопровождает первые два-три месяца?

Запуск это не финиш. Это начало периода, когда система живёт в руках людей, которые привыкли работать по-другому. В первые недели после go-live нагрузка на поддержку резко возрастает. Пользователи делают ошибки, находят граничные кейсы, которые никто не тестировал, и паникуют, когда система ведёт себя не так, как Excel, к которому они привыкли за пять лет.

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

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

Сопротивление персонала убивает больше RPA-проектов, чем технические баги.

Блок 5. Риски и ограничения (вопросы 18-20)

Это тот блок, где проекты либо взрослеют, либо тихо умирают через три месяца после запуска.

Вопрос 18 про регуляторику звучит скучно, но ответ на него определяет архитектуру. Спросите прямо: какие законы и стандарты касаются этого процесса? 152-ФЗ означает, что персональные данные нельзя просто гнать через любой внешний API. Отраслевые стандарты типа ГОСТ Р 57580 в финансах или требования Росздравнадзора в медицине диктуют, где данные хранятся и кто к ним имеет доступ. Внутренний комплаенс может добавить сверху ещё слой ограничений. Если заказчик отвечает "ну наверное что-то есть, уточним у юристов" - уточняйте до старта разработки, а не после.

Вопрос 19 про отказ вскрывает реальный уровень критичности. Формулируйте конкретно: автоматизированный процесс упал в 10 утра в понедельник и не поднимется до 14:00. Что происходит? Если есть ручной обходной путь и команда умеет им пользоваться - хорошо. Если ответ "ну наверное будем как-то делать руками" - это не обходной путь, это хаос. Отсутствие внятного fallback-сценария означает, что вы обязаны либо проектировать high availability, либо честно предупреждать заказчика о рисках в договоре.

Вопрос 20 про критерии go-live - самый болезненный. Спросите его в первую встречу, не в последнюю. Кто принимает решение о запуске в продакшн? Технический директор? Бизнес-руководитель? Юридический отдел? А какие критерии приёмки - конкретные метрики или ощущения? Я видел проекты, которые технически были готовы в декабре, а go-live случился в феврале следующего года, потому что никто заранее не договорился, что значит "готово". Месяц на согласование критериев приёмки в начале проекта дешевле двух месяцев простоя готовой системы.

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

Процесс с жёсткими регуляторными требованиями и высокой нестабильностью, первый кандидат на заморозку, а не на автоматизацию.

Блок 6. Экономика и приоритизация (вопросы 21-23)

Если на встрече с заказчиком автоматизации я не услышал цифр в рублях, я считаю, что встречи не было. Поэтому три вопроса этого блока я задаю всегда, даже если процесс выглядит "очевидно болезненным".

Вопрос 21. Сколько человеко-часов в месяц процесс ест сейчас и сколько будет есть после?

Считаем не в FTE, а в часах, и сразу переводим в деньги по полной стоимости сотрудника: оклад плюс налоги плюс рабочее место плюс управленческая нагрузка сверху. Если бухгалтер закрывает 180 актов сверки в месяц по 25 минут, это 75 часов. Умножили на полную ставку в час, получили конкретную сумму только на одной операции. После автоматизации станет, скажем, 12 часов на разбор исключений. Вот эта дельта

Считайте ROI честно: часы, которые «сэкономит» автоматизация, надо умножать на реальную ставку, а не на оклад.