Procurement observatory.

<!-- PAGE 1 --># VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE 05

## 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 30.4.2026

**DOTAZ č. 1 Příloha č. 2 D — Implementace — Harmonogram (etapy 2–4), čl. 4.1, 5.1–5.5, 6.1.1, 6.1.2, 6.2.1, 6.3.1, 8.2 Smlouvy aktuálně požaduje**

:

- 6 týdnů na zpracování Implementačního projektu (kompletní analýza a návrh řešení všech Objektů, Technologických celků, Technologických prvků, funkcí a uživatelských úkolů) + 2 týdny na jeho akceptaci Zadavatelem,
- Pouhé 2 týdny (etapa 3) od akceptace Implementačního projektu na integraci 2 testovacích Objektů do CP na reálných provozních datech, dodání uživatelské dokumentace a školení testérů TSK,
- pouze další 3 týdny (etapa 4) na integraci všech Objektů/Technologických celků/Technologických prvků do produkčního prostředí, dodání kompletní dokumentace (uživatelská + provozní + bezpečnostní) a školení zaměstnanců TSK všech rolí.

Vzhledem k tomu, že dle čl. 5.5 Smlouvy je závazný popis konkrétního řešení uzavřen až **akceptací Implementačního projektu**

, dodavatel může plnohodnotně zahájit vlastní programové práce na dohodnutém řešení až v okamžiku T1+8. Od tohoto okamžiku zbývá celkem 5 týdnů (2+3) na kompletní

<!-- PAGE 2 -->vývoj, integraci, otestování, zdokumentování a proškolení řešení v plném rozsahu předmětu plnění, a to včetně produkčního nasazení.

Takto nastavený harmonogram považujeme za rizikový pro obě smluvní strany, a to z níže uvedených důvodů:

➢ Fakticky nerealizovatelné, neboť předpokládaná pracnost je vysoká. Plných 5 týdnů od schválení návrhu na naprogramování, integrační testy, ladění na reálných datech poskytovaných rozhraními technologií, zpracování tří různých typů dokumentace a provedení školení pro více rolí neodpovídá pracnosti ani rizikovému profilu díla tohoto rozsahu. Jakákoliv odchylka akceptovaného návrhu od reálného chování zdrojových rozhraní (typicky zjistitelná až při integračních testech) vede v takto krátkém okně k nesplnění termínu T4. ➢ Nepoměr mezi přípravnou a realizační fází. Analytická fáze (6 týdnů) je dokonce delší než vlastní realizaci (5 týdnů po akceptaci). Objem práce a rizika v realizační fázi jsou několikanásobně vyšší. V praxi se analytické a vývojové činnosti navíc zpravidla prolínají i za předpokladu, že se customizuje osvědčené řešení. Ze zadávací dokumentace je patrné, že bude nutno vytvářet řadu nových rozhraní na stávající technologie Zadavatele, ale technická dokumentace k nim není dostupná. Zavázat se k realizaci za 5 týdnů a navíc s pevně definovanou (max. přípustnou) cenou je pro dodavatele vysoce rizikové. Navíc lze očekávat, že v případě vhodné časové konstelace by tato kritická část plnění mohla probíhat v průběhu letních dovolených a kapacity jak na straně odběratele i dodavatele budou limitovány. Realizace zakázky takové rozsahu vyžaduje součinnost více zainteresovaných subjektů a je nutné skloubit časové možnosti všech participujících a neponechat vše jen na smluvní formulaci o zajištění součinnosti ze strany Zadavatele. Dodavatel musí plánovat efektivně zdroje a nemůže nechat svůj tým čekat a zároveň mu nepřidělovat další práci, protože neví, kdy jiná zainteresovaná strana poskytne vstupy apod. ➢ Skrytá diskriminace dodavatelů (§ 6 odst. 2 ZZVZ). Takto nastavený harmonogram reálně mohou splnit pouze dodavatelé, kteří mají přístup k dokumentaci nebo mají již realizované interface na konkrétní technologie Zadavatele ve verzích, které je Zadavatel provozuje. Domníváme se, že škála technologií, které Zadavatel provozuje je tak jedinečná, že i připravené frameworky centralizačních platforem vyžadují značné přizpůsobení, resp. zákaznický vývoj, který v rozmezí 5 týdnů po akceptaci návrhu nelze naprogramovat, otestovat, zdokumentovat a odškolit. Tím dochází ke zvýhodnění úzké skupiny dodavatelů a hrozí riziko nerovného zacházení. ➢ Nepřiměřenost školení ve vztahu k dostupnosti řešení. Školení testerů TSK (etapa 3, T1+10) a všech rolí TSK (etapa 4, T1+13) je vhodné provést až nad stabilizovanou verzí CP. Nastavení, kdy školení probíhá paralelně s dokončováním vývoje a integrace, snižuje kvalitu školení a přenáší riziko nedostatečně vyškolené obsluhy na Zadavatele. Žádáme Zadavatele o úpravu harmonogramu, níže předkládáme základní varianty (zatím bez zohlednění prázdninového období):

