Records Management vs. Spisová služba, část 3. - teoretické možnosti ochrany dlouhodobě ukládaných dokumentů

V dnešním článku se zaměříme na ochranné prvky pro dlouhodobé ukládání elektronických dokumentů tak, jak je zná zákon 499/2004, tj. na elektronický podpis a časové razítko, stejně jako na další alternativní možnosti, jak zaručit 3 aspekty dlouhodobého uložení, tj. čitelnost, prokazatelnost a neměnnost.

Asi každý zná základní fakta, že 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 ... a opatřen kvalifikovaným časovým razítkem. Stejně tak je známé, že elektronický podpis je platný max. po dobu 1 roku a časové razítko max. 5 let.

Na počátku jsou problémy hlavně s podpisy - zejm. jejich platností. Bude-li dokument opatřen platným podpisem, ale dorazí-li k příjemci až po vypršení platnosti, je problém. Toto je problém zejména ve spojitosti s autorizovanou konverzí el. dokumentu na listinnou podobu, ke které nemusí dojít okamžitě po doručení dokumentu.
Další drobnou komplikací souvidející z datovými schránkami je to, že u většiny schránek (typicky u osobních schránek), má doručení přes datové schránky stejnou právní platnost jako by byl dokument podepsán. To je možné vyřešit podepisováním - zde asi spíš značkou organizace - na příjmu.
Je-li však dokument podepsán, stejně není vyhráno, protože je třeba provést ověření platnosti podpisu. To je možné až na "next-business-day", protože rejstříky zneplatněných certifikátů se aktualizují (prý) někdy přes noc. Jen na okraj: ergo, datové schránky z podstaty věci není možné užít na "rychloobrátkové" dokumenty, kdy je třeba reagovat v rámci hodin či 1-2 dnů.
Z hlediska dlouhodobého uložení je však důležitější, že protokol o ověření platnosti podpisu (razítka) je také ZD a musí být uložen spolu s průvodním dokumentem.
K časovému razítku jen asi poznámku, že u datových schránek jimi sice opatřuje zprávu sám systém, jedná se však o razítko na celou zprávu (chcete-li: na zprávu v obálce), nikoliv na razítko přiloženého dokumentu/-ů. Ergo, budete-li chtít s dokumenty pracovat odděleně, budete jej muset zřejmě stejně přerazítkovat (pokud tak neučinil odesílatel).

Řekněme, že s tím se nějak vypořádáme. K problémům, na něž zatím neexistuje jasná odpověď, pak dojde v okamžiku vypršení platnosti časového razítka. Na nastalou situaci existují dva právní názory: jeden tvrdí, že pak je třeba dokument znovu přerazítkovat; druhý tvrdí, že není třeba dělat nic, protože v okamžiku zakládání dokumentu bylo vše platné. S druhým názorem by se mělo bojovat - pokud dojde k prolomení šifry, na které jsou založeny podpisy a razítka, může pak někdo "vyrobit" Vámi podepsaný dokument opatřený časovým razítkem, který jste nikdy neviděli. Aby toho nebylo málo, dodejme, že i ukládání elektronických podpisů není věčné - ukládají se myslím na 10 či 12 let, takže po této době se již ani nebude možné dopátrat, kdo to vlastně dokument podepsal.
Ani přerazítkovávání však není příliš lákavá možnost (tedy, pokud nejste certifikační autorita): pokud za rok vytvoříte X dokumentů, pak za 5 let budete přerazítkovávat X, za 10 let 2X, za 15 let 3x atd. A to prosím zpravidla najednou - nejspíš po měsíčních dávkách. Tedy náklady a jakási práce (nejspíš plně automatizovaná - RM systémy vám v tom mohou pomoci sledováním vypršení platnosti časového razítka).

