6 причини, поради които проектите за автоматизация на роботизирани процеси (RPA) се провалят и как да ги избегнем

Снимка от chuttersnap в Unsplash

Роботизирана автоматизация на процесите (RPA) е гореща тема в полетата за автоматизация и AI. По същество RPA е софтуерен инструмент, който постига автоматизация, като имитира човешки действия, основани на правила и повтарящи се. RPA използва робот или бот за автоматизиране на процесите. Днес в индустрията има много доставчици на RPA, като основните играчи са Automation Anywhere (AA), Blue Prism и UiPath. Ако сте малък бизнес или студент, който изследва RPA полето, повечето от доставчиците предоставят и общностна версия на техните инструменти, която е свободна за използване.

Внедряването на RPA следва жизнения цикъл на развитието на системата (SDLC). Тази статия описва възможните неуспехи в RPA проект, които биха могли да се случат на етапите на SDLC, и как да ги избегнем.

Фази SDLC на проекта RPA
1. Планиране: Избор на правилния процес за автоматизация 2. Анализ: Битката за изискванията 3. Дизайн: Как да избегнем създаването на лош дизайн на решение 4. Разработка: Разпознаване на разликите в средата напред 5. Тестване: Тестови сценарии, които често се пропускат в RPA проекти 6. Хипер-грижа: Ами ако роботът се повреди твърде често?

1. Планиране: Избор на правилния процес за автоматизиране

Първата стъпка в един проект за RPA е да изберете правилния процес за автоматизиране. Лицето, извършващо подбора и оценката, трябва да е запознато с кандидатите за процеса и инструмента за RPA. Има два подхода за оценяване дали процесът е възможен за RPA, които са методите отгоре надолу и отдолу нагоре.

Метод отгоре надолу: Избор на процес чрез идентифициране на ползите, свързани с бизнеса
Метод отдолу нагоре: Избор на процес чрез оценка на техническата приложимост

Методът отгоре надолу обикновено се извършва от ръководно лице, което е запознато и запознато с контекста на процеса, като например броя на служителите, участващи в процеса, настоящото споразумение за ниво на обслужване и въздействието на RPA върху другия процеси и бизнес звена. Този метод обикновено се извършва на много високо ниво, където хората разглеждат множество възможности за процеса едновременно.

От друга страна, подходът „отдолу нагоре“ се осъществява от архитекта или разработчика на RPA решение, който разбира методологията и функциите на RPA. Подходът „отдолу нагоре“ включва идентифициране на необходимата наличност на околната среда, сигурност и наличността на робота. Този подход може да се случи и във фазата на анализ, когато разработчикът събира изисквания.

Достъпът до процес с двата подхода гарантира изпълнимостта на RPA и избягва изхабяването на ресурси в предстоящите дейности.

2. Анализ: Битката за изискванията

Когато е избран процес за RPA, можем да започнем да събираме изисквания. Ако RPA е първият проект за автоматизация на организацията, вероятно повечето от заинтересованите страни / потребители не са запознати с технологията. По този начин бизнес анализаторът на RPA трябва да представи РПА на съответните заинтересовани страни. За бизнес анализатора би било по-лесно да събере изисквания от потребителите, когато са наясно как работи RPA и ползите от него. Често бизнес анализаторът може да открие, че потребителите пропускат определени стъпки и изход, необходими при обсъждане на изисквания, тъй като може да не са запознати с автоматизацията и до каква степен RPA роботът може или не може да направи.

Снимка от Джеймс Понд на Unsplash

Другият сценарий, с който бизнес анализаторът може да се сблъска, са допълнителни изисквания към потребителите. Правилото, ако в обхвата трябва да се добавят допълнителни изисквания, първо е да се разбере колко време отделя ежедневно потребителят за допълнителен обхват; и броя на потребителите, използващи функциите от новия обхват. Бизнес анализаторът може също да се наложи да отдели много време, за да анализира допълнителните изисквания. Допълнителният обхват може лесно да добави усилието / времето, необходимо за извършване на разработка и тестване.

По този начин е разумно да общувате с потребителите относно обхвата и как допълнителният обхват може да възпрепятства срока на разработка.

3. Дизайн: Как да избегнем създаването на дизайн с лошо решение

След като разберем изискванията, е време да създадем план за нашия робот! RPA роботите са технологии за автоматизация, предназначени да намалят излишните работни задачи за хората и затова са чудесни за извършване на повтарящи се и ниско стойностни задачи.

Повечето от роботите по RPA имат четири типични стъпки при автоматизиране на процеса, включително извличане и валидиране на данни, автоматизиране на основния процес (например въвеждане на данни, изчисления) и генериране на изходи и резултати от данни.

Можете да прочетете повече за четирите основни стъпки тук. Тъй като роботите вършат повтарящи се задачи, зад сцената се случват много цикли и ако / иначе логика. Във фазата на проектиране е важно да се коригира логиката на кодиране, за да се избегнат проблеми с дизайна в бъдеще. Следващите примери са някои от съображенията, които архитектът на решения трябва да вземе предвид при създаването на дизайна на решение в RPA проект:

