Příklady použití dokonicase

Transkript

1 Aplikace dokonicase: Příklady použití dokonicase Vypracoval Petr Atanasčev, Lukáš Dziadek Datum 1. ZÁŘÍ 2016 Verze 2.0

2 OBSAH 1. Princip dokonicase Příklady použití Přijaté faktury Smlouvy Projektová dokumentace Objednávky Žádanky Dovolenky Plán výroby Zápisy z porad Reklamační řízení Další příklady... 8

3 1. PRINCIP DOKONICASE Jak se zpracovávají dokumenty v dokonicase? 1. Skenování Dokument je naskenován na multifunkčním zařízení, které umožňuje získat od uživatele další údaje (metadata). 2. Automatické vytěžení dokumentů Systém z dokumentu vytěží textové informace (OCR, ICR), čárové kódy nebo i strukturovaná data (zónové vytěžování). 3. Vstup do dokonicase Dokument vstupuje do dokonicase včetně všech získaných metadat, která mohou v systému určovat postup zpracování dokumentu. 4. Přiřazení informací o typu dokumentu a workflow změna vlastníka dokumentu, změna typu dokumentu, změna nebo úprava údajů Uživatelé doplní dokument o požadované indexy, přičemž systém zaznamenává, kdo a kdy doplnil jaké údaje, případně komu dokument předal. 5. Archivace inteligentní uložení dokumentů Dokument, který obsahuje požadované indexy, může být převeden do archivu v systému dokonicase. Pokud je to požadováno, může být dokument převeden do externího systému (ERP, DMS, apod.). Vysvětlivky workflow definovaný proces oběhu dokumentů OCR technologie pro rozpoznávání strojově psaného textu ICR technologie pro rozpoznávání ručně psaného textu vlastník dokumentu uživatel, který aktuálně zodpovídá za to, co se s daným dokumentem stane metadata nebo také indexy, jsou strukturovaná data, kterými je opatřen každý dokument a která umožňují pozdější vyhledání dokumentu v archivu. Vyhledávání podle indexů je mnohem účinnější než běžné fulltextové vyhledávání. Verze Princip dokonicase 3

4 2. PŘÍKLADY POUŽITÍ 2.1 Přijaté faktury Zákazník řeší problém s likvidací přijatých faktur. Problém způsobuje zejména neschopnost schvalovatelů a účtárny ověřit stav dokumentu v průběhu likvidace a také dlouhé trvání tohoto procesu. Likvidace faktur probíhala v papírové podobě. Po příchodu papírového dokumentu se dokument směřoval na účtárnu, kde byl předkontován a opatřen likvidační košilkou (razítkem). Dále se faktura předávala do osobních kastlíků zodpovědným lidem a mezi pobočkami byl předáván vnitropodnikovou poštou. Významná část faktur nebyla zlikvidována během splatnosti a vznikaly problémy s dodavateli včetně penalizací. Nebylo výjimkou, že některé faktury se ztratily úplně. Díky zavedení našeho řešení byl zrušen krok akontace - účtárna si nyní může kdykoliv ověřit existenci faktury i její stav v procesu likvidace. Do účetnictví se tak dostávají opravdu schválené faktury (účtárna nemusí řešit storna z důvodu jejich zamítnutí). Kromě toho se významně urychlil proces likvidace, běžný čas je nyní zhruba dva dny (oproti předchozím přibližně 9ti dnům). Navíc se významně snížil počet faktur ztracených jakmile totiž faktura vstoupí do dokonicase k procesu schvalování, již se neztratí Smlouvy Zákazník vydává smlouvy, které předává nebo odesílá zákazníkům k podpisu a potřebuje evidovat vrácení podepsané smlouvy zákazníkem. Velké množství vystavovaných smluv způsobovalo problémy v evidenci, sledování a případném dohledávání, zda firma disponuje vrácenou podepsanou smlouvou ve správné verzi. Vystavované smlouvy jsou hned v průběhu tisku opatřeny čárovými kódy, které nesou informaci, o jaký typ smlouvy se jedná, její číslo a verzi. Když se podepsaná smlouva vrátí od klientů zákazníka, je na kterémkoliv pracovišti naskenována a systém automaticky zajistí její správné zařazení do systému podle informací obsažených v čárovém kódu. Okamžitě po naskenování je možno smlouvu v systému dohledat a to i z dalších, napojených systémů, jakým je např. CRM Příklady použití Verze 2.0

