Vše nejlepší do roku 2010

Přeji Vám mnoho úspěchů v osobním i pracovním životě nejen do celého roku 2010.

... architektura v úložišti

Pokud bychom otočili zájem o architekturu naopak na vlastní úložiště nestrukturovaného obsahu (dále "ECM úložiště"), dostaneme se na relativně pevnější půdu Solution Architecture.

Základní přiblížení architektury se dá udělat dnes snad nejopakovanějším slidem v celém Oracle:

1. Pokud bychom začali úplně zespoda, nalezneme tam hardware, na kterém se ukládají nestrukturovaná data (v jazyce výrobců hardware znamená termín úložiště zpravidla právě a jenom toto). Podle objemu dat a dalších požadavků se může jednat o disk, pásku, diskové pole, či nejrůznější hybridní zařízení (např. na našem letošním hitu, Exadatě 2, která slouží jako úložiště - storage pro datové sklady a OLTP databáze se využívají z důvodu rychlosti kromě disků i flash paměti). Budiž však řečeno, že tato zařízení již dávno nejsou jen tupými boxy na odkládání informací (souborů) a že často obsahují velmi příjemné (bohužel však často též poměrně nákladné) doplňující funkce - např. pro podporu na tomto blogu diskutovaného konceptu garantovaného úložiště může úložiště - storage nabídnout redundantní uložení stejného souboru, které z pohledu vyšších vrstev (vč. uživatelů) transparentní, čímž výrazně sníží šanci ztráty obsahu z důvodu technického poškození úložného média.
Tato vrstva je pro jakýkoliv projekt úložiště nestrukturovaného obsahu nezbytná.
2. Na další vrstvě nalezneme to, čím je Oracle stále nejznámější - databázi. V našem ECM úložišti (Oracle UCM) může mít databáze dvojí roli - buď se využívá jen na ukládání metadat (tj. dat o souborech v úložišti - v tomto případě je možné využít i databáze od jiných dodavatelů, i jako důkaz toho, že řešení je skutečně otevřené), nebo slouží na ukládání metadat i vlastního obsahu.
Zejména v prostředí, kde již databázi Oracle znají, doporučujeme jako metodu první volby druhou možnost. Databáze totiž "v ceně" dodá do řešení spoustu funkcionalit (jen namátkou: fulltextové vyhledávání či stemming, a to v mnoha jazycích vč. češtiny, hierarchical storage management, unifikované zálohování a v neposlední řadě díky RAC i škálování výkonu). Za jistou nevýhodu by se mohlo považovat, že databáze zpravidla nedokáže plně využít, pravda často proprietární, "inteligence" hardwarových storage zařízení (někdy se funkcionalita zdvojuje, jako např. u HSM, jindy se ne plně využívá, jako např. u zmiňovaného redundantního ukládání). Přesto je možnost ukládat nestrukturované informace jistě velmi zajímavým doplňkem pro řadu řešení.
3. Na třetí úrovni, middleware, patří vlastní ECM úložiště, proto ji na okamžik vynechme.
4. Poslední vrstva nás pak přenese do širokého světa ostatních systémů a aplikací čerpající služby ECM úložiště. Tím bychom se vrátili k obsahu minulého týdne.

Pokud bychom se nyní zaměřili na detaily vlastního úložiště, můžeme pokračovat v naší logice definování jednotlivých vrstev a jejich role v rámci řešení.
a) na nejnižší vstvě najdeme využití služeb storage a databáze - pokud potřebuji najít či vložit dokument s identifikátorem XYZ, musím vědět, kde ho najdu a jak k němu přistupovat
b) na druhé nejnižší vrstvě najdeme pak poskytování základních dokumentačních služeb, jako je práce s metadaty, definování přístupů, podpora workflows atd., tedy úlohy, které se vyskytují prakticky v každém projektu
Kdysi, ještě za časů, kdy produkt vlastnila firma Stellent, se této vrstvě říkalo Content Server a její nasazení bylo nezbytnou podmínkou každého stellent projektu pro správu obsahu. Je třeba poznamenat, že ve své době se tímto Stellent lišil od řady svých konkurentů (jejichž portfolio často vznikalo akvizicemi velmi technologicky odlišných produktů, takže implementace ECM projektu pak představovala integrační projekt se všemi důsledky tohoto faktu - dnes už byla většina řešení redesignována a nová řešení již vznikají podle tohoto konceptu).
Tato vrstva může sloužit jako stand-alone řešení (např. pro oblast DMS) nebo poskytovat svoje služby dalším vrstvám nad ní.
c) řada těchto vyšších vrstev je standardně dodávána (kdysi ve stellentu byly licencovány odděleně) v rámci produktu Oracle UCM. Jedná se o komponenty pro disciplíny jako je Web Content Management, práci s multimediální obsahem, či podporu splnění nejrůznějších legislativních požadavků na uchovávání obsahu (spisová služba, records management). Zajímavostí z pohledu architektury je, že jsou postaveny tak, že čerpají služby základní komponenty a samy pak nabízejí další služby navenek. Stellent byl servisně orientován v době, kdy SOA ještě ani neexistovala.
Další příjemnou vlastností tohoto způsobu je, že jej je možné:

• snadno rozšiřovat - na každou vrstvu je možné doplňovat další a další služby (ať už Oracle nebo komunity dodávají řadu již hotových komponent)
  
• snadno měnit - pokud nějaká služba nedělá, co by bylo třeba, je možné ji upravit či úplně vyměnit

Celkový obrázek architektury úložiště ECM tak může vypadat např. takto:


Vzhledem k tomu, že toto je poslední článek před Vánocemi, přeji Vám šťastné a příjemné prožití svátků.

Úložiště v architektuře...

V tomto týdnu jsme byli spolu s dalšími kolegy z oddělení presales posláni na školení o významu architektury. Na zpáteční cestě jsem se proto rozhodl, že dnešní téma věnuji otázkám spojující architekturu (spíše ve významu Enterprise Architecture) a problematiku ECM.

Ponechme stranou otázku samotného termínu architektura (na toto téma např. článek) - připustme, že je možné dosáhnout jakéhosi ucházejícího přenesení logiky obchodních procesů do IT infrastruktury. Jaké místo v tomto modelu tedy bude zaujímat ECM úložiště? Předně, nejprve bude nezbytné udělat ještě o jeden krok zpět (ve smyslu modelu "vodopádu") a zapátrat, proč by organizace měla vůbec něco takového chtít (tj. pokusit se definovat požadavky).

ECM primárně řeší správu nestrukturovaného obsahu (textových dokumentů, emailů, multimédiálních souborů, skenů atd.) a jakkoli jsme si nijak nespecifikovali o jaké organizaci se bavíme (ať už velikostně či oborově), troufnu si tvrdit, že správu, tj. zavedení jakýchsi základních pravidel, jak s tímto obsahem pracovat, bude muset dříve nebo později zavést každý - když už kvůli ničemu jinému, tak proto, že tento obsah má tendence skutečně nekontrolovaně (exponenciálně?) růst a velmi často obsahuje v záplavě balastu informace, (dokumenty, soubory) které potřebujeme a nebo o které si naopak nemůžeme dovolit přijít.

Požadavkem, který už do jisté míry souvisí s architekturou, je, aby úložiště bylo pokud možno jen jedno - tento požadavek v podstatě diktuje selský rozum (pokud něco budu hledat, vím, kde to najdu - nebo naopak, že to najít nemohu). V ideálním stavu by tomu tak být mělo, ale v realitě je často úložišť hned několik (se všemi problémy, které jsou s tím pak spojeny - dlouhé vyhledávání, různé triky, pravidla a administrátoři pro různé aplikace atd.) - stačí se jen podívat, jak často jsou v ECM úložišti ukládány a spravovány emaily.

Vzhledem ke zbytku světa (rozuměj dalším systémům v rámci Enteprise architektury) je pak ECM úložiště ne nepodobné databázi (osobně proto někdy užívám termín: "databáze dokumentů") - musí umět přijmout, vyhledat, modifikovat a někdy i smazat spravovaný obsah. A pak samozřejmě provádět uvnitř sebe sama některé další operace, které výše uvedené podporují (příkladem může být např. konverze do formátů, které dokáží zobrazit obsah bez nutnosti instalovat na klientskou pracovní stanici speciální software). Kromě procesů, kdy se (na rozdíl od databáze) počítá, že koncoví uživatelé pracují přímo s úložištěm (přes nějaké grafické rozhraní) je to však v zásadě všechno...

Možná Vás napadne, že vše z výše uvedeného se dá splnit i pomocí poměrně výrazně jednodušších (a levnějších) prostředků (jako jsou souborový systém či zmiňovaná databáze). To je pravda. Zatímco se dá bez újmy na obecnosti tvrdit, že úložiště nestrukturovaného obsahu má místo v každé organizace, není možné říct, že by tím úložištěm nutně musel být produkt s nálepkou ECM. Z čehož vyplývá, že kritéria výběru vhodného typu úložiště jsou dána spíše potřebami jednotlivých systémů (procesů či dokonce uživatelů) čerpajících služby úložiště. Tedy spíše úrovní označovanou jako Solution Architecture. "Letecký snímek" organizace může spíše přispět tím, aby se na nějaké řešení při vyhodnocování potřeb nezapomnělo a nebo naopak při dopadové analýze zavádění nového systému.

Nový produkt: Oracle Forms Recognition

Tak trošku ve volném pokračování článku z minulého týdne budeme pokračovat v představování novinek. Od prosince se v ceníku objevil nový produkt Oracle Forms Recognition (je dokonce tak nový, že jej zatím nenajdete ani na stránkách www.oracle.com a opravdu nemá nic společného s technologií Oracle Forms&Reports).

Přesto si myslím, že se jedná o produkt, který může být pro určitou skupinu zákazníků velmi zajímavý - jedná se o podporu automatického zpracování tzv. semistrukturovaných dokumentů (faktur, objednávek apod.), u kterých sice víte, že obsahují nebo mohou obsahovat určitá data (číslo faktury, dodavatele, seznam položek, cenu za kus, celkovou cenu apod.), ale nevíte, kde přesně se tento údaj nalézá, tudíž použití technologií jako je zónové OCR rozpoznávání je přinejmenším problematické. Nasazení produktu je tedy poměrně jasné - na digitalizačních pracovištích došlých dokumentů (primárně faktur, ale nejen), zejména tam, kde tyto pochází z mnoha zdrojů a tudíž se dá očekávat značná variabilita.

