Ostravská univerzita v Ostravě

Ostravská univerzita v Ostravě

Projekt přípravy a realizace elektronické evidence klíčových dokumentů v DMS (Document Management System)

Závěrečná zpráva o řešení rozvojového projektu MŠMT č. 159/2006

Řešitel: RNDr. Martin Malčík, Ph.D.

Ostrava 2006

Obsah 1. 2. 2.1. 2.2. 2.3. 3. 3.1. 3.2. 3.3. 3.4. 4. 4.1. 4.2. 4.3. 5. 5.1. 5.2. 6. 7. 7.1. 7.2. 7.3. 7.4. 8. 9.

Úvod........................................................................................................................................................ 3 DMS – systém pro správu dokumentů .................................................................................................... 3 Co je základem DMS .............................................................................................................................. 3 Co je principem DMS ............................................................................................................................. 4 Oblasti využití DMS ............................................................................................................................... 4 Výběr technologie ................................................................................................................................... 5 Technologie zahrnuté do procesu výběru................................................................................................ 5 Kritéria výběru technologie..................................................................................................................... 5 Průběh a pravidla výběru ........................................................................................................................ 7 Doporučení technologie .......................................................................................................................... 8 Technologie IBM DB2 Content Manager ............................................................................................... 8 Stručná charakteristika ............................................................................................................................ 8 Struktura technologie .............................................................................................................................. 9 Integrace DMS do univerzitního prostředí............................................................................................ 11 Implementace technologie..................................................................................................................... 13 Aktivity implementace .......................................................................................................................... 13 Otevřené aktivity ................................................................................................................................... 14 Implementace nad rámec projektu ........................................................................................................ 14 Analýza dokumentů .............................................................................................................................. 15 Zájmová oblast dokumentů ................................................................................................................... 15 Nástroj pro mapování resp. tvorbu workflow ....................................................................................... 15 Proces mapování ................................................................................................................................... 16 Proces realizace v DMS ........................................................................................................................ 16 Závěrečné shrnutí projektu.................................................................................................................... 16 Finanční čerpání projektu...................................................................................................................... 17

Přílohy A. B. C. D. E. F. G. H. I. J. K. L.

Příloha č.1 : Magic Quadrant for Enterprise Content Management...................................................... 19 Příloha č.2 : Průběh procesů prezentací ................................................................................................ 20 Příloha č.3 : Splnění/nesplnění požadovaných kritérií pro univerzitní DMS v případě IBM Content Manageru............................................................................................................................................... 21 Příloha č.4 : Těžký klient systému DB2 Content Manager (Windows klient - ukázka) ....................... 25 Příloha č.5 : eClient klient systému DB2 Content Manager (ukázka) .................................................. 28 Příloha č.6 : Portálový klient systému DB2 Content Manager (ukázka) .............................................. 30 Příloha č.7 : Klient administrátora systému DB2 Content Manager (ukázka) ...................................... 33 Příloha č.8 : Zápis z implementačního bloku č. 1 až 2.......................................................................... 34 Příloha č.9 : Vlastníci / Kontaktní osoby / Dokumenty v procesu mapování ....................................... 37 Příloha č.10 : Workflow dokumentu Objednávka v UML 2 ................................................................. 40 Příloha č.11 : Workflow dokumentu Objednávka v BPMN ................................................................. 41 Příloha č.12 : Workflow dokumentu Objednávka v DMS .................................................................... 42

2 / 42

1. Úvod DMS neboli Document Management System je pojem, který není pro „informační současnost“ žádným novým pojmem a je možné se s ním setkat již delší dobu. S postupem času se však tyto systémy pro správu a oběh dokumentů dostaly do popředí zájmu. Jedním z důvodu, proč tomu tak je, je stálý nárůst množství dat, informací a dokumentů v organizacích různého druhu, univerzitní prostředí nevyjímaje. Organizace uspokojují potřeby svých zaměstnanců zákazníků (studentů) a rostoucí množství informací tak musí být zpracováno v mnohem kratším čase. Druhou oblastí, kterou lze DMS velmi efektivně vyřešit, jsou vzrůstající legislativní požadavky. Legislativa klade na organizace vyšší požadavky na uchování veškerých dat a dokumentů spojených s její činností. Fungování organizace musí být transparentní a dlouhodobě zpětně prokazatelná. Toho lze docílit jedině bezpečným uchování všech relevantních dat a dokumentů. Problematika DMS, i přes její relativní „stáří“, není u nás ještě tak aktuální jako v jiných zahraničních zemích, ale postupem času lze očekávat, že i v České republice bude v tomto směru vyvíjen stále větší tlak. Rok 2006 přinesl implementaci systémů DMS na Ostravské univerzitě v Ostravě, VŠB-TUO, Univerzitě Tomáše Bati a na Univerzitě Palackého v Olomouci.

2. DMS – systém pro správu dokumentů Většina činnosti, které na univerzitě probíhají, je spojena s dokumenty a správa dokumentů je oblastí, která tak může výrazně ovlivnit výsledky a efektivitu chodu univerzity. Každý, kdo na univerzitě pracuje s určitými dokumenty, po nějaké době zjistí, že jejich organizace vyžaduje poměrně výrazné úsilí, pokud chce zajistit, aby byl v dokumentech řád a byly sdílené, tedy přístupné těm uživatelům, kterým přístupné mají být. Celá problematika je ještě složitější v okamžiku, kdy se stejnými dokumenty pracuje více lidí nebo se jedná o dokumenty, u kterých je nutné sledovat historii vzniku spolu s jednotlivými verzemi. S rostoucí dobou potřebnou pro vyhledání požadované informace klesá hodnota této informace a mnohdy se stává, že dokumenty jsou raději opakovaně vytvořeny nežli opakovaně využity, což má velký dopad na efektivitu práce s dokumenty a informacemi. Všechny výše uvedené činnosti a negativní důsledky z nich pramenící lze minimalizovat, nebo i zcela odstranit využíváním DMS. Práce s informacemi dnes tvoří jednu z nejdůležitějších částí činnosti univerzity a tak není divu, že i document management (správa dokumentů) nabývá na významu, a pokud je nasazen, může představovat znatelnou konkurenční výhodu.

2.1.

Co je základem DMS

Základem DMS jsou dokumenty spojené v procesech. V první řadě je třeba říci, že pojem dokument v pojetí DMS neznamená pouze klasický kancelářský papír s určitým textem, tak jak si jej při vyslovení tohoto slova představí většina z nás. Dokument je také soubor : a) v elektronické podobě bez ohledu na jeho formát; nejčastěji se setkáváme z formáty kancelářských aplikací MS Office (např. závěrečné zprávy projektů, výstupy/šablony IS MAGION), b) e-mailová zpráva (např. vyjádření souhlasu k vystavení objednávky a/nebo komentář k zápisu z jednání), c) zvukový nebo video záznam (např. záznam z konference, audiovizuální pomůcka k přednášce) d) technický výkres (např. realizační dokumentace investičních staveb univerzity) a mnoho dalších. Všechny tyto objekty jsou nositelé informací, které jsou vytvářeny, modifikovány, sdíleny, zpracovávány a ukládány. Dokumenty lze rozdělit na strukturované a nestrukturované. Strukturované jsou v podobě různých tabulek a databázi, které je velmi snadné elektronicky zpracovávat (např. data v systémech MAGION a/nebo STAG). Nestrukturované jsou jejich přesným opakem (např. dokument výdajová faktura). Aby bylo možné tyto nestrukturované dokumenty, které jsou však také nositeli velmi důležitých informací, efektivně a rychle zpracovávat, vznikly DMS systémy, které spojují tyto dokumenty s reálnými univerzitními 3 / 42

procesy. Zpracování dokumentů v rámci jednotlivých procesů se za podpory DMS stává mnohem rychlejší a efektivnější.

2.2.

Co je principem DMS

Základním principem DMS je umožnit efektivně spravovat a sdílet jakékoliv dokumenty nebo informace. Toho je docíleno v první řádě implementací bezpečného centralizovaného úložiště. Nad tímto úložištěm běží aplikace DMS s možností plné integrace s Portálem univerzity, která uživatelům může nabídnout širokou funkcionalitu pro zpracování dokumentů a zároveň tato aplikace řídí přístup k dokumentům podle nastaveného autorizačního konceptu, čímž je zamezeno zneužití informací při jejich sdílení. Mezi základní rysy DMS patří:

organizace dokumentů do přehledné struktury na základě individuálních požadavků uživatele,

automatická tvorba a řízení verzí a revizí dokumentů,

podpora práce více uživatelů s jedním dokumentem,

efektivní vyhledávání dokumentů,

podpora vytváření standardizovaných dokumentů, přenos dat do dokumentu,

vytváření dynamických pohledů na dokumenty,

podpora elektronického schvalování a uvolňování dokumentů,

správa šablon dokumentů,

evidence historie práce s dokumenty,

publikace dokumentů na intranet,

podpora převodu papírových dokumentů do elektronické podoby (skenování).

2.3.

Oblasti využití DMS

Podle procesů a jejich vazeb na dokumenty můžeme oblasti využití DMS rozdělit na tři části: a) Dokumenty tvoří výstup určitého procesu - DMS nabízí podporu pro vznik a správu dokumentů během jeho celého životního cyklu. U těchto dokumentů se zároveň funkcionality pro elektronické schválení dokumentu před jeho uvolněním. Do této části mohou spadat všechny dokumenty, které na univerzitě vznikají (např. objednávky, různé druhy žádanek, smlouvy, podklady přijímací řízení studentů/zaměstnanců, směrnice, příkazy, dopisy resp. různá vyjádření studentům, informace pro univerzitní web a další. b) Dokumenty jsou vstupem, který procesy startuje - zde DMS primárně řeší evidenci dokumentu, jejíž součástí je obvykle i jeho skenování a následné schválení, realizované pomocí elektronického oběhu dokumentů (workflow). Příkladem této skupiny mohou být například příchozí faktury, které jsou zaevidovány, prochází procesem schválení a poté jsou zaúčtovány. Obzvláště u těchto dokumentů je třeba zajistit bezpečnou archivaci a zamezení jejich změny, protože na jejich základě univerzita provádí své činnosti, které musí být zpětně prokazatelné. Kromě faktur sem můžeme zařadit veškeré příchozí dokumenty. Na archivaci všech příchozích dokumentů je například postaveno řešení spisové služby. c) Dokumenty podporují dané procesy - do třetí skupiny spadají například veškeré dokumenty, které zaměstnanci potřebují jako podklad pro plnění svých pracovních úkolů. Pro tyto dokumenty je důležité, aby byly snadno dostupné a vyhledatelné. V podstatě se jedná o bezpečný archiv dokumentů, který tvoří většina dokumentů z prvních dvou skupin, které již byly zpracovány a uzavřeny, nicméně musí být pracovníkům stále k dispozici. V rámci univerzity jde většinou o aktuální interní předpisy, podepsané smlouvy, schválené a odeslané objednávky nebo faktury a další. Ovšem je nutné si uvědomit, že výše uvedené rozdělení je pro potřeby této závěrečné zprávy velmi 4 / 42

zjednodušené. Obvykle se tyto oblasti vzájemně prolínají a jednotlivé dokumenty a procesy prochází napříč. DMS zároveň přináší řešení pro bezpečnou archivaci všech dokumentů, které jsou jeho součástí, což zajišťuje přístup k těmto informacím i za mnoho let. Systémy DMS jsou velmi flexibilní a jejich „customizací“ je možné je upravit a přizpůsobit konkrétním požadavkům univerzitních potřeb. Proto při výběru technologie byl dán velký důraz na co nejsnazší integrovatelnost s existujícím univerzitním portálovým řešením.

3. Výběr technologie V současnosti jsou na českém trhu nabízeny jak komplexní a robustní technologie pro správu dokumentů tak i specializované, které řeší pouze část celého systému např. Spisová služba. Cílem procesu výběru bylo zvolit komplexní technologii, kterou lze integrovat s existujícími univerzitními systémy a to prostřednictvím centrálního Portálu Ostravské univerzity (dále jen Portál).

3.1.

Technologie zahrnuté do procesu výběru

O zahrnutí technologie do procesu výběru rozhodovalo zejména :

doporučení členů pracovní skupiny DMS VŠB-TU Ostrava, která je spoluředitelem projektu implementace DMS pro univerzity VŠB-TU, UTB Zlín a Univerzita Palackého v Olomouci,

existující obchodní, implementační a servisní zastoupení v ČR a/nebo na Slovensku, které má již zkušenosti s implementací nabízené technologie,

jistota silné, kvalitní a robustní technologie (Příloha č.1).

V následující tabulce jsou uvedeny všechny technologie do procesu výběru zahrnuté :

Technologie SAP NetWeaver FileNET1 IBM Content Manager OpenText Livelink Ginis2 AiP Safe Livelink TreeINFO CRM

Společnosti Autocont CZ Impromat Computer, Datalan (SK) Techniserv, IBM S&T Services, IXTENT GORDIC CPE Group Syconix Camo CSC Computer Science

Tabulka č. 1 – Technologie zahrnuté do procesu výběru.

3.2.

Kritéria výběru technologie

Technologie zahrnuté do výběru byly posuzovány ze tří základních hledisek :

funkcionality,

architektury,

bezpečnosti.

a) Kritéria funkcionality. Technologie : 1

Technologie FileNet byla koncem roku 2006 zakoupena společnosti IBM a brzy by se měla stát nedílnou součástí technologie Content Manager. 2 Zástupce specializovaného systému pro Spisovou službu. 5 / 42

podporuje workflow dokumentů nebo složek dokumentů (dále jen dokument) mezi jednotlivými uživateli nebo skupinami uživatelů,

obsahuje grafický nástroj pro vytváření diagramů workflow procesů. Tento grafický nástroj musí umožňovat modifikaci existujících diagramů,

podporuje různé typy procesů (schvalovací, změnové, ..) oběhu dokumentů,

umožňuje spuštění alternativních toků (včetně paralelních) na základě definovaných podmínek resp. událostí,

umožňuje operativně měnit nebo zakládat procesní schéma na základě mimořádných a neopakovatelných událostí (Ad hoc workflow) a to bez zásahu do programového kódu,

umožňuje oprávněným uživatelům nahlížet na okamžitý stav procesu, případně také upravit právě probíhající proces,

umožňuje spouštět workflow procesy nad existujícími dokumenty v systému nebo automaticky v okamžiku, když jsou dokumenty do systému vkládány (například skenováním, importem,…),

dále umožňuje nastavit automatické spouštění workflow procesu pro určitý typ dokumentu v okamžiku, kdy je dokument v systému vytvořen. Pokud je pro různé typy dokumentů definovaný stejný proces workflow, lze definovat prioritu, s jakou budou procesy spouštěny.

dovoluje nastavit zastupování jednotlivých uživatelů definovaných v DMS,

umožňuje přiřazení rolí pro jednotlivé uživatele do procesního schématu DMS,

pružně automaticky reaguje na změny v personální struktuře univerzity, tj. pohyb zaměstnanců v rámci organizačního schématu případně i krátkodobého charakteru (např. dovolená),

musí být schopen se přizpůsobit změnám v organizační struktuře univerzity formou příslušných zásahů správce systému,

umožňuje automatické nastavení příznaku upozornění, pokud vyprší čas pro provedení požadované činnosti v určitém uzlu workflow nebo pokud vyprší časový limit pro provedení požadované činnosti v celém procesu workflow,

musí umožnit nastavení příznaku přetížení uzlu, pokud počet právě zpracovávaných dokumentů v uvedeném uzlu přesáhne definovanou hranici,

dovoluje na základě nastavených příznaků definovat další postup zpracování prostřednictvím uživatelsky definovaných akcí,

musí umožnit verzování dokumentů včetně možnosti vytvářet paralelní revizní větve s následným schválením/zrušením těchto větví,

musí umožnit pracovat se složenými dokumenty a podporovat logické vazby, které mezi těmito dokumenty mohou existovat (např. check-in/check-out dokumentů),

dovoluje definovat uživatelské (business) aplikace jako pracovní uzly procesu workflow,

