Na początku był Prokom
Historia informatyzacji kluczowych instytucji w naszym kraju sięga początku lat 90. W 1991 roku firma Prokom podpisała kontrakt z Telekomunikacją Polską na wdrożenie systemu finansowo-księgowego. Dzięki temu zleceniu Prokom stał się gigantem. Cztery lata później pojawił się pomysł wykonania systemu dla ZUS-u. Przetarg ogłoszono w roku 1996 i ze względu na wysokie wymagania finansowe jedyną firmą spełniającą wszystkie rygory okazał się Prokom. Równie zaskakujące było utajnienie kontraktu z ZUS-em, za sprawą czego ani resort pracy, ani eksperci ministerstwa nie mogli dokonać oceny systemu. Od samego początku narodzinom Płatnika i systemu informatycznego ZUS-u towarzyszyły dziwne zbiegi nieporozumień.
Ustawa o systemie ubezpieczeń społecznych uchwalona została w październiku 1998 roku, tę o emeryturach i rentach przyjęto zaś dopiero dwa miesiące później. Pięć podstawowych rozporządzeń, kluczowych dla systemu, uchwalono również w grudniu 1998 roku. Termin uruchomienia systemu informatycznego wyznaczono początkowo na 1 stycznia 1999 roku. Tymczasem przygotowanie całego oprogramowania dla ZUS-u uzależnione było od ustaw i rozporządzeń Sejmu, który okazał się bardzo niestały w swoich postanowieniach. Jak podaje Beata Stelmach z Prokomu, szczegółowe przepisy zawarte były w 19 ustawach i 48 towarzyszących im aktach wykonawczych, a przepisy były nowelizowane 230 razy (!). W takich warunkach stworzenie systemu, który mógłby zacząć funkcjonować poprawnie w styczniu 1999 roku, było marzeniem ściętej głowy.
Ustawodawczy bałagan nie ułatwił pracy Prokomowi, jednak fakt, że do dziś system nie działa sprawie w 100%, jak twierdzi pracownik ZUS-u, rzuca cień na wykonawcę systemu. Z kolei Beata Stelmach zaprzecza takim stwierdzeniom, wyjaśniając, że błędy dotyczą jedynie nieprawidłowości w dokumentach rozliczeniowych nadsyłanych przez płatników.
Faktem jest, że szybko zmieniające się polskie ustawodawstwo to prawdziwe nieszczęście dla realizujących projekty informatyczne. Wykonawca nigdy nie zna dnia ani godziny kolejnej poprawki legislacyjnej. A co najgorsze, zleceniodawcom wydaje się, że zmiany do gotowego już systemu można wnieść w mgnieniu oka. Ponadto wprowadzane poprawki do ustaw są już po tym, jak system informatyczny zaczyna działać.
Do trzech razy sztuka?
Jedenaście lat temu Główny Urząd Celny powierzył pewnej firmie zagranicznej wykonanie projektu pilotażowego, jakim było stworzenie systemu informatycznego dla Urzędu Celnego Port Lotniczy w Warszawie. Okazało się jednak, że przedstawiony przez wykonawcę produkt zawierał błędy, braki oraz usterki w oprogramowaniu. W takiej sytuacji GUC obniżył swoje wymagania względem zagranicznej firmy, ale nie koszty. Tym samym za sprzęt komputerowy i software zapłacono 542,3 tys. dolarów, a za okablowanie budynków, opłaty celne, podatki i obsługę bankową – dodatkowe 338 tys. zł.
W 1994 roku system pilotażowy dalej nie działał, a prezes GUC-u podjął decyzję o realizacji Ogólnopolskiego Systemu Informatycznego dla Administracji Celnej (OSIAC). OSIAC miał zautomatyzować procedury celne oraz zintegrować wszystkie jednostki administracji celnej. Wynajęto wtedy kolejną firmę zagraniczną, która nawet do 1997 roku, czyli do zakończenia kontroli NIK-u, nie zrealizowała żadnego z pięciu etapów umowy. Mało tego, w 1995 roku wiceprezes GUC rozpoczął kolejne, już trzecie, nieudane przedsięwzięcie. Dotyczyło ono stworzenia systemu informatycznego dla Generalnego Inspektoratu Celnego. Tym razem system wykonywała polska firma, ale równie nieefektywnie jak jej zagraniczni poprzednicy. Ostatecznie w związku z realizacją wszystkich umów GUC wydał 5,3 mln złotych i nie otrzymał poprawnie funkcjonującego systemu.
| Każdy sobie |
| Jerzy Kalinowski, prezes firmy konsultingowej AMG.net. |
| Wymagania dla projektowanego systemu są często bardzo ogólne z punktu widzenia jego funkcjonalności, a szczegóły dotyczą przede wszystkim elementów technologicznych (wskazanie z góry rozwiązań technologicznych). Stąd powstaje wrażenie, że kupujący po prostu nie wie, jaki system chce zbudować, a tzw. RFP (request for proposal), czyli zamówienie, jest przygotowywane przez specjalistów technicznych nie zawsze rozumiejących warstwę biznesową, która de facto determinuje sukces projektu. Ponadto zbyt mało uwagi poświęca się fazie analizy i szczegółowemu zdefiniowaniu funkcjonalności projektowanego systemu oraz wynikających z nich wymagań. Jest to wspólny błąd zlecających i wykonawców. |
