Kurus procesus ir vērts automatizēt un kā tos atpazīt

Četri jautājumi, ar kuriem savu ikdienas darbu var izsijāt pats: vai tā ir ķēde ar rezultātu, vai mašīna saņem datus vai bildi, vai solis izlemj kaut ko par cilvēku, un vai procesam jau ir ārējs termiņš.

Jautājums „ko mums vajadzētu automatizēt“ parasti tiek uzdots par vēlu, jo tas pieņem, ka atbilde ir rīku saraksts. Praksē lielākā daļa neveiksmīgo automatizācijas projektu ir sākušies ar pareizu rīku, kurš tika uzlikts virsū nepareizi izvēlētam darbam, un tieši izvēle, nevis rīks, izšķīra rezultātu.

Šis raksts nemēģina definēt, kas ir biznesa procesu automatizācija, jo definīcija neko neizšķir; tā vietā tas dod četrus jautājumus, ar kuriem savu ikdienas darbu var izsijāt pašam, un pēc katra jautājuma parāda, kā izskatās gadījums, kurš to iztur, un gadījums, kurš neiztur. Sijāšana neko nemaksā un aizņem vienu pēcpusdienu, bet aiztaupa krietni vairāk nekā jebkurš rīku salīdzinājums, jo tā atbild uz agrāko jautājumu ķēdē.

Pirmais jautājums: vai tā ir ķēde ar rezultātu vai klikšķu virkne

Šī ir tā robeža, kura izšķir visvairāk, un to ir vērts novilkt precīzi: process ir darbību ķēde, kurai ir ieejas dati, iznākums un saimnieks: rēķina izrakstīšana no pasūtījuma, jauna darbinieka uzņemšana darbā, klienta pieteikuma ceļš no formas līdz atbildei. Procedūra jeb atsevišķa darbība ir tas, kā konkrētu soli izdara: kur jāuzklikšķina, ko jāiekopē, kurā laukā jāieliek numurs.

Automatizēt var abus, taču atdeve atšķiras vairākkārt, un tieši tāpēc secība ir svarīga: ja Jūs automatizējat ķēdi, Jūs maināt rezultātu — dokuments nonāk grāmatvedībā pats, un neviens to vairs nepārraksta. Ja Jūs automatizējat klikšķu virkni, Jūs paātrināt vienu soli ķēdē, kura pārējā daļā paliek tāda pati, un ieguvums ir tieši tik liels, cik liela bija tā viena soļa daļa.

Praktiskais atpazīšanas veids ir vienkārši jautāt, kas ar rezultātu notiek pēc tam, un atbilde parasti pasaka visu: ja tā ir „tad kāds paņem šo failu un ieliek citā sistēmā“, tad ķēde turpinās un automatizēt vienu soli nozīmē pārcelt sastrēgumu, nevis to novērst. Ja atbilde ir „tad darbs ir pabeigts un rezultāts ir sistēmā“, tad Jums ir process ar skaidru beigu punktu, un tieši tādi ir tie, kurus ir vērts ņemt pirmos.

Ņemsim vienu tipisku ķēdi un izsekosim tai līdz galam, jo tieši izsekošana parāda, kur ieguvums patiesībā slēpjas: klients aizpilda formu vietnē, pieteikums pienāk uz pastu, kāds to pārraksta klientu uzskaites sistēmā, kāds cits sagatavo piedāvājumu, un pēc apstiprinājuma vēl kāds izraksta rēķinu grāmatvedības programmā. Šeit ir viens process ar skaidru rezultātu (no pieteikuma līdz rēķinam), un tajā ir vismaz trīs vietas, kur vieni un tie paši dati tiek pārrakstīti no jauna, katru reizi ar iespēju kļūdīties.

