Analiza przedwdrożeniowa CRM: co zarząd powinien dostać na koniec

Typowa sytuacja: zarząd firmy handlowej ma na stole trzy oferty na CRM. Pierwsza to abonament za użytkownika z listą funkcji na cztery strony. Druga to system na zamówienie z modułem magazynu, o który nikt nie prosił. Trzecia to rozbudowa obecnego programu do faktur. Każda odpowiada na inne pytanie, więc nie da się ich porównać, a spotkanie kończy się zdaniem „weźmy tę w środku". Pół roku później handlowcy dalej trzymają oferty w arkuszu, bo system nie obsługuje wariantów, które dają klientom.

Ten tekst jest dla właściciela i zarządu firmy średniej lub większej, która planuje CRM albo ma taki, z którego zespół nie korzysta. Nie jest to rzadki przypadek: według GUS w 2025 roku oprogramowanie CRM stosowało 42,8% firm średnich (50 do 249 osób) i 71,1% dużych, czyli ponad połowa firm średnich go nie stosuje. Opisuję, co powinieneś dostać po analizie przed wdrożeniem, żeby następna decyzja była oparta na dokumentach, a nie na tym, która oferta brzmiała najlepiej.

1. Czym jest analiza przedwdrożeniowa, a czym nie jest

Analiza przedwdrożeniowa (nazywana też analizą potrzeb, analizą wymagań albo po angielsku discovery) to praca wykonywana przed wyborem albo budową systemu. Ktoś rozmawia z zarządem i z osobami, które będą w systemie pracować, przegląda obecne programy, arkusze i dane, a potem spisuje: jak firma dziś sprzedaje, jak ma sprzedawać, czego system musi pilnować i co może go wywrócić. Na koniec porównuje warianty: gotowy CRM, system na zamówienie albo rozbudowa tego, co już jest.

Analiza nie jest wyceną. Wycena wykonawcy odpowiada na pytanie „ile kosztuje to, co ja proponuję". Analiza odpowiada na wcześniejsze pytanie: „co w ogóle trzeba zbudować albo kupić". Nie jest też warsztatem sprzedażowym dostawcy, po którym dostajesz rekomendację jego produktu. Dobra analiza może skończyć się zdaniem „kupcie gotowy system i skonfigurujcie go" albo „nie róbcie teraz nic, najpierw uporządkujcie listę klientów".

To nie jest wymysł firm doradczych. Międzynarodowe stowarzyszenie analityków biznesowych IIBA opisuje ten rodzaj pracy w przewodniku BABOK (wersja 3 z 2015 roku), a normy dla inżynierii wymagań zbiera ISO/IEC/IEEE 29148. Obie opisują to samo, czego potrzebuje zarząd: zrozumieć potrzebę, spisać wymagania tak, żeby dało się je sprawdzić, rozważyć kilka rozwiązań i ocenić, które daje największą wartość.

2. Kiedy analiza ma sens, a kiedy nie

W projektach informatycznych ryzyko nie rozkłada się równo. Bent Flyvbjerg i Alexander Budzier przeanalizowali 1 471 projektów IT: średnie przekroczenie kosztów wyniosło 27%, ale co szósty projekt przekroczył koszty średnio o 200%, a harmonogram o prawie 70% (Harvard Business Review, 2011). To badanie nie dowodzi, że analiza przed wdrożeniem temu zapobiega. Pokazuje, gdzie leży ryzyko: w projektach, których zakresu nikt nie opisał na tyle dokładnie, żeby zauważyć problem przed podpisaniem umowy.

Analiza ma sens, gdy przynajmniej jedno z poniższych jest prawdą:

• Sprzedaż przechodzi przez kilka działów: handlowiec, dział techniczny, magazyn, księgowość, serwis.
• Oferty mają warianty, rabaty i wyjątki w cenniku, których nie da się opisać jednym polem „cena".
• CRM ma rozmawiać z innymi programami: programem do faktur, sklepem, BaseLinkerem, pocztą, KSeF.
• Firma raz już wdrożyła CRM i zespół wrócił do arkuszy.
• Zarząd ma kilka ofert, których nie umie porównać, bo każda opisuje inny system.
• W systemie będą dane osobowe wielu klientów i trzeba pokazać, kto ma do nich dostęp.