**Varianta A** — Přerozdělení času mezi fáze při zachování T5. Zkrátit etapu 2 (Implementační projekt) ze 6 na 3–4 týdny a získaný čas přesunout do etap 3 a 4. Důvod: u zkušeného dodavatele CP je kompletní analytický výstup realizovatelný ve 3–4 týdnech, zejména pokud zadavatel poskytne vstupní údaje dle čl. 4.1 Smlouvy úplně a včas. Akceptační fáze návrhu (2 týdny.) zůstává beze změny. Výsledek: etapa 3 = 3–4 týden, etapa 4 = 4–5 týden., T5 = T1+20 beze změny.

**Varianta B** — Prodloužení realizační fáze s posunem T5. Ponechat etapu 2 v délce 6 týdnů, ale etapy 3 a 4 prodloužit na 4 týdny, resp. 6 týdnů (celkem +5 týdnů). Školení přesunout na konec etapy 4, kdy je CP integrována v produkčním rozsahu.

<!-- PAGE 3 -->Výsledek: T3 = T1+12, T4 = T1+18, T5 = T1+25.

**Varianta C** — Souběžná realizace analýzy a vývoje (iterativní přístup). Překlopit etapy 2 a 3 do iterativního režimu: části Implementačního projektu jsou akceptovány inkrementálně po Objektech / Technologických celcích, přičemž integrace 2 testovacích Objektů probíhá souběžně s dokončováním analýzy zbývajícího rozsahu. Pevné milníky T3 a T4 se tím nemění, ale dodavatel získává reálný prostor pro vývoj souběžně s uzavíráním návrhu.

**REAKCE NA DOTAZ č. 1**

Zadavatel nemění harmonogram uvedený v zadávací dokumentaci. Zadavatel hledá dodavatele centralizační platformy, který má toto řešení hotové, dlouhodobě ho poskytuje jako službu svým klientům a má s touto službou zkušenosti. Zadavatel tedy očekává, že Dodavatel umí připojit do své platformy technologie a zařízení, která jsou pro parkovací objekty provozním standardem, a to přes standardní API. Stejně tak zadavatel očekává, že dodavatel má pro své standardní řešení již zpracovanou dokumentaci (uživatelskou, provozní, bezpečnostní) i programy školení. Stávající harmonogram předpokládá, že v rámci implementačního projektu dodavatel současně připravuje integraci parkovacích objektů prostřednictvím API do svého existujícího řešení. Vstupní údaje (popisy všech rozhraní (např. API)/přístupů integrovaných v rámci Implementace, přístupy do konektivity a určení 2 Objektů k testování) budou předány spolu s předáním vstupních údajů. Datum předání je startem harmonogramu. Pro úplnost zadavatel doplňuje, že varianta C není smlouvou vyloučena – dojde-li k částečné akceptaci Implementačního projektu, bude tato závazná pro další činnosti dodavatele.

**DOTAZ č. 2 Vnitřní rozpor mezi Přílohou č. 2 a odpovědí na předešlé dotazy**

- Příloha č. 2 E Smlouvy, list „CP- incidenty", Kategorie A — kritická, položka „výpadek komunikace (přes CP) se zákazníkem v Objektu".
- Vysvětlení zadávací dokumentace, odpověď na dotaz č. 9 písm. a) – e).

**Identifikovaný rozpor**

V Příloze č. 2 je mezi kritickými incidenty kategorie A výslovně uveden výpadek komunikace (přes CP) se zákazníkem v Objektu. Slovní spojení „přes CP" implikuje, že komunikace se zákazníkem v Objektu je funkcionalita, kterou CP zajišťuje nebo zprostředkovává, a její výpadek je tedy přičitatelný dodavateli CP.

Oproti tomu ve Vysvětlení ZD, odpovědi na dotaz č. 9, Zadavatel sděluje, že:

- intercom instalovaný v parkovacích objektech integrovaných do CP bude vždy samostatný systém neintegrovaný do CP (odpověď 9 a, c),
- příjem hovoru je prostřednictvím telefonu obsluhy, tedy mimo CP (odpověď 9 d),
- případná budoucí integrace intercomu do CP by byla předmětem ad-hoc plnění (odpověď 9 a),
- školení pracovníků bude řešeno pouze simulovaným hovorem a vyhledáváním informací v CP (odpověď 9a).