Ja no šīs ķēdes automatizē tikai pieteikuma pārrakstīšanu uzskaites sistēmā, ieguvums ir reāls, bet neliels, jo pārējās divas pārrakstīšanas paliek. Ja automatizē visu ķēdi, mainās pats darba raksturs: cilvēks vairs nepārraksta, bet pārbauda un pieņem lēmumus tur, kur tie tiešām ir vajadzīgi. Tieši tāpēc ķēdes robežas ir vērts uzzīmēt pirms jebkuras rīku sarunas, jo tās nosaka, cik liels ir iespējamais ieguvums.

Ķēdei ir arī saimnieks, un tas ir jautājums, kurš mēdz palikt neuzdots. Ja neviens konkrēts cilvēks nevar pateikt, kā process notiek no sākuma līdz beigām, tad automatizācija būs pieņēmumu virkne par to, kā tas droši vien notiek, un pirmais reālais gadījums šos pieņēmumus salauzīs. Saimnieka atrašana parasti aizņem vienu sarunu, bet aiztaupa vairākas nedēļas, tāpēc tā ir lētākā projekta daļa.

Otrais jautājums: vai mašīna saņem datus vai bildi

Šī ir vissvarīgākā tehniskā atšķirība visā automatizācijā, un Latvijā tai tagad ir arī normatīva puse. Ja sistēma saņem strukturētus datus (XML, JSON, ierakstu datubāzē), tā var tos apstrādāt bez minēšanas. Ja tā saņem attēlu, tas ir, PDF failu vai skenētu lapu, tad pirms apstrādes kādam ir jāuzmin, kas tur ir rakstīts, un tieši šī minēšana rada kļūdas, kuras vēlāk kāds labo ar roku.

Rēķinu piemērs to parāda vislabāk, jo tur abas iespējas pastāv līdzās un tiek sauktas gandrīz vienādi. Strukturēts elektroniskais rēķins, ikdienā saukts arī par e-rēķinu, ir mašīnlasāms dokuments noteiktā formātā — Latvijā tas atbilst standartam LVS EN 16931-1:2017 un PEPPOL BIS Billing 3.0 profilam. Saņēmēja sistēma to spēj iegrāmatot bez cilvēka līdzdalības, tāpēc tieši šis formāts ir tas, uz kuru normatīvie termiņi attiecas.

PDF rēķins, kuru saņēmējs ir piekritis saņemt elektroniski, arī ir derīgs dokuments: Pievienotās vērtības nodokļa likuma 132. pants pieļauj nodokļa rēķinu elektroniskā formā ar nosacījumu, ka saņēmējs šādu formu atzīst. Bet derīgs tas ir kā nodokļa rēķins, ne kā e-rēķins, un mašīnai tas joprojām ir bilde.

No tā izriet secinājums, kurš ietaupa daudz naudas: PDF rēķinu atpazīšana ar OCR nav e-rēķinu ieviešana. Tā ir atsevišķa darbība, kuru cilvēki pamatoti automatizē, jo tā samazina pārrakstīšanu, taču tā nerada strukturētu dokumentu un neizpilda pienākumu to izrakstīt. Uzņēmums, kurš OCR uzskata par atbildi uz normatīvo prasību, pēc pāris gadiem atklāj, ka ir automatizējis nepareizo galu, un tad projekts jāsāk no jauna ar to sistēmu, kura rēķinus izraksta, nevis ar to, kura tos saņem.

Praktiskais pārbaudes veids šeit ir vienkāršs: pajautājiet, kādā formātā sistēma spēj datus izdot un uzņemt. Ja atbilde ir „var eksportēt CSV“, tas jau ir strukturēti dati, tikai nepilnīgi automatizēti. Ja atbilde ir „var izdrukāt“ vai „var saglabāt PDF“, tad attēls ir vienīgais izvads, un tālākais darbs vai nu prasa saskarni, vai paliks minēšana.

Ir vērts arī zināt, ka atbilde nereti ir labāka, nekā uzņēmumā par to domā, jo daudzām grāmatvedības un noliktavas programmām saskarne ir, tikai to neviens nekad nav prasījis, jo ikdienas darbs iztiek ar eksportu. Viens jautājums piegādātājam par to, vai sistēmai ir programmatūras saskarne un ko ar to var darīt, bieži izšķir, vai projekts vispār ir vērts sākt.

