Öffentlichen Einrichtungen und Versorgern fehlt es selten an Systemen. Was ihnen fehlt, ist etwas anderes: ein zusammenhängender Weg, den die Daten zwischen ihnen zurücklegen. Ein staatliches Register antwortet über die eine API, das Finanz-ERP über eine völlig andere, SCADA-Steuerungen sprechen ein industrielles Protokoll, und das Dokumentenarchiv behält sein eigenes Format. Das Ergebnis sind manuelles Abtippen, Daten, die auseinanderdriften, und Prozesse, die an einer einzigen Tabelle hängenbleiben.
Aus unserer Erfahrung ist nicht eine einzelne Technologie das Problem, sondern das Zusammenführen von Welten, die nie für eine Zusammenarbeit entworfen wurden. Auch ohne hier auf eine namentliche Referenz zu verweisen, liefern wir die Menschen, die solche Systeme täglich verbinden: Integrationsingenieure, Architekten und Spezialisten, die kritische Infrastruktur verstehen. Wir bauen die Schicht, die Register, ERP, SCADA und Archive zu einem vorhersehbaren Datenfluss verbindet.
Warum sind Integrationen im öffentlichen Sektor und bei Versorgern so schwierig?
Weil eine Einrichtung meist aus Technologieschichten verschiedener Epochen besteht, die niemand abschalten kann. Ein vor fünfzehn Jahren gebautes System führt einen kritischen Prozess und funktioniert noch, also bleibt es, und neue Lösungen stapeln sich daneben. Mit der Zeit entsteht eine Architektur, in der jede Komponente ein Eigenleben führt.
Drei Dinge wirken dabei zusammen:
- Datensilos - jeder Fachbereich hat sein eigenes System und seine eigene Version der Wahrheit über denselben Bürger oder dieselbe Messstelle,
- Legacy - ältere Anwendungen ohne moderne API, oft undokumentiert und ohne Autor, den man noch fragen könnte,
- Sicherheit und Regulierung - personenbezogene Daten, kritische Infrastruktur und Regeln, die es verbieten, „einfach einen Endpunkt nach außen zu öffnen”.
Deshalb lässt sich eine institutionelle Integration nicht wie ein gewöhnliches Projekt behandeln, bei dem zwei Apps verdrahtet werden. Sie müssen Altes mit Neuem in Einklang bringen, ohne Dienste zu unterbrechen, auf die sich Menschen jeden einzelnen Tag verlassen.
Wie sieht die Anbindung staatlicher Register aus?
Staatliche Register sind eine eigene Gattung. Sie geben eigene Austauschstandards, Zugangsverfahren und Wartungsfenster vor, über die Sie keine Kontrolle haben. Deshalb geht es bei der Anbindung staatlicher Register weniger darum, einen API-Client zu schreiben, als darum, ihn so zu umhüllen, dass die übrigen Systeme nie spüren, dass auf der anderen Seite ein fremder, gelegentlich launischer Dienst sitzt.
In der Praxis bauen wir eine vermittelnde Schicht, die Registerformate in das Datenmodell der Einrichtung übersetzt, Antworten zwischenspeichert, Authentifizierung und Signaturen behandelt und jede Anfrage für das Audit protokolliert. Ist das Register nicht verfügbar, fällt das System nicht aus, es stellt die Anfragen in eine Warteschlange und wiederholt sie nach vereinbarten Regeln. Der Sachbearbeiter oder der Prozess innerhalb der Einrichtung bekommt eine stabile Schnittstelle statt einer rohen Verbindung zur Außenwelt.
Wie verbinden Sie ERP und Finanzsysteme mit dem Rest der Organisation?
Das ERP ist oft das Herz einer Einrichtung und dennoch selten offen. Wir binden es an Dokumentenworkflow, Fachverfahren und Register an, sodass Finanzdaten aufhören, von Hand zu reisen, und stattdessen über einen kontrollierten Kanal fließen.
Am häufigsten liefern wir das über:
- Integration über APIs und einen Bus (ESB, API-Gateway) statt brüchiger Punkt-zu-Punkt-Verbindungen,
- Synchronisation von Stammdaten (Geschäftspartner, Schlüsselverzeichnisse, Kontenplan) zwischen ERP und Fachverfahren,
- Automatisierung von Rechnungs- und Zahlungsabläufen unter Wahrung des Freigabewegs und des Audit-Trails,
- Berichte und gesetzliche Meldungen, die aus Daten mehrerer Systeme zugleich gespeist werden.
Konsistenz ist hier der Schlüssel: Trägt derselbe Geschäftspartner in drei Systemen drei verschiedene Kennungen, hält keine Automatisierung. Deshalb ordnen wir das Datenmodell, bevor wir irgendetwas verbinden.
Wie integrieren Sie SCADA und Zählerwesen, ohne die OT-Welt zu stören?
Bei einem Versorger verläuft die schwierigste Grenze zwischen IT und OT, zwischen der Welt der Geschäftsanwendungen und der Welt der Prozesssteuerung. SCADA, SPS und Zählersysteme leben in einem Industrienetz, in dem unterbrechungsfreier Betrieb und Sicherheit über der Bequemlichkeit einer Integration stehen.
Die SCADA-Integration verlangt Vorsicht, denn ein Fehler bedeutet hier nicht einen Fehler auf einem Bildschirm, sondern eine reale Wirkung auf die Infrastruktur. Deshalb sammeln wir OT-Daten über dedizierte Gateways und industrielle Protokolle (etwa OPC UA, Modbus, MQTT), puffern sie und stellen erst danach den bereinigten Strom Geschäftsanwendungen, Analytik oder Abrechnung bereit. Wir lassen den Verkehr in eine kontrollierte Richtung laufen und halten die Netze getrennt, sodass die Geschäftsseite Telemetrie lesen kann, ohne je die Möglichkeit zu erhalten, in die Steuerung einzugreifen. Diese Verantwortungstrennung ist ein Fundament, keine Option.
Wie binden Sie Dokumentenworkflow und Archive in einen Fluss ein?
Elektronische Schriftgutverwaltung, Repositorien und digitale Archive sind die Stellen, an denen ein Prozess am häufigsten stockt. Wir verbinden sie mit Registern und dem ERP, sodass ein Dokument entsteht, zirkuliert und ins Archiv gelangt, ohne manuellen Export und Import.
In diesem Bereich tun wir meist Folgendes:
- wir verknüpfen die Schriftgutverwaltung mit den Fachverfahren, sodass Fall und Dokument einen Fluss bilden und nicht zwei getrennte,
- wir automatisieren Metadaten und Klassifizierung auf Basis von Daten, die andere Systeme bereits halten,
- wir binden das Archiv an, im Einklang mit Aufbewahrungsfristen und Formaten der Langzeitarchivierung.
Ein gut verbundener Dokumentenfluss hört auf, ein Engpass zu sein, und wird zu einer natürlichen Etappe des Prozesses, in der einmal eingegebene Daten nie wieder getippt werden müssen.
Wie machen Sie Integrationen zuverlässig und sicher?
Eine institutionelle Integration muss weiterlaufen, auch wenn eines der Systeme kurz verstummt. Deshalb entwerfen wir sie fehlertolerant und nicht als Kette, die beim ersten gerissenen Glied bricht.
Wir stützen sie auf einige Säulen:
- Message Queues (etwa Kafka, RabbitMQ), die Systeme entkoppeln und Lastspitzen abfangen,
- Wiederholungen und Idempotenz, damit eine wiederholte Anfrage nie eine Operation dupliziert,
- Verschlüsselung bei der Übertragung und im Ruhezustand sowie Zugriffskontrolle nach den Anforderungen der Einrichtung,
- Monitoring und ein vollständiger Audit-Trail, der zeigt, wer wann welche Daten ausgetauscht hat.
Mit dieser Architektur wird ein kurz dunkles Register oder ein stark belastetes ERP zu einem Ereignis, das das System selbst behandelt, und nicht zu einem Vorfall, der im Morgengrauen eine Reparatur von Hand verlangt.
Welche Kompetenzen bringen wir in ein Integrationsprojekt ein?
Für solche Projekte formen wir das Team um die konkrete Architektur, nicht „auf Vorrat”. Am häufigsten besetzen wir die Rollen:
- eines Integrationsarchitekten, der den gesamten Fluss entwirft und die Standards setzt,
- von Backend- und Integrationsingenieuren (Java, .NET, Python), die Konnektoren, APIs und den Bus bauen,
- von DevOps- und Security-Spezialisten, die Queues, Infrastruktur und Härtung verantworten,
- von OT- und Industriespezialisten überall dort, wo SCADA und Zählerwesen ins Spiel kommen.
Wir haben echte Erfahrung aus Projekten für die öffentliche Verwaltung und in der Systemintegration sowie in kritischer Infrastruktur, wir verstehen also sowohl die regulatorische Strenge als auch die Realität der Arbeit mit der OT-Welt. Wir heften das nicht an eine einzelne Einführung, denn hier sprechen wir über die Kompetenz, die wir in das Team des Kunden einbringen.
Wie machen wir das bei RITS?
Wir arbeiten als Nearshore-Partner aus Polen, der dem Team einer Einrichtung oder eines Versorgers die fehlenden Kompetenzen hinzufügt. In Integrationsprojekten heißt das, dass wir:
- die Rollen von Architekt und Integrationsingenieuren besetzen, die den Umgang mit Legacy und regulatorischer Strenge gewohnt sind,
- die Kompetenzen vor dem Start prüfen und das Team auf die konkrete Architektur und die Protokolle ausrichten,
- in den bestehenden Rhythmus des Kunden einsteigen, in seine Code-Reviews und Sicherheitsprozeduren, ohne langen Anlauf,
- IT und OT verbinden unter Wahrung der Netztrennung und der Anforderungen kritischer Infrastruktur.
Am häufigsten tun wir das über Team-Verstärkung oder ein dediziertes Team, und dort, wo eine Einrichtung eine neue Integrationsschicht von Grund auf aufbaut, als Individualsoftware, erstellt von unserem Team.
Womit beginnen Sie bei der Integration von Systemen in einer Einrichtung?
Beginnen Sie mit dem schmerzhaftesten einzelnen Ablauf - zum Beispiel der Stelle, an der jemand täglich Daten zwischen einem Register und dem ERP abtippt. Diesen einen Pfad durchgängig zu beschreiben zeigt, welche Konnektoren, welche Sicherheitsschicht und welche Rollen Sie tatsächlich brauchen, bevor Sie die ganze Architektur angehen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Verbinden Sie staatliche Register, ERP, SCADA oder Archive in einer Einrichtung? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrer Systemlandschaft zusammen.