Viele Unternehmen starten mit einer Eigenentwicklung aus einem guten Grund: Es gibt am Markt nichts Passendes, die eigenen Prozesse sind speziell, und der Druck ist hoch. Also baut man selbst. Oft gemeinsam mit Menschen, die das Geschäft in- und auswendig kennen. Über die Jahre wird diese Lösung zum Rückgrat des Betriebs – und zu einem Stück Identität.

Irgendwann kippt die Balance: Der Wartungsaufwand steigt, Schlüsselpersonen werden knapp, Anforderungen werden komplexer, Compliance und Security ziehen an, und neue Features dauern länger als früher. Gleichzeitig tauchen am Markt Lösungen auf, die gut sind – oder sogar besser.

Und trotzdem: Der Schritt weg vom Eigenbau fühlt sich nicht wie eine rein rationale Entscheidung an. Er ist emotional.

Dieser Artikel richtet sich an Unternehmen, die genau in dieser Situation sind – und an alle, die den Wechsel nicht nur technisch, sondern auch menschlich sauber gestalten wollen.

1) Warum der Abschied vom Eigenbau so schwerfällt

„Wir haben das aufgebaut.“

Die Eigenentwicklung ist selten einfach nur Software. Sie ist das Ergebnis von Jahren an Entscheidungen, Nachtschichten, Diskussionen, Improvisation und Lernen. Sie trägt Geschichten: Kundengewinne, Krisen, Wachstumsschritte.

Wenn man das ersetzt, fühlt es sich schnell an wie:

• ein Eingeständnis, dass man „es nicht mehr kann“,
• ein Bruch mit der eigenen DNA,
• oder eine Entwertung der Arbeit derjenigen, die das System geschaffen haben.

Diese Gefühle sind normal – und sie werden oft unterschätzt.

„Das ist unser Wettbewerbsvorteil.“

Viele Eigenentwicklungen entstanden aus der Überzeugung: Unsere Prozesse sind einzigartig.
Und oft stimmt das auch – zumindest teilweise. Doch was früher ein Wettbewerbsvorteil war, wird manchmal zum Wettbewerbsrisiko, wenn Weiterentwicklung und Stabilität nicht mehr mithalten.

„Wir verlieren Kontrolle.“

Mit einem Eigenbau entscheidet man selbst über Roadmap, Prioritäten, Release-Zeitpunkte. Eine externe Lösung bedeutet: Abhängigkeit von einem Anbieter, dessen Entscheidungen man nicht vollständig steuern kann.

Kontrollverlust ist einer der stärksten emotionalen Treiber gegen den Wechsel – selbst wenn die Zahlen dafür sprechen.

„Was, wenn es schiefgeht?“

Die Angst vor dem Migrationsprojekt ist meist grösser als die Angst vor dem Status quo. Denn der Status quo ist bekannt, selbst wenn er schmerzt.

Typische Sorgen:

• Datenverlust oder Datenchaos
• Stillstand im Betrieb während der Umstellung
• Akzeptanzprobleme bei den Teams
• versteckte Kosten
• „wir sind danach nicht schneller, nur anders langsam“

2) Der Perspektivwechsel: Es geht nicht darum, ob der Eigenbau gut war – sondern ob er heute noch der richtige Weg ist

Ein Wechsel ist keine Abwertung der Vergangenheit. Im Gegenteil:

Eine Eigenentwicklung, die euch über Jahre getragen hat, war vermutlich eine der besten Entscheidungen, die ihr damals treffen konntet.

Die Frage ist nur: Hat sich eure Realität verändert?
Und: Ist Software bauen noch euer Kerngeschäft – oder eher eine Nebenaufgabe, die inzwischen zu viel kostet?

Oft ist der ehrlichste Satz im ganzen Prozess:

• „Unser Eigenbau war richtig – bis er es nicht mehr war.“

3) Was Unternehmen bei der Evaluation einer externen Lösung wirklich prüfen sollten

A) „Kann die Standardlösung unseren Sonderfall?“

Meist lautet die Antwort: zu 80–90% ja.
Die restlichen 10–20% sind der entscheidende Teil.

Hier hilft ein klares Raster:

• Was ist Prozess-Kritisch (muss exakt so bleiben)?
• Was ist Gewohnheit (fühlt sich wichtig an, ist aber ersetzbar)?
• Was ist historisch gewachsen (kann man vereinfachen)?

