Większość opublikowanych materiałów na temat tworzenia dedykowanych systemów CRM pochodzi od kogoś zainteresowanego konkretną odpowiedzią. Dostawcy platform abonamentowych publikują przewodniki tłumaczące, że budowanie jest drogie, ryzykowne i zbędne. Firmy programistyczne publikują przewodniki tłumaczące, że gotowe platformy są sztywne, przepłacone i wypełnione funkcjami, których nikt nie używa. Oba obozy mają po trochu racji. Żaden z nich nie daje dyrektorowi IT ani dyrektorowi finansowemu tego, czego faktycznie potrzebuje: precyzyjnego opisu, jak wygląda projekt dedykowanego CRM, ile kosztuje w realistycznych przybliżeniach i w jakich konkretnych warunkach daje lepsze wyniki niż zakup gotowca.
Ten artykuł jest takim opisem. Obejmuje pełny cykl projektu od analizy wymagań po utrzymanie, realistyczne ramy kosztowe z aktualnymi punktami odniesienia oraz ustrukturyzowany model decyzyjny dla dylematu budowa kontra zakup. Celem nie jest argumentowanie na rzecz żadnej z tych ścieżek. Celem jest danie osobom podejmującym tę decyzję dokładnego obrazu tego, czym każda z nich faktycznie jest.
Dedykowany system CRM to aplikacja do zarządzania relacjami z klientami zbudowana specjalnie dla jednej organizacji, na bazie kodu, którego ta organizacja jest właścicielem, zaprojektowana wokół specyficznego modelu danych tej organizacji, jej procesu sprzedaży, wymagań integracyjnych i logiki biznesowej. To nie jest pudełkowy produkt skonfigurowany tak, żeby pasował do procesu; to system szyty na miarę, w którym każdy element aplikacji odzwierciedla świadomą decyzję podjętą dla konkretnego kontekstu.
Definicja ma znaczenie, bo wyrażenie „dedykowany CRM” obejmuje w praktyce dość szeroki zakres rozwiązań. Mocno skonfigurowana instancja Salesforce nie jest dedykowanym CRM; to po prostu produkt z określonymi rozszerzeniami. Ta różnica ma realne konsekwencje dla własności, kosztu i elastyczności oprogramowania. System CRM zbudowany na platformie low-code, takiej jak Mendix czy OutSystems, jest bliższy dedykowanemu w pewnych aspektach, ale wciąż wiąże się z zależnością od platformy i opłatami licencyjnymi. CRM zbudowany od podstaw w Javie, .NET lub Oracle APEX, bez żadnej leżącej u jego podstaw płatnej platformy zewnętrznej, to w ścisłym sensie system w pełni dedykowany. Wszystkie trzy kategorie mają różne profile kosztowe, różne struktury własności i różne charakterystyki ryzyka, a mylenie ich to jedno z głównych źródeł rozbieżnych oczekiwań w rozmowach o dedykowanych systemach CRM.
W tym artykule przez „dedykowany CRM” rozumiemy trzecią kategorię: system zbudowany na stosie technologicznym kontrolowanym przez organizację, bez bieżącej zależności licencyjnej od dostawcy platformy CRM. Większość tego, co opisujemy poniżej, ma zastosowanie w różnym stopniu do pierwszych dwóch kategorii, ale ramy kosztowe i logika własności są specyficzne dla budowania od podstaw.
Projekt tworzenia dedykowanego oprogramowania CRM przebiega zgodnie z sekwencją etapów, która jest spójna w różnych wdrożeniach, nawet jeśli szczegóły znacznie się różnią. Zrozumienie pełnej sekwencji jest istotne, bo etapy, które organizacje najczęściej niedoszacowują lub pomijają, to właśnie te, które decydują o tym, czy system działa zgodnie z założeniami pięć lat po uruchomieniu.
Faza analizy to etap, w którym rzeczywisty proces sprzedaży organizacji, model danych, krajobraz integracyjny i logika przepływu pracy są dokumentowane z wystarczającą głębokością, żeby stanowić podstawę decyzji architektonicznych. Nie chodzi o warsztaty wymagań produkujące listę funkcji; chodzi o systematyczną analizę tego, co organizacja robi, jak to robi, gdzie żyją dane i co system musi robić w przypadkach brzegowych i wyjątkach, nie tylko na standardowej ścieżce.
Dla organizacji z umiarkowanie złożonym procesem sprzedaży ta faza trwa od czterech do ośmiu tygodni i typowo obejmuje sesje z kierownictwem sprzedaży, operacjami, działem IT, finansami i przynajmniej częścią handlowców z pierwszej linii. Wynikiem są specyfikacje funkcjonalne, model danych, inwentarz integracji i wstępny dokument architektoniczny. Organizacje, które kompresują tę fazę do dwóch tygodni lub pomijają ją na rzecz iterowania w trakcie budowy, konsekwentnie odkrywają to samo: wymagania niewychwycone w analizie pojawiają się jako przepisywanie w trakcie budowania, gdzie kosztują od trzech do pięciu razy więcej.
Faza architektury przekłada wymagania na projekt techniczny: schemat bazy danych, strukturę warstwy aplikacji, projekt interfejsów programistycznych dla połączeń wewnętrznych i zewnętrznych, model uwierzytelniania i bezpieczeństwa oraz stos technologiczny. W przypadku dedykowanego systemu CRM, który ma służyć organizacji przez dziesięć lub więcej lat, decyzje architektoniczne podjęte w tej fazie mają konsekwencje, których żadna późniejsza przebudowa nie rozwiązuje w pełni.
Dwa pytania architektoniczne mają nieproporcjonalnie duży wpływ na długoterminowy koszt i elastyczność. Pierwsze dotyczy tego, gdzie żyje logika biznesowa: w warstwie aplikacji, w bazie danych czy w kombinacji zarządzanej jawnymi zasadami projektowymi. Systemy, w których logika biznesowa nawarstwiała się w warstwie aplikacji bez udokumentowanego uzasadnienia, stają się progresywnie trudniejsze w utrzymaniu w miarę jak system rośnie i oryginalny zespół deweloperski się zmienia. Drugie dotyczy architektury integracji: czy połączenia z systemem ERP, systemem fakturowania, narzędziami marketingowymi i telefonią są zaprojektowane jako czyste, udokumentowane kontrakty interfejsowe, czy jako połączenia punktowe mnożące złożoność z każdą nową integracją.
Żadne z tych pytań nie ma uniwersalnie poprawnej odpowiedzi. Mają poprawne odpowiedzi dla konkretnych kontekstów, a partner deweloperski, który ich nie zadaje lub odpowiada na nie w sposób optymalizujący pod kątem szybkości pierwszego wdrożenia kosztem długoterminowej utrzymywalności, optymalizuje pod kątem złej rzeczy.
Faza budowy głównej części systemu tworzy podstawowe komponenty funkcjonalne CRM: model danych (kontakty, firmy, szanse sprzedaży, aktywności, oferty), warstwę zarządzania lejkiem sprzedaży, system śledzenia aktywności, interfejs użytkownika i podstawową infrastrukturę raportowania. Dla organizacji ze standardowym procesem sprzedaży i czystym modelem danych to najbardziej prosta faza projektu. Dla organizacji z niestandardową logiką procesową, złożonymi hierarchiami zatwierdzeń, wielopoziomowymi strukturami kanałów sprzedaży lub wymogami regulacyjnymi wpływającymi na sposób przechowywania i dostępu do danych, budowa jest etapem, gdzie różnica między systemem dedykowanym a skonfigurowaną platformą abonamentową jest najbardziej widoczna.
Czas trwania budowy systemu podstawowego wynosi od trzech miesięcy dla ograniczonego zakresu do dwunastu miesięcy dla rozbudowanego systemu klasy korporacyjnej. Najczęstszą przyczyną przekroczenia harmonogramu w tej fazie są wymagania niekompletnie doprecyzowane podczas analizy, które pojawiają się jako nieplanowane prace po rozpoczęciu budowy.
Integracje to element projektu dedykowanego CRM, który jest najczęściej niedoszacowywany na etapie planowania. System, który musi wymieniać dane z systemem ERP, platformą fakturowania, narzędziem do automatyzacji marketingu, systemem telefonii i systemem zarządzania dokumentami, ma w sobie pięć niezależnych projektów integracyjnych, każdy z własną dokumentacją interfejsów, wymaganiami uwierzytelniania, złożonością mapowania danych, obsługą błędów i zakresem testów.
Budowa integracji stanowi typowo dwadzieścia do czterdziestu procent całkowitego kosztu projektu przy dobrze określonym zakresie. Organizacje otrzymujące niskie wyceny projektów dedykowanego CRM często otrzymują wyceny, które wykluczają zakres integracji lub szacują go na poziomie zakładającym czyste, dobrze udokumentowane interfejsy programistyczne po stronie systemów zewnętrznych. W praktyce interfejsy tych systemów są często słabo udokumentowane, niespójnie zbudowane lub częściowo niesprawne, a praca nad zapewnieniem ich niezawodnego funkcjonowania pochłania czas, który nie był w wycenie.
Dedykowane systemy CRM budowane dla organizacji z nietrywialnym procesem sprzedaży obejmują zwykle warstwę automatyzacji: reguły wyzwalające akcje na podstawie zmian stanu, warunków czasowych lub wartości danych. Kierowanie zatwierdzeniami, logika przydziału, reguły eskalacji, wyzwalacze powiadomień i wieloetapowa automatyzacja procesów żyją w tej warstwie. Dla organizacji, których proces sprzedaży nie może być zamodelowany w standardowych narzędziach automatyzacji dostępnych w Salesforce lub HubSpot bez znaczących obejść, to jeden z głównych źródeł wartości w dedykowanym systemie.
Warstwa automatyzacji jest też jednym z głównych źródeł bieżącego kosztu utrzymania, bo procesy biznesowe się zmieniają i reguły, które je kodują, muszą zmieniać się razem z nimi. Systemy zaprojektowane z konfigurowalnym silnikiem przepływu pracy zamiast logiki zakodowanej na stałe są znacznie tańsze w utrzymaniu przez cały cykl operacyjny. To decyzja architektoniczna, która powinna być podjęta jawnie podczas fazy architektury, a nie odkryta jako problem utrzymaniowy dwa lata po wdrożeniu.
Dedykowane systemy CRM budowane w obecnym środowisku mogą wbudowywać możliwości sztucznej inteligencji na dwa wyraźnie różne sposoby, a różnica ma znaczenie dla organizacji oceniających, co „AI w CRM” oznacza w ich konkretnej sytuacji.
Pierwszy to osadzanie usług AI od uznanych dostawców, takich jak OpenAI, Anthropic lub Google, w interfejsie CRM, żeby dostarczać streszczenia, generować szkice odpowiedzi lub prowadzić interfejsy konwersacyjne. Ta możliwość jest osiągalna w każdym projekcie dedykowanego systemu CRM i nie wymaga własnych danych treningowych. Drugi to trenowanie modeli predykcyjnych na własnych danych historycznych organizacji: modeli scoringowych trenowanych na rzeczywistej historii konwersji firmy, modeli ryzyka odejścia klienta trenowanych na jej własnych danych lub modeli rekomendacji kolejnego działania trenowanych na tym, co sprawdziło się dla konkretnych produktów, klientów i rynku tej organizacji.
Druga kategoria jest realnie potężniejsza, ale też trudniejsza do zaimplementowania niż funkcje AI dostępne w platformach abonamentowych, bo dostawcy tych platform trenują swoje modele na zagregowanych anonimowych danych od wszystkich swoich klientów, nie na wzorcach specyficznych dla historii twojej organizacji. Kompromis polega na tym, że czerpanie wartości z własnego treningu wymaga wystarczającej ilości czystych, dobrze ustrukturyzowanych danych historycznych – a wiele organizacji odkrywa, że tych danych po prostu nie posiada. Uczciwa ocena gotowości danych organizacji do trenowania modeli AI to konieczny element określenia zakresu możliwości AI w projekcie dedykowanego systemu CRM.
Faza testów dedykowanego systemu CRM zastępującego istniejący system obejmuje testy funkcjonalne wszystkich funkcji, testy integracyjne wszystkich połączeń zewnętrznych, testy wydajnościowe przy oczekiwanym i szczytowym obciążeniu, przegląd bezpieczeństwa i testy akceptacyjne z reprezentatywnymi próbkami rzeczywistych użytkowników. Każdy z tych elementów to odrębny strumień prac z własnym zakresem i harmonogramem.
Migracja danych ze starych systemów jest konsekwentnie jedną z najbardziej czasochłonnych i obarczonych ryzykiem czynności w projekcie zmiany systemu CRM. Jakość danych w systemie źródłowym jest prawie zawsze gorsza niż zakładano na początku projektu. Duplikaty rekordów, niespójne formaty, brakujące wartości w wymaganych polach i powiązania istniejące w operacyjnym systemie, ale nieodzwierciedlone w strukturze danych wymagają rozwiązania przed migracją, a rozwiązanie wymaga decyzji biznesowych o tym, co zrobić z niejednoznacznymi przypadkami. Dla organizacji migrujących dane z kilku systemów źródłowych migracja danych może być najdłuższą pojedynczą czynnością w całym projekcie.
Koszt tworzenia dedykowanego oprogramowania CRM to jeden z najmniej uczciwie omawianych tematów w branży oprogramowania dla firm. Publikowane wartości wahają się od „50 000 do 500 000 zł+” w przewodnikach, które albo mówią o czymś znacznie prostszym niż korporacyjny CRM, albo podają przedziały tak szerokie, że są bezużyteczne do planowania. Poniższe ramy kosztowe używają aktualnych danych rynkowych, żeby podać orientacyjne szacunki dla trzech profili organizacyjnych.
Czynniki kosztowe decydujące o tym, gdzie konkretny projekt mieści się w tych przedziałach, to: liczba i złożoność integracji, to, czy organizacja potrzebuje konfigurowalnego silnika przepływu pracy czy logiki zakodowanej na stałe, złożoność migracji danych, zakres możliwości AI, poziom tworzenia aplikacji mobilnych oraz to, czy projekt wymaga własnej infrastruktury raportowania czy może opierać się na standardowych narzędziach analitycznych.
| Element projektu | Mały zakres | Średni rynek | Korporacyjny |
| Liczba użytkowników CRM | Do 50 | 100–500 | Ponad 500 |
| Analiza wymagań i architektura | 80 000–170 000 zł | 170 000–350 000 zł | 350 000–650 000 zł |
| Budowa systemu podstawowego | 260 000–520 000 zł | 650 000–1 750 000 zł | 1 750 000–5 200 000 zł |
| Budowa integracji | 85 000–260 000 zł | 350 000–1 100 000 zł | 1 100 000–2 600 000 zł |
| Automatyzacja przepływu pracy | 43 000–130 000 zł | 175 000–520 000 zł | 520 000–1 500 000 zł |
| Możliwości AI (podstawowe) | Zwykle nie uwzględniane | 85 000–260 000 zł | 260 000–870 000 zł |
| Testy i zapewnienie jakości | 65 000–130 000 zł | 175 000–430 000 zł | 430 000–1 100 000 zł |
| Migracja danych | 43 000–130 000 zł | 130 000–430 000 zł | 430 000–1 300 000 zł |
| Łączny koszt budowy | 575 000–1 340 000 zł | 1 735 000–4 840 000 zł | 4 840 000–13 220 000 zł |
| Roczne utrzymanie (15–20% budowy) | 85 000–270 000 zł/rok | 260 000–970 000 zł/rok | 725 000–2 650 000 zł/rok |
Kwoty w tabeli zakładają polskiego partnera programistycznego. Stawki w Europie Zachodniej i Ameryce Północnej są wyższe; realizacja w krajach z niższymi kosztami pracy może zmniejszyć koszt budowy o 30–50%, wprowadzając jednocześnie nakłady koordynacyjne i ryzyko jakościowe wymagające jawnego zarządzania.
Koszty utrzymania zasługują na osobną uwagę, bo są konsekwentnie niedoszacowywanym elementem w planach dedykowanych systemów CRM. Roczne utrzymanie systemu zbudowanego na zamówienie obejmuje naprawianie błędów i drobne ulepszenia, aktualizacje platformy i zależności, łatanie luk bezpieczeństwa, utrzymanie integracji, gdy systemy zewnętrzne się zmieniają, oraz monitorowanie wydajności i bieżących zaległości zadań deweloperskich generowanych przez każdy aktywnie używany system. Organizacje, które budżetują zerowe utrzymanie po uruchomieniu, odkrywają, że to, co zostało dostarczone jako sprawny system, degeneruje się w zobowiązanie w miarę starzenia się zależności i zmieniania się wymagań biznesowych bez odpowiedniej aktualizacji systemu.
Istotne porównanie to nie koszt własnego systemu kontra zero. To koszt własnego systemu plus bieżące utrzymanie kontra opłaty abonamentowe plus koszt dostosowania platformy plus ograniczenia co do tego, co organizacja w ogóle może zrobić.
Po podwyżce z sierpnia 2025 roku Salesforce Sales Cloud Enterprise kosztuje aktualnie 175 dolarów na użytkownika miesięcznie. Microsoft Dynamics 365 Sales Enterprise kosztuje 105 dolarów na użytkownika miesięcznie. Dla organizacji z 300 aktywnymi użytkownikami CRM te stawki przekładają się na:
Salesforce wprowadził dwie podwyżki cen w ciągu ostatnich pięciu lat. Zakładając oszczędny wzrost o 5% rocznie, koszt licencji Salesforce dla 300 użytkowników osiąga około 800 000 dolarów rocznie w piątym roku i około 1 020 000 dolarów rocznie w dziesiątym roku. Dedykowany CRM zbudowany za 4 000 000 złotych z rocznym utrzymaniem za 700 000 złotych kosztuje łącznie 11 000 000 złotych przez dziesięć lat. Sam koszt licencji Salesforce dla 300 użytkowników przez dziesięć lat, przy rozsądnym wzroście cen, wynosi w przybliżeniu 7 200 000 dolarów, wyłącznie za dostęp do platformy, nie uwzględniając żadnego dostosowania ani utrzymania.
To porównanie nie stanowi argumentu za wybieraniem w każdej sytuacji własnego, customowego systemu. To raczej sprostowanie błędnego twierdzenia, że tworzenie własnego systemu jest z natury droższe niż platforma abonamentowa – może tak być, ale nie musi i, w przypadku organizacji o wystarczającej skali, często nie jest. Punkt, w którym własny system daje lepszą ekonomię pięcioletnią niż platformy abonamentowe, zależy od liczby użytkowników, stopnia wymaganego dostosowania platformy i tego, czy proces organizacji mieści się w tym, co konfiguracja abonamentowa może wyrazić. Dla organizacji, w przypadku których platforma wymaga znacznego dodatkowego programowania w dodatku do kosztu licencji, ekonomia przesuwa się coraz mocniej w stronę systemu budowanego od podstaw.
Decyzja, czy budować, czy kupić, nie jest problemem optymalizacyjnym z jedną poprawną odpowiedzią. To decyzja zależna od kontekstu, oparta na czynnikach specyficznych dla każdej organizacji, a czynniki mające największe znaczenie nie zawsze są tymi, które dostają największą uwagę w procesie decyzyjnym.
Poniższe warunki, indywidualnie lub w kombinacji, konsekwentnie przesuwają ekonomię i logikę strategiczną w kierunku własnego systemu.
Proces sprzedaży nie może być wyrażony w standardowej logice pipeline’u.
Platformy CRM dostępne w modelu abonamentowym są projektowane wokół standardowego modelu od potencjalnego do zamkniętego klienta, z konfigurowalnymi etapami i polami. Ten model opisuje wystarczająco dobrze dużą część procesów sprzedaży B2B. Nie opisuje zarządzania siecią dealerów dla operatora telekomunikacyjnego, złożonego strukturowania produktów ubezpieczeniowych, wielopoziomowej sprzedaży kanałowej z różnymi modelami prowizji dla każdego poziomu ani żadnego procesu sprzedaży, gdzie podstawową jednostką pracy nie jest oferta przesuwająca się przez etapy, lecz relacja zarządzana przez wiele produktów, umów i punktów kontaktu jednocześnie. Gdy rzeczywisty proces sprzedaży organizacji wymaga znacznych obejść, żeby go zamodelować w platformie abonamentowej, te obejścia nawarstwiają się w dług techniczny rosnący z każdym nowym uruchomionym produktem, każdą zmianą procesu i każdym nowym wymaganiem, które nie pasuje do oryginalnego modelu.
System musi być własnością własnej logiki i danych.
Organizacje, których CRM koduje przewagę konkurencyjną, taką jak własne modele scoringowe, logikę cenową specyficzną dla danego rynku lub podejście do segmentacji klientów odzwierciedlające lata zgromadzonej wiedzy o rynku, napotykają strukturalny problem z platformami abonamentowymi: ta logika żyje na infrastrukturze dostawcy, podlega warunkom jego umowy serwisowej, jest dostępna dla jego inżynierów i jest zagrożona, jeśli dostawca zostanie przejęty, zmieni ceny lub wycofa produkt. Gdy system CRM jest w efekcie repozytorium własności intelektualnej firmy, pytanie o własność zmienia się z kwestii zakupowej na strategiczną.
Wymagania integracyjne przekraczają możliwości gotowych konektorów.
Każdy większy CRM abonamentowy oferuje rynek integracji z setkami gotowych złączy. Złącza te działają dobrze dla standardowych integracji z innymi dużymi platformami abonamentowymi. Działają gorzej w integracji z własnoręcznie zbudowanymi systemami ERP, starymi platformami fakturowania, własnymi magazynami danych i systemami specyficznymi dla branży poprzedzającymi nowoczesne standardy interfejsowe. Gdy krajobraz integracyjny wymaga pięciu lub więcej własnych integracji z niestandardowymi systemami, złożoność integracyjna własnego systemu CRM jest często porównywalna do złożoności integracyjnej wdrożenia abonamentowego, a własny system daje czystszy wynik, bo architektura integracji może być zaprojektowana jako spójna całość zamiast zestawiania niezależnych złączy.
Skala sprawia, że koszt licencji abonamentowej jest ekonomicznie istotny.
Dla organizacji z pięćdziesięcioma użytkownikami CRM, licencja Salesforce to koszt operacyjny łatwy do uzasadnienia niezależnie od jego tempa wzrostu. Dla organizacji z pięciuset użytkownikami roczne licencje to pozycja budżetowa w siedmiocyfrowych kwotach narastająca z każdą podwyżką. Punkt przejścia, przy którym własny system daje lepszą ekonomię pięcioletnią niż licencje abonamentowe, jest różny dla różnych platform i wymagań konfiguracyjnych, ale konsekwentnie pojawia się gdzieś między dwieście a pięćset użytkowników dla organizacji z istotnymi wymaganiami dostosowania ponad bazową platformę.
Organizacja przeżyła już wymuszoną migrację platformy.
Najbardziej przewidywalnym motorem tworzenia własnych systemów CRM jest organizacja, która wcześniej doświadczyła, co się dzieje, gdy dostawca podnosi ceny ponad akceptowalny poziom, wycofuje produkt, zmienia model danych w sposób psujący istniejące dostosowania lub jest przejęta przez firmę, której strategia produktowa nie obejmuje platformy, od której organizacja zależy. Doświadczenie zainwestowania znacznej wiedzy procesowej w platformę, a następnie przymusowej migracji jej za duży koszt i duże zamieszanie, jest rozstrzygającym argumentem za własnością. Jest też argumentem, który nie musi być stawiany abstrakcyjnie; można go postawić, wyliczając, ile faktycznie kosztowała ostatnia wymuszona migracja.
Standardowe warunki, w których platforma abonamentowa ma więcej sensu:
Organizacja ma standardowy proces sprzedaży, który czysto mapuje się na etapy i pola pipeline’u. Liczba użytkowników jest poniżej punktu przejścia ekonomicznego. Organizacja nie ma wewnętrznej zdolności do zarządzania projektem tworzenia oprogramowania i musiałaby tę zdolność budować lub zatrudniać. Czas do uruchomienia jest ograniczony i nie może pomieścić cyklu budowy trwającego od roku do półtora roku. Wymagania procesowe organizacji mają szansę być zbieżne z mapą drogową platformy abonamentowej, bo jej podstawowa baza użytkowników ma podobne potrzeby. Te warunki opisują wiele organizacji trafnie i dla tych organizacji zakup to właściwa decyzja.
| Czynnik decyzyjny | Przemawia za platformą abonamentową | Przemawia za własnym systemem |
| Złożoność procesu sprzedaży | Standardowy pipeline, konfigurowalne etapy | Niestandardowa logika, sieci dealerów, relacje wieloproduktowe |
| Liczba użytkowników | Poniżej 200 | Powyżej 300, rosnąca |
| Krajobraz integracji | Duże platformy abonamentowe, dostępne gotowe złącza | Starsze systemy ERP, niestandardowe fakturowanie, systemy branżowe |
| Własność i dane | Proces standardowy, brak przewagi konkurencyjnej w logice CRM | Własne modele scoringowe, logika cenowa, segmentacja specyficzna dla rynku |
| Historia platformy | Bez wcześniejszych wymuszonych migracji | Wcześniejsza wymuszona migracja lub doświadczenie zablokowania przez dostawcę |
| Wymagania AI | Wystarczają ogólne funkcje AI | Wymagane trenowanie na własnych danych historycznych |
| Czas do uruchomienia | Wymagane poniżej sześciu miesięcy | Akceptowalne dwanaście do dwudziestu czterech miesięcy |
| Zdolność IT wewnętrzna | Ograniczona zdolność zarządzania projektami deweloperskimi | Doświadczenie w zarządzaniu projektami tworzenia oprogramowania |
| Pięcioletni całkowity koszt posiadania | Licencje abonamentowe poniżej kosztu budowy i utrzymania | Licencje abonamentowe zbliżają się do ekonomiki własnego systemu lub ją przekraczają |
Projekt T-Mobile Polska to najszczegółowiej udokumentowany publicznie przykład tego, co może wyprodukować tworzenie dedykowanego CRM w skali korporacyjnej. Organizacja działała na trzech osobnych historycznych systemach CRM, każdym będącym spuścizną wcześniejszych operacji i przejęć, każdym wymagającym wyłączenia całego środowiska do aktualizacji, każdym prezentującym inny interfejs konsultantom, którzy musieli obsługiwać wszystkie trzy. Pretius zaprojektował i zbudował zunifikowany CRM od podstaw na architekturze mikroserwisów w Javie i Spring Boot ze 350 niezależnymi modułami. System obsługuje ponad jedenaście milionów klientów w sposób ciągły od ponad dekady. Każdy moduł można aktualizować i wdrażać bez wpływu na resztę systemu. Pełna historia klienta i kontekst relacji z wszystkich historycznych systemów dostępne są z jednego miejsca. Pełne studium przypadku: pretius.com/case-study/t-mobile-modern-crm-system.
Istotna lekcja z tego przykładu to nie to, że własny CRM jest zawsze właściwą odpowiedzią. To, że decyzja o budowie własnego systemu była napędzana przez wymagania, których faktycznie nie mogła spełnić żadna dostępna platforma abonamentowa: model procesowy niemający odpowiednika w standardowej architekturze CRM, wymagania integracyjne, które i tak wymagałyby przebudowania większości logiki systemu w warstwie dostosowania platformy abonamentowej i skala, która sprawiała, że ekonomia bieżących licencji była nie do przyjęcia. To są warunki przy których własny system konsekwentnie daje lepsze wyniki, i wszystkie były tu obecne.
Czym jest dedykowany system CRM?
Dedykowany system CRM to aplikacja do zarządzania relacjami z klientami zbudowana od podstaw na stosie technologicznym kontrolowanym przez zamawiającą organizację, zaprojektowana specyficznie dla modelu danych, procesu sprzedaży, wymagań integracyjnych i reguł biznesowych tej organizacji. Cechą wyróżniającą jest własność: organizacja posiada kod źródłowy, nie ma bieżącej zależności licencyjnej od dostawcy platformy CRM i może modyfikować system bez zgody dostawcy ani ograniczeń architektury platformy abonamentowej.
Ile trwa projekt dedykowanego CRM?
Od rozpoczęcia fazy analizy wymagań do uruchomienia produkcyjnego, realistyczny harmonogram to dwanaście do dwudziestu czterech miesięcy dla systemu o pełnym zakresie korporacyjnym i sześć do dwunastu miesięcy dla systemu o mniejszym zakresie. Projekty, które skracają się poniżej tych ram, robią to typowo przez ograniczenie analizy wymagań, co wywołuje prace naprawcze w trakcie budowy, lub przez ograniczenie zakresu integracji, co oznacza, że dostarczony system nie może się połączyć z istniejącą infrastrukturą organizacji. Najdokładniejszy szacunek harmonogramu pochodzi z ustrukturyzowanej fazy analizy wymagań, która wygenerowała zatwierdzony zakres.
Ile kosztuje dedykowany system CRM?
Dla organizacji z segmentu średnich przedsiębiorstw z 100 do 500 użytkowników CRM i umiarkowanie złożonym krajobrazem integracyjnym, całkowity koszt budowy wynosi od około 1 700 000 do 4 800 000 złotych. Zakres korporacyjny ze złożonymi integracjami i możliwościami AI wynosi od 4 800 000 do 13 000 000 złotych. Roczne utrzymanie to 15–20% kosztu budowy. Liczby te zakładają polskiego partnera deweloperskiego.
Czy własny CRM jest droższy niż Salesforce?
Przy małej liczbie użytkowników zazwyczaj tak. Przy dużej liczbie użytkowników ze znacznymi wymaganiami dostosowania zazwyczaj nie. Salesforce Enterprise kosztuje aktualnie 175 dolarów na użytkownika miesięcznie. Dla 300 użytkowników to 630 000 dolarów rocznie wyłącznie za licencje, przed wdrożeniem, dostosowaniem, konsultingiem i wsparciem. Własny CRM zbudowany za 4 000 000 złotych z rocznym utrzymaniem za 700 000 złotych kosztuje łącznie 11 000 000 złotych przez dziesięć lat. Same licencje Salesforce dla 300 użytkowników przez dziesięć lat, przy konserwatywnym wzroście o 5% rocznie, wynoszą około 7 200 000 dolarów, wyłącznie za dostęp do platformy. Porównanie zależy mocno od liczby użytkowników, stopnia wymaganego dostosowania platformy i tego, czy proces organizacji mieści się w tym, co konfiguracja abonamentowa może wyrazić.
Jaki stos technologiczny stosuje się do budowy dedykowanych systemów CRM?
Najczęstsze stosy technologiczne dla systemów CRM dedykowanych korporacyjnym to Java z Spring Boot (najwyższy sufit skalowalności, największa pula talentów, silna integracja z Oracle), .NET (preferowany w środowiskach zdominowanych przez Microsoft), Oracle APEX (najniższy koszt, gdy Oracle Database jest już podstawowym magazynem danych, natywna obsługa logiki PL/SQL) oraz Node.js z frontendem React lub Angular (najszybsze budowanie dla zespołów z doświadczeniem w JavaScript, najszersza dostępność specjalistów). Właściwy wybór zależy od istniejącej infrastruktury organizacji, wewnętrznych kompetencji, wymagań integracyjnych i oczekiwanej skali. Partner deweloperski niezależny technologicznie powinien przedstawić kompromisy przynajmniej dwóch lub trzech opcji przed rekomendacją stosu; partner, który rekomenduje preferowany przez siebie stos bez tej analizy, optymalizuje pod kątem własnej wygody realizacyjnej, nie długoterminowych wyników organizacji.
Kto jest właścicielem kodu w projekcie dedykowanego CRM?
W prawidłowo skonstruowanej umowie na dedykowany CRM zamawiająca organizacja jest właścicielem całej własności intelektualnej wytworzonej w trakcie projektu: kodu źródłowego, schematu bazy danych, specyfikacji interfejsów i dokumentacji. To domyślna pozycja w większości jurysdykcji dla oprogramowania tworzonego na zamówienie, ale warto ją zweryfikować wprost w umowie, bo niektóre firmy deweloperskie konstruują umowy w sposób tworzący zależności licencyjne od ich własnych szkieletów lub narzędzi. Własność intelektualna powinna być określoną i jawną klauzulą, a nie zakładanym wynikiem.
Co się dzieje po wybudowaniu dedykowanego CRM?
Dedykowany CRM wymaga bieżącego utrzymania: naprawiania błędów, łatania luk bezpieczeństwa, aktualizacji zależności, utrzymania integracji, gdy systemy zewnętrzne się zmieniają, i tworzenia nowych funkcji w miarę ewolucji wymagań biznesowych. Opcje zarządzania tym to utrzymanie wewnętrznego zespołu deweloperskiego, kontynuacja z oryginalnym partnerem deweloperskim w ramach umowy serwisowej lub przejście do innego partnera utrzymaniowego. Pierwsza opcja wymaga zatrudnienia i utrzymania inżynierów ze specyficznym stosem technologicznym systemu. Druga jest typowo najbardziej efektywna, bo wiedza oryginalnego zespołu o architekturze i logice systemu reprezentuje lata skumulowanego kontekstu, którego nie da się przekazać w dokumencie zdawczo-odbiorczym. Trzecia jest możliwa, jeśli system był budowany z rygorystyczną dokumentacją logiki biznesowej i architektury, co jest powodem, dla którego dokumentacja powinna być zdefiniowanym elementem dostawy w umowie na pierwotny projekt.