Zpracování probíhá třífázově:

• Klasifikace: kdy se na základě "kontextu" (kterým může být jakýkoliv rozpoznávací znak - text, obrázek, či čárový kód na stránce) určí typ dokumentu (např. faktura od dodavatele XYZ). V rámci klasifikace však ale může dojít i k "rozlámání" souvislého toku stránek ze scanneru na jednotlivé dokumenty
• Extrakce: kdy opět na základě "kontextu" dojde k rozpoznání jednotlivých elementů (hlavička faktury, jednotlivé položky atp.)
• Validace a párování: kdy dochází k ověření takto získaných dat. Tím, že se při rozpoznávání dá velmi často využít již známých dat (např. číselníku dodavatelů z ERP, či seznamu položek z objednávky, pokud se nám podaří správně získat její číslo), je možné řadu kroků opravdu výrazně zefektivnit. Nástroj navíc obsahuje i fuzzy search, tj. párování na neúplnou shodu

Samozřejmě, jistě Vás napadne, že ani takto vybavený nástroj není všemocný - co když např. přijde formát, který jste dosud nikdy neviděli? I na toto je pamatováno ošetřením tzv. výjimek, které se samozřejmě předkládají k manuálnímu zpracování. Nástroj však podporuje i samoučící mechanismy, takže z často se objevujících výjimek se brzy může stát nové pravidlo. Kromě OCR je pak ještě podporováno rozpoznávání ICR. Obě jsou podporovány i v češtině.

Pokud byste hledali další reference na internetu, hledejte Brainware Distiller.

Produktové novinky

• čeština

1. Information Rights Management (Desktop Client) - poslední release produktu IRM (klientské části), konkrétně 10R3, PR5, je konečně k dispozici i v češtině! Jedná se o dlouho očekávanou (a slibovanou) vlastnost. "Sealování" je přeloženo jako "pečetění", což myslím, je poměrně zdařilý ekvivalent (i když osobně budu mít chvíli problémy si na něj zvyknout). Po stažení nové verze se Vám tedy může objevit např. toto (jedná se o Powerpoint 2007):
2. Universal Content Management - v listopadu se na OTN objevila také první Oraclem podporovaná verze lokalizace UCM do češtiny (předchozí verze byly tvořeny spolu s lokálními partnery). Prozatím se jedná o řetězce objevující se koncovým uživatelům (nikoliv tedy např. administrátorské applety - na ty si budeme muset počkat až do jarní verze). Výhodou oficiální verze je zejména kontinuita při aktualizacích verze a podpora překladu u všech standardně dodávaných komponent.
   

• Windows 7

1. kromě češtiny je také výše uvedená verze IRM podporována na operačním systému Windows 7. Z portfolia UCM, které běží vesměs buď jako serverová komponenta nebo je zobrazováno v internetovém prohlížeči, se Windows 7 týkají vlastně jen jediné komponenty, a to Desktop Integration Suite (integrace s klientskými aplikacemi balíku Office). I zde je poslední verze podporována i na Windows 7.
   

Akce konané minulý týden

Minulý týden proběhly dvě akce, ke kterým určitě stojí za to se vrátit.

Chronologicky první, a našemu blogu tématicky možná přeci jen bližší, byla tisková konference Dva týdny ostrého provozu Informačního systému datových schránek pod patronací nového náměstka ministra vnitra pro informatiku ing. Jaroslava Chýlka, MBA. Kompletní tisková zpráva je k dispozici na tomto linku (doporučuji si pročíst zejména prezentaci plnou faktů a čísel). Osobně jsem rád, že přinejmenším z těchto mezivýsledků se zdá, že systém se pomalu dostává do rutinního provozu a po nezbytném vychytání dětských nemocí (teď se asi nejčastěji skloňují phishing, nutnost změny hesla a zabezpečení obecně) už se snad konečně kolem datových schránek vášně trochu uklidní. Ze strany dodavatelů (nejen nás, ale i našich partnerů) mohu pozorovat, že po poněkud nešťastném prohlášení ministra vnitra, ze kterého vyplývala byť pečlivě oklasifikovaná "teoretická" možnost pozastavení povinnosti vybírat datové schránky pro firmy (např. zde), mnoho firem pozastavilo hledání řešení, čímž nám zřejmě způsobí ještě hektičtější konec roku. Asi není překvapující, že zatímco zprávu ze začátku měsíce najdete ve většině (nejen) internetových deníků, o konferenci minulý týden se zprávy hledají značně obtížněji. V Čechách se holt dobré zprávy nenosí. Držme si tedy palce, aby audit datových schránek, který má skončit koncem listopadu dopadl alespoň stejně dobře.

Druhá akce byl námi pořádaný Oracle Day, což byla největší marketingová akce české pobočky Oracle za posledních několik let. O významu akce svědčí i účast prezidenta Oracle Corporation, p. Charlese Phillipse, který přednesl úvodní řeč na téma vize Oracle poskytovat Kompletní, Integrované a Otevřené služby svým zákazníkům, a to na Aplikační, Middlewarové, Databázové a nově (u nás po odstranění administrativních překážek ze strany EU) i Infrastrukturní úrovni. Zástupcem tohoto konceptu budiž např. server Exadata 2, o kterém se dozvíte např. na blogu kolegů z BI (např. zde).

Naše oblast měla zastoupení v rámci bloku Public sektor, což je vzhledem k vývoji za poslední 2 roky logické. Průnik obou akcí pak nastal zejména v přednáškách p. Valenty z partnerské firmy CCA Group, který prezentoval podobná data z resortu spravedlnosti (jen pro zajímavost: resort spravedlnosti, tj. asi 2,5% z celkového počtu, zpracovává přibližně 40% všech datových zpráv; z pohledu p. Valenty je jedním z nejpalčivějších problémů neexistence "telefonního" seznamu, ve kterém by se dalo hledat, zda zejména fyzická osoba vlastní aktivní datovou schránku - přestože šance je relativně malá, kontrola se vždy musí provést, a to i v případě, že s občanem již bylo komunikováno, protože se stav mohl mezitím změnit), a p. Ondřeje Felixe, který přednesl velmi zatímavou přednášku o stavu a budoucnosti eGovernmentu. I já bych se podepsal pod ideu, nechť kolují dokumenty, nikoliv občan - moje nedávná zkušenost, kdy jsme byli pro moji manželku (cizinku s trvalým pobytem) vyzvednout potvrzení o trvalém pobytu na území ČR pro účely poskytnutí Rodičovského příspěvku:
- včera nás poslali z Cizinecké policie v Koněvově ulici, kde se agenda dělala do 1.1.2009 na novou adresu "na Bohdalec - přesná adresa visí támhle někde na nástěnce" - můžete hádat jen jednou - nikde nebyla),
- dnes jsme zjistili, že potřebujeme vědět přesný název úřadu, pro který se potvrzení vystavuje, protože "pro jiné účely je potvrzení neplatné",
- nakonec jsme dostali papír, ze kterého vyplývá, že asi tak půl roku měla manželka trvalé bydliště na dvou místech zároveň (po přihlášení na jedno místo evidentně nedošlo automaticky k odhlášení z prvního) - oprava bude trvat 2 nebo 3 týdny,
a to na osmém měsíci těhotenství (takže tam půjdeme nejspíš ještě jednou, až se malá narodí)...

Garantované vs. Negarantované úložiště (Dlouhodobé ukládání dokumentů)

Poslední dobou, naposledy ve výzvě 06 TC pro Obce s Rozšířenou Pravomocí, o jejímž vypsání jsme psali ve článku minulý týden, se začínají objevovat nejrůznější termíny související s dlouhodobým ukládáním dokumentů, zejména pak termíny garantované resp. negarantované úložiště. Přiznám se, že mi tyto termíny trochu připomínají yettiho - všichni o nich mluví, ale nikdo je dosud neviděl (tím myslím: zákonnou či podzákonnou normu, která by specifikovala, o co se vlastně jedná či v čem je mezi nimi rozdíl).

Bohužel, tento stav nejasnosti se týká nejen těchto termínů, ale celkového stavu "dlouhodobé archivace" (viz např. předposlední odstavec článku J. Peterky "Pandořiny datové schránky..." - k tomu osobní komentář: viděli jsme se jen jednou, ale kdyby se p. Peterka zeptal mně, potažmo Oracle, dostal by odpověď, že my archivujeme podle zákona 499/2004 Sb., tj. jeho novelizované verze, protože nic jiného česká legislativa zatím nezná).

Pokusím se tedy tento stav alespoň trochu objasnit. Předem však upozorňuji, že se jedná o stav k dnešnímu dni, který už zítra může být jiný (chystá se obdobná výzva pro Technologická centra krajů, která by prý měla vyjít do konce listopadu).

Z hlediska ukládání digitálních dokumentů je klíčovou normou novela zákona 499/2004 Sb., konkrétně pak paragraf 69a (Zvláštní ustanovení o dokumentech v digitální podobě). Z pohledu dnešního článku mi přijdou nejdůležitější odstavce č. 3 a č.8 (na toto téma bychom už se opakovali - viz článek z 15.7.2009). Všimněte si formulace "po dobu skartační lhůty dokumentu", která nijak neomezuje, o jak dlouhý interval by se mělo jednat - a to určitě existují dokumenty, u nichž je tato doba na desítky let nebo "navždy".

Jediný časový údaj týkající se dlouhodobého ukládání najdeme jen v definici termínu správní archív, který je definován jako "součást původce určená k dohledu na spisovou službu původce a k uložení, vyhledávání a předkládání dokumentů se skartační lhůtou delší než 5 let," - ergo jakési dělení zřejmě existuje pro dokumenty se skartační lhůtou do 5 let a delší.

