Konfigurations- & Nachverfolgbarkeits-KI

Ein Design. Vierzig Seriennummern. Drei Jahrzehnte Änderungen. Beweisen Sie, dass sie zusammenpassen — das ist der Vertrag.

Jedes Verteidigungssystem existiert gleichzeitig in drei Wahrheiten. As-Designed: was die Zeichnungen und die Teamcenter-Stückliste definieren, in exakten Revisionen und Baselines. As-Built: was tatsächlich gefertigt und ausgeliefert wurde, je Seriennummer, je Schiff, je Kundennation. As-Maintained: was heute im Feld steht, nach Refits, Nachrüstungen und Modifikationsprogrammen. STANAG 4427 und sein ACMP-Rahmenwerk — und dahinter die Abnahmebehörden Ihrer Kunden — verlangen, dass diese drei Wahrheiten über die gesamte Nutzungsdauer abgleichbar bleiben. Dreißig bis fünfzig Jahre. Pro Einheit.

Die Branche weiß, wie schwer das ist: Wenn eine Flotte auf eine “neue Referenzkonfiguration” konsolidiert wird — das Muster Leopard 2 A8 —, dann genau deshalb, weil jahrzehntelange Divergenz die alte Baseline unbeherrschbar gemacht hat. Im Alltag läuft der Abgleich auf dem denkbar fragilsten Werkzeug: erfahrene Leute, Tabellenkalkulationen und wochenlanges Gegenprüfen zwischen PLM, ERP-Baubelegen und Änderungspapier, sobald ein Audit oder eine Kundenfrage eintrifft.

Wir automatisieren die Buchführungsschicht darunter: KI und Regeln vergleichen fortlaufend As-Designed gegen As-Built und die Änderungshistorie, markieren jede Lücke und jeden Konflikt mit angehängtem Nachweis, erstellen Konfigurationsstatusberichte auf Abruf — und beantworten “Welche Seriennummern betrifft diese Änderung?” als Abfrage statt als Rechercheprojekt. Innerhalb Ihres Perimeters, auf dem souveränen Stack. Ihre CM-Boards entscheiden weiterhin; die Maschine führt die Bücher.

// Konfigurationsrealität, in Zahlen

0 Wahrheiten

As-Designed, As-Built, As-Maintained — vertraglich gefordert, über Jahrzehnte abgleichbar zu bleiben

0Tsd.+

technische Änderungen über das Leben einer Plattform — jede eine Gelegenheit für die Wahrheiten, auseinanderzudriften

Wo. pro Audit

manuelles Gegenprüfen zwischen PLM, Baubelegen und Änderungspapier vor jedem FCA/PCA

0 ausgehend

Datensätze verlassen Ihren Perimeter — die Buchführung läuft auf dem souveränen, air-gapped Stack

Konfigurationsdrift ist lautlos — bis zum Audit oder zum Vorfall

Niemand entscheidet, Konfigurationen driften zu lassen. Es passiert Ausnahme für Ausnahme: eine freigegebene Änderung, ab Seriennummer 12 eingearbeitet, aber für die Nachrüstcharge nie rückdokumentiert; eine Bauabweichung, in einem PDF dokumentiert, das nie ins PLM gelangte; eine Ländervariante, deren Delta zur Baseline im Kopf eines einzigen Programmleiters lebt. Jede für sich klein. Über zehntausend Änderungen und vierzig Seriennummern summiert, ergeben sie den Zustand, den jeder CM-Verantwortliche kennt und niemand zugibt: Die offiziellen Aufzeichnungen und die reale Flotte widersprechen sich, und niemand kann genau sagen, wo.

Die Kosten kommen in drei Formen. Auditbefunde — ein FCA/PCA, das Inkonsistenzen zutage fördert, die Sie zuerst hätten finden können, unter den Augen Ihrer Abnahmebehörde. Operatives Risiko — ein Refit, geplant gegen As-Designed-Daten, die nicht zu dem Schiff passen, das tatsächlich in die Werft einläuft. Und reiner Aufwand: Configuration Status Accounting von Hand, Wochen je Audit, Tabellen je Flotte, und die ständige Grundsteuer, “In welcher Konfiguration ist Einheit X?” aus Erinnerung und Ordnern zu beantworten.

