Vier Bruchstellen, die immer wiederkehren

Nach Einschätzung mehrerer Beratungshäuser und dem KfW-Digitalisierungsbericht 2023 stuft ein erheblicher Anteil des deutschen Mittelstands seine Digitalisierungsvorhaben als enttäuschend ein — entweder weil Projekte gestoppt wurden, das Budget gesprengt wurde oder die fertige Software niemand nutzt. Der Bitkom-Lagebericht KMU 2024 zeigt: In Unternehmen mit 20 bis 99 Mitarbeitenden haben zwar zwei Drittel Digitalisierungsmaßnahmen ergriffen — aber weniger als ein Drittel berichtet von messbarer Prozessverbesserung. Das ist keine neue Erkenntnis. Neu ist, dass es immer denselben vier Mustern folgt. Wer sie kennt, kann einen zweiten Anlauf strukturierter planen.

Gescheiterte Digitalisierungsprojekte scheitern selten an der Technik. Sie scheitern an Prozesslogik, die niemand aufgeschrieben hat, an Laufzeiten, die länger waren als die Frage, und an Führungsdynamiken, die kein Berater im Angebot hatte.

Bruchstelle 1: Standardsoftware passt nicht zu gewachsenen Prozessen

Die klassische Annahme: Ein Standard-ERP bringt alle Prozesse in eine saubere Form. Die Realität im Mittelstand sieht anders aus. Hier wurden Prozesse über Jahre oder Jahrzehnte optimiert. Jede Sonderregel hat einen Grund — oft einen guten. Der Kunde, der immer donnerstags beliefert wird. Die Kalkulation, die regionale Faktoren berücksichtigt. Die Freigabe-Logik, die auf eine Branchen-Eigenheit reagiert.

Wenn das ERP verlangt, dass die Prozesse an die Software angepasst werden, entstehen zwei Varianten. Entweder Customizing-Chaos: Das Standardprodukt wird so umgebaut, dass es kaum noch als Standard erkennbar ist, und jedes Update wird zum Risiko. Oder eine stille Verhaltens-Niederlage: Die Software bleibt Standard, die Organisation soll sich anpassen, schafft das aber nur auf dem Papier. Im Alltag laufen die alten Prozesse weiter — parallel zur neuen Software, in Excel-Schatten-Akten.

Im Maschinenbau ist dieses Muster besonders ausgeprägt. Ein Lohnfertiger mit 80 Mitarbeitenden hat Fertigungssteuerungs-Logik, die in 25 Jahren gewachsen ist: Welche Aufträge können auf welchen Maschinen mit welchen Rüstzeiten laufen, welche Kunden bekommen Puffer, welche nicht. Kein Standard-ERP bildet das out of the box ab. Entweder wird massiv customized, oder der Meister überschreibt die ERP-Vorschläge täglich manuell — wozu dann das System?

Was daraus folgt: Vor der Tool-Wahl steht eine ehrliche Frage: Sind deine Kernprozesse Standard- oder Individualware? Wenn sie Individualware sind, ist ein Standard-ERP oft die falsche Antwort. Dann ist Individualsoftware die passendere Alternative — nicht weil Individualsoftware immer besser ist, sondern weil sie zu spezifischen Prozessen passt.

Bruchstelle 2: Projektlaufzeiten überholen die Anforderungen

Typische Einführungsprojekte bei Standard-ERP oder komplexer Individualentwicklung dauern zwölf bis achtzehn Monate. In dieser Zeit ändern sich Märkte, Regulatorik und interne Abläufe. Die fertige Applikation löst oft nicht mehr das Problem, das am Anfang gestellt wurde. Oder sie löst ein Problem, das inzwischen nachrangig ist, während die neue Dringlichkeit unadressiert bleibt.

Anpassungen im laufenden Projekt werden zu Change Requests. Jeder Change Request hat eine eigene Kalkulation, eine eigene Laufzeit, eine eigene Eskalationsschleife. Budgets sprengen, Zeitpläne schieben sich. Am Ende steht eine Software, die das Dreifache gekostet hat und trotzdem nicht genau das tut, was gebraucht wird.

Im Handwerk ist dieses Muster besonders sichtbar. Ein Maler- und Lackierbetrieb mit 35 Mitarbeitenden startete 2021 ein ERP-Einführungsprojekt für Auftragsmanagement und Materialwirtschaft. Laufzeit geplant: 10 Monate. Tatsächliche Laufzeit: 22 Monate. In dieser Zeit änderten sich die Gewärk-Struktur (Akquisition einer kleinen Trockenbau-Firma) und die Anforderungen an Nachkalkulation (neues Werkzeug der Berufsgenossenschaft). Beide Veränderungen wurden als nachträgliche Change Requests eingearbeitet, zum doppelten Stundensatz, mit zusätzlichen vier Monaten Laufzeit.

