Warum Digitalisierungsprojekte scheitern – und wie der Mittelstand gegensteuert

Digitalisierungsprojekte scheitern meist, wenn Unternehmen Software auswählen, bevor sie den tatsächlichen Arbeitsablauf verstanden haben. Werden Medienbrüche, Sonderwege und nicht geregelte Zuständigkeiten lediglich in ein neues System übertragen, wächst der Aufwand trotz moderner Technik. Erfolgreiche Digitalisierung beginnt daher im Betrieb: bei realen Vorgängen, belastbarem Wissen, definierten Rollen und messbarem Nutzen.

Warum scheitern Digitalisierungsprojekte trotz moderner Technik?

Ein neues ERP-System, eine Kundenplattform, eine mobile Service-App oder ein digitales Auftragsportal kann technisch einwandfrei funktionieren und dennoch im Betrieb enttäuschen. Der Grund liegt häufig nicht im Programmcode, sondern in der Annahme, Software könne organisatorische Probleme automatisch beseitigen. Tatsächlich übernimmt ein System zunächst genau das, was ihm vorgegeben wird: Rollen, Freigaben, Datenfelder, Übergaben und Ausnahmen. Ist der zugrunde liegende Ablauf umständlich, wird diese Umständlichkeit lediglich schneller, verbindlicher und schwerer zu umgehen.

Das zeigt sich auch in aktuellen Erhebungen. Laut Gartner erreichen oder übertreffen nur 48 Prozent der digitalen Initiativen ihre angestrebten Geschäftsergebnisse.[1] In Deutschland gibt zugleich eine Mehrheit von 53 Prozent der befragten Unternehmen an, Schwierigkeiten bei der Bewältigung der Digitalisierung zu haben.[2] Beide Werte beschreiben kein reines Technikproblem. Sie weisen auf eine Lücke zwischen Investition und betrieblicher Wirkung hin.

Im Mittelstand fällt diese Lücke besonders auf. Die Mannschaft ist kleiner, Fachwissen steckt oft in wenigen Köpfen, und ein Projekt bindet dieselben Mitarbeiter, die parallel Angebote schreiben, Baustellen koordinieren, Kunden betreuen oder den laufenden Betrieb sichern müssen. Wenn das Vorhaben zusätzliche Dateneingaben, neue Abstimmungen oder Doppelpflege erzeugt, sinkt die Akzeptanz schnell. Dann entsteht eine Schattenorganisation aus Excel-Dateien, E-Mails, Messenger-Nachrichten und handschriftlichen Notizen neben dem offiziellen System.

Was wird bei der Bestandsaufnahme üblicherweise übersehen?

Eine Prozessaufnahme beginnt in vielen Projekten mit Organigrammen, Verfahrensanweisungen und Interviews mit Führungskräften. Das liefert einen ersten Überblick, zeigt aber selten, wie Arbeit unter Zeitdruck tatsächlich erledigt wird. Im Tagesgeschäft entstehen Abkürzungen, Zwischenlösungen und informelle Übergaben, weil Kundenangaben fehlen, ein Lieferant verspätet antwortet, ein Monteur keinen Zugriff auf das System hat oder eine Genehmigung kurzfristig geändert wird.

Gerade diese Abweichungen sind entscheidend. Ein Soll-Prozess beschreibt, wie ein Auftrag laufen sollte. Ein belastbarer Ist-Prozess zeigt, was geschieht, wenn Unterlagen fehlen, Prioritäten wechseln oder mehrere Abteilungen gleichzeitig handeln müssen. Wer nur den Idealweg modelliert, entwickelt Software für einen Zustand, der im Betrieb kaum vorkommt.

In der Praxis lohnt es sich deshalb, reale Vorgänge vom Eingang bis zum Abschluss zu begleiten. Bei einem technischen Dienstleister kann das eine Störungsmeldung sein, die zunächst telefonisch eingeht, später per Foto ergänzt wird, im ERP einen Auftrag auslöst und nach dem Einsatz in eine Dokumentation mündet. Im Bau- oder Handwerksbetrieb kann es um eine Anfrage gehen, bei der Maße, Zufahrt, Terminfenster, Material, Nachunternehmer und behördliche Auflagen zusammengeführt werden müssen. Erst an solchen Fällen werden Medienbrüche, Suchzeiten und Wissenslücken sichtbar.

Warum macht digitalisierte Ineffizienz den Alltag oft schwerer?