Abychom už měli přehled úplný, dodejme ještě problém, který se zatím nikde moc neeskaloval - problém s čitelností. Dnes je čitelnost řešena taxatorním vyjmenováním formátů, ve kterých je možné dokumenty dlouhodobě ukládat - např. pro texty to je primárně PDF/A. Protože se však bavíme o dlouhých skartačních lhůtách -u některých dokumentů to může být na desítky let či "navždy", dá se předpokládat, že i od tohoto formátu se někdy upustí. Pokud někdo vyspecifikuje, jak PDF/A převést na formát XYZ (bude to další instituce pro autorizovanou konverzi?), je třeba dořešit, jak tento nový dokument svázat s původním obsahem, který obsahuje již dávno neplatné a možná i neexistující identifikátory původce -nejspíš tedy bude možné nějak "přibalit" XYZ k původnímu obsahu a držet vše pohromadě - toto je ostatně myšlenka tzv. archívních balíčků (AIP) z normy OAIS, kterou bude zřejmě nezbytné brzy zapracovat do zákona či vyhlášky.

Slíbil jsem ale přehled dalších možností, jak by se daly tři pilíře implementovat jinak:

1. certifikace systému
První možností jsou certifikace - u nás nejspíš stát jmenuje autoritu, která prověří systém (pro MoReq2 existuje sada testovacích případů, kterými bude testovaný systém prověřen). Poté platí, že je-li dokument vložen do systému jako ZD, pak je autentický a nezměněný. Tento princip dokáže řešit všechny tři pilíře (i konverzi je možné otestovat) a je užit např. v Belgii.

2. nezávislý arbitr
Myšlenkou tohoto řešení je, že bude existovat jeden centrální systém, ve kterém budou uloženy kopie všech dokumentů - pokud budete chtít mít jistotu, zeptáte se, zda dokument, který máte k dispozici, je originálem, za který se vydává. Toto řešení - zatím jen pro dokumenty z datových schránek pod hlavičkou CEED či CEDD - prezentovali někteří dodavatelé. Pokud by zároveň s licencí na provozování systému získali právo na provádění konverzí z důvodů čitelnosti, mohlo by to pro určité omezené celky (např. datové schránky) fungovat. Neumím si však představit, že by to fungovalo jako řešení pro RM obecně (když nic jiného: jak by se u tohoto Velkého Bratra řešila bezpečnost obsahu dokumentů?)

3. ochrana hardwarovými prostředky
Pro neměnnost a autenticitu dokumentu existuje ještě jedno řešení: využití technologií WORM (write-once-read-many), které z definice nedovolují obsah měnit. Protože však ani hardware není věčný, mají tato řešení podporu redundantního ukládání záznamu, resp. garanci dostupnosti. Fakticky se tak jedná o jakousi speciální verzi certifikace systému.

Records Management vs. Spisová služba, část 2.

Abychom se dokázali posunout dále a vyhnuli se pokud možno termínové pasti, je třeba si narovnat základní pojmy: pro anglický termín document budu nadále používat český ekvivalent dokument a pro anglický termín record navrhuji založený, popř. zaknihovaný či zaregistrovaný dokument (zkráceně ZD).

Tento termín v sobě implicitně obsahuje informaci, že ZD je dokument, který prošel nějakým dalším procesem; osobně preferuji adjektivum založený, protože vychází ze zvyklosti, kdy se důležité listinné dokumenty, na kterým organizaci záleželo, zakládaly do spisů.

Takto vybaveni pokusíme zapátrat na internetu po definici pojmu records management. Poměrně vyčerpávající jsem našel na mé oblíbené wikipedii, a to zde. Až se probereme detaily, zkuste jen ze zvědavosti srovnat detaily s definicí spisové služby tamtéž.

1. RM je způsob uchovávání ZD organizace od jejich vzniku až po případnou dobu jejich skartace; RM zahrnuje klasifikaci, uložení, zabezpečení a zničení ZD (v některých případech i jejich archivní uchovávání)
... v této obecné rovině moc rozdílů nenajdeme

2. ISO 15489:2001 (jedna z mezinárodních norem specifikující pojem records management) zahrnuje do RM:

• nastavení politik a standardů
• přiřazení zodpovědností a odpovědností
• vydání směrnic
• poskytování řady služeb spojených se správou a užíváním ZD
• navržení, zprovoznění a udržování systémů pro správu ZD
• integraci RM s ostatními systémy a procesy organizace

