Portál výběrových řízení

Detail

Číslo zakázky
ISE-ad97cab3-6aff
Název zakázky
Implementace Zákaznického portálu pro Pražskou plynárenskou, a.s. - změna lhůty pro podání nabídek
Uveřejněno od
08.11.2019 13:00:23
Aktualizace
25.11.2019 17:10:08
Lhůta pro podání nabídek
03.12.2019 16:00:00
Druh
dodávky
Předmět
Předmětem výběrového řízení je návrh a implementace nového zákaznického portálu PPAS pro segment domácností a maloodběratelů.
Kontaktní osoba
Petrášková Lenka Ing.

Dodatečné informace k zadávacím podmínkám na výběrové řízení

Dotaz č. 1:
Dobrý den, chtěli bychom Vás požádat o zodpovězení našich dotazů. Děkuji Vám předem, Martin Trávníček, SEVITECH CZ 1. Je z hlediska portálového řešení nějaká preference, např. Cloud nebo On-premise? 2. Má být předmětem dodávky pouze implementace portálového řešení pro komunikaci se zákazníkem, nebo také redakční systém. V případě, že se má implementovat také redakční systém, jakou funkcionalitu by měl tento redakční systém obsahovat? 3. V jakém postavení bude redakční systém k portálovému řešení a internetovým stránkám? 4. Má portálové řešení přebrat část funkcionality interních back-end systémů (např. možnost konfigurovat atributy produktů, zobrazování předběžné ceny) anebo se má spíše jednat o nástroj pro prezentaci a sběr informací, přičemž jejich zpracovaní bude probíhat výlučně ve stávajících back-end systémech? 5. Při samoodečtu realizovaném ve třetí fázi projektu se očekává využití stávajících OCR nástrojů, anebo tyto nástroje mají být předmětem dodávky? Pokud mají být předmětem dodávky, je možné specifikovat jejich potřebné množství, např. počet uživatelů, pracovních stanic a pod? 6. Kolik administrátorů bude spravovat pořizované řešení?
Odpověď:
1. Preferujeme On-Premise. 2. Preferujeme platformu, jejíž správa není závislá pouze na jednom implementačním partnerovi (vendor lock). 3. Současné webové stránky jsou na Drupal a budou nezávislé vůči ZP (zákaznický portál). 4. Ano, jedná se o nástroj pro prezentaci a sběr informací, jejich zpracovaní bude probíhat výlučně ve stávajících back-end systémech. 5. Stávající stávající OCR nemáme, bude předmětem dodávky. Aktuální počet samoodečtů je v  řádech stovek, přičemž počítáme s  nárůstem. 6. Odhadujeme, že 2-3 administrátoři.

Dotaz č. 2:
Dobrý den, v příloze zasíláme doplňující dotazy a prosíme o jejich zodpovězení, případně upřesnění zadání. Zároveň žádáme o prodloužení původní lhůty pro zpracování nabídky z 29.11. na termín, který bude min. 3 týdny po obdržení odpovědí na doplňující dotazy. Děkuji a přeji pěkný den Petr Medřický AMI Praha a.s.
Přílohy:
d-AMI_Doplnujici_dotazy_1v0.pdf
Odpověď:

Dotaz č. 3:
Dobrý den, v příloze zasíláme doplňující dotazy a prosíme o jejich zodpovězení, případně upřesnění zadání. Zároveň žádáme o prodloužení původní lhůty pro zpracování nabídky z 29.11. na termín, který bude min. 3 týdny po obdržení odpovědí na doplňující dotazy. Děkuji a přeji pěkný den Petr Medřický AMI Praha a.s.
Přílohy:
d-AMI_Doplnujici_dotazy_1v0.pdf
Odpověď:
Odpovědi na dotazy jsou v příloze. Termín ukončení výběrového řízení bude posunut k datu 3.12.2019 - 16.00 hodin.
Přílohy:
o-Odpov_di_Z_kaznick__port_l_AMI.pdf

Dotaz č. 4:
Dobrý den, prosím o zodpovězení následujících dotazů. Děkuji: Klientská data/dokumenty mají být ukládána v rámci nového zákaznického portálu, nebo budou uložena ve stávajících BE systémech? Jaký bude použit systém pro ověřování identity a přes jaký protokol se bude komunikovat? Jakým způsobem jsou evidovány přihlašovací údaje o zákaznících ve stávajícím řešení (z pohledu migrace uživatelských jmen a hesel)? Máte představu o informacích potřebných pro auditní stopu, kterou budete požadovat? Bylo by prosím možné nasdílet aktuální branding/grafický manuál, pokud je k dispozici?
Odpověď:
1. Budou uložena ve stávajících BE systémech 2. V  rámci funkčního požadavku ID1 Registrace do portálu, neplánujeme využití identity management systému. V rámci požadavku ID20 „Přepis odběrného místa bez změny dodavatele“ očekáváme, že uchazeč navrhne způsoby, jakými bude možné ověřit identitu zákazníka (např. identifikace pomocí korunové platby, datovou schránkou apod.). 3. Přihlašovací údaje jsou evidovány nyní v zákaznickém portálu, očekáváme návrh od uchazeče. 4. Konkrétní akce uživatele, které bude třeba logovat budou definovány v rámci technického návrhu. 5. Grafický manuál bude poskytnut na vyžádání a na základě podepsání NDA. Logo je ke stažení na webových stránkách www.ppas.cz