Z odpovědi na dotaz č. 9 tedy vyplývá, že CP není prostředkem komunikace se zákazníkem v Objektu

- tu zajišťuje samostatný intercomový systém a telefonní spojení obsluhy, obojí mimo rozsah dodávky

<!-- PAGE 4 -->CP. Za těchto okolností nemůže pojmově nastat „výpadek komunikace přes CP": komunikace „přes CP" není předmětem plnění.

**REAKCE NA DOTAZ č. 2**

Uvedeného příkladu v Popisu a příkladech Incidentů v Citované incidenty jsou příklady, o které se může jednat funkcionalitu v úvodní fázi neobsahuje, logicky nemůže být ani reálným případem vady. Pro vyloučení pochybností potvrzujeme, že „výpadek komunikace (přes CP) se zákazníkem v nebude reálným případem kritické vady. Nicméně pokud by se v budoucnu do CP integrovala nová technologie zahrnující i komunikaci prostřednictvím interkomu, bude tato funkcionalita součástí integrace v Kategorii A incidentů validní.

**DOTAZ č. 3 Výčet Incidentů v jednotlivých kategoriích**

V listu ‚CP – incidenty' excelové Přílohy č. 2 Smlouvy jsou uvedeny příklady Incidentů, nicméně není zřejmé, do jaké kategorie spadá situace, kdy prostřednictvím CP není možné zvednout závoru v Objektu, která je napojena na místní parkovací systém, a to za předpokladu, že je zajištěno el. napájení, datová konektivita i vlastní funkčnost parkovacího systému. Žádáme o upřesnění, zda se jedná o B kategorii Incidentu?

**REAKCE NA DOTAZ č. 3**

Nemožnost zvednout závoru je zahrnuta v příkladu „výpadek možnosti ovládání jednoho nebo více technologických prvků parkovacího systému v Objektu", který je zařazen do katego

**DOTAZ č. 4**

V listu „CP-schéma-požadavky", požadavek č. 3 (Uživatelská práva) excelové Přílohy č.2 Smlouvy jsou definovány jen 3 základní uživatelské role.

V oblasti centralizačních a dohledových platforem srovnatelného rozsahu je dnes běžnou praxí používat víceúrovňový model správy uživatelských oprávnění, který individuální nastavení uživatele. Tento model umožňuje organizaci spravovat přístupy efektivně, auditovatelně a bez nutnosti udržovat oprávnění ručně u každého uživatele zvlášť. Z popisu Předmětu plnění, předpokládaného počtu uživatelů (min. 50) a více spravovaných objektů soudíme, že i Zadavatel od dodávané CP takový model očekává. Pro vyloučení pochybností a pro zajištění porovnatelnosti nabídek si dovolujeme požádat o potvrzení, zda očekávání Zadavatele na schopnosti CP jsou definovány následovně: Organizovat uživatele do skupin uspořádaných ve víceúrovňové stromové struktuře (nadřazená skupina → podskupina → uživatel), s automatickým děděním oprávnění shora dolů. Přiřadit uživateli i skupině 0 až N kompetencí současně, a to s možností manuálně měnit pořadí

1. přidělených kompetencí.

Nastavit konkrétnímu uživateli individuální oprávnění (povolení i zákaz) bez nutnosti zakládat kvůli němu novou kompetenci.

Kategorii A – kritická si je zadavatel vědom (a to i v budoucnu) a tím pádem bude příklad uvedený

kombinuje kompetence, skupiny a s desítkami uživatelů a více lokalitami

. . Jestliže CP tuto Objektu"

rie A – kritická.

<!-- PAGE 5 -->V případě konfliktu, kdy jeden zdroj přístup povoluje a jiný zakazuje, vyhodnotit oprávnění podle níže uvedeného pořadí priorit, kde pravidlo „blíže uživateli" má vyšší přednost a vyšší priorita přebíjí nižší bez ohledu na to, zda jde o povolení, či zákaz:

**\# Zdroj oprávnění**

1 Oprávnění nastavené přímo na uživateli 2 Kompetence přidělená uživateli (mezi více kompetencemi rozhoduje jejich vzájemné pořadí) 3 Oprávnění skupiny, do které uživatel přímo patří 4 Kompetence přidělená této skupině 5 Oprávnění nadřazené skupiny (rekurzivně výše) 6 Kompetence přidělená nadřazené skupině

Tento model odpovídá standardu používanému v systémech této kategorie (principy role-based access control a least privilege) a je zároveň předpokladem pro auditovatelnou správu přístupů ve smyslu kyberbezpečnostních požadavků uvedených v požadavku č. 25 Zadávací dokumentace. Otázka: Chápeme tedy správně, že popsaný model odpovídá očekávání Zadavatele a že všichni uchazeči musí tento model ve své nabídce zajistit, aby bylo dosaženo souladu požadavky na cyber securitu, vzhledem k tomu, že se jedná o službu v režimu vyšších povinností a Zadavatele vnímáme jako provozovatele kritické infrastruktury?

