Kuriuos procesus verta automatizuoti ir kaip juos atpažinti

Keturi klausimai, kuriais savo kasdienį darbą galite persijoti patys: ar tai grandinė su rezultatu, ar mašina gauna duomenis, ar paveikslą, ar žingsnis ką nors nusprendžia apie žmogų, ir ar procesas jau turi išorinį terminą.

Klausimas „ką mums reikėtų automatizuoti“ paprastai užduodamas per vėlai, nes jis daro prielaidą, kad atsakymas yra įrankių sąrašas. Praktikoje didžioji dalis nesėkmingų automatizavimo projektų prasidėjo nuo teisingo įrankio, kuris buvo uždėtas ant neteisingai parinkto darbo, ir būtent pasirinkimas, o ne įrankis, lėmė rezultatą.

Šis straipsnis nemėgina apibrėžti, kas yra verslo procesų automatizavimas, nes apibrėžtis nieko neišsprendžia; vietoj to jis duoda keturis klausimus, kuriais savo kasdienį darbą galite persijoti patys, ir po kiekvieno klausimo parodo, kaip atrodo atvejis, kuris jį atlaiko, ir atvejis, kuris neatlaiko. Sijojimas nieko nekainuoja ir užima vieną popietę, bet sutaupo gerokai daugiau nei bet koks įrankių palyginimas, nes atsako į ankstesnį klausimą grandinėje.

Pirmasis klausimas: ar tai grandinė su rezultatu, ar paspaudimų seka

Tai riba, kuri atskiria daugiausia, ir ją verta nubrėžti tiksliai: procesas yra veiksmų grandinė, turinti įvesties duomenis, rezultatą ir šeimininką: sąskaitos išrašymas iš užsakymo, naujo darbuotojo priėmimas į darbą, kliento paraiškos kelias nuo formos iki atsakymo. Procedūra, arba atskiras veiksmas, yra tai, kaip konkretus žingsnis atliekamas: kur spustelėti, ką įklijuoti, į kurį lauką įrašyti numerį.

Automatizuoti galima abu, tačiau grąža skiriasi keliskart, ir būtent todėl seka svarbi: jei Jūs automatizuojate grandinę, Jūs keičiate rezultatą — dokumentas į apskaitą patenka pats, ir niekas jo daugiau neperrašinėja. Jei Jūs automatizuojate paspaudimų seką, Jūs pagreitinate vieną žingsnį grandinėje, kurios likusi dalis lieka tokia pati, ir nauda yra lygiai tiek, kiek sudarė to vieno žingsnio dalis.

Praktinis atpažinimo būdas — paprasčiausiai paklausti, kas su rezultatu vyksta paskui, ir atsakymas paprastai pasako viską: jei tai „tada kažkas paima šį failą ir įdeda į kitą sistemą“, grandinė tęsiasi ir automatizuoti vieną žingsnį reiškia perkelti spūstį, o ne ją pašalinti. Jei atsakymas yra „tada darbas baigtas ir rezultatas yra sistemoje“, Jūs turite procesą su aiškiu pabaigos tašku, ir būtent tokius verta imti pirmus.

Imkime vieną tipinę grandinę ir ją sekime iki galo, nes būtent sekimas parodo, kur nauda iš tikrųjų slypi: klientas užpildo formą svetainėje, paraiška ateina į paštą, kažkas ją perrašo į klientų apskaitos sistemą, kažkas kitas parengia pasiūlymą, o po patvirtinimo dar kažkas išrašo sąskaitą apskaitos programoje. Čia yra vienas procesas su aiškiu rezultatu (nuo paraiškos iki sąskaitos), ir jame yra bent trys vietos, kuriose tie patys duomenys perrašomi iš naujo, kiekvieną kartą su galimybe suklysti.

Jei iš šios grandinės automatizuojate tik paraiškos perrašymą į klientų apskaitos sistemą, nauda tikra, bet nedidelė, nes likę du perrašymai lieka. Jei automatizuojate visą grandinę, keičiasi pats darbo pobūdis: žmogus nebeperrašinėja, o tikrina ir priima sprendimus ten, kur jie tikrai reikalingi. Būtent todėl grandinės ribas verta nubrėžti prieš bet kokį pokalbį apie įrankius, nes jos nustato, kokia didelė galima nauda.