Pokud se jedná o termíny garantované či negarantované úložiště (že by zde byla užita ona hranice pěti let?), ty v zákoně nenajdeme. Dokonce tam nenajdeme ani termín úložiště, který se však využívá aspoň v podzákonných normách, konkrétně ve vyhlášce o výkonu spisové služby (191/2009 Sb.), o stanovení podrobností provádění autorizované konverze dokumentů (193/2009 Sb.) a pak samotném Národním standardu pro spisové služby. Ve všech těchto dokumentech se však využívá, jako by bylo jasné, o co se jedná (!!!), přičemž si nemohu odpustit dojem, že se jedná o užívání ne zcela konzistentní (někdy ve smyslu aplikace - např. "sdílení částí úložiště ERMS", jindy ve smyslu čehosi, co má blíže zařízení - např. "stanovením místa ukládání (ukládání na externí média, do jiného systému nebo do vzdáleného úložiště)." Ať už se však jedná o jakékoliv užití, vždy je respektováno dodržení základních principů, tj. věrohodnost, neporušitelnost a čitelnost.

Jediné definice těchto pojmů tak nalezneme jen v konceptu výzvy TC pro ORP (kraje), kde

• úložiště (kap. 5.1.2.2 Popis úložiště): "Ukládání dat řešit prostřednictvím NAS (Networked Attached Storage) popř. SAN (Storage Area Network),...", tj. specifikováno jako hardwarové zařízení (kam zmizela podpora základních principů?)
• negarantované úložiště (implicitně definováno v kap. 3.3.2., resp. 5.1.1.1, např. jako) "Negarantované úložiště, umístěné na TC ORP, je určeno pro ukládání nevyřízených a neuzavřených a spisů pořízených nebo přijatých jak samotnou ORP , tak spádově všemi obcemi ve správním obvodu ORP. "
• garantované úložiště se do čistopisu dostalo už opět jen jako užívaný termín. V konceptu dokumentu (na stránkách MV ČR) pak ale najdeme i definici: "Garantované úložiště je určené zejména pro ukládání dokumentů uzavřených spisů v elektronické podobě do elektronické spisovny. Ta je základem konstrukce TC Kraje. Garantované úložiště musí splnit základní požadavky:
  
  • dlouhodobé uložení spisů dle požadavků aktuální legislativy, včetně požadavků na skartaci;
  
  • aplikace mechanismů prokazatelnost neměnnosti a pravosti původu obsahu spisů;
  
  • garantovaný výhradní přístup oprávněným uživatelům"

Pokud je z toho někdo moudrý a dokáže určit, v čem se mají garantované úložiště od negarantované lišit a hlavně, kde je to napsané (možná existuje ještě nějaká další norma - proč však na ní nikde není alespoň odkaz?), pak já tedy přiznávám, že nevím.

Mohu-li však usuzovat podle toho, "co jsem slyšel" (např. na konferenci CNZ, v přednášce p. Šírla "Elektronické dokumenty a eGovernment ", kde se mj. používaly termíny pasivní a aktivní úložiště), pak rozdíl je v implementaci standardu OAIS (který dosud není v legislativě nikde zakotven) a v tom, že aktivní (garantované) úložiště nabízí i funkce zachování či obnovování základních aspektů dlouhodobé archivace v čase - např. pro neporušitelnost (kde OAIS, která je z roku 2002 a mj. doporučuje CheckSums a předpokládá, že se "tyto mechanismy budou v čase dále vyvíjet").

Poznámka na závěr: technologicky přesný termín v angličtině je důvěryhodné úložiště (viz např. zde). Označovat ovšem úložiště (která budou splňovat např. požadavky zákona 499/2004 Sb., ale jen na kratší skartační lhůty, což jsou mimochodem všechny spisové služby a ERMS systémy velkých dodavatelů) termínem nedůvěryhodné by bylo přeci jen trochu nefér. Uvidíme, jakým způsobem se OAIS, či jiný podobný standard, nakonec do legislativy dostane.

Výzva k předkládání žádostí o finanční podporu v rámci Integrovaného operačního programu

Koncem listopadu vyšla dlouho očekávaná výzva na vybudování tzv. technologických center pro obce s rozšířenou pravomocí. Kompletní dokumentace je k dispozici na tomto linku (resp. na odkazech zde k nalezení).

S ohledem na spuštění datových schránek vytváří tato výzva finanční prostor pro implementaci (nejen) problematiky spojené se správou elektronických dokumentů. Bohužel, prozatím jen pro ORP - obdobná výzva pro kraje (očekávaný obsah této výzvy lze najít v konceptuálním dokumentu, kdy je uvedeno, které částí se týkají jen krajů a které jak krajů, tak ORP).

Předmětem výzvy jsou 3 části:

• zřízení technologického centra ORP, vč. zajištění povinných služeb - kromě nákupu hardware a software licencí se zde jedná především o vytvoření úložiště dat pro nevyřízené a neuzavřené spisy, ale i o služby jako je DNS, poštovní server, antivir, pokud je z nějakého důvodu (nejčastěji nedostatečná kapacita připojení) nebude možné využívat z kraje; v neposlední řadě se pak jedná o služby související s podporou základních registrů (RÚIAN, ROB a RPP)
• spisová služba - zřízení či úprava spisové služby vzhledem k nedávné novele zákona 499/2004 Sb. (na toto téma více např. v seriálu o Národním standardu eSSL)
• vnitřní integrace úřadu - což znamená především přebudování infrastruktury dle principů SOA (využití vrstvy middleware)

V konceptuálním dokumentu pak najdeme pro ORP odkaz ještě nejméně na jednu další agendu, "portál úředníka", na který sice ve výzvě není alokován žádný rozpočet, se kterým je však třeba počítat v celkové strategii projektu.

Oracle, podobně jako u datových schránek, připraví spolu se svými partnery kompletní nabídku, která kromě vlastních produktů bude obsahovat i metodiku, jak správně připravit záměr projektu či studii proveditelnosti, protože si uvědomujeme, že tento typ projektu již dávno není jen o "technologiích". V případě, že byste se o nabídce chtěli dozvědět více, kontaktujte emailem autora článku.

Group Spaces - od stránky k "pracovnímu prostoru"

V minulém článku jsme si představili, jak je ve Web Centru možné vytvářet a modifikovat jednotlivé stránky. Představme si nyní, že máme hotovy všechny stránky a chtěli bychom je dát k dispozici k užívání.


Nejprve bude nutné si uvědomit, kdo by měl (popř. mohl chtít) mít k obsahu přístup a jaký.

Web Center pracuje s konceptem role, což je seznam oprávnění k nejrůznějším akcím. Základních rolí, které se vytvářejí s každým novým pracovním prostorem a ze kterých je potom možné vycházet při definici dalších rolí, je celkem 5.

• Moderátor - typicky tvůrce "prostoru", vedoucí projektu apod.
• Účastník - člen týmu s oprávněním měnit/přidávat (typicky: obsah, ne oprávnění)
• Čtenář - smí jen nahlížet

Další 2 role, Spaces-User a Public-user se užívají pro dosud neznámé (autentikované či neautentikované uživatele).

Z těchto ingrediencí je pak třeba namíchat vhodný koncept - z hlediska dostupnosti i bezpečnosti. Moderátor může přidat, či jen přizvat konkrétní účastníky. Stejně tak ale může jen zveřejnit prostor a nechat na uživatelích, ať se k jeho sledování přihlašují sami (self-registration), či naopak udržovat nad přihlášenými kontrolu schvalováním jejich požadavků o přístup.

Tímto se samozřejmě stanoví pravidla pro celý prostor. U každé stránky (záložky) je pak možné dále doladit pravidla - prostor tedy může obsahovat stránky pro "public users", ale ve skutečnosti se zobrazí jen některé.

Velmi vítaným pomocníkem při vytváření pracovních prostorů jsou pak i šablony, které umožňují uložit základní rozložení a nastavení pravidel přístupu. Nástroj je dodáván se třemi defaultními šablonami (prázdná, pro projekty a pro komunity), které ukazují, jak na to.

Personalizace s WebCenter (WebCenter Composer)

Jelikož se produkt WebCenter od verze 11g pomalu stává jednou z vlajkových lodí portfolia Oracle v oblasti správy dokumentů (či E2.0), asi by stálo za to si jej po malých dávkách představit. V dnešním článku se zaměříme na naprosté základy.

Poslední dobou se od zákazníků začínají (možná i v souvislosti s Web2.0) požadavky na personalizaci. Předně, co se pod tímto pojmem skrývá? Dle Wikipedie to zahrnuje "using technology to accommodate the differences between individuals", tj. možnost upravit si, zpravidla vzhled, dle vlastních preferencí, ale často také při respektování určitých základních pravidel.

Ve světě tenkých klientů může být tím, co se upravuje, stránka (či dashboard, pracovní plocha apod.). Pokud se na nějakou takovou stránku podíváme:

to, co můžeme na stránce měnit jsou především

• forma (rozvržení, fonty, styly či barevná schémata)
• obsah (co je na stránce obsaženo)

V obou případech asi není úplně žádoucí, aby uživatelé měli plnou libovůli v tom, jak bude výsledek vypadat (často ani nemají dostatečné technické znalosti), proto "možnost měnit" ve skutečnosti znamená "možnost vybírat si mezi tím, co pro mě někdo připravil".

U WebCenter, podobně jako u dřívějšího produktu Aqualogic User Interaction (Plumtree), je velmi pohodlné zejména to, jak se připravují tzv. zdroje (portlety, seznamy dokumentů, task flows atp.), z jejichž palety si mohou uživatelé vybírat. Zde se plně uplatní technologie Web2.0 - tj. kromě řady zdrojů, které se nabízejí už v samotném WebCentru, je poměrně snadné vytvořit takovýto zdroj "obalením" existující aplikace, a to dokonce bez ohledu na to, zda se jedná o interní aplikaci, či aplikaci provozovanou někde na internetu. Třešničkou pak může být smíchání takovýchto ingrediencí ve formě mash-upu.

Z pohledu uživatele se však jedná jen o prostý výběr ze seznamu (katalogu), který může vypadat např. takto:
Na pár kliknutí je pak možné změnit (pokud k tomu mám jako uživatel oprávnění) stránku např. do této podoby:

Magický kvadrant pro ECM 2009

Dnešní článek bude výrazně kratší než obvykle. V minulém týdnu vyšel oblíbený magický kvadrant pro ECM na rok 2009. Abych se vyhnul případným problémům s autorskými právy a citacemi, raději jen uvedu link na celou zprávu - detaily si jistě každý najdete sám.

V krátkosti:

• Oracle je mezi leadery
• Oracle (spolu s Microsoftem) prodělal největší posun "doprava a nahoru" - poprvé v historii se tak dostal v obou parametrech před produkty EMC a OpenText
• vzhledem k vývoji nejspíš došlok posunu díky produktu WebCenter, který je však stále vnímán s jistou obezřetností
• k poslednímu bodu ještě jednu poznámku (kterou v reportu nenajdete) - v dohledné době očekáváme nový release UCM 11g a první, významný patch WebCenter, který by měl vizi tohoto produktu posunout ještě významným způsobem kupředu
  

Reshaping Your Business with Web 2.0

V dnešním článku si trochu odpočineme od archivací, legislativy apod. a podíváme se na téma, které by svojí podstatou mělo být mnohem blíže uživatelům - Web 2.0, a to konkrétně jako k reakci na knihu Reshaping Your Business with Web 2.0.

Předně, pokud čekáte nějaký zázračný návod, jak pomocí technologií Web 2.0 převratně změnit Vaši organizaci, nic takového samozřejmě v knize nenajdete. Osobně se mi spíše líbila až střízlivě realistická tvrzení typu: "Web 2.0 je realita, je tady a jistě je lepší, když ji dáte svým uživatelům k dispozici a budete jej mít pod kontrolou, než jej zakazovat" nebo návod použít místo emailové automatické odpovědi odkaz na stránku (wiki), kde Vám někdo, pokud o to opravdu stojí, může nechat svoji otázku k zodpovězení - třeba nebude sám, koho to zajímá a pokud často jezdíte na služební cesty, možná se na to samé bude chtít zeptat i někdo jiný.

Nicméně, vraťme se na samý začátek. Je o tom samozřejmě možné diskutovat, ale osobně docela věřím tezi, že za vznikem Web 2.0 byl přerod, kdy z internetu přestalo být médium jen na čtení, ale začalo být možné začít i psát ("we are all publishers"). A brzy se objevily (na svoji dobu možná překvapující) výsledky:

• přestože je za to nikdo neplatí, lidé chtějí přispívat
• informační hodnota (správnost) je na (některých; např Wikipedia) veřejně modifikovatelných zdrojích stejná jako v expertních publikacích (Encyclopaedia Britannica) - viz též "wisdom of the crowds"; v některých organizacích napomohlo k rozbití klasických hierarchických řídících struktur, protože, ano, Vaši podřízení opravdu (samozřejmě jen v některých oblastech :-) ) mohou vědět více než Vy
  
