Wielkie systemy, wielkie problemy

Zdefiniowane wymagania użytkownika

Brak stabilnych i dobrze zdefiniowanych wymagań użytkownika jest jednym z podstawowych problemów projektów informatycznych. Szczególnie dotyczy to głównych systemów bankowych, gdzie należy zdefiniować bardzo precyzyjnie działanie dużej liczby produktów bankowych, zasad odpowiednich naliczeń, a także odpowiednią listę raportów operacyjnych i zarządczych. Zjawisko rozszerzania wymagań w stosunku do pierwotnie zdefiniowanych i dokładanie coraz to nowych produktów - niekoniecznie rentownych z punktu widzenia prowadzonego biznesu - prowadzi do nie kontrolowanego pogarszania wydajności systemu z biegiem realizowanego wdrożenia. Bardzo często na końcu tego procesu otrzymuje się pokraczną hybrydę, niezdolną do sprawnego wykonywania podstawowych funkcji.

Ponadto eskalacja żądań rozbudowy funkcjonalności prowadzi do znaczącego przekraczania założonych w projekcie kosztów, a winą za ten stan obarcza się kierowników IT. Największym problemem jest fakt, że niezwykle trudno zatrzymać ten proces, a każda taka próba jest interpretowana jako działanie uniemożliwiające funkcjonowanie biznesu. Zjawisko to ma znacznie większy zasięg, niż powszechnie się sądzi, i bardzo rzadko zdecydowane stanowisko najwyższego kierownictwa kładzie mu kres.

W przypadku wdrażania systemu o sprawdzonej na dojrzałym rynku funkcjonalności istnieje możliwość przyjęcia założenia, że bank wdrażający system powinien zaakceptować zdefiniowaną w systemie funkcjonalność jako wzorcową i do niej dostosować swoje produkty. Jednak - pomijając przykłady systemów wdrożonych na tzw. greenfield - nie znany jest mi tego typu projekt przeprowadzony z sukcesem w Polsce, aczkolwiek słyszałem o skutecznym zastosowaniu takiego podejścia za granicą, nieodległą, z wiarygodnego źródła.

Łączenie biznesu z technologią

Powszechne jest przekonanie, że projekt wdrożenia systemu centralnego w banku jest przedsięwzięciem mającym wyraźnie oznaczony początek i koniec. Nic bardziej błędnego! O ile za początek procesu można przyjąć określanie wymagań użytkownika i proces wyboru systemu, o tyle znacznie trudniej ustalić moment jego zakończenia. Nie jest nim bowiem moment zakończenia wdrożenia w ostatnim oddziale. System bowiem "żyje", wymaga wprowadzania nowej funkcjonalności, uaktualnień do nowych wersji i platformy sprzętowej, usuwania licznych - zwłaszcza w początkowej fazie - błędów, łączenia z innymi systemami, wreszcie optymalizacji całej tej struktury. Bardzo często, gdy proces ten zostanie opanowany, czas myśleć o wyborze następnego systemu.

Rzadko dostrzega się także fakt, że do sukcesu projektu konieczne jest umiejętne zestrojenie działań biznesowych i technologicznych. Zazwyczaj nadmierną wiarę pokłada się w technologii, sądząc, że tylko od niej zależy możliwość skutecznego działania na rynku. To przekonanie równie nieprawdziwe jak to, że posiadanie określonego uzbrojenia pozwala wygrać wojnę. Tak może być, ale pod warunkiem że broń ta będzie właściwie użyta przez dobrze wyszkolonego i dowodzonego żołnierza. Znane są - także na rynku polskim - prowadzone z dużym sukcesem działania banków, co prawda niszowych, obsługujących w zasadzie kilka prostych produktów wspieranych przez starannie wybraną, ale nie przesadnie rozbudowaną technologię.

Wielkie projekty informatyczne oznaczają oczywiście wielkie pieniądze. Walka o nie, decydująca nieraz o przeżyciu firmy, może budzić niezdrowe zachowania, czasem - choć chyba rzadziej, niż się sądzi - oznaczające korupcję. Przypadki takie niezwykle rzadko wychodzą na jaw, a przyczyną tego stanu jest trudność jednoznacznego powiązania nieudanego projektu i wymienionego zjawiska. Dwa takie przypadki dotyczą systemów wybieranych za granicą i znane są jedynie ekspertom, dlatego że kierownictwa tych banków zdecydowały się ujawnić fakt złożenia propozycji korupcyjnych. Oczywiście, w tych przypadkach do wyboru tych rozwiązań nie doszło. Najczęściej jednak przyczyną nieudanego projektu jest po prostu brak skrupulatnego przestrzegania podstawowych reguł podejmowania decyzji w obszarze wyboru systemu i jego późniejszej realizacji.


TOP 200