Dedykowany CRM w SAP: kiedy budować własne rozwiązanie, a kiedy integrować gotowy system

Określenie "dedykowany CRM w SAP" może opisywać trzy różne architektury. W pierwszej firma używa funkcji CRM dostępnych w ekosystemie SAP. W drugiej pracownicy korzystają z osobnego CRM, który wymienia dane z SAP. W trzeciej zespół buduje własną aplikację, która pokazuje wybrane dane SAP i realizuje specyficzne procesy firmy.

Dla SAP Business One integrator może korzystać między innymi z Service Layer, interfejsu API opartego na HTTP i OData, albo z DI API. SAP opisuje Service Layer jako interfejs do korzystania z danych i usług SAP Business One; DI API służy między innymi do rozszerzania systemu i łączenia go z rozwiązaniami zewnętrznymi. Wybór interfejsu zależy od wersji, konfiguracji i wymagań danego wdrożenia, a nie od samej nazwy CRM. Dokumentacja Service Layer SAP Business One, dokumentacja DI API SAP

Osobny CRM nie oznacza dublowania całego SAP. Integracja może udostępniać handlowcom tylko potrzebny wycinek: dane kontrahenta, limity, zaległości, zamówienia lub status realizacji. Jeśli dopiero porządkujecie procesy przed wdrożeniem, zacznijcie od mapy przepływu pracy opisanej w przewodniku po automatyzacji procesów biznesowych.

Integracja jest uzasadniona, gdy ręczne przekazywanie informacji między sprzedażą a operacjami powoduje błędy albo opóźnia obsługę klienta. Sygnałem nie jest sama liczba używanych narzędzi, tylko koszt powtarzania tych samych czynności i brak zaufania do danych.

Sprawdźcie, czy handlowcy wpisują nazwę i adres klienta ponownie po utworzeniu go w SAP. Zwróćcie uwagę, czy przed ofertą muszą pytać księgowość o zadłużenie albo magazyn o dostępność. Jeżeli zamówienia trafiają do ERP przez e-mail lub arkusz, proces zależy od pamięci i dostępności konkretnej osoby.

Praktyczna lista sygnałów do omówienia z zespołem:

• W CRM nie widać faktur, płatności, zamówień lub reklamacji, które są już zapisane w SAP.
• Pracownik kopiuje dane z oferty lub zamówienia między systemami.
• Zmiana ceny, warunków handlowych albo statusu realizacji dociera do sprzedaży z opóźnieniem.
• Zespoły tworzą osobne rekordy tej samej firmy i nie wiedzą, który jest aktualny.
• Raport sprzedaży wymaga ręcznego łączenia eksportów z CRM i ERP.

Sama integracja nie naprawi niezgodnych definicji statusów ani słabej jakości kartotek. Najpierw ustalcie, które problemy wynikają z braku przepływu danych, a które z procesu, uprawnień lub nieuporządkowanych rekordów. Gdy przeszkodą jest przede wszystkim akceptacja zespołu, pomocny będzie materiał o tym, dlaczego handlowcy nie uzupełniają CRM i jak poprawić użycie systemu.

Gotowy CRM zazwyczaj pozwala szybciej uruchomić standardowy pipeline i aktywności, a aplikacja dedykowana daje większą kontrolę nad nietypowym procesem. Całkowity koszt zależy jednak również od integracji, licencji, zmian w SAP, utrzymania i zakresu testów.

Tabela decyzji: wybierzcie gotowy CRM, jeśli proces sprzedaży składa się ze standardowych etapów, a potrzebne dane SAP da się bezpiecznie udostępnić przez interfejs. Rozważcie aplikację dedykowaną, jeśli zespół musi obsługiwać wyjątki, nietypowe role, wieloetapowe akceptacje albo szczególne reguły ofertowania, których standardowy CRM nie odwzorowuje bez wielu obejść. Jeżeli różnice dotyczą głównie konfiguracji pól i raportów, zacznijcie od konfiguracji, nie od budowy nowego systemu.

Nie porównujcie wyłącznie kwoty wdrożenia. W analizie uwzględnijcie opłaty licencyjne, środowisko integracyjne, aktualizacje, monitoring, szkolenie i koszt zmiany procesu. Zakres i cenę budowy systemu opisuje oferta na dedykowany CRM, a o wydatkach na własne rozwiązanie szerzej traktuje materiał ile kosztuje dedykowany CRM.

Zacznijcie od obiektów, które pozwolą obsłużyć konkretny etap pracy, i przypiszcie jeden system jako źródło prawdy dla każdego z nich. Dwukierunkowa synchronizacja wszystkiego od pierwszego dnia podnosi ryzyko konfliktów i utrudnia ustalenie, skąd pochodzi błędna wartość.

Identyfikator SAP powinien być zapisany w CRM jako stabilny klucz zewnętrzny. Nie dopasowujcie rekordów wyłącznie po nazwie firmy, bo skróty, literówki i zmiany nazwy mogą utworzyć duplikaty albo połączyć różne podmioty. Przed synchronizacją uzgodnijcie też, co dzieje się z rekordem po scaleniu, dezaktywacji lub zmianie właściciela.

Ustalanie właściciela danych

Dla każdego pola zapiszcie właściciela, dozwolony kierunek zmiany, regułę konfliktu oraz rolę mogącą zatwierdzić korektę. Przykładowo SAP może zarządzać numerem kontrahenta i warunkami płatności, CRM osobą kontaktową i aktywnościami, a status zamówienia może być tylko odczytywany w CRM. Gdy obie aplikacje mogą zmienić to samo pole, określcie priorytet systemu i sposób rejestrowania ręcznej korekty.

