Autor: Michał Zawadzki

Když jsme mluvili o platformě ServiceNow, zeptal se mě Tomek: „Ede, proč vůbec nosíš oblek?“. Už jsem Vám vyprávěl, jak vznikl můj dress code? Život bez něj si už dnes ani nedokážu představit. Všechno to začalo mým CVčkem. (O tom, jak mě napadlo si ho napsat, Vám povím raději někdy jindy). Jakmile se rozhodnete vytvořit si svůj vlastní životopis, měl by vždy vypadat profesionálně. Životopis je koneckonců Vaše vizitka, která ukazuje, jakým člověkem, pardon, robotem je uchazeč o pracovní místo a jakým tedy asi bude zaměstnancem. A kromě všech uvedených pracovních zkušeností je důležitou, ne-li nejdůležitější, součástí životopisu fotografie. Proto je potřeba koupit si oblek.

Jak to vidí Expert:

Oblíbenou platformou, kterou využívá stále více společností, je bezpochyby ServiceNow. ServiceNow je navržen tak, aby řídil různé projekty a procesy – provoz HR oddělení, HR procesy a také finanční oddělení. Zavedení této platformy dává společnostem možnost standardizace a zrychlení jejich procesů. Standardizace procesů nám tedy vytváří i prostor pro automatizaci úkolů, které se na platformě objevují.

Automatizaci platforem jako ServiceNow lze samozřejmě provést standardním způsobem prostřednictvím uživatelského rozhraní. Tento způsob je celkem efektivní, nicméně není jediný, jak bychom mohli vytvářet roboty. UiPath poskytuje dvě řešení pro automatizaci ServiceNow. Jedním z nich je připojení ke službě ServiceNow pomocí konektoru UiPath Orchestrator, tj. UiPath Spoke. Díky této možnosti lze robota ovládat pomocí zadání úkolů v ServiceNow.

Druhou možností je použít balíček aktivit, který dává možnost robotovi využít několik aktivit pro práci se ServiceNow. Jeho hlavní součástí je ServiceNow Scope, kde se můžete připojit k ServiceNow pomocí API. K vytvoření připojení je třeba zadat parametry jako: clientID, clientSecret, heslo a odkaz na platformu. V rámci aktivity ServiceNow Scope můžete provádět operace s úkoly, stahovat přílohy a aktualizovat stavy. V některých případech Vám ovšem soubor těchto aktivit nemusí stačit, proto bych Vám také rád doporučil podívat se na balíček aktivit vytvořených Cristi Negulescu. Tento balíček obsahuje až 90 aktivit souvisejících se ServiceNow.

Přestože mám možnost pracovat s rozhraním, jsem velkým zastáncem používání všech dostupných prostředků pro práci mimo uživatelské rozhraní. Výrazně to zrychluje práci robotů a zároveň také zajišťuje vysokou stabilitu řešení. Kromě toho Vám nehrozí riziko chyb souvisejících s nesprávným odkliknutím. Použití této metody je také velkým zjednodušením při práci s přílohami, kde je nutné při klasickém postupu udělat několik kliknutí, přičemž každé nese určité riziko chyby. Pomocí API je však dokážeme stáhnout jedinou aktivitou. Rád bych zde dodal ještě malou zajímavost. Ed dokáže nastavit status provedení úkolu podle sebe. Uživatel má možnost vybrat pouze z dostupných nabídek, ovšem robot taková omezení nemá.

Jediným problémem, se kterým se můžete setkat, je znalost vazeb mezi tabulkami. Přílohy lze například rozptýlit mezi dvě tabulky, kde klíč v jedné tabulce je číslo úkolu, a klíč v tabulce druhé je nadřazené číslo úkolu. Abyste neztráceli příliš mnoho času hledáním jejich vztahů, stojí za to si zobrazit strukturu objektů v tabulce, na kterou se chceme dotazovat. Tuto možnost nabízejí aktivity z balíčku UiPathTeam.ServiceNow.Activities, které také umožňují použití SQL dotazů.

