С 2019 года мы роботизируем различные рутинные процессы. Это снимает с сотрудников часть монотонной работы и позволяет им уделять больше времени важным задачам. Мы использовали RPA-платформу UiPath, но в феврале 2022 года начался обратный отсчет до момента, когда все, что мы сделали за три года, превратится в тыкву. Нужно было срочно найти замену и избежать наихудшего сценария. 

Как мы это сделали, какое решение выбрали и какие проблемы решили — читайте под катом.

В Hoff 50+ рутинных процессов выполняют роботы

Я Сергей Озеров, разработчик RPA в Hoff Tech. С помощью роботизации делаю так, чтобы 200+ сотрудников компании не тратили время на рутинные задачи.

Роботизация (RPA) — это автоматизация процессов при помощи ботов, взаимодействующих с пользовательским интерфейсом различных программ. Она позволяет автоматизировать процессы в не связанных между собой системах и извлекать данные, которые сложно получить обычным программным путем.

В Hoff таким образом автоматизированы самые разные процессы: 

• сверка отчетов из разных источников;

• разбор сканов и создание фактур в нашей внутренней ERP-системе;

• автоматическое создание счетов в 1С и журналов для поставщиков в ERP-системе на основе выгрузок из 1С;

• создание и обработка задач в Pyrus и их интеграция с ERP-системой.

Например, когда приезжает фура с товаром, человек в работе с документами участвует только один раз — сканирует накладную. Дальше скан падает в папку, откуда его забирает робот, распознает текст и при помощи полученных данных находит этот заказ в ERP-системе.

Затем робот сверяет данные. Если все совпадает — прикладывает скан к накладной и, с учетом данных из скана, создает счет-фактуру на основе выборки из SQL-базы данных.

Другой пример: при доставке заказа покупателю на дом и оплате наличными экспедитор вносит деньги на счет через банкомат, напрямую не интегрированный с кассами Hoff и нашей ERP-системой, где ведется учет оплат по заказам. Робот анализирует банковский отчет и сравнивает записи об оплатах с заказами с информацией из 1С. Если все хорошо, то вносит в журнал, а при несовпадении данных — информирует об ошибке.

Роботов мы создавали на UiPath — популярной и зрелой платформе, лидере по многим критериям. Продукт простой в использовании, с широкими возможностями и большим комьюнити. Наша система роботизации выглядела так: один оркестратор, который запускает и останавливает роботов, две студии UiPath для разработки ботов и три unattended-робота. С 2019 года они обслуживали более 50 процессов в компании. Пока не наступил февраль 2022. 

Как раньше не будет, что дальше — неясно

В конце февраля — начале марта, в связи с потенциальными проблемами с оплатой, мы стали отказываться от Google Cloud Vision, который использовали для оптического распознавания символов в накладных, и переходить на аналогичный инструмент Яндекса. В это же время встал вопрос дальнейшей работы с UiPath, где модель лицензирования — годовая подписка, которую нам надо было продлевать в сентябре 2022. Приобретали лицензию через вендора —GMCS. У них и спросили, что будет дальше, но до конца марта понимания не было. Мы продолжали работать на UiPath в подвешенном состоянии и параллельно снижали зависимость от Google.

И вот в конце марта стало понятно, что UiPath не будет продлевать подписки для российских пользователей. Значит, в сентябре 2022 года все, что мы создали за три года, превратится в тыкву.

Нужно было срочно решать, что делать дальше. Перед нами было несколько вариантов: 

• Срочно набрать людей под рутинные задачи и функции в разных отделах. Много людей, если учитывать, в скольких бизнес-процессах в Hoff задействована роботизация. Вряд ли процесс прошел бы быстро и гладко: найти кандидата, ввести в курс дела, обучить и объяснить, что изо дня в день нужно сверять данные и нажимать на пять кнопок…

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

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

Пересаживаемся на отечественное

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

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

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

Мы проверили работу OCR-активностей, работу мастера и студии Pix RPA, протестировали работу с браузерами, почтой, Excel и PDF-документами, попробовали портировать несколько простых роботов, которые обрабатывают почту, открывают и перекладывают файлы. 

В результате испытаний и общения с техподдержкой мы решили, что в принципе этот продукт может заменить UiPath если не на 100%, то на 80% точно. И в июне 2022 мы приобрели лицензию.

Миграция: конфетно-букетный период

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

Тогда еще было неясно, как Pix RPA покажет себя в сравнении с UiPath — мы еще не запускали сложных процессов и все работало стабильно. А потом начались сюрпризы.

Миграция: стерпится — слюбится