**REAKCE NA DOTAZ č. 4**

Zadavatel očekává splnění minimálních požadavků na centralizační platformu, jak je definuje zadávací dokumentace. Požadavkem Zadavatele je mimo jiné nabídnout řešení splňující požadavky na kyberbezpečnost. Uchazeč ve své nabídce popíše konkrétně nabízení řešení, které může minimální požadavky rozšiřovat a nabízet tak řešení dle jeho best-practise zkušenosti. Jak nicméně dodavatel dostojí požadavkům na kyberbezpečnost je plně na jeho uvážení a odpovědnosti.

**DOTAZ č. 5 Smluvní pokuty za porušení SLA a jejich vztah k měsíční ceně Servisních služeb**

Dodavatel nepředpokládá, že by se v průběhu plnění Smlouvy dovolával výjimek, liberačních důvodů nebo jiných ustanovení omezujících odpovědnost, a považuje dodržování SLA parametrů za standardní součást poskytovaných Servisních služeb. Pro účely řádného a transparentního nacenění ekonomických rizik však žádáme o upřesnění, zda je záměrem Zadavatele, aby souhrnná výše smluvních pokut za porušení SLA parametrů dle Přílohy č. 2 Smlouvy mohla v jednom kalendářním měsíci přesáhnout částku skutečně uhrazenou Dodavateli za Servisní služby dle čl. 3.1.2 písm. c) Smlouvy za tentýž měsíc, případně zda Zadavatel připouští revizi čl. 31.1.2., podle které by maximální výše těchto smluvních pokut v daném měsíci byla omezena výší této měsíční ceny. Uvedené upřesnění je nezbytné výlučně pro stanovení nabídkové ceny a přiměřené ocenění rizika spojeného s paušálním poskytováním Servisních služeb.

<!-- PAGE 6 -->**REAKCE NA DOTAZ č. 5**

Zadavatel k dotazu sděluje, že výše smluvních pokut, které se váží na porušení SLA, nebude limitována měsíčním plněním. Současně však zadavatel připomíná, že čl. 29.6 smlouvy limituje nejen odpovědnost dodavatele za újmu, ale taktéž nároky zadavatele ze smluvních pokut vč. těch za porušení SLA parametrů.

**DOTAZ č. 6 Kumulace „Dalších Servisních služeb" dle čl. 13.4 Smlouvy a její časové omezení**

Z čl. 13.4 Smlouvy vyplývá, že Dodavatel je povinen v rámci Servisních služeb vyhradit kapacitu dvaceti

1. hodin měsíčně, přičemž nevyčerpané hodiny se kumulují do dalších měsíců bez časového omezení a mohou být následně čerpány až do rozsahu 160 hodin v jednom kalendářním měsíci. Dodavatel žádá o upřesnění, zda je záměrem Zadavatele, aby tato kumulace nevyčerpaných hodin probíhala bez jakéhokoli časového omezení po celou dobu trvání Smlouvy. V takovém případě může snadno dojít ke kumulaci stovek nevyužitých hodin. Žádáme o revizi tak, že se kumulace vztahuje pouze k časově omezenému období (např. v rámci určitého klouzavého časového úseku 3 měsíců). Uvedené upřesnění je nezbytné výhradně pro účely kalkulace nabídkové ceny, jelikož povinnost dlouhodobě držet a potenciálně jednorázově uvolnit kumulovanou kapacitu v řádu desítek či stovek člověkohodin v jednom měsíci či několika po sobě jdoucích měsících má přímý dopad na ocenění paušální ceny Servisních služeb dle čl. 3.1.2 písm. c) Smlouvy a na celkovou ekonomickou předvídatelnost plnění.

**REAKCE NA DOTAZ č. 6**

Zadavatel čl. 13.4 koncipoval tak, aby ke kumulaci dojít mohlo, nicméně aby tato kumulace nezatížila dodavatele v jednom měsíci více, než je ekvivalent jednoho pracovníka (160h/měsíc). Pro úplnost zadavatel uvádí, že zánikem smlouvy zaniká právo využít nevyčerpané hodiny.

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

Zadavatel v souvislosti s tímto vysvětlením zadávací dokumentace neprodloužil lhůtu pro podání nabídek, neboť to povaha provedených změn nebo doplnění zadávací dokumentace nevyžaduje.

_______________________________________ Ing. Martin Pípa člen představenstva Technická správa komunikací hl. m. Prahy, a.s.

