Díl 5. Standardizace versus automatizace.

Standardizovat nebo automatizovat – to je otázka. Nejen velcí klasikové, jako Shakespeare, pokládali sobě i světu důležité otázky. Občas si rád jen tak sednu na balkon a přemýšlím kromě jiného i o různých aspektech automatizace. Náš balkon je oblíbeným místem všech pracovníků XELTO DIGTIAL. Při sledování západu slunce jsme se takto s Monikou jednou pustili do zajímavé polemiky:

Jak to vidí expert:

Každé podnikání prochází procesem neustálých proměn. Způsob fungování firmy se mění v situacích, kdy rostou náklady na práci, kdy rostou požadavky zákazníků, v situacích kdy firma bojuje s konkurencí, nebo kdy se obává o účinnost dosavadních řešení. S vědomím vysokých nákladů na případné změny hledáme ty oblasti, ve kterých by proces změn umožnil dosáhnout cíle co nejrychleji a za co nejmenší cenu.

Čím tedy začít?

Určitě identifikací míst zpomalujících procesy, vyčleněním prvků generujících nejvíce chyb, a také těch, které jsou zkrátka z časového hlediska neefektivní. V každém podnikání existují procesy, které jsou zastaralé, které využívají starou technologii a ve velké míře se zakládají na, bohužel, omylnosti člověka. Zvlášť viditelné to je ve velkých firmách s mnoha odvětvími, kde proces definovaný na určeném místě a v určeném čase (a ostatně dokonale fungující po dlouhou dobu) nakonec začíná postupně stagnovat. Pomalu se začíná rozpadat, anebo probíhá už úplně jinak, než byl původně zamýšlen. Provozní podmínky často hrají roli v neúmyslných úpravách procesu a způsobují to, že se jeho původní smysl s každou další interpretací a výjimkou postupně vytrácí. (Do těchto podmínek můžeme brát v potaz i obchodní úseky nacházející se v různých zemích, s různou kulturou práce nebo s různými zvyklostmi). Co tedy s tím? Prvním, a do jisté doby jediným receptem, bylo přistupovat ke každé takové události stejným způsobem, a pokaždé, kdy k ní došlo se pokusit ji standardizovat.

Standardizace znamenala, že všechny známé kroky byly sjednoceny až to té doby, dokud nebylo dosaženo zcela konzistentních procesů. Není nutné zde dodávat, že samotná identifikace a hodnocení různých činností a událostí jsou značně časově náročné, a také vyžadují podstatné náklady. Pokud k tomu připočteme čas nezbytný pro další úkon, tedy automatizaci, moment, kdy dosáhneme očekávané změny se nám výrazně vzdálí.

Je tedy nutné položit si otázku: Co je skutečným cílem této operace? Chceme mít standardizované procesy (připravené na automatizaci) jednotně fungující ve všech oblastech firmy? Anebo nám jde o úspory v nákladech na pracovní sílu a o uvolnění lidského potenciálu? Zvolíme-li pouze standardizaci jako takovou, pak můžeme na úspory zapomenout.

Takže namísto komplexní standardizace před automatizací bychom měli vsadit na standardizaci PROSTŘEDNICTVÍM automatizace. Předpokladem je výběr a identifikace procesů, které je třeba změnit. Čas, který jsme věnovali opravě zaostávajících procesů, bychom spíše měli věnovat analýze těch bodů, kde bude nejlepším řešením automatizace procesu.

Nejdůležitějším cílem automatizace by vždy měla být ochota zbavit vaše zaměstnance zátěže, tedy namáhavých a monotónních úkolů, a umožnit jim rozvíjet se. Existují zajímavá pozorování: z pohledu zaměstnanců toho standardizace na rozdíl od automatizace příliš nemění. Zohledníme-li očekávání, která mají pracovníci vůči oběma procesům, bude u nich určitě větší zájem na zavedení automatizace, protože na jejím konci se objevuje možnost předání obtížných úkolů robotu. Když zaměstnance zbavíme frustrujících a opakujících se úkonů, vrátíme jim zpátky jejich původní pracovní nasazení.