Das Absurde daran: Die Nachweise existieren größtenteils — in Teamcenter-Revisionen und Effectivities, in ERP-Baubelegen, in Änderungsdokumenten, in Abnahmeprotokollen. Sie sind über Systeme verstreut, die nie maschinell abgeglichen wurden. Genau dieser Abgleich ist die Art unermüdlicher, regelgeleiteter Gegenprüfung, für die KI gebaut ist — und genau die Art, die Menschen über dreißig Jahre am schlechtesten durchhalten.

// Konsistenzprüfung — S/N 0043, Kühlsystem · vor dem Refit ausgeführt, nicht währenddessen

1.842 Datensatzpaare verglichen · Teamcenter-Stückliste ⟷ Baubelege ⟷ Änderungshistorie · vollständiger Bericht am Item angehängt

ÜBEREINSTIMMUNG

CHK-0801 · Pumpenbaugruppe: Stückliste Rev. E = Baubeleg Rev. E, Effectivity konsistent, 1.791 weitere Merkmale in Übereinstimmung

LÜCKE

CHK-0834 · Rohrleitungsabschnitt: Bauabweichung im Abnahmeprotokoll vermerkt (2011, PDF), nie als Änderungsdatensatz ins PLM übernommen

KONFLIKT

CHK-0847 · Ventilblock: As-Designed verlangt Rev. C, der Baubeleg zeigt Rev. B verbaut

Im Klartext: Die Änderung auf Rev. C wurde freigegeben und in die Stückliste eingearbeitet, aber S/N 0043 gehörte zur Nachrüstcharge, und die Einarbeitung wurde nie bestätigt. Das Schiff trägt höchstwahrscheinlich weiterhin Rev. B. Vorbereitete Maßnahme: Prüfauftrag für die nächste Werftliegezeit, mit angehängter Nachweiskette entworfen — zur Freigabe durch Ihr CM-Board.

So arbeitet die Buchführungsschicht

Das System tut eine Sache unermüdlich: die Datensätze verbinden, die dieselbe physische Realität beschreiben, und melden, wo sie sich widersprechen. Es sitzt auf Ihren bestehenden Systemen auf — es ersetzt weder Ihr PLM noch Ihr ERP noch Ihren CM-Prozess:

01 — ANBINDEN

Die drei Wahrheiten, angebunden

Teamcenter-Stücklisten, Revisionen, Effectivity
ERP- / Baubelege je Seriennummer
Änderungsdokumente — digital und aus Papier erschlossen
Abnahme- & Wartungsprotokolle

02 — VERKNÜPFEN

Dieselbe Realität, ein Modell

Teile ↔ Änderungen ↔ Seriennummern ↔ Plattformen
Ländervarianten als Deltas zur Baseline
LLM extrahiert aus unstrukturierten Dokumenten
Jede Verknüpfung behält ihre Quelle

03 — PRÜFEN

Widersprüche, maschinell gefunden

As-Designed ⟷ As-Built je Seriennummer
Freigegebene, aber nicht eingearbeitete ECPs
Abweichungen, die im PLM fehlen
ÜBEREINSTIMMUNG / LÜCKE / KONFLIKT mit Nachweis

04 — BERICHTEN

CSA auf Abruf — Menschen geben frei

Konfigurationsstatusberichte, entworfen
Auditnachweis-Pakete (FCA/PCA)
Flotten- & ECP-Wirkungsabfragen
Ihr CM-Board entscheidet — immer

Vier Aufgaben, die die Buchführungsschicht übernimmt

Sobald die Datensätze verknüpft und fortlaufend geprüft sind, werden vier chronische Schmerzen zu Routinevorgängen:

Auditvorbereitung, die die Befunde zuerst findet

