Modernizacja oprogramowania w sektorze publicznym uniemożliwia proste wyłączenie systemu na czas przebudowy. Obsługa procesów krytycznych i uwarunkowania prawne wymuszają rezygnację z rewolucyjnych zmian na rzecz kontrolowanej ewolucji, mapowania zależności oraz rygorystycznego zarządzania ryzykiem operacyjnym.
Dlaczego systemu publicznego nie modernizuje się jak greenfield?
Modernizacja systemu publicznego rzadko może odbywać się w trybie „zatrzymujemy, przebudowujemy, uruchamiamy ponownie”. W wielu przypadkach system musi działać dalej. Obsługuje użytkowników, procesy formalne, dane, integracje, terminy i zależności między instytucjami albo jednostkami organizacyjnymi. Przerwa w działaniu nie jest tylko problemem technicznym. Może oznaczać zatrzymanie obsługi spraw, brak dostępu do danych, opóźnienia w procedurach albo konieczność ręcznego obchodzenia procesu. Dlatego modernizacja systemu publicznego wymaga innego podejścia niż projekt greenfield. Nie chodzi tylko o to, co zbudować. Chodzi o to, jak zmieniać system, który nadal musi działać.
Jakie ryzyka tworzy niepełna wiedza i integracje?
Pierwsze ryzyko to niepełna wiedza o obecnym systemie. W starszych aplikacjach część reguł biznesowych często istnieje tylko w kodzie, konfiguracji albo pamięci osób, które pracowały przy systemie kilka lat wcześniej. Dokumentacja może być nieaktualna, a zależności między modułami słabo opisane. Jeżeli modernizacja zaczyna się bez zrozumienia tych zależności, łatwo naruszyć coś, co formalnie wygląda jak detal, ale w praktyce obsługuje ważny proces.
Drugie ryzyko to integracje. Systemy publiczne rzadko działają samotnie. Komunikują się z innymi aplikacjami, bazami danych, rejestrami, usługami zewnętrznymi, systemami raportowymi albo narzędziami używanymi przez inne jednostki. Każda zmiana może więc mieć wpływ poza samą aplikacją. Przed modernizacją trzeba wiedzieć, które integracje są krytyczne, jak często są używane, kto jest ich ownerem i co się stanie, jeśli przestaną działać poprawnie.
Jak zaplanować release i dane w systemie publicznym?
Trzecie ryzyko to release. W systemach publicznych wdrożenie nie powinno być improwizacją. Trzeba znać okno wdrożeniowe, procedury akceptacji, plan rollbacku, krytyczne ścieżki testowe, osoby odpowiedzialne za decyzje i sposób komunikacji w razie incydentu. Jeżeli release starszej aplikacji już teraz jest ryzykowny, modernizacja może to ryzyko zwiększyć, jeśli wcześniej nie zostanie uporządkowany proces wdrażania zmian.
Czwarte ryzyko to dane. Modernizacja może dotykać struktury danych, migracji, raportów, uprawnień, historii spraw i zgodności z wymaganiami formalnymi. Błąd w danych może być trudniejszy do naprawienia niż błąd w interfejsie. Dlatego trzeba wiedzieć, które dane są krytyczne, gdzie znajdują się źródła prawdy, jak wygląda backup, jak testować migrację i jak sprawdzić poprawność danych po zmianie.
Jak uwzględnić użytkowników i procedury?
Piąte ryzyko to użytkownicy i procedury. Nawet dobrze zaplanowana zmiana techniczna może spowodować problem, jeśli nie uwzględnia sposobu pracy użytkowników. System publiczny często jest częścią większej procedury. Zmiana ekranu, statusu, formularza albo kolejności kroków może wpłynąć na pracę ludzi, którzy korzystają z aplikacji codziennie. Modernizacja powinna więc obejmować nie tylko kod, ale też proces, dokumentację użytkową, komunikację zmiany i moment wdrożenia.
Dlaczego lepiej modernizować etapami?
Szóste ryzyko to próba zrobienia zbyt dużej zmiany naraz. Pełna przebudowa może wyglądać atrakcyjnie na prezentacji, ale w systemie, który musi działać bez przerwy, często bezpieczniejsza jest modernizacja etapowa. Mniejszy zakres łatwiej przetestować, wdrożyć, wycofać i ocenić po release’ie. Nie każda część systemu wymaga natychmiastowej zmiany. Czasem najlepszym pierwszym krokiem jest stabilizacja najbardziej ryzykownego obszaru, poprawa monitoringu, uporządkowanie release’u albo wydzielenie jednego modułu.
Jak Prognetics podchodzi do modernizacji systemów publicznych?
W naszej pracy kładziemy nacisk na to, aby każda zmiana w architekturze uwzględniała specyfikę instytucji, dla których ciągłość świadczonych usług jest absolutnym priorytetem. Zamiast rewolucyjnych przestojów, proces ten opieramy na kilku kluczowych filarach:
- dogłębnej analizie technicznej aktualnego stacku i architektury,
- precyzyjnym mapowaniu powiązanych zależności oraz zewnętrznych integracji,
- audycie procesów wdrożeniowych i procedur release,
- inwentaryzacji baz danych oraz kluczowych obszarów ryzyka operacyjnego.
Dopiero na tej solidnej podstawie wspólnie decydujemy, które elementy wymagają natychmiastowej przebudowy, które warto bezpiecznie zachować, a które należy objąć osobnym planem ewolucyjnym. Naszym celem nie jest modernizacja dla samej modernizacji, lecz dostarczenie stabilnego rozwiązania, które administracja może bezproblemowo rozwijać i utrzymywać pod pełną kontrolą – również poprzez świadome i bezpieczne wprowadzanie rozwiązań opartych na AI w administracji publicznej.
Od czego zacząć rozmowę o systemie publicznym?
Modernizacja systemów w sektorze publicznym nie wymaga rewolucyjnych przestojów, lecz precyzyjnie zaplanowanej ewolucji. Rozmowę techniczną o transformacji krytycznych aplikacji warto oprzeć na trzech danych wejściowych:
- wskazanie aktualnego stacku technologicznego,
- zdefiniowanie krytycznych zależności,
- nazwanie największego ryzyka operacyjnego.
Taki fundament pozwala zaplanować etapową przebudowę z zachowaniem ciągłości działania usług oraz pełną kontrolą ryzyka systemowego.
