SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA

Transkript

1 Smluvní strany: Nárdní knihvna České republiky IČ: se sídlem Praha 1, Klementinum 190, PSČ , jejímž jménem jedná Ing. Tmáš Böhm, generální ředitel (dále jen Nárdní knihvna neb Objednatel ) čísl smluvy: a Lgica Czech Republic s.r.. se sídlem: Praha 6, Na Okraji 335/42, PSČ: IČ: , DIČ: CZ splečnst zapsaná v bchdním rejstříku vedeném Městským sudem v Praze, ddíl C, vlžka bank. spjení: ING Bank N.V., č. účtu: /3500 jejímž jménem jedná Ing. Pavel Malínek, jednatel (dále jen Pskytvatel ) čísl smluvy: dnešníh dne uzavřely tut smluvu v suladu s ustanvením 269 dst. 2 a s přihlédnutím k 536 a násl. zákna č. 513/1991 Sb., bchdní zákník, ve znění pzdějších předpisů (dále jen Obchdní zákník ) (dále jen Smluva )

2 Smluvní strany, vědmy si svých závazků ve Smluvě bsažených a s úmyslem být Smluvu vázány, dhdly se na následujícím znění Smluvy: 1. ÚVODNÍ USTANOVENÍ 1.1 Objednatel prhlašuje, že je právnicku sbu státní příspěvkvu rganizací, jejíž zřízení, půsbnst, zásady činnsti a rganizace jsu stanveny ve statutu Nárdní knihvny České republiky vydaném ve frmě rzhdnutí ministra kultury České republiky; splňuje veškeré pdmínky a pžadavky v tét Smluvě stanvené a je právněn tut Smluvu uzavřít a řádně plnit závazky v ní bsažené; 1.2 Pskytvatel prhlašuje, že je právnicku sbu řádně zalženu a existující pdle českéh právníh řádu; splňuje veškeré pdmínky a pžadavky v tét Smluvě stanvené a je právněn tut Smluvu uzavřít a řádně plnit závazky v ní bsažené. 2. ÚČEL SMLOUVY 2.1 Objednatel je hlavním realizátrem a garantem prjektu s názvem VYTVOŘENÍ NÁRODNÍ DIGITÁLNÍ KNIHOVNY", který byl schválen jak prjektvý záměr Usnesením vlády ČR ze dne č. 536 strategických prjektvých záměrech pr čerpání prstředků ze Strukturálních fndů EU v rámci Smart Administratin pd číslem 116, a t pd registračním číslem prjektu CZ.1.06/1.1.00/ (dále jen Prjekt NDK ). Bližší ppis a specifikace Prjektu NDK jsu bsaženy v Přílze č. 5 Zadávací dkumentace ve smyslu tét Smluvy s názvem Ppis stávajícíh stavu. 2.2 Prjekt NDK bude financván s využitím finanční pdpry pskytvané z Evrpskéh fndu reginálníh rzvje v rámci Integrvanéh peračníh prgramu (IOP). Prjekt NDK bude realizván v partnerství Objednatele a Mravské zemské knihvny (dále jen MZK ). Cílem Prjektu NDK je vytvření fungujícíh systému Nárdní digitální knihvny jak sučásti vznikající České digitální knihvny a Eurpeany (Evrpské digitální knihvny). Za účelem dsažení výše uvedených cílů a za účelem vytvření slžitéh a kmplexníh infrmačníh systému Nárdní digitální knihvny (dále jen IS NDK ), který se skládá ze čtyř subsystémů - subsystému digitalizace, subsystému dluhdbéh ulžení dkumentů (LTP subsystém), subsystému pr transfrmace a kntrly knzistence (transfrmační mdul) a subsystému zpřístupnění infrmací a dkumentů - a řady vzájemné prpjených technických kmpnent, ptřebuje Objednatel technicky, administrativně a prcesně zkušenéh a erudvanéh partnera, Pskytvatele, který za tímt účelem pskytne Objednateli veškeré ptřebné 2

3 knw-hw, technické, prjektvé a administrativní znalsti a zkušensti pr úspěšné navržení, vytvření a prvz IS NDK a statních kmpnent Prjektu NDK. Pskytvatel bude při realizaci Prjektu NDK splupracvat také s sbu hájící zájmy Objednatele, která byla vybrána Objednatelem v samstatném zadávacím řízení (dále jen Prjektvý manager ). 2.3 Pr dsažení výše uvedenéh účelu uveřejnil Objednatel dne v Infrmačním systému veřejných zakázkách pd evidenčním číslem VZ známení tevřenéh řízení na zadání veřejné zakázky s názvem Systémvý integrátr prjektu Vytvření Nárdní digitální knihvny (dále jen Veřejná zakázka ). Na základě zadávacíh řízení byla pr plnění Veřejné zakázky vybrána nabídka Pskytvatele v suladu s ustanvením 81 dst. 1 zákna č. 137/2006 Sb., veřejných zakázkách, ve znění pzdějších předpisů (dále jen ZVZ ). V suladu s ustanvením 82 dst. 2 ZVZ smluvní strany uzavírají Smluvu. 2.4 Pskytvatel Smluvu garantuje Objednateli splnění zadání Veřejné zakázky a všech z th vyplývajících pdmínek pdle zadávací dkumentace Veřejné zakázky, která tvří vlnu přílhu Smluvy jak její Přílha č. 7 (dále jen Zadávací dkumentace ). Tat garance je nadřazena statním pdmínkám a garancím uvedeným ve Smluvě. Pr vylučení jakýchkliv pchybnstí t znamená, že v případě jakéhkliv rzpru Smluvy a Zadávací dkumentace se uplatní výslvné, závazné a knkrétní ustanvení Zadávací dkumentace, nerzhdne-li Objednatel jinak; a v případě chybějících ustanvení Smluvy budu pužita dstatečně knkrétní ustanvení Zadávací dkumentace. 3. PŘEDMĚT SMLOUVY 3.1 Pskytvatel se tut Smluvu zavazuje pskytnut Objednateli plnění spčívající v navržení, vybudvání (implementaci), ddávce IS NDK a dalších kmpnent kmplexníh infrmačníh systému Nárdní digitální knihvny v rámci Prjektu NDK (dále jen Systém ). Pskytvatel se jak hlavní ddavatel Systému zavazuje k prvedení ddávek veškeréh ptřebnéh sftware a hardware a k vybudvání (implementaci) Systému tvřenéh jedntlivými subsystémy (mduly). Systém je tvřen: technicku, systémvu a síťvu infrastrukturu splečnu pr jedntlivé subsystémy (mduly) ve smyslu dst až Smluvy včetně zahájení prvzu wrkflw digitalizace; subsystémem digitalizace; subsystémem dluhdbéh ulžení dkumentů (LTP subsystém); subsystémem pr transfrmace a kntrly knzistence (transfrmační mdul); a subsystémem zpřístupnění infrmací a dkumentů. 3.2 Sučástí plnění dle tét Smluvy je rvněž pskytvání služby systémvé integrace, kdy Pskytvatel zabezpečí, že Systém bude plně integrván a prvázán se stávajícími systémy a prvky Prjektu NDK, které již u 3

4 Objednatele neb u MZK fungují (knihvní systém ALEPH, registr digitalizace, systém autrizace a autentizace, existující datvé úlžiště a další kmpnenty, které jsu ppsány v Přílze č. 5 Zadávací dkumentace), přičemž bude umžněn sledvání tku dkumentů celým Systémem a bude pskytnut centrální bd pr správu a knfiguraci Systému a jeh jedntlivých subsystémů (dále jen Systémvá integrace ). 3.3 Pskytvatel se dále p dbu účinnsti tét Smluvy zavazuje řádně pskytvat službu pdpry prvzu a maintenance Systému a jeh jedntlivých subsystémů ve smyslu dst až Smluvy, a t nejpzději de dne akceptace psledníh ze subsystémů ve smyslu dst až Smluvy pstupem dle tét Smluvy, a t v pžadvané kvalitě a úrvních (SLA) a rvněž se zavazuje pskytvat aktualizaci sftware neb zajistit sftware maintenance d výrbce, t vše d 31. prsince 2014 (dále jen Pdpra ). V úvdní fázi pskytvání Pdpry a jak její sučást se Pskytvatel zavazuje k testvání, věření funkčnsti a vyhdncení fungvání Systému a jeh jedntlivých subsystémů ve smyslu dst až Smluvy, k ptimalizaci wrkflw, pdpře digitalizace a tvrby metadat, pdpře knverze existujících dat, a t p dbu pěti (5) měsíců v suladu s Přílhu č. 8 Zadávací dkumentace a dle Specifikace plnění ve smyslu tét Smluvy (dále jen piltní prvz ). (Systém, Systémvá integrace a Pdpra dále splečně také jen Plnění ). 3.4 V rámci pskytvání Plnění se Pskytvatel zavazuje rvněž k: prvedení analýzy pžadavků Objednatele na Systém (dále jen Analýza ); vypracvání Prváděcíh prjektu, který knkretizuje vymezení jedntlivých plnění dle Specifikace plnění a bude bsahvat také návrh řešení Systému a bude výstupem prvedené Analýzy, přičemž jeh rámcvý bsah je uveden v Přílze č. 7 Zadávací dkumentace (dále jen Prváděcí prjekt ); ddávce hardware (technlgií) a sftware ptřebnéh k realizaci Systému, včetně jejich instalace resp. implementace v rzsahu dle Specifikace plnění ve smyslu tét Smluvy; vývji a implementaci sftware ptřebnéh k realizaci Systému; zpracvání dkumentace a uživatelských příruček k jedntlivým sučástem Systému a jedntlivým subsystémům ve smyslu dst až Smluvy; šklení uživatelů a administrátrů Systému dle Přílh č. 10 a 11 Zadávací dkumentace vztahujících se k subsystému digitalizace a subsystému dluhdbéh ulžení dkumentů (LTP subsystém). 3.5 Smluvní strany sjednávají, že sučástí Plnění dle tét Smluvy bude rvněž ddávka, instalace a plné zprvznění veškerých ptřebných technlgií pr vybudvání Systému, přičemž Pskytvatel převede na Objednatele vlastnické práv k veškerým ddaným technlgiím. Tyt technlgie bude Pskytvatel pvinen ulžit a instalvat d tří (3) datvých center, která se nacházejí v Praze v Klementinu (Datvé centrum K02), Hstivaři (Datvé 4

5 centrum H02) a v Brně v budvě MZK (Primární datvé centrum). Během realizace Prjektu NDK djde ke stěhvání ddané technlgie v lkalitě Hstivař ze stávajícíh datvéh centra d nvéh datvéh centra, přičemž Pskytvatel se zavazuje v takvém případě na základě písemné výzvy Objednatele prvést zabezpečení a přípravu technlgie ke stěhvání, a následně pětvně plně zprvznit a zfunkčnit přestěhvanu technlgii d stavu před stěhváním, t vše dle pdmínek blíže uvedených v Přílze č. 5 Zadávací dkumentaci (dále jen Příprava ke stěhvání technlgie ). Přípravu ke stěhvání technlgie prvede Pskytvatel nejpzději d sedmi (7) de dne dručení písemné výzvy Objednatele. Cena za Přípravu ke stěhvání technlgie již je bsažena v ceně za vytvření technické, systémvé a síťvé infrastruktury dle dst tét Smluvy. Samtné stěhvání technlgie není předmětem tét Smluvy. 3.6 Smluvní strany sjednávají, že technická specifikace Systému a detailnější vymezení jeh jedntlivých subsystémů a mdulů, stejně jak detailní parametry Pdpry, jsu pdrbněji ppsány a vyplývají z Přílhy č. 1 tét Smluvy s názvem Specifikace plnění (dále jen Specifikace plnění ). Prváděcí prjekt, jakžt výstup Pskytvatele ve smyslu dst Smluvy vycházející ze Specifikace plnění, bude p jeh řádné akceptaci Objednatelem v suladu s tut Smluvu představvat závazné upřesnění a specifikaci Plnění, přičemž Prváděcí prjekt bude p jeh řádné akceptaci pr definici Plnění aplikván přednstně před Specifikací plnění. 3.7 Smluvní strany dále sjednávají, že způsb, pdmínky a detailnější vymezení jedntlivých činnstí Pskytvatele při pskytvání Systémvé integrace a s tím suvisející práva a pvinnsti smluvních stran jsu pdrbněji ppsány a vyplývají z Přílhy č. 2 tét Smluvy s názvem Ppis systémvé integrace (dále jen Ppis systémvé integrace ). 3.8 Smluvní strany se rvněž dhdly, že bližší vymezení pdmínek pskytvání Plnění a s tím suvisející práva a pvinnsti smluvních stran v rámci tét Smluvy mhu vyplývat rvněž z jedntlivých metdických dkumentů vypracvaných Prjektvým managerem dle smluvy pskytvání služeb Prjektvéh managera (dále jen Instrukce ), přičemž takvá Instrukce bude vždy puze v rámci plnění dle tét Smluvy a nebude jej žádným způsbem rzšiřvat a nebude mít vliv na cenu a termíny plnění dle tét Smluvy. K závaznsti Instrukce pr Pskytvatele je nezbytné, aby Objednatel prkazatelně seznámil Pskytvatele s takvu Instrukcí. 3.9 Objednatel se zavazuje převzít veškerá plnění Pskytvatele dle tét Smluvy a zaplatit Pskytvateli za pskytvání Plnění dle tét Smluvy cenu za pdmínek tut Smluvu blíže stanvených Objednatel se zavazuje pskytnut Pskytvateli veškerá právnění a zmcnění ptřebná pr řádné pskytvání Plnění. Objednatel se dále zavazuje řádně a včas předkládat Pskytvateli všechny ptřebné dkumenty a pdklady a vyvinut veškeru ptřebnu sučinnst k řádnému pskytvání Plnění. 5

6 4. DOBA A MÍSTO PLNĚNÍ 4.1 Pskytvání Plnění dle tét Smluvy bude Pskytvatelem zahájen bezprstředně p jejím uzavření, nestanví-li Objednatel jinak, a bude pskytván v suladu se závazným harmngramem, který tvří Přílhu č. 3 tét Smluvy (dále jen Harmngram ). 4.2 Místem pskytvání Plnění je celé území České republiky, zejména sídl Objednatele a sídl partnera Prjektu NDK - Mravská zemská knihvna (MZK), Kunicva 65a, Brn, a dále též místa umístění datvých center ve smyslu dst. 3.5 tét Smluvy. Míst pskytvání Plnění je dále specifikván v Specifikaci plnění a může být upřesněn Prváděcím prjektem, Instrukcí Prjektvéh managera neb jinu instrukcí Objednatele. 5. CENA A PLATEBNÍ PODMÍNKY 5.1 Za kmplexní pskytnutí Plnění včetně ddávky a převedení vlastnickéh neb užívacíh práva k ptřebnému sftware a hardware se sjednává cena v členění a ve výši: Druh plnění Cena v Kč bez DPH Sazba DPH Výše DPH v Kč Cena v Kč s DPH XXX Celkvá cena za Plnění krmě Pdpry (investiční část jednrázvé náklady): ,00 20% , ,00 Tat cena za pskytnutí Plnění je maximální, knečná a nepřekrčitelná a zahrnuje veškerá plnění dle tét Smluvy (s výjimku Pdpry), přičemž její výši není mžné změnit s výjimku změny daňvých předpisů týkajících se daně z přidané hdnty (DPH) a s výjimku níže uvedených pdmínek, a t puze v části ceny včetně DPH. 5.2 Za pskytvání Pdpry v pžadvané kvalitě a úrvních (SLA) se pr jedntlivé sučásti Systému dle tét Smluvy sjednává měsíční cena ve výši: Cena v Kč bez Sazba Výše DPH v Cena v Kč DPH DPH Kč s DPH XXX Celkem za měsíc pskytvání Pdpry ,00 20% , ,20 Celkvá měsíční cena za pskytvání Pdpry bude účtvána a hrazena de dne předpkládanéh zahájení pskytvání Pdpry dle Harmngramu, nejdříve však de dne skutečnéh zahájení pskytvání Pdpry ve smyslu dst. 3.3 tét Smluvy. Celkvá měsíční cena za pskytvání Pdpry bude v případě neddržení pžadvané kvality a úrvně (SLA) pr pskytvání Pdpry, Pskytvatelem autmaticky snížena výši kreditu (slevy z ceny) ve smyslu tét Smluvy dle pravidel v tét Smluvě uvedených. O úrvni 6

