Biznesa procesa kartēšana pirms automatizācijas nozīmē aprakstīt, kā darbs patiesībā nonāk no sākuma notikuma līdz pārbaudāmam rezultātam. Labā kartē ir redzami ne tikai secīgie soļi, bet arī atbildīgie, izmantotie dati un sistēmas, lēmumu noteikumi, nodošana starp lomām un rīcība nestandarta gadījumos. Bez šīs informācijas automatizācija parasti nostiprina esošo jucekli, nevis to novērš.
Procesa karte nav jāveido kā sarežģīta diagramma. Nelielam procesam pietiek ar skaidru soļu reģistru un vienkāršu plūsmas attēlojumu. Svarīgāk ir vienoties par procesa robežām, nosaukt vienu īpašnieku un pārbaudīt aprakstu pret reāliem gadījumiem. Tikai pēc tam var droši izlemt, kurus soļus automatizēt, kur vajadzīga cilvēka kontrole un kā sistēmai jāapstrādā izņēmumi.
Kāpēc procesa kartēšana jāveic pirms tehniskā risinājuma
Automatizācija izpilda noteiktu loģiku atkārtoti un konsekventi. Ja loģika nav skaidra, arī tehniskais risinājums būs balstīts minējumos. Izstrādes laikā tad atklājas jauni apstiprinājumi, datu avoti, īpašie klientu gadījumi un neformāli noteikumi, kurus iepriekš zināja tikai viens darbinieks. Mainās prasības, palielinās izmaksas un kļūst grūti noteikt, vai risinājums vispār darbojas pareizi.
Procesa pieeja uzņēmumu aplūko kā savstarpēji saistītu procesu sistēmu, nevis izolētu uzdevumu kopumu. Tas ir būtiski arī automatizācijā: izmaiņa vienā posmā var pārcelt darbu uz citu nodaļu, radīt papildu datu pārbaudi vai izmainīt klienta pieredzi. Lokāli ātrāks solis vēl nenozīmē ātrāku gala rezultātu.
Kartēšanas mērķis nav dokumentēt katru peles klikšķi. Tai jāsniedz pietiekami precīza atbilde uz septiņiem jautājumiem:
- kas iedarbina procesu un kur tas beidzas;
- kādu biznesa rezultātu process rada;
- kādi soļi un lēmumi veido parasto ceļu;
- kura loma par ko atbild;
- kādi dati tiek saņemti, mainīti un nodoti;
- kādi izņēmumi var mainīt procesa gaitu;
- pēc kādiem rādītājiem noteiksim, vai uzlabojums ir izdevies.
Ja uz šiem jautājumiem nav vienotas atbildes, automatizācijas tehnisko uzdevumu vēl ir pāragri rakstīt.
Vispirms nosaki procesa robežas un rezultātu
Pārāk plaša procesa karte ātri kļūst nelietojama. Piemēram, “klientu apkalpošana” vai “rēķinu aprite” nav pietiekami precīzas robežas. Kartējamo procesu labāk formulēt no konkrēta sākuma notikuma līdz konkrētam beigšanas stāvoklim.
Rēķinu saskaņošanas procesam sākums var būt piegādātāja rēķina saņemšana vienā noteiktā kanālā. Beigas var būt viens no trim stāvokļiem: rēķins apstiprināts un nodots iegrāmatošanai, noraidīts ar pamatojumu vai atgriezts precizēšanai. Šāda robeža ļauj saprast, kas ietilpst automatizācijā un kas paliek ārpus tās.
Pieraksti arī procesa rezultātu no saņēmēja skatpunkta. “Rēķins pārvietots uz nākamo mapi” ir sistēmas darbība. “Apstiprināts rēķins ar pilniem uzskaites datiem ir pieejams iegrāmatošanai līdz noteiktam termiņam” jau ir pārbaudāms rezultāts.
Procesa kartes sākumā fiksē:
- procesa nosaukumu;
- sākuma notikumu;
- beigu stāvokļus;
- rezultāta saņēmēju;
- procesa īpašnieku;
- galveno kvalitātes, laika vai izmaksu rādītāju;
- darbības, kas apzināti neietilpst kartes tvērumā.
Šī vienošanās pasargā no situācijas, kurā dažādi cilvēki ar vienu procesa nosaukumu saprot atšķirīgu darba apjomu.
Kartē reālo procesu, nevis vēlamo versiju
Kartēšanas sarunā darbinieki bieži apraksta oficiālo kārtību. Ikdienā process var notikt citādi: informācija tiek prasīta čatā, apstiprinājums saņemts mutiski, dati pārrakstīti privātā tabulā, bet steidzami gadījumi apiet parasto rindu. Automatizācijai vajadzīga faktiskā, nevis deklarētā plūsma.
Sāc ar vienu vai vairākiem nesen pabeigtiem gadījumiem un izseko tiem no sākuma līdz beigām. Atver izmantotos e-pastus, sistēmu ierakstus, dokumentus un statusu vēsturi. Jautā ne tikai “kas notiek tālāk?”, bet arī:
- ko darbinieks saņem pirms šī soļa;
- ko viņš pārbauda;
- kādu lēmumu pieņem;
- ko izveido vai izmaina;
- kam nodod rezultātu;
- kur un kāpēc darbs mēdz gaidīt;
- kā rīkojas, ja vajadzīgās informācijas nav.
Ja reālais process atšķiras no noteikumiem, vispirms nosauc šo atšķirību. Dažreiz jālabo darba kārtība, nevis jāprogrammē sistēma, kas atdarina neformālu apiešanas ceļu.
Dokumentē soļus vienādā detalizācijas līmenī
Procesa solim jāapraksta pabeidzama darbība ar redzamu rezultātu. “Apstrādāt pieteikumu” ir pārāk plaši. To var sadalīt: pārbaudīt obligātos laukus, noteikt pieteikuma kategoriju, identificēt atbildīgo komandu, izveidot ierakstu CRM un nosūtīt saņemšanas apstiprinājumu.
Vienlaikus nav lietderīgi katru soli sadalīt ekrāna klikšķos, kamēr vēl nav izvēlēts konkrēts tehniskais risinājums. Procesa kartē apraksta biznesa darbību; detalizētu lietotāja saskarnes scenāriju veido vēlāk.
Katram solim izmanto vienu struktūru:
- Darbība. Ko tieši dara, vēlams ar darbības vārdu.
- Izpildītājs. Cilvēka loma, sistēma vai ārējs dalībnieks.
- Ievade. Kāda informācija vai notikums nepieciešams sākšanai.
- Rezultāts. Kas pēc soļa ir radīts, mainīts vai apstiprināts.
- Sistēma. Kur darbība un tās rezultāts tiek fiksēts.
- Noteikums. Kādi nosacījumi ietekmē izpildi vai nākamo ceļu.
- Laiks. Cik ilgi darbs parasti notiek un cik ilgi mēdz gaidīt.
Šāds reģistrs vēlāk kļūst par pamatu prasībām, testu scenārijiem un pieņemšanas kritērijiem.
Parādi lomas, atbildību un nodošanas punktus
Daudzi kavējumi nerodas pašā darbībā. Tie rodas brīdī, kad darbs pāriet no viena cilvēka vai departamenta pie cita. Tāpēc procesa kartē jābūt redzamām joslām jeb swimlanes, kas atdala lomas un sistēmas. Katrs plūsmas šķērsojums starp joslām ir nodošanas punkts, kuru vērts pārbaudīt īpaši.
Vienam procesam vajadzīgs viens īpašnieks. Viņš atbild par gala rezultātu un procesa darbību kopumā, taču ne obligāti izpilda visus soļus. Papildus katram solim norāda izpildītāju un, ja vajadzīgs, apstiprinātāju. Konsultējamās personas nepārvērt par slēptiem apstiprinātājiem — citādi process apstājas, gaidot cilvēku, kura lēmuma tiesības nav skaidras.
Nodošanas punktā fiksē četras lietas: ko nodod, kam nodod, kā saņēmējs uzzina par jauno darbu un pēc kā viņš var pārliecināties, ka ievade ir pilnīga. Automatizēts paziņojums nepalīdz, ja nav skaidrs, kurš uzdevumu pārņem vai kāds ir tā izpildes termiņš.
Apraksti datus kā procesa daļu, nevis pielikumu
Uzņēmuma automatizācija bieži apstājas nevis plūsmas, bet datu dēļ. Vienam klientam ir vairāki identifikatori, obligāts lauks paliek tukšs, summa tiek glabāta kā teksts, vai arī divas sistēmas sevi uzskata par galveno avotu. Tāpēc datu apraksts jāveido kopā ar soļiem.
Par katru būtisku datu kopu nosaki:
- datu nosaukumu un biznesa nozīmi;
- avotu un sistēmu, kas ir patiesības avots;
- obligātos un izvēles laukus;
- formātu un pieļaujamās vērtības;
- pārbaudes pirms izmantošanas;
- kurš drīkst datus skatīt vai mainīt;
- kur un cik ilgi rezultāts tiek glabāts;
- kam dati tiek nodoti tālāk.
Nav jāveido pilns datu katalogs katram mazam procesam. Taču laukiem, kas nosaka lēmumu, maksājumu, klienta statusu, nodokļu piemērošanu vai piekļuves tiesības, jābūt nepārprotami aprakstītiem. Pretējā gadījumā izstrādātājs ir spiests biznesa noteikumus izsecināt no veciem failiem vai atsevišķiem piemēriem.
Lēmumu punktos pieraksti biznesa noteikumus
Diagrammas rombs ar jautājumu “viss kārtībā?” nav pietiekama prasība. Sistēmai vajadzīgs pārbaudāms noteikums: kādi lauki tiek vērtēti, kādas robežvērtības piemēro, kurš avots ir autoritatīvs un kas notiek, ja nosacījumi konfliktē.
Piemēram, rēķina apstiprināšanas ceļu var ietekmēt summa, izmaksu centrs, piegādātāja statuss, pirkuma pasūtījuma esamība un līguma limits. Katram nosacījumam norādi noteikuma īpašnieku. Ja finanšu vadītājs maina apstiprināšanas slieksni, jābūt saprotamam, kur sistēmā šo noteikumu pārvaldīs un kā izmaiņas tiks pārbaudītas.
Nošķir biznesa noteikumu no tehniskas realizācijas. “Ja summa pārsniedz apstiprināšanas slieksni, vajadzīgs papildu apstiprinātājs” ir biznesa noteikums. Konkrēta datubāzes tabula, API izsaukums vai automatizācijas platformas nosacījuma bloks ir realizācijas izvēle.
Izņēmumi jāprojektē tikpat rūpīgi kā parastais ceļš
Procesa galvenā plūsma parasti ir vienkārša. Sarežģījumi parādās izņēmumos. Ja tie nav dokumentēti, pēc palaišanas cilvēki sāk labot datus manuāli, veidot paralēlas tabulas vai sūtīt izstrādātājam atsevišķus “mazus” papildinājumus.
Ir lietderīgi nošķirt trīs situāciju veidus:
- biznesa izņēmums — gadījums ir derīgs, bet tam vajadzīgs cits ceļš, piemēram, jauns piegādātājs vai neparasti liela summa;
- datu izņēmums — trūkst obligātas informācijas, vērtības konfliktē vai ieraksts var būt dublikāts;
- tehniska kļūme — sistēma nav pieejama, savienojums beidzas ar timeout vai ārējais serviss noraida pieprasījumu.
Katram būtiskam izņēmumam pieraksti atpazīšanas nosacījumu, atbildīgo, drošo pagaidu stāvokli, paziņojumu, izpildes termiņu un punktu, kurā gadījums atgriežas pamatplūsmā. Jābūt skaidram arī tam, vai darbību drīkst atkārtot un kā novērst dublikātu.
Izņēmumu saraksts nav mēģinājums paredzēt pilnīgi visu. Sāc ar gadījumiem, kuri regulāri patērē darbinieku laiku, rada finansiālu vai juridisku risku, ietekmē klientu vai var apturēt visu plūsmu. Retiem un zema riska gadījumiem var apzināti atstāt manuālu ceļu.
Kādu kartēšanas formātu izvēlēties
Formāts ir atkarīgs no procesa sarežģītības un auditorijas. Vienkāršam vienas komandas procesam pietiek ar soļu tabulu un nelielu plūsmas shēmu. Ja ir vairākas lomas un biežas nodošanas, noder swimlane diagramma. Ja procesā ir daudz notikumu, paralēlu ceļu, ziņojumu un apakšprocesu, var izmantot BPMN — standartizētu biznesa procesu modelēšanas notāciju.
BPMN dod precīzu valodu notikumiem, darbībām, lēmumu vārtejām, dalībniekiem un ziņojumu plūsmām. Tomēr nav jāsāk ar pilnu simbolu komplektu. Diagrammai jāpalīdz biznesa un tehniskajai komandai vienādi saprast procesu. Ja lasītāji nespēj izskaidrot karti bez autora palīdzības, notācija ir kļuvusi svarīgāka par saturu.
Praktiski bieži vajadzīgi divi savstarpēji saistīti artefakti: vizuāla karte kopējai izpratnei un detalizēts soļu, datu, noteikumu un izņēmumu reģistrs izstrādei.
Praktisks piemērs: piegādātāja rēķina saskaņošana
Procesa sākums: rēķins saņemts noteiktā e-pasta adresē vai e-rēķinu kanālā. Beigas: rēķins ar vajadzīgajiem uzskaites datiem apstiprināts, noraidīts vai nosūtīts precizēšanai.
Pamatplūsma var būt šāda:
- Sistēma reģistrē saņemto dokumentu un pārbauda faila formātu.
- Tiek nolasīti piegādātāja, rēķina numura, datuma, summas un apmaksas termiņa dati.
- Sistēma pārbauda iespējamu dublikātu un salīdzina piegādātāju ar uzņēmuma reģistru.
- Atbildīgā persona pievieno izmaksu centru, projektu vai pasūtījuma atsauci.
- Rēķins tiek novirzīts apstiprinātājam atbilstoši noteikumiem.
- Pēc apstiprināšanas dati un dokuments tiek nodoti grāmatvedības sistēmai.
Ar šo sarakstu vien nepietiek. Jāapraksta, kas notiek, ja piegādātājs ir jauns, summa pārsniedz līguma limitu, pirkuma pasūtījums nav atrasts, PVN dati nesakrīt, rēķins iesniegts atkārtoti vai apstiprinātājs ir prombūtnē. Jānosaka arī patiesības avots piegādātāja rekvizītiem un tas, kurā sistēmā glabājas gala apstiprinājums.
Tieši šīs detaļas pārvērš vispārīgu automatizācijas ideju par izstrādājamu un testējamu procesu.
Pārbaudi karti ar reāliem scenārijiem
Pirms tehniskā darba sākšanas izspēlē procesu kopā ar tā dalībniekiem. Izmanto parastu gadījumu, steidzamu gadījumu, nepilnīgus datus un vismaz dažus nozīmīgākos izņēmumus. Pie katra soļa pārbaudi, vai ir zināma ievade, atbildīgais, lēmuma noteikums un nākamais stāvoklis.
Kartes validācijā jāiesaista ne tikai vadītājs. Darbinieki, kuri ikdienā veic darbu, zina faktiskos apiešanas ceļus un datu trūkumus. Savukārt IT vai izstrādes pārstāvis var pamanīt neskaidras sistēmu robežas, nepietiekamas piekļuves tiesības un darbības, kurām nav auditējama pierādījuma.
Noslēdz validāciju ar neatrisināto jautājumu sarakstu. Katram jautājumam vajadzīgs īpašnieks un lēmuma termiņš. Atvērts jautājums nav kļūda, ja tas ir redzams; bīstams ir slēpts pieņēmums, kas izstrādes laikā kļūst par prasību.
Kad process ir gatavs automatizācijas projektam
Process nav jāpadara ideāls, pirms drīkst sākt izstrādi. Tam jābūt pietiekami skaidram, stabilam un izmērāmam. Pirms nodošanas tehniskajai komandai pārbaudi:
- procesa robežas un rezultāts ir vienoti saprasti;
- pašreizējā plūsma ir apstiprināta ar reāliem gadījumiem;
- soļiem ir izpildītāji, ievades un rezultāti;
- lēmumu noteikumi ir formulēti pārbaudāmā veidā;
- būtiskajiem datiem ir zināmi avoti un kvalitātes prasības;
- svarīgākajiem izņēmumiem ir atbildīgais un drošs rezerves ceļš;
- ir noteikti sākuma rādītāji un sagaidāmais uzlabojums;
- ir skaidrs, kur paliek cilvēka apstiprinājums;
- piekļuves, personas datu un auditācijas prasības ir apzinātas;
- procesa īpašnieks pieņems gala risinājumu.
Pēc kartēšanas bieži kļūst redzams, ka dažus soļus var vienkārši izņemt, apvienot vai standartizēt. Tas ir vērtīgs rezultāts. Nav jēgas automatizēt darbību, kas procesam vairs nav vajadzīga.
Procesa karte ir vienošanās, nevis tikai diagramma
Laba procesa karte savieno biznesa vajadzību ar tehnisko realizāciju. Tā parāda ne tikai ideālo secību, bet arī atbildību, datu kustību, lēmumu pamatojumu un rīcību brīdī, kad gadījums neatbilst standartam.
Sāc ar procesa robežu un rezultātu. Tad dokumentē faktisko plūsmu vienādā detalizācijas līmenī, izcel nodošanas punktus, nosauc datu avotus un pārvērt neskaidrus lēmumus pārbaudāmos noteikumos. Izņēmumus neatstāj izstrādes beigām — tie bieži nosaka, vai risinājums būs lietojams ikdienā.
Kad šī vienošanās ir pārbaudīta ar reāliem scenārijiem, biznesa procesu automatizācija kļūst prognozējamāka. Tehniskā komanda zina, ko būvēt un testēt, bet procesa īpašnieks var novērtēt, vai gala rezultāts patiešām uzlabo darbu.
