Digitalisierungs-Roadmap erstellen: Von der Bestandsaufnahme bis zur Umsetzung

Eine Digitalisierungs-Roadmap zu erstellen bedeutet nicht, Softwareprojekte auf einer Zeitachse zu verteilen. Wenn CRM, Kundenportal, ERP-Ablösung und KI-Assistent parallel im ersten Quartal beginnen sollen, fehlt meist keine hübschere Darstellung. Es fehlen Entscheidungen über Abhängigkeiten, Fachkapazität und die Reihenfolge, in der Daten und Prozesse belastbar werden.

Eine brauchbare Roadmap zeigt, welche betriebliche Fähigkeit entstehen soll, welche Grundlagen dafür nötig sind und wann eine Annahme überprüft wird. Sie verbindet strategische Prioritäten mit umsetzbaren Arbeitspaketen. Termine sind dabei wichtig, aber erst nach Ziel, Abhängigkeit und Verantwortung.

Digitalisierungs-Roadmap erstellen: Was sie leisten muss

Die Roadmap beantwortet fünf operative Fragen:

• Welche Vorhaben tragen nachweisbar zum Zielbild bei?
• Welche fachlichen oder technischen Voraussetzungen müssen vorher erfüllt sein?
• Welche Mitarbeiter werden für Analyse, Entscheidung, Test und Einführung benötigt?
• An welchen Punkten wird über Fortsetzung, Anpassung oder Abbruch entschieden?
• Wer verantwortet den späteren Betrieb?

Damit unterscheidet sie sich von anderen Planungsdokumenten. Die Digitalisierungsstrategie legt Zielbild und Prioritäten fest. Die Roadmap ordnet Vorhaben und Abhängigkeiten über einen realistischen Zeitraum. Der Projektplan beschreibt anschließend konkrete Aufgaben, Termine und Liefergegenstände eines einzelnen Vorhabens.

Eine Beratung zur digitalen Transformation kann Strategie und Roadmap miteinander verbinden. Die Reihenfolge darf jedoch nicht allein aus technischer Sicht entstehen. Wenn mehrere Bereiche dieselben Fachkräfte oder Daten benötigen, muss die Geschäftsleitung Prioritätskonflikte entscheiden.

Vor der Roadmap den Planungsauftrag festlegen

Ohne abgegrenzten Auftrag wächst eine Roadmap schnell zur vollständigen Wunschliste des Unternehmens. Der Auftrag nennt deshalb Anlass, betrachtete Wertschöpfungskette, Zeithorizont, verfügbare Kapazität und erwartete Entscheidungen.

Für einen Wartungsbetrieb könnte er lauten: „Die Roadmap ordnet alle Maßnahmen, die in den kommenden 18 Monaten Anfrage, Einsatzplanung, mobilen Leistungsnachweis und Abrechnung durchgängiger machen. Sie berücksichtigt die begrenzte Mitarbeit von Vertrieb, Disposition und zwei Servicetechnikern.“

Auch feste Rahmenbedingungen gehören hinein. Ein auslaufender Softwarevertrag kann eine technische Ablösung erzwingen. Eine bevorstehende Hochsaison kann den Produktivstart eines neuen Buchungssystems begrenzen. Ein laufendes Kundenprojekt kann dieselben Entwickler oder Prozessverantwortlichen beanspruchen.

Der Zeithorizont sollte weit genug für relevante Abhängigkeiten reichen, aber keine Scheingenauigkeit erzeugen. Für weiter entfernte Vorhaben genügt eine grobe Einordnung. Detaillierte Monatspläne sind erst sinnvoll, wenn Anforderungen, Verantwortliche und Voraussetzungen geklärt sind.

Bestandsaufnahme anhand realer Abläufe

Die Roadmap beginnt nicht mit der vorhandenen Softwareliste. Sie beginnt mit den Abläufen, die ein Geschäftsergebnis erzeugen. Für einen Angebotsprozess werden reale Anfragen vom Eingang bis zur Übergabe an den Auftrag untersucht.

Der Leitfaden Geschäftsprozesse analysieren beschreibt, wie Auslöser, Rollen, Systeme, Wartezeiten und Nacharbeit erfasst werden. Für die Roadmap sind besonders Engpässe relevant, die mehrere Vorhaben beeinflussen.

