Павел Ульихин, ОМК: «Важно вовлекать заказчика не только на старте роботизации, но и после»

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

Справка о компании: Объединенная металлургическая компания (ОМК) – одна из крупнейших промышленных компаний России и комплексный поставщик решений для экономики. Компания занимается производством труб различного диаметра и назначения, производством рессор для грузового транспорта, колес для железнодорожного транспорта, ремонтирует подвижные составы, производит трубопроводы для атомных станций, а также металлоконструкции различного назначения.

ОМК – лидер по инвестициям в промышленность и социальную сферу регионов среди трубных компаний. Уже осуществленные вложения и текущая инвестпрограмма ОМК составляет более 350 млрд руб. ОМК развивает среду городов, где расположены ее предприятия, реализует социальные проекты. На развитие регионов ОМК направила уже более 10 млрд руб. ОМК снижает свой экологический след благодаря применению совершенных природоохранных и энергосберегающих технологий. Стратегическая цель – снижение антропогенной нагрузки на 3% ежегодно. ОМК – это более 33 тысячи высокопрофессиональных сотрудников, объединенных общими корпоративными ценностями.

Как отобрать подходящие процессы для программной роботизации?

Основной критерий отбора – правила. Решения о том, какие процессы роботизировать, должны быть основаны на правилах и регламентах. Субъективные решения в расчет не берутся. Второй критерий – стабильность программного обеспечения ИТ-системы, с которой работает робот, и стабильность самих процессов. Отсутствие такой стабильности не является стоп-фактором, но нужно понимать, что при изменении системы или процессов робот вряд ли поймет, как ему моментально подстроиться под изменения. Скорее всего, понадобится его доработка, что, в свою очередь, потребует дополнительных ресурсов и негативно скажется на окупаемости и эффективности. Третий критерий – данные. Они должны быть цифровыми и, желательно, структурированными, чтобы робот понимал, как их воспринимать и что с ними нужно делать.

Этапы роботизации и воронка процессов

При выборе процессов для роботизации мы в первую очередь собираем все заявки, которые поступают от бизнеса, либо самостоятельно ищем подходящие процессы. В последнее время мы практически не занимаемся самостоятельным поиском процессов. Более 90% процессов, которые мы анализируем с точки зрения возможности роботизации, поступают непосредственно от бизнеса. Это либо создание новых роботов, либо улучшение уже существующих. Когда мы только начинали заниматься роботизацией, ситуация была кардинально противоположная, что порождало много проблем: бизнес боялся, что роботы их заменят и скептически оценивал пользу от новой технологии, не желал сотрудничать с нами. Соответственно, сейчас мы поступаем по-другому – рассказываем о роботах и показываем, что они могут стабильно работать и приносить пользу своему заказчику и компании в целом. В ответ мы получаем заинтересованного бизнес-заказчика.

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

Оценка трудозатрат на реализацию

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

Оценить трудозатраты можно двумя способами: экспертной оценкой и автоматической. Экспертная оценка подразумевает оценку человеком, а автоматическая – соответствующим «калькулятором» трудозатрат.

Калькулятор трудозатрат

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

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

Последний момент, который важно внести в таблицу, – ИТ-системы и приложения, с которыми работает робот (их количество, насколько сложное взаимодействие с роботом, возможность использования API, опыт разработчика с этой системой). Одно дело, когда робот просто нажимает на кнопку «ОК» на всплывающем окне и переходит на следующий шаг, и другое дело, когда он в отчете должен считать цвет индикатора и в зависимости от этого пойти по нужному сценарию.

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

Другие важные факторы для выбора процесса

Во-первых, важно понимать – это новый процесс или доработка старого. Такое редко бывает, но предположим, что технические характеристики у них сопоставимы. В таком случае доработка старого всегда будет предпочтительнее, потому что у разработчиков и аналитиков уже есть понимание об этом процессе, настроено взаимодействие с заказчиком. С новым же процессом могут возникнуть сюрпризы. У нас иногда бывает, что приходит бизнес-заказчик и просит роботизировать не существующий процесс, а тот, которого еще нет. Это большой риск, и к таким вещам нужно быть очень внимательным.

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

Как оценить окупаемость робота?