• tím, že se často obsluhuje relativně neodborná skupina uživatelů, začíná být důležitější, zda je informace snadno dostupná a "sexy", spíše než cokoliv jiného - toto se odrazilo ve změně vyhledávacího algoritmu jedné z nejúspěšnějších aplikací této doby, Google, který měří relevantnost stránky jako odpověď na vyhledávací výraz podle počtu stránek, které se na ni odkazují
• jiný způsob, jak získat relevantní informaci, může být, když Vám ji pošle někdo, komu věříte - Váš známý; proto je tedy vhodné (a výhodné) dát uživatelům nástroj, který umožní sledovat "kdo s kým" (social graph)

Na odvrácené straně však stojí i další pozorování:

• neustálé sledování dění ve Vaší sociální síti, či reakce na instant messaging (ICQ, Skype) mohou být skutečně nepředstavitelní žrouti času (viz např. článek "Bill Gates je příliš populární, než aby mohl užívat Facebook")
• výše uvedená paradigma mohou vést k jistému voyeurství, kdy je důležité "zaujmout" či "ohromit davy", a to často bez ohledu na následky (viz. např. kolující fotky z party či jěště více diskreditující fakta, která jsou na internet často publikována samými postiženými)

Tato fakta však nejsou proti užívání Web 2.0, spíše na úrovni podniku o to více podporují tvrzení, že by tyto technologie měly být pod jakousi kontrolou (a to pod takovou, aby se s vaničkou nevylilo i dítě, tj. díky kontrole nedošlo k potlačení pozitivních přínosů).

Na tato témata najdete v knize mnoho příkladů. Kniha rovněž obsahuje poměrně podrobný přehled nejrůznějších technologií. V posledním článku se pak můžeme dočíst i co může být po Web2.0 ("Semantic Web"). Nejen z tohoto důvodu stojí za to knihu přečíst - vzhledem k rychlosti rozvoje tohoto odvětví však doporučuji Vaše rozhodnutí dlouho neodkládat.

Národní standard pro eSSL - 7.část: Operace (vyžadující spolupráci s okolím)

Na poslední část jsem si ponechal operace, které podle mne do ERMS nepatří, nebo jen značně okrajově. Pokud by se však měly brát proklamace z Národního standardu, stal by se z ERMS patrně zdaleka nejrozsáhlejší informační systém v jakékoliv organizaci. Posuďte sami:

• správa oprávnění pro všechny uživatelské role a skupiny uživatelů (pož. 4.1.4, 4.1.5) - by se mohlo vysvětlit i jako nutnost plně implementovat uvnitř ERMS vlastní Identity Management
• kontrola přítomnosti škodlivého kódu (4.5.1) - AntiVirus
• kontrola integrity (6.1.40, vol.) - faktura od neidentifikovaného dodavatele, evidentně vazba na CRM či ERP
• správa emailů (6.3)
• skenování, OCR (6.5)
• vazba na Datové schránky (6.6)
• správa slovníku klíčových slov a klasifikace obsahu jejich pomocí (8.1.14 a dále)
  
• automatická asociace obsahu se zobrazovacími klienty (8.2., viz též MIME Type)
• vytištění, vč. hromadných tisků (např. 8.3.3 - vytištění všech dokumentů věcné skupiny, spisu, ... jedinou operací)
• uživatelsky srozumitelné znázornění dokumentů, které nelze tisknout (8.4.1)
• workflows (10.4)
• elektronický podpis, časové razítko, elektronická značka (10.7)
• šifrování a odstraňování šifer (10.8)
• Digital Rights Management (10.9) - na rozdíl od Oracle se tento termín užívá na práci s vodoznakem, steganografii a jinými DTP metodami ochraňujícími duševní vlastnictví
• integrace s faxem

Nechám na každém, ať si to přebere sám. Osobně si ale myslím, že zatímco některé požadavky (datové schránky) jsou velmi úzce spojeny s ERMS, u většiny ostatních se dá spíše očekávat, že ERMS bude spíše čerpat služby ostatních systémů a některé (hromadný tisk) bych snad raději ani nepovoloval - a pokud ano, pak spíš jako součást velmi pečlivě sledovaných a schálených procesů, než "jedinou operací".

Tímto tedy končíme seriál o Národním standardu pro elektronické spisové služby. Příště už se opět budeme věnovat nějakému jinému tématu.

Virtuální E2.0 konference (reference ze záp. Evropy)

8. října 2009 proběhne virtuální konference, ve které budou prezentovány reference z oblasti E2.0 ze západní Evropy; konkrétně:

10:30 British Telecom (dashboard pro Enterprise a Custom aplikace, Web Center Suite, UCM, SOA Suite)
11:00 Direction Generale de l'Aviation Civile (“WEB 2.0 Virtual desktop”)
11:45 Holtzbrinck Publishing Services (UCM)
12:15 Regione Valle d'Aosta (UCM)

Do konference se můžete přihlásit na tomto linku.

Národní standard pro eSSL - 6.část: Operace (speciální operace)

V této části budeme pokračovat v požadavcích na ERMS, které vycházejí z jeho základního poslání, tj. péči o dokumenty. Abychom se vůbec v rozumném rozsahu článku dobrali konce, vezmeme to hodně telegraficky a jen u některých bodů se pustíme trochu více do hloubky.

• Bezpečnost - přidělování přístupu k dokumentům a metadatům na určitou dobu (toto by měla být jedna ze základních vlastností každého systému spravujícího data)
• Nezbytné dokumenty - klasifikace dokumentů, které se zálohují v odděleném režimu a v případě obnovy jsou k dispozici prioritně
• Zachování metadat - při zničení všech ztvárnění (renditions apod.) dokumentu je třeba ponechat metadata, aby o existenci dokumentu dále byl záznam
• Kontrola duplicity - při přidání dokumentu do spisu se kontroluje, zda už v něm není obsažen
• Typy dokumentů - v podstatě nastavení metadatové hodnoty; typy dokumentů mají pomoci definovat oprávnění vytvářet dokumenty (některé typy budou moci vytvářet jen uživatelé s příslušným oprávněním)
• Hlášení o stavu systému - tvorba reportů (MIS), které umožňují správcům sledovat, co se v systému děje. Jedná se o souhrnné reporty obsahující počty, potenciální rizikové operace (např. změna skartačního režimu), atd.
• Tvorba výtahu - "výtah" je speciální ztvárnění dokumentu, ve kterém jsou odstraněny či skryty informace, u nichž zpracovatel stanovil zvláštní ochranu; ve své obecnosti se jedná spíše o požadavek z oblasti DTP (např. i obfuskace fotografií či osobních údajů) a jsem zvědav, jak budou implementace vypadat
• Evidence analogových dokumentů - možná vás to překvapí, ale již dnes u všech projektů digitalizace je třeba myslet i na analogové, tj. listinné dokumenty. I kdyby se organizace rozhodla zdigitalizovat vše (což se prakticky nikdy nedělá - důvody jsou hlavně ekonomické, protože většinu starších dokumentů už fakticky "nikdo nepotřebuje"), je třeba myslet na přechodné období, kdy je část dokumentů již v digitální a část stále v analogové podobě. U analogových dokumentů, jejichž správa připomíná spíš systém pro prezenční výpůjčky v knihovně nebo skladové hospodářství se objeví některá specifika:
  • fyzický výskyt dokumentu
  • využití čárových kódů
  • sledování naplněnosti skladovacích prostor
  • a to vše pokud možno při užití stejných pravidel (dohledatelnosti, skartace apod.) jako u digitálních dokumentů
• Práce se záznamy, tj. elektronickými dokumenty, které je ještě možno měnit či nejsou součástí spisového a skartačního řádu
  
  • odlišení záznamů a dokumentů
  • tvorba dokumentu ze záznamu a naopak (modifikovatelná kopie)
  • podpora verzování u záznamů