Съвети за проектиране на RPA Solution: 1. Основната логика за цикъл за обработка на всички записи (въвеждане на данни) трябва да е налична за всеки процес
2. Роботът трябва да генерира резултати за всеки запис (въвеждане на данни), като "OK", "fail" и забележки, ако е необходимо 
3. Роботът трябва да уведомява потребителя, когато е завършил процес чрез изскачащи прозорци, имейл и т.н.
4. Планиране на връщане назад: ако се случи грешка, върнете се на стъпка X, за да продължите обработката на следващия запис
5. Планиране на връщане назад: ако се случи повреда в системата, спрете процеса и затворете приложението преди излизането на робота
6. Уверете се, че всички използвани приложения са затворени преди излизането на робота

Прекарването на достатъчно време във фазата на проектиране е от решаващо значение за осигуряване на плавен жизнен цикъл на разработване на RPA. Документът за проектиране на решение също трябва да изброява всички потенциални изключения, които биха се случили, и обяснява как роботите трябва да се справят с изключенията.

4. Развитие: Разпознаване на различията в околната среда напред

RPA роботите разчитат на потребителския интерфейс (UI), за да знаят как и кога той трябва да въведе клавиш за бърз достъп, щракнете или изпълнете функция. Идентичните екрани на приложения във всички среди (разработка, тестване за приемане от потребители (UAT) и специфична среда за производство) биха помогнали за подобряване на процеса на разработка. Въпреки това, поведението на приложението често е леко различно във всяка среда и когато се използва от различни типове потребители. По този начин, разработчикът трябва да планира планове за действие при извънредни ситуации, когато е установено такова несъответствие.

Снимка на Кевин Ку на Unsplash

В най-добрия случай архитектът на решения трябва да идентифицира и да се справи с проблемите във фазата на проектиране. По този начин е възможно несъответствия да се открият само в развитието. Когато се случи такава ситуация, разработчикът трябва да обсъди с архитекта на решение, за да провери дали е необходим нов дизайн на решение и да направи анализ на въздействието върху останалите стъпки на процеса.

Друго основно правило при разработването на RPA е да пишете модулирани кодове и да използвате повторно модулите толкова често, колкото е необходимо. Разработчиците на RPA често могат да се сблъскат със ситуации, в които процесът на процеса трябва да бъде променен поради пренебрегвани или допълнителни изисквания. По този начин един модулиран код би спестил време, тъй като разработчикът трябва само да направи промени в определени редове от код, за да отразява необходимите промени.

5. Тестване: Тестови сценарии, които често се пропускат в проекти по RPA

Има две основни области за тестване на роботите RPA: свързани с RPA и бизнес изисквания. Когато правите тестове, е лесно да пропуснете функционалните спецификации, свързани с технологията RPA, тъй като може да не е изрично посочен в проектните документи. Ето някои тестови сценарии за двете области:

Свързани с RPA сценарии - сценарии за прозорец, обект не са намерени - множество роботи, изпълняващи един и същ процес по едно и също време - всички приложения затворени преди излизането на робота - лог файлът се запазва и чете за всеки процес на стартиране
Свързани с бизнеса сценарии - сценарий за въвеждане на данни не е предоставен - успешно въведете име, възраст и запазете потребителския профил - Резултатът от изчислението е правилен - отпечатайте резултата за грешка, ако не е посочено име, и продължете процеса - брой на запазените FTE (макро KPI)

Сценариите за тестване се прилагат за всички среди и трябва да включват тестване на възможно най-много отрицателни сценарии. Във фазата на UAT потребителите биха могли да видят „физически“ изход от робота и често могат да поискат козметични промени по отношение на начина, по който се представя продукцията. Така че, разработчиците винаги трябва да проверяват с потребителите дали са доволни от резултатите от тестовете.

6. Хипер-грижа: Ами ако роботът се повреди твърде често?

Честито! Вашият робот RPA вече е разгърнат! Сега е въпрос само на мониторинга на роботите, за да се уверите, че те изпълняват процеса като задействан.

Можем да определим сценарий като „RPA роботът е функционирал“, ако процесът на изпълнение не е постигнал очаквания резултат / ключови показатели за ефективност (KPI), обикновено посочени в проекта на харта.

Някои примерни RPA KPI включват: 
- Брой записани FTE (макро KPI) -% от времето / изпълнение, което се нуждае от човешка намеса - Брой записи за обработка на час / ден - Брой записи, обработени успешно от робота

Освен наблюдение на поведението на роботите и изследване на изключенията, хората често пропускат да записват и измерват ефективността на роботите. По този начин екипът на RPA трябва да подготви списък на KPI, за да измери и ресурсите, посветени на разбирането и анализа, дали прилагането на RPA е успешно.

От страна на забележка, са необходими подобрения, ако роботите не работят както се очаква или хвърлят твърде много изключения обратно към потребителя. Типично е да разгърнете процес за 2-3 пъти в производствената среда, ако това е вашият първи RPA проект.

Снимка на Филип Гликман на Unsplash

Честита автоматизация!