KT Sparks

Ботове, които оцеляват в продукция

Всеки провал на RPA, който сме наследили, се свежда до едно от четири неща.

Инженерна практика2 мин. четене

Bots that survive contact with production

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

Автоматизациите умират по обикновени начини

Не драматично. Доставчик пуска промяна в интерфейса. Сертификат изтича. Файл, който пристигаше в 06:00, идва в 06:40, а задачата вече се е отказала. Някой преименува колона. Ботът продължава да работи и не произвежда нищо или, още по-лошо, произвежда нещо правдоподобно.

Нито едно от тези неща не е екзотично. Всички са преодолими, ако изграждането е предвидило, че ще дойдат.

Проектирайте първо нещастния път

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

Автоматизация без маршрут за изключения не е 90% автоматизирана. Тя е 90% автоматизирана и 10% невидима, а невидимата част се трупа безшумно до края на тримесечието.

Четири неща, които трябва да съществуват преди пускането

Мониторинг на резултата, а не на здравето на процеса. „Задачата се изпълни“ не е сигналът. „Задачата осчетоводи 412 документа, което е в рамките на две стандартни отклонения за вторник“ - това е сигналът.

Сигнал с име към него. Сигналите, насочени към обща пощенска кутия, са сигнали, за които никой не отговаря. Посочете човек и заместник.

Оперативно ръководство, използвано от друг. Написано от този, който е изградил решението, и изпълнено веднъж преди предаването от човек, който не е участвал. Ако той не може да рестартира автоматизацията по документа, документът е грешен.

Авариен изключвател. Един документиран начин автоматизацията да се спре чисто, а натрупаната работа да се обработи ръчно. Никой не го иска до сутринта, в която много го иска.

Версионирайте това, от което зависи автоматизацията

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

Предаването е етап от изпълнението, а не имейл

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

Мярката, която има значение

Не датата на пускане. Броят месеци, в които автоматизацията работи без обаждане до хората, които са я изградили. Това е единствената цифра, която показва дали спестяването е било реално.

Анализи