Was daraus folgt: Ein zweiter Anlauf sollte radikal kürzere Zyklen planen. Nicht ein Projekt über zwölf Monate, sondern mehrere Projekte über jeweils wenige Wochen. Jeder Zyklus liefert produktive Software, nicht nur Meilenstein-Dokumente. Das ist einer der Gründe, warum autonome Softwareentwicklung in kurzen Zyklen schneller tragfähig ist als klassische Wasserfall-Modelle.

Bruchstelle 3: Wissen hängt an Einzelpersonen, das Projekt erfasst es nicht Das Bundesinstitut für Berufsbildung (BIBB) im Qualifikationspanel 2023 bestätigt: Bei über 60 Prozent der untersuchten KMU existiert kein strukturierter Wissenstransfer-Prozess für ausscheidende Mitarbeitende.

Viele Digitalisierungsprojekte unterschätzen, wie viel Prozess-Wissen nirgendwo dokumentiert ist. Der Controller, der die Excel-Konsolidierung im Kopf hat. Der Kalkulator, der jede Ausschreibung aus dem Gefühl bewertet. Der Disponent, der jeden Kunden, jede Sonderregelung kennt. Der Einkäufer mit zwanzig Jahren Lieferanten-Historie.

Wenn das Projekt diese Wissens-Träger nicht strukturiert einbezieht, entsteht Software, die technisch funktioniert, aber die wirklich wichtigen Entscheidungen nicht trifft. Das ist einer der häufigsten stillen Gründe, warum Systeme „da sind, aber niemand sie nutzt“. Die Software kennt die Regel nicht, die der Kalkulator im Kopf hat. Also kalkuliert der Kalkulator weiter in seiner alten Excel-Datei. Das neue System wird zum teuren Dokumentations-Overlay ohne operative Kraft.

In Familienunternehmen kommt eine zusätzliche Dynamik dazu: Wissen ist Macht. Der Verkaufsleiter, der alle Kundenbeziehungen kennt, hat manchmal ein persönliches Interesse daran, unersetzlich zu bleiben — nicht aus bösem Willen, sondern aus natürlicher Selbsterhaltung. Wenn das Digitalisierungsprojekt diesen Interessenkonflikt nicht adressiert, bleibt das Wissen verschlossen, und die Software bildet es nicht ab.

Was daraus folgt: Ein zweiter Anlauf sollte Wissens-Träger früh und intensiv einbinden — nicht als Beteiligte am Rand, sondern als Fach-Experten im Zentrum. Personengebundenes Wissen lässt sich gezielt in ausführbare Applikationen überführen, statt es im nächsten Großprojekt mitzuschleppen und am Ende wieder nicht abzubilden.

Bruchstelle 4: Lastenheft unvollständig, Scope explodiert im laufenden Projekt

Ein gutes Lastenheft ist die halbe Miete. Aber selbst gute Lastenhefte haben typischerweise Lücken in vier Bereichen:

  • Fehler- und Ausnahmepfade werden übersehen: Was passiert, wenn die Schnittstelle nicht antwortet, die Eingabe unplausibel ist, der Auftrag storniert wird?
  • Nicht-funktionale Anforderungen werden vernachlässigt: Performance, Skalierung, Sicherheit.
  • Out-of-Scope-Definitionen fehlen: Was ausdrücklich nicht gebaut werden soll, wird später trotzdem erwartet.
  • Rollen- und Rechtemodelle bleiben oberflächlich: „Es gibt User und Admins“ reicht in keinem regulierten Prozess.

Wenn diese Lücken erst während der Entwicklung auffallen, werden sie zu Change Requests. Die ursprüngliche Schätzung war nicht falsch — sie bezog sich auf ein Lastenheft, das nur die Hälfte der Arbeit beschrieb.

Fallskizze: Eigentümer-CFO-Konflikt bei ERP-Einführung (anonymisiert)

Ein metallverarbeitender Betrieb (Lohnfertigung, 55 MA, Ostwestfalen) startete 2022 eine ERP-Einführung. Der Eigentümer wollte: Auftragsmanagement, Lagerverwaltung, einfache Kalkulation. Der kaufmännische Leiter (kein Familienmitglied, seit acht Jahren im Betrieb) wollte: Anbindung DATEV, strukturierte Kostenstellenrechnung, Freigabe-Workflow für Einkäufe über 5.000 Euro.