Stručně řečeno: Místo zavržení standardizace ji můžeme modelovat tak, aby se stala prvkem automatizace, a ne pouze samostatným řešením. Stejně důležitá je nutnost soustředit pozornost na potenciál pracovníků. Z pozorování vyplývá, že potenciál pracovníků proporčně roste v souvislosti s delegováním jejich úkolů robotům.

Autor: Monika Stawicka – Business Analyst

Zdroj: Should You Automate Your Processes „As-Is“ or Standardize First?

Díl 4. ODBC – Musí být obrovské množství dat vždy jen přítěž?

Už umím být nejen užitečný ale i zdvořilý – jsem už náležitě připraven, abych mohl pro Vás lidským způsobem automatizovat spoustu business procesů. Jak jistě dobře víte, firmy používají mnoho programů, pracují se starými systémy a zpracovávají obrovské množství dat, kterých je s každým dnem stále více.  Jednoho dne jsme se s Tomášem pustili do debaty na téma ODBC. Tyto naše rozhovory mě baví – oba máme za to, že nemožné prostě neexistuje:

 Jak to vidí expert:

 Práce s daty je neodmyslitelným prvkem mnoha procesů. Machine Learning, Data Science, a také RPA musí velmi často pracovat se složitými soubory dat s tisíci zápisy.  V každém z těchto případů je správnost údajů velmi důležitá, ovšem lidský faktor je bohužel velmi náchylný k chybám. S těmito problémy se však dokážeme vypořádat mnoha způsoby.

Během automatizace se často potýkáme se složitými procesy, které zpracovávají velké množství dat, což může celý proces v některé z jeho fází zastavit. Toto pak může vést k menší či větší ztrátě času. Skvělým řešením je použít k ověření dat databáze automatizovaných aplikací. Aplikace mají často vestavěné možnosti ověření vstupního pole, a díky přístupu, který k nim máme, můžeme už v počátečním stádiu eliminovat některé chyby ovlivňující procesy.

V tomto ohledu je velmi užitečný balíček UiPath.Database.Activities, díky kterému můžeme vytvořit spojení s databází s využitím rozhraní ODBC, a následně tak pracovat s daty v režimu read a write. Jako jednoduchý příklad můžeme uvést procesy běžící v systému ERP JD Edwards, kde automatizace často potřebují vytvoření nových záznamů (obvykle prostřednictvím navzájem propojených programů). Je nutné podotknout, že jde o systém, který je méně vhodný pro automatizaci, což znamená, že některé úkony lze urychlit jen v omezené míře. Každá úspora času je pro nás důležitá a vyloučení chybných úkonů v počátečních fázích je tedy více než žádoucí. V rámci tohoto systému můžeme vstupní data zadaná do jedné z aplikací ověřovat hned na začátku. Lze také zkontrolovat, zda uživatelem určená data ve zdrojových tabulkách uchovávajících možné hodnoty pro daná pole skutečně existují.

Díky výše uvedeným operacím můžeme velmi rychle zrušit celá chybná zadání, bez nutnosti vyhledávání všech jednotlivých chyb během zpracovávání úkolů v systému JDE, čímž pro uživatele získáme cenný čas. To je výhoda zejména pro procesy s vysokou prioritou a velkou mírou složitosti.  Informování uživatele, že jeho zadání obsahuje chyby ještě před vlastním zpracováním dat, snižuje počet nutných zásahů, které nás pak mohou ve výsledku připravit o celkový čas.

Jak robot obsluhuje celé rozhraní, může být pro uživatele zajímavá podívaná. Ovšem je dobré udělat vše pro zlepšení bezpečnosti, spolehlivosti a účinnosti robota (např. použít rozhraní API). Proto také doporučujeme spolupráci robotů s databázemi, aby se tak zlepšila produktivita a v důsledku rovněž i spokojenost koncových uživatelů.

Autor: Tomasz Sioła – RPA Developer

Foto: iStock

Díl 3. Slušné chování v automatizaci – dokážou se roboti chovat jako lidé?

