Analýza schvalovacího workflow Škody Auto a.s.

Účastnice DA: Barbara Havlíková, Lucie Smetanová

Mentor: Jaroslav Rys, Škoda Auto a.s.

„Rozhodli jsme se letět na Měsíc… Chceme letět na Měsíc a dokázat ještě víc. Ne proto, že je to snadné, ale právě proto, že je to obtížné.“

Tento citát Johna Fitzgeralda Kennedyho mi běžel hlavou několikrát denně od zahájení DA. Američané cíle dosáhli, my s Luckou to zvládneme taky.

Téma

Nápadů na téma projektu jsme měly mnoho, buď jsme vymyslely téma a pak sháněly volně dostupná data nebo to vzaly opačně, našly data a vymýšlely, co s nimi vytvořit. Naše nápady začínaly někde u analýzy ceny ropy a jejího vlivu na ceny pohonných hmot, přes analýzu uživatelů webu ČSFD až po tvorbu aplikace vyhledávání veřejných záchodků v centru Prahy. Samo hledání dat přineslo cenné informace, zjistily jsme například lokace odhalených varen a pěstíren v našem okolí, či které zvíře v ZOO Praha můžeme adoptovat.

Po exkurzi ve Škodě DigiLabu jsme se shodly, že by se nám dobře pracovalo s Jardou Rysem ze Škodovky, který nabízel hned několik mentorských projektů. S touto ideou a několika vlastními nápady (veřejné záchodky jsme nechaly doma) jsme šly na „meet your mentor“. S trochou obav před a trochu větší euforií po vše vyšlo a my se mohly těšit na analýzu schvalovacího workflow ve Škodovce.

Cíl

Předpokládaným přínosem má být buď potvrzení, že schvalovací workflow je nastavené správně a není další prostor pro zefektivnění nebo navrhnout, jak workflow zefektivnit, zkrátit a tím ušetřit čas a finanční prostředky.

Schvalovací workflow je proces, v rámci kterého zaměstnanci Škoda Auto žádají o různé záležitosti — vytvoření uživatele, zpřístupnění aplikace, průchod do závodu a podobně. Každý typ žádosti má svůj formulář, který má předdefinované schvalovací kroky (workflow) — pořadí schvalovatelů.

Použité nástroje

Data

Měly jsme štěstí a zatímco ostatní holky stále pátraly po datech nebo měly data teprve přislíbená, my jsme už měly v ruce vzorek dat, se kterými budeme pracovat. Vzorek obsahoval Excelovou tabulku záznamů z jednoho měsíce, a k tomu meta data. Prvotním cílem bylo trochu se v datech začít orientovat a případně si připravit dotazy na mentora. Takže trochu prvotního filtrování a hlavně pivotek (ty velké, lepší a cool nástroje nás ještě čekaly). Za týden jsme dostaly 20 měsíčních csv souborů, a to za období leden 2016 — srpen 2017.

Metadata
Vzorek dat v Excelu

Brzy jsme zjistily, že získaná metadata budou jedinou podpůrnou informací, kterou obdržíme, vše ostatní si musíme najít v datech samy. Neměly jsme k dispozici žádné vnitřní směrnice ani metodiky a popsané postupy k datům, které jsme měly analyzovat. Kdybychom tyto dokumenty měly, projekt by se možná odvíjel i dalšími směry. Postupem času jsme zjistily, že je to vlastně úžasné, kolik informací, příběhů, se z daných dat dá vyčíst. Jednu skříňku jsme otevřely a najednou tam byly příběhy další a další a taky další otázky.

Po první schůzce s mentorem jsme měly trochu víc jasno v tom, jak začít. Všechny tabulky někde nahrát a vytvořit z nich jednu, tu vyčistit a normalizovat. Normalizované tabulky nám pak budou sloužit jako píseček pro naši další práci. Dohodli jsme se také, že data budeme zkoumat analyticky i statisticky, Barča se zaměří primárně na vizualizace, Lucka na statistiku.

