Was kostet die Digitalisierung eines Geschäftsprozesses?

Ein Geschäftsprozess kann eine überschaubare interne Freigabe oder ein unternehmenskritischer Ablauf über mehrere Abteilungen und Systeme sein. Beide Vorhaben heißen Prozessdigitalisierung, unterscheiden sich aber grundlegend in Fachlichkeit, Risiko und technischem Umfang.

Für die Kalkulation reicht es daher nicht zu wissen, dass heute E-Mail und Excel verwendet werden. Relevant ist, wie viele Schritte und Varianten bestehen, welche Daten verarbeitet werden, welche Systeme beteiligt sind und welches Ergebnis künftig zuverlässig erreicht werden muss. Ebenso wichtig ist die Frage, ob ein vorhandenes System besser konfiguriert, eine Schnittstelle gebaut oder eine eigene Anwendung entwickelt wird.

Ohne diese Informationen wäre ein konkreter Betrag vor allem eine Ansammlung von Annahmen. Eine erste Einordnung kann Bandbreite und Kostentreiber benennen; ein belastbarer Preis benötigt einen definierten Scope.

Der Funktionsumfang ist nur ein Teil der Kalkulation. Aufwand entsteht auch dort, wo Systeme sicher zusammenarbeiten, Daten bereinigt, Rechte geregelt und ein neuer Ablauf eingeführt werden müssen.

Besonders relevant sind:

• Anzahl und Abhängigkeit der Prozessschritte,
• Nutzergruppen, Rollen und Berechtigungen,
• beteiligte Systeme und verfügbare Schnittstellen,
• Qualität, Umfang und Herkunft der Daten,
• Regeln, Ausnahmen und notwendige menschliche Entscheidungen,
• Anforderungen an Datenschutz, Sicherheit und Nachvollziehbarkeit,
• Tests, Migration, Schulung, Rollout und Betrieb.

Nicht jeder zusätzliche Prozessschritt verursacht den gleichen Aufwand. Ein einfacher Statuswechsel ist etwas anderes als eine Entscheidung mit mehreren Datenquellen, Berechtigungen und rechtlichen Folgen. Deshalb wird nicht nur gezählt, sondern fachlich bewertet.

Eine vollständige Kalkulation betrachtet nicht nur die Programmierung. Schon vor der Umsetzung entstehen notwendige Ergebnisse: Der Ist-Prozess wird aufgenommen, das Zielbild abgestimmt und die technische Lösung gewählt. Anschließend folgen Entwicklung oder Konfiguration, Integration, Datenübernahme, Tests und Einführung.

Eine sinnvolle Phasenfolge lautet:

1. Analyse: tatsächlichen Ablauf, Probleme, Daten und Systeme verstehen.
2. Konzeption: Soll-Prozess, Anforderungen, Architektur und Scope festlegen.
3. Umsetzung: Software entwickeln oder vorhandene Systeme konfigurieren.
4. Integration: Datenflüsse und beteiligte Anwendungen verbinden.
5. Migration: relevante Bestandsdaten prüfen, bereinigen und übernehmen.
6. Tests: fachliche Abläufe, Berechtigungen, Fehlerfälle und Qualität validieren.
7. Einführung: Nutzer vorbereiten, Rollout durchführen und Betrieb stabilisieren.
8. Betrieb: Updates, Monitoring, Backups und Support organisieren.

Nicht jedes Vorhaben benötigt jede Phase im gleichen Umfang. Auslassen sollte man sie aber nur nach bewusster Prüfung.

Der ideale Standardfall ist schnell beschrieben. Aufwand entsteht oft an den Rändern: Was passiert bei unvollständigen Daten? Wer darf eine Entscheidung korrigieren? Wie wird ein Fehler in einer Schnittstelle sichtbar? Welche Datei ist die gültige Quelle?

Häufig erst spät berücksichtigt werden Ausnahmefälle, Datenbereinigung, Berechtigungskonzepte, fehlende oder eingeschränkte APIs, realistische Testdaten und die Beteiligung der Fachabteilung. Hinzu kommen Fehlerbehandlung, Monitoring, Rollout-Kommunikation und die Frage, wie ein laufender Betrieb während der Umstellung weiterarbeitet.