Trešais jautājums: vai solis izlemj kaut ko par cilvēku

Lielākā daļa automatizācijas ir skaitļu pārvietošana starp sistēmām, un tur nekādu īpašu juridisku jautājumu nav. Ir tomēr viena soļu grupa, kura jāatpazīst atsevišķi: tie soļi, kuri izlemj kaut ko par konkrētu cilvēku — vai viņu pieņemt darbā, vai piešķirt kredītu, vai atlaist, vai piešķirt pabalstu.

Vispārīgās datu aizsardzības regulas 22. pants nosaka, ka cilvēkam ir tiesības nebūt pakļautam lēmumam, kurš balstīts tikai uz automatizētu apstrādi un rada tiesiskas sekas vai līdzīgi būtiski viņu ietekmē. Izņēmumi pastāv (līguma nepieciešamība, likums ar aizsardzības pasākumiem, nepārprotama piekrišana), bet arī tad paliek tiesības uz cilvēka iesaisti, viedokļa paušanu un lēmuma apstrīdēšanu. Uzraugu vadlīnijas piebilst svarīgu niansi: cilvēka iesaistei ir jābūt jēgpilnai, un formāla apstiprināšanas poga, kuru kāds spiež, neskatoties saturā, procesu no 22. panta neizņem.

Tas nav aizliegums automatizēt, bet norādījums par to, kas tieši šādā procesā ir automatizējams: automatizēt var sagatavošanas darbu (datu savākšanu, pārbaudi, priekšlikuma sagatavošanu), bet pats lēmums paliek pie cilvēka, kurš to tiešām pieņem. Praktiski tas maina projekta apjomu, tāpēc to ir vērts pamanīt pirms izstrādes, ne pēc.

Blakus tam ir vērts zināt vienu termiņu, kurš vēl nav pienācis, bet ietekmē ilgtermiņa plānus: mākslīgā intelekta regulas prasības augsta riska sistēmām nodarbinātības jomā, tas ir, atlasei un personāla lēmumiem, sāk piemērot 2027. gada 2. decembrī. Tas nozīmē, ka šodien izvēle ir brīvāka, bet sistēmai, kuru būvē ilgtermiņā, šis datums ir jāieliek plānā.

Ceturtais jautājums: vai procesam jau ir ārējs termiņš

Daļai procesu termiņu nosaka nevis uzņēmuma prioritātes, bet ārējs pienākums, un tie automātiski pārceļas saraksta augšgalā, jo par tiem vairs nav jālemj, vai darīt, bet tikai, kad un kā. Latvijā skaidrākais piemērs atkal ir rēķini, un tur ir trīs dažādi datumi, kurus mēdz sajaukt.

Pirmkārt, uzņēmums, kurš izraksta rēķinu budžeta iestādei, strukturēto formātu lieto jau kopš 2025. gada 1. janvāra. Otrkārt, kopš 2026. gada 1. janvāra šo rēķinu dati nonāk arī Valsts ieņēmumu dienestā — vienu reizi, ne vēlāk kā piecu darbdienu laikā pēc rēķina nosūtīšanas dienas. Treškārt, pienākums izrakstīt strukturētu rēķinu citam uzņēmumam sākas 2028. gada 1. janvārī, un pa vidu, no 2026. gada, datus VID var iesniegt brīvprātīgi.

Tieši šis trešais datums ir tas, kurš publiskajā apritē visbiežāk ir nepareizs, un tam ir vienkāršs iemesls: sākotnējā redakcija paredzēja agrāku termiņu, tas vēlāk tika pārcelts, un daļa sekundāro rakstu to nekad nelaboja. Uzņēmumam, kurš plāno budžetu, atšķirība starp diviem gadiem ir liela, tāpēc datumu ir vērts pārbaudīt pirmavotā, ne pārstāstā.