Analiza nie ma sensu albo może być bardzo krótka, gdy:

• Firma jest mała, sprzedaje prosty produkt, a proces mieści się w jednym lejku. Lepiej przetestować dwa albo trzy gotowe systemy w okresie próbnym.
• Produkt jest już wybrany i kupiony. Wtedy potrzebna jest konfiguracja i przeniesienie danych, a nie analiza wariantów (opisuję to na systembox.pl/uslugi/konfiguracja-systemow).
• Nikt w zarządzie nie ma czasu, żeby podjąć decyzje. Analiza bez sponsora kończy się dokumentem, którego nikt nie zatwierdzi.

3. Kto z firmy musi poświęcić czas

Najczęstszy powód słabej analizy nie leży po stronie analityka, tylko w kalendarzach. Wymagania do CRM znają ludzie, którzy sprzedają, obsługują zamówienia i wystawiają faktury. Jeśli nie znajdą czasu, analityk opisze system na podstawie rozmowy z zarządem, a zespół potem go nie przyjmie. Z mojej praktyki potrzebne są te osoby:

• Sponsor w zarządzie. Jedna osoba, która ustala cel, rozstrzyga spory między działami i odbiera wynik. Bez niej każda decyzja wraca do punktu wyjścia.
• Kierownicy działów, przez które przechodzi sprzedaż. Opisują, jak jest dziś i co ich blokuje, a potem zatwierdzają proces docelowy dla swojej części.
• Jeden lub dwóch ludzi z pierwszej linii. Najlepiej handlowiec, który najgłośniej narzeka na obecne narzędzia. Wie, co naprawdę dzieje się z ofertą po wysłaniu.
• Osoba od informatyki, wewnętrzna albo zewnętrzna. Daje listę programów i licencji, dostępy do odczytu i eksporty danych.
• Księgowość, jeśli CRM ma dotykać faktur, rozrachunków albo KSeF.
• Inspektor ochrony danych albo prawnik, jeśli firma go ma, na jedno spotkanie o danych osobowych.

4. Siedem dokumentów na koniec

Oto zestaw, który zarząd firmy średniej powinien dostać po analizie przed wdrożeniem CRM. Przy każdym dokumencie piszę, po co jest i kto go używa. Nazwy mogą być inne, ale treść powinna się pokrywać.

1. Dokument decyzji z wariantami. Po co: na kilku stronach porównuje gotowy CRM, system na zamówienie i rozbudowę obecnego programu, z plusami, ryzykami, orientacyjnym czasem i rekomendacją. Kto używa: zarząd, przy decyzji „tak, nie, który wariant".
2. Mapa procesów: jak jest i jak ma być. Po co: pokazuje drogę od zapytania klienta do faktury i serwisu, kto co robi na każdym etapie i gdzie ginie czas. Kto używa: kierownicy działów, którzy ją zatwierdzają, i wykonawca, który na niej projektuje ekrany.
3. Lista wymagań z priorytetami. Po co: każde wymaganie opisane tak, żeby dało się je sprawdzić przy odbiorze, z podziałem na „musi być w pierwszym etapie", „powinno być" i „może poczekać". Kto używa: wykonawca do wyceny, osoba odbierająca system do testów.
4. Schemat systemów i przepływu danych. Po co: jakie programy zostają, jakie dane z nich płyną do CRM i z powrotem, co trzeba przenieść ze starych arkuszy i w jakim stanie są te dane. Kto używa: Twój informatyk i wykonawca, a zarząd widzi, od czego CRM będzie zależał.
5. Lista ryzyk z właścicielami. Po co: nazwane wprost ryzyka, np. dane osobowe, uzależnienie od jednego dostawcy, słaba jakość danych, brak czasu ludzi, z osobą odpowiedzialną i sposobem ograniczenia. Kto używa: zarząd i kierownik projektu, a w części o danych osobowych także inspektor ochrony danych.
6. Plan wdrożenia w etapach. Po co: kolejność etapów, każdy z własną wartością i punktem decyzji, oraz lista rzeczy do zmierzenia przed i po wdrożeniu. Kto używa: zarząd do planu budżetu, kierownik projektu do harmonogramu.
7. Opis zakresu dla wykonawców. Po co: wersja dokumentów, którą możesz wysłać kilku wykonawcom i dostać porównywalne oferty, bez tajemnic firmy, które nie są potrzebne do wyceny. Kto używa: zarząd albo osoba od zakupów, a potem wykonawcy.