Jak na to?

Před tím, než jsme začaly něco někde nahrávat, musely jsme si data v hlavě nějak srovnat. Data byla tvořena několika základními prvky, prvním byl formulář, druhým jednotlivé případy — na každý případ jeden formulář, třetím pak schvalovací kroky každého případu spolu se schvalovateli. Takže čtyři tabulky? Ne, tři stačí, schvalovatele můžeme v našem případě nechat u kroků. Výsledek našich úvah (a kreslení) jsme zpracovaly ve Visiu.

Datový model s původními názvy sloupců

Dalším krokem bylo vytvoření jedné velké tabulky se všemi měsíci a aby se nám s daty lépe pracovalo, sloupečky jsme si přejmenovaly. Dále jsme zvažovaly, zda tabulky nahrát do Snowflaku přes Keboolu nebo napřímo, nakonec jsme je nahrály napřímo a vše prošlo víceméně hladce. Důvodem našeho rozhodnutí byl fakt, že data byla v jednom datovém formátu, nebyla tedy potřebná transformace. Přípravnou tabulku jsme si vytvořily takto:

Pak začaly nahrávat tabulky podle návodu z hodiny SQL a podle doporučení nahrávaly s podmínkou, že se soubory mají nahrát pouze pokud neobsahují žádnou chybu. Neprošlo to, zvýšily jsme tedy počet povolených chyb na 1 a vše se nahrálo. Zkoušely jsme chybu najít, ale nenašly ani s pomocí rádců. Nahrávaly jsme pak přes volbu “nahrát pouze validní data”, počet řádků jsme testovaly se zdrojovými daty a nahrály se všechny řádky. Tímto jsme data prohlásily za nahraná.

Dalším krokem bylo data vyčistit. Pro účely naší analýzy bylo potřeba smazat všechny záznamy, které se týkají formuláře docházky, docházkovým formulářem procházejí každý měsíc všichni zaměstnanci a v téměř 100 % případů je schválený automaticky (dle informací od mentora). Nejedná se tak o statisticky zajímavou informaci. Dále nám mentor doporučil spojit všechny záznamy obsahující datum a čas v jeden sloupec a záznam ručního vložení kroku z „X“ na 1 a 0, kde „X“ nebude, aby se vše lépe počítalo. Skript vypadal takto:

Jakmile byla tabulka vytvořena, myslely jsme si, že je vše hotovo, máme čistá data a můžeme vytvořit tři normalizované tabulky:

a plnit je:

Vše se zdálo hotové, SQL nic červeně nenamítalo a my byly spokojené. Do té doby, než jsme data začaly testovat. Objevily jsme, že jsou případy, které nezačínají prvním krokem, to nás vedlo k otázce, jestli nemáme také případy, které sice prvním krokem začínají, ale chybí mezikroky, takže jsme začaly hledat chyby, které bychom původně nečekaly. Další obavy nastaly se sloupci, u kterých jsme povolily NULL hodnoty, což bylo v pořádku, například pro automaticky schválené, či zamítnuté případy schvalovatel být nemusí nebo nemusí být ve všech krocích. Co když ale existují případy, kde hodnota NULL být nemá? A tyto případy jsme také našly, byly spojeny s chybějícími schvalovateli.

Po poradě s mentorem jsme případy s chybějícími kroky a schvalovateli smazaly pomocí skriptu níže. Jejich počet nedosáhl ani jednoho procenta všech našich dat a proto jsme usoudily, že nám jejich smazání nebude při analýze narušovat výsledek.

Tabulky jsme „vysypaly“ a znovu naplnily čistými daty a vizualizovaly náš datový model.

Upravený datový model v Power BI

Statistika

(Lucka)

V tento okamžik se měla naše práce rozdělit na deskriptivní a analytickou část, ale rozhodně to neznamenalo snížení efektivity naší spolupráce, spíše naopak.

