Szczegółowy Opis Przedmiotu Zamówienia

Załącznik nr 1 do SIWZ Załącznik nr 1 do umowy

Szczegółowy Opis Przedmiotu Zamówienia

I. Słownik użytych pojęć

1. ACD – Automatic Call Distribution (ACD) - mechanizm automatycznego rozdzielania wywołań.

2. Administrator Bazy wiedzy – Użytkownik Systemu CC mający możliwość przeszukiwania po wszystkich dostępnych parametrach (co najmniej status, kategoria, słowa kluczowe, dowolne słowo lub fragment tekstu, znaczniki czasu) i przeglądania artykułów. Dodatkowo mający możliwość konfigurowania, wprowadzania, publikowania (w tym również z możliwością co najmniej określenia przyszłej daty publikacji i terminu ważności artykułu), modyfikowania i wersjonowania oraz archiwizacji i usuwania wszystkich artykułów.

3. Administrator biznesowy – Użytkownik Systemu CC zarządzający i nadzorujący co najmniej kontami i uprawnieniami Użytkowników Systemu CC oraz pracą Systemu CC (posiadający dostęp do narzędzi pozwalających na tworzenie, modyfikację i usuwanie parametrów Systemu CC w zakresie CRM, IVR, Nagrywania rozmów, Logistyki, Planowania pracy, Raportów, Bazy wiedzy, Testów).

4. Administrator IT – użytkownik Systemu CC odpowiedzialny za utrzymanie, rozwój i backup Systemu CC oraz posiadający uprawnienia do tworzenia, modyfikacji i usuwania dowolnego parametru Systemu CC, w tym technicznego.

5. Administrator Testów – Użytkownik Systemu CC mogący konfigurować, wprowadzać, publikować, modyfikować i wersjonować, archiwizować i usuwać parametry i treść testów, przeszukiwać i przeglądać testy, dystrybuować testy do Użytkowników Testów, przeszukiwać, przeglądać i raportować wyniki Użytkowników Testów (z możliwością ich eksportu do plików).

6. Aplikacja dla Mieszkańca – responsywna strona internetowa do zgłaszania alertów z przestrzeni publicznej – dostępna również na urządzeniach mobilnych.

7. Baza wiedzy – grupa funkcjonalności Systemu CC pozwalająca na konfigurowanie, wprowadzanie, publikowanie modyfikowanie, wersjonowanie, archiwizację i usuwanie, przeszukiwanie i przeglądanie artykułów zawierających informacje o usługach Urzędu Miasta Lublin oraz inne informacje konieczne do obsługi klientów.

8. CRM – Customer Relationship Management (CRM) - system informatyczny, który automatyzuje i wspomaga procesy na styku klient-organizacja w zakresie obsługi klienta.

9. EZD – usługowy system dziedzinowy, służący do elektronicznego zarządzania dokumentacją.

10. Geoportal Miejski SIPL – portal internetowy, zapewniający dostęp do usług danych przestrzennych, będący jedną z aplikacji systemu SIPL.

11. IVR – Interactive Voice Response – system interaktywnej obsługi osoby dzwoniącej.

12. Karta Kontaktu – zestaw informacji o kliencie pozwalających na jego identyfikację (w tym imię, nazwisko, XXXXX, numer telefonu, adres e -mail) oraz zawierający informacje o wcześniejszych Zgłoszeniach i Zadaniach dotyczących klienta.

13. Konektor – jest to dedykowany komponent, służący do komunikacji i wymiany danych pomiędzy określonym systemem a Szyną ESB, ukrywający niekompatybilność interfejsów, protokołów i formatów danych, występujących pomiędzy integrowanymi za pomocą Szyny ESB systemami.

14. Konsultant – Użytkownik Systemu CC przyjmujący i obsługujący Zgłoszenia i Zadania oraz posiadający dostęp co najmniej do grupy funkcjonalności Systemu CC, CRM, Baza wiedzy, Testy, Logistyka.

15. Logistyka – grupa funkcjonalności Systemu CC umożliwiająca zarządzanie informacją, co najmniej o dokumentach gotowych do odbioru.

16. Planowanie pracy – grupa funkcjonalności Systemu CC umożliwiająca planowanie i zarządzanie grafikami pracy Konsultantów i Supervisorów.

17. Redaktor Bazy wiedzy – Użytkownik Systemu CC mający możliwość przeszukiwania po wszystkich dostępnych parametrach (co najmniej tytuł, status, kategoria, słowa kluczowe, dowolne słowo lub fragment tekstu, znaczniki czasu) i przeglądania artykułów. Dodatkowo mający możliwość konfigurowania, wprowadzania (ale bez uprawnień do ich publikacji), modyfikowania własnych artykułów, jak również mający możliwość usuwania własnych nieopublikowanych artykułów.

18. Redaktor Testów – Użytkownik Systemu CC mogący przeszukiwać i wykonywać testy oraz przeglądać własne wyniki. Dodatkowo mogący konfigurować, wprowadzać, modyfikować i wersjonować parametry i treść testów, ale bez uprawnień do ich publikacji, jak również mogący usuwać własne nieopublikowane testy.

19. RODO – rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1 oraz L 127 z 23.05.2018, str. 2).

20. Serwis WWW – Serwis WWW obsługiwany pod adresem xxxxx://xxxxxx.xx.

21. SFK - usługowy system dziedzinowy, służący do zarządzania finansami i księgowością.

22. SIPL – System Informacji Przestrzennej miasta Lublina - system wzajemnie współpracującego i zintegrowanego oprogramowania dedykowanego, standardowego i narzędziowego, przeznaczony do obsługi wszystkich dziedzin związanych z danymi przestrzennymi, wdrożony w wyniku realizacji projektu „Opracowanie i wdrożenie systemu informacji przestrzennej dla miasta Lublin”.

23. Supervisor – Użytkownik Systemu CC zarządzający i nadzorujący (bieżącą) pracą Konsultantów oraz realizacją Zgłoszeń i Zadań (posiadający możliwość przyjmowania i obsługiwania Zgłoszeń i Zadań), posiadający dostęp co najmniej do CRM, Nagrywania rozmów, Logistyki, Planowania pracy, Raportów, Bazy wiedzy, Testów.

24. System – wszelkie dostarczone i wdrożone przez Wykonawcę komponenty, w zakresie określonym w Umowie, złożone w szczególności z Systemu CC, konektorów do Szyny ESB, Systemu telekomunikacyjnego, Aplikacji i e-usług.

25. System CC - System Contact Center (ang. dosłownie – centrum kontaktowe) – całość elementów programowych, w tym również CRM, służących do obsługi masowych kontaktów z klientami obsługujących kontakty różnymi kanałami, w tym poprzez połączenie telefoniczne, fax, SMS, pocztę elektroniczną, chat, newsletter, alert, formularz zgłoszeniowy.

26. System Telekomunikacyjny – całość środowiska telekomunikacyjnego, na którym zostanie osadzony System CC.

27. Szyna ESB – Szyna integracyjna ESB (ang. Enterprise Service Bus - korporacyjna magistrala usług) Zamawiającego – oprogramowanie narzędziowe służące do integracji elementów Systemu oraz integracji Systemu z aplikacjami zewnętrznymi niebędącymi przedmiotem

zamówienia, oparte wyłącznie o komponenty opensource (na otwartej licencji z nieograniczonym dostępem do kodów źródłowych).

28. Testy – grupa funkcjonalności Systemu CC umożliwiająca weryfikację wiedzy pracowników poprzez wykonywanie testów.

29. Urządzenia końcowe – urządzenia klasy PC lub urządzenia mobilne, z których korzystają pracownicy Urzędu Miasta Lublin lub klienci wyposażone w przeglądarkę internetową.

30. Użytkownik Aplikacji dla Mieszkańca – klient Urzędu Miasta Lublin korzystający z tej aplikacji na Urządzeniu końcowym.

31. Użytkownik Bazy wiedzy – użytkownik Systemu CC mający możliwość przeszukiwania po wszystkich dostępnych parametrach (co najmniej status, kategoria, słowa kluczowe, dowolne słowo lub fragment tekstu, znaczniki czasu) i przeglądania artykułów.

32. Użytkownik CRM – użytkownik Systemu CC obsługujący Zadania posiadający dostęp do CRM.

33. Użytkownik Systemu CC – użytkownik (pracownik Urzędu Miasta Lublin) obsługujący System CC z określonymi w systemie uprawnieniami.

34. Użytkownik Testów – użytkownik Systemu CC mogący wykonywać testy oraz przeglądać własne wyniki.

35. Zadanie – sprawa zainicjowana na podstawie Zgłoszenia, wymagająca dłuższego procesu obsługi przez Konsultanta lub przez pracownika spoza Systemu CC, obsługiwana poprzez grupę funkcjonalności CRM.

36. Zgłoszenie – forma kontaktu klienta Urzędu Miasta Lublin za pośrednictwem dostępnych kanałów kontaktu: połączenie telefoniczne, fax, SMS, poczta elektroniczna, chat, newsletter, alert, formularz zgłoszeniowy.

II. Przedmiot zamówienia

1. Przedmiotem zamówienia jest „Budowa Contact Center” rozumiana jako dostawa i wdrożenie rozwiązania w środowisku telekomunikacyjnym oraz serwerowym Zamawiającego, składającego się z systemu kontaktu z klientami oraz systemu zarządzania relacjami z klientami dalej zwanych wspólnie Systemem Contact Center, w ramach projektu „Budowa i rozbudowa e-usług w Gminie Lublin” współfinansowanego przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa Lubelskiego na lata 2014-2020.

2. Przedmiot zamówienia obejmuje w szczególności:

2.1. przeprowadzenie analizy przedwdrożeniowej,

2.2. zapewnienie prawidłowego funkcjonowania środowiska telekomunikacyjnego Zamawiającego,

2.3. utworzenie konektorów do Szyny ESB Zamawiającego,

2.4. dostawę i wdrożenie Systemu Contact Center,

2.5. świadczenie nadzoru technicznego.

3. W ramach dostawy i wdrożenia Systemu Contact Center, Wykonawca będzie musiał wdrożyć dwie e-usługi:

3.1. System Contact Center na poziomie dojrzałości 5,

3.2. Aplikacja dla Mieszkańca na poziomie dojrzałości 4.

4. Dostarczenie i wdrożenie Systemu CC, w tym instalacja i uruchomienie Systemu CC w środowisku serwerowym i telekomunikacyjnym Zamawiającego obejmują, co najmniej:

4.1. Wdrożenie i uruchomienie nowych funkcjonalności środowiska telekomunikacyjnego przez Wykonawcę, na udostępnionym przez Zamawiającego środowisku telekomunikacyjnym, opisanego w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego.

4.2. Istniejące środowisko telekomunikacyjne i co za tym idzie realizowane za jego pośrednictwem usługi, rozszerzone o nowe funkcjonalności środowiska telekomunikacyjnego stworzą system telekomunikacyjny Zamawiającego (System Telekomunikacyjny).

4.3. Wykonawca zapewni kompatybilność wdrażanego Systemu CC ze środowiskiem telekomunikacyjnym wraz z zapewnieniem wsparcia technicznego w zakresie tego środowiska.

4.4. Uruchomienie środowiska testowego Systemu CC o funkcjonalnościach tożsamych z środowiskiem produkcyjnym. Wszelkie zmiany w systemie muszą być w pierwszej kolejności uruchamiane na środowisku testowym Systemu CC w celu weryfikacji poprawności.

4.5. Serwisy udostępnianie w sieci Internet muszą spełniać wymagania WCAG 2.1.

4.6. Przygotowanie integracji wdrażanego systemu z wymaganymi systemami zewnętrznymi i wewnętrznymi Urzędu Miasta Lublin, które zostały przedstawione na Schemacie 1 w rozdziale II. Przedmiot zamówienia i opisane w rozdziale V.3, VI i VIII.

4.7. Dostarczenie wymaganych aktualnych licencji wraz z zapewnionym wsparciem producenta w okresie gwarancji dla wdrażanych produktów.

4.8. Implementacja drzew aplikacji IVR zgodnie ze scenariuszami uzgodnionymi z Zamawiającym.

4.9. Implementacja scenariuszy dystrybucji Zgłoszeń i Zadań dla wszystkich kanałów kontaktu. Muszą one zapewniać elastyczną obsługę wielu grup Użytkowników, Systemu CC, kierowanie do nich Zgłoszeń i Zadań w zależności od ustalonych parametrów.

4.10. Osadzenie wszystkich dostarczanych funkcjonalności WWW dla klientów w posiadanym przez Zamawiającego Systemie zarządzania treścią CMS Edito.

4.11. Przygotowanie mechanizmów monitorowania pracy Systemu CC.

4.12. Przygotowanie procedur i instrukcji, co najmniej:

4.12.1. instalacji systemu,

4.12.2. zatrzymania systemu,

4.12.3. uruchomienia systemu,

4.12.4. wykonywania kopii zapasowych systemu,

4.12.5. odzyskiwania i przywracania systemu.

4.13. Przygotowanie instrukcji stanowiskowej w języku polskim dla:

4.13.1. Konsultanta I i II linii,

4.13.2. Supervisora,

4.13.3. Użytkownika testów,

4.13.4. Redaktora testów,

4.13.5. Administratora testów,

4.13.6. Użytkownika Bazy wiedzy,

4.13.7. Redaktora Bazy wiedzy,

4.13.8. Administratora Bazy wiedzy,

4.13.9. Użytkownika CRM,

4.13.10. Administratora Biznesowego.

4.14. Przygotowanie instrukcji stanowiskowej w języku polskim lub angielskim dla Administratora IT.

4.15. Przeprowadzenie testów systemowych, integracyjnych i niezawodnościowych.

4.16. Przygotowanie dokumentacji powdrożeniowej opisującej wdrażany system i interfejsy z systemami Urzędu Miasta Lublin lub Zamawiającego.

4.17. Przeprowadzenie instruktaży stanowiskowych dla wszystkich rodzajów Użytkowników Systemu CC.

Schemat 1. Schemat logiczny Systemu

str. 7

III. Zgodność z aktami prawnymi

1. Przedmiot zamówienia musi być zgodny z prawem powszechnie obowiązującym, w szczególności z następującymi aktami prawnymi:

1.1. Ustawa z dnia 4 marca 2010 r. o infrastrukturze informacji przestrzennej (Dz. U. z 2020 r. poz. 177 z późn. zm.),

1.2. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 20 października 2010 r. w sprawie ewidencji zbiorów i usług danych przestrzennych objętych infrastrukturą informacji przestrzennej (Dz. U. z 2010 r. Nr 201, poz. 1333 z późn. zm.),

1.3. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2019 r. poz. 700 z późn. zm.),

1.4. Ustawa z dnia 16 lipca 2004 r. Prawo telekomunikacyjne (Dz. U. z 2020 r. poz. 346 z późn. zm.)

1.5. Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz. U. z 2019r. poz. 848),

1.6. Ustawa z dnia 19 lipca 2019 r. o zapewnianiu dostępności osobom ze szczególnymi potrzebami (Dz. U. z 2020 r. poz. 1062),

1.7. Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz. U. 2020 r. poz. 1173),

1.8. Ustawa z dnia 14 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2019 r. poz. 1231 z późn. zm.)

1.9. Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE.

1.10. Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania i doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz. U. z 2018 r. poz. 180)

1.11. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. 2006, Nr 206, poz. 1517);

1.12. Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U. 2005, Nr 217, poz. 1836);

1.13. Ustawa z 27 lipca 2001 roku o ochronie baz danych (Dz. U. z 2019 r. poz. 2134 z późn. zm.),

1.14. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2017 r. poz. 2247);

1.15. Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz. U. z 2019 r. poz. 1781),

1.16. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych) (Dz. Urz. UE L 119 z 04.05.2016, str. 1 oraz L 127 z 23.05.2018, str. 2),

1.17. Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. z 2011r. nr 14 poz. 67 z późn. zm.).

1.18. Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848 z późn. zm.)

2. Przedmiot Zamówienia musi być zgodny również z Polityką Bezpieczeństwa Informacji Urzędu Miasta Lublin, stanowiącą załącznik nr 1 do zarządzenia nr 1/3/2017 Prezydenta Miasta Lublin z dnia 1 marca 2017 r. w sprawie Polityki Bezpieczeństwa Informacji Urzędu Miasta Lublin.

IV. Wymagane funkcjonalności środowiska telekomunikacyjnego

Schemat 2. Architektura obecna i docelowa Systemu Telekomunikacyjnego

Część A - Funkcjonalności Systemu Telekomunikacyjnego – wymagania ogólne dotyczące zrealizowania funkcjonalności

1. Wykonawca zagwarantuje pełną kompatybilność podsystemu telekomunikacyjnego TDM/VOIP i podsystemu telekomunikacyjnego VOIP Softswitch SIP z urządzeniami, aplikacjami i systemami z nimi współpracującymi tj. z podsystemem Fakserwer, Centralnym podsystemem taryfikacji oraz Centralnym podsystemem zarzadzania aparatami

2. Wykonawca w podsystemie telekomunikacyjnym TDM/VOIP umożliwi utworzenie licencji pozwalających na wygenerowanie, co najmniej 1279 linii abonenckich cyfrowych IP, SIP z możliwością dowolnego wygenerowania także na tych licencjach linii abonenckich analogowych i cyfrowych TDM (systemowych), wykorzystujących posiadane przez Zamawiającego terminale opisane w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego.

3. Wykonawca w podsystemie telekomunikacyjnym VOIP Softswitch umożliwi utworzenie licencji pozwalających na wygenerowanie, co najmniej 1105 cyfrowych linii abonenckich SIP

4. Wykonawca zagwarantuje pełną kompatybilność podsystemu telekomunikacyjnego TDM/VOIP i podsystemu telekomunikacyjnego VOIP Softswitch SIP z urządzeniami,

aplikacjami i systemami z nimi współpracującymi, w tym z podsystemem Faks-serwer, Centralnym podsystemem taryfikacji, Centralnym podsystemem zarzadzania aparatami oraz posiadanym środowiskiem telekomunikacyjnym Zamawiającego opisanego w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego.

5. Wykonawca zapewni transmisję faksów dla wszystkich abonentów podsystemu telekomunikacyjnego VOIP Softswitch, z wykorzystaniem protokołu T.38 bez konieczności angażowania żadnych jakichkolwiek dodatkowych licencji.

6. Wykonawca zapewni współpracę podsystemów środowiska telekomunikacyjnego z posiada- nymi przez Zamawiającego aparatami systemowymi (WL3) TDM, IP (HFA, SIP) opisanymi w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego, dotyczącym opisu środowiska telekomunikacyjnego Zamawiającego, w zakresie wykorzystania pełnych możliwości wyświetlacza każdego modelu aparatu oraz usług i funkcjonalności przez nie reali- zowanych. Aktualnie eksploatowane telefony systemowe IP (HFA) i TDM muszą posiadać możliwość ich pełnego wykorzystania odpowiednio w każdym z podsystemów telekomunika- cyjnych. Ponadto Wykonawca zapewni najbardziej aktualne oprogramowanie dla aparatów sys- temowych IP (opisanych w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Za- mawiającego) posiadanych przez Zamawiającego.

W przypadku braku możliwości zapewnienia współpracy środowiska telekomunikacyjnego z w/w posiadanymi przez Zamawiającego aparatami systemowymi, Wykonawca dostarczy odpowiedniki kompatybilne o funkcjonalności nie gorszej od wyżej opisanej.

7. Wykonawca zapewni współpracę z posiadanymi przez Zamawiającego bramkami VOIP (opisanymi w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego) w zakresie usług przez nie dotychczas realizowanych, w tym obsługę protokołu T.38, prezentację numeru oraz prezentacje nazwy użytkownika (w ruchu wewnętrznym) abonenta wywołującego, na wyświetlaczu abonenta wywoływanego, przekierowanie połączeń za pośrednictwem funkcji „flash” z aparatu telefonicznego (usługa CT - call transfer), obsługę kodeków G729 i G711.

8. System Telekomunikacyjny musi zapewnić pełne przeniesienie prezentacji numerów dla abonentów wywoływanych, wywołujących, do i z sieci publicznej,

9. System Telekomunikacyjny musi zapewnić realizację połączeń telefonicznych abonentów VoIP SIP z wykorzystaniem kodeków, co najmniej G.729 i G.711.

10. System Telekomunikacyjny musi zapewnić pełną integrację z systemem numeracji wewnętrznej i publicznej Urzędu w zakresie 81466 1000 – 81466 6999,

11. Rozbudowa pojemności Systemu Telekomunikacyjnego musi być możliwa wyłącznie poprzez aktywowanie dodatkowych licencji.

12. W zakresie administracji oraz zintegrowania prawidłowego funkcjonowania wszystkich podsystemów w Systemie Telekomunikacyjnym Wykonawca zapewni:

12.1. centralną administrację z możliwym dostępem poprzez strony WWW oraz lokalną administrację przez użytkownika w ramach nadanych mu uprawnień

12.2. mechanizmy dotyczące możliwość wykonywania cyklicznych kopii bezpieczeństwa w zakresie parametrów konfiguracyjnych (eksport ustawień konfiguracyjnych),

12.3. mechanizmy rejestrowania wszelkich zdarzeń związanych konfiguracją ww. systemów

12.4. mechanizmy stałego monitorowania parametrów technicznych, z wykorzystaniem sys- temu SPLUNK, będącego w posiadaniu Zamawiającego, a w szczególności: (dopuszcza się automatyczne powiadamianie przez e-mail, odpytywanie o ich stan, przez SNMP lub automatyczne generowanie logów systemowych)

12.4.1. jednoczesnej ilości połączeń SIP,

12.4.2. wykorzystania pamięci RAM,

12.4.3. utylizacji procesorów.

12.5. możliwość implementacji punktu styku do zarządzania webservices celem integracji z innymi systemami IT.

12.6. mechanizmy prawidłowego przesyłania, naliczania i zabezpieczenia rekordów taryfika- cyjnych przed utratą.

13. System Telekomunikacyjny musi posiadać mechanizm automatycznego rozdzielania wywołań ACD (Automatic Call Distribution), czyli możliwość kolejkowania połączeń telefonicznych w ruchu przychodzącym do systemów typu CTI, Contact Center, Call Center, IVR.

14. Podsystemy telekomunikacyjne TDM/VOIP i VOIP muszą umożliwiać wymianę faksów pomiędzy sobą, za pomocą protokołu T.38 za pośrednictwem protokołu SIP-Q tunelowanego protokołem SIP. Sprawność „łącza SIP” z tunelowanym protokołem SIP-Q (dla transmisji połączeń faksowych) pomiędzy obydwoma wyżej wymienionymi podsystemami musi być na poziomie nie gorszym niż 99,7%.

15. Podsystemy telekomunikacyjne TDM/VOIP i VOIP muszą umożliwiać (za pośrednictwem protokołu SIP-Q) przenoszenie pomiędzy sobą następujących usług:

15.1. CLIP / CLIR,

15.2. COLP / COLR,

15.3. CNIP/CNIR,

15.4. CNOP/CNOR,

15.5. DTMF,

15.6. Name display,

15.7. Hold / Retrieve / Toggle,

15.8. Call transfer,

15.9. Call forwarding (CFU/CFB/CFNR),

15.10. Call deflection,

15.11. Second call,

15.12. Callback on busy subscriber / Callback No Reply,

15.13. Do Not Disturb,

15.14. Digest Authentication,

15.15. End-To-End Payload,

15.16. Message Waiting Indication,

15.17. Route Optimization,

15.18. Survivability Media Gateway,

15.19. Signaling and Payload Encryption (TLS / SRTP),

15.20. T38 fax (OSCAR profil).

16. W ruchu wewnętrznym pomiędzy poszczególnymi podsystemami telekomunikacyjnymi numery wewnętrzne muszą się prezentować wyłącznie w postaci czterocyfrowej.

17. Prezentacja nazwy (usługa: „display name”) i numeru (usługa: clip) abonenta wirtualnego podsystemu telekomunikacyjnego TDM/VOIP, musi być widoczna w podsystemie telekomunikacyjnym VOIP SOFTSWITCH w przypadku realizowania polaczenia telefonicznego za pośrednictwem usługi CF (Call Forwarding) każdego rodzaju. Zamawiający dopuszcza możliwość alternatywnego „programowego samodzielnego przełączania” prezentacji nazwy i numeru abonenta wirtualnego (w trakcie realizowania usługi CF) z prezentacji wymaganej (opisanej wyżej) na prezentację „przezroczystą” tj. prezentującą ewentualnie nazwę i koniecznie numer abonenta wywołującego tj. dzwoniącego do abonenta wirtualnego.

18. Wykonawca zapewniając Zamawiającemu dostosowanie Systemu Telekomunikacyjnego, wykonuje czynności w siedzibie Zamawiającego, zgodnie z poniższymi warunkami:

18.1. Zadania muszą być realizowane w godzinach 8:00 – 16:00 w dni robocze. Nie dotyczy to prac, które wymagają zatrzymania systemów. Prace te muszą być wykonywane po godzinie 17:00 w dni robocze. Zamawiający nie dopuszcza przerw w działaniu produkcyjnym systemów w czasie godzin pracy Urzędu.

18.2. Realizacja zadań musi być prowadzona w siedzibie Zamawiającego. W szczególnych przypadkach, gdy Wykonawca posiada dostęp zdalny do sieci VPN, prace mogą być wykonywane zdalnie, jednak każdorazowo Zamawiający musi być o tym poinformowany przez Wykonawcę i wyrazić na to zgodę.

19. System Telekomunikacyjny musi zostać wdrożony według wskazań Zamawiającego, w zakresie obejmującym w szczególności:

19.1. zapewnienia poprawności wymiany informacji sygnalizacyjnych pomiędzy systemami podsystemami telekomunikacyjnymi,

19.2. zapewnienia jednolitości dostępu do usług opisanych w wymaganiach funkcjonalnych dla wszystkich podsystemów telekomunikacyjnych,

19.3. zapewnienia przenośności usług pomiędzy podsystemami telekomunikacyjnymi,

19.4. zapewnienia pełnej funkcjonalności faksów z wykorzystaniem protokołu T.38 w sieci telekomunikacyjnej Zamawiającego.

20. Wykonawca przekaże dokumentację odbiorową (techniczną) Zamawiającemu na minimum 5 dni roboczych przed zgłoszeniem gotowości do odbioru prac. Odbiór prac będzie przeprowadzony przez komisję techniczną utworzoną przez wytypowanych przedstawicieli Stron.

21. W ramach odbioru Wykonawca zapewni asystę techniczną dla Systemów podczas pierwszego dnia produkcyjnego po wykonaniu upgrade rozumianą przez fizyczną obecność serwisu w siedzibie Zamawiającego.

22. Zamawiający sprawdzi w szczególności:

22.1. zgodność konfiguracji sprzętowej urządzeń z zamówieniem,

22.2. pozytywny wynik testów komunikacji i jakości połączeń,

22.3. przekazanie kompletu instrukcji obsługi całego systemu,

22.4. dokumenty potwierdzające przeprowadzenie instruktaży stanowiskowych dla pracowników Wydziału Informatyki i Telekomunikacji.

23. Zamawiający zobowiązuje się do wykonania następujących kopii konfiguracji, umożliwiających przewrócenie najbardziej aktualnej wersji środowiska telekomunikacyjnego:

23.1. kopii konfiguracji aktualnego środowiska systemu VOIP Softswitch,

23.2. kopii RMX aktualnego środowiska systemu telekomunikacyjnego TDM/VOIP,

23.3. kopii konfiguracji aktualnego środowiska systemu telekomunikacyjnego TDM/VOIP,

23.4. kopii konfiguracji systemu taryfikacyjnego,

23.5. kopii serwera Faksów.

Część B - Funkcjonalności Systemu Telekomunikacyjnego – wymagania szczegółowe

1. Funkcjonalności Systemu Telekomunikacyjnego – Podsystem TDM/VOIP

1.1. System Telekomunikacyjny – wymagania ogólne:

1.1.1. W zakresie połączenia systemu z publiczną siecią ISDN centrala musi spełniać następujące normy dotyczące sygnalizacji Euro ISDN DSS1 oraz parametrów styku BRI i PRI:

1.1.1.1. PN-ETSI EN 300 011-1 V1.2.2:2005

1.1.1.2. PN-ETSI EN 300 012-1 V1.2.2:2005

1.1.1.3. PN-ETS 300 125:1997

1.1.1.4. PN-ETS 300 102-1:1997

1.1.1.5. PN-ETS 300 102-2:2005

1.1.1.6. PN-ETS 300 402-1:2005

1.1.1.7. PN-ETS 300 402-2:2005

1.1.1.8. PN-ETSI EN 300 403-1 V1.3.2:2005

1.1.1.9. PN-ETSI EN 300 058-4 V1.3.1:2005

1.1.1.10. PN-ETSI EN 300 058-6 V1.4.1:2005

1.1.1.11. PN-ETSI EN 300 064-6 V1.4.3:2005

1.1.1.12. PN-ETSI EN 300 092-1 V2.1.1:2005

1.1.1.13. PN-ETSI EN 300 093-4 V1.3.1:2005

1.1.1.14. PN-ETSI EN 300 093-6 V1.4.1:2005

1.1.1.15. PN-ETSI EN 300 097-6 V1.3.4:2005

1.1.1.16. PN-ETSI EN 300 098-6 V1.3.4:2005

1.1.1.17. PN-ETSI EN 300 130-4 V1.3.2:2005

1.1.1.18. PN-ETSI EN 300 130-6 V1.3.4:2005

1.1.1.19. PN-ETSI EN 300 052-4 V1.3.1:2005

1.1.1.20. PN-ETSI EN 300 052-6 V1.3.3:2005

1.1.1.21. PN-ETSI EN 300 141-4 V1.3.3:2005

1.1.1.22. PN-ETSI EN 300 141-6 V1.3.4:2005

1.1.1.23. PN-ETSI EN 300 182-1 V1.3.6:2005

1.1.1.24. PN-ETSI EN 300 182-2 V1.3.4:2005

1.1.1.25. PN-ETSI EN 300 182-3 V1.4.1:2005

1.1.1.26. PN-ETSI EN 300 182-4 V1.4.1:2005

1.1.1.27. PN-ETSI EN 300 182-5 V1.4.1:2005

1.1.1.28. PN-ETSI EN 300 182-6 V1.4.1:2005

1.1.1.29. PN-ETSI EN 300 286-4 V1.3.3:2005

1.1.1.30. PN-ETSI EN 300 286-5 V1.4.1:2005

1.1.1.31. PN-ETSI EN 300 286-6 V1.4.1:2005

1.1.2. System telekomunikacyjny musi gwarantować możliwość wprowadzania zmian wynikających z rozwoju technologicznego oraz zapewnia możliwość rozbudowy, zwiększania pojemności i funkcjonalności w zależności od potrzeb Zamawiającego zarówno w części dotyczącej oprogramowania jak i sprzętu maksymalnie do 12000 portów.

1.1.3. Dla portów na kartach łączy miejskich wieloportowych musi być zapewniona możliwość stosowania dowolnej kombinacji cyfrowych protokołów komunikacyjnych indywidualnie dla każdego portu, zmiana protokołu odbywa się tylko w sposób programowy bez konieczności wykonywania restartu całego modułu.

1.1.4. Interfejsy XXXX 00XxX oraz 2B+D muszą być wyprowadzone z modułów liniowych centrali bez konieczności stosowania dodatkowych urządzeń/przystawek.

1.1.5. Konstrukcja modułowa, tj. zbudowana w oparciu o tzw. półki montowane do uniwersalnych stojaków 19-cali wyposażone w gniazda rozszerzeń, do których instalowane będą karty systemu, w tym trakty linii miejskich, abonenckich, systemu poczty głosowej.

1.1.6. Swobodne wynoszenie półek lub specjalizowanych modułów (bez konieczności wyposażania ich w jednostkę sterującą) za pośrednictwem opcjonalnego medium miedzianego lub światłowodowego, tj. system musi umożliwiać przygotowanie struktury zdecentralizowanej.

1.1.7. W lokalizacji głównej wszystkie gniazda rozszerzeń muszą posiadać dowolne przeznaczenie, tzn. umożliwiają instalację dowolnego wyposażenia systemu (dopuszczalne jest wydzielone dedykowane miejsce na karty sterujące systemem).

1.1.8. System telekomunikacyjny musi posiadać oprogramowanie sterujące działające w oparciu o otwarty system czasu rzeczywistego.