5 2.3 Projektová dokumentace Zákazník pracuje na projektech, ke kterým se vážou dokumenty různého typu. Chybí přehledná evidence dokumentace k projektům. Je požadována možnost sledování stavu projektů. Před nasazením systému byly dokumenty evidovány buď v papírové podobě v šanonech k projektu, nebo v elektronické podobě ve sdílených adresářích a ech jednotlivých pracovníků. Nejednotná evidence způsobovala problémy při sdílení informací a měla vliv na komplikace v projektech. Nebylo možné spolehlivě přidělit přístup pouze pověřeným osobám. Veškeré dokumenty jsou nyní digitalizovány a ihned při vzniku nebo doručení zaevidovány ke konkrétnímu projektu. Přiřazením k projektu jsou jasně definována práva přístupu konkrétních osob a zatříděním dle typu dokumentu a dalších atributů je zajištěna snadná dohledatelnost nejen napříč projekty. K projektům je vedena evidence jejich fází a termínů, vázaná na existenci či stav konkrétního dokumentu, což umožňuje sledovat stavy a aktuální fáze jednotlivých projektů. 2.4 Objednávky Zákazník potřebuje evidovat vystavené objednávky tak, aby je bylo možné jednoduše přiřazovat k příchozím fakturám. Objednávky byly vystavovány pověřenými pracovníky jednotlivých oddělení. Vystavené objednávky byly schvalovány nadřízenými daných oddělení, případně za určitých okolností centrálně nejvyšším vedením. Po schválení byla objednávka zaevidována v centrální evidenci a odeslána dodavateli. Po příchodu faktury od dodavatele byla faktura buď spárována, nebo odmítnuta. Cesta objednávky po firmě byla nepřehledná a někdy velmi zdlouhavá. Pověřený pracovník zakládá objednávku v systému. Systém neumožňuje objednávku zadat, aniž by byly vyplněny všechny potřebné náležitostí. Takto vystavená objednávka je předána ke schválení. Proces předání je nyní jednoduchý, velmi rychlý a doba trvání jednotlivých kroků (zdržení u jednotlivých pracovníků) je snadno zjistitelná a vyhodnocovatelná. Zpracování objednávky se významně zrychlilo bez nutnosti popohánět jednotlivé osoby a celý proces se zprůhlednil. Vazba na přijaté faktury je jednodušší, než kdykoli předtím, a přesnější. 2.5 Žádanky Od nasazení systému se očekává sjednocení způsobů požadavků mezi jednotlivými odděleními, možnost evidence a dokladovatelnost. Verze Příklady použití 5

6 Běžný proces žádosti o cokoliv ve firmě existoval už odjakživa, stejně tak obecně existuje v mnoha podobách. Sledování průběhu jednotlivých žádostí bylo složité, ne-li nemožné. Po odevzdání žádanky neměl žádající žádnou kontrolu nad průběhem své žádosti. U žádanek, u kterých bylo nutné vyjádření více úseků nebo stupňů, nebylo možné kontrolovat, jak dlouho se žádanka kde zdržela. Statistické vyhodnocování žádanek (např. podle předmětu žádosti) bylo možné jen díky separátní evidenci, která byla náročná a nepřesná. Zavedením jednotného systému žádanek se situace velmi zpřehlednila a ujednotila. Žadatelé mají kdykoliv možnost se podívat, jaký je aktuální stav jejich žádanky, případně u koho se zdržela. Vedoucí pracovníci mohou vyhodnocovat efektivitu a rychlost vyřizování žádostí. Zavedení systému proběhlo bezproblémově, jelikož proces práce se žádankami je na všech úrovních prakticky totožný jako u donedávna používaného papírového. To, co přinesl nový systém, je zejména rychlost a transparentnost zpracování. 2.6 Dovolenky Ve firmě jsou používány papírové formuláře pro žádost o dovolenou. Jejich evidence je nepřehledná, schválení trvá dlouho a zatěžuje jak žádajícího tak schvalovatele. Žádající nemá přehled o stavu žádosti. Není možné schvalovat, pokud je schvalovatel na služebních cestách apod. Zaměstnanec žádající o dovolenou musel vyplnit formulář, který si nejprve nechal schválit od toho, kdo jej má zastupovat a poté od svého nadřízeného, že s dovolenou souhlasí. Potvrzenou dovolenku poté předával asistentce, která připravila přehled pro mzdovou účetní. Problém způsobovalo jak schvalování, které bylo zdlouhavé, tak následná evidence (otázky typu Má to schváleno, nebo nemá? ). Pomocí jednoduchého, elektronického formuláře zaměstnanec vyplní žádost a v systému předá ke schválení zastupujícímu. Ten zastupování odsouhlasí, případně odmítne a předá zpět žádajícímu nebo svému nadřízenému. Nadřízený dovolenku také buď schválí nebo odmítne a vrátí ji žadateli. Pověřená asistentka se může kdykoli podívat na všechny schválené (i neschválené) dovolenky za konkrétní období, např. podle oddělení a jednoduše zaslat přehled mzdové účetní. 2.7 Plán výroby Firma plánuje výrobu pomocí dokumentu, který schvaluje několik instancí. Od systému se očekává, že schvalování proběhne rychleji a přehledněji. Zejména při opakovaném schvalování. Firma používala pro plánování výroby soubor v Excelu, který připravil manažer plánu výroby. Tento plán rozeslal em a jednotliví vedoucí do něj zapisují připomínky. Nebylo možné sledovat, v jaké fázi je aktuální schválení plánu. Připomínky a reakce se dostávaly k zúčastněným pozdě Příklady použití Verze 2.0

