Business Case dla integracji systemów informatycznych

Data: 2012-12-04
Autor: Sebastian Konkol

Wiele projektów, w których miałem przyjemność uczestniczyć, dotyczyło integracji systemów informatycznych. Obserwowałem wystarczająco często menedżerów IT, którzy męczyli się bardzo próbując opracować dokumentację inwestycyjną i uzasadnienie biznesawe (sic!) dla wprowadzenia do środowiska informatycznego firmy narzędzi integracyjnych. W wielu z tych przypadków, zaraz na początku projektu lub – co gorsza – już po wdrożeniu okazywało się, że business case „się nie składa”. Tylko dlaczego?

Odkąd stało się oczywiste, że niemalże każda firma posiada systemy informatyczne w liczbie większej, niż palce u jednej dłoni, a jakość prowadzenia biznesu zależy od współpracy tych systemów, wiele miejsca w teorii tworzenia złożonych systemów informacyjnych poświęcano integracji systemów. W kolejności chronologicznej pojawiały się kilkuliterowe skróty: EAI, SOA, BPM, Processes Orchestration i ESB (to name just a few). Wszystkie one wabiły obietnicą łatwiejszej, sprawniejszej i bardziej zarządzalnej działalności integracji. Dzięki Gartnerowi i naśladowcom skróty te awansowały często do pozycji Świętego Graala, a każdy szanujący się dyrektor IT musiał je „mieć”. Wystarczyło tylko zbudować odpowiednie uzasadnienie dokonania takiej inwestycji.

Większość takich uzasadnień – a widziałem ich całkiem sporo – lokowało się w kategoriach, które określam jako naiwne. Zakładały one bowiem, że po wdrożeniu integracji będzie się łatwiej tworzyło systemy, będą one sprawniej działały i będą podatniejsze na zmiany, a same zmiany będą dobrze izolowane (nie będą generowały konieczności zmian w innych elementach środowiska systemów informacyjnych). No i tu zaczynała się udręka menedżerów IT. Okazywało się bowiem, że – już po pewnym czasie, kiedy opadała euforia i „czynnik ludzi” dochodził do głosu – korzyści z integracji jakoś nie chcą się ujawniać, a jeśli nawet, to objawiały się skalą co najmniej rząd wielkości mniejszą, niż oczekiwane. Zwykle kłopot polegał na założeniu, że wdrożenie integracji to wdrożenie „kolejnego” systemu informatycznego, tylko że dla samych informatyków. Nie wiem z jakich powodów opowieści o znienawidzonych użytkownikach nie były przekładane na grunt „użytkowników-informatyków”. Prawda jest taka, że integracja (o czym pisali, choć drobniejszym drukiem, wszyscy znający się na tej materii) wymaga zmiany niemalże światopoglądowej w szeregach inżynierów IT. Mściło się to, że wdrażając integrację nie zadbano o zmianę sposobu myślenia z systemo-centrycznego na szersze. Odbijało się czkawką słabo przemyślane podejście do wdrożenia. Opór inżynierów przed Nowym Ważniejszym w połączeniu z ich „dobrymi praktykami” sprawiały, że wizja integracji była wypaczana niemiłosiernie i zamiast sprawy upraszczać, komplikowała. A od szkolnych błędów aż się roiło. A tzw. Biznes nie bardzo widział w tym rolę dla siebie.

Anglicy mawiają: “What You pay for is what You get”. Jeśli więc uzasadnienie wdrożenia integracji budowane jest w oparciu o argumenty wyłącznie techniczne, to – poza tym, że nie sposób nazwać tego uzasadnienia „biznesowym” – tylko kompletny naiwniak oczekiwałby korzyści, które rzeczywiście dawałyby się wyrazić w walucie. Czy oznacza to, że integracja systemów to ślepa uliczka ewolucji informatyki użytkowej? Zdecydowanie nie! Trzeba jej tylko nadać właściwy kierunek, bo postawiony cel determinuje podejmowane działania.

