Экспериментально оценить эффективность ПО, имитирующее работу пользователя и взаимодействующее исключительно с интерфейсом систем, в качестве механизма миграции данных.
Пример: Формирование реестра контрагентов
Приложению-роботу задается алгоритм перебора полей и нажатия кнопок в соответствии с интерфейсом исходной БД и веб-клиентом DirectumRX;
Робот копирует из интерфейса исходной БД содержание реквизита «ИНН» в DirectumRX, затем нажатием кнопки «Заполнить по ИНН» автозаполняет карточку контрагента в соответствии с ЕГРЮЛ;
Робот корректирует автозаполненную карточку путем копирования с заменой содержания отдельных реквизитов (например, поле «Наименование») для достижения необходимого заказчику формата;
Робот сохраняет карточку контрагента и переходит к внесению следующей организации.
Ввиду узкой ограниченности инструментов интеграции для DirectumRX в облачной поставке, технологии роботизации можно рассматривать в качестве одного из основных источников автоматизации процессов, связанных с вводом данных и созданием объектов системы. ООО «ТАНАИС Ритейл» планирует также использовать RPA-технологии для формирования связей между объектами системы (связывание корреспонденции в переписки, договора с другими первичными документами и т.п) при реализации последующих проектов внедрения.
Холькин Никита - Специалист группы продаж DIRECTUM
Михайлов Константин - Разработчик RPA
Обсудите реализацию с экспертом Directum
Комментарии (11)
а что остановило от использования Утилита импорта данных в DirectumRX?
Она достаточно не сложно дорабатывается.
Денис, текущая миграция - это скорее эксперимент, который призван проверить робота на практике и увидеть эффект от его использования.
Помимо этого использование утилиты от DIRECTUM имеет свои сложности:
1. Текущую выгрузку от Заказчика необходимо привести в стандарт шаблона, Заказчик не готов к этим трудоемкостям.
2. Если нужно изменить подход к миграции (связывание документов), то это перепиливать утилиту.
3. Разработка робота занимает меньше времени и позволяет делать любые операции.
Пока роботы побеждают людей - 1:0.
Привет Алексей!
Денис, текущая миграция - это скорее эксперимент, который призван проверить робота на практике и увидеть эффект от его использования.
Как эксперимент - крайне интересное решение!
В начале 2000-х, на КАМАЗе, делали такие штуки на Delphi, для ввода каких-то, то ли счетов, то ли остатков чего-то, в их ERP BAAN IV. Десятки тысячи позиций, учитывая общую тормознутость системы BAAN IV, выходило не сильно быстрее оператора :) По крайне мере при визуальном наблюдении за процессом. Но плюсы несомненно были перед ручным вводом.
1. Текущую выгрузку от Заказчика необходимо привести в стандарт шаблона, Заказчик не готов к этим трудоемкостям.
Ну так и вам робота надо к этому формату подготовить, и работу утилиты можно изменить под формат.
2. Если нужно изменить подход к миграции (связывание документов), то это перепиливать утилиту.
И робот сам об изменениях не узнает, надо их кодить.
3. Разработка робота занимает меньше времени и позволяет делать любые операции.
Тут уж все упирается в компетенции.
Пока роботы побеждают людей - 1:0.
Окончательная и бесповоротная победа роботов несомненна :)
Ввиду узкой ограниченности инструментов интеграции для DirectumRX в облачной поставке
Не благодаря, а вопреки, так и внедряем :)
Я бы ещё к немаловажным преимуществам использования роботизации добавил:
1. Коммуникацию нескольких систем исключительно через интерфейс (это позволяет переносить данные без промежуточного экспорта/импорта и избежать вмешательства в работу действующих КИС заказчика);
2. Защита информации (например, при организации импорта данных силами подрядчика с использованием утилиты от DIRECTUM, требуется довольно подробное изучение сотрудниками исполнителя хранилища данных заказчика. однако, из соображений безопасности, не каждый заказчик готов на это пойти. в данном случае, использование RPA позволит не только избежать необходимости формирования шаблонов для миграции, но и гарантировать конфиденциальность данных)
Добрый день!
Интересное решение, но есть одно ограничение – функциональность по заполнению карточки организации по ИНН не предназначена для массовой загрузки исторических данных, а только для внесения новых контрагентов вручную пользователями, иначе система примет вас за робота и заблокирует действия.
В случае загрузки исторических данных рекомендуем все же пользоваться утилитой импорта.
Екатерина, а какого именно рода и для какого объема ограничение?
Нам удалось внести почти 300 записей контрагентов в базу заказчика за один день (я проверял поиском карточек организаций по дате создания).
Кроме того, контрагенты - это лишь предмет эксперимента. В будущем хотим попробовать использовать робота главным образом для автоматизации формирования связей между архивными документами. Это должно быть интереснее)
А правильно ли понимаю, что в конкретно этом решении робот может работать только с веб-страницей, судя по скриншоту?
Для поиска контролов в которые ввод осуществляется используется привязка к атрибутам элемента (ИД, классы)? Или как-то компьютерное зрение используете?
Утилиты RPA могут работать не только с веб-интерфейсом, но и с десктопным. При необходимости и в образом экрана при удаленном подклчении, но это уже последний шанс, где будет ниже быстродействие и выше шанс на ошибки.
Провел беглый анализ интерфейса RX - к десктопному интерфейсу будет легко обращаться для ввода, чтения и навигации. В отличии от Directum5, там придется повозиться.
Работаю с RPA UiPath, являюсь сертифицированным разработчиком.
Коллеги, а вы что использовали?
Александр, согласен с Вашим комментарием: у нас были разные эксперименты и с RX и с 5.х по теме роботизации (в частности роботизировали тестирование типовых маршрутов) и могу с уверенностью сказать, что интерфейс RX (особенно веб) гораздо легче поддаётся роботизации, чем интерфейс DIRECTUM 5.х.
Для роботизации мы использовали собственные наработки.
Если интересно - обращайтесь, с удовольствием поделюсь информацией.
Мой адрес эл. почты: i.seredkin@tanais.ru
у меня тоже пару вопросов появилось.
1. вот к примеру мы загрузили 300 контрагентов, он их обработал и в системе появилась какая то иформация. Кто несет ответственности за корректность данных в системе?
2. К крупных предприятий есть помимо обычного КПП крупнейшего налогоплательщика. Как система выбирает наименование в данном случае?
Добрый день, Андрей
1. В случае, если данные переносим из текстового редактора или копируем из интерфейса сторонней системы, то мы гарантируем строгое соответствие исходным данным.
2. Во-первых, мы можем внести контрагента в строгом соответствии с исходными данными заказчика. Во-вторых, при использовании функции "Заполнить по ИНН/ОГРН" значение КПП не влияет на выбор наименования организации, а в поле КПП подтягивается значение КПП крупнейшего налогоплательщика; В-третьих, в зависимости от исходных данных и потребностей заказчика можно задавать роботу алгоритмы различной сложности с учётом множества факторов
Авторизуйтесь, чтобы написать комментарий