Jak ZUS sfinansuje rozwój Kompleksowego Systemu Informatycznego

Koszty budowy od początku nowego Kompleksowego Systemu Informatycznego byłyby nadmierne, a realizacja przewlekła. Przenosimy obecny KSI na infrastrukturę x86. Dzięki oszczędnościom w zakresie licencji i infrastruktury chcemy uzyskać samofinansującą się inwestycję. Z zaoszczędzonych środków zamierzamy finansować dalszy rozwój systemu – mówi w rozmowie z "Computerworldem" Krzysztof Dyki, wiceprezes Zakładu Ubezpieczeń Społecznych ds. IT.

Computerworld: Kompleksowy System Informatyczny ZUS uchodzi za jeden z dziesięciu najbardziej złożonych systemów IT na świecie. Zakład korzysta z niego już od 21 lat, a stopień komplikacji systemu jest w ogromnej mierze efektem niekończących się i coraz częstszych zmian w przepisach emerytalno-rentowych. KSI działa sprawnie, ale jest poplątany, złożony i drogi w utrzymaniu. Powtarza pan, że ZUS potrzebuje KSI 2. Jaki to będzie system?

Krzysztof Dyki: Projekt KSI 2 polega na przepisaniu systemu z obecnej architektury fizycznej komputera centralnego na architekturę x86. Na tym etapie zachowujemy niezmienny zakres funkcjonalny systemu – ze wszystkimi zaletami i słabościami. Analizowaliśmy różne koncepcje, ale także przyczyny niepowodzeń projektów informatycznych klasy przedsiębiorstwa – zarówno w sektorze publicznym, jak i prywatnym. Na podstawie wyciągniętych wniosków uznaliśmy, że nie powinniśmy w jednym czasie tworzyć zupełnie nowego systemu w nowej architekturze fizycznej.

Zobacz również:

Z powodu niektórych nieoptymalnych cech KSI pierwotnie doradzano nam, aby powstał zupełnie nowy projekt. System KSI powstawał w określonym czasie i naturalnie cechują go ograniczenia możliwości rozwoju oraz wykorzystania potencjału obecnie dostępnych rozwiązań sprzętowych. Należy pamiętać, że system ten był i jest rozwijany w otoczeniu legislacyjnym, czyli w bardzo krótkich przestrzeniach czasowych na realizację każdej modyfikacji systemu.

Trudno byłoby znaleźć wykonawcę zdolnego do napisania całkowicie nowego KSI dla nowej architektury. W ostatnich latach w sektorze państwowym niepowodzeniem kończyły się budowy znacznie mniejszych systemów informatycznych. Dlatego z szacunkiem podchodzimy do obecnego systemu i staramy się wykorzystać jego potencjał, stopniowo i odpowiedzialnie go transformując. W każdym roku dokonujemy wielu modyfikacji KSI wynikających z obowiązków legislacyjnych.

Tak więc nawet przy założeniu budowy nowego systemu przez kilka lat należałoby uwzględnić, że w tym czasie kilkadziesiąt procent założeń projektowych znacznie by się zmieniło. W tym samym czasie, w którym modyfikowano by projekt oraz wytwarzano zaktualizowane moduły, dochodziłyby kolejne zmiany wynikające z potrzeb legislacyjnych.

Pan chce skrócić ten okres i dlatego mówi o przeniesieniu całego systemu, ze wszystkimi jego cechami, ze starej platformy, czyli z mainframe, na platformę x86.

Tak, mamy doświadczenie w optymalizacji wydatków i chcemy utworzyć finansowe perpetuum mobile. W wybranych obszarach aktualnej architektury komputera centralnego znacznie obniżyliśmy już koszty licencyjne oraz usługowe. Przykładowo zmieniliśmy model licencyjny opłacany ryczałtowo na model oparty na rozliczeniu rzeczywiście wykorzystywanej mocy obliczeniowej serwera oraz renegocjowaliśmy warunki i koszty usług. Architektura x86 cechuje się optymalnymi modelami licencyjnymi i kosztami utrzymania zarówno w zakresie oprogramowania, jak i sprzętu.

ZUS przeniesie KSI na serwery x86 i od razu będzie taniej, ale system w dalszym ciągu pozostanie zawiły. Przeniesiecie architekturę spaghetti do nowego kotła i co dalej?

