Ako zmapovať firemné procesy pred vývojom systému

Čo potrebujete predtým, než začnete mapovať firemné procesy?

Pred mapovaním procesov nepotrebujete drahý softvér, ale jasný cieľ, jedného vlastníka, vybraný proces, prístup k reálnym podkladom a nástroj na vizualizáciu. Ak tieto vstupy chýbajú, tím sa rýchlo opiera o domnienky a výsledkom je diagram, ktorý sa pri vývoji systému nedá použiť.

Pripravte si najmä tieto vstupy:

• Biznis cieľ: čo má nový systém zmeniť, napríklad skrátiť čas spracovania objednávky, znížiť prepisovanie dát alebo odstrániť schvaľovanie cez e-mail.
• Vlastníka procesu: osobu, ktorá vie rozhodnúť, čo je správne a čo už správne nie je.
• Rozsah mapovania: jeden proces alebo jednu procesnú líniu, nie celú firmu naraz.
• Účastníkov: ľudí, ktorí proces reálne vykonávajú, nielen manažérov.
• Podklady: formuláre, e-maily, Excel súbory, exporty zo systému, šablóny dokumentov, interné smernice a aspoň niekoľko reálnych prípadov.
• Nástroj na kreslenie a poznámky: Miro, Lucidchart, Draw.io, Bizagi Modeler, prípadne jednoduchý whiteboard a následný prepis.
• Miesto na požiadavky: Jira, Confluence, ClickUp alebo Notion, aby sa poznámky nestratili medzi zápisnicami.
• Časový rozpočet: pri jednom procese počítajte minimálne s prípravou, 1 až 2 workshopmi a jedným validačným kolom.

Ak riešite aj rozpočet, nesledujte iba cenu budúceho systému. Nákladom je aj interný čas ľudí, dostupnosť podkladov a počet výnimiek, ktoré treba zachytiť. Externé náklady sa potom odvíjajú od počtu procesov, zapojených oddelení, existujúcich systémov a hĺbky dokumentácie.

Ako určíte cieľ, rozsah a hranice mapovania?

Dobré mapovanie sa začína presným pomenovaním toho, čo riešite, kde proces začína, kde končí a čo do analýzy zámerne nepatrí. Bez tejto hranice vzniká nekonečný workshop, kde sa mieša obchod, logistika, účtovníctvo aj vývoj a výsledok nie je jednoznačný.

Postupujte takto:

1. Pomenujte výsledok v jednej vete. Napríklad: „Chceme navrhnúť systém pre spracovanie dopytu od prijatia po odovzdanie obchodníkovi.“
2. Určite spúšťač a koniec procesu. Spúšťač môže byť prijatý formulár, e-mail alebo objednávka. Koniec musí byť rovnako konkrétny, napríklad odoslaná cenová ponuka alebo uzavretý prípad.
3. Vymenujte roly, nie mená. Obchodník, back office, schvaľovateľ, účtovník, skladník, zákazník. Mapa potom zostane použiteľná aj pri personálnych zmenách.
4. Zapíšte, čo je mimo rozsahu. Ak teraz riešite prijatie a spracovanie dopytu, reklamácie alebo HR onboarding do tej istej mapy nepatria.
5. Zvoľte priority. Začnite procesom, ktorý je častý, bolestivý alebo finančne citlivý.

Pri definovaní rozsahu si hneď pripravte miesto aj pre vstupy, výstupy, systémy, zodpovednosti a metriky procesu. Práve tieto polia používa pri procesnom mapovaní aj metodika Ministerstvo vnútra SR. Hranice procesu sú preto praktický filter: čo patrí do návrhu systému a čo je zatiaľ mimo neho.

Ako zozbierate dáta o procese tak, aby ste zachytili realitu?