1.1.9. System telekomunikacyjny musi cechować się brakiem konieczności zakupu licencji dla portów liniowych: miejskich / skrośnych w technologii TDM oraz VoIP.

1.1.10. System telekomunikacyjny musi mieć zaimplementowane uniwersalne licencjonowanie portów abonenckich TDM oraz VoIP.

1.1.11. System telekomunikacyjny musi posiadać zaimplementowane wspólne licencjonowanie w ramach centrali tj. w ramach lokalizacji głównej i wyniesionych. Aktywacja portu abonenckiego w danej lokalizacji nie może powodować konieczności realizacji dodatkowych usług wgrywania/przenoszenia licencji do tej lokalizacji lub usług statycznego dzielenia wspólnej puli licencji na dane lokalizacje.

1.1.12. System telekomunikacyjny musi być wyposażony w duplikację jednostki sterującej działającej w trybie „gorącej rezerwy” (zawierającej pełną replikę oprogramowania sterującego i aplikacyjnego), w szczególności system musi zapewniać utrzymanie bez zmian i strat jakości wszystkich zestawionych połączeń w czasie i po przełączeniu na zapasową jednostkę sterującą.

1.1.13. System telekomunikacyjny musi posiadać redundantne zasilacze półek abonenckich i półki sterującej. Awaria jednego z prostowników nie powoduje wyłączenia poszczególnych półek.

1.1.14. System telekomunikacyjny powinien posiadać możliwość podłączenia do redundantnej siłowni telekomunikacyjnej wraz z bateriami podtrzymującymi działanie głównego systemu na 8 godzin. Moc siłowni jest tak dobrana, że w przypadku awarii nawet dwóch modułów prądowych siłowni, nie następuje przeciążenie i wyłączenia siłowni.

1.1.15. Zasilanie modułów wyniesionych musi być dobrane tak, by było zachowane podtrzymanie bateryjne na minimum 8 godzin.

1.1.16. System musi gwarantować niezależność poszczególnych modułów wyniesionych w przypadku utraty połączenia z głównymi serwerami sterującymi. W przypadku odseparowania danego modułu wyniesionego musi być zachowana możliwość dzwonienia w obrębie lokalizacji oraz na zewnątrz systemu telekomunikacyjny poprzez lokalne łącza sieciowe oraz miejskie w technologii TDM/VoIP. System musi gwarantować niezależność co najmniej dwóch modułów wyniesionych (w lokalizacjach Xxxxxxxxxx 00 i Lipowa 27).

1.1.17. Dla lokalizacji głównej przełącznica dla strony stacyjnej o pojemności XXX par musi być wyposażona jest w łączówki rozłączne oraz kable do rozszycia kart systemowych. Łączówki są wyposażone w zabezpieczenia przepięciowe.

1.1.18. Dla modułów wyniesionych przełącznica strony stacyjnej musi być zakończona patch-panelami RJ45 – zintegrowanymi z modułami. Każda lokalizacja jest wyposażona w szafę rack 19” w której mieści się sprzęt.

1.1.19. System telekomunikacyjny musi być wyposażony we wszystkie niezbędne licencje wymagane do obsługi Systemu.

1.1.20. Połączenie systemu telekomunikacyjny w lokalizacji głównej z modułami wyniesionymi musi być zrealizowane za pomocą technologii IP.

1.1.21. System telekomunikacyjny musi być wyposażony w funkcję służącą do awaryjnego zestawienia połączenia pomiędzy lokalizacją główna i modułami wyniesionymi w oparciu o łącza ISDN w przypadku awarii/niedostępności technologii IP.

1.1.22. System telekomunikacyjny musi posiadać zintegrowany podsystem CTI umożliwiający integrację zewnętrznych aplikacji w oparciu o otwarty protokół CSTA

III. Aktywacja linku CSTA, monitorowanie abonentów poprzez CSTA, realizacja funkcji telekomunikacyjnych z zastosowaniem CSTA nie wymaga zakupu dodatkowych licencji. Liczba wymaganych jednoczesnych połączeń CSTA w systemie to minimum 100.

1.1.23. System telekomunikacyjny musi obsługiwać telefony analogowe przewodowe z funkcją CLIP prezentującą na ich wyświetlaczach numer i/lub nazwę dzwoniącego abonenta (nazwa dzwoniącego abonenta wewnętrznego systemu pochodzi z bazy danych abonentów centrali telefonicznej).

1.1.24. System telekomunikacyjny musi się integrować się z funkcjonującą u Zamawiającego siecią LAN/WAN wykorzystującą protokoły IP, obsługuje sieci typu Ethernet IEEE 802.3, interfejs 100 BaseT.

1.1.25. System musi mieć możliwość przygotowania infrastruktury telefonii DECT

z wykorzystaniem punktów dostępowych i terminali tego samego producenta co centrali telefonicznej PABX, umożliwiającej przekazywanie rozmowy między punktami dostępowymi w czasie przemieszczania się użytkownika po obiekcie, bez zrywania aktualnie prowadzonej rozmowy.

1.1.26. System musi mieć możliwość przygotowania infrastruktury telefonii bezprzewodowej w technologii VoIP z wykorzystaniem istniejących punktów dostępowych WLAN będących w posiadaniu Zamawiającego i terminali WLAN tego samego producenta co centrali telefonicznej PABX.

1.1.27. System telekomunikacyjny musi mieć możliwość rozbudowy o dedykowane aplikacje tego samego producenta ze względu na integralność realizowanych usług:

1.1.27.1. centralny system faks serwer

1.1.27.2. centralny system poczty głosowej

1.1.27.3. system automatycznego powiadamiania i alarmowania w ramach Zarządzania Kryzysowego

1.1.27.4. system audio konferencyjny

1.1.27.5. system contact center

1.1.27.6. system kryzysowej łączności dyspozytorskiej/operacyjnej

1.1.27.7. aplikacja na urządzenia mobilne typu smartfon z systemem operacyjnym Android oraz iOS

1.1.28. System telekomunikacyjny musi mieć możliwość rozbudowy o rozwiązanie centralnego nagrywania rozmów – rejestrator w lokalizacji głównej nagrywający wybranych abonentów:

1.1.28.1. TDM (analogowych i systemowych),

1.1.28.2. VoIP (systemowych i SIP),

1.1.28.3. DECT

podłączonych do systemu w lokalizacji głównej oraz wyniesionych. Aktywacja nowego nagrywanego abonenta powinna wymuszać wprowadzanie nowych połączeń krosowych (abonenci TDM) lub stosowania funkcji port-mirroring na przełączniku sieciowym (abonenci VoIP). Integracja rejestratora z systemem jest zrealizowana za pomocą łączy E1 lub styku SIP. Wybór nagrywanych abonentów odbywa się programowo za pomocą konsoli administracyjnej spośród dowolnych abonentów systemu.

1.1.29. W celu zabezpieczania nadmiernego obciążania sieci IP, moduły wyniesione są wyposażone w lokalnie generowane komunikaty głosowe i kanały audio- konferencyjne. Komunikacja wewnętrzna w ramach modułu wyniesionego nie może alokować na stałe kanałów do modułu głównego.

1.1.30. Centrala musi posiadać dedykowane moduły/karty liniowe w lokalizacji głównej na potrzeby obsługi łączy ISDN PRA (30B+D) – styk E1 - z sygnalizacją DSS1 i bezpośrednim wybieraniem numeru wewnętrznego DDI.

1.1.31. Lokalizacje wyniesione muszą posiadać dedykowane moduły/karty liniowe na potrzeby obsługi łączy ISDN PRA (30B+D) – styk E1 - z sygnalizacją DSS1 i bezpośrednim wybieraniem numeru wewnętrznego DDI – co najmniej jako zapasowa droga w przypadku awarii łączy podstawowych wewnętrznych oraz miejskich.

1.1.32. Centrala musi posiadać dedykowane moduły/karty liniowe w lokalizacji głównej na potrzeby obsługi łączy ISDN BRA z sygnalizacją DSS1 i bezpośrednim wybieraniem numeru wewnętrznego DDI. Łącza ISDN 2B+D muszą być wyprowadzone z modułów liniowych centrali bez konieczności stosowania dodatkowych urządzeń/przystawek.

1.1.33. Lokalizacje wyniesione muszą posiadać dedykowane moduły/karty liniowe na potrzeby obsługi łączy ISDN BRA z sygnalizacją DSS1 i bezpośrednim wybieraniem numeru wewnętrznego DDI. Łącza ISDN 2B+D muszą być wyprowadzone z modułów liniowych centrali bez konieczności stosowania dodatkowych urządzeń/przystawek.

1.1.34. Centrala musi posiadać dedykowane moduły/karty liniowe w lokalizacji głównej na potrzeby obsługi łączy analogowych miejskie A/B z obsługą funkcji CLIP (dla wywołań przychodzących). Łącza analogowe muszą być wyprowadzone z modułów liniowych centrali bez konieczności stosowania dodatkowych urządzeń/przystawek

1.1.35. Centrala musi posiadać dedykowane moduły/karty abonenckich portów cyfrowych umożliwiających podłączenie aparatów systemowych za pomocą jednej pary przewodów na odległość minimum 1200 m bez dodatkowych aktywnych urządzeń pośredniczących.

1.1.36. Centrala musi posiadać dedykowane moduły/karty abonenckich portów analogowych umożliwiających podłączenie aparatu analogowego na odległość, co najmniej 2000 metrów z użyciem jednej pary przewodów (skrętka), wraz z prezentacją numeru osoby dzwoniącej (CLIP dla wszystkich łączy abonenckich analogowych)

1.1.37. Centrala musi posiadać zintegrowany sprzętowo moduł bramy łączy miejskich Voice over IP w standardzie SIP Trunk wykorzystujący jako medium transportowe sieć LAN/WAN. Moduł ma możliwość instalacji w lokalizacji głównej oraz w każdej lokalizacji wyniesionej.

1.1.38. Centrala musi posiadać zintegrowany sprzętowo moduł bramy abonentów Voice over IP z zachowaniem pełnej funkcjonalności systemowego aparatu stacjonarnego oraz łączy VoIP wykorzystujący jako medium transportowe sieć LAN/WAN. Moduł jest instalowany w lokalizacji głównej oraz w każdej lokalizacji wyniesionej.

1.1.39. Moduł bramy VoIP musi obsługiwać jednocześnie abonentów VoIP z wykorzystaniem dedykowanego protokołu systemowego producenta H.323 oraz uniwersalnego protokołu SIP.

1.1.40. Moduł bramy VoIP musi obsługiwać jednocześnie abonentów VoIP oraz styku trunk VoIP z wykorzystaniem protokołu SIP.

1.1.41. Moduł bramy VoIP musi obsługiwać jednocześnie minimum 60 rozmów. Jeżeli w dostosowanym środowisku telekomunikacyjnym nie będzie możliwe utrzymanie istniejących 60-cio kanałowych modułów Zamawiającego, to Zamawiający oczekuje wymiany tych modułów na nowe kompatybilne, współpracujące z dostosowanym środowiskiem telekomunikacyjnym

1.1.42. Moduł bramy VoIP musi obsługiwać jednoczesną rejestrację minimum 240 abonentów VoIP z obsługą protokołu systemowego.

1.1.43. Moduł bramy VoIP musi wspierać poniższe standardy:

1.1.43.1. Obsługę standardu IEEE 802.1Q,

1.1.43.2. Obsługę QoS w warstwie 2 zgodnie ze standardem 802.1p,

1.1.43.3. Obsługę QoS w warstwie 3 zgodnie ze mechanizmem TOS oraz DiffServ.

1.1.44. Moduł bramy VoIP musi wspierać kodowanie G.711, G.729, G.722 dla wszystkich abonentów VoIP. Wybór kodowania nie wiąże się z zakupem dodatkowych licencji.

1.1.45. Moduł bramy VoIP musi obsługiwać łącza wewnętrzne VoIP między lok. główną a pozostałymi modułami w lokalizacjach wyniesionych.

1.1.46. Moduł bramy VoIP musi obsługiwać łącza VoIP do innych systemów telekomunikacyjnych z zastosowaniem standardu SIP-Trunk.

1.1.47. Bezpłatne licencje dla portów łączy miejskich, skrośnych, specjalnych w technologii TDM oraz VoIP,

1.1.48. Bezpłatne licencje dla funkcjonalności autonomi działania lokalizacji wyniesionej (APE) oraz zestawiania alternatywnego kanału sygnalizacji lokalizacji wyniesionej (Signalling Survivability)

1.1.49. Bezpłatne licencje na połączenie systemu z aplikacjami rozszerzającymi funkcjonalność systemu w oparciu o CTI z protokołem CSTA,

1.1.50. Wprowadzenia osobnego licencjonowania portów abonenckich TDM oraz uniwersalnych licencji portów abonenckich Flex (TDM oraz VoIP),

1.1.51. Umożliwienie wprowadzenia rozwiązania jako następcy dla istniejących rozwiązań konsol awizo,

1.1.52. Wprowadzenia nowego portu dla obsługi abonentów SIP o nazwie UFIP – z rozszerzonym zakresem funkcjonalnym w stosunku do istniejącego portu typu SIP.

1.1.53. Wprowadzenia rozwiązania jako następcy dla istniejących modułów wyniesionych pozwalających na instalację więcej niż 9-ciu kart/pakietów per moduł.

1.1.54. Rozszerzenie istniejących funkcjonalności dla abonentów:

1.1.54.1. w zakresie obsługi grup poszukiwania, grup zbiorowego wywołania, oddzwonienia przy zajętości,

1.1.54.2. w zakresie monitoringu statusu portu poprzez CTI z protokołem CSTA,

1.1.54.3. w zakresie prezentacji nazwy abonenta na wyświetlaczu,

1.1.54.4. w zakresie aktywacji/deaktywacji funkcji przeniesienia rozmowy na wskazany numer za pomocą zewnętrznej aplikacji (Remote Call Forwarding),

1.1.55. Wsparcie dla integracji z rozwiązaniem z chmury publicznej Circuit.

1.1.56. Wsparcie dla nowych aparatów systemowych producenta podsystemów telekomunikacyjnych.

1.1.57. Zintegrowanie aplikacji DTB (zintegrowana książka telefoniczna dla abonentów systemowych z wyświetlaczem) w centralnej części systemu podsystemu telekomunikacyjnego TDM/VOIP.

1.1.58. Wsparcie dla zintegrowanej aplikacji serwera BLF rozszerzającej funkcjonalności awizo w podsystemie telekomunikacyjnym TDM/VOIP. Aplikacja kliencka BLF musi wprowadzać funkcjonalność monitorowania statusu abonentów na stacji roboczej z OS Windows dla operatora awizo.

1.1.59. Wprowadzenie wsparcia dla oprogramowania typu softphone na urządzenia mobilne z OS Android oraz iOS.

1.1.60. Wprowadzenia wsparcia dla nowego oprogramowania typu softphone (OSDC) na stacje robocze z OS Windows.

1.2. System telekomunikacyjny – funkcje telefoniczne i zarządzanie

1.2.1. System telekomunikacyjny musi obsługiwać dostęp do funkcji telefonicznych z poziomu aparatów systemowych, analogowych oraz VoIP.

1.2.2. System musi obsługiwać przydział kilku różnych numerów wewnętrznych (co najmniej pięciu) do jednego aparatu systemowego, z możliwością wyboru przez przycisk na aparacie linii wewnętrznej, za pomocą której będzie realizowane połączenie wychodzące (właściwa i różna prezentacja numeru dla połączeń wychodzących w zależności od wybranej linii wewnętrznej: służbowej, prywatnej i pilnej).

1.2.3. System musi posiadać mechanizm marszrutowania połączeń, który dla każdego abonenta, w sposób automatyczny, dokonuje wyboru najlepszej (najtańszej) trasy połączenia, z funkcją przepełnienia (łączenia rozmów drogą obejściową).

1.2.4. System musi posiadać poniższe funkcje telekomunikacyjne:

1.2.4.1. Prezentacja numeru (CLIP),

1.2.4.2. Blokada prezentacji numeru (CLIR),

1.2.4.3. Identyfikacja numeru dzwoniącego (COLP),

1.2.4.4. Blokada identyfikacji numeru dzwoniącego (COLR),

1.2.4.5. Call Hold (HOLD),

1.2.4.6. Advice of charge (AOC) – wyświetlenie informacji o opłacie za połączenie na wyświetlaczu aparatu systemowego w walucie PLN,

1.2.4.7. Połączenia automatyczne typu gorąca linia (HOT LINE) bezzwłocznie realizowane natychmiast po podniesieniu mikrotelefonu,

1.2.4.8. Połączenia automatyczne typu gorąca linia (HOT LINE) ze zwłoką, realizowane po upływie predefiniowanego czasu po podniesieniu mikrotelefonu jeżeli użytkownik nie rozpoczął wybierania w sposób konwencjonalny,

1.2.4.9. Możliwość realizacji połączeń z dowolnego aparatu z wykorzystaniem posiadanych uprawnień (przypisanie opłat taryfikacyjnych na rachunek dokonującego połączenie) poprzez wprowadzenie kodów PIN,

1.2.4.10. Kod osobisty telefonu – możliwość zablokowania/odblokowania telefonu dla wszystkich abonentów systemu,

1.2.4.11. Mechanizm (zdalnego) monitorowania linii na aparatach systemowych: nadzór linii abonenckiej układu sekretarsko-dyrektorskiego,

1.2.4.12. Przeniesienie dzwonienia na inny numer: natychmiastowe, przy braku odbioru, przy zajętości,

1.2.4.13. Transfer rozmów wychodzących - możliwość przekazania rozmowy wychodzącej do innego abonenta z jednoczesną kontrolą odpowiednich uprawnień do realizacji takiej usługi,

1.2.4.14. Transfer odebranego połączenia z anonsem na dowolny numer wewnętrzny lub zewnętrzny,

1.2.4.15. Transfer odebranego połączenia bez anonsu na dowolny numer wewnętrzny lub zewnętrzny,

1.2.4.16. Sygnalizacja rozmowy oczekującej (przychodzącej) z możliwością dezaktywacji bądź aktywacji tej usługi,

1.2.4.17. Definiowanie grup poszukiwania (hunting groups) – tworzenie numeru grupowego po wybraniu którego wywoływane są kolejne stacje wg. określonego szyku: liniowo, cyklicznie,

1.2.4.18. Definiowanie grup przechwytujących (Pick-up groups) – w przypadku wywołania na jednej ze stacji grupy możliwość przejęcia tego wywołania na dowolnej stacji grupy,

1.2.4.19. Oddzwanianie przy zajętości – w przypadku zajętości stacji wywoływanej abonent może zażądać zasygnalizowania faktu, że stacja wywoływana przeszła w stan spoczynku, tzn. zakończyła dotychczasowe połączenie,

1.2.4.20. MCID - możliwość aktywowania usług identyfikacji złośliwych połączeń, napastliwych, nękających itp. z publicznej sieci ISDN,

1.2.4.21. „Wejście na trzeciego” dla uprzywilejowanego abonenta - możliwość włączenia się w trwającą rozmowę, możliwość przerwania trwającej rozmowy i zestawienie rozmowy z wybranym numerem,

1.2.4.22. Ochrona przed „wejściem na trzeciego”- możliwość aktywowania dla wewnętrznego wybranego abonenta usługi uniemożliwiającej włączenie w prowadzone przez niego rozmowy,

1.2.4.23. Tworzenie uprawnień na potrzeby przerywania użytkownikowi aktualnie prowadzonej rozmowy i połączenie się z nim – w sytuacjach priorytetowych (wejście na trzeciego z rozłączeniem),

1.2.4.24. Wybieranie DTMF,

1.2.4.25. Zapamiętanie numeru zewnętrznego i ponowne połączenie,

1.2.4.26. Funkcja „nie przeszkadzać”,

1.2.4.27. Indywidualna książka telefoniczna,

1.2.4.28. Centralna książka telefoniczna dostępna z dla wszystkich aparatów systemowych TDM oraz systemowych VoIP,

1.2.4.29. Połączenia oczekujące (wieloliniowość),

1.2.4.30. Zróżnicowany sygnał dzwonienia (inny dla wewnętrznych i inny dla zewnętrznych),

1.2.4.31. Obsługa fikcyjnych numerów wewnętrznych (minimum 5000) dla potrzeb użytkowników bez aparatów fizycznych – mających dostęp do systemu za pomocą kodów PIN,

1.2.5. System telekomunikacyjny musi posiadać usługę jednego numeru kontaktowego (inaczej: numer osobisty) dla grupy urządzeń użytkownika:

1.2.5.1. aparat systemowy,

1.2.5.2. inny aparat wewnętrzny, w tym analogowy, SIP, DECT,

1.2.5.3. aparat zewnętrzny, w tym gsm.

Wywołanie powinno być kierowane jednocześnie do wszystkich urządzeń. W przypadku podjęcia rozmowy na dowolnym z aparatów pozostałe przestają dzwonić.

1.2.6. System telekomunikacyjny musi posiadać w lokalizacji głównej usługę audiokonferencji ośmiostronnej – realizowaną manualnie poprzez rozbudowę

konferencji trójstronnej przez dodanie kolejnych uczestników konferencji z dowolnego aparatu wewnętrznego systemowego, dla uczestników, którymi są zarówno abonenci wewnętrzni centrali jak i zewnętrzni (sieć publiczna i korporacyjna).

1.2.7. System telekomunikacyjny musi posiadać w lokalizacji wyniesionej usługę audiokonferencji trójstronnej – możliwość zestawienia konferencji z dowolnego aparatu wewnętrznego, dla uczestników, którymi są zarówno abonenci wewnętrzni centrali jak i zewnętrzni.

1.2.8. System telekomunikacyjny musi posiadać w lokalizacji wyniesionej usługę audiokonferencji ośmiostronnej – możliwość rozbudowy konferencji trójstronnej przez dodanie kolejnych uczestników konferencji z dowolnego aparatu wewnętrznego systemowego, dla uczestników, którymi są zarówno abonenci wewnętrzni centrali jak i zewnętrzni (sieć publiczna i korporacyjna).

1.2.9. System telekomunikacyjny musi mieć możliwość doposażenia w konsolę awizo bazującą na komputerze (komplety komputer + monitor wraz z niezbędnym oprogramowaniem) oraz dedykowaną klawiaturę do obsługi połączeń telefonicznych. Aplikacja umożliwia również monitorowanie jednocześnie co najmniej 300 obiektów w czasie rzeczywistym.

1.2.10. System telekomunikacyjny musi posiadać wewnętrzne grupy ACD z routingiem opartym na metodach kolejkowania ACD na potrzeby wewnętrznej infolinii. Obsługa minimum 50 Konsultantów, 20 grup, 5 Supervisorów.

1.2.11. System telekomunikacyjny musi realizować lokalne wgrywanie zapowiedzi głosowych (import pliku wav) dla co najmniej 4 plików jako zapowiedź ogólna.

1.2.12. System telekomunikacyjny musi realizować funkcję odtwarzania komunikatów przed połączeniem osoby dzwoniącej z zewnątrz na daną grupę numerów.

1.2.13. System telekomunikacyjny musi realizować obsługę zestawów sekretarsko- dyrektorskich. Liczba obsługiwanych jednocześnie zestawów na aparatach cyfrowych w konfiguracji 2 Sekr. i 4 Dyr. minimum 50.

1.2.14. Zestaw sekretarsko-dyrektorski musi umożliwiać pracę zestawów w konfiguracji typu n-sekretarek obsługuje m dyrektorów, gdzie n=1-2 (minimum) m=1-4 (minimum).

1.2.15. Zestaw sekretarsko-dyrektorski musi umożliwiać filtrowanie połączeń zewnętrznych i wewnętrznych.

1.2.16. Zestaw sekretarsko-dyrektorski musi umożliwiać powiadamianie o nieobecności dyrektora.

1.2.17. Zestaw sekretarsko-dyrektorski musi umożliwiać natychmiastowe przekazywanie połączeń z telefonu dyrektora do telefonu sekretarki, aktywowane przez dyrektora lub sekretarkę.

1.2.18. System telekomunikacyjny musi posiadać jako integralny element systemową centralną książkę telefoniczną o pojemności co najmniej 5 000 rekordów (wpisów dla abonentów wewnętrznych oferowanego systemu PBX).

1.2.19. Dostęp do książki telefonicznej dla dowolnego abonenta wewnętrznego oferowanego systemu telekomunikacyjnego musi być możliwy bezpośrednio z przypisanego aparatu systemowego wyposażonego w wyświetlacz. Możliwość wybierania „po nazwie” abonenta.

1.2.20. System telekomunikacyjny posiada, jako integralny element, system zarządzania centralą. Komunikacja między użytkownikiem a systemem zarządzania jest realizowana za pomocą połączenia IP.

1.2.21. System telekomunikacyjny musi posiadać możliwość zarządzania całością lub wybraną częścią systemu w sposób lokalny lub zdalny jednocześnie przez 2 różnych administratorów, z zachowaniem pełnej rozliczalności pracy każdego administratora.

1.2.22. System telekomunikacyjny musi posiadać możliwość zarządzania systemem przez interfejs WWW w trybie graficznym oraz za pomocą dedykowanej aplikacji instalowanej na komputerze – w architekturze klient-serwer.

1.2.23. Zarządzanie poprzez Interfejs WWW w trybie graficznym musi prezentować unikalny identyfikator (numer seryjny) systemu, ilości licencji abonenckich zakupionych do systemu oraz ilości używanych przez system z tej puli, wersje oprogramowania systemu telekomunikacyjnego, czas do zakończenia kontraktu wsparcia producenta dla systemu.

1.2.24. W przypadku awarii systemu rozumianej jako uszkodzenie sterowania, modułu sterującego lub pojedynczej karty fakt ten zostanie jest wysłany w sposób automatyczny poprzez SNMP do wskazanego centralnego systemu monitorowania.

1.2.25. System telekomunikacyjny musi posiadać możliwość obsługi alarmów i raportów generowanych przez elementy systemu.

1.2.26. System telekomunikacyjny musi posiadać możliwość definiowania praw dostępu dla poszczególnych użytkowników (sposób dostępu, różne poziomy użytkownika) na potrzeby zarządzania systemem.

1.2.27. System telekomunikacyjny musi umożliwiać:

1.2.27.1. przeglądanie zainstalowanych modułów,

1.2.27.2. zarządzanie łączami i kierowanie ruchem,

1.2.27.3. administrację abonentami (kreowanie, usuwanie, wyświetlanie danych, modyfikacja uprawnień i danych itp.),

1.2.27.4. zarządzanie rejestrację ruchu na poszczególnych łączach lub grupach łączy do ewentualnych celów rozliczeń międzyoperatorskich.

1.2.28. System musi posiadać zdolność do tworzenia rekordów taryfikacji połączeń wychodzących, przychodzących, wewnętrznych.

1.2.29. System musi posiadać zdolność do tworzenia rekordu taryfikacyjnego zawierającego oprócz podstawowych elementów również:

1.2.29.1. informację o zrealizowaniu połączenia lub nieodebraniu rozmowy,

1.2.29.2. czas wywoływania na aparacie użytkownika przed odebraniem lub rozłączeniem się strony A bez podjęcia wywołania,

1.2.29.3. akt zastosowania indywidualnego kodu PIN przez użytkownika dla rozmowy wychodzącej.

2. Funkcjonalności Systemu Telekomunikacyjnego – Podsystem VOIP

2.1. Funkcjonalności serwera telekomunikacyjnego typu SOFTSWITCH SIP (moduł):

2.1.1. System telekomunikacyjny do realizacji usług głosowych w sieci IP musi opierać się na architekturze Softswitch i RFC3261 i działa wyłącznie w oparciu o komutację pakietów w sieci IP.

2.1.2. System telekomunikacyjny musi charakteryzować się otwartą architekturą, umożliwia przyłączanie terminali użytkowników różnych producentów w oparciu o interfejs z protokołem SIP 2.0.

2.1.3. System telekomunikacyjny musi pozwalać na korzystanie z łączy SIP trunk, gdzie łącza SIP trunk i kanały głosowe w SIP trunk nie są ograniczane licencjami (dodawanie kanałów głosowych w SIP trunk nie wymaga wykupienia dodatkowych licencji).

2.1.4. System telekomunikacyjny musi charakteryzować się otwartą architekturą, umożliwia przyłączanie aplikacji (typu IVR) różnych dostawców w oparciu o interfejsy z protokołem SIP.

2.1.5. Podłączanie terminali różnych dostawców nie będzie wymagało wykupienia dodatkowych licencji lub dodatkowej liczby licencji innych niż dla telefonów dostawcy systemu.

2.1.6. System telekomunikacyjny musi pozwalać na rozszerzenie liczby użytkowników do co najmniej 4500 jedynie poprzez zakup odpowiednich licencji.

2.1.7. System telekomunikacyjny musi być w stanie obsłużyć jednocześnie min. 4500 aktywnych połączeń.

2.1.8. Pojedyncza licencja musi umożliwiać zarejestrowanie minimum 5 urządzeń (typu aparat systemowy, aparat VoIP, terminal GSM, DECT, WLAN) o tym samym numerze, dla klientów SIP aktualnego systemu OSV, którzy mogą być uruchomieni na dowolnym urządzeniu obsługującym aplikacje kliencką abonenta SIP.

2.1.9. System telekomunikacyjny główny powinien realizować scenariusz niezawodnościowy z zastosowaniem klastra serwerów pracujących w trybie aktywny-aktywny. Awaria/niedostępność jednego z serwerów systemu nie może wpływać na realizację połączeń telekomunikacyjnych – już zestawionych oraz nowych.

2.1.10. Klaster serwerów musi mieć możliwość umieszczenie w rozdzielonych geograficznie lokalizacjach serwerowni Zamawiającego. Klaster powinien pracować w tym samym segmencie adresacji sieci oraz wykorzystywać połączenie w warstwie L2 do synchronizacji danych pomiędzy węzłami klastra.

2.1.11. System telekomunikacyjny musi realizować scenariusz niezawodnościowy z podwójną rejestracją telefonów SIP - rejestracja w systemie głównym i niezależnie w autonomicznej bramie SIP Proxy (funkcja przetrwania).

2.1.12. W przypadku scenariusza z podwójną rejestracją telefony pracujące w trybie awaryjnym i rejestrujące się do bramy SIP Proxy z funkcją przetrwania cyklicznie muszą sprawdzać dostępność głównego systemu SIP Registrar. W takiej sytuacji system tel. umożliwia losowy dobór czasu po którym następują takie próby aby nie przeciążać serwera.

2.1.13. System telekomunikacyjny musi być certyfikowany przez producenta do pracy w środowisku zwirtualizowanym w oparciu o standard Open Virtualization Format (OVF).

2.1.14. W funkcjonującym Systemie nie ma wersji testowych (ang. trial) oprogramowania komercyjnego.

2.1.15. W funkcjonującym Systemie nie ma oprogramowania darmowego (ang. Freeware/OpenSource) bez wsparcia producenta.

2.1.16. System telekomunikacyjny musi zapewniać nieograniczoną ilość konferencji trójstronnych SIP.

2.1.17. System telekomunikacyjny musi zapewniać możliwość jednoczesnego prowadzenia co najmniej 20 konferencji wielostronnych (co najmniej 8 uczestników każda).

2.1.18. System telekomunikacyjny musi zapewniać funkcję automatycznego stanowiska awizo dla połączeń przychodzących, z możliwością tworzenia indywidualnych zapowiedzi (IVR).

2.1.19. System telekomunikacyjny musi zapewniać funkcję wgrania lub usunięcia zapowiedzi jako plik wav.

2.1.20. System telekomunikacyjny musi zapewniać funkcję nagrania zapowiedzi przez telefon po podaniu kodu w zakresie poczty głosowej dla co najmniej 30 abonentów.

2.1.21. System telekomunikacyjny musi zapewniać obsługę wielu scenariuszy każdy z osobną nazwą.

2.1.22. Dla każdego scenariusza system musi zapewniać funkcję przypisania osobnych zapowiedzi w sytuacji: przywitanie, prośba o wybór klienta kodem DTMF, informacja w przypadku niepoprawnego wyboru, pożegnanie.

2.1.23. Scenariusze muszą być aktywowane i dezaktywowane automatycznie na podstawie dnia tygodnia i godziny gdy mają być aktywne.