Ārēji termiņi ir arī citviet: darba laika uzskaitei ir jābūt objektīvai un pieejamai, grāmatvedības dokumentiem ir glabāšanas termiņi, un līgumos mēdz būt atskaišu datumi. Kopīgais ir tas, ka šie termiņi nav apspriežami, un process, kuram tāds ir, dod skaidru pamatojumu darbam — atšķirībā no procesa, kuru automatizē tāpēc, ka tas šķiet moderni.

Kā izskatās process, kuru ir vērts ņemt pirmo

Ja apvieno visus četrus jautājumus, iznāk diezgan konkrēts portrets, kuru var pielikt klāt jebkuram sarakstam: vērtīgākais pirmais kandidāts ir ķēde ar skaidru rezultātu, kurā dati jau eksistē strukturētā veidā vai var tādi kļūt, kurā neviens solis neizlemj neko par cilvēku, un kuram ir ārējs termiņš vai vismaz izmērāms apjoms.

Praksē tas parasti izskatās tā: pasūtījums no veikala nonāk grāmatvedības sistēmā bez pārrakstīšanas; apstiprinājumu ķēde, kurā pieteikums aiziet pareizajam cilvēkam un atgriežas ar atzīmi; datu sinhronizācija starp noliktavu un vietni, kur cilvēks šobrīd divreiz dienā eksportē failu. Visos trijos ir viena kopīga pazīme — starp divām sistēmām šodien staigā cilvēks ar failu.

Tieši šo pazīmi ir visvieglāk pamanīt un visgrūtāk aizmirst, tāpēc ar to ir vērts sākt inventarizāciju. Uzrakstiet, kur Jūsu uzņēmumā kāds eksportē, iekopē vai pārraksta, cik bieži un cik ilgi. Šis saraksts parasti ir īsāks, nekā gaidīts, un tajā gandrīz vienmēr ir viens ieraksts, kurš izceļas.

Otra pazīme, kura kandidātu izceļ, ir kļūdas cena, un to aprēķinos parasti izlaiž: ja pārrakstīšanas kļūda šajā ķēdē nozīmē nepareizu rēķinu klientam, nepareizu atlikumu noliktavā vai nokavētu termiņu, tad ieguvums no automatizācijas nav tikai ietaupītās stundas, bet arī novērstās kļūdas, un tas parasti ir lielākais no abiem skaitļiem. Process, kurā kļūda ir nemanāma un nekaitīga, šajā ziņā ir mazāk vērtīgs kandidāts, pat ja tas aizņem tikpat daudz laika.

Trešā pazīme ir tā, kā apjoms mainās līdz ar uzņēmumu, un tā ir vissvarīgākā no trim: darbs, kurš aug līdzi uzņēmumam, jo vairāk pasūtījumu nozīmē vairāk pārrakstīšanas, ar laiku kļūst arvien dārgāks, un tieši tur automatizācija atmaksājas divkārt: tā atbrīvo laiku šodien un noņem izmaksu, kura citādi pieaugtu. Darbs ar nemainīgu apjomu neatkarīgi no apgrozījuma šo otro ieguvumu nedod.

Pie portreta ir vērts pielikt vienu lietu par secību, jo tajā uzņēmumi kļūdās biežāk nekā rīku izvēlē: pirmais automatizētais process nav jāizvēlas pēc tā, kurš ir vislielākais vai vissāpīgākais, bet pēc tā, kurš ir vislabāk saprotams un visātrāk pabeidzams, jo pirmais projekts māca uzņēmumam, kā šādi projekti vispār notiek — kā aprakstīt izņēmumus, kā testēt un kā rīkoties ar kļūdām. Šo mācību ir daudz lētāk saņemt uz vienkārša darba nekā uz tā, no kura atkarīga naudas plūsma.

Kā izskatās process, kuru nav vērts ņemt pirmo

Tikpat noderīgi kā atpazīt labu kandidātu ir atpazīt to, kas izskatās pievilcīgi, bet atmaksājas slikti, un šādu gadījumu ir četri. Pirmais ir darbs, kurš notiek reti (reizi ceturksnī vai reizi gadā), jo izstrādes izmaksas paliek tādas pašas, bet ietaupījums tiek dalīts ar četriem vai ar vienu.

