W instytucji publicznej i u dostawcy mediów rzadko brakuje systemów. Brakuje czegoś innego: jednej, spójnej drogi, którą dane przechodzą między nimi. Rejestr krajowy odpytuje się przez jedno API, ERP finansowy przez zupełnie inne, sterowniki SCADA mówią przemysłowym protokołem, a archiwum trzyma własny format. Efektem jest ręczne przepisywanie, rozjeżdżające się dane i procesy, które zatrzymują się na pojedynczym pliku Excela.
Z naszego doświadczenia problem nie leży w pojedynczej technologii, tylko w połączeniu światów, które nigdy nie były projektowane do współpracy. Nawet jeśli nie pokazujemy tu wdrożenia z nazwą klienta, dostarczamy ludzi, którzy łączą takie systemy na co dzień: inżynierów integracji, architektów i specjalistów od infrastruktury krytycznej. Spinamy rejestry, ERP, SCADA i archiwa w jeden, przewidywalny obieg danych.
Dlaczego integracje w administracji i utilities są tak trudne?
Bo instytucja to zwykle warstwy technologii z różnych epok, których nikt nie może wyłączyć. System sprzed piętnastu lat obsługuje krytyczny proces i działa, więc zostaje, a obok dokłada się kolejne rozwiązania. Składają się na to trzy rzeczy naraz:
- silosy danych - każdy dział ma swój system i swoją wersję prawdy o tym samym obywatelu czy punkcie poboru,
- legacy - starsze aplikacje bez nowoczesnego API, często bez dokumentacji i bez autora, którego można dopytać,
- bezpieczeństwo i regulacje - dane osobowe, infrastruktura krytyczna i wymogi, które nie pozwalają „po prostu wystawić endpointu na świat”.
Dlatego integracji w instytucji nie da się potraktować jak zwykłego projektu łączenia dwóch aplikacji. Trzeba pogodzić stare z nowym, nie przerywając usług, z których ludzie korzystają każdego dnia.
Jak wygląda integracja z rejestrami krajowymi?
Rejestry krajowe to osobny gatunek. Rządzą się własnymi standardami wymiany, procedurami dostępu i oknami serwisowymi, na które nie mamy wpływu. Integracja z rejestrami krajowymi polega więc nie tyle na napisaniu klienta API, co na opakowaniu go tak, by reszta systemów nie odczuła, że po drugiej stronie jest zewnętrzna, czasem kapryśna usługa.
W praktyce budujemy warstwę pośredniczącą, która tłumaczy formaty rejestru na model danych instytucji, buforuje odpowiedzi, obsługuje uwierzytelnianie i podpisy oraz zapisuje każde zapytanie do celów audytowych. Kiedy rejestr jest niedostępny, system nie wywraca się, tylko kolejkuje żądania i ponawia je według ustalonych reguł. Proces po stronie instytucji dostaje jeden, stabilny interfejs zamiast surowego połączenia z zewnętrznym światem.
Jak połączyć ERP i systemy finansowe z resztą organizacji?
ERP bywa sercem instytucji, ale rzadko bywa otwarty. Spinamy go z obiegiem dokumentów, systemami dziedzinowymi i rejestrami tak, żeby dane finansowe nie wędrowały ręcznie, lecz kontrolowanym kanałem.
Najczęściej realizujemy to przez:
- integracje przez API i magistralę (ESB, API gateway) zamiast punktowych, kruchych połączeń jeden-do-jednego,
- synchronizację danych referencyjnych (kontrahenci, słowniki, plan kont) między ERP a systemami dziedzinowymi,
- automatyzację obiegu faktur i płatności z zachowaniem ścieżki akceptacji i śladu audytowego,
- raportowanie i sprawozdawczość zasilane danymi z wielu systemów naraz.
Kluczem jest spójność: jeśli ten sam kontrahent ma trzy różne numery w trzech systemach, żadna automatyzacja nie zadziała. Dlatego zanim cokolwiek połączymy, porządkujemy model danych.
Jak zintegrować SCADA i systemy pomiarowe bez naruszania świata OT?
U dostawcy mediów najtrudniejsza granica przebiega między IT a OT, czyli między aplikacjami biznesowymi a sterowaniem procesem. SCADA, PLC i systemy pomiarowe żyją w sieci przemysłowej, gdzie priorytetem jest nieprzerwana praca i bezpieczeństwo, a nie wygoda integracji.
Integracja SCADA wymaga tu ostrożności, bo pomyłka nie oznacza błędu na ekranie, tylko realny wpływ na infrastrukturę. Dlatego dane z warstwy OT zbieramy przez wyznaczone bramy i protokoły przemysłowe (np. OPC UA, Modbus, MQTT), buforujemy je i dopiero oczyszczone udostępniamy aplikacjom biznesowym, analityce czy billingowi. Ruch prowadzimy w jedną, kontrolowaną stronę, z zachowaniem separacji sieci, tak aby świat biznesowy mógł czytać telemetrię bez możliwości ingerencji w sterowanie. Ten rozdział odpowiedzialności to fundament, nie opcja.
Jak wpiąć obieg dokumentów i archiwa w jeden przepływ?
Systemy EZD, repozytoria i archiwa cyfrowe to miejsca, w których proces najczęściej się zatrzymuje. Łączymy je z rejestrami i ERP tak, aby dokument powstawał, krążył i trafiał do archiwum bez ręcznego eksportu i importu. W tym obszarze zwykle:
- spinamy EZD z systemami dziedzinowymi, żeby sprawa i dokument były jednym obiegiem, a nie dwoma oddzielnymi,
- automatyzujemy nadawanie metadanych i klasyfikację na podstawie danych z innych systemów,
- podłączamy archiwum zgodnie z wymogami retencji i formatami długoterminowego przechowywania.
Tak połączony obieg przestaje być wąskim gardłem, a dane wprowadzone raz nie trafiają do systemu po raz drugi.
Jak zapewnić niezawodność i bezpieczeństwo integracji?
Integracja musi działać także wtedy, gdy jeden z systemów chwilowo nie odpowiada. Projektujemy ją więc jako odporną na awarie, a nie jako łańcuch, który rwie się przy pierwszym zerwanym ogniwie.
Opieramy to na kilku filarach:
- kolejki komunikatów (np. Kafka, RabbitMQ), które rozdzielają systemy i amortyzują skoki ruchu,
- mechanizmy retry i idempotencja, dzięki którym ponowienie żądania nie dubluje operacji,
- szyfrowanie w tranzycie i spoczynku oraz zarządzanie dostępem zgodne z wymogami instytucji,
- monitoring i pełny ślad audytowy, pokazujący, kto, kiedy i jakie dane wymienił.
Dzięki temu chwilowa niedostępność rejestru czy przeciążenie ERP staje się zdarzeniem, które system obsługuje sam, a nie incydentem wymagającym ręcznej interwencji o świcie.
Jakie kompetencje dostarczamy do projektu integracyjnego?
Do takich projektów dobieramy skład pod konkretną architekturę, nie „na zapas”. Najczęściej obsadzamy role:
- architekt integracji, który projektuje całość przepływu i wyznacza standardy,
- inżynierowie backendu i integracji (Java, .NET, Python) budujący konektory, API i magistralę,
- specjaliści DevOps i bezpieczeństwa, odpowiadający za kolejki, infrastrukturę i hardening,
- specjaliści OT/przemysłowi tam, gdzie w grę wchodzą SCADA i systemy pomiarowe.
Mamy realne doświadczenie w projektach dla administracji, w integracjach systemowych i w infrastrukturze krytycznej, więc rozumiemy i rygor regulacyjny, i realia pracy ze światem OT. Mówimy tu o kompetencji, którą wnosimy do zespołu klienta.
Jak robimy to w RITS?
Pracujemy jako partner nearshore z Polski, który dokłada brakujące kompetencje do zespołu instytucji lub dostawcy mediów. W projektach integracyjnych znaczy to, że:
- obsadzamy role architekta i inżynierów integracji przeszkolonych w pracy z legacy i rygorem regulacyjnym,
- weryfikujemy kompetencje przed startem, a skład dopasowujemy do konkretnej architektury i protokołów,
- wchodzimy w istniejący rytm pracy, przeglądy kodu i procedury bezpieczeństwa klienta, bez długiego rozruchu,
- łączymy świat IT i OT z poszanowaniem separacji sieci i wymogów infrastruktury krytycznej.
Najczęściej robimy to w modelu wzmocnienia zespołu lub zespołu dedykowanego, a tam, gdzie instytucja buduje nową warstwę integracyjną od podstaw, jako dedykowane oprogramowanie budowane przez nasz zespół.
Od czego zacząć integrację systemów w instytucji?
Zacznij od jednego, najbardziej bolesnego przepływu, na przykład od miejsca, w którym ktoś codziennie ręcznie przepisuje dane między rejestrem a ERP. Opisanie tej jednej ścieżki od końca do końca pokazuje, jakich konektorów, jakiej warstwy bezpieczeństwa i jakich ról naprawdę potrzebujesz. Różnice między modelami współpracy opisaliśmy w tekście o modelach współpracy IT.
Spinasz rejestry krajowe, ERP, SCADA lub archiwa w jednej instytucji? Porozmawiajmy, dobierzemy zespół i architekturę pod Twój krajobraz systemów.