Dodatečná informace č. 4 k nadlimitní veřejné zakázce, zadávané formou otevřeného řízení podle § 27 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“) Ve smyslu ustanovení § 151 zákona č.137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“) pověřil zadavatel výkonem zadavatelských činností v rámci zadávacího řízení k výše uvedené veřejné zakázce společnost Český a moravský účetní dvůr (dále jen „osoba pověřená“), s.r.o., IČ: 25972154, se sídlem Masarykovo náměstí 1484, Pardubice, PSČ 530 02, zastoupený Ing. Janou Dvořákovou. V souladu s ustanovením § 49 odst. 2 zákona poskytuje zadavatel prostřednictvím osoby pověřené dodatečné informace k zadávacím podmínkám na základě 39 dotazů k výše uvedené veřejné zakázce, které byly podány jedním z uchazečů 4. 1. ve 21,30 tedy v zákonném termínu, takže je nutno ze zákona na ně odpovědět ještě před termínem pro podání nabídek: S ohledem na časovou nouzi se zadavatel tímto omlouvá za formální úpravu dotazů a odpovědí, které byly zpracovány v nejkratším možném termínu.
část 3. – Vnitřní integrace - předmětem části 3 je zejména: • Integrace s centrálními projekty eGovernment (základní registry) DOTAZ č. 1: Funkční integrace na Základní registry veřejné správy může být vytvořena až po zveřejnění specifikace rozhraní informačního systému Základních registrů jejich provozovatelem, tj. Správou základních registrů ČR. Pokud toto nebude zveřejněno do požadovaného data odevzdání nabídky (9.1.2012), lze uvést pouze principy integrace, nikoli jejich implementaci. Je uvedení principů uznáno zadavatelem jako vyhovující způsob splnění požadavků zadavatele? ODPOVĚĎ:V rámci předmětného výběrového řízení je poptávané řešení, které tuto službu (resp. propojení) zajistí. Pro Zadavatele bude v rámci nabídky směrodatný závazek k plnění a zajištění této činnosti v rámci předmětné výzvy. Úřad požaduje, aby byly implementovány všechna rozhraní, která budou v době realizace projektu známá. • Řešení integrace v rámci hlavního provozovaného IS s možností napojení ostatních IS DOTAZ č. 2: Jaký IS považuje zadavatel za „hlavní“ ? Prosíme o uvedení všech“ ostatních IS“ zadavatele, které mají být integrovány, včetně jejich konkrétních verzí a jejich výrobců. ODPOVĚĎ: Hlavním IS je agendový systém MěÚ. Taxativní výčet využívaných komponent IS je popsán ve Studii proveditelnosti – v kapitole 7.3.3.1 (str. 116-119), v rámci které je zahrnut i popis požadovaných integračních můstků (propojení).
strana 1 z 17
• Integrace oblasti správy majetku města a ekonomickými agendami města • Poskytnutí uživatelských přístupových licencí DOTAZ č. 3: Jaký počet licencí zadavatel požaduje? Prosíme uvést v členění: počet pojmenovaných uživatelů, počet zaručených simultánních přístupů. ODPOVĚĎ: Požadujeme multilicence – tzn. neomezený počet přístupů. • Licence pro připojení stávajících agend do Spisové služby DOTAZ č. 4: Jaký počet licencí zadavatel požaduje? Prosíme uvést v členění: počet pojmenovaných uživatelů, počet zaručených simultánních přístupů. ODPOVĚĎ:Popis a počet provázanosti vůči spisové službě je uveden v rámci Zadávací dokumentace v Příloze č. 2 v části Technické a funkční požadavky. Co se týče přístupů, požadujeme neomezené propojení, tzn. multilicenční model. • Poskytnutí záručního servisu DOTAZ č. 5: Prosíme uvést požadované podmínky záručního servisu. ODPOVĚĎ:Podmínky jsou uvedeny v rámci ZD v kapitole „Technická podpora zahrnuje“ 5*12*4 • Poskytnutí nezbytného školení na datové technologie DOTAZ č. 6: Prosíme uvést druhy „datových technologií“, na které je požadováno školení, počet účastníků a požadovaný minimální rozsah v časových jednotkách a obsah školení. ODPOVĚĎ: Jedná se o uchazečem nabízené datové technologie. Abychom byli schopni vykonávat elementární činnosti v rámci údržby nabízeného řešení, požadujeme vyškolení v rozsahu 2 čld (2 x 8 hodin) za účasti 2 pracovníků zadavatele. • Zajištění publicity projektu v souladu s požadavky výzvy • Workgroupové prostředí - komunikační server s možností o sdílení kontaktů, úkolů o s poštovním serverem se zabezpečenou portálovou prezentací všech klientských funkcí účtu komunikačního serveru o nativně provázaný se stávajícími klientskými instalacemi MS Office o plná nativní podpora formátů dle ISO (docx, xlsx, …) o schopnost pracovat ve virtualizovaném prostředí TC o možnost doplnit o nativně podporované workgroupové portálové řešení s vlastnostmi DMS o bezpečnost a spravovatelnost z AD DOTAZ č. 7: Požaduje zadavatel zkušební provoz nabízeného systému? Pokud ano v jaké délce a v jakém režimu (osobní přítomnost konzultanta v sídle zadavatele?, vzdálené připojení a postačující telefonické konzultace?).
strana 2 z 17
ODPOVĚĎ:Zkušební provoz je požadován a to v délce 30 dnů za kombinované přítomnost pracovníka dodavatele. V rámci zkušebního provozu požadujeme přítomnost v minimálním rozsahu 3 čld (3 x 8 hodin) (tzn. při zahájení, v průběhu a při ukončení testovacího provozu) a dále garanci telefonické dostupnosti konzultanta v čase Po – Pá 8:00 – 16:00.
Lhůta dodání, časový harmonogram plnění, doba trvání zakázky a. Předpokládaný termín uzavření smlouvy je únor 2012. b. Termín zahájení plnění veřejné zakázky v rámci uzavřené smlouvy je podmíněn řádným ukončením zadávacího řízení a podepsáním příslušné smlouvy. Zadavatel si z těchto důvodů vyhrazuje právo jednostranně změnit předpokládaný termín zahájení. DOTAZ č. 8: Zadavatel neuvedl požadovaný termín dokončení zakázky ve smyslu předání předmětu plnění do produktivního provozu. Lze z toho dovodit, že vyhovující termín plnění zakázky může být k 31.12.2012 ? ODPOVĚĎ: Zadavatel předpokládá jako termín dokončení I. etapy (tj. vybudování TC včetně všech souvisejících produktů a služeb) na 30.6.2012, dokončení II. etapy (tj. dodání SSL ORP a SSL pro obce v oblasti) na 30.9.2012 a dokončení III. etapy (tj. dodání Vnitřní integrace úřadu) na 31.12.2012. Předpokládané termíny jsou však logicky závislé na průběhu zadávacího řízení a mohou být přiměřeně posunuty v návaznosti na termín skutečného uzavření smlouvy s vítězným uchazečem. Podání nabídky a. Uchazeč je povinen podat nabídku vždy na všechny komodity a součásti, které jsou součástí části veřejné zakázky a jsou uvedeny v přílohách, případně ve studii proveditelnosti. b. Pokud uchazeč nepodá nabídku na všechny komodity, jedná se o neúplnou nabídku, která bude vyřazena z dalšího hodnocení. DOTAZ č. 9: Je možné bodu b. článku 11. rozumět tak, že zadavatel připouští jako vyhovující nabídku, která obsahuje pouze všechno požadované plnění Části 3. zakázky ? ODPOVĚĎ: Na tuto otázku bylo odpovězeno v dokumentu Dodatečná informace č. 1 ze dne 13.12.2011, který je uveřejněn na webových stránkách města Beroun. Kvalifikační dokumentace 12.1
Splnění kvalifikace
strana 3 z 17
12.2
Způsob prokazování kvalifikace
12.3 Základní kvalifikační předpoklady 12.3.1
Splnění základních kvalifikačních předpokladů
12.3.2 Prokázání splnění základních kvalifikačních předpokladů Uchazeč prokazuje splnění základních kvalifikačních předpokladů podle předchozího odstavce předložením: a. prosté kopie výpisu z evidence Rejstříku trestů (jde-li o právnickou osobu, musí tento předpoklad splňovat statutární orgán nebo každý člen statutárního orgánu), b. potvrzení příslušného finančního úřadu o bezdlužnosti a ve vztahu ke spotřební dani předložením čestného prohlášení (čestné prohlášení je součástí přílohy č. 5), c. potvrzení příslušné správy sociálního zabezpečení o bezdlužnosti ve vztahu k pojistnému a penále na sociální zabezpečení a příspěvku na státní politiku zaměstnanosti d. čestného prohlášení o splnění ostatních základních kvalifikačních předpokladů (příloha č. 5) e. předložení příslušného seznamu k prokázání čl. 12.3. písm. k/ a l/ zadávací dokumentace nebo předložení negativního prohlášení, že se na něj příslušné písmeno zákona nevztahuje, či je z jiného důvodu irelevantní.
Za bezdlužnost uchazeče dle výše uvedených bodů není považován stav, kdy má uchazeč se správcem daně nebo s příslušnou OSSZ na jakoukoli dlužnou částku dohodnut splátkový kalendář. DOTAZ č. 10: Uzná zadavatel splnění základních kvalifikačních předpokladů formou výpisu ze Seznamu kvalifikovaných dodavatelů, který nebude starší ke dni podání nabídky více než 90 dnů? ODPOVĚĎ: ANO (zodpovězeno již v dodatečné informaci č. 1) 12.4 Profesní kvalifikační předpoklady Splnění profesních kvalifikačních předpokladů prokáže uchazeč, který předloží: a.
prostou kopii Výpisu z obchodního rejstříku, pokud je v něm zapsán, či výpis z jiné obdobné evidence, pokud je v ní zapsán (nesmí být starší než 3 měsíce),
b. prostou kopii dokladu o oprávnění k podnikání podle zvláštních právních předpisů v rozsahu odpovídajícím předmětu zakázky, zejména doklad prokazující příslušné živnostenské oprávnění (živnostenský list) či licenci. DOTAZ č. 11: Uzná zadavatel splnění profesních kvalifikačních předpokladů formou výpisu ze Seznamu kvalifikovaných dodavatelů , který nebude starší ke dni podání nabídky více než 90 dnů? ODPOVĚĎ: ANO (zodpovězeno již v dodatečné informaci č. 1)
strana 4 z 17
12.5 Ekonomické a finanční kvalifikační předpoklady 12.6 Technické kvalifikační předpoklady a. Ad kritérium č. 2 – Garantovaná rychlost reakce v případech závad Hodnotícím kritériem bude garantovaná rychlost reakce dodavatele v situacích, kdy dojde k závadě, která znemožňuje standardní užívání systému. Uchazeč uvede na krycím listu (příloha č. 3) rychlost reakce při zásahu a dále garantovanou dobu plnohodnotného odstranění problému nebo závady v době záruky: DOTAZ č. 12: Požaduje zadavatel, aby režim podpory, tj. připravenost uchazeče na řešení závad, byla nepřetržitá včetně sobot, nedělí a státem uznaných svátků ? Pokud nikoli a požadována je reakce pouze v pracovních dnech, prosíme o uvedení zadavatelem požadované pracovní doby. ODPOVĚĎ: Minimální požadovaný režim podpory je 5 x 12 (12*5*4). a) čas v hodinách, do kdy od prokazatelného nahlášení závady zadavatelem zahájí úkony, kterou povedou k odstranění závady; b) čas v hodinách, do kdy zabezpečí buď uvedení zařízení do standardního výkonu, nebo náhradu nefunkčního zařízení za náhradní zařízení se srovnatelnými užitnými a technickými parametry. DOTAZ č. 13: Prosíme o uvedení požadovaného způsobu „prokazatelného nahlášení závady“. Bude zadavatel akceptovat komunikační nástroj uchazeče? Pokud nikoli, prosíme o popis nástroje, kterým budou závady nahlašovány. ODPOVĚĎ: ANO, Zadavatel bude akceptovat komunikační nástroj uchazeče, a to za předpokladu, že implementací takového nástroje nebude zatížen rozpočet zadavatele, tzn., že tento nástroj bude minimálně po dobu udržitelnosti projektu pro zadavatele zdarma. Zadavatel v rámci hodnocení sečte uchazečem uvedené reakční časy (v hodinách) v obou situacích a vydělením takto vypočítaného součtu (součet: 2), vypočítá průměrnou dobu reakce v hodinách. Takto vypočítaná průměrná doba reakce v hodinách bude podkladem pro hodnocení. Platební podmínky, jednotný způsob zpracování nabídkové ceny Platební podmínky a. Platby bude provádět město Beroun na základě faktur vystavených dodavatelem, za každou zrealizovanou část zakázky vystaví dodavatel po protokolárním předání díla zadavateli příslušnou fakturu.
strana 5 z 17
DOTAZ č. 14: Zadavatel předpokládá pouze jednu platbu až po skončení plnění části 3. zakázky? Nebo připouští dílčí platby po předání jednotlivých dílčích plnění zakázky v této části 3. zakázky? ODPOVĚĎ: Zadavatel nepřipouští zálohy. V ZD na str.13 v 1článku 14.1.a je uvedeno, že: a. Platby bude provádět město Beroun na základě faktur vystavených dodavatelem, za každou zrealizovanou část zakázky vystaví dodavatel po protokolárním předání díla zadavateli příslušnou fakturu. b.
Dodavatel bude fakturovat do 14 kalendářních dnů po převzetí konkrétního plnění zadavatelem.
c.
Splatnost faktur bude minimálně 30 kalendářních dnů po prokazatelném doručení faktury zadavateli.
d.
Zadavatel neposkytuje zálohy.
1.1. Jednotný způsob zpracování nabídkové ceny a. Nabídkové ceny budou rovněž uvedeny v příloze č. 3 - „Krycí list“, budou zpracovány a uvedeny v české měně se zaokrouhlením na celé Kč, v členění na cenu bez DPH a cenu včetně DPH. Jako nabídkové ceny budou hodnoceny ceny včetně DPH, ve vztahu k projektu není zadavatel plátcem DPH. b. Celkovou nabídkovou cenou se rozumí cena za kompletní realizaci zakázky včetně ceny za zpracování projektu realizace, instalaci a implementaci, zkušební provoz, zpracování dokumentace konečného provedení, zaškolení obsluhy. Tato cena zahrnuje základní záruku v délce 60 měsíců. Celkovou nabídkovou cenu zpracuje uchazeč v členění dle přílohy č. 7A. Přehled musí obsahovat všechny položky mající vliv na výši nabídkové ceny. Celkovou nabídkovou cenu zpracuje uchazeč v členění dle přílohy č. 7B. Přehled musí obsahovat všechny položky mající vliv na výši nabídkové ceny. 17.2. Náležitosti návrhu smlouvy – obchodní podmínky Návrhem smlouvy se pro účely zadávacího řízení rozumí návrh smlouvy pro každou část veřejné zakázky samostatně, podepsaný statutárním zástupcem dodavatele, nebo jím zplnomocněnou osobou (včetně příslušné plné moci). Návrh smlouvy musí pro každou část veřejné zakázky obsahovat minimálně následující náležitosti a požadavky zadavatele: - předmět plnění; - místo plnění; - závazek dodavatele vybavit zadavatele a jeho zaměstnance veškerou dokumentací ke všem součástem předmětu veřejné zakázky; - garantovaný termín realizace dle jednotlivých částí – předání díla do zkušebního provozu; - harmonogram testování a zkušebního provozu;
strana 6 z 17
DOTAZ č. 15: Jaké má zadavatel konkrétní požadavky na formu a délku testování? ODPOVĚĎ: Viz odpověď na dotaz č. 7 tohoto dokumentu. -
pravidelné testování systému minimálně jednou za 3 měsíce; DOTAZ č. 16: Prosíme o popis obsahu „pravidelného testování“ a jeho rozsahu. V jakém časovém údobí má být prováděno toto „pravidelného testování“ – po celou dobu 60 měsíců záruční doby, tj. celkem 20 krát ? ODPOVĚĎ: Obsah pravidelného testování bude vycházet z úvodní analýzy a charakteru vysoutěžených produktů. Předpokládáme, že toto testování bude probíhat v rozsahu minimálně 2 čld (2 x 8 hodin), vždy jednou za 3 měsíce. Testování se týká celé doby udržitelnosti projektu, zadavatel si však vyhrazuje právo testování v době udržitelnosti omezit.
-
záruka na plnou funkčnost vytvořeného systému po dobu 5 let od předání díla; rychlost reakce v případě ohlášení poruchy max. do 24 hodin od nahlášení závady sankci 5.000,- Kč za každý den nedodržení lhůty na plnění dle harmonogramu projektu; DOTAZ č. 17: Tento požadavek je nesmyslný s ohledem na neuvedení požadovaného termínu plnění veřejné zakázky! Vůči kterému termínu plnění by se odvozovaly sankce ? ODPOVĚĎ: Sankce se budou logicky odvozovat od termínů plnění zakázky uvedených ve smlouvě uzavřené s dodavatelem.
Příloha č. 2 2. A. Technická specifikace díla, část I – Infrastruktura („Technologické centrum“)
1. B. Technická specifikace díla, část II – Elektronická spisová služba s vlastnostmi DMS
2. C. Technická specifikace díla, část III – Vnitřní integrace Obecné požadavky •
otevřené řešení s co nejširší provázaností funkcí a procesů jednotlivých agend a modulů nabízeného Systému mezi sebou i se svým okolím, provázanost s aplikacemi MS Office (Word, Excel, Outlook)
strana 7 z 17
•
třívrstvá architektura řešení, s možným dalším členěním do více vrstev (klient server, možnost dedikovaných serverů pro databáze, aplikace, s provozem v připravovaném technologickém centru) s minimální instalací klientské části řešení na pracovních stanicích
DOTAZ č. 18: Prosíme o vysvětlení, do jakých dalších vrstev má být členěna třívrstvá architektura. ODPOVĚĎ: V budoucnu může být s ohledem na rozvoj technologií požadováno např. členění uvedené na www.cleverandsmart.cz/vicevrstva-architektura-popis-vrstev •
rozšiřitelnost částí systému na městem zřízené organizace a na obce ve správním obvodu obce s rozšířenou působností Beroun, podpora výměny dat mezi Městským úřadem (dále jen „MěÚ“) a těmito subjekty, mezi MěÚ a nadřízenými orgány státní správy a mezi MěÚ a centrálním informačním systémem veřejné správy DOTAZ č. 19: Prosíme o uvedení počtu organizací, na které je požadováno rozšíření systému. ODPOVĚĎ: Tento počet není znám a bude vycházet ze zájmu těchto organizací využívat toto řešení. Požadujeme závazek, že takové řešení uchazeč akceptuje a bude schopen v budoucnu zajistit. DOTAZ č. 20: Prosíme o vysvětlení jaká data mají být vyměňována mezi MěÚ a nadřízenými orgány státní správy. Co představuje „centrální informační systém veřejné správy“ ? ODPOVĚĎ: Jedná se o data, která jsou/budou definována legislativními předpisy. Pojem „centrální informační systém veřejné správy“ představuje IS, jehož správcem je ministerstvo nebo jiný subjekt veřejné správy s celostátní působností a který je využíván i dalšími subjekty, v tomto případě městy, například vazby na garantované úložiště a státní archiv.
•
řešení poskytující tytéž funkčnosti a tutéž dostupnost bez ohledu na místo napojení a použitou technologii přístupu (LAN, WAN, VPN tunel)
•
možnost snadné konfigurace a přizpůsobení potřebám uživatelů (parametrizace, výstupy apod.)
•
garance stabilního vývojového a konzultačního týmu k poskytování kvalitních, včasných servisních služeb DOTAZ č. 21: Jakým způsobem má být tato garance provedena? ODPOVĚĎ: Způsob provedení garance je plně v kompetenci uchazeče.
•
respektování technologických i věcných souvislostí a provázaností dodávky s projektem z Výzvy č.06 Na rozvoj služeb eGovernmentu v obcích (Technologického centra obce s rozšířenou působností Beroun) a dalšími projekty, které budou v souladu s prosazováním eGovernmentu v území následovat
strana 8 z 17
DOTAZ č. 22: Prosíme o vysvětlení požadovaného závazku uchazeče ve smyslu tohoto požadavku. ODPOVĚĎ: Tento požadavek vychází z předpokladu podpory dalšího rozvoje služeb eGovernmentu. Závazek se týká ochoty a schopnosti dodavatele respektovat požadavky dané tímto rozvojem ve svém řešení po dobu udržitelnosti projektu. •
realizace dokončení workgroupového řešení MS Office systém implementací komunikačního serveru DOTAZ č. 23: Tento požadavek je nesrozumitelná a prosíme o důkladné vysvětlení. ODPOVĚĎ: Město řeší Back Office úřadu v prostředí MS server na úrovni serverů a MS Office na úrovni DeskTop. Nyní požaduje toto řešení doplnit o nativní komunikační server, který naplňuje podmínky plné integrace do řešení – viz odrážka níže, kde jsou uvedeny i počty uživatelů.
Technické požadavky •
Řešení bude postaveno modulárně dle principů třívrstvé architektury s minimální instalací klientské části řešení na pracovních stanicích.
•
Systém musí být sestaven jako otevřený systém, s popsaným integračním rozhraním, které umožní plnou integraci s dalšími aplikacemi a jejich on-line připojení. DOTAZ č. 24: Které „další aplikace“ mají být integrovány nebo jde pouze o garanci principu integrace ? ODPOVĚĎ: Každé implementované řešení musí mít známá rozhraní, nebo datový model, které umožňují vzájemnou integraci řešení a implementaci systémů hodnocení. Detailně je rozvedeno v kapitole 7.3.3.1. Popis současného stavu a požadavků.
•
Data budou uložena v relační databázi s podporou transakcí – součástí nabídky bude i doporučení databázového produktu včetně navržení počtu potřebných licencí a požadavky na technické parametry a softwarové součásti serveru a klientských PC.
•
Jednoduchá a přehledná administrace celého řešení,
•
Podpora provozu na DB informix – písemné potvrzení podepsané statutárním orgánem alespoň ze 2 ORP. DOTAZ č. 25: Uvedené požadavky jsou v přímém rozporu s požadavky uvedenými o dva body výše. Požadavek na konkrétní DB platformu včetně písemného potvrzení považujeme za skryté kvalifikační kritérium zvýhodňující konkrétní uchazeče. Je přípustné řešení splňující pouze jeden z těchto rozporných požadavků?
strana 9 z 17
ODPOVĚĎ: Zadavatel požaduje splnění obou podmínek. Požadavek vychází ze skutečnosti, že v současné době je IS Zadavatele provozován na DB prostředí Informix, a proto požadujeme tuto deklaraci. Zadavatel nevylučuje v budoucnu případnou migraci řešení na jinou DB platformu v rámci mimodotačního rozvoje. Tento bod se však vztahuje pouze k agendám IS. Stávající IS zůstane na Informixu, ostatní řešení mohou využívat např. SQL. Např. MS Office systém, kde komunikační server bude využívat vlastní databáze a portálové řešení. 1. Odpisy majetku Požadujeme rozšíření stávajícího MIS o Odpisy majetku. V současném systému je třeba rozšířit správu majetku o možnost odpisů dle požadavku legislativy. Integraci procesu správy majetku zařazením odpisů majetků do stávající aplikace Majetek, včetně potřebných vazeb. - Požadovaná funkčnost • plná integrace do stávajícího IS, primárně na stávající řešení agendy pro evidenci majetku. DOTAZ č. 26: Prosíme o uvedení detailních funkčních požadavků na integraci. ODPOVĚĎ: Požadovaná funkčnost je uvedená v rámci Přílohy č. 1 ZD – Studie proveditelnosti. 2. Evidence smluv Agenda bude sloužit pro centrální evidenci smluv města, členěno dle odborů a podle nastavení oprávnění. Musí umožnit evidenci všech druhů smluv (kupní, nájemní, smlouva o dílo, prodejní…); zápis doplňujících údajů ke smlouvě (kdo podepsal, datum příchodu a platnosti smlouvy..); vytváření dodatků k dané smlouvě; zápis finančních položek u příjmových a výdajových smluv. 2. Požadovaná funkčnost • vazba na finance; DOTAZ č. 27: Prosíme o uvedení detailních funkčních požadavků této vazby? Má vazba zahrnovat i vazby v oblasti pohledávek, závazků, rezervací, …..? ODPOVĚĎ: Požadujeme minimální splnění níže uvedených integračních prvků (tzn. dodání řešení včetně patřičných rozhraní, tj. včetně funkcí které lze obecně požadovat): • • • • • •
Výdaje Příjmy Prodej majetku Majetek Rozpočet Účetnictví
•
tisk smlouvy,
strana 10 z 17
• • • •
scanování smlouvy; tisk oběhového lístku; vazba na eSpSl, správa prostřednictvím jednotného řešení Identity management.
Centrální správa uživatelů (identity management) Správa uživatelů, jejich profilů a oprávnění je důležitým bodem pro efektivní fungování úřadu. Nastavení pravidel pro autorizaci, identifikaci a autentizaci konkrétního úředníka je zcela zásadní nejen pro bezpečnost vnitřního systému úřadu, ale také pro další činnosti ve vazbě na základní registry. Každý uživatel informačního systému úřadu by měl být jednoznačný z pohledu: •
oprávnění vykonávat danou působnost (tedy mimo jiné využívat k výkonu působnosti daný agendou informační systém a využívat případně editovat data v ní obsažená)
•
role v organizační struktuře daného orgánu veřejné moci ve vazbě na danou agendu a působnost (konkrétní systémová vazba agenda – působnost – organizační struktura – úředník)
•
rozsah přístupových práv v systému a evidence jeho vstupů do systému
Požadavky na funkčnost: •
plná integrovatelnost vůči stávajícímu řešení informačního systému, DOTAZ č. 28: Prosíme o detailní vysvětlení co má tato integrace řešit.
•
•
ODPOVĚĎ: Zadavatel v minulosti vynaložil finanční prostředky v rámci budování IS, a tudíž, pokud poptává rozšíření stávajícího IS a jeho integraci, požaduje i jeho propojení v těch oblastí, kde by nevyžádáním patřičných rozhraní došlo k navýšení zátěže uživatelů, a to v podobě výkonu duplicitních činností. Integrace, v tomto případě, řeší dodání segmentu IS, který bude integrovatelný vůči stávajícímu řešení v co nejširším spektru, zajistí co nejvyšší komfort pro uživatele a hlavně, zajistí veškeré legislativní povinnosti v uceleném řešení. Požadované funkcionality jsou mj. uvedeny v rámci Přílohy č. 1) ZD – Studie proveditelnosti. slouží k zajištění přihlašování a autentizaci uživatelů do všech aplikací prostřednictvím integrovaného systému přihlašování (Single-Sign-On) to i pro externí aplikace prostřednictvím XML rozhraní. správa uživatelských rolí aplikací včetně prezentačního portálu pro úředníky a občany, DOTAZ č. 29: Tento požadavek na „správa uživatelských rolí aplikací“ je nesrozumitelný a prosíme o jeho detailní vysvětlení. ODPOVĚĎ: Detailní vysvětlení pojmu „role“ je uvedeno v rámci Přílohy č. 1 ZD – Studie proveditelnosti.
strana 11 z 17
•
napojení agendových systémů na registr práv a povinností tak, že autorizuje úředníka z pohledu jeho role a oprávnění této role k výkonu konkrétní agendy dle Katalogu působností orgánů veřejné moci, jako součásti Registru práv a povinností. DOTAZ č. 30: Uveďte garanci k požadavku, který je závislý na funkčnosti systému Základních registrů. ODPOVĚĎ: Tento požadavek není Zadavatelem akceptován, přičemž Zadavatel na svém požadavku garance ve znění „napojení agendových systémů na registr práv a povinností tak, že autorizuje úředníka z pohledu jeho role a oprávnění této role k výkonu konkrétní agendy dle Katalogu působností orgánů veřejné moci, jako součásti Registru práv a povinností“ trvá.
Základní funkce aplikace • • • • • • • • •
Evidence organizační struktury Evidence pracovních pozic a vazba na katalog agend Hierarchické členění objektů Časová platnost objektů a vazeb Plánování budoucích změn Uchovávání historického stavu jednotlivých verzí organizační struktury platné v konkrétním čase Přiřazení činností pracovním pozicím Přiřazení pracovníků pracovním pozicím Jednoznačná identifikace uživatelského konta s vazbou na ROB DOTAZ č. 31: Prosíme o vysvětlení produktu/zkratky „ROB“. Pakliže se jedná o jeden ze základních registrů, v rámci jaké agendu se k němu bude přistupovat? ODPOVĚĎ: Používání zkratky „ROB“ je převzato z terminologie IS ZR. Vazba musí splňovat požadavky dané legislativou pro AIS a IS ZR.
•
Spolupráce s LDAP DOTAZ č. 32: Prosíme o vysvětlení co má tato spolupráce řešit. ODPOVĚĎ: Tato spolupráce má za úkol zajistit propojení s poptávaným produktem a stávajícím vybavením IS Zadavatele. Viz. Příloha č. 1 ZD – Studie proveditelnosti.
• •
Export dat Hromadné řízení uživatelských oprávnění
strana 12 z 17
DOTAZ č. 33: Prosíme o vysvětlení co je hromadné řízení uživatelských oprávnění. ODPOVĚĎ: Tímto pojmem se rozumí umožnit provádění hromadných operací v rámci administrace uživatelských oprávnění. Rozhraní na Základní registry Požadujeme autorizaci úředníka z pohledu jeho role, a oprávnění této role k výkonu konkrétní agendy dle Katalogu působností orgánů veřejné moci, jako součásti Registru práv a povinností. Úředníkovi bude umožněno tato ověření provádět vůči jednotlivým základním registrům právě v rozsahu jeho zákonného oprávnění se na tyto referenční údaje dotazovat, tedy na základě stanovené role ve veřejné správě. Proto je potřeba připravit definici a klasifikaci rolí tak, aby bylo možné tyto role zanést do Registru práv a povinnosti pro pokrytí všech činností vykonávaných v agendách OVM. DOTAZ č. 34: Tento požadavek je dle našeho názoru v přímém rozporu s principy fungování Základních registrů, zejména s principy registrace agend. Prosíme o vysvětlení záměru a požadavku zadavatele. ODPOVĚĎ: Zadavatel požaduje splnění legislativních povinností v rámci splnění předmětného požadavku. Následně dle těchto rolí upravit procesy uvnitř úřadu Města Beroun a v návaznosti také informační systémy úřadu nezbytné k zabezpečení těchto procesů. DOTAZ č. 35: Úprava procesů a návazných informačních systémů jsou součástí této zakázky ? ODPOVĚĎ: Procesy budou upraveny v rámci dodaného řešení a získáním metodik k jednotlivým produktům. To znamená, implementací tohoto rozhraní bude úřadem provozovaný agendový IS připraven ke komunikaci se Základními registry, CZECH Pointem a dalšími eGon službami umístěnými v Centrálním místě služeb státu. Portál občana – CzechPOINT@home Tímto projektem bude zahájeno řešení Portálu města, které bude dále v rámci dalších projektů rozšiřováno a plně provázáno na centrální systém úřadu. Požadované služby: - Přihlášení psa - s načtením dat z IS a následným vytěžením dat do IS - Odhlášení psa - s načtením dat z IS a následným vytěžením dat do IS - Komunální odpad - přihlášení poplatníka/plátce - s načtením dat z IS a následným vytěžením dat do IS - Komunální odpad - změna/odhlášení poplatníka/plátce - s načtením dat z IS a následným vytěžením dat do IS - Konto plátce - předpisy, platby, termíny splatností předpisů, dlužné částky - Komunální odpad - informace o občanovi strana 13 z 17
-
Evidence psů - aktuální stav
DOTAZ č. 36: Je součástí této zakázky také úprava na straně systémů, které tato data zpracovávají nebo je předmětem pouze poskytnutí dat pro zpracovávající systémy? Pakliže mají být předmětem i úpravy stávajících systémů, o které systémy se jedná? ODPOVĚĎ: Popis požadovaných funkcí a nároků na propojení je uveden v rámci Přílohy č. 1 ZD – Studie proveditelnosti. Cílovým stavem je on-line propojení na stávající agendové řešení agend Evidence psů, Komunální odpad a Příjmy tak, aby bylo možné tyto činnosti provádět on-line a zajistit tak možnost elektronické komunikace občana s OVM. Rozhraní registry x SVI Zajištění komunikačního rozhraní pro mezi současným řešení vrstvy registrů a projektem MVČR – systém včasné integrace. DOTAZ č. 37: Prosímo o detailní popis současného řešení vrstvy registrů. Jaká bude úloha této vrstvy po 1.7.2012 t.j. po spuštění Základních registrů, kdy začíná platit povinnost využití dat Základních registrů. Požadavek považujeme za velmi vágní a prosíme o jeho detailní vysvětlení. ODPOVĚĎ: Rozsah plnění bude vztažen k metodickým pokynům postupné implementace a rozvoji IS ZR. Technická podpora a údržba produktu Technická podpora zahrnuje: 1.
průběžné provádění inovace produktu, zejména update a legislativního update, upgrade a legislativního upgrade ve vazbě na vždy aktuálně platné právní předpisy,
2.
distribuci produktu upraveného za účelem legislativního update nebo legislativního upgrade bude provedena před termínem účinnosti změn právních předpisů,
3.
poskytování update a upgrade produktu dle potřeby vzniklé legislativními změnami a požadavky zadavatele či samostatnou, nevynucenou inovační činností dodavatele,
4.
provádění obecných změn produktu v důsledku vývoje HW a SW prostředků,
5.
distribuci nových verzí produktu zpřístupněním pokynů k jeho elektronickému stažení zadavatelem z datového úložiště dodavatele,
6.
distribuci nových verzí produktu uživatelům elektronicky; dodavatel zajistí takovou funkcionalitu produktu, která umožní jednorázové centrální automatizované provádění instalace nových verzí pro všechny instalované organizace využívající hostovanou spisovou službu, strana 14 z 17
7.
službu Hot-line formou telefonické podpory pro zaměstnance zadavatele pro řešení technických problémů, poradenství a konzultace,
8.
službu HelpDesk pro zaměstnance zadavatele pro hlášení závad dle jednotlivých kategorií, řešení technických problémů, poradenství a konzultace.
V případě potřeby bude dodavatel v průběhu provozu produktu povinen jednorázově zajistit potřebnou součinnost při přesunu produktu a dat na jinou technickou infrastrukturu a to bezúplatně. DOTAZ č. 38: Jak častou „součinnost“ má zadavatel na mysli v průběhu 60 měsíční záruční lhůty? Předpokládá se jednorázový výkon nebo kolik přesunů má zadavatel na mysli? ODPOVĚĎ: Kdykoliv Zadavatel o takovou aktivitu v rámci technické podpory a údržby produktu zažádá, bude uchazeč povinen tuto služby bezúplatně zajistit. Technická podpora bude poskytována od počátku ověřovacího provozu po celou dobu účinnosti smlouvy. Údržba zahrnuje: 1. 2. 3. 4. 5. 6.
administraci produktu (tj. nastavení a správa uživatelů, jejich profilů a oprávnění), instalaci a konfiguraci produktu a nových verzí v rámci legislativního update a upgrade a vlastní inovační činnosti dodavatele. řešení provozních problémů vzniklých při užití produktu zadavatelem a jednotlivými organizacemi, řešení provozních problémů vzniklých při užití produktu na pracovišti zadavatele a organizací, službu Hot-line formou telefonické podpory pro jednotlivé organizace pro řešení technických problémů, poradenství a konzultace, službu HelpDesk pro zaměstnance jednotlivých organizací pro hlášení závad jednotlivých kategorií, poradenství a konzultace.
Údržba bude dodavatelem poskytována od počátku ověřovacího provozu po celou dobu účinnosti smlouvy. Služby administrace, a konfigurace produktu podle prvních dvou bodů zajišťuje dodavatel po dobu trvání ověřovacího provozu a služby instalace jen do ukončení zkušebního provozu. Podrobná a závazná specifikace pro poskytování technické podpory a údržby a požadavků na službu HelpDesk jsou uvedeny v příloze č. 4 k návrhu smlouvy (Specifikace reakčních dob servisního zásahu – SLA) a příloze č. 3 k návrhu smlouvy (Podmínky poskytování služeb HelpDesk a Hot-line) této zadávací dokumentace. Další služby Dalšími službami se rozumí:
strana 15 z 17
1.
vytvoření a dodání (tj. včetně instalace a konfigurace) update a upgrade produktu na základě požadavku zadavatele, s výjimkou update a upgrade spadajícího pod technickou podporu, 2. vypracování metodik pro zpracování dat, 3. analytické a návrhové práce v oblasti datových modelů, 4. záchrana a obnova dat, 5. školení osob určených zadavatelem na administraci produktu, vedoucí k seznámení s celkovou strukturou, užitými technologiemi, 6. školení osob určených zadavatelem na obsluhu produktu, vedoucí k samostatnému, správnému a efektivnímu užití produktu, 7. poskytování rad ke správnému a efektivnímu provozování a užití všech již dodaných produktů, 8. konzultace nespadající pod technickou podporu nebo údržbu, 9. osobní zásah nebo asistence zaměstnance dodavatele na pracovišti zadavatele, 10. odstraňování vady produktu vzniklé z důvodů na straně zadavatele. DOTAZ č. 39: Zde požadujeme vyspecifikovat rozsah tzv. „dalších“ služeb. ODPOVĚĎ: Rozsah dalších služeb není omezen, tudíž platí minimálně v tomto rozsahu. Všechny výše uvedené služby bude dodavatel zadavateli poskytovat na základě písemných objednávek zadavatele. Dodavatel bude povinen na základě požadavku zadavatele zpracovat způsob realizace služby a časový harmonogram jejich provádění. Dodavatel je povinen se zadavatelem projednat a odsouhlasit počet hodin potřebný k realizaci a cenu služby. Plnění bude potvrzováno na dodacím listě, jehož kopie je nezbytnou přílohou faktury. Potvrzují a hradí se pouze skutečně provedená plnění.
DOTAZ č. 40: V ZD je požadována migrace dat a programového vybavení ze stávajícího HW vybavení do nového virtualizovaného prostředí technologického centra, 3x Windows Server 2003 SE OEM, 1x Windows Server 2008 OEM. Tj. 4 WIN servery. Zároveň je poptáván virtualizační nástroj umožňující virtualní clustering a počet Win licencí v rozsahu minimálně 4 virtuálních serverů s operačním systémem WIN server 2008. Protože OEM verze jsou nepřenositelné a licenční podmínky Microsoftu vyžadují v případě virtuálního clusteru pokryti WIn serveru jak na straně aktivní, tak na straně případné migrace virtualního serveru, je nutné pro správné zalicencování popsaného prostředí minimálně 2 ks Win serveru 2008, každý v rozsahu min 4 virtuální win servery. Má byt tento druhy win server 2008 enterprise součástí dodávky nebo bude financován z jiných zdrojů? ODPOVĚĎ: Ano - zadavatel požaduje, aby byl i druhý Windows server 2008 zalicencován a aby byl součástí dodávky.
Důležité upozornění:
strana 16 z 17
Vzhledem k rozsahu dodatečných informací vyžádaných jedním z uchazečů v poslední den lhůty rozhodl se zadavatel v souladu s ustanovením § 40 odst. 6 zákona přiměřeně prodloužit lhůtu pro podání nabídek pro předmětnou veřejnou zakázku, a to do 31. ledna 2012 ve 14:00. Zadávací dokumentace se proto mění v dotčených bodech takto: 19. Způsob, doba a místo podání nabídek, zadávací lhůta a.
Uchazeči podají písemnou nabídku v řádně uzavřené obálce, zabezpečené na přelepu proti otevření, a to buď doporučeně poštou na adresu:
Český a moravský účetní dvůr Masarykovo nám. 1484; 530 02 PARDUBICE nebo osobně na stejnou adresu (nejlépe po telefonické dohodě na tel. čísle 724935700) do kanceláře společnosti Český a moravský účetní dvůr, s.r.o., 6. patro, kancelář č. 603 případně kancelář č. 601. b. Nabídka bude označena nápisem: NEOTEVÍRAT! VEŘEJNÁ ZAKÁZKA
„„Město Beroun – Rozvoj služeb eGovernementu obce s rozšířenou působností a v obcích správního obvodu ORP““ c.
Nabídky podané po uplynutí lhůty pro podání nabídek komise neotevírá. Pověřená osoba o této skutečnosti bezodkladně vyrozumí uchazeče. Rozhodující je datum a čas přijetí nabídky na adresu osoby pověřené.
d. Lhůta pro podání nabídek končí dne 31.1. 2012 ve 14:00 hod. e.
Zadávací lhůta, tj. minimální doba, po kterou je uchazeč svou nabídkou vázán, je 90 dnů od uplynutí lhůty pro doručení nabídky.
20. Otevírání obálek s nabídkami a. Obálky s nabídkami budou otevírány dne 1. února 2012 v 10:00 v sídle zadavatele – budova radnice Husovo náměstí 68, Beroun – v zasedací místnosti vedle obřadní síně, 2. patro, č. dveří A 306. Ostatní ustanovení zadávací dokumentace se nemění. V Pardubicích, 6. ledna 2012 Ing. Jana Dvořáková, pověřená administrací veřejné zakázky
strana 17 z 17
