Od konieczności integracji danych nie ma ucieczki nawet w systemach zintegrowanych. Zawsze pozostaje coś poza głównym systemem, może nawet drugi i trzeci system ERP, zawsze pozostaje wymagająca analityka biznesowa, wreszcie - nie da się uciec od inwencji użytkowników systemu.

Nie da się oddzielić projektu wdrożenia systemu ERP, ani jego aktualizacji, ani połączenia dwóch systemów ERP po fuzji, ani nawet projektu połączenia dwóch instancji tego samego systemu od projektu integracji danych. Trudno również mówić o jakimkolwiek wdrożeniu systemu Business Intelligence opartego na hurtowni danych czy bazach typu data marts, omijając problem integracji. Próba wdrożenia jakiejkolwiek analityki biznesowej ujawnia natychmiast, czy system zintegrowany faktycznie jest zintegrowany, a jednocześnie uzmysławia zazwyczaj przedsiębiorstwu, że wdrożenie systemu ERP nie wyeliminowało wcale rozmaitych systemów pobocznych, na których polegają działy sprzedaży, marketingu czy produkcji. Zdarzało się, że dwie firmy przejęte przez tego samego konsolidatora rynku z zaskoczeniem konstatowały, jak duży projekt integracyjny je czeka, mimo tego że wdrożyły wcześniej, jeszcze jako niezależne podmioty, systemy tego samego producenta, co więcej, w tych samych wersjach i nie dokonując specjalnie dużej liczby modyfikacji. Im dłużej żyją systemy, tym większa jest liczba dokonywanych w nich modyfikacji i tym bardziej rośnie inwencja użytkowników wykorzystujących dostępne pola w zupełnie nieprzewidzianych przez programistów i projektantów systemów zastosowaniach, tym samym trudniejsza staje się integracja. Kilkanaście lat temu firmy wdrażające systemy ERP z dużym naciskiem mówiły o konieczności uświadomienia przyszłym użytkownikom faktu, że jakość wprowadzanych przez nich informacji ma konsekwencje dla pracowników firmy w innych działach i generalnie wszystkich użytkowników systemu. Dziś ta uwaga wcale nie traci na ważności, a wręcz zyskuje, biorąc pod uwagę, jak rozwija się analityka biznesowa już nie tylko w największych, ale również średnich i całkiem małych firmach. Problem integracji jest szczególnie palący w firmach, które ze względu na swoje szczególne potrzeby utrzymują dwa lub więcej systemów ERP i mają świadomość, że sytuacja ta w dającej się przewidzieć przyszłości nie ulegnie zmianie, gdyż pierwszy system obsługuje od lat szczególny rodzaj produkcji mającej miejsce w wybranym kraju, drugi system jest standardem korporacyjnym w obszarze finansów, natomiast trzeci wykorzystywany jest na poziomie regionu w sterowaniu sprzedażą i dystrybucją.

Jak do tego podejść?

Opracowanie sensownej strategii integracji danych, niezależnie od tego, czy będzie ona dotyczyć integracji dwóch działających jednocześnie systemów ERP, czy też przeniesienia danych ze starego do nowego systemu, czy wreszcie wyekstrahowania danych na potrzeby systemu BI, wymaga przejścia przez wiele dających się opisać etapów.

Integracja danych rozpoczyna się od możliwości podłączenia się do źródeł danych zarówno poprzez dedykowane interfejsy, jak i przy użyciu standardowych mechanizmów, takich jak ODBC czy JDBC. Źródłami danych mogą być relacyjne lub hierarchiczne bazy danych, pliki płaskie, pliki strukturalne takie jak XML, a także systemy ERP. Połączenie powinno umożliwiać nie tylko odczyt, ale też zapis danych. W przypadku większości firm mamy do czynienia ze złożonymi środowiskami informatycznymi i mechanizmy dostępu powinny pozwalać na sięgnięcie do danych znajdujących się na różnych platformach, o ile to możliwe bez konieczności używania plików pośrednich lub ekstraktów. Aby rozwiązanie było kompletne, wymagane jest wsparcie dla kolejek wiadomości czy usług Web. Rozwój technologii sprawia, że w dalszej perspektywie pojawi się - dziś jeszcze słabo zaznaczona - konieczność korzystania z niestrukturalnych źródeł danych, np. dokumentów tekstowych.

