Wny inspektorat transportu drogowego



Pobieranie 1,06 Mb.
Strona1/15
Data22.05.2018
Rozmiar1,06 Mb.
  1   2   3   4   5   6   7   8   9   ...   15


GŁÓWNY INSPEKTORAT

TRANSPORTU DROGOWEGO

BDG.ZPB.0820.4.2015

Warszawa, 18 września 2015 r.



Do wykonawców w postępowaniu numer BDG.ZPB.0820.4.2015

ogłoszenie o zamówieniu opublikowane w Dzienniku Urzędowym UE pod nr 2015/S 144

-266479 z dnia 29 lipca 2015 r.
Dotyczy: postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego, którego przedmiotem jest: „Budowa, wdrożenie, utrzymanie i rozwój Krajowego Rejestru Elektronicznego Przedsiębiorców Transportu Drogowego”
Na podstawie art. 38 ust. 1 oraz 4 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2013 r. poz. 907 z późn. zm.), zwanej dalej „ustawą”, Zamawiający – Skarb Państwa – Główny Inspektorat Transportu Drogowego odpowiada na pytania Wykonawców oraz dokonuje modyfikacji SIWZ:



  1. OPZ, pkt. 5.1 WF51, WF52, WF48, WF53, WF54, WF55, WF87, WF88, WF89, WF90, WF91, WF92,

Prosimy o przekazanie specyfikacji interfejsów usług systemów zewnętrznych umożliwiających integrację z KREPTD zgodnie z wymaganiami Zamawiającego. W szczególności prosimy o wyspecyfikowanie interfejsów usług systemów Transbit, OpenBTM, CEN.

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że specyfikacja usług jak i same usługi WF48, oraz WF51 do WF92 są przedmiotem postępowania „Na budowę, wdrożenie, utrzymanie i rozwój Krajowego Rejestru Elektronicznego Przedsiębiorców Transportu Drogowego” i powinny zostać wyspecyfikowane i zrealizowane przez Wykonawcę.

zakres integracji zostanie ustalony przez Wykonawcę na etapie analizy dla realizacji tego zagadnienia.



  1. OPZ, pkt. 5.1 WF51, WF52, WF48, WF53, WF54, WF55, WF87, WF88, WF89, WF90, WF91, WF92,

Prosimy o potwierdzenie, że Zamawiający zapewni gotowość odpowiednich specyfikacji, dokumentacji, interfejsów oraz współpracę/usługi podmiotów zewnętrznych (np. gestorów systemów zewnętrznych) umożliwiając Wykonawcy terminowe i zgodne z wymaganiami wywiązanie się z umowy. W szczególności prosimy o wskazanie przewidywanych terminów gotowości do integracji interfejsów systemu OpenBTM, CEN, Transbit

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że specyfikacja usług jak i same usługi WF48, oraz WF51 do WF92 są przedmiotem postępowania „Na budowę, wdrożenie, utrzymanie i rozwój Krajowego Rejestru Elektronicznego Przedsiębiorców Transportu Drogowego” i powinny zostać wyspecyfikowane i zrealizowane przez Wykonawcę.

Szczegółowy zakres integracji zostanie ustalony na etapie analizy dla realizacji tego zagadnienia.



  1. OPZ, "Opis Systemu i uwarunkowania realizacyjne", pkt. 1 Uwarunkowania formalno-prawne, poz. 18 "Projekt Ustawy o zmianie ustawy o transporcie drogowym"

Prosimy o wskazanie lokalizacji powołanego projektu lub załączenie go do SIWZ.

Odpowiedź Zamawiającego:

Zamawiający wskazuje link do projektu ustawy - https://legislacja.rcl.gov.pl/projekt/12269356


https://legislacja.rcl.gov.pl/docs//2/12269356/12276538/12276539/dokument163535.pdf



  1. OPZ, "Opis Systemu i uwarunkowania realizacyjne", pkt. 1 Uwarunkowania formalno-prawne, poz. 19 - 23