Ak chcete mapu, ktorá odhalí slabé miesta, nestačí sa opýtať vedenia, ako by proces mal fungovať. Potrebujete vidieť jeho dnešný priebeh na konkrétnych prípadoch, s reálnymi dokumentmi, výnimkami a čakaním medzi krokmi. Až potom určíte, čo má nový systém riešiť.

Použite kombináciu viacerých zdrojov:

1. Rozhovory s vykonávateľmi procesu. Pýtajte sa, čo presne robia, podľa čoho sa rozhodujú, čo kontrolujú ručne a kde musia údaje prepisovať.
2. Workshop naprieč rolami. Práve tam sa ukáže, čo jedna rola považuje za hotové a čo druhá ešte vôbec nedostala.
3. Shadowing alebo priame pozorovanie. Sledujte aspoň niekoľko reálnych priebehov procesu. Ľudia často vynechajú kroky, ktoré berú ako samozrejmosť.
4. Vzorky dokumentov a dát. Zoberte 3 až 5 reálnych prípadov: štandardný, urgentný, neúplný, zamietnutý a opravený. Práve na nich sa lámu pravidlá systému.
5. Exporty a logy zo súčasných nástrojov. Aj jednoduchý CSV export vie ukázať, kde sa hromadia čakajúce prípady alebo koľko polí zostáva nevyplnených.

Pri každom kroku zapisujte aj tieto otázky: kto ho robí, v akom nástroji, s akými vstupmi, čo je výstup, čo sa kontroluje, čo sa schvaľuje, čo sa stane pri chybe a ako dlho sa na krok čaká. Ak toto nevidíte, zatiaľ nemapujete proces, ale iba názor na proces.

Ako nakreslíte mapu súčasného stavu AS-IS, ktorej rozumie aj vývoj?

Mapa AS-IS má ukázať, ako proces funguje dnes, nie ako má vyzerať po digitalizácii. Dobrá mapa je čitateľná pre biznis aj IT, zachytáva poradie krokov, rozhodnutia, roly, systémy, výnimky a miesta, kde sa čaká alebo prepisujú dáta.

Pri kreslení sa držte tohto postupu:

1. Začnite jedným procesom na jednej ploche. Nespájajte do jednej schémy celý podnikový svet.
2. Rozdeľte mapu podľa rolí. Swimlanes rýchlo ukážu, kde sa práca presúva medzi ľuďmi alebo oddeleniami.
3. Ku každému kroku doplňte päť vecí: spúšťač, činnosť, rozhodnutie, systém alebo nástroj a výsledok kroku.
4. Označte miesta prepisovania dát. Typicky e-mail do Excelu, Excel do CRM, CRM do fakturácie.
5. Zachyťte výnimky. Neúplné podklady, duplicitný záznam, zmena ceny, chýbajúce schválenie, storno, oprava.
6. Pridajte poznámky k času a objemu. Aj orientačné údaje pomôžu určiť priority automatizácie.

Na pracovný workshop často stačí jednoduchý flowchart. Ak však má mapa slúžiť aj analytikovi, integrátorovi a vývojovému tímu, pri detailnejšej verzii sa oplatí siahnuť po Object Management Group, ktorá vedie BPMN 2.0 ako formálnu verziu špecifikácie od decembra 2010.

Cieľom nie je vytvoriť akademický diagram, ale spoločnú verziu reality. Keď sa niekto pozrie na mapu, musí bez vysvetľovania pochopiť, kto čo robí, s akými dátami, v ktorom bode vzniká rozhodnutie a kde sa proces zasekáva. Toto je hodnota dobrej AS-IS mapy pre vývoj.

Ako z mapy vytvoríte návrh budúceho stavu TO-BE a zadanie pre systém?

Mapa TO-BE vzniká až vtedy, keď rozumiete súčasnému stavu a viete pomenovať zbytočné kroky, slabé miesta a pravidlá. Jej úlohou nie je prekresliť chaos do modernejšieho diagramu, ale navrhnúť jednoduchší spôsob práce, z ktorého možno odvodiť zadanie pre nový systém.

