Es ist doch nur eine einfache Neuentwicklung — Eine Geschichte von Schätzungen, Egos und schließlichem Erfolg

Das Unternehmen, das die Zeit formte

Hartmann & Söhne wurde 1998 als klassisches deutsches Systemhaus gegründet — ein Software-Unternehmen, das eine bestimmte Branche bediente. Ihre Nische: Konfiguration und Auftragsabwicklung für spezialisierte Industriemaschinen. Wenn ein Hersteller eine komplexe Sondermaschine mit Hunderten konfigurierbarer Optionen, Preisregeln und technischen Einschränkungen anbieten musste, erledigte das die Software von Hartmann.

Die Anwendung namens MaschinenKonfigurator wurde zum Standard in ihrem Markt. Entwickelt in Borland Delphi mit einer lokalen SQL-Server-Datenbank lief sie beim Kunden vor Ort. Die Software akkumulierte zwei Jahrzehnte an Branchenwissen: komplexe Preisalgorithmen, Compliance-Regeln für verschiedene Exportmärkte, Integration mit CAD-Systemen und die eigenartige Logik der Konfiguration von Industriemaschinen.

Klaus Hartmann, der Sohn des Gründers und jetziger Geschäftsführer, stand 2024 vor einer unbequemen Realität. Das Delphi-Ökosystem war geschrumpft. Entwickler zu finden, die Object Pascal verstanden, wurde immer schwieriger. Die beste Entwicklerin, die seit 2003 dabei war, näherte sich dem Ruhestand. Kunden fragten nach Cloud-Zugang, Mehrstandort-Nutzung und Integration mit modernen ERP-Systemen.

Die Entscheidung schien offensichtlich: Neuentwicklung als moderne SaaS-Anwendung. Was folgte, war weit komplizierter, als irgendjemand ahnte.

Die anfängliche Begeisterung

Die Geschäftsführung versammelte sich zu dem, was Klaus einen „Transformations-Kickoff” nannte. Die wichtigsten Technologieentscheidungen waren bereits getroffen: Java mit Spring Boot für das Backend, ein modernes JavaScript-Framework für das Frontend, PostgreSQL für die Datenbank, Kubernetes auf AWS für das Hosting.

„Wir wissen genau, was die Software leisten muss”, sagte Klaus. „Wir haben zwanzig Jahre funktionierenden Code. Wir müssen ihn nur in moderne Technologie übersetzen.”

Thomas, der Entwicklungsleiter, nickte vorsichtig. „Die gesamte Geschäftslogik ist vorhanden. Wir haben das meiste über die Jahre dokumentiert.”

Maria, die Produktmanagerin, die drei Monate zuvor von einem größeren Software-Unternehmen gekommen war, meldete sich. „Wie lange hat es gedauert, das ursprüngliche System zu entwickeln?”

Thomas rechnete nach. „Die erste Version wurde nach achtzehn Monaten ausgeliefert. Aber wir haben zwanzig Jahre lang kontinuierlich Funktionen ergänzt.”

„Dann entwickeln wir also nicht wirklich achtzehn Monate Arbeit neu”, stellte Maria fest. „Wir entwickeln zwanzig Jahre angesammelte Funktionalität neu.”

Der Raum wurde still. Klaus blickte zu Thomas, der seinem Blick auswich. In der Ecke verschränkte Heike — die erfahrene Delphi-Entwicklerin, die seit 2003 dabei war — die Arme und sagte nichts. Sie hatte schon früher Vorschläge zur Neuentwicklung erlebt. Keiner war je umgesetzt worden. Diesmal fühlte es sich anders an — und nicht auf gute Weise.

Die Schätzungsfalle

Die ersten Planungssitzungen offenbarten ein bekanntes Muster. Das Entwicklungsteam, nun verstärkt durch Auftragnehmer mit Java- und Spring-Boot-Erfahrung, begann die Neuentwicklung zu schätzen.

„Benutzerauthentifizierung und -autorisierung — zwei Wochen.”

„Einfacher Konfigurationsmotor — drei Monate.”

„Preisregeln — sechs Wochen.”

„CAD-Integration — vier Wochen.”

Die Schätzungen summierten sich zu einem angenehmen Achtzehn-Monats-Plan. Klaus genehmigte das Budget. Das Team begann zuversichtlich mit der Arbeit.

Drei Monate später war das Authentifizierungssystem fertig. Der einfache Konfigurationsmotor existierte, konnte aber die Sonderfälle nicht bewältigen, die den MaschinenKonfigurator wertvoll machten. Die Preisregeln, angeblich ein Sechs-Wochen-Aufwand, hatten zwei Monate verbraucht und deckten vielleicht dreißig Prozent der tatsächlichen Komplexität ab.

Thomas berief eine Krisensitzung ein. „Wir übersetzen keinen Code. Wir entdecken wieder, warum der Code überhaupt so geschrieben wurde.”

