Po okresie inwestycji w systemy scentralizowane banki zajęły się porządkowaniem obsługi informatycznej gospodarki własnej. PKO BP postąpił odwrotnie, decydując się najpierw - ze względu na zbliżającą się prywatyzację - na wdrożenie systemu obsługi gospodarki własnej.

Podstawowym celem prowadzonego od ponad roku w PKO BP SA projektu wdrożenia scentralizowanego systemu obsługi gospodarki własnej jest zmniejszenie pracochłonności i czasochłonności zarządzania majątkiem banku. Bank chciał ograniczyć koszty osobowe, przetwarzania informacji i skrócić czas dostępu do nich. Nowe rozwiązanie miało też umożliwić prowadzenie sprawozdawczości, zoptymalizować zapasy utrzymywane w magazynach i udostępnić je wszystkim oddziałom poprzez tzw. wirtualny magazyn. Nie bez znaczenia była również konieczność precyzyjnego określenia i zinwentaryzowania całości majątku banku w związku ze zbliżającą się prywatyzacją.

Excel i papiery

Do tej pory operacje związane z zarządzaniem majątkiem banku od strony księgowej były rejestrowane syntetycznie w systemie Zorba 3000, obsługującym również klientów banku. Tylko w centrali banku księgowość w zakresie gospodarki własnej była prowadzona w systemie Oracle Financials. Natomiast od strony ewidencyjnej zdarzenia rejestrowano w clipperowym systemie SRT, który z czasem - w wyniku modyfikacji - przybrał odmienny kształt w różnych oddziałach i regionach banku. Oprócz niego istniało kilka odrębnych systemów ewidencji majątku trwałego. Ewidencja była również prowadzona przy użyciu arku- szy Excela, a w niektórych oddziałach wręcz wyłącznie w postaci papierowej.

Jednym z problemów, które stanęły przed zespołem wdrożeniowym, okazały się rozbieżności między danymi z systemów ewidencyjnych a danymi z systemów księgowych. Rozbieżności te nawarstwiały się z czasem, gdyż korekty często były dokonywane już w chwili sporządzania miesięcznego raportu syntetycznego, a zmian nie wprowadzano później do analitycznego systemu ewidencyjnego. Centrali trudno było uzyskać informację szczegółową na temat zdarzeń związanych z gospodarką własną oddziałów. Jedyną metodą było kierowanie zapytań do poszczególnych jednostek z prośbą o udzielenie szczegółowych danych. Trudno było w tej sytuacji o rozsądne zarządzanie majątkiem banku, kontrolę zużycia poszczególnych jego elementów czy też wspólną politykę zakupów.

"Tak naprawdę rozpoczynając projekt nie wiedzieliśmy jeszcze, co nas czeka. Mieliśmy pewną wizję przyszłości, ale nie sądziliśmy, że wprowadzenie nowej kultury pracy i zmiana jej organizacji będzie niosła tyle wyzwań" - mówi Włodzimierz Trzoch, dyrektor Departamentu Inwestycji i Logistyki PKO BP SA.

Kompletna anarchia

Największym wyzwaniem okazało się scalenie danych z wcześniej funkcjonujących systemów. Efektem rozdzielenia systemu ewidencyjnego i księgowego była niespójność informacji opisujących majątek banku w obu aspektach. Przed rozpoczęciem projektu nikt nie zdawał sobie sprawy, ile odrębnych środków trwałych znajduje się w ewidencji banku. Z czasem doliczono się ok. 450 tys. pozycji, z których każda była opisana przez kilkadziesiąt pól informacji szczegółowych (np. datę zakupu, nazwę użytkownika, okres amortyzacji i inne dane księ- gowe). Niezbędne było zebranie danych, ich standaryzacja oraz ujęcie w określonej strukturze i formacie narzuconych koncepcją projektu. Dane w postaci papierowej należało przetworzyć do formy elektronicznej. Okazało się, że wykorzystywano ok. 30 formatów daty, nie mówiąc o odmiennych sposobach zapisu szczegółów. Oprócz błędów formalnych natrafiono na wiele błędów merytorycznych, np. błędny symbol konta lub niewłaściwy okres amortyzacji. Tego rodzaju pomyłki zawierała niemal połowa rekordów.

Czyszczenie danych zamiast pla- nowanych trzech miesięcy zajęło prawie rok i wymagało stworzenia dedykowanych narzędzi w pewnym stopniu automatyzujących porządkowanie i ujednolicanie danych oraz pośredniej, scalonej bazy danych w Microsoft Access, stopniowo weryfikowanej i korygowanej przez poszczególne jednostki w dotyczącym ich zakresie. Tworzenie nie planowanych narzędzi i ręczne poprawienie danych nie poddających się automatycznej korekcie wpłynęło na przekroczenie początkowego budżetu i harmonogramu projektu.