Procurement observatory.

<!-- PAGE 1 --># VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE 01, 02 a 03

## IDENTIFIKACE ZAKÁZKY A ŘÍZENÍ

Název zakázky

**Centralizační platforma vzdálené správy parkovacích objektů**

Druh zakázky služby Režim zakázky nadlimitní Druh řízení otevřené řízení URL na profilu zadavatele https://nen.nipez.cz/verejne-zakazky/detail-zakazky/N006-26- V00002754

## IDENTIFIKACE ZADAVATELE

Název

**Technická správa komunikací hl. m. Prahy, a.s.**

Sídlo Veletržní 1623/24, 170 00 Praha 7 IČO 03447286 Profil zadavatele https://nen.nipez.cz/profil/TSK

## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 1.4.2026

**DOTAZ Č. 1**

Správa uživatelů a rolí: webové nebo administrátorské rozhraní? Příloha č. 2A, bod 3 uvádí, že CP musí umožňovat nastavení uživatelských práv, definování rolí a přidělování oprávnění jednotlivým uživatelům, přičemž ZD výslovně uvádí: „Objednatel může objednat nastavení rolí a práv prostřednictvím ad-hoc služeb." Žádáme Zadavatele o potvrzení, zda toto ustanovení znamená, že:

1. Samoobslužná správa uživatelů přímo ve webovém prohlížeči (zakládání účtů, přiřazování rolí, nastavení oprávnění na úrovni jednotlivých úkonů) není povinnou součástí dodávky webové CP a Dodavatel může tuto správu zajistit prostřednictvím jiného nástroje nebo adhoc servisního modelu?
2. Nebo naopak Zadavatel trvá na tom, aby veškerá správa uživatelů byla realizována výhradně jako samoobslužná funkce přímo v prostředí webového prohlížeče v rámci webové CP? Odůvodnění dotazu: Webové administrátorské rozhraní výrazně zvyšuje rozsah a cenu implementace, přičemž ZD samo uvádí ad-hoc servisní model jako přijatelnou variantu. Potvrzení umožní přesnější ocenění nabídky.

<!-- PAGE 2 -->**REAKCE NA DOTAZ Č. 1**

Odpověď na dotaz č. 1 a) Samoobslužná správa uživatelů přímo ve webovém prohlížeči je povinnou součástí funkcionalit dodávané webové centralizační platformy (CP). Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Dodavatel nemůže tuto povinnou součást CP správu zajistit jiným způsobem, např. prostřednictvím jiného nástroje nebo prostřednictvím ad-hoc služeb. Prvotní nastavení uživatelských rolí provede Dodavatel pro zahájení zkušebního a běžného provozu jako součást činností s tím spojených. Zadavatel zároveň počítá s tím, že informace o tom, jak bude nadále Zadavatel role nastavovat a spravovat, bude součástí nadstavbového školení pro role manažer a administrátor. Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat nastavení rolí a práv prostřednictvím ad-hoc služeb, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Odpověď na dotaz č. 1 b) Jak uvádí odpověď na dotaz č. 1 a) výše, Zadavatel výslovně požaduje, aby veškerá správa uživatelů byla realizována jako součást dodávané CP. Ze strany Zadavatele ale správa uživatelů vlastními pracovníky ale není jedinou možnou variantou. Jak uvedeno výše v 1a), Zadavatel může u Dodavatele nastavení uživatelských rolí objednat, pokud se tak rozhodne. Postup objednání se řídí postupem objednávání ad-hoc služeb.

**DOTAZ Č. 2**

Zakládání objektů, plánků a prvků: povinná samoobsluha nebo ad-hoc služba? Příloha č. 2A, body 4, 5 a 6 uvádějí, že CP musí umožňovat zakládání lokalit, nahrávání plánků a vkládání či editaci technologických prvků. ZD přitom u všech tří požadavků výslovně uvádí: „Po dobu trvání smlouvy je možnou variantou objednávka výše uvedených úkonů v rámci ad-hoc služeb." Žádáme Zadavatele o upřesnění:

1. Je samoobslužná editace těchto prvků přímo ve webovém prohlížeči povinnou součástí dodávky, nebo postačuje model, kdy prvotní konfiguraci provede Dodavatel v rámci implementace a následné změny Objednatel objednává jako ad-hoc službu?
2. Pokud je webová editace plánků povinná — v jakém formátu bude Objednatel plánky do CP vkládat a jaké jsou požadavky na editor (například přetahování prvků na plánku, definice zón apod.)?

**REAKCE NA DOTAZ Č. 2**

Odpověď na dotaz č. 2 a) Samoobslužná správa, editace a doplňování jednotlivých objektů (lokalit), technologických prvků a vybraných zařízení přímo ve webovém prohlížeči je povinnou součástí funkcionalit dodávané webové centralizační platformy (CP). Dodavatel provede prvotní konfiguraci pro zahájení zkušebního a běžného provozu jako součást činností s tím spojených. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Zadavatel zároveň počítá s tím, že informace o tom, jak bude nadále provádět správu, zakládání a editaci objektů (lokalit), technologických prvků a vybraných zařízení přímo v CP bude součástí základního a nadstavbového školení. Doptávaná varianta prvotní konfigurace provedené Dodavatelem a objednávání následných změn formou adhoc služeb není přípustný.

<!-- PAGE 3 -->Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat založení a editaci lokalit, prvků a zařízení, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Odpověď na dotaz č. 2 b) K formátům obrázků Zadavatel v bodě 4. Přílohy 2A Zadávací dokumentace uvádí: „Plánky budou vkládány jako obrázky (formáty jpeg a pdfpovinně, případně další standardně používané formáty)". Na základě dotazu Zadavatel zpřesňuje popis takto: „Plánky budou vkládány jako obrázky (formáty jpeg nebo png povinně, případně další standardně používané formáty)". Požadavky na editaci uvádějí body 4., 5. a 6. přílohy 2A ZD. Přetahování prvků na plánku je součástí editace. Stejně je třeba počítat s tím, že objekt může být vícepodlažní a je třeba zobrazit plánky všech podlaží, případně i okolí objektu, kde jsou umístěny prvky (např. informace o obsazenosti). Zadavatel předpokládá, že Dodavatel má s obdobnými dodávkami zkušenosti a dodávaný systém CP tedy obsahuje praktické a účelné funkcionality, které lze při správě a provozu parkovacích objektů očekávat. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení.

**DOTAZ Č. 3**

Konfigurace akčních pokynů: webová editace nebo ad-hoc služba? Příloha č. 2A, body 11 a 16 uvádějí, že CP umožní Objednateli upravovat způsob upozornění a akční pokyny pro obsluhu. ZD zároveň u těchto požadavků uvádí: „Po dobu trvání smlouvy je možnou variantou objednávka výše uvedených úkonů v rámci ad-hoc služeb." Žádáme Zadavatele o potvrzení:

1. Je editace akčních pokynů a nastavení způsobu upozornění přímo ve webovém prohlížeči povinnou součástí dodávky, nebo postačuje, aby tuto konfiguraci prováděl Dodavatel na základě písemné objednávky Objednatele v rámci ad-hoc služeb?
2. Pokud je webová editace povinná — jaký je požadovaný formát a způsob zadávání akčních pokynů (textové pole, krokovaný průvodce, šablony apod.)?

**REAKCE NA DOTAZ Č. 3**

Odpověď na dotaz č. 3 a) Samoobslužná editace pokynů a nastavení způsobu upozornění je povinnou funkcionalitou dodávané CP. Konfigurace na základě objednávky ad-hoc služeb jako výlučné řešení nabízení Uchazečem nepostačuje. Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat nastavení úkonů prostřednictvím ad-hoc služeb, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Odpověď na dotaz č. 3 b) Zadavatel předpokládá, že Dodavatel má s obdobnými řešeními zkušenosti a dodávaný systém CP tedy obsahuje praktické a účelné nástroje, které lze při správě a provozu parkovacích objektů očekávat. Zadavatel očekává návrh řešení, které je ověřené praxí a které Dodavatel popíše a vysvětlí. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Konkrétní nastavení bude součástí Implementačního projektu.

<!-- PAGE 4 -->**DOTAZ Č. 4**

API dokumentace systému Green Center: rovné podmínky pro uchazeče Příloha č. 2A, bod 2 uvádí: „Popis rozhraní bude předán po podpisu smlouvy s dodavatelem CP." Zadavateli je zřejmě znám obsah rozhraní systému Green Center, neboť společnost Green Center s.r.o. se zúčastnila předběžné tržní konzultace (PTK) jako potenciální dodavatel a s největší pravděpodobností Zadavateli rozhraní svého systému prezentovala. Ostatní uchazeči o tuto zakázku přitom k API dokumentaci přístup nemají. Tato situace znevýhodňuje uchazeče, kteří nejsou provozovatelem systému Green Center, neboť nemohou realisticky ocenit integrační práce. Konkrétně: není znám datový model API (formát parkovacích událostí, plateb, parkovacích karet, dokladů, výčetek hotovosti), není potvrzeno, která z požadovaných datových sad je přes API Green Center vůbec dostupná, není znám protokol, autentizační model ani způsob připojení. Žádáme Zadavatele, aby před termínem podání nabídek zpřístupnil všem uchazečům:

1. Dokumentaci rozhraní systému Green Center (nebo ekvivalentní technickou dokumentaci systémů instalovaných na jednotlivých lokalitách), kterou Zadavatel obdržel v rámci předběžné tržní konzultace.
2. Potvrzení, která z níže uvedených datových sad je prostřednictvím rozhraní systému Green Center dostupná: parkovací události (vjezd, výjezd, délka parkování), záznamy o platbách, parkovací karty a dlouhodobá oprávnění, doklady o platbě (účtenky, lístky), výčetky aktuálního stavu hotovosti v automatických pokladnách.
3. Sdělení, která z výše uvedených dat jsou dostupná pouze přímým přístupem k databázi nebo prostřednictvím proprietárního protokolu — a zda Zadavatel tuto formu integrace považuje za součást předmětu plnění.

**REAKCE NA DOTAZ Č. 4**

Odpověď na dotaz č. 4 a) Zadavatel neobdržel v rámci PTK popis API od žádného z účastníků. Dokumentaci rozhraní parkovacího systému Green Center a specifikaci rozhraní kamerových systémů obdrží vybraný Uchazeč při podpisu smlouvy. Zadavatel uvádí, že v případě parkovacího systému se jedná o standardní RestAPI, které bude komunikovat data obecně popsaná v zadávací dokumentaci. Jedná se o data běžně evidovaná standardními parkovacími systémy. Odpověď na dotaz č. 4 b) Datové sady jsou dovoditelné ze zadávací dokumentace. Nejsou vázány na jednoho dodavatele parkovacího systému. Vámi uvedené sady jsou typicky poskytované. V rámci implementačního projektu bude dále upřesněno. V průběhu trvání smlouvy předpokládáme integraci dalších technologií, které budou mít shodnou základní logiku ohledně rozhraní a komunikovaných dat. Odpověď na dotaz č. 4 c) Data budou dostupná prostřednictvím komunikačních rozhraní – viz příloha č. 2B ZD. Součástí předmětu plnění je zajištění komunikace CP s těmito rozhraními.

<!-- PAGE 5 -->**DOTAZ Č. 5**

Parkovací karty: evidenční systém a požadovaný rozsah funkce Příloha č. 2A, bod 22 uvádí evidenci a vyhledávání parkovacích karet a oprávnění podle registrační značky vozidla, čísla karty, jména a objektu. Žádáme Zadavatele o upřesnění:

1. Jsou parkovací karty (dlouhodobá parkovací oprávnění) evidovány přímo v systému Green Center a dostupné prostřednictvím jeho rozhraní?
2. Nebo jsou evidovány v jiném systému TSK (například v systému správy smluv, interní databázi nebo jiném evidenčním nástroji)?
3. Má CP pouze zobrazovat a vyhledávat existující záznamy z evidenčního systému, nebo také zakládat, editovat a rušit parkovací karty?
4. Může Zadavatel upřesnit datovou strukturu záznamu o parkovací kartě — zobrazení v CP požadována?

**REAKCE NA DOTAZ Č. 5**

Odpověď na dotaz č. 5 a) Ano. Odpověď na dotaz č. 5 b) V budoucnu mohou být evidovány i v jiném systému než namísto do databáze Green Center do databáze jiného dodavatele parkovací technologie nebo databáze TSK. Přechod na evidenci dalšími systémy bude předmětem ad Odpověď na dotaz č. 5 c) Ano, pouze vyhledávat a zobrazovat existující záznamy o parkovacích kartách (dlouhodobých parkovacích oprávněních) z evidenčního systému integrovaného do CP. Odpověď na dotaz č. 5 d) Datová struktura je dovoditelná ze zadávací dokumentace. Není parkovacího systému a musí poskytovat pro Objednatele informace rozhodné pro ověření platnosti karty v případě dotazu klienta na pracoviště centrální správy parkovacích objektů provozované TSK. Základní sada dat, kterou očekáváme komunikovat je: ID karty, Lokalita platnosti, Platnost od, Platnost do, Vlastník + RZ oprávněných vozidel, Datum a čas posledního Očekáváme, že Dodavatel pracuje v rámci svého řešení se sadou dat, která odpovídá potřebám vzdálené správy parkovacích objektů a nejlepší možné praxi. Konkrétní řešení bude předmětem nabídky Uchazeče, v rámci další zpřesnění.