Grandinė turi ir šeimininką, ir tai klausimas, kuris dažnai lieka neužduotas. Jei nė vienas konkretus žmogus negali pasakyti, kaip procesas vyksta nuo pradžios iki pabaigos, automatizavimas bus prielaidų seka apie tai, kaip tai greičiausiai vyksta, ir pirmasis tikras atvejis tas prielaidas sulaužys. Šeimininko suradimas paprastai užima vieną pokalbį, bet sutaupo kelias savaites, todėl tai pigiausia projekto dalis.

Antrasis klausimas: ar mašina gauna duomenis, ar paveikslą

Tai svarbiausias techninis skirtumas visame automatizavime, ir Lietuvoje jam dabar yra ir teisės aktų pusė. Jei sistema gauna struktūrizuotus duomenis (XML, JSON, įrašą duomenų bazėje), ji gali juos apdoroti be spėjimo. Jei ji gauna paveikslą, tai yra PDF failą arba nuskenuotą lapą, prieš apdorojimą kažkam tenka atspėti, kas ten parašyta, ir būtent šis spėjimas kuria klaidas, kurias vėliau kažkas taiso ranka.

Sąskaitų pavyzdys tai parodo geriausiai, nes ten abi galimybės egzistuoja greta ir vadinamos beveik vienodai. Struktūrizuota elektroninė sąskaita, kasdienėje kalboje vadinama ir e-sąskaita, yra mašininai skaitomas dokumentas nustatytu formatu — Lietuvoje jis atitinka Europos elektroninių sąskaitų faktūrų standartą EN 16931 ir PEPPOL BIS Billing 3.0 profilį. Gavėjo sistema gali jį įtraukti į apskaitą be žmogaus dalyvavimo, todėl būtent šis formatas yra tas, kuriam taikomi normatyviniai terminai.

PDF sąskaita, kurią gavėjas sutiko gauti elektroniniu būdu, taip pat yra galiojantis dokumentas: Pridėtinės vertės mokesčio įstatymo 79 straipsnis leidžia elektroninę PVM sąskaitą faktūrą su sąlyga, kad yra išankstinis pirkėjo sutikimas. Bet galiojanti ji yra kaip PVM sąskaita faktūra, ne kaip e-sąskaita, ir mašinai tai vis tiek paveikslas.

Iš to išplaukia išvada, kuri sutaupo daug pinigų: PDF sąskaitų atpažinimas naudojant OCR nėra e-sąskaitų diegimas. Tai atskiras veiksmas, kurį žmonės pagrįstai automatizuoja, nes jis sumažina perrašinėjimą, tačiau jis nesukuria struktūrizuoto dokumento ir neįvykdo prievolės tokį išrašyti. Įmonė, kuri OCR laiko atsakymu į normatyvinį reikalavimą, po kelerių metų atranda, kad automatizavo neteisingą galą, ir tada projektą tenka pradėti iš naujo su ta sistema, kuri sąskaitas išrašo, o ne su ta, kuri jas gauna.

Praktinis patikros būdas čia paprastas: paklauskite, kokiu formatu sistema geba duomenis išduoti ir priimti. Jei atsakymas yra „galima eksportuoti CSV“, tai jau struktūrizuoti duomenys, tik ne visai automatizuoti. Jei atsakymas yra „galima atspausdinti“ arba „galima įrašyti PDF“, tada paveikslas yra vienintelė išvestis, ir tolesnis darbas arba reikalauja sąsajos, arba liks spėjimas.

Verta žinoti ir tai, kad atsakymas neretai būna geresnis, nei įmonėje manoma, nes daugeliui apskaitos ir sandėlio programų sąsaja yra, tik jos niekas niekada neprašė, nes kasdienis darbas apsieina su eksportu. Vienas klausimas tiekėjui, ar sistema turi programinės įrangos sąsają ir ką su ja galima daryti, dažnai nulemia, ar projektą apskritai verta pradėti.

