Vymezení předmětu plnění
Vymezení předmětu plnění
1. Předmět plnění
(1) Předmětem plnění veřejné zakázky jsou dodávky včetně služeb (dále také jen „řešení“) – pro vybudování informačního systému pro jednotnou evidenci nemovitého majetku a jeho stavu, tzn. systém pro pasportizaci nemovitého majetku (dále také jen „systém“ nebo „pasportizační systém“). Součástí plnění je dále podpora provozu na dobu 60 měsíců po předání řešení do ostrého provozu. ěešení musí být navrženo tak, aby náklady na provoz systému byly co nejmenší.
(2) Předmětem plnění veřejné zakázky jsou zařízení a systémy uvedené v následující tabulce, včetně služeb (komodity).
Označení | Název | Počet |
K1 | Evidence majetku | 1 |
K2 | Technicko pasportizační evidence | 1 |
K3 | Mobilní aplikace | 1 |
K4 | Business Inteligence | 1 |
K5 | Datový sklad | 1 |
K6 | Integrační platforma | 1 |
2. Popis současného stavu
2.1. Popis organizace a její členění
(1) Organizace Magistrát města Karlovy Vary (dále MMKV) sídlí ve 2 administrativních budovách, kde pracuje většina zaměstnanců a je zde umístěná převážná část IT technologií. Organizace je zřizovatelem organizací v oblasti dopravy, kultury, správy majetku, školství, sociální a zdravotní.
(2) Další organizace jsou umístěny na území města, aktuální adresy jsou uvedeny na webových stránkách xxxxx://xxxx.xx/xx/xxxxxxx-xxxxxxxxxx.
2.2. Popis lokalit
(1) Z pohledu IT jsou pro MMKV nejvýznamnějšími lokalitami budova Moskevská 2035/21, 361 20 Karlovy Vary a budova X Xxxxxxxxxx 000/0, 000 00 Xxxxxxx Xxxx. V těchto lokalitách jsou umístěny ICT technologie. Projekt bude realizován v obou lokalitách.
(2) Projekt bude dále realizován na adresách těchto organizací, jedná se společnosti
s majetkovou účastí města:
Organizace |
Statutární město Karlovy Vary |
Alžbětiny Lázně, a.s. |
Balneologický institut Karlovy Vary, o.p.s. |
Dopravní podnik Karlovy Vary, a.s. |
HVĚZDÁRNA a RADIOKLUB LÁZEŇSKÉHO MĚSTA KARLOVY VARY o.p.s. |
INFOCENTRUM MĚSTA Karlovy Vary, o. p. s. |
JOCKEY PARK Karlovy Vary, a.s. |
Karlovarská městská, a.s. |
Karlovarská teplárenská, a.s. |
Karlovarské městské divadlo, o.p.s. |
Komunální odpadová společnost, a.s. |
KV Arena, s.r.o. |
KV CITY CENTRUM, s.r.o |
Lázně Kyselka, o.p.s. |
Městská galerie Karlovy Vary, s.r.o. |
Nadace FILM-FESTIVAL KARLOVY VARY |
Nadace města Karlovy Vary, o.p.s. |
Zámecká kolonáda a.s. |
2.3. Popis stávajícího HW prostředí
(1) Technologické centrum ORP (dále TC ORP nebo TC) je infrastrukturním základem pro poskytování IT služeb. Cílem je zajištění co nejlepších podmínek provozu informačních systémů v režimu 5×12. V současné době je Technologické centrum situováno v lokalitě Moskevská.
(2) Technologické centrum bylo vybudováno z původní serverovny úřadu v roce 2012 v rámci Výzvy 06 IROP, dále rozšířeno v rámci Výzvy 09, kdy byly vybudován i softwarové platformy pro správu dokumentů, identit a archivaci. V roce 2014 prošlo TC zatím poslední modernizací – doplněním síťových firewallů, konsolidací zálohování, modernizací groupware a systému řízení tisku a zavedením provozního monitoringu.
(3) Hlavní serverová infrastruktura je tvořena 2 ks HP Blade šasi. Šasi jsou osazena devíti kusy dvouprocesorových Blade serverů BL460 G7 a G8. Pro řízení zálohování a další pomocné úlohy slouží samostatný fyzický server HP DL380 G8.
(4) SAN infrastruktura je tvořena optickými SAN přepínači – 2 kusy v každém HP Blade šasi a 2 kusy HP 8/24 Base SAN Switch. Do SAN infrastruktury jsou zapojena 4 externí disková pole MSA2000G3 s expanzními policemi, dále dvě páskové knihovny MSL 2024 a 4048, obě Blade šasi, zálohovací server a 2 appliance diskové virtualizace FalconStor NSS GA700 s externími rychlými vyrovnávacími pamětmi (cache) tvořenými servery HP DL380p G8 s rychlými flash úložišti. Účelem diskové virtualizace je zajištění pokročilých služeb – zejména zrcadlení úložišť, zajištění vysoké dostupnosti úložišť a abstrakce úložišť vůči fyzickým i virtuálním serverům.
(5) V TC ORP je využívána serverová virtualizační technologie VMware vSphere, aktuálně ve verzi 5.1 v edici Enterprise Plus (16 CPU). Pro správu prostředí slouží vSphere vCenter Standard. Jsou využívány rozšířené funkce virtualizační platformy High-availability, Vmotion, DRS.
(6) Pro napájení nových technologií je v primární lokalitě k dispozici zálohované napájení o výkonu 40 kVA zajišťované UPS Xxxxx 93PM. UPS je vybavena externím bypassem a systémem nouzového odstavení. Pro správu UPS a automatické řízení virtualizační platformy při výpadku a obnově napájení je používán systém Xxxxx Intelligent power manager. UPS splňuje požadavky na spolehlivé zajištění nepřetržitého napájení TC a má výkonovou rezervu pro zálohování poptávaných technologií.
(7) TC ORP je navrženo a budováno pro poskytování vysoce dostupných služeb. Klíčové prvky TC ORP jsou redundantní a jsou implementovány technologie umožňující automatické překlenutí odstávky (plánované i neplánované) klíčového prvku s žádným nebo minimálním (v řádu jednotek minut) výpadkem služeb.
(8) TC ORP je primárně zálohováno systémem Veeam Backup & Replication s ukládáním záloha na diskové pole a páskovou knihovnu MSL 2024. Některé zálohy a archivy, popř. méně důležitá data (např. instalační zdroje) jsou ukládány na úložišti typu NAS Windows Storage Server.
(9) Hlavním databázovým úložištěm MMKV je Microsoft SQL Server, aktuálně ve verzi 2008.
(10) Síťová infrastruktura LAN je osazena převážně aktivními prvky HP (HPE) řad 51xx a 55xx
s operačním systémem Comware.
(11) Zabezpečení přístupu k Internetu využívá dvou firewallů Fortinet FortiGate FG-240D v režimu vysoké dostupnosti (clusteru) včetně rozšiřujících bezpečnostních UTM funkcí.
(12) Groupwarové služby zajišťuje systém Exchange 2013 s doplňkovými nástroji pro bezpečnostní kontrolu příchozích a odchozích zpráv (antivir, antispam). Systém zajišťuje i obsluhu mobilních zařízení.
(13) Většina uživatelů využívá pro přístup k aplikacím tenké klienty HP. Aplikace jsou doručovány technologií Citrix Presentation Server 4 provozovanou na virtuálních serverech Windows 2003 R2. Pro vzdálený přístup k aplikacím je využívána technologie Citrix Secure Gateway.
(14) V prostředí TC ORP je implementován systém SafeQ pro řízení tiskového prostředí. Tiskové prostředí je tvořeno zejména tiskárnami a multifunkčními stroji HP LJ 3035, HPLJ4350dtn, HPLJP2055dn, Develop INEO 353 a osobními tiskárnami uživatelů, převáženě značky HP. Celkový počet tiskových zařízení je cca. 100.
(15) Provoz TC ORP je monitorován dohledovým systémem, který vychází ze systému Nagios. Systém monitoruje dostupnost a parametry služeb, aplikací, operačních systémů a zařízení včetně speciálních – docházkové terminály, kamerové systémy a další. Systém provádí i environmentální monitoring.
(16) MMKV disponuje optickou komunikační infrastrukturou (dále KI) typu MAN (metropolitan area network) propojující většinu městských organizací a také obě lokality MMKV (délka spoje mezi lokalitami je < 1 km, k dispozici je min. 8 single modových vláken). KI prochází kontinuálním rozvojem ve dvou klíčových oblastech – připojování dalších městských organizací a zavádění služeb pro tyto organizace. Komunikace mezi KI a TC ORP i komunikace s externími sítěmi (Internet, RKI Karlovarského kraje apod.) je řízena clusterem firewallů Fortinet FortiGate FG-240D. MAN je provozována na aktivních prvcích HP (HPE) řad 55xx a 75xx a je monitorována HP Intelligent Management Center (je částečně využíván i pro monitoring LAN).
(17) V prostorách MMKV je vybudován přípojný uzel krajské Regionální komunikační infrastruktury (dále RKI) vlastněné a provozované Karlovarským krajem. RKI propojuje všechny ORP Karlovarského kraje a významné organizace Karlovarského kraje (nemocnice, střední školy, SÚS (Správa a údržba silnic) a další. RKI je připojena k národním a resortním sítím – např. KIVS. RKI prochází kontinuálním rozvojem stejně jako KI.
(18) Pro účely správy dokumentů a provoz specifických aplikací (např. Registr dlužníků) využívá MMKV platformy Microsoft Sharepoint Foundation 2010 s rozšířením Nintex Workflow a Nintex Forms v edici Workgroup.
(19) Pro účely archivace dokumentů (např. stavebního archivu) využívá MMKV platformu IBM
FileNet (Business proces manager a Content Collector for E-mail).
(20) Standardním kancelářským balíkem využívaným pro potřeby MMKV je Microsoft Office, s ohledem na sjednocení uživatelského rozhraní a kompatibilitu dokumentů ve verzi 2007 a vyšší. Standardně jsou využívány aplikace Word, Excel, Outlook a OneNote.
2.4. Popis stávajícího SW prostředí
(1) Systémové služby jsou provozovány na platformě Microsoft Windows.
(2) Primární adresářovou službou je Active Directory, server zajišťuje také služby DNS a
DHCP.
(3) Standardním kancelářským balíkem využívaným pro potřeby DPKV je Microsoft Office v různých verzích (2003 – 2016). Standardně jsou využívány aplikace Word, Excel, Powerpoint a Outlook.
(4) MMKV má v současné době (v souladu se zákonem č. 128/2000 Sb., o obcích) základní majetkové evidence pokryté dále uvedenými stávajícími informačními systémy. Ty byly pořizovány postupně podle aktuální potřeby:
(a) Účetní systém a Evidence smluv GINIS (výrobce GORDIC s.r.o., Jihlava)
(b) Registr nemovitostí (výrobce T-MAPY spol. s r.o., Hradec Králové)
(c) Evidence majetkových úkonů parcel (výrobce T-MAPY spol. s r.o., Hradec Králové)
(d) Archiv stavebního úřadu (výrobce T-MAPY spol. s r.o., Hradec Králové)
Tyto aplikace poskytují základní zákonné informace o majetku MMKV. Evidované informace nestačí potřebám MMKV z hlediska správy majetku, ale obsahují data, která musí být dostupná z pasportizačního systému.
(5) Dostupnost dat ze stávajících informačních systémů úřadu pro oblast majetku je možná pomocí rozhraní API. API pro jednotlivé aplikace, které je nutné integrovat, jsou buď k dispozici, nebo v současné době neexistují a budou vytvořena stávajícími výrobci a vítěznému uchazeči bude zpřístupněn popis těchto API do 30 kalendářních dní od data účinnosti smlouvy. Uchazeč je povinen zahrnout do své nabídky náklady na vytvoření těchto API rozhraní v dále uvedené výši:
Stávající systémy | API rozhraní | Náklady na vytvoření API |
GINIS (výrobce GORDIC s.r.o., Jihlava) | K dispozici je API tvořené sadou WS, viz Otevřená integrační platforma GINIS xxxxx://xxxxx.xxxxxx.xx/Xxx/ | - |
Registr nemovitostí (výrobce T-MAPY spol. s r.o., Hradec Králové) | API není k dispozici | 80 000,- Kč bez DPH |
Evidence majetkových úkonů parcel (výrobce T-MAPY spol. s r.o., Hradec Králové) | API není k dispozici | 80 000,- Kč bez DPH |
Archiv stavebního úřadu (výrobce T- MAPY spol. s r.o., Hradec Králové) | API není k dispozici | 80 000,- Kč bez DPH |
Mapové podklad (T-MAPY spol. s r.o., Hradec Králové) | API je k dispozici. Je tvořené sadou WMS. | - |
(6) Zadavatel v souladu s § 96 odst. 2 ZZVZ poskytne dodavatelům popis (existujících) API rozhraní informačních systémů podle předchozího odstavce na písemnou žádost a proti podpisu písemného čestného prohlášení dodavatele, že tento popis využije výhradně pro účely přípravy své nabídky na plnění předmětu této veřejné zakázky a s podmínkou, že případné zneužití popisu rozhraní nad rámec uvedeného účelu bude vůči dodavateli sankcionováno částkou 400 000,- Kč.
2.5. Popis dokumentace
(1) K provozování a řízení rozvoje informačních systémů je využívána a udržována Provozní
dokumentace.
(2) Provozní dokumentace popisuje základní nastavení technologií, hardwarových a softwarových systémů a je tvořena souborem dokumentací zpracovaných v průběhu realizovaných implementačních ICT projektů.
(3) Citlivé údaje (přístupové účty apod.) jsou uloženy odděleně od Provozních dokumentací.
(4) Uchazeč je povinen v rámci zakázky zajistit nezbytné doplnění Provozní dokumentace reflektující provedené změny. Relevantní části Provozní dokumentace budou dodavateli zpřístupněny před zahájením realizace předmětu plnění.
2.6. Popis způsobu řešení incidentů
(1) Zadavatel pro řešení incidentů a podporu uživatelů využívá vlastní systém Helpdesk.
(2) Zadavatel zajišťuje podporu 1. úrovně a většinu běžných problémů jsou schopni vyřešit interní pracovníci Zadavatele.
(3) Incidenty a požadavky, které nevyřeší interní specialisté, jsou zadávány do helpdeskových systémů dodavatele systému, který vykazuje incident nebo na který směřuje požadavek uživatele. Hlášení incidentů a požadavků je prováděno telefonicky, emailem nebo přímo zadáním ticketu/požadavku do helpdeskového systému dodavatele.
2.7. Popis servisních oken
(1) Zadavatel nemá pevně definovaná pravidelná servisní okna.
(2) Aplikace aktualizací a oprav informačních systému provádějí specialisté zadavatele dle
potřeby a s přihlédnutím k minimalizaci omezení uživatelů.
3. Povinné parametry technického řešení
3.1. Obecné požadavky
(1) Pasportizační systém musí splňovat tyto obecné požadavky:
(a) Pasportizační systém musí být ve všech částech lokalizován v českém jazyce.
(b) Pasportizační systém musí být dostupný přes webové rozhraní.
(c) Pasportizační systém musí být dostupný pro oprávněné uživatele s využitím
autentifikace a autorizace pomocí Active Directory
(2) Zadavatel při výstavbě, správě a provozu technologií striktně dodržuje hledisko technologické neutrálnosti, tj. využití technologií takovým způsobem, který neomezuje implementaci technologií různých výrobců – tuto strategii musí splňovat i řešení dodané v rámci této veřejné zakázky.
(3) Pokud uchazeč vyžaduje využití konkrétních softwarových produktů a jím zvolený přístup k řešení zadání je na takových konkrétních řešeních závislý, musí jejich pořízení zahrnout ve své nabídce v potřebném rozsahu a v rámci nabídnuté ceny.
(4) Za předpokladu, že uchazečem navržené řešení vyžaduje fyzickou infrastrukturu (např. kabely, komunikační prvky atd.) neobsaženou v popisu předmětu plnění, zahrne uchazeč do své ceny všechny náklady na její pořízení, instalaci, konfiguraci a další služby potřebné pro uvedení do provozu.
(5) Pro každý softwarový produkt, který uchazeč nabídne v rámci svého řešení, budou v nabídce výslovně uvedeny všechny licenční nebo výkonové požadavky spojené s instalací a provozem řešení, včetně uvedení konkrétní infrastruktury, na které bude řešení provozováno.
(6) Uchazeč ve své nabídce detailně popíše vazby na stávající systémy Zadavatele, které jsou nezbytné pro správné fungování řešení nabízeného Uchazečem.
(7) Zadavatel z důvodů co nejjednodušší a jednotné správy a minimalizace provozních nákladů vyžaduje využití stávajících prostředků a používaných technologií. V případě, že uchazeč vyžaduje ve svém řešení stejné nebo podobné funkce, jaké poskytují stávající prostředky a technologie, je povinen využít nebo vhodným způsobem rozšířit stávající prostředky – není přípustné implementovat např. další serverovou virtualizační platformu, adresářovou službu apod.
(8) Dodavatel prokáže, že všechny výrobky, které dodá Zadavateli:
(a) jsou nové, byly oprávněně uvedeny na trh v EU nebo pochází z autorizovaného prodejního kanálu výrobce,
(b) mají plnou záruku od výrobce,
(c) mohou být podporovány výrobcem a mohou být součástí servisního a podpůrného programu výrobce,
(d) obsahuji licenci na používání příslušného softwaru,
(e) jsou určeny pro provoz v České republice,
(f) z databází výrobce, distributora či prodejce bude možné výše uvedené skutečnosti doložit. Tyto skutečnosti dodavatel doloží čestným prohlášením distributora, popř. uchazečem samotným,
nelze-li prohlášení distributora získat. Zadavatel si vyhrazuje právo na zjištění původu výrobku
při jejich převzetí, a to dle příslušných sériových čísel a právo podpisu akceptačního protokolu,
osvědčujícího převzetí dodávky, až po ověření původu výrobku.
3.2. Evidence majetku
(1) Navrhované řešení zajistí věcnou evidenci všech nemovitých majetků (budov, pozemků a staveb) ve vlastnictví SMKV, včetně majetku ve správě organizací zřízených městem nebo dalších organizací. Musí umožnit evidovat i majetek, který není ve vlastnictví SMKV.
(2) ěešení musí umožnit přístup k evidenci majetku a správu údajů o majetku a jeho pasportu přímo správcům majetku na jejich pracovištích na základě oprávnění.
(3) Evidence majetku musí být napojena na data Registru nemovitostí (data KN) a v měsíčních intervalech musí být možné verifikovat evidovaný majetek proti jeho aktuálnímu stavu na KN.
(4) Evidence majetku musí být navázána na stávající účetní systém a musí poskytovat základní ekonomické údaje o majetku města s využitím rozhraní na stávající účetní systém GINIS.
(5) Evidence musí být propojena s aplikací Evidence majetkových úkonů parcel a musí umožnit zobrazení údajů z této aplikace přímo v Evidenci majetku.
(6) Evidence musí být propojena s aplikací Archív stavebního úřadu a musí umožnit zobrazení údajů z této aplikace přímo v Evidenci majetku.
(7) Evidence musí být propojena s aplikací Evidence smluv GINIS a musí umožnit zobrazení údajů z této aplikace přímo v Evidenci majetku
3.3. Technicko pasportizační evidence
(1) Tato evidence musí umožnit pořízení a správu pasportních údajů o evidovaném majetku.
(2) Musí být uživatelsky dostupné definování jednotlivých skupin pasportizovaných parametrů a jednotlivých parametrů pasportu majetku.
(3) Struktura pasportizovaných prvků musí být odlišná pro jednotlivé druhy majetku tak, aby odpovídala danému typu majetku. V rámci daného druhu majetku může být dále strukturována, např. u budov na konstrukční prvky, zdravotně technickou instalaci atd. V dodávky musí být nakonfigurována struktura, která musí obsahovat alespoň tyto typy majetků:
(a) Parcely,
(b) Budovy,
(c) Mosty,
(d) Opěrné zdi,
(e) Plošné stavby,
(f) Liniové stavby,
(g) Vodní plochy
(4) Může existovat vícestupňová hierarchie pasportizovaných prvků.
(5) U pasportizovaného prvku musí být možné sledovat jednotku, počet, označení, popis a stav. Pokud je to relevantní tak i rok pořízení, roky oprav a periodu oprav.
(6) Musí existovat výstup do formátu XLSX, PDF, RTF, který reprezentuje tiskový pasport majetku a obsahuje všechny evidované pasportní údaje
(7) K pasportu majetku se musí vázat stavební akce prováděné na majetku a půjde je navázat až na jednotlivé pasportované prvky.
(8) Aplikace musí umožnit vyhledat majetky na kterých je prováděna zadaná stavební akce
(9) Aplikace musí evidovat termíny revizí jednotlivých prvků. Evidovat dokumenty u provedených revizí (revizní zprávy) a upozorňovat na termíny revizí pomocí notifikací.
3.4. Mobilní aplikace
(1) Aplikace musí umožnit v on-line režimu přístup k pasportnímu systému z mobilních zařízení. V plném rozsahu jeho funkčnosti.
(2) Aplikace musí být schopná v on-line režimu poskytnout prostorová data o majetku.
3.5. Business inteligence (BI)
(1) Pro potřeby komplexních přehledů a statistik v oblasti evidence majetku budou součástí předmětu plnění nástroje Business Intelligence, které budou využívat data z datového skladu.
(2) Prezentační vrstva a nástroje Business Inteligence představuje z hlediska uživatelů systému nejdůležitější prvek systému, jde o souhrn analytických, reportovacích, vizualizačních a interaktivních nástrojů pro analýzu, vizualizaci a reportování dat. Reporting zajistí alespoň:
(a) přístup k reportům přes webové rozhraní
(b) export reportů do různých formátů (xls, pdf, obrázek, text, xml …)
(c) automatickou distribuci reportů (min. emailem)
(d) pokročilé řízení přístupu uživatelů k reportům i vlastnímu obsahu reportů
(e) musí umožňovat generování reportů z více datových oblastí
(3) Samotná příprava reportů bude prováděna pomocí „průvodců“ (tzn. sled dialogových oken), kde uživatel postupně vybírá:
(f) Jaká data chce v reportu zobrazit
(g) Jak chce tato data filtrovat
(h) Jaké bude rozložení (layout) reportu (řádky, sloupce atd.)
(4) V rámci tvorby reportů bude možné nastavit řadu parametrů týkajících se filtrů, zobrazení, možností exportu atp.
(5) Systém umožní pracovat s datovým skladem i ad-hoc a to pomocí stávající aplikace MS Excel a to uživateli z domény úřadu. Jde zejména o možnost vytvořit připojení na datový zdroj na multidimenzionální objekty datového skladu, použití nástroje MS Excel kontingenční tabulky a možnosti použití vzorců do tabulek MS Excelu.
3.6. Datový sklad
(1) Primárním zdrojem dat pro datový sklad bude implementovaný pasportizační systém a
stávající systémy uvedené v kapitole 2.4, bod (4).
(2) Datový sklad se bude skládat z jednotlivých vrstev:
(a) Relační vrstva L0 – „Stage“ (stg) slouží pro přesun dat z primárních datových zdrojů. Jednorázově bude využita také pro iniciální load (prvotní načtení historických dat). Pravidelná denní aktualizace pak bude obsahovat pouze ta data, u kterých lze předpokládat, že došlo k jejich aktualizaci na zdroji.
(b) Relační vrstva L1 „Konsolidovaná databáze“ (dwh) - základní relační vrstva, která plní především archivační funkci.
(c) Relační vrstva L2 „Datové tržiště“- jedná se o vrstvu, která slouží jako podklad pro analytickou úroveň datového skladu. Mezi vrstvou L1 a L2 bude docházet ke značné míře transformace dat. V principu tato vrstva obsahuje tabulky faktů a číselníky pro dimenze.
(d) Analytická databáze (multidimenzionální databáze, OLAP atp.) – data zde budou uložena v tzv. multidimenzionálních objektech, tzv. „datových kostkách“ (či na obdobně fungujícím způsobu ukládání dat). Role databáze tohoto typu je v tom, že umožňuje rychlou analýzu dat, tvorbu multidimenzionálních dotazů, různé pohledy na data, a především rapidní zrychlení jak analytické práce s daty, tak běžné rutinní práce např. s tabulkovým kalkulátorem. Tato vrstva je zdrojem pro „prezentační vrstvu“ a veškeré analytické nástroje v ní obsažené.
(2) Konfigurace datového skladu – datové pumpy budou načítat ve stanovených intervalech data do „nulté“ vrstvy, kde se uloží v původní kvalitě. Následně budou na data aplikovány čistící, validační i kontrolní mechanismy (tzv. ETL mechanismy) tak, aby byla zajištěna jejich správnost a jednotný formát. Důležitým znakem ETL je jejich univerzálnost na vstupu, kde je možno zpracovávat téměř jakýkoliv formát vstupních strukturovaných dat. Konsolidovaná data z „nulté“ vrstvy se uloží do „první“ vrstvy, která je základem pro všechny typy výstupů z datového skladu. Data zde budou uložena v tzv. multidimenzionálních objektech (či na obdobně fungujícím způsobu ukládání dat), které umožňují rychlou analýzu dat, tvorbu multidimenzionálních dotazů, různé pohledy na data, a především rapidní zrychlení jak analytické práce s daty, tak běžné rutinní práce např. s tabulkovým kalkulátorem. Tato vrstva je základem pro „prezentační vrstvu“ (tj. Business Inteligence) a veškeré analytické nástroje v ní obsažené.
(3) Data odesílaná do datového skladu se načítají v určených intervalech a v plné kvalitě.
(4) Všechna data načtená do datového skladu se uchovávají v plně kvalitě a teprve poté jsou transformována do optimalizovaných úložišť.
(5) Import dat z ostatních částí systému do datového skladu probíhá v nastavitelných
intervalech automaticky.
(6) Pro praktické využití datového skladu bude připraveno datové tržiště – Městský majetek. Datové tržiště – Městský majetek – bude vytvářeno automatickým denním sběrem dat přímo ze zdrojových dat pasportizačního systému. Cílem datového tržiště je poskytování informací pro potřeby úřadu, a to až do podrobností konkrétních karet majetku a k nim dalších měřených
veličinách na konkrétních druzích majetku a to do nejnižší analytické podrobnosti, která je sledována v pasportizačním systému. Struktura datového tržiště musí umožnit výstupy:
(a) Přehled o konkrétním majetku – jednak jeho aktuální stav a to:
(i) obecné vlastností zjištěných při pasportu jako poloha, rozměry, přístup, základní konstrukce, energetický štítek, popis jednotlivých částí budovy, technické zařízení, průběh poslední revize atp.
(ii) ekonomická data (i v časové řadě) – pořizovací cena, zhodnocení, dotace, odepisování, zůstatková cena, provozní náklady, tržby (např. nájemné), opravy atp.
(iii) Technická data (i v časové řadě) – plocha, objem, ztráty, spotřeba energií atp.
(b) Přehledy sumarizační a porovnávací – vychází z evidence o konkrétním majetku, tzn., jedná se o seskupené pohledy na konkrétní druh majetku, zájmovou oblast a to za konkrétní zvolený časový okamžik (stav), nebo vývoj v čase (časovou řadu). Požadovány jsou alespoň:
(i) Výpis příjmů a výdajů po jednotlivých objektech dle hierarchie jejich druhu,
(ii) Výpis pronájmu pozemků po jednotlivých pozemcích dle hierarchie jejich druhu (nebytové prostory, plocha, výnos z pronájmu, výnos na m2 atp.) a to zvlášť za bytové a nebytové prostory. Je požadováno, aby bylo možné jednoduše filtrovat za pronajmuté a nepronajmuté pozemky, možnost jednoduše zjistit poslední cenu pronájmu za m2, filtr za vybranou zájmovou oblast atp.
3.7. Integrační platforma
(1) Z pasportního systému bude přímo přístupný stávající Registr nemovitostí.
(2) Současně se vybraná aktuální (ve smyslu poslední dodaná) katastrální data (katastr, číslo parcely, výměra, LV) budou zobrazovat na pasportním záznamu majetku, zároveň bude k dispozici „historie“ katastrálních dat.
(3) Do pasportního systému budou integrována ze stávajícího účetního systému následující data: hodnota majetku, průběh odepisování, dotace a rozpouštění dotací.
(4) Do pasportního systému budou integrovány ze stávající Evidence smluv následující data: metadata smluv a dodatků a jejich skeny.
(5) V pasportním systému bude provedena integrace stávajících mapových podkladů alespoň v rozsahu: katastrální mapa, ortofotomapa, vrstva majetku města, vrstva majetkových úkonů parcel.
(6) V pasportním systému bude provedena integrace se stávající Evidencí majetkových úkonů
parcel alespoň v rozsahu: Evidence úkonu, žádostí, průběhu úkonu, žadatelů a uzavřených smluv.
(7) Pasportní systém bude mít integrována data stávajícího Archívu stavebního úřadu vztahující se k danému majetku.
3.8. Popis povinných parametrů dodávaného řešení
(1) V dále uvedených tabulkách jsou uvedeny minimální povinné parametry dodávaného řešení.
(2) Uchazeč musí všechny povinné parametry splnit, v případě nesplnění je jeho nabídka vyloučena.
(3) Komodita K1 - Evidence majetku
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto povinného parametru včetně značkové specifikace nabízených dodávek | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
Evidence nemovitého majetku | |||
1 | Evidence nemovitého majetku v minimálním rozsahu evidovaných údajů: a) Číslo majetku b) Číslo inventární karty v účetní evidenci GINIS c) Druh majetku (budova, stavba, pozemek) d) Název e) Popis f) Pořizovací cena (včetně zhodnocení) g) Oprávky (všechny s datem provedení) h) Dotace i) Rozpuštěný transfer (všechny s datem provedení) j) Vztah k evidovanému majetku k) Podíl města na majetku l) Areál m) Účel užití majetku n) Číslo kulturní památky o) Výměra p) Číslo parcely q) Číslo budovy (čp., če.) r) Katastr s) List vlastnictví | ||
t) Správce majetku u) Datum zavedení v) Datum zrušení | |||
2 | Funkce porovnání atributů evidovaného majetku s KN – nový, vyřazený a změněný na těchto atributech a akceptace změn těchto atributů a) Vlastnický podíl b) Výměra c) Číslo parcely d) Číslo budovy (čp., če.) e) Katastr f) List vlastnictví g) Správce h) Vlastníci dle KN | ||
3 | Sestavy evidovaného majetku (formát XLS a PDF) a) Inventurní sestavy - po správcích b) Kontrolní sestavy c) Statistické sestavy | ||
4 | Funkce pro porovnání majetku evidovaného v Pasportním systému a ve stávajícím účetním systému GINIS – nový, vyřazený a promítnutí poslední změny ceny, výše dotace, oprávek a rozpuštění transferů | ||
5 | Funkce na uživatelský záznam účetních informací o pořizovací ceně, oprávkách, dotacích a rozpuštěných dotacích pro případ, kdy majetek odepisuje jeho správce | ||
6 | Evidence nemovitého majetku musí být navázána na data katastru nemovitostí. | ||
7 | Lze zaevidovat majetek a porovnávat ho na katastrální údaje i mimo území MMKV. | ||
8 | Lze zaevidovat i cizí majetek a sledovat jeho stav na katastru nemovitostí. | ||
9 | Bude možné zobrazit on-line stav majetku na katastru, a to včetně jeho historického vývoje na katastru nemovitostí. | ||
Registr nemovitostí | |||
10 | Prohlížení dat KN včetně vlastníků a jejich IČ/RČ (chráněno diferencovaným a monitorovaným přístupem) | ||
Mapová aplikace | |||
11 | Mapová aplikace musí zobrazovat majetek města (budovy, stavby a pozemky odděleně). | ||
12 | Musí existovat přístup z mapové aplikace přímo do evidence majetku na daný majetek a s ním související evidence. | ||
13 | Mapová aplikace musí umožnit zapínání různých podkladových map (letecký snímek, katastrální mapa, plán města atp.). | ||
14 | Musí umožnit vyhledání majetku přímo v mapové aplikaci | ||
15 | Aplikace musí mít nástroje na záznam poznámky do mapy a tisk mapového podkladu. | ||
16 | Popisná (databázová) a mapová část se zobrazuje v jednom společném okně (bez nutnosti přepínání). | ||
Registr RUIAN (ISZR) | |||
17 | Musí existovat zobrazení vyhledaného územního objektu v mapě (alespoň v území obce). Mimo obec (tedy mimo dostupné mapové podklady) tato funkčnost být nemusí. | ||
18 | Aplikace musí umožnit hledat územní prvky v rozsahu celé ČR. | ||
Evidence požadavků | |||
19 | Aplikace musí evidovat požadavky k majetku | ||
20 | Musí být umožněno vyhledávání majetku podle evidovaných požadavků k majetku. | ||
Evidence procesů | |||
21 | Pokud je výsledkem procesu smlouva (např. procesem je záměr pronájmu a následuje smlouva o pronájmu), musí jít zaznamenat vazba mezi smlouvou a procesem. | ||
22 | Aplikace musí evidovat procesy k majetku | ||
23 | Musí být umožněno vyhledávání majetku podle procesů s ním spojených. | ||
Evidence správců majetku | |||
24 | Evidence správců majetku musí mít jednoznačný identifikátor, kromě IČ umožnit také evidovat interní číslo organizace. | ||
25 | Aplikace musí umět vyhledat majetek podle správců majetku. Správce majetku musí být identifikován pomocí IČ. | ||
Evidence smluv | |||
26 | Evidence smluv správců majetku s třetími stranami. Tyto smlouvy nejsou součástí stávající Evidence smluv na MMKV. | ||
Notifikační systém | |||
27 | Notifikace musí být možné vytvořit i na základě šablony. Šablony notifikací musí být uživatelsky editovatelné. | ||
28 | Aplikace musí být schopna k danému majetku zaznamenat notifikaci (s textem, termínem odeslání a periodicitou a termínem ukončení odesílání) a zaslat ji na zadané emaily. | ||
29 | Musí být dostupný monitoring vytvořených a odeslaných notifikací. | ||
Integrace se stávající evidencí smluv | |||
30 | K danému majetku musí být možnost evidovat metadata smlouvy (odkazy do stávající Evidence smluv), k tomuto majetku. | ||
31 | Smlouvy evidované k majetku budou v případě majetku SMKV navázány pomocí synchronizačního procesu na smlouvy evidované v centrální evidenci ve stávajícím systému GINIS. | ||
32 | Smlouvy uzavřené správci majetku na majetek, který mají ve správě, budou pouze zaznamenány do pasportizačního systému, nebudou se odesílat do stávající Evidence smluv. | ||
Integrace se stávající evidencí majetkových úkonů parcel | |||
33 | K danému majetku musí být možné zobrazit všechny (i vyřízené nebo zamítnuté) žádosti o pronájmy nebo prodeje tohoto majetku. | ||
34 | K danému majetku musí být možné zobrazit všechny smluvní vztahy spojené s pronájmem nebo prodejem tohoto majetku. | ||
35 | K danému majetku musí být možné zobrazit průběh jednotlivých úkonů, které se v procesu pronájmu/prodeje udály a jsou evidovány v aplikaci | ||
36 | Evidence majetku musí zobrazit data ze stávající Evidence úkonů parcel navázaná na daný majetek | ||
Integrace se stávajícím Archívem stavebního úřadu | |||
37 | Evidence majetku musí zobrazit data ze stávajícího Archívu stavebního úřadu navázaná na daný majetek | ||
38 | K danému majetku musí být možné zobrazit všechny evidované dokumenty z archívu stavebního úřadu. | ||
(4) Komodita K2 - Technicko Pasportizační evidence
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto | Uchazeč uvede odkaz na přiloženou |
povinného parametru včetně značkové specifikace nabízených dodávek | část nabídky, kde je možné ověřit naplnění parametru | ||
Pasport objektů | |||
1 | Pasport majetku musí být členěn do alespoň dvou úrovní (skupina sledovaných položek a vlastní položky pasportu). | ||
2 | Musí být uživatelsky možné definovat novou skupinu a nové položky pro pasportizaci | ||
3 | Pro různé druhy majetku je možné definovat různé skupiny sledovaných položek | ||
4 | Pasport majetku musí umožnit uložení fotografií, technické dokumentace a dalších dokumentů v libovolném formátu jako přílohu, bez omezení počtu těchto příloh. | ||
5 | Pasport majetku musí umožnit pasportizovat i majetek který není v majetku SMKV. | ||
6 | Pasport majetku musí umožnit zakreslit daný majetek v mapě, pokud neexistuje jeho geometrie na katastru nemovitostí (jedná se zejména o stavby) | ||
7 | Aplikace musí být schopna k pasportizovanému druhu majetku vést evidenci revizí jeho prvků. | ||
8 | Aplikace musí být schopna k plánované revizi zaslat předem notifikaci (s textem, termínem, odkazem na danou revizi v systému – ideálně jako URL odkaz) a to na zadané emaily. | ||
Evidence stavebních akcí | |||
9 | Evidence stavebních akcí musí obsahovat dodavatele a možnost jeho ověření v ARES nebo v ROS (ISZR). | ||
10 | Stavební akce musí být vázány na majetek, případně na pasportizovaný prvek (např. výměna oken v budově) | ||
(5) Komodita K3 - Mobilní aplikace
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto povinného parametru včetně značkové specifikace nabízených dodávek | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
1 | Mobilní aplikace musí pracovat na OS Android včetně mapové části | ||
2 | Aplikace musí umožnit v on-line režimu zákres daného majetku do mapy. |
(6) Komodita K4 - Business Inteligence (BI)
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto povinného parametru včetně | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné |
značkové specifikace nabízených dodávek | ověřit naplnění parametru | ||
1 | Musí být k dispozici přehledy o konkrétním majetku - obecné vlastnosti zjištěné při pasportu jako poloha, rozměry, přístup, základní konstrukce, energetický štítek, energetický audit, popis technických zařízení, průběh poslední revize, seznam stavebních akcí s dodavatel, seznam požadavků k majetku, seznam smluv k majetku a seznam procesů, které se váži k majetku. Ekonomická data k majetku – pořizovací cena, zhodnocení, dotace, odepisování, zůstatková cena, opravy | ||
2 | Musí být k dispozici sumarizační přehledy k vybraným majetkům Jde o seskupené pohledy na konkrétní druh majetku, zájmovou oblast. Např. „Výpis budov, ve kterých se topí určitým druhem paliva a počet takových kotlů v každé budově“. | ||
3 | BI musí poskytnout informace pro potřeby úřadu, a to až do podrobností konkrétních karet majetku to do nejnižších analytických podrobností, která jsou sledována v pasportizačním systému. | ||
4 | Struktura multidimenzionálních úložišť musí umožnit základní dotazy v rozsahu dat uvedených v kapitole 3.3, bod (6) Komodita K4 - Business Inteligence | ||
5 | BI musí umožnit výstup poskytovaných dat v podobě sestav ve formátech (XLS, PDF, XML) | ||
6 | BI musí obsahovat řízení přístupu uživatelů k reportům i vlastnímu obsahu reportů |
(7) Komodita K5 - Datový sklad
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto povinného parametru včetně značkové specifikace nabízených dodávek | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
1 | Aplikace musí umět pracovat s datovým skladem i ad-hoc pomocí MS Excel. Musí být možné připojení na datový zdroj a na objekty datového skladu a použitím nástroje MS Excel a zejména kontingenčních tabulek vytvářet vlastní uživatelské výstupy. | ||
2 | Datový sklad musí být schopen načítat data ve strukturovaném vstupním formátu. Tento formát definuje správce datového skladu v zákaznicky definované struktuře vstupních dat. | ||
3 | Uložení dat do datového skladu musí obsáhnout jejich původní kvalitu. Tedy nahrát kompletní poskytnutá data bez jejich agregací. |
(8) Komodita K6 - Integrační platforma
Č. | Popis povinného parametru | Uchazeč popíše způsob naplnění tohoto povinného parametru včetně | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné |
značkové specifikace nabízených dodávek | ověřit naplnění parametru | ||
1 | U off-line integrací je nutné, aby existoval monitoring o jejich provedení (např. formou emailu odpovědným správcům systému). | ||
2 | V pasportním systému budou přímo dostupná data z KN (max. 1 měsíc starý stav) a to včetně historie změn, které na nich proběhly. | ||
3 | Z pasportního systému bude možné přímo zobrazit aktuální data z KN přímým přístupem na KN. | ||
4 | Ze stávajícího účetního systému budou v pasportním systému k dispozici údaje související s majetkem a stávající účetní systém bude řídit zařazení a vyřazení majetku pomocí rozdílových sestav. | ||
5 | Smlouvy evidované k majetku ve stávající Evidenci smluv bude možné zobrazit v pasportním systému (metadata) k danému majetku. | ||
6 | Skeny smluv ve stávající Evidenci smluv bude možné zobrazit přímo z pasportního systému k danému majetku a přístup k nim bude řízen přístupovými právy aplikace. | ||
7 | V mapové části pasportního systému bude možné zvolit základní mapové podklady (ortofotomapa, katastrální mapa). | ||
8 | V pasportním systému půjde zobrazit data ze stávající Evidence majetkových úkonů parcel vztahující se k danému majetku. | ||
9 | V pasportním systému půjde zobrazit data ze stávajícího Archívu stavebního úřadu vztahující se k danému majetku. |
3.9. Architektura technického řešení
(1) Identita uživatelů bude spravována centrálně. Tato centrální správa identit bude realizována formou integrace se stávajícím systémem Active Directory.
(2) Popsané otevřené aplikační rozhraní pro obousměrnou komunikaci s dalšími aplikacemi IS
zadavatele – na bázi Web Services (technologie SOAP).
(3) Systém pasportizace nemovitého majetku nabídne uživatelům komfortní přístup
k informacím nejenom pomocí popisných informací, ale i pomocí mapové aplikace:
(a) Mapová část aplikace musí umožnit zobrazit různé podkladové mapy a zaintegrovat
webové mapové služby poskytované ČÚZK.
(b) Současně musí být součástí vrstva zobrazující majetek města, a to alespoň v členění
parcely, budova, stavby.
(c) Mapová část aplikace musí umožnit na daném objektu (parcela, budova, stavba) zpět
informace o majetku v popisné části aplikace.
(d) Mapová část aplikace musí umožnit na daném objektu (parcela, budova) zpět informace z katastru nemovitostí. A to jak evidované v systému, tak i on-line pomocí veřejného nahlížení do katastru nemovitostí.
(e) Mapová část aplikace musí umožnit vyhledávání objektů podle katastrálního území a čísla parcely (pozemky) a také podle adresy (budovy).
3.10. Požadavky na kompatibilitu
(1) Pro všechny níže uvedené integrace zajistí zadavatel součinnost a nezbytné technické podmínky pro realizaci integrace. U datových integrací (import dat) zajistí vstupní data:
(a) Katastr nemovitostí - cílem integrace je zajistit promítnutí informací z katastru do
Evidence majetku, včetně historie změn na KN.
(b) Ekonomický systém GINIS - tato integrace má za cíl zejména zajistit přenos informací o účetním stavu majetku (pořizovací cena, oprávky, dotace, rozpuštění transferu). Dále je nedílnou součástí integrace zajištění informací o vyřazení nebo zařazení majetku.
(c) Evidence majetkových úkonů parcel - tato integrace má zajistit “promítnutí” pronájmů a prodejů majetku do Pasportizačního systému.
3.11. Požadavky na typy klientů
(1) Zobrazení mapy a mapových podkladů zobrazovat v běžných internetových prohlížečích, alespoň v nejnovějších verzích prohlížečů Google Chrome, EDGE, Mozilla Firefox.
(2) Mobilní aplikace musí pracovat na mobilním zařízení s operačním systémem Android.
3.12. Požadavky na bezpečnost informací
(1) Přihlašování k pasportizačnímu systému prostřednictvím SSO (Single Sign-On) – jednou
přihlášeného uživatele už není potřeba znovu ověřovat.
(2) ěízení přístupových práv aplikací a jejich nastavování z jednoho místa v dodávaném systému.
(3) Ověřování uživatele – autentizace – prostřednictvím Active Directory.
(4) Načtení oprávnění uživatele v aplikaci - autorizace – z jednoho místa v dodávaném systému.
(5) Bezpečnost uložených dat v souladu s nařízením Evropské unie GDPR (General Data
Protection Regulation).
3.13. Migrace dat
(1) Pokud není uvedeno jinak, je předpoklad, že informace a data budou do nově dodávaných částí řešení doplňovány ručně uživateli Zadavatele, od okamžiku spuštění do ostrého provozu.
(2) Prvotní nastavení aplikace je součástí předmětu plnění a bude provedeno na základě prováděcí dokumentace.
(3) Migrace dat (resp. úvodní naplnění daty) bude realizována pouze v těchto uvedených případech:
(a) Naplnit Registr nemovitostí daty z KN – prvotní naplnění daty.
(b) Naplnit Evidenci majetku daty z KN – prvotní naplnění budov a pozemků.
(c) Naplnit Evidenci majetku daty poskytnutými Zadavatelem (ve formátu CSV) – prvotní naplnění staveb. Struktura souboru staveb pro naplnění je:
(i) inventární číslo stavby,
(ii) název,
(iii) identifikace parcely, kde stavba stojí,
(iv) vlastnictví stavby (cizí, vlastní),
(v) správce stavby (IČ),
(vi) datum od kdy je stavba evidována.
(4) Zadavatel metodicky podpoří napárování dat v Evidenci majetku na data v Ekonomickém systému.
3.14. Požadavky na licence
(1) Požadovány jsou licence pro pracovníky zadavatele (min 150 uživatelů) a dále pro pracovníky správců (17 zřizovaných organizací a 2 realitní kanceláře).
(2) Pro všechny nabízené produkty použité pro implementaci předmětu plnění požaduje
zadavatel multilicenci bez omezení počtu uživatelů a funkcí nabízených systémů.
(3) Uchazeč ve své nabídce výslovně uvede počty dodávaných licencí a úplné licenční podmínky.
4. Hodnocené parametry technického řešení
4.1. Požadavky na vlastnosti technického řešení
(1) Zadavatel požaduje kromě splnění minimálních povinných parametrů také další funkční vlastnosti nabízeného řešení. Na rozdíl od povinných parametrů není uchazeč při nesplnění některého z požadovaného hodnoceného parametru vyloučen. Způsob hodnocení je uveden v ZD.
Hodnocené parametry | |||
Parametr | Popis | Uchazeč popíše způsob naplnění tohoto hodnoceného parametru včetně značkové specifikace nabízených dodávek | Uchazeč uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
Komodita K1 - Evidence majetku | |||
Evidence majetku | |||
1 | Evidence majetku umožňuje výstupy do formátu XML, XLSX, DOCX, RTF, PDF | ||
2 | Existují statistické výstupy nad evidencí majetku | ||
Mapová aplikace | |||
3 | Je možné zapínat/vypínat další podkladové mapy (letecké, historické, plán města), samotné podkladové mapy nejsou součástí předmětu plnění | ||
Registr RUIAN (ISZR) | |||
4 | Existuje proklik do Mapové aplikace na vybranou adresu nebo parcelu. | ||
Evidence požadavků | |||
5 | Lze evidovat stavy požadavků nebo postup vyřizování požadavků. | ||
Evidence procesů | |||
6 | Lze evidovat stavy požadavků nebo postup vyřizování procesů. | ||
Evidence správců majetku | |||
7 | Evidence správců obsahuje kontakty na jejich zástupce a je možné tyto kontakty využít v Notifikačním systému pro zasílání informací správcům. | ||
Notifikační systém | |||
8 | Umožňuje odesílání automatických notifikací při a) nečinnosti správce (neaktualizaci údajů o majetku delší než zadaný interval) b) provedení automatických akcí systému (např. při importu dat třetích stran) | ||
Integrace evidence smluv | |||
9 | Umožňuje zobrazit nejenom popisné informace, ale i skeny smluv (dle přístupových práv) z jejich centrálního úložiště. | ||
Integrace Evidence majetkových úkonů parcel | |||
10 | Pasportizačním systémem jsou respektována přístupová práva definovaná k této aplikaci. | ||
Integrace Archívu stavebního úřadu | |||
11 | Pasportizačním systémem jsou respektována přístupová práva definovaná k této aplikaci. | ||
Komodita K2 - Technicko pasportizační evidence | |||
Technicko pasportizační evidence | |||
12 | Technicko pasportní evidence umožňuje výstupy do formátu XML, XLSX, DOCX, RTF, PDF | ||
13 | Je možné zadání přípojných míst elektrické energie, plynu nebo vody včetně identifikátorů těchto míst (EAN, EIC), a vyhledání podle nich. | ||
14 | Je možné vést informace o energetické auditu budovy/stavby a energetický průkaz s datem jeho platnosti. | ||
Evidence stavebních akcí | |||
15 | Lze evidovat dodavatele stavební akce a ověřit ho v dostupných registrech (ISZR ROS, ARES atd.) | ||
Komodita K4 - Business inteligence | |||
16 | BI má nástroj na vytváření vlastního reportingu pomocí „průvodců“. | ||
Komodita K5 - Datový sklad | |||
17 | Lze prohlížet data uložená v datovém skladu v původní kvalitě (tak jak byla dodána) a to včetně jejich historie. | ||
Komodita K6 – Integrační platforma | |||
18 | Existuje monitoring využití integrační platformy, co kdy, kdo požadoval a kdy a jak bylo doručeno. | ||
5. Implementační služby
5.1. Obecné požadavky
(1) Zadavatel požaduje provést minimálně následující implementační práce na dodaných komponentech a případně dalších zařízeních. Uchazeč je dále povinen zahrnout do nabídky veškeré další činnosti a prostředky, které jsou nezbytné pro provedení díla v rozsahu doporučeném výrobci a dle tzv. nejlepších praktik, i v případě, pokud nejsou explicitně uvedeny, ale jsou pro realizaci předmětu plnění podstatné. Implementační služby budou minimálně v následujícím rozsahu:
(a) Zajištění projektového vedení realizace předmětu plnění.
(b) Zpracování prováděcí dokumentace, která představuje projektovou dokumentaci, podle které se projekt bude realizovat. Součástí zpracování prováděcí dokumentace je mj. provedení předimplementační analýzy a zpracování finálního návrhu cílového stavu.
(c) Dodávku nabízených zařízení a kompletní implementaci řešení splňující povinné parametry technického řešení,
(d) Provedení školení,
(e) Zajištění zkušebního provozu,
(f) Provedení akceptačních testů,
(g) Zpracování provozní dokumentace v rozsahu detailního popisu skutečného provedení a popisu činností běžné údržby a administrace systémů a činností pro spolehlivé zajištění provozu.
(h) Předání do ostrého provozu,
(2) Náklady na provedení implementačních služeb musí být zahrnuty v nabídkové ceně
k položce, ke které se vztahují a nelze je vyčíslit zvlášť.
(3) Uchazeč dle svého uvážení může doplnit v nabídce další služby, které jsou dle jeho názoru potřebné pro úspěšnou realizaci zakázky.
(4) Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích v elektronické formě ve standartních formátech (např. MS Office) používaných zadavatelem na datovém nosiči a 1x kopii v papírové formě.
5.2. Požadavky na zpracování prováděcí dokumentace
(1) Uchazeč před zahájením implementačních prací zpracuje prováděcí dokumentaci, která bude důsledně vycházet z předimplementační analýzy a bude zahrnovat všechny aktivity potřebné pro řádné zajištění implementace předmětu plnění.
(2) Jako podklad pro zpracování prováděcí dokumentace provede uchazeč předimplementační analýzu, která bude zohledňovat stávající prostředí zadavatele ve vztahu ke konkrétnímu nabízenému plnění uchazeče, zejména pak s ohledem na uchazečem použité technické řešení, minimálně pro následující oblasti:
(a) Analýza možností napojení připojovaných systémů.
(b) Analýza provozních režimů jednotlivých technologií a návrh nastavení.
(c) Analýza požadované migrace dat.
(d) Analýza nároků dodávaných systémů na ukládání a zálohování dat, toky a objemy dat, nároky na výpočetní kapacity, včetně specifikace objemu předpokládaných datových toků.
(e) Požadavky na uživatelské prostředí – způsob ovládání, požadované funkce.
(f) Požadavky na rekonfiguraci stávajících systémů ve vztahu k plánovanému využití.
(g) Dopady implementace na dostupnost a funkčnost stávajících služeb.
(h) Požadované součinnosti Zadavatele.
(i) Návrh opatření k odstranění neshod zjištěných v průběhu analýzy.
(3) Prováděcí dokumentace musí zohlednit podmínky stávajícího stavu, požadavky cílového stavu dle zadávací dokumentace a konkrétního technického řešení nabízeného uchazečem a musí obsahovat minimálně tyto části:
(a) Detailní popis cílového stavu včetně funkcionalit jednotlivých částí systému,
(b) Způsob zajištění dodávek a služeb,
(c) Způsob zajištění koordinace realizace předmětu plnění s běžným provozem,
(d) Detailní návrh a popis postupu implementace předmětu plnění,
(e) Detailní popis zajištění bezpečnosti informací,
(f) Detailní harmonogram projektu včetně uvedení kritických milníků,
(g) Vazby na stávající systémy a jejich konfigurace,
(h) Návrh akceptačních kritérií a akceptačních testů,
(i) Detailní popis navrhovaných školení.
(j) Obsah a rozsah provozní dokumentace.
(4) Prováděcí dokumentace musí být před zahájením realizace dalších etap plnění výslovně schválena zadavatelem.
(5) Prováděcí dokumentace bude před ukončením zkušebního provozu aktualizována dle skutečného stavu a následně bude součástí provozní dokumentace.
5.3. Harmonogram realizace
(1) Uchazeč zajistí projektové vedení po celou dobu realizace zakázky osobou odpovědnou za realizaci předmětu plnění, která bude hlavní kontaktní osobou a která bude přítomna při všech jednáních týkajících se projektu.
(2) Zadavatel vyžaduje dodržení následujícího harmonogramu plnění – zde jsou uvedeny maximální možné lhůty pro jednotlivé kritické milníky. Údaj D značí datum účinnosti smlouvy o dílo. Čísla značí počet kalendářních dnů.
Etapa č.. | Etapa projektu – činnost | Zahájení etapy | Ukončení etapy |
1 | Předimplementační analýza a zhotovení Prováděcí dokumentace | D | D+21 |
2 | Předání Prováděcí dokumentace Zadavateli, připomínkové řízení | D+21 | D+25 |
3 | Zapracování připomínek a předání finální verze Prováděcí dokumentace – akceptace Zadavatelem | D+25 | D+30 |
4 | Dodávky a implementace | D+30 | D+120 |
5 | Školení uživatelů a administrátorů | D+100 | D+120 |
6 | Zkušební provoz | D+100 | D+120 |
7 | Akceptační testy | D+100 | D+120 |
8 | Zahájení plného provozu | D+120 | - |
(3) Uchazeč může dle svého uvážení výše uvedené maximální lhůty trvání zkrátit při dodržení všech částí předmětu plnění a bez snížení kvality dodávaných služeb.
(4) Maximální lhůty trvání nesmí uchazeč při tvorbě detailního harmonogramu prodloužit.
(5) Uchazeč uvede závazný harmonogram plnění ve své nabídce a zároveň v návrhu smlouvy o dílo.
(6) Uchazeč uvede potřebnou součinnost zadavatele pro splnění harmonogramu plnění ve své nabídce.
5.4. Požadavky na školení
(1) Uchazeč zajistí školení administrátorů – na systémy, dodávané v rámci této veřejné zakázky, a to minimálně v rozsahu předávané provozní dokumentace. Školení zajistí seznámení pracovníků Zadavatele se všemi podstatnými částmi díla v rozsahu potřebném pro provoz, údržbu a identifikaci nestandardních stavů systému a jejich příčin a pracovníkům bude vystaveno osvědčení o školení s uvedením rozsahu školení. Minimální rozsah školení je 6 hodin. Předpokládá se účast max. 4 účastníků. Náklady na školení musí být zahrnuty v nabídkové ceně k položce, ke které se vztahují a nelze je vyčíslit zvlášť.
(2) Uchazeč dále zajistí školení klíčových uživatelů systému a to minimálně v rozsahu seznámení se všemi hlavními funkcemi dodávaných systémů. Minimální rozsah školení je 6 hodin v alespoň 2x turnusech, tj. uchazeč nabídne alespoň 2x6h školení ve dvou různých termínech. Předpokládá se účast max. 10 účastníků na školení. Náklady na školení klíčových uživatelů systému musí být naceněny zvlášť.
(3) Všechny školení bude probíhat v sídle Zadavatele.
5.5. Požadavky na testovací prostředí
(1) Zadavatel nedisponuje testovacím prostředím.
(2) Vyžaduje-li uchazeč pro realizaci zakázky testovací prostředí, zahrne do nabídky náklady na jeho vybudování a požadovanou součinnost Zadavatele.
5.6. Požadavky na provedení akceptačních testů, zkušební provoz a
přechod do ostrého provozu
(1) Uchazeč navrhne způsob a provedení akceptačních testů.
(2) Součástí akceptačních testů musí být minimálně:
(a) Ověření (otestování) veškerých požadovaných funkcí a parametrů všech dodávaných zařízení,
(3) O provedení akceptace a jejím výsledku musí být vyhotoven písemný protokol.
(4) Uchazeč zajistí podporu zkušební provozu v délce minimálně 30 dnů včetně technické
podpory následovně:
(a) zajištění fyzické přítomnosti jednoho specialisty dodavatele v sídle zadavatele alespoň jeden den v každém týdnu po dobu zkušebního provozu (konkrétní termíny budou upřesněny před zahájením zkušebního provozu) během pracovní doby zadavatele,
(b) zajištění technické podpory formou telefonické konzultace se specialistou dodavatele s dostupností maximálně 2 hodin od nahlášení požadavku v pracovní dny v době od 8:00 do 17:00 hod. - v termínech bez fyzické přítomnosti specialisty dodavatele v sídle zadavatele a to po celou dobu zkušebního provozu.
(5) Ukončením zkušebního provozu a přechodem do ostrého provozu se rozumí okamžik úspěšné akceptace díla včetně vypořádání všech vad a nedodělků.
6. Záruky a servisní podmínky
6.1. Požadavky na záruky a servisní podmínky
(3) Zadavatel uvádí u jednotlivých komodit požadovanou min. záruku, popř. podporu. Uváděné parametry byly průzkumem trhu zjištěny jako standardní, tj. poskytovány výrobci jako součást standardní dodávky a ceny. Není-li uvedeno u konkrétní komponenty jinak, požaduje zadavatel záruku minimálně v délce 24 měsíců.
(4) Dodavatel ve své nabídce výslovně uvede všechny podmínky záruk a poskytované služby v době platnosti 24 měsíční záruky od doby předání dodávaného systému jako celku do plného produktivního provozu.
(5) Veškeré opravy zjištěných vad po dobu záruky budou provedeny bez dalších nákladů pro zadavatele. Vadou se rozumí stav, který je v rozporu:
(a) se standardní funkcionalitou systému implementovaného na produkčním prostředí a tento rozpor je vůči uživatelské dokumentaci systému,
(b) s funkcionalitou definovanou ve smlouvě o dílo (jejích přílohách), případně v akceptačním protokolu implementace systému,
(c) s platnou legislativou ČR k datu hlášení incidentu zadavatelem.
(6) Není-li uvedeno u konkrétní komponenty jinak, požaduje zadavatel provedení záruční opravy zjištěné vady do tří pracovních dnů.
(7) Pro hlášení servisní požadavků zajistí Dodavatel Zhotoviteli přístup ke svému helpdeskovému systému s on-line přístupem pro kompletní správu požadavků včetně uchování historie požadavků a jejich řešení. Detailní popis helpdeskového systému a jeho obsluhy musí být součástí nabídky. Provozní doba helpdeskového systému musí být minimálně 8-17 hod. v pracovních dnech.
(8) Po dobu 60 měsíců od předání díla jako celku do plného provozu, musí dodavatel (popř. výrobce) dodaných zařízení typu hardware garantovat běžnou dostupnost náhradních komponentů a dostupnost servisu.
6.2. Požadavky na zabezpečení provozu
(1) Uchazeč zpracuje provozní dokumentaci, která bude detailně popisovat konfiguraci zhotoveného díla a jeho vazby na stávající systémy.
(2) Provozní dokumentace bude vycházet z prováděcí dokumentace, která bude před předáním
do provozu aktualizovaná dle skutečného stavu.
(3) Součástí provozní dokumentace bude popis úkonů doporučené údržby a specifikace intervalů jejích provádění a další dokumentaci v rozsahu stanoveném v prováděcí dokumentaci.
(4) Uchazeč zajistí technickou podporu po spuštění ostrého provozu v délce 2 týdnů takto:
(a) fyzická přítomnost jednoho specialisty dodavatele v sídle zadavatele jeden den v každém týdnu,
(b) možnost technické podpory formou telefonické konzultace se specialistou dodavatele s dostupností maximálně 2 hodin od nahlášení požadavku v pracovní dny v době od 8:00 do 16:00 hod. - v termínech bez fyzické přítomnosti specialisty dodavatele v sídle zadavatele,
(5) Dodavatel ve své nabídce uvede poskytované služby a podmínky podpory zabezpečení provozu po dobu minimálně 60 měsíců od předání dodávaného systému jako celku do plného produktivního provozu. Služby budou rozděleny na základní servisní podporu a rozšířenou servisní podporu.
(6) Součástí základní servisní podpory musí být alespoň:
(a) instalace a údržba aktuálních verzí, upgrade a update dodaného software na vyžádání zadavatele a
(b) zajištění instalace legislativního servisu, kdy aktuální verze dodaného software musí být zadavateli nainstalována nejpozději k datu nabytí účinnosti nové právní úpravy za předpokladu vydání prováděcích předpisů k této úpravě nejpozději 60 dnů před nabytím účinnosti této nové právní úpravy (v opačném případě do 60 dnů od vydání prováděcích předpisů k příslušné právní úpravě).
(c) Pravidelný měsíční update dat Registru nemovitostí daty z KN.
Cenu Základní servisní podpory zahrne dodavatel do položky „Základní servisní podpora“ v jednotlivých letech, v nichž má být zajišťována.
(7) Součástí rozšířené servisní podpory musí být alespoň:
(a) řešení případných změnových požadavků, tj. možné úpravy nebo doplnění standardní funkcionality dodaného systému (tzv. change request – změnový požadavek) v rozsahu min. 32 hodin ročně. V případě nerealizování úprav nebo doplnění standardní funkcionality je možné tuto kapacitu vyčerpat dalšími uvedenými službami rozšířené podpory,
(b) provozní kontrola systému (profylaxe) v rozsahu min. 32 hodin ročně,
(c) implementace nových verzí produktu v rozsahu min. 32 hodin ročně,
(d) poskytování konzultací v rozsahu min. 32 hodin ročně,
(e) poskytování školení (doškolení změn nebo nově příchozích pracovníků úřadu)
v rozsahu min. 32 hodin ročně.
Cenu Rozšířené servisní podpory zahrne dodavatel do položky „Rozšířená servisní podpora“
v jednotlivých letech, v nichž má být tato servisní podpora zajišťována.
(9) Pro případ, že bude Zadavatel požadovat služby podle odst. (7) nad rámec uvedeného rozsahu služeb zahrnutých v měsíčním paušálu dané služby, Dodavatel tyto služby nacení v kalkulaci nabídkové ceny též jako hodinovou sazbu za službu (označení služby „EXP-WRK“), přičemž hodinová sazba nesmí být vyšší než hodinová sazba použitá pro výpočet ceny dle odst. (7).
(10) Dodavatel bude v průběhu produktivního provozu vykonávat podporu uživatelů osobní přítomností, prostřednictvím vzdáleného připojení do prostředí objednatele nebo prostřednictvím telefonických konzultací.