Planowanie integracji firm oraz faktyczna jej realizacja odbywa się na różnych płaszczyznach: budowania docelowego modelu operacyjnego, realizacji synergii, zasobów ludzkich czy też integracji funkcjonalnej. W przypadku fuzji i przejęć jednym z aspektów, których nie można pominąć, jest technologia. Tego problemu nie należy bagatelizować, zwłaszcza w firmach z bardzo rozwiniętymi systemami informatycznymi, a do takich bezsprzecznie należą banki. Oczywiście wszystko przebiega w trzech etapach: planowania, realizacji i monitorowania rezultatów. Jedną z tajemnic powodzenia każdej zmiany jest zaangażowanie w nią członków kadry zarządzającej – im wcześniej, tym lepiej. Wówczas fakt przejęcia odpowiedzialności nie pozwoli się im zdystansować wobec całego przedsięwzięcia i jego rezultatów, a już samo to wróży sukces.
KWESTIE INTEGRACJI
Połączenie dwóch systemów może spowodować, że na przykład powstanie skomplikowana sieć interfejsów łączących nie tylko systemy płatności i kanały płatności, ale również systemy podstawowe. Ponieważ pewne funkcje występują we wszystkich systemach bankowych (płatności, zarządzanie ryzykiem, zabezpieczenia przed oszustwami, bezpieczeństwo itp.), więc najkorzystniej będzie jeżeli zostaną one połączone, ale… Właśnie z powodu tego „ale” nie są to rozwiązania proste, zwłaszcza jeżeli dotyczą strategii zarządzania ryzykiem (i systemów do jej realizacji) i zarządzania bezpieczeństwem. Najlepiej jeżeli możliwa jest integracja aplikacji, bo wówczas istniejące już systemy można połączyć z nowymi technologiami, bez potrzeby zmieniania systemów i bez pracy programistów. W efekcie powstanie jeden spójny przepływ procesów biznesowych w prostej strukturze.
Banki – tak jak inne przedsiębiorstwa – wykorzystują zintegrowane systemy do zarządzania przedsiębiorstwem i oprogramowanie do zarządzania infrastrukturą oraz specjalistyczne systemy biznesowe. W sytuacji gdy te same funkcje są w stanie realizować systemy różnych producentów, warto chyba decydować się na integrowanie specjalistycznych produktów wielu producentów zamiast wymiany części z nich na rozwiązania tylko jednego dostawcy (nawet jeżeli są one w danej chwili najlepsze). Co prawda wtedy oprócz integracji procesów może pojawić się kolejny problem związany z integracją danych – problem z rozwiązaniem którego banki i tak mają kłopot. Jeżeli łączone podmioty miały zupełnie inne procesy biznesowe i były w odmienny sposób zarządzane, to niewątpliwie trzeba te procesy zintegrować – inaczej nie będzie możliwa integracja danych.
To nie wszystko, bo pozostaje jeszcze kwestia integracji aplikacji. Jest ona szczególnie istotna w przypadku rozwiązań, które powstawały niezależnie od siebie i nie projektowano wymiany informacji między nimi. W takim przypadku można wykorzystać rozwiązania tzw. midleware (oferuje je np. Sybase). Pozwalają one na wymianę informacji między najróżniejszymi systemami, co umożliwia integrację danych na najniższym poziomie, jednak pod warunkiem zezwolenia użytkownikowi na modelowanie danych. Jest to ważne z powodu ciągle zmieniających się warunków biznesowych wymagających modyfikowania narzędzi informatycznych. Istota tego rozwiązania polega na bardzo szybkim zintegrowaniu zasobów informatycznych i późniejszym ich modelowaniu – i to jest jeden ze sposobów rozwiązania problemu.
Innym rozwiązaniem w takiej sytuacji jest zastosowanie hurtowni danych, a połączenie ich daje jeszcze inną możliwość – korzystania z danych zgromadzonych w różnych systemach również w sytuacjach przejściowych, np. w procesach konsolidacji firm. Oczywiście to ciągle nie jest odpowiedź na pytanie, w jaki sposób powinna być prowadzona integracja systemów informatycznych. Rozsądek podpowiada, że dobrze jest mieć odpowiedniego partnera wdrożeniowego. Na przykład konsultanci Infovide są zdania – z którym trudno się nie zgodzić – że projektów integracyjnych nie można realizować ad hoc, lecz rozpocząć od próby technologicznej wybranego procesu biznesowego i działając w sposób nieinwazyjny, zrealizować pierwszy etap prac. Dopiero po pozytywnym zakończeniu prób można planować dalsze etapy wdrożenia, mając na uwadze cel projektu.
ORIENTACJA NA USŁUGI
Rozwiązaniem niektórych problemów spowodowanych odmiennością systemów informatycznych stała się SOA (Service Oriented Architecture), architektura zorientowana na usługi. Jest to koncepcja budowania systemów informatycznych, w której największy nacisk kładzie się na definiowanie usług, które spełniają wymagania użytkownika. Jako usługę określa się każdy element oprogramowania, który może działać niezależnie od innych i posiada wyspecyfikowany interfejs, za pomocą którego udostępnia realizowane funkcje. Przepływ danych między różnymi elementami platformy systemowej odbywa się swobodnie przez wspólne, dostępne dla wszystkich medium komunikacyjne z niezależnym protokołem komunikacyjnym. W sumie architektura SOA przypomina obiekty rozproszone z niezależnie definiowanymi interfejsami usług, niezależnymi również od platformy operacyjnej.
Kolejnym elementem ułatwiającym łączenie systemów jest szyna ESB (Enterprise Service Bus) bazująca na standardach. ESB łączy messaging, web services, XML, transformacje danych oraz zarządzanie łączeniem i koordynacją interakcji aplikacyjnych. Aplikacje do komunikacji wykorzystują wiadomości XML i dlatego nie ma problemu z protokołami komunikacyjnymi i ich fizyczne rozlokowanie nie jest ważne. ESB traktuje wszystkie aplikacje jako niezależne usługi podłączone do szyny. Za pomocą niezależnych narzędzi można stosunkowo łatwo tworzyć interfejsy usługowe wbudowane w Java 2 Platform Enterprise Edition i środowisko Net Microsoftu. Technologie używane w ramach ESB są oparte na standardach, co jest bardzo ważne, bo zdecydowanie ułatwia integrowanie systemów.
Systemy informatyczne są coraz bardziej złożone, a to powoduje, że ich integracja stała się problemem do rozwiązania. Widać więc, że jak zwykle nie ma rozwiązania uniwersalnego i być może dlatego w praktyce bywa to tak trudnym zadaniem, że czasem prowadzi do klęski. Globalizacja wymusza łączenie się firm na nie spotykaną dotąd skalę, co skłoniło firmę analityczną Gartner Group do przeprowadzenia badań, z których wynika, że trzy czwarte wszelkich fuzji kończy się fiaskiem, a jedną z przyczyn są problemy w integracji systemów informatycznych. W 1985 roku na rynku były m.in.: Burrougs, Bull, CDC, DEC, Fujitsu, Hitachi, Honeywell, IBM, ICL, NCR, NEC, Nixdorf, Olivetti, Siemens, Sperry. Aktualnie stawka wielkich jest inna… DEC, druga (po IBM) tzw. full-line company, oferująca klientom własne standardy w niemal całym spektrum produktów informatycznych – od sieci, przez bazy danych, aż po drukarki – została połknięta przez Compaqa, po którym dzisiaj pozostało tylko wspomnienie, bo marka razem z produktem jest już własnością koncernu Hewlett Packard.
Monika Andrycz odpowiada za projekty z zakresu fuzji i przejęć w IBM Global Business Services:
– Doświadczenia konsultantów IBM Global Business Services z realizacji ponad 1000 projektów fuzji i przejęć pokazują, że stosowanie szeroko rozpoznawanych i uznanych metod skutkuje integracją zapewniającą dostarczenie wartości dla udziałowców, przy zasadniczym zmniejszeniu ryzyka niepowodzenia. Prowadzi również do przełożenia celów związanych z akwizycją na kompletny program działań przyczyniających się do wzrostu opartego na szansach rynkowych. Niestety, często dyskusje na temat modelu operacyjnego przebiegają bez należytego rozumienia rynku, możliwości biznesowych oraz strategii przyszłej zintegrowanej firmy. Mają również tendencję do wykraczania poza wymagany integracją zakres. W takich sytuacjach należy ograniczyć zakres zmian w modelu operacyjnym do niezbędnych elementów, które w najwyższym stopniu przyczyniają się do zwiększenia wartości dla udziałowców. Próby realizacji wszystkiego naraz są zarówno niepotrzebne, jak i niemożliwe. Szacunki dotyczące potencjalnych synergii są przygotowywane bez pełnego zrozumienia docelowego modelu operacyjnego. To co jest ustalane w gabinetach okazuje się trudne lub niemożliwe do realizacji – aż 50 proc. synergii przestaje istnieć w momencie funkcjonowania już połączonych jednostek biznesowych. Należy więc przez cały czas monitorować korzyści i koszty. Pomyślna integracja zależy nie tylko od klientów, dostawców i partnerów biznesowych, ale również od pracowników. Wiadomo, że odmienne metody pracy, różnice w kulturach organizacyjnych, walka o przyszłe stanowiska wśród kadry kierowniczej nie sprzyjają integracji. Wówczas trzeba zadbać o odpowiednią komunikację zmian i zapewnienie spokoju. Należy zaangażować kluczowych pracowników obu stron w proces zmian, włączając jednocześnie element zmiany kultury organizacyjnej w program transformacji.
Marek Kucharski, prezes zarządu Parasoft w Polsce:
– Rozwiązaniem, które ułatwia integrację systemów IT, jest architektura SOA (Service Orientem Architecture), w której różne funkcje przedsiębiorstwa są odwzorowane jako tzw. usługi. Każda z nich może być wykorzystana jako część procesu biznesowego, który zastępuje pracę człowieka. SOA umożliwia zatem i ułatwia łączenie procesów, w których współpracują ze sobą pracownicy i części systemów. Użycie SOA gwarantuje też większą wydajność i niższe koszty realizacji procesów biznesowych przedsiębiorstwa. W momencie rozpoczęcia działania serwisu SOA może on być włączony w proces biznesowy, którego nie jesteśmy właścicielem, co zwiększa naszą odpowiedzialność. Powinniśmy również zwrócić uwagę na kilka innych spraw: serwis musi zawsze poprawnie odpowiadać na pytanie, ale jednak musi się on poprawnie zachować również wtedy, gdy otrzyma niepoprawne zapytanie. Ponieważ nie kontrolujemy kto pyta, nie kontrolujemy także jak pyta. W obu przypadkach pomocne są zestawy testów automatycznych, najlepiej tworzonych przy użyciu jakiegoś dostępnego na rynku narzędzia. Użytkownicy serwisu mogą też próbować uzyskać informację, do której nie mają uprawnień, dlatego należy autoryzować użytkownika, zabezpieczyć się przed włamaniami, reglamentować informację oraz monitorować zachowanie użytkowników i sprawdzać czy odpowiada ich profilowi. Kolejną ważną rzeczą jest przystosowanie serwisu do obciążenia. System musi też być gotowy na nagłe zwiększenie obciążenia i powinien być właściwie przetestowany. To tylko podstawowe problemy, z jakimi należy się liczyć przy integracji systemów w SOA. Na szczęście korzyści znacząco przewyższają koszty i wysiłek, jakie trzeba włożyć w integrację.
Platformy systemowe wykorzystywane w instytucjach finansowych (wybór)
– AIX
– HPUX
– Linux
– Mainframe
– Solaris
– Windows
Współczesne wyzwania dla systemów bankowych:
– otwarte interfejsy oparte na usługach sieciowych i JMS
– łączność JCA z gotowymi aplikacjami (np. SAP)
– obsługa poczty elektronicznej
– łączność z bazą dostępową SWIFT
– graficzne narzędzia do transformacji umożliwiające definiowanie zasad konwersji danych
– zautomatyzowane zarządzanie wyjątkami (w przypadku problemów przewidywalnych)
– eliminowanie zbędnego komunikowania przez sieć SWIFT.net
– przepływy pracy umożliwiające śledzenie komunikatów i uzgadnianie ich treści
– oddzielenie odbiorców danych od składnic danych
– automatyczne przywracanie funkcji serwera po awarii
– duża regulowana wydajność systemu
