Idėja gimė konferencijoje: kol vienas pranešėjas pasakojo apie per mėnesį sukurtas automatizacijas, InPost ir Office Samurai vadovai juokavo, kad jie galėtų tai padaryti per savaitę. „O kodėl ne per 24 valandas?“ – kažkas tarė. Kelis mėnesius tai liko vidiniu pokštu, kol abi įmonės nusprendė paversti jį realybe ir susivienijo drąsiam 24 valandų automatizacijos eksperimentui.
Rezultatai? Skaitykite toliau.
Iššūkis
Pirmoji SpeedRun taisyklė buvo tokia: automatizuojamas procesas turėjo būti tikras. Sukurti netikrą užduotį atrodytų kaip apgaulė – automatizacija yra svarbi tik tada, kai ji sprendžia realius įmonės poreikius. Verslo analitikai parengė „būtinas“ ir „pageidautinas“ testavimo atvejų sąrašus, kad sėkmės kriterijai būtų pamatuojami.
Pasirinktas procesas nebuvo rutininė užduotis – jis apėmė nuskaitytų dokumentų skaitymą ir duomenų išgavimą. Tai reiškė darbą su nestruktūruota informacija, kartais net ranka rašytu tekstu, bei situacijas, kuriose tikslumas buvo neabejotinai būtinas.
Tai, kas prasidėjo kaip linksmas pokštas konferencijoje, netrukus tapo rimtu projektu. Kuo giliau ėjome į planavimą, tuo labiau suvokėme, koks sudėtingas buvo pasirinktas procesas, ir idėja per 24 valandas pristatyti visiškai veikiančią automatizaciją ėmė atrodyti neįmanoma.
Tačiau grįžti atgal nebuvo pasirinkimo. Abi įmonės subūrė savo geriausius specialistus ir pasinėrė į pasiruošimą. Dviem verslo analitikams buvo suteikta galimybė iš anksto peržiūrėti procesą, kad įvertintų projekto įgyvendinamumą, tačiau jie nepasidalijo jokios informacijos su SpeedRun komanda iki pat renginio. Kaip ir standartiniame projekte – pradinė analizė yra momentas, kai specialistai procesą pamato pirmą kartą.
Trys InPost kūrėjai, trys Office Samurai kūrėjai ir du InPost srities ekspertai (SME) įžengė į SpeedRun areną nieko nežinodami, ką jiems teks automatizuoti. Tik tada, kai pradėjo tiksėti 24 valandų laikrodis, atsiskleidė visas iššūkio mastas.
Pasiruošti, dėmesio, startas!
Laikrodis pradėjo tiksėti 14 valandą – ir viskas prasidėjo. Komanda pirmąsias dvi valandas praleido kalbindama SME ekspertus ir kruopščiai analizuodama procesą. Didelė sieninė lenta tapo erdve sprendimo dizainui ir svarbioms pastaboms. Energijos ir ryžto netrūko, tačiau ėmė rastis pirmosios kliūtys – pavyzdžiui, paaiškėjo, kad vienas iš el. pašto adresų nebuvo bendras pašto dėžutės adresas, o grupė, sukėlusi didelį techninį iššūkį. Užduoties mastas ėmė atrodyti pribloškiantis.
Analizė užsitęsė ir smarkiai išeikvojo brangų laiko biudžetą. Šiuo momentu verslo analitikams (BA) buvo leista įsikišti – jie galėjo pateikti užuominų ir stebėti, ar pagrindinis proceso srautas nenukrypsta į mažiau svarbias detales. Komanda vėl įgavo pagreitį. Ji nustatė, kad visą procesą galima padalyti į dvi pagrindines dalis, todėl pasidalijo į dvi saviorganizuojančias komandas, kuriose kiekvienas asmuo prisiėmė konkrečią rolę.
Kiekviena komanda paskyrė vieną žmogų dokumentacijai (daugiausia proceso žemėlapio kūrimui), kitą – Dispatcher roboto programavimui (atsakingo už užduočių eilės paruošimą), o trečią – Performer roboto kūrimui (vykdančio faktinį procesą sistemose ir programose). Be to, vienas komandos narys susitelkė į esminių dirbtinio intelekto komponentų kūrimą – viso sprendimo „smegenis“: UiPath Document Understanding™ nuskaitytiems dokumentams apdoroti ir generatyvinį DI (OpenAI ChatGPT) reikalingų reikšmių semantiniam konvertavimui.
Iš viso komanda turėjo sukurti penkis robotus, kiekvieną suprojektuotą taip, kad jis galėtų veikti tiek savarankiškai, tiek bendradarbiaudamas vykdant realius testavimo atvejus.
Vidurio maratonas
Sutemus programavimo fazė atnešė stabilumo jausmą. Turėdama aiškius individualius tikslus ir sklandų komandų bendradarbiavimą, komanda atrado savo ritmą. Kiekviena komanda buvo sudaryta iš trijų žmonių, todėl natūraliai tapo „trijulėmis“. Abi trijulės sėdėjo nedideliu atstumu viena nuo kitos – pakankamai arti, kad galėtų akimirksniu bendradarbiauti, bet pakankamai toli, kad išlaikytų susikaupimą.
Jei reikėtų įvardyti vieną svarbiausią renginio akcentą, tai būtų šis: sklandus bendradarbiavimas.
Įsivaizduokite projektą, kuriame kiekviena kliūtis, klausimas ar sprendimas išsprendžiamas iš karto, akis į akį. Jokio laukimo atsakymų, jokių blaškančių veiksnių – tik grynas susitelkimas, kai visi supranta užduotį, procesą ir technologiją. Nors aplinkybės buvo unikalios, tai buvo efektyviausias projekto įgyvendinimas, kokį esu kada nors matęs.
Tačiau, žinoma, pakeliui kilo ir problemų.
Proceso sudėtingumas buvo stipriai neįvertintas. Tai, kas prieš renginį atliktoje analizėje atrodė įveikiama, pasirodė kupina išimčių ir niuansų. Komandos ambiciją tinkamai apdoroti kiekvieną atvejį teko pristabdyti. Laikui senkant, jie turėjo susitelkti į tai, kad pagrindinis proceso srautas veiktų nuo pradžios iki galo.
Ir tada atėjo nuovargis. Tai nebuvo dėl sąlygų – patalpose buvo viskas: skanus maitinimas, poilsio kambariai su kilimėliais miegui, tiek kavos, kiek tik norėjai, ir medicininė pagalba nelaimės atvejui (laimei, neprireikė). Tiesiog nenatūralu taip ilgai nemiegoti. Didžiausia krizė ištiko apie 3 val. ryto. Vystymas pasiekė sudėtingą etapą, ir komanda išsisklaidė – vieni ieškojo trumpo pogulio, kiti tęsė darbą.
Naktis būna tamsiausia prieš aušrą.
Feniksas iš pelenų
Lūžio taškas atėjo kartu su kylančia saule, apie penktą ryto. Tai gali skambėti pernelyg poetiškai – vadinkite kaip norite, bet tikrai atrodė, kad komanda po ilgos, į jūros tylą panašios pauzės pagavo antrą kvėpavimą.
Šiuo metu pirmosios robotų versijos jau buvo pakankamai funkcionalios, kad būtų galima pradėti vienetinius testus. Dokumentacijos juodraščiai buvo paruošti, o komandos dar labiau sustiprino bendradarbiavimą, pamažu pradėdamos integruoti atskirus komponentus į vientisą sprendimą. Nepaisant riboto mokymo pavyzdžių skaičiaus, Document Understanding modelis sėkmingai ištraukė duomenis, o rytinė šviesa tikrai atrodė daranti skirtumą. Prasidėjo tikrų testavimo atvejų paieška. Norėčiau, kad būtume vilkėję pižamas ir zuikučių šlepetes – tai puikiai atitiktų atmosferą.
Palikus istoriją nuošaly, nepamirškime problemos ir sprendimo sudėtingumo.
Pirmoji pagrindinė dalis turėjo apdoroti el. laiškus ir nuskaitytus dokumentus. Tekstą buvo įmanoma suvaldyti, tačiau su skenais pagrindinį darbą turėjo atlikti UiPath Document Understanding. Išgautos reikšmės negalėjo būti naudojamos tiesiogiai, todėl įsijungė ChatGPT, kad apdorotų netikslios logikos atitikimus tokioms detalėms kaip adresai ar datos – o tai nebuvo lengva, turint omenyje lenkų kalbos linksniavimo sudėtingumą.
Antroji dalis buvo dar sudėtingesnė. Pirmojo etapo duomenys turėjo laukti, kol atkeliaus papildomi dokumentai su nauja informacija. Skenuoti failai buvo perduoti (kaip jau atspėjote) Document Understanding, reikėjo suderinti gijas, atnaujinti įrašus ir tik tada galutinis Performer robotas atliko reikiamus veiksmus.
Tai būtų buvęs sudėtingas projektas net ir turint kelias savaites jam įgyvendinti. Tačiau niekas nepasidavė. Komanda dirbo iki pat paskutinės minutės, pasiryžusi pasiekti rezultatą. Štai nuotrauka tai įrodyti – visa tai prasidėjo penktadienį 14 valandą.
Laikas baigėsi!
Atgalinis skaičiavimas sustojo. Turėjome 10 minučių atokvėpio prieš susirinkdami į konferencijų salę bandomiesiems paleidimams ir galutinei santraukai. Nepaisant nuovargio, visi atrodė nuoširdžiai laimingi ir stebėtinai ramūs dėl rezultato. Galiausiai svarbiausia buvo ne tik pasiekti rezultatą – labiausiai reikšmę turėjo unikali bendra patirtis. Bet kad ilgai nekalbėti…
Tai suveikė.
Dešimt tikrų, nesukurtų testinių el. laiškų perėjo per visą procesą ir grąžino laukiamą rezultatą, kuris buvo užregistruotas „SharePoint“ lentelėje. Atsižvelgiant į žinomas tam tikrų vietų silpnybes, mus maloniai nustebino, kad visi atvejai buvo įvykdyti visiškai be klaidų. Komitetas, sudarytas iš InPost, Office Samurai ir UiPath atstovų, paskelbė projektą sėkmingu – ir tai iš tiesų jautėsi kaip apčiuopiamas rezultatas, o ne tuščias šūkis.
Kad šiek tiek subalansuotume saldumą, buvo sukurtos tik „būtinos“ funkcijos, o kodą po renginio reikėjo šiek tiek optimizuoti. Pavyzdžiui, „Dispatcher“ ir „Performer“ robotų poros buvo sujungtos į vienetus. Tačiau tai nė kiek nesumenkina fakto, kad InPost rekordiškai greitai gavo veikiančią, gamybiniam lygiui pritaikytą automatizaciją. Komanda įveikė itin sunkų ir varginantį iššūkį, parodydama neprilygstamą bendradarbiavimo pavyzdį. Pati iniciatyva ir renginio formatas buvo novatoriškas žingsnis automatizacijos industrijoje, kuris gali būti pakartotas (spoileris!) arba įkvėpti kitus pasekti šiuo pavyzdžiu. Nuoširdžiai raginame jus eksperimentuoti, mesti iššūkius savo kasdieniam verslui ir kartu pasimėgauti procesu.
SpeedRun metu sukurta sprendimas iki šiol veikia efektyviai. Iki šiol jis apdorojęs 13 875 atvejus, iš kurių tik 534 sukėlė verslo išimtis (duomenys nuo 2024-04-05 iki 2025-07-30). Vidutinis apdorojimo laikas – 6,19 minutės, todėl jau sutaupoma apie 1,3 FTE per mėnesį. Išskyrus robotų sujungimą, sprendimas patyrė tik nedidelius pakeitimus: smulkias atsakymų šablonų korekcijas, datų ir vardų konvertavimą bei priedų saugojimą SharePoint. Renginio metu sukurta pagrindinė architektūra išliko nepakitusi.
Dar daugiau – SpeedRun sėkmė įkvėpė InPost komandą išlaikyti pagreitį, ir po pusės metų ta pati architektūra buvo atkurta labai panašiam procesui automatizuoti. Šis procesas taip pat ir toliau teikia naudos įmonei (daugiau nei 9 000 sėkmingų paleidimų).
Ar pakartotumėte tai dar kartą?
Jei reikia paprasto atsakymo – taip, pakartočiau (asmeniškai aš). Tačiau ko iš tikrųjų norėčiau – tai dažniau patirti tokias puikias darbo sąlygas. Nekalbu apie 24 valandų darbą be pertraukos – tai buvo vienkartinis triukas, nulemtas renginio formato. Ką mielai pakartočiau – tai komandinę dvasią, intensyvų susitelkimą ir smagumą. Tai buvo unikalios aplinkybės, kurias sunku ilgai išlaikyti ar dažnai atkartoti, bet jos parodė, kokie neįtikėtini gali būti žmonės.