Po zjištění, že by mentor rád viděl v projektu statistiku, jsem se zaradovala, protože jsem se statistikou již pracovala a říkala jsem, že si rozšířím obzory a něco nového se naučím a využiju všechny ty knihy o statistice, co mám v knihovně. Po prvotní deskripci dat jsem začínala mít nápady. Chtěla jsem řešit závislosti mezi daty. Až hodně později jsem si začala ujasňovat konkrétní hypotézy.

K závěrům, ke kterým jsem došla, byla cesta velice trnitá a posetá stresem, ale i to byla veliká zkušenost.

Najednou jsem narazila na velice tvrdou zeď. Většina mých zkušeností se statistikou byla s časovými řadami, kde jsem dělala korelace, regrese, predikce a korelační matice. Ale já přeci nemám časové řady. Najednou jsem nevěděla, jak mám své znalosti aplikovat na naše data. Začala jsem tedy studovat, zkoušet na zkušebních tabulkách co jsem si vytvářela ze zaslaného vzorku dat od mentora a pak již na selectech ve Snowflaku. Nic…. v hlavě jsem jen měla, jak aplikovat statistiku na časové řady a byla jsem v kocích. Pokračovala jsem tedy v deskripci dat a vymýšlet jakou statistickou metodu mohu využít. Po další schůzce s mentorem jsem dostala doporučení, co si mám dále nastudovat a asi jakým směrem bych se měla ve statistice směřovat. Takže další knihy a další články o statistice. Už jsem měla pocit, že všichni statistiku umí, jen já jediná jí nerozumím. Když už jsem měla nápad, co s daty udělám, tak po vyzkoušení se mi zase můj nápad rozplynul.

Nápad přišel…… obrátit se na odborníka, kterého znám několik let a je to výborný statistik, statistiku vyučuje a živí se s ní. Velké díky Marinu Rybářovi, protože je to velice vytížený člověk a udělal si na mě hodinu svého drahocenného času.

Když jsem přišla k Marianovi a ukázala jsem můj vzorek dat tak se dost podivil jako, jakouže statistiku na těchto datech chci dělat. Začala jsem mu vysvětlovat, co jsem na začátku v datech viděla a jaký bych nejraději viděla výsledky. Tak jsme začali pracovat a objasňovat si co v datech opravdu vidím a co z nich chci a můžu vyzkoumat a jaký použít nástroj.

Tady musím napsat, že k závěrům, ke kterým jsem docházela, mě naprosto zklamávaly a byla jsem z toho rozčarovaná, že mi vlastně nic „nevychází“. Očekávaly jsme něco převratného, co statistikou v datech objevíme.

Statistkou jsem chtěla dojít k závěrům, jaké máme závislosti v datech. A moje otázky a hypotézy byly:

Závisí délka schvalovacího procesu na typu formuláře?

Závisí délka schvalovacího procesu na schvalovateli?

Závisí délka schvalovacího procesu na dni vložení požadavku?

Závisí délka schvalovacího procesu ručně vloženém příznaku?

Závisí délka schvalovacího procesu na počtu kroků ve schvalování?

S Marianem jsme se dohodli, že bude pro naše data vhodné použít metodu Anova a z důvodu časové tísně využít nástroj R commander, který je hojně využíván studenty statistiky. V R commander jsem začala zkoušet a bádat a tady je ukázka mých výsledků.

Jednofaktorová Anova

V rámci jedno faktorové Anově jsem zkoušela, zda závisí délka schvalovacího procesu na typu formuláře. A vyšlo mi „ANO“.

Dále jsem stejným způsobem zkoušela, zda závisí délka schvalovacího procesu na příznaku vložení. A opět mi vyšlo, že „ANO“.

A naposledy jsem si vyzkoušela, zda závisí délka schvalovacího procesu na dni vložení požadavku. A opět vyšlo, že “ANO”.

V rámci dvou faktorové Anovy jsem zkoušela, zda závisí délka schvalovacího procesu na typu formuláře a dni vložení požadavku a potvrdil se mi stejný závěr jako v jedno faktorové Anově, že „ANO“. Předchozí analýzy mi tedy potvrdily očekávání, ale nepoukázaly na žádnou anomálii.

