Wróżki, Wyrocznie i działalność IT

Data: 2009-01-31
Autor: Sebastian Konkol

Jakiś czas temu brałem udział w spotkaniu, którego celem było zdefiniowanie celu biznesowego pewnego projektu. Moja rola w tym projekcie polegała na proponowaniu rozsądnych rozwiązań problemów biznesowych wykorzystujących także technologię informatyczną. Zadanie przed jakim stanął zespół projektowy wymagało określenia głównych wyznaczników kontekstu biznesowego przedsięwzięcia, które uzasadniałyby konieczność wykorzystania dosyć zaawansowanych metod statystycznych (kart scoringowych) dla wspomagania podejmowania decyzji w ważnym procesie biznesowym (windykacja należności). Dyskusja „nie kleiła się”. Zapytałem więc głównego przedstawiciela wymagających: „Jaki jest pomysł na nowy proces windykacji należności?”, a mój partner w dyskusji odparł „System IT musi być elastyczny”. Cóż, nie byłem usatysfakcjonowany tą odpowiedzią, więc zapytałem w nieco inny sposób: „Jak powinien wyglądać proces biznesowy po wdrożeniu nowego narzędzia wspomagającego decyzje?” i otrzymałem odpowiedź: „System IT musi być elastyczny”. Tego typu dialog zajął jeszcze kilka iteracji formułowania inaczej pytania i otrzymywania tej samej odpowiedzi, niezbyt z pytaniem związanej. Po którejś z nich wyrwało mi się: „Elastyczna to jest gumka”, co – rzecz jasna – zakończyło to spotkanie natychmiast. Moją intencją było powiedzenie, że taki obiekt jak gumka jest być może wystarczająco prostym, aby opisać go jedną cechą – elastyczności – choć zapewne dobrze byłoby wiedzieć na przykład, jak dalece elastyczną ona jest. Napięta sytuacja w czasie spotkania i jednoznaczne skojarzenia obecnych sprawiły jednak, że próba wyjaśniania intencji nie miałaby najmniejszych szans powodzenia. Nie jestem dumny ze swojego zachowania, ale cóż – stało się. Uznałem to wydarzenie za „wypadek przy pracy” i przestałem o nim myśleć.

Później w czasie tego samego projektu wydarzyło się jednak coś innego, co wyzwoliło skojarzenia z elastycznością gumki. Projekt dotarł jakimś cudem do miejsca, w którym trzeba było określić przedmiot predykcji modelu statystycznego wykorzystywanego w karcie skoringowej. Pomijając formę i zawiłą treść komunikatu, przedstawiciele strony biznesowej postanowili wymagać od technologii informatycznej dostarczenia funkcji wróżki opartej o metody predykcji statystycznej. Nie mając danych do wnioskowania i nie znając przedmiotu wyliczeń jest raczej oczywistym, że ani Wróżka, ani inna Wyrocznia nie ma szans być zaimplementowana w systemie informatycznym – bez względu na zaawansowanie i koszty zastosowanej technologii informatycznej. To „małe” ograniczenie nie zniechęciło w żaden sposób przedstawicieli biznesu przed stawianiem wymagania.

Zajście trzeciego zdarzenia z tej serii w tym samym projekcie zmusiło mnie do spojrzenia na całość zagadnienia z nieco innej perspektywy. Tym razem przedstawiciele biznesu wymagali bardzo mocno rozbudowanej parametryzacji niemal każdego elementu systemu wspomagania decyzji – w przybliżeniu każda zmienna i każda reguła decyzyjna miała być „ustawialna” w locie przez przedstawicieli biznesu. Samo to wymaganie – w oderwaniu od poprzednich doświadczeń – nie wydaje się niemądre. Wszak procesy i reguły biznesowe stają się coraz bardziej złożone, a czas ich obowiązywania staje się coraz krótszy – takie czasy nam nastały. Skoro tak, to formuła transformacji tych procesów i reguł do postaci systemu informatycznego powinny mieć tak dużą siłę wyrazu, jak to tylko możliwe, o ile można jeszcze nad tym zapanować i zapewnić bezpieczeństwo biznesowi firmy w razie nieudanej modyfikacji. Jednak biorąc pod uwagę doświadczenia nabyte w czasie wcześniejszych zderzeń z przedstawicielami biznesu, ten przypadek wskazywał już na zupełnie inny schemat myślenia i postępowania, o którym za chwilkę.

