Po terminiePrzetarg nieograniczony · PN627484-2026
Dostawa systemu ERP/CRM i szyny danych – Tychy
Rejonowe Przedsiębiorstwo Wodociągów i Kanalizacji w Tychach S.A.0 aktualnych · 19 w archiwum·NIP 6460010322·śląskie
Składanie ofert: 4 listopada 2026 · Wartość szacunkowa: 2 145 244 zł · Wadium: 64 000 zł
Przedmiot zamówienia
AI- Zintegrowany system ERP/CRM wraz z modułami dodatkowymi: dostawa, wdrożenie, konfiguracja, migracja danych i przekazanie do eksploatacji w celu obsługi kluczowych procesów biznesowych Zamawiającego.
- Szyna danych ESB/API: zaprojektowanie, wdrożenie, konfiguracja i przekazanie do eksploatacji jako centralny punkt interoperacyjnej wymiany danych.
- Integracje z systemami Zamawiającego: zapewnienie wymiany danych pomiędzy wdrożonym zintegrowanym środowiskiem a funkcjonującymi u Zamawiającego systemami.
- Instruktaż: niezbędny instruktaż dla użytkowników umożliwiający przekazanie całego środowiska do eksploatacji.
Trudność: wysoka
Kompleksowe, silnie zintegrowane wdrożenie obejmujące migrację danych, centralną szynę integracyjną oraz interoperacyjność z wieloma istniejącymi systemami Zamawiającego.
Terminy realizacji
Czas na realizację (termin wykonania)
do 2 listopada 2027 r.
do 2 listopada 2027 r.
Wymagany okres gwarancji
min. 60 miesięcy (od protokołu odbioru końcowego)
min. 60 miesięcy (od protokołu odbioru końcowego)
Warunki udziału
AI1Sytuacja finansowa — środki finansowe lub zdolność kredytowa na kwotę co najmniej 1 000 000,00 zł
2Doświadczenie — w okresie ostatnich 3 lat (lub krótszym okresie prowadzenia działalności) należycie wykonał zamówienia polegające na dostawie, wdrożeniu, konfiguracji i uruchomieniu produkcyjnym systemu klasy ERP lub ERP/CRM, przy czym jednym z nich był system klasy ERP lub ERP/CRM, o łącznej wartości nie mniejszej niż 1 000 000,00 zł brutto w ramach maksymalnie 4 odrębnych zamówień; łącznie obejmujące wdrożenie systemu ERP/CRM obejmującego co najmniej 3 z 5 obszarów funkcjonalnych, migrację danych z co najmniej jednego systemu źródłowego oraz integrację z co najmniej trzema systemami zewnętrznymi lub dziedzinowymi przy wykorzystaniu standardowych mechanizmów integracyjnych (API, WebService, ESB, API Gateway lub równoważne)
Pozostałe 2 warunki po założeniu darmowego konta.
Kryteria wyboru oferty
AIWagi punktowe, według których zamawiający oceni oferty.
Cena
80%
Termin realizacji zamówienia0–20 pkt wg tabeli skrócenia terminu
20%
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Brak limitu odpowiedzialności
§ 12 ust. 18 i § 14 ust. 10 wzoru umowy: Zamawiający odmawia limitu odszkodowawczego i wyłączenia utraconych korzyści.
Równoległe roszczenia
§ 12 ust. 6 wzoru umowy: rękojmia na cały okres gwarancji.
Kara za zmiany prawa
§ 14 ust. 2 pkt 7 wzoru umowy: kara za niedostosowanie systemu do zmian przepisów (VAT, JPK, KSeF).
Nielimitowane konsultacje
§ 12 ust. 12 pkt 4 wzoru umowy: Zamawiający potwierdza nielimitowane konsultacje w okresie gwarancji.
Kary i sankcje
AI- Wadium: 64 000,00 zł (pieniądz, gwarancja bankowa/ubezpieczeniowa, poręczenie PARP)
- Zabezpieczenie należytego wykonania: 3% ceny brutto (pieniądz, poręczenie bankowe/SKOK, gwarancja bankowa/ubezpieczeniowa, poręczenie PARP)
- Zwrot zabezpieczenia: 70% w 30 dni od odbioru końcowego; 30% na roszczenia z tytułu gwarancji, zwrot do 15 dnia po upływie gwarancji
Pozostałe 1 zapis o karach po założeniu darmowego konta.
Pytania i odpowiedzi
248Wyodrębnione z wyjaśnień treści SWZ.
1W OPZ przewidziano bardzo szeroki zakres integracji obejmujący m.in. GIS, SCADA, systemy zdalnego odczytu wodomierzy, Węzeł Krajowy, e-Doręczenia, KSeF, Active Directory, Exchange, telematykę pojazdów, gospodarkę flotową, operatorów płatności, systemy odczytowe, platformy zakupowe oraz inne systemy dziedzinowe, etc. Czy Zamawiający dopuści podział integracji na grupę 1) integracji krytycznych oraz 2) pozostałych a następnie zróżnicowanie wymagań w zakresie ich wdrożenia? Przykładowo integracje krytyczne realizowane byłyby zgodnie z bieżącymi wymaganiami. Integracje pozostałe mogłyby stanowić grupę opcjonalną, osobno wycenioną, od realizacji której Zamawiający mógłby odstąpić w przypadku potencjalnego przekroczenia kosztów. Alternatywnie integracje pozostałe mogłyby też zostać dopuszczone do realizacji w ostatniej kolejności, bez rygoru związanego z okresem stabilizacji systemu i – w razie takiej konieczności – również z wykorzystaniem części puli 1000 godzin.
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
2Pytanie nr 2: Modyfikacja kryterium technicznego (warunku udziału w pośtępowaniu)
Odwołanie do dokumentacji: SWZ – Rozdział X pkt 4 lit. a (Warunki udziału w pośtępowaniu – zdolnośc techniczna lub zawodowa).
Treśc wniośku Wykonawcy:
„Wnioskujemy o wykreślenie z treści warunku tekstu „... o łącznej wartości nie mniejszej niż 1 000,000,00 zł brutto (zrealizowane w ramach maksymalnie 4 odrębnych zamówień)”. W ocenie Wykonawcy doświadczenie w realizacji dostaw systemów ERP stanowi wystarczający miernik zdolności do wykonania zamówienia. Dodatkowy wymóg osiągnięcia określonego progu wartościowego nie pozostaje w bezpośrednim związku z zakresem funkcjonalnym i organizacyjnym wykonanych dostaw, a jednocześnie może prowadzić do ograniczenia konkurencji poprzez wyeliminowanie wykonawców posiadających adekwatne doświadczenie projektowe.”
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.
3Pytanie nr 3: Zakreś przekazywanych kodow zrodłowych i prawa do modyfikacji
Odwołanie do dokumentacji: Załącznik nr 1 do SWZ (OPZ) – Rozdział 20.3 oraz Załącznik nr 8 do SWZ (Wzor Umowy) – § 9 uśt. 1, 3, 12.
Treśc wniośku Wykonawcy:
„W zmodyfikowanej wersji dokumentacji Zamawiający wskazuje, że „Wykonawca jest zobowiązany przekazać Zamawiającemu kody źródłowe do komponentów oprogramowania dedykowanych dla systemu Zamawiającego, a wytworzonych w toku realizacji zamówienia (obejmujących w szczególności: adaptery integracyjne, mostki, dedykowane wydruki, szablony oraz konfiguracje procesów workflow)”. Jednocześnie jednak dalej wskazano, że „Z chwilą zakończenia lub rozwiązania umowy Zamawiający nabywa prawo do modyfikacji oprogramowania wytworzonego w toku realizacji Zamówienia.” Prosimy o jednoznaczne potwierdzenie, że pojęcie „oprogramowanie wytworzone w toku realizacji Zamówienia” odnosi się wyłącznie do dedykowanych komponentów wskazanych w poprzednich akapitach i nie obejmuje standardowych komponentów systemu ERP/CRM, platformy ESB, bibliotek, komponentów open source czy produktów własnych Wykonawcy.”
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.
4Pytanie nr 4: Odpowiedzialnośc za integracje z śyśtemami podmiotow trzecich
Odwołanie do dokumentacji: Załącznik nr 1 do SWZ (OPZ) – Rozdziały 19.1, 19.5, 20, 25
oraz Załącznik nr 8 do SWZ (Wzor Umowy) – § 12 uśt. 16-17, § 15 uśt. 1 pkt lit. d.
Treśc wniośku Wykonawcy:
„Wnosimy o jednoznaczne potwierdzenie, także w kontekście zapisów projektu Umowy
dotyczących gwarancji (par. 12, ust. 16), że Wykonawca nie ponosi odpowiedzialności za:
niedostępność systemów lub usług podmiotów trzecich; brak współpracy dostawców tych
systemów; zmiany interfejsów API, sposobów autoryzacji lub protokołów komunikacyjnych
dokonywane przez dostawców po odbiorze wdrożenia; wady lub ograniczenia funkcjonalne
występujące po stronie integrowanych systemów.”
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
Historia zmian
19.06.2026 — ogłoszenie o zamówieniu
17.07.2026 — sprostowanie
24.07.2026 — sprostowanie
03.08.2026 — sprostowanie
10.08.2026 — sprostowanie
24.08.2026 — sprostowanie
01.09.2026 — sprostowanie
11.09.2026 — sprostowanie
18.09.2026 — sprostowanie
28.09.2026 — sprostowanie
12.10.2026 — sprostowanie
04.11.2026 — upływ terminu składania ofert