ERP, CRM, BI – jak zbudować spójny ekosystem technologiczny, a nie zbiór systemów

Trzy systemy, trzy różne wersje rzeczywistości

Sytuacja, którą widać w wielu średnich i dużych przedsiębiorstwach, wygląda podobnie. Firma ma ERP, wdrożony kilka lat temu, rozbudowany, obsługujący finanse, magazyn, produkcję. Ma CRM, kupiony przez sprzedaż, zwykle później i trochę obok. Ma też jakieś narzędzie BI albo przynajmniej zestaw raportów w Excelu, które ktoś przygotowuje na poniedziałkowe spotkanie zarządu.

I ma problem: na tym spotkaniu dyrektor sprzedaży podaje jedną liczbę, dyrektor finansowy drugą, a controlling trzecią. Wszystkie są policzone poprawnie. Po prostu liczone są z różnych źródeł, w różnych momentach i według różnych definicji.

To nie jest problem techniczny. To problem zarządczy, który tylko objawia się w technologii. Zanim więc zapyta się „jaki system wybrać”, warto zapytać: czym w naszej firmie jest klient, zamówienie, marża i przychód – i kto ma prawo to zdefiniować?

Dlaczego integracja systemów zwykle nie wystarcza

Gdy problem staje się dostrzegalny, pierwszą reakcją jest zazwyczaj projekt integracyjny. Połączmy CRM z ERP, wystawmy API, dorzućmy warstwę raportową. Technicznie to możliwe i często potrzebne. Tylko że integracja przenosi dane, a nie porządek.

Jeżeli w CRM handlowiec zakłada nową kartotekę klienta przy każdym zapytaniu, a w ERP ten sam podmiot występuje pod trzema numerami NIP z różnymi nazwami, integracja nie naprawi niczego. Zwielokrotni chaos i doda mu wiarygodności, bo teraz będzie on prezentowany na estetycznym dashboardzie.

Z doświadczeń naszych ekspertów wynika, że w projektach tego typu największa część pracy nie dotyczy interfejsów, lecz uzgodnienia: co jest źródłem prawdy dla danego obiektu danych, jaki jest cykl życia tego obiektu i kto odpowiada za jego jakość. Dopóki to nie jest ustalone, każde kolejne wdrożenie zwiększa koszt utrzymania architektury, nie zwiększając zdolności decyzyjnej organizacji.

Podział ról: co ma robić ERP, co CRM, a co BI

Spójny ekosystem technologiczny zaczyna się od jasnego podziału odpowiedzialności między systemami. Brzmi banalnie, ale w praktyce granice bardzo szybko się zacierają – zwłaszcza gdy dostawcy obu systemów obiecują, że „to też potrafią”.

Uproszczony, ale użyteczny podział wygląda tak:

- ERP odpowiada za transakcję i zapis zdarzenia gospodarczego: zamówienie, dokument, stan magazynu, koszt, rozliczenie. To system rejestru i kontroli. - CRM odpowiada za relację i proces przed transakcją: lead, pipeline, historia kontaktu, prognoza, aktywność handlowa. To system pracy zespołu sprzedaży, nie archiwum dla zarządu. - BI odpowiada za wnioskowanie: łączy dane z obu światów, nadaje im wspólne definicje i pokazuje zależności, których nie widać w żadnym systemie źródłowym osobno.

Problemy pojawiają się wtedy, gdy któryś z systemów przejmuje funkcję innego. Marża liczona w CRM na podstawie danych wpisanych ręcznie przez handlowca prawie zawsze rozjedzie się z marżą z ERP. Pipeline utrzymywany w arkuszu obok CRM prawie zawsze będzie optymistyczny. Raport zarządczy budowany bezpośrednio na tabelach ERP prawie zawsze będzie trudny do utrzymania po pierwszej aktualizacji systemu.

Kilka pytań, które warto zadać przed decyzją o narzędziu

- Które decyzje biznesowe podejmujemy dziś zbyt późno albo na wyczucie – i jakich danych do nich brakuje? - Gdzie powstaje dana i kto ma interes w tym, żeby była poprawna? - Ile razy ta sama informacja jest wpisywana ręcznie w różnych miejscach? - Co się stanie, jeśli odejdzie osoba, która „wie, jak się to liczy”?

Ostatnie pytanie jest szczególnie istotne. Uzależnienie raportowania od jednej osoby i jej prywatnego pliku to realne ryzyko operacyjne, które rzadko trafia do rejestru ryzyk.

Konsekwencje biznesowe, których zwykle się nie liczy

