Checklista kupującego: co sprawdzić zanim wybierzesz integratora IT
Wybór integratora systemów to decyzja, którą trudno cofnąć w połowie projektu. Ten artykuł pokazuje, jak ocenić oferty bez gubienia się w technikaliach — z listą pytań, czerwonymi flagami i tym, co musi znaleźć się w umowie.
Jak kupować integrację systemów bez błędów
Zanim zaczniesz szukać — co musisz wiedzieć o własnym procesie
Najczęstszy błąd kupującego to zlecenie integracji bez opisania procesu, który ma integracja obsługiwać. Integrator dostaje brief: „połącz CRM z ERP”, ale nie wie, jaki jest przepływ zamówień, kto może anulować, co dzieje się z wyjątkami i jakie są wymagania na monitoring. Efekt: oferta jest podana w złej warstwie abstrakcji — za techniczna albo za ogólna, i w obu przypadkach niezwiązana z Twoim problemem.
Przed wysłaniem briefu warto odpowiedzieć na pięć pytań: Co konkretnie się zmieni po integracji w codziennej pracy zespołu? Jakie dane muszą przepływać i w jakim kierunku? Ile wyjątków od standardowego procesu obsługujesz ręcznie w tygodniu? Jakie masz wymagania dotyczące dostępności i SLA? Kto wewnętrznie będzie właścicielem procesu po wdrożeniu? Odpowiedzi na te pytania powinny znaleźć się w briefie — nie oczekuj, że integrator je wyciągnie z Ciebie bez przygotowania.
Dobry integrator zaczyna od analizy procesu, nie od prezentacji technologii — jeśli na pierwszym spotkaniu słyszysz głównie o stacku, to sygnał ostrzegawczy.
12 pytań, które warto zadać każdemu kandydatowi
Pierwsze cztery pytania dotyczą podejścia do projektu: Czy zaczynacie od warsztatu procesowego czy od wyboru technologii? Jak opisujecie obsługę wyjątków biznesowych w projekcie? Jakie jest Wasze SLA po go-live i co się dzieje, gdy integracja nie działa? Kto jest właścicielem kodu i dokumentacji po zakończeniu projektu?
Kolejne pytania dotyczą doświadczenia i umowy: Czy możecie pokazać przykład podobnego projektu z obsługą błędów i monitoringiem? Jak wygląda Wasz proces zarządzania zmianą zakresu? Co się dzieje, jeśli musimy przerwać projekt w połowie? Jak wygląda proces przekazania projektu wewnętrznemu zespołowi IT po wdrożeniu? Oraz pytania o bezpieczeństwo: Jak przechowujecie klucze API i poświadczenia do naszych systemów? Jakie są Wasze standardy bezpieczeństwa i czy podpiszecie umówę powierzenia danych? Jak wygląda Wasz model monitoringu i co nam raportujecie regularnie? Czy oferujecie dokumentację techniczną procesu, nie tylko kod?
- Warsztat procesowy czy od razu technologia?
- Jak opisują obsługę wyjątków?
- SLA po go-live i konsekwencje jego braku
- Własność kodu i dokumentacji po projekcie
- Przykład podobnego projektu z obsługą błędów
- Zarządzanie zmianą zakresu i cennik zmian
- Możliwość wyjścia z projektu w połowie
- Bezpieczeństwo poświadczeń i umowa powierzenia
Czerwone flagi w propozycjach i rozmowach sprzedażowych
Kilka sygnałów, które powinny Cię zatrzymać przed podpisaniem umowy. Oferta nie zawiera opisu obsługi wyjątków — to oznacza, że integrator zakłada, że wszystko zawsze działa poprawnie, co jest nierealistyczne. Słyszysz „to standardowe rozwiązanie, które wdrażamy u wszystkich” — dobra integracja jest zawsze dostosowana do Twojego procesu, bo Twój proces jest unikalny. Integrator chce zintegrować wszystko naraz od razu — dobry projekt idzie etapami, zaczynając od priorytetowego odcinka.
Inne czerwone flagi: brak pytań o to, jak Twój proces wygląda dziś i co ma się zmienić; oferta nie wspomina o monitoringu ani o tym, kto reaguje na błędy; integrator nie wie, jak wygląda Twój ERP lub CRM od środka (nie ma wcześniejszego doświadczenia z tymi systemami). Szczegółowo o tym, jakich błędów, które kosztują po wdrożeniu można unikać na etapie wyboru integratora, piszemy w osobnym artykule.
Co powinna zawierać dobra umowa na integrację systemów
Dobra oferta i dobra umowa różnią się od siebie. Oferta może być ogólna — umowa musi być konkretna. Trzy elementy, których nie może brakować: opis zakresu z przykładami (nie tylko listą systemów, ale z opisem konkretnych przepływów, danych i wyjątków), klauzula zarządzania zmianami (co się dzieje, gdy w trakcie projektu pojawi się nowy wymóg — kto decyduje, jak jest wyceniane), klauzula własności i wyjścia (czy kod jest Twój, czy masz dostęp do dokumentacji i czy możesz zmienić dostawcę bez utraty kluczowych elementów projektu).
Dodatkowo: definicja SLA z konsekwencjami (nie tylko opisem, ile godzin na reakcję, ale też co się dzieje, gdy SLA nie jest dotrzymane), zakres monitoringu i raportowania oraz jasność dotycząca umowy powierzenia danych osobowych. Jeśli chcesz, możesz zacząć od rozmowy o harmonogramie i etapach projektu integracyjnego zanim wyślesz brief.
Jak porównać trzy oferty bez gubienia się w technikaliach
Stwórz prostą matrycę decyzyjną z pięcioma kryteriami i oceń każdą ofertę w skali 1–5: (1) Głębokość rozumienia Twojego procesu — czy propozycja odnosi się do Twoich wyjątków i specyfiki; (2) Obsługa błędów i wyjątków — czy jest opisana, czy zakładana; (3) SLA i monitoring po go-live — konkretny, z konsekwencjami czy ogólny; (4) Własność kodu i dokumentacji — czy jasna; (5) Ścieżka wyjścia — czy masz plan B bez utraty projektu.
Cena to szóste kryterium, ale nie pierwsze. Najtańsza oferta, która nie odpowiada na pierwsze cztery kryteria, jest de facto najdroższa — bo wdrożenie będzie wymagało napraw, wydłużeń i dodatkowych prac. Pamiętaj też, żeby przed podpisaniem umowy sprawdzić referencje — nie marketingowe case studies, ale możliwość rozmowy z poprzednim klientem o tym, jak wyglądał projekt po go-live i jak reagował zespół integratora na problemy. Możesz też zacząć od bezpłatną analizą swojego procesu.