2.1.24. Aktywowanie i dezaktywowanie scenariusza za pomocą interfejsu graficznego terminala administracyjnego musi być obsługiwane ręcznie. Aktywowanie i dezaktywowanie scenariusza za pomocą kodu DTMF jest obsługiwane ręcznie.

2.1.25. Osobno dla każdego scenariusza musi być obsługiwany domyślny cel przekierowania (numer awizo, działu lub sekretariatu).

2.1.26. Domyślny cel przekierowania musi być obsługiwany zarówno, jako numer wewnętrzny w systemie, jak również numer zewnętrzny, w tym operatora publicznego stacjonarnego lub gsm.

2.1.27. System telekomunikacyjny musi być kompletny, tj. posiadać wszystkie niezbędne elementy sprzętowe, programowe i licencyjne.

2.1.28. System telekomunikacyjny musi posiadać wbudowaną funkcjonalność firewall pozwalającą na blokowanie ruchu na podstawie parametrów warstw 2, 3, 4 modelu ISO/OSI.

2.1.29. System telekomunikacyjny musi pozwalać na realizowanie połączeń przez użytkowników z zewnątrz sieci IP Zamawiającego – bez względu na lokalizację (wsparcie dla przekierowania połączeń NAT przez Intranet).

2.1.30. System telekomunikacyjny musi umożliwiać uruchomienie lokalizacji z funkcjami autonomii w oparciu o środowisko w pełni wirtualne, w której (tj. lokalizacji) znajduje się platforma wirtualizacyjna realizująca usługi: SIP Proxy, zapowiedzi i konferencje (serwer mediów), automatyczne awizo, oraz łącze do miasta typu SIP Trunk.

2.1.31. System telekomunikacyjny musi dostarczać następujące funkcje dla użytkowników końcowych:

2.1.31.1. Prezentację numeru abonenta dzwoniącego (CLIP) oraz blokada prezentacji numeru abonenta dzwoniącego (CLIR).

2.1.31.2. Interkom jednostronny - system tel. musi realizować funkcję jednokierunkowego połączenia interkomowego. Uprawniony użytkownik aparatu systemowego (Abonent A) wybiera kod dostępu do funkcji a następnie odbiorcę wyposażonego w aparat systemowy (Abonent B). Powoduje to zestawienie jednostronnego kanału komunikacji głosowej od abonenta A do abonenta B. Po użyciu funkcji głośnik w aparacie odbiorcy powinien zostać automatycznie włączony, a po rozłączeniu się abonenta A połączenie zostanie zakończone. Funkcjonalność interkomu jednostronnego musi być realizowana przez wszystkie terminale systemowe Zamawiającego, które posiadają możliwość zaimplementowania (programowego lub sprzętowego) przycisku

„interkom”. Jednoczesne korzystanie z tej funkcjonalności to maksymalnie 30 połączeń Interkomowych (abonentów).

2.1.31.3. Interkom dwukierunkowy - System Telekomunikacyjny powinien mieć możliwość realizowania funkcji dwukierunkowego połączenia interkomowego. Uprawniony użytkownik aparatu systemowego (Abonent A) wybiera kod dostępu do funkcji a następnie odbiorcę wyposażonego w aparat systemowy (Abonent B). Powoduje to zestawienie dwukierunkowego kanału komunikacji głosowej pomiędzy abonentami A i B. Po użyciu funkcji głośniki i mikrofony w obu aparatach zostaną automatycznie włączone

2.1.31.4. Prezentację numeru abonenta, z którym jest zestawione połączenie (COLP) oraz blokada prezentacji numeru abonenta, z którym jest zestawione połączenie (COLR).

2.1.31.5. Prezentację nazwy abonenta dzwoniącego (CNIP) oraz blokada nazwy abonenta dzwoniącego (CNIR).

2.1.31.6. Prezentację nazwy abonenta, z którym jest zestawione połączenie (CNIP) oraz blokada prezentacji nazwy abonenta (CNIR), z którym jest zestawione połączenie.

2.1.31.7. Wizualną sygnalizacja rozmowy przychodzącej dla aparatów systemowych.

2.1.31.8. Przekierowanie wszystkich połączeń (natychmiastowe CFU).

2.1.31.9. Przekierowanie przy zajętości (CFB).

2.1.31.10. Przekierowanie w przypadku nie odbierania (CFNR).

2.1.31.11. Przekierowanie w przypadku braku rejestracji.

2.1.31.12. Przekierowanie zależne od czasu wszystkich połączeń (natychmiastowe CFU w tym tylko w godzinach pracy).

2.1.31.13. Przekierowanie zależne od czasu przy zajętości (CFB w tym tylko w godzinach pracy).

2.1.31.14. Przekierowanie zależne od czasu w przypadku nie odbierania (CFNR w tym tylko w godzinach pracy).

2.1.31.15. Możliwość zdalnego aktywowania przekierowania za pomocą aparatu (RCF) z podaniem kodu PIN. Przekierowanie może być zdefiniowane na numer wewnętrzny, zewnętrzny lub zbiorowy numer grupy poszukiwania.

2.1.31.16. Przekazywanie połączeń bez konsultacji.

2.1.31.17. Przekazywanie połączeń z konsultacją.

2.1.31.18. Szybkie wybieranie numeru docelowego (speed dialing).

2.1.31.19. Restrykcje dostępu do sieci minimum dla połączeń wewnętrznych, lokalnych, krajowych, międzynarodowych.

2.1.31.20. Możliwość zastosowania wymogu podania kodu PIN dla połączeń wychodzących.

2.1.31.21. Możliwość rozliczania rozmów dla danego projektu/konta oraz rozliczania kosztów poprzez podanie odpowiedniego kodu PIN.

2.1.31.22. Bezpośrednie wybieranie numerów wewnętrznych.

2.1.31.23. Zestawianie połączeń w oparciu o zdefiniowany plan numeracji.

2.1.31.24. Przekierowanie wszystkich połączeń oparte na serwerze (protokół CSTA).

2.1.31.25. Przekierowanie połączeń nie odbieranych oparte na serwerze (protokół CSTA).

2.1.31.26. Przekierowanie połączeń przy zajętości oparte na serwerze (protokół CSTA).

2.1.31.27. Funkcjonalność „nie przeszkadzać” DND w oparciu o serwer z możliwością konfiguracji zachowania dla abonenta A: zastosowania przekierowania warunkowego lub odrzucenia połączenia z komunikatem o niedostępności.

2.1.31.28. Obsługę połączeń oczekujących w sytuacji pracy normalnej i dla oddziałów wyposażonych w funkcje przetrwania również w czasie awarii WAN.

2.1.31.29. Obsługę klawiszy szybkiego wybierania numerów.

2.1.31.30. Transferowanie połączeń.

2.1.31.31. Callback – oddzwonienie.

2.1.31.32. Automatyczne wybieranie najlepszej drogi (z uwzględnieniem wag łączy).

2.1.31.33. Narzędzia dynamicznego uaktualniania oprogramowania systemowego telefonów.

2.1.31.34. Możliwość generowania raportów połączeń (Call Detail Reports) z aplikacji taryfikacyjnej.

2.1.31.35. Funkcjonalność sekretarsko-dyrektorska.

2.1.31.36. Możliwość realizacji usługi wideotelefonii z wykorzystaniem kamery i aplikacji instalowanej na stacji roboczej. Usługa wideotelefonii musi umożliwiać co najmniej trzy dwustronne interakcje jednocześnie, bez wykorzystania dodatkowych mostków wideokonferencyjnych

2.1.31.37. Możliwość realizacji usługi wideotelefonii z wykorzystaniem aparatu VoIP doposażonego w kamerę. Usługa wideotelefonii musi umożliwiać co najmniej trzy dwustronne interakcje jednocześnie, bez wykorzystania dodatkowych mostków wideokonferencyjnych.

2.1.31.38. Możliwość realizacji usługi wideotelefonii z wykorzystaniem dedykowanego zestawu wideokonferencyjnego.

2.1.31.39. Współpraca z aparatami telefonicznymi wspierającymi certyfikaty x509v3.

2.1.31.40. Zabezpieczenie protokołów sygnalizacyjnych protokołem IPsec lub TLS 1.3.

2.1.31.41. Zestawianie połączeń szyfrowanych na trasie od telefonu IP do telefonu IP protokołem SRTP.

2.1.31.42. Możliwość wyboru mechanizmu wymiany klucza (wymagana możliwość konfiguracji przez administratora systemu każdej z poniższych opcji indywidualnie dla każdego z abonentów systemu):

2.1.31.42.1. MIKEY

2.1.31.42.2. SDES

2.1.31.42.3. MIKEY lub SDES

2.1.31.42.4. Wyłączenie szyfrowania

2.1.32. System telekomunikacyjny musi posiadać wbudowany mechanizm Call Admission Control (CAC), tj. blokowanie możliwości zestawiania nowych połączeń przy niewystarczających zasobach sieci, uwzględniający minimum połączenia głosowe, faksowe i wideo.

2.1.33. Mechanizm CAC musi obsługiwać topologię sieci w postaci gwiazdy oraz kraty.

2.1.34. Mechanizm CAC musi umożliwiać zmianę parametrów używanych dla obliczeń pasma i definiowanie alarmów związanych z wysokim użyciem pasma.

2.1.35. Mechanizm CAC musi umożliwiać tworzenie grup CAC składających się z użytkowników i bram podlegających wspólnemu ograniczeniu zasobów sieciowych w oparciu o:

2.1.35.1. Numer telefonu,

2.1.35.2. Adres IP,

2.1.35.3. Domenę lokalizacji.

2.1.36. Mechanizm CAC musi umożliwiać definiowanie i stosowanie polityk CAC związanych z przesyłaniem strumieni połączeń obejmujących:

2.1.36.1. Połączenia tranzytowe przez łącze o ograniczonych zasobach pomiędzy grupami CAC i rdzeniem sieci (standardowe polityki CAC),

2.1.36.2. Połączenia tranzytowe przez łącze o ograniczonych zasobach pomiędzy dwoma różnymi grupami CAC (polityki między-grupowe CAC).

2.1.37. Polityki CAC umożliwiają jawne ograniczenie listy dozwolonych kodeków.

2.1.38. System telekomunikacyjny musi poprawnie obsługiwać wywołania na połączenia alarmowe dla następujących przypadków:

2.1.38.1. Gdy terminale użytkowników mają numery IP przywiązane do lokalizacji,

2.1.38.2. Gdy użytkownik wewnętrzny wybiera numer 112 system sprawdzi jego adres IP i w oparciu o ten adres przekieruje do właściwego dla lokalizacji użytkownika centrum powiadamiania alarmowego,

2.1.38.3. Gdy w parametrze wywołania „SIP INVITE” system przekaże informację o lokalizacji użytkownika

2.1.38.4. Gdy jest dostępna brama PSTN w obszarze działania właściwego centrum powiadomień alarmowych wywołanie alarmowe jest skierowane za jej pośrednictwem do centrum powiadomień alarmowych z pominięciem normalnych reguł kierowania połączeń ustalonych dla użytkownika wywołującego numer alarmowy (112),

2.1.38.5. Gdy nie będzie dostępna brama PSTN w obszarze działania właściwego centrum powiadomień alarmowych wywołanie alarmowe zostanie skierowane do centrum powiadomień alarmowych z użyciem normalnych reguł kierowania połączeń ustalonych dla użytkownika wywołującego numer alarmowy (112),

2.1.38.6. Gdy system telekomunikacyjny musi przechowywać informację o lokalizacji użytkownika i właściwym sposobie kierowania połączeń do centrum powiadomień alarmowych w specjalnej tabeli ELIN/LIN,

2.1.38.7. Gdy lokalizacja użytkownika może być określona przez parametry: 2.1.38.7.1. Numer telefonu,

2.1.38.7.2. Adres i podsieć IP użytkownika 2.1.38.7.3. Domenę lokalizacji

2.1.38.8. Gdy dostęp do kierowania połączeń alarmowych dla użytkowników wewnętrznych musi być realizowany z wykorzystaniem mechanizmów

redundancji nie gorszych niż do obsługi podstawowej usługi telefonicznej.

2.1.39. System telekomunikacyjny musi pozwalać na generowanie trapów SNMP w przypadku wykonywania rozmów na numery alarmowe. Wygenerowany w takim przypadku event SNMP zawiera co najmniej: wybrany numer, identyfikację numeru dzwoniącego, ELIN/LIN, oznaczenie czasu.

2.1.40. System telekomunikacyjny musi posiadać kompatybilne rozwiązanie poczty głosowej, możliwe do zintegrowania z systemami poczty elektronicznej, zarządzane przez przeglądarkę WWW.

2.1.41. System telekomunikacyjny musi posiadać funkcjonalność generowania raportów bilingowych (poprzez wykorzystanie rozwiązania firmy trzeciej).

2.1.42. System telekomunikacyjny musi zapewniać współpracę z bramami głosowymi opisanymi w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego.

2.1.43. System telekomunikacyjny musi zapewniać współpracę z SIP Proxy Server.

2.1.44. System telekomunikacyjny musi zapewniać współpracę z urządzeniami klienckimi (telefony IP, oprogramowanie dla stacji roboczych) z wykorzystaniem protokołu SIP.

2.1.45. System telekomunikacyjny musi zapewniać obsługę połączeń oczekujących.

2.1.46. System telekomunikacyjny musi obsługiwać wstrzymanie połączenia – Hold.

2.1.47. System telekomunikacyjny musi obsługiwać przejęcie połączenia.

2.1.48. System telekomunikacyjny musi obsługiwać linie wirtualne.

2.1.49. System telekomunikacyjny musi obsługiwać dynamiczne licencje użytkowników. Umożliwia wygenerowanie abonentów do pełnej żądanej rozbudowy sytemu. Zakupione licencje dynamiczne umożliwiają rejestrację wskazanej liczby abonentów SIP.

2.1.50. System telekomunikacyjny musi obsługiwać dzwonienie seryjne. Możliwość włączenia, wyłączenia funkcji, odsłuchania, bądź edycji listy urządzeń (min 6) na które ma zostać wysłany kolejno sygnał dzwonienia - przy połączeniu przychodzącym. Obsługa odbywa się za pomocą telefonu użytkownika.

2.1.51. System telekomunikacyjny musi obsługiwać dzwonienie równoległe. System musi zapewniać dla wszystkich użytkowników softswitch funkcję skierowania dzwonienia równolegle na aparat GSM, telefon programowy na PC, telefon biurkowy w systemie PBX oraz telefon w domu. Funkcja musi być konfigurowana przez administratora systemu. Przy odebraniu połączenia dzwonienie na inne numery ustaje. Możliwość włączenia i wyłączenia funkcji, odsłuchania bądź edycji listy urządzeń (minimum 6) na które ma zostać wysłany jednoczesny sygnał dzwonienia przy połączeniu przychodzącym. Obsługa musi być możliwa za pomocą telefonu użytkownika.

2.1.52. System telekomunikacyjny musi obsługiwać dzwonienie równoległe zdalną aktywacją. Możliwość włączenia funkcji z lokalizacji innej niż własny telefon po podaniu kodu PIN.

2.1.53. System telekomunikacyjny musi obsługiwać Interfejs One Number Service CSTA (ONS). Możliwość zarządzania wybieraniem i funkcjami abonenta za pomocą aplikacji komputerowej z interfejsem CSTA w taki sposób, aby niezależnie od tego

na jakim fizycznym urządzeniu wykonywana lub odbierana jest rozmowa abonent B widział stały numer abonenta A zdefiniowany w usłudze ONS.

2.1.54. System telekomunikacyjny musi obsługiwać funkcję Prywatna lista szybkiego wybierania definiowana przez użytkownika. Możliwość zdefiniowania listy do 25 numerów.

2.1.55. System telekomunikacyjny musi obsługiwać funkcję Prywatna lista szybkiego wybierania współdzielenie. Możliwość zdefiniowania listy jako współdzielonej z innymi użytkownikami systemu.

2.1.56. Systemowa lista szybkiego wybierania musi być definiowana przez administratora. Musi posiadać możliwość zdefiniowania 10 list do 1000 numerów i przypisania min 2 list każdemu użytkownikowi.

2.1.57. System telekomunikacyjny musi posiadać obsługę standardu Secure Shell dla Interfejsu Zarządzania w wersji 2.

2.1.58. System telekomunikacyjny musi posiadać wsparcie dla Native SIP Trunking.

2.1.59. System telekomunikacyjny musi posiadać obsługę grupy Pick-Up.

2.1.60. System telekomunikacyjny musi posiadać obsługę wieloliniowości. System powinien pozwalać na kreowanie zestawów wieloliniowych tak, by pojedyncza rozmowa była sygnalizowana u wielu abonentów. Rozmowa musi być sygnalizowana na stanowisku optycznie i akustycznie.

2.1.61. Obsługa wieloliniowości - system musi pozwalać na przypisanie linii jako pierwotnej do danego stanowiska, dodatkowej (pierwotnej na innym stanowisku), lub wirtualnej nie będącej pierwotnie przypisanej do żadnego stanowiska. Zależnie od trybu, sygnalizacja akustyczna (dzwonienie) może być włączona, opóźniona lub wyłączona.

2.1.62. Obsługa wieloliniowości - system dodatkowo musi pozwalać na przypisanie linii jako pierwotnej, lub dodatkowej jako prywatnej (przypisanej wyłącznie do jednego stanowiska).

2.1.63. System telekomunikacyjny musi pozwalać na równoległe wykorzystanie wieloliniowej grupy wyszukiwania (multiline hunt grup) oraz usługi One number Service sterowanej przez CSTA. Softswitch przekazuje do certyfikowanego serwera UC (Unified Communications) informacje pozwalające na rozróżnienie pomiędzy rozmowami automatycznie dystrybuowanymi w grupie i rozmowami nieskierowanymi do grupy.

2.1.64. Zarządzanie systemem jest realizowane co najmniej za pomocą interfejsu www oraz w postaci interfejsu SOA/WebService.

2.1.65. System telekomunikacyjny musi posiadać możliwość grupowej i zdalnej konfiguracji terminali VoIP.

2.1.66. System telekomunikacyjny musi posiadać możliwość zdalnej aktualizacji oprogramowania terminali VoIP.

2.1.67. System telekomunikacyjny musi posiadać możliwość tworzenia kopii zapasowej konfiguracji terminali VoIP.

2.1.68. System telekomunikacyjny musi posiadać możliwość rejestracji użytkownika na gościnnym terminalu przyłączonym do systemu, z przeniesieniem wszystkich ustawień z terminala podstawowego (między innymi konfiguracja przycisków funkcyjnych oraz książki telefonicznej).

2.1.69. System telekomunikacyjny musi posiadać funkcję backupu systemu.

2.1.70. System telekomunikacyjny musi pozwalać na wykorzystanie kodu uwierzytelnienia pozwalającego na rozróżnienie rozmów prywatnych i służbowych dla danego użytkownika w danej grupie biznesowej.

2.2. Funkcjonalności oraz wymagania dotyczące bramy łączy miejskich TDM z funkcją autonomii (SIP Proxy)

2.2.1. System musi posiadać rozwiązanie dla łączy miejskich TDM z funkcją autonomii (SIP Proxy),

2.2.2. SIP Proxy musi zapewniać usługi dla aparatów i użytkowników SIP zarejestrowanych w Softswitch'u:

2.2.2.1. Wsparcie dla głosu i wideo dla użytkowników końcowych Rozwiązanie SBC musi wspierać zarówno połączenia głosowe jak i wideo. W szczególności urządzenia głosowe takie jak aparaty sprzętowe oraz klienci programowi,

2.2.2.2. SIP Proxy musi umożliwiać realizację funkcji serwera pośredniczącego dla rejestracji SIP dla użytkowników w lokalizacji w sytuacji normalnej pracy (zgodnie z RFC 3261),

2.2.2.3. SIP Proxy musi umożliwiać realizację funkcji kierowania połączeń dla użytkowników w lokalizacji w sytuacji normalnej pracy,

2.2.2.4. SIP Proxy musi umożliwiać realizację funkcji autonomicznej rejestracji SIP dla użytkowników w lokalizacji w czasie braku łączności z serwerami Softswitch,

2.2.2.5. SIP Proxy musi umożliwiać realizację funkcji alternatywnego kierowania połączeń dla użytkowników w czasie braku łączności z serwerami Softswitch,

2.2.2.6. SIP Proxy musi obsługiwać komunikację SIP w oparciu o protokoły TLS/TCP i UDP.

2.2.3. SIP Proxy musi realizować usługi SBC:

2.2.3.1. Funkcję manipulacji nagłówkiem pakietu w celu ukrycia topologii sieci,

2.2.3.2. Funkcję serwera pośredniczącego w sesjach RTP, dla wsparcia transmisji VoIP przez bariery NAT w zakresie minimum Near End NAT i Far End NAT,

2.2.3.3. Funkcję obsługi łączy SIP trunk do operatora,

2.2.3.4. Funkcję zabezpieczenia obsługi łączy SIP dla abonentów FMC w sieci Internet.

2.2.4. SIP Proxy musi zapewniać funkcjonalność wsparcia dla połączeń Skype, unikalnych wymagań SIP trunking’u dla usługi ‘Skype Connect SIP trunking service’ związanej z uwierzytelnieniem IP-PBX, informacji o koncie, związku z jedną lub więcej tożsamością, które mogą być przypisane do IP-PBX - oddziałów biznesowych lub użytkowników.

2.2.5. Usługi SIP SBC musi umożliwiać obsługę minimum 250 jednoczesnych sesji SIP w lokalizacji - rozbudowa jedynie poprzez dogranie licencji.

2.2.6. Usługi SIP SBC musi umożliwiać obsługę minimum 10 równoległych sesji SIP Trunk do różnych operatorów w lokalizacji wyłącznie przez rekonfigurację administracyjną parametrów, bez nowego wdrożenia.

2.2.7. SIP Proxy musi realizować usługi serwera mediów w oparciu o zasoby lokalne:

2.2.7.1. Odtwarzanie stałych i zmiennych zapowiedzi dla użytkowników w lokalizacji,

2.2.7.2. Odtwarzanie tonów dla użytkowników w lokalizacji,

2.2.7.3. Zbieranie cyfr od użytkowników w lokalizacji,

2.2.7.4. Zestawianie konferencji inicjowanych przez użytkowników w lokalizacji,

2.2.7.5. Zapewnienie tonów,

2.2.7.6. Kodeki audio G.711 A-law, G.711 μ-law i G.729,

2.2.7.7. Wsparcie autonomii lokalizacji z zapasowym łączem danych.

2.2.8. SIP Proxy lokalnie powinien realizować usługi systemowe/strukturalne w czasie braku połączenia z systemem Softswitch (w trybie przetrwania). Minimalne wymagane usługi realizowane w oparciu o zasoby lokalne SIP Proxy to:

2.2.8.1. Obsługa wieloliniowych zestawów klawiszowych dla użytkowników aparatów systemowych.

2.2.8.2. Obsługa numerów grupowych (hunting MLHG).

2.2.8.3. Obsługa funkcji Przekierowanie połączeń.

2.2.8.4. Obsługa funkcji Transfer połączeń.

2.2.8.5. Obsługa funkcji Wstrzymanie połączenia (hold).

2.2.8.6. Obsługa funkcji Połączenia alarmowe.

2.2.8.7. Obsługa kierowania połączeń w oparciu o numery skrócone.

2.2.8.8. Obsługa bram dostępowych.

2.2.8.9. Funkcje serwera mediów – realizacja zapowiedzi i konferencji.

2.2.9. SIP Proxy musi wspierać redundancję w oparciu o standardowy protokół VRRP.

2.2.10. SIP Proxy musi wspierać obsługę redundancji konsultantów głosowych Contact Center – realizacja grup kierowania połączeń w oparciu o mechanizmy ACD i IVR obsługujące zapasową obsługę konsultantów Contact Center z własną zapowiedzią powitalną i zapowiedzią w kolejce oraz możliwością zalogowania/wylogowania konsultanta jedynie przez doposażenie o odpowiednie licencje.

2.2.11. W celu zapewnienia komunikacji z różnymi centralami telefonicznymi oraz sieciami operatorów, SIP Proxy musi realizować funkcję SIP Trunk jedynie przez doposażenie o odpowiednie licencje.

2.2.12. SIP Proxy musi realizować następujące usługi związane z bezpieczeństwem:

2.2.12.1. Wbudowany firewall zwiększający bezpieczeństwo komunikacji i realizujący:

2.2.12.1.1. Funkcje inspekcji stanowej (stateful) dla Network Address Translation / Port Address Translation (NAT/PAT).

2.2.12.1.2. Wykrywanie włamań sieciowych.

2.2.12.1.3. Prostą weryfikację protokołu TCP dla wymuszenia stanu sesji TCP.

2.2.12.1.4. Weryfikację numerów sekwencyjnych i potwierdzeń sesji, odrzucanie błędnych kombinacji flag sesji TCP.

2.2.12.2. Obsługę terminacji połączeń SRTP. Pośredniczenie dla MIKEY0 i SDES. Ta funkcja musi zapewnić współpracę SRTP i RTP, a także na pośredniczenie SRTP pomiędzy metodami wymiany kluczy MIKEY0 i SDES dla połączeń multimedialnych kierowanych przez SBC. Funkcja musi zapewnić utrzymanie maksymalnego bezpieczeństwa strumienia multimedialnego w obrębie sieci firmowej podczas używania trunk’ów SIP do dostawcy usług SIP, który nie wspiera SRTP.

2.2.12.3. SIP Proxy musi realizować funkcję Statefull Firewall z obsługą klasyfikacji w warstwie 7 (protokoły SIP i MGCP).

2.2.12.4. Obsługę bezpiecznych połączeń poprzez sieci publiczne (Virtual Private Network - VPN) w oparciu o:

2.2.12.4.1. Standard IPSec.

2.2.12.4.2. Generację kluczy przez OpenSSL.

2.2.12.4.3. Standardy podpisów XX0, XX0, XXX0, XXX-000, XXX, XXX-0, XXX-000, XXX-000, XXX-000, XXX-000.

2.2.12.4.4. Standardy kodowania i szyfrowania: kodowanie Base64, Blowfish, CAST, CAST5, DES, Triple-DES, IDEA, RC2, RC4, RC5.

2.2.12.5. Obsługę zabezpieczenia kryptograficznego sygnalizacji protokołu SIP w oparciu o:

2.2.12.5.1. Szyfrowanie połączeń w zakresie sygnalizacji za pomocą TLS

1.3 (Transport Layer Security). 2.2.12.5.2. Generację kluczy przez OpenSSL.

2.2.12.5.3. Obsługę standardów podpisów XX0, XX0, XXX0, XXX-000, XXX, XXX-0, XXX-000, XXX-000, XXX-000, XXX-000.

2.2.12.5.4. Obsługę standardów kodowania i szyfrowania: kodowanie Base64, Blowfish, CAST, CAST5, DES, Triple-DES, IDEA, RC2, RC4, RC5.

2.2.12.6. Obsługa bezpiecznego dostępu administracyjnego w oparciu o: 2.2.12.6.1. Bezpieczny dostęp administracyjny przez przeglądarkę przy

użyciu protokołu HTTPS.

2.2.12.6.2. Bezpieczny dostęp administracyjny i przesyłanie plików dzięki użyciu protokołu Secure Shell (SSH2).

2.2.12.6.3. Bezpieczne zarządzanie oprogramowaniem przez wsparcie protokołu sFTP umożliwia bezpieczną dystrybucję oprogramowania.

2.2.13. SIP Proxy musi być objęte wspólnym graficznym zarządzaniem za pomocą interfejsu www z systemem Softswitch w zakresie minimum:

2.2.13.1. Wsparcia dla bram łączy PSTN.

2.2.13.2. Wsparcie pracy z serwerem Softswitch w trybach z redundancją serwerów sterujących w jednym Data Center, Data Center rozdzielonych w warstwie L2, Data Center rozdzielonych w warstwie L3.

2.2.14. Oferowane modele rozwiązania SIP Proxy muszą realizować funkcje:

2.2.14.1. Zarządzania graficznego za pomocą centralnego interfejsu www wspólnego z systemem Softswitch zabezpieczonego przez https.

2.2.14.2. Zarządzana graficznego za pomocą centralnego lokalnego dostępu www zabezpieczonego przez https.

2.2.14.3. Wsparcia dla SNMP V2.

2.2.14.4. Wsparcia centralnego zbierania logów systemowych z systemem Softswitch.

2.2.14.5. Wsparcia centralnej realizacji funkcji kopi zapasowych i odtwarzania z systemem Softswitch.

2.2.14.6. Wsparcia funkcji instalacji oprogramowania w trybach: 2.2.14.6.1. Instalacja uproszczona (tryb kreatora), 2.2.14.6.2. Instalacja pełna (tryb ekspercki),

2.2.14.6.3. Modernizacja (nowa wersja oprogramowania), 2.2.14.6.4. Aktualizacja (poprawki usuwające błędy),

2.2.14.7. Wsparcia dla profili dostępu administracyjnego użytkowników.

2.2.15. System zapewnia redundancję pary serwerów SIP Proxy obsługujących rejestracje SIP dla abonentów oddziału, pracujących w trybie aktywny-zapasowy. Systemy wymieniają informację o aktywnych rejestracjach za pośrednictwem interfejsu LAN.

2.2.16. SIP Proxy musi lokalnie obsługiwać funkcję zapowiedzi w celu ograniczenia użycia łączy WAN.

2.2.17. SIP Proxy musi zapewniać funkcję automatycznego stanowiska awizo dla połączeń przychodzących, z możliwością tworzenia indywidualnych zapowiedzi:

2.2.17.1. SIP Proxy musi zapewniać obsługę co najmniej 4 jednoczesnych połączeń z indywidualnymi zapowiedziami.

2.2.17.2. SIP Proxy musi zapewniać funkcję wgrania lub usunięcia zapowiedzi jako plik wav.

2.2.17.3. SIP Proxy musi zapewniać funkcję nagrania zapowiedzi przez telefon po podaniu kodu.

2.2.17.4. SIP Proxy musi zapewniać obsługę wielu scenariuszy każdy z osobną nazwą.

2.2.18. Dla każdego scenariusza SIP Proxy zapewnia funkcję przypisania osobnych zapowiedzi w sytuacji: przywitanie, prośba o wybór klienta kodem DTMF, informacja w przypadku niepoprawnego wyboru, pożegnanie.

2.2.19. Scenariusze muszą być aktywowane i dezaktywowane automatycznie na podstawie dnia tygodnia i godziny gdy mają być aktywne.

2.2.20. Za pomocą interfejsu graficznego terminala administracyjnego, musi być obsługiwane ręczne - aktywowanie i dezaktywowanie scenariusza.

2.2.21. Za pomocą kodu DTMF musi być obsługiwane ręczne aktywowanie i dezaktywowanie scenariusza.

2.2.22. Dla każdego scenariusza musi być obsługiwany domyślny cel przekierowania (numer awizo, działu lub sekretariatu) osobny.

2.2.23. Domyślny cel przekierowania musi być obsługiwany zarówno, jako numer wewnętrzny w systemie jak również numer zewnętrzny w tym gsm.

2.2.24. SIP Proxy musi zapewniać zarządzanie ruchem Quality of Service (QoS) wspierając standard Differentiated Services Code Point (DSCP) dla różnych typów ruchu, w tym sygnalizacja, treść połączeń, czy zarządzanie.

2.2.25. SIP Proxy musi zapewniać podstawowe usługi i funkcje usług aplikacji sieciowych:

2.2.25.1. Realizacja funkcji DNS w trybie serwera dla klientów w oddziale.

2.2.25.2. Wsparcie dla NTP konfiguracja z zapewnieniem lokalnego źródła czasu NTP, bądź z synchronizacją do zewnętrznego źródła czasu NTP w data center, aby zapewniać dostęp do usługi NTP klientom po stronie dostępowej.

2.2.25.3. Realizacja funkcji lokalnego serwera DHCP dla klientów w oddziale.

2.2.25.4. Realizacja funkcji lokalnego repozytorium plików oprogramowania sterującego dla aparatów sprzętowych w oddziale.

2.2.26. SIP Proxy musi być dostępne zarówno, jako czyste oprogramowanie w tym do implementacji w środowisku wirtualizacyjnym, jak również, jako zintegrowane rozwiązanie sprzętowo-programowe (appliance).

2.2.27. Oferowane modele rozwiązania SIP Proxy muszą pochodzić od producenta systemu Softswitch.