**DOTAZ Č. 6**

Doklady o platbě: dostupnost a formát v systému Green Center Příloha č. 2A, bod 23 uvádí zobrazení, tisk a export dokladů o platbě včetně vystavení kopie nebo duplikátu. Žádáme Zadavatele o upřesnění:

1. Jsou doklady o platbě (parkovací lístky, účtenky z automatických pokladen) ukládány v centrálním systému Green Center ve strojově čitelné podobě, nebo jsou generovány a tisknuty výhradně lokálně na místě platby?
2. Poskytuje rozhraní systému Green Center přístup k jednotlivým dokladům — jako strukturovaná data umožňující rekonstrukci dokladu?

jaká pole jsou pro

Green Center. CP se pak bude dotazovat do

- \-hoc služeb. vázána na jednoho dodavatele vjezdu/výjezdu, Poznámka implementačního projektu lze očekávat

ve formátu PDF nebo

<!-- PAGE 6 -->1. Pokud doklady nejsou v systému Green Center centrálně uloženy — jak Zadavatel představuje splnění tohoto požadavku technicky?

**REAKCE NA DOTAZ Č. 6**

Odpověď na dotaz č. 6 a) Doklady jsou ukládány v parkovacím systému GREEN CENTER jako strukturovaná data. V budoucnu mohou být evidovány i v jiném parkovacím systému, který bude do CP integrován. Odpověď na dotaz č. 6 b) V parkovacím systému Green Center jsou doklady ukládány ve formě strukturovaných dat, která umožňují rekonstrukci dokladu. Odpověď na dotaz č. 6 c) Bezpředmětné – jsou centrálně uloženy, jak popisují odpovědi 6 a) a 6 b) výše.

**DOTAZ Č. 7**

Výčetka stavu hotovosti: dostupnost dat Příloha č. 2A, bod 24 uvádí zobrazení výčetky aktuálního stavu hotovosti v automatických pokladnách. Žádáme Zadavatele o upřesnění:

1. Je aktuální stav hotovosti v automatických pokladnách přístupný prostřednictvím rozhraní systému Green Center?
2. Pokud ano — v jakém formátu a s jakou frekvencí aktualizace jsou tato data dostupná?
3. Pokud ne — jakým způsobem Zadavatel předpokládá, že CP tato data získá?

**REAKCE NA DOTAZ Č. 7**

Odpověď na dotaz č. 7 a) Ano, aktuální stav hotovosti v automatických pokladnách je přístupný prostřednictvím rozhraní systému GREEN CENTER. Odpověď na dotaz č. 7 b) V parkovacím systému Green Center jsou doklady ukládány ve formě strukturovaných dat, která umožňují zobrazení informace o aktuálním stavu. Tj. frekvence je bezpředmětná. Odpověď na dotaz č. 7 c) Bezpředmětné – viz odpověď 7 a).

**DOTAZ Č. 8**

ServiceDesk: potvrzení, že jde o nástroj Dodavatele, nikoli modul CP Smlouva v čl. 6.4 a čl. 13.1 stanoví, že Dodavatel je povinen zajistit a Objednateli zpřístupnit ServiceDesk. Zadavatel i Dodavatel tak ServiceDesk vnímají jako nástroj na straně Dodavatele, ke kterému Objednatel přistupuje, přičemž ServiceDesk není součástí samotné CP. Žádáme Zadavatele o potvrzení:

1. ServiceDesk pro evidenci a řešení incidentů je nástroj provozovaný Dodavatelem (například specializovaný software třetí strany — Jira, Freshdesk nebo vlastní řešení), ke kterému Objednatel přistupuje prostřednictvím odkazu nebo jiného způsobu přístupu, a není požadován jako modul integrovaný přímo do webového rozhraní CP?

<!-- PAGE 7 -->1. Jakým způsobem bude Objednatel do ServiceDesku přistupovat — aplikace, e-mail?
2. Jsou pro ServiceDesk stanoveny konkrétní technické nebo funkční požadavky (například povinné rozhraní, formát exportu dat, integrace s MQTT nebo jinými systémy TSK)?

**REAKCE NA DOTAZ Č. 8**

Odpověď na dotaz č. 8 a) Ano. ServiceDesk slouží k evidenci a řešení incidentů centralizační platformy, který dodá Dodavatel v rámci plnění smlouvy, a na své náklady ho bude pod dobu trvání smlouvy provozovat. Předpokládá se přístup prostřednictvím webové služby, přístup udělí Dodavatel osobám, které Objednatel určí. Jako modul integrovaný do CP bude dodána Servisní kniha (viz bod 18 přílohy 12A ZD) V praxi pak pracovník Objednatele zapíše do Servisní knihy také incident Současně pak zapíše incident také do ServiceDesk Dodavatele. Ten může být (a pro Objednatele by to bylo praktické) napojen na Servisní knihu, ze které je možné poslat záznam Konkrétní řešení bude popsáno v nabídce Uchazeče. Dále pak bude řešeno v projektu. Odpověď na dotaz č. 8 b) Základní forma přístupu do ServiceDesk bude prostřednictvím webové aplikace (dostupné z mobilního telefonu). Možnost zaslat e-mail nebo zatelefonovat se předpokládá. Konkrétní řešení bude popsáno v nabídce Uchazeče. Dále pak bude řešeno v projektu. Odpověď na dotaz č. 8 c) Zadávací dokumentace konkrétní ani funkční požadavky nestanovuje, nicméně musí splnit požadavky uvedené zejména v čl. 6.4. a 13.1. Smlouvy. Dále pak bude řešeno v rámci implementačního projektu.

**DOTAZ Č. 9**

Intercom: typ zařízení a komunikační protokol Příloha č. 2C (osnova školení, bod 39) uvádí komunikaci s klientem v objektu prostřednictvím intercomu jako součást výuky. Žádáme Zadavatele o upřesnění:

1. Jaký typ intercomového zařízení je instalován v parkovacích objektech TSK (výrobce, model)?
2. Jaký komunikační protokol tato zařízení podporují (SIP/VoIP, ONVIF, vlastní HTTP rozhraní)?
3. Je intercom propojen se systémem Green Center, nebo funguje jako samostatný systém?
4. Je k dispozici technická dokumentace stávajících intercomů nebo kontakt na jejich správce?
5. Má CP realizovat obousměrnou hlasovou komunikaci přímo ve webovém prohlížeči (například prostřednictvím WebRTC nebo SIP přes WebSocket), nebo postačuje jiný způsob zprostředkování hovoru?

**REAKCE NA DOTAZ Č. 9**

Odpověď na dotaz č. 9 a) Intercom instalovaný na parkovacích objektech, které budou integrovány do CP bude samostatný systém neintegrovaný do CP. Informace nesdělujeme, je pro nabídku uchazeče bezpředmětná integroval, bude předmětem ad o konkrétních typech instalovaných na parkovacích objektech . Pokud by se v budoucnu do CP systém intecomu

- \-hoc plnění.

webový prohlížeč, mobilní

. na centralizační platformě. do ServiceDesk. rámci implementačního PC i rámci implementačního

<!-- PAGE 8 -->V případě školení bude pouze simulováno volání prostřednictvím intercomu a školený pracovník na základě této komunikace bude hledat potřebné informace v CP. Odpověď na dotaz č. 9 b) Bezpředmětné, viz odpověď 9 a). Odpověď na dotaz č. 9 c) Intercom instalovaný na parkovacích objektech, které budou integrovány do CP, bude vždy samostatný systém neintegrovaný do CP, ať se jedná o jakéhokoliv výrobce. Odpověď na dotaz č. 9 d) Není. Je bezpředmětné vzhledem k tomu, že se jedná se o telefonické spojení, kdy příjem hovoru je prostřednictvím telefonu obsluhy, tedy mimo CP. Odpověď na dotaz č. 9 e) Viz odpověď č. 9 c)

**DOTAZ Č. 10**

Omezení přístupu pomocí seznamu povolených IP adres: úroveň implementace Příloha č. 2A, bod 1 uvádí omezení přístupu k CP prostřednictvím seznamu povolených IP adres (whitelistu). Žádáme Zadavatele o upřesnění:

1. Je požadováno, aby seznam povolených IP adres byl konfigurovatelný přímo v administrátorském rozhraní CP — tj. aby jej správce CP mohl upravovat prostřednictvím webového uživatelského rozhraní?
2. Nebo postačuje, aby seznam povolených IP adres byl konfigurován na úrovni síťové a proxy infrastruktury Dodavatele (firewall, reverzní proxy), bez přístupu Objednatele ke konfiguraci tohoto seznamu?
3. Jak Zadavatel řeší přístup mobilních uživatelů s dynamickou IP adresou (například manažer přistupující z notebooku mimo kancelář TSK)?

**REAKCE NA DOTAZ Č. 10**

Odpověď na dotaz č. 10 a) Ano, je požadováno, aby seznam povolených IP adres byl konfigurovatelný přímo v CP, tj. aby jej Zadavatel mohl upravovat přímo prostřednictvím webového rozhraní. Zadavatel požaduje, aby řešení zajišťovalo bezpečnostní opatření řízení přístupu k CP jen pro povolené IP adresy a je na Dodavateli, jaký způsob zvolí a bude garantovat jeho plnou funkčnost a ochranu CP před komunikací z ostatních, tj. nepovolených IP adres. Odpověď na dotaz č. 10 b) Viz odpověď č. 10 a) Odpověď na dotaz č. 10 c) Uživatel Zadavatele, který pracuje vzdáleně (mimo kanceláře a objekty Zadavatele) přistupuje do interního perimetru výhradně prostřednictvím VPN připojení. Přistup do externích systémů nebo aplikací, které má Zadavatel umístěné mimo interní perimetr (hosting, cloudová prostředí apod.), je následně řízen přes konkrétní vybrané IP adresy Zadavatele, které tak provozovatelé pro přístup do externích systémů a aplikací nastaví jako povolené.

<!-- PAGE 9 -->**DOTAZ Č. 11**

Zákon o kybernetické bezpečnosti: rozpor v citaci zákona a rozsah povinností V zadávací dokumentaci byl zjištěn věcný rozpor v citaci právních předpisů týkajících se kybernetické bezpečnosti: Hlavní text ZD, Příloha č. 2A, bod 25 odkazuje na zákon č. 264/2025 Sb. o kybernetické bezpečnosti a vyhlášku č. 409/2025 Sb. o bezpečnostních opatřeních. Příloha č. 5 ZD (formulář popisu technického řešení dodavatele) odkazuje na zákon č. 181/2014 Sb. o kybernetické bezpečnosti a vyhlášku č. 82/2018 Sb. Tyto předpisy jsou obsahově odlišné, přičemž zákon č. 181/2014 Sb. byl zákonem č. 264/2025 Sb. nahrazen. Žádáme Zadavatele o upřesnění:

1. Která právní úprava je pro plnění smlouvy závazná — zákon č. 181/2014 Sb. nebo zákon č. 264/2025 Sb.?
2. Je Příloha č. 5 ZD v odkazu na právní předpisy neaktuální, a bude opravena nebo nahrazena?
3. Je TSK jako provozovatel CP klasifikována jako regulovaná služba v režimu vyšších nebo nižších povinností podle zákona č. 264/2025 Sb.?
4. Jaká konkrétní bezpečnostní opatření jsou požadována přímo od Dodavatele jako poskytovatele služby v modelu SaaS (například hlášení incidentů, penetrační testování, bezpečnostní dokumentace)?
5. Je soulad s příslušnými právními předpisy součástí akceptačních kritérií, nebo se jedná o průběžnou povinnost po dobu trvání smlouvy?

**REAKCE NA DOTAZ Č. 11**

Odpověď na dotaz 11 a) Závazná je platná právní úprava (zákon č. 264/2025 Sb.). Odpověď na dotaz 11 b) Příloha č. 5 ZD bude zachována, protože v bodě 25 uvádí, že bude zajištěn soulad s tam uvedenými právními předpisy (zákon č. 181/2014 Sb. vyhláška č. 82/2018 Sb.) nebo s předpisy nahradí. Je tak zřejmé, že se použijí aktuálně platné předpisy nahradily. Odpověď na dotaz 11 c) Jedná se o regulovanou službu v režimu vyšších povinností. Odpověď na dotaz 11 d) Konkrétní bezpečnostní opatření vyplývají zejména z Odpověď na dotaz 11 e) Soulad s právními předpisy v oblasti kyberbezpečnosti je požadován po celou dobu trvání smlouvy – v době akceptace, tak v průběhu navazujícího trvání smlouvy. Konkrétní akceptační scénáře/kritéria budou předmětem implementačního projektu. Cílem je prověřit splnění požadavků Zadavatele.

**DOTAZ Č. 12**

Uchování dat po dobu dvou let: rozsah a datový objem Příloha č. 2A, body 7 a 17–24 uvádějí uchovávání dat po dobu minimálně dvou let. Žádáme Zadavatele o upřesnění:

předpisy, které uvedené právní předpisy, které specifikované právní přílohy č. 2A, 9A a 9B závazného návrhu smlouvy. jak

