Der Business Case für Konsolidierung: So begründen deutsche Unternehmen eine zentrale Plattform

TL;DR (Quick Summary)

Ein tragfähiger Business Case für Tool-Konsolidierung braucht mehr als die Hoffnung auf weniger Lizenzen. Er muss zeigen, was der heutige Zustand wirklich kostet, was die zentrale Plattform konkret ersetzt und wie das Risiko der Umstellung beherrscht wird.

• Ausgangslage erfassen: Systeme, Verträge und Prozessbrüche sichtbar machen.
• Kosten-Baseline erstellen: heutige Kosten verdichten und managementtauglich darstellen.
• Zielzustand modellieren: Nutzen konkret und prüfbar beschreiben.
• Risiken bewerten: Migrationsaufwand und kritische Annahmen offenlegen.

Takeaway: Genehmigt wird selten die beste Plattform, sondern der am besten begründete Weg dorthin. Wer Scope, Nutzen, Risiko und nächste Entscheidung sauber trennt, erhöht die Freigabechance deutlich.

---

Viele interne Vorschläge zur Plattform-Konsolidierung scheitern nicht an der Technologie, sondern an der Vorlage. Sie sagen, dass Tools reduziert werden sollen, lassen aber offen, was genau beschlossen werden soll, was der Status quo kostet und wie die Umstellung ohne Betriebschaos abläuft. Ein genehmigungsfähiger Business Case braucht einen engen Entscheidungsrahmen, eine belastbare Ist-Basis, ein nachvollziehbares Zielbild, eine offene Risikobewertung und klare Freigabepunkte.

Das gilt unabhängig davon, welche Plattform am Ende gewählt wird – ob eine All-in-One-Lösung wie Bitrix24 oder ein Verbund aus wenigen Kernsystemen. Wer nur weniger Tools verspricht, ohne die heutigen Kosten transparent zu machen oder den Migrationspfad zu beschreiben, überzeugt keine Geschäftsführung.

Den Entscheidungsrahmen festlegen: Wofür die zentrale Plattform intern genehmigt werden soll

Der erste Fehler passiert oft ganz am Anfang: Der Vorschlag wird als allgemeiner „Tool-Wechsel“ formuliert. Damit kann die Geschäftsführung wenig anfangen. Sie braucht eine konkrete Entscheidung mit Budget, Zeitrahmen und Verantwortlichen.

Formulieren Sie deshalb von Beginn an, welche Freigabe Sie erreichen wollen. Geht es um Mittel für eine Vorstudie, einen Pilot in einem abgegrenzten Bereich, die erste Migrationsphase oder die vollständige Konsolidierung über mehrere Funktionen hinweg?

Ein guter Entscheidungsrahmen beantwortet drei Fragen in einem Satz:

• Was soll freigegeben werden?
• Wofür wird das Budget eingesetzt?
• Bis wann liegt welches Ergebnis vor?

Also nicht „Wir möchten unsere Tool-Landschaft konsolidieren“, sondern: „Wir beantragen die Freigabe für eine stufenweise Konsolidierung der Systeme für Vertrieb, Service und Reporting auf eine zentrale Plattform – zunächst mit Budget für Analyse, Pilot und erste Migrationen sowie einem benannten Projektteam.“

Die Geschäftsführung bewertet typischerweise fünf Punkte:

• Wirtschaftlichkeit: Was kostet der Status quo, was kostet die Umstellung, wann zeigt sich der Nutzen?
• Risiko: Welche Betriebs-, Datenschutz- oder Abhängigkeitsrisiken entstehen oder entfallen?
• Umsetzbarkeit: Sind Team, Datenlage und Prozesse reif genug?
• Operative Kontinuität: Bleiben Vertrieb, Service, Buchhaltung und Reporting arbeitsfähig?
• Zeitpunkt des Nutzens: Warum jetzt und nicht in zwölf Monaten?

Wenn Sie diese Kriterien nicht selbst adressieren, stellt die Geschäftsführung sie im Termin – und Ihr Vorschlag gerät in die Defensive.

[BANNER type="lead_banner_1" title="Baukasten für Plattform-Nutzen: Kostenmodell und Entscheidungsvorlage" description="Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten" picture-src="/upload/medialibrary/c0f/04zrwoo0jpzvirn15czqu595pynw0yl9.webp" file-path="/upload/medialibrary/615/nwowune303l2bp7b04z13d4ru4jq3xnn.pdf"]

Die Ausgangslage belastbar erfassen: Systemlandschaft, Verträge und Prozessbrüche inventarisieren

Bevor über Einsparungen oder Standardisierung gesprochen wird, brauchen Sie eine brauchbare Ist-Aufnahme. Nicht perfekt, aber belastbar genug, dass Finance, IT und Fachbereiche dieselbe Ausgangslage sehen. Viele Konsolidierungsprojekte geraten früh ins Stocken, weil niemand genau weiß, welche Tools tatsächlich genutzt werden und welche Nebenprozesse daran hängen.