Trečiasis klausimas: ar žingsnis ką nors nusprendžia apie žmogų

Didžioji automatizavimo dalis yra skaičių perkėlimas tarp sistemų, ir ten jokių ypatingų teisinių klausimų nėra. Yra vis dėlto viena žingsnių grupė, kurią reikia atpažinti atskirai: tie žingsniai, kurie ką nors nusprendžia apie konkretų žmogų — ar jį priimti į darbą, ar suteikti kreditą, ar atleisti, ar skirti išmoką.

Bendrojo duomenų apsaugos reglamento 22 straipsnis („Automatizuotas atskirų sprendimų priėmimas, įskaitant profiliavimą“) nustato, kad žmogus turi teisę, kad jam nebūtų taikomas tik automatizuotu duomenų tvarkymu grindžiamas sprendimas, dėl kurio jam kyla teisinės pasekmės arba kuris jam panašiu būdu daro didelį poveikį. Išimčių yra (sutarties būtinybė, įstatymas su apsaugos priemonėmis, aiškus sutikimas), bet ir tada lieka teisė į žmogaus įsikišimą, savo požiūrio pareiškimą ir sprendimo ginčijimą. Priežiūros institucijų gairės prideda svarbų niuansą: žmogaus įsikišimas turi būti prasmingas, ir formalus patvirtinimo mygtukas, kurį kažkas spaudžia nežiūrėdamas į turinį, proceso iš 22 straipsnio taikymo nepašalina.

Tai nėra draudimas automatizuoti, o nurodymas, kas būtent tokiame procese automatizuotina: automatizuoti galima parengiamąjį darbą (duomenų surinkimą, tikrinimą, pasiūlymo parengimą), bet pats sprendimas lieka žmogui, kuris jį iš tikrųjų priima. Praktiškai tai keičia projekto apimtį, todėl tai verta pastebėti prieš kūrimą, o ne po jo.

Greta to verta žinoti vieną terminą, kuris dar nėra atėjęs, bet veikia ilgalaikius planus: dirbtinio intelekto reglamento reikalavimai didelės rizikos sistemoms užimtumo srityje, tai yra atrankai ir personalo sprendimams, pradedami taikyti 2027 metų gruodžio 2 dieną. Tai reiškia, kad šiandien pasirinkimas laisvesnis, bet sistemai, kurią statote ilgam, šią datą reikia įrašyti į planą.

Ketvirtasis klausimas: ar procesas jau turi išorinį terminą

Daliai procesų terminą nustato ne įmonės prioritetai, o išorinė prievolė, ir jie automatiškai pakyla sąrašo viršun, nes dėl jų nebeklausiama, ar daryti, o tik kada ir kaip. Lietuvoje aiškiausias pavyzdys vėl yra sąskaitos, ir ten yra trys skirtingi dalykai, kuriuos dažnai painiojama.

Pirma, įmonė, kuri išrašo sąskaitą viešojo sektoriaus subjektui, struktūrizuotą formatą naudoja jau nuo 2017 metų liepos 1 dienos. Antra, visų PVM mokėtojų išrašytų ir gautų PVM sąskaitų faktūrų duomenys Valstybinei mokesčių inspekcijai teikiami per i.SAF jau nuo 2016 metų spalio — kas mėnesį, iki kito mėnesio 20 dienos. Trečia, prievolė išrašyti struktūrizuotą sąskaitą kitai įmonei Lietuvoje dar nenustatyta: B2B e-sąskaitos kol kas savanoriškos, o 2028 metų data, kurią mini dalis antrinių straipsnių, nėra Lietuvos įstatymo terminas.

Būtent šis trečiasis punktas viešojoje apyvartoje dažniausiai būna neteisingas, ir tam yra paprasta priežastis: antriniai straipsniai 2028-uosius mini kaip jau nustatytą prievolę, nors Lietuvos teisė B2B struktūrizuotos sąskaitos termino dar nėra įtvirtinusi. Įmonei, kuri planuoja biudžetą, skirtumas tarp „jau įstatymas“ ir „kol kas gairės“ yra didelis, todėl datą verta tikrinti pirminiame šaltinyje, ne perpasakojime.