Papier und Tabellen sind fehleranfällig, besitzen aber eine Eigenschaft, die in Projekten unterschätzt wird: Mitarbeiter können spontan reagieren. Sie ergänzen eine Notiz, rufen einen Kollegen an oder verschieben eine Aufgabe, weil die Situation es verlangt. Ein schlecht gestaltetes digitales System nimmt diese Beweglichkeit, ohne zugleich bessere Unterstützung zu bieten. Pflichtfelder blockieren die Bearbeitung, starre Statusmodelle passen nicht zum Auftrag, und fehlende Schnittstellen erzwingen zusätzliche Übertragungen.

So wird aus einem einfachen Problem eine Kette neuer Tätigkeiten. Der Vertrieb erfasst die Kundendaten im CRM, die Disposition überträgt sie in die Einsatzplanung, die Buchhaltung legt den Debitor im ERP an, und der Projektleiter führt parallel eine eigene Liste, weil wichtige Informationen in keinem System vollständig sichtbar sind. Formal wurde digitalisiert. Operativ hat sich die Zahl der Übergaben erhöht.

Was dabei üblicherweise fehlschlägt, ist die Trennung zwischen Datenerfassung und Arbeitsunterstützung. Ein Formular sammelt Informationen, hilft aber nicht automatisch bei der Entscheidung, ob eine Anfrage vollständig ist. Ein Dashboard zeigt Statuswerte, erklärt aber nicht, welche Aufgabe als Nächstes ansteht. Eine Dokumentenablage speichert Dateien, stellt jedoch nicht sicher, dass die gültige Arbeitsanweisung im richtigen Moment verfügbar ist. Digitalisierung erzeugt erst dann Entlastung, wenn das System den nächsten Arbeitsschritt vorbereitet, relevante Informationen zusammenführt und unnötige Eingaben vermeidet.

Wie unterscheiden sich ein technikgetriebenes und ein prozessnahes Projekt?

Der Unterschied liegt nicht darin, dass prozessnahe Projekte weniger anspruchsvoll wären. Sie verschieben den Schwerpunkt. Statt möglichst früh viele Funktionen festzulegen, investieren sie zuerst in das Verständnis des Arbeitsablaufs. Dadurch kann das Team Funktionen weglassen, die im Betrieb keinen Beitrag leisten, und jene Stellen intensiver bearbeiten, an denen Wissen, Entscheidung und Übergabe zusammenkommen.

Welche Rolle spielen Fachbereiche, IT und Geschäftsführung?

Digitalisierung wird oft als Aufgabe der IT behandelt. Die IT kann Architektur, Sicherheit, Schnittstellen, Berechtigungen und Betrieb verantworten. Sie kann aber nicht allein entscheiden, welche Angaben ein Bauleiter vor der Disposition benötigt, wann ein Serviceauftrag abrechnungsfähig ist oder welche Abweichung in der Qualitätssicherung eine Eskalation auslöst. Dieses Wissen liegt im Fachbereich.

Umgekehrt kann der Fachbereich nicht allein festlegen, wie Datenmodelle, Integrationen und Zugriffsrechte aufgebaut werden. Werden Anforderungen lediglich über den Zaun geworfen, entsteht ein Übersetzungsproblem: Der Fachbereich beschreibt Funktionen, die IT baut technische Komponenten, und erst im Test zeigt sich, dass beide Seiten unterschiedliche Situationen vor Augen hatten.

Die Geschäftsführung muss deshalb nicht jedes Detail freigeben, aber sie muss den geschäftlichen Zweck, die Priorität und die Entscheidungswege tragen. Eine aktuelle Untersuchung des Project Management Institute nennt die Trennung zwischen Planung und Umsetzung mit 35 Prozent als meistgenanntes Hindernis für die Erneuerung von Unternehmen.[3] Für Digitalisierungsprojekte bedeutet das: Verantwortung darf nicht mit dem Projektauftrag enden. Fachliche Entscheidungen, Ressourcenkonflikte und Änderungen im Betriebsmodell benötigen einen benannten Entscheider.

Warum reicht ein Pflichtenheft allein nicht aus?

Ein Pflichtenheft kann Leistungen, Schnittstellen und Abnahmekriterien beschreiben. Es kann jedoch das Erfahrungswissen der Mitarbeiter nur begrenzt erfassen. Viele Entscheidungen beruhen auf Mustern, die im Unternehmen selbstverständlich wirken: Ein bestimmter Kundentyp benötigt eine zusätzliche Prüfung, bei einer Baustelle mit enger Zufahrt muss früher disponiert werden, oder eine technische Störung verlangt je nach Anlage eine andere Reihenfolge der Rückfragen.