<!-- PAGE 10 -->1. Vztahuje se dvouletá lhůta pro uchovávání dat také na obrazová data (videozáznamy z přehledových kamer a kamer pro rozpoznávání registračních značek uložené v NVR nebo serverech kamerových systémů), nebo pouze na strukturovaná a textová data v CP (události, platby, přístupy, záznamy auditního protokolu)?
2. Kdo zodpovídá za uchovávání videozáznamů — Dodavatel CP v rámci služby SaaS, nebo TSK prostřednictvím vlastní infrastruktury NVR?
3. Jaký je přibližný předpokládaný denní počet parkovacích událostí (vjezdů a výjezdů) celkem za všechny objekty? Tato informace je nezbytná pro správné dimenzování datového úložiště a ocenění infrastruktury.

**REAKCE NA DOTAZ Č. 12**

Odpověď na dotaz 12 a) Dvouletá lhůta uchovávání dat se nevztahuje pro obrazová data z přehledových kamer a kamer čtení registračních značek. Odpověď na dotaz 12 b) Uchovávání videozáznamů z kamerových systémů Odpověď na dotaz 12 c) Předpokládaný denní počet kapacitě objektu, režimu provozování faktorech. Negarantovaný průměrný výjezdů) na den. parkovacích událostí na jeden objekt (návštěvnický / nájemní) odhad pro výčet objektů v je odpovědností Objednatele. nelze stanovit přesně, jelikož závisí na , ročním období a dalších proměnlivých příloze 2A ZD je 3000 – 6000 událostí (vjezdů a

**DOTAZ Č. 13**

Cíl bodu obnovy (RPO) dvě hodiny: způsob ověření při akceptaci Příloha č. 2A, bod 26 uvádí, že maximální přípustná ztráta dat při incidentu (RPO) nesmí přesáhnout dvě hodiny. Žádáme Zadavatele o upřesnění:

1. Jakým způsobem bude splnění cíle bodu obnovy ověřeno v rámci akceptační procedury (simulace výpadku, audit zálohovací konfigurace, čestné prohlášení)?
2. Je požadováno, aby Dodavatel provedl ukázku obnovy provozu po havárii jako součást akceptace zkušebního provozu?
3. Vztahuje se cíl bodu obnovy také na data třetích stran synchronizovaná do CP ze systému Green Center — to jest, pokud systém Green Center přestane poskytovat data, je Dodavatel CP odpovědný za ztrátu synchronizace?

**REAKCE NA DOTAZ Č. 13**

Odpověď na dotaz 13 a) Konkrétní akceptační scénáře budou předmětem implementačního projektu. Cílem je prověřit splnění požadavku Zadavatele. Odpověď na dotaz 13 b) Viz 13 a). Zadavatel předpokládá, že ukázka obnovy bude provozu. Odpověď na dotaz 13 c) Dodavatel CP není v takovém případě zodpovědný za přerušení poskytování dat, ale je zodpovědný za logickou součástí akceptace zkušebního

<!-- PAGE 11 -->detekci takového výpadku a za následné dotažení dat za dobu výpadku ze systému Green Center do své databáze. Obecně to platí pro všechny technologie integrované do CP, které tuto možnost poskytují.

**DOTAZ Č. 14**

Automatický pravidelný export dat: cílové úložiště a formát Příloha č. 2A, body 19–22 uvádějí možnost nastavení pravidelného automatického exportu (parkovací události, platby, stavy prvků, parkovací karty). Žádáme Zadavatele o upřesnění:

1. Do jakého cílového úložiště má být automatický export zasílán (server TSK s protokolem SFTP, sdílený síťový disk, příloha elektronické pošty, rozhraní REST na straně TSK, cloudové úložiště)?
2. V jakém datovém formátu (CSV, XLSX, JSON, XML)?
3. Jaká je požadovaná frekvence exportu (denně, hodinově, v reálném čase)?
4. Je automatický pravidelný export povinnou součástí dodávky v rámci implementace, nebo volitelnou nadstavbou objednatelnou jako adhoc služba?

**REAKCE NA DOTAZ Č. 14**

Odpověď na dotaz 14 a) Konkrétně bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Aktuálně počítáme s umístěním cílového úložiště na server TSK s protokolem SFTP nebo na sdílený síťový disk. Volba úložiště se může po dobu trvání smlouvy změnit. Odpověď na dotaz 14 b) Platí, co uvádí ZD. Tj.:

- Příloha č. 2A body 19-22 uvádí: „V CP je možné nastavit pravidelný (nastavitelný parametr) automatický export plateb za parkování." Na konci je pak uvedena věta „Pokud je uveden export, Zadavatel požaduje vždy nejméně export do přehledně strukturované tabulky nejméně volbu xls a pdf."
- Příloha č. 2A bod 27 uvádí: „CP umožňuje strukturovaný export všech dat ukládaných v CP do externího úložiště v běžně užívaném databázovém formátu". Vámi uvedené formáty patří mezi běžně užívané formáty pro přenos a ukládání dat. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Odpověď na dotaz 14 c) ZD neuvádí konkrétní frekvenci pro automatický export. Nebude nastaven on-line automatický export, ale vždy dávkový export pro zadané období. Předpokládané jsou denní, týdenní nebo měsíční intervaly. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Odpověď na dotaz 14 d) Automatický pravidelný export vyjmenovaných dat a jeho nastavení přímo objednatelem je povinnou součástí dodávané CP. Obdobně je povinnou součástí CP možnost exportu všech dat ukládaných v CP, který zadá v CP sám objednatel.

<!-- PAGE 12 -->Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v Dodavatel nemůže tyto povinné součásti CP zajistit jiným způsobem, např. prostřednictvím ad služeb.

**DOTAZ Č. 15**

Aktualizace soupisu objektů před podáním nabídky Příloha č. 2B obsahuje poznámku: „bude aktualizováno ke dni vypsání VŘ a poté po podpisu smlouvy (předání podkladů)." Žádáme Zadavatele o upřesnění:

1. Kdy bude k dispozici finální aktualizovaný soupis objektů, technologických celků a prvků, který bude závazný pro ocenění implementace?
2. Lze potvrdit, zda budou do CP integrovány všechny lokality uvedené v aktuální Příloze č. 2B, nebo zda se jejich výčet před podpisem smlouvy změní?
3. Jaký je předpokládaný celkový počet technologických prvků (stojany, závory, pokladny, kamery, intercomová zařízení) po aktualizaci soupisu?

**REAKCE NA DOTAZ Č. 15**

Odpověď na dotaz 15 a) Ke dni vypsání byl zveřejněn aktuální soupis objektů, technologických celků a prvků

- Implementace – soupis integrovaných Objektů, Technologických celků a Technologických prvků. Poznámka „bude aktualizováno ke dni vypsání VŘ a poté po podpisu smlouvy (předání podkladů uvedena ve skrytém řádku a byla interní poznámkou v viditelný, proto si ho Uchazeč nemá všímat. Správnější by bylo namísto skrytí tento řádek smazat ho považujte za smazaný. Jednotlivé kroky Implementace jsou popsány v příloze č.2 – Ocenění implementace se váže k uvedenému seznamu a harmonogramu. součástí nabídky Uchazeče a je závazná a konečná. Odpověď na dotaz 15 b) Před podpisem smlouvy se soupis objektů, technologických celků a prvků uvedený v příloze č. 2B nezmění. Soupis se může změnit v 8.4. Změna integrovaných Objektů/Technologických prvků v Objednatel si vyhrazuje právo změnit v které by měly být integrovány splnění následujících podmínek: 8.4.1. Celkový počet nově specifikovaných Objektů nebude větší než dva (2) oproti původnímu počtu průběhu Implementace, jak uvádí čl. 8.4. Smlouvy: průběhu Zkušebního provozu Objekty/Technologické prvky, do Centralizační platformy Objektů; 8.4.2. Celkový počet nově specifikovaných Technologických prvků nebude větší než padesát (50) oproti původnímu počtu Technologických prvků; 8.4.3. Požadovaná změna nesmí zahrnovat integraci nového Technologického celku (tj. nesmí se týkat Technologického prvku, který by byl součástí Technologického celku neintegrovaného v Implementace); 8.4.3. Změna může být Objednatelem požadována provozu (není-li s Dodavatelem dohodnuto jinak). Budou-li splněny výše uvedené podmínky, není Dodavatel Implementaci s tím, že pro účinnost změny Objektů/Technologických prvků Dodavateli; tato změna nevyžaduje uzavření dodatku

příloze 5 ZD – Popis technického řešení.

rámci přípravy podkladů po ZD. Tento řádek není Implementace - Harmonogram. Cena implementace je průběhu Implementace v rámci Implementace, nejpozději 14 dnů před koncem Zkušebního bude oprávněn požadovat dostačující doručení nové

\-hoc

jako příloha č. 2B )" je , proto avšak pouze při rámci navýšení ceny za specifikace ke Smlouvě.

<!-- PAGE 13 -->Odpověď na dotaz 15 c) Viz odpověď 15 a).

**DOTAZ Č. 16**

Síťová infrastruktura a datové toky: konektivita mezi CP a lokalitami CP je poskytována v modelu SaaS, tedy je provozována mimo infrastrukturu TSK. Pro správné navržení architektury a ocenění nabídky potřebujeme znát způsob, jakým je CP propojena s technologiemi na jednotlivých parkovacích lokalitách.

1. Síťová konektivita k lokalitám
2. Jsou parkovací lokality TSK připojeny do centrální sítě TSK (WAN, MPLS, VPN) nebo je každá lokalita připojena samostatně k internetu?
3. Kdo zajišťuje a hradí síťové připojení jednotlivých lokalit — TSK, nebo se tato povinnost přenáší na Dodavatele CP?
4. Jaká je dostupná přenosová kapacita na jednotlivých lokalitách (přibližné hodnoty upload/download)? Tato informace je nezbytná pro dimenzování přenosu RTSP videotoku z kamer.
5. Způsob přístupu CP k technologiím na lokalitách
6. Jakým způsobem předpokládá Zadavatel, že CP (jakožto SaaS mimo síť TSK) získá přístup k rozhraní systému Green Center na jednotlivých lokalitách — přes veřejnou IP adresu lokality, přes centrální API bránu TSK, nebo jiným způsobem?
7. Jakým způsobem předpokládá Zadavatel přístup CP ke kamerovým systémům (RTSP streamy, ONVIF) umístěným na lokalitách — jsou kamery přístupné přímo z internetu, nebo pouze z interní sítě TSK?
8. Je na lokalitách nebo v síti TSK provozováno zařízení zajišťující agregaci nebo překlad síťového provozu (například NVR s veřejnou IP adresou, síťový videorekordér zpřístupněný přes NAT, nebo VPN koncentrátor)?
9. Přístup uživatelů k CP
10. Přistupují uživatelé CP (operátoři, manažeři, správci) k webovému rozhraní CP výhradně z interní sítě TSK, nebo také z internetu (z domova, z mobilního zařízení)?
11. Pokud je přístup omezen na interní síť TSK — je počítáno s tím, že Dodavatel CP zpřístupní své SaaS rozhraní pouze prostřednictvím VPN nebo dedikovaného síťového okruhu do sítě TSK?
12. Bezpečnostní a provozní požadavky na síťové propojení
13. Jsou na straně TSK stanoveny konkrétní požadavky na způsob zabezpečení síťového propojení mezi CP a lokalitami (například šifrovaný tunel, certifikátová autentizace, konkrétní protokol VPN)?
14. Kdo nese odpovědnost za dostupnost síťového spojení mezi CP a lokalitami — je výpadek konektivity na straně TSK nebo lokality považován za vynětí z SLA na straně Dodavatele?

**REAKCE NA DOTAZ Č. 16**

Odpověď na dotaz 16 A)

1. lokality jsou připojeny v rámci jednotné sítě, která je vyčleněna pouze pro parkovací objekty
2. síťové připojení jednotlivých lokalit zajišťuje a hradí TSK
3. minimální přenosová rychlost:
4. u větších parkovacích objektů je rychlost 100/100 Mbit
5. u menších parkovacích objektů je rychlost 40/40 Mbit

<!-- PAGE 14 -->Odpověď na dotaz 16 B)

1. přístup k rozhraní GREEN CENTER bude zajiště příloha č. 2 B ZD. Obecně to platí i pro další technologie, které budou do CP integrovány.
2. kamery jsou přístupné přes kamerový server internetu (NAT) nebo je možné využít připojení přes protokol RTSP/ONVIF (záleží na přesném typu kamerového serveru/kamer), viz také příloha č. 2 B ZD.
3. viz odpověď e) Odpověď na dotaz 16 C)
4. Přístup uživatelů do webového prostředí CP bude parkovací objekty). Přístup uživatelů z mobilního zařízení řešení pro manažera/administrátora viz zadávací dokumentace.
5. Přístup do CP Dodavatelem bude uživatelům konkrétní zvolené technické řešení je pak na Dodavateli. Odpověď na dotaz 16 D)
6. Konkrétní způsob zabezpečení síťového propojení je výhradně na dodržet všechny zadané požadavky viz zadávací dokumentace Minimální funkční požadavky.
7. Závisí, zda výpadky konektivity jsou na straně výpadek konektivity je prokazatelně na straně Objednatele Objednatelem.

## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 8.4.2026

**DOTAZ**