musí mít otevřené API pro vytváření vlastních programů pro podporu workflow dokumentů.

b) Kritéria architektury. Technologie :

musí být otevřený pro možnost jednoduché modifikace systému vlastními kapacitami zadavatele,

musí být dostupný i v případě HW poruchy části DMS - podpora požadavku "high-availability",

musí být volně rozšiřitelný pro libovolný počet spravovaných dokumentů bez nutnosti zakupovat další licence,

musí umožňovat práci v distribuované architektuře s možností rozložení zátěže,

musí obsloužit alespoň 200 současně připojených uživatelů. Celkový rozsah uživatelů se bude pohybovat v rozmezí 700 zaměstnanců a 7000 studentů,

musí poskytovat Webové klientské prostředí bez nutnosti instalace dalšího software na straně 6 / 42

uživatele,

musí podporovat rozhraní pro práci v portálovém prostředí IBM WebSphere a být plně integrován v současném portálovém řešení OU,

musí podporovat rozhraní webových služeb pro integraci s ostatními univerzitními systémy,

musí na platformě Windows umožňovat těsnou integraci s nástroji MS Office, a to včetně výměny a synchronizace standardních atributů mezi oběma systémy,

musí umožňovat e-mailové zasílání předem vybraných dokumentů uživatelům pracujících mimo DMS,

musí dovolit hromadný tisk vybraných dokumentů,

musí podporovat rozdílné operační systémy – Windows, Unix, Linux,

je rozšiřitelný o další komponenty, které umožní archivovat dokumenty Novell GroupWise,

poskytuje dokumentované API pro vytváření vlastních aplikací pro správu dokumentů – nejlépe J2EE,

musí umožňovat integraci s dalšími úložišti dokumentů (například relační databáze, JDBC a ODBC zdroje),

licenční politika na uživatele nebo procesor. Vzhledem k počtu univerzitních uživatelů je preferována licence na server.

c) Kritéria technická a zabezpečení. Technologie :

3.3.

administrátorské prostředí a další dodávané nástroje musí být lokalizované do českého jazyka,

musí umožňovat vzdálenou správu všech komponent systému z grafického administrátorského prostředí,

musí oprávněnému uživateli nabízet, bez zásahu do programového řešení, přehlednou a jednotnou správu uživatelů, rolí a skupin s možností přidělovat jim práva,

musí umožňovat autentizaci prostřednictvím Novell eDirectory,

práce nad DMS, dokumenty a práce uživatelů musí být monitorována a uchovávána,

musí umožnit funkčnost elektronického auditu (kdo, kdy dokument měnil/odsouhlasil),

musí splňovat bezpečnostní Common Criteria pro informační systémy,

musí zajistit a zvládat zabezpečenou komunikaci (SSL) a zabezpečit samotný dokument proti zneužití,

musí podporovat fulltextové české prohledávání ve všech běžně používaných formátech dokumentů, jako je např. Text, HTML, XML, MS Word, RTF, Excel, PDF a další,

musí podporovat tvorbu/skladbu vlastních uživatelských dotazů,

musí dovolit exportovat případně importovat všechny informace o jeho konfiguraci prostřednictvím XML formátu.

Průběh a pravidla výběru

Výběr technologie byl odstartován v květnu 2006 prvotním oslovením společností uvedených v Tabulce č.1. Dále následovaly logické kroky procesu výběru : a) Dohoda na termínu první/úvodní prezentace – elektronické oslovení společností, které jsou schopny nabídnout pro projekt zajímavou technologii. Objasnění základních očekávání univerzity od celého systému a dohodnutí prvotní prezentace. b) Realizace prezentace – setkání zejména s obchodními partnery společností a základní představení nabízených technologií. c) Formální vyhodnocení – jednání realizačního týmu – zdali oslovit společnost i pro druhé kolo 7 / 42

prezentací. d) Dohoda na termínu druhé (čistě technologické) prezentace - pokud technologie byla pro univerzitní projekt zajímavá zrealizovala se čistě technologická prezentace jejíž náplní byly konkrétní technické otázky implementace v univerzitním prostředí (např. praktická podpora Novell LDAP3, možnosti API4 rozraní). Prezentace se vždy zúčastnili zástupci technického oddělení, referátu vývoje a bezpečnosti IS/ICT CIT. e) Realizace prezentace - setkání čistě s techniky a analytiky společnosti a detailní technické představení nabízených technologií. f) Vyhodnocení - jednání realizačního týmu – zdali daná technologie je pro řešení DMS univerzity vhodné nebo nikoliv. Jednotlivé kroky v procesu prezentací byly podrobně zaznamenávány. Centrálním „projektovým“ místem Projektu DMS se stal http://cvportal.osu.cz/dms/. Portál je přístupný pouze autorizovaným uživatelům. Pro ucelenou představu je příklad záznamu průběhu prezentací pro společnost GORDIC a IBM uveden Příloze č.2 této zprávy.

3.4.

Doporučení technologie

Na základě splnění/nesplnění jednotlivých kritérií uvedených v kapitole 3.2. , důležitosti integrace se stávajícím řešením WebSphere Portal, integrací s kancelářským systémem, garantovanou podporou Novell eDirectory neboli LDAP, nabídkou dokumentovatelné API na platformě J2EE, servisní podporou, zkušeností z jiných projektů bylo realizačním týmem rozhodnuto o výběru technologie společnosti IBM DB2 Content Manager. Příklad splnění/nesplnění kritérií uvedených v kapitole 3.2. je zachycen v Příloze č.3 této zprávy a týká se vybrané technologie DB2 Content Manager.

4. Technologie IBM DB2 Content Manager 4.1.

Stručná charakteristika

DB2 Content Manager je jádrem portfolia produktu DB2 Content Management pro správu obsahu v organizacích různého typu a velikosti. Poskytuje vícevrstvou, distribuovanou architekturu, která nabízí rozšiřitelnost, otevřenost a bezpečné prostředí. Obsahuje datový model s podporou XML. Integruje se do aplikací a aplikačního programového vybavení pro kritické úlohy, včetně produktů DB2 Records Manager, WebSphere MQ Workflow, portálu WebSphere Portal a Workplace Forms. Podporuje replikaci k ukládání a správě objektů na více místech. Nabízí společné rozhraní API k integraci všech forem obsahu do systémů Customer Relationship Management (CRM – systém pro řízení vztahu se zákazníky), systémů Enterprise Resource Planning (ERP – systém plánování zdrojů v organizaci) a obchodních aplikací. Racionalizuje sled prací prostřednictvím technicky pokročilých řešení. Pro práci uživatelů nabízí využití tří základních klientů – těžký Windows klient, lehký eClient (WWW prohlížeč) a portálový klient (soustava portletů pro IBM WebSphere Portal). Portálový klient je preferovaným řešením Ostravské univerzity.

3 4

Lightweight Directory Access Protocol - protokol pro přístup k adresářovým službám v on-line komunikacích. Aplikační programové rozhraní - soubor programů, knihoven a rutin, které slouží k programování aplikací.

8 / 42

Faktury, tiskové výstupy Skenované papíry a faxy Wireless & PDA

SCM, CRM data, SAP, Oracle Centrálně uložená a spravovaná data DMS OU

E-mail (Novel GroupWise) Dokumenty kancelářských aplikací

Kiosk

Portál / Web prohlížeč

Audio, video, fotografie Web stránky Helpdesk

Obrázek č. 4.1 – Možnosti využití sytému pro správu dokumentů - DB2 Content Manager.

4.2.

Struktura technologie

Technologie IBM DB2 Content Manager (dále jen DMS) má třívrstvou architekturu. Konkrétně je složen z těchto základních komponent (Obrázek č.4.2) : a) Klienti - DMS nabízí 3 druhy klientů prostřednictvím,kterých uživatel může se systémem pracovat :

klient pro Windows – jedná se o tzv. těžkého klienta, který je postaven na platformě 9 / 42

C++; klient nabízí plnou standardní funkčnost pro práci s dokumenty + nástroje pro skenování, které v ostatních klientech nejsou standardně obsaženy, klient komunikuje přímo s Library Serverem; součásti klienta je také rozhraní Open Document Management API (ODMA5) , které umožňuje připojení desktopových aplikací WORD, EXEL, PowerPoint, VISIO, Outlook přímo do DMS, ukázka těžkého klienta je uvedena v Příloze č. 4,