Vor jedem FCA/PCA läuft die Konsistenzprüfung flottenweit: Lücken und Konflikte tauchen mit angehängtem Nachweis auf, Prüfaufträge werden entworfen, und Sie gehen mit Ihrer eigenen Befundliste ins Audit — gelöst oder erklärt — statt sie live zu entdecken.

Flottenkonfiguration, abfragbar

„In welcher Konfiguration ist Einheit X tatsächlich?“ — beantwortet aus verknüpften Datensätzen, je Seriennummer, mit dem Delta zur Baseline und jeder nicht eingearbeiteten Änderung sichtbar. Refits werden gegen die Realität geplant, nicht gegen die Hoffnung.

ECP-Wirkung in Minuten

Eine Änderung wird vorgeschlagen: Welche Seriennummern, Varianten und Plattformen berührt sie, womit kollidiert sie, von welchen früheren Änderungen hängt sie ab? Die Wirkungshälfte des Änderungsmanagements wird zur Abfrage — Ihr Board verbringt seine Zeit mit der Entscheidung, nicht mit der Recherche.

Alte Änderungshistorie, zurückgewonnen

Jahrzehnte an Papier-ECRs, Abweichungsblättern und Abnahmeprotokollen werden in die strukturierte Historie erschlossen — dieselbe Pipeline wie bei unserem Zeichnungs-Mining. Die Änderungen, die nur als gescannte Unterschriften existieren, kommen endlich in der Buchführung an.

Für wen das gedacht ist

Sie sind ein Kandidat, wenn das meiste hiervon zutrifft:

Sie liefern oder betreuen Systeme unter Konfigurationsmanagement nach STANAG 4427 / ACMP — mit FCA/PCA-Audits und offizieller Abnahme.
Ihre Flotte umfasst Konfigurationen auf Seriennummernebene — als Einzelstücke gebaute Schiffe, Fahrzeugchargen, Ländervarianten.
Configuration Status Accounting läuft auf Tabellen und Veteranen — und die Auditvorbereitung kostet jedes Mal Wochen.
Ein Teil der Änderungshistorie existiert nur als Papier und gescannte PDFs aus früheren Jahrzehnten.
Sie betreiben Teamcenter (oder ein vergleichbares PLM) neben einem ERP — und die beiden wurden nie maschinell abgeglichen.
Ihre Datensätze sind VS-NfD oder exportkontrolliert — die Buchführung muss innerhalb Ihres Perimeters laufen.

Worauf die Buchführungsschicht aufbaut

Ihre Systeme bleiben die führenden Systeme — die Schicht verbindet und prüft, auf Infrastruktur, die Sie kontrollieren.

Teamcenter-Stückliste / -Revision / -Effectivity ERP-Baubelege je Seriennummer LLM-Extraktion aus Änderungsdokumenten Verknüpfung Teil–Änderung–Seriennummer–Plattform Regelbasierte Konsistenzprüfungen CSA-Berichtserzeugung Nachweispakete mit Quellverlinkung Pipeline zur Erschließung von Altpapier Im Perimeter · souveräner Stack

Vorher und nachher: sechs Wochen bis zum PCA

Das physische Konfigurationsaudit für eine Schiffsklasse steht an. So laufen die sechs Wochen davor, auf beiden Seiten der Veränderung:

Vorher — die Tabellenkampagne

Task Force zusammengestellt, Programmarbeit geparkt — 6 Wo.
PLM, ERP und Ordner von Hand abgeglichen, Seriennummer für Seriennummer
Bekannte Problemzonen still überhofft
Der Auditor findet den nicht eingearbeiteten ECP trotzdem — Befund, Maßnahmenplan, Nachaudit
Nächstes Audit: dieselbe Kampagne, von null

Nachher — laufende Buchführung

Der Konsistenzstand ist an Tag eins bekannt — die Prüfungen liefen das ganze Jahr
Offene LÜCKEN und KONFLIKTE tragen entworfene Prüfaufträge — bearbeitet, nicht gefürchtet
Nachweispakete werden je Auditumfang erzeugt — Stunden
Sie legen Ihre eigene Befundliste mit Lösungen vor — das Audit wird zum Review
Die Task Force wird wieder zu Ingenieuren

