CAFM: Wirtschaftlichkeits- und Nutzenanalyse (Business Case)
Facility Management: FM-Software » Strategie » Vorbereitung » Business Case
Wirtschaftlichkeits- und Nutzenanalyse für eine FM‑Software
Die „Wirtschaftlichkeits- und Nutzenanalyse (Business Case)“ erstellt eine belastbare, prüffähige Entscheidungsgrundlage für die Einführung bzw. Erneuerung/Erweiterung einer FM‑Software. Sie quantifiziert und begründet – soweit möglich – Kosten, Nutzeffekte (quantitativ/qualitativ), Risiken, Alternativen und Finanzkennzahlen, sodass Budgetfreigaben, Priorisierungen und Governance‑Entscheidungen fachlich und kaufmännisch sauber getroffen werden können. Im Projektmanagement‑Kontext ist der Business Case zudem nicht nur „Startdokument“, sondern ein Steuerungsinstrument: die fortlaufende wirtschaftliche Begründung (continued business justification) und verwendet den Business Case als Entscheidungsgrundlage, damit ein Projekt wirtschaftlich sinnvoll bleibt (ROI‑Logik, gerechtfertigter Ressourceneinsatz). Abzugrenzen ist der Business Case von der Nutzenrealisierung: Ein Business Case legitimiert die Investition; die Nutzenrealisierung organisiert, wie und wann Benefits gemessen und realisiert werden (z. B. Benefits Register, Verantwortlichkeiten, Reviews).
- Ziele und Deliverables
- Aktivitäten, Meilensteine und Exit‑Kriterien
- Typische Meilensteine mit Eintrittsbedingungen
- Beispiel‑RACI für Kernaktivitäten
- Risiken und Gegenmaßnahmen
- Vorlagen, Checklisten, Varianten und Informationsbedarf
- Beispielhafte Kosten- und Nutzenkategorien
- Beispiel‑KPIs für FM‑Software‑Business‑Cases
Ziele und Deliverables
Zielzustand der Dienstleistung ist ein freigegebener Business Case (inkl. Modell), der (a) für interne Entscheidungsgremien tragfähig ist, (b) für Beschaffung/Verhandlungen verwendbar ist (SaaS/On‑Prem/Partnerleistungen), und (c) als „lebendes“ Referenzartefakt über Projektphasen aktualisiert werden kann.
| Deliverable | Zweck / grober Inhalt | Owner (Erstellung) | Freigabe (Accountable) | Optionalität / Bedingungen |
|---|---|---|---|---|
| Business‑Case‑Dokument (Versionen: Draft → Final) | Executive Summary, Ausgangslage, Zielbild/Scope‑Bezug, Alternativen/Optionen (mind. BAU/„do minimum“), Kosten‑/Nutzen‑Logik, Risiken, Empfehlung. | Projektleitung + Controlling | Sponsor/Auftraggeber | Must |
| Rechenmodell (Excel) „Kosten/Nutzen/Finanzkennzahlen“ | Transparentes Modell mit Parametern, Annahmen, Cashflows, ROI/Payback/IRR‑Berechnung | Controlling (mit Projektleitung) | Sponsor + Controlling | Must |
| Kostenmodell (TCO‑Struktur) | Struktur der Einführungskosten und Betriebskosten inkl. interner Aufwände und externer Kosten über Evaluierung bis Betrieb | Controlling + Projektleitung | Sponsor | Must |
| Nutzenkatalog (quantitativ) inkl. Herleitung | Quantitative Nutzenannahmen (z. B. Prozesszeitersparnisansatz) und – sofern passend – Erfahrungswerte/Benchmarks | FM‑Fachverantwortung + Controlling | Sponsor | Must |
| Nutzenkatalog (qualitativ) inkl. Bewertungsmatrix | Qualitative Nutzen (z. B. Sicherheit, Qualität, Image, Nachhaltigkeit, Transparenz) mit nachvollziehbarer Bewertungsskala | Projektleitung + FM | Sponsor | Should (in der Praxis häufig Must) |
| Benefits Register & „Benefit Profile“ (Messlogik) | Strukturierte Benefit‑Einträge: Beschreibung, Beobachtbarkeit, Attribution/Owner, Messmethode, Review‑Zeitpunkte; Nutzenmanagement betont, dass Benefits definiert und messbar gemacht werden müssen und empfiehlt Benefit Profiles. | Projektleitung/Change + FM | Sponsor | Should; wird Must bei strengem Invest‑Controlling |
| Sensitivitäts- und Szenarioanalyse | Robustheit gegen Unsicherheiten (z. B. Adoption‑Rate, Integrationsaufwand, Datenqualität); unterstützt „Investitionsfähigkeit“ unter Risiko. | Controlling | Sponsor | Should |
| Compliance‑/Datenschutz‑Kosten-/Nutzenbeitrag | Bewertung, ob DSFA/zusätzliche TOMs/Prozessanpassungen erforderlich sind (Zeit/Budget‑Folgen). DSFA‑Pflicht folgt aus Schwellwertanalyse; Entscheidung ist zu dokumentieren; zudem verlangt Art. 32 risikoadäquate Maßnahmen unter Berücksichtigung u. a. der Implementierungskosten. | Datenschutz + IT‑Security + Controlling | Sponsor/Legal | Optional → wird Must bei personenbezogenen Daten/hohem Risiko |
| Entscheidungsunterlage für Lenkungskreis | Kompakte Vorlage (1–5 Seiten) mit Kernaussage, Kosten/Nutzen, Risiken, Empfehlung, Freigabeantrag. | Projektleitung | Sponsor | Should |
| Aktualisierungsplan (Business‑Case‑Lifecycle) | Festgelegte Update‑Zeitpunkte (z. B. nach Anbieterangeboten, nach Scope‑Freeze, vor Go‑Live‑Entscheidung) inkl. Verantwortlichkeiten; PRINCE2 stellt auf regelmäßige Prüfung der wirtschaftlichen Begründung und Staged‑Steuerung ab. | Projektleitung/PMO | Sponsor | Should |
Vorgehenslogik
Für FM‑Software‑Business‑Cases ist eine mehrstufige Logik zweckmäßig, weil die Kostengenauigkeit typischerweise mit zunehmender Markt‑ und Lösungskenntnis steigt (z. B. nach Angebotsphase oder nach Architektur-/Betriebsmodellentscheidungen). In strukturierten Business‑Case‑Leitfäden wird daher häufig zwischen frühen und späteren Reifegraden unterschieden und zugleich ein „Options Framework“ genutzt, das mindestens Business‑as‑Usual (BAU) und eine „do minimum“‑Option als realistische Kernoption vorsieht.
Eine praxistaugliche Stufenabbildung (vereinfacht):
BC-Scoping (BAU/Optionen) → BC-Draft (Kosten/Nutzen grob) → BC-Final (mit Angeboten/Architektur)
→ Investitionsentscheidung → BC-Updates je Projekt-Gate → Benefits Review nach Go-Live
Aktivitäten-/Arbeitspaket‑Tabelle
| Aktivität/Arbeitspaket | Beschreibung (Zweck, Aktivitäten, Ergebnis) | Verantwortliche Rolle | Dauer/Aufwand (Richtwert mittelgroß; kontextabhängig) | Abhängigkeiten |
|---|---|---|---|---|
| Kick‑off Business Case & Scoping | Zielsetzung, Zeithorizont, Bewertungslogik, Entscheidungsbedarf (Gremien), Versionierungsplan; Festlegung BAU‑Baseline und Mindestoption („do minimum“) als Vergleich. | Projektleitung + Sponsor | 2–5 Tage | Zielbild/Scope‑Entwurf; Stakeholderverfügbarkeit |
| Optionen/Alternativen strukturieren | Erfassung BAU, do‑minimum, Zwischenoptionen; Abgleich auf „what/where/how/who/when/funding“ (Options Framework). | Projektleitung + Controlling | 3–7 Tage | Grundverständnis Zielbild; IT‑Rahmen |
| Kostendaten erheben und strukturieren | Interne Aufwände & externe Kosten über Evaluierung bis Betrieb; Einführung + Betrieb; ggf. IT‑Infrastrukturkosten als eigener Block. | Controlling | 1–2 Wochen | Ressourcen-/Rollenklarheit; Vorinformationen Anbieter/IT |
| Nutzenhebel identifizieren & priorisieren | Nutzenhebel entlang FM‑Kernfelder (z. B. Instandhaltung, Flächenmanagement) und Transparenz/Dokumentation; Ableitung erster KPI‑Kandidaten. | FM‑Fachverantwortung | 1–2 Wochen | Prozess-/Datenbasiskenntnis; Key‑User‑Input |
| Nutzen quantifizieren (Prozesskostenansatz, Erfahrungswerte) | Monetarisierung über Zeitersparnis/Prozesskostenansatz; Plausibilisierung über Erfahrungswerte/Benchmarks (soweit passend); Dokumentation der Berechnungslogik. | Controlling + FM | 1–3 Wochen | Prozessdaten/Zeiterfassungen; Annahmenlog |
| Qualitative Nutzen bewerten | Bewertung nicht oder nur schwer monetarisierbarer Nutzen (z. B. Sicherheit, Qualität, Image, Nachhaltigkeit, Transparenz) in einer Matrix; Herleitung (warum relevant, welche Stakeholder). | Projektleitung + FM | 3–7 Tage | Stakeholderanalyse; Compliance‑Input |
| Finanzmodell erstellen (Kennzahlen, Cashflows) | Modell mit Cashflow‑Logik, Abzinsung/ Aufzinsung, ROI/Payback/IRR/MIRR; Szenarien (Base/Best/Worst) und Parametersteuerung. | Controlling | 1–2 Wochen | Kosten- und Nutzenquantifizierung |
| Sensitivitätsanalyse & Risikozuschläge | Variation zentraler Treiber (z. B. Adoption‑Rate, Integrationskosten, Datenaufbereitung) und Dokumentation der Robustheit; ggf. Risikopuffer/Contingency. | Controlling + Projektleitung | 3–7 Tage | Finanzmodell stabil |
| Compliance-/Datenschutz‑Einordnung (falls relevant) | Schwellwertanalyse DSFA (Erforderlichkeit), Dokumentation der Entscheidung; Aufwand für TOMs/DSFA/Reviews berücksichtigen; Art. 32 verlangt risikoadäquate Maßnahmen unter Berücksichtigung u. a. der Implementierungskosten. | Datenschutz + IT‑Security | 3–10 Tage | Datenkategorien & Systemdesign grob bekannt |
| Review, Qualitätssicherung, Freigabeprozess | Reviews mit FM/IT/Controlling/Sponsor; nachvollziehbare Annahmen; Konsistenzprüfung (keine Doppelzählung, saubere BAU‑Baseline); Freigabepaket finalisieren. | Projektleitung | 1–2 Wochen (kalendergetrieben) | Stakeholderverfügbarkeit; Entscheidungstermine |
Typische Meilensteine mit Eintrittsbedingungen
| Meilenstein | Ergebnis | |
|---|---|---|
| Business‑Case‑Kick‑off abgeschlossen | Bewertungsrahmen fixiert | Scope‑Entwurf liegt vor; BAU‑Baseline und Mindestoption („do minimum“) definiert; Verantwortlichkeiten geklärt. |
| Business‑Case‑Draft (v0.x) | Erste belastbare Größenordnung | Kostenstruktur Einführung/Betrieb angelegt; Nutzenhebel identifiziert; Annahmenlog erstellt; offene Punkte transparent. |
| Business‑Case‑Final (v1.0) freigabefähig | Entscheidungsreife | Finanzkennzahlen (ROI/Payback/IRR) nachvollziehbar; Sensitivitäten dokumentiert; qualitative Nutzen bewertet; Empfehlung formuliert. |
| Investitionsentscheidung / Budgetfreigabe | Go/No‑Go | Entscheidungsunterlage liegt vor; Finanzierung/Verantwortlichkeiten bestätigt; Roadmap‑Implikationen verstanden (z. B. SaaS‑Lizenzmodell). |
| Benefits‑Review‑Plan verabschiedet | Nutzenrealisierung steuerbar | Benefits Register inkl. Messlogik/Owner; Review‑Zeitpunkte definiert; Verbindung zum Betrieb/Controlling hergestellt. |
Klarer Exit‑Kriteriensatz für die Dienstleistung
Das Arbeitspaket ist abgeschlossen, wenn Business‑Case‑Dokument + Rechenmodell freigegeben sind, wesentliche Annahmen/Risiken dokumentiert sind und Nutzenverantwortlichkeiten (Benefit Owner) inkl. Messlogik mindestens für die MVP‑/Release‑1‑Benefits festgelegt sind.
Typische Rollen/Stakeholder
Für einen FM‑Software‑Business Case braucht es eine enge Kopplung von Fachlichkeit, IT‑Realität und kaufmännischer Steuerung.
Datenschutz/Informationssicherheit sind nicht nur „Compliance‑Beifang“: DSFA‑Pflicht ergibt sich aus einer Schwellwertanalyse (mit Dokumentationspflicht), DSFA ist vor Aufnahme der Verarbeitung durchzuführen, und Art. 32 verlangt risikoadäquate Sicherheitsmaßnahmen unter Berücksichtigung der Implementierungskosten sowie regelmäßige Wirksamkeitsprüfung.
Rollen: Sponsor/Auftraggeber (SP), Projektleiter (PL), FM‑Manager/Fachprozessowner (FM), IT‑Leitung/Architekt (IT), Implementierungspartner/Anbieter (IP), Controlling/Finance (CO), Datenschutz/ISB (DS)
| Kernaktivität | SP | PL | FM | IT | IP | CO | DS |
|---|---|---|---|---|---|---|---|
| Bewertungsrahmen & Optionen (BAU/do‑minimum) | A | R | C | C | I | R/C | I |
| Kostenerhebung Einführung/Betrieb | C | C | I | C | I | A/R | I |
| Nutzenhebel identifizieren | C | R | A/R | C | C | C | I |
| Nutzen quantifizieren (Prozesskosten/Zeitersparnis) | C | C | R | I | C | A/R | I |
| Finanzmodell & Kennzahlen (ROI/Payback/IRR) | I | C | I | I | I | A/R | I |
| Sensitivitäts-/Szenarioanalyse | I | C | C | C | I | A/R | I |
| Datenschutz-/Compliance‑Scoping (DSFA‑Schwellwertanalyse) | I | C | I | C | I | I | A/R |
| Review & Freigabeempfehlung | A | R | C | C | C | C | C |
Grobe Aufwandsschätzung
Für ein mittelgroßes FM‑Software‑Projekt ist für einen entscheidungsfähigen Business‑Case‑Erstdurchlauf typischerweise ein Korridor von ca. 3–8 Wochen realistisch (kalendergetrieben durch Datenerhebung, Reviews, Gremientermine). Der reine Analyseaufwand liegt häufig im Bereich 15–35 Personentage, je nach Datenverfügbarkeit, Integrationsgrad und erforderlicher Sensitivitäts-/Risikotiefe (kontextabhängig, nicht normativ). Ein zweiter Durchlauf („Business Case Refinement“) ist oft sinnvoll, sobald belastbare Anbieterangebote und/oder Architekturentscheidungen (SaaS/On‑Prem, Integrationsvorgehen) vorliegen; das folgt dem in strukturierten Business‑Case‑Leitfäden beschriebenen Stufengedanken (von Scoping bis finaler Ausgestaltung).
Abhängigkeiten zu anderen Dienstleistungen/Arbeitspaketen
Der Business Case ist fachlich abhängig von Zielbild/Scope/Roadmap sowie von einer belastbaren Projektorganisation, weil ohne stabile Scope‑Baseline weder Kosten noch Nutzen sinnvoll normiert werden können (Änderungen würden sonst die Kalkulation permanent entwerten).
Technisch hängt die Kostenseite stark vom Integrationsumfang ab.
Organisatorisch verändern Multi‑Site‑Rollouts, Outsourcing‑Modelle und mobile Nutzung die Roadmap und damit Kosten- und Nutzenprofil (z. B. Schulungs-/Change‑Aufwand, Lizenzmodelle, App‑Integration). Schwerpunkt sind u. a. die zunehmende SaaS‑Nutzung mit neuen Betriebsformen/Lizenzmodellen sowie mobile Apps als Standard einer Systemintegration.
Datenschutz/Compliance kann eigenständige Kosten und Zeitachsen erzeugen: Die DSFA‑Erforderlichkeit folgt aus einer Schwellwertanalyse; die Entscheidung ist zu dokumentieren, DSFA ist vor Aufnahme der Verarbeitung durchzuführen und rechtzeitig zu starten (nicht „ad hoc“).
Risiken und Gegenmaßnahmen
Die häufigsten Business‑Case‑Risikofelder in FM‑Software‑Vorhaben liegen weniger in Rechenmethoden als in Daten, Annahmenqualität, Doppelzählungen und Adoption.
| Typisches Symptom | Gegenmaßnahme (im Arbeitspaket verankern) | |
|---|---|---|
| BAU‑Baseline unsauber | Nutzen erscheint „zu groß“ oder widersprüchlich | BAU explizit modellieren; Mindestoption („do minimum“) als realistischer Kern; Konsistenzcheck gegen Scope. |
| Doppelzählung von Nutzen | Mehrere Benefits referenzieren denselben Effekt (z. B. Zeiteinsparung + Kostensenkung ohne Trennung) | Benefit‑Profiles mit Attribution und Messmethode; Nutzenregister als „Single Source“. |
| Integrations-/Datenaufwände unterschätzt | Business Case „kippt“ nach Architektur-/Schnittstellenklarheit | Früh‑Scoping IT‑Integration (Schnittstellenarten, Datenumfang); Sensitivitäten für Integrationsaufwand. |
| Nutzenannahmen nicht messbar | „Weiche“ Nutzenargumente ohne KPI‑Anker | Qualitative Nutzenmatrix plus definierte Proxy‑KPIs; PRINCE2‑Logik: Business Case unterstützt Entscheidung, Projekt muss wirtschaftlich sinnvoll bleiben. |
| Adoption/Change nicht eingepreist | Nutzen tritt nicht ein, obwohl System live ist | Benefit Owner + Benefits‑Reviews; Leitfäden fordern Benefits‑Register und Benefits‑Realisation‑Arrangements. |
| Datenschutz/DSFA spät erkannt | Stop/Delay kurz vor Rollout | Schwellwertanalyse früh, Entscheidung dokumentieren; DSFA rechtzeitig starten; Art. 32‑Maßnahmen budgetieren. |
| Politische/strategische Zielkonflikte | Business Case wird „verhandelt“, nicht gerechnet | Options-/Szenariologik transparent; Sensitivitäten offenlegen; Entscheidungsgremium entscheidet bewusst entlang dokumentierter Trade‑offs. |
Beispiel‑Gliederung Business Case
| Abschnitt | Zweck / Beispielinhalt |
|---|---|
| Management Summary | Kernaussage, Empfehlung, KPIs, Entscheidungsbedarf |
| Ausgangslage & Problemdefinition | Ist‑Kosten-/Prozesslage, Defizite, Treiber (z. B. Transparenz, Dokumentation) |
| Zielbild, Scope und Annahmen | Bezug auf Projekt‑Scope; Annahmenlog; nicht enthaltene Themen |
| Optionen/Alternativen | BAU, do‑minimum, Zwischenoptionen; Begründung der bevorzugten Option („preferred way forward“). |
| Kostenmodell (Einführung & Betrieb) | Interne/externe Kosten; Einführung/Betrieb; ggf. IT‑Infrastrukturkosten. |
| Nutzenmodell (quantitativ) | Prozesskosten-/Zeitersparnisansatz; Erfahrungswerte/Benchmarks; Nutzenhebel z. B. Instandhaltung/Fläche. |
| Nutzenmodell (qualitativ) | Matrix: Sicherheit, Qualität, Image, Nachhaltigkeit, Transparenz; Gewichtung/Punktwerte. |
| Wirtschaftlichkeitskennzahlen | ROI, dynamische Amortisation, IRR/MIRR; Kapitalwert/Abzinsung (modellabhängig). |
| Sensitivitäts-/Szenarioanalyse | Treiber, Bandbreiten, Worst/Base/Best; Risiken und Puffer. |
| Nutzenrealisierung & Messkonzept | Benefits Register, Benefit Owner, Review‑Zeitpunkte, KPI‑Messung. |
| Risiken, Compliance, Next Steps | DSFA‑Schwellwertanalyse/Art‑32‑Aufwände (falls relevant); Roadmap‑Ableitung, Freigabebedarf. |
Beispielhafte Kosten- und Nutzenkategorien
| Kategorie | Typische Unterkategorien (Beispiele) | Hinweise/Varianten |
|---|---|---|
| Einmalkosten (Einführung) | Auswahl/Evaluierung, Projektmanagement/PMO, Implementierungspartnerleistungen, Datenmigration & Bereinigung, Schnittstellen/Integration, Schulung/Key‑User‑Aufbau, Test/Abnahme, Go‑Live/Cutover | Integrationsgrad dominiert häufig Aufwand; Einbindung in IT‑Umfeld/Schnittstellenumfang ist eigenständig zu betrachten. |
| Laufende Kosten (Betrieb) | SaaS‑Subscription oder Wartung, Support/Service Desk, Betrieb/Hosting, Weiterentwicklung/Release‑Management, Lizenz‑/User‑Skalierung, Monitoring/Backups | SaaS/Cloud verändert Betriebs‑ und Lizenzmodelle. |
| Quantitative Nutzen (Euro) | Prozesszeitersparnis (z. B. weniger Doppelpflege), reduzierte Bearbeitungszeiten, optimierte Instandhaltung/Verfügbarkeit, Flächenoptimierung, bessere Kosten-/Leistungstransparenz | Nutzenhebel werden u. a. in Instandhaltung und Flächenmanagement gesehen; Prozesskosten-/Zeitersparnisansatz als Monetarisierungsweg. |
| Qualitative Nutzen (Bewertung) | Sicherheit/Betreiberverantwortung, Qualitätssteigerung, Image, Nachhaltigkeit, Transparenz | Diese Nutzenkategorien werden explizit als qualitative Matrix genannt. |
Diese KPIs sind bewusst als Beispiele formuliert (projektspezifisch anzupassen)
| Nutzenhebel | KPI‑Beispiele (Outcome‑nah) | Typische Datenquellen |
|---|---|---|
| Instandhaltung/Technische Verfügbarkeit | Anteil fristgerechter Wartungen, mittlere Störungsbehebungszeit, Anlagen‑Downtime, Anteil präventiv vs. reaktiv | CAFM‑Tickets/Workorders, Wartungspläne, Anlagenstammdaten |
| Flächenmanagement | Auslastungsgrad, m² pro Arbeitsplatz/Funktion, Flächenkosten pro m², Leerstandsquote (wo anwendbar) | Flächen-/Belegungsdaten, ERP/Controlling, CAD/BIM (falls integriert) |
| Transparenz/Kosten & Leistungen | Kosten je Objekt/Service, Service‑SLAs/Erfüllungsquote, Budgetabweichungen | ERP/Controlling, Serviceprovider‑Reports, CAFM‑Reporting |
| Dokumentation/Betreiberverantwortung | Quote vollständiger Prüf-/Wartungsnachweise, Audit‑Findings, Fristenüberschreitungen | Dokumentenmanagement, Rechtskataster/Prüfpläne, CAFM‑Dokumentation |
Sensitivitätsanalyse‑Template
Ein robustes Minimal‑Set an Sensitivitäten (als Excel‑Eingabeparameter) umfasst typischerweise: (a) Integrationsaufwand, (b) Datenaufbereitungsaufwand, (c) Adoption‑Rate/Nutzungsgrad, (d) Lizenz‑/Betriebskostenentwicklung, (e) realisierte Zeiteinsparungen. Die Notwendigkeit, Optionen/Umsetzungsvarianten nachvollziehbar zu filtern und dabei BAU/do‑minimum als Referenz zu führen, ist in strukturierten Business‑Case‑Leitfäden explizit beschrieben.
Varianten und Kontextinformationen, die vom Auftraggeber benötigt werden- Die Business‑Case‑Ausgestaltung hängt stark vom Kontext ab. Besonders wirkungsrelevant sind:
SaaS/Cloud vs. On‑Prem: andere Kostenprofile (OPEX‑lastig vs. CAPEX‑lastig) und Lizenzlogiken.
Viele Standorte vs. wenige: Rollout‑Wellen, Trainings-/Change‑Kosten, Nutzenrealisierungszeitpunkt.
Hoher Integrationsgrad vs. Low‑Integration: Schnittstellenarten/Datenaustauschumfang beeinflussen Kosten und Projektpfad.
Für eine spätere, „ausformulierbare“ Leistungsbeschreibung (RfP/Pflichtenheft‑Textbausteine) sind typischerweise folgende Auftraggeber‑Inputs erforderlich: Zielmodule/Use‑Cases, Standorte/Objekte, Nutzerrollen, vorhandene Datenquellen und Datenqualität, gewünschtes Betriebsmodell, Integrationskandidaten/Systemowner, interne Kostensätze (nur für interne Kalkulation), relevante Compliance‑Rahmenbedingungen (personenbezogene Daten, DSFA‑Trigger).