Ako pomocou AI premeniť rozhovory na procesnú mapu a funkčné požiadavky

Profesia: Biznis analytik (19. profesia zo 100) Pracovný výstup: overená procesná mapa súčasného stavu a návrh funkčných požiadaviek s dohľadateľným pôvodom. Modelová situácia: firma chce zjednodušiť vybavovanie vráteného tovaru v e-shope.

Traja ľudia opisujú ten istý proces tromi spôsobmi

Pracovníčka zákazníckeho servisu tvrdí, že zákazník dostáva potvrdenie o prijatí vrátenia okamžite. Skladník vysvetľuje, že sa stav mení až po fyzickej kontrole balíka. Účtovníčka pod „prijatým vrátením“ rozumie až schválené vrátenie peňazí. Všetci používajú rovnaké slovo, no myslia tým odlišné udalosti. Ak biznis analytik prepíše prvý rozhovor do zadania bez overenia, nový systém môže nesprávne informovať zákazníka alebo vytvoriť účtovný problém.

AI umožňuje zo záznamov rozhovorov vyťažiť činnosti, aktérov, rozhodovacie body a návrhy požiadaviek. Zároveň dokáže odhaliť rozpory medzi výpoveďami. Zápis z rozhovoru však ešte nie je schválené procesné pravidlo. Dobrý analytik musí nejasnosti vrátiť kompetentným ľuďom a pri každej požiadavke vedieť ukázať jej zdroj.

Začnite otázkami, ktoré sledujú konkrétny prípad

Na rozhovor pozvite zástupcov zákazníckeho servisu, skladu a financií. Namiesto abstraktného „Ako fungujú vratky?“ ich požiadajte, aby na anonymnom príklade opísali cestu jednej zásielky. Zistite spúšťaciu udalosť, kto vykonáva jednotlivé kroky, na základe akého dokladu, v ktorom systéme a kedy sa prípad považuje za dokončený. Samostatne prejdite výnimky: chýbajúce číslo objednávky, neúplnú zásielku, sporný stav výrobku a nesúlad vo výške refundácie.

Pred nahrávaním rozhovorov určite právny základ, účel, rozsah, dobu uchovávania a informovanie dotknutých osôb. Ak je to možné, použite schválené anonymizované poznámky namiesto zvukových záznamov. Z interných podkladov odstráňte zákaznícke mená, adresy a platobné údaje; prístup k pracovnému materiálu obmedzte podľa interných pravidiel. EDPB pripomína zásady minimalizácie, presnosti a dôvernosti osobných údajov.

Každému výroku v zápise dajte identifikátor zdroja, napríklad SERV-03, SKL-07 a FIN-04. Nezáleží na tom, či používaný nástroj podporuje automatický prepis; aj ten treba skontrolovať. Nesprávne zachytená negácia „neschvaľujeme“ môže otočiť obchodné pravidlo na pravý opak.

Prvý prompt: z rozhovorov vytiahnite udalosti

Prompt 1 – extrakcia procesu a rozporov

Si asistent biznis analytika. Spracuj tri anonymizované
zápisy rozhovorov a priložené platné interné pravidlá.

Vytvor tabuľku:
ID kroku | Spúšťač | Rola | Činnosť | Vstup | Výstup |
Systém | Rozhodnutie alebo výnimka | Zdroj výroku.

Zvlášť vypíš:
- rovnaké pojmy používané s odlišným významom;
- rozpory medzi rozhovormi;
- chýbajúce rozhodovacie pravidlá;
- kroky bez jednoznačného vlastníka;
- tvrdenia, ktoré nie sú potvrdené dokumentom.

Nevymýšľaj procesné pravidlá. Každú neistotu označ
NA POTVRDENIE. Nenavrhuj automatickú refundáciu.

Výstup si prejdite s jednotlivými účastníkmi. Niekedy zdanlivý rozpor vznikne len tým, že jeden človek opisuje bežnú vratku a druhý reklamáciu. Tieto prípady sa nemajú bez ďalšieho zlúčiť do jednej procesnej vetvy.

Vytvorte čitateľnú mapu súčasného stavu

Pre modelový proces možno po potvrdení faktov zostaviť jednoduchý sled:

1. Zákaznícky servis: zaeviduje požiadavku a priradí identifikátor prípadu.
2. Zákazník: odošle zásielku podľa potvrdených pokynov.
3. Sklad: zaznamená fyzické doručenie a vykoná schválenú kontrolu obsahu.
4. Zodpovedná rola: podľa interných pravidiel rozhodne o výsledku posúdenia.
5. Finančné oddelenie: spracuje schválený finančný krok.
6. Zákaznícky servis alebo systém: odošle správu o aktuálnom, presne pomenovanom stave prípadu.