Išorinių terminų yra ir kitur: darbo laiko apskaita turi būti objektyvi ir prieinama, apskaitos dokumentams yra saugojimo terminai, o sutartyse pasitaiko ataskaitų datų. Bendras bruožas tas, kad šie terminai neaptariami, ir procesas, kuris tokį turi, duoda aiškų pagrindą darbui — kitaip nei procesas, kurį automatizuoja todėl, kad tai atrodo modernu.

Kaip atrodo procesas, kurį verta imti pirmą

Jei sujungiate visus keturis klausimus, išeina gana konkretus portretas, kurį galima pridėti prie bet kurio sąrašo: vertingiausias pirmasis kandidatas yra grandinė su aiškiu rezultatu, kurioje duomenys jau egzistuoja struktūrizuoti arba gali tokie tapti, kurioje joks žingsnis nieko nenusprendžia apie žmogų, ir kuri turi išorinį terminą arba bent išmatuojamą apimtį.

Praktikoje tai paprastai atrodo taip: užsakymas iš parduotuvės patenka į apskaitos sistemą be perrašinėjimo; patvirtinimų grandinė, kurioje paraiška nueina tinkamam žmogui ir grįžta su žyma; duomenų sinchronizavimas tarp sandėlio ir svetainės, kur žmogus dabar du kartus per dieną eksportuoja failą. Visuose trijuose yra vienas bendras požymis — tarp dviejų sistemų šiandien vaikšto žmogus su failu.

Būtent šį požymį lengviausia pastebėti ir sunkiausia pamiršti, todėl nuo jo verta pradėti inventorizaciją. Užrašykite, kur Jūsų įmonėje kažkas eksportuoja, įklijuoja ar perrašinėja, kaip dažnai ir kiek ilgai. Šis sąrašas paprastai būna trumpesnis, nei tikėtasi, ir jame beveik visada yra vienas įrašas, kuris išsiskiria.

Antras požymis, kuris kandidatą išskiria, yra klaidos kaina, ir ją skaičiavimuose paprastai praleidžia: jei perrašymo klaida šioje grandinėje reiškia neteisingą sąskaitą klientui, neteisingą likutį sandėlyje arba praleistą terminą, tada nauda iš automatizavimo yra ne tik sutaupytos valandos, bet ir išvengtos klaidos, ir tai paprastai yra didesnis iš abiejų skaičių. Procesas, kuriame klaida nepastebima ir nekenksminga, šiuo požiūriu yra mažiau vertingas kandidatas, net jei užima tiek pat laiko.

Trečias požymis yra tai, kaip apimtis keičiasi kartu su įmone, ir tai svarbiausias iš trijų: darbas, kuris auga kartu su įmone, nes daugiau užsakymų reiškia daugiau perrašinėjimo, ilgainiui tampa vis brangesnis, ir būtent ten automatizavimas atsiperka dvigubai: jis atlaisvina laiką šiandien ir nuima sąnaudą, kuri kitaip augtų. Darbas su pastovia apimtimi, nepriklausoma nuo apyvartos, šios antros naudos neduoda.

Prie portreto verta pridėti vieną dalyką apie eiliškumą, nes čia įmonės klysta dažniau nei rinkdamosi įrankį: pirmojo automatizuojamo proceso nereikia rinktis pagal tai, kuris didžiausias ar skaudžiausias, o pagal tai, kuris geriausiai suprantamas ir greičiausiai baigiamas, nes pirmasis projektas moko įmonę, kaip tokie projektai apskritai vyksta — kaip aprašyti išimtis, kaip testuoti ir kaip elgtis su klaidomis. Šią pamoką gerokai pigiau gauti ant paprasto darbo nei ant to, nuo kurio priklauso pinigų srautas.

Kaip atrodo procesas, kurio neverta imti pirmo