• Práce s typovými spisy, tj. jakýmisi šablonami, které definují předem známou strukturu užívanou v předem stanovených procesech
• Podpora distribuovaných systémů, tj. lokální kopie obsahu a řešení kolizí mezi lokálními stavy a centrem (např. při změně metadat); ve své obecnosti je tento požadavek něco, co může nasazení ERMS značně prodražit
• Podpora offline režimu - o tom už jsme se zmiňovali; dokumenty mají umožňovat klasifikaci, které z nich takto nikdy být staženy nemohou
• Bezpečnostní kategorizace - neplést se zabezpečením; zde se jedná o klasifikaci na min. 5 úrovních přístupu (důvěrné - tajné - super tajné apod.), která je nadřazena "normálnímu" bezpečnostnímu mechanismu založeném např. na rolích
• Doplňování implicitních hodnot
• Vyznačování právní moci na dokumentech nebo vykonatelnosti - doplnění doložky právní moci do dokumentu

(Poslední pokračování za týden)

Národní standard pro eSSL - 5.část: Operace (ERMS specifické)

Dnes se zaměříme jen na jedinou třídu operací, a to operace specifické pro Records Management, tj. ty, které zaručují, že dokumenty nebudou smazány před uplynutím skartační lhůty, či naopak podporují proces skartace.

Zamezit smazání je technologicky netriviální problém. Nejhorší to je v případě, je-li ERMS skutečně jen management systém (tj. dokumenty mohou být ve skutečnosti uloženy někde jinde - např. v Content Management Systému). U produktu Oracle Universal Records Management jsou dodržování nadefinovaných pravidel implementovány pomocí adaptérů, které musí být doinstalovány na systém držící dokumenty a které dnes existují pro všechny nejrozšířenější systémy (ano, i pro CMS od konkurence).
Ono to ale v případě, že ERMS drží sám dokumenty je snažší jen o kousek. Pravidla ERMS se kontrolují většinou na aplikační úrovni (tj. pokusím-li se např. přes webové rozhraní uskutečnit požadavek na smazání dokumentu, systém mi oznámí, že to nejde), je však třeba zajistit, aby ke smazání nedošlo na nižších úrovních (např. používá-li se filesystem, pak na úrovni operačního systému). I zde je možné užít adaptéry. Z pohledu Oracle však raději doporučujeme ukládat dokumenty do datábáze Oracle, kde je možné retention management provádět i prostředky databáze (zejm. při využití bezpečnostních options). Úplně nejjistější, ale podle všeho také přimeřeně drahou variantou je využití WORM (Write Once, Read Many) zařízení, která, jak napovídá název, jsou přímo tak postavena a certifikována.

Pokud se podíváme na druhý konec, tam je vše řízeno skartačními režimy (o této problematice jsme psali už ve třetím dílu). Kromě nich existuje ještě specifický požadavek na pozastavení skartační operace (u Oracle se používá termín "Freeze" čili zmrazení), které se používá na ad hoc výjimky - např. na dokumenty, které by sice již měli být zničeny, které jsou však předmětem probíhajícího soudního procesu a tudíž jejich zničení není žádoucí/dovoleno.
Problematika zničení digitálních dokumentů však skrývá i několik problémů - v oblasti zničení či skartace se s listinnými dokumenty pracuje o mnoho snáze. Zatímco papír prohnaný skartovačkou můžeme považovat za efektivně zničený, s digitálním dokumentem smazaným z centrálního úložiště to tak snadné není. Především, data v centrálním systému musí být zálohována a zničení dokumentu by muselo mít za efekt i znepoplatnění všech záloh jej obsahujících (ty zpravidla ve správě ERMS nejsou a jejich zničení by naopak mohlo vést ke značným rizikům jinde). Dále pak musí být zaručeno, že centrální systém je jediným místem, kde se zničený dokument vyskytuje. Národní standard (MoReq2) si v tomto bodě sám protiřečí, protože explicitně vyžaduje možnost práce v off-line režimu, tj. možnost stažení dokumentů mimo centrální úložiště. A to samozřejmě nemluvíme o možnosti Save As, která je vlastní patrně všem aplikacím, ve kterých bude obsah prohlížen. A tím, že budou dokumenty opatřeny kontrolními znaky (elektronický podpis, časové razítko) budou mít tyto kopie stejnou platnost jako dokument v centrálním úložišti. Přiznám se, že prozatím jediné řešení tohoto problému se vším všudy, o kterém vím, je užití nástrojů jako Oracle Information Rights Management, které dokáží znepoplatnění takovéto kopie (dokonce i kopií v zálohách). Tento uživatelský scénář se jmenuje True Delete a určitě si jej někdy popíšeme. Osobně spíš ale očekávám, že tento bod bude ještě dále upravován anebo že se nad výše zmíněnými inkonzistencemi prostě "přimhouří oko".

(Pokračování za týden)

Národní standard pro eSSL - 4.část: Operace (obecné koncepty)

Původně jsem po návratu z dovolené ještě uvažoval o zařazení lehčího tématu, ale když jsem uviděl, o kolik se po začátku uvedení seriálu o Národním standardu zvýšila navštěvovanost blogu, řekl jsem si, že by bylo škoda Vás nechat napínat, jaká bude koncovka. Jak už jsem psal, poslední téma, tj. požadavky na operace, které explicitně zmiňuje Národní standard, jsou natolik rozsáhlé téma, že se určitě do jednoho článku nevejde. Takže přinejmenším ještě jedno pokračování určitě bude.
Pro dnešek začněme se spíše obecnými koncepty.

Dědičnost
Prvním konceptem, který se táhne napříč řadou požadavků, je dědičnost. Pokud si ještě vzpomenete na první část našeho seriálu, kdy jsme se bavili o hierarchickém uspořádání spisového plánu, dědičnost z něj přesně vychází - dědičnost totiž specifikuje požadavky, aby bylo možné některé vlastnosti (přiřazení skartačních režimů, hodnoty metadat, vč. různých nastavení, co je možno a co ne) propagovat z objektů výše v hierarchii (tj. z věcných skupin do včleněných věcných skupin, spisů atd. - existuje i minimálně jeden příklad, kdy se naopak propagují informace z nižších vrstev nahoru, a to informace, že spis obsahuje kromě digitálních i analogové dokumenty) a na nižších vrstvách naopak vyžadovat splnění těchto přednastavených pravidel.

Automatické generování metadat
Z velmi podobného soudku je požadavek, aby systém automaticky generoval některá významná metadata (např. plně určené spisové znaky, jednací čísla, či jednoznačné identifikátory). Oproti dědičnosti tu však navíc přibývá jeden specifický požadavek, a to tvorba podacího deníku, který se (zpravidla po skončení kalendářního roku) uzavře a pro nové období se pořadové číslo dokumentů začne generovat znovu od počáteční hodnoty.

Operace nad seskupením
Opět do značné míry vycházejí z hierarchického uspořádání. Tentokrát však jde o to, aby se se seskupením (spisem, věcnou skupinou) dalo pracovat jako s celkem. Příkladem takovýchto operací je rozdělení věcné skupiny na dvě či přesunutí věcné skupiny v rámci spisového plánu na jiné místo.

Export/Import
Velmi specifickým příkladem takovéto operace jsou exporty či importy části hierarchické struktury. Příloha 2 pak obsahuje XML schémata, v jakých mají data poskytovat. Jinak importovat či exportovat se dá skutečně vše: dokumenty, spisové plány nebo jejich části, skartační plány (režimy), implicitně s tím aktualizace metadatového modelu a dokonce i transakční protokoly (audit).

(Pokračování za týden)

Rozdíly mezi edicemi UCM (UCM vs. UCM SE)

Jestliže před akvizicí firmy Stellent bylo v ceníku několik desítek položek, z nichž se každá ještě prodávala podle nejrůznějších metrik, takže sestavit srozumitelnou obchodní nabídku byl někdy sám o sobě docela obtížný úkol, v ceníku Oracle najdeme vlastně jen tři položky:
- Oracle Universal Content Management (UCM)
- Oracle Universal Content Management Standard Edition (UCM SE)
- Oracle Enterprise Content Management Suite, která se vlastně ale skládá jen z UCM a dvou dalších produktů (URM, I/PM)

Pro výběr vhodné edice je tedy klíčové pochopit licenční omezení UCM SE (jak už je u Oracle zvykem, jedná se ve skutečnosti o jeden a tentýž kód, u nějž jsou omezení dána výhradně na základě koupené licence a důvěry v koncového zákazníka).

Chybějící funkcionalita
Nejvíce zřejmým je funkční omezení – UCM SE je řešením pro jedinou oblast ECM, a to Document Management (DM). Kromě základní komponenty, Content Server, která poskytuje všechny základní funkce pro DM, obsahuje UCM SE už jen dvě další komponenty, a to Desktop Integration Suite, který poskytuje přímou integraci s nástroji jako je Microsoft Office, Lotus Notes, ad., a Dynamic Converter, který slouží ke konverzi vložených dokumentů do formátu html (tj. pro read-only náhled do spravovaných dokumentů).
Všechny ostatní moduly, jako Web Content Management (WCM), Records Management (RM), Digital Asset Management (DAM) ad. nejsou v edici zahrnuty. Stejně tak nejsou v licenci zahrnuty ani produkty BPEL Process Manager či Conversion Server. UCM SE tak sice nabízí možnost definovat workflows; jedná se však o proprietární workflows psaná v jazyce IDOC Script, která lze jen obtížně využívat pro řízení workflows zahrnujících i jiné aplikace či vyžadujícíh složitější logiku, než je sekvenční změna stavu(-ů) jednoho konkrétního dokumentu.

Další omezení
Mezi další omezení pak patří:
- UCM SE je možné instalovat na server s maximálně 4 sockety (paticemi)
- k UCM SE není možné přistupovat přes Web Services – k integraci by se tedy muselo využít např. JAVA API
- UCM SE neumožňuje replikaci na ostatní UCM servery
- UCM SE neumožňuje active-active clustering

UCM SE je určeno jako samostatné (stand-alone) řešení pro uspokojení potřeb z oblasti Document Management pro menší či střední organizace.

Národní standard pro eSSL - 3.část: Metadata