Vážený zadavateli, zadavatel stanovil v bodě 9.1 ZD kvalifikační požadavek na předložení alespoň jedné významné služby spočívající v dodávce integrační platformy, technologických celků v minimálně 10 objektech, přičemž tyto celky musí povinně a kumulativně zahrnovat (1) Automatické parkovací systémy a (2) Kamerové dohledové systémy s požadavkem na „zobrazení obrazů z kamer". Požadované referenční období je stanoveno na poslední 3 roky. Dodavatel má za to, že takto formulovaný požadavek je nepřiměřeně restriktivní a omezuje hospodářskou soutěž v rozporu se zásadami přiměřenosti a zákazu diskriminace dle § 6 zákona č. 134/2016 Sb., o zadávání veřejných zakázek. Požadavek omezuje okruh potenciálních dodavatelů na subjekty, které realizovaly vysoce specifický projekt, v němž byl v rámci jedné jediné integrační platformy implementován rozsáhlý automatický parkovací systém a zároveň kamerový systém včetně přenosu obrazu. Mnoho vysoce kvalifikovaných dodavatelů disponuje robustními řešeními v oblasti parkování a smart city (např. integrace tisíců parkovacích míst, závor, senzorů a platebních bran), nicméně přenos živého kamerového obrazu do téže platformy často nebyl součástí plnění z důvodu rozhodnutí daných investorů, nikoliv kvůli technické neschopnosti dodavatele. Současně dodavatel považuje za nepřiměřené omezení referenčního období na poslední 3 roky, a to s ohledem na charakter, komplexnost a dlouhodobost realizace takto specifických softwarových děl. Standardem v oblasti dodávek komplexních centrálních integračních IT řešení pro veřejný sektor je referenční období alespoň 5 let.

n primárně prostřednictvím RestAPI, viz také (NVR), na který je možné se připojit přímo z zejména ze sítě TSK (oddělená síť pro všechny nebo z domova jsou pouze jako nouzové zajištěn v rámci zadaných požadavků objednatele a Dodavateli, nicméně je nutné

- Příloha č.2 A - Schéma CP a Dodavatele nebo Objednatele. V případě, že , tak odpovědnost jde pouze za

která kumulativně splňuje integraci podřízených

<!-- PAGE 15 -->Dodavatel proto žádá zadavatele o zvážení úpravy kvalifikačního požadavku tak, aby odpovídal zásadám přiměřenosti, umožnil širší hospodářskou soutěž a umožnil prokázat schopnost integrace parkovacích a kamerových systémů formou sčítání referencí.

**Za tímto účelem dodavatel navrhuje následující vyznačeny):**

„Dodavatel předloží seznam významných služeb realizovaných v posledních 5 letech, ze kterého bude vyplývat dodávka a/nebo implementace integrační (centralizační) platformy umožňující integraci a správu více technologických celků.

**Tato kvalifikace může být prokázána jednou nebo více referenčními zakázkami, které v součtu splní následující požadavky:**

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky v alespoň 10 objektech a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků.
2. Dodavatel v rámci referenčního plnění integroval alespoň následující technologické celky:
3. **Automatické parkovací systémy a (2) Kamerové dohledové systémy včetně schopnosti zobrazení obrazů z kamer. Požadavek na integraci kamerových dohledových systémů může být prokázán samostatnou referenční zakázkou."**
4. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele."

**REAKCE NA DOTAZ**

Zadavatel s ohledem na obdržený dotaz mění zadávací podmínky, konkrétně podmínky technické kvalifikace. Snahou zadavatele je umožnit co nejširší hospodářskou soutěž, které se budou moci zúčastnit všichni relevantní dodavatelé. Zadavatel mění čl. 9.1 zadávací dokumentace takto, přičemž v čarou zůstávají beze změny: Původní změní: Technická kvalifikace dle § 79 odst. 2 písm. b) ZZVZ 9.1 Dodavatel podle § 79 odst. 2 písm. b) ZZVZ prokazuje splnění technické kvalifikace předložením seznamu významných služeb provedených, tj. dokončených dodavatelem za poslední 3 roky před zahájením zadávacího řízení. Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: Nejméně 1 významné služby, spočívající v dodávce softwarového řešení integrační platformy, která integruje podřízené technologické celky

v alespoň 10 parkovacích či jiných objektech

a splňuje všechny následující požadavky (kumulativně):

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, zobrazení obrazů z kamer, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků

.

1. Technologické celky parkovacích či jiných objektů integrované do integrační platformy Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: Čestné prohlášení o členech realizačního týmu, ze kterého požadavků zadavatele. Zadavatel doporučuje využití vzorového čestného prohlášení, dokumenta0ce.

**úpravu požadavku (změny jsou**

tomto článku uvedené poznámky pod musí vyplývat splnění veškerých které je přílohou č. 3 Zadávací

<!-- PAGE 16 -->jsou alespoň následující: (1) Automatické parkovací systémy, (2) Kamerové dohledové systémy.

1. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele, nebo osoby s ním spojené ve smyslu § 23 odst. 7 zákona č. 586/1992 Sb., o daních z příjmů.

Nové znění (provedené změny **tučně** ): Technická kvalifikace dle § 79 odst. 2 písm. b) ZZVZ 9.1 Dodavatel podle § 79 odst. 2 písm. b) ZZVZ prokazuje splnění technické kvalifikace předložením seznamu významných služeb provedených, tj. dokončených dodavatelem za poslední **5 let** před zahájením zadávacího řízení. Zadavatel požaduje praxi dodavatele spočívající v Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: realizaci: Způsob prokázání:

**1 či více významných služeb** , spočívající v Čestné prohlášení **o významných službách** , ze dodávce softwarového řešení integrační kterého musí vyplývat splnění veškerých platformy, která **každá** integruje podřízené požadavků zadavatele. technologické celky

v alespoň 10 parkovacích či Zadavatel doporučuje využití vzorového čestného jiných objektech2

**a všechny dohromady**

prohlášení, které je přílohou č. 3 Zadávací

**splňují následující požadavky (každá**

dokumentace. **významná služby alespoň jednu)** :

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, zobrazení obrazů z kamer, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků

.

1. **Do integrační platformy jsou integrovány alespoň automatické parkovací systémy jako technologický celek parkovacích či jiných objektů.**
2. **Do integrační platformy jsou integrovány alespoň kamerové dohledové systémy jako technologický celek parkovacích či jiných objektů.**
3. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele, nebo osoby s ním spojené ve smyslu § 23 odst. 7 zákona č. 586/1992 Sb., o daních z příjmů.

<!-- PAGE 17 -->## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 9.4.2026

**DOTAZ č. 1**

Vymezení vztahu standardního produktu a čl. 21.4 Žádáme o upřesnění výkladu čl. 21.4 návrhu Smlouvy. Rozumí Zadavatel tomuto ustanovení tak, že licence k Dílu, které nebylo vytvořeno pro Objednatele v rámci plnění Smlouvy (tj. ke standardnímu softwarovému produktu Dodavatele existujícímu před uzavřením Smlouvy), je poskytnuta výhradně za účelem provozování Centralizační platformy dle této veřejné zakázky, anebo má zadavatel za to, že tato licence opravňuje Objednatele k využití takového Díla i v rámci jiných informačních systémů, projektů či služeb Objednatele?

**REAKCE NA DOTAZ č. 1**

Dodavatel splní svoji povinnost ze Smlouvy i tím, pokud dodaný standardní SW umožní Zadavateli užít pouze pro účely plnohodnotného a nerušeného užití funkcí Centralizační platformy (srov. čl. 21.4.2 Smlouvy).

**DOTAZ č. 2**

Zdrojový kód a jeho rozsah Může Zadavatel jednoznačně potvrdit, že povinnost Dodavatele předat zdrojový kód dle čl. 22 Smlouvy se vztahuje výhradně na Díla ve smyslu čl. 21.3, tedy na zakázkový vývoj vytvořený specificky pro Objednatele v rámci této Smlouvy, a nikoli na zdrojové kódy standardního softwarového produktu Dodavatele nebo jeho obecných komponent?

**REAKCE NA DOTAZ č. 2**

Ano, povinnost předat zdrojový kód se vztahuje výhradně na Díla ve smyslu čl. 21.3 Smlouvy.

**DOTAZ č. 3**

Vztah licence k jiným projektům HMP nebo jeho organizací Zvažuje Zadavatel, že licence poskytované podle čl. 21 Smlouvy mají být využitelné i pro jiné projekty hl. m. Prahy nebo jím zřizovaných či ovládaných subjektů či jiné projekty/služby případné nástupnické organizace TSK, než je provoz Centralizační platformy dle této veřejné zakázky? Pokud ano, žádáme o potvrzení tohoto záměru, neboť má zásadní dopad na cenotvorbu této zakázky.

**REAKCE NA DOTAZ č. 3**

Pokud jde o SW „na zakázku" ve smyslu čl. 21.3 Smlouvy, k tomu Zadavatel nabyde velmi široká oprávnění blíže specifikovaná v tomtéž článku Smlouvy, vč. možnosti libovolně postoupit licenci či poskytnout sublicenci jakékoliv třetí osobě. Pokud jde o SW „standardní" ve smyslu čl. 21.4 Smlouvy – k tomu srov. odpověď na dotaz č. 1. Pro úplnost Zadavatel dodává, že postoupení či sublicencování takového SW je možné pouze za podmínek obecně závazných právních předpisů, tj. zásadně se souhlasem Dodavatele. Přechod jakýchkoliv licencí dle Smlouvy na právní nástupce Zadavatele vyplývá z obecně závazných právních předpisů a z čl. 21.6 Smlouvy.

**DOTAZ č. 4**

Tenký x Tlustý klient

<!-- PAGE 18 -->V zadávací dokumentaci je uvedeno, že Zadavatel očekává obsluhu Centralizační platformy skrze tenkého klienta. Domníváme se, že v některých případech je praktičtější využívat tzv. tlustého klienta, zejména pokud s ním pracují dispečeři. Jeho každodenní používání je mnohem komfortnější a nabízí standardně více funkcionalit. Naše doporučení je přinejmenším používat obě dvě verze, tenkého klienta například pro rychlý operativní přehled a detailní administraci přes tlustého klienta.

**REAKCE NA DOTAZ č. 4**

Zadavatel primárně požaduje tenkého klienta. Pokud nabízené řešení umí zajistit obsluhu Centralizační platformy taktéž skrze tlustého klienta, ať dodavatel tuto skutečnost uvede v popisu svého řešení s tím, že konkrétní provedení bude dohodnuto v rámci Implementačního projektu.

**DOTAZ č. 5**

SW x Operational maintenance V zadávací dokumentaci je exaktně uvedena softwarová maintenance, ale není uvedena aplikační operational maintenance, do které například spadá profilaxe apod. Předpokládá Zadavatel že operational maintenance je součástí servisních služeb, nebo ad-hoc služeb, či si ji chce zajišťovat Zadavatel vlastními silami, protože data v Centralizační platformě jsou jeho vlastnictví a zpracování dat je prováděno pracovníky Zadavatele?

**REAKCE NA DOTAZ č. 5**

Veškeré údržbové práce na Centralizační platformě (SW maintenance, aplikační SW maintenance) by měly být zahrnuty v Paušálních službách. To znamená, že Zadavatel nepřipouští, aby se kontinuální/rutinní činností k zajištění provozuschopnosti Centralizační platformy čerpaly formou ad-hoc služeb.

**DOTAZ č. 6**

KPI u SLA Považujeme SLA parametry za velmi ambiciózní. Například požadavek na vyřešení A incidentu za 1 hodinu s mnoha integrovanými technologiemi je prakticky nedosažitelný, pokud nebudou zastavovány „hodiny", kdy je potřeba zajistit součinnost Zadavatele nebo třetích stran. Navíc, pokud chápeme správně, Servisní služby jsou požadovány ve 24x7 režimu, což vyžaduje v rámci zajištění SaaS (a tím pádem u PaaS/IaaS) mít v pohotovosti širokou skupinu specialistů, a tím se cena za tuto položku výrazně zvyšuje a není prakticky možné dosáhnout požadované kvality za očekávanou cenu.

**REAKCE NA DOTAZ č. 6**

Zadavatel sděluje, že závazný návrh smlouvy ve svém čl. 13.3 (Servisní zásahy Dodavatele) obsahuje dodavatelem zmíněné „zastavování hodin" – zmíněný článek stanoví: „Dodavatel není odpovědný za prodlení s provedením Servisního zásahu (tj. s odstraněním Incidentu), pokud nebyla ze strany Objednatele poskytnuta součinnost v rozsahu a za podmínek této Smlouvy, nebo pokud se následně ukáže, že Problém leží mimo rozsah plnění Dodavatele dle této Smlouvy. V takovém případě lhůta pro provedení Servisního zásahu neběží, dokud není odstraněna překážka na straně Objednatele nebo jiné třetí strany, za kterou Dodavatel neodpovídá." Pokud jde o nastavení SLA, ta zohledňují provozní potřeby a rizika, která vyplývají z omezení/zastavení provozu Centralizační platformy.

<!-- PAGE 19 -->## PRODLOUŽENÍ LHŮTY PRO PODÁNÍ NABÍDEK

Zadavatel v souvislosti s tímto vysvětlením zadávací dokumentace prodloužil lhůtu pro podání nabídek o celou původní délku, a to

**do 21.05. 2026, 10:00.**

**________________________________ Ing. Dana Jurášková**

ředitelka úseku doprava v klidu Technická správa komunikací hl. m. Prahy, a.s.

Page 1

# VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE 01, 02 a 03

## IDENTIFIKACE ZAKÁZKY A ŘÍZENÍ

Název zakázky

**Centralizační platforma vzdálené správy parkovacích objektů**

Druh zakázky služby Režim zakázky nadlimitní Druh řízení otevřené řízení URL na profilu zadavatele https://nen.nipez.cz/verejne-zakazky/detail-zakazky/N006-26- V00002754