7 pskytvání Pdpry v daném kalendářním měsíci bude Pskytvatelem vyhtvván Reprt SLA ve smyslu dst Smluvy. 5.3 Cena za pskytvání Plnění dle dst. 5.1 Smluvy je vždy splatná na základě faktur - daňvých dkladů (dále jen Faktura ) vystavených Pskytvatelem až p řádné a úplné akceptaci neb převzetí a předání předmětnéh Plnění pstupem dle čl. 7 tét Smluvy. Celkvá měsíční cena za pskytvání Pdpry je vždy splatná na základě Faktur vystavených Pskytvatelem p sknčení každéh kalendářníh měsíce pskytvání Pdpry, za který má být účtvána a hrazena cena dle dst. 5.2 Smluvy. Pskytvatel se zavazuje všechny Faktury vystavit d patnácti (15) pracvních dnů d výše uvedenéh rzhdnéh dne pr fakturaci. Pskytvatel dešle Fakturu Objednateli nejpzději následující pracvní den p vystavení Faktury. Splatnst všech plateb je stanvena na třicet kalendářních (30) dnů de dne prkazatelnéh dručení Faktury Objednateli. 5.4 Všechny Faktury musí bsahvat ustanvení tht znění: Plnění byl pskytnut v rámci prjektu reg. č. CZ 1.06/1.1.00/ Integrvanéh peračníh prgramu a musí dále splňvat všechny náležitsti pžadvané záknem č. 235/2004 Sb., dani z přidané hdnty, ve znění pzdějších předpisů, účinných v dbě fakturace, avšak výslvně musí vždy bsahvat minimálně následující údaje: značení smluvních stran (Pskytvatel a Objednatel) a jejich adresy, IČ, DIČ, údaj zápisu vystavvatele Faktury v bchdním rejstříku, značení Smluvy, přesný ppis pskytnutéh plnění, čísl Faktury, den vystavení a lhůtu splatnsti Faktury, značení peněžníh ústavu a čísl účtu, na který se má platit, fakturvanu částku a pdpis právněné sby. Přílhu Faktury budu vždy všechny Objednatelem akceptvané akceptační prtkly, předávací prtkly neb Reprty SLA vztahující se k danému Plnění neb bdbí. 5.5 Nebude-li Faktura bsahvat stanvené náležitsti, neb v ní nebudu správně uvedené údaje dle Smluvy, je Objednatel právněn ji vrátit ve lhůtě splatnsti. V takvém případě se přeruší běh lhůty splatnsti a nvá lhůta splatnsti pčne běžet dručením nvé Faktury Objednateli p prvedeném dstranění vytčených nedstatků. V tét suvislsti smluvní strany prhlašují, že veškeré jejich vzájemné phledávky jsu navzájem zapčitatelné ve smyslu ustanvení 364 Obchdníh zákníku. 5.6 Faktury se platí bankvním převdem na účet příslušné smluvní strany uvedený ve Faktuře. Dnem úhrady se rzumí den, kdy je částka depsána z bankvníh účtu desílatele platby ve prspěch účtu příjemce platby. 5.7 V případě prdlení kterékliv smluvní strany se zaplacením peněžitéh závazku, je tat smluvní strana pvinna zaplatit druhé smluvní straně úrk z prdlení ve výši 0,03 % za každý i zapčatý den prdlení. 6. DALŠÍ PRÁVA A POVINNOSTI SMLUVNÍCH STRAN 6.1 Pskytvatel bude v průběhu celéh trvání Smluvy dpvědný za řádné a včasné vytvření, implementaci a fungvání Systému jak celku a jeh jedntlivých kmpnent. 7

8 6.2 Pskytvatel bude v průběhu celéh trvání Smluvy pskytvat Plnění v suladu s účelem Smluvy a Zadávací dkumentace tak, aby vždy byla zachvávána vyská kvalita pskytvanéh Plnění a byl dbán na dsažení cílů Objednatele stanvených tut Smluvu a Zadávací dkumentací. 6.3 Pskytvatel se zavazuje uchvávat veškeru dkumentaci suvisející s realizací Prjektu NDK, včetně účetních dkladů v suladu s článkem 90 Nařízení Rady (ES) č. 1083/2006 p dbu realizace Prjektu NDK a následně p dbu deseti (10) let d uknčení Prjektu NDK, minimálně však d knce rku 2021, a pkud je v českých právních předpisech stanvena lhůta delší než v evrpských předpisech, musí být pr úschvu pužita delší lhůta. Každý riginální účetní dklad musí bsahvat infrmaci, že se jedná prjekt Integrvanéh peračníh prgramu a musí být značen číslem prjektu. 6.4 Pskytvatel se zavazuje umžnit sbám právněným k výknu kntrly Prjektu NDK, z něhž je Veřejná zakázka hrazena, prvést kntrlu dkladů, a t p dbu danu příslušnými právními předpisy k jejich archivaci. 6.5 Pskytvatel se zavazuje p dbu realizace Prjektu NDK a následně p dbu deseti (10) let d uknčení Prjektu NDK, minimálně však d knce rku 2021 za účelem věřvání plnění pvinnstí vyplývajících z pdmínek prgramu IOP pskytvat pžadvané infrmace a dkumentaci zaměstnancům neb zmcněncům pvěřených rgánů (OSF MV ČR, MMR, Ministerstva financí, Evrpské kmise, Evrpskéh účetníh dvra, Nejvyššíh kntrlníh úřadu, příslušnéh finančníh úřadu a dalších právněných rgánů státní správy) a je pvinen vytvřit výše uvedeným sbám pdmínky k prvedení kntrly, vztahující se k realizaci Prjektu NDK a pskytnut jim při prvádění kntrly sučinnst. 6.6 Pskytvatel se zavazuje prvádět infrmační a prpagační patření na základě Nařízení Kmise (ES) č. 1828/2006, kde je mim jiné stanvena dpvědnst příjemců, pkud jde infrmační a prpagační patření pr veřejnst. 6.7 Pskytvatel se pdle ustanvení 2 písm. e) zákna č. 320/2001 Sb., finanční kntrle ve veřejné správě a změně některých záknů, ve znění pzdějších předpisů, zavazuje splupůsbit při výknu finanční kntrly prváděné v suvislsti s úhradu zbží neb služeb z veřejných výdajů. 6.8 Pskytvatel je pvinen všechny písemné zprávy, písemné výstupy a prezentace dle tét Smluvy patřit vizuální identitu prjektů dle Pravidel pr prvádění infrmačních a prpagačních patření (viz přílha č. 4 Příručky pr žadatele a příjemce finanční pdpry v rámci Integrvanéh peračníh prgramu pr priritní su 1a a 1b Oblasti intervence 1.1a a 1.1b Rzvj infrmační splečnsti ve veřejné správě Výzva čísl 07 časvě nemezená Elektrnizace služeb veřejné správy). Pskytvatel prhlašuje, že ke dni nabytí účinnsti tét Smluvy je s těmit pravidly seznámen. V případě, že v průběhu plnění tét Smluvy djde ke změně těcht pravidel, je Objednatel pvinen tét skutečnsti Pskytvatele bezdkladně infrmvat. 6.9 Pskytvatel se zavazuje, že Plnění bude pskytván v kvalitě a rzsahu specifikvaném ve Smluvě. Pskytvatel se zavazuje praktivně sledvat 8

9 stav a pdmínky pskytvání Plnění a v suladu s pžadavky Smluvy se zavazuje upzrňvat Objednatele v důvdněných případech na mžné rzšíření či změny Plnění za účelem lepšíh naplňvání cílů Smluvy Pskytvatel se zavazuje, že Pdpru bude pskytvat minimálně v kvalitě a úrvních definvaných v jedntlivých SLA (Service Level Agrement, dále jen SLA ), které jsu uvedeny Přílze č. 4 a ve Specifikaci plnění. SLA bsahují měřené parametry pr Pdpru pskytvanu Objednateli V případě, že Pskytvatel nepskytuje Objednateli Pdpru v suladu s příslušnými SLA, zavazuje se Pskytvatel: bez zbytečnéh prdlení zajistit na své náklady další zdrje neb kapacity s cílem pskytvat Pdpru v suladu se SLA, dstranit takvý závadný stav v nejkratší mžné dbě v suladu se Smluvu V případě, že Pskytvatel nepskytuje Objednateli Pdpru v suladu s příslušnými SLA, zavazuje se Pskytvatel pskytnut Objednateli kredity (slevy z ceny), jež jsu pr neddržení jedntlivých parametrů SLA stanveny v Přílze č. 4 a ve Specifikaci plnění Pskytvatel je pvinen neprdleně p zahájení pskytvání Pdpry hlídat a mnitrvat kvalitativní úrveň pskytvání Pdpry tak, aby měl Objednatel dle svéh uvážení kdykliv přístup k průběžným, aktuálním a průkazným výsledkům mnitrvání kvalitativní úrvně pskytvání Pdpry Pskytvatel je pvinen minimálně jednu (1) měsíčně předkládat Objednateli přehledné a kmpletní výkazy a výsledky mnitrvání kvalitativní úrvně pskytvání Pdpry v členění dle jedntlivých subsystémů (dále jen Reprty SLA ), ze kterých bude jednznačně zřejmé, zda byla Pdpra pskytvána v kvalitě definvané v jedntlivých SLA dle tét Smluvy Objednatel neb Prjektvý manager je právněn kdykli v průběhu pskytvání Pdpry prvádět kntrlu úrvně a kvality Pskytvatelem pskytvané Pdpry, přičemž Pskytvatel je pvinen k tmu pskytnut Objednateli, resp. Prjektvému managervi, veškeru nezbytnu a přiměřenu sučinnst. Bližší pravidla sučinnsti smluvních stran jsu uvedena v Ppisu Systémvé integrace Objednatel je dále právněn udělvat Pskytvateli závazné instrukce ke způsbu pskytvání Pdpry, které je Pskytvatel pvinen respektvat a ddržvat, nebudu-li v rzpru se Smluvu, Specifikací plnění, Ppisem systémvé integrace neb Prváděcím prjektem. Budu-li instrukce udělené Objednatelem v rzpru se zájmy Objednatele neb s účelem tét Smluvy, Specifikací plnění, Ppisem systémvé integrace neb Prváděcím prjektem, je Pskytvatel pvinen na tut skutečnst Objednatele bez zbytečnéh prdlení písemně upzrnit a prjednat tut skutečnst s Oprávněnu sbu Objednatele, hrzí-li prvedením instrukce Objednateli vážná újma. 9

10 6.17 Pskytvatel bude mít p celu dbu trvání Smluvy k dispzici a využívat pr plnění Smluvy sby v pstavení Veducíh týmu a IT specialistů, v pžadvaném pčtu a splňující technické kvalifikační předpklady dle Zadávací dkumentace Pskytvatel bude p celu dbu trvání Smluvy udržvat v platnsti certifikáty systému řízení jaksti, systému řízení služeb IT a managementu bezpečnsti infrmací dle pžadavků Zadávací dkumentace, vydané pdle českých technických nrem akreditvanu sbu, neb rvncenné certifikáty vydané akreditvanu sbu v členském státě Evrpské unie Pskytvatel bude p celu dbu plnění Smluvy udržvat v platnsti a účinnsti pjistnu smluvu, jejímž předmětem je pjištění dpvědnsti za škdu způsbenu Pskytvatelem třetí sbě, přičemž limit pjistnéh plnění nesmí být nižší než ,- Kč (slvy: st milinů krun českých) a na pžádání Objednatele neprdleně prkázat existenci a platnst takvé pjistné smluvy Objednateli. Zárveň je Pskytvatel pvinen známit Objednateli každé uknčení platnsti pjistné smluvy, djde-li k takvét skutečnsti a bezdkladně sjednat nvu pjistnu smluvu dpvídající výše uvedeným pdmínkám. 7. AKCEPTACE JEDNOTLIVÝCH VÝSTUPŮ POSKYTOVATELE 7.1 Výsledky a výstupy Pskytvatelem pskytvanéh Plnění budu akceptvány Objednatelem na základě příslušné akceptační prcedury. 7.2 Bude-li Plnění Pskytvatele spčívat v samtné ddávce hardware (technlgií) neb licencí k sftware, prběhne předání a převzetí takvéh Plnění na základě prtklárníh předání těcht Plnění. Smluvní strany prvedu fyzicku kntrlu předávanéh hardware (technlgií) a licencí sftware v předávacím místě a v případě řádnéh Plnění pdepíšu předávací prtkl na ddaný hardware (technlgie) neb předávané licence sftware. Hardware (technlgie) a licence sftware lze předávat i p částech. 7.3 Bude-li Plnění Pskytvatele spčívat ve vypracvání dkumentu v listinné neb elektrnické pdbě běžnéh (každdenníh) charakteru (zejména knkrétní výzva, upmínka, Reprt SLA apd.), bude takvý dkument pvažván za akceptvaný uplynutím třetíh (3.) dne de dne jeh převzetí, nevznese-li příslušná smluvní strana vůči takvému dkumentu písemné námitky. 7.4 Bude-li Plnění Pskytvatele spčívat ve vypracvání dkumentu v listinné neb elektrnické pdbě zásadníh charakteru (zejména Prváděcí prjekt, dkumentace k Systému, ppř. jiné takt výslvně značené dkumenty), bude jeh akceptace prvedena v suladu s ustanvením dst. 7.6 Smluvy. 7.5 Akceptační prcedura zahrnuje věření, zda Pskytvatelem prvedené Plnění vedl ke smluvenému výsledku, tedy zda dpvídá specifikaci, která je na základě Smluvy závaznu, a t prvnáním skutečných vlastnstí jedntlivých částí takvéh Plnění s jejich specifikací bsaženu ve Specifikaci plnění, Ppisu systémvé integrace neb Prváděcím prjektu. 7.6 Akceptace dkumentů v listinné neb elektrnické pdbě 10

11 7.6.1 Pskytvatel se zavazuje průběžně knzultvat vypracvání dkumentů s Objednatelem. Objednatel se zavazuje při průběžných knzultacích Pskytvateli pskytvat veškeru ptřebnu sučinnst a dle svých mžnstí se vyjadřvat k průběžným výstupům Pskytvatele Pskytvatel se zavazuje předat první verzi dkumentu Objednateli k akceptaci v takvé lhůtě, aby nebyla hržena lhůta (milník) pr vyhtvení danéh dkumentu stanvená v Harmngramu. Milník dle Harmngramu představuje časvý kamžik, kdy nejpzději má být dané Plnění s knečnu platnstí akceptván Objednatel se zavazuje vznést veškeré své výhrady neb připmínky k první verzi dkumentu předlžené dle dst d pěti (5) pracvních dnů d jejíh dručení. Nevznese-li Objednatel ve stanvené lhůtě k první verzi dkumentu žádné výhrady ani připmínky, pvažují smluvní strany uplynutím tét lhůty dkument ve znění jeh první verze za řádně akceptvaný a pr smluvní strany závazný Vznese-li Objednatel ve stanvené lhůtě své výhrady neb připmínky k první verzi dkumentu dle dst , zavazuje se Pskytvatel d tří (3) pracvních dnů d jejich dručení prvést veškeré ptřebné úpravy dkumentu dle pdstatněných výhrad a relevantních připmínek Objednatele a takt upravený dkument předat jak jeh druhu verzi Objednateli k akceptaci Objednatel se zavazuje vznést veškeré své výhrady neb připmínky k druhé verzi dkumentu předlžené dle dst d pěti (5) pracvních dnů d jejíh dručení. Nevznese-li Objednatel ve stanvené lhůtě k druhé verzi dkumentu žádné výhrady ani připmínky, pvažují smluvní strany uplynutím tét lhůty dkument ve znění jeh druhé verze za řádně akceptvaný a pr smluvní strany závazný. K výhradám neb připmínkám, které Objednatel mhl a měl vznést již k první verzi dkumentu, ale neučinil tak, se pr účely akceptace nebude přihlížet, Pskytvatel však bude pvinen takvét výhrady neb připmínky Objednatele vypřádat d deseti (10) pracvních dnů d akceptace dkumentu Vznese-li Objednatel ve stanvené lhůtě své výhrady neb připmínky k druhé verzi dkumentu dle dst , zavazují se smluvní strany zahájit splečné jednání za účelem dstranění veškerých vzájemných rzprů a akceptace dkumentu, a t nejpzději d tří (3) pracvních dnů d výzvy kterékliv smluvní strany. Smluvní strany se zavazují nepřerušit zahájené jednání za účelem dstranění vzájemných rzprů a akceptace dkumentu až d úspěšné akceptace dkumentu Smluvní strany se zavazují p akceptaci dkumentu dle dst , dst neb dst ptvrdit akceptaci sepsáním písemnéh akceptačníh prtklu, a t nejpzději d tří (3) pracvních dnů d akceptace dkumentu. Účinky akceptace nastávají pdpisem 11