Prosimy o wskazanie lokalizacji powołanych wytycznych, zarządzeń GITD i regulaminów wewnętrznych lub załączenie ich do SIWZ

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że Wykonawca, na potrzeby przygotowania Oferty, może zapoznać się w siedzibie Zamawiającego z kompletem dokumentów, którymi dysponuje Zamawiający. Materiały są udostępniane w dni powszednie w godzinach pomiędzy 10:00 a 14:00. W celu wyznaczenia terminu takiej wizji lokalnej Wykonawcy powinni zwrócić się do Zamawiającego z taką prośbą wysyłając fax pod numer 22/220-48-99 lub za pośrednictwem poczty elektronicznej na adres email: zamowieniapubliczne@gitd.gov.pl





  1. OPZ, rozdz. 5.1, WF1:

Zamawiający wskazał procesy biznesowe PB16 - PB24 jednocześnie określając Etap jako 2. Procesy PB16 - PB-18 dotyczą modelu docelowego i nie są zamieszczone na diagramie "Procesy w modelu przejściowym". Taki zapis sugeruje, że wymaganie ma zostać zrealizowane w całości w ramach Etapu 2 a według Oferenta wymaganie to realizowane jest zarówno w Etapie 2 jak i Etapie 3 (z odpowiadającymi tym etapom procesami biznesowymi)

Prosimy o zamieszczenie poprawnego opisu wymagania WF1 i uspójnienie go z diagramami zamieszczonymi w OPZ.



Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez wskazanie w wymaganiu WF1 realizacji w Etapie II procesów PB19 do PB21, w Etapie III procesów od PB16 do PB18 oraz procesów od PB22 do PB24 .





  1. OPZ, "Opis systemu i uwarunkowania realizacyjne", pkt. "2.Procesy biznesowe wspierane przez system", sekcja "Procesy w modelu przejściowym"

W opisie dla "Edycja / Zmiana danych w KREPTD" ("Mapę procesów biznesowych w modelu przejściowym podzielono na następujące 4 grupy") zapisano:

"w tej grupie procesów zawarto procesy, które prowadzą do zmiany danych w KREPTD. Procesy te będą inicjowane poprzez zmianę danych przedsiębiorcy transportu drogowego w systemie TransBit (PB21 i PB22) lub zmianę danych przedsiębiorcy zarejestrowaną przez starostwo (PB23 i PB24)"

PB22 dotyczy danych ze starostw a nie danych z TransBit. Prosimy o poprawę opisu.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ w tym zakresie.





  1. OPZ, rozdz. 5.1, WF3:

Zamawiający wskazał procesy: PB13 oraz PB15. Jednocześnie, realizacja procesu PB14 jest wskazana zarówno w modelach procesów (przejściowego i docelowego) oraz określona jako niezbędna do realizacji w ramach wymagania WF8.

Prosimy o zamieszczenie poprawnego opisu wymagania WF3 i uspójnienie go z diagramami zamieszczonymi w OPZ oraz zapisami w pozostałych wymaganiach.



Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez wskazanie w wymaganiu WF3 realizacji w etapie 2 procesów PB12, BP13, PB14, PB15 w zakresie opisany w wymaganiu WF3.





  1. OPZ, rozdz. 5.1, WF4:

Zamawiający wskazał procesy: PB1, PB13, PB15 - 24. Analogicznie jak w przypadku WF3 nie wskzano PB14. Procesy PB16 - PB-18 dotyczą modelu docelowego i nie są zamieszczone na diagramie "Procesy w modelu przejściowym". Taki zapis sugeruje, że wymaganie ma zostać zrealizowane w całości w ramach Etapu 2 (z pominięciem P14) a według Oferenta wymaganie to realizowane jest zarówno w Etapie 2 jak i Etapie 3 (z odpowiadającymi tym etapom procesami biznesowymi).