Diese Diskussion wurde nicht vor dem Projekt geführt. Sie wurde während des Projekts geführt, als der Anbieter für jede neue Anforderung des kaufmännischen Leiters einen Change Request stellte. Nach sechs Monaten hatten sich die Change Requests auf 40 Prozent des ursprünglichen Budgets summiert. Der Eigentümer stoppte das Projekt. Der kaufmännische Leiter kündigte vier Monate später.

Dieses Muster — Eigentümer definiert Scope, interner Fachverantwortlicher hat andere Anforderungen, Konflikt wird erst im laufenden Projekt sichtbar — ist kein Einzelfall. Es ist eine strukturelle Eigenheit des Mittelstands, wo die Geschäftsführung oft nicht die tief betriebliche Perspektive hat und die Fachabteilung nicht die Budgethoheit.

Was daraus folgt: Ein zweiter Anlauf sollte das Lastenheft strukturiert prüfen lassen, bevor irgendein Code geschrieben wird. Lücken vor dem Bau schließen ist immer billiger als Lücken während des Baus zu schließen. Ein Spec-Review identifiziert typische Lücken in vier Stunden, nicht in drei Workshops über vier Wochen.

Was ein zweiter Anlauf anders machen sollte

Aus den vier Bruchstellen lassen sich vier Prinzipien ableiten:

  1. Prozess-Passung vor Tool-Wahl. Zuerst klären, ob deine Kernprozesse Standard- oder Individualware sind. Das entscheidet, ob ein Standard-ERP oder Individualsoftware die richtige Antwort ist. Diese Entscheidung gehört an den Anfang — nicht in den zweiten Workshop-Block.
  2. Kurze Zyklen statt eines Monster-Projekts. Mehrere Projekte über jeweils wenige Wochen liefern schneller produktive Software als ein Zwölf-Monats-Projekt, das am Ende nicht mehr zur Frage passt. Jeder Zyklus produziert etwas Nutzbares, nicht nur ein Zwischenstand-Dokument.
  3. Wissens-Träger ernst nehmen. Die Person, die den Prozess kennt, ist Fach-Expertin, nicht Ablöse-Objekt. Ihre strukturierte Einbindung entscheidet, ob das System im Alltag wirklich nutzbar wird oder nur auf dem Papier existiert.
  4. Scope vor dem Bau klären. Bevor gebaut wird, prüft jemand das Lastenheft gegen typische Lücken. Das ist der günstigste Hebel gegen Scope-Kriechen während der Umsetzung.

Ein zweiter Anlauf ist keine Schande. In den Gesprächen, die wir mit mittelständischen Geschäftsführungen führen, ist er oft die Lernerfahrung, die den Unterschied zwischen „Digitalisierung läuft irgendwie“ und „Digitalisierung trägt“ ausmacht. Schade ist nur, wenn er denselben Fehlern folgt wie der erste.

Wie du den nächsten Anlauf absicherst

Bevor du einen neuen Software-Anbieter beauftragst oder ein neues ERP-Projekt startest, lohnen sich drei konkrete Fragen:

Frage 1: Welche unserer Kernprozesse sind in keinem System abgebildet, weil sie zu spezifisch sind? Diese Liste ist deine Entscheidungsgrundlage: Was davon braucht Individualsoftware, was ist wirklich Standard? Nicht alles, was im ERP nicht drinsteht, ist Individualware — manchmal wurde nur nie sauber konfiguriert.

Frage 2: Welche Person würde fehlen, wenn sie morgen aufhören würde? Nicht als Personalfrage, sondern als Wissens-Frage. Wessen mentale Landkarte trägt Prozesse, die sonst niemand kennt? Diese Person muss im Projekt nicht ganz vorne stehen — aber ihr Wissen muss extrahiert werden, bevor das System gebaut wird.

Frage 3: Was kostet es, in sechs Monaten alles nochmal zu machen? Das ist die Opportunitätskosten-Frage. Wenn die Antwort „weniger als das aktuelle Projekt“ ist, sollte das Projekt gestoppt und neu gestartet werden — nicht aus Prinzip, sondern weil Sunk-Cost-Denken im Mittelstand messbar mehr kostet als ein disziplinierter Neuanfang.

Diese Fragen kosten nichts. Sie verhindern viel.

