Kto odpowiada za jakość danych w integracji systemów?

Zamówienia ze sklepu internetowego trafiają do systemu ERP, stamtąd do magazynu, a następnie do systemu fakturowania. Na papierze wszystkie systemy są połączone, jednak codziennie trzeba poprawiać numery artykułów, brakuje danych dotyczących dostawy, a w raporcie menedżerskim widać inny stan magazynowy niż w rzeczywistości. W takich sytuacjach szybko pojawia się pytanie: kto odpowiada za jakość danych w integracji systemów?

Krótka odpowiedź: nie tylko zespół IT, nie tylko integrator systemów, i nie tylko pracownik, który jako pierwszy wprowadził dane. Jakość danych to odpowiedzialność biznesowa, która wymaga zarówno kontroli technicznych, jak i operacyjnych. Jeśli nie jest to jasno określone, integracja jedynie szybciej przenosi błędy z jednego systemu do drugiego.

Integracja nie naprawia automatycznie danych

Zadaniem integracji systemów jest przekazywanie i synchronizacja informacji zgodnie z określonymi zasadami. Może to być zamówienie, dane partnera, baza produktów, cena, stan magazynowy, status produkcji lub informacje o fakturowaniu. Jednak fakt, że dane technicznie przechodzą z systemu A do systemu B, nie oznacza, że są one użyteczne biznesowo.

Jeśli ten sam produkt występuje pod trzema różnymi numerami artykułów, integracja nie może sama wiedzieć, który jest poprawny. Jeśli w sklepie internetowym numer telefonu jest opcjonalny, ale w systemie przewoźnika obowiązkowy, ktoś musi zdecydować, co zrobić z niekompletnym zamówieniem. Jeśli dział sprzedaży wpisuje unikalne nazwy klientów, podczas gdy dział finansowy fakturuje na podstawie nazw prawnych, duplikaty rekordów partnerów nie powstają z powodu błędu technologicznego.

Dlatego nie warto traktować jakości danych jako jednej kategorii błędów. W praktyce liczy się dokładność, kompletność, spójność, aktualność i jednoznaczność. Nawet wczorajsze, ale dokładne dane magazynowe mogą stanowić problem, gdy dziś trzeba złożyć obietnicę realizacji klientowi.

Kto odpowiada za jakość danych w integracji systemów w praktyce?

Odpowiedzialność jest podzielona, ale nie może być niejasna. Każda krytyczna grupa danych powinna mieć właściciela biznesowego, odpowiedzialnego za operacje i odpowiedzialnego technicznie. Nie zawsze są to trzy różne osoby w firmie 20-osobowej, ale trzy perspektywy muszą być obecne.

Właściciel danych biznesowych decyduje, które dane są poprawne

Właściciel danych biznesowych zna znaczenie i konsekwencje danych. Na przykład kierownik handlowy może być odpowiedzialny za dane klientów i cen, kierownik magazynu za zasady operacyjne dotyczące stanów magazynowych i bazy produktów, a kierownik finansowy za dane dotyczące fakturowania i podatków.

To nie oznacza, że musi ręcznie poprawiać każdy rekord. Jego zadaniem jest określenie, które dane są oficjalne, w jakiej formie powinny być rejestrowane, co uważa się za dopuszczalne odchylenie i co zrobić w przypadku błędu. Na przykład decyduje, kiedy nowy produkt może osiągnąć status sprzedażowy i kto może zatwierdzić jednostkę miary lub stawkę VAT w bazie produktów.

Bez właściciela danych biznesowych IT często jest zmuszone do podejmowania decyzji biznesowych. W takich przypadkach programista lub administrator systemu wybiera logikę zamiast brakujących informacji. Może to wydawać się szybkie, ale później prowadzi do wątpliwego działania: system robi to, co zostało ustawione, ale niekoniecznie to, czego potrzebuje biznes.

Właściciel procesu odpowiada za poprawne tworzenie danych

Błąd danych najczęściej nie powstaje w warstwie integracyjnej. Powstaje wcześniej: podczas przyjmowania zamówienia, zakupu, odbioru, dodawania produktu lub importu pliku Excel. Właściciel procesu bada, gdzie, kto i w jakich okolicznościach rejestruje dane.

Weźmy prosty przykład. Magazyn regularnie otrzymuje zamówienia, do których nie podano odpowiedniego sposobu dostawy. Rozwiązaniem niekoniecznie jest, aby magazyn nadal dzwonił do działu sprzedaży lub aby integrator pisał kolejną regułę wyjątku. Najpierw trzeba zrozumieć, dlaczego brakuje danych. Czy pole nie jest obowiązkowe w sklepie internetowym? Czy obsługa klienta wprowadza zamówienie z e-maila? Czy nie jest jasne, który przewoźnik jest używany dla którego produktu?