... zde už pár drobných rozdílů najdeme. Především, musíme si uvědomit, že rozmach RM nastal (jak se ostatně v anglickém článku na wikipedii zmiňuje) po aféře společnosti Enron, která ve spolupráci s poradenskou firmou Arthur Andersen, podváděla své investory - na základě zfalšované či ztracené dokumentace.
U nás je praxe trochu jiná - RM či spisovou službu organizace provádějí, "protože to po nich stát chce"; často však aniž by stát sám věděl proč, či měl mechanismy jak provádět kontrolu

Můj oblíbený příklad, který uvádím při prezentacích: podle zákona 499/2004 Sb. mají povinnost uchovávat dokumenty také politické strany. Ve smyslu výše uvedeného případu Enron/Andersen by bylo zajímavé provést kontrolu, zda politické strany také neuvádějí v omyl své investory, tj. voliče...

Jiný případ nesouvisí přímo s dokumenty: během své civilní služby v polovině devadesátých let jsem na základní škole Na Líše prováděl kontrolu počtu plynových masek pro děti. Masky byly staré, zaprášené, nemyslím, že by v případě chemického poplachu byly velkou pomocí a naopak možná by spíš způsobily pár problémů v případě cvičení. Přesto, kdyby se ztratila byť jediná, tak paní ředitelku zavřou...

Ale k meritu věci: rozdíl mezi RM a spisovou službou je ten, že RM je mnohem více metodologie, či proces, který slouží k ochraně něčeho, co buď organizace, nebo stát chce chránit. Jeho hlavní podstatou je říct, co se má dělat a kdo je za to zodpovědný a je mnohem volnější v provedení jak. Naopak, spisová služba je hlavně povinnost. Specifikuje co, je velmi detailní v jak, ale je velmi vágní v definování odpovědnosti (zkuste si např. najít v textech najít slovo "odpovědn*"). V jisté extrémní interpretaci se naplnění povinnosti chápe jako "implementace (aplikace) spisové služby" - tj. termínem "spisová služba" se míní sama aplikace.

3. zastavme se ještě u standardů
Pokud připustíme, že i v komerční organizaci existují elektronické dokumenty, které má smysl dlouhodobě uchovávat, ale na které se nevztahuje zákon 499/2004 Sb. (nebo jiný, např. 235/2004 Sb., který se vztahuje na účetní dokumenty - účtenky a faktury, pokud by byly vydávány v elektronické podobě) - může se jednat o nejrůznější vnitrofiremní standardy a procedury, či např. osobní údaje zaměstnanců či údaje o zákaznících (zde může RM pomoci zejména se zákonnou skartací danou zákonem 101/2000 Sb. o ochraně osobních údajů), pak standardy uvedené v zákoně o spisové službě, resp. jeho prováděcí vyhlášce, mohou být značně na obtíž - asi není nic špatného na formátu PDF/A (zajišťujícím čitelnost), dost možná však nebudou třeba elektronický podpis (autenticita - vnitrofiremní systémy si jistě s autenticitou vkladatele poradí), ani časové razítko (neměnnost - opět, organizace bude "věřit" svému systému), nemluvě o košatém metadatovém modelu Národního standardu.

4. časově omezená platnost ochranných prvků aneb legislativní časovaná bomba?
V neposlední řadě je třeba zmínit snad již poměrně známý fakt, že ochranné prvky zajišťující dlouhodobé uložení, mají samy časově poměrně omezenou platnost - což. J. Peterka nazývá ve svém článku "Časovanou bombou v e-Governmentu". Toto téma si zaslouží samostatný článek.

Records Management vs. Spisová služba, část 1.

Pokud bych se měl vyjádřit expresívně, pak v tom v tom tvůrci národního standardu pro spisové služby, byť možná ve vleku zákonodárce, udělali pěkný bordel.

Národní standard je do značné míry překladem evropské normy MoReq2 (mimochodem, už se připravuje nový standard MoReq2010 - bude se tedy Národní standard aktualizovat?), který ovšem obsahuje některé "překladatelské boty" (že by cui bono?), které ve svém důsledku vedou k naprostému zmatení pojmů. Totiž, větu, která v originále zní:

"some documents become records"

přeložili jako

"záznamy se stávají dokumenty"

(to jest prohodili pojmy).

Pojem "Electronic Records Management System" pak překládají jako "Elektronický systém spisové služby", což má evidentně navodit dojem, že "spisová služba" je tím pravým ořechovým pro udržování elektronických dokumentů.

