NIK o SLPS: Nie osiągnięto celów całego przedsięwzięcia

W grudniu 2020 pisałem, w jaki sposób system informatyczny Ministerstwa Sprawiedliwości mógłby posłużyć do manipulacji losowanymi składami sędziowskimi. Pokazałem, że temat losowości w komputerze jest bardzo trudny a mechanizm do ręcznego sterowania wybranymi losowaniami dałoby się przygotować tak, by w razie odkrycia wyglądał jak błąd niekompetentnego programisty.

Miesiąc później opublikowano raport Najwyższej Izby Kontroli opisujący m.in. System Losowego Przydziału Spraw. Czytamy w nim: „na chwilę obecną w systemie SLPS brak jest mechanizmów zabezpieczających przed ewentualnymi, intencjonalnymi działaniami ograniczającymi „losowość” przydziału spraw referentom. […] W konsekwencji możliwe jest dowolne dopasowanie raportów skróconych z losowania (zawierających wyłącznie informację o wylosowanym referacie) do innej dowolnej sprawy z tej samej kategorii.”

Niniejszy artykuł niemal w całości składa się z cytatów z raportu NIK. Jeśli wśród czytelników znajdzie się ktoś pracujący z systemami informatycznymi sądów, uprzejmie proszę o napisanie w komentarzu opinii, czy obserwowane w ostatnich latach metody informatyzacji wymiaru sprawiedliwości idą w dobrym kierunku. Po lekturze raportu trudno o optymizm…

Wyniki kontroli NIK

Wszystkie cytaty w niniejszym tekście pochodzą z dokumentu „Informacja o wynikach kontroli – Realizacja projektów informatycznych mających na celu usprawnienie wymiaru sprawiedliwości” dostępnego na stronie www.nik.gov.pl/kontrole/P/19/038/

Nr ewidencyjny: 160/2020/P/19/038/KPB
Data publikacji: 2021-01-15 10:04
Dział tematyczny: sprawiedliwość

Wszystkie śródtytuły i wyróżnienia w cytatach pochodzą od redakcji Informatyka Zakładowego. Przy cytatach podano numery stron z opublikowanego dokumentu. Obecne w cytatach sformułowania typu „obecnie” odnoszą się do okresu przeprowadzania kontroli, czyli przedziału od 10.10.2019 do 3.04.2020.

Czy SLPS pozwala na manipulacje składami sędziowskimi?

[Strona 49]
Kontrola wykazała również, że na chwilę obecną w systemie SLPS brak jest mechanizmów zabezpieczających przed ewentualnymi, intencjonalnymi działaniami ograniczającymi „losowość” przydziału spraw referentom. W związku z brakiem integracji (możliwości bezpośredniego importu/eksportu danych do/z systemów repetoryjno-biurowych) istnieje możliwość manipulacji losowym przydziałem spraw, poprzez zamianę przydzielonych przez SLPS spraw między okładkami. Problem ten dotyczy tzw. „wspólnego wpływu”, w przypadku którego odwrócona zostaje kolejność nadania sygnatury (w systemie biurowym i w SLPS). W wydziałach sądu zajmujących się tym samym zakresem spraw (np. w sytuacji, gdy w sądzie funkcjonuje kilka wydziałów karnych, cywilnych, itp.) sygnatura jest przyznawana sprawie dopiero po wylosowaniu referenta w SLPS. Na potrzebę samego losowana w SLPS nadaje jej (tymczasową) sygnaturę z wirtualnego repertorium „L”. Nie istnieje jednak systemowe powiązanie między tymi sygnaturami. W konsekwencji możliwe jest dowolne dopasowanie raportów skróconych z losowania (zawierających wyłącznie informację o wylosowanym referacie) do innej dowolnej sprawy z tej samej kategorii. Mechanizmy zabezpieczające przed taką sytuacją pozostają obecnie wyłącznie na poziomie dobrych praktyk biurowości – pracownik sekretariatu może przed losowaniem ręcznie oznaczyć daną sprawę, tak by niemożliwa była jej późniejsza podmiana (instrukcja w tej sprawie została wysłana przez zespół merytoryczny zajmujący się SLPS w Ministerstwie do OWI Gdańsk, który tworzy pierwszą linię wsparcia dla użytkowników systemu losującego).

Czy system SLPS zapewnia rozliczalność działań użytkowników?