Dobry właściciel procesu nie szuka szybkości naprawy błędów, ale przyczyny ich powstawania. Dzięki temu można zmniejszyć powtarzającą się administrację pracowników oraz ryzyko, że doświadczony pracownik będzie pamiętał wszystkie wyjątki.

IT i integrator odpowiadają za techniczną ścieżkę danych

Odpowiedzialność techniczna polega na zapewnieniu, że zaakceptowane zasady biznesowe działają niezawodnie między systemami. Obejmuje to mapowanie pól, zarządzanie identyfikatorami, sprawdzanie obowiązkowych pól, obsługę błędów, rejestrowanie, uprawnienia i monitorowanie.

Odpowiedzialność integratora systemów jest szczególnie istotna, gdy systemy różnie interpretują te same dane. Data może być datą realizacji, datą zamówienia lub oczekiwaną datą dostawy. „Aktywny” produkt może oznaczać, że może być widoczny w sklepie internetowym, ale także, że magazyn może go wydać. Nie można tego zakładać.

Techniczna realizacja musi również pokazywać, jeśli coś nie przeszło. Cicha awaria synchronizacji jest szczególnie niebezpieczna. Jeśli zamówienie nie zostanie wprowadzone do ERP z powodu błędnych danych, zespół nie powinien dowiedzieć się o tym od niezadowolonego klienta lub z raportu Excel przygotowanego podczas codziennego zamknięcia. Potrzebna jest wyznaczona kolejka błędów, powiadomienie i wyraźny odpowiedzialny za ich przetwarzanie.

Bez systemu źródłowego spór będzie trwały

Podstawową zasadą dla danych zarządzanych w wielu systemach jest to, że każda istotna dana powinna mieć wyznaczone główne źródło. Nie oznacza to, że wszystkie dane mogą istnieć tylko w jednym miejscu. Oznacza to, że jeśli występuje różnica, wiadomo, które dane systemu są wiodące.

Baza produktów może należeć do ERP, a sklep internetowy jedynie wyświetla i uzupełnia ją o treści marketingowe. Źródłem zgody na komunikację z klientem może być CRM, podczas gdy dane fakturowe pochodzą z systemu finansowego. W przypadku danych magazynowych szczególnie ważne jest, aby dokładnie określić, czy autorytatywny jest system zarządzania magazynem fizycznym, ERP czy system produkcyjny.

Wyznaczenie systemu źródłowego czasami wymaga podjęcia niewygodnych decyzji. Może się zdarzyć, że dział straci swobodę w modyfikowaniu danych we własnej tabeli. W zamian zniknie sytuacja, w której w piątek trzech menedżerów przesyła sobie trzy różne liczby dotyczące przychodów lub stanów magazynowych. Celem nie jest centralizacja dla samej centralizacji, ale zapewnienie wiarygodnej podstawy do podejmowania decyzji.

Odpowiedzialność należy przekształcić w mierzalne działanie

„Zwracajmy większą uwagę na dane” to nie jest system zarządzania jakością danych. Zarząd powinien wybrać kilka wskaźników istotnych dla biznesu: ile zamówień przychodzi z niekompletnymi danymi, ile rekordów partnerów jest zduplikowanych, jak długo trwa naprawa błędu integracji, ile ręcznych korekt jest potrzebnych w miesiącu i jaka jest różnica w danych magazynowych między systemami.

Nie każdy błąd warto natychmiast eliminować do zera. Obsługa rzadkiego, niskowartościowego wyjątku może kosztować więcej niż sam błąd. Inaczej jest, gdy różnica dotyczy fakturowania, realizacji terminowej, planu produkcji lub obowiązków zgodności. Dlatego akceptowalny poziom jakości należy określić na podstawie ryzyka biznesowego.

Warto regularnie, krótko przeglądać sytuację z udziałem działu biznesowego, operacyjnego i IT. Nie jako techniczne spotkanie statusowe, ale z konkretnymi pytaniami: które dane błędne spowodowały najwięcej dodatkowej pracy, gdzie pojawiła się nowa ręczna ścieżka obejścia, która zasada już nie odzwierciedla rzeczywistego działania? W rosnącej firmie proces, który był poprawny w zeszłym roku, łatwo może stać się wąskim gardłem w tym roku.

Jakość danych to w rzeczywistości dyscyplina operacyjna

Ostatecznie za jakość danych w integracji systemów odpowiada zarząd, ponieważ to on musi wyznaczyć ramy własności i podejmowania decyzji. Właściciel danych biznesowych odpowiada za znaczenie danych, właściciel procesu za ich poprawne tworzenie, a IT i integrator za to, aby informacje były weryfikowalne, bezpieczne i śledzone do odpowiedniego miejsca.

Jeśli te role są jasne, integracja nie będzie niewidocznym, niepewnym procesem w tle. Zapewni podstawę operacyjną, na której zespół będzie mógł budować wzrost z mniejszą ilością poprawek, szybszym podejmowaniem decyzji i większą przewidywalnością.