Tak, w pierwszym kroku przenosimy system ze wszystkimi jego cechami. Nie tworzymy od początku nowego KSI, ponieważ uznajemy jego otoczenie funkcjonalne za środowisko wysokiego ryzyka wynikającego z procesów legislacyjnych. Nie dostrzegamy wykonawcy zdolnego do budowy tak zaawansowanego systemu w racjonalnym i przewidywalnym czasie oraz przy rozsądnych kosztach. Z uwagi na aktualną skalę i zawiłą logikę systemu KSI koszty budowy nowego systemu byłyby nadmierne, przy jednocześnie dużym ryzyku niepowodzenia oraz trudnym do określenia czasie realizacji.

Nie prosimy nikogo o dodatkowe środki, nie zwiększamy budżetu na informatyzację ZUS – inwestycję finansujemy z bieżących oszczędności, które pokryją nie tylko koszty jej realizacji, ale także możliwość sfinansowania dalszego rozwoju KSI 2.

Czyli za pieniądze zaoszczędzone na sprzęcie, licencjach i usługach można od nowa budować aplikację?

O takim efekcie rozmawiamy. Z samych oszczędności na nowej architekturze fizycznej można sfinansować rozwój KSI 2. Jeżeli spojrzymy na obszary dokonanych już przez nas oszczędności, to dostrzeżemy projekty, w których jeden proces optymalizacyjny potrafi przynieść kilkadziesiąt milionów złotych stałych oszczędności rocznych. Środki tej wysokości pozwalają sfinansować coroczny koszt przepisywania dowolnego systemu informatycznego, bez względu na czas realizacji projektu.

Projekt KSI 2 jest ważny nie tylko z powodów oszczędności, ale też ze względu na konieczność separacji domeny świadczeniowej. KSI składa się z dwóch głównych domen: świadczeniowej i dochodowej. Domeny te są wzajemnie zależne. Dążymy do ich logicznej separacji, dzięki czemu uzyskamy większą swobodę i efektywność projektową na poziomie realizowanych modyfikacji. Obecnie rozpoczęcie prac rozwojowych na jednej z tych domen istotnie ogranicza możliwość równoległych prac rozwojowych w drugiej domenie.

Obok zmniejszenia kosztów następuje poprawa logiki…

Tak, chcemy zredefiniować logikę systemu, zachowując jego spójność i niezbędną funkcjonalność. Po wydzieleniu domeny świadczeniowej nie ma wymogu migracji domeny dochodowej. Kwestia ta będzie podlegać ocenie członka zarządu sprawującego w tym czasie swoją funkcję. Możemy sobie wyobrazić, że priorytetem nie będzie wtedy migracja domeny dochodowej, ale przykładowo przepisanie już zmigrowanej domeny świadczeniowej do mikrousług.

Pamiętajmy, że obecna technologia komputera centralnego to synonim niezawodności i bezpieczeństwa, czyli cech pożądanych w obszarze funkcji społecznych realizowanych przez KSI. Dlatego po dokonaniu migracji domeny świadczeniowej zarząd będzie miał komfort i swobodę decyzyjną w zakresie dalszych kroków i priorytetów.

Mówi pan często o wysokich kosztach, ale też o partnerskiej współpracy z IBM i uznaniu dla technologii mainframe. Czyli w ZUS nie została ona skazana na wymarcie?

Oczywiście w tym przypadku partnerska współpraca nie opiera się na jednym wspólnym celu, którego trudno doszukać się pomiędzy instytucją publiczną a firmą prywatną. Nasza współpraca opiera się na zrozumieniu, formie komunikacji, poszanowaniu wzajemnych interesów oraz wspólnej pasji. Współdziałamy i rozwijamy się wspólnie z wiarygodnymi partnerami. W formule negocjacyjnej w grudniu zakupiliśmy serwery klasy IBM Mainframe z14 na optymalnych warunkach umownych oraz finansowych.

To dobra i niezbędna inwestycja, ponieważ projekt KSI 2 jest długoterminowym przedsięwzięciem, a dotychczas posiadane maszyny nie miały już oficjalnego wsparcia producenta.

Wróćmy do KSI 2, czyli migracji na x86. Zaproszenie zostało skierowane tylko do Comarchu i do Asseco. Co mają zrobić i w jakim czasie?

Zmierzamy do zawarcia umowy wykonawczej w ramach umowy rozwojowej KSI. Zakładamy, że migracja jest wykonalna w ciągu 18 miesięcy, ale spodziewamy się, że nasi partnerzy będą chcieli, aby trwało to dłużej. Zakładam, że od podpisania umowy do czasu wdrożenia produkcyjnego upłynie około półtora roku. Obecnie czekamy na oferty.