Martin, einer der Java-Auftragnehmer, konterte. „Wenn die ursprünglichen Entwickler ihre Arbeit ordentlich dokumentiert hätten, müssten wir nicht raten.”

Die Temperatur im Raum sank. Heike, die gerade einen Ausdruck durchsah, blickte auf. „Wir haben alles dokumentiert, was damals wichtig erschien. Zwanzig Jahre von allem ist eine Menge Dokumentation. Soll ich Ihnen zeigen, wo sie ist, oder möchten Sie lieber weiter klagen?”

Klaus intervenierte, bevor die Situation eskalierte. Aber der Schaden war sichtbar. Die neuen Entwickler sahen das Alt-Team als Hindernisse. Das Alt-Team sah die neuen Entwickler als arrogante Neulinge, die nicht verstanden, was sie demontierten.

Das Wissensproblem

Der Delphi-Code enthielt zwanzig Jahre an Entscheidungen. Einige waren dokumentiert. Die meisten existierten nur im Code selbst — oder in der Erinnerung von Entwicklern, die längst weitergezogen waren.

Heike wurde zur wertvollsten Ressource des Projekts — obwohl es Wochen dauerte, bis das neue Team das erkannte. Sie konnte einen Block Object Pascal betrachten und erklären: „Das behandelt den Fall, wenn ein Kunde eine Maschine für den japanischen Markt konfiguriert, aber deutsche Sicherheitszertifizierungen für den Re-Export haben möchte. Das haben wir 2011 hinzugefügt, nachdem wir einen wichtigen Auftrag verloren hatten.”

Die neuen Java-Entwickler implementierten eine Funktion, demonstrierten sie Heike und sahen, wie sie den Kopf schüttelte. „Das funktioniert für Standardkonfigurationen. Aber was ist mit Kombinationseinschränkungen? Was ist mit alten Preisvereinbarungen? Was ist mit den Maschinen, die vor unserer Änderung des Komponentennummerierungsschemas 2015 konfiguriert wurden?”

Jede „einfache” Funktion hatte Verästelungen in Sonderfälle, die erst sichtbar wurden, wenn jemand versuchte, das System so zu nutzen, wie es echte Kunden taten.

Der Kurswechsel: Parallelbetrieb

Sechs Monate nach Projektbeginn stand Klaus vor einer schwierigen Entscheidung. Das neue System hatte die Hälfte des Budgets verbraucht, aber vielleicht zwanzig Prozent der benötigten Funktionalität geliefert. Den gleichen Ansatz fortzusetzen bedeutete, entweder das Budget drastisch zu erhöhen oder ein System auszuliefern, das das Original nicht ersetzen konnte.

Maria schlug eine andere Strategie vor. „Was, wenn wir nicht versuchen, den MaschinenKonfigurator auf einen Schlag zu ersetzen? Was, wenn wir beide Systeme parallel betreiben und Funktion für Funktion migrieren?”

Der Ansatz hatte Kompromisse. Zwei Systeme zu betreiben erhöhte die operative Komplexität. Kunden müssten während der Übergangszeit mit beiden arbeiten. Aber er bot etwas, das dem ursprünglichen Plan fehlte: die Möglichkeit zu lernen und anzupassen, ohne alles auf ein einziges Ergebnis zu setzen.

Das Team strukturierte das Projekt um drei Prinzipien herum neu:

Funktionsmigration statt Code-Übersetzung. Statt Delphi-Module nach Java zu übersetzen, identifizierten sie diskrete Funktionen, die Kunden tatsächlich nutzten. Jede Funktion wurde ein eigenständiger Teil des neuen Systems.

Produktivvalidierung bei jedem Schritt. Jede Funktion ging in Produktion, sobald sie fertig war, und lief neben dem Altsystem. Kunden konnten wählen, welches System sie für diese Funktion nutzen wollten.

Kontinuierliche Lernzyklen. Jede Funktionsbereitstellung umfasste Telemetrie. Nutzungsmuster, Fehler und Leistungskennzahlen leiteten die Priorisierung.

Der erste echte Erfolg

Das Team wählte die Preisberechnungen als erstes Ziel. Die Preisberechnung war komplex, aber relativ eigenständig — sie verarbeitete Konfigurationsdaten und erzeugte Angebote ohne tiefe Integration in andere Teile des Systems.

Der Aufbau der Preis-Engine dauerte drei Monate, nicht sechs Wochen. Aber diesmal hatte das Team Heike, die jeden Algorithmus prüfte, Ergebnisse mit dem Delphi-System verglich und Sonderfälle identifizierte, bevor Kunden sie entdeckten.

Die neue Preis-Engine wurde als optionale Funktion eingeführt. Kunden konnten Angebote mit beiden Systemen erstellen. Telemetrie verfolgte die Genauigkeit — produzierte die neue Engine dieselben Ergebnisse wie die alte?

