Практический опыт эксперта: о причинах проблем, а также когда и как можно забрать на RPA часть рутины.
Последние полтора года я искала дыры в процессах. Принцип очень простой: если у вас достаточно хорошая документация, чтобы взять и переложить процесс на робота, всё ок. Если роботизировать не выйдет — процесс плохой и он сломается.
Почему так? Ну например, уйдёт на больничный единственный человек, который знает, как что-то делать. И всё. Если знания хранятся не только в его голове, это не проблема. То есть должна быть инструкция или что-то похожее — а это значит, что можно роботизировать по такому артефакту.
Если вам тревожно уходить в отпуск — это тоже оно. Это ваши знания куда-то не переложены.
Если вашу работу можно было бы роботизировать (хотя бы в теории), то пускай с качеством ниже, но она выполнялась бы.
Ещё два признака: мелкое изменение приводит к резкому увеличению трудоёмкости — и никто точно не знает, кто и в какой конкретно момент принимает решение.
Попробуйте проверить процесс на роботизируемость:
Сразу скажу, компаний без кривых процессов в принципе не бывает, как и компаний без техдолга.
Это примерно одно и то же. И подход один и тот же — надо вовремя что-то с этим делать. Лучше раньше.
Самые частые ситуации в моей практике, когда надо отлаживать такие процессы, — это потому, что так исторически сложилось, потому что лучше жить в хаосе, чем разбираться, потому что кто-то хочет стать незаменимым. Один большой набор крайне кривых процессов я разбирала после слияния-поглощения компаний, когда одинаковые вещи делались по-разному.
Кроме портала, мы предлагаем вам и альманах «Управление производством». Все самое интересное и уникальное мы публикуем именно в нем. 300+ мощных кейсов, готовых к использованию чек-листов и других полезных материалов ждут вас в полном комплекте номеров. Оформляйте подписку и получайте самое лучшее!
Абстрактная Антонина Семёновна давно работает в компании, и со многими отделами у неё сложились негласные договорённости. То есть процессы, которые она использует, подходят только для неё лично. Когда приходит новый человек, она с ним заново договаривается и заново объясняет, что и как. В этой схеме всё прекрасно и быстро работает до тех пор, пока, например, она не уходит на больничный.
Она ушла — и ломается всё. Без неё никто не может найти документы, понять, кому именно направлять документ на согласование и почему директор так долго не подписывает.
Если в компании уйдёт сразу четыре Антонины Семёновны, то затраты на онбординг увеличатся больше, чем в 4 раза. Возрастут цена и количество ошибок. Ну и ещё где-то месяц отдел будет стоять.
Процесс был прописан, но немного поменялся первый раз, потом второй — а никто это не задокументировал. В результате в инструкции одно, а на практике другое. Это если повезёт и инструкция есть. Потом поменялась инфраструктура, например, архитектура сети стала чуть другой. В результате через 3 года по инструкции просто невозможно сделать то, что нужно. Все знания в головах у людей.
Конечно, надо сесть и записать всё это в документы и сохранить в базе знаний. Но подождите, у нас срочные дела, давайте на следующей неделе.
«Следующая неделя» длится уже 2–3 года.
Кому-то так удобнее, и всё тут. В моей практике был курьёзный случай, когда все элементы процесса сменились много раз, кроме одного. У нас одна очень опытная сотрудница как делала 10 лет табличку с отчётом одного вида, так и продолжала делать.
Почему такая форма отчёта — никто точно не знал.
Для чего он нужен — эти знания пропали 5 лет назад.
Она продолжала это делать. Судя по документации, это шло куда-то дальше. Мне пришлось найти концы, узнать, для чего она собирает данные — и оказалось, что часть из них уже не нужна, а часть можно не обрабатывать так сложно.
То есть просто смысл процесса заменился на традицию. Это случается достаточно часто. Часть жизни любого предприятия — регулярно проходить по организационным и производственным процессам и разбираться, почему тот или иной шаг делается именно так. И на что он влияет.
Большие компании присоединяют к себе компании, которые часто не могут прямо сейчас начать работать по утверждённому шаблону. Ну или пока не хотят. Работает же, зачем менять?
Такие процессы в один прекрасный день тоже станут узким местом.
Часто кто-то пытается (не всегда из плохих побуждений) скрыть использование какого-то ресурса.
Здесь важно понимать, что это за ресурс, кто его контролирует, а кто пытается движение этого ресурса спрятать.
Наиболее характерный пример: когда хотят сохранить сотрудников — скрывают экономические эффекты их работы. Ведь жалко же. Особенно перед пенсией.
Более редкий — когда исполнителю просто нравится то, что он делает и как он это делает, и он бы не хотел менять процесс на более подходящий для компании. Потому что тогда уже будет не так интересно.
Я всегда вздрагиваю от этой фразы. Но гораздо больше её боятся специалисты по технике безопасности. Их процесс сделан не для того, чтобы быстрее. В процессах, которые я разбираю, скорость тоже не всегда главный фактор. Иногда важнее снизить риски.
Часто бывает такое, что если раскопать процесс, то окажется, что внутри целых 3, 4 или 5 сценариев выполнения процесса, при одинаковых входных данных. Это бывает при объединении нескольких процессов в один (например, документооборотов отделов, которые соединили в один) или просто потому, что когда-то процессы задокументировали по-разному.
Из этих форков выбирается лучшая версия (или собирается из частей) и запускается как оптимальная.
Речь здесь идёт о рутинных процессах, которых в организации больше, чем может показаться на первый взгляд. Это такие повторяющиеся действия, которые занимают много времени — и которые можно заменить на робота при определённом старании. Что иногда и происходит.
Легче всего автоматизируется типичная операционка: обработка первичных документов, формирование отчётов, двойной ввод в информационные системы.
Характерные признаки:
Стандартный результат каждый раз без сюрпризов.
Таких процессов очень много в клиентских центрах, финансовых и бухгалтерских отделах и отделах кадров.
Во-первых, такой процесс можно не трогать. Потому что иногда не надо. Как банки живут со своим легаси без рефакторинга, потому что дороже, так и некоторые процессы можно потерпеть. Вот основные причины терпеть:
Если роботизировать дороже, чем потенциальная экономия, то не стоит даже пытаться. Ну знаете, классно же 8 часов писать код, который позволит за 5 минут сделать то, что один раз заняло бы 6 часов.
Надо смотреть, как часто меняется процесс. Постоянно меняющиеся процессы = постоянные затраты. Если процесс нестабилен, то его придётся постоянно дорабатывать и дополнительно вкладываться.
Есть процессы, которые вообще роботизировать нельзя. Например, чтобы сделать процесс одинаковым для всех, нужно сделать столько изменений и собрать столько людей вместе, что лучше не трогать. Работает — не трогайте!
Точно надо:
Есть несколько типичных вопросов:
Один из самых сложных вопросов. Часто бывает понятно, как процесс выполняется и что мы получаем на выходе. Самый сложный случай, когда входные данные записываются в тетрадочку, а потом обрабатываются в системе.
Кто-то точно будет делать по-другому. Часто встречается кейс с формированием индивидуального реестра под каждую компанию. Или пять сделают одного вида, пятнадцать другого и один третьего.
Самый болезненный вопрос для многих простых процессов. Относится к «тайным знаниям», обычно не содержится ни в одной инструкции и неподвластен таблицам мэппинга.
Здесь может оказаться, что прямо сейчас идёт согласование, оно немного затягивается, ведь запустили его полгода назад. И вообще методика расчёта дохода утверждена только для 2 компаний. А в периметр надо брать все.
Если да, то нам повезло. Если нет, то сотрудники могут интерпретировать процесс по-своему и выполнять его, как научились. В этом случае придётся найти эталонное выполнение.
Роботизация не «серебряная пуля». Сначала процесс должен быть выстроен, чтобы повышать его эффективность. Вполне возможно, что мы планируем документировать заведомо неэффективный процесс.
Ещё есть пример, как делать не надо. Не надо сокращать количество людей до такой степени, что владельца процесса просто не остаётся. Иначе можно столкнуться с тем, что всё как-то хорошо работало, потом робот сломался, а эксперта, который бы разобрался с этим, просто нет. Со своей стороны мы этот риск закрываем документацией.
Иногда просто отделу становится сильно легче.
Иногда звено, которое тормозит и саботирует процесс, нужно просто снять.
Иногда получается забрать на RPA часть рутины. Мы пишем робота, имитирующего деятельность человека. Поскольку всё формализовано и алгоритмизируемо, он может делать то же самое. В результате получается дополнительный сотрудник с идеальной памятью, который может работать 24/7, выполнять работу во много раз быстрее человека и не допускать ошибок по невнимательности. Правда, очень тупой, поэтому ему нужны очень точные инструкции.
Так вот, если вы способны объяснить такому сотруднику, как работает процесс, — он точно хороший.
Алена Буторина, Менеджер бизнес-аналитики и роботизации «ОМК-ИТ»