Bezpieczna integracja zaczyna się od inwentaryzacji wersji SAP, dostępnych interfejsów, środowisk i właścicieli procesów. Następnie projektuje się model danych i przepływy, zanim powstaną mapowania pól.

1. Rozpoznajcie środowisko. Zbierzcie wersję i poprawki SAP Business One, typ bazy, konfigurację Service Layer lub DI API, dodatki oraz sposób dostępu z sieci. Dla Service Layer sprawdźcie wymagania HTTPS, certyfikat, uwierzytelnienie i utrzymywanie sesji. Dokumentacja SAP opisuje dostęp przez ścieżki OData, w tym `/b1s/v2` dla OData 4 w aktualnej dokumentacji API.
2. Uzgodnijcie model. Rozpiszcie obiekty, pola wymagane, słowniki, identyfikatory, statusy i reguły walidacji. Dla każdego przepływu określcie, czy jest natychmiastowy, cykliczny czy uruchamiany zdarzeniem.
3. Wybierzcie warstwę integracyjną. Bezpośrednie połączenie może wystarczyć dla prostego zakresu, a middleware ułatwia kolejkowanie, mapowanie, monitoring i obsługę wielu systemów. Nie zapisujcie bezpośrednio do tabel bazy SAP z pominięciem mechanizmów aplikacji.
4. Ograniczcie uprawnienia. Użyjcie dedykowanego konta integracyjnego, zakresu dostępu dopasowanego do operacji i bezpiecznego przechowywania poświadczeń. Oddzielcie dane testowe od produkcyjnych.
5. Zaprojektujcie awarie. Rejestrujcie identyfikator rekordu, czas, operację i odpowiedź interfejsu, ale nie zapisujcie haseł ani pełnych danych wrażliwych. Błąd tymczasowy powinien trafić do kolejki ponowień z limitem prób; błąd walidacji do kolejki wymagającej korekty.

Dla Service Layer SAP publikuje referencję API z dostępnymi obiektami i operacjami. DI API ma inne wymagania techniczne, między innymi dokumentacja SAP wskazuje, że DI API nie obsługuje wielowątkowości. Te ograniczenia trzeba uwzględnić w doborze architektury i testach obciążenia. Referencja Service Layer API

Jeśli system ma też obsłużyć sklep, integracja wymaga osobnej mapy stanów, cen i zamówień. Zakres techniczny opisuje integracja sklepu z ERP. Przy porównywaniu platform CRM sprawdźcie też HubSpot i Pipedrive pod kątem funkcji i kosztów wdrożenia.

Wycena wynika z liczby obiektów i reguł, jakości danych, dostępnych interfejsów oraz tego, czy projekt obejmuje migrację, szkolenia i utrzymanie. Bez analizy wersji SAP i procesu nie da się rzetelnie obiecać jednej kwoty ani terminu dla każdej firmy.

Aby porównać oferty wykonawców, poproście o listę obiektów, kierunków przepływu, wyjątków, testów odbiorowych i założeń. Warto też ustalić, kto odpowiada za dostęp do SAP, licencje, decyzje o źródłach prawdy oraz poprawę jakości danych. Nieporównywalne zakresy często kryją się pod tym samym hasłem "integracja CRM".

Test odbiorowy powinien sprawdzić poprawne dane, duplikaty, błędy walidacji i odzyskanie pracy po awarii. Zespół biznesowy musi zatwierdzić wynik na przykładowych rekordach przed uruchomieniem przepływu produkcyjnego.

Sprawdźcie też zachowanie przy powtórnym wysłaniu tego samego komunikatu. Operacja powinna być idempotentna, czyli ponowienie nie może tworzyć kolejnego zamówienia ani faktury. Odbiór powinien obejmować logi, alerty, procedurę ręcznego wznowienia i właściciela kolejki błędów.

Najczęstsze problemy wynikają z nieuzgodnionej odpowiedzialności za dane, a nie z samego połączenia API. Integracja bez właściciela procesu może szybciej przenosić błędne wartości między systemami.

Perspektywa KC Mobile: w projektach integracyjnych najpierw porządkujemy reguły obiegu danych, bo technicznie poprawna synchronizacja nie rozstrzyga, który dział ma prawo zmienić kontrahenta, cenę albo status. Gdy te decyzje pozostają niejasne, pracownicy zaczynają obchodzić system arkuszami lub ręcznymi korektami.

Unikajcie uruchamiania zapisu w obu kierunkach dla tego samego pola bez priorytetu i historii zmian. Nie mapujcie statusów CRM i SAP po podobnie brzmiących nazwach bez uzgodnienia znaczenia biznesowego. Nie pomijajcie kontroli duplikatów, limitów API, ponowień, wersjonowania i procedury wycofania wdrożenia.

Przypiszcie właściciela każdemu obiektowi oraz osobę odpowiedzialną za kolejkę błędów. Po uruchomieniu monitorujcie liczbę rekordów oczekujących, nieudanych operacji i zmian odrzuconych przez walidację. To pozwala reagować, zanim niezgodność przejdzie do kolejnych dokumentów.

• CRM: definicja pojęcia, funkcje i zastosowanie w firmie
• Automatyzacja obsługi sprzedaży: od zapytania do realizacji
• Optima CRM: jak sprawdzić cenę licencji, modułów i wdrożenia?
• Automatyzacje w Make: jak połączyć aplikacje i ograniczyć ręczną pracę