Błędny dostawca, błędne rozwiązanie

Przypadek A dotyczy instytucji, która stosunkowo wcześnie zdała sobie sprawę, że jednym z koniecznych warunków sukcesu na rynku bankowym będzie posiadanie sprawnego systemu, umożliwiającego przetwarzanie dużych wolumenów operacji. Trudno określić, jak dokładnie wyglądał proces wyboru, jest jednak faktem, że proces ten sprowadził się do podpisania kontraktu ze znaną firmą - posiadającą bezsprzecznie doświadczenie w realizacji dużych przedsięwzięć informatycznych, lecz głównie związanych z dostawami sprzętu. Problem polegał na tym, że kontrakt dotyczył tylko przedsięwzięcia sprzętowego, aczkolwiek w jego ramach zakupiono także system obsługujący banki za granicą, tyle tylko że jednooddziałowe.

Niewiele czasu było potrzeba, aby dojść do wniosku, że system ten będzie nieprzydatny, bo uzyskanie jakiejkolwiek informacji o kliencie - bądź o jego produkcie - z dowolnego miejsca wymagałoby realizacji projektu o niezwykłym stopniu złożoności, aczkolwiek nie byłoby to przedsięwzięcie niemożliwe do wykonania.

Okazało się też, że wybrano system wyłącznie na podstawie wskazania oferenta, gdyż nie udało się znaleźć wymagań użytkownika, które trzeba było stworzyć na początku projektu. Dopiero na podstawie tych wymagań dokonano powtórnie wyboru systemu, tym razem już o architekturze scentralizowanej. Pozostał mały problem, jak za pomocą sprzętu zakupionego do pierwszego kontraktu w liczbie odpowiadającej planowanej wówczas sieci oddziałów obsłużyć system centralny, ale to już inna historia.

Można by przejść nad takim przypadkiem do porządku dziennego, były to wszakże lata raczkowania polskiej bankowości, gdyby nie fakt, że jeszcze bardziej zadziwiająca historia zdarzyła się kilka lat później innej szacownej instytucji finansowej.

Decyzja wbrew protestom

Bank B, mając znakomite rezultaty na rynku finansowym, postanowił wymienić posiadany system centralny na inny, zgodny ze standardem korporacyjnym, a przy okazji dokonać wyboru systemu dla obszaru, na którym do tej pory nie działał. Prace rozpoczęto zgodnie z wszelkimi regułami sztuki. Dla obszaru, który przewidziano do konwersji, rozpoczęto studium wykonalności, a dla nowego obszaru (tzw. greenfield) projekt rozpoczęto od wskazania przez renomowaną firmę konsultingową krótkiej listy producentów systemów obsługujących tę sferę.

Studium wykonalności było prowadzone pod bezpośrednim nadzorem międzynarodowej centrali przez niezwykle skromne siły lokalne i posuwało się naprzód w proporcjonalnym do tego tempie. Prace nabrały znacznego przyspieszenia w drugim obszarze - po przewinięciu się przez instytucję kilku koordynatorów tego projektu - wraz z momentem pojawienia się ostatniego z nich. Sformułował on tezę, że należy dołożyć do krótkiej listy systemów kolejny, piąty. Rozwiązanie to wygrało, mimo odmiennego zdania części członków zespołu ewaluacyjnego, którzy pisemnie sformułowali zastrzeżenia dotyczące wyboru tego systemu w tym konkretnym obszarze.

Ostatecznie system wdrożono po czterech latach, na największej dostępnej platformie sprzętowej, obsługując pięciokrotnie mniejszy wolumen od zaplanowanego. Koszty wdrożenia okazały się bardzo wysokie, a wszystkie wcześniej wyrażone zastrzeżenia co do możliwości obsługi planowanego wolumenu zasadne. Zgodnie z przypuszczeniami system pracuje jednowątkowo, co powoduje, że zastosowanie maszyny wieloprocesorowej do tej aplikacji nie ma sensu.

Przykłady te ilustrują, w jaki sposób można doprowadzić do bardzo kosztownych problemów już na początku procesu wyboru, łamiąc wydawałoby się elementarne zasady sztuki prowadzenia projektu. Powstaje zasadne pytanie, czy firmy mogą się uchronić przed takim scenariuszem? Wydaje się, że tak. Pytanie tylko, czy potrafią lub czy chcą? Zostawiam je czytelnikom pod rozwagę.