W dużej firmie infrastruktura bywa scentralizowana, ale kompetencje aplikacyjne - nie zawsze, zwłaszcza po fuzjach firm. Jak rozsądnie można rozwiązać problem geograficznego rozproszenia zasobów? Czy warto dążyć do centralizacji za wszelką cenę? Co sprawdziło się w polskich warunkach?

Gdyby współczesna informatyka miała brać przykład z dzisiejszego przemysłu, mogłoby się okazać, że każdy składnik zarówno fizyczny, jak i logiczny infrastruktury informatycznej znajdowałby się geograficznie w innym miejscu i jeszcze z innej lokalizacji byłby zarządzany.

W informatycznej praktyce nie dochodzi do aż tak skrajnych rozwiązań, ale spotyka się najróżniejsze modele - od takich, w których wszystko jest razem i blisko siebie, do przypadków, gdzie nader luźne związki między rozrzuconymi po świecie zasobami skłaniają do zastanowienia - jak to wszystko w ogóle działa?

Bawarczycy lubią się chwalić, że u nich układy elektroniczne produkowane po jednej stronie monachijskiej ulicy trafiają wprost do samochodów, które wytwarza się naprzeciwko. W rzeczywistości droga ta jest długa, a bywa i zawiła, wyznaczając szlak tzw. łańcucha dostaw. Szlakiem tym oprócz namacalnych produktów płyną również informacje, w czym uczestniczą rozmaite systemy informatyczne. Odmienność poszczególnych systemów oraz terytorialne rozproszenie ich zasobów nie stanowią jednak żadnej przeszkody w ich sprawnej współpracy.

W tym momencie można zadać, chociażby tylko retoryczne, pytanie: czy centralizacja zasobów informatycznych (a tym samym i informacyjnych) wszystkich uczestników takiego łańcucha dostaw przyniosłaby jakieś wymierne korzyści dla całego procesu i poszczególnych jego uczestników?

Zwolennicy rozwiązań silnie scentralizowanych wskażą na niższe koszty i lepszą integrację. Sceptycy powiedzą, że w istocie nic się nie zmieniło, bo poszczególne systemy, mimo że działają w jednym miejscu, to zachowały przecież swą odmienność i własne zasoby danych. Przeciwnicy orzekną zaś, że owszem, jest może nieco taniej niż osobno, ale ryzyko większe, bo wisi nad wszystkimi naraz, nikt nie ma pełnej kontroli nad tym, co wyłącznie jego i niełatwo jest wyłamać się stamtąd i wrócić ze swoim do siebie.

Komplikując nieco powyższy przykład można założyć, że w łańcuchu powiązań kooperacyjnych uczestniczą czterej partnerzy, a piątym jest ostateczny odbiorca. Co stanie się, jeżeli np. pierwszy z tych partnerów przejmie trzeciego? Sekwencja dostaw albo się nie zmieni i nadal będzie to 1-2-3-4-5, albo drugi przestanie być uczestnikiem łańcucha i stanie się partnerem wyłącznie dla połączonego 1/3. Pierwszy może próbować narzucić trzeciemu własny system informatyczny, chyba że przeszkodą w tym będzie zasadniczo różny charakter produkcji jednego z nich (niektóre systemy ERP niezbyt dobrze sobie radzą w niektórych gałęziach przemysłu, np. chemicznym). Może też zrezygnować z własnego systemu i objąć siebie tym, który ma trzeci. Zakładając, że trzeci, mimo przejęcia nie zmieni lokalizacji, to możliwy jest i taki wariant, w którym pierwszy i trzeci tak zreorganizują swe środowiska informatyczne, że - działając na jednym wspólnym systemie - staną się one dla siebie środowiskami zapasowymi na wypadek awarii bądź sytuacji kryzysowej. O ile jednak nie przemawiają za tym jakieś względy bardzo szczególne - wykluczyć należy scenariusz, w którym obie strony rezygnują ze swych systemów dotychczasowych i wybierają zupełnie nowy, ale za to wspólny. Rozwiązanie takie byłoby możliwe i uzasadnione tylko w przypadku słabej przydatności lub bardzo ograniczonych, w stosunku do potrzeb, możliwości istniejących systemów.

Z punktu widzenia drugiego natomiast, każde rozwiązanie poza zachowaniem status quo jest niedobre, bo chcąc zachować rolę partnera organizacji powstałej w wyniku połączenia pierwszego i trzeciego, musi poczynić zmiany we własnych rozwiązaniach informatycznych i zrobić to pod dyktando nowej organizacji (przy założeniu, że drugi nie jest rozdającym karty koncernem globalnym).

Reality

