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

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

Если вам тревожно уходить в отпуск — это тоже оно. Это ваши знания куда-то не переложены.

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

Ещё два признака: мелкое изменение приводит к резкому увеличению трудоёмкости — и никто точно не знает, кто и в какой конкретно момент принимает решение.

Попробуйте проверить процесс на роботизируемость:

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

Сразу скажу, компаний без кривых процессов в принципе не бывает, как и компаний без техдолга.

Это примерно одно и то же. И подход один и тот же — надо вовремя что-то с этим делать. Лучше раньше.

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

Подробнее, как такие процессы появляются

Процесс заменён на личные договорённости

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

Она ушла — и ломается всё. Без неё никто не может найти документы, понять, кому именно направлять документ на согласование и почему директор так долго не подписывает.

Если в компании уйдёт сразу четыре Антонины Семёновны, то затраты на онбординг увеличатся больше, чем в 4 раза. Возрастут цена и количество ошибок. Ну и ещё где-то месяц отдел будет стоять.

Никто не трогал эту часть «техдолга»

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

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

«Следующая неделя» длится уже 2–3 года.

Так быстрее или удобнее кому-то

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

Почему такая форма отчёта — никто точно не знал.

Для чего он нужен — эти знания пропали 5 лет назад.

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

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

Слияние

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

Такие процессы в один прекрасный день тоже станут узким местом.

Хочется что-то спрятать

Часто кто-то пытается (не всегда из плохих побуждений) скрыть использование какого-то ресурса.

Здесь важно понимать, что это за ресурс, кто его контролирует, а кто пытается движение этого ресурса спрятать.

Наиболее характерный пример: когда хотят сохранить сотрудников — скрывают экономические эффекты их работы. Ведь жалко же. Особенно перед пенсией.

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

«Так быстрее»

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

3–4–5 сценариев

Часто бывает такое, что если раскопать процесс, то окажется, что внутри целых 3, 4 или 5 сценариев выполнения процесса, при одинаковых входных данных. Это бывает при объединении нескольких процессов в один (например, документооборотов отделов, которые соединили в один) или просто потому, что когда-то процессы задокументировали по-разному.

Из этих форков выбирается лучшая версия (или собирается из частей) и запускается как оптимальная.

Какие процессы лучше всего так проверять?

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

Легче всего автоматизируется типичная операционка: обработка первичных документов, формирование отчётов, двойной ввод в информационные системы.

Характерные признаки:

• Стандартный результат каждый раз без сюрпризов.
• Циклическое исполнение — повторяющаяся рутина.
• Этапы исполнения регламентированы (если повезёт).
• Исполнители и их квалификация определены, то есть заранее точно известно, что исполнитель может всё правильно сделать.

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

Ну понятно, а делать-то что?

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

• Если роботизировать дороже, чем потенциальная экономия, то не стоит даже пытаться. Ну знаете, классно же 8 часов писать код, который позволит за 5 минут сделать то, что один раз заняло бы 6 часов.
• Надо смотреть, как часто меняется процесс. Постоянно меняющиеся процессы = постоянные затраты. Если процесс нестабилен, то его придётся постоянно дорабатывать и дополнительно вкладываться.
• Есть процессы, которые вообще роботизировать нельзя. Например, чтобы сделать процесс одинаковым для всех, нужно сделать столько изменений и собрать столько людей вместе, что лучше не трогать. Работает — не трогайте!

Точно надо:

• Процесс вообще непрозрачен. Есть ресурс, он куда-то уходит, уходит его много, а понять, куда конкретно он уходит, какие ошибки при этом совершаются и где его контрольные точки — невозможно. Тогда надо как минимум сделать что-то вроде мониторинга процесса. А чтобы сделать мониторинг, надо что-то считать. А чтобы что-то считать, надо разбить процесс на понятные шаги и типизировать вход-выход в каждый такой шаг. То есть да, почти как роботизация.
• Если есть единственный хранитель знаний и всё упирается в него. Это классика «автобусного фактора».
• Когда хочется больше порядка, например, чтобы быстрее погружать новых людей в процесс и не повторять словами одно и то же по 200 раз. Вообще, хороший симптом — когда вы что-то объясняете второй раз, спросите себя, зачем вы это делаете вместо того, чтобы написать инструкцию.

Как распутывать?

Есть несколько типичных вопросов:

— С чего начинается процесс?

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

— Сколько сотрудников выполняют этот процесс? А вы все так делаете?

Кто-то точно будет делать по-другому. Часто встречается кейс с формированием индивидуального реестра под каждую компанию. Или пять сделают одного вида, пятнадцать другого и один третьего.

— Кто согласующий?

Самый болезненный вопрос для многих простых процессов. Относится к «тайным знаниям», обычно не содержится ни в одной инструкции и неподвластен таблицам мэппинга.

— Методики расчёта и шаблоны документов утверждены или планируются изменения?

Здесь может оказаться, что прямо сейчас идёт согласование, оно немного затягивается, ведь запустили его полгода назад. И вообще методика расчёта дохода утверждена только для 2 компаний. А в периметр надо брать все.

— Есть инструкция?

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

— А сейчас процесс выполняется эффективно?

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

Примеры процессов

• Люди перестали в конверты запаковывать 7 тысяч писем.
• Больше не нужно делать по 2,5 тысячи приказов на отпуск ежемесячно.
• 75 процентов платежей можно выравнивать и разносить и без замученного бухгалтера.
• Около 19 тысяч сертификатов качества на трубную продукцию формируются роботом, а это больше 85 процентов.

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

И что, потом меняем человека на робота?

Иногда просто отделу становится сильно легче.

Иногда звено, которое тормозит и саботирует процесс, нужно просто снять.

Иногда получается забрать на RPA часть рутины. Мы пишем робота, имитирующего деятельность человека. Поскольку всё формализовано и алгоритмизируемо, он может делать то же самое. В результате получается дополнительный сотрудник с идеальной памятью, который может работать 24/7, выполнять работу во много раз быстрее человека и не допускать ошибок по невнимательности. Правда, очень тупой, поэтому ему нужны очень точные инструкции.

Так вот, если вы способны объяснить такому сотруднику, как работает процесс, — он точно хороший.