Warum Tabellenkalkulationen in der wachsenden Fertigung an ihre Grenzen stoßen

Die meisten Beiträge zu diesem Thema listen Symptome auf: Bestände, die nicht stimmen, ein Report, der zwei Tage Vorlauf braucht, eine einzelne Person, die als Einzige die Logik der Stammdatei versteht. Das ist alles zutreffend, erklärt aber nicht, warum das Problem gerade jetzt auftritt und nicht schon früher.

Die eigentliche Antwort liegt in der Architektur. Eine Tabellenkalkulation ist für eine Person gebaut, die ein Problem zu einem Zeitpunkt modelliert. Fertigung mit wachsender Komplexität ist weder einbenutzerfähig noch flach strukturiert. Sobald man diesen Widerspruch versteht, wird auch klar, wann genau das System kippt und nicht erst, dass es kippt.

Die Annahme, dass nur einer gleichzeitig arbeitet

Excel wurde für individuelle Finanzmodellierung entwickelt. Es gibt keine echte gleichzeitige Bearbeitung, keine Sperrmechanismen, keine Möglichkeit zu wissen, dass eine Zahl vor drei Minuten von jemand anderem geändert wurde. Solange eine Person die Datei besitzt, ist das kein Problem. Es wird zum Problem, sobald Vertrieb, Lager, Fertigung und Buchhaltung in derselben Schicht auf dieselben Zahlen zugreifen müssen.

Die Folge ist vorhersehbar. Die Datei wird kopiert, dann noch einmal mit leicht anderem Namen. Nach ein paar Monaten kursieren vier Versionen, jede für jemanden die eigene Wahrheit, und die Frage, welche Zahl stimmt, kostet echte Besprechungszeit. Das ist kein Schulungsproblem. Es ist die Folge davon, ein Einzelbenutzer-Werkzeug mit einem Mehrbenutzer-Betrieb zu betreiben.

Warum die Struktur ein reales Produkt nicht abbilden kann

Das native Format einer Tabelle ist eine flache Liste. Das funktioniert für ein Produkt mit zehn Teilen ohne Baugruppen. Es funktioniert nicht mehr, sobald ein Endprodukt aus Unterbaugruppen besteht, die wiederum aus kleineren Komponenten bestehen, was bei mehrstufiger Fertigung der Normalfall ist, nicht die Ausnahme.

Um ein flaches Werkzeug ein baumartiges Produkt abbilden zu lassen, entstehen verschachtelte Formeln, oft dutzendweise, um den tatsächlichen Bedarf für eine Losgröße unter Berücksichtigung gemeinsam genutzter Komponenten über mehrere Produkte hinweg zu berechnen. Das hält, bis jemand ein neues Produkt hinzufügt oder die falsche Zelle bearbeitet. Dann bricht die Berechnung, meist ohne Fehlermeldung, sondern mit einer plausibel aussehenden falschen Zahl.

Der Punkt, an dem Konstruktion und Fertigung auseinanderlaufen

Der teuerste Fehler ist keine kaputte Formel. Es ist eine Versionslücke. Ein Konstrukteur ersetzt ein abgekündigtes Bauteil in der Zeichnung. In einem tabellenbasierten Betrieb lebt diese Änderung in einer Datei, auf einem Rechner, bis sie manuell weitergegeben wird. Der Einkauf bestellt weiter das alte Teil. Die Fertigung baut nach einem zwei Wochen alten Ausdruck. Niemand hat etwas falsch gemacht, es gab schlicht keinen Mechanismus, der die Änderung durchsetzt.

Das Ergebnis zeigt sich als Ausschuss, Nacharbeit und verpasste Liefertermine. In der Fachliteratur wird häufig ein zweistelliger Prozentanteil der gesamten Betriebskosten auf Spezifikations- und Prozessfehler dieser Art zurückgeführt. Der Grund liegt selten in Nachlässigkeit. Meist erzwang schlicht nichts, dass eine Version verbindlich blieb.

Warum das nicht neun Monate Einführungszeit rechtfertigt

Im deutschsprachigen Mittelstand gilt eine ERP-Einführung mit neun bis achtzehn Monaten Laufzeit fast als Standard, oft begründet mit tiefem Customizing und regulatorischer Sorgfalt. Für viele Konzernprozesse ist das gerechtfertigt. Für einen Fertigungsbetrieb mit fünfzig bis zweihundert Mitarbeitenden ist es häufig eine Folge davon, dass die Software zuerst an allgemeine Prozesse angepasst und erst danach auf die eigene Fertigungslogik zugeschnitten wird.

Eine Plattform, die mehrstufige Stücklisten, Fertigungsaufträge und Bedarfsrechnung von Grund auf für Fertigung gebaut hat statt nachträglich angepasst, muss diesen Umweg nicht gehen. Das ist kein Argument gegen Sorgfalt bei der Einführung. Es ist ein Argument dafür, dass die Dauer der Einführung eher von der Architektur der Software abhängt als von der Komplexität des eigenen Betriebs.

Was das für die Systemwahl bedeutet

Keiner dieser Punkte ist ein Argument gegen Excel als Werkzeug. Es ist ein Argument gegen Excel als führendes System für einen Betrieb, der über die Annahmen eines Einzelbenutzer-Flachdatei-Werkzeugs hinausgewachsen ist. Die praktische Testfrage ist einfach: Leben die Produktionsdaten noch in einer Datei, die eine Person versteht, oder in einem System, das für die tatsächliche Größe des Betriebs gebaut wurde.

In der eigenen Arbeit an den Produktionsmodulen für Fertiger mit gemischter Stück- und Prozessproduktion bei Bimp zeigt sich dieser Punkt meist genau dann, wenn jemand eine Kennzahl braucht, die zwei Abteilungen betrifft, und zwei Tage darauf wartet.