In der ersten Woche zeigten sich drei Sonderfälle, die das Team übersehen hatte. In der zweiten Woche waren sie behoben. In der vierten Woche waren die meisten Kunden dauerhaft zur neuen Engine gewechselt. Sie war schneller, von jedem Browser aus zugänglich und lieferte identische Ergebnisse.

Wichtiger noch: Das Team hatte etwas gelernt: Das neue System musste nicht jede Funktion des alten replizieren. Es musste die Funktionen replizieren, die Kunden tatsächlich nutzten.

Die Herausforderung der Konfigurations-Engine

Die Preisberechnung war die Aufwärmübung. Die Konfigurations-Engine — das Herz des MaschinenKonfigurators — stellte eine Herausforderung anderer Größenordnung dar.

Die Delphi-Konfigurations-Engine codierte Regeln, die sich über zwanzig Jahre entwickelt hatten. Welche Komponenten mit welchen Grundmodulen kompatibel waren. Welche regulatorischen Anforderungen in verschiedenen Märkten galten. Wie kundenspezifische Preisvereinbarungen Standardregeln modifizierten. Die Abhängigkeiten bildeten ein Netz, das niemand vollständig verstand.

Thomas schlug einen unkonventionellen Ansatz vor: „Wir werden die Konfigurations-Engine nicht nachbauen. Wir werden eine neue bauen, die von der alten lernt.”

Das Team baute die neue Konfigurations-Engine mit expliziten Regeldefinitionen — klar, testbar, dokumentiert. Aber jede Konfiguration, die die neue Engine erzeugte, wurde auch durch das alte Delphi-System geschickt. Abweichungen lösten Untersuchungen aus.

Dieser „Schattenmodus”-Ansatz erfüllte mehrere Zwecke. Er validierte die Korrektheit. Er legte undokumentierte Regeln offen, wenn die Systeme sich unterschieden. Und er baute Vertrauen im Team auf, dass das neue System tatsächlich funktionierte.

Die Konfigurations-Engine dauerte acht Monate statt der ursprünglich geschätzten drei. Aber als sie eingeführt wurde, wurde sie mit Zuversicht eingeführt.

Die menschliche Dimension

Technische Herausforderungen waren nicht die einzigen Hindernisse. Die Transformation belastete die Organisation auf Weisen, die Klaus nicht vorhergesehen hatte — und brachte sie fast zum Zerbrechen.

Die erste große Krise kam drei Monate nach dem Wechsel zum Parallelbetrieb. Jürgen, ein Delphi-Entwickler, der seit zwölf Jahren im Unternehmen war, bat um ein persönliches Gespräch mit Klaus.

„Ich kann das nicht mehr”, sagte Jürgen. Seine Stimme war ruhig, aber Klaus bemerkte, dass seine Hände zitterten. „Jeden Tag komme ich herein und sehe, wie Auftragnehmer Code zerlegen, an dem ich jahrelang gearbeitet habe. Sie fragen nicht, warum die Dinge so funktionieren, wie sie funktionieren. Sie schreiben es einfach um und geben uns dann die Schuld, wenn es kaputtgeht.”

„Wir brauchen dich, Jürgen. Du kennst das Preismodul besser als jeder andere.”

„Das ist ja das Problem.” Jürgens Fassung bröckelte leicht. „Ich bin keine Ressource, die man ausbeuten kann. Ich bin ein Mensch. Und ich habe es satt, wie ein Museumsstück behandelt zu werden, das jeder besuchen muss, bevor er seine richtige Arbeit machen kann.”

Klaus versprach Änderungen. Jürgen willigte ein zu bleiben — vorerst.

Zwei Wochen später ging Martin, einer der Java-Auftragnehmer, zu weit. In einer Teamsitzung verspottete er offen einen Abschnitt Delphi-Code, der auf dem Bildschirm gezeigt wurde. „Wer hat diesen Spaghetti-Code geschrieben? Deshalb müssen Altsysteme sterben.”

Jürgen hatte diesen Code geschrieben. Er stand langsam auf, blass im Gesicht. „Den habe ich geschrieben. 2014. Als wir drei Tage Zeit hatten, einen kritischen Fehler für unseren größten Kunden zu beheben. Elegant ist er nicht, aber er funktioniert seit zehn Jahren ohne einen einzigen Ausfall.” Seine Stimme brach bei den letzten Worten. Er verließ den Raum.

Die Stille, die folgte, war verheerend. Lisa, eine Junior-Entwicklerin, die Notizen gemacht hatte, begann zu weinen. Sie wusste nicht genau warum — die angestaute Spannung war einfach zu viel geworden.

Klaus fand Jürgen auf dem Parkplatz, in seinem Auto sitzend. Er würde nicht wieder reingehen.

„Es ist vorbei”, sagte Jürgen. „Ich werde meine Kündigungsfrist einhalten, aber ich werde an keinen Besprechungen mehr mit diesen Leuten teilnehmen.”