Niespójny ekosystem systemów kosztuje w miejscach, których nie widać w budżecie IT.

Pierwszy koszt to czas menedżerów. Godziny spędzane na uzgadnianiu liczb zamiast na podejmowaniu decyzji. Drugi to opóźnienie decyzyjne – jeśli rzetelny obraz marży na kliencie pojawia się dwa miesiące po fakcie, korygowanie polityki cenowej jest zawsze spóźnione. Trzeci to erozja marży, bo bez wiarygodnej rentowności na poziomie klienta, produktu i kanału rabaty przyznaje się intuicyjnie. Czwarty to ograniczona skalowalność: procesy oparte na ręcznym przepisywaniu danych nie wytrzymują wzrostu wolumenu bez proporcjonalnego wzrostu zatrudnienia.

Jest też skutek trudniejszy do zmierzenia, ale zauważalny w praktyce – spadek zaufania do danych. Kiedy organizacja raz przestanie wierzyć raportom, wraca do opinii i przeczuć, a wtedy nawet dobrze wdrożone narzędzie analityczne nie zmienia sposobu zarządzania.

Jak podejść do budowy ekosystemu w praktyce

Sensowna kolejność jest odwrotna do tej, którą narzuca rynek dostawców. Nie zaczyna się od wyboru systemu.

Zacznij od decyzji, nie od danych. Wypisz kilkanaście decyzji, które faktycznie kształtują wynik firmy – politykę cenową, priorytetyzację klientów, planowanie produkcji, alokację budżetu marketingowego, ocenę zespołu sprzedaży. Dla każdej z nich określ, jaka informacja jest potrzebna, jak często i z jaką dokładnością. Ten spis staje się realnym zakresem wymagań.

Ustal słownik pojęć. Jedna definicja klienta, przychodu, marży, lejka, statusu zamówienia. To najmniej efektowna część projektu i najczęściej pomijana, a bez niej BI będzie tylko ładniejszą wersją sporu.

Wyznacz właścicieli danych. Nie w IT, a w biznesie. Ktoś musi odpowiadać za jakość kartoteki klienta i za dyscyplinę w pipeline. Bez tego żadna automatyzacja nie utrzyma się dłużej niż kwartał.

Uporządkuj proces przed automatyzacją. Zdigitalizowany bałagan pozostaje bałaganem, tylko szybszym i trudniejszym do zatrzymania. Jeśli proces ofertowania jest niespójny w czterech oddziałach, wdrożenie CRM tego nie uzgodni – najwyżej ujawni.

Wdrażaj etapami, ale według jednej architektury. Wybór między jedną zintegrowaną platformą a zestawem najlepszych narzędzi w klasie nie ma uniwersalnej odpowiedzi. Zależy od skali, specyfiki branży, dojrzałości procesów i realnych kompetencji wewnętrznych. Ważniejsze od samego wyboru jest to, żeby ktoś świadomie odpowiadał za całość obrazu, a nie za pojedyncze wdrożenia.

Zaplanuj pomiar efektu. Skrócenie cyklu sprzedaży, czas domknięcia miesiąca, udział decyzji podejmowanych na danych, liczba ręcznych korekt. Jeśli nikt tego nie mierzy, projekt technologiczny zostanie oceniony po budżecie i terminie, a nie po wpływie na wynik.

Technologia jest konsekwencją modelu zarządzania

Najtrudniejsza część transformacji cyfrowej rzadko dotyczy oprogramowania. Dotyczy uzgodnienia, jak firma naprawdę działa i jak chce być zarządzana. Systemy tylko utrwalają ten model – dobry albo zły.

Dlatego pytanie „ERP, CRM czy BI” jest w większości przypadków pytaniem zastępczym. Właściwe brzmi: jakie decyzje chcemy podejmować lepiej i szybciej niż dzisiaj, i co musi się zmienić w procesach, danych oraz odpowiedzialności ludzi, żeby to było możliwe.

Jeżeli rozpoznajesz w tym opisie sytuację własnej organizacji – kilka systemów, kilka wersji liczb i rosnące poczucie, że technologia kosztuje więcej, niż daje – warto przyjrzeć się temu szerzej niż z perspektywy kolejnego wdrożenia. W ITTC zaczynamy od diagnozy: gdzie powstaje rozjazd danych, które procesy generują pracę bez wartości i jakie decyzje biznesowe najbardziej cierpią na braku wiarygodnej informacji. Dopiero z tego wynika architektura, plan wdrożenia i sposób pomiaru efektów.