W sektorze publicznym ryzyko jest szczególnie wysokie. Po jednej stronie mamy procedury i regulaminy, budżet, odpowiedzialność za gospodarowanie środkami publicznymi i wymogi przejrzystości. Po drugiej – technologię, której realną wartość trudno ocenić bez specjalistycznej wiedzy. System może zostać odebrany, wdrożony i działać, a mimo to po czasie mogą pojawić się wątpliwości dotyczące sensu zakupu, sposobu przygotowania specyfikacji, wyboru danego dostawcy, udziału podwykonawców, bezpieczeństwa danych i faktycznego wykorzystania narzędzia.
Spis treści
- Projekt IT w sektorze publicznym – gdzie pojawia się największe ryzyko?
- Czy działający system IT oznacza udany projekt IT? Przykład Hermes
- Specyfikacja w projekcie IT – kiedy przesądza o wyborze dostawcy?
- Czy organizacja ma realną kontrolę nad systemem IT po zakupie?
- Odbiór systemu IT – czy podpisany protokół oznacza, że system działa?
- Cyberbezpieczeństwo w projekcie IT – czy organizacja kontroluje dane i dostęp?
- Co daje audyt śledczy projektu IT i kiedy ma największą wartość?
Projekt IT w sektorze publicznym – gdzie pojawia się największe ryzyko?
OECD, czyli Organizacja Współpracy Gospodarczej i Rozwoju – międzynarodowa organizacja skupiająca państwa wysoko rozwinięte i współpracująca z administracjami publicznymi w zakresie standardów gospodarczych, regulacyjnych i instytucjonalnych – zwraca uwagę, że w obszarze zamówień publicznych zakup systemów IT to jeden z bardziej wrażliwych obszarów działania państwa.
Wynika to z kilku powodów: znacznej wartości wydatkowanych środków, złożoności procedur, a także bliskich kontaktów między sektorem publicznym a prywatnym. Według OECD wątpliwości nie pojawiają się wyłącznie na etapie wyboru wykonawcy. Mogą powstać już przy planowaniu zakupu, opisie potrzeb, przygotowaniu specyfikacji, konsultacjach rynkowych, ocenie ofert, negocjowaniu umowy, odbiorze prac, a następnie przy utrzymaniu i rozliczaniu projektu.
Dlatego audyt śledczy projektów IT nie koncentruje się na samym systemie i poprawności jego działania. Audytorzy badają cały proces, który doprowadził do jego zakupu, wdrożenia oraz rozliczenia. Odtwarzają decyzje, dokumenty, relacje, płatności i momenty, w których ryzyko mogło zostać zignorowane.
Ważny fragment
W projektach finansowanych ze środków publicznych to właśnie ta różnica – między systemem kupionym i działającym, a systemem faktycznie potrzebnym i efektywnym – bywa najważniejsza. I stanowi realne ryzyko odpowiedzialności dla osób podejmujących decyzję o wyborze, sfinansowaniu i wdrożeniu określonego rozwiązania.
Czy działający system IT oznacza udany projekt IT? Przykład Hermes
Przykładem jest głośna medialnie sprawa zakupu przez Prokuraturę Krajową systemu Hermes.
Przypomnijmy, że według informacji Najwyższej Izby Kontroli Prokuratura Krajowa kupiła system Hermes za kwotę 15,56 mln zł w listopadzie 2020 r. System miał służyć do analizy danych z otwartych źródeł informacji (agregowania i przetwarzania danych dostępnych w Internecie) pozyskiwanych wobec podejrzanych. W okresie od 19 stycznia 2021 r. do 13 marca 2024 r. wykonano z jego użyciem 398 analiz kryminalnych. Kontrolerzy NIK negatywnie ocenili zarówno proces nabycia systemu, jak i zbadane aspekty jego wykorzystania. Wskazali oni między innymi, że zakup miał zostać dokonany bez analizy potrzeb prokuratorów, zakresu zastosowania i funkcjonalności, a także bez rzetelnego rozeznania rynku oraz analizy ekonomicznej.
Według NIK najdroższy z alternatywnych systemów dostępnych na rynku i posiadający te same funkcje był o 6,5 mln zł tańszy od Hermesa. Izba wskazała również, że Prokuratura Krajowa nie miała wiedzy między innymi o tym, czy zapytania wprowadzane do systemu były widoczne dla dostawcy systemu, jaka była pula logów i haseł, gdzie przechowywano dane i kto miał do nich dostęp.
W wyniku przeprowadzonej kontroli NIK skierowano dwa zawiadomienia do prokuratury. Pierwsze dotyczyło wyrządzenia szkody majątkowej w wielkich rozmiarach poprzez niegospodarny zakup systemu Hermes, a także niedopełnienia obowiązku przeprowadzenia stosownych analiz przed tym zakupem. Z kolei drugie zawiadomienie dotyczyło nieuprawnionego utajnienia dokumentu księgowego przed kontrolerami NIK w toku kontroli budżetowej zrealizowanej w 2023 r. Zakup systemu Hermes z pominięciem przepisów dotyczących zamówień publicznych stanowił – w ocenie kontrolerów – także naruszenie dyscypliny finansów publicznych. Jednak z uwagi na upływ terminu przedawnienia, wynoszący 3 lata, NIK odstąpiła od skierowania zawiadomienia do właściwego rzecznika dyscypliny finansów publicznych.
Ważny fragment
Przykład ten pokazuje, że zakup i wdrożenie systemu IT w instytucji publicznej bywa początkiem poważnych problemów. System może istnieć, ale nie być używany. Może działać, ale nie odpowiadać potrzebom. Może mieć licencję, ale nie dawać zamawiającemu realnej kontroli. System może zostać formalnie odebrany, mimo że dokumentacja jest niekompletna, testy pozorne, a dalsze utrzymanie uzależnia organizację od jednego dostawcy.
Ten sam mechanizm ryzyka występuje jednak również w firmach prywatnych: zmienia się źródło finansowania i poziom formalizacji procedur, ale problemy bywają bardzo podobne i nie mniej kosztowne.
Należy mieć przy tym na uwadze, że projekty IT są trudniejsze do kontroli niż wiele klasycznych zakupów, ponieważ ich rzeczywistą wartość widać dopiero po zestawieniu potrzeb użytkowników, wymagań technicznych, warunków licencyjnych, bezpieczeństwa danych i faktycznego sposobu wykorzystania systemu.
Właśnie dlatego audyt śledczy w projektach IT musi łączyć kompetencje w kilku dziedzinach jednocześnie: specyfice zamówień publicznych i analizie finansowej, badaniu poprawności dokumentacji i ocenie ścieżki decyzyjnej, niezależnej weryfikacji podwykonawców, a tam, gdzie to konieczne, także wsparciu technicznym.
Specyfikacja w projekcie IT – kiedy przesądza o wyborze dostawcy?
Jednym z najważniejszych dokumentów w projekcie IT jest specyfikacja. To w niej często rozstrzyga się, czy postępowanie będzie realnie konkurencyjne, czy tylko formalnie poprawnie przygotowane.
Jeżeli wymagania są nadmiarowe, niejasne albo dopasowane do konkretnego rozwiązania, wynik może zostać przesądzony jeszcze przed złożeniem ofert. Czasami wystarczy kilka pozornie technicznych parametrów, które w praktyce eliminują alternatywnych dostawców.
Audyt śledczy bada więc nie tylko treść specyfikacji, ale także jej genezę. Kto ją przygotował? Czy korzystano z doradców zewnętrznych? Czy doradca miał relacje z późniejszym wykonawcą? Czy wymagania wynikały z realnych potrzeb użytkowników? Czy zamawiający potrafił uzasadnić każdy istotny wymóg? Czy przeprowadzono analizę rynku?
google news
Bądź na bieżąco ze zmianami w prawie, podatkach i księgowości! Zaobserwuj nas w Wiadomościach Google
Czy organizacja ma realną kontrolę nad systemem IT po zakupie?
Podobnie wygląda kwestia licencji i praw do systemu. Organizacja może zapłacić znaczną kwotę, ale nie uzyskać realnej swobody korzystania z rozwiązania, jego modyfikacji, utrzymania lub przeniesienia do innego dostawcy. Może posiadać system, którego nie potrafi samodzielnie utrzymać. Może być związana warunkami licencyjnymi, których nikt nie przeanalizował przed odbiorem. Może nie mieć dokumentacji technicznej, administracyjnej albo dostępu do komponentów, które decydują o dalszym funkcjonowaniu rozwiązania. Problemem bywa również brak rzeczywistej integracji z systemami, z których organizacja już korzysta. Nowe narzędzie może formalnie działać, ale nie komunikować się poprawnie z systemem finansowym, kadrowym, zakupowym albo innymi kluczowymi aplikacjami. W efekcie organizacja nie tylko nie osiąga zakładanej efektywności, ale może wręcz dołożyć sobie pracy.
Audyt śledczy nie poprzestaje więc na pytaniu, czy istnieje umowa. Bada, czy organizacja rzeczywiście kontroluje to, za co zapłaciła.
Odbiór systemu IT – czy podpisany protokół oznacza, że system działa?
Protokół odbioru bywa w projektach IT traktowany jak ostateczne potwierdzenie wykonania umowy już w chwili, gdy system został formalnie dostarczony, choć nie zawsze oznacza to, że sprawdzono jego rzeczywiste działanie, przeprowadzono testy i zweryfikowano zgodność z wymaganiami. Tymczasem w projektach dotyczących wdrożenia systemów IT rzetelny odbiór powinien pokazywać coś więcej niż formalne dostarczenie systemu. Powinien potwierdzać, że wymagania zostały spełnione, testy przeprowadzone, błędy usunięte, dokumentacja przekazana, a użytkownicy przygotowani do pracy. Powinien też dawać odpowiedź na pytanie, czy zamawiający ma prawa, dostępy i wiedzę potrzebne do dalszego utrzymania rozwiązania oraz czy płatność rzeczywiście odpowiada etapowi prac, który miał zostać wykonany.
Dlatego ważne jest nie tylko to, że protokół został podpisany, ale również kto go podpisał i na jakiej podstawie. Podpis pod protokołem odbioru nie stanowi dowodu wykonania umowy – stanowi jedynie dowód, że ktoś uznał ją za wykonaną. Czy była to osoba, która mogła realnie ocenić system? Czy opierała się na wynikach testów, czy głównie na zapewnieniach wykonawcy? Czy w dokumentacji dotyczącej odbioru gotowego produktu opisano zastrzeżenia, błędy i sposób ich usunięcia? W takich sytuacjach dokument, który miał zamykać projekt, sam staje się jednym z najważniejszych dowodów w sprawi.
Cyberbezpieczeństwo w projekcie IT – czy organizacja kontroluje dane i dostęp?
Należy pamiętać, że projekty IT nie kończą się na zakupie licencji. System może przetwarzać dane osobowe, dane kontrahentów, informacje finansowe, dane operacyjne, tajemnice przedsiębiorstwa – a to wszystko są informacje wrażliwe dla sektora publicznego. Jeżeli organizacja nie wie, kto ma dostęp do systemu, gdzie przechowywane są dane, jak wykonywane są kopie zapasowe i jak wygląda odtworzenie działania po awarii, projekt IT staje się poważnym ryzykiem operacyjnym, prawnym i reputacyjnym.
Ustalenia NIK dotyczące cyberbezpieczeństwa samorządów wykazały, że w ponad 70% kontrolowanych urzędów brakowało przygotowania do zapewnienia ciągłości działania systemów informatycznych, a istotne nieprawidłowości wystąpiły w 23 z 24 badanych jednostek. Izba zidentyfikowała 222 nieprawidłowości, obejmujące między innymi braki w procedurach ciągłości działania, planach odtworzeniowych, zabezpieczeniu serwerowni, kopiach zapasowych, szkoleniach i zapisach umownych dotyczących poufności.
Cyberbezpieczeństwo nie jest zatem technicznym dodatkiem, który można odłożyć na później. Jeżeli organizacja kupuje system przetwarzający ważne dane, musi wiedzieć, kto ma do nich dostęp, gdzie są przechowywane i jak są chronione. W przeciwnym razie razem z nowym narzędziem wprowadza do organizacji ryzyko, nad którym nie ma pełnej kontroli.
Co daje audyt śledczy projektu IT i kiedy ma największą wartość?
Ważny fragment
Dobrze przeprowadzony audyt śledczy nie kończy się ogólną konkluzją, że „wystąpiły nieprawidłowości”. Jego wartość polega na tym, że porządkuje fakty i daje osobom decyzyjnym materiał, na podstawie którego można podjąć konkretne działania. Dla właściciela, zarządu czy rady nadzorczej nie wystarczy informacja, że projekt budzi wątpliwości. Najważniejsze jest, kto podejmował decyzje, na jakiej podstawie, gdzie zawiodły mechanizmy kontroli i czy sprawa może oznaczać szkodę, roszczenia, odpowiedzialność konkretnych osób albo konieczność naprawienia całego procesu.
To podejście jest szczególnie ważne tam, gdzie zaawansowana technologia łączy się z dużym wydatkiem – niezależnie od tego, czy chodzi o środki publiczne, budżet prywatnej firmy, czy pieniądze inwestora. W takich projektach ryzyko nie polega na tym, że system nie działa. Zasadnicze pytanie brzmi, czy można uczciwie wykazać, że powinien zostać kupiony właśnie w takim trybie, za taką cenę, od tego wykonawcy i na takich warunkach.
Audyt śledczy pozwala tę historię odtworzyć krok po kroku. Oddziela decyzje dobrze uzasadnione od tych, których nikt nie potrafi dziś wyjaśnić. Pokazuje, gdzie kończy się ryzyko techniczne, a zaczyna zarządcze. Sprawdza, czy formalny odbiór oznaczał realny efekt, czy tylko zamknięcie projektu. W projektach IT właśnie ta różnica bywa najdroższa.
Warto przy tym pamiętać, że audyt śledczy nie zawsze prowadzi do prostego wniosku, że doszło do nadużycia. Czasami jego najważniejszym efektem jest jasne pokazanie, że decyzje podejmowano w warunkach wskazujących na brak należytej staranności, rażące niedbalstwo albo po prostu brak wyobraźni i właściwego nadzoru.