Erfassen Sie pro System mindestens:

• Systemname, Zweck und unterstützte Kernprozesse
• betroffene Nutzergruppen oder Teams
• Lizenzmodell, groben Nutzungsumfang und Kostenstelle
• Vertragslaufzeit und Kündigungsfenster
• fachlich Verantwortliche und technische Ansprechpartner
• relevante Schnittstellen, Exporte und Importe

Noch wichtiger als die Tool-Liste sind die Brüche zwischen den Systemen. Suchen Sie gezielt nach doppelter Datenerfassung, manuellen Excel-Exporten, Schattenprozessen per E-Mail oder Dateiablage, Übergaben ohne klare Verantwortung und abweichenden Datenständen.

Begrenzen Sie den Scope bewusst. Sonst wächst aus einem genehmigungsfähigen Vorschlag schnell ein Großprojekt ohne Kontur. Legen Sie fest, welche Systeme in die erste Betrachtung gehören und welche zunächst außen vor bleiben. Häufig ist ein zusammenhängender Prozess sinnvoll, etwa Lead-to-Cash, Ticketbearbeitung oder Projektabwicklung mit Reporting.

Diese Abgrenzung zeigt, dass Sie nicht alles auf einmal umkrempeln wollen, sondern eine beherrschbare erste Stufe vorschlagen.

Viele Business Cases scheitern außerdem daran, dass Kündigungsfristen übersehen oder Exit-Kosten unterschätzt werden. Deshalb lohnt sich ein einfacher Vertragstracker mit diesen Feldern:

• Anbieter: Name des Software- oder Serviceanbieters
• Laufzeitende: Datum des Vertragsendes
• Kündigungsfenster: Zeitraum, in dem gekündigt werden kann
• Verlängerungsbedingungen: automatische Verlängerung, Optionen oder Sonderklauseln
• Exit- und Ablösekosten: Kosten für Vertragsauflösung, Migration oder Ablösung

So werden parallele Laufzeiten und Exit-Kosten planbar, statt später als Überraschung im Budget aufzutauchen.

Die heutigen Kosten in eine managementtaugliche Baseline übersetzen

Die meisten internen Vorlagen bleiben bei den offensichtlichen Lizenzkosten stehen. Das reicht nicht. Eine managementtaugliche Baseline beschreibt nachvollziehbar, was der heutige Zustand pro Jahr wirklich kostet – einschließlich interner Aufwände, die sonst nirgends als Tool-Kosten auftauchen.

Beginnen Sie mit den direkten Kosten:

• Lizenzen, Zusatzmodule, Implementierungs- und Supportverträge
• Kosten für Schnittstellen und Middleware
• externe Dienstleister für Betrieb, Anpassungen oder Reports
• interne Betriebsaufwände in IT und Fachbereichen

Danach folgen die versteckten Kosten. Gemeint ist der Aufwand, der nur entsteht, weil mehrere Systeme parallel laufen und die Daten nicht sauber zusammenpassen: manueller Datenabgleich, Fehlerkorrekturen nach widersprüchlichen Datenständen, Berichte aus mehreren Quellen, Benutzerverwaltung über verschiedene Admin-Oberflächen und Audit-Vorbereitung aus verteilten Systemen.

Manueller Datenabgleich heißt hier: Mitarbeitende exportieren jeden Monat Listen, führen sie zusammen und prüfen Abweichungen von Hand, weil es keinen verlässlichen gemeinsamen Datenstand gibt. Das ist ein eigener Kostenblock.

Rechenbeispiel: 10 Stunden pro Monat × 50 € Stundensatz × 12 Monate = 6.000 € jährlicher Aufwand allein für den manuellen Abgleich.

Angenommen, die Umstellung dieses Teilprozesses kostet einmalig 9.000 € (Einrichtung, Datenmigration, Schulung), und die Einsparung ist netto, also nach Abzug der laufenden Plattformkosten. Dann ergibt sich je nach Annahme:

• Szenario A: 50 % weniger Aufwand → 3.000 € pro Jahr → Amortisation nach 3 Jahren
• Szenario B: 75 % weniger Aufwand → 4.500 € pro Jahr → Amortisation nach 2 Jahren
• Szenario C: Aufwand entfällt vollständig → 6.000 € pro Jahr → Amortisation nach 1,5 Jahren

Die Prozentsätze zeigen hier nur den Rechenweg. Welche Einsparung realistisch ist, muss aus der eigenen Baseline abgeleitet werden.

