Не тащите хаос в систему: как подготовить процесс к автоматизации
Блог Kaiten ·
Разбираем, как описать текущую работу, выбрать действия для автоматизации и проверить изменения на пилоте
Перед автоматизацией важно разобраться с самим процессом. Без подготовки в систему можно перенести лишние этапы, спорные правила и действия, которые вообще не стоило сохранять в прежнем виде.
Поэтому сначала нужно подготовить сам процесс, а затем переходить к технической настройке. В статье разберем, как подготовить его к автоматизации и на что обратить внимание до первого запуска.
Для первого запуска лучше выбрать отдельный повторяющийся процесс: обработку заявки, согласование договора, закупку или найм сотрудника. Если сразу охватить работу всего отдела, придется одновременно разбирать много связанных правил, ролей и исключений.
При выборе процесса важно смотреть не только на количество ручных действий. Чтобы понять, какие еще признаки учитывать, можно обратиться к исследованию по отбору процессов для RPA — автоматизации повторяющихся действий с помощью программных роботов.
Исследование провели специалисты немецкого университета FH Aachen и IT-компании Gothaer Systems. Они изучили, по каким признакам можно определить, подходит ли процесс для такой автоматизации. Самый высокий вес получили три критерия:
И хотя исследование касается RPA, эти критерии применимы к автоматизации в целом, поэтому при первом отборе стоит проверить:
Например, менеджер несколько раз в день переносит заявки из формы в рабочую систему и назначает исполнителя по одному и тому же правилу. Здесь повторяются и само действие, и условия назначения, поэтому их можно формализовать.
Другой пример — сотрудник два раза в год за несколько минут собирает небольшой отчет. Затраты на настройку и поддержку автоматического правила могут оказаться выше экономии времени.
При этом редкий процесс не обязательно нужно исключать. Например, раз в месяц сотрудник целый рабочий день собирает отчет из нескольких систем по одной и той же схеме. Хотя работа повторяется редко, автоматизация части действий может освободить до нескольких рабочих дней в год, поэтому такой процесс тоже стоит рассмотреть.
До подробного описания нужно определить, где процесс начинается и заканчивается. В противном случае его границы быстро размываются. Например, при разборе согласования договора в процесс можно постепенно включить подготовку документа, переговоры с контрагентом, подписание, оплату и дальнейшее исполнение обязательств, хотя это уже отдельные участки работы.
Для определения границ процесса Purdue MEP, центр Purdue University в национальной сети NIST по развитию и улучшению производственных процессов, рекомендует использовать SIPOC. Это схема, которая помогает описать процесс на верхнем уровне. В ней фиксируют пять элементов: 
SIPOC обычно выглядит как простая таблица из пяти колонок. Каждая колонка отвечает на один вопрос о процессе. Например, для подготовки ежемесячного отчета SIPOC может выглядеть так:
На этом этапе не нужно расписывать каждое действие сотрудников. Достаточно определить, с какого события начинается процесс, каким результатом заканчивается и кто получает этот результат.
После определения границ восстановите фактический порядок работы. Такое описание часто называют моделью AS IS, то есть состоянием «как есть».
Сверьте регламент с практикой. Порядок работы часто закрепляют в регламенте, чтобы сотрудники понимали, какие действия и в какой последовательности выполнять. Но для модели AS IS одного регламента недостаточно: по нему не всегда можно понять, что происходило с конкретными задачами на самом деле.
Например, по регламенту инициатор договора сначала передает документ юристу, после согласования — бухгалтеру, а затем руководителю. На практике часть договоров сотрудники сразу отправляют руководителю, отдельные вопросы согласуют в чате, а при задержке сами напоминают ответственному о проверке.
Разберите несколько завершенных задач. Если команда ведет работу в CRM, таск-трекере или другой системе, часть информации можно взять из истории действий. Для каждой задачи проверьте:
Выделите основной маршрут и повторяющиеся исключения. Например, большинство заявок может сразу переходить от менеджера к исполнителю, часть — требовать дополнительного согласования, а заявки без обязательных данных — возвращаться клиенту.
Такой порядок можно зафиксировать в таблице или на блок-схеме. Независимо от формата важно показать не только основной маршрут, но и регулярные отклонения: возврат на доработку, дополнительное согласование или переход на другой этап.
Если схему будут использовать бизнес-аналитики и разработчики, процесс можно оформить в BPMN — стандартном формате для изображения этапов, участников и переходов между ними.
После описания текущего порядка проверьте сам процесс: какие этапы стоит сохранить или убрать, а какие действия можно автоматизировать либо сначала изменить. Один и тот же недостаток процесса может быть связан с разными причинами, поэтому начинать сразу с настройки правил не стоит.
Например, компания хочет сократить время согласования договоров. Причины задержек могут быть разными:
Поэтому перед настройкой каждого участка проверьте две вещи:
Так команда перенесет в систему согласованный порядок работы без лишних этапов и спорных правил.
После разбора текущего процесса и проблемных участков соберите обновленный порядок работы. Возьмите описание AS IS за основу и внесите изменения, о которых договорилась команда: уберите лишние этапы, уточните ответственность и зафиксируйте новые правила передачи задач.
Чтобы участники одинаково понимали процесс, уточните основные элементы:
Отдельно отметьте этапы, где результат зависит от оценки сотрудника. Например, юрист проверяет договор и определяет, можно ли его согласовать без изменений или нужно вернуть инициатору на доработку. В описании процесса нужно зафиксировать оба варианта: кто проводит проверку и куда договор переходит после каждого результата.
Назначьте владельца процесса. Он следит за процессом целиком: согласует изменения правил, контролирует показатели и помогает решить вопросы на стыке подразделений. Если порядок работы меняется, владелец следит, чтобы команда обновляла описание процесса после таких изменений.
После этого можно переходить к следующему шагу и решать, какие действия внутри нового порядка стоит автоматизировать.
Когда команда определит новый порядок работы, пройдите его по этапам и отметьте места, где конкретное событие должно запускать заранее определенное действие.
Для каждого такого места составьте правило из трех частей. Разберем на примере договора, который нужно передать руководителю, если сумма превышает установленный лимит:
По такому же принципу можно описать назначение исполнителя, изменение статуса, отправку уведомления, добавление чек-листа или создание повторяющейся задачи.
В результате у команды получится список конкретных правил, каждое из которых связано с конкретным событием или этапом процесса.
Перед переносом процесса в систему проверьте:
Если на все вопросы есть однозначные ответы, можно переходить к пилоту и проверять новый порядок на реальных задачах.
Новый порядок лучше сначала проверить на части реальных задач, а уже потом распространять на весь процесс. Такой подход соответствует циклу PDCA: изменение планируют, тестируют в небольшом масштабе, оценивают результат и при необходимости корректируют.
Определите границы пилота. Для проверки можно выбрать одну команду, одно подразделение или часть входящих задач. Объема должно хватить, чтобы проверить основной маршрут и типичные отклонения от него.
Зафиксируйте исходный показатель. До запуска определите, по какому показателю будете оценивать результат, и запишите его текущее значение. После пилота сравните новые данные с исходными.
Показатель зависит от того, что команда хочет изменить:
Проверьте, как процесс работает после изменений. Одного итогового показателя недостаточно: посмотрите, правильно ли задачи переходят между этапами, хватает ли сотрудникам данных и не появились ли новые задержки.
Если результат улучшился и пилот не выявил новых проблем, новый порядок можно распространить на больший поток. Если нужного эффекта нет, скорректируйте процесс и проведите еще одну проверку.
До этого мы разбирали подготовку к автоматизации. Теперь покажем, как настроить такой порядок на примере Кайтена — платформы для комплексного управления работой компании.
Сначала перенесите в систему новый порядок работы. В Кайтене можно создать столько колонок, сколько этапов есть в процессе, и назвать колонки по этапам, которые команда определила при подготовке к автоматизации. 
За счет этого на доске можно отразить на доске свой порядок работы без привязки к базовой структуре, которую предлагает система. Например, для согласования документов можно создать отдельное пространство, где каждая колонка соответствует своему этапу:
Конкретный договор ведут в отдельной карточке и перемещают между колонками по мере согласования. В полях карточки можно хранить данные, от которых зависит дальнейший маршрут, например сумму договора, если от нее зависит участие руководителя.
Можно не собирать пространство с нуля. В галерее Кайтена есть готовые пространства для разных процессов. Шаблон можно импортировать, а затем изменить этапы, типы карточек и другие элементы под свой порядок работы.
Настройте правила для отдельных переходов и действий. В Кайтене правило можно запустить после создания или перемещения карточки, изменения данных, выполнения чек-листа, появления комментария или наступления определенного срока. К событию можно добавить условия, чтобы правило срабатывало только для нужных карточек.
Например, событием может быть переход карточки на этап согласования. Если тип карточки — «Договор», а сумма выше лимита, можно назначить руководителя ответственным, поставить срок и переместить карточку на нужный этап. Для одного события можно настроить сразу несколько действий и указать порядок их выполнения.
Не каждую цепочку нужно запускать по событию. В Кайтене можно добавить в карточку кнопку и привязать к ней несколько действий. Такой вариант подойдет, когда сотрудник сам определяет момент срабатывания: например, после проверки нажимает «Передать на согласование», чтобы карточка перешла на другой этап и чтобы у нее назначились ответственный и срок.
Для регулярных задач есть отдельная настройка. Если команда регулярно создает одинаковые задачи — например, раз в неделю или раз в месяц, — для них можно настроить создание карточек по расписанию . Это пригодится, например, для регулярных отчетов, проверок или других типовых работ.