12 akceptačníh prtklu běma smluvními stranami dle dst. 7.8 Smluvy K akceptaci lze předlžit i dílčí části Prváděcíh prjektu. Akceptace každé dílčí části Prváděcíh prjektu se řídí ustanveními dst. 7.6 Smluvy. Prváděcí prjekt jak celek je však akceptván až akceptací všech jeh dílčích částí. 7.7 Akceptace jiných Plnění, zejména jedntlivých subsystémů Akceptační prcedura bude zahrnvat akceptační testy, které budu prbíhat před zahájením piltníh prvzu na základě specifikace akceptačních testů vypracvané Pskytvatelem jak sučásti Prváděcíh prjektu, přičemž tat bude pdléhat schválení (akceptaci) Objednatelem. Specifikace akceptačních testů bude pr jedntlivá Plnění pdléhající akceptaci dle tht dst. 7.7 bsahvat specifikaci knkrétních testvacích scénářů, akceptačních kritérií, příkladů a dat na akceptační test Pskytvatel vyzve Objednatele písemně k účasti na akceptační prceduře nejméně deset (10) dní před jejím zahájením. Objednatel je právněn se akceptačních testů zúčastnit a svědčit jejich knání. Pkud se Objednatel nedstaví v termínu určeném pr prvedení akceptačních testů, přestže byl Pskytvatelem k účasti řádně a včas vyzván, je Pskytvatel právněn prvést příslušné akceptační testy bez jeh přítmnsti. Objednateli budu pskytnuty kpie veškerých dkumentů vypracvaných v suvislsti s prvedením akceptačních testů, jinak akceptační testy nebyly prvedeny řádně Jestliže jedntlivý předmět akceptačních testů splní akceptační kritéria, pvažuje se smluvními stranami za akceptvaný dnem úspěšnéh uknčení akceptačních testů. Smluvní strany akceptaci ptvrdí sepsáním písemnéh akceptačníh prtklu, a t nejpzději d tří (3) dnů d akceptace dkumentu. Účinky akceptace nastávají pdpisem akceptačníh prtklu běma smluvními stranami dle dst Pkud kterýkliv předmět akceptačních testů nesplňuje stanvená akceptační kritéria příslušnéh akceptačníh testu, sdělí Objednatel své připmínky písemně Pskytvateli frmu strukturvanéh rzdílvéh prtklu, a t nejpzději d patnácti (15) dnů de dne uknčení příslušnéh akceptačníh testu, neb de dne, kdy mu Pskytvatel pskytl veškeru dkumentaci danéh akceptačníh testu, pdle th, c nastane pzději. Nevznese-li Objednatel své připmínky ve stanvené lhůtě, pvažuje se daný předmět akceptačních testů uplynutím tét lhůty za akceptvaný Rzdílvý prtkl je dkument bsahující připmínky Objednatele k předmětu akceptačních testů, který nesplnil akceptační kritéria příslušnéh akceptačníh testu. Připmínky musí být Objednatelem specifikvány v dstatečné pdrbnsti a při zachvání pravidla knkrétnsti. Frmulace připmínek prvedená příslušnými pracvníky Objednatele musí vždy bsahvat přinejmenším tyt náležitsti: (i) název výstupu, k němuž se připmínka vztahuje; (ii) 12

13 bsah připmínky frmulvaný knkrétně, tj. tak, aby byl zřejmé, v čem připmínka spčívá a aby byl mžné připmínku zrealizvat; a (iii) pkyny upřesňující pstup realizace připmínky neb charakteristiku cíle, cílvéh stavu p zapracvání připmínky Vznese-li Pskytvatel výhrady neb připmínky k řádně a včas ddanému rzdílvému prtklu, zavazují se smluvní strany k bezdkladnému zapčetí vzájemných jednání způsbu a termínu jejich dstranění. Nevznese-li Pskytvatel k řádně a včas ddanému rzdílvému prtklu výhrady neb připmínky ve lhůtě pěti (5) dnů d jeh dručení, pvažuje se rzdílvý prtkl za schválený dnem uplynutí tét lhůty Pskytvatel je pvinen na základě schválenéh rzdílvéh prtklu připmínky zapracvat a bez zbytečnéh prdlení předlžit příslušný předmět akceptačních testů k pakvané akceptaci, která se přiměřeně řídí ustanveními tht dst Prces testvání a následných prav se bude pakvat, dkud daný předmět akceptačních testů nesplní veškerá akceptační kritéria příslušnéh akceptačníh testu P vzájemné dhdě bu smluvních stran, má Objednatel práv schválit akceptaci s výhradu, a t na základě rzdílvéh prtklu připmínkvanéh Pskytvatelem, kde Pskytvatel ke každému nesplněnému akceptačnímu kritériu ddá analýzu dpadů prtklvaných nedstatků, a navrhne závazný termín ddání příslušné pravy. Smluvní strany ptvrzují akceptaci s výhradu sepsáním akceptačníh prtklu, kde bude výše uvedený rzdílvý prtkl připmínkvaný Pskytvatelem nedílnu sučástí tht akceptačníh prtklu. Účinky akceptace s výhradu nastávají pdpisem akceptačníh prtklu běma smluvními stranami dle dst. 7.8 Smluvy. 7.8 K pdpisu akceptačníh prtklu pdle tht čl. 7 je právněn statutární rgán smluvní strany, dále právněná sba smluvní strany ve smyslu čl. 13 tét Smluvy, případně těmit sbami písemně pvěřená sba, nebude-li vyplývat z tét Smluvy neb jinéh závaznéh dkumentu jinak. 8. UŽÍVACÍ PRÁVA 8.1 K písemným výstupům Pskytvatele pskytnutým v rámci pskytvání Plnění neb k tzv. unikátním pčítačvým prgramům, tedy pčítačvým prgramům vytvřeným výhradně pr ptřeby Objednatele, které mají pvahu autrskéh díla dle zákna č. 121/2000 Sb, autrskéh zákna, ve znění pzdějších předpisů (dále jen autrské díl ), je Objednateli Pskytvatelem pskytvána pr území České republiky nevýhradní licence bez mezení c d mnžství a způsbu užití, a t p celu dbu trvání majetkvých práv autrských k takvému autrskému dílu (dále jen Licence ). Jak sučást Licence dle tht dstavce uděluje Pskytvatel Objednateli i suhlas k prvedení jakýchkliv změn neb mdifikací výsledků uvedených autrských děl, a t i prstřednictvím třetích sb a výslvný suhlas k pstupení Licence a k pskytnutí právnění užít tyt výsledky 13

14 třetím sbám dle uvážení Objednatele, t vše bez nutnsti dalšíh suhlasu ze strany Pskytvatele. Pr vylučení jakýchkliv pchybnstí smluvní strany prhlašují, že cena za pskytnutí práva užít uvedená autrská díla je již zahrnuta v ceně Plnění, v rámci něhž byl autrské díl vytvřen. 8.2 Pskytuje-li Pskytvatel Licenci k unikátním pčítačvým prgramům, vztahuje se ve stejném rzsahu k pčítačvým prgramům ve zdrjvém a strjvém kódu, jakž i ke kncepčním přípravným materiálům. Pskytvatel se zavazuje v případě, že se Licence vztahuje k pčítačvým prgramům, pskytnut Objednateli zdrjvé kódy takvých pčítačvých prgramů a kncepční přípravné materiály (zahrnující zejména analýzy a technické designy) a tyt v případě změny průběžně aktualizvat a pskytvat i dkumentaci prvedených změn. Pskytvatel se dále zavazuje předat Objednateli aktuální dkumentvané zdrjvé kódy a kncepční přípravné materiály všech pčítačvých prgramů d třiceti (30) dnů d sknčení účinnsti tét Smluvy. 8.3 Bude-li výsledkem plnění neb jiné činnsti Pskytvatele prváděné dle tét Smluvy pčítačvý prgram, který nebyl vytvřen výhradně pr ptřeby Objednatele, ale jedná se zejména tzv. standardní pčítačvý prgram Pskytvatele neb třetí strany, který je autrským dílem, nabývá Objednatel Licenci dnem pskytnutí autrskéh díla Objednateli k užívání. Sučástí Licence je rvněž nemezené práv Objednatele pskytnut třetím sbám pdlicenci k užití autrskéh díla v rzsahu shdném s rzsahem Licence a také suhlas Pskytvatele k pstupení Licence na třetí sby. Licence se autmaticky vztahuje i na všechny nvé verze, aktualizvané verze, i na úpravy a překlady autrskéh díla, ddané Pskytvatelem. 8.4 Pskytvatel je pvinen pstupvat tak, aby udělení Licence k autrskému dílu dle tét Smluvy včetně právnění udělit pdlicenci zabezpečil, a t bez újmy na právech třetích sb. Nebude-li mžné p Pskytvateli spravedlivě pžadvat udělení Licence v rzsahu dle dst. 8.1, 8.2 neb 8.3 tét Smluvy, je Pskytvatel pvinen na t písemně Objednatele upzrnit splu s náležitým důvdněním a pskytnut Objednateli neb zajistit pr Objednatele pskytnutí licence či pdlicence v nejširším mžném rzsahu. Pstup dle předchzí věty je mžný jen s výslvným písemným suhlasem Objednatele, přičemž Objednatel se zavazuje, že tent suhlas nedmítne pskytnut bez vážnéh důvdu. 9. ODPOVĚDNOST ZA ŠKODU 9.1 Každá ze smluvních stran nese dpvědnst za způsbenu škdu v rámci platných právních předpisů a Smluvy. Pskytvatel plně dpvídá za plnění Smluvy rvněž v případě, že příslušnu část plnění pskytuje prstřednictvím třetí sby (subddavatele). Seznam subddavatelů Pskytvatele je bsažen v Přílze č.6 tét Smluvy. 9.2 Obě smluvní strany se zavazují k vyvinutí maximálníh úsilí k předcházení škdám a k minimalizaci vzniklých škd. 9.3 Žádná ze smluvních stran nedpvídá za škdu, která vznikla v důsledku věcně nesprávnéh neb jinak chybnéh zadání, které bdržela d druhé smluvní strany. V případě, že Objednatel pskytl Pskytvateli chybné zadání 14

15 neb pkyn a Pskytvatel s hledem na svu pvinnst pskytvat plnění s dbrnu péčí mhl a měl chybnst takvéh zadání neb pkynu zjistit, smí se ustanvení předchzí věty dvlávat puze v případě, že na chybné zadání Objednatele písemně upzrnil a Objednatel trval na půvdním zadání. Žádná ze smluvních stran není dpvědná za nesplnění svéh závazku v důsledku prdlení druhé smluvní strany neb v důsledku klnstí vylučujících dpvědnst ( 374 Obchdníh zákníku). 9.4 Objednatel je právněn pžadvat náhradu škdy i v případě, že se jedná prušení pvinnsti, na kteru se vztahuje smluvní pkuta, a t v plné výši dle Smluvy. 9.5 Případná náhrada škdy bude zaplacena v měně platné na území České republiky, přičemž pr prpčet na tut měnu je rzhdný kurs České nárdní banky ke dni vzniku škdy. 9.6 Smluvní strany prhlašují, že celkvá předvídatelná výše škdy, která může z prušení pvinnstí dpvědné smluvní strany při plnění tét Smluvy vzniknut pškzené smluvní straně a kteru může neb mhla dpvědná smluvní strana v dbě vzniku tét Smluvy při vynalžení bvyklé péče předvídat, nepřesáhne částku rvnající se limitu pjistnéh plnění vyplývajícíh z pjistné smluvy Pskytvatele ve výši ,- Kč (slvy: st milinů krun českých). Tt mezení se netýká škd způsbených smluvní stranu úmyslně neb z hrubé nedbalsti. Smluvní strany shdně prhlašují, že v suladu s ustanvením 379 Obchdníh zákníku se škda způsbená neúmyslně neb nedbalstně pškzené smluvní straně, převyšující výši předvídatelné škdy dle tht dstavce, nenahrazuje. 10. VYŠŠÍ MOC 10.1 Žádná ze smluvních stran není dpvědná za prdlení s plněním závazků stanvených Smluvu, pkud byl způsben klnstmi vyšší mci Smluvní strany se zavazují upzrnit druhu smluvní stranu bez zbytečnéh dkladu na vzniklé klnsti vyšší mci, bránící řádnému plnění Smluvy. Smluvní strany se zavazují k vyvinutí maximálníh úsilí k dvrácení a překnání vyšší mci. 11. SANKCE 11.1 Smluvní strana je v prdlení s plněním svéh závazku, který pr smluvní stranu vyplývá ze Smluvy aneb platných právních předpisů, jestliže jej nesplní řádně a včas. Žádná ze smluvních stran není v prdlení s plněním svéh závazku v důsledku prdlení druhé smluvní strany V případě prdlení Pskytvatele s vypracváním Prváděcíh prjektu, vzniká Objednateli nárk na smluvní pkutu ve výši ,- Kč (slvy: třicet tisíc krun českých) za každý i zapčatý den prdlení s vypracváním tht dkumentu V případě prdlení Pskytvatele s pskytnutím některéh Plnění dle milníku uvedenéh v Harmngramu, vzniká Objednateli nárk na smluvní pkutu 15

16 ve výši ,- Kč (slvy: třicet tisíc krun českých) za každý i zapčatý den prdlení s pskytnutím takvéh Plnění V případě prdlení Pskytvatele s pskytnutím sučinnsti dle dst. 6.13, neb 6.19, vzniká Objednateli nárk na smluvní pkutu ve výši ,- Kč (slvy: deset tisíc krun českých) za každý i zapčatý den prdlení s pskytnutím tét sučinnsti V případě prdlení Pskytvatele s Přípravu ke stěhvání technlgie na základě příslušné výzvy Objednatele dle dst. 3.5 Smluvy, vzniká Objednateli nárk na smluvní pkutu ve výši ,- Kč (slvy: třicet tisíc krun českých) za každý i zapčatý den prdlení s prvedením takvé Přípravy ke stěhvání technlgie V případě prdlení Pskytvatele s plněním jinéh závazku ve smyslu dst. 3.4 tét Smluvy, pkud Pskytvatel nezjedná nápravu ani d pěti (5) pracvních dnů d písemnéh upzrnění Objednatele na tt prdlení, vzniká Objednateli nárk na smluvní pkutu ve výši ,- Kč (slvy: třicet tisíc krun českých) za každý i zapčatý den prdlení s plněním každéh jedntlivéh závazku V případě jednání Pskytvatele spčívajícíh v prušení pvinnsti chránit Osbní údaje dle dst Smluvy, vzniká Objednateli nárk na smluvní pkutu ve výši pěti (5) násbku sankce ulžené Úřadem na chranu sbních údajů za každý jedntlivý případ Smluvní strana, která pruší pvinnsti vyplývající ze Smluvy hledně chrany Důvěrných infrmací ve smyslu čl. 12 Smluvy, je pvinna zaplatit druhé smluvní straně smluvní pkutu ve výši ,- Kč (slvy: st tisíc krun českých) za každé prušení takvé pvinnsti, a t d třiceti (30) dnů de dne dručení písemné výzvy na její uhrazení, přičemž maximální výše tét pkuty je mezena v suhrnu na částku ,- Kč (slvy: jeden milin krun českých). Tím není dtčen ani mezen nárk na náhradu vzniklé škdy Za prušení pvinnsti mlčenlivsti Pskytvatelem se pvažují též případy, kdy tut pvinnst pruší kterákliv z sb uvedených v dst , dst neb dst Smluvy Smluvní pkuta je splatná třicátý (30.) kalendářní den de dne dručení písemné výzvy právněné smluvní strany k jejímu uhrazení pvinnu smluvní stranu Není-li dále stanven jinak, zaplacení jakékliv sjednané smluvní pkuty nezbavuje pvinnu smluvní stranu pvinnsti splnit své závazky a nedtýká se nárku na náhradu škdy v plné výši dle Smluvy Maximální suhrnná výše všech pkut dle Smluvy je mezena na částku ve výši ,- Kč (slvy: dvě stě milinů krun českých). Tím není dtčen ani mezen nárk na náhradu vzniklé škdy. 12. OCHRANA INFORMACÍ 12.1 Smluvní strany jsu si vědmy th, že v rámci plnění závazků ze Smluvy: 16