W rzeczywistości sytuacja nie bywa tak idylliczna, ale nie zawsze też sprawdza się scenariusz "zwycięzca bierze wszystko". Dowodu na taki właśnie obrót spraw można by upatrywać w polskim przemyśle, jednak trzeba uwzględnić i to, że w chwili sprzedaży partnerom lub inwestorom zagranicznym, nieliczne tylko zakłady dysponowały dobrymi, w miarę nowoczesnymi rozwiązaniami informatycznymi. Dotyczyło to również firm nowo powstałych na przełomie lat 80. i 90., gdzie na ogół nie doceniano roli systemu informacyjnego i decydowano się na domorosłe często (by nie rzec: amatorskie) rozwiązania pod klucz, które stały się specjalnością polskiej informatyki tamtego okresu. Stan taki niejako automatycznie przesądzał o tym, jaki system informatyczny zostanie zastosowany w przejętej w Polsce części firmy.

Nie oznaczało to jednak, że najczęściej wybierano model z systemem centralnym za granicą, tylko użytkownikami którego stawali się pracownicy polskiej jednostki. W dużych przedsiębiorstwach przemysłowych pojawiała się często kopia systemu firmy-matki z całą własną infrastrukturą, najczęściej jednak zupełnie bez, lub ze skrajnie ograniczonym zespołem rozwojowym. Upraszczało to współpracę systemów w ramach ponadnarodowej grupy czy korporacji, umożliwiając jednocześnie lepsze dopasowanie systemów działających w poszczególnych krajach i zakładach do ich specyfiki oraz lokalnych potrzeb i wymogów.

Taki model informatyki

okazuje się mieć jeszcze jedną, rzadko wyróżnianą i braną pod uwagę zaletę: obecnie, gdy pojawiają się pierwsze, nieliczne jeszcze przypadki "obrotu wtórnego" nabytymi nie tak znowu dawno przedsiębiorstwami w Polsce, znacznie łatwiej jest oddzielić sprzedawany zakład od macierzy, gdy nie trzeba przecinać przy okazji tysięcznych więzów z jej systemem informatycznym.

Nie trzeba dodawać, że taki chirurgiczny zabieg pozbawia sprzedawaną jednostkę jakiejkolwiek obsługi informatycznej, a więc drastycznie obniża jej rynkową wartość.

Bodaj w kilku zaledwie przypadkach ośrodki informatyczne przy polskich przedsiębiorstwach przemysłowych okazały się tak prężne (i jednocześnie zapewne tańsze od zagranicznych), że powierzono im prace rozwojowe na potrzeby własne i całych korporacji, do których należały.

Trudno jednak doszukać się tu jakiejś uniwersalnej prawidłowości, poza niemal banalnym stwierdzeniem, że stopień autonomii i zakres działania służb informatycznych po polskiej stronie był na ogół większy w dużych firmach, podczas gdy organizacjom średnim i małym przypisywano rolę informatycznych satelitów jednostek macierzystych.

Banki zawsze inaczej

Inaczej zgoła sprawa przedstawia się w bankach, na co bez wątpienia znaczny wpływ ma to, że banki, jako instytucje zaufania publicznego, podlegają szczególnemu nadzorowi ze strony państwa. To zaś zostawia znacznie mniejszy zakres swobody decyzji ich właścicielom, szczególnie zagranicznym. Ograniczyło to do minimum przypadki, w których banki działające w Polsce korzystają z systemu informatycznego znajdującego się za granicą. Praktycznie każdy, uważany za główny, system informatyczny obsługujący bieżące transakcje, stosowany przez banki w Polsce, ma na miejscu całe swe środowisko sprzętowo-programowe. W większości przypadków również na miejscu działają zespoły zajmujące się rozwojem tych systemów i ich dopasowywaniem do bieżących potrzeb.

I niewiele zapewne pod tym względem się zmieni, gdyż jakiekolwiek przeniesienie poza Polskę jakichkolwiek danych o klientach, podstawowych dla każdego takiego systemu, jest obwarowane uzyskaniem zgody władz, o co wcale niełatwo. Niewiele też zmieniło pod tym względem przystąpienie Polski do Unii Europejskiej, co rozczarowało zapewne niektórych zagranicznych właścicieli banków w Polsce. W tzw. środowisku stale jednak mówi się o zamiarach niektórych z nich przeniesienia do krajów macierzystych prac rozwojowych. Trudno oceniać takie zamiary w czystych kategoriach informatycznych i biznesowych, bo silny wpływ na decyzje z tego zakresu ma również polityka. Chodzi o prestiż wynikający z dominacji, napędzanie własnego rynku pracy i usług, a czasem i brak zaufania do lokalnych rozwiązań i specjalistów.

Przypadki łączenia dużych banków w Polsce w większe jednostki, z wyjątkiem jednego może przypadku, wiązały się z jednoczesnym zastępowaniem informatycznych systemów oddziałowych przez systemy scentralizowane. Związany z tym proces miał cechy znacznej neutralności i dość skutecznie eliminował dylemat kto-kogo. Wspomniane systemy jednak zapewniają tylko pewien zakres obsługi informatycznej banku i wymagają współdziałania z innymi, o wąskiej specjalizacji. Rozwój stosowania takich właśnie systemów jest widoczny szczególnie w bankach, gdzie - w ramach jednego banku - działa wiele służb prowadzących działalność w sposób pozwalający dostrzec w nim nawet pewne cechy autonomii. Dobrym na to przykładem są domy maklerskie, będące odrębnymi firmami, czy jednostki kredytów hipotecznych, uprawiające wyłącznie własną, relatywnie wąską działkę.