Warum inteliScience — und was die KI bewusst nicht tut

Konfigurationsmanagement ist in seinem Datenkern eine Teamcenter-Disziplin — Revisionen, Effectivity, Baselines, Änderungsobjekte — verheiratet mit einem ERP und begraben unter Jahrzehnten von Dokumenten. Genau diese Kombination ist unser Heimspiel: Wir bauen jeden Tag Teamcenter-Anpassungen auf unterstützten Schnittstellen, und unsere Dokumenten-KI liest die unstrukturierte Hälfte Ihrer Änderungshistorie. Keine generische KI-Beratung bringt beides mit; kein CM-Toolhersteller liest Ihre Abweichungsblätter von 1994.

Die Grenzen, klar benannt. Die KI macht kein Konfigurationsmanagement. Ihr CM-Plan, Ihre Boards, Ihre Freigaben bleiben Prozess und Menschen — die Maschine ist die Buchführungsschicht darunter: Sie findet Widersprüche, entwirft Berichte und Prüfaufträge und stellt Nachweise zusammen; sie gibt nichts frei und arbeitet nichts ein. Sie kaschiert keine Lücken. Wo die As-Built-Dokumentation schlicht Löcher hat, macht das System sie sichtbar und listet sie auf — was vor einem offiziellen Audit genau das ist, was Sie wollen: eine bekannte Lücke mit Prüfplan schlägt eine unbekannte Lücke, auf die der Auditor seine Taschenlampe richtet. Und weil diese Datensätze Verteidigungssysteme beschreiben, läuft die gesamte Schicht innerhalb Ihres Perimeters, auf dem souveränen, air-gapped Stack, mit Kennzeichnungen je Nutzer.

Festpreis — keine Tagessätze, keine Überraschungen

Konfigurations-Buchführungs-Pilot

€29,900 Festpreis

Ein System oder eine Plattformfamilie — As-Designed-/As-Built-Quellen innerhalb Ihres Perimeters angebunden
Konsistenzprüfung über die verfügbaren Datensätze — gemessene Befundliste (ÜBEREINSTIMMUNG/LÜCKE/KONFLIKT)
Stichprobe alter Änderungsdokumente in die strukturierte Historie erschlossen
CSA-Bericht und Demo eines Audit-Nachweispakets, gemeinsam mit Ihrem CM-Team geprüft
Rollout-Blueprint: weitere Plattformen, laufende Prüfung, Abstimmung auf den Auditkalender

Pilotgespräch starten

8–10 Wochen · läuft vollständig auf Ihrer Infrastruktur · Befunde und Berichte gehören Ihnen, wie auch immer Sie sich danach entscheiden.

Zum Vergleich

Der Status quo mit Tabellen

Wochenlange Task-Force-Abgleiche vor jedem Audit, flottenweit, von Hand
Befunde, Maßnahmenpläne und Nachaudits für Konflikte, die eine Maschine in Sekunden findet
Und das operative Risiko: Refits, geplant gegen Datensätze, zu denen das Schiff nicht passt

Häufige Fragen

Ersetzt das unseren CM-Prozess oder unsere Werkzeuge?

Nein — bewusst nicht. Ihr CM-Plan, Ihre Änderungsboards, Ihre Teamcenter-Änderungsobjekte und Ihre Freigaben bleiben genau das, was STANAG 4427 von ihnen erwartet: Ihr Prozess, betrieben von Ihren Leuten. Die KI ist die Buchführungsschicht darunter — sie gleicht Datensätze ab, die Ihr Prozess ohnehin erzeugt, entwirft Berichte, die Ihr Prozess ohnehin schuldet, und übergibt Befunde an die Menschen, die entscheiden. Nichts wird von einer Maschine freigegeben, eingearbeitet oder geschlossen.

Unsere As-Built-Dokumentation hat echte Lücken. Was passiert dann?

