[Анализ и проектирование систем, IT-инфраструктура, Проектирование и рефакторинг, Usability, Data Engineering] RPA — обезболивающее или серебряная пуля?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
RPA (Robotic Process Automation) сейчас в некотором смысле напоминает старую добрую миниатюру Реввы: “Киииборги. Они заполонили всю планету!”. Про RPA говорят все чаще и чаще, появляются статьи и видео, рассказывающие о небывалом росте этого сегмента и многомиллионных экономиях тех, кто уже внедрил у себя RPA. Не то, чтобы и раньше этого не было, но сейчас стало уж совсем много.Отзывов настоящих пользователей существенно меньше. Это не говорит о том, что RPA это плохо. Это просто факт, который и побудил меня написать эту статью и поделиться своими размышлениями.Некоторое время назад, столкнувшись с определенными задачами, я выбирал средство для их решения и обратил внимание именно на RPA. Прорвавшись через миллион рекламных статей и восторженных видео от реселлеров, протестировав практически все, что доступно в trial / free версиях, я остановился на Automation Anywhere, который неплохо подходил под требования. Позже, к слову, я обнаружил что в нашей компании существует целый отдел, который занимается автоматизацией с помощью Blue Prism. Обратная, так сказать, сторона крупных корпораций - не всегда знаешь, что у нас уже есть…Ну да речь не об этом. Не сразу, но через какое-то время я обнаружил, что самая сложная задача в RPA, это вовсе не написание роботов и не процесс их имплементации и сопровождения. Самое сложное - это управление ожиданиями на стороне менеджмента. Понимаете - они не инженеры, они управленцы. Они не понимают и не знают как, а главное почему, многие вещи работают так или иначе. Они читают такие же рекламные статьи и смотрят такие же рекламные видео как я в самом начале - и делают вывод: “Это же то, что нам нужно! Это решит все проблемы!”. И начинают интенсивно форсировать процесс внедрения. И хорошо, если есть внутренний инженерный ресурс, который этим вопросом будет заниматься и подскажет, что где и как. А вот если задача попадет к интеграторам - это может быть большой проблемой. Может быть не сразу, может быть в перспективе, но я думаю что обязательно будет, и вот почему:Зачем нужен RPAДля автоматизации повторяющихся процессов, которые выполняются вручную и не требуют когнитивных усилий или принятий решений выходящих за рамки стандартных алгоритмов. Хороший пример, с которого я начал путь в RPA: есть отдел поддержки клиентов, который в конце каждого месяца получает от вендоров новые ставки по продуктам для различных продавцов. Получают в произвольном формате - от скриншота из Excel, до просто текста в письме. И до 1-го числа (а точнее даже раньше) они должны:
- Перенести все данные в внутреннюю Excel таблицу
- Провести кросс-проверки, все ли правильно они внесли
- Для каждого продавца (в том случае их было 42 и 13 продуктов) завести предложение на следующий месяц в CRM. Это куча полей, куда очень, очень аккуратно нужно перенести данные, добавить специальным образом сформированные txt файлы с SKU и еще десяток различных манипуляций.
- Провести кросс-проверку, все ли правильно они внесли
- Уведомить продавцов, что новое предложение для них сформировано и его нужно принять до 1-го числа, иначе все превратиться в тыкву.
- Убедиться что все предложения были приняты
- Сформировать внутренний Change Log, в котором описывается какие изменения произошли с каждым из продуктов для каждого из продавцов.
- Ну и еще некоторое количество различных манипуляций.
А так как это не единственная и далеко на главная работа этих людей, плюс добавьте к этому давление из-за ограниченности сроков - и вы сразу поймете с какой радостью они приняли RPA решение, которое за 12 минут делало то, на что они тратили как минимум два дня.Примеров, таких как описанный выше, скопилось за год работы с RPA довольно много. RPA, к слову, справился с ними на отлично. Разработка была довольно быстрой, надежность высокая - в целом, можно сказать что все хорошо. На одном пункте относящемуся к этому я остановлюсь чуть позже.Казалось бы все хорошо - был ужасный процесс, который нервировал людей, тратил их время, которое могло бы пойти на развитие бизнеса, заставлял их овертаймить. Теперь этого процесса нет - все делает трудолюбивый как пчелка Майя робот. Но все ли на самом деле хорошо? И правильный ответ - нет. Потому что отойдя от эйфории, стоит задуматься над следующим вопросом:Почему нужен RPA
Потому что у вас есть процессы, которых… не должно существовать! Смотрите, давайте представим воображаемую сферическую компанию в вакууме. У нее есть процесс А и процесс Б. Простейший путь между ними - это прямая. Импульс возникает в А и передается в Б. Все просто. Все работает. Программисты, которые создавали эту систему хорошо поработали, все настроили, отладили, протестировали. Процесс работает как часы. Компания растет, программисты начинают разрабатывать другие бизнес решения, количество которых, само собой, растет каждый год. Процессы А и Б продолжают работать, но тут возникает первая загвоздка. В цепочке А->Б возникает дополнительное требование. Неважно какое - может быть достаточно небольшое, главное, что оно в этой системе А-Б отсутствует в native виде. Пользователь обращается к разработчикам - но им не до этой маленькой фичи. Они заняты очень приоритетными процессами, их можно понять. Поэтому пользователь, видя что его задача висит где-то в конце очереди, начинает выкручиваться. И делает небольшой кусочек работы где-нибудь, скажем, в Excel. С точки зрения пользователя - ничего страшного, ну, добавилась небольшая мелочь, но все же работает дальше как часы. С точки зрения менеджмента и разработчиков - еще лучше, задачу можно де-приоритизировать и вообще отложить в очень долгий ящик. И это начало конца. Импульс уже не идет по кратчайшей прямой из А в Б. Он делает небольшое ответвление. А потом возникает новое требование - и ситуация повторяется. И опять, и опять… И это нормально - мир переменчив, выживают те, кто умеют быстро адаптироваться. Только вот пользователь после 3-4 раза уже даже не приходит к разработчикам, а сразу занимается самолечением, добавляя и добавляя новые сущности и подпроцессы.И путь уже выглядит не как прямая, а как-то так:
В какой-то момент ситуация доходит до момента, когда пользователь начинает кричать и звать на помощь. Потому что дедлайны, овертаймы, стресс и вот это вот все. И вот тут то и появляется RPA. Которое путем терпимой суммы денег и незамысловатой разработки избавит пользователя от страданий. Пользователь доволен. Менеджмент тоже, как вы понимаете, доволен - проблема ведь решена, верно? И разработчики в целом наверное тоже довольны - их не выдернут посреди спринта разбирать авгиевы конюшни. А решена ли на самом деле проблема? Нет. Мы всего лишь добавили очередной виток в той безумной спирали, куда сваливается незамысловатая цепочка процессов А и Б. А таких процессов еще много - и чем крупнее компания, тем больше. Причем заметьте - не простой виток, как новая табличка в Excel, понятная и привычная пользователю. Нет, мы добавили сложное технологическое решение, которое ставит нас в зависимость от сторонней компании, наличия ресурсов на поддержание и развитие этой компоненты и так далее. Т.е. теперь в будущем пользователя будут игнорировать не только разработчики, но и RPA команда.И тут самый подходящий момент вернуться, как я обещал выше к одной теме. Некоторые RPA вендоры в рекламе заходят так далеко, что чуть ли не пользователь может сам построить робота и решить все свои проблемы. Забудьте об этом сразу - RPA подразумевает инфраструктуру и навыки, которых у обычного пользователя нет в принципе, иначе бы он работал на совсем другой работе. Да, бывают очень незамысловатые роботы - но взгляните на процесс приведенный в качестве примера. Без знания что такое SDLC, XPath, VBA и алгоритмического мышления этого робота в реальности было бы просто невозможно создать. По сути это была полноценная разработка, пусть даже и code less. ВыводыИ это возвращает нас к тому, с чего я начал. Управление ожиданиями. Внедряя RPA вы должны очень четко дать понять руководству (или просто осознать, если вы и есть руководство), что RPA - это не серебряная пуля, которая решит все ваши проблемы. Ваши проблемы остануться на месте, они продолжать расти и становиться больше и больше. Пока не рухнут окончательно под собственным весом.Но RPA это совершенно потрясающее обезболивающее, которое позволит вам выиграть время, необходимое на то, чтобы привести в систему в порядок. Оно снимет симптомы и уберет боль, пользователь в краткосрочной перспективе прекратит страдать и порываться убежать из вашей компании. Процессы продолжат бежать - ведь show must go on. Используйте это время с умом и найдите долгосрочное решение. Избавьтесь от процессов, которые не должны существовать. Проведите анализ и ретроспективы, чтобы понять как сделать, чтобы такое никогда не повторилось. К счастью в нашей компании это понимание удалось сформировать. Мы не стали создавать специальный RPA отдел, а взамен его мы создали Business Process Automation team, которая приходит к пользователю, изучает его процесс и делает две вещи - разрабатывает (обычно за неделю-две) краткосрочное решение используя любые подручные методы (RPA, Python, Excel, RTFM, etc.) и выносит рекомендации для менеджмента и разработчиков по общему реинжинирингу процессов и системы, которые должны привести к тому, что линия между процессами опять станет прямая.Здоровых вам процессов и да прибудет с вами сила.P.S. Без сомнения - существуют процессы, в которых RPA окажется идеальным решением. Например работа с внешним web application, который категорически не хочет отдавать (или принимать) нужные вам данные через API. А они вам очень нужны, и их нужно упаковать в Excel, и вы достаете все это вручную… Да, RPA тут будет хорош. Как и в парсинге сложных страниц, где нужно проводить определенные манипуляции до считывания данных. Только такие примеры не очень часто фигурируют в рекламе RPA продуктов - так что эту тонкую грань между использованием RPA для латания дыр на тонущем корабле и хорошим инструментом - придется вам нащупать самостоятельно.
===========
Источник:
habr.com
===========
Похожие новости:
- [Проектирование и рефакторинг, Управление разработкой] Continious Refactor
- [Системное администрирование, IT-инфраструктура, Облачные сервисы, Софт] 3CX Bridge: как связать несколько IP-АТС 3CX в единую систему
- [IT-инфраструктура, Виртуализация, IT-компании, Микросервисы, Kubernetes] Угрожает ли микросервисная (контейнеризация) архитектура светлому будущему Published Apps (Citrix & Co.)
- [Анализ и проектирование систем, Erlang/OTP, Параллельное программирование, Elixir/Phoenix] To spawn, or not to spawn? (перевод)
- [IT-инфраструктура, Гаджеты, История IT, IT-компании] Уроки Symbian OS — фиаско топ менеджеров, колосс на глиняных ногах, или неотвратимость бытия?
- [Анализ и проектирование систем, Управление проектами, Инженерные системы] Архитектура архитектуры: воспалённый аппендикс
- [Проектирование и рефакторинг, CAD/CAM, Реверс-инжиниринг, Прототипирование, Подготовка технической документации] Основные проблемы фриланса для инженера-конструктора в машиностроении
- [Клиентская оптимизация, Бизнес-модели] Что нужно знать перед началом роботизации процессов?
- [IT-инфраструктура, Сетевые технологии, Законодательство в IT, Сетевое оборудование, IT-компании] Роскомнадзор опроверг проблемы и сбои у операторов связи из-за оборудования для «суверенного рунета»
- [Big Data, Data Engineering] Как мы выбирали Data Catalog, но в итоге оставили все как есть
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_itinfrastruktura (IT-инфраструктура), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_usability, #_data_engineering, #_rpa, #_automation, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_itinfrastruktura (
IT-инфраструктура
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_usability, #_data_engineering
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:56
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 RPA (Robotic Process Automation) сейчас в некотором смысле напоминает старую добрую миниатюру Реввы: “Киииборги. Они заполонили всю планету!”. Про RPA говорят все чаще и чаще, появляются статьи и видео, рассказывающие о небывалом росте этого сегмента и многомиллионных экономиях тех, кто уже внедрил у себя RPA. Не то, чтобы и раньше этого не было, но сейчас стало уж совсем много.Отзывов настоящих пользователей существенно меньше. Это не говорит о том, что RPA это плохо. Это просто факт, который и побудил меня написать эту статью и поделиться своими размышлениями.Некоторое время назад, столкнувшись с определенными задачами, я выбирал средство для их решения и обратил внимание именно на RPA. Прорвавшись через миллион рекламных статей и восторженных видео от реселлеров, протестировав практически все, что доступно в trial / free версиях, я остановился на Automation Anywhere, который неплохо подходил под требования. Позже, к слову, я обнаружил что в нашей компании существует целый отдел, который занимается автоматизацией с помощью Blue Prism. Обратная, так сказать, сторона крупных корпораций - не всегда знаешь, что у нас уже есть…Ну да речь не об этом. Не сразу, но через какое-то время я обнаружил, что самая сложная задача в RPA, это вовсе не написание роботов и не процесс их имплементации и сопровождения. Самое сложное - это управление ожиданиями на стороне менеджмента. Понимаете - они не инженеры, они управленцы. Они не понимают и не знают как, а главное почему, многие вещи работают так или иначе. Они читают такие же рекламные статьи и смотрят такие же рекламные видео как я в самом начале - и делают вывод: “Это же то, что нам нужно! Это решит все проблемы!”. И начинают интенсивно форсировать процесс внедрения. И хорошо, если есть внутренний инженерный ресурс, который этим вопросом будет заниматься и подскажет, что где и как. А вот если задача попадет к интеграторам - это может быть большой проблемой. Может быть не сразу, может быть в перспективе, но я думаю что обязательно будет, и вот почему:Зачем нужен RPAДля автоматизации повторяющихся процессов, которые выполняются вручную и не требуют когнитивных усилий или принятий решений выходящих за рамки стандартных алгоритмов. Хороший пример, с которого я начал путь в RPA: есть отдел поддержки клиентов, который в конце каждого месяца получает от вендоров новые ставки по продуктам для различных продавцов. Получают в произвольном формате - от скриншота из Excel, до просто текста в письме. И до 1-го числа (а точнее даже раньше) они должны:
 Потому что у вас есть процессы, которых… не должно существовать! Смотрите, давайте представим воображаемую сферическую компанию в вакууме. У нее есть процесс А и процесс Б. Простейший путь между ними - это прямая. Импульс возникает в А и передается в Б. Все просто. Все работает. Программисты, которые создавали эту систему хорошо поработали, все настроили, отладили, протестировали. Процесс работает как часы. Компания растет, программисты начинают разрабатывать другие бизнес решения, количество которых, само собой, растет каждый год. Процессы А и Б продолжают работать, но тут возникает первая загвоздка. В цепочке А->Б возникает дополнительное требование. Неважно какое - может быть достаточно небольшое, главное, что оно в этой системе А-Б отсутствует в native виде. Пользователь обращается к разработчикам - но им не до этой маленькой фичи. Они заняты очень приоритетными процессами, их можно понять. Поэтому пользователь, видя что его задача висит где-то в конце очереди, начинает выкручиваться. И делает небольшой кусочек работы где-нибудь, скажем, в Excel. С точки зрения пользователя - ничего страшного, ну, добавилась небольшая мелочь, но все же работает дальше как часы. С точки зрения менеджмента и разработчиков - еще лучше, задачу можно де-приоритизировать и вообще отложить в очень долгий ящик. И это начало конца. Импульс уже не идет по кратчайшей прямой из А в Б. Он делает небольшое ответвление. А потом возникает новое требование - и ситуация повторяется. И опять, и опять… И это нормально - мир переменчив, выживают те, кто умеют быстро адаптироваться. Только вот пользователь после 3-4 раза уже даже не приходит к разработчикам, а сразу занимается самолечением, добавляя и добавляя новые сущности и подпроцессы.И путь уже выглядит не как прямая, а как-то так:  В какой-то момент ситуация доходит до момента, когда пользователь начинает кричать и звать на помощь. Потому что дедлайны, овертаймы, стресс и вот это вот все. И вот тут то и появляется RPA. Которое путем терпимой суммы денег и незамысловатой разработки избавит пользователя от страданий. Пользователь доволен. Менеджмент тоже, как вы понимаете, доволен - проблема ведь решена, верно? И разработчики в целом наверное тоже довольны - их не выдернут посреди спринта разбирать авгиевы конюшни. А решена ли на самом деле проблема? Нет. Мы всего лишь добавили очередной виток в той безумной спирали, куда сваливается незамысловатая цепочка процессов А и Б. А таких процессов еще много - и чем крупнее компания, тем больше. Причем заметьте - не простой виток, как новая табличка в Excel, понятная и привычная пользователю. Нет, мы добавили сложное технологическое решение, которое ставит нас в зависимость от сторонней компании, наличия ресурсов на поддержание и развитие этой компоненты и так далее. Т.е. теперь в будущем пользователя будут игнорировать не только разработчики, но и RPA команда.И тут самый подходящий момент вернуться, как я обещал выше к одной теме. Некоторые RPA вендоры в рекламе заходят так далеко, что чуть ли не пользователь может сам построить робота и решить все свои проблемы. Забудьте об этом сразу - RPA подразумевает инфраструктуру и навыки, которых у обычного пользователя нет в принципе, иначе бы он работал на совсем другой работе. Да, бывают очень незамысловатые роботы - но взгляните на процесс приведенный в качестве примера. Без знания что такое SDLC, XPath, VBA и алгоритмического мышления этого робота в реальности было бы просто невозможно создать. По сути это была полноценная разработка, пусть даже и code less. ВыводыИ это возвращает нас к тому, с чего я начал. Управление ожиданиями. Внедряя RPA вы должны очень четко дать понять руководству (или просто осознать, если вы и есть руководство), что RPA - это не серебряная пуля, которая решит все ваши проблемы. Ваши проблемы остануться на месте, они продолжать расти и становиться больше и больше. Пока не рухнут окончательно под собственным весом.Но RPA это совершенно потрясающее обезболивающее, которое позволит вам выиграть время, необходимое на то, чтобы привести в систему в порядок. Оно снимет симптомы и уберет боль, пользователь в краткосрочной перспективе прекратит страдать и порываться убежать из вашей компании. Процессы продолжат бежать - ведь show must go on. Используйте это время с умом и найдите долгосрочное решение. Избавьтесь от процессов, которые не должны существовать. Проведите анализ и ретроспективы, чтобы понять как сделать, чтобы такое никогда не повторилось. К счастью в нашей компании это понимание удалось сформировать. Мы не стали создавать специальный RPA отдел, а взамен его мы создали Business Process Automation team, которая приходит к пользователю, изучает его процесс и делает две вещи - разрабатывает (обычно за неделю-две) краткосрочное решение используя любые подручные методы (RPA, Python, Excel, RTFM, etc.) и выносит рекомендации для менеджмента и разработчиков по общему реинжинирингу процессов и системы, которые должны привести к тому, что линия между процессами опять станет прямая.Здоровых вам процессов и да прибудет с вами сила.P.S. Без сомнения - существуют процессы, в которых RPA окажется идеальным решением. Например работа с внешним web application, который категорически не хочет отдавать (или принимать) нужные вам данные через API. А они вам очень нужны, и их нужно упаковать в Excel, и вы достаете все это вручную… Да, RPA тут будет хорош. Как и в парсинге сложных страниц, где нужно проводить определенные манипуляции до считывания данных. Только такие примеры не очень часто фигурируют в рекламе RPA продуктов - так что эту тонкую грань между использованием RPA для латания дыр на тонущем корабле и хорошим инструментом - придется вам нащупать самостоятельно. =========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ), #_itinfrastruktura ( IT-инфраструктура ), #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_usability, #_data_engineering |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:56
Часовой пояс: UTC + 5