Solches Wissen taucht oft erst auf, wenn ein echter Fall bearbeitet wird. Deshalb sollten Anforderungen nicht ausschließlich als abstrakte Sätze formuliert werden. Aussagekräftiger sind konkrete Szenarien: Wer beginnt den Vorgang? Welche Informationen liegen zu diesem Zeitpunkt vor? Welche fehlen üblicherweise? Welche Entscheidung wird getroffen? Wer trägt die Verantwortung? Was geschieht, wenn der Standardweg nicht funktioniert?

Prototypen und frühe produktive Versionen sind dabei keine Präsentationsobjekte. Sie dienen dazu, Annahmen im Arbeitskontext zu prüfen. Ein Mitarbeiter erkennt an einem realen Auftrag schneller, ob eine Maske sinnvoll aufgebaut ist, als anhand einer langen Liste von Feldbezeichnungen. Ebenso zeigt sich früh, ob ein automatischer Vorschlag wirklich unterstützt oder nur eine weitere Meldung erzeugt.

Wie sollte ein Mittelständler ein Digitalisierungsprojekt beginnen?

Der Einstieg sollte nicht mit der Frage beginnen, welche Software gekauft wird. Sinnvoller ist eine betriebliche Fragestellung: Wo verlieren Mitarbeiter regelmäßig Zeit? Wo entstehen kostspielige Fehler? Welche Übergabe verursacht Rückfragen? Welcher Vorgang hängt übermäßig von einer einzelnen Person ab? Wo fehlen Nachweise, obwohl die Arbeit korrekt ausgeführt wurde?

Aus diesen Beobachtungen wird ein begrenzter Anwendungsfall gewählt. Er sollte häufig genug vorkommen, einen spürbaren Aufwand verursachen und organisatorisch beeinflussbar sein. Ein Beispiel wäre die strukturierte Aufnahme einer Kundenanfrage bis zur Übergabe an die Kalkulation. Ein anderes wäre die mobile Erfassung eines Serviceeinsatzes mit Fotos, Material, Arbeitszeit und Kundenfreigabe. Entscheidend ist, dass der vollständige Weg betrachtet wird und nicht nur eine einzelne Bildschirmmaske.

Danach folgt eine kurze Untersuchungsphase im Betrieb. Das Team beobachtet Vorgänge, wertet vorhandene Unterlagen aus, spricht mit den beteiligten Rollen und sammelt typische Ausnahmen. Erst anschließend wird entschieden, welche Funktion, Integration oder Assistenz benötigt wird. Dadurch bleibt die Technik Mittel zum Zweck und das Projekt kann früh beendet oder neu ausgerichtet werden, wenn der erwartete Nutzen nicht trägt.

Wie wird Wissen Bestandteil des Systems?

Viele Projekte digitalisieren Daten, aber nicht das Wissen, das für ihre Nutzung erforderlich ist. Ein Auftrag enthält dann Kundennummer, Termin und Status, während die eigentlichen Entscheidungshilfen weiterhin in Köpfen, alten E-Mails oder privaten Vorlagen liegen. Mitarbeiter müssen das System bedienen und zugleich wissen, welche Besonderheit außerhalb des Systems zu beachten ist.

Ein wirksames Wissensmodell verbindet Fachregeln, Prozessschritte, Dokumente und Erfahrungen mit dem jeweiligen Vorgang. Bei der Angebotserstellung kann das System auf passende Kalkulationsgrundlagen, frühere Vergleichsprojekte und erforderliche Nachweise hinweisen. Im Service kann es zur Anlage passende Prüfschritte bereitstellen. Bei regulatorischen Tätigkeiten kann es dokumentieren, welche Version einer Vorgabe angewendet wurde.

Dabei darf Wissen nicht als einmalige Sammlung verstanden werden. Verantwortliche müssen Inhalte pflegen, Gültigkeiten festlegen und Rückmeldungen aus dem Betrieb aufnehmen. Ohne diese Zuständigkeit altert die Wissensbasis. Das System wirkt dann zunächst hilfreich, liefert später jedoch veraltete Hinweise und verliert Vertrauen.

Woran erkennt man früh, dass ein Projekt aus dem Takt gerät?