Die Lücke wird zu einem aufgelisteten, belegten Befund — nie zu einem stillschweigend interpolierten Datensatz. Das ist ein Konstruktionsprinzip: Für Systeme, die zur See oder ins Feld gehen, ist eine bekannte Lücke mit entworfenem Prüfauftrag (bei der nächsten Werftliegezeit prüfen, bei der nächsten Wartung inspizieren) operativ und auditseitig weit besser als eine selbstbewusste Vermutung. Die erste flottenweite Prüfung kann allein schon den Piloten wert sein, schlicht als ehrliche Landkarte des tatsächlichen Zustands Ihrer Aufzeichnungen.

Wie geht die KI mit Jahrzehnten an Papier-Änderungsdokumenten um?

Mit derselben Mining-Pipeline wie unser Angebot für Altzeichnungen: Gescannte ECRs, Abweichungsblätter und Abnahmeprotokolle werden extrahiert — Änderungs-ID, betroffene Teile, Seriennummern, Freigabeunterschriften, Daten —, konfidenzbewertet, bei Unsicherheit menschlich geprüft und in die strukturierte Historie verknüpft. Die Änderungen, die heute nur als abgeheftete Unterschriften existieren, nehmen endlich an der Buchführung teil. Wo das Papier selbst fehlt, gilt die vorige Antwort: sichtbare Lücke, keine erfundene Historie.

Wo läuft das alles? Diese Datensätze beschreiben Waffensysteme.

Vollständig innerhalb Ihres Sicherheitsperimeters, auf dem souveränen, air-gapped Stack — derselben Architektur wie unsere Verteidigungs-Engineering-KI: keine ausgehenden Routen, lückenloses Audit-Logging, Exportkontroll- und Einstufungskennzeichnungen je Dokument und je Nutzer beachtet. Ihr Sicherheitsbeauftragter ist im ersten Termin willkommen; die Architektur ist darauf gebaut, seine Fragen zu beantworten.

Unsere Flotte driftet seit 20 Jahren. Ist es dafür nicht zu spät?

Im Gegenteil — angesammelte Drift ist genau dort, wo sich die Buchführung am schnellsten bezahlt macht, denn die erste Prüfung erzeugt die ehrliche Landkarte, die seit Jahren niemand hatte: was übereinstimmt, wo Lücken sind, was kollidiert, nach operativer Relevanz sortiert. Genau diese Landkarte braucht ein Re-Baselining (das Muster der „neuen Referenzkonfiguration“, dem die Branche zunehmend folgt) als Eingabe am ersten Tag. Man räumt nicht zwanzig Jahre von Hand auf und automatisiert danach; man automatisiert, um die zwanzig Jahre aufräumbar zu machen.

Können wir mit einem System statt mit der ganzen Plattform starten?

Genau das macht der Pilot: ein System oder eine Plattformfamilie, die verfügbaren As-Designed- und As-Built-Quellen angebunden, die Konsistenzprüfung ausgeführt und eine gemessene Befundliste, die Ihr CM-Team gemeinsam mit uns durchgeht. Die Skalierung auf weitere Systeme ist dann eine Entscheidung auf Basis Ihrer eigenen Zahlen — und der Auditkalender gibt die Reihenfolge meist vor.

Ihr nächstes Konfigurationsaudit steht bereits im Kalender. Finden Sie Ihre Befunde vor dem Auditor.

Wählen Sie das eine System, dessen Aufzeichnungen Sie am wenigsten trauen — wir führen die erste Konsistenzprüfung darauf aus, innerhalb Ihres Perimeters, und gehen die Landkarte gemeinsam durch.

Mit einem Konfigurations-KI-Ingenieur sprechen

Wir sind jederzeit für Sie da: Kontaktieren Sie uns mit Ihren Fragen – wir begleiten Sie Schritt für Schritt.

Telefon: +40 774 463 429
Unser Standort: Str. Ploiești 9, 400157
Cluj-Napoca, Rumänien
E-Mail: info@inteliscience.net
LinkedIn: inteliScience auf LinkedIn
YouTube: inteliScience auf YouTube