Otrais ir process, kura kārtība vēl mainās, un tas ir gadījums, kurā steiga maksā visdārgāk: ja kārtība pēdējā pusgadā ir grozīta trīs reizes, tad automatizācija fiksēs to versiju, kura tāpat drīz mainīsies, un uzturēšana apēdīs ieguvumu. Šeit pareizā secība ir vispirms vienoties par kārtību un tikai tad to automatizēt, lai gan praksē mēdz notikt otrādi.

Trešais ir darbs, kurā katrs gadījums ir izņēmums, un tur robeža ir pašā uzdevuma dabā, jo automatizācija labi tiek galā ar biežo un paredzamo, bet slikti ar situāciju, kurā desmit gadījumos ir desmit dažādi ceļi; tur cilvēka spriedums ir pats darbs, un tā aizvietošana ar noteikumu koku parasti rada vairāk izņēmumu, nekā novērš.

Šos trīs gadījumus vieno viena pazīme: tajos automatizācija fiksē kaut ko, kas vēl nav gatavs tikt fiksēts. Retais darbs nav pietiekami nostrādāts, lai to būtu vērts iemūžināt; mainīgais process vēl meklē savu formu; izņēmumu darbs pēc būtības ir spriedums. Visos trijos pareizā rīcība ir gaidīt vai vispirms sakārtot, nevis automatizēt ātrāk.

Ceturtais ir gadījums, kurā ekrāns tiek imitēts tāpēc, ka sistēmai nav saskarnes. Tas dažreiz ir vienīgais iespējamais ceļš, taču tas ir arī trauslākais: pietiek ar izmaiņu ekrānā, un darbs apstājas. Ja sistēmai saskarne ir vai to var pieprasīt, tā gandrīz vienmēr ir izdevīgāka izvēle nekā ekrāna imitēšana.

Kas notiek ar cilvēkiem, kuru darbu automatizē

Šo jautājumu automatizācijas piedāvājumos parasti apiet, lai gan uzņēmumā to uzdod jau pirmajā dienā, un neatbildēts tas kļūst par klusu pretestību, kura projektu var apturēt drošāk nekā jebkura tehniska problēma. Godīgā atbilde vairumā mazo un vidējo uzņēmumu ir tā, ka automatizācija atbrīvo laiku, nevis cilvēku: pārrakstīšana ir tā darba daļa, kuru neviens negrib, un tās izzušana parasti nozīmē, ka tas pats cilvēks beidzot paspēj darīt to, kam agrāk nepietika laika.

No tā izriet praktiska rekomendācija, kura izklausās mīksta, bet ir tīri projektu vadības jautājums: cilvēks, kurš darbu dara šodien, ir jāiesaista projektā kā zinošākais avots, ne jāinformē par rezultātu. Viņš zina izņēmumus, kurus neviens nav pierakstījis, un tieši izņēmumi ir tie, kas automatizāciju salauž. Projekts, kurā šī saruna notiek sākumā, izmaksā mazāk nekā tāds, kurā tā notiek pēc pirmās kļūdas.

Ir arī godīgi pateikt otru pusi, jo pretējais būtu izlikšanās: ja uzņēmumā kāda cilvēka darbs pilnībā sastāv no datu pārnešanas starp divām sistēmām, tad automatizācija šo darbu tiešām aizvieto, un tā ir saruna par lomas maiņu, kuru vada uzņēmuma vadība, ne piegādātājs. Piedāvājums, kurš šo jautājumu neuzdod vispār, nav delikāts — tas vienkārši nav līdz galam izdomāts.

Kā izrēķināt savu skaitli

Aprēķins, kurš ir vajadzīgs lēmumam, ietilpst vienā lapā un neprasa ne konsultantu, ne pētījumu. Vajadzīgi ir četri skaitļi: cik reižu nedēļā šis darbs notiek, cik minūtes tas aizņem katru reizi, cik maksā stunda tam cilvēkam, kurš to dara, un cik bieži tajā rodas kļūda, kuru pēc tam kāds labo.