Ein Warnsignal ist die zunehmende Distanz zum Arbeitsalltag. Besprechungen drehen sich überwiegend um Funktionen, Lizenzen und technische Meilensteine, während echte Vorgänge kaum noch betrachtet werden. Ein weiteres Signal sind wachsende Listen von Sonderwünschen. Häufig versucht das Team dann, organisatorische Uneinigkeit durch zusätzliche Optionen abzubilden.

Auch die Sprache im Projekt verrät viel. Wenn der Erfolg hauptsächlich daran gemessen wird, ob Module aktiviert, Daten migriert oder Schulungen durchgeführt wurden, fehlt womöglich der Bezug zum Geschäftsergebnis. Diese Leistungen sind notwendig, aber sie belegen noch keine Verbesserung. Entscheidend ist, ob Mitarbeiter einen Vorgang mit weniger Unterbrechungen, Nachfragen und Nacharbeit abschließen können.

Besonders kritisch wird es, wenn erfahrene Mitarbeiter eigene Nebenlösungen entwickeln. Eine zusätzliche Tabelle ist nicht automatisch Widerstand. Sie kann darauf hinweisen, dass das offizielle System eine betriebliche Aufgabe nicht erfüllt. Statt diese Lösung sofort zu verbieten, sollte das Projektteam untersuchen, welche Information oder Entscheidung dort abgebildet wird.

Wie lässt sich der Nutzen im Betrieb nachweisen?

Der Nutzen sollte vor der Umsetzung in beobachtbaren Größen beschrieben werden. Dazu gehören Bearbeitungszeit, Zahl der Rückfragen, Anteil unvollständiger Vorgänge, Nacharbeit, Suchaufwand, Wartezeiten an Übergaben und Häufigkeit manueller Doppelerfassungen. Je nach Anwendungsfall können auch Termintreue, Dokumentationsqualität, Erstlösungsquote oder Zeit bis zur Rechnungsstellung relevant sein.

Wichtig ist der Vergleich mit dem bisherigen Ablauf. Ohne Ausgangswert bleibt später offen, ob die Verbesserung durch das neue System, durch zusätzliche Mitarbeiter oder durch eine vorübergehend geringere Auslastung entstanden ist. Die Messung muss nicht wissenschaftlich aufwendig sein. Eine überschaubare Stichprobe realer Vorgänge reicht oft, um Engpässe und Veränderungen sichtbar zu machen.

Neben Kennzahlen gehört die Nutzungserfahrung dazu. Mitarbeiter können beschreiben, wo sie weiterhin improvisieren, welche Hinweise fehlen und welche Eingabe keinen erkennbaren Zweck besitzt. Solche Rückmeldungen sollten nicht als nachträgliche Änderungswünsche behandelt werden, sondern als Teil der Produktsteuerung.

Warum ist ein begrenzter produktiver Anwendungsfall oft besser als ein Großprogramm?

Große Programme versprechen ein einheitliches Zielbild, erzeugen aber lange Abhängigkeiten. Datenmigration, Prozessharmonisierung, Schnittstellen, Rollenmodelle und Schulungen werden gleichzeitig geplant. Bis der erste Nutzen im Betrieb ankommt, können sich Prioritäten, Personal und Marktbedingungen bereits verändert haben.

Ein begrenzter Anwendungsfall zwingt das Unternehmen, Nutzen und Verantwortung genauer zu bestimmen. Er lässt sich mit echten Mitarbeitern, echten Daten und echten Kundenfällen prüfen. Fehler werden sichtbar, bevor sie sich über mehrere Standorte oder Abteilungen ausbreiten. Gleichzeitig entsteht eine belastbare Grundlage für die nächste Ausbaustufe.

Die Zurückhaltung vieler Unternehmen zeigt, wie wichtig ein wirtschaftlich nachvollziehbarer Einstieg ist. Nach dem aktuellen KfW-Digitalisierungsbericht haben nur 30 Prozent der mittelständischen Unternehmen im betrachteten Zeitraum ein Digitalisierungsvorhaben abgeschlossen.[4] Das spricht nicht gegen ambitionierte Ziele. Es spricht dafür, Vorhaben so zuzuschneiden, dass sie trotz knapper Ressourcen in den Betrieb gelangen und dort Wirkung zeigen.

Welche Konsequenz ergibt sich für den deutschen Mittelstand?

Ein gescheitertes Digitalisierungsprojekt ist selten nur eine abgeschriebene Softwarelizenz. Es verbraucht Aufmerksamkeit, belastet Mitarbeiter und senkt die Bereitschaft, weitere Veränderungen mitzutragen. Deshalb ist ein ehrlicher Projektstopp manchmal wirtschaftlicher als ein Rollout, der nur aufgrund bereits getätigter Investitionen fortgesetzt wird.

