Fragen Sie Ihren Buchhalter, welcher Stand gilt.
Er versteht die Frage nicht. Für ihn ist sie seit dem Handelsgesetzbuch beantwortet: Jeder Wert in der Bilanz führt zurück auf einen Beleg, und jeder Beleg führt vorwärts in die Bilanz. In beide Richtungen, jederzeit, ohne Rückfrage.
Stellen Sie dieselbe Frage in der Entwicklung. Sie bekommen einen Termin.
Der Fachbegriff ist derselbe#
Die GoBD — die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern in elektronischer Form — verlangen ausdrücklich progressive und retrograde Prüfbarkeit. Progressiv heißt: vom Beleg über die Buchung bis zur Bilanzposition. Retrograd heißt: von der Bilanzposition zurück bis zum einzelnen Beleg.
Das ist wörtlich bidirektionale Nachvollziehbarkeit. Im Engineering heißt das Traceability.
Und es ist exakt dasselbe, was Automotive SPICE für die Kette Anforderung–Architektur–Design–Test verlangt, was ISO 26262 für das Sicherheitsargument fordert und was ISO/SAE 21434 für den Cybersecurity-Nachweis erwartet.
Derselbe Begriff. Dieselbe Anforderung. Zwei Abteilungen in derselben Firma. In der einen ist sie so selbstverständlich, dass niemand darüber spricht. In der anderen ist das der Klassiker unter den Assessment-Befunden.
Drei Unterschiede, die keine Kulturfrage sind#
| Rechnungswesen | Engineering und Qualität |
|---|---|
| Keine Buchung ohne Beleg | Werte entstehen in einer Tabelle, die Herkunft ist offen |
| Geändert wird per Storno — mit Spur | Die Zelle wird überschrieben, der alte Wert ist weg |
| Verfahrensdokumentation ist Pflicht | „Das weiß der Kollege" |
Der mittlere Punkt ist der bemerkenswerteste. Eine spurlose Änderung an einer Buchung ist im Rechnungswesen kein Versäumnis, sondern ein Straftatbestand. Dieselbe spurlose Änderung an einem Merkmal, einer Toleranz, einer Bewertung ist im Engineering Dienstag.
Nicht weil dort schlechtere Menschen arbeiten. Sondern weil die Werkzeuge es zulassen — und weil niemand ein Werkzeug benutzt, das ihm die Arbeit erschwert, solange es ein einfacheres gibt.
Und trotzdem: die Buchhaltung hat es leichter#
An dieser Stelle wird der Vergleich normalerweise zur Belehrung. „Werdet so ordentlich wie die Buchhaltung." Das ist unfair, und es ist sachlich falsch.
Ein Buchungssatz ist atomar, abgeschlossen und wird nie wieder angefasst. Er hat einen Betrag, ein Datum, zwei Konten. Er ist in dem Moment fertig, in dem er entsteht.
Ein Requirement ist nichts davon. Es ist in Prosa formuliert und damit auslegungsfähig. Es verzweigt in Varianten, Ländervarianten, Kundenvarianten. Es ändert sich drei-, fünf-, zehnmal bis zum Serienstart und selbst danach. Es hängt an anderen Requirements, an Architekturentscheidungen, an Annahmen über den Einsatzkontext. Es hat Zustände, die ein Buchungssatz nicht kennt: vorgeschlagen, verhandelt, abgelehnt, wieder aufgenommen.
Die Entwicklung soll die schwierigere Aufgabe lösen — mit den schwächeren Mitteln. Das Rechnungswesen hat seit Jahrzehnten Systeme, die für genau seinen Nachweis gebaut sind. Die Entwicklung hat Systeme, die für Dokumente gebaut sind, und daneben Excel, Sharepoint und mehr.
Dass es in der Buchhaltung funktioniert, ist deshalb kein Vorwurf. Es ist ein Existenzbeweis: Der Nachweis über eine ganze Wertschöpfungskette ist möglich, dauerhaft, ohne Heldentum. Er scheitert im Engineering nicht an der Natur der Sache.
Im deutschen Rechnungswesen gekten ca 100 Vorgaben, im Engineering sind 400 ++ Vorgaben eher Normalfall,
Der Engineering Einwand, der berechtigt ist#
„Wenn wir anfangen, wie die Buchhaltung zu arbeiten, ersticken wir in Bürokratie."
Der Einwand ist gut, und wer ihn erhebt, hat meistens recht behalten. Denn wer die Buchhaltung als Vorbild aufruft, holt sich normalerweise ihr gesamtes Paket ins Haus: feste Kontenrahmen, formalisierte Freigabewege, Dokumentation um der Dokumentation willen. In einer Entwicklung, die noch nicht weiß, wie die Lösung aussehen wird, ist das nicht nur lästig — es ist schädlich.
Deshalb gehört der Vergleich begrenzt:
Übertragbar ist das Belegprinzip. Jeder Wert hat eine nachweisbare Herkunft. Jede Änderung hinterlässt eine Spur. Der Nachweis ist erzeugbar, nicht rekonstruierbar.
Nicht übertragbar ist der Kontenrahmen. Eine im Voraus festgelegte, für alle verbindliche Struktur, in die jeder Sachverhalt hineingezwungen wird. Genau das braucht Entwicklung nicht und verträgt sie nicht.
Der Unterschied ist entscheidend: Das eine sagt, woher etwas kommt. Das andere schreibt vor, wie es auszusehen hat. Das erste ermöglicht Entwicklung, das zweite erstickt sie. Wer beides in einem Atemzug fordert…….
Und noch eine Grenze, damit die Analogie nicht überdehnt wird: Das Rechnungswesen kann Zustände nicht abbilden, die im Engineering unverzichtbar sind — Varianten, Alternativen, Annahmen, verworfene Entwürfe, die man später wieder hervorholt. Ein System, das die Herkunft sichert, aber diese Zustände nicht kennt, ist kein Fortschritt, sondern ein Freigabe-Workflow mit besserem Namen.
Woher die Lücke kommt#
Die Kette im Engineering ist nicht deshalb offen, weil niemand sie schließen will. Sie ist offen, weil die Verknüpfungen zwischen den Gliedern kein Datum (fester Wert) sind, sondern Wissen.
Dass dieses Merkmal aus jener Anforderung folgt, weiß der Entwickler. Dass diese Prüfung genau jenes Merkmal absichert, weiß der Qualitätsplaner. Beides steht nirgends, jedenfalls nicht so, dass ein System es auswerten könnte. Es steht in Dokumenten nebeneinander, und der Zusammenhang entsteht im Kopf dessen, der beide gelesen hat.
Genau deshalb ist jedes Merkmal mehrfach vorhanden: In der Spezifikation, in der FMEA, in der Prozess FMEA, im Prüfplan, ind der Arbeitsannweisung, in der Prüfanweisung, im Lastenheft. Viele Kopien, weil viele Sichten gebraucht werden und das System nur Kopien anbietet. Was daraus folgt — und warum das kein Toolproblem ist — steht ausführlicher im Artikel Welcher Stand gilt?.
Kurz gefasst: Der Buchhalter mit vielen Kopien seines Belegs hätte mehr als ernsthafte Probleme. Er hat einen Beleg und viele Auswertungen darüber. Das ist der ganze Unterschied.
Woran Sie es prüfen können#
Zwei Fragen, beide ohne Software zu beantworten:
Die retrograde Frage. Nehmen Sie einen beliebigen Prüfeintrag aus einem laufenden Projekt. Wie lange dauert es, bis jemand belegen kann, aus welcher Kundenanforderung er letztlich folgt? Der Buchhalter braucht dafür Sekunden.
Die progressive Frage. Nehmen Sie eine Kundenanforderung, die vor sechs Monaten geändert wurde. Wie lange dauert es, bis jemand belegen kann, dass alle daraus folgenden Merkmale, Prüfungen und Lieferantenvorgaben nachgezogen wurden — belegen!, nicht vermuten?
Wenn beide Antworten „Sekunden" lauten, brauchen Sie nichts von dem, was hier steht.
Wenn eine davon „das müsste man zusammensuchen" lautet, kennen Sie den Preis.
In eigener Sache
Ich habe fünfzehn Jahre in genau dieser Situation gesessen, auf beiden Seiten des Tisches — als der, der die Kette rekonstruieren musste, und als der, der später erklären durfte, warum sie offen war. 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.