17 si mhu pskytnut infrmace, které budu pvažvat neb budu značeny za důvěrné (dále jen Důvěrné infrmace ); mhu jejich zaměstnanci a sby v bdbném pstavení získat vědmu činnstí druhé smluvní strany neb i jejím pminutím přístup k Důvěrným infrmacím druhé smluvní strany Smluvní strany se zavazují, že žádná z nich nezpřístupní třetí sbě Důvěrné infrmace, které při plnění Smluvy získala d druhé smluvní strany Za třetí sby pdle dst se nepvažují: zaměstnanci smluvních stran a sby v bdbném pstavení, ve vztahu k Objednateli, statutární rgány smluvních stran a jejich členvé, ve vztahu k Pskytvateli jeh subddavatelé, za předpkladu, že se pdílejí na plnění Smluvy, Důvěrné infrmace jsu jim zpřístupněny výhradně za tímt účelem a zpřístupnění Důvěrných infrmací je učiněn v rzsahu nezbytně nutném pr naplnění jeh účelu a za stejných pdmínek, jaké jsu stanveny smluvním stranám ve Smluvě Smluvní strany se zavazují v plném rzsahu zachvávat pvinnst mlčenlivsti a pvinnst chránit Důvěrné infrmace vyplývající ze Smluvy a též z příslušných právních předpisů, zejména sbní údaje dle zákna č. 101/2000 Sb., chraně sbních údajů, ve znění pzdějších předpisů (dále jen ZOOÚ ). Smluvní strany se v tét suvislsti zavazují pučit veškeré sby, které se budu pdílet na plnění Smluvy, výše uvedených pvinnstech mlčenlivsti a chrany Důvěrných infrmací a dále se zavazují vhdným způsbem zajistit ddržvání těcht pvinnstí všemi sbami pdílejícími se na plnění Smluvy Budu-li infrmace pskytnuté Objednatelem či třetími stranami, které jsu nezbytné pr plnění dle Smluvy, bsahvat data pdléhající režimu zvláštní chrany pdle ZOOÚ, zavazuje se Pskytvatel zabezpečit jejich chranu a splnění všech hlašvacích pvinnstí, které ZOOÚ vyžaduje, a bstarat předepsané suhlasy subjektů sbních údajů předaných ke zpracvání. Pskytvatel je pvinen si vyžádat k prvedení úknů dle tht dstavce zvláštní plnu mc d Objednatele Budu-li infrmace pskytnuté Objednatelem či třetími stranami, které budu nezbytné pr plnění dle Smluvy bsahvat i Osbní údaje pdléhající režimu zvláštní chrany pdle ZOOÚ, zavazují se smluvní strany uzavřít samstatnu smluvu zpracvání sbních údajů ve smyslu 6 ZOOÚ, přičemž Objednatel bude správcem a Pskytvatel zpracvatelem sbních údajů Veškeré Důvěrné infrmace zůstávají výhradním vlastnictvím předávající smluvní strany a přijímající smluvní strana vyvine pr zachvání jejich důvěrnsti a pr jejich chranu stejné úsilí, jak by se jednal její vlastní Důvěrné infrmace. S výjimku rzsahu, který je nezbytný pr plnění Smluvy, se bě smluvní strany zavazují neduplikvat žádným způsbem Důvěrné infrmace druhé smluvní strany, nepředat je třetí straně ani svým vlastním zaměstnancům a zástupcům s výjimku těch, kteří s nimi ptřebují 17

18 být seznámeni, aby mhli plnit Smluvu. Obě smluvní strany se zárveň zavazují nepužít Důvěrné infrmace druhé smluvní strany jinak, než za účelem plnění Smluvy Nedhdnu-li se smluvní strany výslvně písemnu frmu jinak, pvažují se za Důvěrné infrmace implicitně všechny infrmace, které jsu a neb by mhly být sučástí bchdníh tajemství, tj. například, ale nejenm, ppisy neb části ppisů technlgických prcesů a vzrců, technických vzrců a technickéh knw-hw, infrmace prvzních metdách, prcedurách a pracvních pstupech, bchdní neb marketingvé plány, kncepce a strategie neb jejich části, nabídky, kntrakty, smluvy, dhdy neb jiná ujednání s třetími stranami, infrmace výsledcích hspdaření, vztazích s bchdními partnery, pracvněprávních tázkách a všechny další infrmace, jejichž zveřejnění přijímající smluvní stranu by předávající smluvní straně mhl způsbit škdu Bez hledu na výše uvedená ustanvení se za Důvěrné infrmace nepvažují infrmace, které: se staly veřejně známými, aniž by t zavinila záměrně či nedbalstně přijímající smluvní strana, měla přijímající smluvní strana legálně k dispzici před uzavřením Smluvy, pkud takvé infrmace nebyly předmětem jiné, dříve mezi smluvními stranami uzavřené smluvy chraně infrmací, jsu výsledkem pstupu, při kterém k nim přijímající smluvní strana dspěje nezávisle a je t schpna dlžit svými záznamy neb důvěrnými infrmacemi třetí strany, p pdpisu Smluvy pskytne přijímající smluvní straně třetí sba, jež takvé infrmace přitm nezíská přím ani nepřím d smluvní strany, d které tyt infrmace pcházejí; jejichž zveřejnění je vyžadván záknem či pravmcným rzhdnutím rgánu státní správy, becných či stálých rzhdčích sudů Pvinnst utajvat Důvěrné infrmace uvedená v tmt článku zavazuje smluvní strany p dbu účinnsti Smluvy a p dbu třech (3) let d uknčení jejich smluvníh vztahu. 13. OPRÁVNĚNÉ OSOBY 13.1 Každá ze smluvních stran jmenuje právněnu sbu či sby. Oprávněné sby budu zastupvat smluvní stranu v záležitstech suvisejících s plněním dle Smluvy Jména právněných sb jsu uvedena v Přílze č. 5 tét Smluvy. Každá ze smluvních stran je právněna jednstranně změnit své právněné sby, je však pvinna na takvu změnu druhu smluvní stranu písemně upzrnit nejpzději d tří (3) pracvních dnů. Účinnst změny právněných sb vůči druhé smluvní straně nastává dnem dručení známení tét změně. Změna právněných sb není pvažvána za změnu Smluvy ve smyslu ustanvení dstavce 20.1 Smluvy. 18

19 14. SOUČINNOST A VZÁJEMNÁ KOMUNIKACE 14.1 Smluvní strany se zavazují vzájemně splupracvat a pskytvat si veškeré infrmace ptřebné pr řádné plnění svých závazků. Smluvní strany jsu pvinny infrmvat druhu smluvní stranu veškerých skutečnstech, které jsu neb mhu být důležité pr řádné plnění Smluvy Smluvní strany jsu pvinny plnit své závazky vyplývající ze Smluvy tak, aby nedcházel k prdlení s plněním jedntlivých termínů a se splatnstí jedntlivých peněžních závazků Pskytvatel je pvinen pskytvat přiměřenu sučinnst a splupracvat s Prjektvý managerem neb s sbami, které může Objednatel dle svéh uvážení v přiměřené míře využívat pr kntrlu a dhled nad řádným plněním Smluvy Veškerá kmunikace mezi smluvními stranami bude prbíhat prstřednictvím právněných sb neb jimi pvěřených pracvníků neb statutárních zástupců smluvních stran Všechna známení mezi smluvními stranami, která se vztahují ke Smluvě, neb která mají být učiněna na základě Smluvy, musí být učiněna v písemné pdbě a druhé smluvní straně dručena dle dst Smluvy, pkud není výslvně stanven jinak Písemnst, která má být dle Smluvy dručena druhé smluvní straně (známení, výpvěď, dstupení d smluvy, atp.), je dručena dnem jejíh převzetí právněnu sbu dle Smluvy, dnem jejíh tevření, byla-li dručena d Datvé schránky neb dnem, kdy byla dručena sbně neb prstřednictvím držitele pštvní licence d sídla tét smluvní strany a převzata sbu právněnu za smluvní stranu jednat neb zaměstnancem pvěřeným přejímáním písemnstí Nepdaří-li se písemnst dručit dle předchzíh dstavce, za den dručení se pvažuje též den, kdy byl přijetí tét písemnsti adresátem dmítnut. Je-li dručván prstřednictvím držitele pštvní licence d vlastních ruku na adresu uvedenu ve Smluvě neb na adresu, kteru smluvní strana písemně známila jak změnu tét adresy, za den dručení se též pvažuje třetí (3.) den d známení ulžení zásilky na pště, i když se adresát tm nedzvěděl, neb den, kdy zásilka byla deslána zpět jak nedručitelná, prtže smluvní strana nadále tut adresu nevyužívá Účinky dručení mhu nastat též dručením písemnsti telegraficky, faxem neb elektrnicku pštu za pdmínky, že takvá písemnst bude neprdleně, nejpzději však d tří (3) pracvních dnů, ptvrzena způsbem uvedeným v dst. 14.6, ledaže by Smluva výslvně připuštěla v knkrétním případě dručení puze elektrnicku frmu Ukládá-li Smluva dručit některý dkument v písemné pdbě, může být dručen buď v listinné pdbě neb na elektrnickém nsiči dat jak dkument textvéh editru MS Wrd verze 2003 a vyšší, příp. tabulkvéh kalkulátru MS Excel verze 2003 a vyšší neb ve frmátu PDF na dhdnutém médiu. 19

20 14.10 Smluvní strany se zavazují, že v případě změny své adresy budu tét změně druhu smluvní stranu infrmvat nejpzději d tří (3) pracvních dnů. 15. JAKOST PLNĚNÍ 15.1 Pskytvatel nese dpvědnst za t, že všechna Plnění ve smyslu tét Smluvy budu pskytvány v nejvyšší dstupné kvalitě tak, aby vyhvvaly ptřebám Objednatele, se kterými byl Pskytvatel seznámen, přičemž budu pskytvány s náležitu dbrnu péčí a prstřednictvím sb, které mají ptřebnu kvalifikaci i zkušensti k plnění svých úklů. 16. ZÁRUKA 16.1 Pskytvatel pskytuje záruku, že hardware a technlgie pskytnuté Objednateli v rámci plnění tét Smluvy mají ke dni pdpisu akceptačníh prtklu příslušnéh Plnění neb jeh části dle tét Smluvy funkční vlastnsti uvedené v Prváděcím prjektu Pkud není v tét Smluvě výslvně uveden jinak, pskytuje se na hardware a technlgii záruka p dbu dvacetičtyř (24) měsíců de dne řádné a úplné akceptace takvéh hardware a technlgie Záruční dba hardware a technlgií začíná plynut dnem pdpisu akceptačníh prtklu Plnění neb té jeh části, ve které je předmětný hardware bsažen, v suladu s tut Smluvu Pkud není v tét Smluvě výslvně uveden jinak, je Objednatel pvinen vady hardware a technlgií písemně známit Pskytvateli bezdkladně, nejpzději d patnácti (15) dnů de dne jejich zjištění, jinak jeh práv z dpvědnsti za vady zaniká. Pskytvatel v takvémt případě pršetří známenu vadu a v případě, že se na ni vztahuje záruka dle tét Smluvy, tut vadu bez zbytečnéh dkladu dstraní. Objednatel mu přitm pskytne ptřebnu sučinnst, a t zejména pr dhalení příčiny vady Pskytvatel nenese dpvědnst za vady hardware a technlgií vzniklé z důvdů na straně Objednatele neb třetích sb, ani v případě, že Objednatel neprváděl stanveným pstupem údržbu hardware a technlgií, nepužíval všechny pravné prgramy ddané Pskytvatelem, užíval hardware neb technlgie i přes existenci vady, ačkliv byl Pskytivatelem upzrněn na nutnst přerušení užívání hardware, neb d hardware neb technlgií zasáhl bez předchzíh suhlasu Pskytvatele s takvým knkrétním zásahem. 17. ZMĚNOVÉ ŘÍZENÍ 17.1 V případě, že Objednatel či Pskytvatel pžaduje změnu rzsahu Plnění neb kvalitativní úrvně pskytvané Pdpry, předlží smluvní strana navrhující tut změnu druhé smluvní straně návrh změny písemně Obě smluvní strany se zavazují takvý pžadavek, včetně jeh důsledků na Celkvu cenu, prjednat a v případě zájmu smluvních stran plnění ve změněném rzsahu neb za změněných pdmínek, zavazují se smluvní 20

21 strany realizvat pžadavek na změnu či bjednávku v suladu se záknnými nrmami a uzavřením ddatku ke Smluvě Smluvní strany beru na vědmí, že změnvé řízení musí být prveden způsbem a v rzsahu, který bude v suladu s předpisy vztahujícími se k zadávání veřejných zakázek, zejména pak v suladu se ZVZ. 18. ŘEŠENÍ SPORŮ 18.1 Práva a pvinnsti smluvních stran výslvně neupravené tut Smluvu se řídí Obchdním zákníkem a statními příslušnými právními předpisy českéh právníh řádu Smluvní strany se zavazují vyvinut maximální úsilí k dstranění vzájemných sprů vzniklých na základě Smluvy neb v suvislsti s ní, včetně sprů jejich výklad či platnst a usilvat se smírné vyřešení těcht sprů nejprve prstřednictvím jednání právněných sb, pvěřených zástupců neb statutárních rgánů smluvních stran či jejich členů Nebude-li sprná záležitst vyřešena d šedesáti (60) dnů de dne dručení výzvy k jednání dle dst Smluvy, budu všechny spry vznikající z tét Smluvy a v suvislsti s ní rzhdvány s knečnu platnstí u Rzhdčíh sudu při Hspdářské kmře České republiky a Agrární kmře České republiky pdle jeh Řádu a Pravidel třemi rzhdci. 19. ÚČINNOST SMLOUVY 19.1 Smluva nabývá platnsti a účinnsti dnem jejíh pdpisu běma smluvními stranami. Smluva se uzavírá na dbu určitu d 31. prsince Účinnst Smluvy zaniká výhradně: dhdu smluvních stran, jejíž sučástí bude i zajištění pskytvání Plnění a Pdpry a vypřádání veškerých vzájemných závazků a phledávek; písemným dstupením d Smluvy v případě pdstatnéh prušení Smluvy jednu ze smluvních stran, které je účinné dnem dručení písemnéh známení dstupení druhé smluvní straně; neb písemným dstupením Objednatele d Smluvy v případě nepředvídatelných klnstí suvisejících s nemžnstí další realizace Prjektu NDK. Takvét dstupení d Smluvy je účinné dnem dručení písemnéh známení dstupení Pskytvateli Pdstatným prušením Smluvy se rzumí zejména prdlení smluvní strany s plněním závazků pdle Smluvy p dbu delší než třicet (30) dnů, pkud druhá smluvní strana nezjedná nápravu ani v ddatečné přiměřené lhůtě, která jí byla první smluvní stranu pskytnuta na základě písemné výzvy ke splnění pvinnsti, přičemž tat lhůta nesmí být kratší než deset (10) dnů d dručení takvét výzvy Smluvní strany se dhdly, že při dstupení d Smluvy je Objednatel ve lhůtě jednh (1) měsíce právněn určit, které pskytnuté plnění (a 21

22 adekvátní pskytnuté prtiplnění) si mají smluvní strany navzájem vrátit. Nebude-li v známení dle předchzí věty uveden výslvně jinak, vylučují smluvní strany pužití ustanvení 351 dst. 2 Obchdníh zákníku a zánikem účinnsti Smluvy z jakéhkliv důvdu není dtčen vzájemné plnění, které byl řádně pskytnut a byl již přijat neb přijat být měl a mhl před účinnstí dstupení, jakž i nárky na úhradu ceny za takvé plnění včetně náhrady přiměřených a prkazatelně důvdněných nákladů Pskytvatele. Pr vylučení pchybnstí smluvní strany prhlašují, že ustanvení předchzí věty se pužijí i ve vztahu k licencím uděleným dle tét Smluvy Uknčením účinnsti Smluvy nejsu dtčena ustanvení týkající se náhrady škdy, smluvních pkut, chrany infrmací a řešení sprů. 20. ZÁVĚREČNÁ USTANOVENÍ 20.1 Smluva představuje úplnu dhdu smluvních stran předmětu Smluvy. Smluvu je mžné měnit puze písemnu dhdu smluvních stran ve frmě číslvaných ddatků Smluvy, bustranně dsuhlasených a pdepsaných právněnými zástupci bu smluvních stran Pkud by se kterékliv ustanvení Smluvy ukázal být neplatným z důvdu rzpru s kgentním ustanvením becně závazných právních předpisů, pak tat skutečnst nepůsbí neplatnst než nh knkrétníh ustanvení, pkud je tt ddělitelné d statníh bsahu Smluvy. Smluvní strany se zavazují takvé neplatné ustanvení dhdu nahradit ustanvením svým bsahem nejbližším duchu takvéh neplatnéh ustanvení, respektujícím pžadavky bchdníh zákníku neb právních předpisů, na něž bchdní zákník dkazuje Veškerá práva a pvinnsti vyplývající ze Smluvy přecházejí, pkud t pvaha těcht práv a pvinnstí nevylučuje, na právní nástupce smluvních stran Nedílnu sučást Smluvy tvří tyt přílhy: Přílha č. 1 Přílha č. 2 Přílha č. 3 Přílha č. 4 Přílha č. 5 Přílha č. 6 Přílha č. 7 Specifikace plnění Ppis Systémvé integrace Harmngram SLA Oprávněné sby Seznam subddavatelů Zadávací dkumentace Veřejné zakázky (vlná přílha) 20.5 Smluva byla vyhtvena a účastníky pdepsána ve čtyřech (4) vyhtveních, každé s platnstí riginálu, z nichž každá ze smluvních stran bdrží p dvu (2) vyhtveních. 22