Ein Beispiel: Vertrieb und Service möchten jeweils eine neue Anwendung. In der Analyse zeigt sich, dass beide dieselben Kundenanlagen verwenden, deren Nummern in mehreren Tabellen unterschiedlich geführt werden. Die gemeinsame Datenklärung muss vor beiden Projekten oder als erstes gemeinsames Arbeitspaket eingeplant werden.

Die Bestandsaufnahme liefert mindestens:

Eine Bestandsaufnahme muss nicht monatelang dauern. Sie muss aber genügend reale Fälle enthalten, um Sonderwege und informelle Arbeit sichtbar zu machen.

Zielzustände statt Produktnamen formulieren

„CRM einführen“ oder „Portal entwickeln“ sind keine ausreichenden Roadmap-Ziele. Sie beschreiben Lösungen, nicht den betrieblichen Zustand nach der Umsetzung.

Ein belastbarer Zielzustand lautet beispielsweise: „Qualifizierte Anfragen enthalten alle kalkulationsrelevanten Daten, werden einer verantwortlichen Person zugewiesen und erhalten innerhalb der intern festgelegten Frist eine nächste Aktion.“ Daraus können ein CRM, ein Anfrageformular, neue Preisregeln oder eine Schnittstelle folgen.

Für jeden Zielzustand werden drei Dinge dokumentiert:

1. gewünschte Geschäftswirkung
2. beobachtbare Änderung im Prozess
3. intern definierte Kennzahl oder Entscheidungskriterium

Die Prozessoptimierung im Unternehmen hilft, Symptome von Ursachen zu unterscheiden. Wenn Angebote verspätet versendet werden, kann die Ursache in fehlenden Kundendaten, unklaren Preisregeln oder einer überlasteten Freigaberolle liegen. Ein neues CRM löst diese Probleme nicht automatisch.

Vorhaben in entscheidungsfähige Bausteine zerlegen

Große Programmnamen verdecken oft mehrere unterschiedliche Risiken. „Kundenportal“ kann Datenbereinigung, Berechtigungskonzept, Schnittstellen, Benutzeroberfläche, Dokumentenlogik und Supportprozess enthalten. Werden diese Bestandteile als ein Block geplant, bleibt unklar, was zuerst gelernt oder entschieden werden muss.

Jedes Roadmap-Vorhaben erhält deshalb einen Steckbrief:

• Zielzustand und erwartete Wirkung
• betroffene Prozesse und Rollen
• benötigte Daten und Systeme
• fachliche und technische Voraussetzungen
• Pilotumfang
• interner und externer Aufwand
• Betriebsverantwortung
• Entscheidungskriterien

Ein Vorhaben darf in Grundlagen, Pilot und Ausbau geteilt werden. Das ist keine künstliche Projektverkleinerung. Es erlaubt, kritische Annahmen zu prüfen, bevor Migration oder Rollout hohe Folgekosten erzeugen.

Bei regelbasierten Übergaben kann eine Workflow-Automatisierung für KMU ein eigener Baustein sein. Sind Entscheidungsregeln noch nicht dokumentiert, gehört die Prozessklärung davor.

Abhängigkeiten sichtbar machen

Die wichtigste Funktion einer Roadmap ist häufig nicht die Zeitplanung, sondern die Darstellung von Abhängigkeiten. Sie verhindert, dass mehrere Projekte gleichzeitig auf ungeklärte Daten oder dieselben Fachrollen zugreifen.

Abhängigkeiten entstehen in vier Formen:

• fachlich: Preis- oder Freigaberegeln müssen beschlossen sein.
• datenbezogen: Kunden, Produkte oder Anlagen benötigen eindeutige Schlüssel.
• technisch: Ein System oder eine Schnittstelle muss verfügbar sein.
• organisatorisch: Rollen, Schulung oder Betriebsverantwortung müssen geklärt werden.

Für Systemverbindungen ist vor der API-Entwicklung festzulegen, welches System welche Daten führen darf und wie Übertragungsfehler behandelt werden. Die technische Schnittstelle kann erst danach sinnvoll spezifiziert werden.