V dnešní části seriálu na téma Národní standard se budeme věnovat metadatům. Po zkušenostech z minulého týdne se raději vystříhám užití tabulek (opravdu to v editoru vypadá jinak).

Zatímco první dvě části je v dokumentu poměrně snadné identifikovat, najít kompletní přehled metadat je možné jedině v přílohách (příloha 1.1, příloha 1.2, XML schéma - příloha 2.) Po pravdě řečeno, ani to není příliš velká pomoc - přílohy 1.1 a 1.2 jsou psány rekurzivním způsobem a příloha 2. jako předpis XML schématu. Bylo by zajímavé změřit, kolik by autorům trvalo odpovědět na otázku: která jsou povinná metadata objektu Dokument?

Nicméně, metadata jde v zásadě rozdělit do několika kategorií:

• identifikační či popisná: např. jednoznačný identifikátor, název, popis, klíčová slova (vybraná ze slovníku) ad.
  
• data: datum vytvoření, otevření, uzavření, vyřazení apod.
• oběh dokumentu/zabezpečení: osoba či oddělení přidelení pro vyřízení, typ dokumentu ad.
  
• specializovaná metadata pro spisovou službu: skartační režim (skartační lhůta), spisový a skartační znak, číslo jednací ad.
  
• metadata specifická pro konkrétní oblast: např. id datové schránky, id odeslané datové zprávy (pro položky vyměňované přes datové schránky), email, CC, předmět (pro emaily), id uživatele, id skenovací sady, počet snímků (pro dokumenty získané skenováním) ad.
• flagy: nastavení možnosti vytvářet ve spisech součásti nebo díly, označení dokumentu za "nezbytný" ad.

Největší pozornost si asi zasluhují metadata zmíněná v sekci specializovaná metadata pro spisovou službu:
Skartační režim - na úrovni věcné skupiny, spisu či dokumentu se jedná o přiřazená metadata; skartační režimy jsou však i objekty definované v rámci ERMS. Jejich rolí je na základě pravidel stanovených zákony či interními procedurami organizace zaručit, že a) nedojde ke smazání položek, u nichž to není možné (např. faktury před uplynutím 10leté skartační lhůty) b) po uplynutí skartační lhůty poslat příslušné dokumenty do skartačního řízení.
Skartační režim rovněž definuje skartační lhůtu - každé položce však může být přiřazeno více režimů (např. dokument může mít obecný skartační režim pro finanční dokumenty, protože se však jedná o fakturu od klíčového zákazníka, může mít nastavena i speciílní pravidla), minimálně však vždy musí být přiřazen alespoň jeden. Případné konflikty pak řeší příslušná správcovská role.
Skartační znak - je položka, jejíž hodnoty jsou dokonce zmíněny už na úrovni zákona 499/2004 Sb. - může mít hodnoty "V" (výběr), "S" (stoupa), "A" (archivováno - u nás do národního archívu).
Číslo jednací, Spisový znak - jedná se vlastně o identifikační metadata, která však mají poměrně úzce specializovaný proces generování - např. číslo jednací je složeno z pořadového čísla dokumentu, roku a kódu organizace či útvaru.

V poslední části, kterou vzhledem k rozsáhlosti tématu bude možná nutné rozdělit do více článků, bychom se ještě podívali na operace, které národní standard vyžaduje podporovat. Vzhledem k mé dovolené si dovolím na příští týden publikovat článek na jiné téma a k národnímu standardu se pak vrátíme, jakmile to časové možnosti dovolí.

Národní standard pro eSSL - 2.část: Zabezpečení

V druhé části se budeme zabývat zabezpečením, tj. zejména rolemi, které definují oprávnění přístupu k obsahu, resp. oprávnění provádět operace. Tato problematika je do jisté míry samopopisná a vychází z tabulky:

Funkce	Role
	uživatelské	správcovské
	Běžný uživatel	Posuzovatel skartačních operací	Místní správce	Ústřední správce
Tvořit nové spisy	Ano	Ne	Ne	Ne
Přijímat dokumenty	Ano	Ne	Ne	Ne
Přetřídit dokument do seskupení	Ano	Ano	Ano	Ano
Vyhledávat a číst dokumenty	Ano	Ano	Ano	Ano
Měnit metadata spisu	Ne	Ano	Ano	Ano
Udržovat spisový plán	Ne	Ano	Ano	Ano
Smazat spisy	Ne	Ano	Ano	Ano
Měnit metadata dokumentů	Ne	Ano	Ano	Ano
Smazat dokumenty	Ne	Ano	Ano	Ano
Zavést nebo odstranit pozastavení skartační operace	Ne	Ano	Ano	Ano
Exportovat a importovat seskupení a dokumenty	Ne	Ano	Ano	Ano
Prohlížet transakční protokoly	Ne	Ano	Ano	Ano
Přidělovat vlastní přístupová práva jiným uživatelům	Ne	Ano	Ano	Ano
Definovat a prohlížet systémové zprávy	Ne	Ano	Ano	Ano
Změna skartačního režimu	Ne	Ano	Ne	Ne
Zničení nebo přenos dokumentu nebo seskupení	Ne	Ano	Ne	Ne
Přidávat nové věcné skupiny	Ne	Ne	Ano	Ano
Přesunout data transakčního protokolu do off-line paměťových médií	Ne	Ne	Ano	Ano
Provádět všechny operace související s uživateli a jejich přístupovými právy	Ne	Ne	Ano	Ano
Konfigurovat a spravovat transakční protokol	Ne	Ne	Ne	Ano
Přidělovat přístupová práva místním správcům	Ne	Ne	Ne	Ano
Zřizovat a spravovat role pro správu typových spisů	Ne	Ne	Ne	Ano
Udržovat systémové parametry	Ne	Ne	Ne	Ano
Měnit obsah dokumentů	Ne	Ne	Ne	Ne
Měnit údaje transakčního protokolu	Ne	Ne	Ne	Ne

Z tabulky snad jen zdůrazněme pokus o oddělení práce s přípravou obsahu (tvorba spisů, možnost přijímat dokumenty "na sebe") od administrátorských úloh - stejně tak některé specifické úkony (např. změna skartačního režimu) jsou k dispozici jen specifické administrátorské roli.
Z tabulky lze však rovněž získat i poměrně zevrubný přehled, jaké operace by měl ERMS podporovat. K tomu se vrátímě někdy příště.

Národní standard pro eSSL - 1.část: Uspořádání dokumentů

V dnešním článku se budeme věnovat dlouho avizovanému tématu, a to návrhu Národního standardu pro elektronické spisové služby tak, jak je dnes k dispozici. Protože se jedná o rozsáhlé téma, bude třeba jej rozdělit na několik částí. V této začneme od uspořádání dokumentů uvnitř systému ERMS.
Uspořádání vychází z tohoto schématu:

Pokud by tento obrázek byl pro Vás nepochopitelný, nabídnu ještě jeden, který sice neobsahuje všechny detaily, ale za to je naprosto jasný:

Začněme úplně na nejnižší úrovni: dokument se může skládat z jedné či několika komponent, tj. několika souborů. Ideou, která je za tímto požadavkem je práce s emaily, které mohou mít více příloh (každá příloha bude komponentou). Podobně může vypadat zpráva poslaná přes datové schránky. Přesto, z pohledu mnoha operací je nejmenší jednotkou dokument a od dalšího dělení můžeme abstrahovat.
Pokud bychom přeskočili na úplně opačný konec, systém ERMS musí umožňovat definici a spravování několika spisových plánů. Ty se pak dále dělí na věcné skupiny a spisy, přičemž v jedné věcné skupině mohou být pouze věcné skupiny nebo pouze spisy a členění věcných skupin musí být umožněno alespoň na 3 úrovně; počet hierarchií spisového plánu pak nesmí být vůbec omezen.
K čemu slouží takovéto dělení? Jednak vychází ze zvyklostí. Z hlediska elektronického zpracování však podporují dvě základní vlastnosti:

• dědičnost - např. při změně metadat (např. spisový znak) je změna na vyšší úrovni automaticky propagována do všech nižších úrovní; podobně je možné od nějaké úrovně dolů vše uzavřít, tj. zakázat přidávání dalších dokumentů, změny metadat apod.
  
• hromadné operace - např. import či export celé věcné skupiny

Od úrovně spisu je možné přiřadit velmi specifický parametr ERMS, a to skartační režim. Detailně se mu budeme věnovat někdy příště, ale toto je parametr, který se stará o to, aby položku nebylo možné smazat před uplynutím skartační lhůty a naopak, aby po jejím uplynutí položka automaticky vstoupila do skartačního workflow.
Na úrovni uprostřed schématu je pak ještě možné spis dále dělit na (volitelné) součásti a díly. Jejich specifikum spočívá v tom, že v jedné otevřené součásti může být jen jeden otevřený díl, tj. díl do kterého je možné přidávat další dokumenty, či měnit metadata.

Oracle UCM se umístil mezi leadery v gartnerovském magickém kvadrantu pro WCM na rok 2009

Původně jsem plánoval, že se tento týden vrátíme k návrhu Národního stadardu pro eSSL, ale vyšla zpráva, o kterou se jednoduše nemohu nepodělit: Oracle UCM se (opět) umístil mezi leadery v magickém kvadrantu analytické společnosti Gartner pro oblast Web Content Management na rok 2009.

Kompletní správa je k dispozici na tomto linku.


Dovolím si ještě pár komentářů: Oracle se umístil jako nejlépe hodnocená firma v oblasti "ability to execute", což je v podstatě schopnost doručit projekt za domluvených podmínek a ne náhodou souvisí i s počtem dodávaných projektů v daném období.

Naše pozice v oblasti "completeness of vision" může být ovlivněna i tím, že nová verze 11g pro produkt UCM bude uvolněna teprve v druhé polovině tohoto roku. Očekává se zejména mnohem větší provázání s portálovými řešeními - někdy se objevuje termín Open WCM, tj. schopnost provádět úpravu webového obsahu, např. tak, jak jsme je viděli v ukázkách v článku z 29.7.2009, a to v plně personalizovaném portálovém prostředí. Uvidíme ale, co se nakonec do 11g podaří vše dostat.

