Stellen Sie einem beliebigen Entwicklungs-, Qualitäts- oder Projektteam eine einzige Frage:
Welcher Stand gilt?
Nicht als Vorwurf, sondern als Zeitmessung. Wie lange dauert es, bis jemand mit Sicherheit sagen kann, welcher der vorliegenden Stände der verbindliche ist? Sekunden? Oder eine Rückfrage, eine Mail, ein Termin? Haben die Kollegen ggf. unterschiedliche Versionen (fast immer)?
Wer diese Frage nicht in Sekunden beantworten kann, beantwortet sie in Besprechungen und Meetings. Das ist der eigentliche Preis, und er steht in keiner Kostenstelle.
Das Beispiel, das jeder kennt#
Ein Merkmal — sagen wir eine Toleranz an einer Welle.
Es steht in der Spezifikation. Es steht in der FMEA, weil dort die Fehlerbetrachtung daran hängt. Es steht im Prüfplan, weil geprüft werden muss. Es steht im Lastenheft an den Lieferanten, weil er es einhalten soll. Vier Einträge, vier Pflegepfade, vier Personen, die sie verantworten.
Jetzt ändert sich die Toleranz.
Im günstigen Fall erfahren es alle vier. Im realistischen Fall erfahren es drei, und der vierte arbeitet weiter mit dem alten Wert. Niemand merkt es. Es gibt keinen Alarm, keine rote Zeile, keinen Widerspruch im System — die vier Einträge wissen nichts voneinander.
Auffallen wird es später. Im Audit, in der Freigabe, in der Reklamation. Und dann ist es kein Datenproblem mehr, sondern ein Vorfall mit Namen und Verantwortlichem.
Warum das Datenproblem nie priorisiert wird#
Genau dieser Zeitverzug ist der Grund, warum das Problem seit zwanzig Jahren bekannt ist und trotzdem nicht gelöst wird.
Der Schaden entsteht nicht dort, wo die Ursache liegt. Wer die Kopie pflegt, spürt nichts. Wer den Schaden hat, sieht die Kopie nicht. Zwischen Ursache und Wirkung liegen Wochen und typischerweise » (1) eine Abteilungsgrenze. Ein Problem mit dieser Signatur landet nie oben auf einer Prioritätenliste, weil an keiner einzelnen Stelle genug Schmerz entsteht, um es dorthin zu tragen.
Stattdessen wird das Symptom kompensiert. Mit Abstimmungsterminen, mit Review-Runden, mit einer Person, die „den Überblick hat". Das funktioniert sogar — es kostet nur dauerhaft Zeit, und es skaliert nicht.
Die zwei üblichen Antworten#
„Wir müssen disziplinierter pflegen."
Das setzt voraus, dass Vollständigkeit erreichbar ist. Bei vier Kopien pro Merkmal und einigen tausend Merkmalen ist sie es nicht. Jede Änderung erfordert, dass jemand alle betroffenen Stellen kennt — auch die in Nachbarabteilungen, auch die in Dokumenten, die er noch nie geöffnet hat. Das ist keine Frage der Sorgfalt, sondern der Erreichbarkeit von Information. Mehr Disziplin verschiebt die Fehlerquote, sie beseitigt die Ursache nicht.
„Wir brauchen ein System, in dem alles zusammenläuft."
Das ist die teurere Variante desselben Irrtums, und sie führt zur nächsten Frage.
Der Einwand, der ernst genommen gehört#
„Wir haben doch längst ein PLM. Genau dafür ist es da."
Der Einwand ist berechtigt, und er ist nicht mit einem Satz zu erledigen. Moderne PLM-, ALM- und QM-Systeme können Verknüpfungen. Sie haben Änderungsmanagement, Baselines, Impact-Analysen. Wer sie konsequent nutzt, hat das Problem in seinem Kern deutlich reduziert. Das ist kein Marketingversprechen, das ist gelebte Praxis.
Und trotzdem: Fragen Sie in einem Unternehmen mit ausgereiftem PLM, ob dort Excel-Dateien im Umlauf sind. Die Antwort ist immer ja.
Das ist der entscheidende Befund. Die Excel-Datei entsteht nicht aus Bequemlichkeit. Sie entsteht, weil jemand eine Sicht auf die Daten braucht, die das System nicht anbietet — eine Zusammenstellung über Modulgrenzen, eine Auswertung, die im Standardbericht nicht vorgesehen ist, eine Arbeitsliste in der Struktur seiner eigenen Aufgabe. Er exportiert, arbeitet weiter, und in dem Moment ist eine neue Kopie in der Welt.
Fragmentierung ist also nicht die Ursache. Sie ist selbst eine Folge. Firmen mit fünf Systemen haben das Problem, und Firmen mit einem großen System haben es auch — nur dass die Kopien dort Excel heißen statt Fremdtool. Die Ursache ist die Kopie, nicht die Zahl der Systeme.
Das erklärt auch, warum Konsolidierungsprogramme so oft enttäuschen. Sie reduzieren die Zahl der Systeme und lassen den Mechanismus unangetastet, der die Kopien erzeugt. Selbst API’s (Application Programming Interface, auf Deutsch Programmierschnittstelle) löst das Problem der Datendrift nicht vollständig. Die Daten sind doppelt vorhanden.
Die These#
Wenn die Kopie das Problem ist, dann ist die Lösung nicht ein besseres System, sondern ein anderes Datenmodell:
Ein Sachverhalt wird einmal gespeichert. Jede Disziplin bekommt eine Sicht darauf — nicht eine Kopie davon.
Der Unterschied ist kein sprachlicher. Eine Kopie ist ein eigenständiges Datum mit eigenem Lebenszyklus; sie kann driften, ohne dass es jemand bemerkt. Eine Sicht ist eine Projektion auf dasselbe Objekt; sie kann nicht driften, weil es nichts gibt, was driften könnte. Wer die Sicht ändert, ändert das Objekt. Wer das Objekt ändert, ändert alle Sichten — gleichzeitig, ohne Abstimmungstermin.
Woran diese These scheitern würde#
Eine Behauptung, die nicht falsch sein kann, ist wertlos. Diese hier ist an mindestens drei Stellen angreifbar, und sie gehören genannt:
Erstens: Wenn zwei Disziplinen denselben Sachverhalt tatsächlich unterschiedlich brauchen — nicht aus Nachlässigkeit, sondern fachlich begründet — dann ist es keine Kopie, sondern zwei verschiedene Dinge. Der Prüfplan darf enger tolerieren als die Spezifikation, allerdings stellt sich sofort die Frage warum. Ein Modell, das solche Fälle nicht abbilden kann, erzwingt eine falsche Gleichmacherei und ist schlechter als vier Kopien. Der Unterschied zwischen „abweichend, weil begründet" und „abweichend, weil vergessen" muss im System sichtbar sein.
Zweitens: An den Rändern zu Fremdsystemen — CAD, Simulation, Lieferantensysteme — bleibt eine Datengrenze bestehen. Dort werden weiterhin Kopien entstehen. Wer behauptet, das Problem restlos zu lösen, hat es nicht verstanden. Es lässt sich verschieben, verkleinern und sichtbar machen; abschaffen lässt es sich nicht.
Drittens: Der Aufwand liegt vorn. Man muss einmal beschreiben, was mit was zusammenhängt. Das ist Arbeit, und sie fällt an, bevor der Nutzen eintritt. Wer das nicht will, ist mit vier Kopien und guter Disziplin besser bedient — und das ist eine legitime Entscheidung.
Woran Sie es messen können#
Der Test ist einfach und braucht keine Software:
Nehmen Sie ein beliebiges Merkmal aus einem laufenden Projekt. Lassen Sie zählen, an wie vielen Stellen es steht. Lassen Sie prüfen, ob alle Stellen denselben Wert tragen.
Wenn die Antwort „an einer Stelle" lautet, brauchen Sie nichts von dem, was hier steht.
Wenn niemand die Zahl kennt, haben Sie das Ergebnis.
In eigener Sache
Ich habe fünfzehn Jahre in genau dieser Situation gesessen, auf beiden Seiten des Tisches — als der, der die Kopien pflegen musste, und als der, der später erklären durfte, warum sie auseinanderliefen. Irgendwann habe ich angefangen, das Werkzeug zu bauen, das ich damals gebraucht hätte. Es heißt OTSM.
Wenn Sie wissen wollen, ob das Modell für Ihre Situation trägt: Sagen Sie mir Ihre Branche, mehr nicht. Ich bereite nichts vor. Sie legen im Gespräch ein Datenproblem aus Ihrem Alltag auf den Tisch, und ich zeige Ihnen live, wie ich es lösen würde.
Wenn ich es kann, sehen Sie es in diesem Termin. Wenn ich es nicht kann, sage ich Ihnen das im selben Termin — dann passt es nicht, und Sie haben eine Stunde verloren statt eines Projekts.