2.2.28. W celu zapewnienia komunikacji z różnymi centralami sąsiedzkimi oraz sieciami operatorów SIP Proxy musi posiadać wersje appliance wyposażone w sprzętowe moduły bram, które umożliwiają konwersję sygnału głosowego z postaci IP na TDM i odwrotnie. Dostępne są minimum następujące modele obsługujące styki:

2.2.28.1. XXXX 00XxX,

2.2.28.2. ISDN 2B+D,

2.2.28.3. FXO/FXS,

2.2.28.4. SIP.

2.2.29. System musi realizować integrację z posiadanym przez Zamawiającego podsystemem telekomunikacyjnym TDM/VOIP umożliwiającą minimum przeniesienie w obie strony następujących usług:

2.2.29.1. Prezentacja numeru abonenta dzwoniącego - CLIP oraz blokada prezentacji numeru abonenta dzwoniącego- CLIR (Calling Line Identification Presentation/Restriction).

2.2.29.2. Prezentacja numeru abonenta, z którym jest zestawione połączenie - COLP oraz blokada numeru abonenta, z którym jest zestawione połączenie - COLR (Connected Line Identification Presentation/ Restriction).

2.2.29.3. Prezentacja nazwy abonenta dzwoniącego - CNIP oraz blokada nazwy abonenta dzwoniącego - CNIR (Calling Name Identification Presentation/Restriction).

2.2.29.4. Prezentacja nazwy abonenta, z którym jest zestawione połączenie - CNOP oraz blokada nazwy abonenta, z którym jest zestawione połączenie - CNOR (Connected Name Identification Presentation/Restriction).

2.2.29.5. Przekierowanie wszystkich połączeń – CFU (Call Forward Unconditional).

2.2.29.6. Przekierowanie przy zajętości – CFB (Call Forward on Busy).

2.2.29.7. Przekierowanie w przypadku nie odbierania - CFNR (Call Forward on No Reply).

2.2.29.8. Przekazywanie połączeń “ślepe” (Blind Transfer).

2.2.29.9. Przekazywanie połączeń bez konsultacji (Semi-attended Transfer).

2.2.29.10. Przekazywanie połączeń z konsultacją (Attended Transfer).

2.2.29.11. Oddzwonienie przy zajętości – CCBS (Call Completion on Busy Subscriber).

2.2.29.12. Grupa Pick up.

2.2.30. System musi posiadać modele SIP Proxy pochodzące od producenta systemu i objęte wspólnym z nim zarządzaniem:

2.2.30.1. skalowane w pojedynczej jednostce do obsługi min 1000 rejestracji SIP za pomocą jedynie dokupowania odpowiednich licencji,

2.2.30.2. skalowane w pojedynczej jednostce do obsługi min 250 rejestracji SIP za pomocą jedynie dokupowania odpowiednich licencji.

2.2.31. System musi realizować funkcjonalności w odniesieniu do funkcjonalności posiadanych w podsystemie VOIP/Softwitch obecnego środowiska telekomunikacyjnego Zamawiającego:

2.2.31.1. wsparcia dla oprogramowania komponentu zapewniającego bezpieczną komunikację w sieci Internet – SBC (Sesion Border Controler).

2.2.31.2. licencjonowanie kanału komunikacyjnego SBC per aktywna sesję komunikacyjna dla terminala SIP oraz dla kanału łącza SIP-Trunk w ramach jednej uniwersalnej puli / pakietu licencji.

2.2.31.3. wspólne zarządzanie podsystemu VOIP Softswitch oraz SBC oraz bram TDM (łącza i abonenci) oraz komponentów proxy (abonenci).

2.2.31.4. wprowadzenia wsparcia dla oprogramowania typu softphone na urządzenia mobilne z OS Android oraz iOS.

2.2.31.5. wprowadzenia wsparcia dla nowego oprogramowania typu softphone (OSDC) na stacje robocze z OS Windows.

2.2.31.6. wsparcie dla zastosowań aplikacji Contact Center wraz z komponentem typu IVR – aplikacji zintegrowanego oprogramowania.

2.2.31.7. wsparcie dla nagrywania rozmów w środowisku VoIP z zastosowaniem trybu aktywnego (nie poprzez tzw. Span port / port mirroring przełącznika sieciowego ethernet) – bezpośrednio z terminala.

3. Funkcjonalności Systemu Telekomunikacyjnego – Podsystem FAXServer

3.1. Zamawiający posiada Podsystem FAXServer, będący jednym z elementów środowiska telekomunikacyjnego Zamawiającego, opisanego w rozdziale VII. Dodatek Nr 1 - Środowisko telekomunikacyjne Zamawiającego, o funkcjonalnościach opisanych poniżej i oczekuje zachowania tych funkcjonalności po uruchomieniu nowych funkcjonalności środowiska telekomunikacyjnego.

3.2. Funkcjonalności FAXserwer:

3.2.1. Podłączenie do centrali telefonicznej musi być zrealizowane za pomocą łączy VoIP.

3.2.2. Integracja z centralą telefoniczną Zamawiającego za pomocy łącza VoIP musi umożliwiać zastosowanie protokołu T.38 dla obsługi wywołań faksowych.

3.2.3. Architektura rozwiązania oraz jego oprogramowanie musi umożliwiać implementację rozwiązania w oparciu o serwer maszyn wirtualnych VMWare ESX/ESXi.

3.2.4. Liczba użytkowników systemu faks serwera możliwych do wygenerowania, powinna wynosić co najmniej 100.

3.2.5. Faks serwer musi mieć możliwość jednoczesnego odbierania/wysyłania wiadomości faksowych przez minimum 30-u użytkowników.

3.2.6. System musi integrować się z dowolnym systemem e-mailowym, a w szczególności z Microsoft Outlook, będącym w posiadaniu Zamawiającego (musi pozwalać na co najmniej wysyłanie i odbieranie faksów z poziomu programu Outlook). Usługa musi być dostępna dla wszystkich użytkowników faks serwera.

3.2.7. System faks serwerowy musi mieć możliwość wysyłania faksów za pomocą przeglądarki internetowej. Usługa musi być dostępna dla wszystkich użytkowników faks serwera.

3.2.8. System faks serwerowy musi integrować się z oprogramowaniem pakietu Microsoft Office, będącym w posiadaniu Zamawiającego, a w szczególności z Microsoft Word (realizować co najmniej funkcję wysyłania faksów z poziomu dokumentu programu). Usługa musi być dostępna dla wszystkich użytkowników faks serwera.

3.2.9. System faks serwerowy musi informować o pojawieniu się w skrzynce nowej wiadomości fax za pomocą dedykowanego przycisku aparatu systemowego podłączonego do centrali oraz za pomocą wiadomości e-mail. Usługa musi być dostępna dla wszystkich użytkowników faks serwera.

3.2.10. System faks serwerowy musi ofertować możliwość archiwizacji faksów przychodzących i wychodzących.

3.2.11. System faks serwerowy musi posiadać możliwość przekazywania faksów za pomocą telefonu systemowego na skrzynkę innego użytkownika systemu

3.2.12. System faks serwerowy musi oferować funkcjonalność FAX-ON-DEMAND, czyli za pomocą połączenia telefonicznego po autoryzacji użytkownika w systemie kodem PIN przekazuje żądanie wysłanie faksu pod wskazany kodem DTMF, numer abonencki.

3.2.13. System faks serwerowy musi umożliwiać ograniczenie ruchu wychodzącego poprzez uprawnienia dla użytkownika – połączenia lokalne, krajowe, międzynarodowe

3.2.14. System faks serwerowy musi być kompletny, posiadać wszystkie niezbędne elementy sprzętowe i programowe/licencyjne.

3.2.15. System faks serwerowy musi mieć możliwość rozbudowy o dodatkowych użytkowników poczty faksowej do wymaganej ilości minimum 2000 użytkowników.

3.2.16. System fax serwerowy musi mieć możliwość zwiększenia jednoczesnej ilości realizowanych połączeń faksowych poprzez zwiększenie ilości kanałów VoIP serwera poczty faksowej.

3.2.17. System fax serwerowy, po zwiększeniu kanałów VoIP serwera poczty faksowej, musi mieć możliwość zwiększenia ilości jednoczesnych połączeń do minimum 60.

3.3. Funkcjonalności poczty głosowej:

3.3.1. System musi posiadać integralny podsystem poczty głosowej dla takiej samej ilości użytkowników jak dla poczty faksowej.

3.3.2. System poczty głosowej musi posiadać możliwość jednoczesnego odsłuchiwania nagrywanych wiadomości głosowych dla min 30 użytkowników.

3.3.3. Użytkownik poczty głosowej powinien mieć możliwość dysponowania uniwersalną skrzynką wiadomości zawierającą wiadomości faks oraz wiadomości głosowe.

3.3.4. System poczty głosowej musi informować, o pojawieniu się w skrzynce nowej wiadomości głosowej, za pomocą dedykowanego przycisku aparatu systemowego oraz za pomocą wiadomości e-mail, dla wszystkich użytkowników serwera poczty.

3.3.5. System poczty głosowej musi mieć możliwość odsłuchu wiadomości głosowej za pomocą aparatu systemowego, analogowego, VoIP, GSM dla wszystkich użytkowników serwera poczty głosowej

3.3.6. System poczty głosowej musi udostępniać indywidualne zapowiedzi skrzynki głosowej – powitanie, informacja o nieobecności, zastępstwie dla wszystkich użytkowników serwera poczty głosowej.

3.3.7. System poczty głosowej musi integrować się z dowolnym systemem e-mailowym, a w szczególności z Microsoft Outlook (musi realizować co najmniej odsłuchiwanie wiadomości z poziomu programu Outlook) dla wszystkich użytkowników serwera poczty głosowej.

3.3.8. System poczty głosowej musi posiadać możliwość odbioru wiadomości głosowej za pomocą przeglądarki internetowej, dla wszystkich użytkowników serwera poczty głosowej.

4. Funkcjonalności Systemu Telekomunikacyjnego – Centralny podsystem taryfikacji

4.1. Moduł kolekcji danych, rozumiany jako narzędzie pozwalające na stworzenie cennika operatora, celem utworzenia pliku z danymi o stawkach operatorów telekomunikacyjnych, który następnie można zaimportować do systemu taryfikacji, musi posiadać następujące funkcjonalności:

4.1.1. import danych CDR (pobieranie danych za pomocą odpowiednich protokołów komunikacyjnych zgodnych i zalecanych przez producenta centrali),

4.1.2. import danych o liniach wewnętrznych,

4.1.3. import danych dla struktur organizacyjnych (pobieranie danych o abonentach i synchronizacja via CTI z centralami telefonicznymi, pobieranie danych i synchronizacja z ACTIVE DIRECTORY/LDAP),

4.1.4. import danych dla numeracji traktów,

4.1.5. import danych o stawkach operatorów telekomunikacyjnych,

4.1.6. możliwość komunikacji z centralami telefonicznymi via CTI (funkcja umożliwiająca kontrolę statusu uprawnień dla linii/abonenta i możliwość zmiany tej kategorii – wykorzystywane przy funkcjonalności blokowania linii wewnętrznych po przekroczeniu zadanego limitu),

4.1.7. rejestrowanie całości ruchu telefonicznego, połączenia wychodzące, przychodzące oraz wewnętrzne z centrali.

4.2. Moduł przetwarzania danych musi posiadać następujące procesy i funkcjonalności:

4.2.1. proces przetwarzania danych CDR i innych danych zbieranych w procesie kolekcji danych,

4.2.2. archiwizację i dearchiwizację danych (wykonywaną według ustalonego harmonogramu),

4.2.3. wykonywanie kopii bezpieczeństwa danych (wykonywana według ustalonego harmonogramu).

4.3. System taryfikacyjny musi pracować w oparciu o system operacyjny Microsoft Serwer w wersji nie starczej niż 2012 oraz w oparciu o system bazodanowy MS SQL Serwer nie starszy niż 2012.

4.4. System taryfikacyjny musi być zainstalowany w środowisku wirtualnym i być kompatybilny z rozwiązaniami VMWare oraz HyperV.

4.5. System taryfikacyjny musi pracować jako usługa systemowa, cały proces przetwarzania oraz wszystkie obliczenia są wykonywane przez serwer, aplikacje klienckie służą jedynie do zmian konfiguracji i uruchamiania procesów.

4.6. System taryfikacyjny powinien być oparty na otwartej architekturze rozwiązania dającej możliwość taryfikowania danych dostarczonych od operatorów komórkowych.

4.7. System taryfikacyjny musi umożliwiać tworzenie dowolnej liczby planów taryfikacyjnych z uwzględnieniem darmowych minut oraz rabatów, również uwzględniających zmienny koszt jednostki taryfikacyjnej.

4.8. System taryfikacyjny musi posiadać funkcjonalność pozwalającą na sprawdzenie procesu taryfikacji krok po kroku (diagnostyka procesu taryfikacji).

4.9. System taryfikacyjny musi umożliwiać tworzenie niezależnych struktur organizacyjnych (widoków) grupujących poszczególne typy linii (wewnętrzne/miejskie) i kodów oraz automatyczne tworzenie i synchronizacja struktur na podstawie danych z AD oraz zewnętrznych plików i baz danych, wraz z mechanizmem pozwalającym dowolnie mapować poszczególne parametry, aby możliwe było dopasowanie konfiguracji do dostępnych danych.

4.10. System taryfikacyjny musi zapewniać automatyczne informowanie o stanie systemu via email (stany awaryjne oraz okresowe informacje o poprawności działania systemu) w szczególności:

4.10.1. analizę ilości zarejestrowanych błędnych rekordów w stosunku do poprawnych,

4.10.2. ilości miejsca na dysku,

4.10.3. wielkości bazy danych.

4.11. Moduł prezentacji danych musi udostępniać dane w postaci bilingów i statystyk dla użytkowników końcowych, poprzez:

4.11.1. interfejs użytkownika aplikacji desktopowej,

4.11.2. interfejs użytkownika aplikacji dostępnej,

4.11.3. interfejs przeglądarki www,

4.11.4. dostęp do zdefiniowanych raportów wysyłanych za pomocą poczty email.

4.12. System taryfikacyjny musi umożliwiać dostęp do raportów i analiz całego ruchu telefonicznego w tym również kontrolę kosztów dowolnej jednostki organizacyjnej.

4.13. System taryfikacyjny musi umożliwiać stworzenie kompletnej struktury organizacyjnej, która odzwierciedli rzeczywistą strukturę organizacyjną klienta w tym podział na jednostki, biura itp. Na podstawie tej struktury moduł musi generować raporty i analizy kosztów połączeń telefonicznych.

4.14. Centralny podsystem taryfikacyjny Zamawiającego w ramach modułu Billing Online (eksportu danych taryfikacyjnych na wskazaną stronę www) musi posiadać następujące funkcjonalności:

4.14.1. nawiązywanie połączenia i pobieranie danych taryfikacyjnych z bazy MS SQL,

4.14.2. zdalny dostęp i przeglądanie billingów tylko za pomocą przeglądarki internetowej,

4.14.3. możliwość tworzenia spersonalizowanych kont użytkownika,

4.14.4. możliwość zalogowania jednocześnie wielu użytkowników o różnych uprawnieniach,

4.14.5. możliwość filtrowania danych taryfikacyjnych po strukturze organizacji,

4.15. możliwość tworzenia indywidualnych raportów użytkownika grupujących informacje według kryteriów:

4.15.1. daty i godziny połączenia,

4.15.2. numeru wybieranego lub/i odbieranego,

4.15.3. stref połączenia, rodzaju połączenia, skutku połączenia,

4.15.4. czasu i kosztu rozmowy,

4.15.5. połączenia z danym numerem.

4.16. Centralny podsystem taryfikacji Zamawiającego w ramach modułu Billing Online musi umożliwiać generowanie bilingów, gdzie pod pojęciem bilingu rozumie się zestawienie danych w postaci tabeli liczbowej wraz z podsumowaniem. Moduł Biling Online musi realizować następujące rodzaje bilingów:

4.16.1. Biling szczegółowy kosztów połączeń dla zdefiniowanej linii lub wybranej części struktury

4.16.2. Biling podsumowujący koszty i ilości połączeń dla zdefiniowanej linii lub wybranej części struktury

4.16.3. Biling podsumowujący z podziałem na strukturę organizacyjną i linie znajdujące się w tej części struktury w jednym raporcie

4.16.4. Biling podsumowujący koszty i ilości połączeń dla struktury organizacyjnej

4.16.5. Biling połączeń ekstremalnych w ujęciu kosztów i czasu trwania, gdzie ukazywane dane są odpowiednio posortowane.

4.17. Centralny podsystem taryfikacji Zamawiającego w ramach modułu Billing Online musi umożliwiać generowanie statystyk, gdzie pod pojęciem statystyki rozumie się zestawienie danych w postaci tabeli liczbowej wraz z podsumowaniem oraz zestawienie danych w postaci graficznej (dane graficzne rozumiane jako interpretacja danych zawartych w tabeli). Dostępne statystyki:

4.17.1. Statystyka dla stref ukazująca rozkład połączeń telefonicznych z podziałem na strefy w ujęciu kosztowym i ilościowym.

4.17.2. Statystyka zajętości łączy ukazująca jaki jest poziom obciążenia traktów połączeniami telefonicznymi w różnych godzinach doby. Statystyka musi mieć możliwość pokazywania danych dla jednego, lub wielu traktów jednocześnie.

4.17.3. Wymienione wyżej raporty i statystyki mają możliwość wydruku oraz zapisu do postaci: PDF, XLSX, CSV.

4.18. Dostęp do danych i ich zakresów musi być indywidualnie definiowany dla każdego użytkownika w postaci uprawnień dla konta dostępowego, gdzie określany jest::

4.18.1. Zakres linii i abonentów widoczny dla danego użytkownika,

4.18.2. Zakres możliwych zmian przyporządkowania linii i abonentów dla zdefiniowanej części struktury w tym zmian: opisów linii, opisów elementów struktury, ich dodawanie i usuwanie, przenoszenie abonentów.

4.18.3. Całość tych zmian musi być widoczna na poziomie centralnego administratora.

4.18.4. Zakres szablonów raportów i statystyk widoczny dla danej jednostki.

4.19. Centralny podsystem taryfikacji Zamawiającego w ramach modułu Billing Online umożliwia stworzenie kont użytkowników o różnych rolach w tym:

4.19.1. Roli Pracownik - użytkownik o tej roli musi posiadać dostęp do danych bilingowych tylko dla swojej linii wewnętrznej. Użytkownik o tej roli będzie miał dostęp do własnego bilingu szczegółowego wraz z zestawem filtrów.

4.19.2. Roli Kierownik - użytkownik o tej roli musi posiadać dostęp do danych bilingowych linii wewnętrznych w ramach swojego działu. Użytkownik o tej roli musi posiadać dostęp do bilingów szczegółowych, podsumowujących oraz do analiz ruchu przychodzącego w ramach swoich uprawnień. Bilingi i analizy dostępne wraz z zestawem filtrów, mieć możliwość tworzenia własnych szablonów raportów na bazie dostępnych bilingów i analiz gdzie stworzony przez użytkownika szablon raportu będzie się zapisywał do zdefiniowanej przez niego nazwy w oddzielnej zakładce

„Moje Raporty”.

4.19.3. Roli Operator - użytkownik o tej roli musi posiadać dostęp do danych bilingowych linii wewnętrznych w ramach części struktury organizacyjnej, do której zostaną mu przydzielone uprawnienia. Użytkownik o tej roli musi posiadać dostęp do bilingów szczegółowych, podsumowujących oraz do analiz ruchu przychodzącego w ramach swoich uprawnień. Bilingi i analizy dostępne wraz z zestawem filtrów, mieć możliwość tworzenia własnych szablonów raportów na bazie dostępnych bilingów i analiz gdzie stworzony przez użytkownika szablon raportu będzie się zapisywał zdefiniowaną przez niego nazwą w oddzielnej zakładce Moje Raporty.

4.19.4. Dodatkowo użytkownik o tych uprawnieniach musi posiadać możliwość edycji i zarządzania zmianami przyporządkowania linii i abonentów dla zdefiniowanej części struktury w tym zmian: opisów linii, opisów elementów struktury, ich dodawanie i usuwanie, przenoszenie abonentów.

4.20. System taryfikacyjny musi umożliwiać wysyłanie zdefiniowanych wcześniej raportów drogą email do zdefiniowanych osób (według ustalonego harmonogramu).

4.21. System taryfikacyjny musi umożliwiać logowanie do systemu zintegrowane z domeną (SSO).

4.22. W ramach Centralnego podsystemu taryfikacyjnego Zamawiającego moduł Kolektor (gromadzący dane taryfikacyjne) musi posiadać następujące funkcjonalności:

4.22.1. pobieranie i gromadzenie rekordów taryfikacyjnych z centrali za pomocą sieci IP,

4.22.2. zapisanie pobranych danych z centrali w postaci plików tekstowych na dysk,

4.22.3. możliwość ustawienia harmonogramu pobierania danych taryfikacyjnych z centrali, konfiguracja parametrów buforów taryfikacyjnych.

4.23. Centralny podsystem taryfikacji musi funkcjonować w oparciu o istniejąca platformę wirtualną (lub nową platformę dostarczona przez Zamawiającego) i bazę SQL Windows Serwer 2008R2 Standard.

4.24. Centralny system taryfikacji musi posiadać mechanizmy limitowania kwotowego tj. blokowania polegającego na „wyłączeniu” uprawnień „wyjścia na miasto” na dowolnej wewnętrznej linii abonenckiej, po przekroczeniu zdefiniowanego limitu kwotowego w jednym z dwóch podsystemów telekomunikacyjnych. Mechanizm blokowania linii musi zapewnić możliwość założenia limitu kwotowego dla minimum 350 linii wewnętrznych.

4.25. Wykonawca dokona integracji Centralnego podsystemu taryfikacji z podsystemem telekomunikacyjnym TDM/VOIP za pomocą protokołu CSTA oraz z podsystemie telekomunikacyjnym VOIP za pomocą protokołów PRE-PAID WEB i SOAP.

4.26. Centralny podsystem taryfikacji musi być skonfigurowany w trybie automatyzacji zadań w zakresie:

4.26.1. automatycznej wysyłki zdefiniowanych raportów do zdefiniowanych użytkowników (adresów email),

4.26.2. automatycznej wysyłki raportów o nieprawidłowym działaniu systemu do administratorów systemu,

4.26.3. automatycznego pobierania CDR i ich taryfikacji,

4.26.4. automatycznej i cyklicznej archiwizacji danych oraz przygotowania kopii bezpieczeństwa na zewnętrznych urządzeniach backupowych (udostępnionych przez Zamawiającego), skonfigurowanych według następujących kryteriów (interwałów czasowych): po każdym zakończonym kwartale baza bieżąca musi zostać przeniesiona do archiwum podręcznego, kopia bezpieczeństwa wykonywana cyklicznie przez Zamawiającego.

4.26.5. automatycznego i cyklicznego (tj. z interwałem co miesięcznym) generowania raportów bilingowych w formacie pdf, z modułu Biling Online na podstawie posiadanej przez Zamawiającego struktury abonentów w podsystemie taryfikacji.

4.27. Centralny podsystem taryfikacji musi posiadać możliwość personalizacji szaty graficznej raportów bilingowych systemu taryfikacji w szacie graficznej modułu Biling'u Online.

4.28. Centralny podsystem taryfikacji musi umożliwiać umieszczenie w raportach bilingowych dowolnego logo dostarczonego przez Zamawiającego.

5. Funkcjonalności Systemu Telekomunikacyjnego - Centralny podsystem zarządzania telefonami

5.1. Centralny podsystem zarządzania terminalami systemowymi IP musi być zintegrowany programowo (za pomocą API) z aplikacją zarządzającą systemu softswitch minimum w zakresie wymiany danych i szablonów abonenta.

5.2. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość zarządzania terminalami końcowymi IP (obsługując zarówno protokół standardowy SIP jak i firmowy HFA).

5.3. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać automatyczne wyszukiwanie i monitorowanie terminali IP (Zamawiającego) w sieci korporacyjnej w zakresie wszystkich rodzajów terminali systemowych IP Systemu Telekomunikacyjnego Zamawiającego.

5.4. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość zdalnej aktualizacji oprogramowania terminali IP (funkcja Plug & Play),

5.5. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość archiwizacji i przenoszenia konfiguracji na inny terminal IP typu:

5.5.1. dane logowania do sieci,

5.5.2. układ klawiszy,

5.5.3. książka telefoniczna,

5.5.4. lista połączeń,

5.6. 454Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość definiowania gotowych szablonów (template’ów) do zdalnej konfiguracji terminali IP na podstawie:

5.6.1. wstępnie zaprogramowanego aparatu użytkownika wzorcowego,

5.6.2. ustawień administracyjnych,

5.7. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość definiowania gotowych szablonów (template’ów) do zdalnej konfiguracji terminali IP i stosowania ich tylko w ograniczonym zakresie w szczególności:

5.7.1. zmiany standardu zaprogramowania klawiszy,

5.7.2. zmiany ustawień czasu,

5.7.3. zmiany ustawień szyfrowania,

5.7.4. dystrybucji kluczy do szyfrowania,

5.7.5. uaktualnienia oprogramowania aparatu dla wybranej grupy użytkowników minimum 50 osób w jednym zadaniu,

5.8. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość zlecenia (zaplanowania) zadań rekonfiguracji aparatów IP na określone godziny i pory dnia.

5.9. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość masowej aktualizacji oprogramowania terminali IP

5.10. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać możliwość masowego wdrożenia terminali IP za pomocą wskazania użytkownika przez podanie numeru telefonu i przypisanie zaprogramowanych wcześniej w systemie ustawień użytkownika.

5.11. Centralny system zarządzania terminalami systemowymi IP musi zapewniać możliwość masowego wdrożenia za pomocą wskazania użytkownika przez podanie adresu sprzętowego telefonu (MAC Adres) i przypisanie zaprogramowanych wcześniej w systemie ustawień użytkownika.

5.12. Centralny podsystem zarządzania terminalami systemowymi IP musi zapewniać raportowanie wykonania masowych działań z dokładnością do wskazania na których aparatach akcja została wykonana pomyślnie a na których niepomyślnie.

5.13. Centralny podsystem zarządzania terminalami systemowymi TDM musi zapewniać możliwość zdalnego przejęcia terminala systemowego TDM i realizowania na nim wszystkich czynności (za pośrednictwem zdalnej konsoli administratora), tożsamych z ręcznym sterowaniem terminalem, wybieraniem numerów, programowaniem klawiszy funkcyjnych, przeglądaniem zawartości pamięci terminala, podglądzie bieżących działań na wyświetlaczu terminala w zdalnej konsoli administratora.

5.14. Centralny podsystem zarządzania telefonami, w przypadku terminali IP musi pochodzić od producenta podsystemu telekomunikacyjnego VOIP softswitch, natomiast w przypadku terminali TDM musi pochodzić o producenta podsystemu telekomunikacyjnego TDM/VOIP.

Część C - Funkcjonalności Systemu Telekomunikacyjnego – instruktaże stanowiskowe i dokumentacja

1. Instruktaże stanowiskowe

1.1. Wykonawca dokona instruktaży stanowiskowych dla minimum 3 administratorów Systemu Telekomunikacyjnego w zakresie eksploatacji, realizacji usług, posiadanych funkcjonalności, administracji oraz realizacji procedur związanych z aktualizacjami Systemu Telekomunikacyjnego.

1.2. Łączny czas trwania instruktaży stanowiskowych nie może być krótszy niż 5 dni roboczych.

1.3. Wszystkie instruktaże stanowiskowe muszą być prowadzone na podstawie autoryzowanych materiałów producentów Systemu Telekomunikacyjnego, w języku polskim przez osoby posiadające udokumentowane doświadczenie oraz zostaną będą się kończyć wydaniem imiennych certyfikatów potwierdzających zdobycie umiejętności.

1.4. Wykonawca, do przeprowadzenia instruktaży stanowiskowych, musi zapewniać:

1.4.1. materiały niezbędne, w języku polskim w formie elektronicznej, odpowiadające zakresem danej funkcjonalności Systemu,

1.4.2. warunki zgodne z przepisami bezpieczeństwa i higieny pracy w trakcie trwania instruktażu stanowiskowego teoretycznego jak i praktycznego oraz odpowiednie wyposażenie (co najmniej stacje robocze, rzutnik),

1.4.3. pokrycie kosztów noclegów instruktorów, w przypadku instruktaży odbywających się poza miejscem pracy,

1.4.4. przeprowadzenie instruktaz˙u stanowiskowych dla kaz˙dego uczestnika przy oddzielnym komputerze.

1.5. Plan instruktażu lub wdrożenia stanowiskowego musi zostać przedstawiony przez Wykonawcę do akceptacji przez Zamawiającego na 7 Dni Kalendarzowych przed rozpoczęciem instruktażu lub wdrożenia stanowiskowego.

1.6. Wykonawca zobowiązany jest do przeprowadzenia instruktażu lub wdrożenia stanowiskowego zgodnie z zatwierdzonym przez Xxxxxxxxxxxxx planem.

1.7. Materiały, niezbędne do przeprowadzenia instruktażu lub wdrożenia stanowiskowego, muszą być zaakceptowane przez Zamawiającego.

1.8. Materiały, o których mowa powyżej muszą być przesłane w formie elektronicznej do akceptacji przez Zamawiającego w terminie nie późniejszym niż na 5 Dni Roboczych przed planowaną datą rozpoczęcia danego zakresu instruktażu lub wdrożenia stanowiskowego.

2. Dokumentacja.

2.1. Zamawiający w zakresie dostarczenia przez Wykonawcę dokumentacji Systemu Telekomunikacyjnego, wymaga:

2.1.1. dostarczenia dokumentacji powykonawczej oraz dokumentacji producenta dla wdrażanych funkcjonalności,

2.1.2. dostarczenia projektu funkcjonalnego, procedur utrzymaniowych oraz instrukcji obsługi dla administratorów Systemu Telekomunikacyjnego w języku polskim,

2.1.3. opisu implementacji rozwiązania, rozdysponowanie usług, konfiguracji systemów w podziale na poszczególne komponenty,

2.1.4. opisu funkcjonalności poszczególnych podsystemów.

2.1.5. opisu komunikatów o błędach,

2.1.6. opisu zasad administrowania systemami dla każdego komponentu składowego,

2.1.7. opisu zasad archiwizacji i bezpieczeństwa systemów, w tym opis procedur naprawczych mających na celu przywrócenie stanu normalnej pracy po wystąpieniu awarii,

2.1.8. opisu pozostałych innych, istotnych informacji, koniecznych do prawidłowego administrowania Systemem Telekomunikacyjnym.

2.2. Do opracowanej i dostarczonej przez Wykonawcę dokumentacji, Wykonawca udzieli Zamawiającemu licencji na czas nieoznaczony.

2.3. Dokumentacja Systemu Telekomunikacyjnego musi zostać przekazana w formie papierowej w liczbie dwóch egzemplarzy oraz w wersji elektronicznej w formacie PDF.

V. Dostawa i wdrożenie Systemu CC

1. Wymagania ogólne i techniczne

1.1. System CC ma realizować następujące grupy funkcjonalności:

1.1.1. CRM,

1.1.2. IVR,

1.1.3. Nagrywanie rozmów,

1.1.4. Logistyka,

1.1.5. Planowanie pracy,

1.1.6. Raporty,

1.1.7. Baza wiedzy,

1.1.8. Testy,

1.1.9. Aplikacja dla Mieszkańca,

1.1.10. Administrowanie Systemem CC.

1.2. Powyższe grupy funkcjonalności muszą integrować się ze sobą w zakresie funkcjonalnym i wymiany danych.

1.3. Wykonawca musi, na etapie Analizy przedwdrożeniowej, przedstawić szczegółowy plan i opis integracji powyższych grup funkcjonalności.

1.4. System CC musi być przygotowany do obsługi następujących kanałów kontaktu:

1.4.1. połączenie telefoniczne (przychodzące i wychodzące),

1.4.2. faks (przychodzący i wychodzący),

1.4.3. SMS (wychodzący),

1.4.4. poczta elektroniczna (wiadomość e-mail przychodząca i wychodząca),

1.4.5. chat (prowadzony poprzez Serwis WWW lub poprzez Aplikację dla Mieszkańca),

1.4.6. newsletter,

