5. Praktická část
5.3. Přehled automatizace v úseku financí
5.4.3. Praktická ukázka automatizovaných procesů
V rámci této kapitoly bude demonstrována aplikace robotické procesní automatizace na vybraných účetních procesech, které jsou již v produkci. Vybrány byly tři ukázky robotu, u kterých jsem měla prostřednictvím vývojáře přístup k detailním informacím. Nejedná se však o největší roboty s nejvyšší přidanou hodnotou pro společnost. Cílem praktické části je tak přiblížit technologii na praktických ukázkách.
Jak bylo zmíněno v kapitole 4.7.1 je robot v UiPath tvořen procesními diagramy, které zaznamenávají jednotlivé úkony robota pomocí aktivit, tak jak by je prováděl zaměstnanec.
Diagramy jsou velmi přehledné, jelikož je lze prohlížet z různých vrstev granularity.
V rozbalené formě na jednotlivé aktivity u veškerých částí procesu zabere ale UiPath diagram klidně několik stránek a jeho použití tak není vhodnou formu pro ukázání procesu v diplomové práci. Navíc diagramy vygenerované přímo z UiPath obsahují značné množství interních
62 informací. Pro modelování procesu automatizace byl zvolen přístup tvorby vlastního zjednodušeného diagramu, který bude ukázán pomocí vizualizací vytvořených v online nástroji diagrams.net2
V diagramu budou použity grafické značky znázorněné na obrázku 11.
Obrázek 11: Přehled grafických značek diagramu
Zdroj: Vlastní zpracování
Pro úsporu místa a zlepšení vypovídací schopnosti budou některé aktivity UiPath diagramu sloučeny do jedné a některé vedlejší kroky, které jsou pouze podpůrnými složkami procesu budou vynechány. Ačkoliv všechny aktivity provádí robot (UiPath), budou aktivity rozlišeny barvami dle jednotlivých aplikací, se kterými robot pracuje. U některých procesů bude pomocí trojúhelníku, připojeného k aktivitě, rozlišen zdroj dat.
5.4.3.1. Robot č. 1: Účetní kontrola úplnosti přijatých faktur
Automatizace procesu účetní kontroly úplnosti přijatých faktur pomocí robotické procesní automatizace navazuje na její částečnou automatizaci pomocí makra v MS Excel zmíněnou v kapitole 5.3.3.
Jak bylo zmíněno v kapitole 5.3.1 přicházejí na podatelnu společnosti faktury v papírové podobě (potřeba naskenovat) a faktury v PDF jako příloha e-mailu (PDF, již naskenované), viz obrázek 12. Z důvodu akvizice německou společností je cca 75 % přijatých faktur odesláno na zpracování do Německa, kde dochází i k jejich zaúčtování do SAP DE (ve kterém má společnost zřízen vlastní okruh). Zbytek faktur je zpracováván v Česku. Přeposlání do Německa probíhá prostřednictvím zakódovaného ČK a jiných např. časových údajů v XML. Přiložena je i samotná faktura jako příloha. XML putuje přes internet prostřednictvím značného množství serverů, přičemž mateřská společnost outsourcuje vytěžování faktur do Asie. Cesta do SAP DE tedy není přímočará a ze zkušenosti analyzované společnosti může nastat např. výpadek těchto
2https://app.diagrams.net/
63 serverů, či naplnění jejich kapacit a faktury tak do SAP DE nedojdou, a to bez jakéhokoliv upozornění. Kontrola je tak důležitou součástí procesu.
Obrázek 12: Diagram procesu přijatých faktur
Zdroj: Vlastní zpracování
Pomocí makra se kontrolovala celistvost číselné řady ČK přijatých faktur z podatelny (pro SAP DE i CZ) a ověřovalo se tak, že všechny přijaté faktury došlé na podatelnu byly zaúčtovány do systému. Makro používalo pouze data ze SAP a hledalo mezery mezi posloupností ČK. Kontrola robotem představuje nadstavbu nad makrem a využívá ke kontrole kromě dat ze SAP i data z podatelny. Kontrola je rozdělena do dvou robotů – kontrola úplnosti ČK faktur v SAP DE a kontrola v SAP CZ.
Denně je takto přeposíláno do Německa okolo 400 faktur a jejich případné opominutí představuje pro společnost velkou hrozbu. V rámci menšího počtu transakcí byla kontrola pomocí makra dostatečná, ovšem po migraci a s rozvojem projektu RPA se jednotka účetnictví, daní a treasury rozhodla o zefektivnění kontroly úplnosti přijatých faktur, a to i jejího častějšího provedení. V současné době se robotická kontrola spouští každý den, čímž usnadňuje zaměstnancům a společnosti značné množství rutinní práce.
Jak popisuje tabulka 7, probíhala kontrola pomocí makra pouze jednou měsíčně zaměstnancem účetního oddělení, přičemž k ní docházelo koncem měsíce a pokrývala celé toto období. Zaměstnanec si musel vygenerovat report s přijatými fakturami ze SAP DE a stejný report ze SAP CZ. Generování reportu v SAP trvalo však u obou reportů v řádu desítek minut, jelikož se načítalo velké množství informací za celý měsíc. Poté se musely tyto reporty zkompletovat na jeden list MS Excel, na němž bylo makro puštěno.
Ačkoliv část manuální práce při dohledávání chybějících čísel v sekvenci ČK byla již nahrazená makrem, bylo s procesem kontroly spjato stále velké množství manuální práce zaměstnance.
Makro muselo být ručně spuštěno a při chybějících ČK musel zaměstnanec sestavovat i informační e-maily, rozesílané na kompetentní osoby. Robot je na rozdíl od makra spouštěn
64 automaticky v určitý vyhrazený čas a zaměstnanec se o proces nemusí vůbec starat. Na konci obdržípouzeinformačníe-mailoprůběhu kontroly,včetněpřiložené tabulkynenalezených ČK.
Tabulka 7: Kontrola úplnosti přijatých faktur v SAP – porovnání makra a robota
AS – IS Makro a zaměstnanec TO – BE Robot
Četnost 1 x měsíčně 1 x denně
Pokryté období měsíc den
Doba trvání cca 1,5 hod max. 10 min
Funkce
• manuální stahování reportů
• manuální kompletace reportů dohromady
• manuální kompletace e-mailů při chybějících ČK
vše automatizované robotem
Zdroj: Vlastní zpracování
Výhody přechodu z makra na RPA - Vyšší frekvence kontrol
- Snížení manuální práce a s ní spojené chybovosti - Škálovatelnost do budoucna
Výhodou automatizace robotem je i prostor o rozšíření RPA na okolní procesy související s kontrolou úplnosti přijatých faktur, či samotné zdokonalování procesu. V současné době je tento robot rozšířen o následnou kontrolu, zda ČK, které nebyly nalezeny v německém SAP, nebyly chybně zaúčtovány do SAP českého. Dále je v provozu robot, který plní stejnou kontrolu, ale na ČK odeslaných faktur do českého SAP. Pokud není ČK nalezen, je s procesem spjato ale stále velké množství manuální interní korespondence. Do budoucna je z tohoto důvodu plánovaná další automatizace, a to procesu v rámci kterého si zaměstnanec vyžádá audit log transakce, provede jeho analýzu a přesměruje nenalezené ČK na odpovědnou osobu ve workflow, u které se během přenosu ztratil.
Postup robota je popsán obrázkem 13.
65 Zdroj: Vlastní zpracování
Obrázek 13: Diagram robota č. 1
66
5.4.3.2. Robot č. 2: Report služebních cest soukromými vozidly
Druhým příkladem automatizovaného procesu pomocí RPA je proces sestavení reportu služebních cest soukromými vozidly, který byl ručně sestavován zaměstnanci oddělení.
Výsledný report lze vidět v tabulce 8. Pro každou pracovní cestu jsou do reportu zaznamenané údaje o zaměstnanci, státní poznávací značce (dále SPZ), počtu ujetých kilometrů, parametrech cen pohonných hmot (dále PHM) a kombinované spotřebě z technického průkazu (dále TP). Report dále obsahuje údaj o vypočtené náhradě, která je vyplacena zaměstnanci jako kompenzace za použití soukromého vozidla na služební cestě. Report slouží pro reportovací účely jak interně v rámci analyzované společnosti, tak i v určité úpravě mateřské společnosti. Report za jednotlivá období dále slouží jako podklad při výpočtu silniční daně dle zákona č. 16/1993 Sb., kdy zaměstnavatel vyplácející cestovní náhrady zaměstnanci za použití soukromého vozidla pro pracovní cestu, může platit zálohu na silniční daň jako 25 Kč za každý den takto použitého vozidla. Druhou možností je platit silniční daň jako poměr roční sazby dle objemu motoru v cm3. Zaměstnanec daní tak pro každé zálohové období provádí analýzu, zda je výhodnější první či druhý způsob zálohy na silniční daň. Vstupem do analýzy výhodnosti je tak počet dní využití automobilu na služební cesty ze sestavovaného reportu.
Report se zpracovává za stejné období, za které se platí záloha na silniční daň:
• Leden – březen
• Duben – červen
• Červenec – září
• Říjen – listopad
• Prosinec
Tabulka 8: Report silničních náhrad a ujetých km v MS Excel za 3. čtvrtletí.
Spotřeba PHM červenec – září 2020
Jméno: PIN
67 Report byl manuálně aktualizován o informace zaměstnancem oddělení při každém zúčtování pracovní cesty soukromým vozidlem. Jelikož je nutné zkompletovat informace ze tří reportů/tabulek ze SAP, je proces náročný na manuální práci. Dle zaměstnance zabere zpracování jedné pracovní cesty cca. tři minuty.
Graf 20: Počet uskutečněných pracovních cest soukromými vozidly v minulosti
Zdroj: Vlastní zpracování
Analyzovaná společnost služební cesty soukromými vozy moc nepodporuje, tudíž ačkoliv se jedná o velkou společnost nejsou počty enormní. V grafu 20 lze např. vidět, jak se na počtu pracovních cest soukromými vozy projevila pandemie z důvodu koronaviru v roce 2020.
Postup procesu je popsán na obrázku 14. Finální report (tabulka 8) je tvořen prostřednictvím pomocné tabulky vytvořené v UiPath s názvem DtCesty (na obrázku 14 lze vidět v dolní části), do které robot postupně vyplňuje všechny potřebné informace. Tabulka DtCesty, se skládá ze 14 sloupečků a data v nich pocházejí manuálním vepisováním či výpočtem pomocí vzorce v MS Excel tak jak bylo uvedeno výše. Pro účely zpřehlednění označují barevné trojúhelníky původ jednotlivých sloupečků včetně poznámky, zda sloupečky vstupují do finálního reportu, nebo zda slouží pouze pro účely výpočtu jiným sloupečkům. Pro sestavení pomocné tabulky DtCesty je potřeba údaje zkompletovat ze čtyř zdrojů, viz tabulka 9.
Tabulka 9: Zdroje dat pro robota č. 2
Zdroj 1 Zdroj 2 Zdroj 3 Zdroj 4
2014 2015 2016 2017 2018 2019 2020
Počet uskutečněných pracovních cest soukromými vozidly
68 Tabulka 10: Report služebních cest soukromými vozidly – porovnání zaměstnance a robota
AS – IS Zaměstnanec TO – BE Robot
Četnost dle frekvence cest 1 x denně
Pokryté období den den
Doba trvání dle počtu cest á 3 min. max. 10 min
Funkce
• Manuální vyhledávání informací v SAP
• Manuální vyplňování dat
• Kompletace e-mailů
vše automatizované robotem
Zdroj: Vlastní zpracování
Výhody automatizace
- Snížení manuální práce a s ní spojené chybovosti - Zrychlení reportingu
Jak lze vidět v tabulce 10, spouští se robot každý den a kontroluje, zda došlo k zúčtování nějaké pracovní cesty. Pracovník oddělení má každý den, díky odeslanému e-mailu robotem, přehled o proběhlých pracovních cestách soukromým automobilem včetně všech souvisejících informacích. Tak jako u prvního robota bylo i zde jedním z motivů pro automatizaci ulehčení pracovníkům finančního oddělení od manuálního zpracování dat. Hlavním cílem byly však reportingové potřeby společnosti. Díky robotu navíc dochází k eliminaci chyb plynoucích z nesprávné manipulace s daty – zkopírování špatné hodnoty, vložení hodnoty do nesprávného sloupečku atd.
69 Zdroj: Vlastní zpracování
Obrázek 14: Diagram robota č. 2
70
5.4.3.3. Robot č. 3: Kontrola stavu peněz na účtech hlavní knihy a pokladního systému
Třetím příkladem RPA je automatizace procesu účetní kontroly zůstatků hotovosti na účtech hlavní knihy (dále HK) v SAP a pokladního systému používaného na prodejnách. Tak jako u prvního příkladu robota se bude jednat o provedení kontrolního mechanismu.
Společnost má přes 130 aktivních prodejních míst, kde jsou prodávané produkty uhrazovány jak platebními kartami, tak hotovostí. V případě prodeje v hotovosti jsou účetní případy přenášeny (v kopii) z pokladního systému pobočky do SAP, a to nejčastěji zápisem:
- MD Pokladna (Robot č. 3 kontroluje stav této položky) - D Výnosy
- D DPH
Do SAP jakožto hlavního podnikového systému musí být přeneseny všechny transakce z pokladního systému, což je kontrolováno v rámci měsíční závěrky. Pro každou prodejnu, označenou identifikačním kódem, se reviduje, zda zůstatek peněz na konci měsíce v pokladním systému odpovídá pokladnímu SAP účtu hlavní knihy prodejny. Kontrolní report je součástí ICS kontrol (z anglického Internal Control System), které mapují a podchytávají možná závažná interní rizika ve společnosti. Zůstatek účtů pokladního systému a SAP se musí ke konci měsíce rovnat neboli rozdíl mezi nimi musí být roven nule. Pokud tomu tak není, nastala na jedné straně chyba a incident se musí detailně dořešit.
Nesoulad mezi pokladním systémem a SAP vzniká nejčastěji z důvodu:
- Časového posunu (z důvodu velkého množství dat dojde k přenosu až následující den) - Výpadku internetu
- Nového produktu (SAP není na nový produkt nastaven a nerozpozná údaje) Tabulka 11: Kontrola stavu peněz – porovnání makra a robota
AS – IS Zaměstnanec TO – BE Robot Četnost Cca 3x na začátku měsíce 1x každý den
Pokryté období Měsíc Měsíc
Doba trvání 1 hod á počet provedení max. 5 min á provedení
Funkce
• manuální stahování reportů
• manuální kompletace reportů dohromady
• odesílání e-mailů
vše automatizované robotem
Zdroj: Vlastní zpracování
71 Zaměstnanec sestavuje kontrolní report v prvních dnech (dle potřeby) nového měsíce v rámci měsíční závěrky a kontroluje stav k poslednímu dni předcházejícího měsíce. Frekvence tvorby reportu není tak častá jako u jiných automatizovaných procesů, ale období účetní závěrky je pro zaměstnance finančního oddělení velmi vytěžující a jakékoliv ulehčení od rutinní práce jako je kompletace reportů znamená značnou pomoc. Pokud zaměstnanec při sestavení reportu nalezne rozdíl mezi koncovými stavy peněz obou systémů, je nutné report poté sestavit znovu pro kontrolu, zda byl nesoulad úspěšně vyřešen, přičemž kompletace reportu trvá dle rozhovoru se zaměstnancem až tři čtvrtě hodiny. Robotovi zabere celý proces dle tabulky 11 maximálně pět minut. Report je sestavován každý den, ačkoliv reálně je potřeba pouze v prvních dnech účetní závěrky. Důvodem je kontrola, zda robot běží správně a fakt, že v případě chyby je efektivnější chybu ve funkcionalitě robota opravit mimo období účetní závěrky.
Tabulka 12: Zdroje pro kompletaci reportu kontroly stavu peněz
Zdroj 1 Zdroj 2 Zdroj 3 Zdroj 4
Aplikace SAP SAP BO MS Excel UiPath
Název reportu Zůstatky účtů HK Denní uzávěrka Mapovací
můstek Výpočet v kapitole 5.2), a to prostřednictvím reportu „Denní uzávěrka“, viz tabulka 12. SAP BO ovšem reportuje stavy peněz na prodejnách jako kumulované denní stavy, kdežto report ze SAP vykazuje kumulovaný stav peněz za celý měsíc. Pro porovnání peněžního stavu konkrétní prodejny je nutné nalézt v reportu ze SAP BO informaci o stavu k poslednímu dni měsíce, kdy měla prodejna otevřeno. Ne všechny prodejny mají ale stejnou otevírací pracovní dobu, a tudíž poslední datum může být pro prodejny rozdílné, zvlášť pokud datum vychází na víkend.
V rámci procesu robota, zobrazeného na obrázku 15 je tento krok řešen pomocí vyfiltrování řádků konkrétní prodejny a seřazení dle data sestupně.
Kontrolovány jsou stavy pokladen na stavy peněz v HK SAP, které lze najít v reportu „Zůstatky účtů HK“. Oba reporty mezi sebou propojuje „Mapovací můstek“, který v MS Excel každé
72 prodejně přiřazuje odpovídající účet HK. Můstek je manuálně udržován zaměstnancem oddělení. V případě zavření prodejny je položka zaměstnancem z přehledu odstraněna a není tak pro ni prováděna kontrola.
Výsledný report kontroly stavu hotovosti na účtech HK a pokladního systému lze vidět v tabulce 13.
Tabulka 13: Report kontroly stavů na účtech hlavní knihy a pokladního systému ID
Prodejny Název prodejny
Účet pokladny hlavní knihy
SAP
Stav peněz v pokladním systém
na prodejně
Stav peněz na účtu hlavní knihy v SAP
Rozdíl Datum
XXX XXX – Adresa 1 222222 1 000 Kč 1 000 Kč 0 Kč 28.02.2021
XXY XXY – Adresa 2 222223 9 600 Kč 9 600 Kč 0 Kč 27.02.2021
XYY XYY – Adresa 3 222224 8 000 Kč 7 400 Kč 600 Kč 28.02.2021
YYY YYY – Adresa 4 222225 2 500 Kč 2 300 Kč 200 Kč 26.02.2021
Zdroj: Vlastní zpracování
73 Zdroj: Vlastní zpracování
Obrázek 15: Diagram robota č. 3
74