Co my tu mamy?

Wydaje się, że w wielu projektach integracji danych część zdrowego rozsądku pozostawiamy za drzwiami przed rozpoczęciem pracy. Często pomijamy lub bardzo ograniczamy etap zrozumienia danych przed ich integracją. Potem, w połowie trwania projektu, nagle okazuje się, że nasze źródła danych nie są tym, czym sądziliśmy, że są. Pola tekstowe zawierają liczby, pole "płeć" zawiera pięć kategorii, faktury wskazują na nieistniejących klientów, zlecenia sprzedaży zawierają wartości ujemne itd. Częścią problemu jest to, że zbyt ufamy katalogom systemowym (metadanym) aplikacji źródłowych. Użytkownicy potrafią adaptować istniejące pola do zapisywania nowych typów informacji. Telemarketerzy mogą np. wpisywać kody odpowiedzi na kampanie reklamowe w polu "data urodzenia", ponieważ departament marketingu chce zbierać taką informację, a w systemie nie zostało przewidziane pole do jej wprowadzenia. Często programiści, którzy zaprojektowali system, nigdy nie udokumentowali go w całości lub zdążyli opuścić firmę i zabrali tę wiedzę ze sobą. Dlaczego analitycy nie są w stanie odpowiednio wcześnie odkryć problemów z danymi? Często wykorzystują jedynie manualne metody analizy zawartości źródeł danych, próbkując dane na kilku - wydaje się - kluczowych polach. Jakość podejścia do profilowania danych zależy nieuchronnie od wiedzy i doświadczenia analityka. Aby zminimalizować takie problemy, kompletna platforma integracji danych powinna zawierać specjalistyczne narzędzia profilowania danych, które są w stanie zeskanować każdy indywidualny rekord, każdą kolumnę, każdą tabelę w systemie, zwracając raporty zawierające wszystkie interesujące statystyki oraz wykresy pozwalające na łatwe i szybkie zrozumienie wszystkiego, co tylko powinniśmy wiedzieć o danych. Przy wykorzystaniu takich narzędzi nasze szanse na odnalezienie nowych lub nieoczekiwanych struktur i wartości znacznie wzrastają. Przy okazji narzędzia te nie wymagają angażowania administratorów IT, którzy tradycyjnie przekazują raporty na temat danych specjalistom biznesowym do oceny.

Integrując dane pochodzące z kilku niezależnych systemów, spotykamy się z problemem identyfikacji kluczy połączeń. Przykładem może być konieczność zebrania danych dotyczących tego samego klienta, gdy informacje o nim są zapisane w każdym systemie w inny sposób. Spotkamy się z przypadkami, gdy nazwisko łącznie z adresem jest zapisane w jednym polu, gdy np. płeć lub adres są zakodowane za pomocą własnych słowników, lub gdy części danych będzie brakować. Pierwszym krokiem, jaki należy wykonać, jest parsowanie umożliwiające rozbicie pól tekstowych na bardziej użyteczne fragmenty i pozwalające prawidłowo zidentyfikować poszczególne elementy: nazwiska, imiona, ulice, numery domów itd. Reguły parsowania muszą bazować na typach danych, a kompletne platformy narzędzi integracji danych powinny zawierać gotowe słowniki, gramatyki, reguły pozwalające wykonywać tę operację w sposób efektywny. Oprócz standardowych sposobów parsowania, właściwych dla typowych danych należy zawsze mieć możliwość rozbudowy reguł, aby uwzględnić przypadki wynikające ze specyfiki danych odbiorcy. Następnym krokiem jest standaryzacja, czyli doprowadzenie danych oznaczających to samo do wspólnej postaci. Dobrym przykładem jest standaryzacja nazw firm, w przypadkach gdy ta sama nazwa może być zapisana w dziesiątkach wariantów. Również w przypadku tego fragmentu integracji danych ważną sprawą jest budowanie środowiska współpracy, gromadzenia i wymiany informacji w ramach organizacji. Tworzenie i opieka nad regułami rozpoznawania i łączenia danych jest zadaniem ekspertów biznesowych, a nie programistów. Platformy integracji danych muszą mieć to na uwadze i zapewniać odpowiednio zintegrowane narzędzia zaprojektowane z myślą o wygodzie pracy różnych grup użytkowników.