Page 1

# VYSVĚTLENÍ ZADÁVACÍ DOKUMENTACE 05

## 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 30.4.2026

**DOTAZ č. 1 Příloha č. 2 D — Implementace — Harmonogram (etapy 2–4), čl. 4.1, 5.1–5.5, 6.1.1, 6.1.2, 6.2.1, 6.3.1, 8.2 Smlouvy aktuálně požaduje**

:

- 6 týdnů na zpracování Implementačního projektu (kompletní analýza a návrh řešení všech Objektů, Technologických celků, Technologických prvků, funkcí a uživatelských úkolů) + 2 týdny na jeho akceptaci Zadavatelem,

- Pouhé 2 týdny (etapa 3) od akceptace Implementačního projektu na integraci 2 testovacích Objektů do CP na reálných provozních datech, dodání uživatelské dokumentace a školení testérů TSK,

- pouze další 3 týdny (etapa 4) na integraci všech Objektů/Technologických celků/Technologických prvků do produkčního prostředí, dodání kompletní dokumentace (uživatelská + provozní + bezpečnostní) a školení zaměstnanců TSK všech rolí.

Vzhledem k tomu, že dle čl. 5.5 Smlouvy je závazný popis konkrétního řešení uzavřen až **akceptací Implementačního projektu**

, dodavatel může plnohodnotně zahájit vlastní programové práce na dohodnutém řešení až v okamžiku T1+8. Od tohoto okamžiku zbývá celkem 5 týdnů (2+3) na kompletní

Page 2

vývoj, integraci, otestování, zdokumentování a proškolení řešení v plném rozsahu předmětu plnění, a to včetně produkčního nasazení.

Takto nastavený harmonogram považujeme za rizikový pro obě smluvní strany, a to z níže uvedených důvodů:

➢ Fakticky nerealizovatelné, neboť předpokládaná pracnost je vysoká. Plných 5 týdnů od schválení návrhu na naprogramování, integrační testy, ladění na reálných datech poskytovaných rozhraními technologií, zpracování tří různých typů dokumentace a provedení školení pro více rolí neodpovídá pracnosti ani rizikovému profilu díla tohoto rozsahu. Jakákoliv odchylka akceptovaného návrhu od reálného chování zdrojových rozhraní (typicky zjistitelná až při integračních testech) vede v takto krátkém okně k nesplnění termínu T4. ➢ Nepoměr mezi přípravnou a realizační fází. Analytická fáze (6 týdnů) je dokonce delší než vlastní realizaci (5 týdnů po akceptaci). Objem práce a rizika v realizační fázi jsou několikanásobně vyšší. V praxi se analytické a vývojové činnosti navíc zpravidla prolínají i za předpokladu, že se customizuje osvědčené řešení. Ze zadávací dokumentace je patrné, že bude nutno vytvářet řadu nových rozhraní na stávající technologie Zadavatele, ale technická dokumentace k nim není dostupná. Zavázat se k realizaci za 5 týdnů a navíc s pevně definovanou (max. přípustnou) cenou je pro dodavatele vysoce rizikové. Navíc lze očekávat, že v případě vhodné časové konstelace by tato kritická část plnění mohla probíhat v průběhu letních dovolených a kapacity jak na straně odběratele i dodavatele budou limitovány. Realizace zakázky takové rozsahu vyžaduje součinnost více zainteresovaných subjektů a je nutné skloubit časové možnosti všech participujících a neponechat vše jen na smluvní formulaci o zajištění součinnosti ze strany Zadavatele. Dodavatel musí plánovat efektivně zdroje a nemůže nechat svůj tým čekat a zároveň mu nepřidělovat další práci, protože neví, kdy jiná zainteresovaná strana poskytne vstupy apod. ➢ Skrytá diskriminace dodavatelů (§ 6 odst. 2 ZZVZ). Takto nastavený harmonogram reálně mohou splnit pouze dodavatelé, kteří mají přístup k dokumentaci nebo mají již realizované interface na konkrétní technologie Zadavatele ve verzích, které je Zadavatel provozuje. Domníváme se, že škála technologií, které Zadavatel provozuje je tak jedinečná, že i připravené frameworky centralizačních platforem vyžadují značné přizpůsobení, resp. zákaznický vývoj, který v rozmezí 5 týdnů po akceptaci návrhu nelze naprogramovat, otestovat, zdokumentovat a odškolit. Tím dochází ke zvýhodnění úzké skupiny dodavatelů a hrozí riziko nerovného zacházení. ➢ Nepřiměřenost školení ve vztahu k dostupnosti řešení. Školení testerů TSK (etapa 3, T1+10) a všech rolí TSK (etapa 4, T1+13) je vhodné provést až nad stabilizovanou verzí CP. Nastavení, kdy školení probíhá paralelně s dokončováním vývoje a integrace, snižuje kvalitu školení a přenáší riziko nedostatečně vyškolené obsluhy na Zadavatele. Žádáme Zadavatele o úpravu harmonogramu, níže předkládáme základní varianty (zatím bez zohlednění prázdninového období):