lehký klient tzv. eClient – je každému oprávněnému uživateli přístupen prostřednictvím internetového prohlížeče bez nutnosti instalace, klient nabízí nižší funkčnost oproti Windows klientu, ukázka těžkého klienta je uvedena v Příloze č. 5,

portálový klient – soustava 5 portletů v rámci existujícího univerzitního portálu IBM WebSphere nabízející plnou funkčnost mimo nástrojů pro skenování, toto rozšíření je zapotřebí dopracovat, ukázka portálového klienta je uvedena v Příloze č.6,

klient administrátora – Windows klient pro potřeby správy celého systému, správy parametrů Library Serveru a Resource Managerů, definice uživatelů (LDAP), přístupová práva, datové modelování, definice workflow, verzování, export definic do XML a další, ukázka klienta administrátora je uvedena v Příloze č.7.

b) Library Server (LS) – komponenta DMS, která ukládá, řídí a provádí řízení přístupu k objektům (dokumentům), uložených na jednom nebo více Ressource Managerech. LS zpracovává požadavky z uživatelského klienta a udržuje integritu mezi všemi komponentami DMS. LS je založen na relačním databázovém systému a lze k němu přistupovat přímo SQL6 jazykem nebo přes databázového klienta. LS je v systému DMS vždy jen jeden a musí být nainstalován na stejném stroji jako databáze. c) Resource Manager (RM) – komponenta DMS, která uchovává samostatné objekty resp. dokumenty DMS na souborový systém a ty dále spravuje. DMS může mít jeden nebo více RM a ty mohou být umístěny ve stejné nebo různých lokalitách oproti Library Serveru. Klient uživatele pracuje s objekty prostřednictvím Library Serveru. RM pro svou práci potřebuje databázový systém kde jsou uložena konfigurační nastavení (např. informace o indexech uložených dokumentů). d) VideoCharger Server - řešení k poskytování souvislého (streaming) datového toku v reálném čase pro multimediální typy dat (AVI, MPG, MP3 a jiné). Odbouráva download a uložení na straně klientu. Uživatel si tak může například spustit video záznam přednášky bez toho aniž by jej musel nejprve stáhnout na svůj lokální počítač. e) OnDemand Server – řešení pro správu elektronických výstupů umožňující zachycování počítačových výstupů velkého objemu stejně jako archivaci skenovaných dokumentů. f) Tivoli Storage Manager – řešení pro správu zálohování fyzického úložiště dokumentů Ressource Manageru.

5 6

Aplikační programové rozhraní pro správu otevřených dokumentů. Databázový dotazovací jazyk. Podstatou SQL je používání interaktivních dotazů při práci s databází.

10 / 42

Obrázek č. 4.2 – Základní architektura univerzitního systému DMS (technologie IBM DB2 Content Manager).

4.3.

Integrace DMS do univerzitního prostředí

a) Obecný návrh integrace Klient

+ ODMA

Administrátorský těžký klient

CM portlety lehký klient

Oracle

Legato NetWorker

IBM WebSphere Portal Server – Express Plus 5.0.2 Information Integrator for Content (relační konektor) Diskové pole Library Server (LS)

DB2 pro LS

DB2 pro RM

Tivoli Storage Manager

WebSphere Application Server Resource manager (RM)

VideoCharge Server

OnDemand

Obrázek č.4.3 – Obecný návrh integrace komponent DMS do prostředí univerzity (stávající univerzitní komponenty jsou vyznačeny modrou barvou).

b) Realizace integrace

11 / 42

IBM WebSphere Portal 5.0.2

CM Portlety

CIT Portlety

autorizace (ID, skupina) Novell eDirectory 8.7.3.2

SUSE Linux Enterprise 8

LDAP NDS

autorizace (ID, skupina) svázání skupin z LDAP a dané role z Portálu

synchronizace skupin

DB pro LS

DB pro RM

URL + security token

IBM WebSphere Portal 5.1 CM Resource Manager

Oracle

Oracle nebo DB2

CM Library Server



Obrázek č.4.4 – Technická realizace integrace komponent DMS. V grafickém návrhu obrázku č.4.4 je také zaznačeno silné zabezpečení komunikace s uloženými dokumenty (vazba mezi Library Serverem a Ressource Managerem: URL+security token). K dokumentům je možné přistoupit pouze prostřednictvím Library Serveru. Na základě žádosti uživatele o dokument je vygenerován řetězec složený s URL (fyzické umístění dokumentu na Ressource Manageru) a Security tokenu. URL je generováno dynamicky a pouze s časovým omezením. Security token je generován na základě ověření uživatele a aplikace resp. klienta, kterým uživatel k dokumentu přistupuje.

c) Řešení autentizace DMS v univerzitním prostředí Se systémem pro správu univerzitních dokumentů popisovaný v této závěrečné zprávě je možné pracovat se 3 druhy uživatelských klientů (viz. kapitola č. 4.2). Preferovaným klientem je klient portálový. Proces autentizace uživatele přistupujícího do systému prostřednictvím Portálu :

Krok č.1 – přihlášení uživatele prostřednictvím přihlašovacího portletu do univerzitního Portálu (http://portal.osu.cz) - uživatelské jméno a heslo je zasláno Portálu (na obrázku CIT WAS).

Krok č.2 – Portál provede automatické ověření identity a oprávnění uživatele vůči univerzitnímu uložišti „identit“ (na obrázku CIT LDAP). Pokud je identita uživatele ověřena je přihlášen do Portálu.

Krok č.3 – uživatel zvolí práci v DMS. Zde má k dispozici soustavu portletů, které si opět ověřují identitu uživatele. Důvodem tohoto opětovného ověřování je skutečnost, že do DMS je možné přistoupit i jinými klienty (viz. kapitola č. 4.2), kteří postrádají ověřovací mechanismus Portálu (viz. Krok č.1). Je důležité upozornit, že ověření v kroku č.3 probíhá na pozadí bez zásahu uživatele – DMS umožňuje Single Sing-On neboli mechanismus jednotného přihlášení. To v praxi znamená, že uživatel se přihlásí pouze jednou při vstupu na Portál.

Krok č.4 – předání uživatelského jména a hesla systému DMS, který provede opětovné ověření identity uživatele.

12 / 42

1

WWW prohlížeč uživatele

4

CIT WAS

id, pass

id, pass

IBM CM Library Server

3 ← Oprávnění uživatele Požadavek na oprávnění uživatele →

Autentizace

CM Portlety

CIT Oracle

2 ← Výsledek autentizace Požadavek na autentizaci →

CIT LDAP

Obrázek č.4.5 – Proces autentizace uživatele přistupujícího do DMS.

5. Implementace technologie Proces implementace technologie DMS vycházel ze Studie proveditelnosti a byl složen z následujících aktivit : a) instalace a konfigurace IBM DB2 Serveru, b) instalace a konfigurace IBM WebSphere Application Server, c) instalace a konfigurace IBM DB2 Content Manager, eClient, Windows klient (ODMA), d) instalace a konfigurace IBM DB2 Information Integrator for Content Edition, e) propojení, konfigurace LDAP, f) propojení s Oracle databází, g) instalace a konfigurace Content manager portletu, h) testování a odladění, i)

analýza, návrh a zpracování dokumentace workflow procesů,

j)

implementace a nastavení prostředí (dokumentace),

k) základní zaškolení administrátora a uživatele, l)

podpora v pilotním režimu,

m) základní zaškolení administrátora Content Manageru, n) zpracování dokumentace, o) projekt management. Jednotlivé aktivity byly realizovány buď přímo v prostorách univerzity na předem dohodnutých schůzkách a nebo vzdáleně i prostřednictvím virtuální privátní sítě (VPN).

5.1.

Aktivity implementace

Jednotlivé aktivity implementace byla naplňovány v následujících implementačních blocích a s obsahem : a) Blok č.1 :

instalace a konfigurace IBM DB2 Serveru, 13 / 42