Für Finance muss die Berechnung prüfbar sein. Halten Sie deshalb pro Position Datenquelle, Annahme, Berechnungslogik und Zuordnung zu Prozess oder Funktionsbereich fest. Die Ist-Kostenbasis muss so aufgebaut sein, dass Finance sie nachrechnen kann und die Fachbereiche sich darin wiederfinden. Gelingt beides nicht, wird später auch der Nutzen nicht geglaubt.

[BANNER type="lead_banner_2" blockquote="\"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht.\"" user-picture-src='/upload/optimizer/converted/upload/iblock/1f0/5znenimejlwyevt3s1tfd1gxgx08i7ew.png.webp?1742972973130' user-name="Geschäftsführer, Alexander Dortmann" user-description="DortmannKids" button-message="KOSTENFREI STARTEN"]

Den Zielzustand und den wirtschaftlichen Nutzen der Konsolidierung modellieren

Erst jetzt kommt das Zielbild. Beschreiben Sie präzise, was die zentrale Plattform leisten soll: Welche Systeme ersetzt sie? Welche Prozesse werden vereinheitlicht? Welche Daten werden an einer Stelle gepflegt? Welche Schnittstellen entfallen, und welche bleiben bewusst bestehen?

Eine zentrale Plattform ist dabei kein abstrakter Architekturbegriff. Gemeint ist ein Systemkern, in dem zusammenhängende Abläufe, Daten und Zuständigkeiten gebündelt werden, statt sie über mehrere Einzellösungen zu verteilen.

Das Zielbild sollte sich an realen Abläufen festmachen:

• Kundendaten werden einmal gepflegt und nicht in drei Tools abgeglichen.
• Statuswechsel im Service erscheinen ohne manuellen Export im Management-Reporting.
• Freigaben laufen im System statt über E-Mail-Ketten.
• Standardberichte greifen auf einen gemeinsamen Datenbestand zu.

Übersetzen Sie den Nutzen dann in konkrete Effekte. „Bessere Transparenz“ oder „mehr Effizienz“ überzeugen selten. Benennen Sie stattdessen, was genau weniger wird oder schneller geht: weniger Lizenzvielfalt, weniger pflegeintensive Integrationen, geringerer Abstimmungsaufwand, konsistentere Datenstände und schnellere Berichte ohne manuelle Zusammenführung.

Wo möglich, quantifizieren Sie den Nutzen mit denselben Größen wie in der Baseline: Stunden, Fehlerkorrekturen, Durchlaufzeiten, Audit-Aufwand oder vermiedene Zusatzbeschaffungen. Vermeiden Sie Scheingenauigkeit. Wenn Sie den Nutzen aus Zeitersparnis ableiten, zeigen Sie die Herleitung, statt auf die zweite Nachkommastelle zu rechnen.

So wird aus „Konsolidierung“ ein nachvollziehbares Betriebsmodell, das die Geschäftsführung gegen Aufwand und Risiko abwägen kann.

Risiken, Migrationsaufwand und kritische Annahmen offen bewerten

Wenn Aufwand und Risiko zu glatt aussehen, sinkt die Glaubwürdigkeit. Geschäftsführung und Finance wissen, dass eine Migration nie nur aus Datenimport und Schulung besteht.

Nehmen Sie die einmaligen Aufwände vollständig auf. Dazu gehören typischerweise Datenbereinigung und Mapping, die Migration von Stamm- und Bewegungsdaten, Prozessanpassungen, Schulung und Begleitung der Nutzergruppen, Parallelbetrieb sowie Kündigungs-, Exit- oder Ablösekosten bestehender Verträge.

Parallelbetrieb ist oft teurer und dauert länger als intern angenommen. Gerade wenn Berichte, Freigaben oder Abrechnungsdaten betroffen sind, lassen sich Altsysteme nicht einfach am Stichtag abschalten. Das muss im Business Case stehen, sonst kommt der Einwand später zurück.

Bewerten Sie die wesentlichen Risiken offen, aber priorisiert:

1. Betriebsunterbrechung: Welche Prozesse dürfen während der Umstellung nicht ausfallen?
2. Funktionslücken: Welche Arbeitsweisen deckt das Zielsystem anfangs noch nicht ab?
3. Akzeptanz: Wo droht ein Rückfall in Schattenprozesse?
4. Anbieterabhängigkeit: Welche Bindung an die Plattform entsteht?
5. Datenschutz und Compliance: Welche Anforderungen müssen vor dem Rollout geprüft sein?

Beim letzten Punkt geht es typischerweise um diese Fragen:

• DSGVO : Ist die Verarbeitung rechtmäßig, und sind die Betroffenenrechte umsetzbar?
• Auftragsverarbeitung: Sind die AV-Verträge mit den beteiligten Dienstleistern vor dem Go-live abgeschlossen und dokumentiert?
• Technische und organisatorische Maßnahmen (TOM): Sind Maßnahmen wie Verschlüsselung, Zugriffskontrollen und Protokollierung geprüft?
• Datenstandort: Werden die Daten in der EU gespeichert, und sind Ausnahmen zulässig?
• Lösch- und Aufbewahrungsfristen: Sind die handels- und steuerrechtlichen Vorgaben technisch umgesetzt?