## IDENTIFIKACE ZADAVATELE

Název

**Technická správa komunikací hl. m. Prahy, a.s.**

Sídlo Veletržní 1623/24, 170 00 Praha 7 IČO 03447286 Profil zadavatele https://nen.nipez.cz/profil/TSK

## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 1.4.2026

**DOTAZ Č. 1**

Správa uživatelů a rolí: webové nebo administrátorské rozhraní? Příloha č. 2A, bod 3 uvádí, že CP musí umožňovat nastavení uživatelských práv, definování rolí a přidělování oprávnění jednotlivým uživatelům, přičemž ZD výslovně uvádí: „Objednatel může objednat nastavení rolí a práv prostřednictvím ad-hoc služeb." Žádáme Zadavatele o potvrzení, zda toto ustanovení znamená, že:

1. Samoobslužná správa uživatelů přímo ve webovém prohlížeči (zakládání účtů, přiřazování rolí, nastavení oprávnění na úrovni jednotlivých úkonů) není povinnou součástí dodávky webové CP a Dodavatel může tuto správu zajistit prostřednictvím jiného nástroje nebo adhoc servisního modelu?

1. Nebo naopak Zadavatel trvá na tom, aby veškerá správa uživatelů byla realizována výhradně jako samoobslužná funkce přímo v prostředí webového prohlížeče v rámci webové CP? Odůvodnění dotazu: Webové administrátorské rozhraní výrazně zvyšuje rozsah a cenu implementace, přičemž ZD samo uvádí ad-hoc servisní model jako přijatelnou variantu. Potvrzení umožní přesnější ocenění nabídky.

Page 2

**REAKCE NA DOTAZ Č. 1**

Odpověď na dotaz č. 1 a) Samoobslužná správa uživatelů přímo ve webovém prohlížeči je povinnou součástí funkcionalit dodávané webové centralizační platformy (CP). Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Dodavatel nemůže tuto povinnou součást CP správu zajistit jiným způsobem, např. prostřednictvím jiného nástroje nebo prostřednictvím ad-hoc služeb. Prvotní nastavení uživatelských rolí provede Dodavatel pro zahájení zkušebního a běžného provozu jako součást činností s tím spojených. Zadavatel zároveň počítá s tím, že informace o tom, jak bude nadále Zadavatel role nastavovat a spravovat, bude součástí nadstavbového školení pro role manažer a administrátor. Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat nastavení rolí a práv prostřednictvím ad-hoc služeb, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Odpověď na dotaz č. 1 b) Jak uvádí odpověď na dotaz č. 1 a) výše, Zadavatel výslovně požaduje, aby veškerá správa uživatelů byla realizována jako součást dodávané CP. Ze strany Zadavatele ale správa uživatelů vlastními pracovníky ale není jedinou možnou variantou. Jak uvedeno výše v 1a), Zadavatel může u Dodavatele nastavení uživatelských rolí objednat, pokud se tak rozhodne. Postup objednání se řídí postupem objednávání ad-hoc služeb.

**DOTAZ Č. 2**

Zakládání objektů, plánků a prvků: povinná samoobsluha nebo ad-hoc služba? Příloha č. 2A, body 4, 5 a 6 uvádějí, že CP musí umožňovat zakládání lokalit, nahrávání plánků a vkládání či editaci technologických prvků. ZD přitom u všech tří požadavků výslovně uvádí: „Po dobu trvání smlouvy je možnou variantou objednávka výše uvedených úkonů v rámci ad-hoc služeb." Žádáme Zadavatele o upřesnění:

1. Je samoobslužná editace těchto prvků přímo ve webovém prohlížeči povinnou součástí dodávky, nebo postačuje model, kdy prvotní konfiguraci provede Dodavatel v rámci implementace a následné změny Objednatel objednává jako ad-hoc službu?

1. Pokud je webová editace plánků povinná — v jakém formátu bude Objednatel plánky do CP vkládat a jaké jsou požadavky na editor (například přetahování prvků na plánku, definice zón apod.)?

**REAKCE NA DOTAZ Č. 2**

Odpověď na dotaz č. 2 a) Samoobslužná správa, editace a doplňování jednotlivých objektů (lokalit), technologických prvků a vybraných zařízení přímo ve webovém prohlížeči je povinnou součástí funkcionalit dodávané webové centralizační platformy (CP). Dodavatel provede prvotní konfiguraci pro zahájení zkušebního a běžného provozu jako součást činností s tím spojených. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Zadavatel zároveň počítá s tím, že informace o tom, jak bude nadále provádět správu, zakládání a editaci objektů (lokalit), technologických prvků a vybraných zařízení přímo v CP bude součástí základního a nadstavbového školení. Doptávaná varianta prvotní konfigurace provedené Dodavatelem a objednávání následných změn formou adhoc služeb není přípustný.

Page 3

Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat založení a editaci lokalit, prvků a zařízení, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Odpověď na dotaz č. 2 b) K formátům obrázků Zadavatel v bodě 4. Přílohy 2A Zadávací dokumentace uvádí: „Plánky budou vkládány jako obrázky (formáty jpeg a pdfpovinně, případně další standardně používané formáty)". Na základě dotazu Zadavatel zpřesňuje popis takto: „Plánky budou vkládány jako obrázky (formáty jpeg nebo png povinně, případně další standardně používané formáty)". Požadavky na editaci uvádějí body 4., 5. a 6. přílohy 2A ZD. Přetahování prvků na plánku je součástí editace. Stejně je třeba počítat s tím, že objekt může být vícepodlažní a je třeba zobrazit plánky všech podlaží, případně i okolí objektu, kde jsou umístěny prvky (např. informace o obsazenosti). Zadavatel předpokládá, že Dodavatel má s obdobnými dodávkami zkušenosti a dodávaný systém CP tedy obsahuje praktické a účelné funkcionality, které lze při správě a provozu parkovacích objektů očekávat. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení.

**DOTAZ Č. 3**

Konfigurace akčních pokynů: webová editace nebo ad-hoc služba? Příloha č. 2A, body 11 a 16 uvádějí, že CP umožní Objednateli upravovat způsob upozornění a akční pokyny pro obsluhu. ZD zároveň u těchto požadavků uvádí: „Po dobu trvání smlouvy je možnou variantou objednávka výše uvedených úkonů v rámci ad-hoc služeb." Žádáme Zadavatele o potvrzení:

1. Je editace akčních pokynů a nastavení způsobu upozornění přímo ve webovém prohlížeči povinnou součástí dodávky, nebo postačuje, aby tuto konfiguraci prováděl Dodavatel na základě písemné objednávky Objednatele v rámci ad-hoc služeb?

1. Pokud je webová editace povinná — jaký je požadovaný formát a způsob zadávání akčních pokynů (textové pole, krokovaný průvodce, šablony apod.)?

**REAKCE NA DOTAZ Č. 3**

Odpověď na dotaz č. 3 a) Samoobslužná editace pokynů a nastavení způsobu upozornění je povinnou funkcionalitou dodávané CP. Konfigurace na základě objednávky ad-hoc služeb jako výlučné řešení nabízení Uchazečem nepostačuje. Zadavatel uvádí pouze jako doplňující informaci, že může u Dodavatele objednat nastavení úkonů prostřednictvím ad-hoc služeb, tj. pokud se k tomu rozhodne. Zadavatel tuto možnost předpokládá využít ve výjimečných případech, kdy by výslovně potřeboval, zejména z kapacitních nebo časových důvodů, s tímto nastavením pomoci. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Odpověď na dotaz č. 3 b) Zadavatel předpokládá, že Dodavatel má s obdobnými řešeními zkušenosti a dodávaný systém CP tedy obsahuje praktické a účelné nástroje, které lze při správě a provozu parkovacích objektů očekávat. Zadavatel očekává návrh řešení, které je ověřené praxí a které Dodavatel popíše a vysvětlí. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Konkrétní nastavení bude součástí Implementačního projektu.

Page 4

**DOTAZ Č. 4**

API dokumentace systému Green Center: rovné podmínky pro uchazeče Příloha č. 2A, bod 2 uvádí: „Popis rozhraní bude předán po podpisu smlouvy s dodavatelem CP." Zadavateli je zřejmě znám obsah rozhraní systému Green Center, neboť společnost Green Center s.r.o. se zúčastnila předběžné tržní konzultace (PTK) jako potenciální dodavatel a s největší pravděpodobností Zadavateli rozhraní svého systému prezentovala. Ostatní uchazeči o tuto zakázku přitom k API dokumentaci přístup nemají. Tato situace znevýhodňuje uchazeče, kteří nejsou provozovatelem systému Green Center, neboť nemohou realisticky ocenit integrační práce. Konkrétně: není znám datový model API (formát parkovacích událostí, plateb, parkovacích karet, dokladů, výčetek hotovosti), není potvrzeno, která z požadovaných datových sad je přes API Green Center vůbec dostupná, není znám protokol, autentizační model ani způsob připojení. Žádáme Zadavatele, aby před termínem podání nabídek zpřístupnil všem uchazečům:

1. Dokumentaci rozhraní systému Green Center (nebo ekvivalentní technickou dokumentaci systémů instalovaných na jednotlivých lokalitách), kterou Zadavatel obdržel v rámci předběžné tržní konzultace.

1. Potvrzení, která z níže uvedených datových sad je prostřednictvím rozhraní systému Green Center dostupná: parkovací události (vjezd, výjezd, délka parkování), záznamy o platbách, parkovací karty a dlouhodobá oprávnění, doklady o platbě (účtenky, lístky), výčetky aktuálního stavu hotovosti v automatických pokladnách.

1. Sdělení, která z výše uvedených dat jsou dostupná pouze přímým přístupem k databázi nebo prostřednictvím proprietárního protokolu — a zda Zadavatel tuto formu integrace považuje za součást předmětu plnění.

**REAKCE NA DOTAZ Č. 4**

Odpověď na dotaz č. 4 a) Zadavatel neobdržel v rámci PTK popis API od žádného z účastníků. Dokumentaci rozhraní parkovacího systému Green Center a specifikaci rozhraní kamerových systémů obdrží vybraný Uchazeč při podpisu smlouvy. Zadavatel uvádí, že v případě parkovacího systému se jedná o standardní RestAPI, které bude komunikovat data obecně popsaná v zadávací dokumentaci. Jedná se o data běžně evidovaná standardními parkovacími systémy. Odpověď na dotaz č. 4 b) Datové sady jsou dovoditelné ze zadávací dokumentace. Nejsou vázány na jednoho dodavatele parkovacího systému. Vámi uvedené sady jsou typicky poskytované. V rámci implementačního projektu bude dále upřesněno. V průběhu trvání smlouvy předpokládáme integraci dalších technologií, které budou mít shodnou základní logiku ohledně rozhraní a komunikovaných dat. Odpověď na dotaz č. 4 c) Data budou dostupná prostřednictvím komunikačních rozhraní – viz příloha č. 2B ZD. Součástí předmětu plnění je zajištění komunikace CP s těmito rozhraními.

Page 5

**DOTAZ Č. 5**

Parkovací karty: evidenční systém a požadovaný rozsah funkce Příloha č. 2A, bod 22 uvádí evidenci a vyhledávání parkovacích karet a oprávnění podle registrační značky vozidla, čísla karty, jména a objektu. Žádáme Zadavatele o upřesnění:

1. Jsou parkovací karty (dlouhodobá parkovací oprávnění) evidovány přímo v systému Green Center a dostupné prostřednictvím jeho rozhraní?

1. Nebo jsou evidovány v jiném systému TSK (například v systému správy smluv, interní databázi nebo jiném evidenčním nástroji)?

1. Má CP pouze zobrazovat a vyhledávat existující záznamy z evidenčního systému, nebo také zakládat, editovat a rušit parkovací karty?

1. Může Zadavatel upřesnit datovou strukturu záznamu o parkovací kartě — zobrazení v CP požadována?

**REAKCE NA DOTAZ Č. 5**

Odpověď na dotaz č. 5 a) Ano. Odpověď na dotaz č. 5 b) V budoucnu mohou být evidovány i v jiném systému než namísto do databáze Green Center do databáze jiného dodavatele parkovací technologie nebo databáze TSK. Přechod na evidenci dalšími systémy bude předmětem ad Odpověď na dotaz č. 5 c) Ano, pouze vyhledávat a zobrazovat existující záznamy o parkovacích kartách (dlouhodobých parkovacích oprávněních) z evidenčního systému integrovaného do CP. Odpověď na dotaz č. 5 d) Datová struktura je dovoditelná ze zadávací dokumentace. Není parkovacího systému a musí poskytovat pro Objednatele informace rozhodné pro ověření platnosti karty v případě dotazu klienta na pracoviště centrální správy parkovacích objektů provozované TSK. Základní sada dat, kterou očekáváme komunikovat je: ID karty, Lokalita platnosti, Platnost od, Platnost do, Vlastník + RZ oprávněných vozidel, Datum a čas posledního Očekáváme, že Dodavatel pracuje v rámci svého řešení se sadou dat, která odpovídá potřebám vzdálené správy parkovacích objektů a nejlepší možné praxi. Konkrétní řešení bude předmětem nabídky Uchazeče, v rámci další zpřesnění.

**DOTAZ Č. 6**

Doklady o platbě: dostupnost a formát v systému Green Center Příloha č. 2A, bod 23 uvádí zobrazení, tisk a export dokladů o platbě včetně vystavení kopie nebo duplikátu. Žádáme Zadavatele o upřesnění:

1. Jsou doklady o platbě (parkovací lístky, účtenky z automatických pokladen) ukládány v centrálním systému Green Center ve strojově čitelné podobě, nebo jsou generovány a tisknuty výhradně lokálně na místě platby?

1. Poskytuje rozhraní systému Green Center přístup k jednotlivým dokladům — jako strukturovaná data umožňující rekonstrukci dokladu?

jaká pole jsou pro

Green Center. CP se pak bude dotazovat do

- \-hoc služeb. vázána na jednoho dodavatele vjezdu/výjezdu, Poznámka implementačního projektu lze očekávat

ve formátu PDF nebo

Page 6

1. Pokud doklady nejsou v systému Green Center centrálně uloženy — jak Zadavatel představuje splnění tohoto požadavku technicky?

**REAKCE NA DOTAZ Č. 6**

Odpověď na dotaz č. 6 a) Doklady jsou ukládány v parkovacím systému GREEN CENTER jako strukturovaná data. V budoucnu mohou být evidovány i v jiném parkovacím systému, který bude do CP integrován. Odpověď na dotaz č. 6 b) V parkovacím systému Green Center jsou doklady ukládány ve formě strukturovaných dat, která umožňují rekonstrukci dokladu. Odpověď na dotaz č. 6 c) Bezpředmětné – jsou centrálně uloženy, jak popisují odpovědi 6 a) a 6 b) výše.

**DOTAZ Č. 7**

Výčetka stavu hotovosti: dostupnost dat Příloha č. 2A, bod 24 uvádí zobrazení výčetky aktuálního stavu hotovosti v automatických pokladnách. Žádáme Zadavatele o upřesnění:

1. Je aktuální stav hotovosti v automatických pokladnách přístupný prostřednictvím rozhraní systému Green Center?

1. Pokud ano — v jakém formátu a s jakou frekvencí aktualizace jsou tato data dostupná?

1. Pokud ne — jakým způsobem Zadavatel předpokládá, že CP tato data získá?

**REAKCE NA DOTAZ Č. 7**

Odpověď na dotaz č. 7 a) Ano, aktuální stav hotovosti v automatických pokladnách je přístupný prostřednictvím rozhraní systému GREEN CENTER. Odpověď na dotaz č. 7 b) V parkovacím systému Green Center jsou doklady ukládány ve formě strukturovaných dat, která umožňují zobrazení informace o aktuálním stavu. Tj. frekvence je bezpředmětná. Odpověď na dotaz č. 7 c) Bezpředmětné – viz odpověď 7 a).

**DOTAZ Č. 8**

ServiceDesk: potvrzení, že jde o nástroj Dodavatele, nikoli modul CP Smlouva v čl. 6.4 a čl. 13.1 stanoví, že Dodavatel je povinen zajistit a Objednateli zpřístupnit ServiceDesk. Zadavatel i Dodavatel tak ServiceDesk vnímají jako nástroj na straně Dodavatele, ke kterému Objednatel přistupuje, přičemž ServiceDesk není součástí samotné CP. Žádáme Zadavatele o potvrzení:

1. ServiceDesk pro evidenci a řešení incidentů je nástroj provozovaný Dodavatelem (například specializovaný software třetí strany — Jira, Freshdesk nebo vlastní řešení), ke kterému Objednatel přistupuje prostřednictvím odkazu nebo jiného způsobu přístupu, a není požadován jako modul integrovaný přímo do webového rozhraní CP?

Page 7

1. Jakým způsobem bude Objednatel do ServiceDesku přistupovat — aplikace, e-mail?

1. Jsou pro ServiceDesk stanoveny konkrétní technické nebo funkční požadavky (například povinné rozhraní, formát exportu dat, integrace s MQTT nebo jinými systémy TSK)?

**REAKCE NA DOTAZ Č. 8**

Odpověď na dotaz č. 8 a) Ano. ServiceDesk slouží k evidenci a řešení incidentů centralizační platformy, který dodá Dodavatel v rámci plnění smlouvy, a na své náklady ho bude pod dobu trvání smlouvy provozovat. Předpokládá se přístup prostřednictvím webové služby, přístup udělí Dodavatel osobám, které Objednatel určí. Jako modul integrovaný do CP bude dodána Servisní kniha (viz bod 18 přílohy 12A ZD) V praxi pak pracovník Objednatele zapíše do Servisní knihy také incident Současně pak zapíše incident také do ServiceDesk Dodavatele. Ten může být (a pro Objednatele by to bylo praktické) napojen na Servisní knihu, ze které je možné poslat záznam Konkrétní řešení bude popsáno v nabídce Uchazeče. Dále pak bude řešeno v projektu. Odpověď na dotaz č. 8 b) Základní forma přístupu do ServiceDesk bude prostřednictvím webové aplikace (dostupné z mobilního telefonu). Možnost zaslat e-mail nebo zatelefonovat se předpokládá. Konkrétní řešení bude popsáno v nabídce Uchazeče. Dále pak bude řešeno v projektu. Odpověď na dotaz č. 8 c) Zadávací dokumentace konkrétní ani funkční požadavky nestanovuje, nicméně musí splnit požadavky uvedené zejména v čl. 6.4. a 13.1. Smlouvy. Dále pak bude řešeno v rámci implementačního projektu.

**DOTAZ Č. 9**

Intercom: typ zařízení a komunikační protokol Příloha č. 2C (osnova školení, bod 39) uvádí komunikaci s klientem v objektu prostřednictvím intercomu jako součást výuky. Žádáme Zadavatele o upřesnění:

1. Jaký typ intercomového zařízení je instalován v parkovacích objektech TSK (výrobce, model)?

1. Jaký komunikační protokol tato zařízení podporují (SIP/VoIP, ONVIF, vlastní HTTP rozhraní)?

1. Je intercom propojen se systémem Green Center, nebo funguje jako samostatný systém?

1. Je k dispozici technická dokumentace stávajících intercomů nebo kontakt na jejich správce?

1. Má CP realizovat obousměrnou hlasovou komunikaci přímo ve webovém prohlížeči (například prostřednictvím WebRTC nebo SIP přes WebSocket), nebo postačuje jiný způsob zprostředkování hovoru?

**REAKCE NA DOTAZ Č. 9**

Odpověď na dotaz č. 9 a) Intercom instalovaný na parkovacích objektech, které budou integrovány do CP bude samostatný systém neintegrovaný do CP. Informace nesdělujeme, je pro nabídku uchazeče bezpředmětná integroval, bude předmětem ad o konkrétních typech instalovaných na parkovacích objektech . Pokud by se v budoucnu do CP systém intecomu

- \-hoc plnění.

webový prohlížeč, mobilní

. na centralizační platformě. do ServiceDesk. rámci implementačního PC i rámci implementačního

Page 8

V případě školení bude pouze simulováno volání prostřednictvím intercomu a školený pracovník na základě této komunikace bude hledat potřebné informace v CP. Odpověď na dotaz č. 9 b) Bezpředmětné, viz odpověď 9 a). Odpověď na dotaz č. 9 c) Intercom instalovaný na parkovacích objektech, které budou integrovány do CP, bude vždy samostatný systém neintegrovaný do CP, ať se jedná o jakéhokoliv výrobce. Odpověď na dotaz č. 9 d) Není. Je bezpředmětné vzhledem k tomu, že se jedná se o telefonické spojení, kdy příjem hovoru je prostřednictvím telefonu obsluhy, tedy mimo CP. Odpověď na dotaz č. 9 e) Viz odpověď č. 9 c)

**DOTAZ Č. 10**

Omezení přístupu pomocí seznamu povolených IP adres: úroveň implementace Příloha č. 2A, bod 1 uvádí omezení přístupu k CP prostřednictvím seznamu povolených IP adres (whitelistu). Žádáme Zadavatele o upřesnění:

1. Je požadováno, aby seznam povolených IP adres byl konfigurovatelný přímo v administrátorském rozhraní CP — tj. aby jej správce CP mohl upravovat prostřednictvím webového uživatelského rozhraní?

1. Nebo postačuje, aby seznam povolených IP adres byl konfigurován na úrovni síťové a proxy infrastruktury Dodavatele (firewall, reverzní proxy), bez přístupu Objednatele ke konfiguraci tohoto seznamu?

1. Jak Zadavatel řeší přístup mobilních uživatelů s dynamickou IP adresou (například manažer přistupující z notebooku mimo kancelář TSK)?

**REAKCE NA DOTAZ Č. 10**

Odpověď na dotaz č. 10 a) Ano, je požadováno, aby seznam povolených IP adres byl konfigurovatelný přímo v CP, tj. aby jej Zadavatel mohl upravovat přímo prostřednictvím webového rozhraní. Zadavatel požaduje, aby řešení zajišťovalo bezpečnostní opatření řízení přístupu k CP jen pro povolené IP adresy a je na Dodavateli, jaký způsob zvolí a bude garantovat jeho plnou funkčnost a ochranu CP před komunikací z ostatních, tj. nepovolených IP adres. Odpověď na dotaz č. 10 b) Viz odpověď č. 10 a) Odpověď na dotaz č. 10 c) Uživatel Zadavatele, který pracuje vzdáleně (mimo kanceláře a objekty Zadavatele) přistupuje do interního perimetru výhradně prostřednictvím VPN připojení. Přistup do externích systémů nebo aplikací, které má Zadavatel umístěné mimo interní perimetr (hosting, cloudová prostředí apod.), je následně řízen přes konkrétní vybrané IP adresy Zadavatele, které tak provozovatelé pro přístup do externích systémů a aplikací nastaví jako povolené.

Page 9

**DOTAZ Č. 11**

Zákon o kybernetické bezpečnosti: rozpor v citaci zákona a rozsah povinností V zadávací dokumentaci byl zjištěn věcný rozpor v citaci právních předpisů týkajících se kybernetické bezpečnosti: Hlavní text ZD, Příloha č. 2A, bod 25 odkazuje na zákon č. 264/2025 Sb. o kybernetické bezpečnosti a vyhlášku č. 409/2025 Sb. o bezpečnostních opatřeních. Příloha č. 5 ZD (formulář popisu technického řešení dodavatele) odkazuje na zákon č. 181/2014 Sb. o kybernetické bezpečnosti a vyhlášku č. 82/2018 Sb. Tyto předpisy jsou obsahově odlišné, přičemž zákon č. 181/2014 Sb. byl zákonem č. 264/2025 Sb. nahrazen. Žádáme Zadavatele o upřesnění:

1. Která právní úprava je pro plnění smlouvy závazná — zákon č. 181/2014 Sb. nebo zákon č. 264/2025 Sb.?

1. Je Příloha č. 5 ZD v odkazu na právní předpisy neaktuální, a bude opravena nebo nahrazena?

1. Je TSK jako provozovatel CP klasifikována jako regulovaná služba v režimu vyšších nebo nižších povinností podle zákona č. 264/2025 Sb.?

1. Jaká konkrétní bezpečnostní opatření jsou požadována přímo od Dodavatele jako poskytovatele služby v modelu SaaS (například hlášení incidentů, penetrační testování, bezpečnostní dokumentace)?

1. Je soulad s příslušnými právními předpisy součástí akceptačních kritérií, nebo se jedná o průběžnou povinnost po dobu trvání smlouvy?

**REAKCE NA DOTAZ Č. 11**

Odpověď na dotaz 11 a) Závazná je platná právní úprava (zákon č. 264/2025 Sb.). Odpověď na dotaz 11 b) Příloha č. 5 ZD bude zachována, protože v bodě 25 uvádí, že bude zajištěn soulad s tam uvedenými právními předpisy (zákon č. 181/2014 Sb. vyhláška č. 82/2018 Sb.) nebo s předpisy nahradí. Je tak zřejmé, že se použijí aktuálně platné předpisy nahradily. Odpověď na dotaz 11 c) Jedná se o regulovanou službu v režimu vyšších povinností. Odpověď na dotaz 11 d) Konkrétní bezpečnostní opatření vyplývají zejména z Odpověď na dotaz 11 e) Soulad s právními předpisy v oblasti kyberbezpečnosti je požadován po celou dobu trvání smlouvy – v době akceptace, tak v průběhu navazujícího trvání smlouvy. Konkrétní akceptační scénáře/kritéria budou předmětem implementačního projektu. Cílem je prověřit splnění požadavků Zadavatele.

**DOTAZ Č. 12**

Uchování dat po dobu dvou let: rozsah a datový objem Příloha č. 2A, body 7 a 17–24 uvádějí uchovávání dat po dobu minimálně dvou let. Žádáme Zadavatele o upřesnění:

předpisy, které uvedené právní předpisy, které specifikované právní přílohy č. 2A, 9A a 9B závazného návrhu smlouvy. jak

Page 10

1. Vztahuje se dvouletá lhůta pro uchovávání dat také na obrazová data (videozáznamy z přehledových kamer a kamer pro rozpoznávání registračních značek uložené v NVR nebo serverech kamerových systémů), nebo pouze na strukturovaná a textová data v CP (události, platby, přístupy, záznamy auditního protokolu)?

1. Kdo zodpovídá za uchovávání videozáznamů — Dodavatel CP v rámci služby SaaS, nebo TSK prostřednictvím vlastní infrastruktury NVR?

1. Jaký je přibližný předpokládaný denní počet parkovacích událostí (vjezdů a výjezdů) celkem za všechny objekty? Tato informace je nezbytná pro správné dimenzování datového úložiště a ocenění infrastruktury.