Mezi silnými stránkami je zmiňován i "recommendation engine" a CRM. To druhé asi představovat není třeba, ale první termín může být relativně neznámý. Jedná se o produkt Real-Time Decision Maker (RTD). Spolupráce s WCM (a CRM na druhé straně) se týká především toho, že RTD sleduje chování koncových uživatelů a dokáže-li uživatele nějakým způsobem autentikovat (ať už přímo jeho identitu, nebo "příslušnost ke skupině"), může patřičně změnit obsah i formu stránek. Nejčastěji se mění nabízené inzeráty (na produkty či služby). Pravidla mohou být buď přímo řízena (např. odd. marketingu) nebo mohou být i samoučící (znáte např. z amazon.com, kdy se zobrazují sekce "Frequently Bought Together" a "Customer Who Bought This Item Also Bought"). Obávám se ale, že u nás zatím o podobné řešení moc zájem nebude - souvisí to zejména se stavem využívání CRM systémů obecně.

Výtka vůči cenám licencí Oracle v porovnání s cenami konkurence trošku srovnává hrušky s jablky - existuje řada řešení, např. RedDot, nedávno koupený OpenTextem, která neumí nic jiného, než WCM, a je jasné, že už jen z tohoto titulu budou levnější. Samozřejmě, nepožaduje-li zákazník nic jiného navíc, a to ani v blízké budoucnosti (tak s výhledem na 5 let), nemá mu asi smysl naše řešení nabízet. Na druhé straně, s Oracle UCM dostane v ceně vlastně všechny komponenty ECM řešení - Document Management, WCM, Digital Asset Management, Records Management, ad., a to za jednu cenu. Při implementaci dalších modulů se už využívá centrální komponenta UCM, Content Server a navazuje se na běžné nutné administrátorské úkony (zálohování, mazání nepotřebného obsahu atd.) a navíc na rozdíl od řady dalších dodavatelů není nutné jednotlivé moduly spolu integrovat, takže v celku může vyjít cena řešení výrazně méně. Je ovšem zřejmé, že tento koncept musí nejprve zákazníkům někdo představit a také, že určitě budou existovat organizace, které se v něm nenajdou.

S odkazem na budoucí vývoj budiž řečeno, že už nyní existuje suite, která obsahuje licence jak na Web Center, tak na Oracle UCM.

Kde mohu najít další informace?

V souvislosti s konáním Webcastu minulý týden (mimochodem, pokud jste jej nestihli a měli byste o obsah zájem, celý záznam je k dispozici na stejném linku v sekci Recorded Events) mě napadlo věnovat článek tento týden přehledu míst, kde je možné získat další informace.

Především je to tento blog a česká E2.0 wiki, na které budeme postupně doplňovat články "trvalejšího" charaketru (how-to's, knowledge base). Pokud Vám nějaké informace zásadně chybí, pošlete mi email a já se to v rámci časových možností zkusím napravit.

Pokud máte zájem o informace z Product Managementu, pořádají se pravidelné čtvrtletní webcasty. Jejich aktualizovaný přehled by měl být na tomto linku (ten poslední tam ale není, tak nevím - raději o něm budu informovat také).

Pokud byste potřebovali pomoci s nějakým technickým problémem či potřebovali radu a nezdálo by se Vám možné použít Metalink, doporučuji 2 diskuzní fóra:

• fórum provozované Oraclem
• veřejné fórum na yahoo

Pro úplnost uvedu ještě některé knihy, které jsou v blízkém vztahu k technologiím Oracle v oblasti E2.0, ale zároveň přinášejí i obecné koncepty pro řešení v dané oblasti, které jsou vlastně technologicky naprosto nezávislé:

• Reshaping Your Business with Web 2.0
• Transforming Infoglut! A Pragmatic Strategy for Oracle Enterprise Content Management (metodika pro projekty)
  
• The Definitive Guide to Stellent Content Server Development (bible pro vývojáře)
• Content Management Bible (již trochu starší - z r.2002 - jniha o konceptech)
  

Ukázky - Web Content Management v Oracle UCM

Abychom si trochu odpočinuli od datových schránek, připravili jsme pro Vás něco z úplně jiného soudku. Velmi často chtějí koncoví zákazníci, ale i partneři vidět, jak vlastně systém funguje. Jeden ze způsobů, který bychom rádi vyzkoušeli, je ukázka základních scénářů při užití jednotlivých produktů.

Nejprve si dejme krátké shrnutí, jak ukázku prohlížet: ukázky byly nahrány pomocí nástroje WebEx Recorder. K jejich prohlížení budete proto potřebovat nainstalovaný WebEx Player, který je k dispozici zdarma např. na http://www.webex.com/downloadplayer.html
Budeme rádi, pokud nám sdělíte, je-li tento způsob pro Vás vyhovující. Pokud nebude, pokusíme se najít jinou variantu.

Nyní ke scénářům: v první sadě jsou k dispozici tři a ukazují možnosti modulu Web Content Management v rámci Oracle UCM (verze 10R3).

První část (k dispozici zde, délka 3:33) ukazuje základní práci při editaci stránek. Nejprve uživatel jen prohlíží stránky, pak se přihlásí (už tím může získat právo na nahlížení dalšího obsahu) a následně vstoupí do tzv. přispěvovatelského módu. Následně pak provede na stránce drobné změny - přidá nový odstavec do textu, přidá obrázek a v novém textu přidá odkaz na veřejný dokument z úložiště. Na konci je pak ještě ukázáno, že po opuštění přispěvovatelského módu se stránka vrátí do původního stavu - publikování změn je vázáno na schválení.

Druhá část (k dispozici zde, délka 1:50) pokračuje tam, kde předchozí část skončila. Normálně by přišel uživateli email, ze které by mohl provádět to samé. Na VM, která byla pro účely scénářů užita bohužel není k dispozici mail server. Proto se uživatel pouze přihlásí do Oracle UCM,kde hned na první stránce nalezne seznam úkolů pro schálení. Při samotném schvalování má uživatel možnost si před schválením nejprve prohléhnout navrhované změny (v ukázce vybarveny zeleně) a pak je teprve schválit. Na konci je pak vidět, že hned poté jsou změny publikovány, bez ohledu na to, je-li uživatel prohlížející obsah stránek přihlášen či nikoliv. Samozřejmě, k publikování by mohlo dojít i později po schválení - např. až v daný den a hodinu.

Poslední část (k dispozici zde, délka 1:16) ukazuje 2 možnosti, jak editovat obsah. První, která už byla vidět i v první části, edituje obsah pomocí web editoru přímo na stránkách. Druhá, kde je sekce vytvořena zobrazením souboru, v našem případě MS Word dokumentu, pak užívá přímo textový editor, na který je koncový uživatel zvyklý. Publikace (v této části webu se schvalovací workflows neaplikuje) pak probíhá stisknutím tlačítka "Save".

Pozn. na závěr: omluvte prosím dobu načítání stránek, zejm. v první části. Scénáře byly snímány na VM běžící na ne právě nejvýkonnějším notebooku.

Pozvánka na webcast

Protože bychom už to příští týden nestihli, zvu Vás tímto na pravidelný čtrtletní webcast s Oracle UCM product managementem na téma novinky v Oracle E2.0 portfoliu. Tento bude věnován u nás poměrně neznámému produktu Imaging and Process Management, což je produkt určený primárně pro podporu ukládání a schvalování naskenovaných dokumentů ve spolupráci s velkými podnikovými systémy (ERP). Produkt byl až doposud k dispozici pouze v angličtině; nicméně, od nové verze by již mělo být možné jej lokalizovat. Samozřejmě, spolu s dalšími vylepšeními.

Webcast se koná ve úterý 28.7. 2009, v 17 hod SEČ. V případě zájmu je třeba se nejprve registrovat na této adrese: https://oracle.on.intercall.com/confmgr/event_register.jsp?eventId=92507, následně pak dostanete link, kde bude webcast probíhat.

Novela zákona o archivnictví a spisové službě (část 2)

Jaké povinnosti tedy zákon jednotlivým subjektům ukládá?
Předně, je jasně řečeno, že povinnost vykonávat spisovou službu, tak jak je popsána v paragrafech 64 – 70 a zejména pak v chybějícím národním standardu, mají jen subjekty jasně vyspecifikovány v paragrafu 63. Konkrétně se pak jedná o:
„a) veřejnoprávní původci uvedení v § 3 odst. 1 písm. a) až e) a i) až m),
b) kraje,
c) hlavní město Praha,
d) obce s pověřeným obecním úřadem a obce se stavebním nebo matričním úřadem,
e) městská část nebo městský obvod územně členěného statutárního města a městská část hlavního města Prahy, na něž byla statutem přenesena alespoň část působnosti obce s pověřeným obecním
úřadem nebo působnosti obce se stavebním nebo matričním úřadem,
(dále jen „určení původci“)“ a některé další subjekty zmíněné v odst. 2-4.
Na druhé straně je jasně stanoveno, že:
„(2) Povinnost uchovávat dokumenty a umožnit výběr archiválií mají za podmínek stanovených tímto zákonem také
a) podnikatelé zapsaní v obchodním rejstříku, pokud jde o dokumenty uvedené v příloze č. 1 k tomuto zákonu,
b) politické strany, politická hnutí, občanská sdružení, odborové organizace, organizace zaměstnavatelů, církve a náboženské společnosti, profesní komory, nadace, nadační fondy a obecně prospěšné společnosti,
(dále jen „soukromoprávní původci“)“,
přičemž velmi podobné ustanovení bylo již v původní verzi zákona z roku 2004. To, co bylo poměrně výrazně pozměněno, je však zmiňovaná příloha (najdeme v ní např.):
„1. Statut – např. stanovy, jednací řády
2. Řízení – např. zprávy o auditu či výroční zprávy
4. Finanční dokumenty – roční statistické uzávěrky
5. Propagační činnost – např. katalogy či letáky ad.“
Co je, přinejmenším pro mě, poněkud matoucí, je, jakým způsobem by se měli podnikatelé starat o dokumenty, protože jediný způsob popsaný v zákoně je výkon spisové služby, který pro ně není závazný. Můj osobní názor je, že pro subjekty neprovozující spisovou službu je tak závazný přinejmenším §69a, který řeší uchovávání digitálního dokumentu obecně.
Navíc, uchovávání konkrétních typů dokumentů, které jsou běžně užívány v komerčním sektoru, řeší i další normy – např. zákon č. 235/2004 Sb, o dani z přidané hodnoty, který se zabývá uchováváním účtenek (zjednodušených daňových dokladů) a faktur, např. §27, odst. 1:
„Plátce je povinen uchovávat všechny daňové doklady rozhodné pro stanovení daně nejméně po dobu 10 let od konce zdaňovacího období, ve kterém se uskutečnilo zdanitelné plnění nebo plnění osvobozené od daně s nárokem na odpočet daně, na jím zvoleném místě. Po tuto dobu plátce odpovídá za věrohodnost původu dokladů, neporušitelnost jejich obsahu, jejich čitelnost a na žádost správce daně za umožnění přístupu k nim bez zbytečného odkladu.“
Jistě ne náhodou se v citaci objevují stejné termíny, o jakých jsme psali minulý týden. Na okraj ještě poznamenejme, že ani tento text není z posledních týdnů – práce s elektronickými fakturami již je nějakou dobu možná.

