Labirynt do przejścia

Uniwersalny przepis na integrację systemów nie istnieje. Wybór metody powinien być uzależniony m.in. od liczby systemów, częstotliwości wymiany danych i liczby potencjalnych beneficjentów integracji.

Uniwersalny przepis na integrację systemów nie istnieje. Wybór metody powinien być uzależniony m.in. od liczby systemów, częstotliwości wymiany danych i liczby potencjalnych beneficjentów integracji.

Trudno sobie wyobrazić organizację, która posługuje się tylko jednym systemem informatycznym. Informatyzacja przeprowadzana etapami to bowiem naturalna kolej rzeczy. Jako pierwsze wdraża się na ogół systemy finansowo-księgowe i sprzedażowo-magazynowe. Później pojawia się potrzeba usprawnienia obsługi klienta, spraw kadrowo-płacowych itd. Wraz ze wzrostem skali firma staje się coraz bardziej uzależniona od informatyki, a w zasadzie od informacji. Tymczasem aplikacje tworzone na przestrzeni długiego czasu, przez różnych producentów i przy użyciu różnych narzędzi rzadko ze sobą współpracują.

Oczywiście, istnieją wyjątki w postaci organizacji, które mają wdrożone systemy całościowo zaspokajające potrzeby biznesowe. Wystarczy jednak zmiana właściciela, połączenie z inną firmą czy nawet uruchomienie nowego kanału dystrybucji, aby zburzyć zwykle ten nietrwały, by nie rzec nienaturalny, stan. Pojawienie się wyzwania w postaci konieczności integracji systemów jest w większości firm tylko kwestią czasu - nie ma od niego ucieczki.

W każdej firmie zarówno potrzeby w dziedzinie integracji, jak i sposób ich zaspokojenia mogą z różnych względów wyglądać odmiennie. Jedno jest pewne - celem integracji i ostatecznym weryfikatorem wysiłków w tej dziedzinie jest możliwość współdzielenia informacji przyczyniająca się do poprawy sprawności operacyjnej organizacji.

Prosta droga

Najprostszą i jednocześnie najczęściej wykorzystywaną metodą integrowania systemów jest przenoszenie zbiorów tekstowych między bazami danych. Ta forma integracji nie wymaga od członków zespołu projektowego specjalnych umiejętności, poza oczywiście znajomością poszczególnych systemów źródłowych, oraz sprawności w posługiwaniu się językiem SQL.

Oto przykład. Aby móc zbudować, a następnie kalibrować system motywacyjny dla handlowców, dział personalny chciałby mieć możliwość podglądu obrotu wygenerowanego przez każdego z nich, dane te są przechowywane w systemie finansowo-księgowym. Informacje są potrzebne raz w miesiącu, dlatego integracja na poziomie danych w tym przypadku nadawałaby się wręcz idealnie. Sprawę załatwia jedno proste wyrażenie SQL, które do rekordu pracownika w systemie kadrowo-płacowym dopisuje statystyki sprzedażowe z systemu finansowo-księgowego.

Wspomniana metoda sprawdza się przede wszystkim tam, gdzie wymiana danych następuje w określonych interwałach, np. raz dziennie, co tydzień lub co miesiąc - zwykle w nocy, w czasie najmniejszego obciążenia integrowanych systemów. W razie awarii tego "pomostu" nie otrzymamy żadnej informacji poza tą, że nie działa, nie dowiemy się jednak od kiedy ani też, czy ostatnie dane zostały załadowane prawidłowo. Konieczność zwrócenia części wynagrodzenia w związku z jego niepoprawnym wyliczeniem lub jego zaniżenie ma raczej niewiele wspólnego z motywowaniem pracowników. To samo dotyczy praktycznie każdej dziedziny, w której od informacji przetwarzanych elektronicznie zależy realne działanie. Bez dedykowanego mechanizmu monitorującego poprawność przepływu danych integrowanie systemów jest nieuchronnie skazane na błędy.