Как отобрать задачи под автоматизацию бизнес-процессов: схема оценки и таблица

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

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

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

Почему первым автоматизируют самое громкое

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

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

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

Признаки хорошего кандидата на автоматизацию

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

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

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

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

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

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

Как описать процесс, прежде чем его оценивать

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

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

Каждая развилка в описании означает правило, которое придётся закодировать, и если развилок на листе больше, чем задач, процесс в основном состоит из решений, а значит, сначала придётся договориться о логике с теми, кто эти решения принимает.

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

Где прячется выгода, которую не видно в заявке

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

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

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

Таблица оценки процессов: шаблон для копирования

Ниже таблица, которую я заполняю вместе с владельцем процесса на рабочей встрече. Каждую строку оцениваем словами "да", "частично" или "нет", потому что спор о баллах съедает всю встречу, а слова заставляют привести живой пример.

Процесс: [название процесса], владелец: [имя и должность]

Повторяемость: процесс случается часто и примерно одинаково? [да / частично / нет], пример: [последний случай]

Правила: решения описываются через "если, то"? [да / частично / нет], пример: [одно правило словами]

Исключения: необычных случаев заметно меньше, чем обычных? [да / частично / нет], пример: [последнее исключение]

Данные на входе: приходят в одном формате из системы или формы? [да / частично / нет], откуда: [источник данных]

Цена ошибки: ошибку машины можно заметить и исправить без штрафа и потери клиента? [да / частично / нет], что будет: [последствие]

Владелец: есть человек, который примет результат и ответит за правила? [да / частично / нет], кто: [имя]

Измеримость: понятно, по какому показателю будет видна польза? [да / частично / нет], показатель: [что меряем]

Сопровождение: есть кто-то, кто будет обновлять правила после запуска? [да / частично / нет], кто: [имя или команда]

Подсчёт по строкам: [сколько "да", сколько "частично", сколько "нет"]

Решение: [брать в работу / сначала навести порядок / оставить человеку], причина: [одной фразой]

Читаю таблицу так: если "нет" стоит в строках про правила, данные или владельца, процесс уходит в наведение порядка, даже если остальные строки выглядят бодро, потому что именно эти пункты ломают проекты сильнее всего.

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

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

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

Частые вопросы про выбор процессов для автоматизации

С какого процесса начинать автоматизацию бизнеса?

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

Какие процессы нельзя автоматизировать?

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

Как оценить, окупится ли автоматизация процесса?

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

Нужно ли описывать процесс перед автоматизацией?

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

Что проверить у себя до конца недели

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

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

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

Какой процесс у вас первым просится в автоматизацию, и выдержит ли он строку про правила?

Новые разборы выходят в моём канале: t.me/promaren.