Vier Bruchstellen, die immer wiederkehren

Digitalisierungsvorhaben im Mittelstand enden überdurchschnittlich oft enttäuschend: entweder weil Projekte gestoppt wurden, das Budget gesprengt wurde oder die fertige Software niemand nutzt. Das ist keine neue Erkenntnis. Bemerkenswert ist, dass es dabei 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 oft 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-Schattenakten.

Im Maschinenbau ist dieses Muster besonders ausgeprägt. Ein illustratives Beispiel. Ein Lohnfertiger mit 80 Mitarbeitenden hat Fertigungssteuerungslogik, 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. Ein Standard-ERP bildet das selten ohne Anpassung 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

ERP-Einführungen im klassischen Mittelstand dauern laut der Trovarit-Studie „ERP in der Praxis“ (2023) vom Beginn der Projektarbeit bis zum Produktivstart zwischen 10 und 13 Monaten. 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 hat eine eigene Kalkulation, eine eigene Laufzeit, eine eigene Eskalationsschleife. Budgets sprengen, Zeitpläne schieben sich. Am Ende steht eine Software, die ein Vielfaches gekostet hat und trotzdem nicht genau das tut, was gebraucht wird.

Ein illustratives Beispiel aus dem Handwerk: Ein Maler- und Lackierbetrieb mit 35 Mitarbeitenden startet ein ERP-Einführungsprojekt für Auftragsmanagement und Materialwirtschaft, geplant für zehn Monate. Tatsächlich werden es 22. In dieser Zeit ändert sich die Gewerkestruktur (ein kleiner Trockenbaubetrieb wird übernommen), und die Anforderungen an die Nachkalkulation ändern sich ebenfalls. Beide Veränderungen werden als nachträgliche Change Requests eingearbeitet, zu höheren Sätzen, mit zusätzlicher 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.

Bruchstelle 3: Wissen hängt an Einzelpersonen, das Projekt erfasst es nicht

Viele Digitalisierungsprojekte unterschätzen, wie viel Prozesswissen 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 und jede Sonderregelung kennt. Der Einkäufer mit zwanzig Jahren Lieferantenhistorie.

Wenn das Projekt diese Wissensträ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 Wissensträger früh und intensiv einbinden: nicht als Beteiligte am Rand, sondern als Fachexperten 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 und kaufmännische Leitung ziehen in verschiedene Richtungen

Ein illustratives Beispiel. Ein metallverarbeitender Lohnfertiger mit rund 55 Mitarbeitenden startet eine ERP-Einführung. Der Eigentümer will: Auftragsmanagement, Lagerverwaltung, einfache Kalkulation. Die kaufmännische Leitung (kein Familienmitglied, seit Jahren im Betrieb) will: Anbindung an die Buchhaltung, strukturierte Kostenstellenrechnung, einen Freigabe-Workflow für größere Einkäufe.

Diese Diskussion wird nicht vor dem Projekt geführt, sondern während des Projekts, als der Anbieter für jede neue Anforderung einen Change Request stellt. Nach einem halben Jahr haben sich die Change Requests auf einen erheblichen Teil des ursprünglichen Budgets summiert. Der Eigentümer stoppt das Projekt. Die kaufmännische Leitung kündigt einige Monate später.

Dieses Muster (Eigentümer definiert den Scope, interne Fachverantwortung hat andere Anforderungen, der 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 zu schließen ist immer billiger, als sie während des Baus zu schließen. Ein Spec-Review findet die typischen Lücken, bevor sie Geld kosten.

Was ein zweiter Anlauf anders machen sollte

Aus den vier Bruchstellen lassen sich vier Prinzipien ableiten:

  • 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.
  • 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 Zwischenstandsdokument.
  • Wissensträger ernst nehmen. Die Person, die den Prozess kennt, ist Fachexpertin, nicht Ablöseobjekt. Ihre strukturierte Einbindung entscheidet, ob das System im Alltag wirklich nutzbar wird oder nur auf dem Papier existiert.
  • 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 Wissensfrage. Wessen mentale Landkarte trägt Prozesse, die sonst niemand kennt? Diese Person muss im Projekt nicht ganz vorne stehen, aber ihr Wissen muss erfasst werden, bevor das System gebaut wird.

Frage 3: Was kostet es, in sechs Monaten alles noch einmal zu machen? Das ist die Opportunitätskostenfrage. Wenn die Antwort „weniger als das aktuelle Projekt" lautet, sollte das Projekt gestoppt und neu gestartet werden, nicht aus Prinzip, sondern weil Sunk-Cost-Denken erfahrungsgemäß mehr kostet als ein disziplinierter Neuanfang.

Diese Fragen kosten nichts. Sie verhindern viel.

Digitalisierungsprojekte, die scheitern, haben in der Nachbesprechung fast immer einen gemeinsamen Nenner: nicht das Tool war falsch, sondern der Zeitpunkt oder die Projektstruktur (fehlende Ressourcen, unklare Zuständigkeiten, zu enge Zeitplanung). Das ist keine technische Diagnose, sondern 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: ____________  Verantwortlich: ____________
  Prozess 2: ____________  Verantwortlich: ____________

Wissens-Inventur
  Wissensträger identifiziert:   ____________
  Interview-Termin gebucht:      ____________
  (idealerweise 12-18 Monate vor dem Austritt der Person)

Lastenheft-Review
  Externer Spec-Review durchgeführt:  Ja / Nein / Datum ______
  Offene Punkte dokumentiert:         ____________

Projektstart-Clearance
  Kein laufendes Unternehmensereignis im ersten Monat
  (Auftragsspitze, Personalwechsel, Umstrukturierung)
  Betriebsrat informiert, falls nach § 87 BetrVG relevant

Diese Vorlage ist kein bürokratischer Aufwand. Sie ist eine Erinnerungsliste für die Punkte, die in gescheiterten Projekten immer wieder fehlen. Wer sie konsequent durchgeht, beseitigt die häufigsten Stolpersteine, bevor das Projekt beginnt. Wer sie überspringt, kann das später 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 belastbarste Ausweg ist ein Neustart mit veränderter Ausgangslage.

Das klingt hart, und es ist eine Einschätzung aus unserer Praxis, keine Erhebung: Weitermachen wird an diesem Punkt meist 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 nach unserer Beobachtung 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 konkret: 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, werden im Betrieb erfahrungsgemäß besser angenommen. Zweitens: einen externen Gegenlesetermin für das Lastenheft einplanen, bevor der erste Entwickler hinzukommt. Ein paar Stunden externe Prüfung sind billiger als Monate falsch gebauter 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: Wissen vor dem Ruhestand sichern. Wann Individualsoftware die richtige Antwort ist und wann nicht: Individualsoftware für den Mittelstand. Wie ein Spec-Review die typischen Lastenheft-Lücken findet: Vom Lastenheft zur Software.

Stand: 16.09.2026 · AthenaRun GmbH, Frankfurt am Main