Comments 15
Если вам надо по кнопкам прощёлкать, при этом у вас есть доступ к конфигуратору 1С, то непонятно зачем вы занимаетесь таким трешем? Ваш кейс не понятен.
Обратите внимание на то, что речь идет про роботизацию, а не программирование. Постараюсь объяснить детальнее, чтобы вам было понятней:
Когда у вас есть компетенции 1С-программиста (или есть такой человек в штате), у вас есть доступ к конфигуратору (не закрытый интегратором), и все, что вам нужно автоматизировать — это только 1С, тогда действительно — вам легче будет написать код в 1С, который будет делать все, что вам нужно.
Когда у вас нет экспертизы в разработке на 1С, нету доступа к редактированию кода, а процесс, который вы хотите автоматизировать, включает в себя не только работу с 1С, но и с другими системами (у которых может не быть внятного API) — возникает вопрос «как мне это сделать?». Ответ прост — использовать роботов (RPA). Вам не нужно быть экспертом в программировании, все что вам нужно — это просто показать роботу как делает свою работу человек: «Открыть 1С, Нажать сюда, потом сюда, ввести данные в эти поля, забрать значение отсюда, открыть другую систему, нажать туда, ввести сюда, итд».
И робот будет делать тоже самое. Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за техническими учетными записями — он просто работает с теми же программами, что и человек.
И вроде все прекрасно, но есть один нюанс — если роботы отлично справляются с большинством приложений/систем/сайтов, то вот с 1С возникают нюансы. И как учитывать эти нюансы — рассказано в данной статье. Надеюсь, теперь для вас более понятен смысл и посыл статьи.
Когда у вас есть компетенции 1С-программиста (или есть такой человек в штате), у вас есть доступ к конфигуратору (не закрытый интегратором), и все, что вам нужно автоматизировать — это только 1С, тогда действительно — вам легче будет написать код в 1С, который будет делать все, что вам нужно.
Когда у вас нет экспертизы в разработке на 1С, нету доступа к редактированию кода, а процесс, который вы хотите автоматизировать, включает в себя не только работу с 1С, но и с другими системами (у которых может не быть внятного API) — возникает вопрос «как мне это сделать?». Ответ прост — использовать роботов (RPA). Вам не нужно быть экспертом в программировании, все что вам нужно — это просто показать роботу как делает свою работу человек: «Открыть 1С, Нажать сюда, потом сюда, ввести данные в эти поля, забрать значение отсюда, открыть другую систему, нажать туда, ввести сюда, итд».
И робот будет делать тоже самое. Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за техническими учетными записями — он просто работает с теми же программами, что и человек.
И вроде все прекрасно, но есть один нюанс — если роботы отлично справляются с большинством приложений/систем/сайтов, то вот с 1С возникают нюансы. И как учитывать эти нюансы — рассказано в данной статье. Надеюсь, теперь для вас более понятен смысл и посыл статьи.
«Нет доступа к редактированию кода, потому что закрыто вендором»: нет, как только ввели расширения, то стало возможным писать код оставляя замочек на основной кофигурации, не трогая код вендора.
По компетенциям 1С частично соглашусь: хотя любой человек, который знает программирование, легко начнёт работу в 1С, (в противовес: это всё равно, что не смочь написать программу на Бейскике, такого человека и к скриптам подпускать нельзя), тем не менее, надо ещё знать конфигурацию, иначе можно понаделать бед. Однако, программистов 1С очень много и они не сильно дороги, что бы это было каким-то существенным препятствием, а вот иметь компетенции в скриптовании GUI — тоже надо и это тоже не бесплатно, и не понятно где их искать.
Ну и самое главное, я занимался работой через «нажимание» кнопок и скажу, по собственному опыту, что основной недостаток этих вещей, это отсутствие чёткой обратной связи, соответственно, такая программа может продолжить работать, хотя какой-то этап был пропущен или сглючил, в этом случае обычная программа остановится с ошибкой, а тут вам будет долбить по кнопкам обезьяна с админскими правами (или у вас на каждое действие, перезаходит пользователь с другими правами? Это очень медленно).
«Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за»
То есть, лезет — трогает, требует контроля, имея теже админские права, что и человек, которому доверили делать комплексные дела в программе. Это всё равно что админу, при возможности снять HDD и скопировать всю инфу при прямом доступе к железу, петь песни, что у него нет доступа к клавиатуре и монитору, поэтому он не увидит ваши данные.
По факту, учитывание контекста для UI скриптов, занимает столько сил и требует неординарного ума, что гораздо проще написать всё это в коде напрямую, либо постоянно скрипт находится в нерабочем состоянии, потому что-то ещё не учли.
Например, такая задача: создаём документ, сохраняем, переоткрываем переносим в него данные по полям из старого (без функционала «скопировать»), старый документ удаляем. Гарантируете, что будет полная копия всех документов и то что не перенеслось не было удалено и никакие поля не пропустили? Сравните количество телодвижений с программным подходом и такими вещами как транзакция.
P.S. Например, у меня была масса случаев, когда Ctrl+V не прошло, из-за того, что какой-то драйвер системным треем перехватил фокус на доли секунды и тому подобные вещи, хотя во всех точках до и после контроль показал, что фокус есть.
По компетенциям 1С частично соглашусь: хотя любой человек, который знает программирование, легко начнёт работу в 1С, (в противовес: это всё равно, что не смочь написать программу на Бейскике, такого человека и к скриптам подпускать нельзя), тем не менее, надо ещё знать конфигурацию, иначе можно понаделать бед. Однако, программистов 1С очень много и они не сильно дороги, что бы это было каким-то существенным препятствием, а вот иметь компетенции в скриптовании GUI — тоже надо и это тоже не бесплатно, и не понятно где их искать.
Ну и самое главное, я занимался работой через «нажимание» кнопок и скажу, по собственному опыту, что основной недостаток этих вещей, это отсутствие чёткой обратной связи, соответственно, такая программа может продолжить работать, хотя какой-то этап был пропущен или сглючил, в этом случае обычная программа остановится с ошибкой, а тут вам будет долбить по кнопкам обезьяна с админскими правами (или у вас на каждое действие, перезаходит пользователь с другими правами? Это очень медленно).
«Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за»
То есть, лезет — трогает, требует контроля, имея теже админские права, что и человек, которому доверили делать комплексные дела в программе. Это всё равно что админу, при возможности снять HDD и скопировать всю инфу при прямом доступе к железу, петь песни, что у него нет доступа к клавиатуре и монитору, поэтому он не увидит ваши данные.
По факту, учитывание контекста для UI скриптов, занимает столько сил и требует неординарного ума, что гораздо проще написать всё это в коде напрямую, либо постоянно скрипт находится в нерабочем состоянии, потому что-то ещё не учли.
Например, такая задача: создаём документ, сохраняем, переоткрываем переносим в него данные по полям из старого (без функционала «скопировать»), старый документ удаляем. Гарантируете, что будет полная копия всех документов и то что не перенеслось не было удалено и никакие поля не пропустили? Сравните количество телодвижений с программным подходом и такими вещами как транзакция.
P.S. Например, у меня была масса случаев, когда Ctrl+V не прошло, из-за того, что какой-то драйвер системным треем перехватил фокус на доли секунды и тому подобные вещи, хотя во всех точках до и после контроль показал, что фокус есть.
Спасибо за такой комментарий, было интересно прочитать ваши сомнения по поводу RPA. На самом деле, с такими сомнениями приходится периодически сталкиваться, так что постараюсь помочь вам избавиться от них:
Действительно, технологий и решений, которые предоставляют возможность именно скрпитования GUI очень много и они, как правило, требуют определенных компетенций — не могу с вами не согласиться. Однако, обращу ваше внимание еще раз на то, что в статье идет речь про RPA, а это уже гораздо больше, чем «скриптование/кликер GUI». И особенно когда речь идет про UiPath.
Тут стоит отметить, что вся настройка робота осуществляется в графическом виде. При чем есть два режима:
И второй режим позволяет взять вашего специалиста, который прекрасно знает свою работу, обучить его (1-2 дня) и дать ему самому настроить робота, который будет делать за него его работу. Конечно, в особо сложных процессах нужна поддержка профессионального разработчика, но вовсе не обязательно, чтобы это был дорогой специалист с огромным опытом. Помимо прочего, если в компании есть IT-специалист, он может пройти бесплатно 1-недельный онлайн курс и стать полноценным RPA-разработчиком (имеются дополнительные углубленные курсы, но это уже по желанию, при необходимости).
Данное замечание нерелевантно для UiPath, о котором идет речь. Если робот не может найти нужную кнопку или не получил отклика от кнопки (не смог нажать), не нашел поля, надписи, или вообще не может определить нужное окно — возникнет ошибка. Эту ошибку можно обработать соответствующим try/catch блоком (да, в графическом режиме он тоже имеется), или же сделать глобальный обработчик ошибок. В общем это уже детали, но главное — дальше робот (сам) не пойдет и вбивать данные «в молоко» не будет.
Важно понимание, что робот — это не программа, которую написали на каком-то языке программирования, а эмулятор человека. Само собой, если у сотрудника, которого он эмулирует, имеется доступ к разным особо чувствительным функциям систем — теоретически робот тоже сможет ими пользоваться. Вот только как робота настроили — так он и работает, никаких шагов влево-вправо. Как указал выше — любое несоответствие ожидания-реальности ведет к возникновению ошибки и остановке выполнения процесса (с уведомлением админов).
Когда же мы программно работаем с API или пишем напрямую в базу данных — сохраняется вероятность того, что мы что-то упустим или недоделаем (если у нас нет высоких компетенций именно в данном API). В случае с роботами — мы не можем случайно пропустить работу с каким-то окном или полем, так как мы просто повторяем все операции за человеком, который делает это каждый день. Единственное, что может пойти не так — это когда этот человек забывает о «редком документе, который приходит раз в месяц, вот его надо еще через другое окошко регистрировать». Но такие случаи и при классической разработке встречаются довольно часто, так что это в целом проблема аналитики, а не разработки.
Странный кейс, если он происходит внутри одной системы. Предположу, что мы говорим о том случае, когда у вас есть документ в одной системе (допустим, клиент оставил заявку на вашем сайте) и на его основании надо сделать аналогичный документ в другой системе (или сразу нескольких системах), в нашем случае — в 1С.
Если такие действия обычно производятся человеком и результат его работы является корректным, то робот, который будет выполнять те же самые действия, что и человек — даст вам 100%-ый результат.
Если же это совсем новая задача/процесс, в котором у вас нет эксперта и у вас имеются прекрасные компетенции в программировании, вы прекрасно знаете API целевой системы — однозначно вы справитесь быстрее, чем если будете применять роботизацию. Но если вы не знаете API, не знаете как все внутри устроено, не уверены, что разные типы документов структурированы одинаково… Как показывает моя практика — изучение всей внутренней кухни какой-либо системы занимает в самом лучшем случае пару дней, но обычно это неделя, а в особых случаях — можно и месяц (суммарно) «убить» на изучение всех тонкостей. А еще надо написать код, отладить, желательно автотесты еще написать и прогнать их.
Настроить робота для такой задачи займет не больше дня (если считать именно разработку с авто-тестами, отладкой, прогоном на тестовом контуре; без них будет быстрей).
Здесь скорее речь о тех случаях, когда у вас все же нет такого человека в штате, брать человека в штат ради одной задачи странно, а нанимать фрилансера — небезопасно (кто будет поддерживать?), а иногда взаимодействие с фрилансерами может быть заблокировано договорными отношениями с интегратором (обращаться к нему по этой задаче будет дольше и дороже, чем роботизировать).
PS: Предлагаю вам зайти на сайт UiPath и скачать бесплатно комьюнити-версию полноценного продукта. Пройдите стартовый курс (займет не больше 4-х часов) и зацените сами на сколько это более удобное решение, чем «скриптинг GUI», с которым, как я понял, вам приходилось сталкиваться.
а вот иметь компетенции в скриптовании GUI — тоже надо и это тоже не бесплатно, и не понятно где их искать.
…
По факту, учитывание контекста для UI скриптов, занимает столько сил и требует неординарного ума, что гораздо проще написать всё это в коде напрямую, либо постоянно скрипт находится в нерабочем состоянии, потому что-то ещё не учли.
Действительно, технологий и решений, которые предоставляют возможность именно скрпитования GUI очень много и они, как правило, требуют определенных компетенций — не могу с вами не согласиться. Однако, обращу ваше внимание еще раз на то, что в статье идет речь про RPA, а это уже гораздо больше, чем «скриптование/кликер GUI». И особенно когда речь идет про UiPath.
Тут стоит отметить, что вся настройка робота осуществляется в графическом виде. При чем есть два режима:
- Профессиональный, где интерфейс чуть посложнее и более удобен проф. разработчикам;
- Для бизнес-пользователей (в статье это «citizen developers»), в котором все максимально упрощено на столько, что даже далекие от айти люди могут делать своих роботов.
И второй режим позволяет взять вашего специалиста, который прекрасно знает свою работу, обучить его (1-2 дня) и дать ему самому настроить робота, который будет делать за него его работу. Конечно, в особо сложных процессах нужна поддержка профессионального разработчика, но вовсе не обязательно, чтобы это был дорогой специалист с огромным опытом. Помимо прочего, если в компании есть IT-специалист, он может пройти бесплатно 1-недельный онлайн курс и стать полноценным RPA-разработчиком (имеются дополнительные углубленные курсы, но это уже по желанию, при необходимости).
основной недостаток этих вещей, это отсутствие чёткой обратной связи, соответственно, такая программа может продолжить работать, хотя какой-то этап был пропущен или сглючил, в этом случае обычная программа остановится с ошибкой, а
Данное замечание нерелевантно для UiPath, о котором идет речь. Если робот не может найти нужную кнопку или не получил отклика от кнопки (не смог нажать), не нашел поля, надписи, или вообще не может определить нужное окно — возникнет ошибка. Эту ошибку можно обработать соответствующим try/catch блоком (да, в графическом режиме он тоже имеется), или же сделать глобальный обработчик ошибок. В общем это уже детали, но главное — дальше робот (сам) не пойдет и вбивать данные «в молоко» не будет.
То есть, лезет — трогает, требует контроля, имея теже админские права, что и человек, которому доверили делать комплексные дела в программе.
Важно понимание, что робот — это не программа, которую написали на каком-то языке программирования, а эмулятор человека. Само собой, если у сотрудника, которого он эмулирует, имеется доступ к разным особо чувствительным функциям систем — теоретически робот тоже сможет ими пользоваться. Вот только как робота настроили — так он и работает, никаких шагов влево-вправо. Как указал выше — любое несоответствие ожидания-реальности ведет к возникновению ошибки и остановке выполнения процесса (с уведомлением админов).
Когда же мы программно работаем с API или пишем напрямую в базу данных — сохраняется вероятность того, что мы что-то упустим или недоделаем (если у нас нет высоких компетенций именно в данном API). В случае с роботами — мы не можем случайно пропустить работу с каким-то окном или полем, так как мы просто повторяем все операции за человеком, который делает это каждый день. Единственное, что может пойти не так — это когда этот человек забывает о «редком документе, который приходит раз в месяц, вот его надо еще через другое окошко регистрировать». Но такие случаи и при классической разработке встречаются довольно часто, так что это в целом проблема аналитики, а не разработки.
Например, такая задача: создаём документ, сохраняем, переоткрываем переносим в него данные по полям из старого (без функционала «скопировать»), старый документ удаляем.
Странный кейс, если он происходит внутри одной системы. Предположу, что мы говорим о том случае, когда у вас есть документ в одной системе (допустим, клиент оставил заявку на вашем сайте) и на его основании надо сделать аналогичный документ в другой системе (или сразу нескольких системах), в нашем случае — в 1С.
Если такие действия обычно производятся человеком и результат его работы является корректным, то робот, который будет выполнять те же самые действия, что и человек — даст вам 100%-ый результат.
Если же это совсем новая задача/процесс, в котором у вас нет эксперта и у вас имеются прекрасные компетенции в программировании, вы прекрасно знаете API целевой системы — однозначно вы справитесь быстрее, чем если будете применять роботизацию. Но если вы не знаете API, не знаете как все внутри устроено, не уверены, что разные типы документов структурированы одинаково… Как показывает моя практика — изучение всей внутренней кухни какой-либо системы занимает в самом лучшем случае пару дней, но обычно это неделя, а в особых случаях — можно и месяц (суммарно) «убить» на изучение всех тонкостей. А еще надо написать код, отладить, желательно автотесты еще написать и прогнать их.
Настроить робота для такой задачи займет не больше дня (если считать именно разработку с авто-тестами, отладкой, прогоном на тестовом контуре; без них будет быстрей).
Однако, программистов 1С очень много и они не сильно дороги, что бы это было каким-то существенным препятствием
Здесь скорее речь о тех случаях, когда у вас все же нет такого человека в штате, брать человека в штат ради одной задачи странно, а нанимать фрилансера — небезопасно (кто будет поддерживать?), а иногда взаимодействие с фрилансерами может быть заблокировано договорными отношениями с интегратором (обращаться к нему по этой задаче будет дольше и дороже, чем роботизировать).
PS: Предлагаю вам зайти на сайт UiPath и скачать бесплатно комьюнити-версию полноценного продукта. Пройдите стартовый курс (займет не больше 4-х часов) и зацените сами на сколько это более удобное решение, чем «скриптинг GUI», с которым, как я понял, вам приходилось сталкиваться.
Скажите пожалуйста, как инженер, как бы вы отнеслись к коллеге, у которого возникла задача из своей системы как-то взаимодействовать с веб-сайтом. При этом у него нет компетенции в области HTTP, и он решил эту задачу с помощью такого вот робота, который открывает страничку в браузере и эмулирует действия пользователя?
Для того, чтобы хоть как-то отнестись к тому или иному решению — нужен бекграунд и детали.
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Но есть другая ситуация, которых очень много по разным компаниям:
«Наша система» разработана полностью в соответствии с исходным планом/потребностями компании, но у нас есть один отдел, где у сотрудников появилась потребность (которой раньше не было) выгружать данные из «нашей системы», проводить с ними какую-то манипуляцию, загружать в другую систему/веб-сайт (или наоборот).
Казалось бы — есть опытные разработчики, которые могут автоматизировать данную работу для наших сотрудников, вот только есть нюансы:
Каждый из перечисленных пунктов замедляет/откладывает процесс автоматизации. Отдельным пунктом стоит то, что на разработку с тестированием, приемкой — уйдет примерно 2-4 недели работы программиста в лучшем случае.
А если мы воспользуемся роботами? Разработчик может прийти к сотруднику, включить средство записи действий UiPath, сотрудник выполнит свой порядок действий за несколько минут, расскажет про нестандартных ситуации… Разработчик возьмет записанный процесс, воспроизведет на своем компьютере, отладит его с учетом нестандартных ситуаций и уже к вечеру того же дня сможет показать сотруднику как робот делает его работу. Само собой, может понадобиться дополнительная отладка с учетом «я еще вспомнил» от сотрудника, но она пройдет довольно быстро, за еще 1-2 дня.
Вот тут мы уже включаем инженера, который не только «гайки крутит», но и экономику считает. И когда мы уже сравниваем условные 3 человеко-дня разработки робота против 10-20 человеко-дней разработки программного кода, то вывод напрашивается сам собой — наш коллега большой молодец. Вместо того, чтобы заниматься этой не очень то критичной проблемой месяц, он сделал ее за 3 дня и теперь может решить еще штук 5 таких же проблем до конца месяца.
Тут, к слову, важно понимание, что роботы — это не затычка для 1-2 задач, это полноценный инструмент для решения вот таких вот проблем с рутиной у сотрудников. Там, где разработка программного кода выходит дороже, чем выгода от этой разработки — спасают именно роботы, так как настраиваются они быстрее, и возврат инвестиций происходит так же в более короткие сроки.
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Но есть другая ситуация, которых очень много по разным компаниям:
«Наша система» разработана полностью в соответствии с исходным планом/потребностями компании, но у нас есть один отдел, где у сотрудников появилась потребность (которой раньше не было) выгружать данные из «нашей системы», проводить с ними какую-то манипуляцию, загружать в другую систему/веб-сайт (или наоборот).
Казалось бы — есть опытные разработчики, которые могут автоматизировать данную работу для наших сотрудников, вот только есть нюансы:
- У внешнего веб-сайта нет открытого API (или есть/можно получить по партнерке, но недокументированный)
- Отдел разработки перегружен задачами, свободное «окно» для данной автоматизации — через 2-3 месяца
- Нужны компетенции не только в обмене данными с внешним веб-сайтом, но и в обработке данных, прямо как это делают сотрудники
Каждый из перечисленных пунктов замедляет/откладывает процесс автоматизации. Отдельным пунктом стоит то, что на разработку с тестированием, приемкой — уйдет примерно 2-4 недели работы программиста в лучшем случае.
А если мы воспользуемся роботами? Разработчик может прийти к сотруднику, включить средство записи действий UiPath, сотрудник выполнит свой порядок действий за несколько минут, расскажет про нестандартных ситуации… Разработчик возьмет записанный процесс, воспроизведет на своем компьютере, отладит его с учетом нестандартных ситуаций и уже к вечеру того же дня сможет показать сотруднику как робот делает его работу. Само собой, может понадобиться дополнительная отладка с учетом «я еще вспомнил» от сотрудника, но она пройдет довольно быстро, за еще 1-2 дня.
Вот тут мы уже включаем инженера, который не только «гайки крутит», но и экономику считает. И когда мы уже сравниваем условные 3 человеко-дня разработки робота против 10-20 человеко-дней разработки программного кода, то вывод напрашивается сам собой — наш коллега большой молодец. Вместо того, чтобы заниматься этой не очень то критичной проблемой месяц, он сделал ее за 3 дня и теперь может решить еще штук 5 таких же проблем до конца месяца.
Тут, к слову, важно понимание, что роботы — это не затычка для 1-2 задач, это полноценный инструмент для решения вот таких вот проблем с рутиной у сотрудников. Там, где разработка программного кода выходит дороже, чем выгода от этой разработки — спасают именно роботы, так как настраиваются они быстрее, и возврат инвестиций происходит так же в более короткие сроки.
Ну вот другими словами у вас вполне обычная точка зрения: это костыли, костыли — это плохо, но иногда приходится.
Моя точка зрения: в 2021 все меньше и меньше мест, где эти костыли оправданы. Разве в какой-нибудь окологосударственной сфере можно столкнуться, или может в дремучем легаси, чтобы не было открытого интерфейса. Вот у вас даже в качестве примера зачем-то выбрана 1С, у которой API (да не один) и открытый и отлично документированный, а вы на нее роботов натравливаете.
Что касается экономического обоснования и экономии человеко-часов, то подход «тяп-ляп и в продакшен» действительно позволяет экономить и деньги и человекочасы. На первых порах. Очень недолго.
Моя точка зрения: в 2021 все меньше и меньше мест, где эти костыли оправданы. Разве в какой-нибудь окологосударственной сфере можно столкнуться, или может в дремучем легаси, чтобы не было открытого интерфейса. Вот у вас даже в качестве примера зачем-то выбрана 1С, у которой API (да не один) и открытый и отлично документированный, а вы на нее роботов натравливаете.
Что касается экономического обоснования и экономии человеко-часов, то подход «тяп-ляп и в продакшен» действительно позволяет экономить и деньги и человекочасы. На первых порах. Очень недолго.
у вас вполне обычная точка зрения: это костыли,
Позвольте поинтересоваться, где мною хоть раз было написано про костыли? Костыль — это крайне ненадежное обходное решение, которое позволяет решить одну точечную проблему, но при этом ведет к потенциальному возникновению ряда других проблем в будущем.
Если же мы говорим про полноценную платформу роботизации, такую как UiPath — мы говорим о промышленном решении, которое работает в тысячах компаний по всему миру (и сотнях в России). При чем это не какие-нибудь шаражкины конторы, а очень большие солидные компании, в которых требования к качеству, безопасности на очень высоком уровне (например, NASA). Так что ваши слова про «костыли» — однозначно написаны без погружения в тему.
Моя точка зрения: в 2021...
Осмелюсь предположить, что ваша точка зрения основывается на том, что все программы/системы в мире умеют дружиться друг с другом/имеют внятное апи и готовы к взаимной интеграции. Вот только это совсем не так. Как не стараются разработчики — у них никогда не получится сделать «Одно единое приложение, в котором будет работать сотрудник». Исключение, разве что, какая-нибудь касса или инфо-стенды (киоски).
Когда речь идет о реальной работе с реальными документами, реальными ситуациями — людям так или иначе приходится использовать несколько систем/программ/сайтов для достижения хорошего результата. И, как правило, эти системы либо вообще нельзя подружить, либо можно, но только за очень много денег и времени на разработку.
Так что, как бы вам не хотелось, реальный мир устроен немножко иначе, и пока он устроен так — подобную автоматизацию в короткие сроки можно делать только с помощью RPA. Других альтернатив (по крайней мере пока) лично мне неизвестно.
Вот у вас даже в качестве примера зачем-то выбрана 1С, у которой API (да не один) и открытый и отлично документированный, а вы на нее роботов натравливаете.
Мне придется вас разочаровать. Несмотря на то, что, вроде бы, количество 1С-программистов у нас в стране большое, на самом деле их реальный процент среди всех разработчиков довольно мал. Как я уже писал выше: RPA, UiPath — это не про «Давайте не будем писать код в 1С, а натравим робота», а про «давайте автоматизируем работу пользователя между несколькими разными приложениями, системами и сайтами».
А так как мы живем в России — среди этих систем очень часто оказывается 1С (и не всегда это основная система, требующая большого количества автоматизации). И проблема здесь в том, что многие RPA-разработчики в принципе не умеют программировать в 1С (а некоторые и вообще не знают как правильно с 1С работать в пользовательском режиме). Благодаря UiPath — им и не надо тратить время на изучение 1С, им надо просто сесть с бухгалтером и записать его действия. Всё. Вот только есть нюансы при роботизации 1С, о которых и рассказано в данной статье.
подход «тяп-ляп и в продакшен»
Если бы вы роботизировали хотя бы один полноценный процесс — вы бы понимали, что «Тяп-ляп» это про что угодно, но только не про UiPath. Рекомендую изучить матчасть, для начала хотя бы почитать другие статьи аккаунта RPAconsultant, а уже потом подумать над тем является ли это «тяп ляп». Иначе ваши слова звучат крайне непрофессионально.
На первых порах. Очень недолго.
Если вы изучите клиентов UiPath — вы увидите, что большие компании пользуются роботизацией годами, при чем число роботизированных процессов в каждой компании неуклонно растет. А это верный показатель того, что выгода сохраняется не «на первых порах», а надолго.
Если же у вас есть в этом сомнения — послезавтра пройдет митап, где будут выступать представители Российских компаний, в которых роботизация идет полным ходом и все ей полностью довольны. Буду рад видеть вас в слушателях: www.meetup.com/UiPath-RPA-Moscow/events/278450076
Позвольте поинтересоваться, где мною хоть раз было написано про костыли?А за что вы тогда коллегу по шапке если не за костыль?
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Когда речь идет о реальной работе с реальными документами, реальными ситуациями — людям так или иначе приходится использовать несколько систем/программ/сайтов для достижения хорошего результата. И, как правило, эти системы либо вообще нельзя подружить, либо можно, но только за очень много денег и времени на разработку.Вы считаете допустимым в реальной работе какие-то интеграционные задачи в продакшене основывать на пользовательских интерфейсах, которые завтра по желанию разработчика сторонней системы кардинально изменятся? Что, бывают в реальной жизни ситуации когда кто-то гарантирует неизменность пользовательских интерфейсов? Ну тогда у нас с вами ну очень разное представление о продакшене. Возможно я излишне зануден.
Мне придется вас разочаровать. Несмотря на то, что, вроде бы, количество 1С-программистов у нас в стране большое, на самом деле их реальный процент среди всех разработчиков довольно мал.Не надо быть 1С-программистом, чтобы прочитать вот это. Или у ваших разработчиков XML-файл определенной структуры сгенерировать не получится?
А за что вы тогда коллегу по шапке если не за костыль?Внимательно следим за руками:
- Задачу можно решить программированием быстро, API изучен, есть опыт в разработке для данного ПО — нужно писать программу, без альтернатив
- Задачу нельзя решить программированием быстро, API не изучен, нет опыта в разработке для данного ПО — лучше использовать робота
Мир не черно-белый. Всегда есть оттенки серого. И профессионализм — это не готовность писать код для всего на свете, а умение выбирать правильный инструмент для конкретной ситуации. И здесь RPA — это не костыль, а полноценный альтернативный вариант решения проблемы.
на пользовательских интерфейсах, которые завтра по желанию разработчика сторонней системы кардинально изменятся? Что, бывают в реальной жизни ситуации когда кто-то гарантирует неизменность пользовательских интерфейсов?Если мы продолжим следовать вашей логике, то точно так же завтра по желанию разработчика актуальные сегодня методы API могут объявить Deprecated и «приплыли».
Если уж мы говорим про промышленную эксплуатацию, то вам точно должно быть известно, что в любой уважающей себя компании перед тем как устанавливать новую версию ПО — ее проверяют на тестовом стенде. Всегда необходимо проверять корректно ли работает само ПО и все интеграции с ним (в том числе роботов) перед тем как устанавливать обновление на продуктив.
Для этих целей у UiPath есть Test Suite, который позволяет настроить большое количество разнообразных тестов для роботов, нацеленных на разные среды. Вот обновили вы ПО на тестовом контуре — просто запускаете тесты и видите результат: Либо все в порядке, либо вам отображаются сведения где именно что сломалось. С этой информацией можно оперативно исправить конкретные проблемы робота при работе с новой версией. И только после того, как вы убеждены в том, что все роботы работают корректно с новой версией ПО — его можно устанавливать на продуктив.
Ну а если вдруг в компании нет практики «Dev-Test-Prod», то здесь можно только пожать плечами и задаться вопросом — отсутствуют ли вообще проблемы при обновлении продуктива? Как показывает моя практика — такого волшебства не бывает.
Если же речь про публично доступные ресурсы, которые меняются без нашего участия и без нашего тестового контура, то, как правило, дается определенный срок, когда можно нажать кнопку «Перейти на старый дизайн». Роботов так же можно очень быстро научить «перед тем как выполнять работу убеждаться, что мы на старом дизайне, а если это не так — нажимать эту кнопку». Таким образом и роботы продолжают работу, и есть время на перепривязку к новому дизайну.
Не надо быть 1С-программистом, чтобы прочитать вот это. Или у ваших разработчиков XML-файл определенной структуры сгенерировать не получится?Во-первых об этом надо знать, во-вторых, опять же — вам легко сказать «определенной структуры», а дайте Junior-разработчику разбираться с этой «определенной структурой» и замерьте сколько он будет заниматься этим самым разбором.
И что-то мне подсказывает, что разбираться он будет дольше, чем настраивать робота. И да, разрабатывать роботов могут даже Junior-ы/вчерашние студенты, и эти роботы выполняют свою работу качественно, стабильно и без ошибок (само собой, большой опыт разработки всегда будет в плюс и матерый программист сделает робота лучше, чем вчерашний студент, но это уже другая тема)
Известно ли вам про такой инструмент как Vanessa-Automation?
И про принцип/подход использованный там:
И про принцип/подход использованный там:
Итого: Фирма 1С написала свой Selenium, который встроен в платформу 1С: Предприятие. И этот Selenium от 1С имеет преимущества. Например, любой элемент управления (он же control) на форме всегда имеет уникальное имя, которое в 99.99% случаев известно заранее.
Соответственно нет проблем с локаторами, а чтобы найти элемент управления достаточно написать:
ИскомыйЭлементУправления = ФормаДокумента.НайтиОбъект(,, УникальноеИмя);
Это бесспорно очень хороший инструмент для экосистемы 1С. Вот только вопрос — насколько он хорошо работает за рамками 1С? Когда надо роботизировать множество других приложений/систем, каждое из которых написано по своему (одно на Java, другое web, третье WPF, четвертое winapi, и вдобавок 1С). Ведь в этом, в общем-то, и сила RPA — возможность связать несвязуемое (или то, на связывание чего через программный код уйдет в лучшем случае половина года).
Во сколько обойдется клиенту решение конкретного кейса из видео? Просьба без маркетингового мусора и скользких оговорок расписать цену в рублях РФ:
— за лицензии
— за часы работы аналитика и программиста РПА для создания конкретно указанного кейса из видеопримера
— за какие -то еще вещи которые в реальном примере потребуются
За рамками цены РПА продуктов вижу цену на отдельный комп, цену на перевод 1С из однопользовательского варианта надомника-тёти-бухгалтера в сетевую двухкомпьютерную
Кстати, сама разработчик 1С сделала в большинстве современных 1С продуктах типовой автоматический обмен между базами, который настраивается пользователем.
— за лицензии
— за часы работы аналитика и программиста РПА для создания конкретно указанного кейса из видеопримера
— за какие -то еще вещи которые в реальном примере потребуются
За рамками цены РПА продуктов вижу цену на отдельный комп, цену на перевод 1С из однопользовательского варианта надомника-тёти-бухгалтера в сетевую двухкомпьютерную
Кстати, сама разработчик 1С сделала в большинстве современных 1С продуктах типовой автоматический обмен между базами, который настраивается пользователем.
Если вас интересует стоимость лицензий и часы работы конкретных специалистов — вам лучше обратиться к официальному дистрибьютору, или же к любому из партнеров UiPath в России.
В данной конфигурации, соответственно, у вас не будет никакой необходимости переводить 1С из однопользовательского режима в сетевой.
За рамками цены РПА продуктов вижу цену на отдельный комп, цену на перевод 1С из однопользовательского варианта надомника-тёти-бухгалтера в сетевую двухкомпьютернуюНа самом деле такой необходимости нет. В отличие от ряда конкурентов, с которыми вы, возможно, сталкивались, у UiPath имеются «роботы-помощники» (в английском варианте — attended robots) — это специальный вид роботв, который может устанавливаться прямо на компьютер пользователя и вызываться им по требованию (кроме того, его можно научить следить за определенными событиями и он будет предлагать выполнить ту или иную работу самостоятельно).
В данной конфигурации, соответственно, у вас не будет никакой необходимости переводить 1С из однопользовательского режима в сетевой.
Кстати, сама разработчик 1СВы можете ознакомиться с перепиской выше, где полностью объяснено когда стоит применять роботов, а когда не стоит. Кратко: Если у вас только 1С и ничего кроме 1С — скорее всего, роботы вам не нужны. Если 1С — одна из нескольких систем, которые не умеют дружить друг с другом (а разработка дружбы стоит дорого и будет идти долго), то роботы избавят вас от этой головной боли быстро, и, вполне возможно, дешевле, чем кастомная разработка интеграции.
Последние год-два регулярно лезет рекламный спам с аббревиатурой RPA. Ребята, нельзя ли на вашей стороне настроить тоньше фильтры и рекламные бюджеты, не показывая это тем, кто уже ознакомлен с существованием вашего продукта? Чересчур агрессивное навязывание
Sign up to leave a comment.
Лайфхаки для роботизации 1С