Digitalisierungsprojekte, die scheitern, haben fast immer einen gemeinsamen Nenner in der Nachbesprechung: nicht das Tool war falsch, sondern der Zeitpunkt oder die Projektstruktur. Der Bitkom-Digitalisierungsindex KMU 2024 zeigt: 58 Prozent der mittelständischen Unternehmen, die ein gescheitertes Projekt dokumentieren, nennen als Hauptursache Projektmanagement-Defizite — fehlende Ressourcen, unklare Zuständigkeiten, zu enge Zeitplanung. Das ist keine technische Diagnose. Es ist eine organisatorische. Und organisatorische Probleme lassen sich vor dem nächsten Projektstart adressieren.

Beispiel: Eintrag im Projekt-Checklisten-Template

```
Projekt-Vorbereitung Checkliste

Projekt: _______
Projektstart: _______

Kernprozesse ohne System-Abbildung:

  • Prozess 1: ___ Verantwortlicher: _____
  • Prozess 2: ___ Verantwortlicher: _____

Wissens-Inventur:

  • Wissens-Traeger identifiziert: ______
  • Interview-Termin gebucht: (12-18 Monate vor Projektstart)

Lastenheft-Review:

  • Externer Spec-Review durchgefuehrt: [Ja / Nein / Datum]
  • Offene Punkte dokumentiert: ________

Projektstart-Clearance:

  • Kein laufendes Unternehmensereignis (Auftragsspitze,
    Personalwechsel, Umstrukturierung) im ersten Monat
  • Betriebsrat informiert (falls relevant nach BetrVG Sec. 87)
    ```

Diese Vorlage ist kein buerokratischer Aufwand — sie ist eine Erinnerungsliste fuer die Punkte, die in gescheiterten Projekten immer wieder fehlen. Wer sie konsequent durchgeht, beseitigt die haeufigsten Stolpersteine, bevor das Projekt beginnt. Wer sie ueberspringt, kann das spaeter nicht nachholen.

Was macht den Unterschied zwischen den Projekten, die diese Checkliste nutzen, und denen, die trotzdem scheitern? Meist ist es nicht ein einzelner Punkt — es ist die Kombination. Ein Projekt, das zum falschen Zeitpunkt startet, dessen Wissensträger nicht eingebunden sind und dessen Lastenheft drei wesentliche Prozesse nicht abdeckt, hat kumulativ drei der vier klassischen Bruchstellen aktiv. An diesem Punkt hilft keine bessere Projektmanagement-Methodik mehr. Der einzige belastbare Ausweg ist ein Neustart mit veränderter Ausgangslage.

Das klingt hart. Es ist aber das Ergebnis, das die Mehrzahl der mittelständischen Unternehmen, die gescheiterte Digitalisierungsprojekte offen analysieren, bestätigen: Weitermachen ist teurer als Stoppen. Der psychologische Widerstand dagegen — das investierte Geld, die intern aufgebauten Erwartungen, die Außenwirkung — ist real. Er ist aber kein Sachargument. Wer ihn überwindet und sachlich neu startet, kommt in der Regel schneller ans Ziel als wer versucht, ein strukturell defektes Projekt durch zusätzliche Ressourcen zu retten.

Drei Hinweise aus der Praxis, die bei einem Neustart helfen: Erstens — die Fachbereiche und die IT-Leitung früh einbinden, nicht nur informieren. Der Unterschied ist: Einbinden bedeutet, dass diese Personen Anforderungen einbringen können, bevor das Lastenheft geschlossen ist. Informieren bedeutet, dass sie fertige Entscheidungen zur Kenntnis nehmen. Projekte, bei denen die Fachbereiche eingebunden waren, haben eine deutlich höhere Akzeptanzrate. Zweitens — einen externen Gegenlesen-Termin für das Lastenheft einplanen, bevor der erste Entwickler hinzukommt. Vier Stunden externe Prüfung sind billiger als vier Monate falsch gebaute Software. Drittens — den Projektstart an einen ruhigen Betriebszeitraum koppeln, nicht an die Verfügbarkeit des Anbieters.

Weiterlesen im Wissen-Hub

Wie personengebundenes Wissen gesichert werden kann, bevor es das Unternehmen verlässt: Wenn Herr Müller in Rente geht. Wann Individualsoftware die richtige Antwort ist und wann nicht: Individualsoftware für den Mittelstand. Wie ein Spec-Review in vier Stunden die typischen Lastenheft-Lücken findet: Vom Lastenheft zur Software.

Stand: 2026-05-26 · AthenaRun GmbH, Frankfurt am Main