ERP-Systemklasse: Kosten entstehen entlang der Prozesskette
ERP als Systemklasse: Warum Kosten hier oft unterschätzt werden
- ERP betrifft Kernprozesse und Compliance: Order-to-Cash, Procure-to-Pay, Finance, Lager/Logistik – Fehler wirken direkt auf Cashflow und Lieferservice.
- Kosten sind nicht nur Lizenz: Migration, Integrationen, Betrieb und Change bestimmen den TCO.
- Der teuerste Zustand ist ein ‘halbes ERP’: Prozesse laufen teils im System, teils in Excel/Insellösungen → doppelte Arbeit.
Typischer Irrtum: 'Wir vergleichen Preise pro User'
- Lizenzpreise sind selten vergleichbar, wenn Module/Add-ons und Nutzerklassen unterschiedlich definiert sind.
- SaaS kann günstig starten, aber über Add-ons, API-Limits oder Support-Level steigen.
- On-Prem kann günstige Lizenz haben, aber Betrieb/Upgrades und Custom Code sind TCO-Treiber.
TCO (3–5 Jahre): die Kostenblöcke, die du vollständig betrachten musst
Eine einfache Faustregel: Wenn ihr nur Lizenzkosten rechnet, unterschätzt ihr ERP-Kosten fast immer. Rechne TCO in Blöcken, und verknüpfe jeden Block mit Annahmen (Scope, Nutzer, Integrationen, Datenqualität).
1
Lizenz / Subscription
User, Module, Add-ons, API-/Transaktionslimits, Environments, Support-Level
2
Implementierung
Prozessdesign, Parametrisierung, Customizing, Tests, Cutover, Dokumentation
3
Datenmigration
Bereinigung, Mapping, Transformation, Imports, Validierung, Delta-Import
4
Integrationen
ERP<>Shop/CRM/PIM/BI/Versand/Payment; Monitoring, Retries, Fehler-Queues
5
Betrieb (Run)
Admin, Rechte, Releases/Upgrades, Monitoring, Backups, Incident-/Change-Prozess
6
Change & Enablement
Schulungskonzept, Rollen, Office Hours, Adoption-Metriken, Prozessdisziplin
7
Risiko-/Puffer
Unerwartete Scope-Änderungen, Datenqualität, Schnittstellenrisiken, Verzögerungen
TCO-Struktur (vereinfachter Überblick) – typisch im Mittelstand
| Kostenblock | Einmalig (CapEx/Projekt) | Laufend (OpEx/Jahr) | Typische Stolperstelle |
|---|---|---|---|
| Lizenz/Subscription | --- | hoch/planbar | Add-ons, Nutzerklassen, API-/Volumenlimits |
| Implementierung | mittel--hoch | --- | Scope wächst, Customizing statt Standardisierung |
| Datenmigration | mittel | --- | Bereinigung, Mapping, Pflichtfelder, Owner fehlen |
| Integrationen | mittel--hoch | mittel | Monitoring/Retry/Fehler-Queues, Punkt-zu-Punkt-Scripte |
| Betrieb/Administration | --- | mittel | Rechte, Stammdaten, Support, Releases/Upgrades |
| Change/Training | mittel | niedrig--mittel | einmaliges Training, keine Office Hours/Onboarding |
| Risiko/Puffer | --- | --- | keine Zeitbox, keine K.O.-Kriterien, keine PoCs |
TCO-Tipp: Rechne nicht nur ‘Best Case’. Lege 2–3 Szenarien an (Base / Realistic / Stress), z.B. mit unterschiedlicher Datenqualität und Integrationskomplexität.
Lizenzmodelle: so vermeidest du Äpfel-mit-Birnen-Vergleiche
Lizenzen: Die häufigsten Modelle (und worauf du achten solltest)
- Named User (pro Person): häufig bei SaaS, gut planbar – aber Achtung bei ‘Power User’ vs ‘Light User’.
- Concurrent User (gleichzeitig): kann in Schichtbetrieben sinnvoll sein, erfordert aber Nutzungsanalysen.
- Modulbasiert: Finance, Einkauf, Lager, Produktion, CRM/Service – vergleiche Module nur entlang eurer Use Cases.
- Transaktions-/Volumenbasiert: Belege, API-Calls, Automationen – wichtig bei Integrationen und EDI.
- Add-ons/Environments: Sandboxes, Reporting, Workflow/Approval, WMS/MES, EDI – klassische Kostentreiber.
Lizenz-Fallen (Mittelstand)
- ‘Benutzer’ ist nicht gleich Benutzer: rollenbasierte Preisstufen machen Vergleich schwierig.
- API- und Integrationslimits werden spät entdeckt (dann eskalieren Betriebskosten).
- Test-/Sandbox-Umgebungen kosten extra (aber ohne Tests sind Releases riskant).
- Support-Level (SLA) wird unterschätzt – besonders bei Monatsabschluss/Peak Season.
Praxis: Lass dir Angebote immer mit denselben Rollen/Nutzerklassen und denselben Must-Have Use Cases kalkulieren. Sonst ist jeder Preisvergleich wertlos.
Versteckte Kosten: was in Projekten wirklich eskaliert
Versteckte Kosten: die Top 10 TCO-Treiber
- Datenbereinigung (Artikel, Partner, Preislogik) – oft größer als der Import selbst.
- Integrationen inkl. Monitoring/Retry/Fehlerhandling (Shop, CRM, PIM/MDM, Versand, Payment, BI).
- Customizing/Extensions: jeder Sonderfall kostet jetzt und bei jedem Upgrade.
- Reporting/BI: KPI-Definition, Datenmodell, Datenqualität, DWH-Anbindung.
- Testaufwand (UAT, Regression) – ohne Tests steigen Störungen im Betrieb.
- Change/Schulung/Adoption: fehlende Disziplin erzeugt Nacharbeit (und ‘ERP wird umgangen’).
- Betrieb/Administration: Rechte, Stammdatenpflege, Incident-/Change-Prozess.
- Release-/Upgrade-Management (Cloud häufiger, On-Prem schwerer).
- Projektverzögerungen durch Scope-Growth, Ressourcenengpässe, Entscheidungsstau.
- Schatten-IT: parallel weiterlaufende Tools, Excel-Prozesse, doppelte Datenerfassung.
Was du im Angebot explizit abfragen solltest
- Welche Add-ons sind für eure Must-Have Use Cases wirklich nötig?
- Welche Environments sind enthalten (Dev/Test/Prod)? Wie laufen Releases/Regression?
- Welche Integrationswege gibt es (API, EDI, Files) und wie wird Fehlerhandling gelöst?
- Welche Datenmigrationstools/Services sind enthalten? Wer verantwortet Datenqualität?
Kostenhebel: so senkst du TCO ohne Qualität zu verlieren
Kostenhebel, die sofort wirken
- Scope in Releases schneiden: erst Kernprozesse, dann Erweiterungen (reduziert Verzögerungen).
- Standardisieren, bevor du customizest: jede Abweichung zahlt sich doppelt aus (Build + Upgrade).
- Master-Daten-Regeln definieren (wer ist Quelle wofür?) – reduziert Dubletten und Sync-Konflikte.
- Integrationen über iPaaS und mit Monitoring: weniger Betriebskosten als Punkt-zu-Punkt.
- Schulung als Programm: Rollen, Übungen, Office Hours, Adoption-KPIs.
Kostenhebel, die oft vergessen werden
- Teststrategie (UAT + Regression) fest einplanen – reduziert Störungen im Run.
- Betriebskonzept definieren: Rollen, Changes, Support, Releasefenster, Verantwortlichkeiten.
- Datenowner benennen: Qualität ist kein einmaliges Projekt, sondern Betrieb.
- PoCs nur für echte Risiken (Integration, Rechte, Preislogik) – verhindert spätere Überraschungen.