**REAKCE NA DOTAZ Č. 12**

Odpověď na dotaz 12 a) Dvouletá lhůta uchovávání dat se nevztahuje pro obrazová data z přehledových kamer a kamer čtení registračních značek. Odpověď na dotaz 12 b) Uchovávání videozáznamů z kamerových systémů Odpověď na dotaz 12 c) Předpokládaný denní počet kapacitě objektu, režimu provozování faktorech. Negarantovaný průměrný výjezdů) na den. parkovacích událostí na jeden objekt (návštěvnický / nájemní) odhad pro výčet objektů v je odpovědností Objednatele. nelze stanovit přesně, jelikož závisí na , ročním období a dalších proměnlivých příloze 2A ZD je 3000 – 6000 událostí (vjezdů a

**DOTAZ Č. 13**

Cíl bodu obnovy (RPO) dvě hodiny: způsob ověření při akceptaci Příloha č. 2A, bod 26 uvádí, že maximální přípustná ztráta dat při incidentu (RPO) nesmí přesáhnout dvě hodiny. Žádáme Zadavatele o upřesnění:

1. Jakým způsobem bude splnění cíle bodu obnovy ověřeno v rámci akceptační procedury (simulace výpadku, audit zálohovací konfigurace, čestné prohlášení)?

1. Je požadováno, aby Dodavatel provedl ukázku obnovy provozu po havárii jako součást akceptace zkušebního provozu?

1. Vztahuje se cíl bodu obnovy také na data třetích stran synchronizovaná do CP ze systému Green Center — to jest, pokud systém Green Center přestane poskytovat data, je Dodavatel CP odpovědný za ztrátu synchronizace?

**REAKCE NA DOTAZ Č. 13**

Odpověď na dotaz 13 a) Konkrétní akceptační scénáře budou předmětem implementačního projektu. Cílem je prověřit splnění požadavku Zadavatele. Odpověď na dotaz 13 b) Viz 13 a). Zadavatel předpokládá, že ukázka obnovy bude provozu. Odpověď na dotaz 13 c) Dodavatel CP není v takovém případě zodpovědný za přerušení poskytování dat, ale je zodpovědný za logickou součástí akceptace zkušebního

Page 11

detekci takového výpadku a za následné dotažení dat za dobu výpadku ze systému Green Center do své databáze. Obecně to platí pro všechny technologie integrované do CP, které tuto možnost poskytují.

**DOTAZ Č. 14**

Automatický pravidelný export dat: cílové úložiště a formát Příloha č. 2A, body 19–22 uvádějí možnost nastavení pravidelného automatického exportu (parkovací události, platby, stavy prvků, parkovací karty). Žádáme Zadavatele o upřesnění:

1. Do jakého cílového úložiště má být automatický export zasílán (server TSK s protokolem SFTP, sdílený síťový disk, příloha elektronické pošty, rozhraní REST na straně TSK, cloudové úložiště)?

1. V jakém datovém formátu (CSV, XLSX, JSON, XML)?

1. Jaká je požadovaná frekvence exportu (denně, hodinově, v reálném čase)?

1. Je automatický pravidelný export povinnou součástí dodávky v rámci implementace, nebo volitelnou nadstavbou objednatelnou jako adhoc služba?

**REAKCE NA DOTAZ Č. 14**

Odpověď na dotaz 14 a) Konkrétně bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Aktuálně počítáme s umístěním cílového úložiště na server TSK s protokolem SFTP nebo na sdílený síťový disk. Volba úložiště se může po dobu trvání smlouvy změnit. Odpověď na dotaz 14 b) Platí, co uvádí ZD. Tj.:

- Příloha č. 2A body 19-22 uvádí: „V CP je možné nastavit pravidelný (nastavitelný parametr) automatický export plateb za parkování." Na konci je pak uvedena věta „Pokud je uveden export, Zadavatel požaduje vždy nejméně export do přehledně strukturované tabulky nejméně volbu xls a pdf."

- Příloha č. 2A bod 27 uvádí: „CP umožňuje strukturovaný export všech dat ukládaných v CP do externího úložiště v běžně užívaném databázovém formátu". Vámi uvedené formáty patří mezi běžně užívané formáty pro přenos a ukládání dat. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Odpověď na dotaz 14 c) ZD neuvádí konkrétní frekvenci pro automatický export. Nebude nastaven on-line automatický export, ale vždy dávkový export pro zadané období. Předpokládané jsou denní, týdenní nebo měsíční intervaly. Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v příloze 5 ZD – Popis technického řešení. Bude projednáno v rámci implementačního projektu, který slouží ke konkrétní specifikaci předávané CP a nastavení jejích vlastností v rámci minimálních parametrů definovaných ZD. Odpověď na dotaz 14 d) Automatický pravidelný export vyjmenovaných dat a jeho nastavení přímo objednatelem je povinnou součástí dodávané CP. Obdobně je povinnou součástí CP možnost exportu všech dat ukládaných v CP, který zadá v CP sám objednatel.

Page 12

Konkrétní řešení, jak ho nabízí jeho systém, popíše Uchazeč v Dodavatel nemůže tyto povinné součásti CP zajistit jiným způsobem, např. prostřednictvím ad služeb.

**DOTAZ Č. 15**

Aktualizace soupisu objektů před podáním nabídky Příloha č. 2B obsahuje poznámku: „bude aktualizováno ke dni vypsání VŘ a poté po podpisu smlouvy (předání podkladů)." Žádáme Zadavatele o upřesnění:

1. Kdy bude k dispozici finální aktualizovaný soupis objektů, technologických celků a prvků, který bude závazný pro ocenění implementace?

1. Lze potvrdit, zda budou do CP integrovány všechny lokality uvedené v aktuální Příloze č. 2B, nebo zda se jejich výčet před podpisem smlouvy změní?

1. Jaký je předpokládaný celkový počet technologických prvků (stojany, závory, pokladny, kamery, intercomová zařízení) po aktualizaci soupisu?

**REAKCE NA DOTAZ Č. 15**

Odpověď na dotaz 15 a) Ke dni vypsání byl zveřejněn aktuální soupis objektů, technologických celků a prvků

- Implementace – soupis integrovaných Objektů, Technologických celků a Technologických prvků. Poznámka „bude aktualizováno ke dni vypsání VŘ a poté po podpisu smlouvy (předání podkladů uvedena ve skrytém řádku a byla interní poznámkou v viditelný, proto si ho Uchazeč nemá všímat. Správnější by bylo namísto skrytí tento řádek smazat ho považujte za smazaný. Jednotlivé kroky Implementace jsou popsány v příloze č.2 – Ocenění implementace se váže k uvedenému seznamu a harmonogramu. součástí nabídky Uchazeče a je závazná a konečná. Odpověď na dotaz 15 b) Před podpisem smlouvy se soupis objektů, technologických celků a prvků uvedený v příloze č. 2B nezmění. Soupis se může změnit v 8.4. Změna integrovaných Objektů/Technologických prvků v Objednatel si vyhrazuje právo změnit v které by měly být integrovány splnění následujících podmínek: 8.4.1. Celkový počet nově specifikovaných Objektů nebude větší než dva (2) oproti původnímu počtu průběhu Implementace, jak uvádí čl. 8.4. Smlouvy: průběhu Zkušebního provozu Objekty/Technologické prvky, do Centralizační platformy Objektů; 8.4.2. Celkový počet nově specifikovaných Technologických prvků nebude větší než padesát (50) oproti původnímu počtu Technologických prvků; 8.4.3. Požadovaná změna nesmí zahrnovat integraci nového Technologického celku (tj. nesmí se týkat Technologického prvku, který by byl součástí Technologického celku neintegrovaného v Implementace); 8.4.3. Změna může být Objednatelem požadována provozu (není-li s Dodavatelem dohodnuto jinak). Budou-li splněny výše uvedené podmínky, není Dodavatel Implementaci s tím, že pro účinnost změny Objektů/Technologických prvků Dodavateli; tato změna nevyžaduje uzavření dodatku

příloze 5 ZD – Popis technického řešení.

rámci přípravy podkladů po ZD. Tento řádek není Implementace - Harmonogram. Cena implementace je průběhu Implementace v rámci Implementace, nejpozději 14 dnů před koncem Zkušebního bude oprávněn požadovat dostačující doručení nové

\-hoc

jako příloha č. 2B )" je , proto avšak pouze při rámci navýšení ceny za specifikace ke Smlouvě.

Page 13

Odpověď na dotaz 15 c) Viz odpověď 15 a).

**DOTAZ Č. 16**

Síťová infrastruktura a datové toky: konektivita mezi CP a lokalitami CP je poskytována v modelu SaaS, tedy je provozována mimo infrastrukturu TSK. Pro správné navržení architektury a ocenění nabídky potřebujeme znát způsob, jakým je CP propojena s technologiemi na jednotlivých parkovacích lokalitách.

1. Síťová konektivita k lokalitám

1. Jsou parkovací lokality TSK připojeny do centrální sítě TSK (WAN, MPLS, VPN) nebo je každá lokalita připojena samostatně k internetu?

1. Kdo zajišťuje a hradí síťové připojení jednotlivých lokalit — TSK, nebo se tato povinnost přenáší na Dodavatele CP?

1. Jaká je dostupná přenosová kapacita na jednotlivých lokalitách (přibližné hodnoty upload/download)? Tato informace je nezbytná pro dimenzování přenosu RTSP videotoku z kamer.

1. Způsob přístupu CP k technologiím na lokalitách

1. Jakým způsobem předpokládá Zadavatel, že CP (jakožto SaaS mimo síť TSK) získá přístup k rozhraní systému Green Center na jednotlivých lokalitách — přes veřejnou IP adresu lokality, přes centrální API bránu TSK, nebo jiným způsobem?

1. Jakým způsobem předpokládá Zadavatel přístup CP ke kamerovým systémům (RTSP streamy, ONVIF) umístěným na lokalitách — jsou kamery přístupné přímo z internetu, nebo pouze z interní sítě TSK?

1. Je na lokalitách nebo v síti TSK provozováno zařízení zajišťující agregaci nebo překlad síťového provozu (například NVR s veřejnou IP adresou, síťový videorekordér zpřístupněný přes NAT, nebo VPN koncentrátor)?

1. Přístup uživatelů k CP

1. Přistupují uživatelé CP (operátoři, manažeři, správci) k webovému rozhraní CP výhradně z interní sítě TSK, nebo také z internetu (z domova, z mobilního zařízení)?

1. Pokud je přístup omezen na interní síť TSK — je počítáno s tím, že Dodavatel CP zpřístupní své SaaS rozhraní pouze prostřednictvím VPN nebo dedikovaného síťového okruhu do sítě TSK?

1. Bezpečnostní a provozní požadavky na síťové propojení

1. Jsou na straně TSK stanoveny konkrétní požadavky na způsob zabezpečení síťového propojení mezi CP a lokalitami (například šifrovaný tunel, certifikátová autentizace, konkrétní protokol VPN)?

1. Kdo nese odpovědnost za dostupnost síťového spojení mezi CP a lokalitami — je výpadek konektivity na straně TSK nebo lokality považován za vynětí z SLA na straně Dodavatele?

**REAKCE NA DOTAZ Č. 16**

Odpověď na dotaz 16 A)

1. lokality jsou připojeny v rámci jednotné sítě, která je vyčleněna pouze pro parkovací objekty

1. síťové připojení jednotlivých lokalit zajišťuje a hradí TSK

1. minimální přenosová rychlost:

- u větších parkovacích objektů je rychlost 100/100 Mbit

- u menších parkovacích objektů je rychlost 40/40 Mbit

Page 14

Odpověď na dotaz 16 B)

1. přístup k rozhraní GREEN CENTER bude zajiště příloha č. 2 B ZD. Obecně to platí i pro další technologie, které budou do CP integrovány.

1. kamery jsou přístupné přes kamerový server internetu (NAT) nebo je možné využít připojení přes protokol RTSP/ONVIF (záleží na přesném typu kamerového serveru/kamer), viz také příloha č. 2 B ZD.

1. viz odpověď e) Odpověď na dotaz 16 C)

1. Přístup uživatelů do webového prostředí CP bude parkovací objekty). Přístup uživatelů z mobilního zařízení řešení pro manažera/administrátora viz zadávací dokumentace.

1. Přístup do CP Dodavatelem bude uživatelům konkrétní zvolené technické řešení je pak na Dodavateli. Odpověď na dotaz 16 D)

1. Konkrétní způsob zabezpečení síťového propojení je výhradně na dodržet všechny zadané požadavky viz zadávací dokumentace Minimální funkční požadavky.

1. Závisí, zda výpadky konektivity jsou na straně výpadek konektivity je prokazatelně na straně Objednatele Objednatelem.

## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 8.4.2026

**DOTAZ**