1.4.7. alert dotyczący problemów w przestrzeni publicznej (rejestrowany za pośrednictwem Aplikacji dla Xxxxxxxxxx),

1.4.8. formularz zgłoszeniowy.

1.5. System CC w całości musi być zainstalowany na serwerach Urzędu Miasta Lublin, z wyjątkiem zapisów SOPZ zawartych w rozdziale V pkt 2.6.3, rozwiązania oparte o przetwarzanie w chmurze wymagają każdorazowo testów i aprobat technicznych oraz akceptacji przez Wydział Informatyki i Telekomunikacji Urzędu Miasta Lublin.

1.6. Serwery wirtualne muszą pracować na platformie Vmware użytkowanej przez Zamawiającego. Zamawiający na potrzeby realizacji umowy udostępni posiadane środowisko Vmware.

1.7. System CC musi być zainstalowany na jednym z poniższych systemów operacyjnych, użytkowanych przez Zamawiającego:

1.7.1. Windows Server 2012 R2 Standard lub DataCenter,

1.7.2. Windows Server 2016 Standard lub DataCenter,

1.7.3. inny system operacyjny, do którego licencję dostarczy Wykonawca

Zamawiający na potrzeby realizacji umowy udostępni systemy operacyjne opisane w punktach 1.7.1. i 1.7.2.

1.8. Rozwiązanie musi być oparte na serwerze aplikacyjnym Użytkowanym przez Zamawiającego tj. Microsoft Internet Information Services wersje 7.5, 8.5, 10 lub Apache Tomcat wersje 7, 9.

1.9. System CC musi być oparty o bazy danych użytkowane przez Zamawiającego tj.: Oracle, Microsoft SQL Server, Postgres.

1.10. Usługi telekomunikacyjne u Zamawiającego są świadczone za pomocą czterech dostępów ISDN PRA (30B+D) z sygnalizacją DSS1, z usługą DDI oraz z gwarancją jakości na styku z wewnętrzną siecią teleinformatyczną Zamawiającego.

1.11. Architektura Systemu CC musi spełniać wymogi pro-konkurencyjnego kształtowania architektury systemów zawarte w Rekomendacji 5 (R.5.1, R.5.3, R.5.4) w dokumencie

„UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE

REKOMENDACJE” wydanym przez Urząd Zamówień Publicznych w 2009 r. dostępnym pod odnośnikiem:

xxxxx://xxx.xxx.xxx.xx/ data/assets/pdf_file/0025/27574/Rekomendacje_UZP20ws.

_zamowiec584_na_systemy_informatyczne.pdf

1.12. System CC musi zostać tak zaprojektowany i wdrożony aby zminimalizować wpływ awarii jednego z elementów na inne elementy, w szczególności w przypadku awarii IVR połączenia muszą być bezpośrednio kierowane do Systemu CC, awaria CRM nie może blokować odbierania połączeń telefonicznych.

1.13. Zamawiający na potrzeby realizacji umowy udostępni zasoby dyskowe/NAS w celu wykonywania kopii bezpieczeństwa

1.14. zSystem CC musi umożliwić skalowanie:

1.14.1. w wymiarze wertykalnym (w tym poprzez dodanie pamięci RAM na obecnych serwerach),

1.14.2. w wymiarze horyzontalnym (w tym poprzez dodanie nowych serwerów),

1.14.3. polegające na zwiększeniu liczby Użytkowników Systemu CC, w tym Konsultantów i Supervisorów wraz z zapewnieniem im wydajnej pracy.

1.15. Zamawiający udostępni przestrzeń dyskową niezbędną do przechowywania plików z zarejestrowanymi nagraniami rozmów.

1.16. System CC musi wykorzystywać system poczty elektronicznej Zimbra (posiadany przez Zamawiającego) mając do dyspozycji protokoły pop3, smtp, imap.

1.17. System CC musi się integrować z systemem WWW i CMS Edito w zakresie udostęp- nienia chat’u.

1.18. System CC musi się integrować z systemem WWW i CMS Edito w zakresie udostęp- nienia formularza zgłoszeniowego.

1.19. Zamawiający preferuje, aby dostarczone grupy funkcjonalności były skonstruowane w technologii trójwarstwowej, jednakże dopuszcza zastosowanie technologii dwuwar- stwowej.

1.20. Grupy funkcjonalności wdrażane przez Wykonawcę muszą być zbudowane zgodnie ze standardem MDI – Multi-Document Interface, co oznacza, że użytkownik musi mieć możliwość otwarcia jednocześnie kilku okien. To rozwiązanie ma pozwolić na równo- legły sposób wykonywania kilku zadań np. wyszukiwania i tworzenia raportu.

1.21. System musi zapewniać uzupełnianie lub selekcję danych przy pomocy słowników. Za- kresy słowników muszą mieć możliwość ich edytowania z poziomu uprawnień Admi- nistratora Biznesowego. Wybór wartości ze słownika musi być możliwy za pomocą przeszukiwania fragmentu wartości.

1.22. Dostarczone rozwiązania oparte o technologię webową musza być zabezpieczone przez protokół SSL/TLS zapewniający poufność i integralność transmisji danych oraz bezpie- czeństwo uwierzytelnienia. Zastosowane algorytmy szyfrowania (cipher suite) muszą zapewniać najwyższy poziom bezpieczeństwa.

1.23. Wykonawca musi wdrożyć środowisko testowo-szkoleniowe Systemu CC będące lo- gicznie oddzielone od części produkcyjnej w infrastrukturze Zamawiającego.

1.24. System CC musi umożliwić obsługę urządzeń końcowych Użytkowników Systemu CC opartych o system operacyjny Microsoft Windows w wersjach 7, 8, 8.1, 10.

1.25. System CC musi umożliwiać obsługę mobilnych urządzeń końcowych Użytkowników Systemu CC wyposażonych w system operacyjny co najmniej: Android, iOS.

1.26. System CC musi umożliwiać obsługę urządzeń końcowych Użytkowników Systemu CC wykorzystujących przeglądarki internetowe co najmniej: Mozilla Firefox, Google Chrome, Internet Explorer, Opera w bieżącej na dzień odbioru Przedmiotu zamówienia stabilnej wersji, dystrybuowanej przez producenta, bez konieczności instalacji wtyczek, apletów, dodatków do przeglądarek.

1.27. System CC nie może wymagać instalacji dodatkowego oprogramowania na urządze- niach końcowych Użytkowników Systemu CC, z wyjątkiem wskazanych w pkt. 2.1.19 w tabeli nr 1 „Wymagania wstępne” rozdziału nr 2 „Wymagania szczegółowe” w części V „DOSTAWA I WDROŻENIE SYSTEMU CC”.

1.28. Nie jest dopuszczalne, aby jakakolwiek funkcjonalność Systemu CC uruchamiana na urządzeniu końcowym Użytkownika Systemu CC (z wyjątkiem Administratora bizne- sowego i Administratora IT) wymagała dla jej wykonania uprawnień administracyj- nych.

1.29. System CC do poprawnej pracy nie może wymagać użycia klucza sprzętowego.

1.30. System CC musi zapewniać zarządzanie tożsamością, uwierzytelnianie i autoryzację Użytkowników Systemu CC, a dostęp do niego musi być zabezpieczony mechanizmami uwierzytelniania i autoryzacji bazującymi na środowisku Active Directory Zamawiają- cego.

1.31. System CC musi być zintegrowany ze środowiskiem Active Directory Zamawiającego w zakresie mechanizmów uwierzytelniania i autoryzacji.

1.32. Wszystkie grupy funkcjonalności Systemu CC muszą wykorzystywać mechanizm jed- nokrotnego logowania (SSO) w oparciu o Microsoft Active Directory, co oznacza, że mechanizm jednokrotnego logowania musi współpracować ze wszystkimi grupami funkcjonalności Systemu CC bez względu na technologię w jakiej są wykonane. Jedno- krotne logowanie musi być oparte o jeden z protokołów: WSFederation, SAML 2.0, OAUTH. Protokoły te muszą współpracować z infrastrukturą teleinformatyczną posia- daną przez Zamawiającego.

1.33. Zamawiający na potrzeby uwierzytelniania i autoryzacji Użytkowników Systemu CC udostępni wielodomenowe, hybrydowe środowisko oparte o usługi Active Directory Domain Services. Usługi Active Directory Domain Services będą realizowane w środo- wisku opartym na Windows Server 2016.

1.34. System CC musi umożliwiać lokalną obsługę Użytkowników Systemu CC co najmniej w zakresie:

1.34.1. kontroli czasu ważności konta/hasła,

1.34.2. kontroli jakości hasła (co najmniej: minimalnej długości, nietrywialności),

1.34.3. unikalności hasła (w ustalonym okresie czasu, np. 12 miesięcy),

1.34.4. wymuszanie zmiany hasła przez Użytkownika Systemu CC,

1.34.5. czasowe blokowanie konta po określonej ilości nieudanych logowań.

1.35. Narzędzia administracyjne muszą zapewniać zarządzanie Użytkownikami Systemu CC poprzez nadawanie i ograniczanie uprawnień w zakresie:

1.35.1. ustalania ról Użytkowników Systemu CC oraz administrowania tymi rolami,

1.35.2. wglądu do danych,

1.35.3. korzystania z określonych funkcji Systemu CC,

1.35.4. zasilania i aktualizacji danych,

1.35.5. grupowania Użytkowników Systemu CC (co najmniej: ze względu na zakres posiadanych uprawnień) i administrowania tymi grupami.

1.36. Narzędzia administracyjne muszą zapewniać zarządzenie konfiguracją Systemu CC po- przez:

1.36.1. zarządzanie słownikami - definiowanie i dodawanie nowego słownika do Sys- temu CC,

1.36.2. ustalanie konieczności wypełniania pól tabel danych, uznanych za wymagane,

1.36.3. zarządzanie terminem ważności konta w Systemie CC oraz czasem, po upływie którego zalogowany Użytkownik Systemu CC zostanie automatycznie wylogo- wany w przypadku braku aktywności w Systemie CC

1.37. Komunikacja przez Użytkowników Systemu CC z Systemem CC musi być szyfrowana (web aplikacje/panele użytkowników muszą korzystać z protokołu https i muszą być zabezpieczone certyfikatem z publicznego, zaufanego urzędu certyfikacji).

1.38. Aplikacja dla Mieszkańca musi zostać osadzona w użytkowanym w Urzędzie Miasta Lublin systemie CMS Edito, a komunikacja z nią musi być szyfrowana.

1.39. Obsługa chat nie może wymagać od klienta instalacji dodatkowego oprogramowania, osadzone na portalu skrypty mają być obsługiwane przez przeglądarki internetowe co najmniej Mozilla Firefox, Google Chrome, Internet Explorer, Opera w bieżącej na dzień odbioru Przedmiotu zamówienia stabilnej wersji, dystrybuowanej przez producenta.

formularz

zgłoszeniowy

Alert

chat

e-mail

fax

SMS (kierunek

wychodzący)

Połączenie głosowe

Aplikacja Mieszkańca / SIPL

Geoportal xxxxxxxxx.xxxxxx.xx

Web server + CMS

Edito

ZIMBRA (mail server)

Xxpression (fax server, fax to email)

Xxpression (sms server, sms to email)

PBX

SIPL Geoportal server

BIP Karty informacyjne UML

Active Directory

ESB

KSAT

MDOK

Linki do Bazy Wiedzy

Zwolnienia, urlopy

Odpowiedzi

Grafiki

Pytania

Planowanie pracy

Testy

Integracja z SIPL Geoportal

Notatki

Wybieranie numeru (w przypadku telefonu)

Ref do kart informacyjnych UML

Artykuły

FAQ

Podgląd zgłoszeń

Baza wiedzy

Obsługa kanałów (alert, formularz kontaktowy, chat)

Dashboard supervisora

Aplikacja dla Mieszkańca

Czas oczekiwania w kolejkach

Administrowanie systemem

Raportowanie

Informacja o dokumentach gotowych do odbioru

Integracja z WWW + CMS Edito (udostępnienie chat)

Logistyka

Integracja z WWW + CMS Edito

(udostępnienie formularza kontaktowego - link)

Wysyłka newslettera

Integracja z SIPL Geoportal

(wystawienie alertów, konsumowanie API map)

Baza newsletterowa

Integracja z KSAT i MDOK przez ESB

Newsletter

Integracja

podpowiadanie jaki jest następny krok w procesie

Eksportowanie

Procesy do implementacji

Odsłuchiwanie

Definiowanie procesów

Przeszukiwanie

Szablony odpowiedzi

Nagrywarka rozmów

Eksport (pdf, html)

Uwierzytelnienie (zestaw pytań)

Zgody

Text to speech

Chat control

IVR

CTI control (odbieranie, dzwonienie, transferowanie, form popup)

Książka telefoniczna

Kolejki (działań statycznych, zgłoszeń i zadań)

Chat server

Zadania

CTI server

Zgłoszenia (Alerty, Pytania, Problemy, Reklamacje)

Kolejki (głosowe i chat)

Działania interaktywne (rozmowa głosowa, chat)

Działania interaktywne (rozmowa głosowa, chat)

Działania statyczne (e-mail, fax, sms, kontakt z formularza zgłoszeniowego, )

Automatic Call Distribution

Kontakt (karta kontaktu)

Obsługa działań interaktywnych

Serwis WWW

SMS API

(kierunek wychodzący)

KANAŁY KONTAKTU

SYSTEMY LUB USŁUGI ZEWNĘTRZE

SYSTEMY WEWNĘTRZE UM

SYSTEM CONTACT CENTER

Mieszkaniec

Konsultant I linia

Panel konsultanta.

Panel

supervisora.

Panel testy

Panel Baza Wiedzy

Panel redaktora testów.

Panel redaktora bazy wiedzy.

Panel raportowy

Panel administra- cyjny biznesowy

Panel administra- cyjny IT

Panel administra- cyjny - Testy

Obsługa na urządzeniach mobilnych

(Android, iOS)

Obsługa na urządzeniach PC w przeglądarkach

Panel administra- cyjny -Baza Wiedzy

Konsultant II linia

Supervisor

Użytkownik Testów

Użytkownik Bazy Wiedzy

Użytkownik CRM (użytkownik CC)

Redaktor Testów

Redaktor bazy wiedzy

Administrator bazy wiedzy

Administrator Logistyki

Administrator Testów

Administrator

Biznesowy

Administrator IT

Schemat 3. Schemat funkcjonalny Systemu CC

2. Wymagania szczegółowe

2.1. Wymagania wstępne

Lp.	Opis wymagania
2.1.1.	System CC musi zostać uruchomiony w infrastrukturze serwerowej Zamawiającego, który przygotuje środowisko wirtualne we własnych zasobach serwerowych wraz możliwością osadzenia w nim baz danych. Niezbędne komponenty sprzętowe takie jak bramy, konwertery mediów czy narzędzia do rejestracji połączeń głosowych (nagrywania rozmów) będą kolokowane w Miejskim Centrum Przetwarzania Danych (MCPD) lub w Zapasowym Centrum Przetwarzania Danych (ZCPD) Zamawiającego. W przypadku konieczności kolokowania innych elementów infrastruktury Systemu CC wymagana jest zgoda oraz uzgodnienia z Wydziałem Informatyki i Telekomunikacji Zamawiającego.
2.1.2.	System CC musi spełniać rolę serwera CTI (Computer Telephony Integration).
2.1.3.	System CC musi wykorzystywać System Telekomunikacyjny Zamawiającego, a Wykonawca zapewni kompatybilność obu Systemów.
2.1.4.	Usługi serwera faksowego muszą być realizowane w środowisku Systemu Telekomunikacyjnego Zamawiającego. Faksy muszą być dostarczane do Systemu CC w postaci wiadomości e-mail.
2.1.5.	System CC musi obsługiwać Interfejs Programowania Aplikacji (API) komercyjnych platform dystrybucji SMS (zarówno dla wiadomości wychodzących, jak i przychodzących), w tym dla systemu SMSAPI lub SMS SERVER.
2.1.6.	System CC musi spełniać rolę serwera chat.
2.1.7.	System CC musi udostępniać kontrolkę chat komunikującą się z serwerem chat.
2.1.8.	System CC musi zapewniać obsługę działań interaktywnych (rozmowa głosowa, faks, SMS, wiadomość e-mail, chat, newsletter, alerty dotyczące problemów w przestrzeni publicznej, formularz zgłoszeniowy).
2.1.9.	System CC musi zapewniać funkcjonalność kolejek dla działań interaktywnych.
2.1.10.	System CC musi umożliwiać obsługę jednocześnie wielu numerów telefonicznych (w tym dostępowych), numerów faksów, brandingów SMS, adresów e-mail, kanałów chatów, kategorii newsletterów, rodzajów formularzy zgłoszeniowych.
2.1.11.	System CC musi obsługiwać minimum 155 jednocześnie zalogowanych do niego Użytkowników Systemu CC.
2.1.12.	System CC musi obsługiwać minimum 55 jednoczesnych połączeń telefonicznych (50 Konsultantów i 5 Supervisorów) z możliwością skalowania w przypadku jego rozbudowy o kolejnych Konsultantów i Supervisorów.
2.1.13.	System CC musi zapewniać równomierne obciążanie Konsultantów połączeniami telefonicznymi.
2.1.14.	System CC musi umożliwiać definiowanie procesów. Procesy muszą być definiowane zarówno jako procesy działające w tle (bez interakcji Użytkownika Systemu CC), jak również jako procesy wymagające interakcji z Użytkownikiem Systemu CC. System CC musi umożliwiać kontynuowanie procesu nawet wówczas, gdy Użytkownik Systemu CC opuści ekran.

2.1.15.	W Systemie CC musi być przygotowany jeden, ogólny, wspólny proces umożliwiający obsługę Zgłoszeń i Zadań, w tym: identyfikacja problemu (ewentualnie przekazanie Zgłoszenia i Zadania do dalszej obsługi), obsługa i zamknięcie Zgłoszenia i Zadania (ewentualnie powiadomienie Mieszkańca).
2.1.16.	System CC musi umożliwiać Administratorowi biznesowemu budowanie procesów bez wiedzy programistycznej, które następnie są uruchamiane na silniku procesowym. System CC musi prezentować budowane procesy w formie graficznej (jako graf, wykres, itp.).
2.1.17.	System CC w ramach etapów i kroków procesu musi umożliwiać definiowanie podpowiedzi co w danej chwili Użytkownik Systemu CC ma wykonać.
2.1.18.	System CC musi umożliwiać Administratorowi biznesowemu wprowadzanie modyfikacji (przygotowywanie ról, formularzy, list, konfigurowanie kryteriów w oknach wyszukiwania itp.) w Systemie CC bez wiedzy programistycznej korzystając z jego interfejsu graficznego.
2.1.19.	System CC w ramach grup funkcjonalności CRM, Logistyka, Planowanie pracy, Raporty, Baza wiedzy, Testy musi pracować jako serwis web w sieci Zamawiającego. Dla Konsultanta i Supervisora dopuszcza się instalację aplikacji na stacjach roboczych. Dla Konsultantów II linii dopuszcza się instalację aplikacji agenta do obsługi połączeń głosowych, jednakże Konsultant II linii musi mieć możliwość kompleksowej obsługi Zadań.
2.1.20.	Interfejsy graficzne dla Użytkowników Systemu CC (z wyjątkiem Administratora IT) muszą być spójne i intuicyjne oraz w całości dostępne w języku polskim.

2.2. Role

Lp.	Opis wymagania
2.2.1.	System CC musi umożliwiać definiowanie, modyfikowanie i usuwanie ról dotyczących uprawnień do pracy w Systemie CC. Na rolę składają się informacje o obiektach, uprawnienia (tworzenie, odczyt, modyfikowanie, usuwanie), kryteria per obiekt i zakres rekordów, do których Użytkownik Systemu CC ma dostęp, dodatkowo stosując operatory logiczne AND i OR.
2.2.2.	System CC musi umożliwiać budowanie w sposób elastyczny kolejnych ról na bazie istniejących ról (nawet zawierających tylko fragment uprawnień danej roli).
2.2.3.	System CC musi umożliwiać określanie uprawnień dla Użytkowników Systemu CC poprzez nadanie odpowiedniej roli lub samego uprawnienia.
2.2.4.	System CC musi umożliwiać nadanie Użytkownikowi Systemu CC jednocześnie wielu ról lub samych uprawnień.
2.2.5.	Panele Użytkowników Systemu CC muszą odzwierciedlać uprawnienia wynikające z przypisanych ról w Systemie CC.

2.3. Panele Konsultanta i Supervisora

Lp.	Opis wymagania
2.3.1.	Konsultant i Supervisor muszą obsługiwać wszystkie kanały kontaktu w Systemie CC w jednym interfejsie graficznym.

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 50
Numer dokumentu Mdok: 140405/11/2020

2.3.2.	W Systemie CC panele Konsultanta i Supervisora muszą prezentować indywidualne informacje dotyczące ich pracy i zawierać co najmniej: a) czas zalogowania, b) czas przebywania w stanie gotowości, c) czas przerw, d) bieżący status w pracy, e) liczbę Zgłoszeń i Zadań oczekujących na obsługę w podziale na poszczególne kanały kontaktu, f) liczbę Zgłoszeń i Zadań w trakcie obsługi w podziale na poszczególne kanały kontaktu, g) liczbę Zgłoszeń i Zadań zaległych w podziale na poszczególne kanały kontaktu, h) liczbę Zgłoszeń i Zadań już obsłużonych w podziale na poszczególne kanały kontaktu, i) średnie czasy obsługi Zgłoszeń i Zadań w podziale na poszczególne kanały kontaktu, j) listę kanałów kontaktu, które są obsługiwane przez Konsultanta i Supervisora, k) listę kolejek, do których przypisany jest Konsultant i Supervisor, l) listę Zgłoszeń i Zadań oczekujących na obsługę w podziale na poszczególne kanały kontaktu, m) listę Zgłoszeń i Zadań w trakcie obsługi w podziale na poszczególne kanały kontaktu, n) listę Zgłoszeń i Zadań zaległych w podziale na poszczególne kanały kontaktu, o) listę Zgłoszeń i Zadań już obsłużonych w podziale na poszczególne kanały kontaktu, p) listę pozostałych powiadomień wynikających z pracy w Systemie CC (co najmniej artykuły z Bazy wiedzy do przeczytania, testy do wykonania). W Systemie CC panel Supervisora musi prezentować wszystkie Zgłoszenia i Zadania podległych mu Konsultantów.
2.3.3.	W Systemie CC liczby i listy, o których mowa w pkt. 2 muszą zawierać aktywne odnośniki do odpowiednich widoków w panelach Konsultanta i Supervisora.
2.3.4.	System CC musi umożliwiać przypisanie Konsultanta i Supervisora do kanałów kontaktu.
2.3.5.	Panele Konsultanta i Supervisora w zakresie obsługi Zgłoszeń i Zadań muszą umożliwiać co najmniej odebranie, przełączenie, zawieszenie, zainicjowanie, zakończenie połączenia telefonicznego, wysłanie SMS, odebranie i wysłanie wiadomości e-mail, odebranie, nawiązanie, zakończenie chat z klientem, Konsultantem, Supervisorem, wysłanie newslettera, odebranie alertu dotyczącego problemów w przestrzeni publicznej, odebranie formularza zgłoszeniowego.
2.3.6.	Panele Konsultanta i Supervisora muszą mieć wbudowaną podręczną książkę telefoniczną. Książka telefoniczna musi składać się z dwóch części: numerów wewnętrznych pobieranych z istniejących obecnie baz danych Urzędu Miasta Lublin oraz numerów zewnętrznych. Książka telefoniczna musi zawierać konfigurowalną listę pól, co najmniej takich jak: nazwa, opis, numer telefonu, odnośnik do strony internetowej. Książka telefoniczna musi posiadać wbudowaną wyszukiwarkę pozwalającą na przeszukiwanie po wszystkich polach. Książka telefoniczna musi być konfigurowana przez Administratora biznesowego.
2.3.7.	Funkcjonalności, sposób działania i wygląd interfejsów graficznych paneli Konsultanta i Supervisora będą przedmiotem Analizy przedwdrożeniowej.

2.4. Weryfikacja klienta

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 51
Numer dokumentu Mdok: 140405/11/2020

Lp.	Opis wymagania
2.4.1.	System CC musi umożliwiać weryfikację klienta dzwoniącego w oparciu o odpowiedzi na pytania zadawane przez Konsultanta albo Supervisora.
2.4.2.	System CC musi umożliwiać przygotowywanie zbiorów pytań zadawanych przez Konsultanta albo Supervisora. System CC musi umożliwiać Administratorowi biznesowemu zarządzanie zbiorami pytań (tworzenie, modyfikowanie, usuwanie).
2.4.3.	System CC musi umożliwiać losowanie zestawu pytań ze zbiorów. Liczba pytań w zestawie musi być definiowalna przez Administratora IT.
2.4.4.	System CC musi umożliwiać przy weryfikacji klienta wywołanie i obsłużenie integracji, o której mowa w rozdziale nr 3 „Integracja”.
2.4.5.	Sposób weryfikacji klienta będzie przedmiotem Analizy przedwdrożeniowej.

2.5. Zgłoszenia i Zadania oraz Karty kontaktu

Lp.	Opis wymagania
2.5.1.	System CC musi umożliwiać kolejkowanie i dystrybucję Zgłoszeń i Zadań z wszystkich dostępnych kanałów kontaktu za pomocą skonfigurowanych parametrów. Konfigurowalne parametry kolejkowania i dystrybucji Zgłoszeń i Zadań to co najmniej: a) godziny pracy, b) kanał kontaktu, c) gałąź drzewa IVR (kategoria), d) liczba oczekujących Zgłoszeń i Zadań, e) maksymalny czas obsługi Zgłoszeń i Zadań, f) poziom umiejętności Konsultanta, g) aktualne obciążenie Konsultanta, h) numer dzwoniący, i) numer wybrany, j) adres e-mail nadawcy, k) adres e-mail odbiorcy, l) historia kontaktów danego klienta, m) historia wątku kontaktu danego klienta.
2.5.2.	System CC musi umożliwiać definiowanie priorytetów w ramach parametrów, o których mowa pkt. 1.
2.5.3.	System CC w sposób graficzny musi prezentować priorytet Zgłoszeń i Zadań na formularzach i listach.
2.5.4.	System CC musi umożliwiać odbiór, zawieszenie, transfer wraz z kontekstem, odrzucenie, zamknięcie Zgłoszeń i Zadań, przywrócenie zamkniętych Zgłoszeń i Zadań z wszystkich dostępnych kanałów kontaktu.
2.5.5.	System CC musi umożliwiać transfer Zgłoszeń i Zadań:
ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 52
Numer dokumentu Mdok: 140405/11/2020

	a) do wybranego Konsultanta, b) na grupę Konsultantów (kolejkę), c) do Supervisora. Sposób transferu musi być możliwy: a) w trybie natychmiastowym, b) z konsultacją (Konsultant łączy się z drugim Konsultantem albo Supervisorem i przekazuje mu informacje albo udostępnia Zgłoszenie lub Zadanie do wglądu, a następnie transferuje Zgłoszenie lub Zadanie).
2.5.6.	Jeżeli w trakcie obsługi Zgłoszenia lub Zadania prowadzona była konsultacja, wówczas System CC musi zapisywać chronologicznie w treści Zgłoszenia lub Zadania informacje o tej konsultacji wraz ze wskazaniem w jakim trybie konsultacja była prowadzona (Konsultant – Konsultant albo Konsultant – Supervisor).
2.5.7.	System CC musi umożliwiać przygotowywanie, modyfikowanie i usuwanie szablonów odpowiedzi (uzależnionych od kanału kontaktu), których Konsultant może użyć podczas obsługi Zgłoszeń i Zadań. Treści już udzielonych odpowiedzi z szablonów w Zgłoszeniach i Zadaniach nie mogą się zmienić pomimo późniejszego zmodyfikowania albo usunięcia szablonów. Szablony odpowiedzi muszą być przygotowywane, modyfikowane i usuwane przez Administratora biznesowego.
2.5.8.	System CC musi umożliwiać przy obsłudze Zgłoszeń i Zadań wywołanie i obsłużenie integracji z systemami EZD, SFK i Geoportal Miejski SIPL poprzez Szynę ESB Zamawiającego.
2.5.9.	System CC musi umożliwiać definiowanie przez Administratora biznesowego maksymalnych czasów na obsługę Zgłoszeń i Zadań zależnych co najmniej od kanału kontaktu, kolejki.
2.5.10.	System CC musi wyświetlać w panelach Konsultanta i Supervisora powiadomienia ostrzegawcze o zbliżającym się końcu maksymalnego czasu na obsługę Zgłoszenia lub Zadania, jeżeli nie zostało ono zamknięte. Poziomy powiadomień ostrzegawczych muszą być konfigurowalne przez Administratora biznesowego.
2.5.11.	System CC musi umożliwiać konfigurowanie w ramach każdego kanału kontaktu liczby Zgłoszeń i Zadań, które może jednocześnie obsługiwać dany Konsultant.
2.5.12.	System CC musi umożliwiać tworzenie przez Konsultanta i Supervisora na podstawie Zgłoszenia jednego albo kilku Zadań, które będą automatycznie powiązane z tym Zgłoszeniem.
2.5.13.	System CC musi umożliwiać łączenie ze sobą Zgłoszeń i Zadań w relacji parent-child dotyczącej jednej sprawy, a zgłaszanej przez wielu klientów.
2.5.14.	System CC musi umożliwiać zamykanie Zgłoszeń i Zadań z relacji parent-child, gdy Zgłoszenie albo Zadanie referencyjne zostanie zamknięte.
2.5.15.	System CC musi umożliwiać definiowanie Konsultanta lub grupy Konsultantów (kolejki), którym automatycznie zostanie przekazane Zgłoszenie lub Zadanie na podstawie skonfigurowanych parametrów kolejkowania i dystrybucji Zgłoszeń i Zadań przez Administratora biznesowego.
2.5.16.	Zgłoszenie i Zadanie w poszczególnych fazach obsługi musi być przypisane do jednego Konsultanta i Supervisora.
2.5.17.	Supervisor musi mieć możliwość przejęcia Zgłoszenia i Zadania, przekazania Zgłoszenia i Zadania do innego Konsultanta albo na grupę Konsultantów (kolejkę), przywrócenia zamkniętych Zgłoszeń i Zadań z wszystkich dostępnych kanałów kontaktu.

2.5.18.	W trakcie obsługi Zgłoszenia lub Zadania Konsultant musi mieć możliwość dodania do nich parametru określającego lokalizację poprzez wybranie punktu na mapie Geoportalu Miejskiego SIPL.
2.5.19.	System CC musi umożliwiać przeszukiwanie artykułów w Bazie wiedzy z poziomu formularza Zgłoszenia i Zadania.
2.5.20.	System CC musi umożliwiać podpięcie artykułów z Bazy wiedzy do Zgłoszenia i Zadania.
2.5.21.	System CC musi umożliwiać eksportowanie Zgłoszeń i Zadań do plików w formatach co najmniej: odt, docx, ods, xlsx, csv, pdf, xml, html.
2.5.22.	Informacje wprowadzane i modyfikowane automatycznie przez System CC albo przez Użytkowników Systemu CC w Zgłoszeniach i Zadaniach muszą być zapisywane w metryce Zgłoszenia i Zadania w taki sposób, aby można było zidentyfikować, kiedy, kto i jakie czynności wykonał. Informacje te muszą być niemodyfikowalne. Informacje dotyczące loginów Użytkowników Systemu CC muszą się zachowywać pomimo zmian personalnych w Urzędzie Miasta Lublin.
2.5.23.	System CC musi zapewniać możliwość raportowania informacji, o których mowa w pkt. 22.
2.5.24.	Funkcjonalności, sposób działania i wygląd interfejsów graficznych Zgłoszeń i Zadań będą przedmiotem Analizy przedwdrożeniowej.
2.5.25.	Karta kontaktu musi zawierać zestaw informacji o kliencie. System CC musi umożliwiać Administratorowi biznesowemu definiowanie w Karcie kontaktu dodatkowych pól typu: data, tekst, wartość, prawda/fałsz, pola wyboru, przyciski opcji.
2.5.26.	System CC generując Kartę kontaktu musi uzupełniać dane, które może pobrać automatycznie (w tym numer telefonu czy adres e-mail).
2.5.27.	Jeżeli na podstawie posiadanych danych System CC nie będzie mógł skojarzyć klienta z istniejącymi Kartami kontaktu, to musi automatycznie wygenerować nową Kartę kontaktu.
2.5.28.	Na Karcie kontaktu muszą być zawarte informacje o zgodach, jakie wyraził klient, w tym zgoda na przekazywanie określonych informacji przez telefon. Informacje te muszą zawierać co najmniej treść zgody oraz daty wyrażenia i cofnięcia zgody. System CC musi umożliwiać Administratorowi biznesowemu konfigurację pól i treści szablonów zgód.
2.5.29.	Konsultant i Supervisor muszą mieć możliwość tworzenia nowych Kart kontaktu oraz łączenia i rozłączania istniejących Karty kontaktu.
2.5.30.	Informacje wprowadzane i modyfikowane automatycznie przez System CC albo przez Użytkowników Systemu CC w Kartach kontaktu muszą być zapisywane w metryce Karty kontatu w taki sposób, aby można było zidentyfikować, kiedy, kto i jakie czynności wykonał. Informacje te muszą być niemodyfikowalne. Informacje dotyczące loginów Użytkowników Systemu CC muszą się zachowywać pomimo zmian personalnych w Urzędzie Miasta Lublin.
2.5.31.	System CC musi zapewniać możliwość raportowania informacji, o których mowa w pkt. 30.
2.5.32.	Funkcjonalności, sposób działania i wygląd interfejsu graficznego Karty kontaktu będzie przedmiotem Analizy przedwdrożeniowej.
2.5.33.	System CC musi automatycznie nadawać każdej Karcie kontaktu, każdemu Zgłoszeniu i Zadaniu unikalny identyfikator widoczny na listach i w formularzach Kart kontaktu, Zgłoszeń i Zadań.