Prosimy o zamieszczenie poprawnego opisu wymagania WF4 i uspójnienie go z diagramami zamieszczonymi w OPZ oraz zapisami w pozostałych wymaganiach.



Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty w treści SIWZ poprzez wskazanie w wymaganiu WF4 realizacji w Etapie II procesów PB1, PB13 do PB15 oraz PB19 do PB24, w Etapie III procesów PB16 do PB18




  1. OPZ, rodz. 5.1, WF6:

Proszę o określenie procesu, w którym wymaganie ma być realizowane.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez wskazanie w wymaganiu WF6 realizacji w Etapie II procesu PB21 oraz w Etapie III procesów od PB18 i PB24. Ponadto Zamawiający wyjaśnia, że dodatkowo wymaganie to skorelowane jest z następującymi wymaganiami WF13 Etap II , WF66 Etap III, gdzie również mowa jest o usuwaniu (archiwizacji) danych.





  1. OPZ, rozdz. 5.1, WF18

Zapis pkt 4 opisu wymagania:

"Użytkownik, który zlecił wysłanie komunikatu „zapytanie”, standardowo otrzyma w ciągu 10 sekund z systemu KREPTD wynik weryfikacji dobrej reputacji Zarządzającego transportem w postaci następujących informacji:

- czy Zarządzający został wpisany do ewidencji osób zarządzających transportem w którymś z Państw Członkowskich UE,

- czy Zarządzający został wpisany do ewidencji osób niezdolnych do kierowania operacjami transportowymi przedsiębiorstwa w którymś z Państw Członkowskich UE,

- iloma przedsiębiorstwami Zarządzający aktualnie kieruje oraz

- iloma pojazdami aktualnie Zarządzający zarządza.

W przypadku, gdy któreś z Państw Członkowskich, którego rejestr przedsiębiorców transportu drogowego został zintegrowany z ERRU, nie odpowie na komunikat „zapytanie”, czas odpowiedzi na zapytanie użytkownika ulegnie wydłużeniu o czas potrzebny na obsłużenie zapytania poza systemem ERRU".

Oferent zwraca uwagę, że wykonawca systemu KREPTD nie może być odpowiedzialny za czasy odpowiedzi Systemów zewnętrznych.

Ponadto - zapis taki jest wewnętrznie sprzeczny - nie obejmuje bowiem w możliwych informacjach zwrotnych komunikatu o braku odpowiedzi w zakładanym czasie.

Prosimy o wyjaśnienie treści wymagania i zmianę jego treści.



Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że czas odpowiedzi na złożone zapytanie wynika z przepisów nałożonych przez Unię Europejską na kraje członkowskie zgodnie z ROZPORZĄDZENIEM KOMISJI (UE) NR 1213/2010 z dnia 16 grudnia 2010 r. ustanawiającym wspólne zasady dotyczące połączenia krajowych rejestrów elektronicznych przedsiębiorców transportu drogowego oraz wiedzą Zamawiającego o planowanej zmianie założonego czasu z 60 sek. Do 10 sdk. Ponadto Zamawiający wyjaśnia, że opis wymagania nie jest wewnętrzne sprzeczny – szczegółowo zostało to zaprezentowane w ramach procesu PB6.. Jeżeli w ciągu 10 sek Użytkownik który zlecil zapytanie nie otrzyma odpowiedzi, to powinien otrzymać komunikat NACK lub jeśli i to nie zostanie zwrócone z ERRU to należy zapoznać się z dokumentem ERRU IMPLEMENTATION GOOD PRACTICES gdzie opisane zostało praktyczne rozwiązanie.




  1. OPZ, rozdz. 5.1, WF25:

Prosimy o poprawienie odnośnika do wymagania.

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia że dla wymagania WF25 chodzi o referencję do wymagania WF34.




  1. OPZ, rozdz. 5.1, WF30:

Zamawiający w wymaganiu określił konieczność wydruku również dokumentów innych niż wymieniane z ERRU. Prosimy o określenie

- liczby rodzajów dokumentów

- czy każdy dokument będzie miał swój szablon

- jeśli dokumenty będą drukowane zgodnie z szablonami, zmienności szablonów