instalace a konfigurace IBM WebSphere Application Server,

instalace a konfigurace IBM DB2 Content Manager, eClient

instalace a konfigurace IBM WebSphere Information Integrator Content Edition

základní zaškolení,

b) Blok č.2 :

propojení, konfigurace LDAP,


c) Blok č.3 :

analýza workflow procesu – „Objednavka“

instalace a konfigurace IBM DB2 Content Manager Windows klient (ODMA),

analýza zálohování, použití produktu IBM Tivoli Storage Manager (TSM) a Hierarchical Storage Managment (HSM),



d) Blok č.4 :

instalace produktu Tivoli Storage Manager,

konfigurace Hierarchical Storage Managment,



e) Blok č.5 :

analýza, návrh a zpracování dokumentace k workflow procesů,

instalace a konfigurace Content manager portletu,

instalace produktu IBM WebSphere Portal 6.0 (nad rámec projektu),

testování a odladění,

Kurzívou zmíněné aktivity se nedají považovat za jednorázové a byly vykonávány průběžně během realizace celého projektu. Výstupem každého implementačního bloku byl podrobný zápis o provedených pracích – výsledcích a problémech. Ukázka takovéhoto zápisu je uvedena v Příloze č. 8 této zprávy.

5.2.

Otevřené aktivity

Vzhledem k náročnosti a problémům při implementaci zejména v navázání na univerzitní „úložiště identit“ tzv. LDAP byly některé aktivity přesunuty na leden až únor 2007 : a) základní zaškolení administrátory DMS a správce/tvůrce workflow, b) zpracování finální dokumentace, c) podpora v pilotním režimu dle požadavku univerzity (nad rámec projektu).

6. Implementace nad rámec projektu V rámci realizace projektu se podařilo s IBM dohodnout několik aktivit nad rámec tohoto projektu, které nebyly ve smlouvě o dílo dohodnuty a tudíž se nepromítly do ceny: a) Převod licence Portálu – po dohodě se Západočeskou univerzitou v Plzni a IBM byla bezplatně 14 / 42

převedena licence pro využívání Portálu verze 5.0 na stranu Ostravské univerzity. Tímto krokem se otevřely možnosti k zajištění lepších služeb Portálu (např. upgrade, zajištění servisních služeb IBM). b) Instalace produktu IBM WebSphere Portal 6.0 – v rámci projektu bylo zajištěno licenční pokrytí Portálu ve verzi 6. Nad rámec projektu pak IBM provedla instalaci portálu, zpracování dokumentace k instalaci a zaškolení správců. c) Instalace produktu IBM Tivoli Storage Manager – technologické posílení univerzitního systému zálohování. d) Servisní podpora pro IBM WebSphere Portal 6.0 – nad rámec projektu byla dohodnuta servisní podpora do 05.2007 bez finančního zatížení projektu.

7. Analýza dokumentů 7.1.

Zájmová oblast dokumentů

Volba oblastí dokumentů, které budou mapovány (bude popsáno workflow) v roce 2006 byla učiněna na základě jejich obsahu. Tak vznikly dokumenty pro oblasti: a) personální, b) právní, c) provozní, d) ekonomické. Bez ohledu na úroveň v organizačním schématu univerzity. Z tohoto pohledu byli tedy kontaktovány osoby pracující s co největším počtem dokumentů v dané oblasti (např. personální dokumenty – personalistka, ekonomické dokumenty – tajemníci fakult, vedoucí ekonomického útvaru).

7.2.

Nástroj pro mapování resp. tvorbu workflow

Pro zmapování současného stavu dokumentů byl využit jazyk UML 2 (Unified Modeling Language) a nástroj Visual Paradigm for UML. a) UML 2 – je grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. UML nabízí standardní způsob zápisu jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. UML neobsahuje způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy. b) Visual Paradigma for UML - obsahuje nástroje pro kompletní vizuální návrh architektury aplikací a její vyjádření pomocí nejnovější notace jazyka UML (Unified Modeling Language). Nabízí propracované IDE pro vizuální návrh, může být dokonce integrováno s vývojovými prostředími Visual Studio .Net, Eclipse/WSAD, NetBeans/Sun ONE a JBuilder. Získáte kontrolu nad kompletním životním cyklem návrhu a vývoje aplikace. Návrhy lze exportovat do mnoha grafických formátů i tisknout.

15 / 42

Obrázek č. 7.1 – Zjednodušený příklad diagramu dokumentů objednávka a faktura v jazyce UML2.

7.3.

Proces mapování

Proces mapování současného stavu dokumentů resp. tvorby workflow probíhal vždy dle scénáře : a) kontaktování uživatele (viz. kapitola 7.1), b) objasnění problematiky DMS, obsahu a výsledku procesu tvorby workflow, c) samotný proces tvorby workflow, d) formální schválení uživatele. Seznam dokumentů a osob se kterými bylo workflow tvořeno je součástí Přílohy č.9 této zprávy. Je nutné zdůraznit, že vytvořená workflow odráží současný stav. Vytvořená workflow byla odsouhlašována uživateli a tak připravena k diskuzi oprávněným osobám, které mohli následně workflow dokumentu změnit a schválit pro realizaci v DMS. V Příloze č. 10 této zprávy je pro názornost uveden příklad workflow dokumentu Objednávky. Proces schvalování oprávněnými osobami v projektu nebyl úspěšně vyřešen. Vyřešení je plánováno pro rok 2007 na úrovni vedení univerzity.

7.4.

Proces realizace v DMS

Součástí projektu byla pilotní realizace vybraného workflow dokumentu v implementovaném systému DMS. Východiskem bylo workflow vytvořené ve fázi mapování aktuálního stavu dokumentů (příklad viz. příloha č.10). Takto vytvořené workflow bylo zpracováno v jazyce BPMN, který je standardem pro popisování procesů. V Příloze č.11 je uvedeno workflow vytvořené v jazyce BPMN dokumentu Objednávky. Takto optimalizovaný proces může být následně převeden do systému DMS. Dokument objednávka realizovaný v systému DMS je uveden v Příloze č.12 této zprávy.

8. Závěrečné shrnutí projektu V rámci řešení byly splněny základní kontrolovatelné výstupy projektu : a) provedena studie proveditelnosti nasazení systému DMS na Ostravské univerzitě, b) zmapování dostupných technologií a výběr technologie pro univerzitu vhodné, c) implementace systému DMS, 16 / 42

d) spolupráce více uživatelů „nad“ sdílenými dokumenty, e) základní zmapování dokumentů, f) základní administrátorské i uživatelské proškolení celého systému. Pro následující období prvních měsíců 2007 bude : a) dokončena podrobná dokumentace celé implementace systému DMS, b) podrobné zaškolení administrátora DMS a administrátora/správce workflow systému, c) technická podpora upgrade Portálu na nejnovější verzi (tato činnost je nad rámec projektu), d) úkoly plynoucí z návrhu projektu DMS 2007.

9. Finanční čerpání projektu Číslo a název projektu

Projekt přípravy a realizace elektronické evidence klíčových dokumentů v DMS (Document Management System)

Program

Program 4 rozvoj moderních technologií,

Řešitel (jméno a příjmení, titul, pracoviště)

RNDr. Martin Malčík, ředitel CIT, Ostravská univerzita v Ostravě

17 / 42

Přidělená dotace na řešení projektu (ukazatel I)

Kapitálové finanční prostředky

Z toho

Dlouhodobý nehmotný majetek (SW, licence) Samostatné věci movité (stroje, zařízení)

Celkem kapitálové finanční prostředky

Z toho

628000 1374552,3 993000 246447,70 1621000 Přidělená dotace na řešení projektu (ukazatel I)

Běžné finanční prostředky

Čerpání dotace

1621000

Čerpání dotace

Mzdy

200000

251409

Pohyblivé složky mzdy

100000

61000

Odměny dle dohod o pracích konaných mimo prac. poměr

66000

0

Odvody na sociální a zdravotní pojištění

35000

87992

Drobný majetek

49000

49205,90

Materiální náklady

100000 175599,36

Služby a náklady nevýrobní povahy

534000 500462,85

Cestovní náhrady

100000

58330,89