Ein einfaches Abhängigkeitsdiagramm reicht meist aus. Vorhaben werden als Knoten dargestellt, Voraussetzungen als gerichtete Verbindungen. Kritisch sind Knoten, von denen mehrere spätere Maßnahmen abhängen. Ihre Verzögerung verändert die gesamte Roadmap und braucht besondere Aufmerksamkeit.

Prioritäten nachvollziehbar bewerten

Nicht jedes wichtige Vorhaben kann sofort beginnen. Eine Bewertung kombiniert Geschäftswirkung, Dringlichkeit, Aufwand, Risiko, Abhängigkeit und Lernwert.

Punktwerte unterstützen die Diskussion, ersetzen aber keine Begründung. Ein Stammdatenprojekt kann eine geringe unmittelbare Umsatzwirkung haben und trotzdem zuerst kommen, weil Kundenportal, Automatisierung und Reporting davon abhängen.

Auch ein hoher Nutzen rechtfertigt keine sofortige Umsetzung, wenn der Betrieb nicht abgesichert ist. Eine Buchungsplattform ohne verantwortliche Rolle für Preisregeln, Stornierungen und Zahlungsfehler erzeugt nach dem Start neue manuelle Arbeit.

Fachkapazität realistisch einplanen

Der häufigste Engpass einer Digitalisierungs-Roadmap ist nicht das externe Entwicklungsbudget. Es sind Mitarbeiter, die ihren Prozess erklären, Regeln entscheiden, Daten bereinigen, Testfälle prüfen und Kollegen einarbeiten müssen.

Für jedes Vorhaben wird der Bedarf pro Rolle geschätzt. Eine Schätzung in Arbeitstagen oder Stunden ist zunächst ausreichend, wenn ihre Unsicherheit sichtbar bleibt. Entscheidend ist der Abgleich mit tatsächlich verfügbarer Zeit neben dem Tagesgeschäft.

Ein Prozessverantwortlicher kann nicht gleichzeitig ERP-Migration, CRM-Einführung und Kundenportal fachlich führen, wenn alle drei Projekte wöchentliche Entscheidungen und Abnahmen verlangen. Die Roadmap muss Vorhaben verschieben oder zusätzliche Verantwortung aufbauen.

Auch Spitzenlasten zählen. Datenmigration und Abnahmetest beanspruchen Fachbereiche oft stärker als die frühe Konzeption. Ein scheinbar freier Monat kann durch Jahresabschluss, Saison oder Urlaubszeit ungeeignet sein.

Zeiträume ohne Scheingenauigkeit planen

Für weiter entfernte Vorhaben eignen sich Horizonte wie „jetzt“, „als Nächstes“ und „später“. Konkrete Monate werden erst vergeben, wenn Voraussetzungen und Ressourcen ausreichend geklärt sind.

Eine Roadmap kann beispielsweise drei Ebenen enthalten:

• 0–3 Monate: Grundlagen klären und zentrale Annahmen testen.
• 3–9 Monate: priorisierte Piloten umsetzen und auswerten.
• 9–18 Monate: bewährte Lösungen ausbauen und abhängige Vorhaben starten.

Diese Zeiträume sind kein allgemeiner Standard. Sie werden an Projektgröße, Saison und interner Kapazität angepasst. Entscheidend ist, dass sich ein weiter entferntes Vorhaben nicht mit einem scheinbar verbindlichen Startdatum schmückt, obwohl sein Vorgänger noch nicht entschieden ist.

Pilotprojekte und Entscheidungstore definieren

Ein Pilot ist kein verkleinerter Rollout. Er prüft eine konkrete Annahme unter begrenzten Bedingungen. Für ein Kundenportal kann die Annahme lauten, dass eine ausgewählte Kundengruppe Auftragsstatus selbst abruft und dadurch weniger telefonische Rückfragen entstehen.

Vor dem Pilot werden Umfang, Zielgruppe, Messung und Abbruchkriterien festgelegt. Danach folgt ein Entscheidungstor:

• fortsetzen: Die Annahme trägt und bekannte Anpassungen sind beherrschbar.
• anpassen: Der Nutzen ist erkennbar, Prozess oder Lösung braucht einen neuen Zuschnitt.
• stoppen: Wirkung, Nutzbarkeit oder Betriebsaufwand rechtfertigen den Ausbau nicht.