Dodatkowo, Zamawiający wskazał w wymaganiu: "Operacje powinny być tak zapisywane aby możliwa była później komunikacja z systemem ERRU" a wymaganie dotyczy możliwości wydruku dokumentów do pliku pdf.

Prosimy o doprecyzowanie oczekiwań Zamawiającego w tym zakresie.

Dodatkowo, analogicznie jak w przypadku np wymagań WF1 i WF4, w wymaganiu wskazane są zarówno procesy wykorzystywane w Etapie2 jak i w Etapie3 a sama realizacja wskazana jest na Etap2. Prosimy o naniesienie poprawek w OPZ.

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że liczba pozostałych dokumentów nie powinna przekroczyć 20 rodzajów dokumentów jednocześnie, każdy dokument będzie miał swój szablon. Zamawiający na tym etapie, nie jest w stanie określić częstotliwości zmiany szablonów lecz zakłada się, że będzie istniała możliwość wydruku dokumentów przy użyciu szablonów archiwalnych co może doprowadzić do sytuacji, w której system będzie umożliwiał wydruk więcej niż 20 typów dokumentów.

Operacja związana z utworzeniem dokumentu wynikającego z komunikacji z ERRU i jego przekazaniem pozasystemowym, powinna być zapisywana w postaci załącznika PDF oraz komunikatu xml lub jako zapis w bazie danych w taki sposób, aby w przypadku nawiązania łączności z systemem ERRU możliwe było wysłanie takiego komunikatu do ERRU lub przyjęcie komunikatu elektronicznego do pisma przekazanego pozasystemowo.


  1. OPZ, rozdz. 5.1, WF31, WF36 - WF43:

Analogicznie jak w przypadku np wymagań WF1 i WF4, w wymaganiu wskazane są zarówno procesy wykorzystywane w Etapie2 jak i w Etapie3 a sama realizacja wskazana jest na Etap2. Prosimy o naniesienie poprawek w OPZ.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez :



  • wskazanie w wymaganiu WF31 realizacji w etapie 2 procesu BP4, w etapie 3 procesów BP2 i PB3.

  • wskazanie w wymaganiu WF36 do 40 realizacji w etapie 2 procesu BP4, w etapie 3 procesu PB3.

  • wskazanie w wymaganiu WF41 do 44 realizacji w etapie 2 procesu BP6, w etapie 3 procesów PB5 i PB7.


  1. OPZ, rozdz. 5.1, WF44:

Analogicznie jak w przypadku np wymagań WF1 i WF4, w wymaganiu wskazane są zarówno procesy wykorzystywane w Etapie2 jak i w Etapie3 a sama realizacja wskazana jest na Etap2. Prosimy o naniesienie poprawek w OPZ.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez wskazanie w wymaganiu WF44 realizacji w etapie 2 procesu PB6 w etapie 3 procesów BP5 i PB7




  1. OPZ, rozdz. 5.1, WF46:

Opis wymagania, pkt. 4 o treści:

"4. System będzie wysyłał komunikat „odpowiedź na powiadomienie o naruszeniu przepisów” do systemu ERRU."

Wskazany proces PB8 dotyczy tylko zapytania o dobrą reputację a nie dotyczy przyjęcia powiadomienia o naruszeniu przepisów.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ "4. System będzie wysyłał komunikat „odpowiedź na zapytanie o dobrą reputację” do systemu ERRU."



  1. OPZ, rozdz. 5.1, WF49:

Prosimy o przekazanie interfejsu CEN dotyczącego wymiany danych o naruszeniach. Jeśli interfejs jest obecnie budowany prosimy o potwierdzenie, że będzie on przekazywał komunikaty o strukturze umożliwiającej realizację punktu 1 wymagania.

Diagram procesu PB1 wskazuje, że w przypadku przekazywania do KREPTD decyzji o nałożeniu kary przez organ kontrolny (zarówno z wykorzystaniem API jak i formularzy na ESP), po stronie KREPT nie jest realizowane:

- dekompozycja komunikatu