Позже, когда дело дошло до разработки сложных роботов, стало очевидно, что на тот момент Pix RPA сильно уступала UiPath по ряду параметров.

Первый заметный недостаток Pix RPA — малое число дополнительных библиотек. Ведь проект состоит не только из кода, который записан в самом проекте, но и из зависимостей от других активностей — модулей с дополнительной функциональностью. В UiPath есть каталог, где можно найти активности для решения различных задач. Нужно отформатировать число «1000» в вид для накладной: единица, пробел и три нуля — пожалуйста. Качаешь активность из репозитория, подключаешь к роботу, подаешь число на вход и получаешь нужный результат. У Pix RPA можно скачать какие-то активности на сайте, но там их всего около десятка и они не так просто интегрируются в проект.

Еще в UiPath мы создавали собственные библиотеки. Например, мы могли упаковать процедуру авторизации на сайте в отдельную библиотеку. Потом мы могли использовать эту процедуру с любым роботом, просто подтягивая эту библиотеку.

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

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

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

Эти дескрипторы тоже можно было загонять в библиотеки. Если сайт менялся, то мы правили адреса кнопок в библиотеке и оставалось только обновить версию библиотеки в проектах.

В Pix RPA реализован только простой селектор, и за ним приходится постоянно следить, потому что нет системы массового обновления адресов. Опять же, если что-то меняется, нужно открывать и править каждый проект. Это притом что RPA-решения почти всегда взаимодействует со сторонними ресурсами, и предугадать, когда тот или иной ресурс обновится или изменит свой внешний вид, нельзя. Это человеку легко найти кнопку скачивания отчета, даже если она переехала из одного угла экрана в другой. Роботу, особенно плохо запрограммированному, в этом смысле гораздо сложнее.

Миграция: 18+ с креативным подходом

Дальше больше. В теории все должно работать, ведь мы используем активности, встроенные в RPA-платформу. Судя по описанию, они должны делать то, что нам нужно, а при запуске робота получаем вовсе не те результаты, которых ожидаем. 

Работа с браузером тоже преподносила сюрпризы. Ни с того ни с сего робот начинал кликать мимо нужных элементов, хотя вроде как их видел и находил. Аналогичные проблемы были и при работе с ERP-системой. При разработке указываешь элемент, робот строит запрос на XPath, а при проверке — элемент не видит.

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

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

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

Смотрели этапы, подключали техподдержку, и оказалось, что робот сам убивает RDP-соединение. Кажется, ему памяти не хватает. Увеличили объем ОЗУ на машине — стало получше, но проблема периодически повторялась. 

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

Еще пример: у нас есть взаимодействие с сайтом, где мы то создаем, то закрываем заявки в зависимости от их статуса, а вызов одного и того же метода или класса происходит несколько раз. Сначала робот отрабатывает корректно и кликает по нужным элементам UI. А начиная со второго раза промахивается со смещением вниз, и непонятно, как это победить.

Подключаем техническую поддержку Pix RPA, а ребята говорят, что пока у них нет решения. В итоге ищем обходной путь: после создания каждой заявки перезапускаем браузер, и все работает корректно. Да, это, безусловно, костыль, но другого варианта мы так и не нашли. На такие вот «креативные»‎ альтернативные решения уходила уйма времени. 

Стабильность работы платформы Pix RPA вначале также была недостаточно хорошей: у нас регулярно падали агенты. Бывало, задание стоит одно, а робот запускается дважды. В результате дублируются данные, а пользователи ругаются, что мы испортили им день. Иногда сам мастер отваливался и переставал запускать что-либо вообще. А иногда самопроизвольно перезагружался во время работы робота и останавливал все процессы в случайных местах. 

Сколково может. И довольно неплохо

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

После свежих релизов уже можно сказать, что платформа работает так же стабильно, как и UiPath. Похоже, что продукт был попросту не готов к повышенному интересу со стороны больших компаний, но видно: разработчики не стоят на месте и оперативно допиливают Pix RPA, в том числе и по нашим отзывам (и включают в релизы наши хотелки).

Большим преимуществом Pix RPA можно считать работу техподдержки, связь с которой у нас налажена в телеграм-чате. И сидят в ней далеко не индусы на аутсорсе. Был случай, когда для разбора бага подключили ведущего разработчика, который участвовал в отладке нашего робота. Кажется, ни один крупный мировой вендор такой поддержки не предлагает. Получается реально индивидуальный подход.

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

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

Наконец, Pix RPA — отечественный продукт и стоит дешевле импортных аналогов, что тоже не может не радовать. 

Немного потеряли, а что-то приобрели