Pirmie trīs dod tiešo laika izmaksu gadā, un šis skaitlis parasti ir mazāks, nekā gaidīts — tieši tāpēc tikai ar to pamatot projektu bieži neizdodas. Ceturtais skaitlis ir tas, kurš pārsvarā izšķir, jo kļūdas cena reti ir tikai tās izlabošanas laiks: nepareizs rēķins nozīmē saraksti ar klientu, nepareizs atlikums nozīmē vai nu preci, kura paliek nepārdota, vai pasūtījumu precei, kuras noliktavā vairs nav, un nokavēts termiņš dažkārt nozīmē soda naudu.

Pretī šiem skaitļiem liek izstrādes izmaksu un uzturēšanu, un tieši uzturēšana ir tā, kuru aizmirst. Automatizācija, kura savieno divas sistēmas, ir dzīva tik ilgi, cik dzīvas ir abas saskarnes, tāpēc plānā ir jābūt vietai izmaiņām, kuras pieprasīs kāds cits. Ja aprēķins atmaksājas tikai tad, kad uzturēšanas izmaksu neieskaita, tad tas patiesībā neatmaksājas vispār.

Vēl viena lieta, kuru ir vērts noskaidrot pirms sarunas, ir tas, cik bieži sistēmas mainās. Mākoņpakalpojums, kurš atjaunojas pats, saskarni var mainīt bez brīdinājuma, savukārt uz vietas uzstādīta programma paliek nemainīga gadiem, bet tās atjaunināšana kādreiz prasa visu pārbaudīt no jauna. Neviens no abiem variantiem nav sliktāks, taču tie prasa atšķirīgu uzturēšanas plānu, un piedāvājums, kurš to neatspoguļo, būs par lētu tieši tajā vietā, kur vēlāk radīsies izmaksas.

Kāpēc procentiem no pētījumiem nevajag ticēt

Automatizācijas piedāvājumos gandrīz vienmēr parādās skaitlis: ka automatizēt var pusi darba, ka projekti izgāžas trešdaļā gadījumu, ka kāds ietaupīja desmitiem tūkstošu stundu. Šie skaitļi eksistē un ir citējami, taču tie gandrīz nekad neapraksta to uzņēmumu, kuram tos rāda, un tieši tas padara tos par sliktu pamatu lēmumam.

Plaši citētais rādītājs par to, ka liela daļa darbību ir automatizējama, ir aprēķins par darbībām algu masā konkrētā valstī un konkrētā gadā, ar tā gada tehnoloģijām, un to publicēja konsultāciju uzņēmums, kurš pārdod šo pašu pakalpojumu. Rādītājs par projektu neveiksmēm nāk no konsultanta pieredzes ar klientiem, kuri viņu izsauca pēc pirmajām neveiksmēm, tāpēc izlase ir izkropļota jau pēc definīcijas. Skaitlis par ietaupītajām stundām apraksta konkrētu četrdesmit cilvēku grāmatvedības nodaļu citā valstī pirms vairākiem gadiem.

No tā neizriet, ka automatizācija neatmaksājas, bet gan tas, ka pareizais skaitlis ir Jūsu pašu: cik reizes nedēļā šis darbs notiek, cik ilgi tas aizņem un cik maksā stunda. Šo aprēķinu var uztaisīt vienā lapā, tas apraksta tieši Jūsu uzņēmumu, un tas ir vienīgais, uz kura pamata ir vērts pieņemt lēmumu.

Kas jāzina par sistēmām, pirms prasa piedāvājumu

Kad kandidāts ir izvēlēts, nākamais solis nav piedāvājuma prasīšana, bet piecu minūšu izpēte par pašām sistēmām, jo tieši tā izšķir, vai saruna ar izpildītāju būs par risinājumu vai par iespējamību. Noskaidrojiet, vai katrai iesaistītajai sistēmai ir programmatūras saskarne, vai tā ir pieejama Jūsu licences līmenī un vai piegādātājs par to prasa atsevišķu samaksu, jo visas trīs atbildes mēdz atšķirties.