Lygiai taip pat naudinga kaip atpažinti gerą kandidatą yra atpažinti tai, kas atrodo patraukliai, bet atsiperka prastai, ir tokių atvejų yra keturi. Pirmasis yra darbas, kuris vyksta retai (kartą per ketvirtį arba kartą per metus), nes kūrimo sąnaudos lieka tokios pačios, o sutaupymas dalijamas iš keturių arba iš vieno.

Antrasis yra procesas, kurio tvarka dar keičiasi, ir tai atvejis, kuriame skubėjimas kainuoja brangiausiai: jei tvarka per pastarąjį pusmetį keista tris kartus, automatizavimas įtvirtins tą versiją, kuri vis tiek greitai pasikeis, ir priežiūra suės naudą. Čia teisinga seka yra pirma susitarti dėl tvarkos ir tik tada ją automatizuoti, nors praktikoje dažnai būna atvirkščiai.

Trečiasis yra darbas, kuriame kiekvienas atvejis yra išimtis, ir ten riba glūdi pačioje užduoties prigimtyje, nes automatizavimas gerai susidoroja su dažnu ir nuspėjamu, bet prastai su situacija, kurioje dešimtyje atvejų yra dešimt skirtingų kelių; ten žmogaus sprendimas ir yra pats darbas, o jo pakeitimas taisyklių medžiu paprastai sukuria daugiau išimčių, nei pašalina.

Šiuos tris atvejus vienija vienas požymis: juose automatizavimas įtvirtina tai, kas dar nėra paruošta būti įtvirtinta. Retas darbas nėra pakankamai išdirbtas, kad jį vertėtų įamžinti; kintantis procesas dar ieško savo formos; išimčių darbas iš esmės yra sprendimas. Visuose trijuose teisingas veiksmas yra palaukti arba pirma sutvarkyti, o ne automatizuoti greičiau.

Ketvirtasis yra atvejis, kuriame ekranas imituojamas todėl, kad sistema neturi sąsajos. Tai kartais vienintelis įmanomas kelias, tačiau jis ir trapiausias: pakanka pakeitimo ekrane, ir darbas stoja. Jei sistema sąsają turi arba jos galima paprašyti, tai beveik visada naudingesnis pasirinkimas nei ekrano imitavimas.

Kas nutinka žmonėms, kurių darbą automatizuoja

Šį klausimą automatizavimo pasiūlymuose paprastai apeina, nors įmonėje jis užduodamas jau pirmą dieną, ir neatsakytas jis tampa tyliu pasipriešinimu, kuris projektą gali sustabdyti patikimiau nei bet kuri techninė problema. Sąžiningas atsakymas daugumoje mažų ir vidutinių įmonių yra tas, kad automatizavimas atlaisvina laiką, o ne žmogų: perrašinėjimas yra ta darbo dalis, kurios niekas nenori, ir jos išnykimas paprastai reiškia, kad tas pats žmogus pagaliau spėja daryti tai, kam anksčiau neužteko laiko.

Iš to išplaukia praktinė rekomendacija, kuri skamba švelniai, bet yra grynas projektų valdymo klausimas: žmogų, kuris darbą daro šiandien, reikia įtraukti į projektą kaip geriausiai darbą išmanantį šaltinį, o ne informuoti apie rezultatą. Jis žino išimtis, kurių niekas nėra užrašęs, ir būtent išimtys automatizavimą sulaužo. Projektas, kuriame šis pokalbis vyksta pradžioje, kainuoja mažiau nei toks, kuriame jis vyksta po pirmos klaidos.

Sąžininga pasakyti ir kitą pusę, nes priešingai būtų apsimetimas: jei įmonėje kurio nors žmogaus darbas visiškai susideda iš duomenų perkėlimo tarp dviejų sistemų, tada automatizavimas šį darbą iš tikrųjų pakeičia, ir tai pokalbis apie vaidmens keitimą, kurį veda įmonės vadovybė, ne tiekėjas. Pasiūlymas, kuris šio klausimo apskritai neužduoda, nėra taktiškas — jis tiesiog nėra iki galo apgalvotas.

Kaip apskaičiuoti savo skaičių