Ein Entscheidungstor ist nur wirksam, wenn ein Projekt tatsächlich beendet werden darf. Wird jeder Pilot unabhängig vom Ergebnis zum Rollout weitergeführt, dient er lediglich als Präsentationsphase.

Kosten und Wirtschaftlichkeit in der Roadmap berücksichtigen

Die Kostensicht umfasst Lizenzen oder Entwicklung, Migration, Schnittstellen, Datenbereinigung, Schulung, Support und spätere Anpassung. Ebenso gehört interne Fachzeit in die Planung.

Nutzenannahmen werden aus dem eigenen Betrieb abgeleitet. Bei einem Angebotsprozess können aktuelle Bearbeitungszeit, Rückfragen und Abbruchgründe erhoben werden. Ein Pilot ersetzt Schätzungen anschließend durch reale Werte.

Eine Roadmap sollte finanzielle Freigaben stufenweise ordnen. Budget für Analyse und Prototyp muss nicht automatisch das vollständige Rollout-Budget auslösen. So bleibt eine wirtschaftliche Entscheidung möglich, nachdem kritische Annahmen geprüft wurden.

Bestehende Systeme bewusst einordnen

Digitale Transformation verlangt keinen Komplettaustausch der IT-Landschaft. Ein stabiles ERP kann weiterhin Aufträge, Bestände und Rechnungen führen, während ein neuer Kundenkanal andere Fähigkeiten ergänzt.

Der Artikel zum ERP-System für kleine Unternehmen hilft bei der Einordnung zentraler kaufmännischer Systeme. Die Roadmap muss festhalten, welche Funktion bestehen bleibt, welche Anwendung abgelöst wird und wie lange ein Parallelbetrieb notwendig ist.

Eine übergreifende Softwarearchitektur wird relevant, wenn mehrere Vorhaben dieselben Systeme verändern. Ohne gemeinsame Leitplanken können lokale Lösungen neue Abhängigkeiten schaffen, die spätere Projekte verteuern.

Roadmap im Betrieb steuern

Eine beschlossene Roadmap ist kein unveränderlicher Vertrag. Erkenntnisse aus Piloten, Anbieteränderungen, Sicherheitsereignisse oder neue Geschäftsziele können die Reihenfolge verändern. Anpassungen müssen jedoch begründet und dokumentiert werden.

Ein regelmäßiges Review prüft:

• Ist das zugrunde liegende Geschäftsproblem weiterhin relevant?
• Wurden Voraussetzungen erfüllt oder sind neue Abhängigkeiten entstanden?
• Reicht Fachkapazität für den nächsten Abschnitt?
• Bestätigt der Pilot die erwartete Wirkung?
• Muss ein Vorhaben verschoben, geteilt oder beendet werden?

Neue Ideen werden nicht direkt als zusätzlicher Balken eingetragen. Sie erhalten zunächst denselben Steckbrief und dieselbe Bewertung wie bestehende Vorhaben. Anschließend wird sichtbar gemacht, welches Budget, welche Fachkapazität oder welches geplante Vorhaben sie verdrängen würden. Diese Regel schützt die Roadmap vor ständig wachsendem Parallelbetrieb.

Änderungen brauchen außerdem einen kurzen Entscheidungsvermerk: Anlass, betroffene Abhängigkeiten, neue Reihenfolge und verantwortlicher Beschluss. So lässt sich später unterscheiden, ob ein Termin wegen einer belegten Erkenntnis angepasst wurde oder weil eine Priorität informell wechselte. Abgelehnte und zurückgestellte Ideen bleiben in einem separaten Speicher mit Begründung erhalten. Sie verschwinden nicht, belasten aber nicht die aktive Planung.

Der Beitrag zum Change Management bei der Digitalisierung zeigt, wie Einführung und Rollen an tatsächlichen Arbeitsfällen ausgerichtet werden. In der Roadmap sollte deshalb nicht nur „Schulung“ stehen, sondern wer welche Fälle vor Produktivstart beherrschen muss und welcher alte Arbeitsweg anschließend entfällt.