Otrs jautājums ir par to, kurš datus glabā un kurš tos drīkst mainīt. Ja divas sistēmas satur vienu un to pašu informāciju, piemēram, klienta rekvizītus vai preces atlikumu, tad pirms savienošanas ir jāizlemj, kura no tām ir galvenā, jo citādi automatizācija sāks abas pārrakstīt savstarpēji un rezultāts būs sliktāks nekā pirms tam. Šī izšķiršanās ir bezmaksas, ja to izdara sākumā, un dārga, ja to atklāj testēšanas laikā.

Trešais ir jautājums par to, kas notiek, kad kaut kas neizdodas. Katrā automatizācijā ir gadījumi, kuri neiziet cauri (trūkst lauka, sistēma neatbild, dati ir pretrunīgi), un tiem ir vajadzīga vieta, kur nokļūt, un cilvēks, kurš tos apskata. Automatizācija bez kļūdu apstrādes strādā tik ilgi, cik ilgi viss ir kārtībā, un tas nekad nav ilgi.

Ir vērts arī iepriekš izlemt, pēc kā vērtēsiet, vai izdevās, jo bez tā projekts nekad nebeidzas, bet vienkārši pārtrūkst. Mērs var būt pavisam vienkāršs: cik reižu mēnesī kāds vēl pārraksta datus ar roku, cik kļūdu izlaboja pagājušajā mēnesī un cik ilgi pieteikums iet no formas līdz atbildei. Šo skaitli ir jēga nomērīt vienu reizi pirms darba sākšanas, lai vēlāk būtu ar ko salīdzināt. Uzņēmumi, kuri šo mērījumu neizdara, pēc pusgada strīdas par to, vai vispār kaut kas mainījās.

Visbeidzot ir vērts atcerēties, ka automatizācija nav vienreizējs darbs, bet kaut kas, kas paliek uzņēmumā un prasa īpašnieku tāpat kā jebkura cita sistēma. Kad process ir savienots, kādam ir jāzina, kur skatīties, ja tas apstājas, un kādam ir jābūt tiesīgam to apturēt, ja rezultāts izskatās nepareizs. Uzņēmumos, kuros šī loma nav nosaukta, automatizācija klusi pārstāj darboties, un to pamana tikai pēc mēneša, kad kāds meklē pazudušu dokumentu.

Ar ko sākt praktiski

Sākums nav ne rīka izvēle, ne piedāvājuma prasīšana, bet viena nedēļa, kurā tiek pierakstīts, kas notiek: kurš darbs atkārtojas, cik bieži, cik ilgi un kur tajā cilvēks pārnes datus starp sistēmām. Pēc tam katram ierakstam uzdodiet četrus šī raksta jautājumus, un lielākā daļa saraksta atkritīs jau pēc pirmajiem diviem.

Rezultātā parasti paliek pāri viens vai divi kandidāti, un tas ir labi, jo tieši tik daudz vienlaikus arī ir vērts sākt: divi pabeigti darbi dod vairāk nekā seši iesākti. Kad kandidāts ir izvēlēts, nākamais solis ir noskaidrot, vai iesaistītajām sistēmām ir saskarnes, jo tas izšķir gan cenu, gan risinājuma izturību.

Ja šajā brīdī ir skaidrs, kurš process ir Jūsu, bet nav skaidrs, kā to savienot, to var apspriest ar mums: biznesa procesu automatizācija mūsu izpildījumā ir integrācijas un darbplūsmas starp sistēmām, kuras Jums jau ir. Ja vēlaties vispirms saprast, ar ko atšķiras dažādās pieejas un rīku grupas, uzrakstiet mums vai atsūtiet savu sarakstu — bieži vien atbilde ir, ka pietiek ar vienu savienojumu, ne ar platformu.