Skaičiavimas, kurio reikia sprendimui, telpa į vieną lapą ir nereikalauja nei konsultanto, nei tyrimo. Reikia keturių skaičių: kiek kartų per savaitę šis darbas vyksta, kiek minučių jis užima kiekvieną kartą, kiek kainuoja valanda tam žmogui, kuris jį daro, ir kaip dažnai jame atsiranda klaida, kurią paskui kažkas taiso.

Pirmi trys duoda tiesioginę laiko sąnaudą per metus, ir šis skaičius paprastai būna mažesnis, nei tikėtasi — būtent todėl vien juo pagrįsti projektą dažnai nepavyksta. Ketvirtasis skaičius yra tas, kuris dažniausiai nulemia, nes klaidos kaina retai tėra jos ištaisymo laikas: neteisinga sąskaita reiškia susirašinėjimą su klientu, neteisingas likutis reiškia arba prekę, kuri lieka neparduota, arba užsakymą prekei, kurios sandėlyje jau nėra, o praleistas terminas kartais reiškia baudą.

Priešais šiuos skaičius dedamos kūrimo sąnaudos ir priežiūra, ir būtent priežiūra yra tai, ką pamiršta. Automatizavimas, kuris sujungia dvi sistemas, gyvas tik tol, kol gyvos abi sąsajos, todėl plane turi būti vieta pakeitimams, kurių pareikalaus kažkas kitas. Jei skaičiavimas atsiperka tik tada, kai priežiūros sąnaudų neįskaičiuoja, tada jis iš tikrųjų visai neatsiperka.

Dar vienas dalykas, kurį verta išsiaiškinti prieš pokalbį, yra tai, kaip dažnai sistemos keičiasi. Debesijos paslauga, kuri atsinaujina pati, sąsają gali pakeisti be įspėjimo, o vietoje įdiegta programa lieka nepakitusi metais, bet jos atnaujinimas kada nors reikalauja viską patikrinti iš naujo. Nė vienas iš abiejų variantų nėra blogesnis, tačiau jie reikalauja skirtingo priežiūros plano, ir pasiūlymas, kuris to neatspindi, bus per pigus būtent toje vietoje, kur vėliau atsiras sąnaudos.

Kodėl procentais iš tyrimų neverta tikėti

Automatizavimo pasiūlymuose beveik visada pasirodo skaičius: kad automatizuoti galima pusę darbo, kad projektai žlunga trečdalyje atvejų, kad kažkas sutaupė dešimtis tūkstančių valandų. Šie skaičiai egzistuoja ir yra cituojami, tačiau jie beveik niekada neaprašo tos įmonės, kuriai juos rodo, ir būtent tai juos padaro prastu pagrindu sprendimui.

Plačiai cituojamas rodiklis, kad didelė dalis veiksmų automatizuotina, yra skaičiavimas apie veiksmus darbo užmokesčio masėje konkrečioje šalyje ir konkrečiais metais, su tų metų technologijomis, ir jį paskelbė konsultacijų įmonė, kuri parduoda tą pačią paslaugą. Rodiklis apie projektų nesėkmes ateina iš konsultanto patirties su klientais, kurie jį iškvietė po pirmųjų nesėkmių, todėl imtis iškreipta jau pagal apibrėžtį. Skaičius apie sutaupytas valandas aprašo konkretų keturiasdešimties žmonių apskaitos skyrių kitoje šalyje prieš kelerius metus.

Iš to neišplaukia, kad automatizavimas neatsiperka, o tai, kad teisingas skaičius yra Jūsų pačių: kiek kartų per savaitę šis darbas vyksta, kiek ilgai jis užima ir kiek kainuoja valanda. Šį skaičiavimą galima padaryti viename lape, jis aprašo būtent Jūsų įmonę, ir tai vienintelis, kurio pagrindu verta priimti sprendimą.

Ką reikia žinoti apie sistemas prieš prašant pasiūlymo