Erfolgreiche Digitalisierung beginnt mit Beobachtung statt Produktkatalog, mit realen Vorgängen statt idealisierten Ablaufbildern und mit betrieblichem Nutzen statt Funktionsumfang. Sie verbindet Fachwissen, Verantwortlichkeiten, Daten und Technik zu einem Arbeitsmittel, das im entscheidenden Moment unterstützt. Für mittelständische Unternehmen ist genau diese Nähe zum Betrieb der wichtigste Schutz vor unnötiger Komplexität.

Wer wissen möchte, warum Digitalisierungsprojekte scheitern, sollte daher nicht zuerst nach dem falschen Tool suchen. Die entscheidende Frage lautet, ob das Unternehmen seinen eigenen Ablauf ausreichend verstanden, die betroffenen Mitarbeiter einbezogen und den Nutzen überprüfbar beschrieben hat. Erst danach wird aus Technologie eine tragfähige Lösung.

Welche Quellen belegen die verwendeten Kennzahlen?

[1] Gartner: „Gartner Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets“
https://www.gartner.com/en/newsroom/press-releases/2024-10-22-gartner-survey-reveals-that-only-48-percent-of-digital-initiatives-meet-or-exceed-their-business-outcome-targets

[2] Bitkom: „Digitalisierung der deutschen Wirtschaft kommt nur langsam voran“
https://www.bitkom.org/Presse/Presseinformation/Digitalisierung-Wirtschaft-langsam

[3] Project Management Institute: „New PMI Research Reveals Strategy-Execution Gap Is Undermining Transformation And How to Close It“
https://www.pmi.org/about/press-media/2025/new-pmi-research-reveals-strategy-execution-gap-is-undermining-transformation-and-how-to-close-it

[4] KfW Research: „KfW-Digitalisierungsbericht Mittelstand 2025“
https://www.kfw.de/PDF/Download-Center/Konzernthemen/Research/PDF-Dokumente-Digitalisierungsbericht-Mittelstand/KfW-Digitalisierungsbericht-2025.pdf

Welche interessanten Links vertiefen das Thema?

Interessante Links

Mittelstand-Digital: Prozesse digitalisieren
https://www.mittelstand-digital.de/MD/Navigation/DE/Themen/Prozesse-Digitalisieren/Digitalisierung-Prozesse/digitalisierung-prozesse.html

Government Digital Service: Wie eine Discovery-Phase funktioniert
https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works

OECD: Technikeinführung in kleinen und mittleren Unternehmen – Erkenntnisse aus der Praxis
https://www.oecd.org/en/publications/sme-technology-adoption-in-the-united-kingdom_5f25ce2a-en/full-report/main-findings-from-the-consultation-process_5320b0bc.html

Warum scheitern Digitalisierungsprojekte besonders häufig im Mittelstand?

Mittelständische Unternehmen verfügen oft über wenig freie Projektkapazität, während wichtiges Prozesswissen auf einzelne erfahrene Mitarbeiter verteilt ist. Das Tagesgeschäft hat Vorrang, Entscheidungen verzögern sich und Anforderungen werden nebenbei erhoben. Wird dann eine umfangreiche Standardlösung eingeführt, ohne reale Fälle ausreichend zu prüfen, entstehen Zusatzaufwand, Nebenlisten und geringe Akzeptanz.

Ist meistens die ausgewählte Software schuld?

Nicht zwingend. Eine Software kann ungeeignet sein, doch häufig liegen die Ursachen in nicht geregelten Abläufen, widersprüchlichen Anforderungen oder fehlenden Zuständigkeiten. Selbst ein leistungsfähiges System liefert wenig Nutzen, wenn es einen umständlichen Prozess übernimmt. Die Produktauswahl sollte deshalb erst erfolgen, nachdem der betriebliche Anwendungsfall, die Daten und die erforderlichen Entscheidungen verstanden wurden.

Wie erkennt man einen geeigneten ersten Anwendungsfall?

Ein guter Einstieg betrifft einen häufigen Vorgang, der spürbaren Aufwand, wiederkehrende Fehler oder viele Rückfragen verursacht. Der Ablauf sollte organisatorisch beeinflussbar und sein Ergebnis beobachtbar sein. Geeignet sind beispielsweise Kundenanfragen, Einsatzdokumentationen, Angebotsvorbereitungen oder interne Freigaben. Weniger geeignet sind seltene Sonderfälle mit vielen externen Abhängigkeiten und kaum verfügbaren Daten.

