Телеком-компании сегодня коренным образом пересматривают стратегии развития: их доходы снижаются и они вынуждены искать новые точки роста и максимально оптимизировать свои бизнес-процессы. Крупнейшая технологическая компания Казахстана — Beeline Казахстан провела масштабную роботизацию своих рабочих процессов. В результате внедрения RPA корпорации удалось сэкономить 60 000 человеко-часов и запустить школу по регулярной подготовке citizen developers из числа собственного персонала.
Внедрение RPA: начало
В декабре 2019 в Beeline Казахстан запустили пилот по роботизации некоторых рабочих процессов. На сегодняшний день в компании роботизировали три подразделения: HR, финансовую дирекцию и колл-центр.
Когда специалисты Beeline выбирали вендора для RPA, они изучили «магический квадрант» Gartner по роботизации и увидели, что лидером в этой сфере является компания UiPath. Руководитель отдела по роботизации бизнес-процессов Александр Нуреев: «Мы не хотели рисковать и тратить много времени на изучение каждого RPA-решения, учитывая, что среди них есть и много стартапов. Выбрав не подходящее решение, мы могли бы разочароваться в самой RPA-технологии, хотя на самом деле это была бы просто плохая реализация в конкретном продукте. Мы рассуждали так: если выбрать топовое решение, то оно гарантированно будет работать стабильно и будет обеспечено максимальным объемом полезной функциональности».
Запускал программу по роботизации в компании один человек — Александр Нуреев, который прошел обучение в академии UiPath, а чуть позже к нему еще присоединился стажер.
На старте не было понимания какие процессы в компании нужно роботизировать. Их искали тривиальным способом — проводили интервью с сотрудниками из подразделений телеком-оператора. За неделю удалось выявить 10 потенциально подходящих для роботизации процессов, из которых потом выбрали всего три. Один из них был связан с бухгалтерией и сверкой excel-файлов, другой — с закупками и занесением данных о поставщиках в ERP-систему.
После того, как эффективность первых роботизированных процессов подтвердилась, был создан отдел RPA-разработки с выделенными штатными специалистами.
В августе 2020 эксперты Beeline Казахстан совместно с коллегами из UiPath стали консультировать другие компании, как внедрять у себя роботизацию бизнес-процессов.
На сегодня в телеком-операторе роботизировано более 256 процессов, что экономит нам 60 000 человеко-часов в год, а в команде RPA-разработчиков работает 30 человек.
Вот как выглядит таймлайн развития программы роботизации в компании:
Внедряем роботов: первые успехи
Целью внедрения RPA в компании было убрать монотонные процессы, от которых устают люди.
Самый первый процесс, который роботизировали — закупочный, потому что он очень простой. Его полную автоматизацию удалось провести всего за 3 недели. На роботизацию следующего более сложного процесса — сверку excel-файлов — потребовалось уже 2 месяца.
В компании есть процесс, когда проводится оповещение о чрезвычайных происшествиях или штормовых предупреждениях. Как оператор сотовой связи мы получаем рассылку МЧС. Оно направляет уведомление операторам, чтобы те делали СМС-рассылку всем жителям региона. Если в установленные сроки рассылка не проводится — оператор может получить штрафы со стороны контролирующих органов. Для этих целей в Beeline Казахстан круглосуточно дежурили специальные сотрудники, которые контролировали эти рассылки.
Был создан робот, который при получении информации от МЧС по ключевым словам проверяет, что это сообщение подходит для рассылки, затем определяет сегмент целевой аудитории и запускает ее. Таким образом, внедрение RPA сняло с коллег стресс и упростило работу целого отдела.
Новые корпоративные клиенты приходят к оператору сразу с требованиями по количеству подключаемых номеров. Из-за ограничений биллинга нужно каждый корпоративный номер создавать отдельно. Для каждого нового номера нужно прописать до 40 параметров, регламентирующих его работу, иначе он будет приносить убытки. В компании работал целый отдел, который обрабатывал информацию по каждому корпоративному номеру. Причем любая ошибка здесь могла привести к нехорошим последствиям. Для этих целей создали программного робота, который помог с этим справиться.
Средствами разработки это реализовать было нельзя, в частности потому что здесь не было API. А технология RPA очень хорошо сработала, потому что умеет взаимодействовать через интерфейс с этой legacy-системой.
Вендор, чтобы добавить возможность массовой активации номеров, запросил доработку стоимостью в 500 000 долларов. С помощью UiPath мы сделали это бесплатно за 3 недели.
Внедряем роботов: первые сложности
На пути внедрения программных роботов возникали типичные барьеры.
Барьер #1
Когда мы начали внедрять RPA, многие сотрудники думали, что их начнут увольнять. В компании провели серию вебинаров, на которых специалисты центра компетенций объясняли, что же такое технология RPA. Чуть позже к ним подключился HR-отдел и сделал поддержку этой программы с помощью СЕО Евгения Настрадина. Он лично говорил, что программа нацелена на сокращение монотонной работы, но никак не на сокращение персонала.
Вместе с HRD была проработана стратегия по организации внутренних школ роботизации. Сотрудники, которые потенциально могли освободиться от своей работы, гарантированно могли попасть в эту школу — чтобы переучиться и получить новые навыки. Например из бухгалтера в java-программиста.
Барьер #2
Сначала было непросто искать процессы, пригодные для роботизации. В компании решили эту задачу с помощью Lean-портала. Все сотрудники знали, что если возникает идея как можно оптимизировать тот или иной процесс — можно зайти на сайт и там ее опубликовать. И туда же добавили блок для подачи идеи на роботизацию процесса. Если до интеграции с сайтом центр компетенций получал по 3-4 идеи на почту в месяц, то после — по 30-35 новых идей для роботизации процессов.
Как запустили интенсив по роботизации и школу RPA
Эксперты центра компетенций разработали две программы обучения, чтобы найти интернов внутри компании, которые бы могли научиться делать роботов. Интенсивное обучение — 14 дней. И вторая программа — фундаментальное обучение.
Для запуска интенсива сделали лендинг и опубликовали в интернете, сделали анонсы во внутренних соцсетях. Из 4000 сотрудников желание выразили 150 человек. Победители марафона официально становились разработчиками RPA. По первичным требованиям из них отобрали 70 человек для дальнейшего обучения. Для обучения теории по роботизации использовали контент из академии UiPath. До конца марафона добралось 15 финалистов-интернов. Помимо теории, они за время обучения роботизировали какой-то один из своих рабочих процессов.
Через полгода многие из интернов перешли в джунов.
После интенсива запустили фундаментальную школу RPA. Совместно с образовательным партнером разработали структуру обучения и создали контент. Запустили лендинг и объявили набор студентов. Один из плюсов UiPath Academy — комьюнити-версия, которая позволяет бесплатно запускать роботов здесь и сейчас.
Итоги и перспективы
С конца 2019 в Beeline Казахстан роботизировали 256 бизнес-процессов, которые стали работать в 2-3 раза быстрее, причем некоторые — круглосуточно. Людей оператор не сокращает, а использует программы рескиллинга и апскиллинга. Первое — это переобучение в школе роботизации — сотрудники осваивают там Python или Java. Второе — это, когда сотрудник, не меняя текущее место, использует RPA в своей работе.
Недавно оператор ввел 3 месяца моратория на роботизацию: новые процессы не автоматизировали, а только улучшали качество уже роботизированных.
Сейчас в Beeline Казахстан роботизируют только сложные процессы, которые экономят более 100 часов. Например, складской процесс на выдачу оборудования для базовых станций. Сотрудником службы строительства сети заводится заявка в ERP на выдачу оборудования. Данные для ERP берутся из Excel-файлов. Каждая такая заявка заводится вручную 15-20 минут. В день их бывает более 20 штук.
Роботизация: планы на ближайшее будущее
В стадии разработки находится еще роботизации пары бизнес-процессов.
Автоматизация проверки обходных листов
Обходной лист при увольнении, в котором фиксируется, что за сотрудником нет никакого оборудования. Робот проверяет архив Excel-файлов и дает информацию по числящемуся оборудованию.
Роботизация мониторинга тендеров
Для процесса тендерных закупок был создан робот, который по ключевым словам мониторит тендеры на сайте госзакупок, и присылает уведомления, если находит подходящие. Теперь не нужно ежечасно проводить мониторинг в сети.
Комментарии (12)
sse
15.11.2021 17:16+2Если вы не сокращаете, а переобучаете людей, то выходит, что вы начинаете а) платить больше ФОТа более квалифицированным сотрудникам б) добавляете ФОТ тех, кто настраивает роботов и в принципе участвовал в процессах - например, отвлекаясь от основной работы в) платите за лицензии владельцу RPA ПО, правильно я понял?
То есть внедрение RPA не уменьшает ФОТ, а увеличивает?
Можете рассказать, какие количественные показатели были поставлены по целям до запуска внедрения RPA?
alex-aa-jr
15.11.2021 22:01+1Спасибо за статью!
Почему была выбрана роботизация вместо автоматизации (и реализации на ЯП: Java, Python и т.д.)?
Кто занимается сопровождением роботизированных процессов?
Drazd
16.11.2021 20:55+1Роботизация - это по своей сути подраздел автоматизации. Главным преимуществом применения роботов является то, что они позволяют автоматизировать взаимодействие с разными системами за очень короткие сроки.
Не у всех систем и программ на свете есть API, а иногда оно на столько неудобное, что требует месяцев разработки и отладки интеграционных модулей, чтобы все работало "как часы". Тут возникает диссонанс - действие, которое нужно автоматизировать кодом через вызов методов API, пользователь делает в два клика (условно). Соответственно, с помощью RPA можно настроить робота, который будет делать эти самые два клика - и это будет очень быстрой разработкой.
А еще почему-то многие ошибочно думают, что "роботы" (RPA) - это только про "квадратики с действиями". На самом деле современные RPA-платформы, в частности UiPath, позволяют вам добавлять целые блоки кода на языках C#, VBNET в своих роботов, а при необходимости - подключать любые доступные .NET Framework и .NET Core библиотеки.
И зачастую наиболее правильным решением будет не "Только писать код" или "Только применять робота", а комбинировать оба подхода. Там где у вас есть компетенции в API и вы уверены, что сделаете интеграцию быстро - пишите код, там где есть понимание, что застрянете в болоте - используйте робота.
alex-aa-jr
18.11.2021 00:54Спасибо за ответ.
Скорость разработки - это преимущество, но как боретесь с изменением интерфейса систем и изменением функциональности? Ведь API - это всё-таки некий легальный контракт взаимодействия, который система предоставляет для других систем. И молча API, даже самописный, просто так не изменить - как правило API версионируется, остаётся (какое-то время) обратная совместимость со старыми версиями, и процесс не упадёт при добавлении новой версии и изменении какой-то сигнатуры методов.
В тоже время робот запрограммирован на выполнение кликов по определённым контролам. Меняется разметка веб страницы, меняется функциональность кнопки - и робот падает, процесс встаёт.
И встаёт вопрос о затратах на переделку робота + траты от простоя по процессу.
Это сообщение коррелирует с моим вторым вопросом про поддержку решений - на него ответ не получил. Кто поддерживает разработанные решения? Кто контролирует доработку решений? И ещё вопрос: есть ли процедуры ревьюирования решений с целью предотвратить изобретение велосипедов и использования роботов только ради использования роботов и с целью быстрой реализации? Как это происходит при таком большом количестве роботизируемых процессов?
Drazd
18.11.2021 02:03+1На самом деле ваши вопросы - довольно частые, и на них уже давно есть ответы. в частности по поводу изменчивости интерфейса можно почитать здесь: https://habr.com/ru/company/uipath/blog/577782/
Разработка новых процессов, доработка существующих, а так же поддержка в целом, как правило, осуществляется центром компетенций, который формируется внутри компании (или привлекается от интегратора). Финансовая сторона вопроса всегда должна быть просчитана еще до того, как вы вошли в эту историю и начали вкладывать средства в роботизацию. Каких-то универсальных цифр я вам не приведу, так как для каждого заказчика они индивидуальны.
Если вам и правда интересно узнать как построить качественный центр компетенций, который будет приносить выгоду компании, а не заниматься бесконечными исправлениями ошибок - стоит связаться с вашим аккаунт-менеджером в UiPath, а если вы еще не установили контакт - всегда можно обратиться через форму обратной связи на https://uipath.marvel.ru/
dbalabanov
16.11.2021 08:26Если в установленные сроки рассылка не проводится — оператор может получить штрафы со стороны контролирующих органов.
ещё бы штрафовать за ночные рассылки
Plovchik
16.11.2021 10:00Спасибо за статью и за подсказку с Uipath.
Но разве базовые программы учета не должны брать на себя заботы с работизацией/автоматизацией? ERP, 1C, SAP у них же есть доступные сервисы. Я веду к тому что не сложно будет сотрудникам работать в нескольких программах?
Drazd
16.11.2021 22:58+1У перечисленных систем далеко не всегда коробочные решения подходят для всего сразу. Они требуют доработки-донастройки. И не всё они умеют без индивидуальной разработки нового функционала. Тем более когда идет вопрос про взаимодействие с другими системами, сайтами, программами, которые либо являются не очень популярными (и не имеют шаблонных коннекторов), либо являются самописными разработками (далеко не лучшего качества).
Интеграция в таком случае - дорогостоящий долгосрочный проект, а роботизация с использованием таких платформ как UiPath позволяет это сделать в разы быстрее и надежнее.
Отдельно важно отметить, что роботы - это не "еще одна программа" для пользователя, а программа, которая эмулирует действия человека. Максимум, что делает сотрудник - это запускает робота (но обычно это происходит по определенному событию или расписанию без участия человека).
ArtyomMorozov1
17.11.2021 06:55закупочный, потому что он очень простой. Его полную автоматизацию удалось провести всего за 3 недели
Полную - вряд ли. Процесс формирования заказа на основе заявок - может быть, но весь процесс закупки совсем не простой и требует участия данных из десятка регистров информации, начиная с рабочего места инициатора при создании требования закупки, которое летит в подразделение закупок. Причем, если доверить роботу весь цикл - а значит гарантированная интеграция с источниками данных в виде связей внутри ERP или по API с внешними данными не производится - то риск ошибки велик (RPA выбирают, когда другой метод недоступен и данные захватывают из изображений в UI), а это риск потерь куда больший, чем затраты на традиционный код. Робот может просто отправить заказ с избыточным или недостаточным количеством, не теми ценами или номенклатурами, или не отправить заказ вовремя.
На роботизацию следующего более сложного процесса — сверку excel-файлов — потребовалось уже 2 месяца.
Зачем нужен робот для сверки Excel-файлов, когда есть нативный VBA и другие доступные бесплатные инструменты для гарантированной и молниеносной обработки массивов из Excel. 2 месяца - это огромный срок для такой задачи, значит дело не в технике сверки между файлами, а в логике и источниках дополнительных данных систем. Можете подробнее описать? Просто интересно, где конкретно RPA выигрывает у обычного кода. Тем более, вы пишите, что поддерживаете многообразие инструментов для различных задач и нет стратегии "RPA only" в архитектуре
Обходной лист при увольнении, в котором фиксируется, что за сотрудником нет никакого оборудования. Робот проверяет архив Excel-файлов и дает информацию по числящемуся оборудованию.
Реестр ОС в "архиве Excel-файлов". Если это правда, то в компании нужно не RPA внедрять, который судя по всему используется как инструмент борьбы с последствиями отсутствия системы учета, а сделать учет в виде простой базы данных в любой бесплатной СУБД или каких-нибудь гугл-таблицах. Иначе работы для RPA будет всегда очень много.
Drazd
18.11.2021 02:19+1Причем, если доверить роботу весь цикл - а значит гарантированная интеграция с источниками данных в виде связей внутри ERP или по API с внешними данными не производится...
Но зачем? Ведь робот может выполнить все действия для связки разных готовых систем, которые уже делают все нужное. Робот не должен сам лезть в источники данных и связи внутри ERP, робот должен нажать кнопку, которая запустит уже 100% отлаженный программный механизм внутри ERP, получить результат с экрана и передать его другому механизму. По сути RPA здесь будет клеем, который позволяет очень быстро объединить системы. Почему не программированием - объяснение ниже.
Зачем нужен робот для сверки Excel-файлов
Сверка сверке рознь. Одно дело, когда контрагент присылает Excel файл и нужно просто взять свой Excel-файл и строчка к строчке сравнить... Но совсем другое дело, когда своего Excel-файла как такового нет, а есть 2-3 системы, где есть информация, которую и надо сверить. Соответственно робот смотрит Excel-файл контрагента строчка за строчкой, и для каждой строчки выполняет проверки в нескольких системах.
Можно такое сделать на VBA? Посидев отлаживая несколько недель вызовы веб-сервисов или COM-объектов... А если у этих систем нет внятного API?
а сделать учет в виде простой базы данных в любой бесплатной СУБД или каких-нибудь гугл-таблицах. Иначе работы для RPA будет всегда очень много.
Легко сказать, да трудно сделать. Как показывает реальная практика, только первый этапы разработки и ввода в эксплуатацию даже самых простых систем в организации такого масштаба - это год (в самом лучшем случае половина года). А чтобы допилить систему до состояния "конфетка" - может потребоваться и 2 и 3 года.
Теперь возьмем весы и сравним два варианта:
Вариант 1 - За 2-3-4 месяца внедрить полноценный процесс, решающий конкретную задачу, которая не может быть решена текущим парком ПО. Результат - старые системы не ломаются, пользователи не тратят время на освоение новых интерфейсов, не испытывают проблем из-за миграции, но при этом получают новый функционал
Вариант 2 - 1 год проходит до того момента, как компания получает первую версию нужной системы, пользователи испытывают проблемы с освоением нового интерфейса, часть данных не перенесена или пересена криво при миграции, всего нужного функционала еще нет...
Даже если представить, что по результатам первого этапа требуемый результат был достигнут - в сравнении с первым компания начинает применять новый функционал на 8 месяцев позже, чем могла бы. А в нашем веке скоростей это может быть очень критичным. Особенно учитывая то, что срок окупаемости RPA-проектов довольно короткий (меньше года, бывает и за 2-3 месяца) - весы все же перевешивают в сторону применения роботов, а не затрат на разработку "нормальной учетной системы".
ArtyomMorozov1
18.11.2021 09:24Про сверку понял, что это не про между Excel-файлами, потому и задал вопрос. Если у систем нет API - наверное, его лучше сделать. Сделав один раз API вы решаете сразу же все текущие и будущие задачи на чтение и запись данных.
Легко сказать, да трудно сделать.
Я так написал именно потому, что сам реализовал не один десяток подобных инструментов для таких простых задач. Причем в компаниях, которые по масштабу сопоставимы с той, что указана в статье. 1 день - БД, 2 недели вечеров после основной работы или две пары выходных - приложение для пользователей: регистрация движений ОС, инвентаризация, ведение справочников. Цель - замена экселя на БД, а не космос с виртуальным ассистентом, 2 недели достаточно.
а не затрат на разработку "нормальной учетной системы".
По тону видно, что вы не беспристрастны и просто в обороне инструмента, который рекламируете, не приводя конкретного примера с оправданным использованием RPA, ещё и заявляя, что он автоматизирует полностью процесс закупки. Для разных задач - разные инструменты. RPA, наверное, хороший оркестратор + он умеет извлекать данные из графического интерфейса и возвращать в него результат - почему бы сразу не выделить эти его стороны. Правда, по моему опыту, с интерфейсом 1С он работает ненадежно, а в СНГ 1С очень популярен. Для SAP RPA вообще бессмысленный, с помощью записи макроса по действиям и расшифровки из них имен объектов форм, можно написать скрипт на VBS, который будет выполнять любой алгоритм с последовательным запуском транзакций, кликами, вставками данных. Это тоже занимает максимум пару недель; и да, я это делал сам ещё 10 лет назад.
Ведь робот может выполнить все действия для связки разных готовых систем, которые уже делают все нужное
Согласен. Сначала архитектура штатных ИС заставляет собственника реализовывать API в формате людей, затем формат API с людей меняют на RPA. Но это далеко не все задачи (взять из одной системы, вставить в другую). Когда речь зайдет о многоэтапной обработке сотни источников (таблиц с операциями, справочниками и прочим) для получения краткого BI-вывода и его возврата в ERP, интересно будет узнать как RPA это решит.
В целом вы описали интересный опыт, но интересны подробности, например участок кода решения конкретной задачи или скриншоты маршрута действий UiPath.
mixsture
Когда появляются бесплатные рабы, окупаемость любой автоматизации становится божественной. Но, собственно, можно было ничего не автоматизировать, а на полфирмы поставить работать бесплатных рабов.
Если без сарказма, то надо сравнивать затраты с одной и другой стороны.