0

0

1184000

1184000

Stipendia Celkem běžné finanční prostředky

18 / 42

A. Příloha č.1 : Magic Quadrant for Enterprise Content Management

Zdroj: Gartner,2006

19 / 42

B. Příloha č.2 : Průběh procesů prezentací Společnost GORDIC

Datum

Akce

16.5.2006 17.5.2006 18.5.2006 22.5.2006

Poptávka na předvedení produktu odeslána. Zareagovali na poptávku s otázkou na další postup. Navržení termínu prezentace na 29.5.06 od 8:00 do 12:00. Čekáme na vyjádření. Termín prezentace potvrzen + ujištění o prezentaci technologické nikoliv obchodní. Termín prezentace opětovně potvrzen. Dále zasláno předpokládané obsazení ze strany CIT a přímá žádost na to, aby prezentace proběhla v duchu technologickém nikoliv obchodním Prezentace zrealizována. Podrobné předvedení produktu GINIS, což je spisová služba. Z prezentace vytvořen zvukový záznam. Odesláno vyrozumění o vyřazení z technologického "hledáčku" v rámci diskutovaného projektu. Důvodem k vyřazení je úzké zaměření nabízené technologie pouze pro potřeby spisové služby.

25.5.2006 29.5.2006 13.6.2006

Note Audio záznam prezentace umístěn na ..\Cluster_data_server\Data\Home\ Zamestnanci\Cit\DMS\prezentaceAudio Společnost IBM

Datum

Akce prezentace + následný postup realizace

17.5.2006

Poptávka na předvedení produktu odeslána. Telefonický rozhovor s pí. Belatkovou. IBM poptávalo informativní schůzku na základě, které by vytvořili prezentaci produktu. Odkázal jsem je na schůzku, která proběhla se společností Techniserv a dle zástupců této společnosti měla tato schůzka sloužit pro diskutovanou přípravu prezentace. Belatková kontaktuje Technisrv a vše si vysvětlí a dá vědět. Telefonický rozhovor s pí. Belatkovou. Ze strany IBM podání návrhu na realizaci informativní schůzky s p. Vyhnalíkem (Teamleader Software Sales SMB). Prvotní schůzka zrealizována. Vyjasněny představy OU na DMS a připraveny podklady pro samotnou prezentaci na živo. Ta dle vyjádření p. Vyhnalíka by se měla uskutečnit v průběhu 24. týdne (od 12 - 15.6). Prezentace dohodnuta na 21.6.2006. Ještě ověřím vytvoření formálního finančního rámce. Prezentace zrealizována (p. Musil) a dohodnut termín další podrobnější prezentace s přihlédnutím k univerzitnímu prostředí IBM WebSphere Portal. Termín 1.7.2006. Prezentace zrealizována. Otevřeno téma vypracování Studie proveditelnosti Nasazení IBM technologií pro správu dokumentů pro Ostravskou univerzitu. Jednání realizačního týmu a rozhodnutí o výběru technologie IBM (Malčík, Šimonek, Kantor, Pomezný). Následně diskutováno s vedoucími oddělení Kamrádem a pí. Lokajovou – učiněno definitivní rozhodnutí. Formální schůzka k tématu Studie proveditelnosti a jejím obsahu + zodpovězení prvotních vstupních otázek pro studii a dohoda na termínu realizace Studie (od 1. – 10.9.2006) Termín dohodnut na 5. a 6.9.2006 Realizace schůzky analytiků IBM a počáteční vklad pro Studii proveditelnosti. Realizace Studie na straně IBM. Formulování smluvních podmínek realizace. Implementace technologie

1.6.2006

6.6.2006 8.6.2006 12.6.2006 21.6.2006 1.7.2006 27.7.2006 1.8.2006 1.9.2006 5. a 6.9.2006 09.2006 od 10.2006 do 12.2006

20 / 42

C. Příloha č.3 : Splnění/nesplnění požadovaných kritérií pro univerzitní DMS v případě IBM Content Manageru Požadavky Kritéria funkcionality

Způsob zajištění

Poznámka

podporuje workflow dokumentů nebo splňuje v plném složek dokumentů (dále jen dokument) mezi rozsahu jednotlivými uživateli nebo skupinami uživatelů,

standardní funkcionalita

obsahuje grafický nástroj pro vytváření splňuje v plném diagramů workflow procesů. Tento grafický rozsahu nástroj musí umožňovat modifikaci existujících diagramů,


podporuje různé typy procesů (schvalovací, změnové, ..) oběhu dokumentů,

splňuje v plném rozsahu


umožňuje spuštění alternativních toků (včetně paralelních) na základě definovaných podmínek resp. událostí,



umožňuje operativně měnit nebo zakládat procesní schéma na základě mimořádných a neopakovatelných událostí (Ad hoc workflow) a to bez zásahu do programového kódu,



umožňuje oprávněným uživatelům nahlížet na okamžitý stav procesu, případně také upravit právě probíhající proces,



umožňuje spouštět workflow procesy nad splňuje v plném existujícími dokumenty v systému nebo rozsahu automaticky v okamžiku, když jsou dokumenty do systému vkládány (například skenováním, importem,…),


dále umožňuje nastavit automatické spouštění workflow procesu pro určitý typ dokumentu v okamžiku, kdy je dokument v systému vytvořen. Pokud je pro různé typy dokumentů definovaný stejný proces workflow, lze definovat prioritu, s jakou budou procesy spouštěny.



dovoluje nastavit zastupování jednotlivých uživatelů definovaných v DMS,



umožňuje přiřazení rolí pro jednotlivé uživatele do procesního schématu DMS,



pružně automaticky reaguje na změny v personální struktuře univerzity, tj. pohyb zaměstnanců v rámci organizačního schématu případně i krátkodobého charakteru (např. dovolená),



musí být schopen se přizpůsobit změnám v organizační struktuře univerzity formou příslušných zásahů správce systému,



21 / 42

umožňuje automatické nastavení příznaku splňuje v plném upozornění, pokud vyprší čas pro provedení rozsahu požadované činnosti v určitém uzlu workflow nebo pokud vyprší časový limit pro provedení požadované činnosti v celém procesu workflow,


musí umožnit nastavení příznaku přetížení uzlu, pokud počet právě zpracovávaných dokumentů v uvedeném uzlu přesáhne definovanou hranici,

splňuje

technologie umožňuje správci definovat počet úkolů zpracování daného dokumentu, v případě překročení podmínky lze například zaslat notifikační zprávu definovanému uživateli nebo zvolit alternativní cestu v procesu (workflow)

dovoluje na základě nastavených příznaků definovat další postup zpracování prostřednictvím uživatelsky definovaných akcí,



musí umožnit verzování dokumentů včetně možnosti vytvářet paralelní revizní větve s následným schválením/zrušením těchto větví,



musí umožnit pracovat se složenými dokumenty a podporovat logické vazby, které mezi těmito dokumenty mohou existovat (např. check-in/check-out dokumentů),

splňuje

technologie umožňuje převzít jednotlivé dokumenty, které jsou v něm uloženy s logickými vazbami

dovoluje definovat uživatelské (business) aplikace jako pracovní uzly procesu workflow,



musí mít otevřené API pro vytváření vlastních programů pro podporu workflow dokumentů.


plná podpora J2EE nejen izolovaně pro prostředí Content Manageru, ale také v rámci integrace s IBM WebSphere

musí být otevřený pro možnost jednoduché modifikace systému vlastními kapacitami zadavatele,



musí být dostupný i v případě HW poruchy části DMS - podpora požadavku "high-availability",



musí být volně rozšiřitelný pro libovolný splňuje v plném počet spravovaných dokumentů bez nutnosti rozsahu zakupovat další licence,


musí umožňovat práci v distribuované architektuře s možností rozložení zátěže,



musí obsloužit alespoň 200 současně připojených uživatelů. Celkový rozsah uživatelů se bude pohybovat v rozmezí 700 zaměstnanců a 7000 studentů,



Kritéria architektury

22 / 42

musí poskytovat Webové klientské prostředí splňuje v plném bez nutnosti instalace dalšího software na rozsahu straně uživatele,