7 Plán výroby je vytvářen pomocí příslušného typu dokumentu a je předáván k paralelnímu schválení všem zúčastněným. Ti se vyjadřují buď schválením nebo připomínkou, která je sledována jako samostatný typ dokumentu a je možno sledovat samostatně způsob reakce na připomínku. 2.8 Zápisy z porad Firma chce evidovat jednak zápisy z porad a zpřístupnit je jednoduše všem zainteresovaným, ale hlavně sledovat úkoly, které na poradách vznikají, včetně informací o jejich plnění. Zápisy vznikaly v elektronické podobě typicky ve Wordu. Jejich zpřístupnění bylo pomocí přímého sdílení tohoto souboru, což přinášelo problémy s definicí přístupových práv. Úkoly si museli jednotliví zaúkolovaní pracovníci vybrat sami, nebo jim je vybrala asistentka a zaslala em. Průběžné sledování plnění úkolů nebylo možné. Pomocí propojení dokumentů typu zápis s porady s úkoly, je možno zadávat přímo v zápisu úkoly konkrétním lidem a pak bud samostatně, nebo přes zápis z porady sledovat plnění úkolů. Zápis z porady je nyní dostupný spolehlivě a jednoznačně konkrétním lidem vždy v platné verzi. 2.9 Reklamační řízení Organizace v případě reklamace od svých klíčových zákazníků podniká kroky jednak k vyřízení reklamace, ale také k nápravě do budoucna. Chce, aby tento proces byl spolehlivě evidován v systému kvůli rychlosti i dokladovatelnosti. Systém má sledovat i plnění nápravných opatření. Pokud zákazník reklamoval dodávku zboží, vznikl dokument (v Excelu), který putoval firmou a jednotliví vedoucí oddělení se k reklamaci vyjadřovali. Sledování plnění nápravných opatření bylo velmi nesnadné a většinou se tak dělo až na základě opakované reklamace. Sumární vyhodnocování reklamací co do počtu a způsobu řešení muselo být prováděno ručně. Manažer systému kvality vytvoří dokument typu reklamační řízení, který má dané povinné údaje tak, aby bylo možno reklamaci vyhodnocovat a vyhledávat. Tento dokument je dán paralelně k vyjádření jednotlivým vedoucím a ti zadávají i návrhy na nápravná opatření. Tyto návrhy jsou sledovány jako samostatné dokumenty a pokud jsou přijaty, je sledováno jejich plnění. Verze Příklady použití 7

8 3. DALŠÍ PŘÍKLADY dokonicase lze nasadit pro evidenci a správu i dalších typů dokumentů a agend, mezi které např. patří: bankovní výpisy ceníky cesťáky daňová přiznání dodací listy (podepsané verze dokumentů) docházkové listy evidenční listy výrobku (průvodky) instalační protokoly korespondence (došlá pošta, odchozí pošta) likvidační protokoly nabídky nařízení personální dokumentace (doklady o vzdělání, školení, kvalifikaci, ) přepravní listy řízená dokumentace (interní směrnice a předpisy) vyhlášky (interní, nebo obecně platné právní předpisy) výpisy z obchodního rejstříku (dokumentace k obchodním partnerům) výrobní dokumentace (výkresy, postupy, ) zakázkové (servisní) listy záruční listy 8 3. Další příklady Verze 2.0