Dvoufaktorová Anova

Jak jsme se víc a víc orientovaly v datech a začaly dělat selecty na propojování tabulek najednou jsem mohla porovnávat číselnou k číselné proměnné a zkusila jsem využít jednoduchou lineární regresi, ale tady mi nevycházelo nic statisticky zajímavého. Například jsem chtěla vysvětlit: „délku schvalovacího procesu je možno pomocí lineární regrese vysvětlit z … % pomocí např. typem formuláře, dnem vložení požadavku“.

Nakonec jsem ještě zkusila Chí-kvadrát test, kde mi vyšlo, že typ formuláře závisí na dnu v týdnu. Tato informace by mohla vést na další hypotézu: Každý typ formulář závisí na dnu v týdnu. Pokud ano (o čemž pochybuji), pak by se zkoumání mohlo vést diferencí ve schvalování přes dny v týdnu. Pokud ne, mohly bychom rozdělit formuláře do dvou skupin — nezávislé na dnu v týdnu a naopak. Tím bychom vlastně získali další kritérium, navázané na typ formuláře.

Chí-kvadrát

Tak a co teď s tím. Už mi začínalo docházet, že moje výsledky ze statistiky nebudou závratné a neobjevím s nimi v rámci tohoto projektu s velice krátkým časovým limitem nic závratného. Tudíž moje závěry jsou takové:

“V rámci základního statistického zkoumání nebyly nalezeny žádné anomálie a mým doporučením je vytvoření důsledné popisné statistiky. Poté by se pokračovalo dalším zkoumáním, a to například vlivu dne zadání požadavku.”

Vizualizace

(Barča)

Už v průběhu zpracování dat jsem uvažovala, jak s vizualizací začít, bála jsem se, že se v datech ztratím. Začala jsem tedy základními počty, malý graf pro data, která jsme smazaly a pak celkové počty formulářů, případů, kroků a schvalovatelů. Užitečnou informací také byl základní popis vzájemných vztahů: každý požadavek/formulář má své jedinečné číslo případu, automaticky stanovený počet schválení (kroků), který může být navýšen manuálním vložením dalšího kroku - schvalovatel si může své schválení podmínit schválením jiného schvalovatele. U případů, které jsou schvalovány automaticky schvalovatel logicky není.

Základní údaje o datech za období: 90 formulářů, 304092 případů, 469905 kroků, 3561 schvalovatelů

K další vizualizaci jsem se snažila přistupovat systematicky, všechny prvky procesu jsou spojené s formuláři, jde tedy spíš o úhel pohledu.