Służby te mają własne budżety i to one decydują o wyborze rozwiązań informatycznych na swoje potrzeby. To zaś nie zawsze pozostaje w zgodzie z architekturą i koncepcją całości informatyki w danej grupie bankowej. Nader często stosowana jest tu (skądinąd zasadna) reguła "kto płaci, ten wymaga", co kończy się albo własnymi serwerami pod biurkiem (czasem własną miniaturą ośrodka informatycznego), albo wiecznymi sporami z centrum informatycznym, którego odpowiedzialności powierzono sprzęt oraz związane z nim oprogramowanie i dane, oczekując w zamian 100-proc.

niezawodności i niezakłóconego współdziałania z innymi systemami. Nie trzeba dodawać, że wszystkie uprawnienia zarządcze i administracyjne stara się zachować swoisty "właściciel" takiego systemu.

Model ten jest stosowany również w przypadku środowisk stosowanych do prac programowych. Ponieważ zaś coraz częstsze bywają przypadki wyłączania zespołów zajmujących się programowaniem z centralnych służb informatycznych poprzez dołączanie ich do jednostek biznesowych (kolejna, któraś już w historii informatyki, próba bratania się z tzw. bezpośrednimi użytkownikami) albo przez tworzenie z nich quasi-firm na ograniczonym własnym rozrachunku. Niezależnie od wybranego modelu - zaostrza to zazwyczaj stosunki z de nomine centralnym włodarzem infrastruktury informatycznej, któremu na różne sposoby próbuje się ograniczać uprawnienia konieczne do właściwego wywiązywania się z obowiązków.

Coś dla wszystkich

Rozsądnym wyjściem z takiej sytuacji wydaje się oparcie wzajemnych stosunków centralnego zarządcy środowisk, czy to z jednostkami biznesowymi, czy z zespołami rozwojowymi, na zasadzie umów o poziomie i zakresie świadczenia usług (SLA), regulujących również sprawę odpłatności za te usługi, chociażby w ramach rozliczeń wewnętrznych. Pójście jednak aż tak daleko bywa sprzeczne z interesami obu stron, bo zmusza do zmian w metodyce rachunku kosztów (co, samo w sobie, też jest źródłem dodatkowych kosztów), a także obnaża rzeczywistą ich wysokość. (Nie można jednak nie zauważyć, że ostatnio pojawia się coraz więcej głosów krytykujących rozwiązania oparte na SLA, jako mało elastyczne i nieprzystające do obecnych potrzeb i warunków.)

W Polsce i przedsiębiorstwa, i banki, czy - szerzej - instytucje finansowe, eksperymentują z różnymi rozwiązaniami z tego zakresu i trudno jest znaleźć jakiś zdecydowanie dominujący model. Zdarzają się przypadki silnej centralizacji, zarówno funkcjonalnej, jak i geograficznej, ale są również przykłady celowego rozpraszania własnych jednostek bądź powierzania pewnych, ściśle określonych zadań firmom zewnętrznym.

Charakterystyczne są pojedyncze przypadki lokalizacji własnych jednostek rozwojowych czy usługowych poza stolicą, ze względu na niższe koszty wynajmu infrastruktury i niższe wydatki na płace. Pewne funkcje biznesowe i informatyczne (np. obsługa transakcji dokonywanych kartami płatniczymi, masowe drukowanie, zarządzanie częścią lub całością sieci teleinformatycznych) powierza się firmom zewnętrznym lub własnym jednostkom o ograniczonej autonomii. Działania te także rozpraszają infrastrukturę informatyczną i związane z nią zasoby.

Optymistyczną konkluzją z niniejszych rozważań byłoby stwierdzenie, że w polskich warunkach, w dużych przedsiębiorstwach i bankach - sprawdzają się oba modele informatyki: scentralizowany i centralny z jednostkami rozproszonymi. Liczne zmiany właścicielskie, fuzje, polityka duża i mała oraz ciągłe, wewnętrzne zmiany organizacyjne powodują jednak, że ocena powyższa jest tylko doraźna, migawkowa bardziej, niż oparta na dłuższej obserwacji w miarę stabilnego otoczenia biznesowego, bo takiego po prostu nie ma.

Wprowadzając zaś nieco pesymizmu, sens powyższego stwierdzenia można odwrócić i powiedzieć, że żaden z wspomnianych modeli nie miał w Polsce warunków do sprawdzenia się, bo wzory do naśladowania coraz częściej staramy się czerpać stamtąd, gdzie systematycznie dzieli się to, co jeszcze całe i scala to, co dopiero co podzielone. A o tym, to jakbyśmy słyszeli już dawno, chociaż w nieco innym kontekście: "Ruch jest wszystkim..." (Eduard Bernstein, 1899).