Postup je praktický:

1. Odstráňte zbytočné kroky ešte pred automatizáciou. Ak sa niečo kontroluje dvakrát bez dôvodu alebo sa dokument posúva medzi ľuďmi len kvôli zvyku, nezabudujte to do systému.
2. Rozhodnite, čo robí človek a čo systém. Systém môže vytvárať úlohy, strážiť termíny, validovať polia, posielať notifikácie a spúšťať workflow. Človek nech rieši rozhodnutia, výnimky a zodpovednosť.
3. Spíšte dátový model procesu. Aké záznamy vznikajú, aké polia musia obsahovať, čo je povinné, čo sa dedí a čo sa mení podľa stavu prípadu.
4. Definujte pravidlá a oprávnenia. Kto môže záznam založiť, upraviť, schváliť, stornovať, vidieť históriu alebo exportovať dáta.
5. Vypíšte integračné body. Účtovníctvo, sklad, e-mail, formuláre, ERP, podpisovanie dokumentov, reporty.
6. Rozdeľte požiadavky na MVP a ďalšie fázy. Najprv riešte jadro procesu, nie všetky výnimky sveta.

Presne tu sa rozhoduje, či firme stačí úprava existujúceho nástroja, alebo potrebuje CRM na mieru či interný systém postavený podľa vlastného workflow. Výstupom tejto fázy nemá byť zoznam prianí, ale TO-BE návrh obrazoviek, stavov, pravidiel, notifikácií, integrácií a metrík, podľa ktorých sa bude riešenie hodnotiť po spustení.

Ako mapu overíte s ľuďmi a premeníte ju na backlog pre vývoj?

Poslednou dôležitou fázou je validácia mapy a jej preklad do jazyka vývoja. Ak tento krok preskočíte, vznikne procesná dokumentácia, ale nie zadanie, podľa ktorého vie tím navrhnúť architektúru, odhadnúť prácnosť a rozumne rozdeliť vývoj na etapy.

Urobte to v piatich krokoch:

1. Prejdite mapu s ľuďmi z praxe krok po kroku. Nech potvrdia, že sedí bežný priebeh aj výnimky.
2. Dajte technickú revíziu. Vývoj alebo architekt potrebuje vidieť roly, stavy, dátové entity, integračné body, notifikácie, audit a reportovanie.
3. Rozdeľte proces na epiky a menšie požiadavky. Napríklad prijatie prípadu, spracovanie, schvaľovanie, notifikácie, reporting.
4. Každú požiadavku doplňte o akceptačné kritériá. Kedy je hotová, čo sa musí stať, čo sa nesmie stať a aké dáta musia ostať uložené.
5. Schváľte baseline. Jedna verzia procesu, jedna verzia priorít, jeden zoznam otvorených otázok.

User stories zapisujte z pohľadu používateľa, nie z pohľadu databázy. Atlassian ich popisuje ako stručný opis potreby z perspektívy koncového používateľa, čo je presne forma, s ktorou vie vývojový tím ďalej pracovať.

V tejto chvíli už viete robiť aj lepšie technologické rozhodnutia, pretože architektúra sa nevyberá podľa trendu, ale podľa reálnych procesov, dát a očakávaného rastu. Dobrý MVP backlog preto nie je len zoznam funkcií, ale most medzi mapou procesu, odhadom prácnosti a fázovaním vývoja.

Aké sú najčastejšie chyby pri mapovaní procesov pred vývojom systému?

Najčastejšie zlyhania nevznikajú pri kreslení diagramu, ale pri zlom zábere, chýbajúcich výnimkách a príliš rýchlom prechode do riešenia. Ak sa im vyhnete, mapa procesov sa zmení z internej dokumentácie na reálne použiteľné zadanie pre vývoj.

Najčastejšie chyby a prevencia:

• Mapujete ideálny stav namiesto reality. Pýtajte sa, čo sa deje dnes, nie čo by sa malo diať.
• Beriete príliš široký rozsah. Začnite jedným procesom alebo jednou procesnou líniou.
• Hovoríte len s manažérmi. Do mapovania musia vstúpiť aj ľudia, ktorí prácu reálne vykonávajú.
• Ignorujete výnimky. Práve výnimky často rozhodujú o tom, či systém bude použiteľný.
• Neriešite dáta a pravidlá. Bez polí, stavov, oprávnení a integrácií nevznikne kvalitné zadanie.
• Automatizujete chaos. Najprv zjednodušte postup, až potom ho digitalizujte.
• Nemáte schváleného vlastníka procesu. Bez rozhodovateľa sa mapa po workshope rozpadne na protichodné názory.

Pravidlo je jednoduché: ak sa z mapy nedá odvodiť, kto čo robí, s akými dátami, v akom systéme a podľa akého pravidla, ešte nie je pripravená na vývoj. Presne tu sa odlišuje procesná dokumentácia od zadania, podľa ktorého sa dá systém navrhnúť a naceniť.

Kedy už má zmysel prizvať partnera na analýzu a návrh riešenia?

Externý partner dáva zmysel vtedy, keď proces prechádza viacerými oddeleniami, používa viac systémov, obsahuje veľa schvaľovaní a výnimiek alebo keď z mapovania má priamo vzniknúť zadanie pre CRM, interný systém či automatizáciu. Vtedy už nejde len o workshop, ale o architektúru, priority a merateľný plán implementácie.

Typické signály, že DIY prístup nestačí:

• proces sa láme medzi obchodom, prevádzkou, financiami a manažmentom,
• dáta sa prepisujú medzi viacerými nástrojmi,
• tím sa nevie zhodnúť na jednom správnom postupe,
• potrebujete riešiť roly, práva, integrácie, audit a reporting,
• výsledkom má byť podklad pre custom vývoj, nie len interná smernica.

Dobrý partner neprinesie iba diagram. Má dodať AS-IS mapu, návrh TO-BE stavu, priority, dátové a integračné požiadavky, MVP backlog a odporúčanie, čo má význam riešiť vo fáze 1 a čo neskôr. Presne takto sa dá pripraviť aj vývoj CRM systému alebo iného riešenia na mieru tak, aby systém kopíroval reálnu prevádzku, nie domnienky.

Ak chcete prejsť od mapovania k návrhu riešenia, môžete prejsť procesy s tímom BeCode, v ktorom staviame softvér okolo reálnych firemných workflow, dát a merateľných výsledkov.

Časté otázky

Potrebujete BPMN 2.0, alebo Vám stačí jednoduchý flowchart?

Na prvé workshopy väčšine firiem stačí jednoduchý flowchart, ak je jasné poradie krokov, roly, rozhodnutia a výnimky. BPMN 2.0 má zmysel vtedy, keď má mapa slúžiť aj analytikovi, integrátorovi a vývojárom ako presnejší podklad pre návrh systému a workflow.

Ako môže vyzerať rozpad procesu na konkrétnom príklade, napríklad pri schvaľovaní faktúr?

Pri schvaľovaní faktúr môže rozpad vyzerať takto: prijatie faktúry, kontrola povinných údajov, priradenie strediska, kontrola rozpočtu, schválenie zodpovednou rolou, odoslanie do účtovníctva, zaúčtovanie a archivácia. Do mapy však patria aj výnimky, napríklad chýbajúci podklad, nesúlad sumy alebo zamietnutie.

Čo má byť minimálnym výstupom mapovania pred začiatkom vývoja?

Minimum sú štyri veci: schválená AS-IS mapa, návrh TO-BE stavu, zoznam rolí a pravidiel a prioritizované požiadavky pre MVP. Ak tieto výstupy chýbajú, vývoj začne skôr podľa predpokladov než podľa reálneho fungovania firmy, čo komplikuje architektúru, odhad aj priority.