40 Jahre Bulli, 40 Jahre COMOS — der gleiche Job

Es gibt ein Wort, das ich von Bulli-Besitzern gelernt habe und seitdem in jedem zweiten Industriekunden-Workshop einbaue: Substanz. Substanz heißt: Da ist was Tragendes. Da ist ein Rahmen, der seit drei Jahrzehnten hält. Da sind Bleche, die noch original sind. Da ist ein Motor, der nicht spritziger geworden ist, aber auch nicht schwächer. Substanz ist das, was geblieben ist, weil es ordentlich gemacht war. Substanz ist nicht „neu", aber sie ist auch nicht „verschlissen". Sie ist die Grundlage, auf der weitergebaut werden kann.

In der Industriesoftware gibt es genau dasselbe — nur dass es da niemand so nennt. Eine COMOS-Datenbank, die seit 1998 läuft, ist Substanz. Eine Wartungsplaner-Anwendung, die drei Eigentümerwechsel überlebt hat, ist Substanz. Ein gewachsenes Berechtigungskonzept, das sechs Werke und vier Sprachen abbildet, ist Substanz. All das hat einen Wert, den man auf keiner Bilanz sieht — und den man in jedem Modernisierungsprojekt zu unterschätzen droht.

Was ich auf der Hebebühne gelernt habe

Beim T3 funktioniert Substanzpflege so: Du gehst einmal im Jahr durch. Du schaust dir die kritischen Stellen an — Schweller, Radhäuser, hinterer Tankträger, Längsträger. Du suchst nicht nach Problemen, du suchst nach Entwicklungen. Wo wird Lack dünner? Wo ist eine kleine Blase? Wo riecht es ungewöhnlich? Du dokumentierst, was du siehst. Im nächsten Jahr vergleichst du. Dinge, die du dieses Jahr noch mit Pinsel und Hohlraumwachs erwischst, kosten in fünf Jahren ein Bodenblech. Dinge, die du in fünf Jahren noch mit einem Bodenblech löst, kosten in zehn Jahren den Rahmen.

Niemand macht in der Industrie-IT diese jährliche Hebebühnen-Runde. Es gibt Audits, ja — die sind aber meistens auf Compliance ausgerichtet, nicht auf Substanz. Es gibt Health Checks, ja — die sind aber meistens vom Hersteller, der gleich auch die Modernisierung anbieten will. Was fehlt, ist die unaufgeregte Inspektion: Wo wird gerade ein Problem dünner? Wo riecht etwas ungewöhnlich?

Drei Praktiken, die ich aus der Werkstatt in die Beratung übernommen habe

1. Die jährliche Bestandsaufnahme.

Einmal pro Jahr setze ich mich mit dem Verantwortlichen für ein System für zwei Stunden hin — nicht in einen Workshop, nicht in ein Audit, sondern in eine ruhige Bestandsaufnahme. Was lief gut? Was war ärgerlich? Welche Hotfixes mussten her? Welche Dokumentation ist veraltet? Welche Kollegen sind verschwunden, die mal die einzigen waren, die etwas verstanden? Das ist die Hebebühne. Sie dauert zwei Stunden. Sie verhindert vierwöchige Krisensitzungen.

2. Das Substanz-Inventar.

Ich führe für jede Anlage, jede Plattform, jedes System eine kleine Liste. Was ist tragend? Was ist auswechselbar? Was ist kosmetisch? Diese Unterscheidung klingt banal, sie ist es nicht. Wenn ich weiß, dass ein Customizing-Skript tragend ist, behandle ich es anders, als wenn es kosmetisch ist. Wenn ich weiß, dass eine Schnittstelle auswechselbar ist, kann ich sie ruhig irgendwann ersetzen, ohne in Panik zu verfallen. Die meisten Migrationsdramen entstehen, weil niemand diese Unterscheidung gemacht hat — und dann beim Umbau plötzlich der Rahmen mitgeschnitten wird.

3. Die ehrliche Reparatur, nicht die zeigbare.