standardní funkcionalita, uživatel může přistupovat prostřednictvím 3 klientů – Windows klienta, eClienta – WWW prohlížeč a Portálového klienta resp.soustavy 5 portletů.

musí podporovat rozhraní pro práci v splňuje v plném portálovém prostředí IBM WebSphere a být rozsahu plně integrován v současném portálovém řešení OU,


musí podporovat rozhraní webových služeb splňuje v plném pro integraci s ostatními univerzitními rozsahu systémy,


musí na platformě Windows umožňovat těsnou integraci s nástroji MS Office, a to včetně výměny a synchronizace standardních atributů mezi oběma systémy,



musí umožňovat e-mailové zasílání předem vybraných dokumentů uživatelům pracujících mimo DMS,



musí dovolit hromadný tisk vybraných dokumentů,


lze na základě programového modulu

musí podporovat rozdílné operační systémy splňuje v plném – Windows, Unix, Linux, rozsahu


je rozšiřitelný o další komponenty, které umožní archivovat dokumenty Novell GroupWise,


standardní funkcionalita – zabezpečena prostřednictvím Open Document Management API (ODMA)

poskytuje dokumentované API pro vytváření vlastních aplikací pro správu dokumentů – nejlépe J2EE,



musí umožňovat integraci s dalšími úložišti dokumentů (například relační databáze, JDBC a ODBC zdroje),


standardní funkcionalita zabezpečena vývojem příslušných konektorů

licenční politika na uživatele nebo procesor. splňuje Vzhledem k počtu univerzitních uživatelů je preferována licence na server.

licenční politika je postavena na způsobu licencování pro uživatele a z části i pro server, v rámci univerzitního prostředí je možné žádat o vysoce speciální ceny

Kritéria technická a zabezpečení administrátorské prostředí a další dodávané nástroje musí být lokalizované do českého jazyka,



musí umožňovat vzdálenou správu všech komponent systému z grafického administrátorského prostředí,



musí oprávněnému uživateli nabízet, bez splňuje v plném zásahu do programového řešení, přehlednou rozsahu a jednotnou správu uživatelů, rolí a skupin s možností přidělovat jim práva,


musí umožňovat autentizaci prostřednictvím splňuje v plném Novell eDirectory, rozsahu

standardní podpora LDAP

23 / 42

práce nad DMS, dokumenty a práce uživatelů musí být monitorována a uchovávána,



musí umožnit funkčnost elektronického auditu (kdo, kdy dokument měnil/odsouhlasil),



musí splňovat bezpečnostní Common Criteria pro informační systémy,



musí zajistit a zvládat zabezpečenou komunikaci (SSL) a zabezpečit samotný dokument proti zneužití,



musí podporovat fulltextové české prohledávání ve všech běžně používaných formátech dokumentů, jako je např. Text, HTML, XML, MS Word, RTF, Excel, PDF a další,



musí podporovat tvorbu/skladbu vlastních uživatelských dotazů,



musí dovolit exportovat případně importovat všechny informace o jeho konfiguraci prostřednictvím XML formátu.



24 / 42

D. Příloha č.4 : Těžký klient systému DB2 Content Manager (Windows klient - ukázka)

Obrázek D.1 – Hlavní menu Windows klienta.

Obrázek D.2 – Hlavní menu pro vyhledávání.

25 / 42

Obrázek D.3 – Pracovní list uživatele.

Souhrn standardních funkcí Windows klienta :

zobrazení dokumentů,

pokročilé vyhledávání,

indexování,

anotace dokumentů,

skenování,

tisk, faxování

vestavěné workflow,

verzování,

check-in/out,

export, import,

systémová administrace.

26 / 42

Obrázek D.4 – Tvorba poznámek k dokumentu.

27 / 42

E. Příloha č.5 : eClient klient systému DB2 Content Manager (ukázka)

Obrázek E.1 – Hlavní menu eClient.

Obrázek E.2 – Import dokumentu. 28 / 42

Obrázek E.2 – Hlavní menu pro vyhledávání.

Obrázek E.3 – Pracovní list uživatele. 29 / 42

F. Příloha č.6 : Portálový klient systému DB2 Content Manager (ukázka)

Obrázek F.1 – Hlavní menu klienta portálu.

30 / 42

Obrázek F.2 – Hlavní menu vyhledávání klienta portálu.

31 / 42

Obrázek F.3 – Uživatelský pracovní list klienta portálu.

32 / 42

G. Příloha č.7 : Klient administrátora systému DB2 Content Manager (ukázka)

Obrázek G.1 – Klient pro administrátora systému + nástroj tvorby workflow.

33 / 42

H. Příloha č.8 : Zápis z implementačního bloku č. 1 až 2 Projekt: Implementace IBM WebSphere Portal Serveru Místo jednání: Ostravská Univerzita Zapsal: Marek Grummich Distribuční list: OU: p. Pomezný IBM: p. Beneš, p.Enc, p. Grummich, p. Hůlka, p. Pavlík

Datum: 17-20.10.2006 Pořadové číslo:1

2. Seznam účastníků: p. Holcová, p. Pomezný, p. Řepka, p. Beneš, p. Grummich, p. Hůlka, p. Pavlík 3. Seznam předaných dokumentů, instalačních kitů: Následující instalační kity byly nakopírované, rozbalené a použité při instalaci na server ferda.osu.cz (195.113.106.57) do adresare /root/dbinstall • DB2 UDB V8.2 (Linux) • DB2 UDB V8.2 Fix Pack 11 • WebSphere Application Server V5.1 (Linux) • Fix Pack 1 pro WebSphere Application Server V5.1 • Cumulative Fix Pack 12 pro WebSphere Application Server V5.1.1 • DB2 Content Manager Enterprise Edition V8.3 (Linux) • Fix Pack 3 pro DB2 Content Manager Enterprise Edition V8.3 • DB2 Information Integrator for Content V8.3 (Linux) • DB2 Content Manager eClient V8.3 (Linux) V adresáři /root/dbinstall/win jsou umístěny kity použité pro instalaci na klientské stanice • DB2 UDB Runtime Client V8.2 (Windows) • DB2 UDB Runtime Client V8.2 Fix Pack 11 • DB2 Content Manager Enterprise Edition V8.3 (Windows) • Fix Pack 3 pro DB2 Content Manager Enterprise Edition V8.3 • DB2 Content Manager Client for Windows V8.3 • Fix Pack 2 pro DB2 Content Manager Client for Windows 4. Program: • Zahájení projektu, představení kontaktních osob o p. Ivo Řepka o p. Jarmila Holcová • Instalace DB2 UDB V8.2 na server ferda.osu.cz (operační systém SLES 9 Service Pack 3) • Instalace DB2 UDB V8.2 Fix Pack 11 • Instalace WebSphere Application Server V5.1 na server ferda.osu.cz • Instalace Fix Pack 1 pro WebSphere Application Server V5.1 • Instalace Cumulative Fix Pack 12 pro WebSphere Application Server V5.1.1 • Instalace DB2 Content Manager Enterprise Edition V8.3 • Instalace DB2 Information Integrator for Content V8.3 • Instalace DB2 Content Manager eClient V8.3 • Instalace Fix Pack 3 pro DB2 Content Manager Enterprise Edition V8.3 V rámci instalace výše uvedených produktů byli vytvořeny tito systémový uživatelé icmadmin, ibmcmadm, icmcont, rmadmin, db2inst1, db2fenc1, dasusr1 a k nim odpovidající skupiny ibmcmgrp, db2grp1, db2fgrp1, dasadm1. Všichni uživatelé, i v rámci content manageru, mají nastavené stejné 34 / 42

heslo i......m • •

Instalace DB2 UDB Runtime Client V8.2 na vybraný klientský počítač Windows XP (pí Holcová) Instalace DB2 UDB Runtime Client V8.2 Fix Pack 11

•