Jakkoli je těchto pojmech beze vší pochyby značný překryv a existují organizace, kde plně splývají, spisová služba není totéž co records management a naopak.

Problém s termínem spisová služba je totiž ten, že je poměrně jasně specifikován zákonem 499/2004 Sb. - §63 stanoví kdo spisovou službu vykonává a §70 potom jakým způsobem.

Termíny spisová služba a records management tedy splývají výhradně u organizací uvedených v §63.

Sám zákon 499/2004 Sb. však stanoví, že "Povinnost uchovávat dokumenty a umožnit výběr archiválií mají" též další organizace dané zákonem. A pokud by tak nepřikazoval zákon, v přiměřené míře by tak měl přikazovat zdravý rozum (minimálně pro tu část věty "uchovávat dokumenty"), protože pro řadu organizací představují dokumenty a jejich efektivní správa skutečnou hodnotu. A troufnu si tvrdit, že přestože by řada z nich ocenila (možná pod vlivem okolností) records management, spisová služba by pro ně byla zbytečnou přítěží.

V čem tedy spočívá rozdíl?

(Pokračování příště)

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.

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)

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.

Národní standard pro systémy elektronické spisové služby

Pokud jste měli při výčtu amerických norem v prvním odstavci článku z minulého týdne pocit, že se nás to netýká, máme pro Vás špatnou zprávu: brzy už to nejspíš nebude pravda. Tím, „kdo za to může“, bude Národní standard pro systémy elektronické spisové služby (název je pracovní, ještě se může změnit), který bude nejspíše zaveden novelou zákona 499/2004 a prováděcími vyhláškami.
K úvodu do této problematiky doporučuji prezentaci p. Miroslava Kunta z Národního archivu, která zazněla na letošní konferenci ISSS a je k dispozici zde. Pro uklidnění: na zavedení bude nejspíš čas (max. však 3 roky od nabytí účinnosti).
V prezentaci se objevuje věta, že tento standard bude vycházet ze standardu MoReq2, což mj. znamená, že nebude úplně totožný. Detaily o rozdílech lze nalézt zde (jen v angličtině).
V této prezentaci se naopak objevuje jedna, na první pohled docela nenápadná věta, totiž „ERMS systems are not and will not be tested in the Czech Republic“ následovaná tvrzením, že mezinárodně činné firmy pravděpodobně budou zvažovat certifikaci na evropské úrovni.
Jednak není jasné, jak bude možné certifikovat řešení podle metod ušitých na přeci jen trochu jiné požadavky. Za druhé, ono to s certifikací dle MoReq2 není o moc slavnější – alespoň podle dostupných informací se zdá, že v současnosti má akreditaci na certifikaci dle tohoto standardu jediná organizace v celé Evropě, a to německá firma imbus AG od prosince 2008 (odkaz na její stránky v angličtině je zde). Akreditace navíc neznamená právo vydávat ověření (dle informací od našeho product managementu nemá sama firma imbus AG dokončenu svoji certifikaci). Pokud tedy někdo tvrdí, že je už dnes certifikován na MoReq2, bylo by zajímavé se zeptat, kdo tento certifikát vystavil.
Pokud bychom se obratem opět vrátili do USA, podobnou roli jako MoReq2 tam mají standardy vydávané Ministerstvem obrany (Department Of Defence), pro oblast Records Managementu pak konkrétně DoD 5015.2., dnes už ve své třetí verzi. Docela zajímavý článek na toto téma je zde – pokud jej navštívíte, přečtěte si i první komentář; docela úsměvné je i sledovat předhánění v tom, kdo „byl první“.

Vzhledem k dovoleným budeme mít příští týden přestávku. Místo toho Vás srdečně zvu na webcast Competing Against & Extending Microsoft SharePoint with Oracle WebCenter Suite, který bude probíhat ve středu 17.6.2009 v 15h (CET) na adrese http://conference.oracle.com, conference id: 146384129 key: 100617

Program webcastu:

• MOSS Overview
• MOSS Strengths: Suite & Portal
• MOSS Limitations: Suite & Portal
• WebCenter Tools to Interoperate and Extend MOSS
• How Microsoft will position WebCenter
• Summary