Rozrzutne skąpstwo. Informatyzacji ZUS ciąg dalszy.

Michał "rysiek" Woźniak
2010-06-07

Jak informuje Gazeta Wyborcza (w tekstach z 5 i z 7 czerwca 2010) w ubiegłym tygodniu zapadła decyzja o dokończeniu informatyzacji Zakładu Ubezpieczeń Społecznych - bez przetargu. Wynika to z tego, że tylko jedna firma - Asseco - jest w stanie zapewnić ciągłość działania systemu. O ZUS-owskim "vendor lock-in" pisze Michał "rysiek" Woźniak.


Każdy, kto kupował cokolwiek o większej wartości (np. mieszkanie czy samochód), z prawdą zawartą w powiedzeniu "skąpy płaci dwa razy" jest raczej dobrze zaznajomiony, i prawdopodobnie przetestował ją na własnej skórze przynajmniej raz. Wiemy doskonale, że częstokroć lepiej jest zapłacić niewiele więcej, ale w zamian być pewnym, że to, co nabywamy, bezawaryjnie posłuży nam wiele lat – i spełni wszystkie nasze potrzeby. Z drugiej strony, wszyscy zdajemy sobie chyba sprawę, że nadmierna rozrzutność też jest niewskazana – warto przed zakupem dobrze zastanowić się, czego naprawdę nam potrzeba, i na tej podstawie podejmować decyzję. W przeciwnym wypadku może okazać się, że słono zapłaciliśmy za możliwości, z których nigdy nie skorzystamy.

Złoty środek – jak zawsze – jest trudny do osiągnięcia, lecz można starać się do niego zbliżać, choćby poprzez realną ocenę swych własnych potrzeb i swego budżetu. Oczywiście, można też pójść w drugą stronę - i połączyć skąpstwo z rozrzutnością w taki sposób, by stracić na obu. I chyba nikt nie będzie zaskoczony, że to właśnie wydaje się być sposobem działania polskich urzędów...

Wyobraźmy sobie urząd, który potrzebuje systemu informatycznego do zbierania i przetwarzania danych milionów Polaków. Dane te mają być następnie przechowywane i w pełni dostępne przez dziesięciolecia, sam system zaś ma być używany przez tysiące urzędników w całym kraju. Co więcej, od danych zawartych w systemie zależeć będzie nieraz być albo nie być poszczególnych obywateli.

Zgodnie z tym, co pojawiło się w pierwszym akapicie, podstawowym zadaniem przy projektowaniu takiego systemu powinno być precyzyjne określenie, czego tak naprawdę od niego oczekujemy, co jest absolutnie wymagane i konieczne; następnie można się zastanawiać, co by się mogło przydać. I dopiero na podstawie tak określonych warunków wstępnych można zacząć konstruować wymagania przetargowe. Pamiętajmy, że mamy do wydania miliony złotych...

W naszym hipotetycznym urzędzie z miejsca oczywista staje się krytyczna ważność tego, by dane były zawsze łatwo dostępne, niezależnie od bieżących układów sił politycznych czy biznesowych – nie można wszak pozwolić na to, by wykonawca naszego systemu informatycznego mógł po pewnym czasie dyktować warunki, mając nasze dane za zakładnika... To oznacza, że musimy upewnić się, że nawet gdyby firma, która wygra przetarg, z czasem upadła czy wycofała się ze współpracy, nie będzie problemu z dostępem do danych. Wbrew pozorom, nie jest to trudne do osiągnięcia – od dziesięcioleci w takich sytuacjach używa się standaryzowanych narzędzi informatycznych (jak relacyjne bazy danych czy usługi katalogowe), które – uzupełnione o pełną dokumentację konkretnego "ułożenia" danych w bazie – pozwala bez problemu uzyskać dostęp do samych danych niezależnie od użytych narzędzi, jeżeli tylko narzędzia te wspierają dany standard. Zatem przede wszystkim – standaryzacja i dokumentacja.

Okazuje się, że standaryzacja i dokumentacja umożliwiają nam też przy okazji rozwijanie i rozbudowę naszego systemu w przyszłości – jeżeli używamy standardowych narzędzi z jasno określonymi (i znanymi!) sposobami dostępu do danych, możemy te dane przetwarzać w dowolny niezbędny nam sposób, nawet, jeżeli początkowo w ogóle nie przewidywaliśmy takiego wykorzystania!

Co więcej, nietrudno znaleźć jeszcze jedną zaletę standaryzacji i dokumentacji – skoro opieramy się na standardowych, udokumentowanych rozwiązaniach, możemy użyć narzędzi już dostępnych, i modyfikując je – dostosować w 100% do naszych potrzeb. Nagle odpada nam mnóstwo pracy związanej z pisaniem systemu od podstaw – gotowych podstaw można użyć, i skupić się na wprowadzaniu już tylko tych zmian, które dla nas są istotne, co znacznie skraca czas i zmniejsza nakłady finansowe, niezbędne do stworzenia danego systemu.

To nie koniec zalet – jeżeli użyjemy standardowych rozwiązań, i w związku z tym możemy wykorzystać gotowe podstawy budowy naszego systemu, oznacza to, że użyjemy oprogramowania, którego ktoś już gdzieś używa – a zatem dużo lepiej przetestowanego w "warunkach bojowych" niż jakikolwiek system, który zdecydowalibyśmy się pisać sami.

