Скорость разработки - это преимущество, но как боретесь с изменением интерфейса систем и изменением функциональности? Ведь API - это всё-таки некий легальный контракт взаимодействия, который система предоставляет для других систем. И молча API, даже самописный, просто так не изменить - как правило API версионируется, остаётся (какое-то время) обратная совместимость со старыми версиями, и процесс не упадёт при добавлении новой версии и изменении какой-то сигнатуры методов.
В тоже время робот запрограммирован на выполнение кликов по определённым контролам. Меняется разметка веб страницы, меняется функциональность кнопки - и робот падает, процесс встаёт.
И встаёт вопрос о затратах на переделку робота + траты от простоя по процессу.
Это сообщение коррелирует с моим вторым вопросом про поддержку решений - на него ответ не получил. Кто поддерживает разработанные решения? Кто контролирует доработку решений? И ещё вопрос: есть ли процедуры ревьюирования решений с целью предотвратить изобретение велосипедов и использования роботов только ради использования роботов и с целью быстрой реализации? Как это происходит при таком большом количестве роботизируемых процессов?
Есть вопрос по организации кода: у вас большое количество компонент и теперь появляется большое количество директив-контроллеров с конкретной реализацией логики. Как удаётся отслеживать появление новых директив, дублирующих существующую функциональность?
И ещё вопрос, связанный с миграцией старого кода на новый: как организовали переход существующих компонент на директивы-контроллеры?
Beeline Казахстан: как за два года роботизировать почти 300 бизнес-процессов и сформировать свой отдел RPA-разработки
Спасибо за ответ.
Скорость разработки - это преимущество, но как боретесь с изменением интерфейса систем и изменением функциональности? Ведь API - это всё-таки некий легальный контракт взаимодействия, который система предоставляет для других систем. И молча API, даже самописный, просто так не изменить - как правило API версионируется, остаётся (какое-то время) обратная совместимость со старыми версиями, и процесс не упадёт при добавлении новой версии и изменении какой-то сигнатуры методов.
В тоже время робот запрограммирован на выполнение кликов по определённым контролам. Меняется разметка веб страницы, меняется функциональность кнопки - и робот падает, процесс встаёт.
И встаёт вопрос о затратах на переделку робота + траты от простоя по процессу.
Это сообщение коррелирует с моим вторым вопросом про поддержку решений - на него ответ не получил. Кто поддерживает разработанные решения? Кто контролирует доработку решений? И ещё вопрос: есть ли процедуры ревьюирования решений с целью предотвратить изобретение велосипедов и использования роботов только ради использования роботов и с целью быстрой реализации? Как это происходит при таком большом количестве роботизируемых процессов?
Beeline Казахстан: как за два года роботизировать почти 300 бизнес-процессов и сформировать свой отдел RPA-разработки
Спасибо за статью!
Почему была выбрана роботизация вместо автоматизации (и реализации на ЯП: Java, Python и т.д.)?
Кто занимается сопровождением роботизированных процессов?
Как мы работу с корреспонденцией оптимизировали
Да, посчитали. Основная экономия получилась на:
FTE (экономим время сотрудников, работающих с корреспонденцией) ;
Бумаге, конвертах;
На выкупе возвратных писем.
Концепция контроллеров компонента в Angular: часть вторая
Спасибо за статью!
Есть вопрос по организации кода: у вас большое количество компонент и теперь появляется большое количество директив-контроллеров с конкретной реализацией логики. Как удаётся отслеживать появление новых директив, дублирующих существующую функциональность?
И ещё вопрос, связанный с миграцией старого кода на новый: как организовали переход существующих компонент на директивы-контроллеры?