Kuriuos procesus verta automatizuoti?
Rinkitės pagal faktinius darbus, o ne technologijos naujumą. Stebėkite įprastą savaitę ar kitą jūsų ciklui tinkamą laikotarpį. Skirkite atlikimo laiką nuo laukimo ir užrašykite išimtis.
| Kriterijus | Palankus požymis | Ką daryti, jei jo nėra |
|---|---|---|
| Dažnis ir apimtis | Darbas kartojasi ir turi aiškią imtį | Vertinti, ar parengimas apskritai atsipirks |
| Taisyklės | Žinomas tinkamas rezultatas | Pirmiausia susitarti dėl proceso |
| Duomenys | Prieinamas aktualus šaltinis su ID | Sutvarkyti šaltinį ar riboti apimtį |
| Išimtys | Žinomos ir turi gavėją | Surinkti išimčių pavyzdžius |
| Klaidos kaina | Galima saugiai patikrinti prieš veiksmą | Griežčiau riboti savarankiškumą |
| Savininkas | Aišku, kas priima rezultatą | Paskirti atsakingą funkciją |
Dažnas, bet neaprašytas procesas nėra automatiškai geras kandidatas. Kartais vertingiausias pirmas darbas – pašalinti duomenų dubliavimą arba nereikalingą patvirtinimą. Proceso audito šablonas padeda užrašyti šias sąlygas vienoje vietoje.
Dažnis, laikas ir klaidų kaina
Taisyklės, duomenys ir savininkas
Išimtys ir priėmimo kriterijai
Taisyklės, RPA, agentas ar komanda?
Taisyklėmis valdoma eiga tinka stabiliems žingsniams: gavus žinomą įvykį patikrinti laukus ir perduoti juos API. RPA atlieka veiksmus per programos sąsają, kai nėra tinkamos tiesioginės jungties; keičiantis ekranui reikia vertinti tokios eigos priežiūrą.
DI agentas naudingas, kai reikia suprasti nevienodą laišką, dokumentą ar klausimą ir pasirinkti veiksmą pagal kontekstą. Jis turi tikslą, įrankius ir ribas. Agentų komanda skiria atsakomybes, kai vienam rezultatui reikia tyrimo, rengimo bei tikrinimo.
Dažnai tinkamas mišrus sprendimas: agentas išskiria poreikį, kodas tikrina sumą, taisyklė tikrina leidimą, o žmogus priima išimtį. Agentų ir tradicinio kodo palyginimas padeda pasirinkti pagal konkrečią užduotį.
Vientisas B2B užklausos pavyzdys
Toliau – iliustracinis procesas su sintetiniais duomenimis. Klientas prašo pasiūlymo 50 vienetų. Nenurodyta pristatymo vieta.
- Gavimas. Užklausa gauna stabilų šaltinio ID. Pakartotas pateikimas susiejamas su tuo pačiu darbu.
- Supratimas. Agentas išskiria poreikį ir kiekį. Nutylėta vieta lieka nežinoma.
- Duomenys. Kaina gaunama iš patvirtintos kainoraščio versijos, o prekės prieinamumas – iš už atsargas atsakingos sistemos.
- Rengimas. Parengiamas pasiūlymo projektas ir trūkstamos informacijos klausimas.
- Kontrolė. Atskirai tikrinamos sumos, gavėjas, nuolaidos ir siuntimo teisė.
- Baigtis. CRM matomas projektas bei laukiama informacija. Pasiūlymas nepažymimas išsiųstu.
Jei kainoraštis neveikia, procesas nesugalvoja kainos. Jei API atsakymas nutrūko po įrašymo, pirmiausia sutikrinama tikslinė būsena. Vien pakartotinis paleidimas negali būti dublikatų prevencijos pakaitalas. Šią logiką išsamiau aprašo darbo grandinės.
Kaip vertinti sąnaudas ir atsipirkimą
Įtraukite vienkartinį parengimą, integracijas, mėnesinę priežiūrą, modelių bei išorinių įrankių naudojimą ir likusią žmogaus peržiūrą. Sutaupytų minučių vertė nėra savaime sutaupytas pinigų srautas. Reikia suprasti, ar laikas atlaisvina pajėgumą, mažina viršvalandžius, ar tiesiog leidžia geriau atlikti kitą darbą.
Iliustraciniame modelyje 400 darbų po 8 minutes, kai valanda kainuoja 18 Eur, sudaro 960 Eur rankinio darbo vertę per mėnesį. Jei automatizuoto darbo sąnaudos su žmogaus peržiūra yra 178,40 Eur, skirtumas – 781,60 Eur. Esant 1 500 Eur vienkartinėms sąnaudoms paprastas atsipirkimas būtų apie 1,92 mėnesio. Tai pasirinktos prielaidos, ne Verslomatikos kainos ar rezultato pažadas.
Mažos apimties procesas gali neatsipirkti. ROI skaičiuoklė pateikia abu atvejus ir matomas formules. Kainodaros paaiškinimas padeda suderinti pasiūlymo sudėtį.
Kaip prijungti esamas sistemas
Nereikia visų programų pakeisti viena platforma. Reikia nustatyti, kas valdo kainą, kontaktą, dokumentą ir būseną. Integracijose aprašome B1 / Site.pro, Rivilę, CRM, Make / n8n ir Dokobit. Kiekvienai jungčiai tikrinamas produktas, planas, operacija ir teisės.
Skaitymo prieiga nereiškia teisės keisti. Dokumento projektas nėra galutinis įrašas. Prieigos neturi būti perduodamos per užduoties tekstą ar bendrą viešą failą. Jautrumą vertinkite prieš siunčiant duomenis pasirinktam modeliui ar įrankiui.
Kaip pradėti ir priimti rezultatą
Pasirinkite procesą su aiškia pradžia bei baigtimi. Surinkite įprastus, neaiškius ir netinkamus pavyzdžius. Užrašykite tikėtiną rezultatą prieš bandymą. Nustatykite žmogaus sprendimo vietas, išlaidų ribą ir sustabdymą.
Po patikros matuokite visą ciklą: atlikimo ir peržiūros laiką, išimtis, klaidų taisymą bei realų verslo rezultatą. Kokybės kontrolė paaiškina įrodymų ribas. Naujos taisyklės ar įrankio versijos priėmimas neturi paveldėti ankstesnio bandymo sėkmės.
Dažniausi pasirinkimo klausimai
Ar automatizavimui visada reikia DI? Ne. Aiškioms taisyklėms ir skaičiavimams dažnai tinka kodas ar įprasta integracija.
Ar vienas agentas gali atlikti visą procesą? Gali, jei apimtis ir įrankiai tinkami. Skirtingoms rengimo bei tikrinimo atsakomybėms gali būti naudingesnė komanda.
Ar automatizuoti galima bet kurią užduotį? Galima projektuoti labai skirtingas eigas, tačiau įgyvendinamumą lemia duomenys, prieigos, saugumas ir priėmimo galimybė. Neaprašytos sąlygos netampa veikiančia integracija vien iš aprašymo.
Raskite sprendimą pagal funkciją arba aprašykite norimą rezultatą agentų kūrėjui.
Kur tęsti pasirinkimą
Automatizavimo būdų palyginimai padeda atskirti agento, tradicinio kodo ir darbo eigos platformos paskirtį. Jei užduotis jau sustojo, pagalbos centre raskite kitą veiksmą pagal prieigų, duomenų ar patvirtinimo būseną.
Jei pirmiausia norite sutvarkyti konkrečią eigą, pasirinkite pagal darbą: pardavimų automatizavimas padeda aprašyti užklausos kelią iki pasiūlymo; klientų aptarnavimo automatizavimas – atsakymo paiešką ir perdavimą žmogui; sąskaitų valdymo automatizavimas – dokumento laukų ir neatitikimų patikrą prieš perduodant apskaitai.