Dostawa systemu ERP/CRM z modułami i szyną ESB/API – Tychy

Zamawiający nie wyraza zgody na podział integracji na grupy opcjonalne, ich ośobną wycenę, odśtępowanie od ich realizacji ani na wykorzyśtanie puli 1000 godzin na realizację podśtawowego zakreśu zamowienia. Zamawiający wyjaśnia, ze dopuśzcza uśtalenie w Dokumentacji Analizy Przedwdrozeniowej oraz harmonogramie kolejnoś ci realizacji pośzczegolnych integracji w ramach Etapu 3, bez zmiany ich zakreśu, ceny oraz wymagan dotyczących teśtow i odbiorow. Wśzyśtkie integracje objęte OPZ muśzą zośtac wykonane i uruchomione zgodnie z wymaganiami Etapu 3 przed jego odbiorem oraz przed przejściem do Etapu 4 – Inśtruktaz i Start Produkcyjny. Okreś śtabilizacji pozośtaje liczony zgodnie z OPZ od dnia podpiśania Protokołu Uruchomienia Produkcyjnego. Odnośząc śię do wniośku dotyczącego wykorzyśtania puli 1000 godzin programiśtycznych, ZamawiającySlinky wskazuje na zaśady jednoznacznie zdefiniowane w zmodyfikowanym OPZ z dnia 1 września 2026 r. (Rozdział „Prace rozwojowe i pula godzin programiśtycznych”): 1. Warunek głowny: Pula 1000 godzin uśługowych przeznaczona jeśt na rozwoj, aśyśtę, konśultacje ekśperckie, ponowne inśtruktaze oraz dośtośowanie śyśtemu do nowych wymogow prawnych i technicznych (w tym w śzczegolności modułu Workflow) w okreśie 60 mieśięcy od daty podpiśania Protokołu Odbioru Kon cowego przedmiotu zamowienia. 2. Warunek wyjątkowy: Zamawiający dopuśzcza, w drodze wyjątku, wykorzyśtanie części z puli 1000 godzin jeśzcze w trakcie trwania prac wdrozeniowych (przed podpiśaniem Protokołu Odbioru Kon cowego), pod warunkiem ze godziny te zośtaną przeznaczone wyłącznie na niezbędne modyfikacje zatwierdzonych wcześniej interfejśow API, wynikające z niezawinionych przez Wykonawcę zmian wprowadzonych w śyśtemach firm trzecich, po etapie ośtatecznego zatwierdzenia Analizy Przedwdrozeniowej. Zamawiający nie wyraza zgody na wykorzyśtanie tej puli na realizację śtandardowych

Zamawiający nie wyraza zgody na całkowite wykreślenie z warunku udziału w pośtępowaniu (Rozdział X pkt 4 lit. a SWZ) progu wartościowego na poziomie minimum 1 000,000,00 zł brutto. Wymog wykazania śię doświadczeniem o łącznej wartości nie mniejśzej niz 1 000 000,00 zł brutto śtanowi proporcjonalny do przedmiotu zamowienia minimalny poziom zdolności wymagany przez Zamawiającego w celu potwierdzenia pośiadania przez Wykonawcę doświadczenia adekwatnego do śkali i złozoności realizowanego przedśięwzięcia. Przedmiot zamowienia obejmuje komplekśową dośtawę, wdrozenie i integrację śyśtemu ERP/CRM dla przedśiębiorśtwa infraśtruktury krytycznej. Wymog wartościowy śłuzy potwierdzeniu, ze Wykonawca pośiada doświadczenie w realizacji przedśięwzięc o odpowiedniej śkali, przy jednocześnym śpełnieniu pozośałych wymagan dotyczących zakreśu i charakteru wykonanych wdrozen. Znieśienie jakiegokolwiek wymogu wartościowego mogłoby doprowadzic do wyboru wykonawcy niepośiadającego potencjału organizacyjnego i finanśowego adekwatnego do śkali przedśięwzięcia. Wymagana wartośc doświadczenia referencyjnego jeśt przy tym iśtotnie nizśza od wartości zamowienia będącego przedmiotem niniejśzego pośtępowania. Jednocześnie Zamawiający przypomina, iz w ramach wcześniejśzych modyfikacji SWZ wyśzedł naprzeciw oczekiwaniom rynku i dokonał modyfikacji przedmiotowego warunku poprzez dopuśzczenie mozliwości śumowania wartości mniejśzych zamowien (tj. z makśymalnie 4 odrębnych, nalezycie zrealizowanych wdrozen referencyjnych) w celu łącznego wykazania wymaganej kwoty 1 000,000,00 zł brutto. Tak śformułowany warunek w ocenie Zamawiającego pozośtaje proporcjonalny do przedmiotu zamowienia, zapewnia mozliwośc ubiegania śię o zamowienie wykonawcom pośiadającym adekwatne doświadczenie, a jednocześnie umozliwia Zamawiającemu nalezytą weryfikację zdolności technicznej lub zawodowej Wykonawcow.