2.5.34.	Każda Karta kontaktu, każde Zgłoszenie i Zadanie muszą mieć przypisany zestaw atrybutów generowanych automatycznie przez System CC lub wprowadzanych i możliwych do modyfikowania przez Konsultanta i Supervisora.
2.5.35.	System CC na podstawie posiadanych danych musi wstępnie przypisać Zgłoszenie do Karty kontaktu. Konsultant i Supervisor muszą mieć możliwość przypisania Zgłoszenia do innej Karty kontaktu, jeżeli uznają w trakcie obsługi Zgłoszenia, że dotyczy ono innego klienta.
2.5.36.	Na formularzu Karty kontaktu musi być widoczna lista wszystkich powiązanych z nią Zgłoszeń i Zadań wraz ze statusem. W celu zachowania przejrzystości i czytelności lista musi prezentować w sposób uporządkowany wzajemną zależność pomiędzy Zgłoszeniami a Zadaniami z możliwością sortowania listy. System CC musi umożliwiać otwarcie Konsultantowi i Supervisorowi Karty kontaktu, Zgłoszenia i Zadania poprzez aktywny odnośnik zawierający w adresie odpowiedni identyfikator Karty kontaktu, Zgłoszenia i Zadania.
2.5.37.	Lista Zgłoszeń i Zadań oraz ich wzajemne zależności na Karcie kontaktu musi być możliwa do zaprezentowania w formie graficznej.
2.5.38.	System CC musi posiadać wbudowaną wyszukiwarkę (dla uprawnionych ról w Systemie CC) Kart kontaktu, Zgłoszeń i Zadań. System CC musi umożliwiać Administratorowi biznesowemu definiowanie parametrów wyszukiwania.
2.5.39.	System CC musi przechowywać treść Kart kontaktu, Zgłoszeń i Zadań (w tym załączniki otrzymane od klienta i wysłane do klienta) oraz historię ich obsługi (w tym wszystkie logi operacji wykonywanych przez Użytkowników Systemu CC).
2.5.40.	System CC nie może zezwalać na modyfikację lub usunięcie historii obsługi Kart kontaktu, Zgłoszeń i Zadań ani treści otrzymanych od klientów i wysłanych do klientów.
2.5.41.	Funkcjonalności wynikające z RODO w zakresie Kart kontaktu, Zgłoszeń i Zadań będą przedmiotem Analizy przedwdrożeniowej.

2.6. IVR

Lp.	Opis wymagania
2.6.1.	IVR musi się integrować z Systemem Telekomunikacyjnym Zamawiającego.
2.6.2.	IVR musi umożliwiać odtwarzanie menu z obsługą DTMF zgodnie ze zdefiniowanymi drzewami IVR (scenariuszami).
2.6.3.	Wraz z IVR Wykonawca musi dostarczyć narzędzie pozwalające na generowanie na podstawie tekstu (Text To Speech) komunikatów głosowych w formie plików audio, które muszą być implementowalne w drzewach IVR. Zamawiający dopuszcza wykorzystanie narzędzi (Text To Speech) z chmury publicznej, wyłącznie do samego nagrania plików, pod warunkiem, że nie będzie to wymagało stałego podłączenia Systemu CC do usług zewnętrznych. Wygenerowane komunikaty głosowe muszą charakteryzować się: - zrozumiałością treści, - dokładnością i precyzją wymowy (w tym z uwzględnieniem słów nieznanych, nietypowych i obcojęzycznych, nazw własnych, skrótów i skrótowców, liczb, ułamków i dat oraz znaków specjalnych), - naturalnością brzmienia,

	- płynnością i właściwą intonacją (w tym pozwalającą rozróżnić zdania pytające, oznajmujące i rozkazujące). Licencje dostarczone z tym narzędziem muszą pozwalać na generowanie komunikatów głosowych w językach: polskim, angielskim i ukraińskim. Funkcjonalności narzędzia pozwalającego na generowanie na podstawie tekstu (Text To Speech) komunikatów głosowych, formaty plików audio oraz rodzaje głosów będą przedmiotem Analizy przedwdrożeniowej.
2.6.4.	IVR musi umożliwiać konfigurowanie komunikatów głosowych dla osób oczekujących na połączenie w przypadku zajętości wszystkich Konsultantów.
2.6.5.	IVR musi umożliwiać konfigurowanie wielu drzew z możliwością przypisania ich do różnych dostępowych numerów telefonicznych i do różnych przedziałów godzinowych.
2.6.6.	System CC musi umożliwiać używanie produkcyjne, konfigurowanie, testowanie, przechowywanie i usuwanie wielu różnych drzew IVR: aktualnych, konfigurowanych, testowanych, nieaktualnych, używanych w szczególnych sytuacjach.
2.6.7.	Drzewa IVR muszą być konfigurowane za pośrednictwem nieskomplikowanego interfejsu graficznego w języku polskim lub angielskim.
2.6.8.	Nieskomplikowany interfejs graficzny musi umożliwiać konfigurowanie zagnieżdżonych menu z różnymi komunikatami głosowymi oraz przekierowywanie połączenia telefonicznego na dowolny numer telefonu (wewnętrzny albo zewnętrzny).
2.6.9.	Nieskomplikowany interfejs graficzny musi umożliwiać testowanie drzew IVR przed ich uruchomieniem produkcyjnym.
2.6.10.	Drzewa IVR muszą być zabezpieczone przed przypadkowym usunięciem za pomocą komunikatów potwierdzających wolę usunięcia konkretnego drzewa IVR.
2.6.11.	Wybór przez klienta konkretnej opcji menu w drzewie IVR musi być widoczny w panelu Konsultanta i Supervisora (w tym na liście Zgłoszeń i Zadań oczekujących na obsługę) zarówno przed odebraniem, w trakcie, jak i po zakończeniu połączenia telefonicznego.
2.6.12.	System CC za pośrednictwem IVR musi umożliwiać automatyczne powiadamianie klientów o jednorazowych albo cyklicznych zdarzeniach za pomocą zdefiniowanych komunikatów głosowych.

2.7. Nagrywanie rozmów

Lp.	Opis wymagania
2.7.1.	Nagrywanie rozmów musi gwarantować współpracę z Systemem Telekomunikacyjnym Zamawiającego zapewniając zapis dźwięku co najmniej wszystkich połączeń telefonicznych przychodzących i wychodzących Konsultantów I linii oraz wszystkich połączeń telefonicznych przychodzących Konsultantów II linii.
2.7.2.	Nagrywanie rozmów musi zapewniać mechanizmy przechowywania, przeszukiwania, odsłuchiwania, archiwizacji i usuwania nagranych rozmów w interfejsie graficznym. Usuwanie nagranych rozmów może być wywoływane ręcznie lub automatycznie (w tym po zdefiniowanym czasie).
2.7.3.	Nagrywanie rozmów musi zapewniać interfejs graficzny do przeszukiwania i odsłuchiwania nagranych rozmów oraz ich eksportu do pliku dźwiękowego.

2.7.4.	W Zgłoszeniach i Zadaniach muszą być dostępne aktywne odnośniki do nagranych rozmów dotyczących danego Zgłoszenia lub Zadania.
2.7.5.	System CC musi umożliwiać zarządzanie dostępem do nagranych rozmów.
2.7.6.	System CC musi umożliwiać logowanie wszystkich operacji (w tym faktu odsłuchania nagranej rozmowy, usunięcia nagranej rozmowy) wykonywanych w ramach Nagrywania rozmów.
2.7.7.	Funkcjonalności, sposób działania i wygląd interfejsu graficznego oraz funkcjonalności wynikające z RODO w zakresie Nagrywania rozmów będą przedmiotem Analizy przedwdrożeniowej.

2.8. Logistyka

Lp.	Opis wymagania
2.8.1.	System CC musi umożliwiać zarządzanie informacjami o dokumentach do odbioru (w tym dowód osobisty, Lubelska Karta Seniora) wraz z ich statusami.
2.8.2.	System CC musi umożliwiać powiadamianie klientów o dokumentach do odbioru poprzez zlecenie Konsultantowi wykonania połączenia telefonicznego, poprzez SMS, wiadomość e-mail albo IVR (za pomocą komunikatu głosowego).
2.8.3.	System CC musi kontrolować dane wprowadzane przez Użytkowników Systemu CC w celu wyeliminowania niebezpieczeństwa kilkukrotnego wprowadzenia danych tego samego klienta.
2.8.4.	System CC musi prezentować Użytkownikom Systemu CC komunikaty informujące o niekompletności bądź błędach w danych.
2.8.5.	System CC musi umożliwiać edytowanie albo usuwanie wprowadzonych danych do momentu posiadania tych danych przez konkretnych Użytkowników Systemu CC.
2.8.6.	System CC musi umożliwiać wyszukiwanie informacji o dokumentach do odbioru wraz z ich statusami.
2.8.7.	System CC musi umożliwiać przygotowywanie raportów w zakresie Logistyki wraz z możliwością zapisywania ich wyników do plików w formatach: odt, docx, ods, xlsx, csv, pdf.
2.8.8.	System CC musi umożliwiać w ramach Logistyki samodzielne budowanie kolejnych procesów zarządzania informacjami o dokumentach do odbioru wraz z ich statusami.
2.8.9.	System CC musi umożliwiać w ramach Logistyki wywołanie i obsłużenie integracji z systemami EZD i SFK poprzez Szynę ESB Zamawiającego.
2.8.10.	Funkcjonalności, sposób działania i wygląd interfejsu graficznego oraz funkcjonalności wynikające z RODO w zakresie Logistyki będą przedmiotem Analizy przedwdrożeniowej.

2.9. Planowanie pracy

Lp. Opis wymagania

2.9.1.	System CC musi umożliwiać automatyczne albo ręczne planowanie grafików pracy Konsultantów i Supervisorów, w tym wprowadzanie nieobecności w pracy, x.xx. urlopów wypoczynkowych, zwolnień lekarskich.
2.9.2.	System CC musi umożliwiać automatyczne albo ręczne modyfikowanie grafików pracy Konsultantów i Supervisorów, w tym ustalanie zastępstw.
2.9.3.	System CC musi umożliwiać konfigurowanie, planowanie i modyfikowanie grafików pracy Konsultantów i Supervisorów za pośrednictwem nieskomplikowanego interfejsu graficznego.
2.9.4.	System CC musi umożliwiać automatyczne albo ręczne generowanie grafików pracy Konsultantów i Supervisorów na podstawie wprowadzonych parametrów oraz ich eksport do plików w formatach co najmniej xls, csv, pdf.
2.9.5.	System CC musi umożliwiać Konsultantom i Supervisorom podgląd grafików pracy Konsultantów i Supervisorów.
2.9.6.	Funkcjonalności, sposób działania i wygląd interfejsu graficznego oraz funkcjonalności wynikające z RODO w zakresie Planowania pracy będą przedmiotem Analizy przedwdrożeniowej.

2.10. Raporty

Lp.	Opis wymagania
2.10.1.	System CC musi umożliwiać konfigurowanie nowych raportów bez konieczności posiadania wiedzy programistycznej przez Administratora biznesowego.
2.10.2.	System CC musi w jednolity sposób raportować i prezentować wyniki raportów co najmniej dla wszystkich Użytkowników Systemu CC, grup funkcjonalności Systemu CC, kanałów kontaktu, gałęzi drzew IVR (kategorii), kolejek.
2.10.3.	System CC musi umożliwiać prezentowanie wyników raportów w formie graficznej i eksportowanie ich do plików w formatach co najmniej: ods, xlsx, csv, pdf, xml, html.
2.10.4.	System CC musi umożliwiać zarządzanie dostępem do raportów.
2.10.5.	System CC musi umożliwiać ręczne albo automatyczne (po skonfigurowanych parametrach, co najmniej określonego dnia, o określonej godzinie) cykliczne generowanie i zapisywanie wyników raportów.
2.10.6.	System CC musi umożliwiać raportowanie w czasie rzeczywistym, jak i generowanie raportów historycznych oraz raportów prezentujących historię kontaktów danego klienta i wątku kontaktu danego klienta.
2.10.7.	Raportowanie w czasie rzeczywistym musi umożliwiać monitorowanie bieżących parametrów pracy Systemu CC, Konsultantów i Supervisorów, kanałów kontaktu, kolejek poprzez co najmniej: a) obrazowanie czasu zalogowania, czasu przebywania w stanie gotowości, czasu przerw, bieżącego statusu w pracy poszczególnych Konsultantów i Supervisorów, b) obrazowanie średnich parametrów pracy poszczególnych Konsultantów i Supervisorów oraz grup Konsultantów, c) obrazowanie zbiorczych parametrów pracy poszczególnych Konsultantów i Supervisorów oraz grup Konsultantów,
ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 58
Numer dokumentu Mdok: 140405/11/2020

	d) obrazowanie liczby Zgłoszeń i Zadań oczekujących na obsługę, w trakcie obsługi, zaległych, już obsłużonych z możliwością podziału na poszczególne kanały kontaktu, e) obrazowanie średnich czasów obsługi Zgłoszeń i Zadań z możliwością podziału na poszczególne kanały kontaktu, f) obrazowanie zbiorczych czasów obsługi Zgłoszeń i Zadań z możliwością podziału na poszczególne kanały kontaktu, g) obrazowanie liczby osób oczekujących na połączenie w poszczególnych kolejkach z możliwością podziału na poszczególne gałęzie drzewa IVR (kategorie), h) obrazowanie średnich czasów obsługi połączeń z możliwością podziału na poszczególne gałęzie drzewa IVR (kategorie), i) obrazowanie zbiorczych czasów obsługi połączeń z możliwością podziału na poszczególne gałęzie drzewa IVR (kategorie), j) obrazowanie powiadomień o przekroczeniu parametrów skonfigurowanych Systemie CC z możliwością podziału na poszczególnych Konsultantów i Supervisorów.
2.10.8.	System CC musi umożliwiać raportowanie w czasie rzeczywistym poprzez wizualizację danych w postaci tabelarycznej, jak i w postaci typu dashboard, w tym również na zewnętrznych monitorach.
2.10.9.	Generowanie raportów historycznych musi umożliwiać zarządzanie parametrami pracy Systemu CC, Konsultantów i Supervisorów, kanałów kontaktu, kolejek poprzez co najmniej: a) obrazowanie sumarycznego lub średniego czasu zalogowania, czasu przebywania w stanie gotowości, czasu przerw, bieżącego statusu w pracy poszczególnych Konsultantów i Supervisorów w zadanym czasie, b) obrazowanie sumarycznych lub średnich parametrów pracy poszczególnych Konsultantów i Supervisorów oraz grup Konsultantów w zadanym czasie, c) obrazowanie sumarycznej lub średniej liczby Zgłoszeń i Zadań oczekujących na obsługę, w trakcie obsługi, zaległych, już obsłużonych z możliwością podziału na poszczególne kanały kontaktu w zadanym czasie, d) obrazowanie sumarycznych lub średnich czasów obsługi Zgłoszeń i Zadań z możliwością podziału na poszczególne kanały kontaktu w zadanym czasie, e) obrazowanie sumarycznej lub średniej liczby osób oczekujących na połączenie w poszczególnych kolejkach z możliwością podziału na poszczególne gałęzie drzewa IVR (kategorie) w zadanym czasie, f) obrazowanie sumarycznych lub średnich czasów obsługi połączeń z możliwością podziału na poszczególne gałęzie drzewa IVR (kategorie) w zadanym czasie, g) obrazowanie sumarycznej lub średniej liczby połączeń straconych, odebranych, przełączonych z możliwością podziału na poszczególne dostępowe numery telefoniczne, poszczególne gałęzie drzewa IVR (kategorie) oraz poszczególnych Konsultantów i Supervisorów w zadanym czasie.
2.10.10.	System CC musi umożliwiać generowanie raportów historycznych poprzez wizualizację danych w postaci tabelarycznej, jak i w postaci typu dashboard.
2.10.11.	Historyczne dane raportowe muszą być dostępne w bazie danych Systemu CC i posiadać opisaną strukturę umożliwiającą łączenie ich z innymi danymi biznesowymi.

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 59
Numer dokumentu Mdok: 140405/11/2020

2.10.12.	Generowanie raportów prezentujących historię kontaktów danego klienta i wątku kontaktu danego klienta musi umożliwiać zapoznanie się ze szczegółowym przebiegiem historii kontaktów danego klienta albo wątku kontaktu danego klienta.
2.10.13.	System CC musi posiadać dostarczony w ramach wdrożenia Systemu CC zestaw zdefiniowanych raportów uzgodnionych z Zamawiającym na etapie Analizy przedwdrożeniowej.
2.10.14.	Funkcjonalności, sposób działania i wygląd interfejsu graficznego oraz funkcjonalności wynikające z RODO w zakresie Raportów będą przedmiotem Analizy przedwdrożeniowej.

2.11. Baza wiedzy

Lp.	Opis wymagania
2.11.1.	System CC musi zawierać Bazę wiedzy, która będzie pełniła rolę merytorycznego wsparcia w obsłudze klientów.
2.11.2.	System CC musi umożliwiać konfigurowanie, wprowadzanie, publikowanie, modyfikowanie i wersjonowanie, archiwizację i usuwanie, przeszukiwanie i przeglądanie artykułów w Bazie wiedzy za pośrednictwem nieskomplikowanego interfejsu graficznego.
2.11.3.	System CC musi umożliwiać w ramach Bazy wiedzy wywołanie i obsłużenie integracji z CMS Zamawiającego (CMS Edito) w celu pobrania i wyświetlenia struktury katalogów i treści Kart informacyjnych Urzędu Miasta Lublin. Zarządzanie Kartami informacyjnymi Urzędu Miasta Lublin pozostaje poza Systemem CC.
2.11.4.	Baza wiedzy musi zawierać ustrukturyzowane artykuły opisujące usługi świadczone przez Urząd Miasta Lublin oraz inne informacje konieczne do obsługi klientów.
2.11.5.	Każdy artykuł w Bazie wiedzy musi zawierać co najmniej: a) tytuł, b) status, c) kategorię/kategorie, d) treść, e) słowa kluczowe, f) datę wprowadzenia oraz imię i nazwisko uprawnionego Użytkownika Systemu CC, który wprowadził artykuł, g) datę publikacji oraz imię i nazwisko uprawnionego Użytkownika Systemu CC, który opublikował artykuł, h) datę modyfikacji oraz imię i nazwisko uprawnionego Użytkownika Systemu CC, który zmodyfikował artykuł, i) datę archiwizacji oraz oraz imię i nazwisko uprawnionego Użytkownika Systemu CC, który zarchiwizował artykuł.
2.11.6.	System CC musi umożliwiać określanie przyszłej daty publikacji artykułów w Bazie wiedzy i automatyczną ich publikację zgodnie z tą datą.
2.11.7.	System CC musi umożliwiać określanie daty ważności artykułów w Bazie wiedzy i automatyczną zmianę ich statusu po uływie tej daty. Jeżeli została określona data ważności artykułu w Bazie wiedzy, wówczas musi być ona w nim widoczna.
ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 60
Numer dokumentu Mdok: 140405/11/2020

2.11.8.	Przeszukiwanie artykułów w Bazie wiedzy musi być możliwe co najmniej po: tytule, statusie, kategorii, dowolnym słowie lub fragmencie tekstu, słowach kluczowych, znacznikach czasu.
2.11.9.	System CC musi umożliwiać wyświetlanie kategorii artykułów lub konkretnych artykułów z Bazy wiedzy w panelu Konsultanta i Supervisora na podstawie wyboru gałęzi drzewa IVR przez klienta.
2.11.10.	System CC musi umożliwiać przeszukiwanie artykułów w Bazie wiedzy z poziomu formularza Zgłoszenia i Zadania.
2.11.11.	System CC musi umożliwiać podpięcie artykułów z Bazy wiedzy do Zgłoszenia i Zadania.
2.11.12.	Funkcjonalności, sposób działania i wygląd interfejsów graficznych w zakresie Bazy wiedzy będą przedmiotem Analizy przedwdrożeniowej.

2.12. Testy

Lp.	Opis wymagania
2.12.1.	System CC musi umożliwiać definiowanie treści pytań i zestawów jednokrotnego/wielokrotnego wyboru odpowiedzi, wykonywanie testów przez Użytkowników Testów oraz raportowanie ich wyników.
2.12.2.	System CC musi umożliwiać konfigurowanie, wprowadzanie, publikowanie, dystrybuowanie, modyfikowanie i wersjonowanie, archiwizację i usuwanie, przeszukiwanie i przeglądanie testów oraz przeszukiwanie, przeglądanie raportowanie ich wyników za pośrednictwem nieskomplikowanego interfejsu graficznego.
2.12.3.	System CC musi umożliwiać łączenie testów z odpowiednimi artykułami w Bazie wiedzy.
2.12.4.	Funkcjonalności, sposób działania i wygląd interfejsów graficznych w zakresie Testów będą przedmiotem Analizy przedwdrożeniowej.

2.13. Aplikacja dla Mieszkańca

Lp.	Opis wymagania
2.13.1.	Aplikacja dla Mieszkańca musi umożliwiać kontakt z Urzędem Miasta Lublin oraz przekazywanie klientom informacji przez Urząd Miasta Lublin.
2.13.2.	Po uruchomieniu Aplikacji dla Mieszkańca musi być widoczny komunikat, że nie służy ona do zgłaszania incydentów związanych z zagrożeniem zdrowia czy życia.
2.13.3.	Aplikacja dla Mieszkańca musi umożliwiać wybranie dostępowego numeru telefonicznego Urzędu Miasta Lublin.
2.13.4.	Aplikacja dla Mieszkańca musi umożliwiać kontakt z Urzędem Miasta Lublin poprzez chat, alerty dotyczące problemów w przestrzeni publicznej i formularz zgłoszeniowy.
2.13.5.	Aplikacja dla Xxxxxxxxxx musi umożliwiać rejestrowanie alertów dotyczących problemów w przestrzeni publicznej poprzez wskazanie punktu na mapie miasta Lublin (w tym poprzez odczytanie lokalizacji GPS, upuszczenie pinezki, ręczne wpisanie adresu) i uzupełnienie

	formularza. Do formularza alertu dotyczącego problemów w przestrzeni publicznej klient musi mieć możliwość dodania załączników o ustalonej maksymalnej wielkości, w tym fotografii.
2.13.6.	Formularz alertu dotyczącego problemów w przestrzeni publicznej musi posiadać zabezpieczenie antyspamowe.
2.13.7.	Zarejestrowany alert dotyczący problemów w przestrzeni publicznej musi zapisać się w Systemie CC jako Zgłoszenie.
2.13.8.	Aplikacja dla Mieszkańca musi umożliwiać w sposób czytelny przefiltrowanie po zadanych parametrach i prezentację na mapie miasta Lublin alertów dotyczących problemów w przestrzeni publicznej.
2.13.9.	Wybierając konkretny alert na mapie miasta Lublin muszą być prezentowane w czytelny sposób podstawowe informacje o tym alercie, co najmniej numer, status, krótki opis.
2.13.10.	Użytkownik Aplikacji dla Mieszkańca musi mieć możliwość uzyskania informacji o zarejestrowanych alertach dotyczących problemów w przestrzeni publicznej (w tym o ich statusie) poprzez wybór alertu dotyczącego problemów w przestrzeni publicznej na mapie miasta Lublin albo poprzez wpisanie unikalnego identyfikatora Zgłoszenia.
2.13.11.	W Aplikacji dla Mieszkańca musi być osadzona mapa Geoportalu Miejskiego SIPL jako widok warstwy zawierającej alerty dotyczące problemów w przestrzeni publicznej. Z poziomu tej warstwy musi być widoczny status alertów dotyczących problemów w przestrzeni publicznej i krótki ich opis.
2.13.12.	Aplikacja dla Mieszkańca musi być przygotowana: a) dla systemów operacyjnych urządzeń mobilnych, co najmniej: Android, iOS, b) dla systemów operacyjnych urządzeń klasy PC wykorzystujących przeglądarki internetowe, co najmniej: Mozilla Firefox, Google Chrome, Internet Explorer, Opera.
2.13.13.	Aplikacja dla Xxxxxxxxxx musi posiadać nieskomplikowany interfejs graficzny w języku polskim.

2.14. Funkcjonalności pozostałe

Lp.	Opis wymagania
2.14.1.	System CC musi umożliwiać konfigurowanie kampanii marketingowych poprzez wiadomości typu newsletter.
2.14.2.	Każdy klient wyrażając zgodę na otrzymywanie wiadomości typu newsletter musi mieć możliwość określenia kategorii wiadomości typu newsletter, jakie chce otrzymywać.
2.14.3.	Klient musi mieć możliwość wyrażenia zgody na otrzymywanie wiadomości typu newsletter (w tym wskazania kategorii wiadomości typu newsletter), modyfikacji (w tym dodania i usunięcia kategorii wiadomości typu newsletter) lub cofnięcia zgody w trakcie połączenia telefonicznego z Konsultantem, za pośrednictwem Serwisu WWW albo w Aplikacji dla Mieszkańca. Informacje o wyrażeniu zgody na otrzymywanie wiadomości typu newsletter (w tym o wskazaniu kategorii wiadomości typu newsletter), modyfikacji (w tym o dodaniu i usunięciu kategorii wiadomości typu newsletter) lub cofnięciu zgody muszą być widoczne w Karcie kontaktu i opatrzone datą.
2.14.4.	Każda wysłana z Systemu CC do klienta wiadomość typu newsletter musi zawierać informację o możliwości rezygnacji z subskrypcji oraz udostępniać odnośnik umożliwiający wykonanie takiej akcji.

2.14.5.	System CC musi umożliwiać konfigurowanie kampanii marketingowych w formie graficznej. Proces konfigurowania kampanii marketingowych musi być wspierany poprzez podpowiedzi na każdym jego etapie.
2.14.6.	System CC musi umożliwiać konfigurowanie w formie graficznej adresów e-mail, z których będą wysyłane wiadomości typu newsletter uwzględniając kategorie wiadomości typu newsletter.
2.14.7.	System CC musi umożliwiać konfigurowanie w formie graficznej listy docelowej kampanii marketingowych uwzględniając kategorie wiadomości typu newsletter.
2.14.8.	W Systemie CC musi być osadzona mapa Geoportalu Miejskiego SIPL jako widok warstwy zawierającej alerty dotyczące problemów w przestrzeni publicznej. Z poziomu tej warstwy musi być widoczny status alertów dotyczących problemów w przestrzeni publicznej i krótki ich opis.
2.14.9.	System CC musi umożliwiać otwarcie każdego alertu dotyczącego problemów w przestrzeni publicznej w celu zapoznania się z jego szczegółami.
2.14.10.	System CC musi umożliwiać zaplanowanie Przypomnień kalendarza, czyli powiadamiania klienta o jednorazowych (np. o możliwości odbioru gotowego dowodu osobistego) albo cyklicznych (np. o terminach rat podatku od nieruchomości) zdarzeniach poprzez zlecenie Konsultantowi wykonania połączenia telefonicznego, poprzez SMS, wiadomość e-mail albo IVR (za pomocą komunikatu głosowego).
2.14.11.	System CC musi umożliwiać konfigurowanie Przypomnień kalendarza w formie graficznej. Proces konfigurowania Przypomnień kalendarza musi być wspierany poprzez podpowiedzi na każdym jego etapie.
2.14.12.	System CC musi umożliwiać konfigurowanie w formie graficznej numerów telefonów albo adresów e-mail, z których będą wysyłane Przypomnienia kalendarza.

3. Integracja

3.1. Zamawiający udostępni Wykonawcy Szynę ESB.

3.2. Systemy dziedzinowe Zamawiającego są zintegrowane z Szyną ESB z wykorzystaniem konek- torów dostarczonych przez dostawców systemów dziedzinowych wdrożonych u Zamawiają- cego.

3.3. Wykonawca musi dokonać integracji Systemu CC poprzez uruchomienie usług sieciowych na Szynie ESB w następującym zakresie:

3.3.1. usługa sieciowa do komunikacji z SFK w zakresie:

3.3.1.1. podatku od nieruchomości, podatku rolnego i podatku leśnego od osób fizycz- nych oraz łącznego zobowiązania pieniężnego (numer podatnika, numer obiektu podatkowego, numery i adresy/położenia działek wchodzących w skład obiektu podatkowego, wymiar podatku za poszczególne lata, wysokość i termin rat, wysokość zaległości dla obiektu podatkowego, numer wirtualnego konta bankowego dla obiektu podatkowego, słowniki dotyczące obiektów podatko- wych),

3.3.1.2. gospodarowania odpadami komunalnymi (dane z deklaracji o wysokości opłaty za gospodarowanie odpadami komunalnymi, typ i nazwa klienta, numer i adres obiektu, status nieruchomości, zaległości w opłatach za gospodarowanie odpa- dami komunalnymi, numer wirtualnego konta bankowego na opłaty za gospo- darowanie odpadami komunalnymi, słowniki dotyczące gospodarowania odpa- dami),

3.3.1.3. dodatków mieszkaniowych i energetycznych (dane osoby, której przyznano do- datek mieszkaniowy i energetyczny, data wydania aktualnie obowiązującej de-

cyzji przyznającej dodatek mieszkaniowy i energetyczny, okres, na jaki przy- znano dodatek mieszkaniowy i energetyczny, wysokość przyznanego dodatku mieszkaniowego i energetycznego, decyzja odmawiająca przyznanie dodatku mieszkaniowego i energetycznego, słowniki dotyczące dodatków mieszkanio- wych i energetycznych),

3.3.1.4. ewidencji ludności (historia meldunków danej osoby, data zameldowania na po- byt stały, okres zameldowania na pobyt czasowy, osoby uprawnione do głoso- wania, słowniki dotyczące ewidencji ludności),

3.3.1.5. słownika miejscowości i słownika ulic;

3.3.2. usługa sieciowa do komunikacji z EZD w zakresie metadanych dokumentów (data wpływu pisma do Urzędu Miasta Lublin, data odbioru i osoba posiadająca dokument).

3.4. Powyższy zakres danych będzie przedmiotem Analizy przedwdrożeniowej i może ulec mody- fikacji.

3.5. Komunikacja między Systemem CC a usługami sieciowymi opisanymi w pkt. 3.3. musi odby- wać się tylko z wykorzystaniem Xxxxx ESB. Zamawiający nie dopuszcza jakichkolwiek in- nych mechanizmów wymiany danych niebazujących na Szynie ESB.

3.6. Zamawiający nie dopuszcza możliwości duplikacji danych na potrzeby Systemu CC.

3.7. Wykonawca musi, na etapie Analizy przedwdrożeniowej, przygotować plan uruchomienia i weryfikacji poprawności wymiany danych między Systemem CC a Szyną ESB, który musi zawierać co najmniej:

3.7.1. plan i opis uruchomienia konektorów,

