Cena oferty brutto — waga 60%, wzór: (najniższa cena brutto / cena w ofercie) × 60 pkt. - Czas usunięcia awarii Oprogramowania — waga 40%, od 24h (0 pkt) do ≤8h (40 pkt).
8
Kary i sankcje
Widoczne 50%
Kary umowne: w projekcie umowy (Załącznik nr 8) — zwłoka rozpoczęcia 0,5%/dzień; reakcja serwisowa 0,01%/godz.; naprawa błędów 0,01%/dz.; zmiany i kody źródłowe 2%/dz.; inne zobowiązania 2%/dz.; poufność 0,5%; dane osobowe 0,5%; odstąpienie 20%; max łącznie 30%
Własność intelektualna: Wykonawca zachowuje prawa autorskie do utworów; udziela Zamawiającemu niewyłącznej, nieograniczonej w czasie i terytorialnie licencji na zmiany z dokumentacją; przekazane obiekty IP nie mogą mieć wad prawnych.
Monitorowanie zdalne: Osoby dostępu do systemów IT Zamawiającego muszą być powiadomione o monitoringu (art. 222 KP); sesje mogą być monitorowane i utrwalane; logi stanowią podstawę weryfikacji.
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 12 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
14 dni za darmo Bez karty płatniczej Rezygnacja w 1 klik
Opis przedmiotu zamówienia
Streszczenie AI · Janusz
Zamówienie dotyczy usług opieki serwisowej oprogramowania Egeria: naprawy błędów i problemów wydajnościowych, konsultacji hotline, wprowadzania zmian prawnych oraz modernizacji (dostosowanie do nowych wersji narzędzi i sprzętu, modyfikacje danych) w limitu 200 osobodni, realizowanej zdalnie przez VPN lub w siedzibie Zamawiającego w Warszawie.
Pytania i odpowiedzi
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, I. DEFINICJE, par. 1
Awaria – Sytuacja, w której z powodu błędów lub Problemu wydajnościowego
Oprogramowania, nie można realizować któregokolwiek procesu biznesowego.
Prosimy o zmianę definicji na:
Awaria – Powoduje, że całkowicie nie działają lub nieprawidłowo działają funkcjonalności
o znaczeniu krytycznym, na skutek czego brak jest możliwości wykonania operacji,
której odroczenie nie jest możliwe ze względu na bezwzględnie obowiązujące przepisy
prawne.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
Poniżej przesyłamy pytania do SWZ / sprostowanie do pytania nr 2 z 29.01.2024
Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, I. DEFINICJE, par. 1
Błąd krytyczny – Nieprawidłowe działanie Oprogramowania, które powoduje albo
całkowity brak możliwości korzystania z Oprogramowania, albo takie
ograniczenie możliwości korzystania z niego, że przestaje ono spełniać swoje
podstawowe funkcje.
Błąd niekrytyczny – Brak działania funkcji Oprogramowania opisanej
w Dokumentacji, który nie jest Błędem Krytycznym ani Awarią, ale skutkuje
uciążliwością w eksploatacji Oprogramowania dla jego użytkownika lub
użytkowników lub spadkiem wydajności działania funkcji Oprogramowania.
Błąd – Awaria, Błąd krytyczny, Błąd niekrytyczny oraz Wada Dokumentacji.
Prosimy o scalenie powyższych definicji błędów do:
Błąd krytyczny- Powoduje, że całkowicie nie działają lub nieprawidłowo działają
funkcjonalności o znaczeniu krytycznym, na skutek czego brak jest możliwości
wykonania operacji, której odroczenie nie jest możliwe ze względu na
bezwzględnie obowiązujące przepisy prawne, ale istnieje funkcjonalność w
Systemie pozwalająca na wykonanie operacji krytycznej w inny sposób.
Błąd niekrytyczny- Powoduje, że nieprawidłowo działają bądź całkowicie nie działają
inne niż krytyczne funkcje Systemu.
(...)
Zmiana na:
Prosimy o zmianę poniższych definicji błędów na:
Błąd krytyczny - Powoduje, że całkowicie nie działają lub nieprawidłowo działają
funkcjonalności o znaczeniu krytycznym, na skutek czego brak jest możliwości
wykonania operacji, której odroczenie nie jest możliwe ze względu
na bezwzględnie obowiązujące przepisy prawne, ale istnieje funkcjonalność
w Systemie pozwalająca na wykonanie operacji krytycznej w inny sposób.
Błąd niekrytyczny- Powoduje, że nieprawidłowo działają bądź całkowicie nie
działają inne niż krytyczne funkcje Systemu.
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, I. DEFINICJE, par. 1
Błąd krytyczny – Nieprawidłowe działanie Oprogramowania, które powoduje albo
całkowity brak możliwości korzystania z Oprogramowania, albo takie ograniczenie
możliwości korzystania z niego, że przestaje ono spełniać swoje podstawowe
funkcje.
Błąd niekrytyczny – Brak działania funkcji Oprogramowania opisanej
w Dokumentacji, który nie jest Błędem Krytycznym ani Awarią, ale skutkuje
uciążliwością w eksploatacji Oprogramowania dla jego użytkownika lub
użytkowników lub spadkiem wydajności działania funkcji Oprogramowania.
Błąd – Awaria, Błąd krytyczny, Błąd niekrytyczny oraz Wada Dokumentacji.
Prosimy o scalenie powyższych definicji błędów do:
Błąd krytyczny - Powoduje, że całkowicie nie działają lub nieprawidłowo działają
funkcjonalności o znaczeniu krytycznym, na skutek czego brak jest możliwości
wykonania operacji, której odroczenie nie jest możliwe ze względu na
bezwzględnie obowiązujące przepisy prawne, ale istnieje funkcjonalność
w Systemie pozwalająca na wykonanie operacji krytycznej w inny sposób.
Błąd niekrytyczny- Powoduje, że nieprawidłowo działają bądź całkowicie
nie działają inne niż krytyczne funkcje Systemu.
Błąd – Wada Oprogramowania polegająca na zachowaniu się Oprogramowania
w sposób niezgodny z opisem funkcjonalnym zawartym w:
1) Umowie wdrożeniowej, dokumentach analizy, zaakceptowanych obustronnie
protokołach ze spotkań, dokumentach projektowych, zaakceptowanych
wnioskach o zmianę, lub
2) Procedurach, przepisach źródłowych UE, przepisach krajowych stanowiących
załączniki do ww. typów dokumentów opracowanych w ramach niniejszej
Umowy w zakresie implementowanym w Systemie.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy:
Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, I. DEFINICJE, par. 1
Raport z testów – Dokument procesu testowania Poprawki programistycznej
zawierający co najmniej – w odniesieniu dla każdego Scenariusza testu - rezultat testu.
Scenariusz testu – Dokument sporządzany przez Wykonawcę udostępniany wraz
z dostarczeniem Poprawki programistycznej zawierający:
1) nazwę procesu/nazwę ścieżki;
2) szczegółową sekwencję główną z listą czynności;
3) opis sekwencji wariantowych;
4) oczekiwany rezultat testu;
5) zestawienie ról i uprawnień;
6) scenariusze w podziale na role;
7) określenie zależności od innych procesów lub czynności.
Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, § 8 SZCZEGÓŁOWE
ZOBOWIĄZANIA WYKONAWCY
Wykonawca przed dostarczeniem Poprawek programistycznych zobowiązuje się
przeprowadzać Testy podstawowe Oprogramowania, w tym dostarczać wyniki
przeprowadzanych testów dla każdego Scenariusza testów w ramach Raportu z testów.
Prosimy o:
1. zmianę definicji w par. 1 w ten sposób, aby dostarczanie Scenariuszy testów nie było
wymagane wraz z dostarczaniem Poprawek programistycznych:
Scenariusz testu – Dokument sporządzany przez Wykonawcę, na podstawie
którego Wykonawca realizuje testy wewnętrzne, przed udostępnieniem Poprawki
programistycznej, zawierający:
1) nazwę procesu/nazwę ścieżki;
2) szczegółową sekwencję główną z listą czynności;
3) opis sekwencji wariantowych;
4) oczekiwany rezultat testu;
5) zestawienie ról i uprawnień;
6) scenariusze w podziale na role;
7) określenie zależności od innych procesów lub czynności.
2. zmianę zapisu w par. 8 w ten sposób, aby dostarczanie Scenariuszy testów nie było
wymagane wraz z dostarczaniem Poprawek programistycznych:
Wykonawca przed dostarczeniem Poprawek programistycznych zobowiązuje się
przeprowadzać Testy podstawowe Oprogramowania.
W naszej opinii zamieszczanie scenariuszy wraz z Poprawkami programistycznymi jest
nadmiarowe, nadmiernie zbiurokratyzuje procesy serwisowe, wydłużając czasy obsługi,
a także zwiększając koszty.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, IV. Warunki
dostarczenia Dokumentacji, par. 3
W przypadku niedostarczenia dokumentacji użytkownika, dokumentacji użytkownika
i administracyjnej Oprogramowania Egeria w odpowiednim terminie KOWR założy
Zgłoszenie serwisowego klasy Błędu krytycznego.
W ww. punkcie prosimy o obniżenie priorytetu Błędu:
W przypadku niedostarczenia dokumentacji użytkownika, dokumentacji użytkownika
i administracyjnej Oprogramowania Egeria w odpowiednim terminie KOWR założy
Zgłoszenie serwisowe w typie Błędu (lub Błędu niekrytycznego).
Zwracamy uwagę, że w sytuacji, w której system i dokumentacja do niego istnieje, brak
dokumentacji (aktualizacji dokumentacji) nie jest krytyczny dla realizacji procesów
biznesowych. W przypadku pozostawienia zapisu jw. może dojść do sytuacji, w której
w danej chwili będzie otwartych kilka Błędów krytycznych (w tym dot. dokumentacji
i dot. oprogramowania) i błędy dot. dokumentacji zostaną szybciej obsłużone niż błędy
dot. dokumentacji, a to nie będzie korzystne dla Zamawiającego.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, Załącznik nr 2,
II. Obsługa Zgłoszeń Serwisowych Oprogramowania, par. 2, pkt 5:
Wykonawca zobowiązuje się przedstawić Zamawiającemu Warunki wykonania dla
każdego Wniosku o zmianę i Wniosku o modyfikację danych najpóźniej w ciągu tygodnia
od chwili jego rejestracji.
oraz:
Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, Załącznik nr 2, IV. Terminy
realizacji zgłoszeń, par. 4, pkt 2
a):
Wykonawca zobowiązuje się, w terminie 1 tygodnia od dnia otrzymania Wniosku
o zmianę, do przygotowania i przedstawienia KOWR Warunków wykonania
podlegających akceptacji przez Zespół ds. Umowy Opieki Serwisowej.
Warunki wykonania sporządzane dla Wniosku o zmianę zawierają w szczególności:
i. Opis zmian;
ii. Wycenę zmian w osobogodzinach;
iii. Czas (termin) realizacji.
Prosimy o zgodę na wydłużenie terminu w powyższych zapisach, odpowiednio:
Wykonawca zobowiązuje się przedstawić Zamawiającemu Warunki
wykonania dla każdego Wniosku o zmianę i Wniosku o modyfikację danych
najpóźniej w ciągu 10 Dni roboczych od chwili jego rejestracji chyba, że
strony uzgodnią inny termin.
Oraz
Wykonawca zobowiązuje się, w terminie 10 Dni roboczych od dnia
otrzymania Wniosku o zmianę, do przygotowania i przedstawienia KOWR
Warunków wykonania podlegających akceptacji przez Zespół ds. Umowy
Opieki Serwisowej. Warunki wykonania sporządzane dla Wniosku o zmianę
zawierają w szczególności:
i. Opis zmian;
ii. Wycenę zmian w osobogodzinach;
iii. Czas (termin) realizacji.
Zwracamy uwagę, że okresowo (w sezonach urlopowych, świątecznych) może być
trudność w udzieleniu odpowiedzi w terminie tygodnia.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, Załącznik nr 1, VI.
Rozbudowa Oprogramowania, par. 6.
Zwracamy uwagę, że przedstawiony proces zakłada, że Zamawiający wnioskuje
o zmiany, Wykonawca je wycenia, a Zamawiający akceptuje przedstawione przez
Wykonawcę wyceny. Możliwa jest zatem sytuacja, w której Wykonawca będzie
analizował poszczególne wnioski o zmianę, wyceniał je, co jest procesem
czasochłonnym (tym bardziej, że Obowiązkiem Wykonawcy jest zidentyfikowanie
wpływu postulowanej zmiany na wszystkie elementy Oprogramowania), a Zamawiający
nie będzie tych wycen akceptował. W takim przypadku Wykonawca nie będzie
otrzymywał wynagrodzenia z tytułu obsługi zmian (w zakresie analiz, wycen,
szacowania wpływu na wszystkie elementy). Dlatego prosimy o potwierdzenie, że dla
dużych zmian (powyżej 5 osobodni) Zamawiający będzie oddzielnie:
1. w 1. kolejności wnioskował o wykonanie analiz, wycen, szacowania wpływu
na wszystkie elementy
2. w 2. kolejności, w ramach oddzielnego zgłoszenia, zamawiał implementację
zmiany
W takim przypadku, Wykonawca będzie mógł uzyskać wynagrodzenie za wykonanie
analiz, wycen, szacowania wpływu na wszystkie elementy, pomimo braku zamówienia
implementacji zmiany.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, Załącznik nr 2, IV.
Terminy realizacji zgłoszeń, par. 4, pkt 1.
Prosimy o zmianę oczekiwanych Czasów naprawy na:
Awaria: 8 Godzin roboczych
Błąd krytyczny: 24 Godziny robocze
Błąd niekrytyczny: 10 Dni roboczych
Błąd Dokumentacji: 20 Dni roboczych
Wydłużenie Czasów naprawy obniży koszty usług serwisowych.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
„Dotyczy: Załącznik nr 8 do SWZ – Istotne Postanowienia Umowy, Załącznik nr 2,
IV. Terminy realizacji zgłoszeń, par. 4, pkt 1.
Prosimy o zmianę oczekiwanych Czasów reakcji serwisowej:
Awaria: 1 Godzina robocza
Błąd krytyczny: 2 godziny robocze
Błąd niekrytyczny: 2 godziny robocze
Błąd Dokumentacji: 2 godziny robocze
Wydłużenie Czasów reakcji serwisowej obniży koszty usług serwisowych.”
Zamawiający nie wyraża zgody na zmianę, o której mowa w pytaniu.
Pokazujemy 9 z 25 pytań. Komplet wyjaśnień — razem z załącznikami, których dotyczą — jest w dokumentacji postępowania.