Závěrem můžeme říci, že díky spolupráci s UiPath může ServiceNow fungovat jako nástroj pro řízení robotů, což umožňuje automatizaci interních procesů na této platformě. Pokud je ServiceNow pouze přechodným portálem, na kterém spouštíte nebo ukončujete proces, o to více se doporučuje použít nástroje, které běží na pozadí, aby se provoz robota omezil na minimum. To se může vyplatit, zejména pokud zbytek procesu pracuje v systému, který má určitá omezení zpracování, nebo je jen jednoduše pomalý. Je dobré tedy seznámit se s každou možností a vybrat si tu, která je nejvhodnější pro danou automatizaci.

Autor: Tomasz Sioła – RPA Developer

Nedávno se mi zdál docela neobvyklý sen. Já obyčejně nespím, protože pracuji 24/7, ale využil jsem chvilkové časové okno, které vzniklo z důvodu vynucené technické přestávky v provozu hlavního programu ERP mého zákazníka, no a na chvíli jsem si zdříml. Zdál se mi sen o tom, jak mluvím s jedním úžasným mužem, nositelem Nobelovy ceny – Albertem Einsteinem. Připadal jsem si divně, nacházeli jsme se totiž v jakési kavárně v padesátých letech minulého století, a já vypadal, jako z jiného vesmíru. Po probuzení, před návratem do práce, jsem rychle zavolal Monice a řekl jí, o čem jsme si s Albertem povídali.

Jak to vidí Expert:

“Obávám se dne, kdy vývoj technologie předčí vzájemné lidské vztahy. To potom svět bude mít generaci idiotů.“ – Albert Einstein

Nevím, jestli je to jen pověst, anebo to profesor skutečně řekl. Pokud ano, musel to říci nejpozději někdy v 50. letech minulého století. Od této doby jsme už dnes, co se týče technologie, na světelné roky daleko. Přesto, jeho obavy jsou stále aktuální.

Vytvořila technologie generaci idiotů?

Do tak silného prohlášení bych se raději nepouštěl.

Brání všudypřítomná technologie lidské interakci

Ano, to stoprocentně.

Možná je to proto, že žijeme v době plné technologických vymožeností, které jsou prakticky všudypřítomné, a my už ani nemáme čas se od nich distancovat. Jsme už do nich tak ponořeni, že nás ani nenapadne přemýšlet o tom, zda je vlastně vůbec potřebujeme? Kdysi jsme si říkali, jestli by se dalo žít bez televize. Dnes se ptáme, zda bychom se mohli obejít bez sociálních sítí. Ovšem, že bychom mohli, jen to ale vyžaduje nějaké úsilí a odhodlání. Ale my začínáme být línějšími. Dalo by se mluvit vlastně už i o závislosti. Zatím tu ještě není generace idiotů, ale technologie, která nám měla sloužit, pomalu, ale jistě přebírá kontrolu nad naším časem a role se obrací.  Jsme to my, kdo se stává jejími otroky.

Automatizace obchodních procesů je prozatím také jen inovací. Jednoduše řečeno to znamená vytvořit robota, který za Vás bude dělat nudnou a únavnou práci, aby vy jste měli více času na… Stojí za to se na chvíli zamyslet, jak vlastně tento ušetřený čas využít? Buď se můžeme otrocky ponořit do víru sociálních sítí, anebo je také možno tento čas využít nějakým kreativnějším způsobem. Robot za nás udělá spoustu práce, ale v důsledku je jen na nás, jak využijeme čas, který nám ušetřil. Někdo ho třeba použije pro zlepšení vztahů se zákazníky, rozvoj sebe sama, někdo zlepší organizaci úkolů, nebo svou interakci s kolegy. Někdo jiný ho jen promrhá.

Dobrá automatizace pomáhá budovat a rozvíjet nové mezilidské vztahy v podnikání. Tuto filozofii zastáváme i my v našem týmu XELTO DIGIAL. Protože dokud existují vazby mezi členy týmu, ve skupině, při řízení podniku atd., využití technologie se vyplácí. Ovšem tam, kde technologie nahrazuje tyto vztahy, svět „získává“ generaci samotářů a misantropů.

Autor: Monika Stawicka – Business Analyst