**Varianta A** — Přerozdělení času mezi fáze při zachování T5. Zkrátit etapu 2 (Implementační projekt) ze 6 na 3–4 týdny a získaný čas přesunout do etap 3 a 4. Důvod: u zkušeného dodavatele CP je kompletní analytický výstup realizovatelný ve 3–4 týdnech, zejména pokud zadavatel poskytne vstupní údaje dle čl. 4.1 Smlouvy úplně a včas. Akceptační fáze návrhu (2 týdny.) zůstává beze změny. Výsledek: etapa 3 = 3–4 týden, etapa 4 = 4–5 týden., T5 = T1+20 beze změny.

**Varianta B** — Prodloužení realizační fáze s posunem T5. Ponechat etapu 2 v délce 6 týdnů, ale etapy 3 a 4 prodloužit na 4 týdny, resp. 6 týdnů (celkem +5 týdnů). Školení přesunout na konec etapy 4, kdy je CP integrována v produkčním rozsahu.

Page 3

Výsledek: T3 = T1+12, T4 = T1+18, T5 = T1+25.

**Varianta C** — Souběžná realizace analýzy a vývoje (iterativní přístup). Překlopit etapy 2 a 3 do iterativního režimu: části Implementačního projektu jsou akceptovány inkrementálně po Objektech / Technologických celcích, přičemž integrace 2 testovacích Objektů probíhá souběžně s dokončováním analýzy zbývajícího rozsahu. Pevné milníky T3 a T4 se tím nemění, ale dodavatel získává reálný prostor pro vývoj souběžně s uzavíráním návrhu.

**REAKCE NA DOTAZ č. 1**

Zadavatel nemění harmonogram uvedený v zadávací dokumentaci. Zadavatel hledá dodavatele centralizační platformy, který má toto řešení hotové, dlouhodobě ho poskytuje jako službu svým klientům a má s touto službou zkušenosti. Zadavatel tedy očekává, že Dodavatel umí připojit do své platformy technologie a zařízení, která jsou pro parkovací objekty provozním standardem, a to přes standardní API. Stejně tak zadavatel očekává, že dodavatel má pro své standardní řešení již zpracovanou dokumentaci (uživatelskou, provozní, bezpečnostní) i programy školení. Stávající harmonogram předpokládá, že v rámci implementačního projektu dodavatel současně připravuje integraci parkovacích objektů prostřednictvím API do svého existujícího řešení. Vstupní údaje (popisy všech rozhraní (např. API)/přístupů integrovaných v rámci Implementace, přístupy do konektivity a určení 2 Objektů k testování) budou předány spolu s předáním vstupních údajů. Datum předání je startem harmonogramu. Pro úplnost zadavatel doplňuje, že varianta C není smlouvou vyloučena – dojde-li k částečné akceptaci Implementačního projektu, bude tato závazná pro další činnosti dodavatele.

**DOTAZ č. 2 Vnitřní rozpor mezi Přílohou č. 2 a odpovědí na předešlé dotazy**

- Příloha č. 2 E Smlouvy, list „CP- incidenty", Kategorie A — kritická, položka „výpadek komunikace (přes CP) se zákazníkem v Objektu".

- Vysvětlení zadávací dokumentace, odpověď na dotaz č. 9 písm. a) – e).

**Identifikovaný rozpor**

V Příloze č. 2 je mezi kritickými incidenty kategorie A výslovně uveden výpadek komunikace (přes CP) se zákazníkem v Objektu. Slovní spojení „přes CP" implikuje, že komunikace se zákazníkem v Objektu je funkcionalita, kterou CP zajišťuje nebo zprostředkovává, a její výpadek je tedy přičitatelný dodavateli CP.

Oproti tomu ve Vysvětlení ZD, odpovědi na dotaz č. 9, Zadavatel sděluje, že:

- intercom instalovaný v parkovacích objektech integrovaných do CP bude vždy samostatný systém neintegrovaný do CP (odpověď 9 a, c),

- příjem hovoru je prostřednictvím telefonu obsluhy, tedy mimo CP (odpověď 9 d),

- případná budoucí integrace intercomu do CP by byla předmětem ad-hoc plnění (odpověď 9 a),

- školení pracovníků bude řešeno pouze simulovaným hovorem a vyhledáváním informací v CP (odpověď 9a).