To oznacza, że migracja na x86 stanie się faktem pod koniec 2020 r. A pracownicy ZUS przez kolejne miesiące będą się uczyć nowego systemu…

W pierwszym kroku, poza większą wydajnością aplikacji, nasi pracownicy nie odczują zmian. Będą pracować na tych samych komputerach, z tymi samymi aplikacjami. KSI 2 to w pierwszym kroku projekt infrastrukturalny, więc będzie on transparentny dla pracowników. Świadomie wybraliśmy taką formę migracji, aby zminimalizować konieczność szkoleń naszych ludzi. Równolegle pracujemy nad integracją aplikacji interakcyjnych i mamy już korzyści dla naszej kadry, które w tym obszarze chcemy rozwijać. Jednym z ciekawszych ubiegłorocznych projektów zorientowanych na zwiększenie komfortu pracy naszych ludzi był projekt pojedynczego logowania KSI. Dzięki niemu udało się zmniejszyć liczbę zbędnych operacji wykonywanych przez naszych pracowników o ok. 30%.

Czyli jedyna zasadnicza różnica będzie dotyczyć komunikacji. Aplikacja przestanie łączyć się z komputerem mainframe, a zacznie z serwerami x86, tak?

Tak, na początku interfejsy pozostaną niezmienne. Aplikacje, które obecnie współpracują z komputerem centralnym, zostaną przepisane w zakresie komunikacji. Na tym etapie minimalizujemy zmiany użytkowe. Ich dopuszczenie spowodowałoby dezorganizację, która mogłaby negatywnie wpłynąć na sam proces migracji domeny świadczeniowej. Chcemy, aby migracja przebiegła bez negatywnych skutków dla pracowników. Dopiero wtedy zaczniemy kolejny etap, przepisując aplikacje lokalne do technologii webowych.

Co trzeba będzie zrobić w tym drugim etapie?

Oprócz potrzeby migracji do technologii webowych rozważamy inwestycje w zwiększenie wydajności, poprawę interfejsów użytkownika oraz implementację mikrousług. KSI 2 to większa swoboda inwestycyjna i technologiczna.

A co dalej z platformą dochodową?

To drugi etap projektu KSI 2 w obecnym wymiarze infrastrukturalnym, po zakończeniu obecnego projektu migracji domeny świadczeniowej. Pytanie, które stanie przed zarządem, będzie sprowadzało się do wyboru celu, czasu, charakteru, metod oraz skali inwestycji. Dzisiaj właściwa wydaje się kontynuacja migracji, czyli przeniesienie domeny dochodowej do architektury x86, ale decyzja należeć będzie do zarządu podejmującego decyzję w danych okolicznościach. Pamiętajmy, że KSI to największy system nie tylko pod względem swojej skali, ale także projektów rozwojowych wynikających z prac legislacyjnych rządu.

Jakie będą techniczne wymogi stawiane wykonawcy KSI 2 poza migracją na serwery x86?

Przede wszystkim KSI powinno pracować w architekturze x86, pod kontrolą otwartego systemu operacyjnego. Pozostałe parametry techniczne, w tym silnik nowej bazy danych, zależą od oferty wykonawców. Wymagamy oczywiście określonych parametrów dostępności, wydajności i kompatybilności. Na wykonawcy spoczywa obowiązek realizacji swojej koncepcji.

Formuła tego zamówienia jest niekonwencjonalna, ponieważ dopuściliśmy dużą swobodę koncepcyjną i technologiczną. Naszym celem było zachęcenie wykonawców do przedstawienia optymalnej według nich konfiguracji programowo-sprzętowej.

Nie wymagacie zbyt wiele…

To kwestia zaufania. Zakładamy, że obaj partnerzy to doświadczeni i profesjonalni uczestnicy obrotu gospodarczego, którzy na podstawie swoich wieloletnich doświadczeń zaproponują najlepsze rozwiązania. Zostaną one ocenione przez naszych specjalistów. Uważamy, że przy ściśle zdefiniowanym i wiarygodnym katalogu wykonawców można dopuścić pewną niezawisłość koncepcyjną i technologiczną. Oczywiście rezultaty tej twórczości muszą podlegać wszechstronnej ocenie. Natomiast zbyt szczegółowe zapisy projektowe mogą ograniczać zarówno zdolność do realizacji zamówienia, jak i efektywność końcową samego rozwiązania. Nasze działanie miało także na celu ograniczenie ryzyka straty czasu na potencjalne spory proceduralne dotyczące ewentualnych obwinień o preferencje poszczególnych technologii.


TOP 200