5. Jak odebrać analizę: pięć pytań kontrolnych

Zarząd nie musi znać się na specyfikacjach, żeby ocenić, czy analiza jest dobra. Wystarczy pięć pytań zadanych przy odbiorze:

• Czy inny wykonawca wyceni wdrożenie z tych dokumentów bez dodatkowego spotkania? Jeśli nie, dokument jest za ogólny.
• Czy każde wymaganie z pierwszego etapu da się sprawdzić w dniu odbioru? „Szybki" nie da się sprawdzić, „oferta PDF generuje się z pozycji katalogu z aktualnym cennikiem" tak.
• Czy wśród wariantów jest gotowy system albo odłożenie projektu? Jeśli jest tylko jeden wariant, dostałeś ofertę.
• Czy każde ryzyko ma nazwisko osoby, która je pilnuje?
• Czy wiesz, co zmierzysz przed wdrożeniem i po nim, żeby ocenić, czy system coś zmienił?

6. Jak przebiega analiza krok po kroku

1. Rozmowa z zarządem o celu i granicach. Co ma się zmienić, jak to zmierzymy, czego analiza nie obejmuje. Wynik: jedna strona celów i zakresu, zatwierdzona przez sponsora.
2. Przegląd tego, co jest. Programy, arkusze, wzory ofert i umów, eksporty danych. Pracuję na kontach, które nadaje firma, domyślnie tylko do odczytu. Wynik: lista systemów, licencji i próbka danych z oceną ich stanu.
3. Rozmowy z działami. Sprzedaż, obsługa zamówień, magazyn, księgowość, serwis, osobno i razem tam, gdzie procesy się stykają. Wynik: mapa procesów „jak jest", z miejscami, w których ginie czas.
4. Proces docelowy i wymagania. Wspólnie z kierownikami działów ustalamy, jak ma być, i spisujemy wymagania z priorytetami. Wynik: lista wymagań zatwierdzona przez właścicieli procesów.
5. Warianty i architektura. Porównanie gotowego systemu, systemu na zamówienie i rozbudowy obecnego, schemat systemów i danych. Wynik: dokument decyzji z rekomendacją.
6. Ryzyka i plan etapów. Wynik: lista ryzyk z właścicielami i plan wdrożenia z punktami decyzji.
7. Odbiór z zarządem. Omawiamy dokumenty i pięć pytań kontrolnych. Wynik: decyzja: wdrażamy wybrany wariant, zmieniamy zakres albo kończymy na gotowym dokumencie.

7. Jak długo trwa i od czego zależy

Analiza przed wdrożeniem CRM w firmie średniej trwa u mnie zwykle od dwóch do sześciu tygodni. Rozpiętość jest duża, bo zależy od rzeczy, które da się przewidzieć dopiero po pierwszej rozmowie:

• Liczba działów i osób do rozmów. Jeden dział sprzedaży to co innego niż sprzedaż, dział techniczny, magazyn i serwis.
• Liczba programów do połączenia i to, czy mają udokumentowany sposób wymiany danych.
• Stan danych. Jedna lista klientów to prosty przegląd, trzy arkusze z duplikatami wymagają osobnej oceny.
• Tempo decyzji po stronie firmy. Każdy tydzień czekania na odpowiedź sponsora to tydzień analizy dłużej.
• Dane osobowe i wymagania bezpieczeństwa, które trzeba opisać przed wyborem wariantu.
• Ocena istniejącego systemu albo kodu, jeśli jednym z wariantów jest jego rozbudowa.

Skąd to wiem: jestem 13 lat w IT i od 2017 roku buduję systemy w Laravel. W latach 2020 do 2023 kierowałem działem IT firmy e-commerce i rozbudowałem go z 2 do 12 osób, więc znam też drugą stronę: zespół, który dostaje zakres do zbudowania. W 2026 roku zaprojektowałem i zbudowałem od podstaw CRM sprzedaży dla firmy z branży OZE (nazwy nie podaję). Model danych, listę ról i plan etapów przygotowuję, zanim powstanie pierwszy ekran.

8. Czy po analizie muszę zlecić wdrożenie temu samemu wykonawcy?