In der Werkstatt gibt es zwei Arten von Arbeit: die, die man sieht (frischer Lack, neue Stoßstange) und die, die man fühlt (kein Klappern, keine Vibration). Beide sind legitim, aber sie haben unterschiedliche Adressaten. In der IT genauso: Ein neues Dashboard ist zeigbar — eine sauber laufende nächtliche Batch-Verarbeitung ist fühlbar. Beide brauchen Aufmerksamkeit. Aber die zeigbaren Sachen bekommen sie ohnehin. Mein Job als Berater ist oft, dem Vorstand zu erklären, warum auch die fühlbaren Sachen Geld kosten dürfen.

Die Versuchung des großen Wurfs

Beim T3 ist die Versuchung manchmal: alles neu lackieren, Innenraum komplett tauschen, Motor frisch revidiert, alle Achsen überholt — und am Ende hat man einen Bus, der aussieht wie neu und sich anfühlt wie eine Restauration, die man nie wieder anfassen will, weil sie 40.000 Euro gekostet hat. Die meisten T3-Veteranen raten davon ab. Sie raten zu Etappen. Erst das Dach, dann die Schweller, dann der Motor, dann die Sitze. Jede Etappe ist abgeschlossen, fahrbar, lebenstauglich. Das Ergebnis sieht weniger glänzend aus, aber es läuft die ganze Zeit, und es ist bezahlt aus laufenden Mitteln statt aus einem Kredit.

In der Industriesoftware ist die Versuchung des großen Wurfs noch verführerischer, weil sie auf einer Folie schöner aussieht. „Wir lösen das alte ERP ab und führen gleichzeitig ein neues MES, eine neue PLM-Plattform und ein neues Wartungssystem ein. Drei Jahre Projekt, neunstellige Investition, am Ende sind wir digital." Auf dem Papier funktioniert das. In der Realität sind das die Projekte, von denen man später nie wieder spricht — nicht weil sie schiefgehen, sondern weil sie irgendwann unter einer neuen Geschäftsführung still entsorgt werden.

Die langweilige Migration

Ich habe in den letzten Jahren eine Reihe von COMOS-Migrationen begleitet. Die besten waren die langweiligsten. Vorbereitung mit Testlauf. Testlauf, Erkenntnis, Anpassung. Zweiter Testlauf an einem ruhigen Wochenende. Produktivumstellung an einem angenehmen Dienstag, gegen zwei Uhr morgens, mit halbiertem Team und vorbereiteter Rollback-Strategie. Donnerstag stand das System, Freitag liefen die ersten produktiven Berichte, am Montag drauf sprach niemand mehr davon.

Das ist Substanzpflege auf Software-Niveau. Kein „Big Bang", kein PR-Termin, kein „digitale Transformation"-Schild im Foyer. Einfach: Etwas Tragendes wurde unter Aufsicht von einem Zustand in den nächsten überführt. Das System läuft weiter — nur jetzt auf einer Datenbank, die noch zehn Jahre Support hat. Genau wie beim T3, dem du gerade die hinteren Längsträger gewechselt hast. Du erkennst ihn nicht beim Hingucken. Du erkennst ihn beim Fahren — er fühlt sich an wie früher, nur jünger.

Was bleibt

Ich glaube, das ist die ehrlichste Definition von Modernisierung, die ich kenne: Etwas, das funktioniert, so überführen, dass es noch lange funktioniert — ohne die Substanz zu verlieren, die es funktionieren ließ. Das gilt für Diesel-Motoren. Das gilt für COMOS-Datenbanken. Das gilt vermutlich für die meisten Dinge, in die jemand mal genug Arbeit gesteckt hat, dass sie es wert wären, nicht weggeworfen zu werden.

Wenn ich einen einzigen Satz mitgeben dürfte, dann diesen: Schau das System einmal im Jahr von unten an, bevor du eine Roadmap schreibst. Die meisten Roadmaps wären andere, wenn das passiert wäre.