Digitální firma X(DFX) Případová studie pro výuku předmětu Digitální firma Autoři: Ing. Dalibor Šimek, Ing. Jiří Krutina, Ing. David Pochobradský; Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 1 Otázky Co je digitalizace? Digitalizace v tom nejobecnějším slova smyslu je jednoduše proces transformace informací do digitálního (tj. počítačem čitelného) formátu, ve kterém jsou informace uspořádány do bitů. Výsledkem je reprezentace objektu, obrazu, zvuku, dokumentu nebo signálu, ale obecně jakýchkoliv datových abstrakcí (procesů, smluv, objednávek, stížností, faktur, zákazníků, dodavatelů atd.) v podobě binárních čísel či jiných digitálních abstrakcí, která usnadňují další počítačové zpracování a další operace. V nejjednodušší podobě digitalizace znamená konverzi analogového materiálu na číselný formát. V dnešní době IT podnikání jde o pojem spojený obecně s digitalizací obchodních informací, obchodních procesů, výrobních procesů a obecně přístup, ve kterém se vše fyzicky existující (smlouvy, objednávky, faktury, účtenky, smlouvy) převádí do elektronických reprezentací a s jako takovými se s nimi dále pracuje v implementovaných procesech, které umožňují kvalitnější řízení, sdílení, delegace a transparentní vynucování obchodních pravidel firmy. Zaměření digitalizace procesů není na „automatizaci“, aby byl proces obhospodařován sám, ale spíše k řízení procesu. Co je proces (work-flow)? Proces je pojem pro postupný různě větvený tok dějů, stavů, aktivit nebo akcí spuštěný určitou událostí. Vykonávání procesu obecně spotřebovává či zpracovává nějaké zdroje a transformuje vstupy na očekávané výstupy. Reálně běžící proces, jeho instance, má vždy i časový rozměr. Obchodní proces je tedy primárně posloupnost = tok aktivit, akcí, vykonávaných buď automatizovaně stroji, nebo lidmi, kteří transformují vstupy na výstupy a během toho spotřebovávají čas a potřebné zdroje. V souvislosti s automatizací procesů se používá anglický pojem “work-flow”. Jde o digitalizovanou posloupnost kroků, během které se posouvají data nebo dokumenty od jednoho člověka k druhému. Jde podstatně o tok aktivit nebo dokumentů libovolného firemního procesu. Zjednodušeně lze říci, že workflow je samotný digitalizovaný firemní proces. Proces se může odehrávat buď v podobě předávání papírových dokumentů a fyzického kontaktu lidí nebo i jako tok digitálních entit či dokumentů. Workflow řešení či systémy se uplatňují zejména při potřebě zpracování různých požadavků vícero lidmi – je při něm tedy důležité znát konkrétní lidi, kteří rozhodují či vykonávají konkrétní kroky v rámci zpracování požadavku. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 2 K tomu je potřeba mít stanovené kompetence a jednotlivé role účastníků procesu. Vzhledem k tomu jsou workflow procesy typicky takové procesy, které se opakují v každodenním provozu firmy a jejich průběh je jasně daný – ví se, jaké má kroky, co se musí splnit, co musí proběhnout, tedy co skrz proces protéká, kde jsou rozhodovací či schvalovací místa a kdo v těchto místech schvaluje či vykonává. Příkladem takových workflow jsou například procesy zpracování faktur, smluv, objednávek, schvalování žádostí o dovolenou, evidence zaměstnanců, jejich pracovních náplní, správa účtenek a podobně. Workflow má definovaná pravidla, která umožňují předávat dokument nebo data mezi pracovníky k dalšímu zpracování nebo ke schválení. Příklad Zpracování faktur ve firmě Synergine: Kontext: 1. Projektů firmy Synergine se účastní různí subdodavatelé, fyzické osoby (OSVČ), kteří pravidelně po dokončení svých prací vydávají faktury k proplacení svých projektových aktivit. 2. K vedení účetnictví využívá společnost externí účetní a účetnictví je vedeno v externím účetním systému 3. Vedení firmy potřebuje mít přehled o fakturaci v rámci jednotlivých projektů a zároveň přehled, které faktury byly proplaceny. 4. Firma Synergine chce poskytovat službu svým dodavatelům, aby měli přehled o stavu proplacení jejich faktur. Proces: 1. Dodavatel firmy Synergine vytvoří fakturu za své práce a vloží ji do systému pro zpracování faktur (či odešle e-mailem na e-mailovou adresu, ze které je faktura do systému načtena). Každá položka faktury je vázána ke konkrétnímu projektu. Spouštěcí událost procesu: Přijetí faktury od dodavatele Vstup: Faktura dodavatele 2. Systém zpracování faktur přiřadí fakturu schvalovatelům dle položek faktury (projektoví manažeři). 3. Projektoví manažeři schválí své položky faktury a tím i celou fakturu. Systém přiřadí fakturu účetní k zaúčtování. 4. Účetní fakturu zaúčtuje, tedy přenese do externího účetního systému a zajistí její proplacení ať už v celku či po částech. Systém zpracování faktur informuje dodavatele o provedené platbě. Ukončující událost: Proplacení faktury Výstup: Odeslání/předání peněz dodavateli Příjemce/Zákazník procesu: Dodavatel Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 3 Co je procesní architektura? Procesní architektura strukturuje souhrn procesů, lze typicky sbírat informace formou souboru v MS Excel, kde se identifikují významné procesy firmy – někdy se používá rozdělení na řídicí, hlavní a podpůrné. Podstatné je určit především ohraničení každého procesu, kdy u každého procesu lze identifikovat: • Spouštěcí událost (Zpráva, Časová, Změnová) • Vstupní informace či materiál • Ukončující událost (Zpráva, Časová, Změnová) • Výstupní informace či materiál • Zákazníka (Interní / Externí) Typický příklad událostí: • Zpráva – přijetí objednávky • Časová – jednou denně na konci směny je potřeba zkontrolovat přístroje na pracovišti • Změnová – dojde k poklesu stavu zásob materiálu na skladě pod určitou stanovenou úroveň Cvičení 1. Identifikace procesů Zadání: Identifikujte u procesů z úvodního příběhu (uzavírání smluv s dodavateli a zpracování objednávek) základní parametry těchto procesů: • Spouštěcí událost (Zpráva, Časová, Změnová) • Vstupní informace či materiál • Ukončující událost (Zpráva, Časová, Změnová) • Výstupní informace či materiál • Zákazníka (Interní / Externí) Řešení: Uzavírání smluv s dodavateli • Spouštěcí událost: Přijetí požadavku k uzavření smlouvy s dodavatelem; širší podnikatelský proces: Zjištění zákazníkovy potřeby či poptávky (proces objednávek), na kterou nemáme dodavatele, nebo obdržení výhodné nabídky od nového dodavatele (proces zpracování nabídek) • Vstupní informace či materiál: Požadavky k vypracování smlouvy – jaký dodavatel, jaké zboží atd. • Ukončující událost: Uzavření smlouvy s dodavatelem • Výstupní informace či materiál: Smlouva • Zákazník (Interní / Externí): (Interní) Proces zpracování objednávek Proces zpracování objednávek: • Spouštěcí událost: Přijetí objednávky (telefonicky, e-mailem, osobně, poštou) Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 4 • Vstupní informace či materiál: Objednávka (objednávané zboží a množství) • Ukončující událost: Dodání zboží zákazníkovi • Výstupní informace či materiál: Zboží, dodací list • Zákazník (Interní / Externí): (Externí) Zákazník (korporát) Analytická fáze sběru a specifikace požadavků Úvod Je potřeba zdůraznit, že na každém projektu digitalizace a obecně vývoje SW řešení je kriticky důležitá fáze identifikace, sběru, analýzy a specifikace POŽADAVKŮ na řešení. Nedostatečná analýza požadavků je obecně nejčastější příčinou komplikací v dodávání sw řešení i procesech digitalizace. Fázi sběru, analýzy a specifikace POŽADAVKŮ nelze přeskočit nebo vynechat ani v případě projektů digitalizace s využitím procesních platforem. Tvoří most překladu strategických cílů do jejich implementace. Otázkou je vždy pouze míra zvolení dostatečné formalizace této fáze. Procesní přístup Abychom mohli inženýrsky řízeným způsobem přistoupit k potřebným změnám ve firmě, tedy k digitalizaci, je potřeba se podívat na firmu z procesního pohledu, identifikovat její hranice, vnější a vnitřní prostor, jednotlivé hráče a komunikační či informační toky mezi nimi v celém obchodním modelu firmy. To nám obrazně i doslova připraví “hřiště” pro další koncepční analytickou práci sběrů a specifikace požadavků. Základní přístup spočívá v těchto krocích: 1. vymezení hranic firmy a jejího vnitřního a vnějšího prostředí. 2. identifikace vnějších aktérů, s kterými firma komunikuje. 3. identifikace hlavních obchodních procesů zajišťující samotné podnikání firmy. 4. identifikace komunikačních toků či povahy vztahů s vnějšími aktéry. Typickým výstupem je artefakt, který se nazývá koncepční či kontextový model. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 5 Cvičení 2. Identifikace kontextového modelu obchodních požadavků Zadání: “Na základě analýzy textu úvodního příběhu případové studie (viz Případová studie – úvodní příběh), podle výše uvedeného postupu identifikujte hranice firmy, její vnější a vnitřní prostor a identifikujte hlavní obchodní procesy pro digitalizaci. Vymezte základní hřiště pro analýzu řešení.” Příklad: Společně se studenty lze vytvořit skicu jednoduchého konceptuálního modelu například na tabuli a společně diskutovat o možnostech a smyslu této koncepční fáze. Pochopení a um: Student si uvědomí způsob nazírání firmy z procesního pohledu s tím, že je schopen identifikovat základní podklad pro následnou analýzu požadavků a návrh řešení. Pochopení, že pro úspěšné vedení projektů digitalizace je nutné projekt ukotvit na základě výchozího konceptuální rámce, který stanovuje rozsah řešení. Konceptuální model firmy DFX Poskytuje pohled na celou firmu DFX z pohledu vymezení vnějšího a vnitřního prostoru a toho, co tyto prostory spojuje, tedy hlavní procesy a povahu komunikačních toků. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 6 Získávání, analýza a specifikace požadavků na řešení V předchozím kroku, ve kterém jsme si vymezili celkové “hřiště”, vnitřní a vnější prostory firmy, aktéry a hlavní obchodní procesy, můžeme přistoupit k dalšímu kroku a to sběru, analýze a specifikaci, tedy dokumentaci požadavků, které mají být implementovány v procesním řešení. POŽADAVKY z pohledu úrovně, kterou specifikují, rozlišujeme na: • Obchodní, “high-level” strategické požadavky na úrovni celkového procesního pohledu vymezující prostor další analýzy požadavků – viz konceptuální model výše, tvoří ukotvení celého procesu sběru a analýzy požadavků; Jsou zachycené většinou v jednoduchém procesním modelu. • Uživatelské požadavky z pohledu uživatelů řešení, tedy z pohledu chování, jak se jeví uživatelům, typicky model případů užití, či scénářů použití (UML Use Case model) či uživatelských příběhů (textový popis interakce se systémem); • Funkční, lépe snad požadavky na chování a funkcionalitu, které zajišťují realizaci identifikovaných případů použití, typicky je lze zachytit pomocí UML diagramu aktivit (work-flow) modelem a textovou specifikací uplatňovaných obchodních pravidel. • Datové, požadavky na datové entity a jejich atributy, které jsou potřebné pro datové abstrakce řešení, typicky zachycené jako Class či Entity-Relationship Diagram (ERD); • Kvalitativní, k dosažení splnění všech očekávání klienta nestačí jenom implementace požadované funkcionality a chování systému. Součástí je i to, jak dobře se se systémem pracuje, tedy stručně kvalita sw řešení. Požadavky spojené s kvalitou tvoří důležitou část specifikace požadavků, které ovlivňují zejména návrh celkové architektury řešení a zvolené návrhové vzory k implementaci řešení. Někdy jsou zvané “nefunkčními” požadavky, což v češtině nedává smysl. Jde o všechny ostatní požadavky z pohledu požadovaných charakteristik (dostupnost, bezpečnost, přívětivost, výkonnost, škálovatelnost, ověřitelnost atd.) Jsou typicky zachycené v textové podobě. Více informací ke kvalitativním požadavkům je k dispozici v příloze "Přehled kvalitativních požadavků IS". Obchodní požadavky V souladu se svými dalšími stanovenými strategickými cíli a vizí se vedení společnosti DFX rozhodlo své dva stávající obchodní procesy transformovat v plně transparentní digitální procesy bez potřeby oběhu papírových dokumentů. Jde o dva základní obchodní procesy: • Uzavírání smluv s dodavateli • Vyřizování nákupních objednávek Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 7 Proces Uzavírání smluv s dodavateli – základní scénář Smlouvy s dodavateli jsou nejprve formálně kontrolovány (u každé smlouvy musí být dodrženo pravidlo kontroly min. čtyř očí) a následně schvalovány a podepisovány kompetentními lidmi na zvláštním oddělení firmy. Schvalování smluv je dvoustupňové podle výše celkové částky. V případě částek nad 10 000,-, je nutné schválení od výkonné rady firmy. Schválené smlouvy jsou poté zasílány k dodavatelům k podpisu a následně archivovány. Je dobrou praxí firmy, že noví dodavatelé jsou zahrnutí do procesu vyřizování objednávek až po podepsání schválené smlouvy, aby byla zajištěna transparentnost v cenách zboží pro zákazníky. Současně firma sleduje jednotlivé smlouvy s ohledem na jejich platnost. Stávající dobíhající smlouvy tak lze buď opět prodloužit a případně upravit, nebo zkrátka nechat vypršet. Proces vyřizování nákupních objednávek – základní scénář Nákup, ať už schválených nebo neschválených kancelářských potřeb, je realizován prostřednictvím nákupních objednávek. Objednávka může být vyřízena pouze v případě již zavedených a schválených dodavatelů a může obsahovat pouze zboží uvedené ve smlouvě. V případě objednávky s částkou vyšší než 5 000,-, je nutné její prvotní schválení. (obchodní pravidlo definováno kurzívou). Cvičení 3. Základní procesní schéma Zadání: Na základě textového popisu identifikovaných procesů zachyťte a navrhněte základní procesní schéma (základní koncept obou procesů) ve formě textového popisu kroků s určením rolí, kdo je za který krok zodpovědný a s ohraničením, čím je proces spouštěn a čím ukončován. Příklad – Workflow Schvalování smluv s dodavateli • Kroky k vytvoření, ověření a schválení jednotlivých smluv s dodavateli má na starost autorizovaný uživatel (REQUESTOR), který přímo pracuje s fyzickými podobami smluv a zadává je do procesu. Zadavatel smluv by měl mít možnost kdykoliv rozpracovanou smlouvu pouze uložit a vrátit se k ní případně později, bez ztráty již zadaných dat. • Kompletně připravená smlouva po uložení zadavatelem bude následně postoupena k formálnímu ověření příslušné odpovědné osobě (SCHVALOVATEL). V případě specifických druhů zboží může být požadován ještě následný ověřovací krok. Zboží, kterého se to týká a osoba určená k ověření, je definováno na úrovni MASTER DAT. • V každém kroku procesu je oprávněnému uživateli umožněno postoupit smlouvu do dalšího kroku procesu, případně ji vrátit zpět na začátek procesu odpovědnému zadavateli smlouvy (REQUESTOR). Když uživatel odmítne postoupit smlouvu do dalšího kroku v procesu, má mít možnost připojit textovou poznámku s uvedením důvodu vrácení smlouvy. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 8 Příklad – Workflow vyřizování nákupních objednávek • Nákup, ať už schválených nebo neschválených kancelářských potřeb, je realizován prostřednictvím nákupních objednávek. Objednávka může být vyřízena pouze v případě již zavedených a schválených dodavatelů a může obsahovat pouze uvedené seznamy věcí. • V případě objednávky s částkou vyšší než 10 000,-, je nutné její prvotní schválení. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 9 Závěr/pochopení Analýza požadavků zodpovídá otázku Co? a tvoří důležitý předěl a zároveň spoj mezi otázkami Proč? (strategická úroveň) a Jak? (návrh a implementace řešení). V semináři 05 se budeme dále zabývat realizovaným řešením, které bylo vytvořeno na základě analýzy a specifikace požadavků a představuje jednu z možných odpovědí na otázku Jak? Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 10 Výstupy z analýzy a ukázky zpracování jednotlivých typů požadavků Uživatelské požadavky – scénáře (případy použití) V této fázi získávání požadavků se zaměřujeme na požadované chování řešení z “vnějšího” uživatelského pohledu, jak je potřebné a jak se jeví samotným uživatelům (aktérům) digitalizovaných procesů. Postupujeme směrem z vnějšku do nitra: 1. identifikujeme hranice systému, kde vně jsou uživatelé (aktéři) pracující se systémem a uvnitř budou specifikované jednotlivé případy použití, jak aktéři potřebují systém užívat. 2. Identifikujeme aktéry (role), kteří potřebují se systémem nějak pracovat. 3. Ke každé roli identifikujeme jednotlivé potřebné případy použití. Případy použití – jejich názvy by měly reflektovat jasně určené obsahy požadavků či aktivit, které má digitální řešení uživateli poskytovat. Diagram případů užití (Use Case Diagram) Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 11 Požadavky na FUNKCIONALITU a vnitřní CHOVÁNÍ procesů Požadavky na chování a funkcionalitu, které zajišťují realizaci identifikovaných případů použití, lze typicky zachytit pomocí UML diagramu aktivit (work-flow) a textovou specifikací uplatňovaných obchodních pravidel. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 12 Obchodní pravidla Každá smlouva vyžaduje schválení autorizovaným schvalovatelem jmenovaným na úrovni oddělení. V případě existence více schvalovatelů, stačí vždy schválení aspoň od jednoho (obchodní pravidlo). V případě, že smlouva přesahuje celkovou částku 10 000 Kč, vyžaduje schválení výkonnou radou firmy. Jedinou autoritou, která může danou smlouvu vypovědět, a tak přerušit všechny návazné procesy, je výkonná rada firmy. I zadavatel smlouvy by měl mít možnost odmítnout smlouvu a vrátit schvalovací proces smluv v jakémkoliv kroku až do stavu Odmítnuto s přiřazením zpět zadavateli. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 13 Požadavky na DATOVÉ ENTITY Datové požadavky pro KATEGORIE: • identifikátor • popis kategorie Datové požadavky pro POLOŽKY: Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 14 • identifikátor • kategorie, do které položka patří. • další schvalovatel (v případě některých položek je žádáno ještě další schvalování). • cenový limit • jednotlivé nasmlouvané položky (SUB-GRID): • id smlouvy • nasmlouvaný dodavatel • množství • jednotková cena • celková cena Datové požadavky pro ODDĚLENÍ: • identifikátor • popis oddělení • schvalovatelé Datové požadavky pro DODAVATEL: • identifikační číslo • název společnosti • kontakty (Více položek) Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 15 Lze vizualizovat diagramem tříd či Entity-Relationship diagramem (ERD): Oznámení V rámci procesu schvalování je požadováno, aby zadavatel (REQUESTOR) byl informován, tedy dostával oznámení o každém kroku v procesu, včetně akcí dalších odpovědných uživatelů v procesu. Oprávněné akce schvalování případně odmítnutí by měli být přístupné přímo z e-mailových oznamovacích zpráv spustitelných jak z PC, tak v mobilních zařízení. Všechna oznámení musí obsahovat jasně definovaný obsah, a to minimálně: číslo smlouvy, odkaz (link) na samotnou smlouvu, dále informace o aktuálním a předchozím stavu smlouvy, aby byla zajištěna transparentnost, odkud smlouva přišla a kam postupuje v procesu. Dále informace o vlastníkovi akce, detaily smlouvy, jako je název dodavatele, název dodávaného zboží, popis, platnost smlouvy, celková cena, jednotlivé položky se svými nasmlouvanými cenami a počtem ks. Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 16 Zajištění kvality dat Je potřeba zajistit jednoznačnost dodavatelů podle českého obchodního rejstříku firem, tedy zajistit kvalitu a jednoznačnost jak MASTER DAT tak TRANSAKČNÍCH DAT o dodavatelích při vytváření - zadávání nového dodavatele. Možnost tisku smlouvy a její archivace Systém musí umět vytisknout smlouvu k odeslání k podpisu dodavateli a následnou archivaci tak, aby smlouvu bylo možné kdykoliv dohledat jednoduchým způsobem. Automatická kontrola časové expirace smluv Smlouvy s dodavateli by měly být automaticky kontrolovány z pohledu data platnosti. Pokud u nějaké smlouvy dobíhá platnost, měl by být zadavatel (REQUESTOR) daného dodavatele upozorněn o blížícím se vypršení smlouvy, a tak mohl provést případné náležité akce, jako je prodloužení smlouvy. Správa schvalovatelů za jednotlivá oddělení Systém by měl umožňovat jednoduchou správu schvalovatelů za jednotlivá oddělení bez nutnosti jiné interakce mimo oddělení Správa smluv a zboží Systém by měl na úrovni MASTER DAT umožňovat správu spojení smluv s jednotlivými produkty. Současně všechny objednávky k daným produktům by měly být přehledně dostupné. Reporty Na požádání by měly být k dispozici sestavy a reporty ohledně relevantních dat týkajících se smluv a objednávek pro další zpracování analytickým oddělením firmy. Potřebná data pro smlouvy jsou: číslo smlouvy, název prodejce, typ smlouvy, doba platnosti smlouvy, kategorie zboží, zboží=položka, cena, množství, objem, cena a status smlouvy. Potřebná data pro objednávky jsou: stejná jako v případě dodavatelů, navíc zahrnují: číslo objednávky, datum vystavení objednávky, datum požadovaného dodání. Role “super uživatele” Jde o požadavek CFO firmy, který má na starosti všechny finanční procesy. Je požadováno vytvoření takové uživatelské role, která bude mít možnost kdykoliv ad-hoc zasáhnout do jakéhokoliv běžícího procesu. Tedy primárně možnost kdykoliv změnit status jakéhokoliv požadavku a měnit obsah formulářů v jakémkoliv čase a stavu Copyright: Kolektiv autorů SYNERGINE, s.r.o. a Slezská univerzita v Opavě, Obchodně podnikatelská fakulta v Karviné. 17 Závěr Základní očekávání je, že výše uvedené požadavky na digitalizaci procesů schvalování dodavatelů a vyřizování objednávek budou implementovány a nasazeny v následujících 3 pracovních dnech pomocí procesní platformy XEELO. Pochopit, analyzovat a dále zpracovat a transformovat výše uvedené obchodní požadavky do návrhu řešení a nakonfigurovat jej v procesní platformě XEELO. Převzaté řešení je pak nutné přetestovat, zda odpovídá dokumentaci uživatelských požadavků formou akceptačního testování. Jsou otestované všechny větve jednotlivých workflow?