Период окупаемости – это срок, который требуется, чтобы были полностью возмещены первоначальные инвестиции. Можно считать, что это соотношение затрат к эффекту. Например, нам, чтобы сделать робота, нужно 100 рублей, а эффект от него – 50 руб. Делим одно на другое и получаем 2 – значит, робот будет окупаться 2 года. Важно отметить, что ввиду того, что мы редко делаем роботов, которые долго окупаются, дисконтирование в расчетах не учитываем, чтобы их не усложнять.

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

Что можно считать затратами?

Первое, самое простое и понятное, – трудозатраты на разработку. Как можно оценить трудозатраты на разработку, мы уже обсудили выше. Второе – трудозатраты на поддержку. С этим сложнее, поскольку до того, как процесс перешел в опытно-промышленную эксплуатацию, сложно оценить трудозатраты на его дальнейшую поддержку. Их необходимо оценивать и закладывать экспертным или опытным путем. Третье – лицензии на роботов (RPA).

Четвертое – сопутствующие трудозатраты. Иногда, чтобы робот полноценно заработал в процессе, нужно доработать саму систему. Для этого мы привлекаем коллег, которые занимаются поддержкой этих систем. На это тратится их время, ресурсы. Они тоже стоят денег, поэтому эти затраты нужно учитывать. Пятое – сопутствующие лицензии. Бывает такое, что робот тратит лицензии, чтобы работать в какой-то системе. И это тоже нужно учитывать. Шестое и последнее – серверные мощности. Конечно же, они тоже не бесплатные.

Что можно считать эффектами?

Первое, наиболее очевидное, – это экономия так называемых «транзакционных трудозатрат». Это трудозатраты в рутинном, часто повторяющемся процессе. Обычно роботов делают ради экономии именно таких трудозатрат. Второе – экономия разовых трудозатрат. На них зачастую не обращают внимания при анализе процесса, но на самом деле есть кейсы с задачей разовой, но настолько масштабной, что проще сделать робота на один раз и забыть про него, чем выполнять работу вручную.

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

Четвертое – стоимость лицензий. Например, у нас есть кейсы: люди работают в платном программном обеспечении, но не постоянно, а от случая к случаю. И проще дать одну лицензию роботу, чем покупать каждому работнику по лицензии. Сотрудники будут передавать этому роботу задачи по почте, после чего он будет выполнять их, используя свою лицензию. Это позволит сэкономить на лицензиях. 

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

Факторный анализ

Заключительный, но очень важный этап – проведение факторного анализа по результатам внедрения робота. Без фактических данных того, как робот справляется с задачами, невозможно понять результат его работы. Фактические данные имеет смысл измерять спустя 3-6 месяцев после перевода робота в промышленную эксплуатацию. Обычно к этому времени завершается период стабилизации и сотрудники заказчика привыкают взаимодействовать с роботом.

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

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

Следующий фактор – изменение нормативов. Например, в процессе разработки робота мы понимаем, что изначальный норматив, по которому считался плановый эффект, оказался неактуальным или некорректным. И робот сейчас приносит другой эффект ввиду того, что эта операция занимала бы у человека другое время. Это тоже является фактором отклонения эффектов.

Третий фактор – изменение количества бизнес-исключений. Например, предполагалось, что на робота будет направляться 100 документов первого, второго и третьего типа, но третий тип он по каким-то причинам не сможет обработать, мы это знаем и закладываем в функционал робота отправку документов этого типа на обработку сотрудникам заказчика. При разработке закладывали 20% таких документов от общего потока, но фактически их оказалось 30%. Из-за того, что робот их не обрабатывает, его эффективность снизилась. В этом случае необходимо вернуться к изначальной оценке и понять, почему пропорция поменялась.

На эффективность влияет также количество системных ошибок робота. Он взаимодействует с программным обеспечением, которое работает не идеально, и могут возникать сбои. Также сбои могут происходить в самом роботе. При оценке эффектов мы сразу закладываем некоторый процент таких ошибок. Т.е. мы понимаем, что иногда робот будет сбоить. Например, мы предполагаем, что с 1С робот работает хуже, чем с SAP. Соответственно, процент ошибок для процессов с 1С мы закладываем больше. Но может оказаться, что мы ошиблись, и робот стал работать гораздо лучше и ошибок стало меньше. Это тоже нужно понимать и отразить в анализе.

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

Павел Ульихин, руководитель практики бизнес-аналитики и роботизации процессов, ОМК

Комментарии