23 Smluvní strany prhlašují, že si Smluvu přečetly, že s jejím bsahem suhlasí a na důkaz th k ní připjují svje pdpisy. Objednatel Pskytvatel V Praze dne V dne Nárdní knihvna České republiky Ing. Tmáš Böhm, generální ředitel Lgica Czech republic s.r.. Ing. Pavel Malínek, jednatel 23

24 Přílha č. 1 SPECIFIKACE PLNĚNÍ 1.1 Celkvá kncepce navrhvanéh řešení Celkvá kncepce řešení Systému NDK nabízenéh Pskytvatelem vychází ze snahy c nejefektivněji naplnit pžadavky kladené v Zadávací dkumentaci. Cílem je dsáhnut vyváženéh pměru stability, výknu, dstupnsti a bezpečnsti systému, výrazné flexibility a rzšiřitelnsti systému a snadnsti bsluhy a užívání systému. Při návrhu nabízenéh Systému NDK jsme vycházeli z prcesů, které je ptřeba v rámci digitalizace, archivace a zpřístupnění realizvat a s pdpru Systému NDK efektivně řídit a také z výchzích parametrů pr dimenzvání pžadvanéh řešení definvaných Objednatelem: Předpkládané kvantitativní parametry Celkvý pčet digitalizvaných stran za dbu prjektu na bu pracvištích: Celkvý pčet digitalizvaných stran za dbu prjektu na 1 pracvišti: 26 mil. 13 mil. Celkvý pčet digitalizvaných stran za dbu prjektu na 1 pracvišti za jeden den: Průměrný pčet stran za 1 den při dvu směnách na 1 pracvišti: Maximální pčet digitalizvaných stran za 1 den na 1 pracvišti: Pčet pracvních stanic: Objem dat v LTP d knce prjektu: 51 pracvních stanic 622,730 TB Architektura Systému NDK Rámcvé schéma výsledné architektury Systému NDK, včetně rzdělení na kmpnenty a znázrnění datvých tků, je vidět na Obrázku 1. Jedntlivé stavební prvky navrženéh Systému NDK a také vysvětlení technických, kncepčních, strategických a rganizačních rzhdnutí, které jsme při návrhu architektury a kncepce učinili, jsu ppsány dále v textu pd brázkem. 1

25 XXX Obrázek 1 Schéma výsledné architektury Systému NDK 2

26 Technické řešení Systému NDK XXX 3

27 1.1.2 Prcesní mdel Systému NDK Obrázek 2 Pdpra prcesů v subsystémech Základní prcesy, z nichž vychází ppsaná architektura nabízenéh Systému NDK, a které tak bude Systém NDK pdprvat, jsu následující: Prcesy plánvání digitalizace na základě vstupů bsahujících pžadavky na digitalizaci (Registr digitalizace), parametrů celéh Systému NDK (výknvé a frmátvé mžnsti skenerů, výknvé parametry pstprcessingu apd.) a při zhlednění zpětné vazby získané mnitringem prvzu Systému NDK je v rámci prcesu plánvání vytvřen cca jednu za měsíc plán digitalizace. Plán digitalizace sumarizuje pžadavky na ddání knih k digitalizaci tak, že specifikuje pžadvanu frmátvu (primární ukazatel, na kterém typu skeneru bude skenván) skladbu titulů a mnžství pr jedntlivé frmáty. Hlavním cílem prcesu plánvání je plné a rvnměrné využití digitalizačních technlgií. Vhdné plánvání by měl zamezit prstjům skenerů z důvdu nedstatku vstupů stejně jak přetěžvání některých druhů skenerů z důvdu převahy jednh knkrétníh typu dkumentu. Pdpra nabízenéh Systému NDK pr prcesy plánvání spčívá v následujících funkcích: Knfigurace parametrů Systému NDK nutných pr plánvání Přijetí pžadavků na digitalizaci d Systému NDK Genervání pžadavku na ddání dkumentů pr digitalizaci 7

28 Prcesy digitalizace pdpra tht základníh prcesu si klade za cíl zkmbinvat efektivní využívání technlgických (skenery), lidských (bsluha skenerů, pracvníci pstprcessingu) a výpčetních zdrjů systému. Pstup převdu sestává z celé řady nezbytných či vlitelných krků, které musí být systémem pdprvány, sledvány a řízeny. Během průchdu dkumentu základním prcesem digitalizace se střídají manuální úlhy, kde je nezbytná akce ze strany uživatele, s úkny plně autmatizvanými, které jsu vyknávány autnmními kmpnentami Systému NDK. V rámci prcesu digitalizace bude vstupní dkument řízeným způsbem převeden d digitální pdby a připraven na vlžení d dluhdbéh úlžiště. Pdpra nabízenéh Systému NDK pr prcesy digitalizace se skládá ze zpřístupnění manuálních perací nad dkumentem a řízení autmatizvaných krků zpracvání. Systém NDK nabízí pdpru především následujících funkcinalit: Přijetí/Vrácení fyzickéh dkumentu k digitalizaci Zahájení/dknčení skenvání dkumentu Zahájení/Dknčení pstprcessingu hrubých naskenvaných dat Prvedení pstprcessingu hrubých naskenvaných dat pmcí specializvaných nástrjů Treventus ScanGate pr dkumenty s pžadavkem na zachycení lgické struktury (lgická strukturální metadata budu získávána maximálně z 5 % digitalizvaných dkumentů, cž dpvídá předpkládanému mnžství zvláště důležitých mngrafií) ScanTailr pr dkumenty typu kniha s většinvě hmgenní strukturu stránek Řízení autmatizvané knverze brazů d pžadvaných frmátů (master cpy, user cpy) Řízení prvedení autmatizvanéh OCR na zvleném OCR mdulu (sučástí ddávky je mdul zalžený na řešení ABBYY Recgnitin Server) - tat funkcinalita pkrývá i mžné pužití jinéh mdulu pr OCR dle vlby Objednatele (bude ddána dkumentace ppisující integraci externích OCR mdulů) Manuální řešení nízké úspěšnsti OCR (prstředky řízení Wrkflw, prstředky Recgnitin Serveru verifikační rzhraní) Řízení kmpletace metadat dkumentu (autmatizvaný sběr z pdprvaných zdrjů, manuální dplnění metadat) Pdpra řešení chybvých či výjimečných situací v případě, že některý z krků sknčí chybu, neb jsu identifikvány prblémy technickéh rázu, systém pskytuje GUI pr nápravu a řešení prblému (rzhraní Wrkflw pr nápravu stavu dkumentu, editační aplikaci pr řešení prblémů v datech dkumentu na pracvním úlžišti) Řízení předání dkumentu d LTP 8

29 Prcesy přijetí dat z jiných zdrjů pr ukládání dat z externích zdrjů nabízený Systém NDK pdpruje řízení zpracvání jak dávek dkumentů, tak jedntlivých dkumentů v definvaném frmátu (dle zdrje). Přijetí dkumentu či dávky ke zpracvání Prvedení transfrmací v transfrmačním mdulu pdle zdrje dat Manuální úprava zpracvávaných dat editačním mdulem (v případě, kdy jsu již ve frmě standardní struktury pracvníh prstru) Předání dkumentů k ulžení d LTP a aplikací pr zpřístupnění Pdpra řešení chybvých či výjimečných situací pmcí zpřístupnění dat editačním mdulem Nabízený systém je dimenzván tak, aby v průběhu dby trvání prjektu zajistil rvněž migraci stávajících brazvých dat d nvé LTP infrastruktury. Plánvaný výkn dedikvaný pr migraci bude dstatečný a umžní migraci v průměru stran denně (celkem dkumentů d rku 2014) Prcesy archivace dat data v definvaném frmátu jsu v rámci prcesu převzata subsystémem LTP, je prvedena validace a data jsu p transfrmaci d AIP ulžena d dluhdbéh úlžiště. Prcesy dluhdbé chrany dat pr data ulžená v dluhdbém úlžišti jsu v pravidelných intervalech spuštěny prcesy dluhdbé chrany. Verifikace ulžení bitstreamu Ověření bezpečnsti pužitých datvých frmátů (ve frmě reprtu všech datvých frmátů v úlžišti) Migrace dat definvaných vlastnstí d nvých frmátů Výběr dat dle frmátu, ve kterém jsu ulžena (alternativně i jiných metadat) a prvedení exprtu vybraných dat. Pmcí služeb transfrmačníh mdulu spustit migrační transfrmační Wrkflw Ulžit d LTP nvu verzi dat Prcesy vyzvednutí dat z archivu - data ulžená v archivu je mžné pdle metadat vyhledat a z úlžiště vyzvednut pmcí následujících funkcinalit: vyhledání sady dkumentů k vyzvednutí z archivu pdle daných kriterií spuštění úlhy vyzvednutí dat v dedikvané části pracvníh prstru vznikne balík DIP bsahující vyzvednutá data Prcesy zpřístupnění mají za úkl zajistit přístup k dkumentům z různých zdrjů pr běžné uživatele a t v jediném, uživatelsky vlídném rzhraním, aniž by uživatel musel vědět, ve 9

30 kterém zdrjvém systému se hledané infrmace nacházejí. Za tímt účelem tedy subsystém Subsystém zpřístupnění pskytuje následující funkce: Sklízení dat z definvaných zdrjů Pskytvání dat (OAI-PMH prvider) Indexaci sesbíraných dat Zpřístupnění prhledávání dat pmcí webvé aplikace Zprstředkvání zbrazení nalezených brazů dkumentů resp. stažení PDF verzí Prcesy řízení a mnitringu digitalizace perativní prcesy řízení jsu pdprvány systémem Wrkflw. Pr pdpru dluhdbéh řízení a mnitringu bude využíván mdul RDC. Mdul RDC pskytuje následující funkcinality: Definvání glbálních metrik a interních prjektů digitalizace Sběr statistických dat pvzu systému NDK Knslidace a zpracvání sebraných dat Vizualizace statistických dat ve frmě reprtů a grafů Exprt reprtů ve frmě XLS Bezpečnst Splečnst Lgica se dluhdbě prfiluje na místním i světvém trhu jak specialista na infrmační bezpečnst. Cílem tét kapitly je demnstrvat náš systematický přístup k řešení bezpečnsti, který není mezený puze na technlgický phled. Z tht phledu je naše řešení navržen tak, že rbustnst a bezpečnst je jeh inherentní vlastnstí Základní výchdiska Pžadavkem Objednatele je zajistit vysku úrveň bezpečnsti a chrany digitální dat. Další pžadavkem na systém je dlnst prti výpadku. Ze Zadávací dkumentace rvněž vyplývá záměr Objednatele pdstupit certifikaci pdle standardu TRAC. Tent standard dkazuje na další nrmy mezi nimi na BS resp. ISO 27001:2005. Z hlediska uvedených standardů je nutné řešit v blasti bezpečnsti následující: a) Omezení ddavatelskéh rizika (TRAC článek C 3.1) b) Ddržení suladu s předpisy a zákny ((TRAC článek C 3.1, ISO článek A přílhy) c) Ochrana fyzickéh a lgickéh perimetru (TRAC článek C 3.2) d) Ochrana integrity dat e) Dstupnst dat 10

31 Omezení ddavatelskéh rizika Omezení rizika Pskytvatele znamená učinit krky, které chrání Nárdní knihvnu a jí investvané prstředky pr případ selhání (úpadku, změny bchdních pdmínek, změny vlastnické struktury) Pskytvatele kmpnent systému digitalizace a dluhdbé chrany. Jestliže nastane takvý případ, pak je jedinu chranu dstupnst zdrjvéh kódu. Prt jsme se při výběru subddavatelů rientvali na tuzemské splečnsti, které v zájmu úspěchu prjektu respektují pžadavek pskytnutí zdrjvéh kódu a licenční pdmínky uvedené v Zadávací dkumentaci. Sučasně tím naše splečnst a její subddavatelé deklarují dstupnst vývjvých pracvníků pr pdpru ddávaných SW kmpnent a jejich další vývj. Stejně tak v případě pdpry skenerů, je náš subddavatel jediným autrizvaným servisem rbtických skenerů 4Digital Bks v reginu CEE. Jsme přesvědčeni, že takvu úrveň šetření ddavatelskéh rizika není mžné zajistit s účastí zahraničníh subddavatele Ddržení suladu s předpisy a zákny vlastnictví dat Pžadavek ddržení právní shdy sučasně znamená vyřešit tázku vlastnictví infrmačních aktiv, v tmt případě především dat. Pkud nebude vyřešen vlastnictví dat a právně pdlžen, nelze předpkládat úspěšnu certifikaci pdle TRAC. Nebyl by tedy splněn jeden z cílů prjektu. Nárdní knihvna pskytne svá zařízení k umístění d prstr MZK. Zde budu předlhy ve vlastnictví MZK digitalizvány. Předlhy, stejně jak jejich digitální kpie však zůstávají vlastnictvím MZK, i když jsu ulženy na HW ve vlastnictví NK. Pkud tedy nebude smluvně vyřešen vlastnictví dat, nelze uspkjivě vyřešit rganizačně i dpvědnst za jejich chranu. T pvede k nesplnění pžadavků, které TRAC klade na rganizační stránku chrany dat. Upzrňujeme na tut skutečnst, jak na jeden z faktrů úspěšnsti řešení a mezení rizik celéh prjektu Ochrana fyzickéh a lgickéh perimetru Řízení bezpečnsti znamená chránit infrmační aktiva na úrvni fyzickéh a lgickéh perimetru. Vzhledem k územní rzsáhlsti umístění fyzických kmpnent systému, je jediným správným řešením mezení veliksti fyzickéh perimetru. Th dsahujeme kncentrací technlgických zdrjů (výpčetní kapacita, pracvní úlžiště) d jednh vysce výknnéh datvéh centra, které zajistí efektivitu prváděných perací při zpracvání velkých bjemů dat. Vzhledem k relativně vyskému bjemu zpracvávaných dat je datvý tk systémem navržen tak, aby všechna data, která mají být zpracvána, byla dpravena na centrální uzel d centrálníh pracvníh úlžiště a tam pak zpracvávána v rámci lkálních SAN/LAN sítí. Ddávané řešení je kncipván tak, že se stane de fact vnitřním systémem NK. Z tht phledu přejímá charakter a metdy prstředí, d nějž je integrván Ochrana integrity dat Integrita dat je chráněna v celém živtním cyklu dat. Během jejich vzniku jsu všechna zařízení vybavena zálžními zdrji s dstatečnu kapacitu. V průběhu zpracvání a transferu d LTP je 11