Dotaz č. 5:
1. Kdy bude dodáno časování zátěžových a penetračních testů?

2. Od klientů jsme viděli trvání penetračních testů v rozpětí jednoho až 4 týdnů, což má dopad na dodávku, blokaci prostředí atp. Kdo bude tvořit textový obsah?
a) Dodáte vy
b) Dodáme my

3. Jazykové verze:
a) Kolik jich bude a o jaké jazyky se jedná?
b) Kdo bude dělat překlad?
c) Překlady budou 1:1?

4. Kolik prostředí (prod+non-prod) máme očekávat?
a) Jaká bude úroveň integrací na jednotlivých prostředích včetně dat?
b) Jaká je možnost mít vývojové prostředí mimo ekosystém PPAS a mít k dispozici mocky integrací / ostrých integrací?
Odpověď:
Odpovědi na dotazy jsou uvedeny v příloze
Přílohy:
o-Odpov_di_Z_kaznick__port_l_Lundegaard.pdf
o-P__loha____1_Prototyp_dotaz__Lundegaard_.pdf

Dotaz č. 6:
1. Jak má být řešení provozováno? Typické je pro nás zajišťovat provoz ve virtálních strojích pod naší správou běžící na "železe" klienta pod jeho správou.
2. V příloze 3 jsou uvedeny požadavky na operační a databázový systém. Jsou využití nabízených možností nutné podmínky nebo je to jen možnost, kterou je dovolené využít?
3. Která přesně data mají být nově uložena v novém portálovém řešení a bude potřeba aby byla součástí řešení vlastní databáze pro trvalé uložení dat, nebo budou všechna data dotahována ze SAPu jako z primární zdroje pravdy.
4. Má nové řešení využívat nějaké existující SSO (single sign on) systém či existující autorizační server pro přihlašování uživatelů, nebo má být takovýto systém naopak navrhnut v rámci nového řešení?
5. V příloze 1 je požadavek na seznam konkrétních subdodavatelů a taky, že minimálně 50% zakázky musej dělat interní zaměstnanci. Je toto mandatorní požadavek?
6.Vztahují se sankce za nedodržení harmonogramu pro případ nesoučinnosti PPAS či 3. stran (např. SAP)?
7. Zhotovitel je Dílo oprávněn plnit po předchozím souhlasu ISE i prostřednictvím vzdáleného přístupu. Za naší stranu je toto preferovaníé řešení. Lze to tedy potvrdit.
8. Je v případě licencí třetí stzrany požadována dodání spolu s dodávkou řešení, nebo bude realizováno zadavatelem?
9. V zadávací dokumentaci je definováno, že nemí možné, aby správa CMS byla závislá pouze na jednom implementačním partnerovi. Zároven je uveden požadavek na dodání zdrojového kódu a vývojářské dokumentace s případnou možností vlastního vývoje. Je toto nebytná prerekvizita?
Odpověď:
Provoz aplikace 1. Tímto způsobem je zajišťován provoz i v PP. 2. Jedná se o nutnou podmínku. U OS je možná varianta Centons Linux. 3. Uchazeč ve své nabídce předloží o návrh doporučené varianty. 4. Dnes SSO nevyužíváme a neuvažujeme o něm ani v budoucnu. Autorizace v současné době funguje na základě přihlašovacích údajů. 5. Ano, toto platí 6. V případě nesoučinnosti ze strany PPAS či 3. stran (např. SAP, vyjma subdodavatele zhotovitele) se sankce za nedodržení harmonogramu nevztahují. 7. Ano, potvrzujeme umožnění vzdáleného přístupu. 8. Předpokládáme dodání od dodavatele. 9. Preferovaná varianta je platforma, jejíž správa není závislá na jednom implementačním partnerovi. Pokud dodavatel má vlastní řešení, požadujeme dodání zdrojového kódu a vývojářské dokumentace.

Dotaz č. 7:
V zmysle dokumentu Zadávací dokumentace, bod III.3 je požadované „Nabídka musí být zpracována v českém jazyce, ...“ Je možné ponuku podať i v slovenskom jazyku?
Odpověď:
Nabídku je možné podat ve slovenkém jazyce, přičemž smlouva bude uzavřena v jazyce českém. Komunikace může probíhat i ve slovenském jazyce. Výstupy v rámci projektu by byly realizovány v jazyce českém.

Dotaz č. 8:
1) Jak jsou uložení uživatelé ve starém systému (migrace stávajících účtů). Jsou uložení v LDAP?
2) jak budeme komunikovat se SAP, bude možná komunikace napřímo z FE, nebo bude nutné komunikovat skrze naší vlastní API vrstvu. Jak se budeme přihlašovat pro volání do SAP (technický uživatel pro všechny call stejny, nebo pro každého usera bude call pod jeho účtem)?
Odpověď:
1. Účty uživatelů jsou uloženi v Liferay. Pokud nepůjde v rámci nového řešení provést migrace (z důvodu zašifrovaných hesel uživatelů), tak jim bude vytvořen nový přístup. 2. Komunikaci s SAP předpokládáme pomocí SAP XI/PI. Volání do SAP je dnes realizováno pod jedním technickým uživatelem.