Znam kilka podstaw uzasadniania integracji systemów informatycznych, które sprawiają, że ekwiwalent finansowy takiego wdrożenia jest mierzalny, a o trzech z nich chciałbym tu napisać.

  1. Eksperymentowanie z modelem biznesowym. We współczesnym biznesie coraz trudniej (czyt. coraz kosztowniej) tworzy się produkty rynkowe. Coraz częściej okazuje się, że łatwiej (czyt. taniej) jest wytworzyć pewną gamę podobnych produktów, a następnie pozwolić klientom wybrać i dopracować te, które im się najbardziej spodobają – na tej podstawie skomercjalizować najlepszy z wariantów. Takie eksperymentowanie wymaga jednak możliwości szybkiego tworzenia nie koniecznie dopracowanych wariantów produktów. Tego typu możliwości daje koncepcja architektury o nazwie Sandbox. W dużym skrócie i uproszczeniu polega ona na tym, że podstawowe funkcje, z których budowane są produkty, możliwe są do powiązania w uproszczony sposób – uproszczony, ale znacznie szybszy. I to jest uzasadnienie dla integracji – umożliwienie tworzenia podstawowych „konstrukcji” produktów na bazie małego zbioru prostych elementów, trochę jak z klocków LEGO®. I nie jest ważne, że nie będzie to osiągało wyrafinowanej wydajności, bo celem jest eksperyment, a nie skala masowa – ważnym jest natomiast to, aby możliwie niskim kosztem zweryfikować potencjał rynkowy produktu.
  2. Kontrola dostawców rozwiązań informatycznych. Przytłaczająca większość organizacji IT w firmach jest uzależniona od dostawców zewnętrznych. Rzecz jasna, każdy menedżer IT pręży muskuły Mocy Zakupowej wspomagany przez „negocjatorów” z działów zakupów, ale to tylko pozory. Prawda jest taka, że rozwiązania informatyczne, na jakich opiera się biznes każdej firmy, są znane przez dostawców, a nie własne IT. W takich sytuacjach nie trudno sobie wyobrazić, kto – tak naprawdę – ma decydujący głos. Ujawnia się to zwykle z całą siłą, kiedy powoływany jest Ważny Projekt Biznesowy, wymagający zmian w kilku systemach. Niezwłocznie, na „kanwie” architektury systemów informatycznych firmy objawiają się strefy wpływów poszczególnych dostawców – oni bowiem zwykle dyktują, co i jak będzie zmienione w ich strefie wpływu, a organizacje IT muszą się zgodzić na takie rozwiązania, bo nie mają jak z tym dyskutować. I to jest uzasadnienie dla integracji – takie rozdzielenie strefy wpływu każdego z dostawców systemów informatycznych, aby negocjacyjna BATNA powodowała jak najmniejsze zamieszanie w środowisku, umożliwiając jednocześnie możliwie łagodne (choć zapewne nie super wyrafinowane) obejście problemu.
  3. Zdolność dostosowania się do zachodzących zmian. W modelach biznesowych współczesnych, dojrzale zarządzanych firm nie stosuje się już pojęcia „pewnika” – są jedynie hipotezy o większej lub mniejszej wiarygodności, a strefy nieoznaczoności narastają z każdym rokiem. Coraz częściej nie to, co się robi, ale jak się robi rzeczy najbardziej podstawowe staje się elementem wydłużającym karencję nietrwałych (obecnie już z definicji) przewag konkurencyjnych. Zdolność do konkurowania budowana jest bowiem na możliwości wykorzystania podstawowych kompetencji firm na coraz to nowe sposoby, rekonfigurując łańcuchy dostarczania kompetencji i oferując je w innych kanałach sprzedaży. Taka zwinność wymaga jednak rzetelnego zidentyfikowania, a następnie udostępnienia kompetencji podstawowych w sposób umożliwiający ich łatwe „wbudowanie” w nowy proces sprzedaży czy świadczenia usług komercyjnych. I to jest uzasadnienie dla integracji – właściwe „obudowanie” podstawowych zdolności firmy i udostępnianie ich (bezpiecznie, wiarygodnie, stabilnie) każdemu, kto przyczyni się do wzrostu wartości firmy – zarówno wewnętrznie, jak i partnerom zewnętrznym. Im trafniej określone zostaną te kompetencje oraz im większe będą możliwości ich wykorzystania (co chyba ma oznaczać większą „elastyczność”), tym łatwiej będzie skorzystać z nich w nowy sposób – przy minimalnym koszcie własnym zwiększyć przychód firmy.

Zanim więc rozpocznie się wdrożenie technologii, warto zadać sobie dwa podstawowe pytania: gdzie leży prawdziwa potrzeba wdrożenia (jakie problemy to wdrożenie ma rozwiązać lub jakie marzenia ma zrealizować) oraz jakie są rzeczywiste (finansowe i pozafinansowe) koszty i konsekwencje takiej zmiany. No i nie warto być naiwniakiem, który los własnej firmy złoży w ręce „analityków” Gartnera, bez względu na wielkość budżetu marketingowego, jakim takie organizacje dysponują. Brzmi znajomo? Działalność IT to także element biznesu, a uzasadnienia inwestycji w IT muszą być rzeczywiście biznesowe. Informatyka to potężne narzędzie, ale tylko narzędzie. Sposób jego stosowania – a więc i konsekwencji, korzyści, problemy, przyszłość – to już zupełnie inna sprawa. Jesteście gotowi do dorosłego myślenia o stosowaniu narzędzi informatycznych?

Pozostaw komentarz