Z odpovědi na dotaz č. 9 tedy vyplývá, že CP není prostředkem komunikace se zákazníkem v Objektu

- tu zajišťuje samostatný intercomový systém a telefonní spojení obsluhy, obojí mimo rozsah dodávky

Page 4

CP. Za těchto okolností nemůže pojmově nastat „výpadek komunikace přes CP": komunikace „přes CP" není předmětem plnění.

**REAKCE NA DOTAZ č. 2**

Uvedeného příkladu v Popisu a příkladech Incidentů v Citované incidenty jsou příklady, o které se může jednat funkcionalitu v úvodní fázi neobsahuje, logicky nemůže být ani reálným případem vady. Pro vyloučení pochybností potvrzujeme, že „výpadek komunikace (přes CP) se zákazníkem v nebude reálným případem kritické vady. Nicméně pokud by se v budoucnu do CP integrovala nová technologie zahrnující i komunikaci prostřednictvím interkomu, bude tato funkcionalita součástí integrace v Kategorii A incidentů validní.

**DOTAZ č. 3 Výčet Incidentů v jednotlivých kategoriích**

V listu ‚CP – incidenty' excelové Přílohy č. 2 Smlouvy jsou uvedeny příklady Incidentů, nicméně není zřejmé, do jaké kategorie spadá situace, kdy prostřednictvím CP není možné zvednout závoru v Objektu, která je napojena na místní parkovací systém, a to za předpokladu, že je zajištěno el. napájení, datová konektivita i vlastní funkčnost parkovacího systému. Žádáme o upřesnění, zda se jedná o B kategorii Incidentu?

**REAKCE NA DOTAZ č. 3**

Nemožnost zvednout závoru je zahrnuta v příkladu „výpadek možnosti ovládání jednoho nebo více technologických prvků parkovacího systému v Objektu", který je zařazen do katego

**DOTAZ č. 4**

V listu „CP-schéma-požadavky", požadavek č. 3 (Uživatelská práva) excelové Přílohy č.2 Smlouvy jsou definovány jen 3 základní uživatelské role.

V oblasti centralizačních a dohledových platforem srovnatelného rozsahu je dnes běžnou praxí používat víceúrovňový model správy uživatelských oprávnění, který individuální nastavení uživatele. Tento model umožňuje organizaci spravovat přístupy efektivně, auditovatelně a bez nutnosti udržovat oprávnění ručně u každého uživatele zvlášť. Z popisu Předmětu plnění, předpokládaného počtu uživatelů (min. 50) a více spravovaných objektů soudíme, že i Zadavatel od dodávané CP takový model očekává. Pro vyloučení pochybností a pro zajištění porovnatelnosti nabídek si dovolujeme požádat o potvrzení, zda očekávání Zadavatele na schopnosti CP jsou definovány následovně: Organizovat uživatele do skupin uspořádaných ve víceúrovňové stromové struktuře (nadřazená skupina → podskupina → uživatel), s automatickým děděním oprávnění shora dolů. Přiřadit uživateli i skupině 0 až N kompetencí současně, a to s možností manuálně měnit pořadí

1. přidělených kompetencí.

Nastavit konkrétnímu uživateli individuální oprávnění (povolení i zákaz) bez nutnosti zakládat kvůli němu novou kompetenci.

Kategorii A – kritická si je zadavatel vědom (a to i v budoucnu) a tím pádem bude příklad uvedený

kombinuje kompetence, skupiny a s desítkami uživatelů a více lokalitami

. . Jestliže CP tuto Objektu"

rie A – kritická.

Page 5

V případě konfliktu, kdy jeden zdroj přístup povoluje a jiný zakazuje, vyhodnotit oprávnění podle níže uvedeného pořadí priorit, kde pravidlo „blíže uživateli" má vyšší přednost a vyšší priorita přebíjí nižší bez ohledu na to, zda jde o povolení, či zákaz:

**\# Zdroj oprávnění**

1 Oprávnění nastavené přímo na uživateli 2 Kompetence přidělená uživateli (mezi více kompetencemi rozhoduje jejich vzájemné pořadí) 3 Oprávnění skupiny, do které uživatel přímo patří 4 Kompetence přidělená této skupině 5 Oprávnění nadřazené skupiny (rekurzivně výše) 6 Kompetence přidělená nadřazené skupině

Tento model odpovídá standardu používanému v systémech této kategorie (principy role-based access control a least privilege) a je zároveň předpokladem pro auditovatelnou správu přístupů ve smyslu kyberbezpečnostních požadavků uvedených v požadavku č. 25 Zadávací dokumentace. Otázka: Chápeme tedy správně, že popsaný model odpovídá očekávání Zadavatele a že všichni uchazeči musí tento model ve své nabídce zajistit, aby bylo dosaženo souladu požadavky na cyber securitu, vzhledem k tomu, že se jedná o službu v režimu vyšších povinností a Zadavatele vnímáme jako provozovatele kritické infrastruktury?