Oprzyrządowanie do operacji na danych i ogólniej zdolności technologii informatycznych dostępnych dzisiaj są tak zaawansowane i rozbudowane funkcjonalnie, że w typowej rzeczywistości biznesowej znacznie przekraczają wymagania, jakie mogłyby zostać wyartykułowane. Mam tu na myśli fakt, że niemal każdy problem, jaki można w ogóle rozwiązać, daje się rozwiązać z pomocą metod technologii informatycznych. Niestety, wraz z postępowaniem tego wyścigu technologicznego systemy IT stały się tak złożone, że nie ma możliwości zrozumieć ich funkcjonowania bez głębszych studiów danego przypadku. W tym samym trybie brak zrozumienia złożoności technologii sprawił, że gdzieś utracono zrozumienie roli tych systemów i sposobu, w jaki wpływają one na powodzenie przebiegu procesów biznesowych organizacji. W takim środowisku za akceptowalne przyjmuje się wyjaśnienie „to coś się dzieje w tym systemie” – akceptowane jest wytłumaczenie braku kontroli nad różnymi działaniami biznesowymi przez – jak to jest głoszone – „zachowanie systemów IT”.

Przytoczone uprzednio przypadki zebrane w czasie trwania tylko jednego projektu reprezentują ogólniejsze klasy problemów, które muszą być otwarcie i uczciwie rozwikłane, jeśli współpraca między IT i biznesem ma być prowadzona w atmosferze partnerstwa.

Pierwszy problem można nazwać rozmyciem odpowiedzialności. Dość powszechnym jest zrzucanie odpowiedzialności za konkretne decyzje biznesowe na systemy informatyczne. Większość z nas zapewne słyszała: „Nie mogę tego zrobić – mój system nie pozwala mi na to!”, kiedy próbowaliśmy uzyskać trochę mniej typową usługę od nieco leniwego konsultanta telefonicznego centrum obsługi klienta. Problemy tej klasy mogą okazać się dużo trudniejsze, jeśli – dla przykładu – decyzje o strategii sprzedaży produktu będą uzasadniane na podstawie raportów z hurtowni danych bez wcześniejszego zastanowienia nad przydatnością tych danych w tym konkretnym przypadku. Przedstawiciele IT powinni być uczuleni na sytuacje mogące skutkować rozmyciem odpowiedzialności, wykrywać je i nie pozwalać im się materializować. W innym wypadku cała odpowiedzialność za konsekwencje podjętych decyzji o rozmytej odpowiedzialności spadnie na IT, bez względu rzeczywisty proces i miejsce podejmowania tej decyzji.

Inna klasa problemów dotyczy wiary w cuda i staje się tym mocniej widoczna, im bardziej złożona jest koncepcja wspomagania decyzji biznesowych zaimplementowana przez konkretny system informatyczny. Wsparcie podejmowania decyzji przy wykorzystaniu zaawansowanych metod modelowania statystycznego jest bardzo adekwatnym przykładem dla zilustrowania tej klasy problemów – dla wielu użytkowników tych narzędzi, samo modelowanie statystyczne jest zagadnieniem z pogranicza magii i fantastyki naukowej. Szybciej zaakceptowaliby Frodo Bagginsa pilotującego X-Winga. Co więcej, „radosna niewiedza” na ten temat pozwala wierzyć, że modele same wyciągają wnioski i wezmą na siebie odpowiedzialność za wyniki biznesowe. Mówiąc krótko, wykonalność wytworzenia modeli statystycznych jakie miałyby wspomagać procesy decyzyjne nie jest w ogóle kwestią do rozważania na jakimkolwiek etapie myślenia biznesowego. W szerszym znaczeniu, systemy informatyczne implementują pewne koncepcje naukowe i są one tak dobre, jak dobre są te koncepcje. Jeśli sama koncepcja nie umożliwia osiągnięcia pewnych celów, jej implementacja w systemie informatycznym nie przeskoczy tego ograniczenia. Przedstawiciele IT powinni wkładać wysiłek w wypełnianie tej luki w wiedzy swych partnerów wskazując założenia i ograniczenia koncepcji zamiast przyjmować je jako ograniczenia implementacji w systemach informatycznych. Czasami wymaga to żmudnej edukacji i pracy u podstaw, lecz bez tego wysiłku organizacja IT będzie postrzegane jako kula u nogi uniemożliwiająca wdrożenie „cudownych metod naukowych” do procesów biznesowych firmy.