3.7.2. sposób weryfikacji wymiany danych między Systemem CC a Szyną ESB,

3.7.3. plan i scenariusze testów komunikacji Systemu CC z Szyną ESB.

3.8. Wykonawca, na podstawie przeprowadzonej Analizy przedwdrożeniowej, musi przygotować konektory, uruchomić je na Szynie ESB oraz skonfigurować usługi sieciowe.

3.9. Funkcjonalność konektorów musi być zrealizowana bez potrzeby autentykacji w systemach dziedzinowych Zamawiającego, z którymi powiązany będzie System CC.

3.10. Każdy konektor do Szyny ESB dostarczony przez Wykonawcę musi zostać opisany w formie dokumentacji.

3.11. Wykonawca musi przygotować dokumentację, będącą częścią dokumentacji powdrożeniowej, opisującą co najmniej:

3.11.1. opis przepływów danych z Szyny ESB do Systemu CC,

3.11.2. opis zakresów i rodzajów danych przekazywanych z Szyny ESB do Systemu CC,

3.11.3. opis konfiguracji usług sieciowych,

3.11.4. zasady bezpieczeństwa dla usług sieciowych, w tym opis procedur naprawczych ma- jących na celu przywrócenie stanu normalnej pracy po wystąpieniu problemu,

3.11.5. dokumentację techniczną opisującą wszystkie usługi sieciowe udostępnione za po- mocą przygotowanych konektorów, podając nazwy i parametry funkcji, logikę prze- pływu danych, strukturę danych.

3.12. Każda zmiana struktury Systemu CC mająca wpływ na integracje musi każdorazowo zostać zgłoszona Zamawiającemu przez Wykonawcę i nie może powodować niestabilności w funk- cjonowaniu integracji. Wykonawca w razie potrzeby dokona niezbędnej modyfikacji konek- tora w celu zapewnienia prawidłowej komunikacji poprzez Szynę ESB.

3.13. W przypadku braku łączności z Szyną ESB lub konektorem musi dokonać się automatyczna, niezwłoczna synchronizacji danych po przywróceniu łączności.

4. Instruktaże i wdrożenia stanowiskowe

4.1. Zamawiający wymaga:

4.1.1. przeprowadzenia instruktaży i wdrożeń stanowiskowych, które muszą być przeprowa- dzone dla każdej grupy funkcjonalności Systemu CC z podziałem na poszczególne role Użytkowników Systemu CC, zakończonych wydaniem imiennych certyfikatów po- twierdzających zdobycie umiejętności,

4.1.2. przeprowadzenia warsztatów technicznych w formie laboratoryjnej oraz teoretycznej z architektury rozwiązania Systemu CC oraz ze struktury baz danych wraz z przekaza- niem dokumentacji w tym zakresie dla 3 Administratorów IT,

4.2. Instruktaże i wdrożenia stanowiskowe muszą:

4.2.1. być prowadzone przez osoby posiadające niezbędną wiedzę i udokumentowane do- świadczenie (oświadczenie oferenta na etapie realizacji),

4.2.2. być przeprowadzone w języku polskim, a ewentualne pojęcia lub określenia obcoję- zyczne użyte w trakcie wdrożeń stanowiskowych na bieżąco tłumaczone na język pol- ski,

4.2.3. zostać podzielone na grupy tematyczne obejmujące swoim zakresem wszystkie wdra- żane funkcjonalności Systemu CC,

4.2.4. dopuścić wykorzystywanie pomocniczo platformy e-learningowej w oparciu o przygo- towane pakiety multimedialne.

4.3. Wykonawca, do przeprowadzenia instruktaży i wdrożeń stanowiskowych, musi zapewnić:

4.3.1. materiały niezbędne, w języku polskim w formie elektronicznej, odpowiadające zakre- sem danej funkcjonalności Systemu CC,

4.3.2. warunki zgodne z przepisami bezpieczeństwa i higieny pracy w trakcie trwania wdro- żenia stanowiskowego, teoretycznego jak i praktycznego oraz odpowiednie wyposaże- nie (co najmniej stacje robocze, rzutnik),

4.3.3. pokrycie kosztów noclegów instruktorów, w przypadku instruktaży odbywających się poza miejscem pracy,

4.3.4. przeprowadzenie instruktażu każdego uczestnika przy oddzielnym komputerze. Wypo- sażenie stanowisk szkoleniowych w przypadku prowadzenia instruktaży w siedzibie Zamawiającego zapewni Zamawiający.

4.4. Zamawiający pokrywa koszty oddelegowania swoich pracowników na czas instruktaży oraz koszty dojazdu do miejsc ich przeprowadzenia, w przypadku instruktaży odbywających się poza miejscem pracy.

4.5. Plan instruktażu lub wdrożenia stanowiskowego musi zostać przedstawiony przez Wyko- nawcę do akceptacji przez Zamawiającego na 14 dni kalendarzowych przed rozpoczęciem instruktażu lub wdrożenia stanowiskowego.

4.6. Wykonawca zobowiązany jest do przeprowadzenia instruktażu lub wdrożenia stanowisko- wego zgodnie z zatwierdzonym przez Xxxxxxxxxxxxx planem.

4.7. Materiały, niezbędne do przeprowadzenia instruktażu lub wdrożenia stanowiskowego, muszą być zaakceptowane przez Zamawiającego.

4.8. Materiały, o których mowa powyżej muszą być przesłane w formie elektronicznej do akcep- tacji przez Zamawiającego w terminie nie późniejszym niż na 5 dni roboczych przed plano- waną datą rozpoczęcia danego zakresu instruktażu lub wdrożenia stanowiskowego.

4.9. W przypadku uwag do przesłanych materiałów, Zamawiający zgłasza je Wykonawcy, który jest zobowiązany je uwzględnić w porozumieniu z Zamawiającym po czym ponownie przesłać je do akceptacji przez Xxxxxxxxxxxxx.

4.10. Instruktaże i wdrożenia stanowiskowe dla Użytkowników Systemu CC muszą być potwier- dzone poprzez poświadczenie obecności lub potwierdzenie zrealizowania instruktażu na plat- formie e-learningowej.

4.11. Instruktaże dla Administratorów Systemu CC muszą być udokumentowane dokumentem po- twierdzającym zdobytą wiedzę.

4.12. Liczebność grup w ramach instruktaży i wdrożeń stanowiskowych musi być dostosowana do liczby Użytkowników Systemu CC odpowiedzialnych za pracę w danym obszarze.

4.13. Po zakończeniu instruktażu i wdrożenia stanowiskowego dla każdej grupy tematycznej Wy- konawca zobowiązany jest do złożenia protokołu odbioru instruktażu i wdrożenia stanowisko- wego, zawierającego co najmniej: datę instruktażu, obszar, zakres oraz liczbę godzin. Do pro- tokołu zostanie dołączona lista obecności.

4.14. Zamawiający wymaga wdrożeń stanowiskowych dla poszczególnych grup Użytkowników Systemu CC, w szczególności dla:

4.14.1. minimum 20 Konsultantów i minimum 5 Supervisor’ów – w zakresie przyjmowania i obsługi Zgłoszeń i Zadań oraz dostępu do Logistyki, Bazy Wiedzy i Testów – które muszą odbywać się w grupach nie większych niż 6-osobowe i trwać min. 8 godzin zegarowych, tak by zapewnić pełny transfer wiedzy.

4.14.2. minimum 5 Supervisor’ów – w zakresie Nagrywania rozmów, Planowania pracy, Ra- portowania – które muszą trwać min. 16 godzin zegarowych, tak by zapewnić pełny transfer wiedzy. Dodatkowo musi zostać przeprowadzony instruktaż stanowiskowy dający Supervisor’owi uprawnienia do przeprowadzania instruktaży i wdrożeń stano- wiskowych kolejnych Konsultantów.

4.14.3. minimum 3 Redaktorów Bazy wiedzy i minimum 3 Administratorów Bazy wiedzy – które muszą trwać min. 8 godzin zegarowych.

4.14.4. minimum 3 Redaktorów Testów i minimum 3 Administratorów Testów – które muszą trwać min. 8 godzin zegarowych.

4.14.5. minimum 3 Użytkowników CRM – w zakresie modułu Logistyka i modułu Raporty – które muszą trwać min. po 6 godzin zegarowych.

4.14.6. minimum 3 Administratorów Biznesowych – które muszą trwać min. 24 godzin zega- rowych, tak by zapewnić pełny transfer wiedzy.

4.14.7. minimum 3 Administratorów IT – które muszą trwać min. 24 godzin zegarowych, tak by zapewnić pełny transfer wiedzy.

4.15. We wszystkich instruktażach i wdrożeniach dla poszczególnych grup Użytkowników Systemu CC muszą uczestniczyć Administratorzy Biznesowi i ewentualnie Administratorzy IT.

4.16. Opis instruktaży i wdrożeń stanowiskowych dla poszczególnych grup użytkowników Systemu CC:

4.16.1. instruktaż dla Administratorów IT musi obejmować następujący zakres tematyczny:

4.16.1.1. koncepcja i działanie wdrażanego Systemu CC,

4.16.1.2. szczegółowa architektura rozwiązania,

4.16.1.3. integracja z innymi Systemami,

4.16.1.4. monitorowanie poszczególnych warstw architektury: aplikacje, bazy da- nych, systemy operacyjne,

4.16.1.5. budowa widoków i serwisów,

4.16.1.6. analiza historyczna zebranych danych,

4.16.1.7. interfejs graficzny poszczególnych modułów Systemu CC,

4.16.1.8. administrowanie Systemem CC, w tym nadawanie i zmiana uprawnień,

4.16.1.9. udostępnianie danych Systemu CC,

4.16.1.10. przygotowanie raportów i analiz,

4.16.1.11. konfigurowanie automatycznej aktualizacji danych Systemu CC,

4.16.1.12. możliwości rozszerzenia i rozwoju Systemu CC,

4.16.1.13. obsługa serwisowa Systemu CC,

4.16.2. instruktaż dla Administratorów IT wraz z przekazaną kompletną dokumentacją admi- nistracyjną i techniczną systemu musi zapewnić pełny transfer wiedzy na temat sys- temu, zgodnie z rekomendacjami Prezesa Urzędu Zamówień Publicznych. Zgodnie z pkt. R.6.2 rekomendacji należy zapewnić wystarczającą ilość czasu na przejęcie wie- dzy.

4.16.3. instruktaż dla Administratorów Biznesowych, Administratorów Bazy wiedzy i Admi- nistratorów Testów musi obejmować następujący zakres tematyczny:

4.16.3.1. ogólna architektura rozwiązania,

4.16.3.2. szczegółowe funkcjonalności poszczególnych grup funkcjonalności Sys- temu CC oraz powiązania między nimi,

4.16.3.3. interfejs graficzny Systemu CC,

4.16.3.4. zgłaszanie błędów i usterek w działaniu Systemu CC,

4.16.3.5. nadawanie i zmiana uprawnień dla Użytkowników Systemu CC (dotyczy instruktażu dla Administratorów Biznesowych),

4.16.3.6. przygotowanie raportów i analiz (Administratorzy Biznesowi muszą mieć możliwość przygotowywania predefiniowanych pakietów raportów dla użytkowników Raportów),

4.16.4. wdrożenia stanowiskowe dla pozostałych Użytkowników Systemu CC muszą obej- mować następujący zakres tematyczny:

4.16.4.1. szczegółowe funkcjonalności wybranych grup funkcjonalności Systemu CC,

4.16.4.2. zgłaszanie błędów i usterek w działaniu Systemu CC.

5. Dokumentacja

5.1. Wykonawca w ramach realizacji Przedmiotu zamówienia musi wykonać i dostarczyć dokumentację powdrożeniową (w tym dokumentację techniczną oraz dokumentację producenta dla wdrażanego Systemu) zawierającą informacje o przekazywanym na rzecz Zamawiającego oprogramowaniu dedykowanym i standardowym, w tym:

5.1.1. podręcznik działania Systemu, opisujący co najmniej:

5.1.1.1. opis poszczególnych komponentów dostarczonych w ramach realizacji Przedmiotu zamówienia wraz z modelem ich architektury,

5.1.1.2. poszczególne aplikacje, komponenty www jak i dostarczone w ramach nich funkcjonalności,

5.1.1.3. opis warstwy bezpieczeństwa w odniesieniu do Polityki Bezpieczeństwa obowiązującej u Zamawiającego,

5.1.1.4. schemat i opis komunikacji z innymi systemami z zastosowaniem dedykowanych modułów integracji, opartych o Szynę ESB wraz z szczegółowym opisem konektorów (nazwy i parametry funkcji, logika przepływu danych, struktura danych),

5.1.1.5. opis istotnych dla pracy Systemu CC parametrów konfiguracji systemów operacyjnych wraz z przykładowymi skryptami,

5.1.1.6. opis zakresu informacyjnego Systemu CC w formie schematów poszczególnych baz danych, zawierających szczegółowy opis tabel i relacji,

5.1.1.7. opis implementacji rozwiązania, rozdysponowanie usług, konfiguracji systemów w podziale na poszczególne komponenty,

5.1.1.8. procedury wykonywania kopii zapasowych przy wykorzystaniu systemu posiadanego przez Zamawiającego, w tym: polityki wykonywania kopii zapasowych oraz procedury odtwarzania systemu z zachowaniem spójności,

5.1.1.9. procedury instalacyjne oprogramowania wdrożonego przez Wykonawcę, określające wszystkie dające wyróżnić się składniki oprogramowania, ich wersje, etykiety nośników instalacyjnych oraz sposób ich instalacji. Wymaga się, aby każdy występujący w procedurze krok instalacyjny był w projekcie zobrazowany fotografią (zdjęciem, zrzutem) ekranu (ang. screeenshot) odpowiadającą procesowi instalacyjnemu u Zamawiającego,

5.1.2. podręczniki administracji dla każdego z komponentów Systemu, opisujące co najmniej:

5.1.2.1. zasady instalacji oraz konfiguracji wszystkich komponentów Systemu, które wymagają takich czynności na etapie instalacji Systemu lub jego ponownej instalacji,

5.1.2.2. zasady administrowania Systemem dla każdego komponentu składowego Systemu,

5.1.2.3. zasady archiwizacji i bezpieczeństwa Systemu, w tym opis procedur naprawczych mających na celu przywrócenie stanu normalnej pracy Systemu po wystąpieniu awarii,

5.1.2.4. system uprawnień oraz podział na grupy użytkowników Systemu, w tym role definiowane wraz z dokładnym opisem ról przeznaczonych dla administratorów,

5.1.2.5. komunikaty o błędach, ostrzeżenia, ich opisy wraz z podaniem rozwiązań,

5.1.2.6. pozostałe inne, istotne informacje konieczne do prawidłowego administrowania Systemem.

5.1.3. podręczniki (instrukcje stanowiskowe) użytkowników Systemu CC opisujące co najmniej:

5.1.3.1. możliwości wszystkich funkcji Systemu CC, dostępnych dla użytkowników,

5.1.3.2. opis ścieżek obsługi procesów,

5.1.3.3. komunikaty o błędach.

5.1.4. instrukcję obsługi Aplikacji dla Mieszkańca dla Użytkowników Aplikacji dla Mieszkańca. Instrukcja powinna być zgodna z Systemem Identyfikacji Wizualnej Urzędu Miasta Lublin.

5.2. Dokumentacja opisana w pkt. 5.1.3. dla Użytkowników Systemu CC, z wyjątkiem Administratora IT, oraz dokumentacja opisana w pkt. 5.1.4. musi być sporządzona w języku polskim. Pozostała dokumentacja dla której nie istnieje wersja w języku polskim musi zostać przekazana w wersji anglojęzycznej.

5.3. Dokumentacja musi zostać przekazana w formie papierowej w liczbie dwóch egzemplarzy z każdego rodzaju opracowania oraz w edytowalnej postaci elektronicznej na nośniku CD-ROM, w formacie przetwarzanym przez MS Word (od wersji 2003), Open Office i wersji PDF.

6. Licencje

6.1. Licencje na wszelkie komponenty, aplikacje grup funkcjonalnych wchodzących w skład Sys- temu CC i Systemu telekomunikacyjnego oraz na utworzone konektory do Szyny ESB muszą zostać udzielone na Gminę Lublin.

6.2. Dostarczony zestaw licencji dla Systemu CC musi pozwalać na jednoczesną pracę minimum 50 Konsultantów i 5 Supervisorów.

6.3. Konsultanci będą rozdzieleni na dwie linie wsparcia, w podziale na 15 Konsultantów I linii i 35 Konsultantów II linii.

6.4. Dla grup funkcjonalności CRM, Nagrywanie rozmów, Logistyka, Planowanie pracy, Raporty, Baza wiedzy, Testy, Aplikacja dla Mieszkańca, Administrowanie Systemem CC system nie może posiadać ograniczeń architektonicznych i ograniczeń licencyjnych na liczbę użytkowni- ków. Dostarczone dla tych grup funkcjonalności rozwiązanie ma umożliwić jednoczesną pracę przynajmniej 100 użytkownikom.

VI. Szyna danych ESB Zamawiającego

1. Zamawiający udostępni Wykonawcy posiadaną Szynę ESB: WSO2 Enterprise Integrator (EI)

6.4.0. Systemy dziedzinowe Zamawiającego są zintegrowane z Szyną ESB z wykorzystaniem konektorów dostarczonych przez dostawców systemów posiadanych i wdrażanych u Zamawiającego.

2. W ramach Szyny ESB Zamawiającego funkcjonuje obsługa usługi katalogowej Active Directory, wykorzystywana do logowania użytkowników do domeny oraz dostarczania informacji o pracownikach (Szyna ESB Zamawiającego jest klientem istniejącej usługi katalogowej). Zarządzanie kontami użytkowników i ich uprawnieniami odbywa się bezpośrednio w systemach dziedzinowych, jednakże dane uwierzytelniające użytkowników do tych systemów pochodzą zarówno z: AD, LDAP, ePUAP, jak i certyfikatu kwalifikowanego.

3. Udostępniona szyna ESB Zamawiającego posiada mechanizm zarządzania tożsamością, uwierzytelniania i autoryzacji zapewniający mechanizmy SSO i SLO.

4. Szczegółowy opis posiadanej przez Zamawiającego Szyny ESB został zawarty w Rozdziale VIII – Dodatek NR 2 – Specyfikacja szyny usług ESB.

VII. Dodatek NR 1 - Środowisko telekomunikacyjne Zamawiającego

Opis istniejącego środowiska telekomunikacyjnego Zamawiającego:

1. Licencje systemu Hipath4000 V 6.0:

1.1. liczba licencji FLEX: w systemie: 1629

2. Środowisko sprzętowe systemu Hipath4000 V 6.0:

2.1. Półka sterująca cPCI - (szt. 1)

2.1.1. Konfiguracja półki sterującej

2.1.1.1. 3 x Karta procesora DSCXL (Q2311-X)

2.1.1.2. Jedna z kart DSCXL obsługuje moduł ADP (sterowanie wyjściami I/O, zdalny dostęp, Unixware),

2.1.1.3. natomiast dwie pozostałe tworzą parę Active – Standby (sterowanie półkami peryferyjnymi, redundancja pola komutacyjnego).

2.2. Moduł przetrwania do AP3700 IP (kaseta cPCI z DSCXL) - (szt. 1)

2.3. Półka peryferyjna AP 3700 - (szt. 3)

2.3.1. Konfiguracja:

2.3.1.1. 3 x LTU - półki IP połączone bezpośrednio do półki sterującej z wykorzystaniem modułu LTUCA (Q2316-X)

2.4. Półka wyniesiona AP 3700 IP - (szt. 14)

2.4.1. Konfiguracja:

2.4.1.1. 14 x IPDA - półki wyniesione IP, rozmieszczone w różnych lokalizacjach, wykorzystujące moduł sterujący NCUI2+/NCUI4; półki wyniesione posiadają opcję AP Emergency (dodatkowy procesor DSCXL), która zapewnia działanie półki w trybie awaryjnym w przypadku utraty łączności IP z półką sterującą. Dodatkowo 8 półek IPDA posiada funkcję SIGNALING SURVIVABILITY, która powoduje zestawienie połączenia sygnalizacyjnego z półką sterującą po sieci PSTN, w przypadku awarii połączenia IP.

2.5. Kaseta emergency - (szt. 3)

2.6. Moduły sterujące:

2.6.1. LTUCA - szt. 3

2.6.2. RTM - szt. 2

2.6.3. MCM - szt. 1

2.6.4. DSCXL – szt. 3

2.6.5. NCUI4 Q2324-X – szt. 3

2.6.6. NCUI-2+ Q2305-X - szt. 6

2.7. Moduły peryferyjne:

2.7.1. STMI2 Q2316-X – szt. 5

2.7.2. STMI4 Q2324-X500 – szt. 2

2.7.3. DIUN-2 – szt. 6

2.7.4. SLMO24 – szt. 3

2.7.5. STHC – szt. 7

2.7.6. TMANI – szt. 1

2.7.7. SLMAC – szt. 54

2.7.8. SLMAV – szt. 1

2.7.9. STMD3 – szt. 1

3. Hipath 4000 Assistant V6 – aplikacja zarzadzajaca systemem telekomunikacyjnym oraz systemowymi aparati telefonicznymi. Na schemacie blokowym architektury Systemu Telekomunikacyjnego jej fragment funkcjonalności oznaczono literą A.

4. Środowisko sprzętowe, konfiguracja systemu OpenScape Voice ver.6.0, licencje:

4.1. Liczba licencji Open Scape Voice Dynamic User Licence V 6.0 - 755

4.2. Wirtualizacja oprogramowania na maszynie wirtualnej VMware w wersji ESXi 4 lub wyższej.

4.3. Serwery SESAP i Trace służące do zarządzania i gromadzenia logów

4.4. OpenScape; OSC Media Server for Voice only - OMS 1

4.5. OpenScape UC Application Server FE, BE, MS, CMP

4.6. OpenScape Mobile Facade

4.7. DLS ver. 6 - na schemacie blokowym archutektury systemu funkcjonalność tej aplikacji oznaczono literą D.

4.8. SA: Survival Authority

4.9. WebConf: Video Conference

4.10. Brama hardware’owas przeznaczona do transmisji faksymilograficznej pomiedzy systemami telekomunikacyjnymi OSV a H4K: Model: Mediatrix 3301-020; firmware version: 1.1.9.85 szt. 1 - oznaczona na schemacie blokowym architektury systemu literą M.

5. Konfiguracja serwera Open Scape Xpressions V7

5.1. v. 8.11.0 WIN-NT Release Build 16072, XPR Monitor Build 8.11.16072

5.2. System Type – Voice only server

5.3. Liczba licencji 100, wykorzystane 90 licencji

5.4. System operacyjny – Windows Serwer 2008 R2

5.5. Platforma VMware w wersji ESXi 4.x lub wyższej.

6. Konfiguracja systemu ITAR/IBB firmy Intelix

6.1. System taryfikacyjny z nakładką wersji Itar 4.03 - na schemacie blokowym architektury systemu funkcjonalnośc tego modułu oznaczono literami ST.

6.2. Liczba central: 2

6.3. Kolektor V 5.2.1 – na schemacie blokowym architektury systemu funkcjonalnośc tego modułu oznaczony literą K.

6.4. Biling Online - na schemacie blokowym architektury systemu funkcjonalność tego modułu oznaczony literami BO

6.5. Liczba linii wewn. LW: 2200

7. Bramy VOIP – Audio Codes MP11X SIP 2,4,8 FXS, Audio Codes MP124 SIP 24 FXS:

7.1. około 200 szt.w rozbiciu na:

7.1.1. Audio Codes MP 112/2FXS/SIP - 60szt.

7.1.2. Audio Codes MP 114/4FXS/SIP - 90szt.

7.1.3. Audio Codes MP 118/8FXS/SIP - 25szt.

7.1.4. Audio Codes MP 124/24FXS/SIP - 25szt. 7.2. Firmware 4.80, 5.20, 5.60, 5.80, 6.20, 6,60

8. Aparaty telefoniczne systemowe i WL3:

8.1. Siemens WL3 – 40 szt.

8.2. Unify OpenStage 15 IP/HFA – 50 szt.

8.3. Unify OpenStage 20 IP/HFA/SIP – 15 szt

8.4. Unify OpenStage 40 IP/HFA/SIP – 30 szt

8.5. Unify OpenStage 60 IP/HFA/SIP – 25 szt

8.6. Unify OpenStage 80IP/HFA/SIP – 10 szt

8.7. Siemens OptiPoint 410 HFA – 30 szt.

8.8. Siemens OptiPoint500 Standard Advanced – 120 szt.

8.9. Unify OpenStage 15T – 20 szt.

8.10. Unify OpenStage 40T – 20 szt.

8.11. Aparaty analogowe – ponad 1500 szt.

VIII. Dodatek NR 2 – Specyfikacja szyny usług ESB

1. Wersja i parametry techniczne szyny ESB

1.1. Na środowisku produkcyjnym oraz testowym zamawiającego zostanie zainstalowana szyna ESB: WSO2 Enterprise Integrator (EI) 6.4.0 lub nowsza.

1.2. WSO2 EI upraszcza integrację, umożliwiając użytkownikom łatwą konfigurację routingu wiadomości, mediacji wiadomości, transformacji, rejestrowania, planowania zadań, równo- ważenia obciążenia, routingu przełączania awaryjnego, pośrednictwa zdarzeń.

1.3. Usługi danych i różne aplikacje mogą być hostowane i udostępniane za pomocą WSO2 EI.

1.4. Integracja może być dodatkowo wspierana przez możliwości środowiska wykonawczego ta- kie jak moduł analityczny, procesor biznesowy czy broker komunikatów.

2. Środowisko serwerowe szyny danych

2.1. Środowisko serwerowe szyny danych złożone będzie z dwóch wirtualnych serwerów aplika- cyjnych z zainstalowaną usługą WSO2EI spiętych w klaster równoważenia obciążenia oraz z dwóch opcjonalnych maszyn bazodanowych zorganizowanych w klaster HA.

2.2. Maszyny aplikacyjne będą pracowały pod kontrolą systemu operacyjnego Linux, równowa- żenie obciążenia pomiędzy dwoma maszynami aplikacyjnymi będzie realizowane poprzez zewnętrzny Load Balancer stanowiący także przedmiot niniejszego zamówienia.

2.3. Na potrzeby szyny danych nie będą wdrażane dodatkowe serwery bazodanowe MSSQL. ESB opcjonalnie może wykorzystać istniejący klaster bazodanowy dedykowany dla systemów Vulcan .

2.4. Mechanizm WSO2EI pracujący w klastrze równoważenia obciążenia może opcjonalnie użyć relacyjnej bazy danych dla dwóch pomocniczych baz WSO2_USER_DB oraz REGI- STRY_DB.

2.5. Ze względu na znikome wymagania wydajnościowe dla powyżej wymienionych baz pomoc- niczych, na potrzeby szyny ESB będziemy utylizować zasoby na poziomie 1 vCPU, 1 GB danych dyskowych oraz 1 GB pamięci RAM (opcjonalnie, na klastrze MSSQL Failover Clu- ster dla systemu Vulcan).

2.6. Na potrzeby środowiska testowego przewidziano pojedynczą maszynę ESBAPPTEST. Baza danych dla środowiska testowego będzie także osadzona na środowisku testowym MSSQL Server dedykowanym pod system Vulcan.

Wykaz maszyn:

Nazwa:	ESBAPP1
Przeznaczenie:	Serwer aplikacyjny ESB
System operacyjny:	Linux Centos 7
vCPU:	4
RAM:	8 GB
HDD:	80 GB
Dodatkowe licencje:	-
UWAGI:	Węzeł NLB

Nazwa:	ESBAPP2
Przeznaczenie:	Serwer aplikacyjny ESB
System operacyjny:	Linux Centos 7
vCPU:	4
RAM:	8 GB
HDD:	80 GB

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 74
Numer dokumentu Mdok: 140405/11/2020

Dodatkowe licencje:	-
UWAGI:	Węzeł NLB

Nazwa:	ESBAPPTEST
Przeznaczenie:	Serwer aplikacyjny ESB
System operacyjny:	Linux Centos 7
vCPU:	2
RAM:	4 GB
HDD:	80 GB
Dodatkowe licencje:	-
UWAGI:	Środowisko testowe

Schemat poglądowy architektury dla systemu ESB

3. Mechanizmy integracyjne

3.1. WSO2 EI ESB to komponent integracyjny zapewniający komunikację pomiędzy podsyste- mami UM Lublin oraz systemami zewnętrznymi Zamawiającego. Komponent umożliwia bu- dowanie i konfigurowanie aplikacji integracyjnych dostosowujących interfejsy komunika- cyjne pomiędzy łączonymi systemami. Komponent WSO2 EI ESB zapewnia:

3.1.1. Definiowanie usług sieciowych w oparciu o protokoły: SOAP, RESTful, JMS,

3.1.2. Obsługę komunikatów w formacie XML,

3.1.3. Transformację komunikatów,

3.1.4. Obsługę asynchronicznych kolejek zdarzeń,

3.1.5. Obsługę zdarzeń cyklicznych,

3.1.6. Bezpieczeństwo komunikacji w oparciu o specyfikacje i protokoły WS-Security, SAML, Kerberos itp.

3.1.7. Monitorowanie komunikacji za pomocą narzędzi zintegrowanych oraz zewnętrznych poprzez udostępnione interfejsy,

3.1.8. Zintegrowane środowisko programistyczne umożliwiające:

3.1.8.1. tworzenie definicji usług sieciowych oraz ich testowanie w ramach środowi- ska z wykorzystaniem mechanizmów debugowania,

3.1.8.2. tworzenie własnych komponentów obsługi komunikatów w oparciu o zinte- growane środowisko programistyczne (IDE) i wykorzystywanie ich w defini- cji usług sieciowych.

3.1.9. Dostęp poprzez przeglądarkę WWW do konsoli administracyjnej.

3.2. Integracje pomiędzy systemami będą się odbywać za pomocą dwóch rodzajów mechani- zmów:

3.2.1. broker komunikatów

3.2.2. mechanizmy proxy service WSO2

4. Broker komunikatów

4.1. Mechanizm brokera komunikatów będzie odpowiadał m. in. za synchronizację danych o użytkownikach pomiędzy systemami. Xxxxxx realizuje komunikację asynchroniczną oraz syn- chroniczną poprzez generyczny mechanizm przekazywania komunikatów pomiędzy syste- mami.

4.2. Jako załącznik do niniejszego raportu Wykonawca przekazuje plik esb-model.zip. Plik za- wiera:

4.2.1. WSDL opisu usług brokera,

4.2.2. pliki XSD z definicjami możliwych do przesyłania komunikatów.

4.3. W ramach umowy zostanie wdrożona obsługa następujących komunikatów:

Typ komunikatu	Opis	Nadawca	Odbiorca
{messages:cruz}Uzytkownik	Komunikat wysyłany po dodaniu, zmodyfikowaniu lub usunięciu użytkownika	Centralny Rejestr Użytkowników	Zewnętrzne moduły zainteresowane synchronizacją rejestru użytkowników
{messages:org}StrukturaOrg	Odpowiedź z żądaną strukturą organizacyjną	KSAT	Zarządzanie platformą edukacyjną
{messages:org}PobierzStruktu reOrg	Żądanie klienta o wskazaną strukturę organizacyjną	Zarządzanie platformą edukacyjną	KSAT
{messages:org}PobierzPodmi oty	Żądanie klienta o listę podmiotów
{messages:org}Podmioty	Odpowiedź lub publikacja listy podmiotów
{messages:ckk}Kontrahent	Komunikat zawierający dane kontrahenta (jeden rekord pobrany na podstawie identyfikatora lub	Opłaty	KSAT

	dotyczący publikacji informacji o zmianie danych w repozytorium centralnym)
{messages:ckk}PobierzKontra henta	Żądanie pobrania danych kontrahenta na podstawie wskazanego filtra.	Opłaty	KSAT
{messages:ckk}ZnajdzKontra hentow	Żądanie wyszukiwania kontrahentów z możliwością zwrotu większej ilości rekordów
{messages:ckk}Kontrahenci	Komunikat zawierający dane kontrahentów znalezionych metodą ZnajdzKontrahentow
{messages:ckk}OdlaczKontra henta	Komunikat informujący, że system lokalny nie obsługuje wskazanego kontrahent
{messages:ckk}PodlaczKontr ahenta	komunikat informuje, że system lokalny obsługuje wskazanego kontrahenta
{messages:szo}ListaNaliczen	Komunikat zawierający kwoty naliczeń dla opłat	Opłaty	KSAT
{messages:szo}OplatyERP	Komunikat informacji o wpłatach, umorzeniach i zwrotach za wybrany okres	Opłaty	KSAT
{messages:szo}OplatyUmowy ERP	Komunikat informacji o wpłatach, umorzeniach i zwrotach dla umowy za wybrany rok	KSAT	Opłaty
{messages:szo}OdsetkiUmow yERP	Komunikat żądania wyliczenia odsetek na podany dzień	KSAT	Opłaty