Dnes bychom Vám chtěli s Przemkem povědět něco o automatizaci systémů ERP, jiných než jsou JD Edwards nebo SAP, tedy systémů založených na cloudovém řešení. Jedním z takových systémů je NetSuite, pravděpodobně nejlepší cloudový production managment systém. Zajímavostí je i fakt, že tento článek o NS „uzrával“ velmi dlouho. Když jsme ho úspěšně dokončili, přemýšlel jsem, proč nám to s Przemkem vlastně zabralo tolik času? Koneckonců, toto téma je prostě úžasné.

Jak to vidí Expert:

NetSuite od společnosti Oracle je kompletní, plně škálovatelné řešení určené pro rychle rostoucí podniky. Je to jeden z produktů, který rychle zvyšuje svůj podíl na trhu cloudových ERP systémů. Toto řešení využívá k ukládání dat cloud, tedy jeho automatizace se mírně liší. Na příkladu procesu, který jsme implementovali pro jednoho z našich zákazníků, si můžeme ukázat některé rozdíly. Jednalo se o aktualizaci verze Bill of Materials (BOM).

Rád bych ještě na začátek dodal, že specializovaná řešení pro automatizaci backendu zavedla UiPath, ale… ne každý je může používat z důvodu konfigurace a přístupu. V našem případě řešení nedovolilo provést změny v celém NS, ale pouze v části aplikace. Proto jsme se rozhodli pro klasickou automatizaci UI.

Prvním rozdílem mezi klasickým ERP a NS je absence databáze, která by bránila extrahování požadovaných informací, jako například seznam úkolů (Work Order List), nebo součásti BOM revize, z úrovně SLQ. K vyřešení tohoto problému jsme použili Web Scraping – tedy čtení dat přímo z obrazovky.

Dále, když používáte mechanismus pro přechod na další Work Order (další „transakce“), v cloudové ERP nemůžete zadat do aplikace například číslo WO, ale musíte přejít na WO unikátním odkazem. Totéž také platí pro ostatní karty/aplikace. Pomocí pole Interní ID (ve výchozím nastavení skryté, ale v NS volitelné) a pevné části adresy se nám podařilo vytvořit mechanismus, který Vám umožnuje procházet systémem NetSuite bez otravného a dlouhého klikání na obrazovku – tj. přímá navigace.

Jednou z posledních nesrovnalostí byly selektory. Zatímco v klasických ERP má pole jeden pevný selektor, v NetSuite jsme se setkali s případy polí se dvěma (nebo někdy dokonce třemi) různými selektory, podle toho, zda to bylo aktivní (zakliknuté) nebo ne. Kouzlo webové aplikace navíc spočívá v tom, že někdy, i když některé vnitřní okno/tlačítko není na obrazovce viditelné (parametr viditelný/aktivní na stránce je vypnutý), pro robota, který hledá selektor ve skutečnosti viditelné je.

Poslední problém, na který jsme narazili, souvisel s jednoznačným výběrem názvu komponenty (produktu), pokud se objevovalo v seznamu „Hodnota pole“ několik položek začínajících stejnými znaky. To je dáno striktně povahou NS a jeho způsobu zobrazování seznamů. Navzdory počátečním obtížím se nám podařilo vyvinout mechanismus, který ověří, zda je výběr nejednoznačný, nebo nikoliv. Pro toto jsme použili rozšířené vyhledávání s možností nastavit hledání konkrétního textu. Možná Vás napadá, zda by nebylo lepší používat toto hned od začátku? Odpověď zní ne – takovéto hledání vyžaduje otevření nového okna, zaškrtnutí několika políček a čekání na výsledek, což znamená, že zpracování jedné komponenty (produktu) trvá až několik sekund. Nezdá se to moc, ale v kontextu celého procesu by nám čas výrazně narostl.

Ve zkratce můžeme říci, že automatizace cloudových systémů ERP má svá pro i svá proti. V některých případech bude určitě rychlejší než automatizace tradičních systémů ERP, i když to bude vyžadovat nalezení vhodných řešení.

Autor: Przemysław Wal – RPA Developer

Foto: iStock