[Strona 47]
do dnia zakończenia kontroli nie został uruchomiony w systemie SLPS moduł raportowy, który oprócz potrzebnych statystyk miałby dostarczać informacje o tym, kto, kiedy i jakie dane wprowadził do programu. Udostępnienie użytkownikom takich informacji sprzyjałoby transparentności procesu i zapewniałoby rozliczalność operacji dokonywanych w systemie. Ograniczyłoby ryzyko potencjalnych manipulacji parametrami, decydującymi o ujęciu sędziego w puli losującej, a także ułatwiłoby weryfikowanie popełnianych przez użytkowników błędów. Funkcję taką w ograniczonym zakresie pełni historia wpisów w oknie „Jednorazowe obciążenie/odciążenie”, jednak według Kierownika Projektu występowała konieczność uruchomienia takiej funkcjonalności w odniesieniu do innych parametrów, w tym wskaźnika przydziału. Realizujący ją moduł raportowy został wdrożony we wrześniu 2019 r., ale zablokowano go, ponieważ generował błędy merytoryczne i był zbyt obciążający dla systemu. Według Dyrektora DIRS produkcyjne wdrożenie modułu raportowego w systemie SLPS planowane jest do końca III kwartału 2020 r.

[Przypis na stronie 47]
Przeprowadzone oględziny wykazały, że obecnie SLPS jest rozliczalny tylko na poziomie bazy danych systemu, w której zapisywane są wszystkie akcje użytkowników. Do bazy dostęp ma jedynie administrator centralny. W praktyce rolę tę pełni jedna osoba – główny specjalista w Wydziale Utrzymania Aplikacji DIRS. Odtworzenie z poziomu bazy danych historii zmian dokonywanych w parametrach SLPS nie jest zautomatyzowane – wymaga osoby ze specjalistyczną wiedzą informatyczną oraz czasu. Wydobywanie informacji odbywa się poprzez tworzenie odpowiednich procedur (zapytań) w języku SQL. Co więcej, już samo zgłoszenie prośby o weryfikację danych w bazie przez użytkownika końcowego wymaga od niego wiedzy odnośnie zasad funkcjonowania systemu (są one niezbędne do zadania odpowiedniego pytania).

Po co nam w ogóle ten SLPS?

[Strona 8]
Badanie czterech projektów, zaliczanych do grupy strategicznych przedsięwzięć Ministra Sprawiedliwości wykazało, że informatyzacja resortu sprawiedliwości nie przebiegała w sposób planowy i zorganizowany. Minister nie opracował strategii informatyzacji sądownictwa, a zbadane projekty nie zostały powiązane z obowiązującym w kontrolowanym okresie dokumentem, określającym strategiczne kierunki rozwoju wymiaru sprawiedliwości. W przypadku wszystkich skontrolowanych projektów założono, że wpłyną one na usprawnienie sądownictwa, ale ich faktyczne cele były formułowane w sposób ogólny i trudny do zwymiarowania.

Jak zbierano wymagania

[Strona 42]

Jak wskazał Dyrektor DKO, analitycy DIRS nie znali zasad funkcjonowania sądów i nie potrafili przedstawiać pytań w tym zakresie w sposób zrozumiały dla sędziów. Z kolei sędziowie nie potrafili pytać analityków DIRS o projektowane zasady funkcjonowania systemu w sposób zrozumiały dla analityków. W związku z powyższym występowały zaburzenia w komunikacji między pionem merytorycznym (użytkownikami), a wytwórcami oprogramowania;

Tutaj nie da się nie wstawić obrazka ze Złotej Kolekcji Klasyki:

Jak wyglądała realizacja projektu

