Последние полтора года я искала дыры в процессах. Принцип очень простой: если у вас достаточно хорошая документация, чтобы взять и переложить процесс на робота, всё ок. Если роботизировать не выйдет — процесс плохой и он сломается.
Почему так? Ну например, уйдёт на больничный единственный человек, который знает, как что-то делать. И всё. Если знания хранятся не только в его голове, это не проблема. То есть должна быть инструкция или что-то похожее — а это значит, что можно роботизировать по такому артефакту.
Если вам тревожно уходить в отпуск — это тоже оно. Это ваши знания куда-то не переложены.
Если вашу работу можно было бы роботизировать (хотя бы в теории), то пускай с качеством ниже, но она выполнялась бы.
Ещё два признака: мелкое изменение приводит к резкому увеличению трудоёмкости — и никто точно не знает, кто и в какой конкретно момент принимает решение.
Попробуйте проверить процесс на роботизируемость:
- Все данные должны быть в электронном виде.
- На входе в процесс каждый раз один и тот же набор данных без творческих дополнений. На выходе тоже всегда одинаковый вывод — без творческих решений.
- Есть чёткий набор действий, которые можно описать алгоритмом.
- Процесс легко поддерживается, то есть не меняется каждый день.
Сразу скажу, компаний без кривых процессов в принципе не бывает, как и компаний без техдолга.
Это примерно одно и то же. И подход один и тот же — надо вовремя что-то с этим делать. Лучше раньше.
Самые частые ситуации в моей практике, когда надо отлаживать такие процессы, — это потому что исторически сложилось, потому что лучше жить в хаосе, чем разбираться, потому что кто-то хочет стать незаменимым. Один большой набор крайне кривых процессов я разбирала после слияния-поглощения компаний, когда одинаковые вещи делались по-разному.
Подробнее, как такие процессы появляются
Процесс заменён на личные договорённости
Абстрактная Антонина Семёновна давно работает в компании, и со многими отделами у неё сложились негласные договорённости. То есть процессы, которые она использует, подходят только для неё лично. Когда приходит новый человек, она с ним заново договаривается и заново объясняет, что и как. В этой схеме всё прекрасно и быстро работает до тех пор, пока, например, она не уходит на больничный.
Она ушла — и ломается всё. Без неё никто не может найти документы, понять, кому именно направлять документ на согласование и почему директор так долго не подписывает.
Если в компании уйдёт сразу четыре Антонины Семёновны, то затраты на онбординг увеличатся больше, чем в 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, выполнять работу во много раз быстрее человека и не допускать ошибок по невнимательности. Правда, очень тупой, поэтому ему нужны очень точные инструкции.
Так вот, если вы способны объяснить такому сотруднику, как работает процесс, — он точно хороший.