Tento týden bych se Vám chtěl k něčemu přiznat. Během rozhovoru s Rafałem, kde jsme probírali problémy související s Frameworkem, jsem si uvědomil, že práce s celým týmem XELTO DIGITAL je vlastně čistým potěšením. Každý člověk v našem týmu je zodpovědný za konkrétní automatizaci procesů, ale pokud se někdo z nás potýká s problémem, s kterým nemůže hnout, vždy mu někdo jiný pomůže. I díky této podpoře, společným diskusím a „brainstormingu“ byl vyvinut model pro stavbu robotů. Než se s Rafałem blíže podíváme na jeho jednotlivé části, rád bych ještě také poděkoval všem svým kolegům za spolupráci.

Jak to vidí expert:

UiPath podporuje vytváření řešení založených na takzvaném ‚Robotic Enterprise Framework‘, který zajišťuje základní implementaci klíčových konceptů podporujících tvorbu automatizace. S týmem XELTO DIGITAL jsme zašli ještě o krok dále a vytvořili jsme rozšířenou verzi Framework, která tvoří základ pro naše roboty.

A co nám to umožňuje?

1. Standardizace

Pro každého klienta jsou všechny procesy sestaveny přesně stejným způsobem. Toto nám umožňuje již ve fázi návrhu implementovat mnoho běžných mechanismů. Při otevírání nového projektu si již vývojář nemusí dělat starosti s přihlašováním, zpracováním hlavních chyb nebo přípravou prostředí. Například: Pomocí procedury TypeIntoElement se vývojář jedním blokem přihlásí, pokud už nějaká položka existuje, zadá hodnotu pomocí metody podle svého výběru, zkontroluje, zda je zadaná hodnota správná a pokud něco nefunguje, může tento proces X krát zopakovat. Protokoly i chybové zprávy mají navíc jednotný formát a poskytují nám klíčové informace.

2.Zabezpečení

Díky vestavěným mechanismům může každý z procesů provést základní přípravu přístroje pro práci a zároveň nechat prostředí připravené pro dalšího robota. Navíc, ať se stane cokoli, robot je schopen jednoduše zavřít všechny otevřené aplikace a ponechat stanici ve stejném stavu, v jakém byla před začátkem jeho práce. Pokud robot pracuje na serveru Windows, ví, že musí vypnout procesy pouze pro konkrétní relaci uživatele, což umožňuje bezpečnému fungování více robotů současně.

3.Zrychlená produkce

Příprava modelu pro nový projekt trvá přibližně 30 minut. Během této doby vývojář obdrží balíček komplexních řešení, jejichž návrh, konstrukce a testování by zabralo nejméně několik dní. Použití opakovaně použitelných komponent Vám také umožňuje rychle vytvářet akce procesu. Mluvím zde jak o univerzálních postupech přítomných ve Framework, tak o těch připravených pro konkrétní aplikace, které jsou k dispozici v námi vytvořených knihovnách. Například již zmíněný TypeIntoElement a ClickElement poběží na každé webové aplikaci, zatímco NavigateFastPathJDE je procedura vytvořená výhradně pro zpracování rychlého tracku v JDE.

4.Lepší technická podpora SLA

Standardizace procesu vývoje robota zkracuje diagnostický čas v případě možného výskytu chyb. Toto má to dva důvody: Za prvé, ke konkrétním chybám může dojít pouze na určitých místech. Pokud připojení ODBC nefunguje, okamžitě víme, že problém by měl být hledán v oblasti „získat údaje o transakcích“. V důsledku toho se výrazně zkrátí čas potřebný k hledání místa problému. Za druhé, zavedli jsme jednotné chybové kódy pro všechny roboty a rozdělili je mezi ty, za které je zodpovědný obchod a na ty, které se objevují jako výsledky použitých aplikací. Pokud při sledování práce robotů vidíme zprávu jako je například „B0001“, je nám okamžitě jasné, že se robotovi nepodařilo přihlásit do aplikace, protože vypršela platnost hesla.

Jednoduše řečeno, implementace našeho vlastního modelu stavby robotů vede k tomu, že nové procesy jsou vytvářeny mnohem rychleji a bezpečněji, a snadno zapadají do jakékoli existující infrastruktury robotů u jakéhokoli zákazníka.

Author: Rafał Korporowicz – Senior RPA Developer

Foto: iStock