I wreszcie, jeżeli używamy standardowych, znanych rozwiązań, możemy w każdej chwili zmienić wykonawcę dużo mniejszym kosztem i bez ryzykowania możliwości utraty dostępu do naszych własnych danych! Nikt nie trzyma nas w szachu, co z kolei oznacza, że mamy realny wpływ, realną kontrolę nad naszym wykonawcą (który musi liczyć się z tym, że jeżeli swoją robotę wykona źle, zostanie po prostu zwolniony).

Proste i zrozumiałe, prawda?

Można nawet pójść o krok dalej i zażądać od wykonawcy – w ramach dokumentacji – pełnego dostępu do kodu źródłowego tworzonego rozwiązania. To oznacza, że nie tylko dane byłyby na bieżąco dostępne, ale i cała implementacja systemu – co z kolei w oczywisty sposób jeszcze bardziej pozytywnie wpływa na nasze możliwości. Ewentualny nowy wykonawca, zatrudniony w miejsce pierwotnego, z którego nie byliśmy zadowoleni, mógłby do pracy przystąpić niemal niezwłocznie, z minimalnym czasem potrzebnym na nauczenie się naszego systemu i jego implementacji, mając do dyspozycji nie tylko dane i dokumentację, ale pełną realizację naszego systemu. Znów – mógłby już budować na czymś, co działa, zamiast zaczynać od zera, od podstaw. Zatem potrzebujemy jeszcze kodu źródłowego.

Ale i to nie jest jeszcze absolutnie wszystko, co możemy zrobić, by zagwarantować sobie maksimum możliwości, naszym danym maksimum bezpieczeństwa, a budżetowi minimum wydatków! Możemy mianowicie wymóc na naszym wykonawcy, by wszędzie, gdzie to tylko możliwe, używał oprogramowania z otwartym, dostępnym publicznie kodem źródłowym. W ten sposób nasze rozwiązanie będzie jeszcze łatwiejsze w utrzymaniu, choćby dlatego, że wielu innych potencjalnych wykonawców będzie już znało to oprogramowanie. To oznacza, że potrzeba ewentualnego „uczenia się” naszego systemu kurczy się do uczenia się jedynie zmian, które zostały wprowadzone do znanych mu rozwiązań zastosowanych w naszym systemie – czyli w zasadzie zupełnie znika, to zaś – znów! – w oczywisty sposób przekłada się na dodatkowe ułatwienie nam ewentualnej zmiany wykonawcy.

I możemy wreszcie pójść jeszcze krok dalej, udostępniając kod źródłowy naszego systemu, tak, by inne urzędy o podobnych potrzebach mogły go użyć i dostosować do swych potrzeb. To oznacza rozłożenie kosztów wdrożenia, utrzymania i modernizacji na kilka urzędów – co znów przekłada się na znaczne oszczędności czasu i pieniędzy. Czyli warto zastanowić się nad otwartością.

Oczywiście, wymuszenie na naszym wykonawcy pełnej dokumentacji, użycia standardowych rozwiązań i otwartego oprogramowania może wymagać od nas liczenia się z niewielkim wzrostem ceny rozwiązania, oraz wydłużeniem czasu jego początkowego wdrożenia. Zalety takiego rozwiązania – szczególnie biorąc pod uwagę krytyczną ważność danych i długi okres przewidywanego wykorzystywania systemu – są jednak nie do przecenienia, pozwalają bowiem ostatecznie zaoszczędzić znacznie więcej, niż początkowo wynosił ewentualny wzrost kosztów. Nie wspominając już o tym, że sytuacja, w której wykonawca może szantażować urząd odcięciem dostępu do danych jest po prostu nie do przyjęcia.

No dobrze, wiemy więc jak należy projektować wymagania systemu informatycznego dla naszego hipotetycznego urzędu. Co by się jednak mogło stać, gdybyśmy tych kilku prostych zasad (standaryzacja, dokumentacja, otwartość) nie wzięli pod uwagę?

Cóż, moglibyśmy na przykład przez 13 lat wydać 3 mld złotych na wdrożenie, utrzymanie i bieżące modyfikacje systemu informatycznego, by na koniec być zmuszonymi podpisać kolejną umowę z wykonawcą, z którego nie byliśmy zadowoleni, na warunkach dyktowanych przez tegoż wykonawcę pod groźbą braku dostępu do danych i braku możliwości bieżącej obsługi systemu przez rok lub dłużej... Moglibyśmy, krótko mówiąc, postąpić jak Zakład Ubezpieczeń Społecznych.

-----------------

Tekst opublikowany jest na licencji CreativeCommons ShareAlike 3.0 PL

Michał "rysiek" Woźniak – asystent Zarządu Fundacji Wolnego i Otwartego Oprogramowania, administrator sieci i systemów w Laboratorium Technik Mobilnych BRAMA na Politechnice Warszawskiej; student filozofii na Uniwersytecie Warszawskim, gorący orędownik Wolnego i Otwartego Oprogramowania, rowerzysta i żeglarz.

Reload Image