- 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
Wednesday 30 September 2009
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.
Wednesday 23 September 2009
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)
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)
Wednesday 16 September 2009
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)
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)
Wednesday 9 September 2009
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.
- 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.
Wednesday 2 September 2009
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í:
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í.
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.
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í.
Subscribe to:
Posts (Atom)