Jak již víte z prvních dílů, nejsem úplně typickým robotem. Když jsem začínal pracovat v XELTO DIGITAL, byl jsem obyčejným robotem, avšak kolegové z týmu mě každý den učili stále zajímavější úkony, díky čemu jsem mohl častěji pomáhat našim zákazníkům v každodenních činnostech. Jistého dne se však zjevila Ona…  Od této chvíle jsem se rozhodl být nejen užitečný, ale rovněž i zdvořilý. Stačil pouze krátký rozhovor s Monikou a Kamilem, aby mě naučili základy slušného vychování…

Jak to vidí expert:

V našem týmu vycházíme z předpokladu, že v procesu automatizace, komunikace mezi robotem a naším zákazníkem není druhořadou záležitostí. Pro účely tohoto článku slovem “komunikace” rozumíme veškeré informace a oznámení, které robot vysílá operátorovi nebo uživateli prostřednictvím e-mailové zprávy.  Mohou to být chybová hlášení, zprávy nebo informace o ukončení úkonu. Každá informace zasílaná robotem může být strojová – automatická, ale také naopak: sympatická a lidově řečeno „lidská“.  Z našich zkušeností se zákazníky vyplývá jednoduchý závěr: zákazník očekává, že robot bude v rámci komunikace lidský.

Co to znamená pro nás, kteří jsme navrhli robota?

Máme na paměti, že na druhé straně je člověk, kterému bude sympatické, pokud obdržená zpráva bude začínat slovy: „Milý uživateli” nebo „Dovoluji si oznámit”. Ostatně, pokud zákazníci vnímají robota jako virtuálního pracovníka nebo kolegu, je zcela logické, že takový přístup má vliv na typ komunikace, stejně jako mezi pracovníky, kteří se navzájem znají.

Dokáže robot mluvit v každém jazyku?

Robot by měl být také polyglotem v takové míře, aby každý uživatel obdržel zprávy ve své rodné řeči.  Je to sice detail, ale opravdu to funguje. Maily v angličtině, což vždy asociuje počítačový jazyk, jsou vnímány jako strojové nebo příliš oficiální. Jednoduše řečeno informace v Tvé rodné řeči jsou vždy přístupnější.

Již víme, že vytvoření takové komunikace není složité. A o tom, že to stojí za to, nás přesvědčila jedna ze zpětných vazeb od zákazníka, kterou jsme dostali: „Robot je velmi milý v rámci zpráv, které zasílá :)”.

Elektronická komunikace

Robotem nejčastěji používaným komunikačním nástrojem je email, který ve většině procesů v tomto rozsahu plně pokrývá veškeré požadavky. E-mailem můžeme uživatele informovat o tom, že robot zahájil proces anebo že jej ukončil. Informujeme o systémových či procesových chybách, odesíláme závěrečnou zprávu anebo informujeme o libovolných událostech, ke kterým došlo během realizace procesu.

Technicky vzato robot může poslat e-mail skrz nainstalovanou aplikaci na každém počítači (např. MS Outlook). Taková metoda nám umožňuje využít firemní poštu, aniž by bylo nutné maily zde mít nebo je ukládat, tudíž i aktualizovat data potřebná k přihlášení. Kromě použití aplikace má robot možnost spojit se s webovým emailovým serverem s použitím protokolů SMTP, POP3, IMAP, anebo v případě mailů zasílaných většími dodavateli, spojit se přímo se serverem, jako je např.  GSuite nebo Microsoft Exchange Server.

Nejen emailová komunikace

Je však nutno mít na paměti, že i když je e-mail základní a nejčastěji používanou formou komunikace, roboti mají k dispozici více možností. V případě procesů, jejichž charakteristika požaduje rychlou reakci anebo větší počet interakcí s uživatelem – může být dobrým řešením také použití aplikace, která umožňuje okamžité zasílání jako je např. MS Teams, Skype, SameTime etc. Náhražkou komunikace robota s člověkem může být rovněž zpráva o průběhu prací robota uložená na příslušném místě na síťovém disku, což může být dobrým řešením, pokud se chceme vyhnout spamu anebo když nemáme k dispozici příslušné nástroje.