Diese Aufgaben sind keine technische Nebensache. Sie bestimmen, ob eine Lösung im Alltag verlässlich eingesetzt werden kann. In der Implementierung werden Migration, Abnahme und Einführung deshalb nicht erst nach der Entwicklung geplant.

Der wirksamste Hebel ist häufig nicht günstigere Entwicklung, sondern ein einfacherer Prozess. Jeder entfallende Sonderweg muss nicht modelliert, programmiert, getestet und später gepflegt werden. Die Prozessoptimierung prüft deshalb, welche Schritte entfernt, vereinheitlicht oder organisatorisch geklärt werden können.

Weitere Hebel sind:

• den Scope nach fachlichem Nutzen priorisieren,
• eine erste Ausbaustufe klar und vollständig abgrenzen,
• vorhandene Systeme und Funktionen bewusst weiterverwenden,
• Integrationsmöglichkeiten und Zugriff früh verifizieren,
• Datenqualität vor der Migration untersuchen,
• Rollen und Akzeptanzkriterien vor der Umsetzung festlegen,
• wiederkehrende Komponenten nur dort individuell entwickeln, wo der Prozess es erfordert.

Ein MVP ist nur dann kostensparend, wenn er einen nutzbaren durchgängigen Teilprozess abbildet. Eine Ansammlung halbfertiger Funktionen verschiebt Aufwand meist nur in spätere Phasen.

Wenn Soll-Prozess, Funktionen, Integrationen, Datenmigration und Abnahme ausreichend konkret sind, lässt sich der vereinbarte Umfang kalkulieren. Vorher kann eine Schätzung der Orientierung dienen, sollte aber ihre Annahmen und Unsicherheiten offenlegen.

Die vertiefende Entscheidungshilfe zur Softwareentwicklung zum Festpreis behandelt die Voraussetzungen eines belastbaren Preises und den kontrollierten Umgang mit Änderungen. Im Vorgehensmodell entstehen Ist-Prozess, Soll-Prozess, Anforderungen und Scope als aufeinander aufbauende Ergebnisse.

Für ein erstes Gespräch ist kein fertiges Pflichtenheft notwendig. Hilfreich ist ein konkreter, tatsächlich ausgeführter Ablauf. Beschreiben Sie, was den Prozess auslöst, welche Rollen beteiligt sind, welche Systeme und Dateien verwendet werden und wo heute manuelle Arbeit oder Fehler entstehen.

Für die Einordnung helfen insbesondere:

• eine knappe Beschreibung des aktuellen Ablaufs,
• beteiligte Rollen und Verantwortlichkeiten,
• vorhandene Systeme, Datenquellen und Dokumente,
• Häufigkeit und grobe Größenordnung der Vorgänge,
• wichtige Ausnahmen und Fehlerfolgen,
• das gewünschte fachliche Ergebnis,
• betriebliche oder zeitliche Rahmenbedingungen.

Die Größenordnung dient dabei nicht als isolierter Multiplikator. Zehn komplexe Fälle können anspruchsvoller sein als viele vollständig standardisierte Vorgänge.

Angenommen, Anfragen werden heute aus einem Postfach in eine Tabelle übertragen und später in ein Bestandssystem eingegeben. Eine erste Ausbaustufe könnte nur die strukturierte Erfassung und Validierung ersetzen. Eine weitergehende Lösung ergänzt Rollen, Freigaben, Schnittstelle, Statuskommunikation und Migration alter Vorgänge.

Beide Varianten betreffen denselben Prozess, liefern aber unterschiedliche Ergebnisse. Die sinnvolle Entscheidung richtet sich danach, welcher durchgängige Teilprozess den größten fachlichen Nutzen bringt und welche Abhängigkeiten bestehen. Dieses ausdrücklich hypothetische Beispiel zeigt, warum ein Preis ohne Scope wenig aussagt – nicht, welche Variante in einem konkreten Unternehmen richtig wäre.

Die Kosten einer Prozessdigitalisierung lassen sich transparent erklären, aber nicht seriös aus einem Schlagwort ableiten. Entscheidend sind Umfang und Kritikalität des Prozesses, Rollen, Daten, Schnittstellen, Sonderfälle sowie Migration und Einführung. Eine frühe Analyse macht diese Faktoren sichtbar. Danach kann der Zielprozess vereinfacht, der Scope priorisiert und ein belastbarer Umsetzungsrahmen kalkuliert werden – ohne erfundene Pauschalbeträge.