- mapowanie (konwersja) kategorii naruszeń

Prosimy o potwierdzenie, że w przypadku danych przekazywanych z organów kontrolnych - to strona przekazująca komunikat będzie odpowiedzialna za właściwe określenie kategorii naruszenia i sankcji (tak, aby były zgodne z ERRU) (zagadnienie powiązane z WF60).

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że budowa interfejsu wymiany wszelkich danych przetwarzanych w systemie KREPTD(w tym danych o naruszeniach) obsługującego procesy dekompozycji i mapowania komunikatów i kategorii naruszeń będzie stanowiła obowiązek Wykonawcy.




  1. OPZ, rozdz. 5.1, WF50:

W wymaganiu określono procesy: PB19 - PB21, które dotyczą modelu przejściowego, a realizację określono na Etap3. Zgodnie z Mapą procesów - w ramach Etapu3 powinny to być procesy PB16 - PB21.

W związku z powtarzającymi się rozbieżnościami - prosimy o weryfikację wymagań, mapowania ich na procesy biznesowe oraz wskazania etapu realizacji wymagania podanego w rozdz. 5.1 OPZ.

W wymaganiu wskazano:

"2. System będzie każdorazowo identyfikował nowe rekordy danych pobranych z TransBit, weryfikował i przetwarzał dane dotyczące przedsiębiorcy transportu drogowego do formatu właściwego dla KREPTD.

3. System będzie zapisywał nowe rekordy w Rejestrze lub usuwał te, które zostały usunięte z bazy systemu TransBit."

Zapis wymagania nie uwzględnia procesu PB20 "Zmiana danych importowanych z systemu TransBit (model przejściowy)"

Prosimy o weryfikację treści zapisu i wyjaśnienia oraz (jeśli zachodzi) - poprawę opisu wymagania.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ w powyższym zakresie.

Zamawiający wyjaśnia, że przypisanie procesów do wymagania jest prawidłowe. Jeśli system OpenBTM nie będzie gotowy do integracji w ramach usługi, to w okresie przejściowym dane nadal będą aktualizowane z systemu Transbit.


  1. OPZ, rozdz. 5.1, WF64:

Prosimy o poprawienie odnośnika do wymagania.

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia że dla wymagania WF64 chodzi o referencję do wymagania WF1.



  1. OPZ, rozdz. 5.1, WF68:

zastrzeżenie co do zapisu "Użytkownik, który zlecił wysłanie komunikatu „zapytanie”, standardowo otrzyma w ciągu 10 sekund z systemu KREPTD wynik weryfikacji dobrej reputacji Zarządzającego transportem w postaci następujących informacji [...]" :

Oferent zwraca uwagę, że wykonawca systemu KREPTD nie może być odpowiedzialny za czasy odpowiedzi Systemów zewnętrznych.

Ponadto - zapis taki jest wewnętrznie sprzeczny - nie obejmuje bowiem w możliwych informacjach zwrotnych komunikatu o braku odpowiedzi w zakładanym czasie.

Prosimy o wyjaśnienie treści wymagania i zmianę jego treści.



Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że czas odpowiedzi na złożone zapytanie wynika z przepisów nałożonych przez Unię Europejską na kraje członkowskie zgodnie z ROZPORZĄDZENIEM KOMISJI (UE) NR 1213/2010 z dnia 16 grudnia 2010 r. ustanawiającym wspólne zasady dotyczące połączenia krajowych rejestrów elektronicznych przedsiębiorców transportu drogowego oraz wiedzą Zamawiającego o planowanej zmianie założonego czasu z 60 sek. Do 10 sdk. Ponadto Zamawiający wyjaśnia, że opis wymagania nie jest wewnętrzne sprzeczny – szczegółowo zostało to zaprezentowane w ramach procesu PB6.. Jeżeli w ciągu 10 sek Użytkownik który zlecil zapytanie nie otrzyma odpowiedzi, to powinien otrzymać komunikat NACK lub jeśli i to nie zostanie zwrócone z ERRU to należy zapoznać się z dokumentem ERRU IMPLEMENTATION GOOD PRACTICES gdzie opisane zostało praktyczne rozwiązanie.




  1. OPZ, rozdz. 5.1, WF69:

W opisie wymagania wprowadzono odwołanie do nieistniejącego wymagania: WF653.

Dodatkowo - wymaganie dotyczy zestawu czynności "wprowadzenie do KREPTD wyników postępowania w sprawie oceny, czy utrata dobrej reputacji przedsiębiorcy lub Zarządzającego transportem stanowi proporcjonalną reakcję" - jako proces wskazano PB4. Proces PB4 opisany jest jako: "Odpowiedź na powiadomienie o naruszeniu przepisów w modelu przejściowym (przy wykorzystaniu TransBit)"

Prosimy o poprawienie opisu wymagania.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty treści SIWZ poprzez wskazanie w wymaganiu WF69 odwołania do wymagania WF65 oraz wskazanie w wymaganiu realizacji w etapie 3 procesu PB14.




  1. OPZ, rozdz. 5.1, WF71:

W wymaganiu jako element systemu wskazano "Aplikację dla starostw", w procesie wskazanym w wymaganiu (PB15) odbiorcą komunikatu jest "Instytut Transportu Samochodowego" a nie pracownik Starostwa.

Prosimy o potwierdzenie, czy element systemu "Aplikacja dla starostw" ma być dostępny również dla innych podmiotów. Jeśli tak, to prosimy o podanie jakich.



Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że w procesie PB15 Pracownik BTM informuje jednostkę wydającą certyfikaty kompetencji zawodowych (Instytut Transportu Samochodowego) o zwrocie certyfikatu a nie o wykreśleniu Zarządzającego z ewidencji osób niezdolnych do kierowania operacjami transportowymi. Natomiast wymaganie mówi o konieczności mailowego powiadomienia pracownika starostwa o wykreśleniu Zarządzającego z ewidencji osób niezdolnych do kierowania operacjami transportowymi.




  1. OPZ, rozdz. 5.1, WF80 - WF81:

W wymaganiach wskazano procesy PB23 oraz PB24 - procesy te dotyczą aktualizacji i usuwania danych na podstawie komunikatów przesyłanych ze starostw.

Treść obu wymagań wskazuje na to, że są to wymagania na integrację między KREPTD a OpenBTM (zapis "w szczególności aplikacji systemu Open BTM" )

Prosimy o poprawienie opisu wymagania.

Odpowiedź Zamawiającego:

Zamawiający dokonuje korekty w treści SIWZ poprzez wykreślenie wskazania procesów PB23 i PB24. Zamawiający potwierdza, że są to wymagania pomiędzy KREPTD a OpenBTM i nie zostały uwzględnione w żadnym procesie opisanym w załączniku.



  1. OPZ, Rozdz. 5.1 Wymagania funkcjonalne i niefunkcjonalne, Wymaganie NF23, str. 104-105

Prosimy o podanie szczegółowej specyfikacji infrastruktury programowo-sprzętowej(producent, typ i model) dostarczanej przez Zamawiającego, która ma być objęta zarządzaniem konfiguracją, zgodnie z wymaganiem NF23. Bez takiej specyfikacji nie jest możliwe zaproponowanie rozwiązania gwarantującego możliwość współpracy z powyższą infrastrukturą.

Odpowiedź Zamawiającego:

Zamawiający odsyła do odpowiedzi na pytanie nr 461.



  1. OPZ, Rozdz. 5.3 Opis wymagań na rozwój systemu ..., ppkt 1.5 str. 129-115. Czy w ramach szkoleń uzupełniających Zamawiający dopuszcza zastosowanie e-learningu czy też muszą to być każdorazowo szkolenia stacjonarne?

Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że w ramach szkoleń uzupełniających nie dopuszcza zastosowania e-learningu jeśli podstawowe szkolenie odbyło się stacjonarnie.





  1. SIWZ cz. III OPZ rozdz. 5.5 pkt 2.6.2