Instalace System Administration Client pouze jedné části DB2 Content Manager V8.3 (Windows) • Instalace Fix Pack 3 pro DB2 Content Manager Enterprise Edition V8.3 • Instalace DB2 Content Manager Client for Windows V8.3 (Linux) • Instalace Fix Pack 2 pro DB2 Content Manager Client for Windows • Vytvoření ukázkového typu dokumentu „Objednávka“ se dvěma atributy • Vytvoření dvou uživatelů „User1“ a „User2” s různými právy na použití aplikace • Ukázka funkčnosti aplikace – jak v eClientovi, tak i v klientovi pro Windows o eClient běží na url adrese http://195.113.106.57:9083/eclient/IDMInit o Byla předvedena rozdílnost fuknčnosti aplikace při přihlášení jako „User1“ a následně pak „User2“ • Test importu uživatelů z LDAP systému Novell eDirectory o Funkčnost byla otestována a předvedena v zabezpečeném SSL režimu • Test přihlášení uživatelů naimportovaných ze systému LDAP o Test dopadl neúspěšně a zprovoznění této funkčnosti bude předmětem další návštěvy • Objasnění role Oracle DB v Content Manager systému o DB systém Oracle bude využíván pouze aplikacemi vyvinutými vlastními silami OU a nebude vyžadována žádná spolupráce mezi systémem Content Manager a DB systémem Oracle 5. Příští jednání: Přesný termín bude ještě dojednán, ale předpokládá se v týdnu od 30.10. – 03.11. 2006 6. Přílohy: Nejsou 7. Výsledky jednání: ( Typy položek: I – Informace, D – Dohoda, R – Rozhodnutí, A – Akce, U – upozornění ) Výsledky jednání Č Popis Kdo Do T 1

Nainstalována základní infrastruktura/produkty Content Manageru

IBM

Startovací / Stopovací skripty

IBM

Zprovoznění přihlášení naimportovaných uživatelů

IBM

I A A Analýza možností zálohování a možnosti využití produktu IBM Tivoli Storage D Manager

IBM, OU

ODMA nainstalovat

IBM

Instalace portletů

IBM

A A

35 / 42

Připravení podkladů pro analýzu, návrh a implementaci workflow procesu

OU

A

36 / 42

I. Příloha č.9 : Vlastníci / Kontaktní osoby / Dokumenty v procesu mapování Jméno/Příjemní Mrhačová Eva, Doc. PhDr., CSc. Malach Josef, Doc. PhDr., CSc.

Útvar FF FPD

Funkce děkan děkan

Kontaktní osoba Kozelský Jaroslav Balcarová Libuše Dvořáková Olga Bolková gabriela Poloková Jana

Útvar FF FPD FPD FPD FPD

Funkce tajemník sekretářka děkana referentka tajemnice katedry tajemnice fakulty

Šindler Petr, Doc. RNDr., CSc.

FPR

děkan

Nevludová Iveta

FPR

tajemnice fakulty

Slaný Jaroslav, Doc. MUDr., CSc

FZS

děkan

Štvrtňová Alena

FZS

sekretářka

Bernatík Rudolf, Prof. Novák Vilém, Prof. Ing., DrSc. Svoboda Jiří, Prof. PhDr., DrSc. Stillerová Miroslava, Ing.

IPUS ÚVAFM ÚRS rekorát

ředitel ředitel ředitel vedoucí personalistiky

Klimešová Jana

IPUS

tajemnice - ekonom

Hynková Šárka, Bc.

FPD

personalistka

Zmapované dokumenty Objednávka Zápis z kolegia děkana Zápis ze zasedání vedoucích kateder Cestovní příkaz Žádanka o přepravu Dovolenka Žádanka edičního střediska pro zakázky k platbě převodem z účtu Žádanka pro ediční středisko Převodka Výdejka - Převodka (do skladu) Platební poukaz Plná moc Žádanka na provedení práce Dokumenty pověřeného referenta děkanátu Objednávka Objednávka Evidenční list docházky Zápis z kolegia děkana s vedoucími kateder Práce s doručenou poštou Faktura přijmová Žádanka o přepravu Cestovní příkaz Dokument o akreditaci Smlouva o praxi studentů Převodka Výdejka - Převodka (do skladu) Objednávka do skladu OU Objednávka Dohoda o užívání nebytových prostor Dovolenka Platební poukaz Plná moc Evidenční list docházky

Žádost o peněžitou pomoc při MD

37 / 42

Mrkva Zdeněk, Ing.

Přádka Miroslav, Ing. MUDr., Ph.D.

rektorát

rektorát

kvestor

prorektora pro strategii, organizaci a rozvoj

Kočířová Renata, Mgr.

Tesarčíková Moškoř Zuzana

Vávrová Helena

rektorát právník

Žádost pro přiznání důchodu Prohlášení o pobírání důchodu Osobní dotazník Životopis zaměstnace Zápočtový list Žádost o přijetí do zaměstnání Doklad o klasifikaci Doklad totožnosti Výpověď zaměstnance Výpověď zaměstnanci Popis prac. činnosti neakademika Dovolenka Pohledávka

rektorát referentka

Odeslání dokumentů - pohledávka Schválení dokumentů - pohledávka Směrnice, příkazy rektor/kvestor Živnostenské listy Pozvánky na akce

rektorát sekretářka

Řídící normy Rozhodnutí o akreditaci Rozvojové programy Závěrečná zpráva z rozvojových projektů Smlouvy dotační Vnitřní předpisy Výroční zpráva Cestovní příkaz Práce s doručenou poštou Práce s odeslanou poštou Evidenční list docházky Zápis z rady CIT Řídící normy, vyhlášky, směrnice, příkazy, sdělení rektora Závěrečná zpráva z Grantové agentury ČR Zahraniční smlouvy vypracované na půdě zahraničního partnera Zahraniční smlouvy vypracované na půdě OU Zahraniční smlouvy doručené poštou na OU

38 / 42

Kapounová Jana, Doc. RNDr., CSc.

rektorát

prorektora pro vědu, uměleckou činnost a zahraniční vztahy

Zmrzlíková Michaela


Zápis z knihovní rady

Zápis z vědecké rady Roční výkaz o vydavateli Ohlašovací lístek ISBN Všeobecné grantové projekty Smlouva o řešení grantového projektu Smlouva o řešení části grantového projektu v rámci Smlouvy o poskytnutí dotace na podporu grantového projektu, grantová agentura ČR (GAČR). Smlouva o poskytnutí dotace na podporu grantového projektu

Baar Vladimír, Doc. RNDr., CSc.

rektorát

rektor

Porubová Jiřina


Lenert Jan, Ing.

rektorát

vedoucí ekonomického útvaru

Beierová Eva

rektorát referentka-sklad

Hubová Iva

rektorát referentka - prodejna skript

Smlouva s edicí Universum na publikace Závěrečná zpráva z grantových projektů Evidence došlé pošty Smlouvy všeobecné Vyúčtování provozní zálohy Žádanka o přepravu Zápis z kolegia rektora Záznam o kontrole Dodací list

Celoroční objednávka Příloha k celoroční objednávce Jednorázová obejdnávka Měsíční uzávěrka Roční inventura Žádanka výdejka Doklad o nabytí Faktura přijmová Faktura výdajová Paragon Příjemnka Výdejka Smlouva o zřízení konsignačního skladu - přijetí komise Smlouva o zřízení konsignačního skladu - vydání do komise Žádost o bezplatné výtisky

39 / 42

J. Příloha č.10 : Workflow dokumentu Objednávka v UML 2

40 / 42

K. Příloha č.11 : Workflow dokumentu Objednávka v BPMN Univerzita Objednávateľ

DMS

Držiteľ grantu

Magion

Rektorát Vystavovateľ objednávky

Schvaľovateľ objednávky

Spracovanie žiadosti na vystavenie objednávky

Žiadosť o vystavenie objednávky

Vystavenie objednávky v IS Magion

Spracovanie v DMS

Yes

No

Schválenie objednávky

Prepracovať

Hradené z grantu ?

Schválenie objednávky

Schválené

Schválené Zamietnuté

Prepracovať

Autorizácia Zamietnuté

No

Schválené ? Yes

nastavenie konečného stavu objednávky

Tlač 3x + distribúcia fyzickej objednávky

stornovanie objednávky

41 / 42

L. Příloha č.12 : Workflow dokumentu Objednávka v DMS

42 / 42

Ostravská univerzita v Ostravě

Recommend Documents