Bankovní institut vysoká škola
Implementace DMS v pojišťovnictví
Diplomová práce
Jan Vlček
Červen 2013
Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Implementace DMS v pojišťovnictví
Autor:
Jan Vlček Informatika a management
Vedoucí práce:
Ing, Doc. Bohumil Miniberger, Csc.
Prohlášení Prohlašuji, ţe jsem tuto diplomovou práci zpracoval samostatně a za pouţití literatury uvedené v seznamu. Svým podpisem stvrzuji, ţe odevzdaná práce v elektronické podobě je identická s tištěnou verzí, která bude archivována v knihovně BIVŠ a bude přístupná
třetím
osobám
prostřednictvím
interní
databáze
elektronických
vysokoškolských prací.
JanVlček
Poděkování Rád bych upřímně poděkoval svému vedoucímu práce Ing. Doc. Bohumilu Minibergerovi, CSc, Za jeho odborné vedení, věcné připomínky, a také za velkou ochotu a vstřícnost, kterou prokázal při vedení této práce. Taktéţ bych chtěl poděkovat své rodině a nejbliţším lidem v mém okolí za psychickou podporu.
Anotace Práce se zaměřuje na popis celého procesu implementace document management systému v organizaci, která se věnuje poskytování pojišťovnických sluţeb občanům na území české republiky. Hlavním zaměřením praktické části je zdokumentování výběru a následné implementace systému, který usnadní zpracování dokumentů a zprůhlední nakládání s nimi.
Klíčová slova: dokument, proces, implementace, document management systém
Annotation The thesis focuses on description of document management system implemeting in an organization dedicated to providing insurance services to citizens in Czech republic. The main focus of the practice part is document selection and subsequent implementation of a system to facilitate processing documents and transparent management. Key words: document, proces, implementation, document management system
OBSAH 1
VYMEZENÍ POJMŮ DMS.................................................................................................................................. 7 1.1 ECM – ENTERPRISE CONTENT MANAGEMENT ................................................................ CHYBA! ZÁLOŽKA NENÍ DEFINOVÁNA. 1.2 DMS PRO SPRÁVU A OBĚH DOKUMENTŮ ....................................................................................................................... 8 1.3 DOKUMENTY A JEJICH SPOJENÍ S PROCESY ...................................................................................................................... 8 1.3.1 Základní funkcionalita DMS ........................................................................................................................ 9 1.3.2 Oblasti využití DMS systémů ..................................................................................................................... 10
2
NÁROKY NA PROVOZ DMS ............................................................................................................................11 2.1 TYPY VYTĚŽOVANÝCH FORMULÁŘŮ ............................................................................................................................. 15 2.1.1 Ruční zpracování ....................................................................................................................................... 18 2.1.2 Ostatní formuláře .................................................................................... Chyba! Záložka není definována. 2.1.3 Nestrukturované dokumenty ................................................................... Chyba! Záložka není definována. 2.1.4 Souhlas s převodem .................................................................................................................................. 22 2.1.5 Seznam dokumentů pro archivaci............................................................................................................. 22 2.1.6 Definice logických kontrol a kontrol proti databázím v rámci OCR .......................................................... 23 2.1.7 Zpracování klonů formulářů ..................................................................................................................... 25
3
POPIS DMS ............................................................................................... CHYBA! ZÁLOŽKA NENÍ DEFINOVÁNA. 3.1 VRSTVA ÚLOŽIŠTĚ .................................................................................................................................................... 26 3.2 APLIKAČNÍ VRSTVA .................................................................................................................................................. 27 3.3 PREZENTAČNÍ VRSTVA .............................................................................................................................................. 27 3.4 POPIS KOMPONENT A ŘEŠENÍ VE VZTAHU K OBJEDNATELI ................................................................................................ 27 3.4.1 Vystavování dokumentu .......................................................................... Chyba! Záložka není definována. 3.4.2 Jednoznačný identifikátor ......................................................................................................................... 28 3.4.3 Podpora volání služeb s delegovaným oprávněním .................................................................................. 28 3.4.4 Rychlost vystavení dokumentu ................................................................................................................. 28 3.4.5 Konverze do TIFF ....................................................................................................................................... 29 3.4.6 Archivace vložených dokumentů .............................................................................................................. 29 3.4.7 Migrace .................................................................................................... Chyba! Záložka není definována. 3.4.8 Logování, audit ........................................................................................ Chyba! Záložka není definována. 3.4.9 Verzování ................................................................................................. Chyba! Záložka není definována. 3.4.10 Komponenta OMS ................................................................................................................................ 32
4
INTEGRACE SYSTÉMŮ ....................................................................................................................................34 4.1 SCAN ................................................................................................................................................................... 38 4.2 OMS.................................................................................................................................................................... 38 4.2.1 Vygenerování a odeslání dokumentu ....................................................................................................... 38 4.3 ETAPA SCAN ....................................................................................................................................................... 41 4.4 ETAPA DS ............................................................................................................. CHYBA! ZÁLOŽKA NENÍ DEFINOVÁNA. 4.5 ANALÝZA POŽADAVKŮ NA TCP.................................................................................... CHYBA! ZÁLOŽKA NENÍ DEFINOVÁNA. 4.6 ANALÝZA POŽADAVKŮ NA INTERFACE .......................................................................................................................... 44 4.6.1 Tvorba návrhu řešení ............................................................................... Chyba! Záložka není definována. 4.6.2 Projektové řízení (nejsou jednoznačně definovány etapy a fáze projektu), ............................................. 46 4.6.3 Fáze realizace ........................................................................................................................................... 47 4.6.4 Servis a podpora ....................................................................................................................................... 48 4.6.5 ETAPA OMS ............................................................................................................................................... 48 4.6.6 Kroky před instalací .................................................................................................................................. 50 4.6.7 Instalace .................................................................................................. Chyba! Záložka není definována. 4.6.8 Potřebná součinnost ................................................................................................................................. 51 4.6.9 Rozsah řešení komponenty OMS .............................................................................................................. 54 5
4.6.10 4.6.11 4.6.12 4.6.13 4.6.14 4.6.15 4.6.16 4.6.17 4.6.18 4.6.19 4.6.20 4.6.21 4.6.22 4.6.23
Dávkové zpracování ............................................................................................................................. 55 OnDemand zpracování......................................................................................................................... 56 Distribuce různými výstupními kanály a jejich kombinacemi ............................................................... 57 Interaktivní dokument.......................................................................................................................... 58 Interaktivní dokument jako prostředek pro opravu dokumentu v dávce ............................................. 58 Archivace dokumentů .......................................................................................................................... 58 Tisk dávky u tiskového providera ......................................................................................................... 59 Specifikace a vývoj nové šablony ......................................................................................................... 59 Přílože .................................................................................................................................................. 59 Spojování zásilek .................................................................................................................................. 60 Šablona v šabloně ............................................................................... Chyba! Záložka není definována. Šifrování ............................................................................................................................................... 61 Marketingová sdělení .......................................................................................................................... 61 Statistiky .............................................................................................................................................. 62
5
ZÁVĚR ...........................................................................................................................................................63
6
POUŽITÁ LITERATURA ...................................................................................................................................64
6
Úvod a cíl práce Cílem práce je popis kompletního nasazení document management systému pro organizaci zabývající se poskytování pojišťovacích sluţeb působící na českém trhu. Práce uvádí a specifikuje všechny potřebné kroky a postupy, které se musí pro projekt tohoto charakteru vykonat. V dnešní době se téměř ţádná organizace neobejde bez kvalitního document management systému. Vůbec nezáleţí na její velikosti a vlastně ani na primárním zaměření, protoţe dokumenty typu faktury, dodací listy, vnitropodnikové směrnice se vyskytují všude a je třeba s nimi nakládat, tak aby nedošlo k jejich ztracení a například u faktur k jejich neproplacení, coţ můţe vézt k problémům v dodavatelských vztazích. Právě faktor ztráty důleţitých dokumentů dokáţe tyto systémy eliminovat téměř na minimum. V první kapitole jsem se zaměřil na specifikování a vymezení pojmů document management systému. Jsou zde uvedeny některé příklady těch nejpouţívanějších systémů patřících do této kategorie. Také zde popisuji základní funkcionality, které jsou pro tento druh systémů specifické. Kapitola druhá je věnována bliţší specifikaci poţadavků na systém, jeho jednotlivých sekcí dodávaného řešení ze strany objednatele systému, který následně slouţí jako podklad výběru vhodného řešení uspokojující veškeré poţadavky. Třetí kapitola popisuje dodávaný systém a jeho jednotlivé komponenty, které jsou v rámci celé dodávky implementovány a customizovány dle potřeb organizace. V kapitole čtvrté uvádím integraci systému na základě shrnutých poţadavků před fází implementace. Celý proces integrace bude řízen procesně a to tak, ţe bude sestávat ze dvou etap. Jedná se o etapu SCAN a o etapu
DS. V kaţdé z těchto etap bude definována
zodpovědnost za její plnění a realizační výstupy.
6
1 Vymezení pojmů DMS S pojmy jako je DMS neboli document managenet system se setkáváme na našem trhu poměrně dlouhou dobu. Postupem let se tyto systémy stále více dostávají do popředí zájmů. Jedním z důvodů proč se tak děje je velký nárůst mnoţství dat, jednotlivých informací a dokumentů v organizacích. Tyto data musí být zpracovány v co nejkratším časovém intervalu, protoţe jednotlivé firmy jsou nuceny uspokojit potřeby zákazníků ve velmi krátkém časovém horizontu. Další neméně podstatnou oblast, kterou lze DMS efektivně řešit jsou rostoucí poţadavky legislativního typu. Tlaky legislativy kladou velké poţadavky na archivování veškerých dat a dokumentů spojených s podnikáním. Činnost kaţdé organizace musí být dlouhodobě zpětně prokazatelná a transparentní. Toho docílíme jedinou moţnou cestou, a to bezpečným uchováváním potřebných dat a dokumentů.
1.1 ECM – enterprise content management Systémy Document management systém (dále jen DMS) netvoří jiţ oddělené samostatné systémy, jako tomu bylo v dávných dobách počátků DMS, ale staly se součástí takzvaných ECM, neboli enterprise content management technologií.
Obrázek 1 Schéma komplexního řešení enterprise content managementu Zdroj: http://www.systemonline.cz/casopis/2004/04_11Ixt01X.jpg
7
ECM je souborem nástrojů a technologických prvků, které ve svém propojení slouţí k distribuci, zpracování, ukládání, sdílení a publikování informací bez ohledu na jejich formát (naskenovaný papír, email, hudba, video atd.). Do nástrojů ECM lze také zařadit systémy pro správu dat a informací v prostředí Internetu a intranetu (WCM – web content management).1
1.2 DMS pro správu a oběh dokumentů Vesměs všechny činnosti probíhající ve firmách jsou více, či méně spojené s dokumenty. Správa a nakládání s jednotlivými dokumenty je oblast, která výrazně ovlivňuje chod a v konečném důsledku celkový výsledek a efektivitu organizace. Všichni lidé ve firmě bez ohledu na její velikost pracují s určitým typem dokumentů. Tito lidé po nějaké době zjistí, ţe musí vyvíjet značné úsilí, pokud si přejí zajistit, aby byl v dokumentech řád a aby byly sdílené, tedy přístupné všem, kterým mají být. Celý proces je sloţitější ve fázi, kdy má například s jedním dokumentem pracovat větší počet osob. Proto je nutné sledovat celou historii nakládání s dokumenty, evidovat zásahy v dokumentech a jejich verzování. Všechny výše uvedené činnosti a negativní důsledky z nich pramenící lze do velmi značné míry eliminovat, nebo dokonce trvale odstranit vyuţíváním systému pro správu a oběh dokumentů DMS.
1.3 Dokumenty a jejich spojení s procesy Za prvé je určitě dobré říci, ţe dokument jako jeden z pojmů v oblasti DMS systémů není jen klasický papír s určitým textem, jak je zná většina lidí. Dokument je také soubor v elektronické podobě bez ohledu na jeho formát. Mezi nejčastější formáty, se kterými se můţeme setkat, jsou formáty MS office aplikací, s nimiţ pracuje většina administrativních pracovníků v kancelářích. Elektronický dokument můţe být také například email, zvukový záznam, technický výkres, fax, atd. Tyto objekty jsou nositelé informací, které jsou modifikovány, sdíleny a ukládány. Všechny dokumenty lze rozdělit na strukturované a nestrukturované. Strukturované jsou ukládány v podobě tabulek a databází. Tyto typy lze následně velmi dobře elektronicky zpracovávat. Nestrukturované dokumenty jsou jejich přesným opakem. Abychom mohli nestrukturované typy dokumentů vůbec ukládat, vznikly
1
http://www.systemonline.cz/clanky/dms-systemy-pro-spravu-a-obeh-dokumentu.htm
8
1
systémy DMS. Dokumenty nestrukturované nesou velice důleţité informace, které je třeba efektivně zpracovávat. Proces zpracování dokumentů v souvislosti s firemními procesy se stává za podpory DMS mnohem rychlejší a efektivnější. Pro pouţívání DMS systémů také jednoznačně hovoří fakt, ţe mezi mnoţstvím výše uvedených zpracovávaných typů dokumentů a informací ve firmách je zastoupeno 10% strukturovaných oproti 90% nestrukturovaných informací.
2
1.3.1 Základní funkcionalita DMS Hlavním principem DMS je efektivně spravovat a sdílet dokumenty, nebo informace. Toho je v první řadě docíleno implementací bezpečného uloţiště. Nad tímto uloţištěm běţí aplikace DMS, která nabízí koncovým uţivatelům širokou platformu funkcionalit pro zpracování dokumentů, také přístup k jednotlivým informacím a dokumentům na základě definovaného autorizačního konceptu, čímţ je zamezeno zneuţívání informací. Mezi základní rysy DMS patří: -
Organizování dokumentů do přehledných struktur
-
Automatizované řízení verzí a revize dokumentů
-
Umoţnění práce více uţivatelům s jedním dokumentem
-
Vytváření a podpora standardizovaných dokumentů
-
Tvorba dynamických pohledů na dokumenty
-
Elektronické schvalování dokumentů
-
Spravování firemních šablon dokumentů
-
Evidování historie práce s dokumenty
-
Publikace na intranet
-
Podpora převodu dokumentů do elektronické podoby (skenování)3
Existuje řada systémů DMS a způsobů přístupu k nim. V případě potřeby lze DMS integrovat zcela do prostředí hostitelských aplikací, jako je například ERP systém SAP nebo CRM systémy Siebel, SAP CRM, jak je znázorněno na obr. 2.
2 3
http://www.systemonline.cz/clanky/dms-systemy-pro-spravu-a-obeh-dokumentu.htm http://businessworld.cz/podnikove-is/dms-a-ecm-pouze-technologie-nespasi-7553
9
Obrázek 2 IXOS DMS pro ERP systém SAP - záznam jednotlivých verzí dokumentů a sledování historie změn Zdroj: http://www.systemonline.cz/clanky/dms-systemy-pro-spravu-a-obeh-dokumentu.htm
Přístup do DMS systému je moţné také zajistit lokálně za pouţití takzvaného tenkého klienta, který se uvnitř vnitropodnikové sítě distribuuje přes webové rozhraní. Další nejrozšířenější způsob, jak se lze do systému přistupovat je za pouţití tlustého klienta. Jedná se o aplikaci, která se instaluje na lokální stanici daného uţivatele.
1.3.2 Oblasti vyuţití DMS systémů Dle daných procesů a jejich vazeb na data a dokumenty můţeme oblasti DMS rozdělit na tři části: 1. Dokumenty jsou výstupem určitého procesu. DMS systémy nabízí velkou podporu pro správu a vznik dokumentů po celou dobu jeho ţivotního cyklu. Do této části spadají veškeré dokumenty vznikající ve firmě jako je objednávka, smlouva, podklady pro objednávky a například i interní směrnice. 2. Dokumenty jsou vstupem, který startuje určitý proces. V tomto pojetí DMS řeší evidenci dokumentu, jejíţ součástí můţe být například pořízení digitálního obrazu dokumentu po naskenování a následném spuštění schvalovacího procesu, který je 10
realizovaný pomocí workflow. Příkladem této skupiny můţou být například faktury, které přichází do firmy. Jsou následně archivovány, procházejí schvalovacím procesem a v posledním kroku dojde k jejich zaúčtování. Faktury jsou příkladem dokumentů, u kterých je kladen velký důraz na bezpečnou archivaci a zamezení jejich změny, protoţe na jejich základě provádí firma své činnosti, které je třeba zpětně prokázat. Na archivování všech dokumentů, které přicházejí do firmy je postavena například řešení spisové sluţby. V pojišťovnictví můţou DMS pomáhat vyřešit vyrovnání po vypořádání pojistných událostí. V bankovním sektoru mohou slouţit ke zpracování poţadavků klientů. 3. Do třetí skupiny spadají vnitropodnikové dokumenty, které slouţí k plnění úkonů jednotlivých pracovníků. Pro tento typ je důleţité, aby byli snadno dostupně, a rychle dohledatelné Ve své podstatě se jedná o bezpečný archiv, který tvoří většina dokumentů uvedených v prvních dvou skupinách. V této fázi se jedná o dokumenty, které jiţ prošli schvalovacím procesem a jsou uzavřeny. Nicméně musí být i nadále přístupné všem pracovníkům v organizaci. V rámci společnosti se jedná o aktuální interní předpisy, smlouvy uzavřené s dodavateli, odeslané nabídky, schválené faktury, ISO dokumentace a mnoho jiných.
2 Nároky na provoz DMS Předmětem dodávky DMS je komplexní dodávka tří komponent, poptávaných organizací. Jednotlivé dílčí dodávky systému jsou rozloţeny do tří různých projektů: -
Scan
-
DS (document storage)
-
OMS (output management systém)
Komponenta SCAN Pro zpracování formulářů bude slouţit software KOFAX Capture, protoţe byl tento systém vyhodnocen jako nejspolehlivější pro zpracování formulářů. Systém je rozšířen o modul KOFAX Transformation Module Forms, neboli KTM Forms. Systém OCR je sloţen z několika dílčích modulů. Některé z těchto modulů běţí zcela automaticky bez jakékoliv
11
interakce ze strany uţivatelů na straně serveru, a některé zase naopak interakci uţivatelů vyţadují.4 Diagram toku dokumentů mezi jednotlivými moduly:
Obrázek 3 Toky dokumentů mezi jednotlivými moduly Zdroj: Vlastní
Diagram zobrazující kde jednotlivé moduly běţí:
Obrázek 4 Grafické zobrazení jednotlivých modulů Zdroj: Vlastní
Modul Scan Modul Scan zajišťuje konverzi papírového dokumentu do digitální podoby a komunikuje přímo s připojeným skenovacím zařízením. Uţivatel v rámci tohoto modulu zaloţí v systému 4 http://www.kofax.com/document-capture-software/
12
novou dávku, vloţí do skeneru připravené dokumenty a spustí skenování. Program na základě nastavení automaticky rozpozná čárové kódy, které jsou umístěné na dokumentech a zařídí jejich automatickou separaci. K dosaţení co moţná nejkvalitnějšího naskenovaného obrazu pomáhá výrazně systém VRS (VirtualReScan), který se stará o komunikaci mezi skenerem a Modulem Scan. Systém bude z hlediska uţivatele nastaven na velmi příjemné a intuitivní ovládání. Pro efektivní práci budou v Modulu Scan nastaveny a vyladěny jednotlivé skenovací profily pro zajištění kvalitního skenovacího obrazu. Po procesu naskenování bude ještě uţivateli umoţněno jednotlivé dokumenty překontrolovat a případně uspořádat. Po ukončené kontrole uţivatel dávku uzavře a tím zajistí její uvolnění pro zpracování dalším modulem ve frontě. Dokumenty se budou skenovat černobíle v rozlišení 300 DPI. Jedná se o rozlišení, které je doporučeno pro zajištění kvalitního rozpoznání jednotlivých údajů s ohledem na zajištění dobré čitelnosti vlastního naskenovaného obrazu. Při skenování nedochází k identifikaci dokumentu a jeho typu. Typ dokumentu je identifikován aţ v následném modulu KTM server, v němţ jsou zadána jednotlivá pro korektní určení typu dokumentu. Modul KTM server Modul KTM server zajišťuje přiřazení naskenovaných obrazů k šablonám a následné rozpoznání jednotlivých indexů. Tento modul běţí automaticky na serveru. Jakmile zjistí, ţe je připravená nová dávka ke zpracování, automaticky ji natáhne a zpracuje. Nejprve je rozpoznán čárový kód a dle jeho hodnoty bude určen správný typ dokumentu. Pokud dokument čárový kód neobsahuje, dojde k automatickému přiřazení správné šablony na základě vzhledu formuláře popřípadě na základě dalších doplňujících podmínek, jako je třeba část textu. Během vlastního rozpoznávání jednotlivých indexů provádí systém kontroly oproti různým číselníkům, nebo logickou kontrolu struktury dat. Pro bezchybné vytěţení dat lze třeba klást velký důraz, aby například razítka nepřekrývala důleţité informace, které se mají vytěţit. Razítka je třeba umístit mimo zóny nadefinované pro automatické vytěţování údajů. Modul Validation Modul Validation slouţí ke kontrole vytěţovaných informací a indexaci daných dokumentů. Uţivatel vidí na obrazovce formulář s předdefinovanými indexy, vyplněnými vytěţenými daty a v druhé části obrazovky vidí naskenovaný dokument. Naskenovaný dokument lze také zobrazit na samotném monitoru. Uţivatel postupně kontroluje vytěţené indexy. Systém 13
označuje automaticky barevně vytěţené indexy. Index, u kterého si je systém dostatečně jistý, ţe jej vytěţil zcela správně, označí zelenou barvou. V případě indexu, u kterého si systém není zcela jistý, ţe jej vytěţil správně, dojde k označení červenou barvou. Pokud je některý index červený, nedovolí systém příslušnou dávku zpracovat a uzavřít ji. Příklad správně vytěţeného údaje:
Obrázek 5 Správně vytěţený údaj z čárového kódu Zdroj: screenshot z formuláře pojišťovny
Příklad vytěţeného údaje, u kterého si systém není jistý:
Obrázek 6 Nesprávně vytěţený údaj Zdroj: screenshot z formuláře pojišťovny
Jakmile jsou veškeré indexy označeny zelenou barvou, systém automaticky nabízí k indexaci a kontrole následující ne zcela správně rozpoznaný formulář v dané dávce. Zcela správně rozpoznané formuláře systém nenabízí uţivateli ke kontrole. Modul Validace nabízí uţivateli k opravě nikoliv celou hodnotu indexu nýbrţ jen jednotlivá písmena, u kterých si systém nebyl jistý. Není tedy nutné přepisovat vţdy celý údaj, stačí jen typovat jednotlivá písmena, která systém nabídne k opravě. V praxi to znamená urychlení indexace. Kurzor se pohybuje po jednotlivých znacích, které špatně rozpoznal, nebo si u nich není jistý. Znak, který je ţlutě zvýrazněn, je aktuálně nabídnutý ke korekci. Zeleně označené znaky jsou správně vytěţené a červeně označené znaky čekají stále na korekci. Modul PDF Generator Modul PDF Generator zajišťuje vlastní převod do PDF nebo PDF/A. Tento modul běţí na serveru automaticky. Jeho vyuţití záleţí na zvoleném výstupním formátu obrazů. V případě, ţe jako formát výstupu bude zvolen TIF, nebude tento modul vyuţívaný vůbec. Oba výše uvedené formáty jsou součástí standardní verze systému OCR.
14
Modul Release Modul Release zajišťuje předání dat ze systému OCR na filesystém. Tento modul běţí automaticky na serveru. Jakmile zjistí, ţe je připravená nová dávka ke zpracování, automaticky ji natáhne a zpracuje. Modul předává jak vytěţené či doplněné indexy tak i vlastní naskenovaný obraz v poţadovaném formátu.
2.1 Typy vytěţovaných formulářů V současném systému, který je vyuţíván se nachází zhruba 80 typů různých šablon. Během implementace bude provedena revize pouţívaných šablon. Základní identifikace typu formuláře (šablony) bude probíhat na základě vytěţené hodnoty čárového kódu. Z povahy systému OCR není nutné pro kaţdý čárový kód vytvářet samostatnou šablonu. Sloučením více typů formulářů do jedné šablony zároveň umoţňuje efektivnější a rychlejší správu celého systému OCR. Společná pravidla napříč všemi typy formulářů V této části jsou popsány vytěţované údaje, které se vytěţují napříč skoro všemi typy formulářů a jejich chování je totoţné včetně ověřování správnosti oproti případné databázi. Jednotlivé indexy se aţ na výjimky vztahují vţdy pouze ke konkrétnímu dokumentu nikoliv celé dávce. Nicméně je moţné nadefinovat pravidla, kdy se daný index bude automaticky propisovat i k dalším dokumentům v rámci dávky. Anti-money Laundering Anti-money laundering (AML) je postup, který zamezuje legalizaci výnosů z trestné činnosti a financování terorismu. Povinnost je dána přímo zákonem č. 253/2008 Sb. Pro vlastní proces skenování jde v podstatě o kontrolu, zda jsou některé údaje na dokumentu přítomny, tedy o vyhodnocení vyplněnosti. Obsah polí jiţ není podstatný a není nutné jej kontrolovat. Systém bude nastaven jako v případě zaškrtávacích polí, kdy se specifikuje, jaké procento daného pole musí být vyplněno, aby se dal daný údaj povaţovat za vyplněný. Pokud jsou pravidla splněna, bude automaticky nastaven příznak AML. Vyhodnocení příznaků bude součástí aţ dalšího zpracování mimo Kofax. Údaje z formuláře budou vytěţeny standardně.
15
Obrázek 7 Ukázka pole formuláře Zdroj: screenshot z formuláře pojišťovny
Politicky exponovaná osoba (PEO) Během vytěţování se kontroluje, zda je příslušné zaškrtávací pole zaškrtnuté či nikoliv. Tento proces bude zcela automatický. Pokud bude dané pole zaškrtnuto, nastaví se příznak PEO. Čárový kód Čárový kód vytištěný na formuláři přesně specifikuje jeho typ. Jeden typ formuláře můţe být specifikován i více čárovými kódy. Pojišťovna dodá číselník, který bude obsahovat párování hodnoty čárového kódu s typem formuláře.
Obrázek 8 Typ vytěţovaného čárového kódu Zdroj: screenshot z formuláře pojišťovny
Telefonní číslo klienta Pokud je na formuláři vyplněno telefonní číslo klienta je nutné jej vytěţit. Vzhledem k navrţeným formulářům je vytěţení telefonního čísla klienta problematické. Z povahy formuláře není moţné určit, zda je telefonní číslo uvedeno včetně předvolby. Návrh řešení v tomto specifickém případě je oříznout vytěţený údaj zprava na devět znaků a zbylý řetězec automaticky doplnit do pole předvolba. Pokud nebude předvolba detekována, bude automaticky nastavena na 00420. Výše je uvedena jedna z moţností, jak danou problematiku řešit a je z našeho hlediska nejoptimálnější. Dalším moţným způsobem řešení je kontrolovat předvolbu proti číselníku. Část řetězce, identifikovaná jako předvolba bude porovnána s hodnotami v číselníku předvoleb, který bude k dispozici v podobě pevného číselníku (slovníku), pokud nebude hodnota nalezena, bude doplněna vţdy hodnota 00420.
16
Prodejce Existuje několik podob na různých formulářích. Vţdy se vytěţí všechny dostupné informace. Kontrola bude probíhat pouze proti databázi prodejců. Priorita zpracování Jedná se o interní příznak, který slouţí pro prioritní zpracování jak v rámci OCR, tak i v rámci workflow. Na validačním formuláři bude tento poţadavek řešen zaškrtávacím polem, které bude implicitně nezaškrtnuto. Pokud uţivatel pole zaškrtne, získá automaticky daný dokument vyšší prioritu. Prioritu zpracování bude moţné přiřadit i na úrovni celé dávky, kdy následně automaticky jednotlivé dokumenty získají tento příznak. Tento příznak bude uloţen jako jeden z parametrů do výstupního XML pojišťovny. Poznámka U kaţdého typu formuláře bude moţné zadat krátkou poznámku s omezením 50 znaků. Poznámka bude poté přenesena do DS. V DS bude prostor pro rozšíření jiţ stávající poznámky přenesené ze systému OCR.U poznámky nebudou nastaveny ţádné logické či jiné kontroly. Pokud bude dokument zcela správně vytěţen, nebude uţivateli nabídnut ke korekcím. Uţivatel má moţnost se k jednotlivým dokumentům v dávce vrátit a poznámku případně doplnit. Další moţností doplnění poznámky je na úrovni DS. Toto platí všeobecně o všech indexech, nevztahuje se pouze k indexu poznámka. Dokument mající příznak otazník bude uţivateli nabídnut ke korekci. Dokument bez tohoto příznaku je zcela správně rozpoznán nebo jiţ prošel korekcí. Uţivatel se pomocí myši můţe k jednotlivým dokumentům v dané dávce vracet. Zpracováno Jedná se o interní příznak, který slouţí pro identifikaci, zda má být daný dokument zpracován v rámci workflow, nebo pouze uloţen do archivu. Tento příznak se uloţí do XML na disk. Workflow pojišťovny by mělo být nastaveno tak, aby bral tento příznak v potaz. Nastavení zpracování na straně pojišťovny je plně v reţii pojišťovny. Zpracováno bude moţné přiřadit i na úrovni celé dávky, kdy následně jednotlivé dokumenty automaticky získají tento příznak. 17
2.1.1 Ruční zpracování Interní příznak označující dokument, jeţ vyţaduje při zpracování zásah operátora. Vynucené zpracování i pro dodatky, jeţ by prošly automaticky všema kontrolami. Zamezí se tak problémům s ručně dopsanými údaji a podobně. Tento příznak se uloţí do XML na disk.Workflow pojišťovny by mělo být nastaveno tak, aby bral tento příznak v potaz. Nastavení zpracování na straně pojišťovny je plně v reţii pojišťovny. Jednostranná kopie Příznak specifikuje dokument, který je kopií formuláře bez jeho druhé strany. Jde opět o příznak pro interní potřebu. Tento příznak se uloţí do XML na disk. Workflow pojišťovny by mělo být nastaveno tak, aby bral tento příznak v potaz. Nastavení zpracování na straně pojišťovny je plně v reţii pojišťovny. Zaškrtávací pole V této kapitole je obecně popsáno chování zaškrtávacího pole. Systém vyhodnocuje zaškrtávací pole na základě procentuálního vyplnění daného pole. Na základě této hodnoty se potom systém rozhoduje, zda je dané pole zaškrtnuté či nikoliv. Tento práh je na úrovni administrace nastavitelný. Systém nehlídá, jakým způsobem bylo dané pole vyplněno, zda kříţkem či háčkem nebo obecně jakýmkoliv způsobem. Smlouva o penzijním připojištění Stěţejním typem formuláře je Smlouva o penzijním připojištění. Smlouvy ve formátu A4 se skenují jednostranně. Některé smlouvy se však skenují i oboustranně. Jedná se převáţně o smlouvy ve formátu A5, jelikoţ na druhé straně se občas vyskytují různé poznámky a je potřeba je zachovat. Smlouvy se skenují včetně případných příloh do jednoho výsledného souboru. Z tohoto formuláře se budou vytěţovat veškeré údaje, které jsou na daném formuláři k dispozici. Většina formulářů je ručně vyplněna. Některé vytěţované údaje je moţné kontrolovat oproti poskytnutým číselníkům. Takto je moţné např. kontrolovat vytěţené číslo smlouvy, PSČ atd.
18
Obrázek 9 Pole číslo smlouvy Zdroj: screenshot z formuláře pojišťovny
Další vytěţované údaje mají svojí vnitřní logiku, kterou je nutné kontrolovat. Takovým příkladem je rodné číslo klienta, které odpovídá logické kontrole modulu, aţ na některé výjimky. Podobným způsobem lze například ověřovat i IČ. Tyto kontroly a pravidla budou nasazena v rámci implementace formou skriptů v systému OCR.
Obrázek 30 Pole kolonka rodné číslo Zdroj: screenshot z formuláře pojišťovny
Z poskytnutých číselníků bude moţné i údaje automaticky doplňovat. Na základě rodného čísla je moţné, pokud je klient v evidenci pojišťovny, dotáhnout další identifikační údaje o daném klientovi, jako je jeho jméno, příjmení a adresa. Pokud bude v komunikační databázi více řádků se stejným rodným číslem, k doplnění se vţdy pouţije ten nejvíce aktuální.
Obrázek 11 Pole se základními údaji Zdroj: screenshot z formuláře pojišťovny
Pokud existuje u některých údajů moţnost omezit vytěţované údaje na číselník, bude to takto nastaveno. Jako příklad lze uvést titul klienta.
Obrázek 12 Pole pro uvedení titulu Zdroj: screenshot z formuláře pojišťovny
V některých případech lze u indexů nastavit výchozí hodnotu. Toto je moţné například u indexu kód země, kde bude výchozí hodnota nastavena na CZE. 19
Obrázek 13 Pole kód země Zdroj: screenshot z formuláře pojišťovny
Některé údaje není moţné vůči ţádným číselníkům kontrolovat. Takovýmto případem je například vytěţení e-mailové adresy klienta. Z hlediska dlouhodobého není e-mail ideální kontaktní informace, jelikoţ v čase velmi často podléhá změně a během vytěţování nelze ţádným způsobem ověřit jeho platnost.
Obrázek 14 Formulářové pole e-mail Zdroj: screenshot z formuláře pojišťovny
Dalším problematickým vytěţovaným údajem je oprávněná osoba, kde je v jednom poli uvedeno příjmení, jméno a titul. Systém vytěţí jednotlivé údaje a pokusí se je spárovat s dostupnými číselníky platných jmen. Pokud najde shodu, automaticky rozdělí jméno a příjmení. Pokud shodu nenajde, vyplní první údaj do příjmení a druhý do jména. Na validačním formuláři bude připraveno tlačítko k prohození údajů, aby uţivatel nemusel v případě mylného rozdělení údaje ručně přepisovat. V případě nenalezení shody označí údaje červeně.
Obrázek 15 Pole základní údaje Zdroj: screenshot z formuláře pojišťovny
Na pozadí budou dále probíhat další logické kontroly a na základě jejich vyhodnocení bude uţivatel například vyzván ke kontrole dalších polí. Validační formulář se bude chovat jinak v případě, ţe se jedná o klienta jiné neţ české národnosti. Z celkového mnoţství se jedná o zhruba 20%.
Obrázek 16 Pole pro příslušníky cizích států Zdroj: screenshot z formuláře pojišťovny
20
Zhruba 0,5% příchozích smluv obsahuje dodatek ke smlouvě. Během skenování je nutné zajistit, aby takovýto dodatek byl přílohou dané smlouvy. Dodatek má svůj vlastní čárový kód. Při přípravě je nutné tento čárový kód znehodnotit, například svisle přeškrtnout černou fixou nebo po naskenování ručně dané dokumenty sloučit. To lze provést přetaţením pomocí myši. V případě, ţe smlouva obsahuje přílohu, bude během validace vţdy vynucena manuální kontrola.
2.1.2 Ostatní formuláře Zpravidla většina klientů, kteří se na formulářích vyskytují, má aktivní uzavřenou smlouvu v systému ČPII. Počítá se s vytěţováním všech polí na všech formulářích. I v této oblasti se předpokládá nasazení různých kontrol oproti databázím včetně automatického doplňování údajů na základě vytěţeného indexu, např. na základě rodného čísla budou dotaţeny všechny ostatní identifikační údaje daného klienta. Pokud systém nalezne více záznamů k danému rodnému číslu, systém OCR vyzve uţivatele k vybrání jedné z nalezených hodnot. Uţivatel poté pomocí dvojkliku na správný záznam hodnotu vybere. V seznamu se můţe také pohybovat pomocí šipek a následně pomocí klávesy ENTER vybrat poţadovaný záznam. Řazení jednotlivých záznamů v nabídce bude moţné na úrovni administrace systému definovat.
Obrázek 17 Ukázka databáze vendors Zdroj: screenshot interní systém pojišťovny
21
Vytěţovat nebo z části automaticky doplňovat se budou zejména následující indexy: -
Číslo smlouvy
-
Rodné číslo
-
Jméno
-
Příjmení
-
Typ formuláře
-
Telefonní číslo klienta
Skenovací aplikace umoţní uţivatelsky zadat k jednomu dokumentu více skupin hodnot indexu – multiindex.
2.1.3 Nestrukturované dokumenty Během implementace se nepředpokládá nasazení řešení pro nestrukturované dokumenty. Jejich indexace bude probíhat ručně. Operátor vyplní jen indexy, které jsou dostupné na dokumentu. Systém OCR disponuje moţností vytěţovat indexy i z polostrukturovaných nebo nestrukturovaných dokumentů. V této oblasti je moţné v budoucnu řešení rozšířit a tím zefektivnit i tuto část procesu.
2.1.4 Souhlas s převodem Jedná se o dokumenty, které náleţí jinému penzijnímu fondu. Tyto dokumenty nevstupují do workflow v systému ČPII, ale jsou archivovány pouze v digitálním archivu pro jejich evidenci. Při skenování se ručně opatří indexem rodné číslo. Fyzicky se dokument po naskenování přeposílá na adresu komu správně náleţí.
2.1.5 Seznam dokumentů pro archivaci Systém by měl umoţnit efektivní archivaci papírových dokumentů. Při skenování bude uţivatel vyzván k zadání čísla archivní krabice. Uţivatel můţe číslo archivní krabice ručně vyplnit. Tento způsob je ovšem náchylný na překlepy. Archivní krabice budou opatřeny štítkem s čárovým kódem a ty následně pomocí standardní čtečky čárových kódů načítat. 22
Číslo archivní krabice bude součástí indexu. Toto pole bude moţné vyplnit jednak nad celou dávkou, tak nad konkrétním dokumentem. Následně systém umoţní uţivateli vytisknutí reportu, který bude obsahovat následující poloţky: -
ID dokumentu
-
Číslo smlouvy
-
Rodné číslo
-
Příjmení
-
Jméno
-
Typ formuláře
-
Název firmy
-
Kód pobočky
-
IČ
Seznam indexů v daném reportu bude přesně určen v rámci upřesnění návrhu řešení a bude pevně daný. Seznam nebude moţné uţivatelsky měnit. Pokud u některého dokumentu nebude konkrétní index vytěţen či vyplněn, zůstane příslušné pole v reportu prázdné. Report se bude vytvářet na úrovni digitálního archivu s moţností exportu do MS Excelu. Takto vygenerovaný přehled se poté vloţí do archivační krabice a krabice se zaloţí.
2.1.6 Definice logických kontrol a kontrol proti databázím v rámci OCR V závislosti na typu formuláře se budou uplatňovat různé kontroly. Z hlediska typů kontrol lze tuto kategorii rozdělit na následující logické celky: -
Pevné číselníky
-
Dynamické číselníky
-
Veřejné rejstříky
Číselníky budou do KOFAX předávány formou textového databázového souboru. Pevné číselníky Za pevné číselníky povaţujeme číselníky, které se v čase nemění, nebo mění jen velmi sporadicky. Ideálním příkladem pevného číselníku je číselník měsíců v roce. Takovéto číselníky se v systému OCR nazývají slovníky. Zdrojem pro tyto číselníky jsou textové soubory. 23
Jednotlivé pevné číselníky budou uloţeny v jedné sloţce, do které budou mít oprávnění uţivatelé přístup. Pro upravení číselníku stačí upravit příslušný textový soubor. Systém OCR si změnu sám automaticky natáhne. Dynamické číselníky Za dynamické číselníky lze povaţovat číselníky, které se v čase mění. Jedná se například o databázi klientů. Zdrojem pro tyto číselníky je databáze systému pojišťovny. Veřejné rejstříky Během analýzy byla zjištěna potřeba kontrolovat některé vytěţené údaje vůči veřejným rejstříkům. Typickým příkladem je číselník poštovních směrovacích čísel či rejstřík platných adres v ČR. Zdroje těchto číselníků jsou různé. Předpokladem pro vyuţití těchto číselníků je jejich zakoupení či jiná forma získání a jejich pravidelná aktualizace. Systém OCR můţe s těmito číselníky pracovat, pokud budou dostupné v tabulkách databáze MS SQL přístupné. Při implementaci se počítá s vyuţitím maximálně pěti veřejných číselníků. Zodpovědnost za jejich aktualizaci a za správnost poskytnutých dat bude na straně pojišťovny. Vyšší počet veřejných číselníku je z technického hlediska moţný, nicméně vyšší počet nedoporučujeme vzhledem k poţadavku na co nejrychlejší odezvy systému OCR. Logické kontroly a formátování: Při definici jednotlivých šablon je moţné vyuţít základních dostupných logických kontrol. Kontroly se vţdy definují na úrovni konkrétního indexu na dané šabloně. Mezi základní logické kontroly a formátování zejména patří: -
Zda je index povinný či nepovinný
-
Formát indexu (např. jen numerické znaky, datum)
-
Minimální a maximální délka indexu
-
Automatické odmazávání vodících nul
-
Automatické odmazávání mezer
-
Automatické nastavení kapitálek
24
Další kontroly je moţné do systému doplnit pomocí skriptovacího rozhraní. Do této části nespadají kontroly oproti číselníkům či slovníkům. Pokud systém neprojde nadefinovanými kontrolami je daný index označen červeně a není moţné bez korekce pokračovat dále. Systém vţdy zobrazí chybovou hlášku charakterizující danou chybu.
2.1.7 Zpracování klonů formulářů Při tvorbě nových formulářů je kladen důraz na jejich vzájemnou podobnost a to jak z hlediska vzhledu, tak i z hlediska rozloţení jednotlivých polí. Nově vzniklý formulář je tedy klonem formuláře jiţ existujícího. Tímto způsobem je eliminována velká pracnost při nasazování nových formulářů do systému OCR. Systém OCR by měl zajistit rychlou a efektivní práci při vytváření nových klonů jiţ existujících formulářů. Klony se minimálně vţdy liší hodnotou čárového kódu uvedeného na formuláři. V některých případech je rozdílný i popis jednotlivých polí. Jejich rozloţení je ve většině případů totoţné.
Obrázek 4 Ukázka čárového kódu Zdroj: screenshot z formuláře pojišťovny
V systému OCR bude přidávání nových klonů řešeno jen formou mapování nové hodnoty čárového kódu s novým typem formuláře. Veškerá nastavení tedy zůstanou stejná. V systému OCR nebude vznikat úplně nová šablona, ale bude vyuţita jiţ stávající. Do té se pouze přidá nově výše uvedené mapování. Tento způsob tvorby klonů formulářů zároveň sniţuje pracnost při přípravě a vlastním skenování. Uţivatelé nemusí jednotlivé klony třídit na různé typy dle čárového kódu. Veškeré takové formuláře můţe vloţit do jedné dávky a systém na základě vytěţení hodnoty čárového kódu sám určí typ formuláře. K tomuto úkonu budou řádně proškolení vybraní uţivatelé pojišťovny. Nastavení se bude provádět v administraci systému OCR. Četnost výskytu nových klonů formulářů je zhruba dva za měsíc. Jedná se o jeden z klíčových procesů pojišťovny, nasazení nových klonů formulářů do produkce musí být velmi rychlé. 25
Pokud bude rozloţení indexů na formuláři jiné, neţ na původním formuláři, bude nutné v systému vytvořit úplně novou šablonu. Tento proces bude schopen zajistit řádně vyškolený pracovník. Při tvorbě nové šablony je moţné částečně převzít nastavení i z jiné jiţ existující šablony.
3 Popis DMS Dokumentová storage neboli centrální úloţiště - jedná se o digitální archiv pro ukládání, správu, zálohování, vyhledávání a verzování digitálního obsahu, pro který tato nabídka počítá s dodávkou technologie Transactional Content Processing od společnosti Open Text. Schematická architektura řešení a komponenty Ze systémového hlediska se Document Storage skládá z následujících komponent:
Obrázek 19 Rozloţení jednotlivých komponent DMS Zdroj OpenText Transactional Content Processing 10.2.1 - System Overview Guide English (TCP100201-GGD-EN-2)
3.1 Vrstva úloţiště Obsahuje především robustní archivní řešení Enterprise Library Services, dále RDBMS a sluţbu pro správu uţivatelů. 26
3.2 Aplikační vrstva Hlavní komponentou této vrstvy je TCP Service. Tato sluţba zpracovává poţadavky, které přicházejí buď z prezentační vrstvy, nebo z API. Pomocí TCP Web Services se generuje do uţivatelského GUI tenkého klienta, webové stránky a poskytuje dokumenty. Další komponentou důleţitou komponentou je Context Service, tedy sluţba zodpovědná za komunikaci s TCP Service a Enterprise Library Service. Tato vrstva je rovněţ zodpovědná za správu metadat a přístupových oprávnění. Document Input je komponenta pro zpracování dokumentů z různých zdrojů (disk, MS Exchange server) a extrakci vnořených dokumentů. Důleţitou komponentou, kterou předpokládáme vyvinout je C# API (Adaptér). Toto rozhraní bude hlavním komunikačním kanálem mezi Document Storage a workflow systémem. TCP API je nativní API systému TCP, Imaging Services je komponenta zodpovědná za transformaci dokumentů do TIF a realizaci začerňování částí dokumentů.
3.3 Prezentační vrstva Součástí této vrstvy je TCP WEBUI, tedy tenká klientská část pro přístup do systému a práci v něm.
3.4 Popis komponent a řešení ve vztahu k objednateli Document Input je komponenta, která se na základě poţadavku z workflow připojí ke zdroji dokumentů na disku a metadat ve formátu XML, zajistí zpracování dokumentu (převod na TIF, rozdělení do dílčích dokumentů, extrakce vnořených dokumentů). Dokument včetně metadat a TIF renderu zarchivuje a vrátí zpět do workflow identifikaci zarchivovaného dokumentu(ů). Archivace ostatních záznamů (odchozí papírová korespondence, další dokumenty, SMS a další). Obecně je archivace iniciována z workflow. Komponenta Document Input se připojuje na definované místo na disku a zde archivuje nalezené dokumenty a připojuje k nim odpovídající metadata XML. Pokud to formát dovoluje, dokumenty jsou konvertovány na multipage TIF. Nastavení oprávnění Oprávnění lze v systému TCP nastavit buď staticky na základě vstupu dokumentu do archivu (s vyuţitím metadat, která vstupují s dokumentem), nebo je kontrolovat dynamicky při kaţdém poţadavku na dokument. Oprávnění na dokument lze řídit i s pomocí metadat na 27
dokumenty (např. smlouvu lze obchodnímu zástupci zobrazit pouze v případě, ţe je cílová částka niţší neţ 10.000.000 a podobně).
3.4.1 Vystavování dokumentu Na základě poţadavku na dokument komponenta API vystaví dokument formou streamu. Oprávnění uţivatelé a jeho poţadavek bude rozhodovat o tom, zda mu bude vystaven originál dokumentu, nebo jeho TIF kopie. Při přístupu do systému napřímo přes WEBUI TCP bude TIF obrázek zobrazen v prohlíţečce bez uloţení na disk počítače. To se netýká ostatních formátů dokumentů (např. mp3, docx).
3.4.2 Jednoznačný identifikátor Kaţdý dokument uloţený v systému TCP má jednoznačný identifikátor, který se sestává z logického archivu, ve kterém je uloţen (tzv. ARCHIVID) a unikátního identifikátoru dokumentu (tzv. DOCID). Z uţivatelského pohledu je tato kombinace sloţitě uchopitelná, proto doporučujeme (kde je to moţné) opatřovat v rámci metadat dokumenty lidsky přívětivými unikátními identifikátory.
3.4.3 Podpora volání sluţeb s delegovaným oprávněním Systém předpokládá spolupráci s AD, tedy pokud uţivatel pracuje přímo s TCP WEBUI je jeho kontext ověřován tímto způsobem (buď přihlášením se do TCP WEBUI, nebo pomocí Single SignOn). Pokud uţivatel pracuje v jiném systému, např. Case mng. a potřebuje si dokument zobrazit, předá Case mng. uţivatelský kontext wf aplikaci, ta předá uţivatelský kontext DS. DS ověří oprávnění uţivatele a na základě výsledu ověření vystaví uţivateli dokument.
3.4.4 Rychlost vystavení dokumentu Systém byl dimenzován tak, aby rychlost vystavení dokumentu, to znamená čas od předání poţadavku na dokument do DS po zahájení jeho přenosu na klientský počítač byla většinou niţší, neţ 1sec. Do času se nezapočítává čas nutný pro komunikaci mezi DS a klientským počítačem (přenos poţadavku na dokument) a čas nutný pro inicializaci komponent prohlíţečky na straně klienta. Do archivu lze uloţit jakýkoliv typ souboru bez omezení.
28
3.4.5 Konverze do TIF Dokumenty, u kterých to má smysl, budou konvertovány při archivaci do černobílých multiple TIF a uloţeny vedle archivovaných originálů. Předpokládáme konverzi následujících typů dokumentů: -
pdf (Portable Document Format)
-
PDF/A (Portable Document Format for the Long-term Archiving)
-
xml (Extensible Markup Language Document) (pouze konverze webových formulářů se šablonou)
-
fo/zfo (602XML Filler dokument)
-
html/htm (Hypertext Markup Language Document)
-
odt (Open Document Text)
-
ods (Open Document Spreadsheet)
-
odp (Open Document Presentation)
-
txt (prostý text)
-
rtf (Rich Text Format)
-
doc + docx (MS Word Document)
-
xls + xlsx (MS Excel Spreadsheet)
-
ppt (MS PowerPoint Presentation)
-
jpg/jpeg/jfif (Joint Photographic Experts Group File Interchange Format)
-
png (Portable Network Graphics)
-
gif (Graphics Interchange Format)
-
isdoc/isdocx (Information System Document) verze 5.2 a vyšší
-
msg (uloţený e-mail z MS Outlook)
3.4.6 Archivace vloţených dokumentů Pokud se v archivovaném dokumentu vyskytne vnořený dokument, bude extrahován a konvertován na TIF. Takto extrahované dokumenty lze archivovat buď jako celek ve formátu ZIP, nebo samostatně jednoznačnou vazbou na původní dokument. Předpokládáme takto řešit dokumenty vnořené do formátů doc, docx, zfo, zip, msg.
3.4.7 Migrace Na základě proběhnuvší analýzy předpokládáme migraci různých systémů. Pro migraci bude vyuţit nativní nástroj Document Pipeline, který na základě předloţených metadat a 29
dokumentu tento zarchivuje do DS. Document Pipeline je interface pro hromadnou archivaci dokumentů s vlastním administračním a monitorovacím nástrojem. Migrace není součástí této dodávky.
3.4.8 Logování, audit Logování lze nastavit pro klasické manipulace s dokumenty (vloţení, úprava, otevření, vymazání). V případě verzování dokumentu lze logovat i změny metadat. Dále lze logovat aktivitu uţivatelů (přihlášení se do systému, činnost v systému).
3.4.9 Verzování U vybraných typů dokumentů, u kterých to má smysl lze zapnout verzování. Systém potom ukládá všechny změny dokumentu jako nové verze. Tato vlastnost je k dispozici při přístupu k dokumentu přes TCP WEB UI. Generování událostí do jiných systémů z auditního logu systému DS bude dávkově generován report, který bude dohodnutou formou předáván ke konzumaci dalším systémům (přes Adaptér). Toto bude vyuţito pro informování Workflow, ţe byl zaarchivován dokument s definovaným ID. Servisní poţadavky Jsme připraveni předat zdrojové kódy, které vzniknou v rámci vývoje komponent, které nejsou součástí out – of – the – box řešení. Servisní podpora je standardní součástí dodávky a zahrnuje řešení chyb produktu a implementace. Údrţba document storage ve stavu odpovídajícímu legislativě je součástí servisní podpory s tím, ţe připadané poţadavky na změnu budou iniciovány objednatelem. Testovací prostředí Během instalace vznikne na jednom serveru zcela oddělené vývojové – testovací – školící prostředí, které bude z funkčního hlediska identické s produkčním prostředím.
30
Způsob začlenění řešení do infrastruktury Řešení je postaveno na klasické klient / server architektuře s důrazem na API pro workflow systém. Server 1 (TCP Service, TCP Web Service, Context Service, TCP API, C# API] Server 2 (Enterprise Library Services, Document Input, Imaging Services, User Management Services) Server 3 (SQL) Server 4 (vývojový / testovací server se všemi výše zmíněnými komponentami) Na klientské straně předpokládáme následující typy klientů: Klient přistupující do aplikace z workflow, resp. třetích systémů. Zde se nebudou nacházet ţádné komponenty systému TCP a veškerá komunikace bude realizována pomocí interface prohlíţečky Java Viewer. Klient přistupující do aplikace přes TCP WEB UI. Tento klient je webový vyjma komponenty pro zobrazování obrázků bez ukládání na disk. Komponenta se instaluje na klientský počítač Způsob ukládání dokumentů do zprovoznění DS ČP2 se ukládá do archivu Sirius Část ČP3, která je jiţ v produkci (Provize a Case Management) do „Provizorního“ archivu Do DS budou dokumenty ukládány aţ po zprovoznění celé ČP3, předmětem dodávky bude dodání rozhraní pro integrační test ČP3 Rozsah řešení V oblasti SCAN bude nastaveno max. 10 unikátních formulářů (klony jsou brány jako 1 formulář) Bude nastaveno 10 šablon, přičemţ souhrn vytěţovaných polí na zavedených šablonách nepřesáhne 300. Kaţdé vytěţované pole můţe být kontrolováno 1:1 proti číselníku Bude vytvořeno dohromady maximálně 10 sloţitých logických kontrol V oblasti DS bude implementováno max. 20 typů dokumentů (skupin unikátních atributů) Nebude vytvářena uţivatelská dokumentace Školení uţivatelů pro oblast SCAN bude realizováno jedním školícím během pro maximálně 10 pracovníků 31
Školení uţivatelů pro oblast DS bude realizováno jedním školícím během pro maximálně 10 pracovníků K zobrazení dokumentů bude vyuţita prohlíţečka dodaná Zhotovitelem. Pro ruční editaci indexů bude vyuţit tenký klient Open Text TCP. V DS bude vytvořeno max. 5 různých uţivatelských rolí s unikátním nastavením přístupových práv Pracovníci - agenti – nebudou do systému přímo ani přes 3 systém přistupovat, pokud budou potřebovat dokumenty, tak si je vyţádají a dostanou kopii např. emailem. DS umoţní uloţení dokumentu s multiindexem - vazba typu 1:n mezi dvěma typy dokumentů (rekord types). V této fázi nejsou poţadovány tyto funkcionality: - Začerňování části dokumentu -
Přímé propojení s e-mail systémem (archivace bude probíhat z disku)
-
Propojení s datovými schránkami
-
Propojení s webovými formuláři
-
Propojení se systémem telefonických hovorů
-
Opatřování obrázků vodoznakem
-
Omezení přístupu na části dokumentu
3.4.10 Komponenta OMS Implementace nejnovější verze StreamServe Persuasion SP55, umoţňuje jednotné komunikační platformy pro všechny firemní procesy, které sjednotí oddělenou komunikaci do jednoho uzlu a umoţňuje sdruţovat výstupy všech platforem na jedno médium. Předmětem dodávky a instalace jsou níţe uvedené součásti (komponenty) StreamServe Persuasion SP5, jejichţ implementací bude naplněna potřeba PF na sjednocení komunikační platformy. StreamServe Persuasion EDP StreamServe EDP (Enterprise Document Presentment) obsahuje všechny základní komponenty pro funkční běh produktu StreamServe. Tyto základní komponenty jsou definovány níţe a jsou nedílnou součástí předmětu dodávky OMS. 5
http://database3.com/s/streamserve-persuasion-sp5-oracle-database-e217
32
Design Center Windows aplikace určená vývojářům. V této aplikaci se jednak definují šablony a jednak se pomocí grafického prostředí definuje celé procesní flow projektu. Vytvořený projekt či šablony se pak exportují pro pouţití se StreamServerem. Control Center Windows aplikace určená pro správce systému. Umoţňuje správu celé topologie řešení včetně jednotlivých prostředí pro vývoj, testy a produkce. Přístup k aplikaci je zabezpečen uţivatelským jménem a heslem. Aplikace umoţňuje definování více uţivatelů s různými právy. StreamServe AdHoc & Correspondence Reviewer Users StreamServe Composition Center StreamServe Composition center (součást webové aplikace StreamStudio) je aplikací umoţňující „business“ uţivateli přímou definici obsahu pro jednodušší dokumenty (smlouva, dopis, upomínka) Composition Center má variantu AdHoc a Reviewer pro editaci některých textů Composition center nabízí také schvalovací workflow. StreamServe AdHoc modul součást Composition Center (předpokládá tedy jeho instalaci) slouţící k vytvoření a následné editaci dokumentu (dokumentů) před jeho (jejich) odesláním. Modul AdHoc je plně integrovatelný do prostředí zákazníka – jde o technologii servlet, portlet. Corespondence Reviewer modul Reviewer je stejně jako AdHoc modul součástí Composition Center a umoţnuje uloţení vytvořeného dokumentu ve vnitřní databázi StreamServe a jeho odsouhlasení, editaci nebo zamítnutí odpovědnou osobou.
33
StreamServe Post Processing Modul Post Processor (Post Processing) umoţňuje realizovat konsolidaci dokumentů, jako jednu ze základních funkcí Persuasion. Post processing je dynamicky zapojitelný do workflow a obvykle se pouţívá pro generování výstupu dávkových tisku. Vygenerované dokumenty se ukládají do databáze bez ohledu na šablonu či zdroj, který je vytvořil. Takové dokumenty se pak vybírají z databáze pomocí dotazu (Post Processor Query – PPQ), který má formu XML souboru a můţe tedy kombinovat různé podmínky. PPQ je moţné volat automaticky nebo dynamicky. Pro dynamickou tvorbu PPQ se často pouţívá web rozhraní napojené na StreamServe, který na základě uţivatelského dotazu vytvoří PPQ. PPQ neobsahuje jen podmínky výběru dokumentu, ale muţe obsahovat i podmínky pro jejich řazení (sort) či obálkování, výběr tiskového formátu dle výstupního zařízení a podobně. Pro kaţdou tiskovou úlohu se obvykle generují samostatné statistiky. PPQ muţe obsahovat i další informace, například typ rozloţení (simplex, duplex, 2UP,…), tray, typ OMR a další. Níţe uvedený diagram zobrazuje moţný tok dokumentu jednotlivými moduly komponenty OMS
Obrázek 20 Liecycle dokumentu Zdroj: vlastní
4 Integrace systémů Integračním prvkem celého řešení je modul Workflow (dále WF), který objednatel interně vyvíjí. S WF budou systémy komunikovat přes adaptéry. Předpoklady integrace: komunikace mezi adaptérem a WF bude řešit objednatel komunikaci mezi adaptérem a jednotlivými systémy bude řešit zhotovitel 34
objednatel poskytne součinnost při detailní specifikaci jednotlivých rozhraní pro systémy Kofax, DS a OMS Integrace Kofax: - Výstup dokumentů bude do file systému - Výstup dat bude do file systému ve formátu XML - Vstup dat do Kofaxu pro validaci bude předáváním číselníků přes ODBC, nebo textové soubory Integrace OMS: Rozhraní bude realizováno přes ODBC nebo přímý konektor na Sybase Integrace OMS na stávající Digitální archiv (Sirius) – bude slouţit jako dočasné řešení do vypnutí ČP2 (ledy cca 1 rok). Budou vytvořeny adaptéry s následující funkcionalitou: Digital storage Uloţit dokument do archivu Popis: Uloţí dokument do archivu a vrátí jeho nové ID.. Asynchronní – po zpracování zavolá Notifikaci o uloţení. Směr: WF -> DS Vstupní parametry: ·
Href soubor – unc cesta (string)
·
XML index (string)
·
Typ dokumentu (string)
Výstupní parametry: ·
ID jobu, který dokument zpracovává (guid?)
Uloţit dokument do archivu pro rezervované ID Popis: Uloţí dokument do archivu pod zarezervovaným ID. Asynchronní – po zpracování zavolá Notifikaci o uloţení. Směr: WF -> DS Vstupní parametry: ·
ID dokumentu
·
Href soubor – unc cesta (string)
·
XML index (string) 35
·
Typ dokumentu (string)
Výstupní parametry: ·
ID jobu, který dokument zpracovává (guid)
Notifikace o uloţení Popis: Upozorňuje na úspěšné/neúspěšné uloţení dokumentu do archivu a jeho konverzi. Směr: DS -> WF Vstupní parametry: ·
ID jobu, který dokument zpracovává (guid)
·
ID dokumentu
·
Zda bylo zpracování úspěšné (bool)
·
Hláška při neúspěšném zpracování (string)
Vytvořit vazbu mezi dokumenty Popis: Vytvoří vazbu mezi dokumenty dvěma dokumenty. Směr: WF -> DS Vstupní parametry: ·
ID dokumentu 1
·
ID dokumentu 2
·
Typ vazby (string)
Získat seznam dokumentů v relaci s daným dokumentem Popis: Vrátí seznam svázaných dokumentů. Směr: WF -> DS Vstupní parametry: ·
ID dokumentu (?)
·
Typ vazby (string)
Výstupní parametry: ·
Pole ID dokumentu – typu - jména
Získat seznam dokumentů omezených hodnotou indexu Popis: Vrátí seznam IDček dokumentů, filtrovaných dle hodnoty indexu a stářím dokumentu. (příklad: všechny dokumenty klienta za poslední rok) Směr: WF -> DS Vstupní parametry: 36
·
Pole indexu pro filtraci (string)
·
Hodnota pro filtraci (string)
·
Maximální stáří dokumentu (string – datum ve formátu dd.mm.rrrr)
Výstupní parametry: ·
Pole ID dokumentu – typu - jména
Změnit hodnotu indexu existujícího dokumentu Popis: Změna hodnoty indexu po zaarchivování. Směr: WF -> DS Vstupní parametry: ·
ID dokumentu (?)
·
Změněné části indexu ve formátu XML (string)
Rezervace nového ID dokumentu Popis: Pro tisk dopisů potřebujeme rezervovat ID pro archivaci a tisknout ho na dopis před uloţením do archivu. Směr: WF -> DS Vstupní parametry: ·
Ţádné - moţná typ dokumentu dle implementace v OT
Výstupní parametry: ·
ID dokumentu (?)
Získat dokument dle ID Popis: Uloţí dokument z archivu do souborového systému Směr: WF -> DS Vstupní parametry: ·
ID dokumentu (?)
·
Adresář, do kterého ukládat (string)
·
Zda chci originál či kopii (enum)
Výstupní parametry: ·
Href uloţeného souboru (string)
Získat index dokumentu dle ID Popis: Získání informací o souboru dle jeho ID. Směr: WF -> DS
37
4.1 SCAN Ukládání naskenovaných dokumentů a indexu do adresáře dle typu Popis: Ukládání naskenovaného dokumentu v TIF, PDFA verzi a index v XML souboru do adresáře na disku dle typu naskenovaného dokumentu. Směr: SCAN WF Data potřebná k validaci dokumentů načítat z SQL database Popis: Data potřebná k validaci formulářů budou získávána z Microsoft SQL database pomocí view. Výstupem uloţených procedur bude číselník hodnot, proti kterým budou data porovnávána. Uloţené procedury bude vytvářet objednatel dle poţadavků poskytovatele. Předpokládáme, ţe bude třeba 15 – 25 uloţených procedur. Směr: ČP3 SCAN
4.2 OMS Integrace OMS a ČPII V případě interního systému ČP II není integrace OMS poţadována. Vstupní data pro realizaci poţadavku na tiskové výstupy jsou očekávána ve sledovaném adresáři, který je systémem OMS v definovaných časových intervalech prohlíţen.
4.2.1 Vygenerování a odeslání dokumentu Popis: Dle vstupních dat dotáhnout pro danou šablonu všechna potřebná data a odeslat dopis daným kanálem. Pokud nebude vyplněna adresa, získá se adresa za pomoci vstupních dat dotazem. Směr: WF -> OMS Vstupní parametry: Šablona Vstupní data Kanál pro distribuci Volitelně adresa Zda před tiskem zobrazit náhled Volitelně IP adresa pro náhled Zda zobrazit v ad-hoc 38
Výstupní parametry: Při zobrazení v adhocu url pro práci s vygenerovaným dokumentem v interaktivním reţimu Odeslání kopie dokumentu Popis: Dodaný dokument opatří razítkem kopie a odešle ho daným kanálem. Směr: WF -> OMS Vstupní parametry: Href dokumentu, jehoţ kopie se má odeslat (Tiff) Kanál pro distribuci Adresa Uloţ dokument do archivu Popis: Předá vygenerovaný dokument do archivu. Směr: OMS -> WF Vstupní parametry: Href dokumentu XML index XML data, ze kterých se dokument generoval Rezervované ID v archivu Rezervuj ID v archivu Popis: Získá z archivu ID, které natiskne do dokumentu, a poté se pod tímto ID dokument do archivu uloţí. Workflow implementuje tuto funkčnost jako webovou sluţbu. Volání sluţby přes standardní konektor na webovou sluţbu. Směr: OMS -> WF Vstupní parametry: Typ dokumentu Výstupní parametry: ID dokumentu Načti přílohu z archivu Popis: Získá dle zadaného ID dokument z archivu. Metoda se volá pokud šablona umoţňuje přiloţení příloh z archivu. Workflow implementuje tuto funkčnost jako webovou sluţbu. Volání sluţby přes standardní konektor na webovou sluţbu. Mazání nepotřebných souborů je zodpovědností workflow. 39
Směr: OMS -> WF Vstupní parametry: ID dokumentu Výstupní parametry: href dokumentu exportovaného z archivu Spuštění dávky Popis: Pokud se v předdefinovaném adresáři, objeví nový soubor s daty pro dávkové generování souboru je spuštěno dávkové generování dopisů. Směr: ČP3 -> OMS Vstupní parametry: Datový XML soubor Notifikace o realizaci tiskového výstupu Popis: Upozorňuje na úspěšnou/neúspěšnou realizaci tiskového výstupu ze systému OMS (neřeší problémy s nevytištěním výstupu nebo jeho nedoručením emailem) Směr: OMS -> WF Vstupní parametry: ID jobu, který dokument zpracovává ID dokumentu Zda bylo zpracování úspěšné Hláška při neúspěšném zpracování Vstup dat přes sledovaný adresář V případě realizace poţadavků z interního systému ČP II (jak pro „Dávkové zpracování“ tak i „OnDemand zpracování“) a v případě realizace „Spuštění dávky“ v interním systému ČP III, budou vstupní data OMS získána ze sledovaného adresáře. Soubory vstupních dat formátu XML, CSV nebo TXT mohou nebo nemusí obsahovat kompletní data pro zpracování šablon dopisů tiskových výstupů. V případě chybějících údajů ve vstupních souborech zrealizuje OMS při zpracování poţadavku jejich doplnění pomocí „Získání dat v průběhu zpracování“. Získání dat v průběhu zpracování
40
V případě, ţe v rámci poţadavku na realizaci tiskového výstupu byly OMS předány vstupní informace, které neobsahují všechny údaje pro naplnění konkrétní šablony tiskového výstupu OMS tyto informace, získá data přímým přístupem do databází interních systémů PF. Pro tyto účely pouţije konektor JDBC/ODBC a data získá buď SQL dotazem, nebo voláním uloţené procedury. Vstup dat přes online konektor OMS dokáţe přijmout a zpracovat poţadavek na realizaci tiskového výstupu přes online protokol. Případy pouţití konektoru a parametry volání jsou popsány v části Integrace OMS a ČPIII. Datový typ parametrů a implementační podrobnosti jednotlivých volání budou dospecifikovány v rámci analytické fáze.
4.3 ETAPA SCAN Jako podklad pro Analýzu a návrh řešení SCAN bude pouţit Popis plnění SCAN. Do takto vzniklého dokumentu budou doplněny informace o jednotlivých vytěţovaných formulářích, u kaţdého formuláře budou specifikována políčka, která se budou vytěţovat, u kaţdého políčka bude specifikován algoritmus pro kontrolu a případně číselník, proti kterému se bude vytěţená hodnota kontrolovat. Dále bude popsán formát výstupu na disk (TIF + XML, případně PDF + XML, nebo PDF/A + XML). Bude vytvořen návrh testovacích scénářů pro akceptaci řešení. Takto vytvořený dokument bude zaslán Objednateli k připomínkování. Pokud to bude nutné, bude dokument prezentován. Výstupy: Analýza a návrh řešení SCAN Testovací scénáře Akceptace analýzy a zapracování změn Do dokumentu Analýza a návrh řešení SCAN budou zapracovány vzájemně odsouhlasené připomínky a dokument bude prezentován objednateli. Na konci prezentace bude dokument schválen. Do testovacích scénářů budou doplněny případné připomínky.
Výstupy: 41
Schválený dokument Analýza a návrh řešení SCAN se zapracovanými připomínkami Schválené testovací scénáře Nastavení OCR OCR systém KOFAX bude nainstalován na pracovišti optické archivace. Na základě dokumentu Analýza a návrh řešení SCAN bude provedeno nastavení KOFAXu. Výstupy Nainstalovaný a nastavený systém OCR serverech a 1 skenovacím pracovišti Vypracování dokumentace Bude vypracována dokumentace administrátora. Dokumentace administrátora bude obsahovat kapitoly o zálohování, základní správě systému a instalaci dalších skenovacích pracovišť. Výstupy Administrátorská dokumentace Školení Školení uţivatelů a administrátorů proběhne v prostorách Objednatele na nainstalovaném systému. Pro školení OBJEDNATEL zajistí vyplněné formuláře, které bude moţné naskenovat. Výstupy: Prezenční listina z uţivatelského školení Prezenční listina z administrátorského školení Akceptace a zapracování změn Akceptace řešení Proběhne akceptace formou ověření testovacích scénářů. Případné objevené odchylky budou buď opraveny na místě, nebo zaznamenány do testovacích scénářů. Na základě výsledku akceptačních testů bude vyplněn Akceptační protokol. Případné změnové poţadavky, které vyplynou ze školení, nebo akceptačních testů a budou vzájemně odsouhlaseny, se zapracují do řešení. Výstupy Vyplněné testovací scénáře Vyplněný akceptační protokol Případně vyplněný protokol o změnách 42
Nasazení do ostrého provozu Nasazení do ostrého provozu Z řešení budou odstraněna testovací data a řešení se připraví pro ostrý provoz. Protokol o zahájení ostrého provozu Řízení projektu Během celé etapy SCAN budou podle potřeby, nejméně 1x za 14 dní prováděny schůzky vedení projektu. Na nich bude řešen aktuální stav projektu, plánovány úkoly na další období, řízena rizika a řešeny záleţitosti, které z projektu vyplynou. Výstupy Zápisy z vedení projektu
4.4 ETAPA DS Aby bylo moţné provést analýzu poţadavků a návrhu řešení v úzké spolupráci s IT pracovníky pojišťovny, bude na začátku této etapy proveden workshop, který seznámí pracovníky s moţnostmi a limity technologie DS, tedy komponentami Archiv, DMS a okrajově WF, včetně interaktivního předání veškeré dokumentace, která k DS je. Workshop se bude konat v prostorách pojišťovny.
4.5 Analýza poţadavků na TCP Budou sebrány veškeré poţadavky na dokumentový store, především typy uloţených dokumentů, typy souvisejícíh objektů, které ponesou metadata, atributy, vyhledávací a zobrazovací masky, skupiny uţivatelů, organizační struktura, přístupová práva, reporty, auditní informace, konverze dokumentů, práce s unikátními identifikátory dokumentů, verzování dokumentů, tvorbu testovacího prostředí, skartaci, HW a SW nároky řešení. Tento dokument bude předán k připomínkování. Výstup Dokument Analýza poţadavků na TCP
43
4.6 Analýza poţadavků na Interface Budou sebrány veškeré poţadavky na interface k Dokumentovému Store, SCAN, především poţadavky na následující metody: Vystavování dokumentu Na lokální stanici (o parametrech minimálně: Intel Dual Core 2,66 GHz, 1 GB RAM/ Win XP, 2 GBRAM /Vista s rychlost připojení minimálně 10 Mbit/s a maximální latencí v řádu jednotek ms), za podmínky kdy jsou na této stanici iniciovány všechny potřebné aplikace (spuštěn viewer, vyhledány souboru, uţivatel je přihlášen) se první stránka dokumentu vyţádaného z digitálního archívu (kdy dokument má velikost maximálně 200kB, počet jeho stránek nepřesahuje 3 stránky velikosti A4 a formátu dokumentu B/W TIFF) zobrazí na displeji uţivatele ve spuštěné prohlíţečce v 60% případů nejdéle za 3 sekundy, za maximálně za 6 sekund ve 30% případů a zbylých deset procent budou dokumenty zobrazeny, ale v negarantovaném čase. Delegování oprávnění Generování událostí do jiných systémů Uloţit dokument do archivu Vytvořit vazbu mezi dokumenty Získat seznam dokumentů v relaci s daným dokumentem Získat seznam dokumentů omezených hodnotou indexu Změnit hodnotu indexu existujícího dokumentu Rezervace nového ID dokumentu Uloţit dokument do archivu pro rezervované ID Získat dokument dle ID Získat index dokumentu dle ID Ukládání naskenovaných dokumentů a indexu do adresáře dle typu Data potřebná k validaci dokumentů načítat z SQL database Vygenerování a odeslání dokumentu Odeslání kopie dokumentu Uloţ dokument do archivu Rezervuj ID v archivu Zobraz náhled dokumentu
44
Zapracování připomínek do analýz Analýzy poţadavků na DS a interface budou předány klíčovým uţivatelům k připomínkování. Podle potřeby proběhnou schůzky. Po dokončení sběru připomínek budou tyto zapracovány do dokumentu. Výstupy Dokument Analýza poţadavků na interface se zapracovanými připomínkami Dokument Analýza poţadavků na TCP se zapracovanými připomínkami
4.6.1 Tvorba návrhu řešení Na základě vstupních analýz bude vytvořena první verze návrhu řešení realizace sebraných poţadavků, mimo jiné ER model datové struktury DS (viz. obrázek 21), technologie, metody a atributy volání jednotlivých komponent interface a další. Rovněţ budou vytvořeny testovací scénáře. Výstup Návrh řešení DS a Interface Testovací scénáře
Obrázek 21 Datový model jednotlivých dokumentů pouţitých v systému Zdroj: vlastní
45
První prezentace návrhu řešení a zapracování připomínek Návrh řešení a testovací scénáře budou odprezentovány a předány k prvnímu kolu připomínek. Připomínky budou sebrány a zapracovány. Návrh řešení DS a Interface se zapracovanými připomínkami Testovací scénáře se zapracovanými připomínkami
Druhá prezentace návrhu řešení a zapracování připomínek Návrh řešení a testovací scénáře se zapracovanými připomínkami budou odprezentovány a předány k druhému kolu připomínek. Připomínky budou sebrány a zapracovány. Návrh řešení DS a Interface se zapracovanými finálními připomínkami Testovací scénáře se zapracovanými finálními připomínkami Akceptace návrhu řešení Návrh řešení a testovací scénáře budou formálně akceptovány. Výstupy Schválený Návrh řešení DS a Interface Schválené Testovací scénáře Akceptační protokol
4.6.2 Projektové řízení Jednotlivé fáze projektu jsou dále blíţe definovány. Během celé této etapy budou podle potřeby, nejméně 1x za 14 dní prováděny schůzky vedení projektu. Na nich bude řešen aktuální stav projektu, plánovány úkoly na další období, řízena rizika a řešeny záleţitosti, které z projektu vyplynou. Výstupy Zápisy z vedení projektu Fáze vývoj Interface Na základě Návrhu řešení bude vyvinut Interface včetně generování událostí Delegování oprávnění 46
Document input Archivace vloţených dokumentů Konverze do TIFF Výstupy Interface a vyvinuté komponenty nainstalované na testovacím serveru
4.6.3 Fáze realizace Instalace Systém DS bude nainstalován na připravených serverech, tedy archivní a aplikační server. Výstupy Systém nainstalovaný na serverech
Nasazení a pilotní provoz Na základě návrhu řešení bude vytvořen datový model na dokumentovém serveru a provedeno napojení na vyvinutý interface. Po vytvoření dokumentace, vyškolení uţivatelů a provedení testů bude proveden pilotní provoz. Po dokončení pilotního provozu bude systém překlopen do ostrého provozu. Výstupy Systém nastavený podle Návrhu řešení Protokol o provedení pilotního provozu Integrační testy Bude ověřena spolupráce DS s okolím, tedy interakce přes GUI a s pouţitím interface. Jako podklad pro testování budou vyuţity testovací scénáře Výstupy Protokol o provedení integračních testů Akceptační testy Na základě testovacích scénářů budou provedeny akceptační testy. Průběh bude zaznamenán do testovacích scénářů. Výsledek akceptačního testu bude zaznamenán do Akceptačního protokolu. 47
Výstup Vyplněné testovací scénáře Akceptační protokol
4.6.4 Servis a podpora Po zahájení ostrého provozu bude poskytnuta intenzivní podpora po dobu 1 měsíce v rozsahu 5 dní. Výstupy Protokol o provedení podpory Testovací prostředí Pro účely vývoje, testování a školení bude nainstalováno testovací prostředí DS na jeden server. Výstupy Testovací prostředí Dokumentace Budou vytvořeny instalační reporty obou prostředí a administrátorská dokumentace. Nebude dodána uţivatelská dokumentace. Výstupy Instalační report ostrého prostředí Instalační report testovacího prostředí Administrátorská příručka
4.6.5 ETAPA OMS Fáze analýza Kroky před analýzou Základním dokumentem pro zpracování analýzy implementace produktu StreamServe Persuation SP5 (dle „Specifikace software“) je „Seznam klíčových poţadavků na OMS“.
48
Výstupem analýzy je 1. Rozdělení veškeré korespondence pojišťovny (písemné i elektronické) do logických oblastí, v rámci nichţ bude dle obsahu stávající korespondence určeno, jaké by měly vzniknout šablony v OMS systému, tak, aby byly veškeré oblasti komunikace novými šablonami pokryty. Výstupem této části analýzy bude mimo jiné první návrh seznamu šablon OMS, níţe popsaný. 2. Definované, vícenásobně pouţitelné části šablon, další logické celky šablon v systému OMS a doporučení pro vytvoření sdíleného úloţiště těchto komponent. 3. Detailní rozpracování klíčových poţadavků a scénářů a konkrétní návrh jejich řešení v prostředí OMS. Definování procesů v rámci pojišťovny a s tiskovým providerem, které v souvislosti s nasazením systému OMS nově vznikají. 4. Detailní návrh řešení 3 vybraných šablon, jejichţ seznam je uveden v příloze B „Seznam šablon pro převod do OMS“. Dle tohoto návrhu budou v rámci fáze implementace tyto šablony vyvinuty. 5. Poţadavky na změny či rozšíření původního návrhu Integrace OMS ČPIII definovaného v příloze C. 6. Doporučení pro administraci a správu systému OMS v produkci, vč. definování přístupových práv. Proces analýzy jako takový se pak sestává z níţe uvedených částí: Workshop s business uţivatelem nebo uţivateli a s tzv. business konzultantem nad dokumentem „Seznam klíčových poţadavků na OMS“. Analýza poţadavků Rozpad poţadavků do logických celků Popis šablon z pohledu poţadavků Rozpad šablon do funkčních a logických celků Příprava projektu pro tvorbu šablon Dokumentace -
Dokument „Analýza implementace klíčových poţadavků v prostředí OMS“
-
Dokument „Popis návrhu funkčnosti šablon v prostředí OMS“
-
Dokument „Funkční návrh post processingu “
Potřebná součinnost: Dostupnost business uţivatele v plánovaných časech (jedná se o časově náročnou roli) 49
Dostupnost business konzultanta v plánovaných časech. (jedná se o časově náročnou roli) Popis poţadavků Grafický layout (mění-li se oproti stávajícímu stavu) Moţnost následné konzultace s business uţivatelem a business konzultantem s garantovanou dobou odpovědi Součinnost architekta znalého stávající Implementace šablon Výstup (viz Dokumentace výše tj.) Dokument „Analýza implementace klíčových poţadavků v prostředí OMS“ Dokument „Popis návrhu funkčnosti šablon v prostředí OMS“ Dokument „Funkční návrh post processingu “ Uvedené dokumenty budou předány objednateli k připomínkám, v případě potřeby formou prezentace těchto dokumentů. Dokumenty budou předány klíčovému uţivateli k připomínkování. Podle potřeby proběhne schůzka k objasnění připomínek. Po zapracování případných připomínek budou dokumenty revidovány ze strany objednatele a následně akceptovány (akceptační schůzka s podpisem akceptačního protokolu).
4.6.6 Kroky před instalací Před samotným procesem instalace bude ze strany dodavatele dodán PF dokument „Detailní specifikace HW, SW pro instalaci produkčního prostředí OMS“. Na základě tohoto dokumentu bude připraveno PF HW, SW prostředí pro instalaci produkčního prostředí. Jakmile bude toto prostředí připraveno, bude dodavatelem provedena jeho kontrola a jeho připravenost na instalaci produkčního prostředí OMS bude oběma stranami stvrzena podpisem protokolu. Stejně tak bude ze strany dodavatele dodán PF dokument „Detailní specifikace HW, SW pro instalaci testovacího prostředí OMS“. Na základě tohoto dokumentu bude připraveno PF HW, SW prostředí pro instalaci testovacího prostředí. Jakmile bude toto prostředí připraveno, bude dodavatelem provedena jeho kontrola a jeho připravenost na instalaci testovacího prostředí OMS bude oběma stranami stvrzena podpisem protokolu. Dále bude PF dodavateli poskytnut dokument „HW a SW konfigurace počítačů pro instalaci vývojového prostředí“, na kterých bude nainstalováno vývojové prostředí. 50
Tato HW, SW specifikace bude ze strany dodavatele potvrzena podpisem tohoto dokumentu.
4.6.7 Instalace Instalace vývojového prostředí na tři počítače s operačním systémem MS Windows dle dodavatelem akceptovaných specifik viz „HW a SW konfigurace počítačů pro instalaci vývojového prostředí“. Instalace testovacího prostředí na počítač dle dodavatelem akceptovaných specifik viz „Detailní specifikace HW, SW pro instalaci testovacího prostředí OMS“. Instalace s nastavení webových sluţeb Instalace modulů AdHoc, Reviewer, SSSP (ADHoc se rozumí „Ad Hoc Correspondence“, Reviewer se rozumí „Correspondence Reviewer“ a SSSP se rozumí „StreamServe Service Provider“). Integrace do síťové infrastruktury POJIŠŤOVNY. Instalace komponenty StreamServe Previewer (StreamServe Previewer - podporované formáty (PDF, PCL5, PS, TIFF, DCX, TXT) a prohlíţeče (Adobe Acrobat Reader, PCL Viewer, Ghostview, Image, Windows Notepad) pro zobrazení náhledů tiskových výstupů v „nonweb“ aplikacích Nastavení prostředí s MS SQL. Propojení administrátorského prostředí. Otestování prostředí s pomocí testovací aplikace Dokumentace procesu instalace (posloupnost jednotlivých fází instalace) a instalovaných komponent funkční popis nainstalovaných komponent je součástí uţivatelských příruček k produktu. Instalace nezahrnuje následující úkony: Datová integrace modulu AdHoc Příprava hostitelské aplikace (portal, web aplikace, servlet,…) pro AdHoc a Reviewer.
4.6.8 Potřebná součinnost Dedikovaný fyzický HW nebo virtuální prostředí Práva lokálního administrátora v prostředí MS Windows, případně přítomnost administrátora při instalaci. Optimálně samostatný uţivatel v prostředí LINUX, SUN, AIX nebo HP-UX Operační systém MS Windows 2008 server R2 51
Databáze MS SQL 2008 R2 Podporovaný servlet container (při zakoupení Composition center a/nebo Collector) Dostupnost DB administrátora pro vytvoření (dle zakoupené konfigurace) Dvou aţ čtyř databází v prostředí MS SQL Dvou aţ čtyř „resource users“ a tří aţ pěti „access users“ v prostředí Oracle Databáze by měla být nastavena v souladu s doporučením pro pouţití s Persuasion. Datová integrace Ostatní SW bude v souladu se specifikaci dokumentu „Supported platforms and software.pdf“ Výstupy Systém nainstalovaný na poţadovaném HW Protokol o instalaci Implementace projektu Předmětem implementace projektu jsou níţe uvedené činnosti: Project připravený pro integraci se stávajícím prostředím pojišťovny předávání XML souborů potřebných pro naplnění šablony, souborů k archivaci, a výstupních souborů (např. PCL) ve sledovaných adresářích. Project připravený pro integraci s novým prostředím pojišťovny Přijetí poţadavku na vytvoření výstupu (on-line, hromadně) Podle vstupních dat a typu výstupního kanálu výběr šablony Podle potřeby, dotaz na chybějící data primárních systémů Alternativně Podle identifikátorů přiloţení dokumentů formátu TIFF ze souboru k výstupu Podle identifikátorů přiloţení dokumentů poţádat webovou sluţbu Workflow o soubory, které budou k správě přiloţeny. Pro tisky budou přikládány pouze soubory tiff, pro maily a datové schránky moţné přiloţit jakýkoli soubor. Vygenerování náhledu a jeho odsouhlasení Editace v Ad-hoc reţimu 52
Voláním webové sluţby workflow získat rezervovaného id dokumentu v datové storage Vytvoření výstupu a indexu a archivního výstupu Odeslání výstupu zvoleným kanálem Implementace šablon definovaných v „Seznam šablon pro převod do OMS“ pro potřeby testu Nasazení projektu v testovacím prostředí pojišťovny Řízení workflow (moţnost dynamického směrování dokumentů, tedy určení, který dokument půjde na Preview, který na lokální tiskárnu, mailem, SMS, hromadným tiskem či do archivu.) Dokumentace Dokument „Popis projektu pro tvorbu šablon v prostředí pojišťovny“ Potřebná součinnost: Architekt se znalostí stávajícího prostředí a poţadované integrace Architekt s moţností testovacího napojení Web Services Integrace s prostředím produkčního tisku V současnosti nejsou známé poţadavky na tiskové řešení, vycházíme proto z implementací v českém prostředí. V odhadu zohledňujeme i potřebnou úpravu statistik a předávacích protokolů pro tiskové centrum a správu doporučených dopisů dle pravidel České pošty platných od 1.9.2010. V rámci integrace s prostředím produkčního tisku bude tiskovému providerovi PF umoţněno realizovat vlastními silami (rozumí se pověřenými pracovníky tiskového providera) tzv. post processing dávek připravených PF. Implementace projektu „Příprava projektu Post Processor“ pro poţadovaný tiskový výstup (PS, PCL nebo AFP) Správa zásilek podle hmotnosti, typu doručení a země příjemce Tvorba elektronické podací knihy pro českou poštu. Správa zásobníků a příloţí Tvorba souborů pro statistiku a odsouhlasení účtů mezi pojišťovnou a tiskovým centrem. 53
-
Laser report – statistika materiálu
-
Manifest – seznam dokumentů s poštovným
Potřebná součinnost: Zadání typu tiskového streamu Definice poţadavků na typ tisku, obálek a obálkovačku Testovací tisk Definice jmenné konvence a formátu výše uvedených souborů Implementace šablon Implementace 3 šablon definovaných v „Seznam šablon pro převod do OMS“ v rozsahu 12 dnů. Časový pro sadu dokumentů vychází ze znalostí čerpaných na základě existujících dokumentů a zkušeností. Očekáváme, ţe implementace prvních tří šablon bude delší z důvodů ladění procesů. Integrační testy Bude ověřena spolupráce OMS s okolím resp. ČP adaptérem. Jako podklad pro testování budou vyuţity testovací scénáře Výstupy Protokol o provedení integračních testů Fáze pilotního provozu Po vytvoření dokumentace, vyškolení uţivatelů a provedení akceptačních testů bude proveden pilotní provoz. Po dokončení pilotního provozu bude systém překlopen do ostrého provozu. Dokumentace Protokol o provedení pilotního provozu
4.6.9 Rozsah řešení komponenty OMS Rozsahem implementace komponenty OMS v rámci instalace jsou činnosti uvedené v „Kroky před instalací“ a „Instalace“, dále „Kroky před analýzou“ a „Analýza“, dále „Implementace projektu“, „Integrace s produkčním tiskem“ a „Implementace šablon“. Rozsah projektu implementace komponenty OMS plně pokryje, v souladu s akceptovanými dokumenty „Analýza implementace klíčových poţadavků v prostředí OMS“ a „Popis návrhu funkčnosti šablon v prostředí OMS“ poţadavky uvedené v „Seznam klíčových poţadavků na OMS“. 54
Projekt bude realizován na šablonách uvedených v „Seznam šablon pro převod do OMS“ dle dokumentů „Popis projektu pro tvorbu šablon v prostředí pojišťovny“, „Popis funkčnosti šablon v prostředí OMS“ a „Popis řízení a správy workflow“. Součástí projektu je také školení a to v následujícím rozsahu: 1x jednodenní školení Administrace pro maximálně 10 pracovníků 1x čtyřdenní školení Základy + StoryTeller pro maximálně 6 pracovníků 1x třídenní školení Rozšířené + Post Processor pro maximálně 6 pracovníků (včetně pracovníků tiskového providera PF) 1x jednodenní školení uţivatelů Compositon Center a AdHoc pro maximálně 25 pracovníků Všechna školení budou probíhat v češtině a to v prostorách společnosti PF nebo jim určených. Tréninkové materiály jsou v angličtině. V ceně školení je vţdy jedna tištěná sada tréninkových materiálů s moţností přikoupení dalších sad.
4.6.10 Dávkové zpracování Na základě vstupních dat (viz. Pozn.1) ve formě XML, CSV nebo TXT souborů OMS připraví dávku tiskových a elektronických (e-maily, SMS,...) výstupů naplněním šablon ze seznamu „Seznam šablon pro převod do OMS“. Tiskovou dávkou se rozumí sestavení tiskového spoolu a jeho uloţení na PF definované úloţiště. OMS získá soubory vstupních dat ze sledovaného adresáře. OMS zabezpečí, ţe nepřijme do zpracování datové soubory, které nejsou kompletní (např. při vytváření velkého souboru XML nedojde ke spuštění zpracování šablony dokumentu nad souborem, aniţ by byl dokončen přenos tohoto souboru z interního systému PF do sledovaného adresáře). Předmětem tiskového spoolu bude: 1 soubor typu PCL (PS nebo AFP) pro tiskového providera obsahující zpracované šablony nad všemi daty ve vstupních souborech tak, aby bylo moţno realizovat tisk na zařízeních definovaných tiskovým providerem (viz. Pozn.2) 1 soubor typu XML obsahující všechna vstupní data tak, jak byla pouţita pro vytvoření tiskového spoolu. X souborů typu PDF, TIF a XML, kde hodnota X odpovídá počtu záznamů o jednotlivých klientech ve vstupních souborech. Soubory formátu PDF a TIF slouţí pro uloţení do digitálního archivu, soubor typu XML slouţí jako index pro digitální archiv a nese patřičné informace o souborech typu PDF a TIF. 55
Všechny výše definované výstupní soubory budou uloţeny na úloţiště definované PF. Výše popsané dávkové zpracování bude realizováno jak vůči stávajícímu systému PF tj. vůči systému ČP II tak i nově vyvíjenému systému ČP III (viz „Spuštění dávky“ v části „Integrace OMS se systémy PF). Pozn1: Data budou připravena PF. Pro potřeby dávkového zpracování budou datové soubory obsahovat větší mnoţství dat (informace minimálně o 10 klientech PF), pro potřeby jednoho on demand výstupu budou datové soubory obsahovat jeden aţ dva záznamy. Datové soubory budou obsahovat anonymizovaná data tak, aby bylo moţno realizovat všechny poţadavky PF na OMS. Pozn2: V rámci Analýzy musí proběhnout analýza potřeb a moţností tiskového providera na zpracování výstupu PF.
4.6.11 OnDemand zpracování Na základě poţadavku (vstupní data) předaného interním systémem PF zrealizuje OMS tiskový výstup a tento odešle na tiskárnu v systému uţivatele defaultně nastavenou. Současně s tímto tiskovým výstupem provede OMS výstup do formátu PDF, TIFF a XML pro uloţení realizovaného výstupu do digitálního archivu, obdobně jako u procesu poţadavku na „Dávkové zpracování“. Společně s tiskovým výstupem můţe být realizován další v podobě odeslání emailu (včetně příloh – blíţe bod 4) nebo sms zprávy. V případě, ţe bylo v poţadavku (vstupní data) interního systému indikováno zpracování tiskového výstupu jako kopie, oprava nebo opis, realizovat tento tiskový výstup s natištěním (razítkem/vodotiskem) textu „Kopie“, „Oprava“ nebo „Opis“. O úspěšné či neúspěšné realizaci výstupu OMS informuje iniciátora poţadavku prostřednictvím „Notifikace o realizaci tiskového výstupu“ v případě realizace poţadavku v rámci systému ČP III. V rámci systému ČP II zašle na emailovou adresu uţivatele emailovou notifikaci (zprávu) o realizovaném/nerealizovaném tiskovém výstupu. V rámci předávání poţadavků (vstupních souborů) interními systémy se rozumí v případě komunikace se systémem ČP II jako vstupní soubor pro zpracování poţadavku na realizaci jednoho OnDemand výstupu výskyt vstupního souboru xml, csv a nebo txt ve sledovaném adresáři. V případě komunikace s vyvíjeným systémem Č III se jedná o zpracování poţadavku Workflow (interní systém PF) viz „Odeslání dokumentu“ v části „Integrace OMS se systémy PF“. 56
Náhled dokumentu OMS umoţňuje realizovat tiskový výstup s náhledem. Náhled bude realizován ve formátu PDF pro jeho zobrazení pomocí StreamServe Previewer (viz. Pozn3) v Adobe Acrobat Reader. Při zobrazení PDF bude moţné, pomocí aktivních tlačítek generovaných v PDF odsouhlasit nebo stornovat odeslání výstupu. Provedení odsouhlasení nebo stornování bude realizováno prostředky OMS. Pozn3: StreamServe Previewer musí být nainstalován na počítači uţivatele, který poţaduje realizaci náhledu dokumentu, stejně tak jako příslušný prohlíţeč daného typu dokumentů
4.6.12 Distribuce různými výstupními kanály a jejich kombinacemi V případě realizace OnDemand výstupu (viz „OnDemand zpracování“) umoţní OMS místo tiskového výstupu směřovaného na lokální tiskárnu realizovat tiskový výstup do souboru formátu PDF a poslat ho jako přílohu emailu vybranému uţivateli. V případě realizace tiskového výstupu na primární tiskárnu nastavenou v systému uţivatele, zašle OMS notifikační email o realizaci tiskového výstupu. V případě realizace dávkového výstupu (viz „Dávkové zpracování“) OMS realizuje dávku tiskových výstupů do jednoho souboru typu PCL (PS nebo AFP), současně s tímto výstupem realizuje výstup do plnobarevných souborů typu PDF, TIFF a XML souborů. Dalším z výstupních kanálů, který je automaticky uvaţován při zpracování tiskových výstupů, je emailový konektor a jeho prostřednictvím zasílání emailových zpráv. Dalším z distribučních kanálů je v případě realizace komunikačního výstupu z OMS zápis definovaného komunikačního sdělení do interní databáze PF s vyuţitím JDBC/ODBC konektoru. Systém OMS umoţní návaznost jednotlivých výstupů (dopis, email, sms zprava) dle předem definovaných procesů.
57
4.6.13 Interaktivní dokument OMS umoţní uţivateli upravit / stornovat jeden dokument tiskového výstupů (realizovaného na základě poţadavku „OnDemand zpracování“) prostřednictvím uţivatelského interface. V něm bude uţivateli umoţněno třídit a filtrovat jednotlivé dokumenty a tím určovat prioritu zpracování. OMS upozorní uţivatele na to, ţe v zásobníku existuje dokument vyţadující uţivatelovu interaktivitu. OMS umoţní uţivateli realizovat změny na dokumentu, vyjma částí předem blokovaných k úpravám. Při jakékoli úpravě původního dokumentu se automaticky v dolní části zobrazí text se jménem a telefonní linkou uţivatele (dotaţení údajů z databáze uţivatelů). OMS také předá do primárního systému ČP III informaci o tom, ţe byl dokument modifikován. Uţivatel si bude moct vybrat z několika podpisů, které pouţije pro jím vytvářený dokument. Vyţaduje-li to situace, bude mu umoţněno také zvolit jinou adresu příslušící ke smlouvě (např. místo adresy oprávněné osoby pouţít adresu opatrovníka oprávněné osoby – obě adresy budou uloţeny v ČP III a OMS si je pro pouţití v odpovídající šabloně získá SQL dotazem nebo voláním uloţené procedury z příslušné evidence systému ČP III). Takto upravený dokument bude vyţadovat schválení jiným uţivatelem. OMS poskytne upravený dokument definovanému uţivateli, který úpravu dokumentu potvrdí nebo zamítne. Poté je dokument předán zpět realizátorovi úprav, který provede jeho vytištění na lokální tiskárně nebo jej odešle do dávky tj. do tiskového spoolu určeného pro tisk u tiskového providera. Tiskový spool OMS uloţí na definované úloţiště.
4.6.14 Interaktivní dokument jako prostředek pro opravu dokumentu v dávce V průběhu realizace procesu „Dávkové zpracování“ OMS umoţní náhodně nebo dle zadaných pravidel vybrat několik tiskových dokumentů a zařadí je do fronty čekající na manuální úpravy v interaktivním reţimu. OMS pozastaví zpracování dávky. Uţivatel provede úpravy / storna tiskových dokumentů v interaktivním reţimu. Po potvrzení realizovaných úprav OMS dokončí zpracování dávky tiskových výstupů.
4.6.15 Archivace dokumentů OMS v rámci zpracování poţadavků na tiskové výstupy připraví soubory pro uloţení do digitálního archivu, viz „Dávkové zpracování“. V případě realizace poţadavku z interního 58
systému ČP II uloţí soubory v definovaném formátu na úloţiště definované PF. V případě realizace poţadavku z interního systému ČP III odešle OMS zprávu do Workflow (interní systém PF) viz „Uloţ dokument do archivu“ v části „Integrace OMS se systémy PF.
4.6.16 Tisk dávky u tiskového providera OMS připraví tiskovou dávku, viz „Dávkové zpracování“ pro její vytištění u tiskového providera (AZ Prima). OMS vytvoří výstup v jednom z podporovaných tiskových výstupů (PCL) se správou tiskových přihrádek dle dispozic poskytovatele tiskových sluţeb. Zároveň přidá řídící čárové kódy pro automatizované obálkování a správu příloţí dle poţadavků tiskového providera. V implementaci se předpokládá, ţe poţadavky nevybočují z běţných zvyklostí odvětví.‘.
4.6.17 Specifikace a vývoj nové šablony OMS umoţní znalému uţivateli vyvinout šablonu, kromě tří šablon realizovaných dodavatelem, kterou bude moţno zpracovat jak dávkovým tak interaktivním způsobem. V případě realizace poţadavku interního systému ČP II bude šablona očekávat vstupní data ve sledovaném adresáři (jak v případě dávkového tak i interaktivního zpracování), v případě realizace poţadavku interního systému ČP III viz. „Vygenerování a odeslání dokumentu“ a „Spuštění dávky“, očekává vyvinutá šablona vstupní data z Workflow (data v podobě základních identifikátorů jako je např. ID šablony, ID klienta, apod. Zbylá data pro naplnění šablony si OMS získá SQL dotazem nebo voláním uloţené procedury z příslušných evidencí systému ČP III)). Verzování šablon OMS umoţní napojení na stávající systém CVS pro verzování šablon.
4.6.18 Příloţe OMS umoţní uţivateli v rámci interaktivního zpracování šablon vybrat přílohy (z definovaného seznamu nebo úloţiště, digitálního archívu) pro jejich přiloţení k právě realizovanému tiskovému výstupu. Typickým příkladem je dokument z digitálního archivu (smlouva, dodatek nebo jakékoliv jiné sdělení klienta nebo klientovi nebo marketingové sdělení, ve formátu TIFF) nebo různý počet sloţenek. 59
V tomto případě bychom rádi měli detailnější zadání. Například jaké typy příloţí, do jakých formátů, jak je budeme získávat a podobně. Workflow připraví kaţdou z příloh jako samostatný soubor ve formátu TIF a OMS takový soubor dále integruje do svého výstupu dle poţadavků jednotlivých šablon. V případě výstupního kanálu e-mail a datové schránky bude OMS umoţňovat přikládat příloţe (přílohy) i v jiných formátech neţ TIF.
4.6.19 Spojování zásilek OMS umoţní spojení zásilek na základě definovaných pravidel (viz. Pozn.4) tj. v případě vygenerování tiskového výstupu pro jednoho klienta v jeden časový okamţik (typicky jeden den) do různých dávek např. jedna dávka obsahuje registrační dopis a druhá dávka obsahuje mimořádné výpisy zaslat klientovi oba realizované tiskové výstupy v rámci jedné zásilky. V případě, ţe v OMS čeká na vygenerování dokument a v primárním systému (ČP II nebo ČP III) je provedena změna v údaji, který je v dokumentu zanesen, provede se také tato změna v čekajícím dokumentu.
4.6.20 Šablona v šabloně OMS umoţní uţivateli v interaktivním reţimu vybrat další šablonu ze seznamu, kterou OMS naplní daty a realizuje tiskový výstup. Výsledkem této uţivatelovy činnosti jsou pak dva výstupní tiskové soubory resp. adekvátní počet výstupních souborů. Realizace tohoto bodu není předmětem prvotní fáze implementace (pro implementaci tří definovaných šablon není předpoklad volání jedné šablony dokumentu ze šablony jiné). V analýze pouze navrţeno moţné řešení této problematiky. Seznam šablon OMS poskytne interním systémům seznam dostupných šablon (ID šablony, název šablony.) tak, aby s nimi tyto interní systémy mohly pracovat tj. vybírat si dostupné šablony a ty pak volat pro zpracování jimi poţadovaných tiskových výstupů.
60
Datové schránky OMS umoţní Integraci s externí aplikací pro komunikaci s datovými schránkami. OMS připraví komunikační sdělení (tiskový výstup) do takové elektronické formy, aby ho bylo moţno externí aplikací odeslat prostřednictvím datových schránek. SMS zprávy OMS umoţní integraci se systémem MobilChange, tj. umoţní zápis komunikačního sdělení do databáze MobilChange v uţivatelem definovaných intervalech dle jeho stanovených priorit. Komunikačním sdělením se rozumí výstup odesílání sms zpráv, jako níţe popsaným, a jejich řízení tj. definice intervalu generování komunikačního sdělení a jeho odeslání prostřednictvím MobilChange. Pozn.: Komponenta MobilChange – pro PF spravovaná společností DATASYS. Jedná se o aplikaci nabízející propojení SMS zpráv s databázemi, archivy a dalšími způsoby komunikace. Umoţňuje posílat a přijímat SMS z mobilního telefonu přímo v prostředí firemní elektronické pošty. V současné době MobilChange ukládá data do tabulek databáze MS SQL Server 2005.
4.6.21 Šifrování OMS umoţní zašifrování realizovaného výstupu pomocí PGP (pomocí PGP jsou šifrovány celé emailové zprávy tj. tělo emailu včetně jeho příloh) a jeho odeslání emailem. Pozn.: PGP pracuje na principu dvou klíčů. Jeden klíč je veřejný, lze jím zprávu zamknout (zašifrovat), ale uţ nikoliv odemknout (dešifrovat). Druhý klíč je soukromý (privátní), lze jim zprávu odemknout (dešifrovat), ale nikoliv zamknout. V současné době je v pojišťovně pouţívaný software Symantec PGP Desktop Professional verze 10.2.0. Nejedná o součást první fáze realizace, v analýze bude navrţeno moţné řešení této problematiky.
4.6.22 Marketingová sdělení Dávkově zpracovávané dokumenty budou obsahovat marketingová sdělení – transpromo v závislosti na vstupních datech a času. Jejich příloţe mohou být personalizované. OMS zajistí správu všech variant příloţí v dané dávce. 61
4.6.23 Statistiky Pro všechny realizované tiskové výstupy OMS bude vytvářet statistiky. Statistiky budou obsahovat informace o procesech realizujících jednotlivé úlohy, počtech a typech vstupních dat (souborů), časová razítka, počtech zpracovaných/nezpracovaných dat. Tyto statistiky OMS uloţí tak, aby je bylo moţno kdykoliv ze systému na vyţádání získat a to ať jiţ zpracování konkrétní šablony OMS určené pro statistiky nebo jiným způsobem (např. SQL dotazem, exportem dat).
62
5 ZÁVĚR Jako cíl této práce jsem si stanovil popis kompletního nasazení document management systému pro organizaci, která se zabývá poskytováním pojišťovacích sluţeb na území České republiky. Hlavním důvodem, proč jsem si vybral právě toto téma, je skutečnost, ţe si v dnešní době stále větší počet firem uvědomuje, ţe DMS je způsob, jakým lze dosáhnout větší kontroly nad zpracovávanými dokumenty. Kvůli různým a častým legislativním úpravám předpisů a zákonů, se tyto dokumenty stávají nepřehlednými a nakládaní s nimi je o to těţší. Součástí zavádění DMS je také optimalizace řízení procesů, kterými se následně DMS řídí. I kdyţ nelze jednoznačně vyhodnotit veškeré přínosy z ekonomického pohledu, můţeme pomocí měkkých metrik vyčíslit jejich přínosy. Tyto přínosy se většinou projeví tehdy, jakmile propojíme různé systémy typu ERP a například CRM pomocí workflow. To se odvíjí od typu společnosti a jejího pohledu na řízení podnikových procesů, kdy se snaţí dosáhnout vyššího stupně zralosti vnitropodnikových procesů. V kaţdé společnosti jsou totiţ oblasti, kde nasazení DMS můţe přinést markantní výsledky, ale jsou také oblasti, kde se nasazení DMS nemusí jevit jako nezbytné a je spíše kontraproduktivní. Na základě poznatků, které jsem nabyl v rámci své praxe a při tvorbě této práce doporučuji, aby bylo DMS nasazeno pouze v oblasti těch nejklíčovějších procesů. V rámci těchto procesů se většinou nakládá s dokumenty, které je třeba pečlivě spravovat a bezpečně archivovat. Neméně důleţitým aspektem pro zavádění systému tohoto druhu je také zvýšení efektivity práce zaměstnanců a v neposlední řadě spokojenosti koncových zákazníků.
63
POUŢITÁ LITERATURA Elektronické monografie http://www.systemonline.cz/casopis/2004/04_11Ixt01X.jpg http://www.systemonline.cz/clanky/dms-systemy-pro-spravu-a-obeh-dokumentu.htm http://www.systemonline.cz/clanky/dms-systemy-pro-spravu-a-obeh-dokumentu.htm http://businessworld.cz/podnikove-is/dms-a-ecm-pouze-technologie-nespasi-7553
Tištěné monografie OPEN TEXT CORPORATION. OpenText Transactional Content Processing.Customization Guide English. Rev.:24Mar.2012 (TCP100201-CGD-EN-4) OPEN TEXT CORPORATION. OpenText Transactional Content Processing 10.2.1 - System Overview Guide English Rev.:13Dec.2011 (TCP100201-GGD-EN-2)
64
Seznam obrázků Obrázek 1
Schéma komplexního řešení enterprise content managementu
Obrázek 2 XOS DMS pro ERP systém SAP - záznam jednotlivých verzí dokumentů a sledování historie změn Obrázek 3 Toky dokumentů mezi jednotlivými moduly Obrázek 4
Grafické zobrazení jednotlivých modulů
Obrázek 5
Správně vytěţený údaj z čárového kódu
Obrázek 6
Nesprávně vytěţený údaj
Obrázek 7
Ukázka pole formuláře
Obrázek 8
Typ vytěţovaného čárového kódu
Obrázek 9
Pole číslo smlouvy
Obrázek 10 Pole kolonka rodné číslo Obrázek 11 Pole se základními údaji Obrázek 12 Pole pro uvedení titulu Obrázek 13 Pole kód země Obrázek 14 Formulářové pole e-mail Obrázek 15 Pole se základními údaji Obrázek 16 Pole pro příslušníky cizích států Obrázek 17 Ukázka databáze vendors Obrázek 18 Ukázka čárového kódu Obrázek 19 Rozloţení jednotlivých komponent DMS Obrázek 20 Livecycle dokumentu Obrázek 21 Datový model jednotlivých komponentů v systému
Seznam zkratek DMS Document Management System ECM Enterprise Content Management VRS VirtualReScan OMS Output Management System DS Document Storage AML Anti Money Laudering OCR Optical Character Recognition TIF Tag Image Format 65
66