V takejto mape musí byť viditeľné, že zaevidovanie vratky nie je to isté ako schválenie refundácie. Nevyjasnené rozhodovacie pravidlo ponechajte ako otvorený bod. Nepresúvajte kompetenciu z financií na zákaznícky servis len preto, že by mapa vyzerala jednoduchšie.

Ak chce tím používať BPMN, nech AI vytvorí iba koncept aktérov, aktivít, udalostí a brán. Súlad s notáciou BPMN 2.0.2 overí analytik v príslušnom modelovacom nástroji; textový diagram s krabicami sám osebe nie je BPMN model. Pri prvom stretnutí býva praktickejšia jednoduchá mapa podľa rolí než komplikovaný diagram s desiatkami symbolov.

Od mapy prejdite k funkčným požiadavkám

Funkčná požiadavka hovorí, čo má systém robiť. Nezamieňajte ju s technickým riešením, napríklad s pokynom použiť konkrétnu databázu alebo programovací jazyk. Najprv potrebujete dohodnuté pracovné pravidlo, až potom návrh implementácie.

Z tabuľky zatiaľ nemožno vyhlásiť, kto má právo schvaľovať refundáciu ani aký časový limit sa na to vzťahuje. Právne povinnosti pri odstúpení od zmluvy je potrebné riešiť osobitne podľa platných pravidiel a obchodného modelu e-shopu, nie doplniť odhadom jazykového modelu.

Prompt 2 – návrh požiadaviek a kontrola pôvodu

Z potvrdenej procesnej mapy priprav návrh funkčných
požiadaviek FR-01, FR-02 atď.

Pri každej uveď:
- používateľskú rolu a spúšťač;
- presne pozorovateľné správanie systému;
- vstup a očakávaný výstup;
- obmedzenia a výnimočné stavy;
- ID rozhovoru alebo schváleného pravidla;
- otvorené otázky a osobu, ktorá ich má rozhodnúť.

Nedopĺňaj neoverené zákonné lehoty ani kompetencie.
Z návrhu nevyhlasuj schválenú špecifikáciu.

Pošlite mapu späť tým, ktorí podľa nej pracujú

IIBA považuje potvrdenie získaných informácií za samostatnú úlohu biznis analýzy. Urobte spoločné krátke stretnutie, na ktorom účastníci prejdú dve bežné vratky a jednu výnimku. Požiadajte ich, aby pri každom kroku povedali, kto má konať a aký doklad to umožňuje. Ak procesná mapa nevie spracovať neúplnú zásielku alebo zamietnutý návrh refundácie, ešte nie je pripravená na schválenie.

Až potom prejdite k akceptačným kritériám a testovacím prípadom. Pri FR-02 môže byť kontrolovateľný výsledok: po potvrdení prijatia zásielky sa k správnemu prípadu uloží udalosť s časom a oprávnenou rolou; pri nesprávnom ID sa zmena nevykoná a používateľ dostane zrozumiteľné upozornenie. Takto sa rozhovor mení na niečo, čo bude možné pri dodaní softvéru naozaj skontrolovať.

Váš konečný balík nemá byť len obrázok. Odovzdajte procesnú mapu súčasného stavu, zoznam rozporov, register otvorených rozhodnutí a funkčné požiadavky so zdrojmi. AI uľahčí prvé spracovanie, ale výslednú pravdivosť procesu potvrdzujú ľudia, ktorí zaň nesú zodpovednosť.

Odborné zdroje

• IIBA, The Business Analysis Standard – Elicitation and Collaboration: https://www.iiba.org/knowledgehub/the-business-analysis-standard/5-applying-business-analysis-tasks/5-3-business-analysis-knowledge-areas/elicitation-and-collaboration/
• IIBA, Introducing Business Analysis Tasks: https://www.iiba.org/knowledgehub/business-analysis-standard/4-tasks-and-knowledge-areas/introducing-business-analysis-tasks/
• OMG, Business Process Model and Notation (BPMN) 2.0.2: https://www.omg.org/spec/BPMN/2.0.2
• European Data Protection Board, Basic principles: https://www.edpb.europa.eu/topics/key-gdpr-concepts/basic-principles_en

Firma, rozhovory, označenia a požiadavky sú modelové. Zdroje overené 23. 10. 2026.