Nichts, was Klaus sagte, änderte seine Meinung. Jürgen ging vier Wochen später und nahm unersetzliches Wissen über die komplexesten Algorithmen der Preis-Engine mit. Das Team verbrachte die folgenden zwei Monate damit, Code per Reverse Engineering zu entschlüsseln, den er an einem Nachmittag hätte erklären können.

Was Martin betraf — Klaus entließ ihn am nächsten Tag.

„Sie können mich nicht für eine Meinung entlassen”, protestierte Martin.

„Ich entlasse Sie, weil Sie ein feindliches Umfeld geschaffen haben, das uns einen Mitarbeiter mit zwölf Jahren Betriebszugehörigkeit gekostet hat”, antwortete Klaus. „Ihre Meinung hat in fünf Sekunden mehr Wert zerstört, als Sie in fünf Monaten geschaffen haben. Räumen Sie Ihren Schreibtisch.”

Martin drohte mit rechtlichen Schritten. Es kam nichts dabei heraus. Aber die Nachricht verbreitete sich schnell unter den verbliebenen Auftragnehmern: Die alten Regeln galten nicht mehr.

Inzwischen erschien Heike nicht mehr zu den Integrationsbesprechungen. Als Klaus fragte warum, war sie direkt: „Jedes Mal, wenn ich etwas erkläre, verdreht jemand die Augen. Ich schütze dieses System seit zwanzig Jahren. Wenn sie meine Hilfe nicht wollen, warte ich, bis sie darum bitten.”

Klaus sah ein personelles Problem. Und wie viele Führungskräfte, die vor personellen Problemen stehen, griff er zu einer bekannten Lösung: externe Hilfe.

Die Berater

Die Unternehmensberatung kam mit besten Empfehlungen. Sie waren spezialisiert auf „organisatorische Transformation” und „Change Management”. Ihr leitender Berater, Dr. Berger, erschien mit einem Team von drei Junior-Analysten und einer Methodik namens „Adaptives Übergangs-Framework”.

„Technische Projekte scheitern an Menschen, nicht an Technologie”, erklärte Dr. Berger in seiner Einführungspräsentation. „Wir werden Ihre Stakeholder aufeinander abstimmen, klare Kommunikationsprotokolle etablieren und Führungsstrukturen schaffen, die Ergebnisse liefern.”

Thomas war skeptisch. „Hat jemand in Ihrem Team schon mal Software entwickelt?”

Dr. Berger lächelte geduldig. „Wir müssen die technischen Details nicht verstehen. Menschliche Dynamiken sind universell. Widerstand gegen Veränderung folgt vorhersehbaren Mustern, unabhängig von der Branche.”

Sechs Wochen lang führte das Beraterteam Interviews, moderierte Workshops und produzierte einen 47-seitigen Bericht. Sie identifizierten „Kommunikationslücken”, „unklare Rollendefinitionen” und „unzureichende Veränderungsbereitschaft”. Ihre Empfehlungen umfassten eine neue Führungsstruktur, wöchentliche Abstimmungsmeetings und eine Rolle als „Transformations-Champion”.

Die wöchentlichen Abstimmungsmeetings fügten jedem Terminkalender drei Stunden hinzu. Die Führungsstruktur schuf Genehmigungsengpässe, die Entscheidungen verlangsamten. Der Transformations-Champion — ein Junior-Manager aus dem Vertrieb — hatte keine Ahnung, wovon die Entwickler sprachen, und hörte nach zwei Wochen stillschweigend auf, teilzunehmen.

Heike besuchte eine von Dr. Bergers „Integrationssitzungen für Alt-System-Stakeholder”. Sie ging nach zwanzig Minuten. Als Klaus fragte, was passiert war, sagte sie: „Er bat mich, meine ‘emotionale Beziehung’ zum Code zu beschreiben. Ich sagte ihm, meine Beziehung zum Code sei, dass ich weiß, wie er funktioniert, und sie nicht. Er sagte, ich zeige ‘typische Abwehrhaltung von veränderungsresistenten Persönlichkeiten’.”

An diesem Abend schickte Heike Klaus eine E-Mail mit ihrer Kündigung im Anhang. „Ich habe diesem Unternehmen zwanzig Jahre gegeben”, schrieb sie. „Ich werde meine letzten Berufsjahre nicht damit verbringen, von Leuten psychoanalysiert zu werden, die kein Hallo-Welt-Programm kompilieren könnten.”

Klaus rief sie sofort an. Es dauerte fünfundvierzig Minuten, sie davon zu überzeugen, die Kündigung aufzuschieben. „Gib mir eine Woche”, sagte er. „Wenn sich nichts ändert, akzeptiere ich sie ohne Widerspruch.”