32 integrita dat průběžně validvána a chráněna. Tím je zaručena jejich správnst a neprušenst. Ochrana ulžených dat v LTP je předmětem prcesů dluhdbé chrany dat (v suladu se standardem OAIS), které jsu ppsány dále Dstupnst dat Jak již byl uveden výše, data jsu průběžně chráněna. Samtný bsah LTP pak existuje ve třech kpiích, z čehž dvě kpie jsu ulženy v navzájem vzdálených gegrafických lkalitách. XXX Další patření k psílení bezpečnsti Pžadavek na ddržení bezpečnstních standardů předpkládá jejich plnění i v průběhu ddávky prjektu. Standard TRAC vyžaduje jak základ pr zahájení certifikačníh prcesu existenci certifikátu dle BS (ISO 27001:2005). T znamená, že je nutné zpracvat veškeru dkumentaci vyžadvanu tut nrmu. Pr Pskytvatele je takvým dkumentem analýza rizik řešení. Ta bude zpracvána standardizvanu metdu Treath Mdel a bude sučástí prváděcíh prjektu, stejně jak dkument Plán šetření rizik bsahující patření pr eliminaci rizik. V průběhu realizace bude trvale mnitrván naplňvání bezpečnstních pžadavků. 1.2 Ppis vytvření Prváděcíh prjektu V rámci plnění první prjektvé fáze vytvří Pskytvatel Prváděcí prjekt. Sučástí Prváděcíh prjektu bude pdrbný návrh architektury řešení, pdrbný návrh jedntlivých ddávek a služeb Prjektu NDK a návrh řešení bezpečnsti. V suladu s pžadavky Objednatele bude Prváděcí prjekt bsahvat níže ppsané části. Prjektvá příprava, zahrnující: Prjektvý plán Specifikace cílů Prjektu NDK Rzsah Prjektu NDK Ppis způsbu a rganizace řízení Prjektu NDK s dkazy na využitu metdiku a suvisející platné nrmy Organizační struktura prjektu. Ppis zdrjů (lidských i hmtných) pr zapjení na prjektu Infrmace účastnících Prjektu NDK vč. kntaktů a jejich hlavní půsbnsti Harmngram Prjektu NDK 12

33 Přehled suvisejících prjektů Vymezení základních rizik Prjektu NDK Charakteristika jedntlivých fází prjektu Charakteristika předmětu plnění pdle jedntlivých fází Charakteristika předpkládaných a využitelných vstupů a vazeb Knkrétní výstupy jedntlivých etap Plán kvality Rzpčet prjektu na jedntlivé fáze Prjektu NDK včetně harmngramu jeh čerpání (sučinnst Objednateli) Plán pstupů při řízení kvality Plán testů Organizace při řízení kvality Strategie testvání pr Prjekt NDK SI Specifikace akceptačních testů Akceptační kritéria pr Prjekt NDK SI i jedntlivé fáze Plán šklení Analytická příprava, zahrnující: Analýza pžadvaných pracvních pstupů a prcesů Analýza a vyhdncení uživatelských pžadavků Návrh řešení, zahrnující: Knceptuální návrh celéh řešení Prcesní mdel Detailní návrh celkvé lgické architektury řešení Detailní návrh celkvé fyzické/technlgické architektury řešení Detailní návrh ddávek a služeb v rámci jedntlivých subsystémů Funkční specifikace jedntlivých subsystémů Specifikace rzhraní na externí systémy Detailní návrh implementace jedntlivých kmpnent řešení Bezpečnstní dkumentace, zahrnující: Analýza bezpečnstních rizik 13

34 Dkument ppisující prcesní a technická rizika Prjektu NDK jejich závažnsti. Na tmt základě budu identifikvaná a kvantifikvaná rizika priritizvána. Pr zpracvání dkumentu bude pužita metda Threat Mdelling. Plán šetření bezpečnstních rizik Dkument vycházející ze seznamu priritizvaných rizik a ppisující způsb jak tat rizika eliminvat. V rámci testvání bude prvěřena účinnst patření. Bezpečnstní plitika a navazující pdřízené dkumenty Dkument určující bezpečnstní cíle, rganizaci bezpečnsti a rle jedntlivých sb. Návrh zálhvání a bnvy dat Akceptací výsledků či výstupů tét části plnění budu Objednatelem a Pskytvatelem dále zpřesněny a dplněny detailní parametry pskytvaných ddávek a služeb pr Prjekt NDK SI. 14

35 1.3 Specifikace realizace technické, systémvé a síťvé infrastruktury, včetně ppisu zajištění dlnsti prti výpadku, nárčnsti bsluhy a zašklení jedntlivých uživatelů a úrvně bezpečnsti a chrany digitálních dat Při návrhu technické, systémvé a síťvé infrastruktury NDK se Lgica řídila níže uvedenými pžadavky Objednatele zmíněnými v technické části dpvídajících částech Zadávací dkumentace. Při návrhu výknvých parametrů jedntlivých kmpnent architektury tét technické infrastruktury vycházela Lgica nejen ze základních pžadavků na dimenzaci řešení, ale také z pžadavků kladených na jedntlivé subsystémy a na hlavní výknvé cíle celéh Prjektu NDK. Všechny tyt pžadavky jsu navrženu technicku, systémvu a síťvu infrastrukturu splněny. Navržená technická infrastruktura tedy plně splňuje následující ptřeby Objednatele: Navržená technická, systémvá a síťvá infrastruktura tvří p technické stránce jedntný, maximálně hmgenní a plně integrvaný celek Navržená technická, systémvá a síťvá infrastruktura a její prvzní parametry splňuje pžadavky vyské bezpečnsti, dstupnsti i výknu. Infrastruktura umžňuje vertikální i hrizntální škálvatelnst pdle reálných ptřeb Objednatele, jejich pstupnéh upřesňvání a nárůstu. Navržená architektura technické, systémvé a síťvé infrastruktury tvří maximálně knslidvanu a hmgenní a hlavně plně funkční infrmační infrastrukturu 15

36 XXX Obrázek 3 - Lgické členění technlgií 16

37 1.3.1 Servervá infrastruktura XXX Servery pr SQL Cluster XXX Servery pr OCR XXX Server pr mdul Transfrmace XXX 17

38 Servery pr prstředí standardní virtualizace Prvz systémů s menšími pžadavky na výkn bude řešen prstředím virtualizace na platfrmě systémů splečnsti VMware. Řešení je kncipván s vysku dstupnstí. XXX Servery pr virtualizaci pracvních stanic XXX Externí servery XXX Servery pr FS cluster CIFS XXX 18

39 XXX Server pr TSM XXX Systémy pr ukládání dat Úlžiště pr Systém NDK XXX Rzšíření úlžiště pr uživatelské kpie Pr data, která budu genervána v rámci digitalizace v průběhu prvzvání systému pkrytém tut nabídku, bude ddána diskvá kapacita, která je určena pr ulžení nvě vzniklých uživatelských kpií. Předpkládáme, že uživatelská kpie je genervána tak, že průměrná velikst jedntlivéh subru stránky je cca 0,5MB. P ulžení předpkládanéh pčtu 26 mil. Obrazů ve frmátu uživatelské kpie. Kapacita ptřebná na ulžení uživatelských kpií za výše uvedených předpkladů je 20TB. XXX Infrastruktura SAN XXX Blade SAN XXX Externí SAN přepínače XXX Prstředí sítě LAN XXX Příslušenství, RACK Pr umístnění ddávanéh hardware navrhujeme pužít standardní skříň RACK. V tét skříni bude umístěn Blade řešení, externí servery, diskvá úlžiště, mnitr, přepínače SAN. XXX Sftware Operační systémy XXX

40 SQL Databáze XXX Virtualizace Virtualizace serverů Virtualizace serverů nabízí vyšší využití výknu serverů i vyšší dstupnst. Umžňuje dsáhnut vyské úspry nákladů a zárveň stabilnější a snáze řiditelný prvz. Změny a migrace ve virtuální infrastruktuře pak mhu prbíhat výrazně pružněji, bezpečněji s minimálními neb nulvými nárky na dstávky serverů. Prvz serverů je díky virtualizaci nezávislý na fyzickém zařízení. XXX Desktpvá virtualizace XXX Technická infrastruktura LTP Řešení LTP archivu pr NDK, jakžt jednh ze čtyř základních mdulů digitalizace NDK, je dle pžadavků Objednatele navržen tak, aby splňval pžadavky vyské bezpečnsti, dstupnsti, 25 SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA výknu, škálvatelnsti archivních svazků nejméně 400% veliksti dat v rce 2014 a také aby vyhvval ptřebám dluhdbé archivace Návrh řešení Pr archivaci dat v LTP prdukčním i testvacím systému jsme zvlili prdukt XXX, který vyhvuje nárčným pžadavkům dluhdbéh ulžení a vyskému stupni chrany digitalizvaných dat. XXX Funkční ppis archivace XXX Prdukční a testvací prstředí archivace Pr prdukční i testvací prstředí bude pužit sdílený virtuální archív, který bude dále rzdělen na dvě prstředí. Oddělení bu prstředí bude realizván na základě plitik, které zajistí různě definvatelné parametry archivace, jak jsu dba archivace, typ a umístění dat v úlžišti. Rzdělení úlžiště dat bude řešen na úrvni strage plu a t jak pr primární pl typu disk tak i pr sekundární pl i cpy pl typu páska. Znamená t, že na diskvém pli tak bude samstatný prstr pr každé prstředí a sady pásek budu sdruženy d plu, který bude dedikván pr každé prstředí. Systém LTP (klient s TSM API) nde SSAM se asciuje s plitiku pdle typu prstředí prdukční neb testvací. Na serveru můžeme mít ba ndy sučasně neb každý z nich na dedikvaném serveru.

41 XXX Ppis systému a perací s páskami Archivvaná data budu nejprve ulžena v plu typu disk. P dsažení určité hranice zaplnění neb na základě jiných pravidel definvaných plitiku budu data z tht prstru migrvána na pásky. V prvním krku budu data migrvána d primárníh plu (1. kpie), a také budu sučasně synchrnně kpírvána d prvníh cpy plu (2. kpie). Tímt bude zajištěna dstupnst dat v případě výskytu chyby na některé pásce. Dále pak pmcí naplánvané administrativní úlhy, budu data kpírvána d druhéh cpu plu (3. kpie). Dále pak budu bsahy pásek autmatizvaně v pravidelných intervalech např. 1x týdně (bude upřesněn v prváděcím prjektu) z bu cpy plů (pásky typu WORM) značeny jak ffsite a přemístěny d IO sltů knihvny. Odtud budu perátry vyjmuty z páskvé knihvny a dnášeny d fyzicky vzdálené lkality k dluhdbému uskladnění. XXX 28

42 Ppis perace s vadnu pásku V případě výskytu chyby na pásce se tat nahradí nvu neb vlnu pásku. Administrátr IA bude identifikvat jmén pásky pmcí čárvéh kódu jedné ze dvu validních kpií. Kpie pásky pak bude převezena ze vzdálené lkality. Pté ji administrátr vlží d IO sltu knihvny a spustí prces zkpírvání pásky na nvu náhradu. P sknčení tét perace bude páska vrácena pět d IO sltu. P vyjmutí z IO sltu se páska dveze zpět d fyzicky vzdálené lkality. Obrázek 10 - IO Slt páskvé knihvny Pr chranu pásky před vnějšími vlivy či před mechanickým pškzením budu pásky přenášeny ve speciálním bxu s kapacitu 20 pásek Pravidelná kntrla ffsite pásek IBM IA dispnuje prstředky pr verifikaci pásek. Verifikace prbíhá tak, že při čtení pásky jsu prvnány infrmace archivvaných datech s infrmacemi ulženými v interní databázi IA. Při tmt prcesu se zjistí případné neknzistence. V případě, že verifikace pásky dhalí nesrvnalst neb nečitelnst pásky, administrátr IA prvede náhradu pškzenéh média dle výše uvedenéh ppisu. Administrátr IA bude identifikvat pásky pdle čárvých kódů za určité bdbí (rzsah bude upřesněn). Například nejstarší pásky za dva kalendářní měsíce, které ještě nebyly verifikvány - cca 20 pásek. Takt vybrané pásky přivezené ze vzdálené lkality vlží d IO sltů. Následně administrátr spustí prces verifikace pásek a řeší případné prblémy. P sknčení kntrly administrátr IA přesune prgramvě pásky d IO sltu, pásky vyjme a tyt pět převeze zpět d vzdálené lkality Navrhvaná knfigurace ppis XXX XXX XXX

43 Zálhvání Zálhvání IA XXX Zálhvání nvě ddaných systémů XXX. Zálhvaná data budu ulžena d primárníh plu typu disk, následně deduplikvána a migrvána d úlžišť sdílené páskvé knihvny, kde se prvede replikace dat. K replikaci zálžních/archivních dat bude využívána technlgie TSM cpy strage plů. Data primárních strage plů budu replikvána d páskvých cpy strage plů jednu denně pté, c dběhnu nční zálhvací schedule. Replikace bude spuštěna administrativní úlhu TSM serveru. Evidence všech zálhvacích schedulí plánů je v režii centrálníh scheduleru plánvače TSM serveru. Vlastní spuštění úlh na klientech v sučinnsti s TSM serverem zajišťuje TSM klientský Schedule (plánvač), který je sučástí instalace TSM BA klienta Zálhvané entity infrastruktury Operační systémy Zálhvání peračních systémů je prváděn nativními prstředky příslušnéh OS. Zálhu OS Windws systému má na starsti klientský SW (TSM Backup Archive klient), který za pmci VSS služeb vytvří braz systémvéh disku (image backup) a ten následně ulží d TSM Subrvé zálhy Zálhvání bude zajišťvat TSM Backup Archive klient sftware určený pr zálhvání a bnvu subrvých dat. Zálhvání bude prbíhat denně metdu inkrementálních zálh (technlgie Incremental Frever). Zálhvány budu všechna data, vyjma těch, které jsu vyspecifikvány v Exclude listech. D denní inkrementální zálhy nebudu zahrnuty datvé subry databází, které se zálhují speciálním SW TSM fr Databases Databázvá data včetně archivních lgů Zálhvání kmpnent systému MS SWL bude částečně pkryt zálhu subrvých systémů (perační systém, binární subry, knfigurační subry) a částečně zálhu databáze MS SQL. Kmbinací těcht zálh bude zajištěna kmpletní či částečná bnvitelnst systémů v případě ztráty či pškzení dat. K zálhvání databází bude využíván sftware TSM fr Databases (MS SQL), který pskytuje nástrj pr přímu zálhu d úlžišť TSM serveru Ppis prduktu TSM server Základní sftwarvu kmpnentu TSM serveru je vestavěná relační databáze. Veškeré definvané plitiky, lgvání, autentizace, správa médií a bjektů je řízena tut databází. Pr ukládání zálhvaných dat TSM pužívá strage repsitry. Tím se rzumí jakákli kmbinace diskvých, 33

