Integration von inmation: Warum fließende Daten allein noch keinen Nutzen erzeugen
Die Anbindung läuft, das Datenmodell steht, die Schnittstellen sind dokumentiert. Aus Sicht des Projekts ist die Integration abgeschlossen. Aus Sicht der Produktion hat sie noch nicht angefangen. Warum diese Lücke systematisch entsteht – und warum sie kein Qualitätsproblem der Integration ist.
Es gibt einen Moment in Datenprojekten, den ich inzwischen erwarte. Die Abnahme ist durch, die Kennzahlen des Projekts sind erreicht: Alle vorgesehenen Quellen sind angebunden, das Modell ist konsistent, die Historisierung läuft, die Schnittstellen antworten in der zugesagten Zeit. Fachlich sauber, oft unter erheblichem Aufwand.
Und dann fragt jemand aus dem Betrieb: „Und wie komme ich jetzt an die Zahlen?"
Die Frage klingt harmlos, ist es aber nicht. Sie zeigt, dass zwei Beteiligte mit unterschiedlichen Definitionen von „fertig" gearbeitet haben – und beide zu Recht. Für die Integration ist fertig, wenn Daten verlässlich fließen. Für den Betrieb ist fertig, wenn jemand ohne Rückfrage eine Antwort bekommt. Zwischen diesen beiden Zuständen liegt Arbeit, die in keinem Integrationsangebot steht.
Was ein Integrationsprojekt tatsächlich umfasst
Bevor es um die Lücke geht, ein Wort zur Leistung selbst. Eine Integration auf Basis von AspenTech Inmation ist kein Konfigurationsvorgang. Sie besteht aus vier Blöcken, von denen jeder eigene Fachkenntnis verlangt.
Anbindung
Steuerungen, Historians, Leitsysteme, Datenbanken, Altanlagen ohne dokumentierte Schnittstelle. Jede Quelle mit eigenem Protokoll, eigenem Verhalten bei Verbindungsverlust und eigenen Eigenheiten bei Zeitstempeln.
Modellierung und Kontext
Aus „Temp_01" wird ein Messwert mit Anlagenbezug, Einheit und Bedeutung. Dieser Schritt entscheidet später darüber, ob eine Auswertung über Standorte hinweg überhaupt möglich ist – und er ist kaum nachträglich zu korrigieren.
Historisierung
Aufbewahrungsfristen, Verdichtung, Wiederherstellbarkeit, Nachvollziehbarkeit für Audits. Was hier nicht bedacht wurde, fehlt Jahre später genau dann, wenn es gebraucht wird.
Schnittstellen
Offene APIs, Datenbanklinks, Anbindung an ERP, MES und Auswertungswerkzeuge. Technisch der sichtbarste Teil – und der Punkt, an dem das Projekt üblicherweise als erfüllt gilt.
Das ist anspruchsvolle Arbeit, und sie ist notwendig — ohne diese vier Blöcke gibt es nichts zu nutzen. Der Punkt ist also nicht, dass zu wenig geliefert würde, sondern wo die Linie gezogen wird.
Warum die Grenze dort liegt, wo sie liegt
Die naheliegende Erklärung wäre Bequemlichkeit auf Anbieterseite, und sie trifft jedenfalls in der Regel nicht zu. Die Grenze hat einen sachlichen Grund: Links davon steht Datentechnik, rechts davon Anwendungsgestaltung. Das sind zwei Disziplinen.
Wer ein Datenmodell über vier Standorte konsistent aufbaut, denkt in Strukturen, Zeitreihen und Konsistenzregeln. Wer eine Ansicht für die Nachtschicht entwirft, denkt in Blickverläufen, Fehlbedienung und der Frage, was um drei Uhr morgens auf einen Blick erkennbar sein muss. Beides sind anspruchsvolle Tätigkeiten, die nur selten in derselben Person zusammenkommen.
Historisch war die Trennung außerdem sinnvoll. Ansichten kamen früher aus dem Leitsystem und waren dort Teil der Lieferung. Mit dem Aufkommen der Datenschicht als eigener Ebene ist diese Zuständigkeit stillschweigend verwaist. Sie wurde nicht abgeschafft, sondern niemandem zugeordnet.
Drei Dinge, die eine Integration nicht liefern kann
Es geht dabei nicht um Leistungen, die man hätte mitbestellen können. Es geht um Eigenschaften, die auf der Datenebene gar nicht entstehen können, weil sie erst in der Anwendung existieren.
Der dritte Punkt ist der, der in Projektreviews am seltensten auftaucht und im Betrieb am meisten wiegt. Wie er sich technisch löst – über fertige, konfigurierbare Compilations statt selbstgebauter – haben wir im ersten Beitrag dieser Reihe beschrieben.
Das zweite Projekt, das niemand geplant hat
Was hinter der Projektgrenze liegt, verschwindet nicht. Es wird nur später bezahlt, aus einem anderen Budget und meist ohne den Namen, der dazu passt.
Typischerweise läuft es so: Nach dem Go-Live baut jemand aus dem Team eine erste Ansicht, weil sie gebraucht wird. Sie funktioniert. Ein halbes Jahr später gibt es vier davon, gebaut von zwei oder drei Personen, jede anders aufgebaut. Dann fällt eine Person aus, eine Anforderung ändert sich, und die Änderung dauert länger als der ursprüngliche Bau. In diesem Moment beginnt ein zweites Projekt – nur heißt es nicht so, sondern „Aufräumen".
Der Aufwand dafür steht in keiner Investitionsrechnung. Er verteilt sich auf laufende Kapazität, auf Überstunden und auf Anfragen an einen Dienstleister, die einzeln klein aussehen. Genau deshalb wird er nicht gesteuert.
Die drei Fragen, die zeigen, ob die Lücke besteht
Wie viele Excel-Exporte laufen bei uns aus einem System, das Echtzeitdaten liefert?
Das ist der zuverlässigste Indikator, den ich kenne, und er kostet nichts. Jeder solche Export ist eine Ansicht, die jemand gebraucht hätte und nicht bekommen hat. Die Zahl steht in keinem Report, aber jeder Abteilungsleiter kann sie in fünf Minuten schätzen.
Wie lange lag zwischen der Abnahme unserer Datenschicht und der ersten Nutzung durch einen Bediener?
Sind es Wochen, hat die Anwendungsebene funktioniert. Sind es Monate oder ist die Frage unbeantwortbar, lag die Arbeit hinter der Projektgrenze und wurde nachträglich improvisiert.
Stand im Umfang unseres Integrationsprojekts, wer die Ansichten verantwortet?
In den meisten Verträgen steht dazu nichts – auch in unseren früheren nicht. Diese Frage vor dem nächsten Projekt zu stellen, ist der günstigste Zeitpunkt, an dem sie gestellt werden kann.
Was die Integration liefert, was der Betrieb braucht
| Gegenstand | Ergebnis der Integration | Anforderung des Betriebs |
|---|---|---|
| Datenzugang | Offene Schnittstelle, dokumentiert | Ansicht, die ohne Erklärung bedienbar ist |
| Kontext | Messwert mit Anlagenbezug und Einheit | Die drei Werte, die zusammen eine Aussage ergeben |
| Berechtigung | Rechte auf Datenpunkte und Objekte | Rollen, die einer Aufgabe im Betrieb entsprechen |
| Dokumentation | Systemdokumentation für die IT | Anleitung am Bildschirm, an dem gearbeitet wird |
| Änderung | Anpassung am Modell oder an der Schnittstelle | Zusätzliche Kennzahl in einer bestehenden Ansicht |
| Wer handelt | Datenteam oder Dienstleister | Wer die Frage hat, im Moment der Frage |
| Maßstab für „fertig" | Daten fließen verlässlich | Jemand arbeitet damit, ohne zu fragen |
Die linke Spalte ist erfüllt, sie ist nur nicht die rechte — und keine Verbesserung in der linken bringt die rechte näher. Eine schnellere API macht aus einer Schnittstelle keine Ansicht.
Wie wir das inzwischen anders angehen
Wir haben unsere Projektgrenze verschoben, nicht aus Kulanz, sondern weil die alte Grenze die Wirkung unserer eigenen Arbeit begrenzt hat. Eine Datenschicht, die niemand nutzt, ist für uns kein erfolgreiches Projekt, auch wenn sie abgenommen wurde.
Die Anwendungsebene gehört zum Umfang
Wir klären vor dem Projekt, wer welche Ansichten braucht und wer sie später pflegt. Diese Frage kostet im Vorfeld eine Stunde und entscheidet über die Wirkung der gesamten Investition.
Fertige Compilations statt Codevorlagen
Das cts Application Framework liefert einsatzbereite Ansichten, die das Team des Kunden konfiguriert. Damit liegt die Pflege dort, wo das Prozesswissen sitzt – und nicht bei uns.
Bestehendes wird eingebunden
Was nach einem früheren Projekt selbst gebaut wurde, wird nicht ersetzt. Es wird in denselben Rahmen geholt und erbt Oberfläche, Rechte und Dokumentationsbindung.
Was wir nicht versprechen
Der Rahmen und die Compilations sind fertig, die Zuordnung zu Anlagen, Rollen und Prozessen dagegen ist Projektarbeit. Wie viel, hängt vom Setup ab – das schätzen wir vorher gemeinsam ab, nicht hinterher.
Die unbequeme Fassung dieses Befundes lautet: Wir haben als Branche jahrelang Datenschichten geliefert und die Frage, wer damit arbeitet, dem Kunden überlassen. Formal war das korrekt. Nützlich war es nicht. Wer heute eine Integration ausschreibt, sollte die Anwendungsebene mit ausschreiben – und wer sie anbietet, sollte sie mit anbieten.
Steht Ihre Datenschicht – und die Nutzung fehlt?
Sie brauchen kein Briefing. Wir sehen uns an, was heute bereits läuft, und sagen Ihnen, welche Strecke zwischen Ihrer Datenschicht und dem Betrieb noch offen ist.
Sprechen Sie mit unseren Experten