Autoři: Monika Stawicka – Business Analyst, Kamil Gawlista – RPA Developer

Díl 2. Příběh jistého razítka neboli PDF vonící pečetidlem.

Dnes bych chtěl popsat, jak ve 21. století dokážeme „virtuálně razítkovat“. Počátky razítkování sahají až do starodávných časů. V antickém Řecku a Římě se razítka používala k zajištění korespondence
a k potvrzení autenticity závěti. V průběhu století se tento postup jakož i metoda používání razítka vyvíjely. A stejně jako název mého oblíbeného filmu Diamanty jsou věčné, lze obdobně povědět, že podobně je to i s razítky.

Chtěl bych Vám spolu s Kamilem vyprávět o jedné z našich automatizací, kterou je STAMPER:

Názor experta:

Soubory ve formátu PDF ovládly svět digitálních dokumentů a každý, kdo má alespoň minimální kontakt s počítačem se s nimi určitě setkal. „Pédéefka“ se díky svým přednostem stala převládajícím formátem souborů, pomocí kterých publikujeme textové i grafické informace pro širší okruh odběratelů. Tyto soubory jsou rovněž velmi často používány v rámci firemních a korporátních procesů, v nichž jsou publikovány dokumenty, ceníky, brožurky a mnoho jiných formátů.

Charakteristickou vlastností „pédéefek“ je omezená možnost jejich editace, což je na jedné straně jejich výhoda, protože soubory tak mají svůj již určený formát nezávisle na programu, v němž je otevíráme, ale někdy je to i vada, např. tehdy, pokud chceme obsah souboru PDF rychle editovat anebo něco dopsat. Nejpopulárnější programy pracující s tímto druhem souborů buď takové funkce nemají anebo jimi disponují ve velmi omezené míře.

Naštěstí Adobe Systems již v roce 1996 vyvinul řešení, které aspoň částečně vychází vstříc našim potřebám. Soubory s rozšířením FDF, které jsou obyčejnými textovými soubory, lze importovat do PDF, a takto lze vytvořit dodatečnou snadno editovatelnou vrstvu objektů.

V XELTO DIGITAL jsme udělali ještě jeden krok navíc a připravili jsme řešení spojující robotiku
a možnosti, které nám poskytuje formát FDF. Vyvinuli jsme produkt s názvem STAMPER. Jde o nástroj sloužící razítkování „pédéefek“, který může fungovat samostatně nebo může být zahrnut do širšího procesu, během něhož bychom chtěli, aby zpracovávané PDF byly příslušným způsobem označené. Razítka vytvořená STAMPEREM se vyznačují velkou pružností. Kromě obsahu lze libovolně editovat ohraničení, pozadí, orientaci a mnoho dalších prvků.

Díky našemu řešení můžete doplnit dodatečné informace před vytištěním faktury, nebo označit již zpracované dokumenty příslušným dovětkem. Využití STAMPERU během automatizace kancelářských procesů Vám dává nové možnosti a způsobí to, že soubory lze konečně označit čitelným způsobem.

Autor: Kamil Gawlista – RPA Developer

Díl 1. ReCAPTCHA bez tajemství.

Jmenuji se Ed… Robot Ed. Ano vím, zní to jako příběh o slavném agentovi 007, ale řeknu Vám, že má dobrodružství jsou stejně poutavá, jako ta, která se přihodila hrdinovi Iana Fleminga. Navíc jsem velkým fanouškem Jamese Bonda a stejně jako on zbožňuji technologické novinky. Máme také jiné společné tajemství, ale o tom někdy jindy. Začněme však hezky od začátku.

Během nejbližších týdnů bych Vás chtěl vzít do fascinujícího světa automatizace, který mě samotného bezmezně pohltil. O všech inovacích a možnostech, které dává automatizace procesů bych mohl vyprávět do nekonečna. Díky práci v týmu XELTO DIGITAL mohu soustavně získávat poznatky od našich specialistů a podělit se o ně s Vámi na stránkách našeho blogu:

Jak to vidí expert:

Když robot řekne „Nejsem robotem”, nemluví pravdu?

Práce s webovými stránkami a webovými aplikacemi je jednou ze základních věcí, s nimiž si musí roboti poradit ve své každodenní práci. Uvedu příklad, máme ideální proces na automatizaci – jednoduchý, strukturovaný proces s digitálními vstupními daty, ale na cestě k realizaci našeho cíle se objeví ono slavné potvrzení „I’m not a robot”. Na štěstí to není konec světa (a ani našeho projektu), protože máme několik možností.

Zaprvé, zvláště pokud pracujeme na vnitřní aplikaci, můžeme se zkontaktovat se správcem a požádat jej o to, aby připravil verzi webové stránky bez reCAPTCHA. Jenže jak to v životě bývá, častější jsou ty případy, kdy to budeme muset nějak vyřešit sami. Nyní můžeme využít placená nebo neplacená řešení založená na strojovém učení. Ta placená si dovolím vynechat, na internetu je jich dost, a jejich fungování nejlépe vysvětlí ti, kteří je prodávají. Nežli je však použijete, vyzkoušejte si rozšiřující modul Buster: Captcha Solver for Humans. Lze ho použít v prohlížeči Chrome a FireFox.

V čem to spočívá?

Modul přidává k oknu reCAPTCHA nové tlačítko, kliknutím spustíme zvukovou verzi reCAPTCHA, modul si ji nepozorovaně vyslechne a následně správně napíše požadované řešení úkolu. Dodám jen, že je to tlačítko, na které náš robot bez problému umí kliknout!

Jak to vypadá?

Když náš robot spustí reCAPTCHA, jsou dvě možnosti. Buď nás mechanismus prostě pustí dál nebo se objeví dobře známé okno s obrázky. Po instalaci modulu se objeví třetí tlačítko s oranžovou postavičkou, což vyřeší náš problém. Stisknutí tohoto tlačítka robotem, spustí automatické řešení úkolu. Jediné, co nyní zbývá, je vybudování automatické procedury za účelem monitorování chování reCAPTCHA.

Je to ideální řešení?

Ne. V rámci velkého počtu přihlášení nás reCAPTCHA bude vnímat jako útok na stránku a zablokuje jakékoliv pokusy o spojení se stránkou. Navíc, i když práce na aktivní obrazovce funguje velmi dobře v Chrome i ve Firefoxu, přenos na vzdálenou plochu komunikaci znesnadňuje. Z mé zkušenosti vyplývá, že si s tímto úkolem lépe poradí Firefox s užitím „send window message”, ideálně ve verzi 64, protože v pozdějších verzích se vyskytuje chyba způsobující to, že modul neodpovídá (toto naštěstí řeší opětovné spuštění prohlížeče). Nicméně tento způsob by měl pomoci vyhnout se tomuto problému v rámci automatizace procesu.

Autor: Rafał Korporowicz – Senior RPA Developer

Kde je můj druhý domov? Praha!

Nedávno jsem přemýšlel, kam budou vést další kroky na mé cestě automatizace. Polsko už znám docela dobře, tak proč si neudělat cestu do zahraničí?

Vždycky jsem snil o tom, že uvidím zemi svého původu. Víte odkud je slovo ROBOT? Z České republiky! Slovo „robot“ bylo poprvé použito pro označení fiktivního humanoida v české hře s názvem R.U.R. od Karla Čapka.

Ale kam jít nejprve? Kde by lidé nejvíce ocenili moji pomoc? Mělo by to být velké město se spoustou příležitostí. Myslím, že je to jasné, musí to být Praha!

Slyšel jsem mnoho příběhů o Praze, je jedním z nejbezpečnějších hlavních měst na světě, má neuvěřitelnou starou architekturu, s hlavními atrakcemi jako je Pražský hrad, Karlův most nebo Staroměstské náměstí s Pražským orlojem, a také si tam můžete dát to nejlepší pivo na světě!