44 ptických neb páskvých zařízení, které jsu lkálně (ppř. přes SAN) připjeny k TSM serveru. V rámci strage repsitry mhu zařízení pervat samstatně, neb mhu být spjeny dhrmady a tvřit tak jednu neb více strage hierarchií. Specifikace: Filsfie snadné zálhy a rychlé bnvy s využitím funkcinality "Prgressive Incremental Backup" (stálá rzdílvá zálha). Plně autmatizvané řešení nezávislé na hardwaru, typu peračních systémů neb nline zálhvaných aplikací. Centrální výknná vnitřní databáze pr jakukliv knfiguraci veliksti zálhvacíh řešení. Server i klienti nabízejí tři administrátrská rzhraní - Web, GUI neb příkazvu řádku. TSM je plně integrvatelný s mnitrvacím řešením Tivli Mnitring pr real-time mnitring a histrický reprting. Vyská variabilnst živtnsti zálh a archivů v úlžištích (disk, ptická média, páskvá média). Mžnst nastavení řešení pr 7 vrstev Disaster Recvery (definvané mezinárdní skupinu SHARE) Prvázanst s IBM Tivli mnitringem, zahrnut v základní licenci. Mžnst diagnstickéh sledvání zálhvacíh řešení v reálném čase, mžnst vytváření histrických phledů včetně trendů. Pkrčilá diagnstika a reprting backup prcesů. Prvádí výknnstní a rzšiřitelné zálhvání a bnvu, které minimalizují síťvý prvz a zajišťují účinné a plánvané přensy dat, a pskytuje funkce pr sledvání externích úlžišť. Využívá funkce dstraňvání duplicit a hierarchizaci ukládání dat ke zvýšení účinnsti a k úspře prstředků Ppis TSM Backup archive klient TSM je sftware pracující na bázi klient-server. Klientská část (B/A klient), která musí být instalvána na každé pracvní stanici, kteru pžadujeme zálhvat, služí ke kmunikaci klienta a TSM serveru. Pdbně jak server se klient skládá z prgramvé části a z knfiguračních subrů. Mezi hlavní výhdy patří: Efektivní zálhvání různrdých peračních systémů, filesystémvých dat nezávislé na pužitém hardware. Jednduchý management a autmatizace zálhvacích perací Snadné využití funkcinalit jedntlivých peračních systémů jak Windws ASR, VSS neb technlgií diskvých plí jaku je Snapsht. Mžnst úpravy, ptimalizace binárníh kódu klienta, aby vyhvěl nadstandardním pžadavkům zákazníka. 34

45 Ppis Tivli data prtectin fr Databases (MS SQL) TDP pr MS SQL Server je kmplexní zálhvací prdukt, který umžňuje nline zálhu, bnvu Micrsft SQL databází s využitím úlžišť TSM serveru. Mezi hlavní výhdy patří: Efektivní zálhvání databázvých dat bez mezení funkčnsti aplikace. Rychlý a snadný backup a restre, který nevyžaduje žádné mezikrky, cž značně přispívá k chraně důležitých dat a snižuje dbu zálhy i bnvy Ppis Tivli data prtectin fr SAN Strage agent ve spjení s TSM serverem umžňuje implementvat LAN-free backup s využitím SAN infrastruktury. Vhdný je zejména pr bjemné zálhy, které směřují přím na páskvé úlžiště Ppis Tivli data prtectin fr virtual envirnment Využívá VMware s vstrage APIs fr Data Prtectin, včetně blck-level incremental zálhvání zalženém na VMware Change Blck Tracking. Přesuvá zátěž spjenu se zálhváním z virtuálních strjů a prdukčních ESX hstu na vstrage backup server. Pskytuje flexibilní mžnsti bnvy file, vlume neb image. Autmatizuje discvery nvých virtuálních strjů a autmaticky aplikuje pravidla pr zálhvání Navrhvané umístění HW infrastruktury Celé ddávané řešení infrastruktury serverů, LAN, SAN a LTP IBM IA navrhujeme splečně umístit d lkality Depzitáře NK Hstivař - Datvé centrum H02. Následující brázek reprezentuje předpkládané fyzické umístění skříní RACK. XXX 35

46 Hmtnstní a příknvá analýza XXX Ddávaná prstředí Prdukční prstředí Prdukční prstředí systému se skládá z následujících kmpnent: Skenery a skenvací pracviště lkality Brn a Praha Hstivař Pracvní stanice celkem 51 stanic, které mhu být rzmístěny dle ptřeby Objednatele Datvé centrum kncentruje veškeru kapacitu jak úlžiště, tak výpčetní. Kmpnenty datvéh centra pr Systém NDK jsu umístěny v datvém centru Hstivař. Datvé centrum zahrnuje veškerý HW a SW prvzvaný centrálně (Wrkflw, LTP, Subsystém zpřístupnění) Ulžení ff-line zálh pásek ve dvu lkalitách rzdílných d primární lkality datvéh centra budu ulženy pásky bsahující zálhy dat LTP Celý systém zajišťuje bezpečnst řešení (využívání bezpečných prtklů HTTPS apd., bezpdmínečná autentizace všech uživatelů i systémů navzájem). Dstatečný výkn systému je zajištěn využitím nejmdernějších serverů a řešení pr úlžiště. Zárveň je mžné systém výknvě 36

47 škálvat prstým přidáváním výpčetních uzlů (transfrmační mdul a OCR) a ddáváním diskvé a páskvé kapacity d infrastruktury úlžišť. Pr lkalitu Brn nepředpkládáme instalaci servervých kmpnent. Puze bude instalván ddatečný aktivní síťvý prvek pr připjení nvých pracvních stanic a skenerů. XXX Testvací prstředí Obrázek 15 - Schéma prdukčníh prstředí Pr testvání bude v rámci systémů v datvém centru vytvřen testvací prstředí, kde bude naknfigurvána lgicky stejná architektura jak v prdukčním prstředí. Pr vytvřené testvací prstředí budu vyhrazeny: Dva fyzické blade servery jak hstitelské pr virtualizvané testvací prstředí Prstr na úlžišti Prstr v LTP úlžišti veliksti 10TB bez dalších mezení 37 SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA

48 Zálhvání napájení Praha-Hstivař XXX Silvý rzvaděč RUPS bude instalván v datvém centru v blízksti zdrje UPS. Z výstupu UPS bude napájena zálhvaná sběrnice a z ní bude napájena knfigurace IT HW umístěná ve čtyřech servervých skříních (racích), jedna ze skříní bude bez napájení. D každé skříně budu přivedeny dva silvé kruhy s příslušnu dimenzí kabelu a typem průmyslvé zásuvky, zpravidla IEC 309. D nich pak budu zapjeny napájecí lišty PDU, které budu instalvány ve skříních a nejsu sučástí tét nabídky. Z rzvaděče RUPS bude vyveden kabel pr napájení rzvaděče RSD, který bude umístěn v místnsti skenerů neb na chdbě v její blízksti. Z tht rzvaděče budu napájeny veškeré skenery instalvané v tét místnsti. Silvé kruhy s patřičnými dimenzemi kabelů a jištěním budu přivedeny d blízksti skenerů a zaknčeny zásuvku dpvídající typu skeneru. Pčty silvých kruhů jsu zřejmé ze zjedndušenéh schématu: Napájení IT: XXX Ve výknu zdrje UPS je již zapčítána rezerva 50% dle Zadávací dkumentace. Pkud by měl být zálhván puze IT HW, pstačil by výkn zdrje UPS 30kVA. Předpkládáme, že pracvní stanice se dvěma mnitry a připjeným skenerem budu napájeny lkálním zdrjem UPS, který není sučástí naší nabídky, nebť čekáváme, že bude sučástí ddávky ddavatele pracvních stanic. Hlavní plžky ddávky: XXX MZK Brn XXX Manuální bypass bude realizván v silvém rzvaděči RUPS viz nástin zapjení. Předpkládáme, že vývd/jistící prvek pr připjení zdrje UPS bude připraven ve stávajícím rzvaděči a rvněž bude k dispzici zařízení na měření dběru elektrické energie. 40

49 XXX Silvý rzvaděč RUPS bude instalván v datvém centru v blízksti zdrje UPS. Z výstupu UPS bude napájena zálhvaná sběrnice a z ní bude mžné v buducnsti napájet zařízení instalvaná v datvém centru. V tét fázi bude připraven rzvaděč s jističi, ale nebudu realizvány silvé kruhy z důvdu mezení investičních nákladů. Z rzvaděče RUPS bude vyveden kabel pr napájení stávajícíh rzvaděče na chdbě S137 před místnstí č. S140. Z tht rzvaděče budu napájeny veškeré skenery instalvané v místnsti č Silvé kruhy s patřičnými dimenzemi kabelů a jištěním budu přivedeny d blízksti skenerů a zaknčeny zásuvku dpvídající typu skeneru. Pčty silvých kruhů jsu zřejmé ze zjedndušenéh schématu: XXX Dále bude připraven napájení pr venkvní klimatizační jedntky (prpjení mezi venkvními a vnitřními jedntkami bude prveden při samtné instalaci chlazení a je zapčítán v ceně - jedná se verzi split jedntek). 41

50 XXX Ve výknu zdrje UPS je již zapčítána rezerva 50% dle Zadávací dkumentace. Předpkládáme, že pracvní stanice se dvěma mnitry a připjeným skenerem budu napájeny lkálním zdrjem UPS, který není sučástí naší nabídky, nebť čekáváme, že bude sučástí ddávky ddavatele pracvních stanic. Hlavní plžky ddávky: XXX SMLOUVA O POSKYTOVÁNÍ SLUŽEB SYSTÉMOVÉHO INTEGRÁTORA 42 XXX Chlazení Praha Hstivař Nvě instalvaný HW d datvéh centra si vyžádá navýšení chladící kapacity 8kW, která již v sbě také zahrnuje zmiňvanu rezervu 50%. Byla vybrána jedntka max. chladícím výknu 10kW. Jedná se venkvní jedntku XXX. Pkud budeme uvažvat redundanci řešení, je nutné vzít v úvahu, že v datvém centru je vlná kapacita chlazení cca 9,8kW. Tut kapacitu by byl pkryt jak výpadek jedné ze stávajících klimatizací, tak výpadek navrhvané klimatizační jedntky. D datvéh centra tedy navrhujeme na dplnění chladící kapacity puze jednu jedntku. V místnsti se skenery by se měly pužít klimatizační jedntky celkvém chladícím výknu 11kW. I v tét hdntě je pčítán s rezervu 50%. Pr zvýšení splehlivsti a dstupnsti chlazení navrhujeme jedntky v redundanci 1+1 max. chladícím výknu 12,3kW. Navrhujeme venkvní XXX XXXX XXX XXX. Vzhledem k tmu, že neznáme přesné dispzice bjektu v Praze Hstivaři, vytvřili jsme cenvu kalkulaci za předpkladu, že ptrubí mezi venkvními a vnitřními jedntkami nepřesáhne délku 20m. XXX 43

51 XXX Začlenění d mnitringu APC Infrastruxure Central Předpkládáme, že zdrj UPS APC Galaxy bude připjen přes SNMP adaptér, který je standardní výbavu, d Objednatelvy sítě. Splupráce s APC Infrastruxure Central je nativní vlastnstí tht adaptéru. Klimatizační jedntky jsu schpny předat signál pruše, který bude mci Infrastruxure Central zpracvat prstřednictvím adaptéru typu kntakt MZK Brn Chlazení je navržen dle prjektu, který je sučástí Zadávací dkumentace, prtže lze předpkládat, že Objednatel bude chtít řešit chlazení nvéh datvéh centra na jedné straně a na straně druhé není na základě bdržených dpvědí na dtazy účastníků výběrvéh řízení zcela jasné, jak k prblematice chlazení DC přistupit v případě, že řešení nepředpkládá umístění nabízenéh HW d tht DC, prtže je uveden, že alternativy výběrvé řízení nepřipuští. Avšak dvě venkvní kndenzační jedntky jsu nutné kvůli chlazení skenerů, které je pvinné, jak jsme také pchpili z bdržených dpvědí. Dvě jedntky jsu navrženy z důvdu redundance (1+1). Tt řešení je zvlen také z důvdu příliš dluhé trasy pr trubky veducích d venkvních jedntek a pr příliš velké převýšení vnitřních a venkvních jedntek. 44

52 Pkud bude rzhdnut nechladit DC, lze dečíst 12 vnitřních jedntek z cenvé kalkulace. V rámci hledání rezerv jsme tyt jedntky z kalkulace vypustili a pnechali v DC dvě jedntky pr chlazení zdrje UPS a dvě jedntky v místnsti skenerů verze kndenzačních jedntek. Ještě jsme přidali variantu chlazení v MZK Brn puze s dvěma dvjicemi split jedntek, jednu pr DC a jednu pr místnst skenerů. Výkn venkvních jedntek je ddržen ve shdě s prjektem, vnitřní jedntky v místnsti skenerů mají prti prjektu výkn vyšší. V místnsti se skenery by se měly pužít klimatizační jedntky celkvém chladícím výknu 11kW. I v tét hdntě je pčítán s rezervu 50%. Z důvdu přiblížení se k pžadavkům prjektu chlazení, navrhujeme chlazení jedntkami v redundanci 1+1 max. chladícím výknu 7,1kW. Hlavní plžky ddávky verze split jedntky: Ppis Mnžství XXX Přehled ddávaných kmpnent Servery a suvisející infrastruktura XXX Úlžiště a LTP XXX 50

53 Licence p zadání XXX

54 Síťvá infrastruktura XXX Systémvý SW XXX 1.4 Specifikace realizace subsystému digitalizace Subsystém digitalizace je, vzhledem k hdntícímu kritériu celéh Prjektu NDK, kterým je pčet digitalizvaných stran, klíčvu sučástí celéh systému, na které závisí úspěch či neúspěch Prjektu NDK. Zajišťuje převd fyzických předlh d jejich digitální pdby a jejich přípravu pr transfrmaci, 52

55 dluhdbé ulžení a prezentaci. Cílem digitalizace je připravit pdmínky pr dluhdbé uchvání brazů riginálních publikací a jiných listinných pramenů v digitální frmě jak AIP. Celý prces je řízen prstřednictvím Wrkflw Prces digitalizace bsahuje jak fyzický tk materiálu, tak samzřejmě přizvání, úpravu dat a jejich přesun v infrastruktuře až d kamžiku ulžení. Fyzické přesuny znamenají přesun předlh z depzitáře na digitalizační pracviště, jejich manipulaci na pracvišti a následné vrácení zpracvaných knih zpět na půvdní pzice ve skladech. Přesuny mezi jedntlivými kmpnentami infrastruktury jsu fázemi zpracvání přízených dat, pstupnéh bhacvání a dplňvání metadat. Digitální brazy budu vytvářeny na digitalizačních zařízeních (skenerech) jejichž vlastnsti plně dpvídají pžadavkům definvaným v Zadávací dkumentaci. Úklem navrhvanéh řešení je vytvření intelektuální entity dpvídající knkrétní předlze. U mngrafií tak vzniká entita na úrvni svazku. Jedná-li se vícesvazkvu publikaci, pak jsu vzájemné vazby ppsány v metadatech, jejichž mnžina vzniká během zpracvání. Obdbně u svázaných peridik jsu intelektuální entitu jedntlivá čísla a přiřazená d knkrétníh rčníku. Vytvářením entit ve frmátu vhdném pr ulžení v LTP prjdu také předlhy, které jsu již v digitální pdbě a budu čerpány z externích zdrjů (Manuscriptrium, WebArchiv, Kramerius). Data z těcht zdrjů budu zpracvávána Transfrmačním mdulem (viz kapitla 1.6). Zpracvání knčí vytvřením PSP deslaným d Transfrmačníh mdulu, který vytvří SIP 1 a 2, které jsu ukládány d LTP a d aplikace Kramerius. V dalším textu je ppsána struktura ddávaných kmpnent Subsystému digitalizace a ppis prcesu digitalizace Struktura ddávky S cílem ddat vybavení digitalizačních pracvišť pr NK a MZK bude mít ddávka následující části: a) Digitalizační zařízení skenery v pčtech a struktuře vyžadvané Zadávací dkumentací. Každý ze skenerů je vybaven čtečku čárvých kódů, stanicí resp. serverem (v závislsti na typu) b) Sftware pr imprtně exprtní funkce umžňující minimálně následující: a. imprtvat bibligrafické záznamy digitalizvaných dkumentů ve frmátech MARC 21, MARC XML b. imprtvat ppisná metadata ve frmátech MODS aktuální verze neb verze předchzí, DublinCre, MARC XML, strukturální metadata ve frmátu XML c. imprtvat brazvé subry vytvřené na skenerech v běžných frmátech (min. TIFF, JPEG2000, JPEG, PNG) d. imprtvat textvé subry ve frmátu TXT a subry ve frmátu ALTO XML e. imprtvat čárvé kódy (identifikace jedntlivých svazků) f. imprtvat digitalizvané dkumenty neb jejich části (pr pravy, editace apd.) g. imprtvat digitální dkumenty p knverzi 53