První část: případy. První grafy ukazují, jaké formuláře tvoří silnou čtyřku, tedy formuláře s počtem případů nad 20000 ( (viz. graf „number of cases per form) za období, ale také, kde se početně nachází většina formulářů (průměr: 3380, medián: 940). Poslední částí se rozložení výsledků případů, jestli byl schválen, schválen automaticky, zamítnut či pozastaven. Pouhým okem jde vidět, že většina případů má šťastný konec.

KLIKNĚTE ZDE PRO CELÝ REPORT

Zkoumala jsem také počty případů v jednotlivých měsících

Počty případů v jednotlivých měsících

a jejich procentuální část z celkového období , je zřejmé, že nejsilnější byl leden 2017, nejslabší oba července, což je logické, v této době bývá ve Škodovce závodní dovolená.

Dále jsem se zaměřila na dva formuláře, které měly záznamy, že jsou automaticky schvalovány, formulář přihlášky ke vzdělávání (REQ-PRIHL) je přitom početně nejsilnější. Předpokládala jsem, že tyto formuláře byly během zkoumaného období zautomatizovány, což by vysvětlovalo fakt, že některé byly schváleny automaticky, některé schváleny či zamítnuty schvalovatelem. Podle časových údajů tomu tak ale není. Při pohledu na počet automatických a schválených formulářů proti počtu zamítnutých je logická otázka, proč jsou některé formuláře schvalovány automaticky a některé procházejí schvalovacím procesem.

Dále jsem se zaměřila na trvání případů, tedy časový horizont, který vede k jejich uzavření (schválení nebo zamítnutí). Z grafu je vidět, že nejdelší průměrná doba schválení je 38 dnů u formuláře ZMPDFORM. Proč tomu tak je nevyčteme ani z jeho popisu “PD formulář”, je to však formulář, který se v našem období vyskytl pouze 5krát. Silná čtyřka se drží do 4 dnů, s vyjímkou SKONETU 3901 (žádost o přidělení přístupu do zón), který má průměr 6 dnů a medián všech se drží okolo jednoho dne.

Přidávám ještě maxima formulářů, případy s nejdelší dobou mezi vznikem případu a jeho vyřešením.

Druhá část: kroky případů

Zde jsem se nejdřív zaměřila na rozložení případů, respektive formulářů v jednotlivých krocích, jinými slovy kolika schvalovatelů je potřeba na schválení případu/formuláře. Z grafu níže je vidět, že 65% případů končí v prvním kroku, do druhého se jich dostane jen 23% a do dalších kroků už méně než 10% případů.

Zajímavé bylo také zkoumání, které kroky jsou nejvíce zatíženy manuálním vložením (schvalovatel podmíní své schválení schválením jiného schvalovatele). První krok je logicky nulový, je vložen do systému žadatelem, z grafu je pak zřejmé, že nejvíc zatížen je krok 2, dále pak krok 4.

Nakonec jsem zkoumala, na kterých krocích je nejvyšší procento zamítnutí. Zvýšené množství je zřejmé u kroku 2 a pak od kroku 8.

Třetí část: schvalovatelé. Hned první dashboard ukazuje, kdo má se schvalováním nejvíc práce, je to 50039961 (konkrétní jména schvalovatelů nebyla na základě ochrany osobních údajů poskytnuta), který/á pracoval/a na neuvěřitelných 14129 případech, to je 706 případů měsíčně. Dále jsem u každého schvalovatele zkoumala počty schválení a zamítnutí, počty případů, kdy byli manuálně požádáni o rozhodnutí, ale také, kolikrát sami své schválení podmínili schválením jiného schvalovatele.

KLIKNĚTE ZDE PRO CELÝ REPORT

Porovnávání faktů v absolutních číslech nemá vždy správnou vypovídací schopnost, zkoumala jsem tedy i poměrově. Nejprve procento schválených případů. Tady jsem si schvalovatele omezila na ty, kteří se účastnili více než 100 případů. Na prvním místě tady stojí schvalovatel, který schválil pouze 15 % všech svých případů (měl jich více než 500). Pro lepší představu jsem si schvalovatele rozdělila do tří skupin (A, B, C), cluster je popsán v grafu a z tohoto rozdělení vyplývá, že téměř 100 % schvalovatelů schvaluje více než dvě třetiny svých případů.

PRO CELÝ REPORT KLIKNĚTE ZDE

Pak jsem zkoumala schvalovatele, kteří jsou manuálně žádáni o schválení, opět rozdělení na třetiny. Z výsledku vyplývá, že 89% schvalovatelů je požádáno o schválení nad rámec standardního workflow pouze v 1/3 svých případů a jen 9 % schvalovatelů bylo požádáno ve více než 2/3 svých případů.

Z druhé strany, 98 % schvalovatelů požádalo o extra schválení v méně než 1/3 svých případů a pouze 17 schvalovatelů (skupina C) požádalo o extra schválení ve více než 2/3 svých případů.

Další otázkou bylo, jak rychle schvalovatelé případy řeší. Průměrná reakční doba (bez ohledu na schválení či zamítnutí) je 2,73 dne, skupina A v grafu reprezentuje schvalovatele, kteří schvalují průměrně či nadprůměrně, skupina B jsou pohodáři a reagují v čase delším než průměrném. Největší pohodář má průměrný čas 125 dnů. Největší pracant, 50039961, pracuje průměrným časem 1,6 dne na případ.

PRO CELÝ REPORT KLIKNĚTE ZDE

Další zajímavé zkoumání bylo porovnání reakční doby vedoucí ke schválení vůči době vedoucí k zamítnutí. Z grafu je zřejmé, že se rychleji schvaluje než zamítá, ale i tady je pár výjimek mezi schvalovateli.

Poslední částí, kterou jsem zkoumala byl fakt, že někteří schvalovatelé se některých případů účastnili dvakrát i vícekrát na různých krocích. Logicky jsem neviděla důvod, proč by tomu tak mělo být. Nejvíc je tímto úkazem ovlivněn formulář CC_INTUSER (žádost o přidělení přístupu do SAP pro interní zaměstnance), následován CC_EXTUSERem. Z hlediska schvalovatelů vede 110701 následován 43643.

Výstup naší analýzy a z ní plynoucí doporučení pro firmu:

Oběma postupy (statistikou i vizualizací) jsme došly ke stejným závěrům, neobjevily jsme dosud žádný rozhodující faktor, jehož nápravou by došlo k výraznému zefektivnění procesu. Kdybychom znaly pozadí zkoumaného data setu, byly bychom schopny vyvodit širší statistické závěry. V rámci vizualizace jsme objevily jednotlivosti, které mohou být významné.

Podněty k zamyšlení pro Škodovku:

  • Formuláře REQ-PRIHL a VZD_CNC zautomatizovat kompletně, nicméně dát prostor schvalovatelům žádost v případě potřeby zamítnout. Nastavil by se limit, po jehož uplynutí by žádost byla automaticky schválena. Limit pro zamítnutí navrhujeme dva dny pro REQ_PRIHL (průměrná reakční doba za naše období 1,83 dne) a jeden den pro VDZ_CNA (průměrná reakční doba za naše období 0,26 dne). Po odfiltrování těchto častých formulářů ze zkoumání mohou vyjít najevo zajímavé odchylky u méně často zastoupených požadavků (viz graf case_number over the whole period.
  • Ovlivňují schvalovatelé s vysokým počtem zamítnutých případů procesy ve Škodovce (například schvalovatel 73939)?
  • Jak významně ovlivňuje procesy ve škodovce fakt, že 9% schvalovatelů je ve více než dvou třetinách svých případů dodatečně (manuálně) přizváno do schvalovacího procesu?
  • Zjistit důvody dlouhé reakční doby některých schvalovatelů a opět vliv na procesy.
  • Jsou objektivní důvody (pozadí) faktu, že někteří schvalovatelé schvalují výrazně pomaleji, než zamítají?
  • Zjistit důvody (pozadí) faktu, že se někteří schvalovatelé účastní některých případů vícekrát, jsou opakovaně žádáni o vyjádření.
  • Obecně stanovit a nastavit lhůty u jednotlivých kroků (i celkově u formulářů) pro vyjádření a následně měřit zpoždění.

V rámci naší práce jsme vesměs nacházely anomálie, jednotlivosti, které mohou procesy zpožďovat. Další postup bychom zaměřily na vytipování podskupin formulářů a zkoumaly jednotlivé skupiny odděleně. Faktory roztřídění do skupin by byly poměr schválených/zamítnutých formulářů, počet ručních vložení do systému, délka schvalování a počet případů na formulář. Další práce by mohla začít třeba takto (graf znázorňuje formuláře a jejich polohu při porovnání procenta schválení a počtu manuálních vložení:

Závěrem bychom chtěly poděkovat našemu mentorovi Jardovi, který se námi ochotně scházel a vedl nás.

Moc bychom chtěly poděkovat našim rodinám a přátelům za pochopení, že jsme pro ně na tři měsíce zmizely z povrchu zemského. Těšíme se na návrat.

Barča a Lucka