V roce 1983 se na obálce časopisu Times objevil robot, který veze na trakaři továrnu. Uvádí článek s názvem: Nová ekonomika. Článek je věnován prognózám v době recese a bankrotů v těžkém průmyslu, které předpovídaly snížení počtu dělníků. Byla to doba, kdy se začal rozvíjet průmysl v oblastech nových technologií, jako například mikroelektronika, laser, nebo genetické inženýrství. Vznikaly zcela nové oblasti vývoje, jako v případě společnosti Apple, která se právě tehdy transformovala z malé společnosti v garáži na silnou korporaci. V této době rostly obavy z rozvoje automatizace a možnosti nahrazení celých sektorů pracovišť dosud ovládaných člověkem roboty nebo automaty.

Koneckonců, člověk se automatiky bál už od spuštění prvních strojů. Možná jste zaslechli o ničení strojů v továrnách na počátku 19. Století. Šlo o dobře organizované hnutí takzvaných ludditů, kteří protestovali proti změnám ve způsobu jejich života a hrozbám, které přináší vynález a zavedení tkacích strojů. Noční útoky na tkalcovny, ničení strojů nebo zastrašování lidí ovšem nezvrátily proces industrializace, podobně jako zákaz používání pneumatických rozprašovačů uložený americkými odbory téměř o století později. Jasně se ovšem ukázalo, že strach z nového bude vždy doprovázet člověka, bez ohledu na dobu, ve které žije.

Čísla však ukazují, že mechanizace výroby vedla spíše k prudkému nárůstu, než ke snížení počtu pracovních míst. Například v USA v roce 1910 pracovalo v automobilovém průmyslu 140 tisíc lidí, zatímco v roce 1920, jak mechanizace postupovala, se počet pracovních míst zvýšil až na 250 tisíc a v roce 1930 už v tomto odvětví pracovalo 380 tisíc lidí.

Poté, co Carl Frey a Michael Osborn publikovali článek „Budoucnost zaměstnání: Jak náchylné jsou pracovní pozice k automatizaci?“ byla v roce 2013 dokonce vytvořena aplikace: WILL ROBOTS TAKE MY JOB?. Funguje dodnes a umí vypočítat pravděpodobnost, že vaši pracovní pozici nahradí roboti. Jste analytik počítačového systému? – pravděpodobnost, že bude vaše pozice nahrazena robotem je extrémně nízká, činí 0,7%. Pozice manažera nákupu, tedy zaměstnance pracujícího v oddělení nákupu velké společnosti, již má 98% riziko, přičemž v příštích dvou desetiletích dojde k dalšímu nárůstu o 59%. Riziko nahrazení analytika se v příštích 20 letech zvýší o jen 32%. Článek předpovídá, že nízké riziko nahrazení automatizovaným systémem se týká pouze jednoho ze tří pracovníků, zejména těch, kteří jsou zaměstnáni ve školství, zdravotnictví, dále pak umělců a manažerů na různých úrovních, a v neposlední řadě také IT profesionálů.

Jaké jsou ale vyhlídky pro následující roky?

Jak už jsme zmínili, strach z automatizace není novinka. Dnes se v důsledku automatizace některé skupiny zaměstnanců stávají nadbytečnými, ale současně se také vytvářejí nová pracovní místa (často lépe placená než ta, která zanikla). Obecně platí, že s výjimkou běžných obtíží v období transformace se celá situace spíše zlepšuje.

Podívejme se například na strojové učení a robotiku. Tato odvětví nacházejí způsoby, jak dělat stejné věci lépe, rychleji a levněji než specialisté, kteří bývali v tomto oboru zaměstnáni po celá desetiletí. Při takovéto konkrétní změně jsou zaměstnanci přesunuti do jiných rolí. A opět, stejně jako za průmyslové revoluce, je spíše nepravděpodobné, že přechodné období bude bezbolestné. Bude potřeba času, aby se lidé rekvalifikovali, a aby manažeři znovu objevili potenciál využití uvolněné pracovní síly. Dnes na to však mají mnohem méně času, než měli před stoletím. Změny totiž probíhají mnohem rychleji než kdy dříve a mají daleko širší dosah.