56 h. exprtvat digitalizvané dkumenty v předepsané struktuře dle přílhy Definice SIP/PSP pr digitalizaci v rámci NDK IOP i. exprtvat dkumenty neb jejich části (data a metadata) v různém stadiu zpracvání j. exprtvat výstup pdle vlastní knfigurace c) Sftware pr zpracvání brazvých dat (imageprcessing) umžňující minimálně následující a. prvádět řez (uvnitř a vně kraje dkumentu), narvnání (pdle řádků textu), ptlačení šumu a pzadí ve frmátu TIFF a ulžení ve frmátu JPEG2000 bez kmprese neb s bezeztrátvu kmpresí (preservatin master), dle specifikace pr LTP a se ztrátvu kmpresí dle specifikace pr Kramerius 4, aplikace bude schpna prvnat shdu archivních subrů ve frmátu TIFF a JPEG2000 b. bude mžné specifikvat parametry příkazu pr knverzi d JPEG2000 včetně vlby kdeku (knihvny, např. Kakadu) c. prvádět knverze z frmátu TIFF d JPEG2000, JPEG d. vytvářet kntrlní sučty pr každý subr při ulžení e. kntrlvat kvalitu brazvých subrů f. parametrizvat, že brazvé subry budu bsahvat 1 stranu dkumentu g. spjvat dva brázky d jednh subru (mapy, tabulky apd.) h. snímkvat velké předlhy p sekcích a kmpletvat je (stitching) i. skenvat všechny strany dkumentu včetně neptištěných d) Aplikace pr přípravu a plánvání digitalizace umžňující minimálně následující: a. prvádět výběr a vyžádání dkumentu pr digitalizaci b. zařadit tent dkument d digitalizačníh plánu c. prvede základní přípravné perace včetně přiřazení dkumentu ke knkrétním skenerům d. výběr dkumentů z dstupných zdrjů e. sledvat lhůty ddání dkumentů pr digitalizaci f. prvádět varvná hlášení při neddání dkumentů g. vytvářet dílčí a celkvé reprty pr řízení prcesu a pracvišť e) Aplikace pr OCR umžňující minimálně následující: a. vytvářet z brazvých subrů bsahující tištěné texty fulltext ve frmátech ALTO XML dle Zadávací dkumentace b. z výše uvedenéh výslednéh frmátu ihned neb ddatečně genervat subry ve frmátu TXT a dvuvrstvé PDF (hrní viditelná vrstva brázek, spdní text) 54

57 c. autmatické vyhdncvání úspěšnsti OCR d. využívat externí slvníky a sady starších fntů vytvřených v rámci vývjvých prjektů v ČR e. implementvat vybrané nástrje evrpskéh prjektu IMPACT a dalších prjektů výzkumu a vývje f) Systém pr management a sledvání prcesu digitalizace - v rámci celplšnéh systému, který bude zajišťvat management a sledvání všech prcesů a mnitring systému jak takvéh, budu v subsystému digitalizace evidvány minimálně následující typy perací: a. tky dkumentů b. plnění závazných indikátrů c. sledvání výknů V průběhu celéh pracvníh prcesu (příprava dkumentů, skenvání, zpracvání a editace metadat) budu dkumenty evidvány na jedntlivé perátry. Každý perátr si bude přebírat dkumenty ke zpracvání načtením čárvéh kódu na knize na vlastní knt. Pr každý typ zpracvání bude mžné nastavit časvý limit, d kteréh bude třeba knihu předat k dalšímu zpracvání, neb vrátit prstřednictvím knihvníh systému. P uplynutí časvéh limitu budu frmu lgu vypsány nevrácené dkumenty a upzrněn příslušný perátr a jeh veducí. Systém pr management a sledvání prcesu digitalizace dále umžní minimálně následující: d. evidenci zhtvených brazvých subrů, digitalizvaných stran, digitalizvaných svazků dle předem definvaných časvých intervalů e. sledvání pracvních výknů pdle skenerů, pracvních stanic a perátrů dle předem definvaných časvých intervalů f. v případě neplnění přednastavených hdnt bude zbrazvat varvné lgy g. zajistí definvání prjektů a bude schpen přiřadit perátry specifickým úklům neb prjektům a fázím h. sledvání všech zpětných lgů pr případné mžné realkvání zdrjů v různých fázích neb prjektech i. prvádět změny v následnsti fází, akceptvání již částečně vytvřených dkumentů na externím pracvišti a zahájit fázi uvnitř Wrkflw prezentvat získaná data frmu tabulek a grafů g) Šklení bslužnéh persnálu dsažení cíle zpracvat 26 mil. stran předlh je závislý na výknu technlgie a vycvičensti bsluhy a rganizaci práce. Kapacita technlgie je nezpchybnitelná a prvěřená. Limitujícím faktrem je v případě hrmadné digitalizace výknnst bsluhy. Splečnst Lgica na základě svých zkušenstí dpručuje vyšklit skupinu tzv. klíčvých uživatelů, kteří budu představvat základnu expertýzy pr zbytek zaměstnanců zapjených d digitalizace. Vzhledem k předpkládanému pčtu bsluhy zahrnující perátry skenerů, pracvníky pr úpravu brazů (grafik) a bsluhu pracviště přípravy předlh a směnnsti je předpkládaný pčet klíčvých zaměstnanců dhadnut na max. 30 pracvníků. P vyšklení a zapracvání budu klíčví uživatelé využiti jak interní 55

58 trenéři statních pracvníků. Klíčví uživatelé budu rzděleni d tří skupin (max. 10) a budu prcházet škleními na jedntlivých zařízeních a aplikacích. Pžadavky na pracvníky v rli klíčvéh uživatele: - Předchzí praxe ze stávajících digitalizačních pracvišť - Pčítačvá gramtnst na úrvni pkrčiléh uživatele - Min. pasivní znalst anglickéh jazyka Před zařazením d skupiny klíčvých uživatelů bude nutné věřit kvalifikaci frekventantů šklení. Tent krk je nezbytný pr dstranění rizika zpždění prjektu z důvdu uživatelských chyb. Každá skupina prjde následujícím šklícím cyklem: I. Prces digitalizace a jeh řízení (Plánvací mdul a Wrkflw) 4 hdiny II. Práce s aplikacemi (pstprcessing, OCR, Editační mdul, transfrmační mdul) 8 hdin III. Obsluha rbtických skenerů 8 hdin Kurzy jsu řazeny takt z důvdu, aby je byl mžné uspřádat nezávisle na ddávce a instalaci rbtů. Harmngram šklení bude sučástí prváděcíh prjektu a bude stanven na základě zhdncení dstupnsti vhdných uchazečů pr rli klíčvéh uživatele. h) Šklící materiály bsahující ppis jedntlivých perací a činnstí při digitalizaci i) Plné uživatelské manuály/příručky ke všem hardwarvým a sftwarvým řešením digitalizačníh pracviště. Sučástí těcht dkumentů bude i specifikace prduktu s jeh ptimálním nastavením a uživatelská příručka ve vztahu k servisním pdmínkám a maintenance V dkumentaci pr aplikaci Wrkflw bude rvněž uveden ppis prcesů a subprcesů včetně jejich nutné sekvence neb paralelizace. j) Šklení administrátrů (2) k) Administrátrské příručky Subsystém digitalizace ve splupráci s Wrkflw umžní dále minimálně následující: a) v různých krcích prcesu digitalizace patřvat dkumenty všemi pžadvanými metadaty (ppisná metadata, strukturální metadata a technická a administrativní metadata) pžadvanými a definvanými Zadávací dkumentaci. b) splupracvat s dalšími systémy (knihvní systém Aleph, Registr digitalizace, Kramerius, LTP a Reslver URN:NBN). Pr manipulaci se záznamy, digitálními daty a knižními svazky budu využívány identifikátry definvané v Zadávací dkumentaci c) předávat sestavy metadat a subrů vztahujících se k jedntlivým digitalizvaným svazkům frmu kntejnervéh frmátu METS 1.9 definvaný v Zadávací dkumentaci d) vytvářet identifikátry pr skenery, pracvní stanice a perátry e) prvádět kntrlu knzistence f) přebírat úkly mezi lkalitami (Praha, NKČR a Brn, MZK) g) zhtvené uživatelské kpie dkumentů vzájemně replikvat mezi systémy NKČR a MZK 56

59 1.4.2 Řízení digitalizace Celý prces digitalizace je řízen prstřednictvím Wrkflw (blíže ppsané v kapitle 2.3.1), prstřednictvím kteréh je mžné sledvat stav zpracvání předlh a které služí jak rzhraní pr řízení manuálních perací s předlhami. Zárveň jsu d něj prmítány změny stavu předlh, které nastávají jak výsledek autmatickéh zpracvání. Wrkflw umžňuje spuštění jak celéh prcesu, tak autnmní spuštění jedntlivých krků neb jejich vynechání. Rvněž tak zaznamenává prvzní pruchy a vyvlává ptřebu náhradníh pstupu. V celém průběhu prcesu digitalizace je mžné prvádět validace struktury pracvníh adresáře a úpravy dat pmcí Editačníh mdulu. Manuální úpravy pmcí Editačníh mdulu budu dstupné zejména při dplňvání metadat, vytváření entit a řešení chybvých stavů. Editační mdul je ppsán v kapitle Pdpra plánvání digitalizace Žádný prjekt rzsahu srvnatelnéh s Prjektem NDK se v dnešní dbě nebejde bez kvalitníh plánvání prací a kapacit. P uvedení technické infrastruktury d prvzu se těžištěm prjektu stane samtná digitalizace dkumentů. Jde fázi prjektu rganizačně neméně slžitu než budvání technickéh zázemí. Cílvý bjem digitalizvaných dat je značný a mají-li být ddrženy zadané termíny, je třeba využívat kapacity pracvišť c mžná nejefektivněji. Pr tyt účely vyvine Pskytvatel v rámci Subsystému digitalizace Aplikaci pr pdpru plánvání digitalizace. Jejím účelem je zajistit plynulu a rvnměrnu ddávku vhdných dkumentů na digitalizační linky tak, aby byla plně využívána kapacita instalvaných zařízení a byla tak ddržena prdukce dstatečná pr splnění cílů Prjektu NDK Kncept plánvání Aby byl maximálně využit kapacit skenvacích zařízení, je třeba umžnit jejich nepřetržité zásbvání prací, nebli zajistit dpvídající ddávku dkumentů určených k digitalizaci. Aplikace pr pdpru plánvání k tmut účelu využívá kapacity meziskladů jak zásbníku pr samtný prces digitalizace. Z phledu plánvání je navrhvaný cyklus digitalizvanéh dkumentu v systému následující: Aplikace přijímá pžadavky na digitalizaci v pdbě seznamu děl. Přijaté pžadavky jsu validvány a infrmace dkumentech jsu ulženy ve Wrkflw a dplněny základní data z dalších interních či externích zdrjů (Aleph, RD). Peridicky neb na vyžádání bsluhy je mžné vygenervat seznam pžadavků na ddávku dkumentů na digitalizační pracviště, na jehž základě jsu fyzické dkumenty pstupně ddávány z depzitářů d meziskladů, kde si je přebírají pracvníci digitalizačních linek a dále je zpracvávají. P úspěšném zpracvání naskenvaných brazů jsu fyzické dkumenty devzdány zpět d půvdníh umístění. Plánvání jedntlivých dkumentů P úspěšném přijetí seznamu pžadavků na digitalizaci jsu infrmace dkumentech zaznamenány ve Wrkflw a následně bhaceny ppisné infrmace z externích zdrjů. T umžňuje dkumenty 57

60 rzdělit d kategrií dle typu dkumentu (stáří, rzměry apd.). Dkumenty jsu následně zařazeny d frnty dkumentů připravených k digitalizaci. Pr plynulu digitalizaci je ptřebné udržvat v meziskladech digitalizačních pracvišť dstatečnu zásbu vhdných dkumentů. Aplikace je úzce prpjena s Wrkflw a jeh prstřednictvím kntrluje aktuální naplnění meziskladů a v případě vlné kapacity generuje pžadavek na ddání dstatečnéh pčtu čekajících děl z jedntlivých kategrií. Sučástí tht pžadavku může být jmenný seznam vhdných dkumentů. Celkvá pžadvaná úrveň naplnění meziskladu dpvídá sučtu denních kapacit jedntlivých zařízení na daném pracvišti násbenému určitým keficientem (předpkládá se naplnění skladu v řádu jedntek dnů denní prdukce). Bude pčítána pr jedntlivé kategrie dkumentů na základě mžnstí a schpnstí knkrétních zařízení/skenerů na pracvišti. V případě, že zařízení je schpn zpracvávat více kategrií dkumentů, bude jeh kapacita rzdělena mezi kategrie v pměru dpvídajícím pčtu dkumentů v příslušných kategriích čekajících ve frntě na digitalizaci. Vlná kapacita meziskladu bude stanvena jak rzdíl pžadvané úrvně jeh naplnění a jeh aktuálníh využití. O přadí, v jakém budu knkrétní fyzické dkumenty ddávány d meziskladu, budu rzhdvat pracvníci NDK na základě svéh uvážení/preferencí. Systém bude pskytvat indikativní infrmace využití kapacit zařízení a vydávat dpručení vhdné skladbě ddávek tak, aby byl využití kapacit ptimální. Obdbně budu rzhdvat pracvníci digitalizační linky přadí a vhdné vlbě skenerů pr digitalizaci dkumentů již připravených v meziskladu. Systém bude mít samregulační efekt. Nebudeli v dstatečné míře dcházet k digitalizaci určité kategrie dkumentu (např. z důvdů dstávky vhdnéh skeneru), přestane mdul genervat pžadavky na ddávku příslušných dkumentů d meziskladu. Napak při vyšší výknnsti zařízení budu pžadavky na ddávku vhdných dkumentů frekventvanější. Zárveň bude takt zajištěna určitá tlerance vůči dchylkám nminální kapacity zařízení d reálných mžnstí fakticky bude vlivněna puze dba, p kteru je mezisklad schpen ddávat dkumenty k digitalizaci bez přísunu nvých zásb. Využití pracviště samtnéh je neustále maximální. Pr případ, kdy by celkvá kapacita digitalizační linky byla dluhdbě nižší než sučet kapacit jedntlivých zařízení (např. z důvdů zdluhavéh OCR), bude systém umžňvat regulvání pžadvané úrvně naplnění meziskladu určitým redukčním keficientem. Zamezí se tak např. zaplnění kapacity pracvníh datvéh úlžiště. Uvlnění dkumentu z meziskladu je řízen infrmací z Wrkflw a nastává ve chvíli, kdy se dkument dstane d stavu zpracvání, kdy již nemůže být pžadván dskenvání. 58

61 Pžadavky na digitalizaci Aplikace plánvání Knihvník Depzitář Pžadavky na ddávku Objekty k Stav digitalizace Mezisklad digitalizaci Metadata dkumentů Stav A B C Úkly Obsluha digitalizační linky Extenrí zdrje (Aleph, RD, URN Reslver) WF Úkly Stav Obsluha digitalizační linkyskener 1 Skener 2 Skener 3 Úkl y Stav Zpracvání brazů Obsluha digitalizační linky Legenda: Dkumenty LTP Data Infrmace Obrázek 20 - Zjedndušené schéma plánvání Interní prjekty Aplikace pr pdpru plánvání bude umžňvat seskupvat digitalizvané dkumenty d ucelených lgických celků. T usnadní dhled nad pstupem digitalizace a umžní smysluplnu priritizaci ddávek na digitalizační pracviště. Pr tyt účely bude mžné v grafickém rzhrání aplikace definvat interní prjekty a jejich atributy. Pd interním prjektem si je mžné představit např. subr peridik první plviny 19. Stletí apd. Základními atributy prjektu budu: Název interníh prjektu Kód prjektu Ppis prjektu 59