Nie. Dokumenty z analizy powinny być napisane tak, żeby mógł je wykorzystać dowolny wykonawca albo Twój dział IT. Po to jest siódmy dokument, opis zakresu dla wykonawców. Jeśli analityk nie zgadza się, żebyś pokazał jego pracę innym firmom, analiza była w praktyce częścią jego oferty.

Mówię to wprost, bo sam buduję systemy CRM i mam w tym interes. Dlatego przy analizie trzymam się trzech zasad: wariant z gotowym systemem jest w dokumencie decyzji zawsze, a jeśli uznam go za lepszy, piszę to w rekomendacji; analizę wyceniam i rozliczam osobno od wdrożenia; po odbiorze możesz zakończyć współpracę z gotowymi dokumentami.

Dwie rzeczy warto wpisać do umowy na analizę. Pierwsza: że możesz przekazać dokumenty innym wykonawcom w celu uzyskania ofert i realizacji wdrożenia. Druga: kto ma dostęp do danych firmy w czasie analizy i co się z nimi dzieje po jej zakończeniu. Nie jestem prawnikiem; sposób zapisu tych postanowień warto uzgodnić ze swoim prawnikiem.

9. Ile to kosztuje

Nie mam cennika projektów, bo zakres, liczba godzin i cena zależą od firmy. Doradztwo i zespół IT rozliczam w jednej z trzech form: stała kwota za etap analizy przed wdrożeniem, pakiet miesięczny przy stałym doradztwie dla zarządu albo pakiet na czas budowy zespołu, aż do przekazania prowadzenia Twojej firmie. Po każdym etapie możesz zakończyć współpracę z gotowym dokumentem. Kwotę podaję po pierwszej rozmowie, kiedy znam zakres.

Na kwotę wpływa to samo, co na czas: liczba działów i osób do rozmów, liczba programów, stan danych i to, czy trzeba ocenić istniejący system. Proces wyceny opisuję na systembox.pl/jak-wyceniam. Pierwsza rozmowa, 30 minut, jest bezpłatna i bez zobowiązań.

Nie obiecuję zwrotu z inwestycji, bo nie znam Twoich procesów. Analiza nie gwarantuje udanego wdrożenia. Daje zarządowi dokumenty, na podstawie których może podjąć decyzję, porównać oferty i wiedzieć, co zmierzyć przed i po.

10. Skąd te twierdzenia

Opis analizy wymagań opiera się na przewodniku BABOK Guide v3 stowarzyszenia IIBA (struktura i zadania ze stron IIBA, bez cytowania płatnej treści) oraz na opisie normy ISO/IEC/IEEE 29148:2018 ze strony ISO. Dane o CRM w polskich firmach pochodzą z publikacji GUS „Społeczeństwo informacyjne w Polsce w 2025 r." (tablica 22, firmy od 10 osób), a liczby o przekroczeniach budżetów z artykułu Flyvbjerga i Budziera w Harvard Business Review z 2011 roku, podlinkowanego w wersji autorskiej. Zasady RODO streszczam z tekstu rozporządzenia w EUR-Lex. Listę siedmiu dokumentów, osoby z firmy, czas trwania i pięć pytań kontrolnych opisuję z własnej praktyki i z przeglądu opisów usług analizy przedwdrożeniowej na polskim rynku. Nazw firm usługowych, które robią podobne analizy, celowo nie podaję. Nie przytaczam też popularnych w sieci statystyk o skuteczności projektów z walidacją wymagań, bo znam je tylko z cytatów i nie dotarłem do badania źródłowego.

Podsumowanie

Analiza przedwdrożeniowa CRM jest warta tyle, ile dokumenty, które z niej zostają. Trzy decyzje do podjęcia przed jej zamówieniem: kto w zarządzie jest sponsorem i ma czas na decyzje, które osoby z działów dostaną w kalendarzu spotkania, i czy w umowie jest zapis, że wynik możesz pokazać dowolnemu wykonawcy. Przy odbiorze sprawdź siedem dokumentów i pięć pytań kontrolnych. Jeśli chcesz sprawdzić, czy w Twojej firmie analiza ma sens i jak długo by trwała, umów rozmowę; pierwsze 30 minut jest bezpłatne i bez zobowiązań.

FAQ: najczęstsze pytania