Viele „Must-haves“ sind in Wahrheit „Nice-to-have mit emotionalem Gewicht“.

B) Integrationen, Schnittstellen, Datenqualität

Ein Eigenbau kaschiert oft jahrelang schlechte Datenstrukturen, weil das System „weiss, was gemeint ist“. Externe Systeme sind konsequenter – und das ist gut. Aber es braucht Vorbereitung:

• Datenbereinigung
• klare Datenverantwortung
• definierte „Single Source of Truth“

C) Veränderungsfähigkeit statt Feature-Vergleich

Viele kaufen nach Feature-Listen – und sind nachher enttäuscht, weil der Alltag anders aussieht.

Besser ist:

• Wie schnell können wir Prozesse anpassen?
• Wie gut können wir Rollen und Berechtigungen abbilden?
• Wie schnell sind wir bei neuen Anforderungen (legal, operativ, Markt)?

4) Wie man den Wechsel emotional richtig aufsetzt

1) Würdigt den Eigenbau offiziell

Das klingt banal, ist aber extrem wirksam.

• Macht sichtbar, was die Eigenentwicklung ermöglicht hat.
• Benennt, welche Menschen sie getragen haben.
• Kommuniziert klar: Der Wechsel ist ein Reifezeichen – kein Scheitern.

2) Holt die „Erbauer“ an den Tisch – nicht aus dem Raum

Die grösste Gefahr ist, dass diejenigen, die das System gebaut haben, den Wechsel als Angriff erleben und (bewusst oder unbewusst) blockieren.

Besser:

• gebt ihnen eine aktive Rolle (z. B. Requirements Owner, Prozess-Lead, QA Lead)
• nutzt ihr Wissen für die Übergangsphase
• lasst sie mitgestalten, welche Teile bewusst „losgelassen“ werden

3) Setzt ein Pilot-Ziel, das jeder versteht

Nicht: „Wir migrieren das ganze System.“
Sondern: „Wir schaffen in 8 Wochen, dass X in der neuen Lösung funktioniert – stabil, messbar und schneller als heute.“

Gute Pilot-Ziele:

• ein Standort
• eine Abteilung
• ein Prozess (z. B. Planung + Zeiterfassung)
• ein definierter Zeitraum (z. B. eine Saisonphase)

4) Vermeidet den „Big Bang“, wenn ihr könnt

Der emotionale Druck steigt mit dem Risiko. Stufenweise Migration reduziert Angst und Widerstände:

• parallel laufen lassen (kurzzeitig)
• kritische Prozesse zuerst stabilisieren
• „nice-to-have“-Prozesse später

5) Ein realistischer, sicherer Weg: Das 3-Phasen-Modell

Phase 1: Klarheit (2–4 Wochen)

• Prozessinventur: Was machen wir wirklich?
• Pain Points: Was kostet uns heute Zeit/Geld/Nerven?
• Must-haves vs. verhandelbar
• Daten-Check (Qualität, Vollständigkeit, Ownership)

Ergebnis: Ein Entscheidungspapier, das nicht auf Bauchgefühl basiert.

Phase 2: Pilot (6–10 Wochen)

• Setup + Schulung
• echte Testfälle mit echten Daten
• klare Erfolgskriterien (z. B. „Planung dauert 30% weniger“, „Fehlerquote sinkt“)

Ergebnis: Beweis, dass es funktioniert – oder sauberes Stop/Go.

Phase 3: Rollout (8–16 Wochen)

• Migration nach Einheiten/Prozessen
• Change-Kommunikation
• Support-Struktur
• Abschluss: Altsystem archivieren, nicht „vergessen“

Ergebnis: Kontrolle, Stabilität, Akzeptanz.

6) Fazit: Loslassen ist kein Verlust – sondern Fokus

Wenn ihr euch emotional schwer tut, den Eigenbau abzulösen, ist das kein Zeichen von Schwäche. Es ist ein Zeichen, dass er wichtig war.

Aber: Unternehmen wachsen, Märkte ändern sich, Risiken verschieben sich – und irgendwann wird „Software selber bauen“ zur Bremse statt zum Motor.

Der beste Wechsel ist der, bei dem ihr nicht nur technisch migriert, sondern auch menschlich sauber abschliesst:

• mit Respekt für das, was euch getragen hat,
• mit Klarheit, was ihr wirklich braucht,
• und mit einem Plan, der Risiken reduziert und Vertrauen aufbaut.