Automatizācija sākas ar konkrētu darba situāciju
Uzņēmumā par automatizāciju parasti sāk runāt tad, kad kāds darbs jau ir kļuvis kaitinošs. Darbinieks atkārtoti ievada vienus datus vairākās vietās, vadītājs gaida pārskatu vai klients zvana, jo pēc pieteikuma nav saņēmis atbildi. Šīs situācijas ir labs sākums izpētei, tomēr tās vēl nav gatavs tehniskais uzdevums. Vispirms jānoskaidro, kurš solis aizņem laiku, kāda informācija tajā ir vajadzīga un kas būtu uzskatāms par pareizi pabeigtu darbu.
Izvēlieties vienu nesenu gadījumu un izsekojiet tam no sākuma līdz beigām. Piemēram, klients aizpildīja pieteikumu pirmdien, darbinieks to pārkopēja tabulā otrdien, bet atbildes sagatavošanai vēl vajadzēja noskaidrot pieejamību pie kolēģa. Šajā piemērā problēma var būt gan pārrakstīšana, gan neskaidra atbildība, gan nepieejams kalendārs. Ja automatizē tikai e-pasta nosūtīšanu, pārējā gaidīšana var saglabāties.
Tālāk aprakstītie piemēri ir ilustratīvi. Tie palīdz izvēlēties pirmo uzlabojumu, bet nesola noteiktu ietaupījumu vai garantētu pārdošanas pieaugumu. Automatizācijas vērtību nosaka konkrētā procesa biežums, kļūdu cena un cilvēku spēja izmantot jauno risinājumu ikdienā. Tāpēc sākumā vajadzīgs saprotams problēmas apraksts, nevis pēc iespējas garāks iespējamo tehnoloģiju saraksts.
Pierakstiet procesu tā, kā tas notiek šodien
Procesa aprakstā iekļaujiet arī neērtos starpsoļus. Ja darbinieks nosūta sev atgādinājumu, izveido pagaidu tabulu vai jautā vadītājam ziņapmaiņas lietotnē, tā ir daļa no faktiskās darbības. Skaista shēma, kurā šie soļi pazūd, var radīt nepareizu priekšstatu par darba apjomu. Svarīgi ir saprast, kā informācija patiesībā nonāk līdz nākamajam cilvēkam.
Katram solim pierakstiet izraisītāju, ievadi, rezultātu un atbildīgo. Piemēram, izraisītājs ir saņemts pieteikums, ievade ir klienta kontaktinformācija un vajadzības apraksts, rezultāts ir izvērtēšanai gatavs ieraksts, bet atbildīgais ir konkrēta loma komandā. Ja solis beidzas tikai ar vārdiem “kāds paskatās”, tur vēl trūkst pietiekamas skaidrības automatizēšanai.
Noderīgi ir atsevišķi atzīmēt aktīvo darbu un gaidīšanu. Piecu minūšu uzdevums var kavēt klienta atbildi divas dienas, ja tas gaida vienīgo cilvēku ar nepieciešamo piekļuvi. Savukārt bieža datu pārrakstīšana var prasīt daudz kopējā laika, kaut arī katrs atsevišķais gadījums šķiet nenozīmīgs. Abi šķēršļi ir svarīgi, taču tiem vajadzīgi atšķirīgi risinājumi.
Nosakiet vienu saprotamu rezultātu
Formulējums “vēlamies automatizēt pārdošanu” ir pārāk plašs pirmajam projektam. Precīzāks mērķis būtu: katrs mājaslapas pieteikums nonāk kopīgā sarakstā ar saņemšanas laiku un atbildīgo, un komanda redz, kuri pieteikumi vēl nav apstrādāti. Šādu rezultātu var pārbaudīt ar konkrētiem piemēriem, arī neiesaistot sarežģītu pārdošanas sistēmu.
Izvēlieties sākotnējo rādītāju, kuru jau spējat novērot. Tas var būt laiks līdz pirmajai atbildei, ierakstu skaits bez atbildīgā vai labojumu skaits pēc manuālas pārrakstīšanas. Pierakstiet, kā rādītājs tiek iegūts. Ja vienā mēnesī mēra darba stundas, bet nākamajā kalendāro laiku, salīdzinājums būs maldinošs pat tad, ja dati izskatīsies precīzi.
Mērķis nedrīkst mudināt pasliktināt klienta pieredzi. Ātri nosūtīta automātiska ziņa vēl nenozīmē, ka klienta jautājums atrisināts. Tāpēc līdzās ātrumam jāvērtē arī atbildes lietderība un kļūdainu gadījumu skaits. Labs sākuma mērķis apvieno vienkāršāku darbu komandai ar skaidrāku nākamo soli klientam.
Izvēlieties pirmo procesu pēc ieguvuma un riska
Salīdziniet vairākus kandidātus pēc līdzīgiem jautājumiem. Cik bieži darbs atkārtojas? Vai ievade ir pieejama digitāli? Vai lēmums balstās skaidros noteikumos? Kas notiks, ja automatizācija kļūdīsies? Vai rezultātu iespējams atsaukt? Šāda izvērtēšana parasti palīdz labāk nekā tikai jautājums par to, kuru darbu komandai visvairāk nepatīk darīt.
Pirmajam izmēģinājumam bieži piemērots process ar atkārtojamu ievadi un nelielu kļūdas ietekmi. Piemēram, sagatavot iekšēju pieteikumu kopsavilkumu var būt drošāk nekā uzreiz automātiski apstiprināt nestandarta cenu. Tas nenozīmē, ka sarežģītākus procesus nevar uzlabot. Tie vienkārši prasa skaidrākas robežas, atbildību un vairāk pārbaudes piemēru.
Neizvēlieties projektu tikai tāpēc, ka tam ir iespaidīga demonstrācija. Demonstrācija var parādīt vienu ideālu ievadi, bet uzņēmuma ikdienā dati mēdz būt nepilnīgi un situācijas mainīgas. Pajautājiet, kā risinājums rīkosies, ja pietrūks obligātās informācijas vai atbildīgais darbinieks būs prombūtnē. Atbilde uz šiem jautājumiem palīdz saprast reālo ieviešanas apjomu.
Sakārtojiet datus pirms savienošanas
Automatizācija neatrisina neskaidru datu nozīmi. Ja vienā tabulā “klients” nozīmē uzņēmumu, bet citā kontaktpersonu, vienkārša kolonnu savienošana var radīt sajauktus ierakstus. Vienojieties par būtiskajiem laukiem, to nozīmi un vietu, kur attiecīgā informācija tiek uzturēta. Sāciet ar tiem datiem, kas patiešām vajadzīgi izvēlētajam procesam.
Pārbaudiet vairākus reālus, vajadzības gadījumā anonimizētus piemērus. Apskatiet tukšus laukus, atšķirīgu datumu pierakstu, vecus ierakstus un dublikātus. Izlemiet, vai kļūdainu ierakstu drīkst labot automātiski, vai tas jānodod cilvēkam. Neskaidras vērtības nevajag aizpildīt ar minējumiem tikai tāpēc, lai darbplūsma turpinātos bez paziņojuma.
Noder arī vienkāršs datu īpašnieku saraksts. Kontaktinformāciju var pārbaudīt klientu apkalpošanas komanda, bet pakalpojumu pieejamību uztur cita loma. Tehniskais risinājums var norādīt neatbilstību, taču kādam joprojām jāspēj izlemt, kura vērtība ir pareiza. Bez šīs atbildības kļūdas tikai ātrāk pārvietojas starp sistēmām.
Atšķiriet noteikumus no interpretācijas
Daļu uzdevumu var izpildīt ar skaidru noteikumu: ja nav obligāta lauka, pieteikums nav gatavs apstrādei; ja statuss mainās, jāizveido paziņojums. Šādos gadījumos nav obligāti vajadzīgs mākslīgais intelekts. Vienkāršs noteikums ir vieglāk pārbaudāms un dod paredzamāku rezultātu, ja ievades struktūra nemainās.
AI var palīdzēt tur, kur jāapstrādā brīvs teksts, jāizveido melnraksts vai jāsagrupē līdzīgi jautājumi. Tomēr tā interpretācija jānodala no uzņēmuma apstiprinātajiem datiem. Ja modelis no klienta vēstules izsecina iespējamu prioritāti, tas nav tas pats, kas klienta skaidri norādīts termiņš. Saglabājiet sākotnējo informāciju, lai darbinieks var salīdzināt secinājumu ar avotu.
Praktisks sākuma variants ir automātiski sagatavots priekšlikums ar cilvēka pārbaudi. Piemēram, sistēma apkopo pieteikumu un iesaka kategoriju, bet darbinieks apstiprina nākamo darbību. Kad uzkrāti pārbaudīti piemēri un zināmas kļūdu robežas, var izvērtēt, kurus soļus pamatoti atstāt pilnīgi automātiskus.
Paredziet izņēmumus pirms palaišanas
Katram procesam ir gadījumi, kuros ierastais ceļš neder. Klients var iesniegt pieteikumu divreiz, mainīt kontaktinformāciju vai atsaukt savu vēlmi, kamēr darbinieks vēl gatavo piedāvājumu. Izņēmumus nevajag uzskatīt par vēlāk atrisināmiem sīkumiem. Tie nosaka, vai automatizācija palīdzēs komandai vai radīs papildu neskaidrību.
Izveidojiet īsu izņēmumu sarakstu un katram norādiet rīcību. Trūkstoša informācija var nozīmēt gaidīšanas statusu. Nesaskanīgi dati var prasīt manuālu pārbaudi. Ārējā pakalpojuma īslaicīga nepieejamība var ļaut mēģināt vēlreiz. Šīs situācijas ir atšķirīgas, tāpēc vienāds sarkans paziņojums “kļūda” visām nebūs pietiekams.
Darbiniekam jāredz, ko viņš drīkst darīt tālāk. Vai var atkārtot darbību? Vai pieteikums jau saglabāts? Vai klientam nosūtīta ziņa? Vai labojums skars tikai šo gadījumu? Saprotama kļūmes apstrāde ir daļa no risinājuma funkcionalitātes. Tā nav tikai tehniska informācija, kuru pēc palaišanas var atstāt izstrādātāja žurnālā.
Nepieļaujiet atkārtotas darbības nejauša mēģinājuma dēļ
Tīkla pārtraukums var radīt situāciju, kurā sūtītājs nezina, vai saņēmējs jau izpildīja darbību. Lietotājs nospiež pogu vēlreiz vai sistēma atkārto pieprasījumu. Ja katrs mēģinājums izveido jaunu ierakstu, rezultāts var būt vairāki vienādi pieteikumi un atkārtoti paziņojumi. Šis risks jāņem vērā arī nelielā automatizācijā.
Procesam vajadzīgs veids, kā atšķirt jaunu uzdevumu no tā paša uzdevuma atkārtojuma. Tehniskais risinājums var izmantot unikālu pieprasījuma identifikatoru un saglabātu izpildes rezultātu. Uzņēmumam svarīgākais pārbaudes kritērijs ir vienkāršs: atkārtots mēģinājums nedrīkst nepamanīti dubultot vienu klienta darbību.
Pārbaudiet arī apzinātus atkārtojumus. Tas pats klients var iesniegt divus dažādus pasūtījumus, un tos nedrīkst apvienot tikai vienāda e-pasta dēļ. Tāpēc dublikātu noteikšanas loģikai jāatbilst procesa nozīmei. Pareizais jautājums ir nevis “vai šo cilvēku jau redzējām”, bet “vai šī konkrētā darbība jau ir izpildīta”.
Saglabājiet cilvēkam pārskatāmu vadību
Automatizētam procesam jābūt redzamam arī pēc palaišanas. Komandai vajadzētu saprast, kuri uzdevumi gaida, kuri izpildīti un kuriem vajadzīga palīdzība. Ne vienmēr nepieciešams jauns vadības panelis. Dažreiz pietiek ar jau izmantotu sarakstu un skaidriem statusiem, ja informācija tajā ir uzticama un savlaicīga.
Nosakiet, kurš drīkst mainīt noteikumus un kurš tikai apstrādā atsevišķus gadījumus. Ikdienas darbiniekam nav nepieciešama piekļuve visai tehniskajai konfigurācijai, lai labotu klienta tālruni. Savukārt uzturētājam jāspēj pārbaudīt procesa darbību, nesaņemot nevajadzīgu piekļuvi pilnīgi nesaistītiem uzņēmuma datiem.
Jābūt arī saprotamai apturēšanas iespējai. Ja automatizācija sāk dot nepareizu rezultātu, atbildīgais var apturēt jaunas darbības un turpināt kritisko darbu manuāli. Iepriekš vienojieties, kur saglabājas neapstrādātie uzdevumi un kā tos atsākt. Apturēšana nedrīkst nozīmēt, ka komanda pazaudē informāciju par saņemtajiem klientu pieteikumiem.
Izmēģiniet risinājumu ar reprezentatīviem piemēriem
Pārbaudei nepietiek ar vienu pareizi aizpildītu formu. Izmantojiet parastu gadījumu, nepilnīgu ievadi, atkārtotu darbību un situāciju, kad kāds savienojums nav pieejams. Pierakstiet sagaidāmo rezultātu pirms testa. Pretējā gadījumā pastāv risks jebkuru iegūto rezultātu pēc tam nosaukt par pieņemamu.
Sākuma testus var veikt atsevišķā lokālā vidē ar izdomātiem datiem. Tas ļauj pārbaudīt loģiku bez īstiem klientu ziņojumiem un maksājumiem. Taču lokāls tests nepierāda, ka ārējais e-pasta pakalpojums vai publiskā vide darbojas pareizi. Šīs robežas jānorāda atskaitē, un nepieciešamie savienojumi jāpārbauda savā ieviešanas posmā.
Lietderīgi ir uzaicināt ikdienas darbinieku izpildīt dažus scenārijus bez izstrādātāja palīdzības. Viņš var pamanīt nesaprotamus statusus vai trūkstošu informāciju, kuru tehniskais tests neuzrāda. Pierakstiet gan kļūdas, gan jautājumus. Arī regulāri atkārtots jautājums var norādīt, ka sistēma cilvēkam nedod pietiekami skaidru nākamo soli.
Ieviesiet pa posmiem un saglabājiet atkāpšanās ceļu
Pirmajā posmā automatizācija var tikai sagatavot rezultātu salīdzināšanai ar esošo darbu. Piemēram, tā izveido pārskata melnrakstu, bet komanda vēl izmanto ierasto apstiprināšanas kārtību. Šāda paralēla pārbaude palīdz atrast neatbilstības pirms automātiskām ārējām darbībām. Tā jāierobežo laikā, lai neradītu pastāvīgu dubultu darbu.
Nākamajā posmā var pieslēgt vienu pakalpojumu, vienu komandu vai nelielu pieteikumu grupu. Skaidri norādiet, kuri gadījumi jau iet caur jauno procesu. Ja daļa darbinieku turpina izmantot veco sarakstu bez kopīgas vienošanās, radīsies divas atšķirīgas patiesības. Ieviešanas komunikācija šeit ir tikpat svarīga kā tehniskais savienojums.
Pirms pārslēgšanās sagatavojiet atjaunošanas plānu. Tajā jābūt zināmam iepriekšējam stāvoklim, atbildīgajam un nepabeigto uzdevumu sarakstam. Nav nepieciešams sarežģīts dokuments, bet jāspēj atbildēt: ko darām, ja nākamajā rītā process nestrādā? Šī atbilde palīdz izvairīties no improvizētas datu labošanas steigas brīdī.
Aprēķiniet uzturēšanu kopā ar ieviešanu
Sākotnējā izveide ir tikai viena izmaksu daļa. Noskaidrojiet, kādi pakalpojumi būs vajadzīgi ikdienā, kas uzraudzīs kļūmes un kā rīkosieties, ja mainīsies ārējās sistēmas noteikumi. Nelielam procesam nav automātiski vajadzīga sarežģīta infrastruktūra. Izvēlei jāatbilst faktiskajam apjomam un komandas iespējām uzturēt risinājumu.
Atsevišķi nodaliet izstrādes darbu, ārējo pakalpojumu maksas un turpmāku izmaiņu apjomu. Ja izmantojat AI, vienojieties arī par to, kad tas darbojas un kā tiek kontrolēts patēriņš. Skaidra izmaksu struktūra palīdz salīdzināt variantus. Tā ir lietderīgāka nekā viena kopīga summa bez paskaidrojuma par to, ko tā ietver.
Uzturēšanas vienošanās var paredzēt piekļuves, problēmas pieteikšanas kārtību un atbildību par satura izmaiņām. Pierakstiet arī, kas notiek, ja sadarbība beidzas. Uzņēmumam jāspēj iegūt savu informāciju un saprast, kuri servisi ir nepieciešami procesa turpināšanai. Šos jautājumus ir vieglāk sakārtot sākumā nekā steidzamas pārejas laikā.
Piemērs: pieteikumu apstrāde pakalpojumu uzņēmumā
Iedomāsimies uzņēmumu, kas saņem pieprasījumus mājaslapā un e-pastā. Darbinieks tos pārkopē tabulā, pārbauda pieejamību un sagatavo atbildi. Daļa vēstuļu pazūd kopējā pastkastē, bet vadītājam nav skaidrs, kuri klienti vēl gaida. Šeit pirmais mērķis var būt visu pieteikumu redzamība, nevis pilnīgi automātiska pārdošana.
Sākuma risinājums saglabā mājaslapas pieteikumu, piešķir tam identifikatoru un parāda to atbildīgajam. Darbinieks papildina trūkstošo informāciju un atzīmē turpmāko soli. E-pasta pieteikumiem sākumā var saglabāt manuālu ievadi tajā pašā sarakstā. Šādi komanda iegūst kopīgu procesu, nepievienojot uzreiz sarežģītu katras vēstules interpretāciju.
Pārbaudes scenāriji ietver atkārtoti nospiestu iesniegšanas pogu, nepareizu adresi un darbinieka prombūtni. Gatavības kritērijs ir viens saglabāts pieteikums, skaidrs statuss un pārņemama atbildība. Tikai pēc šī pamata pārbaudes ir jēga pievienot automātisku kopsavilkumu vai papildu savienojumus. Piemērs parāda pieeju, nevis universālu komplektu katram uzņēmumam.
Ko sagatavot pirmajai sarunai
Sagatavojiet viena procesa īsu aprakstu un dažus anonimizētus piemērus. Norādiet izmantotās sistēmas, iesaistītās lomas, aptuveno atkārtošanās biežumu un biežākās problēmas. Pirmajai izvērtēšanai nav jāsūta paroles vai visa klientu datubāze. Par piekļuvēm vienojas tad, kad ir skaidrs nepieciešamais apjoms un drošs tās piešķiršanas veids.
Pierakstiet arī to, ko nevēlaties mainīt. Varbūt komandai der esošais kalendārs, bet nepatīk pieteikumu pārrakstīšana. Varbūt svarīgi saglabāt konkrētu apstiprināšanas soli. Šīs robežas palīdz veidot samērīgu risinājumu un novērš nevajadzīgu sistēmu nomaiņu. Labs darba uzdevums ietver gan vēlamo uzlabojumu, gan saglabājamās darba priekšrocības.
Sarunas beigās vajadzētu būt saprotamam pirmajam posmam: ko mainām, kā to pārbaudām un kas paliek vēlākam laikam. CANIMAPS DIGITAL var palīdzēt izprast šo procesu, sagatavot risinājuma apjomu un ieviest saskaņotu automatizāciju. Sāciet ar konkrētas situācijas aprakstu, lai piedāvājums balstītos jūsu uzņēmuma darbā, nevis vispārīgā tehnoloģiju solījumā.
Pārskatiet rezultātu pēc reālas lietošanas
Pēc ieviešanas atgriezieties pie sākumā noteiktā rādītāja un salīdziniet līdzīgus darba periodus. Viena neparasti mierīga diena vēl nepierāda būtisku laika ietaupījumu. Apskatiet arī pieteikumu daudzumu un sarežģītību. Ja jaunajā periodā pieprasījumu ir mazāk, īsāka atbilžu gaidīšana var nebūt tikai automatizācijas nopelns. Pierakstot šos apstākļus, uzņēmums iegūst daudz uzticamāku priekšstatu par izmaiņu vērtību.
Pārrunājiet rezultātu ar tiem, kuri procesu izmanto. Var izrādīties, ka pārrakstīšana ir pazudusi, bet jauns statuss darbiniekiem prasa papildu skaidrošanu. Tas nav iemesls uzreiz atteikties no visa risinājuma. Nosakiet konkrēto šķērsli un izvērtējiet nelielu labojumu. Savukārt funkciju, kuru neviens nelieto un kurai nav skaidra uzdevuma, nevajag uzturēt tikai tāpēc, ka tā sākotnēji tika iekļauta plānā.
Atsevišķi novērtējiet klientu jautājumus pēc izmaiņām. Ja apmeklētāji biežāk jautā, vai pieteikums saņemts, apstiprinājuma teksts var būt nepietiekami skaidrs. Ja darbiniekiem joprojām jāzvana, lai precizētu vienu un to pašu detaļu, formā vai pakalpojuma aprakstā var pietrūkt būtiskas informācijas. Šādi novērojumi dod nākamajiem uzlabojumiem konkrētu pamatojumu.
Uzturiet nelielu izmaiņu vēsturi
Procesa noteikumi laika gaitā mainās. Uzņēmums pievieno jaunu pakalpojumu, maina komandas pienākumus vai ievieš citu darba grafiku. Katram būtiskam labojumam pierakstiet, ko mainījāt, kāpēc un kā pārbaudījāt rezultātu. Nav vajadzīga sarežģīta birokrātija, bet pēc mēneša jāspēj saprast, kura izmaiņa ietekmēja konkrēto darbību. Tas palīdz arī tad, ja uzturēšanu pārņem cits cilvēks.
Pirms noteikuma maiņas pārbaudiet, kas notiks ar jau iesāktajiem gadījumiem. Ja pieteikums saņemts pie vecās kārtības, vai tas turpinās pēc tās vai pāries uz jauno? Abas pieejas var būt pamatotas, taču izvēlei jābūt apzinātai. Pretējā gadījumā komanda var dot klientam vienu solījumu un vēlāk nejauši piemērot atšķirīgus nosacījumus.
Pēc labojuma atkārtojiet pārbaudes, kuras šī izmaiņa var ietekmēt. Ja mainīta pieteikuma kategoriju izvēle, pārbaudiet saglabāšanu, atbildīgā piešķiršanu un attēlojumu darbiniekam. Nav nepieciešams katru reizi pārbaudīt nesaistītu uzņēmuma sistēmu. Mērķēta pārbaude ietaupa resursus un vienlaikus dod pierādījumu par to, ka konkrētā izmaiņa izpilda paredzēto uzdevumu.
Automatizācijas robežās iekļaujiet informācijas dzīves ciklu
Domājot par datiem, neapstājieties pie to saņemšanas. Jāsaprot, kur ieraksts glabājas pēc apstrādes, kas to var redzēt un kā tiek apstrādāts labojums. Ja viena klienta informācija nokopēta vairākās sistēmās, izmaiņa vienā vietā var neatspoguļoties citur. Pierakstiet šīs saites, lai ikdienas darbinieks zinātu, kurš ieraksts ir galvenais un kur nepieciešama papildu darbība.
Neiekļaujiet tehniskajos žurnālos visu pieteikuma tekstu tikai tāpēc, ka to ir viegli saglabāt. Kļūmes izpētei bieži pietiek ar ieraksta identifikatoru, darbības laiku un kļūdas kategoriju. Vajadzīgo informācijas apjomu nosaka konkrētais process. Arī testu piemēros priekšroka dodama izdomātiem vai anonimizētiem datiem, lai ikdienas klientu informācija nevajadzīgi neizplatītos izstrādes materiālos.
Vienojieties arī par arhivēšanu un piekļuves pārskatīšanu. Darbiniekam mainot pienākumus, iepriekš nepieciešamā piekļuve var vairs nebūt vajadzīga. Procesa uzturētājam savukārt jāspēj iegūt pietiekamu diagnostiku, neprasot kopīgas paroles visiem uzņēmuma rīkiem. Sakārtota piekļuve padara turpmākus labojumus vienkāršākus un skaidrāk nosaka katras iesaistītās puses atbildību.
Kā atpazīt, ka pirmais posms ir gatavs
Pirmo posmu var uzskatīt par pabeigtu, kad saskaņotais ceļš darbojas, izņēmumi ir saprotami un atbildīgais prot procesu izmantot. Tam pievienojiet īsu pierādījumu sarakstu: pārbaudītie piemēri, zināmie ierobežojumi un instrukcija biežākajai problēmai. Gatavība nav tikai demonstrācija ar izstrādātāju blakus. Ikdienas komandai jāspēj patstāvīgi izpildīt parasto darbu un atpazīt gadījumu, kad vajadzīga palīdzība.
Nākamās idejas glabājiet atsevišķā sarakstā, lai tās nepagarinātu pirmo posmu bez skaidras izvēles. Ja jau pārbaudītais risinājums dod praktisku ieguvumu, to var izmantot, kamēr papildu iespējas vēl tiek izvērtētas. Turpmāko darbu prioritāti nosaka faktiskās problēmas un lietošanas pieredze. Tā automatizācija kļūst par pakāpenisku uzņēmuma darba uzlabošanu, kur katram papildinājumam ir saprotams iemesls un pārbaudāms rezultāts.
Sagatavotā procesa aprakstu var izmantot arī darbinieka ievadapmācībā. Ja jauns kolēģis pēc tā spēj atrast pieteikumu, saprast tā statusu un izvēlēties nākamo soli, apraksts palīdz praksē. Ja tas iespējams tikai ar autora mutisku skaidrojumu, papildiniet tieši neskaidro vietu, nevis veidojiet vēl vienu garu, ikdienā nelietotu dokumentu.