[Strona 41]
Szczegółowe Założenia Projektu (SZP) zostały opracowane z 11-miesięcznym opóźnieniem (tj. faktycznie w końcowej fazie realizacji projektu), a Kierownik Projektu i Zespół Projektowy z 7-miesięcznym opóźnieniem (22 maja 2018 r.), w związku z czym brak było osoby koordynującej działania zespołu merytorycznego oraz analitycznego (przekładającego wymagania merytoryczne na zadania dla deweloperów). Jak wyjaśnił Dyrektor DKO (formalny Inicjator Projektu SLPS) Departament został zaskoczony tym, że DIRS nie dysponuje kandydatem na kierownika projektu i to DKO ma wyznaczyć taką osobę. Ponadto Departament nie dysponował odpowiednim pracownikiem, który miałby wszechstronną wiedzę o funkcjonowaniu sądów i jednocześnie rozumiał działanie systemów informatycznych oraz potrafił formułować wymagania dla informatyków. Pozyskanie osoby, która spełniałaby oba kryteria, okazało się niemożliwe. Osoba powołana, w październiku 2018 r., na stanowisko Kierownika Projektu rozpoczęła odpowiednie studia podyplomowe dopiero po objęciu tej funkcji. Projekt SLPS zyskał więc w pełni przygotowanego do pełnienia swojej funkcji kierownika dopiero w końcowej fazie realizacji. Należy również podkreślić, że formalna decyzja Ministra Sprawiedliwości w sprawie uruchomienia projektu SLPS została wydana dopiero w dniu 8 listopada 2018 r.92, tj. dziesięć miesięcy po produkcyjnym uruchomieniu systemu SLPS i rozpoczęciu losowania za pomocą tego narzędzia składów orzekających w sądach powszechnych (w związku z wejściem w życie zmienionego rusp)

Jak testowano poprawność działania SLPS

[Strony 43-44]
stosowana do listopada 2018 r. procedura testowa nie spełniała powszechnie przyjętych standardów w zakresie realizowania projektów IT. W szczególności brak było standaryzowanych scenariuszy testowych, przypadków testowych oraz raportów z testów poprzedzających produkcyjne wdrożenie kolejnej wersji systemu. Zrezygnowano również z przeprowadzenia tzw. testów User Experience (tj. testów kluczowych dla zrozumienia oczekiwań użytkownika końcowego oraz określenia, co warto poprawić w aplikacji). Brak rzetelnych testów przełożył się na dużą liczbę błędów występujących w systemie (co opisano szczegółowo poniżej);

[Strona 44]
w okresie 1 października 2018 r. – 20 listopada 2018 r. przydzielenie sprawy sędziemu zastępcy (poprzez opcję „osoba zastępująca”) skutkowało błędnym zaliczaniem takiej sprawy za kilkadziesiąt lub nawet ponad sto spraw. W konsekwencji taki sędzia był pomijany w losowaniach, aż inni sędziowie wylosowali równie dużą liczbę spraw

Jak testowano bezpieczeństwo SLPS

[Strona 44]
kompleksowe testy bezpieczeństwa systemu zostały przeprowadzone (w formie audytu) dopiero w końcowej fazie projektu. Ostateczna wersja raportu z testów została opracowana na początku lipca 2019 r., co oznacza, że SLPS został dopuszczony do działania produkcyjnego bez przeprowadzenia testów bezpieczeństwa i działał w ten sposób przez blisko 1,5 roku

Jak wyglądało wdrożenie i parametryzacja

[Strona 43]
przez okres ponad półtora roku od produkcyjnego uruchomienia SLPS, brak było kompleksowej instrukcji użytkownika systemu. Przed wdrożeniem SLPS opracowane zostały instrukcje użytkownika, dla roli pracownika sekretariatu oraz administratora lokalnego. Opisano w nich poszczególne funkcjonalności aplikacji, ale nie zawierały one pogłębionego wprowadzenia do zasad działania systemu. Instrukcje nie posiadały rozszerzonych informacji w miejscach, które mogły sprawić problem użytkownikom. Nie były też systematycznie aktualizowane ze względu na ciągły rozwój systemu. Informacje o nowych funkcjonalnościach lub problemach związanych z działaniem systemu były wyświetlane użytkownikom automatycznie po zalogowaniu się w SLPS, jednak nie zapisywały się one na trwałe, np. w historii komunikatów. Pełna wersja instrukcji użytkownika została wytworzona dopiero na koniec projektu i dołączona do wersji 1.7 SLPS (z 6 września 2019 r.)

[Strona 47]
według stanu na koniec kontroli nie była aktywna funkcjonalność systemu SLPS zapewniająca jego integrację (możliwość importowania i eksportowania danych) z systemami repertoryjno-biurowymi sądów. Z ustaleń kontroli wynika, że funkcjonalność import/eksport łącząca SLPS z systemami repertoryjno-biurowymi została wdrożona produkcyjnie 6 września 2019 r., natomiast pozostaje ona nieaktywna, ponieważ nie zostały zakończone prace dostosowawcze po stronie dostawców tych systemów.