Vážený zadavateli, zadavatel stanovil v bodě 9.1 ZD kvalifikační požadavek na předložení alespoň jedné významné služby spočívající v dodávce integrační platformy, technologických celků v minimálně 10 objektech, přičemž tyto celky musí povinně a kumulativně zahrnovat (1) Automatické parkovací systémy a (2) Kamerové dohledové systémy s požadavkem na „zobrazení obrazů z kamer". Požadované referenční období je stanoveno na poslední 3 roky. Dodavatel má za to, že takto formulovaný požadavek je nepřiměřeně restriktivní a omezuje hospodářskou soutěž v rozporu se zásadami přiměřenosti a zákazu diskriminace dle § 6 zákona č. 134/2016 Sb., o zadávání veřejných zakázek. Požadavek omezuje okruh potenciálních dodavatelů na subjekty, které realizovaly vysoce specifický projekt, v němž byl v rámci jedné jediné integrační platformy implementován rozsáhlý automatický parkovací systém a zároveň kamerový systém včetně přenosu obrazu. Mnoho vysoce kvalifikovaných dodavatelů disponuje robustními řešeními v oblasti parkování a smart city (např. integrace tisíců parkovacích míst, závor, senzorů a platebních bran), nicméně přenos živého kamerového obrazu do téže platformy často nebyl součástí plnění z důvodu rozhodnutí daných investorů, nikoliv kvůli technické neschopnosti dodavatele. Současně dodavatel považuje za nepřiměřené omezení referenčního období na poslední 3 roky, a to s ohledem na charakter, komplexnost a dlouhodobost realizace takto specifických softwarových děl. Standardem v oblasti dodávek komplexních centrálních integračních IT řešení pro veřejný sektor je referenční období alespoň 5 let.

n primárně prostřednictvím RestAPI, viz také (NVR), na který je možné se připojit přímo z zejména ze sítě TSK (oddělená síť pro všechny nebo z domova jsou pouze jako nouzové zajištěn v rámci zadaných požadavků objednatele a Dodavateli, nicméně je nutné

- Příloha č.2 A - Schéma CP a Dodavatele nebo Objednatele. V případě, že , tak odpovědnost jde pouze za

která kumulativně splňuje integraci podřízených

Page 15

Dodavatel proto žádá zadavatele o zvážení úpravy kvalifikačního požadavku tak, aby odpovídal zásadám přiměřenosti, umožnil širší hospodářskou soutěž a umožnil prokázat schopnost integrace parkovacích a kamerových systémů formou sčítání referencí.

**Za tímto účelem dodavatel navrhuje následující vyznačeny):**

„Dodavatel předloží seznam významných služeb realizovaných v posledních 5 letech, ze kterého bude vyplývat dodávka a/nebo implementace integrační (centralizační) platformy umožňující integraci a správu více technologických celků.

**Tato kvalifikace může být prokázána jednou nebo více referenčními zakázkami, které v součtu splní následující požadavky:**

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky v alespoň 10 objektech a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků.

1. Dodavatel v rámci referenčního plnění integroval alespoň následující technologické celky:

1. **Automatické parkovací systémy a (2) Kamerové dohledové systémy včetně schopnosti zobrazení obrazů z kamer. Požadavek na integraci kamerových dohledových systémů může být prokázán samostatnou referenční zakázkou."**

1. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele."

**REAKCE NA DOTAZ**

Zadavatel s ohledem na obdržený dotaz mění zadávací podmínky, konkrétně podmínky technické kvalifikace. Snahou zadavatele je umožnit co nejširší hospodářskou soutěž, které se budou moci zúčastnit všichni relevantní dodavatelé. Zadavatel mění čl. 9.1 zadávací dokumentace takto, přičemž v čarou zůstávají beze změny: Původní změní: Technická kvalifikace dle § 79 odst. 2 písm. b) ZZVZ 9.1 Dodavatel podle § 79 odst. 2 písm. b) ZZVZ prokazuje splnění technické kvalifikace předložením seznamu významných služeb provedených, tj. dokončených dodavatelem za poslední 3 roky před zahájením zadávacího řízení. Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: Nejméně 1 významné služby, spočívající v dodávce softwarového řešení integrační platformy, která integruje podřízené technologické celky

v alespoň 10 parkovacích či jiných objektech

a splňuje všechny následující požadavky (kumulativně):

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, zobrazení obrazů z kamer, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků

.

1. Technologické celky parkovacích či jiných objektů integrované do integrační platformy Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: Čestné prohlášení o členech realizačního týmu, ze kterého požadavků zadavatele. Zadavatel doporučuje využití vzorového čestného prohlášení, dokumenta0ce.

**úpravu požadavku (změny jsou**

tomto článku uvedené poznámky pod musí vyplývat splnění veškerých které je přílohou č. 3 Zadávací

Page 16

jsou alespoň následující: (1) Automatické parkovací systémy, (2) Kamerové dohledové systémy.

1. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele, nebo osoby s ním spojené ve smyslu § 23 odst. 7 zákona č. 586/1992 Sb., o daních z příjmů.

Nové znění (provedené změny **tučně** ): Technická kvalifikace dle § 79 odst. 2 písm. b) ZZVZ 9.1 Dodavatel podle § 79 odst. 2 písm. b) ZZVZ prokazuje splnění technické kvalifikace předložením seznamu významných služeb provedených, tj. dokončených dodavatelem za poslední **5 let** před zahájením zadávacího řízení. Zadavatel požaduje praxi dodavatele spočívající v Zadavatel požaduje praxi dodavatele spočívající v realizaci: Způsob prokázání: realizaci: Způsob prokázání:

**1 či více významných služeb** , spočívající v Čestné prohlášení **o významných službách** , ze dodávce softwarového řešení integrační kterého musí vyplývat splnění veškerých platformy, která **každá** integruje podřízené požadavků zadavatele. technologické celky

v alespoň 10 parkovacích či Zadavatel doporučuje využití vzorového čestného jiných objektech2

**a všechny dohromady**

prohlášení, které je přílohou č. 3 Zadávací

**splňují následující požadavky (každá**

dokumentace. **významná služby alespoň jednu)** :

1. Integrační platforma integruje alespoň tři různé podřízené technologické celky a umožňuje vzdálený dohled technologických prvků, upozornění na jejich závady, zobrazení obrazů z kamer, evidenci všech provozních událostí, evidenci přístupových práv a realizovaných přístupů do systému, možnost vzdáleného ovládání základních funkcí technologických prvků

.

1. **Do integrační platformy jsou integrovány alespoň automatické parkovací systémy jako technologický celek parkovacích či jiných objektů.**

1. **Do integrační platformy jsou integrovány alespoň kamerové dohledové systémy jako technologický celek parkovacích či jiných objektů.**

1. Alespoň dva různé podřízené technologické celky integrované do centralizační platformy jsou od jiného výrobce než dodavatele, nebo osoby s ním spojené ve smyslu § 23 odst. 7 zákona č. 586/1992 Sb., o daních z příjmů.

Page 17

## VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE NA ŽÁDOST ZE DNE 9.4.2026

**DOTAZ č. 1**

Vymezení vztahu standardního produktu a čl. 21.4 Žádáme o upřesnění výkladu čl. 21.4 návrhu Smlouvy. Rozumí Zadavatel tomuto ustanovení tak, že licence k Dílu, které nebylo vytvořeno pro Objednatele v rámci plnění Smlouvy (tj. ke standardnímu softwarovému produktu Dodavatele existujícímu před uzavřením Smlouvy), je poskytnuta výhradně za účelem provozování Centralizační platformy dle této veřejné zakázky, anebo má zadavatel za to, že tato licence opravňuje Objednatele k využití takového Díla i v rámci jiných informačních systémů, projektů či služeb Objednatele?

**REAKCE NA DOTAZ č. 1**

Dodavatel splní svoji povinnost ze Smlouvy i tím, pokud dodaný standardní SW umožní Zadavateli užít pouze pro účely plnohodnotného a nerušeného užití funkcí Centralizační platformy (srov. čl. 21.4.2 Smlouvy).

**DOTAZ č. 2**

Zdrojový kód a jeho rozsah Může Zadavatel jednoznačně potvrdit, že povinnost Dodavatele předat zdrojový kód dle čl. 22 Smlouvy se vztahuje výhradně na Díla ve smyslu čl. 21.3, tedy na zakázkový vývoj vytvořený specificky pro Objednatele v rámci této Smlouvy, a nikoli na zdrojové kódy standardního softwarového produktu Dodavatele nebo jeho obecných komponent?

**REAKCE NA DOTAZ č. 2**

Ano, povinnost předat zdrojový kód se vztahuje výhradně na Díla ve smyslu čl. 21.3 Smlouvy.

**DOTAZ č. 3**

Vztah licence k jiným projektům HMP nebo jeho organizací Zvažuje Zadavatel, že licence poskytované podle čl. 21 Smlouvy mají být využitelné i pro jiné projekty hl. m. Prahy nebo jím zřizovaných či ovládaných subjektů či jiné projekty/služby případné nástupnické organizace TSK, než je provoz Centralizační platformy dle této veřejné zakázky? Pokud ano, žádáme o potvrzení tohoto záměru, neboť má zásadní dopad na cenotvorbu této zakázky.

**REAKCE NA DOTAZ č. 3**

Pokud jde o SW „na zakázku" ve smyslu čl. 21.3 Smlouvy, k tomu Zadavatel nabyde velmi široká oprávnění blíže specifikovaná v tomtéž článku Smlouvy, vč. možnosti libovolně postoupit licenci či poskytnout sublicenci jakékoliv třetí osobě. Pokud jde o SW „standardní" ve smyslu čl. 21.4 Smlouvy – k tomu srov. odpověď na dotaz č. 1. Pro úplnost Zadavatel dodává, že postoupení či sublicencování takového SW je možné pouze za podmínek obecně závazných právních předpisů, tj. zásadně se souhlasem Dodavatele. Přechod jakýchkoliv licencí dle Smlouvy na právní nástupce Zadavatele vyplývá z obecně závazných právních předpisů a z čl. 21.6 Smlouvy.

**DOTAZ č. 4**

Tenký x Tlustý klient

Page 18

V zadávací dokumentaci je uvedeno, že Zadavatel očekává obsluhu Centralizační platformy skrze tenkého klienta. Domníváme se, že v některých případech je praktičtější využívat tzv. tlustého klienta, zejména pokud s ním pracují dispečeři. Jeho každodenní používání je mnohem komfortnější a nabízí standardně více funkcionalit. Naše doporučení je přinejmenším používat obě dvě verze, tenkého klienta například pro rychlý operativní přehled a detailní administraci přes tlustého klienta.

**REAKCE NA DOTAZ č. 4**

Zadavatel primárně požaduje tenkého klienta. Pokud nabízené řešení umí zajistit obsluhu Centralizační platformy taktéž skrze tlustého klienta, ať dodavatel tuto skutečnost uvede v popisu svého řešení s tím, že konkrétní provedení bude dohodnuto v rámci Implementačního projektu.

**DOTAZ č. 5**

SW x Operational maintenance V zadávací dokumentaci je exaktně uvedena softwarová maintenance, ale není uvedena aplikační operational maintenance, do které například spadá profilaxe apod. Předpokládá Zadavatel že operational maintenance je součástí servisních služeb, nebo ad-hoc služeb, či si ji chce zajišťovat Zadavatel vlastními silami, protože data v Centralizační platformě jsou jeho vlastnictví a zpracování dat je prováděno pracovníky Zadavatele?

**REAKCE NA DOTAZ č. 5**

Veškeré údržbové práce na Centralizační platformě (SW maintenance, aplikační SW maintenance) by měly být zahrnuty v Paušálních službách. To znamená, že Zadavatel nepřipouští, aby se kontinuální/rutinní činností k zajištění provozuschopnosti Centralizační platformy čerpaly formou ad-hoc služeb.

**DOTAZ č. 6**

KPI u SLA Považujeme SLA parametry za velmi ambiciózní. Například požadavek na vyřešení A incidentu za 1 hodinu s mnoha integrovanými technologiemi je prakticky nedosažitelný, pokud nebudou zastavovány „hodiny", kdy je potřeba zajistit součinnost Zadavatele nebo třetích stran. Navíc, pokud chápeme správně, Servisní služby jsou požadovány ve 24x7 režimu, což vyžaduje v rámci zajištění SaaS (a tím pádem u PaaS/IaaS) mít v pohotovosti širokou skupinu specialistů, a tím se cena za tuto položku výrazně zvyšuje a není prakticky možné dosáhnout požadované kvality za očekávanou cenu.

**REAKCE NA DOTAZ č. 6**

Zadavatel sděluje, že závazný návrh smlouvy ve svém čl. 13.3 (Servisní zásahy Dodavatele) obsahuje dodavatelem zmíněné „zastavování hodin" – zmíněný článek stanoví: „Dodavatel není odpovědný za prodlení s provedením Servisního zásahu (tj. s odstraněním Incidentu), pokud nebyla ze strany Objednatele poskytnuta součinnost v rozsahu a za podmínek této Smlouvy, nebo pokud se následně ukáže, že Problém leží mimo rozsah plnění Dodavatele dle této Smlouvy. V takovém případě lhůta pro provedení Servisního zásahu neběží, dokud není odstraněna překážka na straně Objednatele nebo jiné třetí strany, za kterou Dodavatel neodpovídá." Pokud jde o nastavení SLA, ta zohledňují provozní potřeby a rizika, která vyplývají z omezení/zastavení provozu Centralizační platformy.

Page 19

## PRODLOUŽENÍ LHŮTY PRO PODÁNÍ NABÍDEK

Zadavatel v souvislosti s tímto vysvětlením zadávací dokumentace prodloužil lhůtu pro podání nabídek o celou původní délku, a to

**do 21.05. 2026, 10:00.**

**________________________________ Ing. Dana Jurášková**

ředitelka úseku doprava v klidu Technická správa komunikací hl. m. Prahy, a.s.