Integracja między systemami ma jedną zdradliwą cechę: kiedy przestaje działać poprawnie, zwykle nikt tego od razu nie widzi. Sklep dalej przyjmuje zamówienia, ERP dalej wystawia faktury, CRM dalej pokazuje klientów. Tyle że każdy z nich zaczyna pokazywać trochę inną rzeczywistość. Różnicę odkrywa się później - przy zamknięciu miesiąca, przy reklamacji albo przy pytaniu klienta, dlaczego dostał coś innego, niż zamówił.

Poniżej opisujemy, gdzie najczęściej giną dane i jak wyłapać rozjazdy, zanim zrobią szkody.

1. Błędy, o których nikt się nie dowiaduje

Najczęstszy scenariusz jest banalny. Jeden z systemów zmienia sposób komunikacji, wygasa klucz dostępu albo serwer po drugiej stronie przez chwilę nie odpowiada. Synchronizacja kończy się błędem, błąd trafia do logów - i na tym koniec. Nikt nie dostaje powiadomienia, więc zaległości rosną przez dni albo tygodnie.

Problem nie leży w samym błędzie, bo te zdarzają się w każdej integracji. Leży w tym, że nikt się o nim nie dowiaduje. Log, którego nikt nie czyta, niczego nie chroni.

2. To samo pole, różne znaczenie

Drugi rodzaj rozjazdu jest trudniejszy do zauważenia, bo technicznie wszystko działa poprawnie. Dane przechodzą z systemu do systemu bez błędów, tylko w każdym z nich znaczą coś innego. Cena w sklepie jest brutto, a w ERP netto. Status “zrealizowane” w jednym miejscu oznacza wysłane, w drugim - opłacone. Rabat w jednym systemie liczy się przed podatkiem, w drugim po.

Takie różnice zwykle wychodzą przy pierwszym nietypowym przypadku: zwrocie, korekcie, zamówieniu z niestandardowym rabatem. Dlatego przed uruchomieniem integracji warto spisać, co dokładnie znaczy każde przesyłane pole po obu stronach. To nudna praca, ale tańsza niż wyjaśnianie rozbieżności po fakcie.

3. Dwa systemy, które uważają się za właściciela tych samych danych

Trzecia przyczyna dotyczy architektury. Jeśli te same dane - ceny, stany magazynowe, dane klienta - można zmieniać w dwóch miejscach, a integracja przesyła je w obie strony, prędzej czy później jedna zmiana nadpisze drugą. Która wygra, zależy od kolejności synchronizacji, nie od tego, która była poprawna.

Rozwiązanie jest proste do opisania i wymaga dyscypliny we wdrożeniu: dla każdego rodzaju danych jeden system jest źródłem prawdy. Ceny ustala się w jednym miejscu, a pozostałe systemy je tylko odczytują. Jeśli ktoś musi coś poprawić, robi to w systemie źródłowym, a nie tam, gdzie akurat zauważył błąd.

Jak wyłapać rozjazdy, zanim zrobi to księgowość

Monitoring z alertem do konkretnej osoby

Każda nieudana synchronizacja powinna trafiać do człowieka, a nie tylko do logów. Alert ma mieć adresata, który wie, co z nim zrobić, i jasny opis: co nie przeszło, kiedy i dlaczego. Dobrze ustawiony monitoring sprawia, że błąd z punktu pierwszego trwa godziny, a nie tygodnie.

Codzienne uzgadnianie liczb

Monitoring mówi, czy integracja działa. Nie mówi, czy dane się zgadzają. Do tego służy automatyczne porównanie liczb między systemami: liczby zamówień, sum faktur, stanów magazynowych. Raz dziennie system zestawia wartości z obu stron i zgłasza różnice. Ten sam mechanizm może pilnować reguł biznesowych - na przykład zgłaszać sprzedaż poniżej ceny zakupu, zanim zrobi się z tego miesiąc strat.

Właściciel integracji

Za każdą integracją powinna stać konkretna osoba, która odpowiada za to, że dane się zgadzają - nie “dział IT” ogólnie i nie dostawca jednego z systemów. Dostawca sklepu odpowiada za sklep, dostawca ERP za ERP, a przestrzeń między nimi często nie należy do nikogo. Właśnie tam giną dane.

Lista kontrolna

  1. Czy każda nieudana synchronizacja trafia do konkretnej osoby, a nie tylko do logów?
  2. Czy istnieje spisane znaczenie każdego pola przesyłanego między systemami?
  3. Czy dla cen, stanów i danych klienta wiadomo, który system jest źródłem prawdy?
  4. Czy codziennie porównujecie kluczowe liczby między systemami?
  5. Czy kontrole obejmują reguły biznesowe, takie jak sprzedaż poniżej kosztu?
  6. Czy każda integracja ma wskazanego właściciela?

Podsumowanie

Integracja, która się zatrzymała, to problem widoczny i zwykle szybko naprawiany. Groźniejsza jest ta, która działa, ale przenosi dane rozumiane inaczej po obu stronach albo nadpisuje poprawne wartości błędnymi. Takich rozjazdów nie widać w logach. Widać je w liczbach - pod warunkiem, że ktoś regularnie na nie patrzy.