Sollten bestehende Prozesse vor der Digitalisierung immer verändert werden?

Nicht jeder Prozess muss vollständig neu gestaltet werden. Manche Abläufe bestehen aus gutem Grund, etwa wegen gesetzlicher Anforderungen, Sicherheitsvorgaben oder Kundenvereinbarungen. Dennoch sollte geprüft werden, welche Schritte tatsächlich Wert erzeugen, welche nur historische Gewohnheiten darstellen und wo Informationen mehrfach erfasst werden. Erst danach lässt sich entscheiden, was beibehalten, vereinfacht oder automatisiert wird.

Wie stark müssen Mitarbeiter in das Projekt einbezogen werden?

Mitarbeiter sollten nicht nur am Ende geschult, sondern während Analyse, Prototyping und Erprobung beteiligt werden. Sie kennen Ausnahmen, Zeitdruck, Kundenreaktionen und informelle Übergaben, die in Verfahrensbeschreibungen oft fehlen. Ihre Beteiligung bedeutet jedoch nicht, jeden Einzelwunsch umzusetzen. Entscheidend ist, wiederkehrende betriebliche Bedürfnisse von persönlichen Vorlieben zu unterscheiden.

Welche Aufgabe hat die Geschäftsführung in einem Digitalisierungsprojekt?

Die Geschäftsführung setzt den geschäftlichen Zweck, priorisiert Ressourcen und entscheidet bei Konflikten zwischen Bereichen. Sie muss nicht jede Maske oder Schnittstelle bewerten, darf das Vorhaben aber auch nicht vollständig an IT oder Anbieter delegieren. Besonders wichtig sind ein verantwortlicher Entscheider, verbindliche Erfolgskriterien und die Bereitschaft, bei Bedarf auch organisatorische Regeln zu verändern.

Wann sollte ein Digitalisierungsprojekt gestoppt werden?

Ein Stopp ist sinnvoll, wenn der erwartete Nutzen nicht mehr trägt, entscheidende Voraussetzungen dauerhaft fehlen oder die Lösung nur mit unverhältnismäßigem Zusatzaufwand betrieben werden kann. Bereits investiertes Geld ist kein ausreichender Grund für die Fortsetzung. Ein früher Abbruch nach einer Untersuchungs- oder Pilotphase kann Ressourcen schützen und wertvolle Erkenntnisse für einen besseren Ansatz liefern.

Welche Kennzahlen eignen sich zur Erfolgsmessung?

Geeignete Kennzahlen hängen vom Anwendungsfall ab. Häufig relevant sind Bearbeitungszeit, Rückfragen, unvollständige Vorgänge, Nacharbeit, Suchaufwand, manuelle Übertragungen und Wartezeiten zwischen Rollen. Im Service können Erstlösungsquote und Dokumentationsqualität hinzukommen, im Vertrieb die Zeit bis zum Angebot. Gemessen werden sollte möglichst vor und nach der Einführung unter vergleichbaren Bedingungen.

Warum entstehen nach einer Einführung häufig Excel-Nebenlisten?

Nebenlisten entstehen, wenn das offizielle System eine wichtige Information, Entscheidung oder Übersicht nicht ausreichend unterstützt. Mitarbeiter bauen dann eine pragmatische Ergänzung, um ihren Arbeitsauftrag zu erfüllen. Das sollte als Diagnosehinweis betrachtet werden. Das Projektteam muss prüfen, welcher Bedarf dahintersteht, ob Daten fehlen oder ob das System den tatsächlichen Arbeitsablauf zu stark vereinfacht.

Welche Rolle spielt Unternehmenswissen für erfolgreiche Digitalisierung?

Unternehmenswissen verbindet Daten mit Bedeutung. Es erklärt, welche Regel in welcher Situation gilt, welche Ausnahme zulässig ist und welche Erfahrung bei einer Entscheidung hilft. Bleibt dieses Wissen außerhalb der Software, müssen Mitarbeiter weiterhin suchen oder Kollegen fragen. Eine gepflegte Wissensbasis macht digitale Prozesse belastbarer, reduziert Abhängigkeiten und unterstützt neue Mitarbeiter bei der Einarbeitung.

Alle Artikel zum Thema Digitalisierung im Mittelstand