**REAKCE NA DOTAZ č. 4**

Zadavatel očekává splnění minimálních požadavků na centralizační platformu, jak je definuje zadávací dokumentace. Požadavkem Zadavatele je mimo jiné nabídnout řešení splňující požadavky na kyberbezpečnost. Uchazeč ve své nabídce popíše konkrétně nabízení řešení, které může minimální požadavky rozšiřovat a nabízet tak řešení dle jeho best-practise zkušenosti. Jak nicméně dodavatel dostojí požadavkům na kyberbezpečnost je plně na jeho uvážení a odpovědnosti.

**DOTAZ č. 5 Smluvní pokuty za porušení SLA a jejich vztah k měsíční ceně Servisních služeb**

Dodavatel nepředpokládá, že by se v průběhu plnění Smlouvy dovolával výjimek, liberačních důvodů nebo jiných ustanovení omezujících odpovědnost, a považuje dodržování SLA parametrů za standardní součást poskytovaných Servisních služeb. Pro účely řádného a transparentního nacenění ekonomických rizik však žádáme o upřesnění, zda je záměrem Zadavatele, aby souhrnná výše smluvních pokut za porušení SLA parametrů dle Přílohy č. 2 Smlouvy mohla v jednom kalendářním měsíci přesáhnout částku skutečně uhrazenou Dodavateli za Servisní služby dle čl. 3.1.2 písm. c) Smlouvy za tentýž měsíc, případně zda Zadavatel připouští revizi čl. 31.1.2., podle které by maximální výše těchto smluvních pokut v daném měsíci byla omezena výší této měsíční ceny. Uvedené upřesnění je nezbytné výlučně pro stanovení nabídkové ceny a přiměřené ocenění rizika spojeného s paušálním poskytováním Servisních služeb.

Page 6

**REAKCE NA DOTAZ č. 5**

Zadavatel k dotazu sděluje, že výše smluvních pokut, které se váží na porušení SLA, nebude limitována měsíčním plněním. Současně však zadavatel připomíná, že čl. 29.6 smlouvy limituje nejen odpovědnost dodavatele za újmu, ale taktéž nároky zadavatele ze smluvních pokut vč. těch za porušení SLA parametrů.

**DOTAZ č. 6 Kumulace „Dalších Servisních služeb" dle čl. 13.4 Smlouvy a její časové omezení**

Z čl. 13.4 Smlouvy vyplývá, že Dodavatel je povinen v rámci Servisních služeb vyhradit kapacitu dvaceti

1. hodin měsíčně, přičemž nevyčerpané hodiny se kumulují do dalších měsíců bez časového omezení a mohou být následně čerpány až do rozsahu 160 hodin v jednom kalendářním měsíci. Dodavatel žádá o upřesnění, zda je záměrem Zadavatele, aby tato kumulace nevyčerpaných hodin probíhala bez jakéhokoli časového omezení po celou dobu trvání Smlouvy. V takovém případě může snadno dojít ke kumulaci stovek nevyužitých hodin. Žádáme o revizi tak, že se kumulace vztahuje pouze k časově omezenému období (např. v rámci určitého klouzavého časového úseku 3 měsíců). Uvedené upřesnění je nezbytné výhradně pro účely kalkulace nabídkové ceny, jelikož povinnost dlouhodobě držet a potenciálně jednorázově uvolnit kumulovanou kapacitu v řádu desítek či stovek člověkohodin v jednom měsíci či několika po sobě jdoucích měsících má přímý dopad na ocenění paušální ceny Servisních služeb dle čl. 3.1.2 písm. c) Smlouvy a na celkovou ekonomickou předvídatelnost plnění.

**REAKCE NA DOTAZ č. 6**

Zadavatel čl. 13.4 koncipoval tak, aby ke kumulaci dojít mohlo, nicméně aby tato kumulace nezatížila dodavatele v jednom měsíci více, než je ekvivalent jednoho pracovníka (160h/měsíc). Pro úplnost zadavatel uvádí, že zánikem smlouvy zaniká právo využít nevyčerpané hodiny.

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

Zadavatel v souvislosti s tímto vysvětlením zadávací dokumentace neprodloužil lhůtu pro podání nabídek, neboť to povaha provedených změn nebo doplnění zadávací dokumentace nevyžaduje.

_______________________________________ Ing. Martin Pípa člen představenstva Technická správa komunikací hl. m. Prahy, a.s.