Mantra BI: jakość danych

Praktyka budowy hurtowni danych wskazywała, że jednym z głównych problemów, z jakimi trzeba się zmierzyć, jest "zapewnienie odpowiedniej jakości danych". Dokładnie ten sam problem występuje we wszystkich innych projektach integracji danych. Zauważmy, że problemy z jakością danych niekoniecznie są wynikiem błędnych reguł lub procesów wdrożonych w firmie. Czasami dane po prostu się starzeją, co najlepiej widać na przykładzie danych osobowych: zmieniają się nazwiska, adresy, osoby w ramach gospodarstwa domowego. Tak więc nawet jeśli posiadamy wdrożone najlepsze dostępne procedury korekty danych, to wciąż w naszych systemach będą się pojawiać dane niespójne lub niepełne. Kompletne środowisko integracji danych powinno zawierać mechanizmy zapewnienia jakości danych. Zwróćmy uwagę na kilka elementów, które powinny być częścią takich rozwiązań. Po pierwsze istotna jest możliwość definiowania własnych reguł oceniających poprawność danych, reguł zwykle zależnych od specyfiki klienta. Następną rzeczą, gdy już wiemy które dane są błędne, jest budowa reguł korekty lub usuwania. W obu tych przypadkach mamy do czynienia z zadaniami, które wymagają wiedzy merytorycznej i powinny być wykonywane nie przez informatyków, ale przez specjalistów biznesowych. Wykorzystywane narzędzia powinny to uwzględniać i brać pod uwagę odmienność upodobań i sposobów pracy. Równie cenna jest integracja narzędzi w taki sposób, aby wiedza zdobyta i zgromadzona w postaci reguł biznesowych mogła być łatwo i szybko zastosowana w różnych projektach integracji danych. Klasycznym przykładem może być wykorzystanie reguł powstałych na użytek procesu ETL hurtowni danych do tego, aby budować jakość danych na samym początku, sprawdzając poprawność nazwisk i adresów w punkcie wprowadzania danych do systemu ERP lub CRM. Zapewnienie jakości danych jest procesem ciągłym i nie może być ograniczone do izolowanego, ograniczonego w czasie projektu.

Integracja metadanych

Informacja, która pozostaje niezorganizowana i odizolowana od innych danych, jest niemal bezużyteczna. Celem integracji danych jest więc połączenie różnych źródeł danych i zebranie ich w taki sposób, aby wartość danych jako całości była większa. Dużo łatwiej jest to osiągnąć, gdy każdy z etapów integracji współdzieli metadane z innymi fragmentami środowiska; gdy parametry połączenia do źródeł danych zdefiniowane zostaną raz, a następnie wykorzystane we wszystkich narzędziach, czy to używanych przez informatyków, czy to przez administratorów, czy wreszcie przez odbiorców biznesowych; gdy wyniki profilowania danych są zapisywane we wspólnym repozytorium i mogą być wykorzystane przy innych projektach; gdy definicje reguł biznesowych związanych z dopasowaniem lub poprawą jakości danych są wspólne w ramach wszystkich źródeł danych, systemów i projektów. Dodatkowo wspólne metadane pozwalają prześledzić, które dane pochodzą z których systemów, jakie reguły biznesowe zostały zastosowane. Problem uporządkowania metadanych jest krytycznym zagadnieniem, przed którym stają organizacje. Brak profesjonalnego podejścia do tego zagadnienia zwykle prowadzi do późniejszych problemów i dodatkowych kosztów.

<hr>Współautorami tekstu są: Piotr Borowik, starszy konsultant, oraz Adam Bartos, dyrektor ds. technologii. SAS Institute.