Хотя было много сложностей, для 90% в конечных пользователей внутри компании миграция прошла незаметно. 

У меня до сих пор иногда спрашивают, что там с переходом и как это будет, хотя на деле мы давно мигрировали и работает другой робот. Конечные пользователи не чувствуют разницы и узнают об этом разве что из подписей к письмам. Для PixRPA мы сделали немного другую подпись, чтобы во время параллельной работы платформ понимать, какой робот генерирует конкретное письмо. 

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

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

Нормально все будет, если не сдаваться

Когда я узнал, что предстоит переносить весь наш трехлетний опыт эксплуатации на неизвестную платформу, для меня это было вызовом, появился двойной интерес к работе — мы с азартом начали процесс миграции. Да, когда пошли проблемы со стабильностью работы платформы и косяки, которые мы своими силами решить не могли, руки иногда опускались. Но в целом этот вызов был мотивирующим: я возвращался к задачам, которые решал пару лет назад, и находил более элегантные решения. Было интересно проводить эту миграцию, не только получать новый опыт, но и совершенствовать подходы к роботизации. 

Да, для Pix RPA не найти готовых ответов на Stack Overflow. Многое приходится искать самостоятельно и уделять этому время. Идти своим путем, а не постоянно опираться на чужие решения. Это одна из причин, по которой наша миграция прошла не так быстро: банальные вещи иногда требовали больше времени, поиска альтернативного решения или смены подхода. Но вообще я был приятно удивлен, что в России предлагают уже вполне работоспособный продукт, который может конкурировать со многими зарубежными платформами. Классно, что у нас есть свои разработки. Сложившиеся обстоятельства дали шанс таким компаниям, как Pix RPA, проявить себя и предложить рынку продукты, которые раньше никто не замечал в тени известных брендов. Думаю, все мы как пользователи от этого только выиграем.

Хабр

Шалупастик приглашает в магазин "Есть ВСЁ" - мы вместе с Россией !

Новый магазин от нас на ОЗОН "Здесь ВСЁ!"

Заходите в ещё один наш магазин на ОЗОН - Автодром !

Шалупастик на Wildberries !

Торговая площадка Яндекс Маркет

Сайт VK Link

ВКонтакте

Яндекс ДЗЕН

Приходите, Шалупастик ждёт !

Специальное предложение

------------------------------------

Ванна из сантехнического акрила АБС/ПММА 1400х750х670 Эгея 1400, Seven Luxe

Компания ООО «СЕВЕН ЛЮКС И КО» (торговая марка «Seven 7Luxe» занимается производством акриловых (простых и гидромассажных) ванн. Все изделия изготавливаются на высокотехнологичном немецком вакуум-формовочном оборудовании GEISS. Алюминиевые формы сантехнической продукции приобретены в Италии.

Ванны изготавливаются из антибактериального сантехнического акрила АБС/ПММА толщиной от 5 мм до 6 мм. Это комбинированный пластик, состоящий из нескольких слоев: сочетание ПМААА (полиметилметакрилат, синтетический полимер метилметакрилата, термопластичный прозрачный пластик, известный под названием акриловое стекло, акрил или органическое стекло) с пластиком АБС (ударопрочная термопластичная смола на основе сополимера акрилонитрила с бутадиеном и стиролом). ПАША дает идеальную гладкую поверхность, пластик АБС повышает эластичность комбинированного материала. Применяемый в производстве ванн сантехнический акрил отличается от других производителей тем. что имеет два слоя с высоким глянцем поверхности, глубоким цветом, высокой стойкостью к царапанью, повышенной химической стойкостью, стойкостью к разрастанию бактерий. Листы АБС/ПААМА ударопрочные, имеют устойчивость к низким температурам, срок службы ванны из двухслойного пластика увеличивается более чем в двое. При производстве листового сантехнического акрила применяется сырье ведущих мировых производителей.

Для придания изделию дополнительной Жесткости и прочности все акриловые изделия "Seven 7Luxe" армируются стекловолокном с дополнительным усилением дна. Материал обладает сниженной теплопроводностью, что обеспечивает медленное остывание воды в ванне. Отсутствие шума при попадании воды на поверхность ванны или поддона сделает принятие душа еще более комфортным.

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

Купить на Яндекс МАРКЕТ по СПЕЦИАЛЬНОЙ цене 21897 рублей доставка СДЕК

Купить на ОЗОН "Здесь ВСЁ" от Шалупастика по СПЕЦИАЛЬНОЙ цене 19013 рублей доставка "Деловые линии"

------------------------------------

ТАК ЖЕ большой выбор душевых поддонов