Specyfikacja Załącznik nr 2 Spis treści 1. Kontekst biznesowy... 2 2. Cel projektu... 2 3. Zakres wymagań... 2 3.1 Wymagania funkcjonalne... 2 3.2 Wymagania pozafunkcjonalne... 4 4. Przedmiot zapytania... 5 5. Zawartość ofert... 5 6. Załączniki i informacje dodatkowe... 5
1. Kontekst biznesowy innogy Stoen Operator zarządza siecią elektroenergetyczną stolicy i realizuje zadania Operatora Systemu Dystrybucyjnego. Głównym obszarem działania spółki jest stały monitoring stanu sieci elektroenergetycznej, wykonywanie niezbędnych prac eksploatacyjnych oraz czuwanie nad bezpieczeństwem energetycznym miasta Warszawa. innogy Stoen Operator, jako spółka dystrybucyjna nie działa na rynku wysoce konkurencyjnym, nie walczy o Klientów z innymi firmami. W tym kontekście strona internetowa ma pełnić głównie funkcję informacyjną, pomagać w spełnianiu obowiązków ustawowych oraz być czytelna. Operator jest mniej aktywny sprzedażowo, a marketing usług ma drugoplanowe znacznie. Strona powinna odróżniać się od strony innogy Polska nie tylko po adresie, ale i po zawartości. Przede wszystkim powinny być eksponowane treści związane z techniką zdjęcia sieci, stacji, prace w terenie, dane dotyczące inwestycji, innowacje. Strona powinna wskazywać przewagi rynkowe firmy, ie jak długości linii kablowych, czy liczba posiadanych stacji. Perspektywa klienta to przede wszystkim możliwość znalezienia aktualnych danych o stanie sieci energetycznej, zasadach wzywania pogotowia energetycznego, obowiązujących regulacjach prawnych, a że planowanych przerwach eksploatacyjnych oraz awariach - te informacje powinny być dostępne dla Klienta od razu, na pierwszy rzut oka. Koncepcja projektu nie zakłada przenoszenia na stronę obsługi procesów realizowanych przy wykorzystaniu serwisów zewnętrznych - ebok, system zmiany sprzedawcy, natomiast należy zwrócić uwag, że jednym z głównych wyzwań stojących przed projektem jest poprawa ergonomii konsumpcji treści umieszczonych na stronie. Obecnie na stronie dostępne są rozmaite formularze pdf, które można pobrać do wydruku, docelowo większość z nich powinny zastąpić interaktywne formularze, które są wysyłane jednym kliknięciem. 2. Cel projektu Głównym celem projektu jest zmiana technologii oraz dostosowanie strony internetowej innogystoenoperator.pl do wytycznych wynikających ze zmiany marki, przy zastosowaniu obowiązujących standardów i praktyk branżowych w zakresie tworzenia stron internetowych. 3. Zakres wymagań Lista wymagań zamieszczona poniżej nie jest pełnym spisem wymagań. Szczegółowy zakres i kształt funkcjonalności powinien powstać w pierwszej fazie projektu, na etapie analizy i budowania koncepcji strony. 3.1 Wymagania funkcjonalne 3.1.1 Interfejs i wszystkie treści na stronie powinny być wykonane w języku polskim i angielskim z możliwością wyboru określonego języka. 3.1.2 Strona powinna wspierać standard RWD.
3.1.3 Strona powinna zostać zbudowana w sposób uwzględniający czytelny podział na segmenty Klientów: 1) gospodarstwa domowe, 2)przedsiębiorcy, 3)wytwórcy energii, przedsiębiorstwa energetyczne sprzedawcy oraz inni OSD. 3.1.4 Na stronie powinien zostać wyraźnie wydzielony i łatwo dostępny obszar regulacyjny IRiESD (taryfa, komunikaty obowiązkowe, komunikacja z innymi uczestnikami rynku energii). 3.1.5 Strona powinna posiadać zaawansowany mechanizm wyszukiwania, pozwalający na przeszukiwanie treści we wszystkich sekcjach / ekranach oraz przeszukiwanie treści załączników. Wyniki wyszukiwania powinny być zawężone (stronicowanie) lub uzupełniane dynamicznie w widoku. 3.1.6 Z poziomu strony powinna istnieć możliwość wywołania podlinkowanych, zewnętrznych aplikacji, przede wszystkim ebok oraz portalu przyłączeniowego. 3.1.7 Klient powinien mieć możliwość przesłania dowolnego zapytania poprzez formularz kontowy osadzony na stronie, zamiast wysyłania korespondencji na oficjalne adresy kontowe. 3.1.8 Na stronie powinna być prezentowana informacja o awariach oraz planowanych wyłączeniach sieci. Dane te powinny być łatwo dostępne, prezentowane w formie tabelarycznej i graficznej. Powinna istnieć możliwość wyszukiwania i zawężania widoku (np. do konkretnego adresu) oraz jeżeli klient pozostawi wymagane dane wysyłania mu informacji sms oraz mailowo. 3.1.9 Na stronie powinna zostać zapewniona możliwość prezentacji dynamicznych wykresów generowanych na bazie dostarczanych danych statystycznych (np. poprzez import z pliku csv). 3.1.10 Powinna istnieć możliwość aktualizowania wybranych informacji poprzez zaczytanie pliku z poziomu GUI lub wywołanie akcji zasilenia poprzez dedykowane API. 3.1.11 Strona musi umożliwiać zbieranie i przechowywanie danych klientów oraz informacji o zgodach marketingowy, które wyraził. Z poziomu administratora powinien zostać stworzony widok umożliwiający zarządzanie danymi o zgodach. 3.1.12 Rozwiązanie musi wspierać definiowanie różnych ról i określanie poziomów uprawnień dla użytkowników. 3.1.13 Powinna istnieć możliwość zarządzania treścią strony w możliwie szerokim zakresie, poprzez panel administratora dostępny z poziomu przeglądarki internetowej. Panel administratora powinien być zabezpieczony hasłem. Strona powinna wspierać logowanie z wykorzystaniem ActiveDirectory dla użytkowników wewnętrznych, o ile nie będzie to ograniczone z powodów związanych z bezpieczeństwem lub architekturą. 3.1.14 Rozwiązanie powinno umożliwiać wprowadzanie i edytowania treści w możliwie prosty sposób np. poprzez panel typu WYSIWYG / HTML. 3.1.15 System powinien zapewnić możliwość tworzenia różnego rodzaju formularzy, bez potrzeby wykonywania skomplikowanych prac deweloperskich. 3.1.16 Rozwiązanie powinno wspierać obsługę RSS i umożliwiać automatyczne dodawanie kanałów dla poszczególnych podstron.
3.1.17 Powinna istnieć możliwość umieszczania na stronie plików (wszystkie popularne rozszerzenia: pdf, ppt, xlsx, docx) oraz osadzania treści video (bezpośrednio lub w formie odnośników) wraz z możliwością wprowadzania etykiet, tagów. 3.1.18 Rozwiązanie powinno umożliwiać tworzenie stron na podstawie gotowych, predefiniowanych modułów (listy plików, galeria, newsy, itp.). 3.1.19 Strona musi umożliwiać raportowanie aktywności użytkowników, a że analizę trendów - najczęściej odwiedzane obszary strony, najczęściej poszukiwane informacje itp. 3.1.20 Rozwiązanie powinno zapewniać wersjonowanie elementów strony, umożliwiać cofnięcie wprowadzonych zmian lub powrót do wybranej wersji edytowanego elementu. 3.2 Wymagania pozafunkcjonalne 3.2.1 Strona powinna zostać dostosowana i zoptymalizowana do poprawnego wyświetlania treści we wszystkich popularnych przeglądarkach internetowych Przeglądarka 1 2 Google Chrome Mozilla Firefox Microsoft Internet Explorer Edge IE 11.x IE 10.x IE 9.x Apple Safari Opera 1, oznacza, że strona będzie wyświetlała się w danej przeglądarce zgodnie z zatwierdzonym przez Klienta projektem graficznym. 2, oznacza, że mogą wystąpić różnice między wyświetlaniem się strony w danej przeglądarce, a zatwierdzonym przez Klienta projektem graficznym. Różnice te nie wpłyną na działanie strony, a jej funkcjonalności będą dostępne dla użytkownika. Przykładowe różnice: różne odstępy między elementami, mniej płynna animacja elementów na stronie, brak cieni czy zaokrąglonych rogów. 3.2.2 Strona powinna być zgodna z wytycznymi brandbook innogy Stoen Operator. 3.2.3 Strona powinna być wykonana w technologii HTML5 3.2.4 Bazowy CMS powinien być popularny i ogólnie dostępny tzn. powinien być używany w > 10 wdrożeniach realizowanych przez > 5 różnych firm. 3.2.5 Rozwiązanie powinno umożliwiać wczytywanie się strony w czasie poniżej 1,5 s. oraz umożliwiać wywołanie 150 równoległych stron.
4. Przedmiot zapytania Przedmiotem zapytania obejmuje: 4.1.1 Przygotowanie wizualizacji strony internetowej z uwzględnieniem założeń brandbook a innogy. Oferent powinien uwzględnić przygotowanie minimum trzech propozycji wizualizacji (opracowanie wizualizacji wyceniane jest jako opcja). 4.1.2 Zaprojektowanie i wykonanie interfejsu strony internetowej. Serwis powinien zostać zaprojektowany zgodnie z aktualnymi trendami i wyróżniać się na tle innych, podobnych serwisów spółek dystrybucyjnych. 4.1.3 Zaprojektowanie i wykonanie interfejsów do innych systemów w zakresie zapewniającym spełnienie wymagań funkcjonalnych. 4.1.4 Instalacja i konfiguracja rozwiązania na platformie sprzętowej. 4.1.5 Migracja zawartości obecnej strony na nową platformę. 4.1.6 Przeprowadzenie przez Oferenta testów rozwiązania (funkcjonalne, integracyjne, wydajnościowe) oraz zapewnienie wsparcia na etapie testów penetracyjnych i UAT. 4.1.7 Przeprowadzenie szkoleń dla administratorów i kluczowych użytkowników biznesowych w siedzibie Zamawiającego oraz przekazanie kodu rozwiązania. 4.1.8 Przygotowanie instrukcji i dokumentacji powykonawczej. 4.1.9 Wsparcie w okresie stabilizacji rozwiązania. 4.1.10 Zapewnienie wsparcia serwisowego w okresie 12 miesięcy po zakończeniu okresu stabilizacji (wsparcie serwisowe wyceniane jest jako opcja). 5. Zawartość ofert 5.1.1 Krótka prezentacja firmy. 5.1.2 Informację o technologiach i językach programowania wykorzystanych do budowy rozwiązania. 5.1.3 Informację o zasadach udostępniania oprogramowania niebędącego własnością Oferenta, które jest niezbędne do stworzenia rozwiązania. 5.1.4 Architektura i wymagane środowisko sprzętowe. 5.1.5 Proponowany harmonogram realizacji projektu. 5.1.6 Wymagania względem Zamawiającego, bez których realizacja projektu nie będzie możliwa. 5.1.7 Cena w rozbiciu na koszty licencji, fazę analizy z uwzględnieniem tworzenia grafiki lub bez niej, realizację, testy, szkolenia, utrzymanie. 6. Załączniki i informacje dodatkowe 6.1.1 Zamawiający zobowiązuję się zapewnić wymaganą infrastrukturę według specyfikacji dostarczonej przez Oferenta. Rozwiązanie przygotowane zostanie do poziomu os-ready, włącznie z silnikiem bazy danych. 6.1.2 W końcowej fazie realizacji projektu Zamawiający zakłada przeprowadzenie niezależnej oceny jakości rozwiązania obejmującej testy typu black-box, white-
box symulujące typowe ai, którym może podlegać rozwiązanie. Zamawiający oczekuje, że wszelkie zidentyfikowane w tym zakresie luki w oprogramowaniu dostarczanym przez Oferenta zostaną usunięte na etapie realizacji, w zakresie prac objętych ofertą. Warunkiem odbioru rozwiązania będzie pozytywny wynik audytu. 6.1.3 Po uruchomieniu produkcyjnym przewiduje się dwumiesięczny okres stabilizacji dla potwierdzenia prawidłowego działania rozwiązania. Okres ten może ulec wydłużeniu na wniosek Zamawiającego w przypadku występowania istotnych problemów w działaniu systemu. Odbiór rozwiązania nastąpi po zakończeniu okresu stabilizacji. 6.1.4 Z uwagi na specyfikę projektu, Zamawiający preferuje realizację prac z zastosowaniem elementów metodyk zwinnych.