Vraťme se na závěr zpátky k článku z časopisu Time. Objevuje se v něm citát z roku 1950. Jde o názor Johna Diebolda, konzultanta managementu z New Yorku: „V různých dobách, obvykle v časech nejhlubší ekonomické recese, lidé vždy říkali, že kvůli automatizaci bude těžké dostat se z toho. Několik let později už je ale vše zapomenuto. Některá pracovní místa umírají a jiná zase rostou. To je znakem zdravé ekonomiky “. 71 let poté a stále není, co k tomuto tvrzení dodat…

Source: Will Robots Take My Job, Strach przed automatyzacją (Fear of Automation), https://en.wikipedia.org/wiki/Luddite, (TIME) The new economy

Autor: Monika Stawicka – Business Analyst

Vzpomínám si, jak všichni podnikatelé začínali pracovat s Whitelistem. A jak už to tak bývá, ze začátku vše probíhalo ve velkém chaosu. Někdy si říkám, jestli je vůbec nutné, aby každá změna musela takto začínat. A přitom, ve skutečnosti změny jsou dobré. Alespoň já mám rád, když se stále něco děje. Vraťme se ale zpátky k Whitelistu. Všichni byli nervózní a měli obavy, jak bude fungovat. Nakonec se ale ukázalo, že nic není tak horké, jak se uvaří. Po pravdě, Bond tuto frázi nikdy nevyslovil, ale jsem si jistý, že jí někde hluboko v sobě měl. Když jsem se potkal s Przemkem na kávě, pověděl mi trochu více o Whitelistu:

Jak to vidí expert:

 Od roku 2019 je v Polsku povinnost ověřovat obchodní partnery takzvaným Whitelistem. Jedná se o vládní seznam (vyhledávač) všech společností, který udává jejich status plátce DPH.

Na trhu jsou řešení, která umožňují hromadné dotazování databáze Whitelist pomocí API, ovšem jedná se o konkrétní řešení „šitá na míru“ danému zákazníkovi a systému ERP. Tato řešení také mají určitá omezení vyplývající přímo z ustanovení zákona, která se týkají maximálního počtu denních dotazů, které lze provádět, a také maximálního množství zpracovávaných dat (maximálně 300 záznamů).

V XELTO DIGITAL jsme vyvinuli vlastní způsob ověřování Whitelistu na základě automatizace vyhledávání na webu bez použití API.

Uživatel poskytne seznam daňových identifikačních čísel a/nebo čísel bankovních účtů obchodních partnerů. Poté robot každé číslo na stránce vyhledávače plátců DPH jedno po druhém zkontroluje a shromáždí potřebné informace, jako například: stav poplatníka, ověření, zda je číslo (čísla) účtu v seznamu ověřených účtů, datum vyhledávání a jedinečné ID. Dále pak robot tato data uloží do výsledného souboru, který lze kamkoliv uložit, anebo zákazníkovi zaslat e -mailem.

Na rozdíl od ostatních, již existujících řešení, je výhodou našeho řešení pro zákazníka jeho značná volnost v možnostech nastavení, která mu umožňuje přizpůsobit jej svým konkrétním potřebám.

Další velkou výhodou je obcházení limitů pro dotazy API, protože v našem řešení simulujeme přímo lidskou činnost, tedy otevírání webu a vyhledávání plátců „ručně“.

Pokud je proces automatizován pomocí uživatelského rozhraní, je pomalejší než odesílání dotazů prostřednictvím rozhraní API. I přesto je ale stále mnohokrát rychlejší, než by to udělal člověk, díky čemuž se můžete vyhnout limitu v počtu vyhledávání.

Technicky vzato, vývoj procesu vyžaduje, aby byla věnována pozornost volbám nastavení vyhledávacích tlačítek – po prvním hledání se tlačítko přesune na jiné místo na obrazovce, a přestože vypadá úplně stejně, jeho volba nastavení se v dalších dotazech liší. Pokud vstupní soubor obsahuje čísla DIČ i čísla bankovních účtů, v kódu robota by měl být seznam oddělen.

Robot nejprve zkontroluje bankovní účty, a teprve poté až čísla DIČ, čímž se vyhne zbytečnému přepínání mezi obrazovkami pro vyhledávání.

Autor: Przemysław Wal – RPA Developer

 

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?

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

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

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

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