UWAGA! Wymagana jest realizacja obsługi komunikatów w systemach źródłowych i docelowych. Nie wszystkie objęte są one dostawą wynikającą z umowy, której dotyczy raport. W szczególności np. w systemie KSAT konieczne jest wdrożenie funkcjonalności obsługi następujących komunikatów:

{messages:org}StrukturaOrg

{messages:org}PobierzStruktureOrg

{messages:org}PobierzPodmioty

{messages:org}Podmioty

{messages:ckk}Kontrahent

{messages:ckk}PobierzKontrahenta

{messages:ckk}ZnajdzKontrahentow

{messages:ckk}Kontrahenci

{messages:ckk}OdlaczKontrahenta

{messages:ckk}PodlaczKontrahenta

{messages:szo}ListaNaliczen

{messages:szo}OplatyERP

{messages:szo}OplatyUmowyERP

{messages:szo}OdsetkiUmowyERP

5. Tryb asynchroniczny

5.1. Broker w trybie asynchronicznym obsługuje jedną metodę relay wstawiającą komunikat do obsłużenia. W trakcie wysyłania komunikatu klient brokera otrzymuje informację czy komu- nikat został umieszczony w kolejce. Odpowiedź z systemu docelowego zwracana jest klien- towi w późniejszym terminie i obsługiwana z wykorzystaniem oddzielnej kolejki komunika- tów.

6. Przekazanie komunikatu do obsłużenia

6.1. System źródłowy przygotowuje treść komunikatu do wysłania w oparciu o zdefiniowany mo- del danych. Komunikat jest dowolnym dokumentem XML

6.2. System źródłowy opakowuje treść komunikat w kopertę brokera komunikatów ustawiając: 6.2.1.Nadawcę komunikatu,

6.2.2.Adresatów komunikatu, 6.2.3.Symbol typu komunikatu,

6.2.4.Wersję modelu danych typu komunikatu, 6.2.5.Identyfikator komunikatu,

6.2.6.Datę zdarzenia (komunikatu),

6.2.7.(opcjonalnie) Numer z sekwencji komunikatów (w przypadku komunikatów, których kolejność może być istotna),

6.2.8.(opcjonalnie) Maksymalny czas życia komunikatu, 6.2.9.(opcjonalnie) Priorytet komunikatu

6.3. System źródłowy przesyła komunikat do brokera za pomocą usługi relay interfejsu ZSI-I- BROKER

6.4. Broker komunikatów weryfikuje:

6.4.1.Dopasowanie uwierzytelnionego systemu źródłowego do wskazanego w komunikacie nadawcy,

6.4.2.Uprawnienia systemu źródłowego do przekazywania komunikatów danego typu do wszystkich wskazanych adresatów,

6.4.3.Zgodność modelu danych komunikatu ze wskazanym typem,

6.4.4.Gotowość obsługi przez broker modelu danych we wskazanej w komunikacie wersji, 6.4.5.Unikalność identyfikatora komunikatu względem wcześniej wysłanych przez xxxx xxx-

tem – celem uniknięcia sytuacji, w której w wyniku błędu komunikacji zwrotnej system źródłowy ponawia wielokrotnie ten sam komunikat

6.5. Broker komunikatów (o ile jest taka potrzeba) przeprowadza transformację komunikatu z wersji otrzymanej do aktualnie obowiązującej wersji kanonicznego modelu danych

6.6. Broker komunikatów wstawia komunikat do kolejki celem dalszej obsługi

6.7. Broker komunikatów odpowiada systemowi źródłowemu informacją o pomyślności lub błę- dzie zakończenia operacji wstawiania komunikatu do kolejki. Broker może zwrócić jeden z następujących komunikatów:

6.7.1.Komunikat poprawnie przyjęty do obsłużenia,

6.7.2.Komunikat obsłużony (w przypadku wymuszenia komunikacji synchronicznej), a odpo- wiedź systemu docelowego jest umieszczona w treści,

6.7.3.Błąd treści żądania klienta – np. walidacja modelu danych zakończyła się błędem, 6.7.4.Brak uprawnień,

6.7.5.Wskazana wersja komunikatu nie jest obsługiwana, 6.7.6.Komunikat został już wcześniej umieszczony w kolejce, 6.7.7.Błąd serwisu,

6.7.8.Maksymalny czas realizacji żądania się skończył.

6.8. W zależności od kodu błędu system kliencki może po jakimś czasie podjąć kolejną próbę wy- słania komunikatu lub zgłosić błąd użytkownikowi. W przypadku błędu odpowiedź zawiera również komunikat tekstowy opisujący zaistniały problem.

7. Obsługa komunikatu przez system docelowy

7.1. Adapter systemu docelowego zainstalowany na szynie usług otrzymuje zdarzenie informu- jące o nowym komunikacie oczekującym w kolejce do obsłużenia

7.2. Adapter odbiera treść komunikatu

7.3. Adapter, o ile jest taka potrzeba, przeprowadza transformację komunikatu z wersji zgodnej z bieżącym kanonicznym modelem danych do wersji modelu danych obsługiwanej przez sys- tem docelowy

7.4. Adapter wywołuje alternatywnie:

7.4.1.dedykowane dla tego typu komunikatu API systemu docelowego, 7.4.2.generyczne API brokera komunikatów

7.5. System docelowy przetwarza żądanie i zwraca odpowiedź

7.6. Jeśli komunikat żądania posiada wskazane wymaganie odpowiedzi broker umieszcza komu- nikat odpowiedź w osobnej kolejce adresując zwrotnie do nadawcy komunikatu żądania.

8. Obsługa odpowiedzi

8.1. Obsługa odpowiedzi realizowana jest poprzez wykonanie usługi process interfejsu ZSI-I- BROKER/KOM udostępnionej przez system klienta. Komunikat odpowiedzi przekazany do metody process może (zależnie od konfiguracji) zawierać obiekt żądania dla którego otrzy- mano odpowiedź. Odpowiedź odebrana przez usługę brokera z usługi ZSI-I-BROKER/KOM służy jedynie weryfikacji poprawności obsługi komunikatu odpowiedzi przez system kliencki.

9. Tryb synchroniczny

9.1. Broker w trybie synchronicznym obsługuje jedną metodę send interfejsu ZSI-I-BROKER przekazującą komunikat do systemu docelowego celem obsłużenia. Po wykonaniu żądania przez system docelowy klient usługi automatycznie uzyskuje odpowiedź wraz ze statusem wykonania żądania. W przypadku napotkania problemu z doręczeniem komunikatu do sys- temu docelowego klient otrzymuje w odpowiedzi status oraz komunikat słowny opisujący błąd.

10. Przekazanie komunikatu do obsłużenia

10.1. Komunikacja synchroniczna z wykorzystaniem usługi brokera realizowana jest w sposób zbliżony do komunikacji asynchronicznej. Podstawową różnicą pomiędzy oboma trybami jest fakt, że:

10.1.1. żądanie synchroniczne za pomocą metody send interfejsu ZSI-I-BROKER ocze- kuje na odpowiedź serwisu docelowego i odpowiedź jest zwracana bezpośrednio w odpowiedzi usługi send,

10.1.2. żądanie asynchroniczne za pomocą metody relay interfejsu ZSI-I-BROKER koń- czy się w momencie dodania komunikatu do kolejki. Klient usługi otrzymuje jedy- nie informację o statusie dodania komunikatu do kolejki żądań. Kolejka jest obsłu- giwana niezależnie, a odpowiedź na wskazany komunikat przekazywana jest na przygotowany dla danego systemu źródłowego interfejs zgodny z definicją ZSI-I- BROKER/KOM.

10.2. Broker komunikatów zapewnia:

10.2.1. Autentykację systemu klienckiego w oparciu o mechanizmy logowania http lub WSS,

10.2.2. Autoryzację żądań w oparciu o wewnętrzną konfigurację dostępnych przepływów komunikatów,

10.2.3. Identyfikację komunikatów i odpowiedzi,

10.2.4. Mechanizmy ponawiania prób doręczenia w przypadku błędów,

10.2.5. Obsługę doręczania odpowiedzi,

10.2.6. Obsługę błędów,

10.2.7. Obsługę wersjonowania i transformacji modelu danych,

10.2.8. Obsługę trybów komunikacji adresowanej oraz rozgłoszeniowej

11. SOAP Proxy Service

11.1. Mechanizm proxy service to moduł w aplikacji WSO2 EI, który odbiera wiadomości i przetwarza je przed przekazaniem ich do usługi do danego serwisu docelowego. Takie po- dejście pozwala na wykonanie niezbędnych przekształceń i wprowadzenie dodatkowej funkcjonalności bez zmiany istniejącej usługi.

11.2. Na przykład, jeśli chcemy używać WS-Security z istniejącą, niezabezpieczoną usługą, można utworzyć bezpieczną usługę proxy service z włączoną WS-Security z określonymi zasadami bezpieczeństwa. Ponadto, jeśli jest potrzeba, aby usługa obsługiwała wiadomości w różnych formatach, można utworzyć proxy service do przekształcania żądań i odpowie- dzi w oparciu o określone konfiguracje XSLT.

11.3. Za pomocą mechanizmu proxy service WSO2 EI udostępni konieczne webserwisy syste- mów docelowych oraz opis tych serwisów poprzez plik WSDL.

11.4. Wykaz serwisów systemów udostępnionych na WSO2 EI znajduje się w tabeli poniżej:

System docelowy		Nazwa serwisu	Opis
KSAT		BudPckApiWsService	Usługi w zakresie planów budżetowych: a) pobieranie z systemu finansowo- księgowego słowników budżetowych (słownik jednostek budżetowych, słownik klasyfikacji budżetowych, słownik obiektów budżetowych i źródeł finansowania, słownik zadań budżetowych), b) przekazywanie do systemu finansowo-księgowego projektu planu budżetu i planu wydzielonego rachunku, c) przekazywanie do systemu finansowo-księgowego zmian dotyczących planu budżetu i planu wydzielonego rachunku, d) pobieranie z systemu finansowo- księgowego planu budżetu i planu wydzielonego rachunku na dany dzień;
MDOK		MdokWsKsatService (MDOK UM) MdokWsKsatService (MDOK MJO)	Usługi w zakresie sprawozdań budżetowych i finansowych: a) pobieranie z systemu finansowo- księgowego do systemu obiegu spraw i dokumentów sprawozdań budżetowych i finansowych;
MDOK		MdokWsKsatService (MDOK UM) MdokWsKsatService (MDOK MJO)	Usługi w zakresie deklaracji VAT-7: a) pobieranie z systemu finansowo- księgowego do systemu obiegu spraw i dokumentów deklaracji VAT-7 jednostki;
KSAT		KgPckApiWsService	Usługi w zakresie dowodów księgowych: a) przekazywanie do systemu finansowo-księgowego dowodów księgowych, b) pobieranie z systemu finansowo- księgowego słowników związanych z dowodami księgowymi tj.
ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 83
Numer dokumentu Mdok: 140405/11/2020

		wszystkich niezbędnych do utworzenia dowodu księgowego wraz z dekretem uzupełniającym;
KSAT	OrgPckApiWsService	Usługi w zakresie umów cywilno- prawnych: a) przekazywanie do systemu finansowo-księgowego umów cywilno-prawnych, b) pobieranie z systemu finansowo- księgowego słowników związanych z umowami (słownik rodzajów umów, słownik typów terminów trwania umowy, słownik kategorii umów, słownik typów umów);
KSAT	NzPckApiWsService	Usługi w zakresie dokumentów finansowych: a) przekazywanie do systemu finansowo-księgowego dokumentów finansowych, b) pobieranie z systemu finansowo- księgowego słowników dotyczących dokumentów finansowych;
KSAT	RsPckApiWsService	Usługi w zakresie faktur: a) przekazywanie do systemu finansowo-księgowego danych faktury oraz faktury korygującej (wraz z danymi dodatkowych kontrahentów faktury i informacjami dodatkowymi dla faktury), b) pobieranie z systemu finansowo- księgowego słowników dotyczących faktur;
KSAT	CkkPckApiWsService RsPckApiWsService	Usługi w zakresie danych kontrahentów (istniejące integracje w trybie żądanie/odpowiedź): a) przekazywanie do systemu finansowo-księgowego danych kontrahentów (w tym pracowników), b) pobieranie z systemu finansowo- księgowego danych kontrahentów, c) pobieranie z systemu finansowo- księgowego słowników dotyczących kontrahentów.

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 84
Numer dokumentu Mdok: 140405/11/2020

12. Opis przepływów integracyjnych szyny ESB

12.1. Lista aplikacji integrowanych:

12.1.1. Zintegrowany System Informatyczny dla jednostek oświatowych VULCAN - ZSI,

12.1.2. Zintegrowany System finansowo-księgowy KSAT - ERP,

12.1.3. System Obiegu Dokumentów Mdok – SOD

12.1.4. Szyna usług WSO2 – ESB

12.2. Typy komunikatów brokera

Symbol	Typ komunikatu	Opis
MSG-UZ/01	{messages:cruz}Uzytkownik	Komunikat wysyłany po dodaniu, zmodyfikowaniu lub usunięciu użytkownika
MSG- SORG/01	{messages:org}StrukturaOrg	Odpowiedź z żądaną strukturą organizacyjną
MSG- SORG/02	{messages:org}PobierzStruktureOrg	Żądanie klienta o wskazaną strukturę organizacyjną
MSG-POD/01	{messages:org}Podmioty	Odpowiedź lub publikacja listy podmiotów
MSG-POD/02	{messages:org}PobierzPodmioty	Żądanie klienta o listę podmiotów
MSG-KL/01	{messages:ckk}Kontrahent	Komunikat zawierający dane kontrahenta (jeden rekord pobrany na podstawie identyfikatora lub dotyczący publikacji informacji o zmianie danych w repozytorium centralnym)
MSG-KL/02	{messages:ckk}PobierzKontrahenta	Żądanie pobrania danych kontrahenta na podstawie wskazanego filtra.
MSG-KL/03	{messages:ckk}OdlaczKontrahenta	Komunikat informujący, że system lokalny nie obsługuje wskazanego kontrahent
MSG-KL/04	{messages:ckk}PodlaczKontrahenta	komunikat informuje, że system lokalny obsługuje wskazanego kontrahenta
MSG-NAL/01	{messages:szo}ListaNaliczen	Komunikat zawierający kwoty naliczeń dla opłat
MSG-NAL/02	{messages:szo}OplatyERP	Komunikat informacji o wpłatach, umorzeniach i zwrotach
MSG-NAL/03	{messages:szo}OplatyUmowyERP	Komunikat informacji o wpłatach, umorzeniach i zwrotach dla umowy
MSG-NAL/04	{messages:szo}OdsetkiUmowyERP	Komunikat żądania wyliczenia odsetek na podany dzień

12.3. Ścieżki integracyjne

Symbol	Komunikat	Opis
ZSI
ZSI-INT-UZ/01	MSG-UZ/01	Publikacja informacji o kontach użytkowników oraz uprawnieniach w postaci komunikatu {messages:cruz}Uzytkownik
ZSI-INT-KL/01	MSG-KL/02	Pobranie danych kontrahenta
ZSI-INT-AD/01		Zarządzanie użytkownikami w ramach usługi Active Directory
ZSI-INT-NAL/01	MSG-NAL/01	Przekazanie informacji o liście naliczeń
ZSI-INT-NAL/02	MSG-NAL/02	Przekazanie informacji o wpłatach, umorzeniach i zwrotach
ZSI-INT-NAL/03	MSG-NAL/03	Przekazanie informacji o wpłatach, umorzeniach i zwrotach dla umowy

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 85
Numer dokumentu Mdok: 140405/11/2020

ZSI-INT-NAL/04	MSG-NAL/04	Żądanie wyliczenia odsetek na podany dzień
ERP
ERP-INT- SORG/01	MSG-SORG/01	Publikacja danych o strukturze organizacyjnej
ERP-INT-POD/01	MSG-POD/01	Publikacja danych o podmiotach wchodzących w skład ZSI
ERP-INT-KL/01	MSG-KL/01	Publikacja danych o kontrahentach
ERP-INT- MDOK/01		Przekazywanie dokumentów do systemu SOD
SOD
SOD-INT-DOK/01		Przekazywanie dokumentu do systemu e-PUAP
SOD-INT-KL/01	MSG-KL/02	Pobranie danych kontrahenta
SOD-INT- SORG/01	MSG-SORG/02	Pobranie struktury organizacyjnej podmiotu

12.4. Usługi integracyjne

Symbol	Komunikat	Opis
ESB
ESB-BROKER	*	Przekazywanie komunikatów pomiędzy systemami
ESB-ERP-BUD/01		Usługa BudPckApiWsService
ESB-ERP-KG/01		Usługa KgPckApiWsService
ESB-ERP-ORG/01		Usługa OrgPckApiWsService
ESB-ERP-NZ/01		Usługa NzPckApiWsService
ESB-ERP-RS/01		Usługa RsPckApiWsService
ESB-ERP-CKK/01		Usługa CkkPckApiWsService
ESB-SOD- MDOK/01		Usługa MdokWsKsatService
ZSI
ZSI-SRV-POD/01	MSG-POD/01	Obsługa komunikatu o liście podmiotów systemu zintegrowanego
ZSI-SRV-KL/01	MSG-KL/01	Obsługa komunikatu o kontrahencie
ERP
ERP-SRV-KL/01	MSG-KL/02	Obsługa żądania pobrania danych kontrahenta
ERP-SRV-KL/02	MSG-KL/03	Obsługa żądania odłączenia kontrahenta od wskazanego systemu
ERP-SRV-KL/03	MSG-KL/04	Obsługa żądania dołączenia kontrahenta do wskazanego systemu
ERP-SRV-NAL/01	MSG-NAL/01	Obsługa komunikatu o liście naliczeń
ERP-SRV-NAL/02	MSG-NAL/02	Obsługa komunikatu informacji o wpłatach, umorzeniach i zwrotach
ERP-SRV-NAL/03	MSG-NAL/03	Obsługa komunikatu informacji o wpłatach, umorzeniach i zwrotach dla umowy
ERP-SRV- SORG/01	MSG-SORG/02	Obsługa żądania pobrania struktury organizacyjnej podmiotu
ERP-ERP-BUD/01		Usługa BudPckApiWsService
ERP-ERP-KG/01		Usługa KgPckApiWsService
ERP-ERP-ORG/01		Usługa OrgPckApiWsService
ERP-ERP-NZ/01		Usługa NzPckApiWsService
ERP-ERP-RS/01		Usługa RsPckApiWsService
ERP-ERP-CKK/01		Usługa CkkPckApiWsService

SOD
SOD-SRV-UZ/01	MSG-UZ/01	Obsługa komunikatu o kontach użytkowników
SOD-SRV-POD/01	MSG-POD/01	Obsługa komunikatu o liście podmiotów systemu zintegrowanego
SOD-SRV-KL/01	MSG-KL/01	Obsługa komunikatu o kontrahencie
SOD-SRV- SORG/01	MSG-SORG/01	Obsługa komunikatu o strukturze organizacyjnej podmiotu
SOD-SRV- MDOK/01		Usługa MdokWsKsatService
AD
AD-SRV		Usługa Active Directory

13. Lista przepływów komunikacyjnych

13.1. INT-UZ/01 - Synchronizacja użytkowników

Kod	INT-UZ/01
Typ	Komunikacja asynchroniczna, Broker
Nazwa	Synchronizacja użytkowników
Systemy	ESB – Szyna integracyjna, ZSI – Vulcan SOD – Mdok AD – Active Directory
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd cruz-messages.xsd
Komunikaty	MSG-UZ/01 {messages:cruz}Uzytkownik

cmp INT-UZ/01 - Synchronizacja użytkowników

ZSI - Vulcan

Activ e Directory

AD-SRV

Diagram

Centralny Rejestr Użytkowników

ZSI-INT-UZ/01

ZSI-INT-AD/01

A

MSG-UZ/01 {messages:cruz}Uzytkownik

ESB - Szyna integracyjna

SOD - Mdok

SOD-SRV-UZ/01

13.2. INT-KL/01 - Publikowanie danych kontrahentów

Kod	INT-KL/01
Typ	Komunikacja asynchroniczna, Broker
Nazwa	Publikowanie danych kontrahentów
Systemy	ESB – Szyna integracyjna, ZSI – Vulcan SOD – Mdok KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd ckk-messages.xsd
Komunikaty	MSG-KL/01 {messages:ckk}Kontrahent

cmp INT-KL/01 - Publikowanie danych kontrahentów

Diagram

ERP-INT-KL/01

KSAT/CKK - Centralna Kartoteka Kontrahentów

KSAT - System ERP

A

MSG-KL/01{messages:ckk}Kontrahent

ESB - Szyna integracyjna

ZSI - Vulcan

ZSI-SRV-KL/01

SOD - Mdok

SOD-SRV-KL/01

13.3. INT-KL/02 - Pobieranie danych kontrahentów

Kod	INT-KL/02
Typ	Komunikacja synchroniczna, Broker
Nazwa	Pobieranie danych kontrahentów
Systemy	ESB – Szyna integracyjna, ZSI – Vulcan SOD – Mdok KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd ckk-messages.xsd
Komunikaty	MSG-KL/02 {messages:ckk}PobierzKontrahenta MSG-KL/01 {mesages:ckk}Kontrahent

cmp INT-KL/02 - Pobieranie danych kontrahentów

Diagram

SOD-INT-KL/01

SOD - Mdok

ZSI-INT-KL/01

ZSI - Vulcan

ERP-SRV-KL/01

KSAT/CKK - Centralna Kartoteka Kontrahentów

KSAT - System ERP

ESB - Szyna integracyjna

MSG-KL/02{messages:ckk}PobierzKontrahenta A

13.4. INT-SORG/01 - Publikowanie struktury organizacyjnej

Kod	INT-SORG/01
Typ	Komunikacja asynchroniczna, Broker
Nazwa	Publikowanie struktury organizacyjnej
Systemy	ESB – Szyna integracyjna, SOD – Mdok KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd org-messages.xsd
Komunikaty	MSG-SORG/01 {messages:org}StrukturaOrg

cmp INT-SORG/01 - Publikowanie struktury organizacyjnej

Diagram

ERP-INT-SORG/01

KSAT

A

MSG-SORG/01 - {messages:org}StrukturaOrg

ESB - Szyna integracyjna

SOD - Mdok

SOD-SRV-SORG/01

13.5. INT-SORG/02 - Pobieranie struktury organizacyjnej

Kod	INT-SORG/02
Typ	Komunikacja synchroniczna, Broker
Nazwa	Pobieranie struktury organizacyjnej
Systemy	ESB – Szyna integracyjna, SOD – Mdok KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd org-messages.xsd
Komunikaty	MSG-SORG/02 {messages:org}PobierzStruktureOrg MSG-SORG/01 {messages:org}StrukturaOrg

cmp INT-SORG/02 - Pobieranie struktury organizacyjnej

Diagram

SOD-INT-SORG/01

SOD - Mdok

A

MSG-SORG/01 - {messages:org}StrukturaOrg

ESB - Szyna integracyjna

KSAT

ERP-SRV-SORG/01

13.6. INT-SORG/03 - Publikowanie listy podmiotów

Kod	INT-SORG/03
Typ	Komunikacja asynchroniczna, Broker
Nazwa	Publikowanie listy podmiotów
Systemy	ESB – Szyna integracyjna, ZSI – Vulcan SOD – Mdok KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd org-messages.xsd
Komunikaty	MSG-POD/01 {messages:org}Podmioty

cmp INT-SORG/03 - Publikacja listy podmiotów

Diagram

ERP-INT-POD/01

KSAT

A

MSG-POD/01 - {messages:org}Podmioty

ESB - Szyna integracyjna

ZSI - Vulcan

ZSI-SRV-POD/01

SOD - Mdok

SOD-SRV-POD/01

13.7. INT-NAL/01 - Obsługa naliczeń

Kod	INT-NAL/01
Typ	Komunikacja synchroniczna/asynchroniczna, Broker
Nazwa	Obsługa naliczeń
Systemy	ESB – Szyna integracyjna, ZSI – Vulcan KSAT – System ERP
Definicja	broker-service.wsdl broker-receiver.wsdl broker-operations.xsd broker-messages.xsd broker-datatypes.xsd integrator-datatypes-2.0.xsd ckk-messages.xsd szo-messages.xsd
Komunikaty	MSG-KL/01 {messages:ckk}Kontrahent MSG-KL/02 {messages:ckk}PobierzKontrahenta MSG-NAL/01 {messages:szo}ListaNaliczen MSG-NAL/02 {messages:szo}OplatyERP MSG-NAL/03 {messages:szo}OplatyUmowyERP MSG-NAL/04 {messages:szo}OdsetkiUmowyERP

SZO::ZSI - Vulcan

ZSI-INT-NAL/01 ZSI-INT-NAL/02 ZSI-INT-NAL/03

ZSI-INT-NAL/04

ZSI-INT-KL/01

cmp INT-NAL/01 - Obsługa naliczeń

Diagram

KSAT::KSAT

ERP-SRV-KL/01 ERP-SRV-NAL/01

ERP-SRV-NAL/02 ERP-SRV-NAL/03

ERP-SRV-NAL/04

ESB::ESB - Szyna integracyjna

MSG-KL/02{messages:ckk}PobierzKontrahenta

MSG-NAL/04 - {messages:szo}OdsetkiUmowyERP MSG-NAL/03 - {messages:szo}OplatyUmowyERP

MSG-NAL/02 - {messages:szo}OplatyERP

MSG-NAL/01 - {messages:szo}ListaNaliczen

A

13.8. INT-ERP/01 Interfejsy ERP i SOD publikowane na szynie ESB

Kod	INT-ERP/01
Typ	Komunikacja synchroniczna, Proxy
Nazwa	Interfejsy ERP i SOD publikowane na szynie ESB (Obsługa usług zgodnie z listą usług opisanych w punkcie 2.2 SOAP Proxy Service)
Systemy	ESB – Szyna integracyjna, SOD – Mdok KSAT – System ERP ZSI – Vulcan oraz systemy zewnętrzne korzystające z interfejsów
Definicja	BudPckApiWsService.wsdl KgPckApiWsService.wsdl OrgPckApiWsService.wsdl NzPckApiWsService.wsdl RsPckApiWsService.wsdl CkkPckApiWsService.wsdl MdokWsKsatService.wsdl

Diagram cmp INT-ERP/01 Interfejsy ERP i SOD publikowane na szynie ESB
KSAT ESB - Szyna integracyjna Systemy zewnętrzne Komunikacja z usługami ERP System dziedzinowy ESB-ERP-BUD/01 ERP-ERP-BUD/01 ERP-ERP-RS/01 ESB-ERP-RS/01 System dziedzinowy ERP-ERP-ORG/01 ESB-ERP-ORG/01 ERP-ERP-CKK/01 ESB-ERP-CKK/01 ERP-ERP-KG/01 ESB-ERP-KG/01 System dziedzinowy ERP-ERP-NZ/01 ESB-ERP-NZ/01
Komunikacja z SOD ERP-INT-MDOK/01 ESB-SOD-MDOK/01 A
SOD - Mdok
SOD-SRV-MDOK/01

ERP-INT-MDOK/01

14. Usługi sieciowe

14.1. Usługa broker-service

Nazwa	broker-service.wsdl
Opis	Usługa brokera komunikacyjnego szyny ESB
Typ	Definicja usługi
Format	WSDL
Security	https, http-Basic-Authorization
Metody	relay	Wstawienie komunikatu asynchronicznego do kolejki brokera
	send	Synchroniczne wykonanie komunikatu brokera przez klienta

14.2. Usługa broker-receiver

Nazwa	broker-receiver.wsdl
Opis	Usługa systemów docelowych wykorzystywana przez broker komunikacyjny celem przekazania obsługiwanego komunikatu
Typ	Definicja usługi
Format	WSDL
Metody	process	Odbiera komunikatu od brokera, obsługuje i zwraca wynik w postaci obiektu komunikatu odpowiedzi

15. Modele danych

15.1. Model danych broker-datatypes

Nazwa	broker-datatypes.xsd
Opis	Model danych generycznego komunikatu obsługiwanego przez moduł brokera komunikacyjnego
Typ	Definicja modelu danych
Format	XSD
Namespace	xxxx://xxx.xxxx.xx/xxxxxx/xxxx-xxxxx
Definicje	message	Obiekt komunikatu żądania brokera

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 96
Numer dokumentu Mdok: 140405/11/2020

15.2. Model danych integrator-datatypes

Nazwa	integrator-operations-2.0.xsd
Opis	Bazowy model danych klas obiektów obsługiwanych przez mechanizmy integracyjne brokera komunikacyjnego
Typ	Definicja modelu danych
Format	XSD
Namespace	xxxx://xxx.xxxx.xx/xxxxxxxxxx/xxxx-xxxxx
Definicje	Adres	Adres
	Dokument	Dokument w rozumieniu Systemu Obiegu Spraw i Dokumentów
	JednostkaOrg	Opis jednostki organizacyjnej
	KontoBankowe	Konto bankowe
	Kontrahent	Obiekt klasy data:Osoba
	Odpowiedz	Podstawowy typ danych odpowiedzi na żądanie kierowane do usługi. Typ jest rozszerzany o dodatkowe elementy w razie potrzeby
	Osoba	Klasa obiektów z danymi osób. Klasa może być rozszerzana przez inne klasy doprecyzowujące obiekt własnymi atrybutami
	Plik	Obiekt w postaci treści binarnej, dokumentu XML lub referencji do zasobu zewnętrznego. Obiekt może wskazywać zarówno na obiekty plikowe jak również stanowić odwołanie do sprawy, dokumentu lub dowolnego innego obiektu, dla którego możliwe jest przygotowanie adresu URI
	PozycjaSlownika	Określa klasę obiektów przechowujących wartość słownikową np. kategoria, wzorzec dokumentu itp. Klasa w zależności od potrzeb wykorzystywana zarówno samodzielnie jako typ danych jak również jako klasa bazowa dla bardziej złożonych typów danych
	Pracownik	Rozwinięcie klasy obiektu data:Osoba o atrybuty związane z definicją pracownika instytucji
	Role	Obiekt listy ról dostępowych dla wskazanego podmiotu
	Sprawa	Sprawa w rozumieniu System Obiegu Spraw i Dokumentów
	Stanowisko	Stanowisko pracownicze
	StrukturaOrg	Struktura organizacyjna instytucji
	Uprawnienia	Obiekt listy uprawnień systemu
	Uzytkownik	Rozwinięcie klasy obiektu data:Osoba o atrybuty związane z definicją

		pracownika instytucji
	Wiadomosc	Wiadomość systemowa
	WzorzecDokumentu	Wskazanie na wzorzec dokumentu pozwalający na generowanie treści dokumentu na podstawie innych atrybutów np. metadanych. Obiekt powinien przechowywać przynajmniej symbol wzorca dokumentu, a w przypadku generowania dokumentu na podstawie dodatkowych danych powinien przechowywać również strukturę metadanych (dokument XML) zrozumiały dla systemu docelowego w tym kontekście
	Zatrudnienie	Umowa zatrudnieniowa pracownika

15.3. Model danych cruz-messages

Nazwa	cruz-messages.xsd
Opis	Model danych komunikatów Centralnego Repozytorium Użytkowników (CRU)
Typ	Definicja modelu danych
Format	XSD
Namespace	messages:cruz
Definicje	Uzytkownik	Komunikat zawierający dane użytkownika CRU

PobierzUzytkownika Komunikat żądania pobrania danych użytkownika

15.4. Model danych ckk-messages

Nazwa ckk-messages.xsd

ZP-P-I.271.93.2020	Szczegółowy opis przedmiotu zamówienia	str. 99
Numer dokumentu Mdok: 140405/11/2020