Werkzeugwahl: Eine Tabelle kann ausreichen

Eine Roadmap benötigt nicht zwingend Spezialsoftware. Für wenige Vorhaben kann eine Tabelle mit Verantwortlichen, Zielzustand, Abhängigkeiten, Aufwand, Status und nächstem Entscheidungstor vollständig genügen.

Ein Portfoliowerkzeug wird sinnvoll, wenn viele Projekte dieselben Ressourcen beanspruchen, mehrere Standorte beteiligt sind oder verschiedene Planungsebenen konsistent gehalten werden müssen. Das Werkzeug löst aber keine ungeklärte Priorität. Es visualisiert lediglich die eingetragenen Entscheidungen.

Wichtig sind Versionsstand und Verantwortlichkeit. Mitarbeiter müssen erkennen, welche Roadmap beschlossen ist, wer Änderungen einträgt und wo Begründungen dokumentiert werden.

Praxisbeispiel: Ein Kundenportal beginnt mit Daten und Pilot

Das folgende Beispiel ist hypothetisch. Ein technischer Großhändler plant CRM, Kundenportal, automatisierte Angebote und ein neues Reporting. Zunächst sollen alle Projekte parallel starten.

Die Bestandsaufnahme zeigt, dass Kundenadressen in ERP und Vertriebslisten voneinander abweichen. Produktverfügbarkeiten werden erst nach Rückfrage bestätigt. Angebotsstatus sind nicht einheitlich definiert. Für alle vier Vorhaben fehlen damit gemeinsame Grundlagen.

Die Roadmap ordnet die Arbeit neu:

1. Kunden- und Produktdaten erhalten eindeutige Quellen und Verantwortliche.
2. Angebotsstatus und Freigaberegeln werden anhand realer Fälle definiert.
3. Ein CRM-Pilot übernimmt nur eine ausgewählte Kundengruppe.
4. Die Schnittstelle zum ERP wird mit Fehlerüberwachung getestet.
5. Ein begrenztes Portal zeigt zunächst freigegebene Dokumente und Auftragsstatus.
6. Automatisierte Angebote folgen für Produkte mit belastbarer Preis- und Verfügbarkeitslogik.
7. Reporting wird aufgebaut, sobald Status und Datenquellen stabil sind.

Nach jedem Pilot entscheidet das Unternehmen über Ausbau oder Korrektur. Die Roadmap verschiebt sichtbare Funktionen zugunsten ihrer Voraussetzungen. Dadurch wird die Umsetzung nicht langsamer, sondern entscheidungsfähig.

Typische Fehler bei Digitalisierungs-Roadmaps

Ein häufiger Fehler ist eine reine Softwareliste. Ein zweiter ist die parallele Planung ohne gemeinsame Fachkapazität. Auch feste Termine für ungeklärte Vorhaben erzeugen Scheinsicherheit.

Weitere Probleme entstehen, wenn Grundlagenprojekte ohne sichtbare Geschäftswirkung nicht priorisiert werden, Piloten keine Entscheidungskriterien besitzen oder der spätere Betrieb fehlt. Eine Lösung kann termingerecht live gehen und trotzdem außerhalb der Roadmap neue Support- und Pflegearbeit verursachen.

Zu viele Details sind ebenfalls hinderlich. Eine Roadmap sollte Abhängigkeiten und Entscheidungen zeigen. Einzelne Entwicklungsaufgaben gehören in den jeweiligen Projektplan.

Eine externe IT-Beratung und Projektplanung ist hilfreich, wenn technische Abhängigkeiten schwer einzuschätzen sind, Bereiche um dieselben Ressourcen konkurrieren oder Anbieter bereits unterschiedliche Lösungen vorschlagen. Die geschäftliche Priorität bleibt eine Entscheidung des Unternehmens.

Der erste Schritt ist eine Liste von höchstens den Vorhaben, die in den gewählten Zeithorizont passen. Ergänzen Sie für jedes Vorhaben Zielzustand, Voraussetzung, benötigte Fachrollen und nächsten Entscheidungspunkt. Sortieren Sie anschließend nicht nach gewünschtem Startdatum, sondern nach Abhängigkeit. Daraus entsteht das tragfähige Grundgerüst der Roadmap.