Ostatnia klasa problemów, na jaką zwróciłem uwagę i jaką chciałbym tu opisać, dotyczy precyzji definiowania procesów biznesowych. Coraz częstszym przypadkiem jest maskowanie niemocy lub niechęci do określenia przebiegu jakiegoś procesu przez wymagania elastyczności i konfigurowalności implementacji tegoż procesu. Zdarza się, że z powodu braku podstawowych analiz biznesowych potrzebnych do określenia przebiegu procesu stawiane są wymagania konfigurowalności tego procesu w każdy wyobrażalny sposób w każdym punkcie przebiegu procesu. Co więcej, zakłada się, że tego typu wymagania zostaną zaadresowane przez system informatyczny poprzez uczynienie go – uwaga, moje „ulubione” – elastycznym! Przedstawiciele IT muszą być wrażliwi na oznaki prób maskowania niezdolności strony biznesowej do określenia reguł prowadzenia biznesu przez wymagania konfigurowalności rozwiązań informatycznych sprawiających, że systemu stają się tak bardzo złożone i tak nieprzewidywalne. W innym przypadku systemy informatyczne (a w konsekwencji organizacja IT) będą winne, jeśli – po konfrontacji z rzeczywistością biznesową – nikt nie zdoła zapanować nad tworem, który – „dzięki” tej przytłaczającej elastyczności – każdego dnia ma prawo działać zupełnie inaczej, niż działał dotychczas.

Konfuzja spowodowana złożonością systemów informatycznych jest często sztucznie podtrzymywana i wzmacniana. Byłem wielokrotnie świadkiem przekonywania przedstawicieli biznesu przez siły sprzedaży przedstawicieli różnych rozwiązań informatycznych, że ich rozwiązanie może działać bez wsparcia IT. W zasadzie równie dobrze mogliby obiecywać szóstkę w totka. Zwiedzeni w ten sposób przedstawiciele biznesu tracą zaufanie do przedstawicieli IT i gubią zdolność odróżniania przetwarzania danych i prowadzenia obliczeń od „Funkcjonalności Wyroczni” opartej o myślenie życzeniowe. Najbardziej mnie jednak uderza siła przekonania przedstawicieli biznesu, że jakiś system informatyczny zrobi to, czego oczekuje biznes i rozwiąże problem, który nie doczekał się jeszcze nawet naukawego rozwiązania, nie mówiąc już o algorytmicznej i obliczeniowej implementacji tego rozwiązania. Ale przedstawiciele biznesu są doskonale szczęśliwi i ten drobny szczegół nie pogarsza ich nastroju.

W technologii informatycznej nie istnieje nic takiego, jak Funkcjonalność Wróżki czy Opcja Wyroczni. Oczywiście, każdy kto ujawnia taką trudną prawdę staje się automatycznie wrogiem publicznym przedstawicieli biznesu. Niestety, jest to nieprzyjemne ale absolutnie niezbędne działanie i musi być realizowane przez przedstawicieli IT. Ponieważ IT jest zwykle rozliczane z adekwatności i optymalności doboru rozwiązań informatycznych, jest zobligowane do zapewnienia, że wykorzystywana technologia będzie dostarczać korzyści biznesowych, włączając w to zrozumienie ograniczeń wynikających z koncepcji implementowanych w tych systemach. To koncepcja, sposób rozwiązania problemu wprowadza istotne ograniczenia, nie sama technologia implementacji.

Najgorszą rzeczą, jaką może zrobić IT w sytuacjach podobnych do opisanych tutaj, to popaść w otwarty konflikt poprzez przeniesienie dyskusji na grunt reguł zarządzania systemami IT. Sposób, w jaki budowane są systemy IT nie jest już autonomiczną decyzją IT. W tym samym sensie, podejście do konstrukcji procesów biznesowych nie jest także wyłączną domeną kierownictwa biznesowego, jeśli liczą oni na wsparcie tych procesów narzędziami technologii informatycznej. Podstawową odpowiedzialnością architektów IT jest, szczególnie na poziomie odnoszącym się do architektury korporacyjnej, jest prezentowanie ograniczeń i konsekwencji tak samo jak korzyści i szans związanych z konkretną koncepcją i powiązanie jej z odpowiednimi procesami biznesowymi. Dobór optymalnej technologii nabiera wtedy drugorzędnej wagi. Wierzę, że takie zadanie znacznie lepiej wykonywać w trybie ewangelizacji, niż poprzez „prawo i rozporządzenia”.

Pozostaw komentarz