[Strona 48]
Tymczasem, jak wykazała kontrola, system zbudowany został bez zabezpieczeń przed wprowadzaniem parametrów skutkujących nieprawidłowym realizowaniem przepisów rusp, tj. np. wpisaniem nieprawidłowo ustalonego w podziale czynności wskaźnika przydziału spraw, dodatkowego przydziału (dla nowego sędziego w danym wydziale), wyłączenia z losowania (wstrzymania wpływu w referacie danego sędziego), czy funkcji „jednorazowe obciążenie” (dedykowanej budowie nowego referatu)

Jak radzili sobie użytkownicy

[Strony 42-43]
System SLPS nie jest zarządzany centralnie i zapewnienie jego prawidłowego działania wymaga poprawnej obsługi ze strony użytkowników. Od działań osób obsługujących system w poszczególnych sądach zależy, czy zapewniony będzie równomierny przydział spraw sędziom, asesorom sądowym i referendarzom. Aby było to możliwe, użytkownik musi mieć gruntowną, praktyczną wiedzę dotyczącą zasad funkcjonowania SLPS oraz poprawnego parametryzowania poszczególnych funkcjonalności (stosownie do rusp oraz sytuacji w danym wydziale). Zdaniem NIK, popełniane przez użytkowników SLPS błędy (opisane m.in. na str. 44–45 informacji o wynikach kontroli) pokazują, że przeprowadzone w 2018 r. oraz na początku 2019 r. szkolenia były niewystarczające i nie przygotowały użytkowników należycie na problemy, z jakimi mieli do czynienia w trakcie korzystania z aplikacji

[Strona 45]
wśród błędów popełnianych przez użytkowników jednym z najpowszechniejszych było bezpodstawne używanie okna „jednorazowe obciążenie/odciążenie”. Powinno być ono wykorzystywane wyłącznie w sytuacjach, o których mowa w § 67 rusp, tj. w przypadku budowania referatu, zwiększenia lub zmniejszenia wskaźnika przydziału. Tymczasem było ono wykorzystywane także w innych przypadkach, powodując generowanie nieprawidłowych wartości w bazie danych;

Jakie działania naprawcze podjęto

[Strony 45-46]
Opisane powyżej błędy sprawiały, że SLPS nieprawidłowo liczył sędziom obciążenia, co przekładało się negatywnie na równomierność przydziału spraw. W grudniu 2018 r. Dyrektor DKO opracował koncepcję naprawy danych w bazie SLPS. Generalne przeliczenie wartości zgodne z tą koncepcją odbyło się 15 lutego 2019 r. Operacja ta okazała się skuteczna tylko częściowo i jednocześnie sama była przyczyną kolejnych nieprawidłowości w bazie danych. Dlatego w marcu 2019 r. wprowadzono do SLPS możliwość zerowania obciążeń, a w lipcu udostępniono użytkownikom arkusz Excel służący do ręcznego przeliczenia danych i rozpoczęcia przydziału od nowa. Pomimo wprowadzenia ww. rozwiązania, do końca kontroli w niektórych wydziałach utrzymywały się skutki wcześniejszego, nieprawidłowego funkcjonowania SLPS. Skala nieprawidłowych obciążeń nie została rozpoznana do czasu zakończenia kontroli. Według wyjaśnień Kierownika Projektu planowane jest uruchomienie odpowiedniego mechanizmu raportującego, który z poziomu centralnej bazy wykrywałby nietypowe różnice w obciążeniach sędziów. Prace nad takim mechanizmem przedłużały się jednak ze względu na ograniczoną dostępność zasobów i kompetencji w Wydziale III DKO oraz brak zawartej umowy na utrzymanie i rozwój systemu.

W ramach podsumowania

[Strona 8]
Negatywnie NIK oceniła również nieosiągnięcie (według stanu na dzień 20 sierpnia 2020 r.) zakładanych, kluczowych celów projektu SLPS oraz brak uruchomienia funkcjonalności gwarantujących m.in.: pełną transparentność procesu losowania i rozliczalność operacji dokonywanych w systemie. Funkcjonalności te są niezbędne do zabezpieczenia SLPS przed intencjonalnymi działaniami oraz błędami użytkowników, które mogą ograniczać losowość i równomierność przydziału spraw