Zavolám tedy českému kolegovi Michaelovi, dáme si jedno pivo, a probereme, jak mohu pomoci lidem v Čechách.

Můj sen se stal skutečností! Od července zahájila společnost XELTO DIGITAL CZECHIA své podnikání v Praze!

Srážková daň – jak s ní automatizace pomáhá? (I)

Vyhledávání v zahraničních databázích dodavatelů

Srážková daň je forma daně z příjmu uplatňovaná na přeshraniční převody. Jde o formu daně z příjmu (od právnických a fyzických osob), kterou vybírají plátci z určitých příjmů (včetně dividend, úroků, licenčních poplatků). Srážková daň se vybírá z transakce, kdy příjemce převodu (který se stává plátcem daně) má jinou daňovou rezidenci než odesílatel převodu, který platí daň. Polsko podepsalo smlouvy o zamezení dvojího zdanění. Odesílatel převodu za služby zahraničního dodavatele, který platí srážkovou daň, musí podle těchto ustanovení znát daňové údaje dodavatele, kterému bude daň účtována.

Ve světle nových předpisů jsou polští daňoví poplatníci provádějící přeshraniční platby pohledávek ve výši přesahující 2 miliony PLN (v daném roce danému příjemci) povinni vybírat srážkovou daň v příslušné sazbě, tj. 20 % nebo 19 %.

Výběru daně se lze vyhnout, pokud správní rada tuzemského plátce předloží prohlášení, mj. že při vynaložení náležité péče ověřila, že zahraniční subjekt přijímající platbu je jejím skutečným vlastníkem a provozuje skutečnou podnikatelskou činnost. V takové situaci však odpovědnost za nevybranou daň a riziko v případě budoucího sporu s finančními úřady přechází na správní radu polského plátce. Uplatnění osvobození od srážkové daně bude možné také po získání individuálního stanoviska finančních úřadů potvrzujících řádné postavení zahraničního příjemce plateb z Polska.

To vše zahrnuje kontrolu a shromažďování daňových údajů dodavatelů. Pro zaměstnance firmy, která odvádí srážkovou daň, to znamená hodiny strávené prohledáváním databází registrovaných dodavatelů a stahováním jejich daňových údajů. Čím více zemí původu protistran existuje, tím více údajů je třeba zkontrolovat; Evropa, Spojené státy americké nebo Japonsko, každá oblast provozuje své vlastní služby daňové evidence a žádost o data z těchto služeb se stává velmi časově náročným úkolem. Pro společnost, která nakupuje mnoho služeb podléhajících srážkové dani, to znamená značné množství času stráveného přípravou daňových podkladů.

V takovém případě je automatizace procesu vyhledávání dat zhotovitele obrovskou výhodou. Edward Robotowski má za úkol zaměstnanci společnosti ulehčit tyto náležitosti převzetím procesu kontroly a stahováním dat dodavatelů z různých zemí a daňových oblastí.

Data, která mají být zpracována v procesu automatizace, jsou seznam dodavatelů, seznam zemí a daňových služeb pro tyto země, tedy činnost robota spočívá v poskytování údajů zaměstnanci rozdělených do dvou skupin: údaje, které lze získat explicitně a údaje, které jsou k dispozici po zaplacení určité částky. Veškeré práce probíhají na pozadí provozu společnosti. Robot pracuje bez chyb a poskytuje potřebné zprávy pro analýzu.

Zaměstnanec pak musí pouze posoudit vhodnost placených dat a nechat robota získat ta, za která se rozhodne zaplatit. Robot, vybavený mechanismem pro provádění plateb na konkrétní servisní účty a shromažďování údajů o zaplacených daních, tak pokračuje ve svém provozu. Závěrečná zpráva poskytuje údaje, které splňují požadavky při ověřování zahraničního dodavatele.

Zdroj: https://www.podatki.gov.pl/wht/podatek-u-zrodla-wht/https://www2.deloitte.com/pl/pl/pages/tax/topics/Podatek-u-zrodla-WHT.html

Autor: Monika Stawicka – Business Analist