Thomas war in der nächsten Führungsbesprechung direkter. „Klaus, diese Berater verbrennen €15.000 pro Woche und machen alles schlimmer. Die Entwickler, die gerade angefangen hatten zusammenzuarbeiten, sitzen jetzt in Besprechungen und zeichnen Stakeholder-Maps. Währenddessen wird kein Code geschrieben. Und gestern Abend hätten wir fast Heike verloren — die einzige Person, die dieses Projekt tatsächlich fertigstellen kann.”

Dr. Berger verteidigte seinen Ansatz. „Transformation ist unbequem. Widerstand zeigt, dass wir die eigentlichen Themen angehen.”

„Widerstand zeigt, dass Menschen, die Software entwickeln, es nicht genießen, von Leuten psychoanalysiert zu werden, die noch nie Software entwickelt haben”, erwiderte Thomas.

Der Wendepunkt kam, als die Berater „temporäre Rollenrotation” zum Aufbau von Empathie empfahlen — mit dem Vorschlag, dass Heike zwei Wochen mit dem Java-Team arbeiten solle, während ein Java-Entwickler ihre Delphi-Arbeit „begleiten” würde.

Heikes Antwort war eisig. „Sie wollen, dass jemand, der kein Object Pascal kennt, zwanzig Jahre Arbeit begleitet, die er nicht lesen kann? Und dass ich Java schreibe, das ich noch nie verwendet habe, während das Projekt in Flammen steht? Das ist keine Teambuilding-Übung. Das ist ein Unternehmen, das kurz davor steht, sein einziges Produkt zu verlieren.”

Klaus sah endlich, was Thomas und Heike ihm seit Wochen sagten. Die Berater verstanden generische Organisationsdynamiken, aber sie hatten keine Ahnung, was Software-Entwicklung wirklich erforderte. Ihre Frameworks behandelten jeden Widerstand als emotional — ohne je in Betracht zu ziehen, dass mancher Widerstand rationale Ablehnung von Menschen sein könnte, die das Problem besser verstanden als die Berater.

Er beendete das Engagement. €90.000 ausgegeben, sechs Wochen verloren, und das Team zerstrittener als zuvor.

Klaus erkannte, dass er nach einer externen Lösung für ein internes Problem gesucht hatte. Die Reibung ging nicht um „Veränderungsbereitschaft” oder „Stakeholder-Abstimmung”. Es ging um Respekt — und Respekt lässt sich nicht in einem Workshop herbeiführen.

Er berief eine Besprechung ein — nicht über Code, sondern über Kultur. Keine Berater. Keine Frameworks. Nur Ehrlichkeit. „Heike ist nicht hier, um Wissen zu übergeben und zu gehen. Sie ist hier, um uns zu helfen, etwas Besseres zu bauen als das, was wir hatten. Wenn das neue System fertig ist, wird sie es mitgestaltet haben. Wer damit nicht arbeiten kann, soll es mir jetzt sagen.”

Der Raum war still.

„Und Heike — ich brauche dich in jeder Integrationsbesprechung. Nicht als jemand, der verhört wird, sondern als die technische Autorität dafür, was dieses System wirklich tut. Wenn jemand die Augen verdreht, will ich es wissen.”

Heike nickte langsam. Es war das erste Mal, dass Klaus öffentlich ihre Rolle als wesentlich anerkannte — nicht als Übergangslösung.

Das Team strukturierte sich neu. Heike wurde technische Beraterin, die Designs vor der Implementierung prüfte. Alt-System-Entwickler arbeiteten paarweise mit neuen Entwicklern, jede Gruppe lehrte die andere. Zwei weitere Auftragnehmer gingen — sie wollten Projekte auf der grünen Wiese, keine archäologischen Expeditionen. Aber die, die blieben, begannen zu verstehen: Das Ziel war nicht „das alte System ersetzen”. Es war „die nächste Generation dessen bauen, was wir begonnen haben”.

Die Multi-Mandanten-Herausforderung

Der Betrieb beim Kunden vor Ort bedeutete, dass der MaschinenKonfigurator nie echte Mandantenfähigkeit brauchte. Jede Installation war isoliert. Kundendaten konnten nicht zwischen Installationen lecken, weil es nichts gab, wohin sie lecken konnten.

SaaS änderte alles. Mehrere Kunden würden sich Infrastruktur teilen. Ihre Konfigurationen, Preise und Geschäftsregeln brauchten vollständige Isolation bei gleichzeitiger Ausführung auf gemeinsamen Systemen.

„Das ist kein Feature”, bemerkte Maria. „Das ist eine fundamentale Architekturentscheidung, die alles beeinflusst.”

Das Team hatte bereits mehrere Funktionen unter der Annahme eines Einzelmandantenbetriebs gebaut. Die Nachrüstung der Mandantenfähigkeit würde erhebliche Überarbeitung erfordern.

Thomas entschied: „Wir stoppen die Feature-Entwicklung für sechs Wochen. Wir bauen das Fundament für Mandantenfähigkeit um, bevor wir weitermachen.”