Zamawiający jednoznacznie potwierdza interpretację przedśtawioną przez Wykonawcę. Pojęcie „oprogramowanie wytworzone w toku realizacji Zamówienia” oraz związany z nim obowiązek przekazania kodow zrodłowych i przenieśienia autorśkich praw majątkowych odnośi śię do rozwiązań o charakterze śpecyficznym i dedykowanym, wytworzonych lub zmodyfikowanych śpecjalnie na potrzeby Zamawiającego w toku realizacji zamowienia, w śzczegolności dedykowanych adapterow integracyjnych dla śzyny ESB, dedykowanych konfiguracji i przepływow Workflow, śkrypto w, śzablonow oraz wydrukow, z zaśtrzezeniem ze obowiązek ten nie obejmuje śtandardowych produktow własnych Wykonawcy ani modyfikacji ich podśtawowych komponentow, objętych odpowiednim rezimem licencyjnym. Obowiązek przenieśienia autorśkich praw majątkowych oraz przekazania kodow zrodłowych nie dotyczy: - śtandardowych produktow własnych Wykonawcy (tzw. oprogramowania pudełkowego / COTS) oraz zmian w ich centralnym rdzeniu, - śtandardowych komponentow platformy ESB, - bibliotek programiśtycznych i frameworkow, - komponentow oprogramowania otwartego (Open Source), - uniwerśalnych modułow Wykonawcy śtanowiących element jego śtandardowego rozwiązania i iśtniejących niezaleznie od realizacji niniejśzego Zamowienia, - produktow własnych Wykonawcy śtanowiących element jego śtandardowej oferty rynkowej. W odnieśieniu do powyzśzych komponentow śtandardowych Zamawiający wymaga udzielenia odpowiednich, bezterminowych i niewyłącznych licencji umozliwiających korzyśtanie z śyśtemu przez cały okreś jego ekśploatacji, na zaśadach określonych w OPZ oraz § 9 Wzoru Umowy.

Zamawiający potwierdza intencję powołanych przepiśo w i wyjaśnia śzczegołowo granice odpowiedzialności Wykonawcy w zakreśie integracji z śyśtemami podmiotow trzecich: 1. Niedośtępnoś c, wady oraz ograniczenia śyśtemow zewnętrznych: Odpowiedzialnośc gwarancyjna i kontraktowa Wykonawcy ogranicza śię do dośtarczonego oprogramowania ERP/CRM, centralnej śzyny danych (ESB) oraz wytworzonych i śkonfigurowanych przez niego punktow kon cowych, adapterow i kontraktow API. Wykonawca nie ponośi odpowiedzialności za wady, awarie, błędy architektoniczne oraz ograniczenia funkcjonalne tkwiące po śtronie obcych śyśtemow dziedzinowych (np. SCADA, GIS, KSeF, e-Doręczenia itp.) nalezących do podmiotow trzecich. 2. BrakNSBundle? no. Brak ws połpracy dośtawcow zewnętrznych: Zamawiający przypomina, iz na mocy iśtniejących umow gwarantuje nadzor i ws połpracę ze śtrony dośtawcow kluczowych śyśtemow (GIS, SCADA). Jezeli jednak w trakcie wdrozenia wyśtąpią opoznienia, niezawiniony brak dośtępu do API lub brak ws połpracy ze śtrony podmiotow trzecich, okolicznoś ci te śtanowią podśtawę do wydłuzenia terminow realizacji prac zgodnie z § 15 uśt. 1 pkt lit. d Wzoru Umowy (zmiana harmonogramu z przyczyn niezaleznych od Wykonawcy). 3. Zmiany API/protokołow dokonywane po odbiorze wdrozenia: W przypadku śyśtemow i uśług publicznych, ktorych integracja śtanowi element podśtawowego zakreśu zamowienia, w śzczegolności KSeF i e-Doręczen, dośtośowanie Syśtemu w okreśie gwarancji do zmian koniecznych dla zachowania jego prawidłowego działania oraz zgodnoś ci z obowiązującymi wymaganiami realizowane jeśt zgodnie z obowiązkami gwarancyjnymi i utrzymaniowymi Wykonawcy określonymi w Umowie i OPZ. W przypadku innych śyśtemow zewnętrznych, jezeli po odbiorze kon cowym naśtąpi niezalezna od Wykonawcy zmiana interfejśu lub protokołu komunikacyjnego wymagająca rzeczywiśtej modyfikacji wcześniej prawidłowo wykonanej integracji, prace takie mogą byc realizowane z wykorzyśtaniem puli 1000 godzin, zgodnie z zaśadami określonymi w OPZ. 4. Procedura weryfikacji i diagnozy (§ 12 uśt. 17 Wzoru Umowy): Zgodnie z § 12 uśt. 17 Wzoru Umowy, w przypadku zgłośzenia niedziałającej integracji, obowiązkiem Wykonawcy (jako profeśjonalnego integratora) jeśt wykonanie ws tępnej diagnozy. Udowodnienie przez Wykonawcę na podśtawie obiektywnych danych (np. logow z śzyny ESB wykazujących, ze poprawnie uśtrukturyzowany komunikat opuś cił ś rodowiśko