[Strona 9]
Zastrzeżenia NIK dotyczyły również braku właściwego przygotowania poszczególnych przedsięwzięć. Na przykład w przypadku SLPS, przez okres dwóch lat od rozpoczęcia realizacji projektu nie określono jego szczegółowych założeń, ani wymagań merytorycznych tworzonej aplikacji. Stosowna dokumentacja, a także struktury organizacyjne odpowiadające za jej wdrażanie zostały przygotowane dopiero pod koniec realizacji projektu, w związku z czym, w dniu uruchomienia systemu (1 stycznia 2018 r.) użytkownicy otrzymali wadliwie działające oraz pozbawione kluczowych funkcjonalności narzędzie informatyczne. Wpłynęło to negatywnie na równomierność przydziału spraw referentom oraz spowodowało wyłączenie mechanizmów zabezpieczających przed ewentualnymi, intencjonalnymi działaniami ograniczającymi losowość przydziału. Nierzetelne przygotowanie przedsięwzięcia wywierało negatywne skutki przez cały okres realizacji projektu SLPS. Funkcjonalności gwarantujące m.in. pełną transparentność procesu losowania rozliczalność operacji dokonywanych w systemie nie zostały w pełni wdrożone do dnia zakończenia kontroli NIK

[Strona 10]
Największa liczba stwierdzonych nieprawidłowości dotyczyła SLPS – jedynego projektu z badanej próby, którego wdrażanie było prowadzone samodzielnie przez komórki organizacyjne Ministerstwa Sprawiedliwości. NIK oceniła sposób realizacji tego przedsięwzięcia negatywnie wskazując m.in. na: nieopracowanie planu projektu oraz dokumentacji technicznej potrzebnej do utrzymania systemu; nieprawidłowe zdefiniowanie potrzeb szkoleniowych użytkowników; rozpoczęcie z opóźnieniem praktycznych szkoleń warsztatowych; brak rzetelnych testów odbiorczych kolejnych wersji systemu; blisko półtoraroczne opóźnienie w przeprowadzeniu testów bezpieczeństwa SLPS oraz w zakresie opracowania procedury obsługi zgłoszeń użytkowników. W rezultacie, poszczególne produkty nie zostały zrealizowane w pełnym zakresie oraz w założonych terminach. Nie osiągnięto także celów całego przedsięwzięcia.

Od redakcji

W sytuacji, gdy System Losowego Przydziału Spraw jest tak odległy od poprawnej realizacji swych podstawowych funkcji, transparentność losowania sędziów wydaje się odległym marzeniem. Warunek transparentności podany w poprzednim tekście zachowuje jednak aktualność – najpierw publikowana ma być lista losowań, potem tworzone ma być ziarno generatora liczb losowych. Taka metoda – połączona z publikacją wskaźników przydziału – pozwoli opinii publicznej nie tylko na weryfikację losowości przydziału, lecz także obserwację długoterminowych trendów i dostrzeżenie nieprawidłowości innego typu.

Dodatek specjalny – NIK o platformie ePUAP

Kilka dni temu NIK opublikował informację o wynikach kontroli „Realizacja usług publicznych dla obywateli z wykorzystaniem platformy ePUAP” – skrót prasowy udostępniono tutaj. Zainteresowało mnie to w kontekście nawracających problemów z dostępnością Profilu Zaufanego, który nie wytrzymuje obciążenia rzędu kilkuset sesji logowania na sekundę.

Z lektury dowiadujemy się, że wskaźniki dostępności obliczane przez Centralny Ośrodek Informatyki na potrzeby Ministra Cyfryzacji (bo Ministerstwa już niestety nie mamy) nie zależą od rzeczywistego działania Profilu Zaufanego, ale od klasy incydentu. Jeśli nie możesz się zalogować do PZ ale nie zaistniał wąsko definiowany incydent krytyczny – w statystykach nadal wszystko gra. Dowiedzieliśmy się też o następującej magii w wykonaniu COI – choć 76% incydentów dotyczących PZ nie zostało nawet otwartych, zaraportowana do MC skuteczność obsługi zgłoszeń wyniosła 96,2% (marzec 2020).

NIK nie przedstawił rzeczywistych statystyk awarii oraz incydentów załamania usługi PZ z powodu zbyt dużej liczby sesji. Nie dowiedzieliśmy się niczego o obciążeniu systemu, o zakładanej i realizowanej liczbie równoległych sesji, podano za to nic nie mówiące statystyki zajętości przestrzeni dyskowej serwerów. Mam nadzieję, że raport nie jest na stronie 47 dostatecznie precyzyjny i że takie parametry jak obciążenie łącza są logowane częściej niż co pięć minut.