Klaus widersprach heftig. „Sechs Wochen ohne sichtbaren Fortschritt? Der Vorstand stellt bereits Fragen. Ich habe ihnen gesagt, wir liegen im Plan.”

„Dann sagen Sie ihnen, dass wir nicht im Plan liegen”, antwortete Thomas. „Denn wenn wir auf diesem Fundament weiter bauen, werden wir in zwölf Monaten erklären, warum wir von vorne anfangen müssen. Schon wieder.”

Das Argument dauerte eine Stunde. Maria durchbrach schließlich den Stillstand: „Klaus, welches Gespräch wollen Sie mit dem Vorstand führen — ‘wir haben acht Wochen pausiert, um die Architektur zu korrigieren’ oder ‘wir haben achtzehn Monate damit verbracht, etwas zu bauen, das wir wegwerfen müssen’?”

Klaus genehmigte die Pause. Es war die schwierigste Entscheidung, die er seit Projektbeginn getroffen hatte.

Die Nachrüstung der Mandantenfähigkeit dauerte acht Wochen, nicht sechs. Sie betraf jede bereits gebaute Funktion.

Die Überarbeitung brachte die verbliebene Teammoral fast zum Zusammenbruch. Andreas, ein Senior-Java-Entwickler, der nach dem Exodus der Auftragnehmer festangestellt worden war, stellte Thomas im Flur zur Rede. „Sie sagen mir, dass die letzten vier Monate meiner Arbeit weggeworfen werden?”

„Refaktoriert, nicht weggeworfen.”

„Das ist Unternehmenssprech für weggeworfen.” Andreas zitterte sichtbar. „Ich bin mit meiner Familie hierhergezogen für diesen Job. Ich habe eine sichere Stelle in München aufgegeben. Und jetzt sagen Sie, meine Arbeit zählt nicht?”

Thomas verbrachte eine Stunde damit, Andreas zu beruhigen. Zwei andere Entwickler reagierten ähnlich — einer drohte, sofort zu kündigen, der andere sprach eine Woche lang überhaupt nicht mehr mit Thomas. Die Spannung war so groß, dass Maria begann, private Einzelgespräche zu führen, nur damit die Leute sich Luft machen konnten, ohne Angst haben zu müssen, gehört zu werden.

Thomas verbrachte in diesen Wochen Stunden damit zu erklären, dass das ursprüngliche Design nicht falsch war, nur unvollständig für Anforderungen, die erst später klar geworden waren. Einige Entwickler akzeptierten das. Andere vertrauten der Führung nie wieder vollständig.

Als die Nachrüstung abgeschlossen war, konnte das System auf Hunderte von Mandanten skalieren, ohne architektonische Änderungen. Wichtiger noch: Das Team hatte eine echte Krise gemeinsam überstanden. Aber die Narben blieben. Vertrauen, einmal gebrochen, baut sich langsam wieder auf, wenn überhaupt.

Den richtigen Auslieferungsrhythmus finden

Zu Beginn des Projekts waren Bereitstellungen große Ereignisse. Das Team sammelte Änderungen über Wochen, dann wurde in einer sorgfältig orchestrierten Veröffentlichung ausgeliefert. Jede Bereitstellung war stressig — so viel hatte sich geändert, dass Ausfälle unvorhersehbar waren.

Das Infrastrukturteam, geleitet von einem DevOps-Ingenieur namens Felix, investierte stark in Automatisierung. Kubernetes-Orchestrierung. Automatisierte Test-Pipelines. Feature-Toggles, die es erlaubten, Code bereitzustellen, ohne ihn zu aktivieren.

Allmählich erhöhte sich die Bereitstellungsfrequenz. Wöchentlich wurde täglich. Täglich wurde mehrmals täglich. Jede Bereitstellung war kleiner, risikoärmer, leichter zu diagnostizieren, wenn etwas schiefging.

Der psychologische Wandel war tiefgreifend. Entwickler dachten nicht mehr in Releases, sondern in kontinuierlicher Verbesserung. Eine Fehlerkorrektur konnte in Stunden in Produktion sein. Eine neue Funktion konnte schrittweise eingeführt werden, für einige Kunden aktiviert, bevor sie breit ausgerollt wurde.

Das Abschaltungsgespräch

Achtzehn Monate nach Projektbeginn — der ursprüngliche Zeitplan für die vollständige Ablösung — existierten etwa sechzig Prozent der Funktionalität des MaschinenKonfigurators in der neuen SaaS-Plattform. Aber diese sechzig Prozent deckten etwa neunzig Prozent der täglichen Kundennutzung ab.

Klaus musste entscheiden: beide Systeme unbegrenzt weiterbetreiben oder mit der Abschaltung der Alt-Anwendung beginnen.