Závěr
Možná již začínáte mít pocit jistého déjà vu. Ano, většina konceptů spojovaných s datovými schránkami zde již opravdu nějakou dobu je a často vlastně ani s datovými schránkami nemají nic moc společného. Co je tedy dnes jinak? Předně to, že existuje povinnost (jednu ukládá 300/2008, tj. vybírat schránku a patřičně reagovat na zprávy v ní nalezené, druhou pak novela 499/2004, tj. uchovávat a skartovat). Za druhé to, že když už systém vznikne, něco jím dříve nebo později začne chodit – jeden z našich potenciálních klientů po naprosto povrchní analýze s překvapením zjistil, že mu bude denně chodit více než 1 500 zpráv (!!!). Další už pak může být vyvoláno lavinovým efektem – jakmile vznikne infrastruktura, bývá už pak přidávání dalších agend poměrně jednoduché, či v neposlední řadě i příležitostmi, které systém nabízí (od 1.1. 2010 B2B komunikace, od 1.7.2010 pak i např. B2C, i když zde bude muset ještě někdo udělat kampaň, která přesvědčí fyzické osoby ke zřizování datových schránek v masivním měřítku).

Novela zákona o archivnictví a spisové službě (část 1)

K dnešnímu datu se už asi poměrně zřídka najde zákazník, který by doposud neslyšel o datových schránkách. Při detailní debatě se zjistí, že všichni většinou mají strach z toho, jak budou svoji schránku vybírat. Mnohem méně zákazníků si však uvědomuje zásadní problém – co budeme s datovými zprávami dělat, až přijdou....
Předně, zopakujme znovu: systém IS DS není archivační systém – zpráva se po 90 dnech (po přečtení či vypršení lhůty pro fikci doručení) smaže.
Datová zpráva však také obsahuje nějaké sdělení, na které se mohou vztahovat nějaká pravidla definovaná jinými zákony, než je zákon 300/2008 Sb., z titulu toho, že se jedná o specifický druh zprávy (žádost podaná na úřad, soudní vyrozumění či faktura). Kromě nutnosti zprávu zaarchivovat (tj. uložit ji definovaným způsobem a po uplynutí dané lhůty ji jiným definovaným zprůsobem zničit), je to v první řadě potřebu zprávu vyřídit – ať už se jedná o prosté vzetí na vědomí či vypracování odpovědi, rovněž odesílané přes rozhraní datových schránek (či jinak).
Zákon o archivnictví a spisové službě, jak napovídá jeho název, se zabývá zejména archivací.

1. většinu důležitých ustanovení pro dokumenty v digitální podobě lze nalézt v §69a. Především, je jasně specifikováno, že „Uchovávání dokumentu v digitální podobě provádí určený původce postupem zaručujícím věrohodnost původu dokumentu, neporušitelnost jeho obsahu a čitelnost dokumentu, a to včetně údajů prokazujících existenci dokumentu v digitální podobě v čase. Tyto vlastnosti musí být zachovány po dobu skartační lhůty dokumentu.“
2. Věrohodnost a neporušitelnost obsahu je prokazována pomocí uznávaného elektronického podpisu, elektronické značky nebo (zde by se spíše hodilo „a“) časového razítka, přičemž je-li dokument těmito aspekty opatřen, je původce povinen ověřit jejich platnost a zaznamenat výsledky ověření; v opačném případě pak opatřit dokument kvalifikovaným časovým razítkem (které samozřejmě něco stojí).
   Ve vazbě na datové schránky budiž doplněno, že časovým razítkem bude opatřovat zprávy ministerstvo, jinak ale budou umožňovat datové schránky doručení podepsaných i nepodepsaných zpráv; za vypravované zprávy bude mít pak zodpovědnost statutární orgán odesílatele. Není však zřejmé, zda se tato zodpovědnost vztahuje na zprávu jako na celek, nebo i na jednotlivé části (pokud obsahuje zpráva více příloh, které je následně třeba rozdělit – např. více faktur).
3. Čitelnost je pak upravena specifikací formátu, ve kterých je možné data dlouhodobě uchovávat (přesný seznam se nalézá ve vyhlášce 191/2009 Sb.): PDF/A (ISO 19005), PNG, TIFF, JPEG, MPEG1, MPEG2, MP2, MP3, WAV. XML bude výstupním formátem pro metadata, a to podle schématu XML, který bude přílohou národního standardu.
4. Velmi důležitým odstavcem, bez kterého by změny vlastně nešly uskutečnit, je §69a, odst. 8: „Neprokáže-li se opak, dokument v digitální podobě se považuje za pravý, byl-li podepsán platným uznávaným elektronickým podpisem nebo označen platnou elektronickou značkou osoby, která k tomu byla v okamžiku podepsání nebo označení oprávněna, osoby odpovědné za převedení z dokumentu v analogové podobě nebo změnu formátu dokumentu v digitální podobě nebo osoby odpovědné za provedení autorizované konverze dokumentů a opatřen kvalifikovaným časovým razítkem.“
5. Na několika místech v zákoně je rovněž zmíněn Národní standard pro elektronické systémy spisové služby (např. §70, odst. 2), který bude založen na normě MoReq2 (na toto téma vizte další detaily v článku z 10.6.2009) a který bude v plné míře popisovat detaily, jak má být archív digitálních systémů provozován. Zatím není k dispozici, ale draft dokumentu je možné získat např. na tomto linku.
   

Výše uvedené body jsou hodně o otázce „jak“. Tato otázka je hodně definována chybějícím národním standardem (přesto se asi v budoucnu někdy vrátíme i k draftu). Další otázkou, ve kterého je často zmatek, je, jaké povinnosti vlastně tento zákon klade na jednotlivé subjekty, zejm. pak na komerční sektor. Tomuto tématu se budeme věnovat příští týden.

Za minulé dva týdny na frontě datových schránek došlo ke dvěma událostem:

• Došlo ke spuštění Informačního systému datových schránek
• Na poslední chvíli vyšlo ve Sbírce zákonů několik novel a především vyhlášek, které upravují velmi důležité detaily (k dispozici např. ve stejnopise zde)

Pokud si chcete systém vyzkoušet, aniž byste chtěli aktivovat svoji skutečnou datovou schránku, využijte možnosti testovacího prostředí na www.czebox.cz; jeden z našich partnerů se účastní jako beta-tester též testování přístupu přes webové služby.

Pojďme se ale podívat více na obsah legislativních změn.

1) posun termínu „nuceného“ spuštění na 1.11.2009 (jinak též konec §31 v novele zákona 300/2008): „Datová schránka podle věty první je zpřístupněna prvním přihlášením osoby uvedené v § 8 odst. 1 až 4. Nepřihlásí-li se osoba uvedená v § 8 odst. 1 až 4 do datové schránky, datová schránka se zpřístupní dnem 1. listopadu 2009.”
2) umožnění využití datových schránek pro B2B a B2C komunikaci (zejm. §18a)

• subjekt nejprve musí požádat, že chce mít možnost takovéto zprávy od ostatních přijímat (§18a, odst. 1)
• posílání takovéto zprávy bude zpoplatněno (bohužel, ve stejnopisu chybí odkaz na příslušnou poznámku pod čarou - §18a, odst. 3, takže není známa cena, ani kde bude určena)
• posílání nevyžádaných či škodlivých sdělení bude trestáno jako přestupek (§26 a-c)
• tato možnost bude k dispozici až od 1.1.2010, a to jen v omezené podobě („mohou … dodávat … pouze faktury nebo obdobné žádosti o zaplacení.“); toto omezení přestane platit po šesti měsících (čl. VII, resp. čl. IX)

3) právnickým osobám a orgánům věřejné moci může být na žádost zřízeno i více datových schránek (§5 a, resp. §6, odst. 4)
4) provozování datových schránek, s výjimkou zasílání notifikačních SMS a odesílání B2B a B2C zpráv, bude zdarma (§14)
5) přímo k problematice datových schránek se vztahují i dvě vyhlášky, a to 193/2009 a 194/2009

1. první řeší především konverze – pokud se nebudete ucházet přímo o certifikaci na provádění autorizovaných konverzí, je zajímavý detail, že vstupním formátem obsaženým do datové zprávy, je PDF 1.3 a vyšší nebo PDF/A
2. druhá vyhláška řeší bezpečnost přístupu do datové schránky (tj. zejména posílení základního mechanismu: jméno/heslo)
3. druhá vyhláška však také stanovuje některé důležité technické údaje:

• velikost zprávy nesmí být větší než 10 MB
• dovolené formáty jsou: pdf, PDF/A, xml (pokud odpovídají veřejně dostupnému XSD schématu), fo, zfo, html, odt, ods, odp, txt, rtf, doc (MS Word), xls, ppt, jpeg, png, tiff, gif, mpeg1, mpeg2, wav, mp2, mp3, isdoc, isdocx

6) jakkoli to není zákonná norma, vyšla taktéž nová verze, bohužel, opět ne finální, rozhraní na datové schránky. Je k dispozici zde (Finální verze má být prý k 15.7.20097)
7) kromě dokumentů týkajících se datových schránek však vyšly i další, které se týkají archivace a spisové služby. Jakkoli toto téma zatím tak akcentováno není, jedná se ve skutečnosti o normy, které jsou pro úspěšnou elektronizaci možná ještě důležitější, než samotné datové schránky.

Těmto novelám se budeme věnovat příště.