Arbeiten Sie auch beim Gesamtbild mit Szenarien statt mit einem einzigen optimistischen Bild:

• vorsichtig: höherer Aufwand, späterer Nutzen, langsame Migration
• erwartet: Verlauf auf Basis der heutigen Daten
• günstig: schnellerer Nutzen bei guten Voraussetzungen

Damit machen Sie Unsicherheit sichtbar und verhindern, dass der ganze Business Case an einer einzigen Annahme hängt.

Einen stufenweisen Umsetzungsplan mit Entscheidungspunkten formulieren

Kaum eine Geschäftsführung genehmigt gern eine vollständige Konsolidierung auf einen Schlag. Ein Phasenmodell senkt das Risiko und macht die Steuerung greifbar. Es geht dabei nicht um Projektmethodik auf Folienniveau, sondern um belastbare Entscheidungspunkte.

Ein typischer Ablauf:

1. Analyse: Scope bestätigen, Ist-Basis finalisieren, Zielbild schärfen.
2. Pilot: einen abgegrenzten Prozess oder Bereich auf der Plattform abbilden.
3. Erste Migrationen: priorisierte Systeme oder Teams umstellen.
4. Ausweitung: weitere Bereiche nach demselben Muster anbinden.
5. Abschaltung der Altsysteme: Verträge beenden und Altprozesse stilllegen.

Jede Phase braucht ein Entscheidungstor (Decision Gate): einen formalen Prüfpunkt, an dem entschieden wird, ob die nächste Stufe freigegeben, nachgebessert oder der Scope angepasst wird. Ohne solche Tore rutscht die Konsolidierung leicht in einen offenen Dauerzustand.

Benennen Sie außerdem die Verantwortlichkeiten. Wer entscheidet am Gate? Wer liefert die Kostendaten? Wer verantwortet die Datenbereinigung? Wer führt das Change Management? Wer prüft, wann Altverträge gekündigt werden können? Gerade diese Übergaben fehlen in vielen Vorschlägen.

Die konkreten Zielwerte hängen von der eigenen Baseline ab. Wichtig ist, dass sie vor Projektstart feststehen – sonst wird am Gate über Eindrücke statt über Ergebnisse entschieden.

Ergänzend hilft eine kompakte Verteilung der Verantwortung nach dem RACI-Schema:

So entsteht ein klarer Governance-Rahmen, der die Entscheidungspunkte im Umsetzungsplan absichert.

Den Business Case als freigabefähiges Entscheidungsdokument aufbauen

Am Ende zählt nicht, wie viel Vorarbeit in Tabellen steckt, sondern ob die Geschäftsführung schnell zu einer tragfähigen Entscheidung kommt. Das Dokument muss deshalb wie eine Entscheidungsvorlage funktionieren, nicht wie eine Projektablage.

Eine praxistaugliche Struktur:

• Executive Summary: was beschlossen werden soll und warum jetzt
• Ist-Kosten: heutige Baseline mit den wichtigsten Kostentreibern
• Zielbild: was die zentrale Plattform ersetzt oder vereinheitlicht
• Wirtschaftlichkeit: Nutzen, Aufwände und Szenarien
• Risiken: die wesentlichen Punkte und wie sie begrenzt werden
• Plan: Phasen, Gates, Verantwortliche, nächste Schritte
• Freigabeempfehlung: konkrete Entscheidung mit Budget und Erwartung bis zum nächsten Gate

Die Empfehlung muss eindeutig sein. Typische Einwände sollten Sie im Dokument selbst vorwegnehmen:

• Warum nicht beim Status quo bleiben? Weil der heutige Aufwand nicht nur aus Lizenzen besteht, sondern aus laufender Abstimmung, Fehlerkorrektur, Integrationspflege und Brüchen im Reporting.
• Warum jetzt? Weil Vertragsfenster, wachsender manueller Aufwand, anstehende Verlängerungen oder operative Engpässe den Zeitpunkt wirtschaftlich und organisatorisch sinnvoll machen.
• Wie begrenzen wir das Migrationsrisiko? Durch einen begrenzten Start-Scope, einen Pilot, Entscheidungstore, Parallelbetrieb nur dort, wo er nötig ist, und Freigaben je Phase statt einer Komplettumstellung auf Verdacht.

Wenn eine Geschäftsführung unterschreiben soll, helfen keine zehn Zusatzfolien mit Plattformfunktionen. Entscheidend ist, dass klar erkennbar ist, was heute genehmigt wird – und was ausdrücklich noch nicht.