„Einige Kunden werden sich wehren”, warnte der Vertriebsleiter Stefan. „Müller Maschinenbau ist seit fünfzehn Jahren bei uns. Sie haben sich schon dreimal über die neue Oberfläche beschwert.”

„Einige Funktionen, die wir nie nachgebaut haben, werden verschwinden”, warnte Thomas. „Es gibt Funktionen im Delphi-System, die zwei Kunden nutzen. Halten wir das ganze Altsystem für zwei Kunden am Laufen?”

Heike meldete sich zu Wort — etwas, das sie jetzt öfter tat. „Diese zwei Kunden zahlen uns zusammen €180.000 im Jahr. Einer von ihnen ist der Referenzkunde, den wir in jeder Vertriebspräsentation verwenden. Wenn wir ihnen sagen, dass ihr Workflow eingestellt wird, könnten wir sie verlieren.”

Der Raum spaltete sich. Der Vertrieb wollte jeden Kunden zufriedenstellen. Die Entwicklung wollte aufhören, zwei Systeme zu warten. Die Finanzabteilung wies darauf hin, dass der Betrieb paralleler Infrastruktur €8.000 im Monat kostete.

Das Team analysierte ausgiebig die Nutzungstelemetrie. Sie identifizierten Funktionen, die wirklich wichtig waren, versus solche, die nur existierten, weil niemand sie entfernt hatte. Sie sprachen mit jedem Kunden über tatsächliche Bedürfnisse versus theoretische Präferenzen.

Klaus traf die Entscheidung. „Wir bauen den Workflow für Müller Maschinenbau nach. Das sind drei Wochen Arbeit, und wir behalten unseren besten Referenzkunden. Die anderen Alt-Funktionen bekommen dokumentierte Alternativen und zwölf Monate Vorankündigung.”

Stefan vom Vertrieb war nicht zufrieden. „Was sage ich Kunden, die sich beschweren?”

„Sagen Sie ihnen die Wahrheit”, sagte Klaus. „Wir bauen etwas Besseres. Einige Dinge werden den Übergang nicht schaffen. Wir helfen ihnen bei der Anpassung.”

Der Abschaltungsplan gab den Kunden zwölf Monate Parallelbetrieb. Drei Kunden entschieden sich gegen die Migration und gingen schließlich. Zwei von ihnen hatten minimale Gebühren gezahlt und unverhältnismäßig viele Support-Ressourcen verbraucht. Der dritte, ein mittelständischer Hersteller, wechselte zu einem Wettbewerber — ein Verlust, der schmerzte, aber bestätigte, dass das Unternehmen nicht für jeden alles sein konnte.

Der Endzustand

Zweieinhalb Jahre nach Beginn der Transformation hatte Hartmann & Söhne ihre Reise abgeschlossen. Die neue Plattform — umbenannt in MachineConfigure, um den Übergang zu signalisieren — bediente alle bestehenden Kunden plus neue, die die alte Desktop-Anwendung nie in Betracht gezogen hätten.

Die Ergebnisse übertrafen die Erwartungen in einigen Bereichen und blieben in anderen dahinter zurück:

Leistung: Das neue System verarbeitete komplexe Konfigurationen in Sekunden statt Minuten. Kunden nannten dies wiederholt als die sichtbarste Verbesserung.

Zugänglichkeit: Teams an mehreren Standorten konnten nun an Konfigurationen zusammenarbeiten. Mobiler Zugriff ermöglichte Vertriebsmitarbeitern, Angebote vor Ort beim Kunden zu erstellen.

Integration: Moderne APIs ermöglichten Verbindungen zu ERP-Systemen, CAD-Plattformen und E-Commerce-Kanälen, die mit der alten Architektur unmöglich waren.

Funktionsparität: Etwa fünfundachtzig Prozent der Alt-Funktionen wurden übernommen. Die restlichen fünfzehn Prozent wurden entweder mit anderen Ansätzen neu gebaut oder vollständig eingestellt.

Zeitplan: Zweieinhalb Jahre statt achtzehn Monate. Das Projekt dauerte länger als die optimistische ursprüngliche Schätzung, aber deutlich kürzer, als ein vollständiger Parallelentwicklungsansatz erfordert hätte.

Kosten: Etwa das Doppelte des ursprünglichen Budgets — einschließlich €90.000 für Unternehmensberater, die alles verschlimmerten, Monate verlorener Produktivität durch die Wissenslücke nach Jürgens Weggang, und die Kosten der Entlassung von Martin, bevor Klaus akzeptierte, dass Respekt sich nicht in Workshops erzwingen lässt und Toxizität nicht toleriert werden kann. Teuer, aber die Alternative — ein zunehmend unwartbares Altsystem weiter zu pflegen — hätte auf Dauer mehr gekostet.

Erkenntnisse aus der Reise

Klaus, ein Jahr nach Abschluss über die Transformation nachdenkend, identifizierte Prinzipien, die anderen Organisationen mit ähnlichen Herausforderungen helfen könnten:

Das Wissen steckt in den Menschen, nicht im Code. Die Entwickler zu halten und zu respektieren, die das Altsystem gebaut hatten, erwies sich als wertvoller als jede Dokumentation. Heike entdeckte Probleme, die kein automatisierter Test finden konnte — aber erst nachdem das Team gelernt hatte, ihr zuzuhören. Jürgens Weggang wegen der gedankenlosen Spötterei eines Auftragnehmers kostete Monate an Reverse-Engineering-Zeit. Die Auftragnehmer, die das Wissen des Alt-Teams abtaten, waren die ersten, die gingen — oder vor die Tür gesetzt wurden. Die, die blieben, lernten Demut.

Generische Unternehmensberatung hilft bei technischen Transformationen selten. Die Berater, die „Stakeholder-Abstimmungs-Workshops” und „Veränderungsbereitschafts-Assessments” empfahlen, hatten noch nie Software ausgeliefert. Sie behandelten rationale technische Meinungsverschiedenheiten als emotionalen Widerstand. Die €90.000, die für Frameworks und Führungsstrukturen ausgegeben wurden, waren €90.000, die nicht für die Lösung echter Probleme ausgegeben wurden. Wenn Ihre Experten Ihnen sagen, dass etwas nicht funktionieren wird, ziehen Sie in Betracht, dass sie recht haben könnten.

Parallelbetrieb reduziert das Risiko dramatisch. Beide Systeme gleichzeitig zu betreiben ermöglichte Lernen und Anpassung. Die Möglichkeit, Ergebnisse zu vergleichen, baute Vertrauen auf, dass das neue System tatsächlich korrekt funktionierte.

Kleine, häufige Bereitstellungen ändern alles. Der Wechsel von Big-Bang-Releases zu kontinuierlicher Auslieferung transformierte die Beziehung des Teams zum Risiko. Kleine Änderungen waren leichter zu validieren und leichter zurückzurollen.

Mandantenfähigkeit ist kein Feature — sie ist ein Fundament. Der Versuch, Mandantenfähigkeit nachzurüsten, nachdem Einzelmandanten-Funktionen gebaut wurden, verschwendete Monate. Architekturentscheidungen müssen früh getroffen werden, auch wenn Features dringender erscheinen.

Nicht jedes Feature verdient es zu überleben. Altsysteme akkumulieren Funktionen, die ihre Nützlichkeit überdauern. Transformation ist eine Gelegenheit zum Beschneiden, nicht nur zum Portieren.

Der ursprüngliche Zeitplan ist immer falsch. Nicht weil das Team nicht schätzen kann, sondern weil das Team nicht wissen kann, was es nicht weiß. Erhebliche Puffer einzubauen ist kein Pessimismus — es ist Realismus.

Die Geschichte geht weiter

Die Transformation von Hartmann & Söhne war kein Ende. Sie war ein Übergang zu einer neuen Arbeitsweise. Das SaaS-Modell brachte neue Herausforderungen: Verfügbarkeit über mehrere Kunden hinweg überwachen, Abonnementabrechnungen verwalten, Anforderungen an Datenresidenz für internationale Kunden handhaben.

Aber die Organisation hatte auch neue Fähigkeiten aufgebaut. Sie konnten jetzt täglich statt jährlich Verbesserungen ausliefern. Sie konnten beobachten, wie Kunden das System tatsächlich nutzten, nicht nur, wie sie ihre Nutzung beschrieben. Sie konnten mit Funktionen experimentieren, bevor sie sich voll darauf festlegten.

Der Markt für spezialisierte Maschinen brauchte immer noch ausgefeilte Konfigurationswerkzeuge. Hartmann & Söhne lieferten sie immer noch. Die Technologie hatte sich vollständig verändert. Das Wertversprechen blieb dasselbe.

Heike ging sechs Monate nach dem Start der neuen Plattform in den Ruhestand — zu ihren eigenen Bedingungen, nachdem sie das System mitgestaltet hatte, das ihre Arbeit weiterführen würde. Auf ihrer Abschiedsfeier sagte sie zu Klaus: „Ich war kurz davor zu kündigen, als Martin sagte, meine Dokumentation sei wertlos. Ich bin froh, dass ich geblieben bin.”

„Ich auch”, antwortete Klaus. „Wir hätten es ohne dich nicht geschafft.”

„Nein”, stimmte sie zu. „Hättet ihr nicht. Erinnere dich daran, wenn dir das nächste Mal jemand sagt, eine Neuentwicklung sei einfach.”

---

Dies ist ein fiktiver Bericht. Jede Ähnlichkeit mit tatsächlichen Unternehmen, Ereignissen oder Personen ist rein zufällig. Falls Sie allerdings Ihre eigene Organisation in dieser Geschichte wiedererkannt haben, ist das wahrscheinlich kein Zufall — sondern ein Muster.