Kai kandidatas pasirinktas, kitas žingsnis nėra pasiūlymo prašymas, o penkių minučių tyrimas apie pačias sistemas, nes būtent jis nulemia, ar pokalbis su vykdytoju bus apie sprendimą, ar apie galimybę. Išsiaiškinkite, ar kiekviena dalyvaujanti sistema turi programinės įrangos sąsają, ar ji prieinama Jūsų licencijos lygiu ir ar tiekėjas už ją prašo atskiro mokesčio, nes visų trijų atsakymai dažnai skiriasi.

Antras klausimas — kas duomenis saugo ir kas juos gali keisti. Jei dvi sistemos turi tą pačią informaciją, pavyzdžiui, kliento rekvizitus arba prekės likutį, tada prieš jungiant reikia nuspręsti, kuri iš jų yra pagrindinė, nes kitaip automatizavimas ims abi perrašinėti vieną kita ir rezultatas bus prastesnis nei iki tol. Šis apsisprendimas nemokamas, jei jį padarote pradžioje, ir brangus, jei jį atrandate testavimo metu.

Trečias yra klausimas, kas nutinka, kai kažkas nepavyksta. Kiekviename automatizavime yra atvejų, kurie nepraeina (trūksta lauko, sistema neatsako, duomenys prieštaringi), ir jiems reikia vietos, kur patekti, ir žmogaus, kuris juos peržiūri. Automatizavimas be klaidų apdorojimo veikia tiek, kiek viskas tvarkoje, ir tai niekada nėra ilgai.

Verta ir iš anksto nuspręsti, pagal ką vertinsite, ar pavyko, nes be to projektas niekada nesibaigia, o tiesiog nutrūksta. Matas gali būti visai paprastas: kiek kartų per mėnesį kažkas dar perrašo duomenis ranka, kiek klaidų ištaisė praėjusį mėnesį ir kiek ilgai paraiška eina nuo formos iki atsakymo. Šį skaičių prasminga išmatuoti vieną kartą prieš pradedant darbą, kad vėliau būtų su kuo palyginti. Įmonės, kurios šio matavimo nedaro, po pusmečio ginčijasi, ar apskritai kas nors pasikeitė.

Galiausiai verta prisiminti, kad automatizavimas nėra vienkartinis darbas, o kažkas, kas lieka įmonėje ir reikalauja savininko taip pat kaip bet kuri kita sistema. Kai procesas sujungtas, kažkas turi žinoti, kur žiūrėti, jei jis stoja, ir kažkas turi turėti teisę jį sustabdyti, jei rezultatas atrodo neteisingas. Įmonėse, kuriose šis vaidmuo neįvardytas, automatizavimas tyliai nustoja veikti, ir tai pastebi tik po mėnesio, kai kažkas ieško dingusio dokumento.

Nuo ko pradėti praktiškai

Pradžia nėra nei įrankio pasirinkimas, nei pasiūlymo prašymas, o viena savaitė, per kurią užrašoma, kas vyksta: kuris darbas kartojasi, kaip dažnai, kiek ilgai ir kur jame žmogus perkelia duomenis tarp sistemų. Po to kiekvienam įrašui užduokite keturis šio straipsnio klausimus, ir didžioji sąrašo dalis nukris jau po pirmųjų dviejų.

Rezultate paprastai lieka vienas arba du kandidatai, ir tai gerai, nes būtent tiek vienu metu ir verta pradėti: du baigti darbai duoda daugiau nei šeši pradėti. Kai kandidatas pasirinktas, kitas žingsnis yra išsiaiškinti, ar dalyvaujančios sistemos turi sąsajas, nes tai nulemia ir kainą, ir sprendimo atsparumą.

Jei šiuo metu aišku, kuris procesas yra Jūsų, bet neaišku, kaip jį sujungti, tai galima aptarti su mumis: verslo procesų automatizavimas mūsų vykdyme yra integracijos ir darbo eigos tarp sistemų, kurias Jūs jau turite. Jei norite pirmiausia suprasti, kuo skiriasi įvairūs požiūriai ir įrankių grupės, parašykite mums arba atsiųskite savo sąrašą — dažnai atsakymas yra, kad pakanka vienos jungties, o ne platformos.