Czy Zamawiający nie podając w pkt 2.6.2 czasu na obejście dla Błędu kategorii niski, potwierdza że Wykonawca na ewentualne obejście ma 72h?

Odpowiedź Zamawiającego:

Zamawiający nie potwierdza takiego założenia. Dla błędu kategorii „niski” Zamawiający nie przewiduje obejścia. 72 h to czas na rozwiązanie zgłoszenia.



  1. SIWZ cz. III OPZ rozdz. 5.5 pkt 2.4

Zamawiający oczekuje, że Wykonawca zapewni obsługę zgłoszeń (incydentów i problemów) i jednocześnie nie definiuje tych pojęć. Jednocześnie Zamawiający oczekuje świadczenia usług zgodnie z biblioteką ITIL v3. Czy w tej sytuacji należy przyjąć następujące definicje?:

Zgłoszenie - każde zdarzenie zgłoszone przez użytkownika Systemu KREPTD,

Incydent - Każde zgłoszenie, które dotyczy działania niezgodnego z dokumentacją Systemu KREPTD, działania utrzymywanej infrastruktury Problem - nieznana przyczyna jednego lub wielu Incydentów, Znany błąd - Incydent lub Problem, którego przyczyna wystąpienia jest znana i dla którego została zidentyfikowane zostało obejście.

Jeśli Zamawiający nie akceptuje proponowanych definicji to prosimy o ich sprecyzowanie, zwłaszcza, że w ramach usługi utrzymani, jedną z głównych usług jest obsługa zgłoszeń (incydentów i problemów).



Odpowiedź Zamawiającego:

Zamawiający wyjaśnia, że interpretacja i adaptacja kluczowych pojęć pochodzących z biblioteki ITIL musi uwzględniać wszystkie wymagania Zamawiającego zgłoszone na etapie analizy.





  1. SIWZ cz. III OPZ rozdz. 5.5 pkt 2.6.2

Zamawiający oczekuje, że Wykonawca zapewni podejmowanie i realizację zgłoszeń w czasach określonych w niniejszym punkcie i jednocześnie nie definiuje pojęć Czas reakcji na zgłoszenie, Czas realizacji zgłoszenia, obejście oraz rozwiązanie zgłoszenia. Jednocześnie Zamawiający oczekuje świadczenia usług zgodnie z biblioteką ITIL v3. Czy w tej sytuacji należy przyjąć następujące definicje?:

Czas reakcji na zgłoszenie - czas na wysłanie odpowiedzi na zgłoszenie użytkownika Systemu KREPTD, potwierdzającej rejestrację zgłoszenia,

Czas realizacji zgłoszenia - czas na obsługę zgłoszenia przyjętego do realizacji, w ramach którego zostanie zastosowane obejście lub rozwiązanie docelowe z uwzględnieniem wymagań procesu wdrażania zmian w Systemie KREPTD.

obejście/Obejście - minimalizacja lub eliminacja wpływu Incydentu na działanie usług Systemu KREPTD, dla którego nie opracowano docelowego rozwiązania. Obejście dla incydentów o priorytetach 1 i 2 oznacza przywrócenie poprawnego działania usługi poprzez restart usługi lub jej komponentu, wykonanie skryptu naprawczego, zmianę parametrów konfiguracyjnych itp. działań. W przypadku zgłoszeń o priorytecie 3, obejście stanowi jeden ze sposobów obsługi incydentu, rozwiązanie zgłoszenia - działanie podjęte w celu naprawy zgłoszonego Incydentu poprzez zastosowanie rozwiązania docelowego lub poprzez zastosowanie Obejścia. Jeśli Zamawiający nie akceptuje proponowanych definicji to prosimy o ich sprecyzowanie, zwłaszcza, że w ramach usługi utrzymani, jedną z głównych usług jest obsługa zgłoszeń (incydentów i problemów).




  1   2   3   4   5   6   7   8   9   ...   15


©operacji.org 2017
wyślij wiadomość

    Strona główna