Bachelorarbeit Prozessoptimierung: CFO-Leitfaden Finance & IT

Rechnungen bleiben im Klärfall hängen, obwohl ERP und DMS längst implementiert sind. Days Sales Outstanding (DSO) und Days Payables Outstanding (DPO) variieren zwischen Gesellschaften erheblich, Dunkelverarbeitung scheitert an Schnittstellen und fehlenden Stammdatenregeln. Eine Bachelorarbeit Prozessoptimierung setzt genau hier an: Aus einem konkreten Pain Point entsteht ein belastbares Untersuchungsvorhaben mit Hypothese, Messung, Ursachenanalyse, Soll-Konzept und Pilotplan – idealerweise entlang eines klar abgegrenzten Purchase-to-Pay-Prozesses. Für CFOs bedeutet das messbaren Beitrag zu Cash, Kosten, Steuerbarkeit und Risikominimierung – mit nachvollziehbaren Prozessen und prüffähiger Dokumentation.

Zentrale Ergebnisse, die Sie erwarten können:

• Ist-Prozess inklusive Varianten und belegte Schwachstellen
• Ursachenanalyse mit Evidenz (KPIs und Beispiele)
• Sollprozess inklusive Kontrollen und Ausnahmehandling
• Priorisiertes Maßnahmenportfolio mit Business Case
• KPI-Set plus Messkonzept
• Pilotplan mit Übergabepaket für IT und Operations

Typische Hebel:

• Verkürzung Durchlaufzeit um 30 bis 50 Prozent
• Senkung Klärfallquote von 25 auf unter 10 Prozent
• Erhöhung Skontoquote um 5 bis 15 Prozentpunkte
• Reduktion Prozesskosten pro Rechnung um 20 bis 40 Prozent
• Verbesserung First-Time-Right von 60 auf über 85 Prozent

Business Case First: Cash-, Kosten- und Risikohebel messbar machen

Aus CFO-Sicht sind drei Dimensionen entscheidend: Cash-Effekte durch Skontorealisierung (durchschnittlich 2 Prozent bei 10 Tagen Zahlungsziel), Working-Capital-Steuerung via DPO und DSO (jeder Tag zählt) sowie Vermeidung von Mahn- und Verzugskosten. Kosteneffekte entstehen durch Prozesszeitreduktion (Stundensatz Finance 50 bis 80 Euro), Fehlerkosten (Rework, Dubletten, Fehlüberweisungen) und Skalierbarkeit (gleiches Team, höheres Volumen). Risiko- und Compliance-Effekte umfassen IKS-Wirksamkeit durch strukturierte Kontrollen, Fraud-Prävention (Bankdatenänderung, Vendor-Change), Auditfähigkeit (Belegkette, Prüfpfad, Logging) und Forecast-Qualität durch transparente Pipeline.

Nutzenkategorien priorisiert

Harte Effekte:

• Prozesszeitkosten
• Skontoverluste
• Mahn- und Gebühren
• Fehlerkosten

Indirekte Effekte:

• Working Capital
• Forecast-Qualität
• Auditaufwand
• Risikoexposition

Risiko- und Compliance-Nutzen:

• IKS-Wirksamkeit
• Segregation of Duties (SoD) Sauberkeit
• Manipulationsschutz
• Nachvollziehbarkeit

Beispielrechnung Procure-to-Pay (Rechnungsprüfung)

Ausgangslage: 1000 Rechnungen pro Monat, Klärfallquote 25 Prozent, durchschnittliche Durchlaufzeit Klärfall 8 Tage, Bearbeitungszeit 45 Minuten, Skontoverlust 40 Prozent der Fälle.

Ziel: Klärfallquote auf 10 Prozent senken, Durchlaufzeit auf 3 Tage, Bearbeitungszeit auf 20 Minuten.

Effekt:

• 150 vermiedene Klärfälle monatlich
• 6,25 Stunden Zeitersparnis (150 mal 25 Minuten)
• 375 Euro Zeitkosten (60 Euro Stundensatz)
• 300 Euro Skontorealisierung (150 mal 2 Euro durchschnittlicher Skontovorteil)
• Insgesamt 675 Euro pro Monat, 8100 Euro pro Jahr

Zusätzlich: weniger Rückfragen, weniger Eskalationen, höhere Lieferantenzufriedenheit.

Kern-KPIs und Benchmark-Orientierungswerte für Finance-Prozesse

CFOs benötigen klare Zielkorridore. Die folgenden Benchmarks bieten Orientierung für die Bewertung von Ist-Zustand und Verbesserungspotenzial.

Procure-to-Pay (P2P)

• Durchlaufzeit Rechnung bis Zahlung: 5 bis 10 Tage (Best Practice unter 7 Tage)
• Klärfallquote: unter 10 Prozent (Zielkorridor 5 bis 8 Prozent)
• First-Time-Right: über 85 Prozent (Best Practice über 90 Prozent)
• Prozesskosten pro Rechnung: 3 bis 8 Euro (abhängig von Automatisierungsgrad)
• Skontoquote: über 80 Prozent bei skontierfähigen Rechnungen
• Liegezeit: maximal 30 Prozent der Durchlaufzeit

Order-to-Cash (O2C)

• Billing Accuracy: über 95 Prozent (Fehlerquote unter 5 Prozent)
• DSO: 30 bis 45 Tage (branchenabhängig)
• Overdue-Anteil: unter 15 Prozent
• Mahnquote: unter 20 Prozent
• Durchlaufzeit Leistung bis Rechnung: unter 3 Tage

Stammdaten

• Dublettenrate: unter 2 Prozent
• Pflichtfeld-Vollständigkeit: über 98 Prozent
• Änderungsvolumen monatlich: unter 5 Prozent der Basis
• Änderungsfehlerrate: unter 1 Prozent

Messung und Baseline

Definieren Sie folgende Parameter für eine belastbare Messung:

• Zeitraum: mindestens 3 Monate
• Stichprobe: mindestens 200 bis 500 Vorgänge
• Segmentierung: Gesellschaft, Team, Lieferantengruppe
• Zielwerte in Bandbreiten plus Sensitivitäten: Best Case, Realistic Case, Conservative Case

Trennen Sie Pilotmessung (kleinerer Scope, engeres Monitoring) von Rolloutmessung (breitere Basis, regelmäßiges Reporting).

Minimum Controls und Compliance: Was im Prozessdesign zwingend berücksichtigt werden muss

IKS- und Fraud-Perspektive sind nicht optional. Jeder Prozess muss grundlegende Kontrollpunkte berücksichtigen, um Auditfähigkeit, Nachvollziehbarkeit und Manipulationsschutz zu gewährleisten.

Typische Kontrollpunkte Procure-to-Pay

• 3-Way-Match (Bestellung, Wareneingang, Rechnung) wo sinnvoll
• Freigabegrenzen und Ausnahmefreigaben dokumentiert
• Trennung von Funktionen (SoD): Anlage versus Freigabe versus Zahlung
• Zahlungsfreigabeprozess (Vier-Augen, Limits, Ausnahmezahlungen)
• Bankdatenänderung nur mit zusätzlicher Prüfung (Change-Management)

Typische Kontrollpunkte Order-to-Cash

• Leistungsnachweis vor Rechnungsstellung
• Freigabe durch Projektleiter oder Vertrieb
• Dublettenprüfung vor Rechnungsversand
• Mahnprozess mit Eskalation und Dokumentation
• Zahlungszuordnung automatisiert plus manuelle Prüfung bei Ausnahmen

Fraud- und Manipulationsmuster, die Prozessdesign adressieren muss

• Bankdatenänderung kurz vor Zahlung
• Umgehung von Freigaben durch Dringlichkeit (Urgent Payment)
• Fiktive Lieferanten oder Dubletten
• Rechnungen ohne Bestellbezug oder Leistungsnachweis
• Splitting von Beträgen unterhalb Freigabegrenzen

Auditfähigkeit entsteht durch

• Nachvollziehbare Belegkette (wer, wann, was, warum)
• Konsistente Dokumentation (Ablage, Benennung, Versionierung)
• Audit-Trail und Logs (unveränderbar, zeitgestempelt)
• Klare Verantwortlichkeiten (RACI, Stellvertreterregelung)
• Aufbewahrungsfristen und Löschkonzept

Prüfungsnachweise, die vorbereitet sein müssen

• Prozessdokumentation inklusive Kontrollen
• Berechtigungskonzept und -nachweis (wer darf was)
• Änderungsprotokolle (Stammdaten, Bankdaten, Freigaben)
• Belegkette exemplarisch (Stichproben)
• Vier-Augen-Nachweis bei kritischen Vorgängen
• SoD-Matrix und Testnachweis

Roadmap und Priorisierung: Quick Wins, mittelfristige Maßnahmen, strukturelle Hebel

Die Priorisierung von Maßnahmen folgt dem Prinzip: schnelle Wirkung vor struktureller Tiefe. Nicht jede Verbesserung erfordert IT-Aufwand.

Quick Wins (0 bis 3 Monate, ohne IT)

• Klärfallkategorien definieren plus SLA und Eskalation
• Freigabelogik klären und dokumentieren
• Arbeitsanweisungen und Checklisten erstellen
• KPI-Routinen einführen (wöchentliches Review)
• Rollen und RACI-Matrix aufräumen

Mittelfristig (3 bis 6 Monate, mit IT)

• Workflow-Einführung oder -Optimierung (Status, SLA, Eskalation)
• Validierungen und Plausibilitätschecks (IBAN, Zahlungsbedingungen, Kontierung)
• Stammdaten-Governance (Owner, Regeln, Vier-Augen)
• Schnittstellen-Optimierung (Fehlerhandling, Retry, Logging)
• E-Rechnung/OCR-Qualität verbessern plus Ausnahmeregelungen

Langfristig (6 bis 12 Monate, strukturell)

• Process Mining wenn Event-Logs verfügbar
• End-to-End-Optimierung über Systemgrenzen
• Datenarchitektur und Master Data Management
• SoD-Automatisierung und Berechtigungsmanagement
• Kontinuierliche Verbesserung (KPI-Steuerung, regelmäßige Reviews)

Bewertungsmatrix für Maßnahmen

IT-Integration und Betrieb: Was CFOs von IT-Verantwortlichen einfordern sollten

CFOs müssen sicherstellen, dass IT-Architektur, Integration und Betrieb frühzeitig mitgedacht werden. Prozessoptimierung endet nicht mit dem Soll-Konzept, sondern muss in bestehende Systemlandschaften integriert und betrieben werden.

Systemkontext typisch

• ERP (SAP, Oracle, Microsoft Dynamics)
• DMS (DocuWare, d.velop, OpenText)
• Workflow/BPM (Nintex, Camunda, K2)
• OCR/eInvoice (Basware, Candis, DATEV)
• Bank/Payment (Camt, Pain, EBICS)
• Ticketing (Jira, ServiceNow)
• Stammdaten-Tools (Informatica, Profisee)
• Data Warehouse oder Analytics-Plattform

Integrations- und Schnittstellenmuster

• API (REST, SOAP) für Echtzeit und strukturierte Daten
• EDI (EDIFACT, X12) für standardisierte Transaktionen
• SFTP-basierte Übergaben für Batch und File-Transfer
• iPaaS/ESB (MuleSoft, Dell Boomi, Azure Logic Apps) für Orchestrierung
• Event-Logs als Grundlage für Monitoring und Process Mining
• Fehler-/Retry-Mechanismen, Idempotenz und Quarantäne-Queues für Ausnahmefälle

Security und Datenschutz

• Least Privilege, Rollenmodelle und SoD im Berechtigungsdesign
• Logging und Audit-Trail (unveränderbar, zeitgestempelt)
• Manipulationsschutz (Checksummen, digitale Signaturen)
• Nachvollziehbarkeit (wer, wann, was, IP, Änderungsgrund)
• Aufbewahrung, Löschung, Datenminimierung und Umgang mit personenbezogenen Daten

Betriebs- und Wartbarkeit

• Monitoring (Prozess-KPIs plus technische Metriken wie Response Time, Error Rate, Queue Length)
• Alerting (Schwellwerte, Eskalation, On-Call)
• Ownership (wer ist verantwortlich für Betrieb, Incident, Problem, Change)
• Incident/Problem/Change-Prozesse nach ITIL oder eigenem Standard
• Release-Management (Deployment-Fenster, Rollback-Plan, Testing)
• Dokumentationsstandard (Architektur, Schnittstellen, Runbooks)

Ergebnisformate für IT-Verantwortliche

• Sollprozess mit Systemzuordnung je Schritt plus Datenobjekte
• Schnittstellenübersicht (Quelle, Ziel, Format, Trigger, Fehlerfall)
• Backlog mit User Stories und Akzeptanzkriterien
• Betriebs- und Support-Konzept light (Owner, Monitoring, Logging, Eskalation)

Typische Stolpersteine und wie Sie sie vermeiden

Auch methodisch saubere Bachelorarbeiten scheitern an typischen Umsetzungshürden. Die folgenden Stolpersteine treten regelmäßig auf – und sind vermeidbar.

Stolperstein 1: Zu breiter Scope ohne Fokus

Symptom: Prozesslandkarte über mehrere Unternehmensbereiche, keine klare Abgrenzung.

Lösung: Begrenzen Sie auf einen Teilprozess (zum Beispiel Rechnungsprüfung, nicht gesamtes P2P), definieren Sie klare Ein- und Ausgangspunkte, setzen Sie Volumengrenzen (zum Beispiel nur eine Gesellschaft oder ein Team).

Stolperstein 2: Tool-Implementierung ohne Prozess- und Kontrollverständnis

Symptom: Workflow wird eingeführt, aber Ausnahmen und Fehlerbehandlung nicht geklärt.

Lösung: Erst Sollprozess inklusive Kontrollen und Ausnahmen definieren, dann Tool-Anforderungen ableiten, nicht umgekehrt.

Stolperstein 3: Kein Zugriff auf Event-Daten oder Belege

Symptom: Keine Logs, keine Stichproben, keine Messbarkeit.

Lösung: Datenzugang frühzeitig klären, Sponsor einbinden, notfalls Erhebung über Interviews und Workshops plus manuelle Stichproben.

Stolperstein 4: Zu wenige Fälle für belastbare Aussagen

Symptom: Nur 20 Vorgänge pro Monat, hohe Varianz.

Lösung: Zeitraum verlängern (3 bis 6 Monate), Segmentierung prüfen (sind es wirklich zu wenige oder gibt es versteckte Volumina), Fokus auf qualitative Ursachenanalyse statt rein quantitativ.

Stolperstein 5: Wunsch-Sollprozess ohne Pilottauglichkeit oder Betreibbarkeit

Symptom: Perfekter Prozess auf dem Papier, aber keine Testumgebung, keine Kapazitäten, keine Freigaben.

Lösung: Pilotplan frühzeitig entwickeln, Umsetzbarkeit mit IT und Fachbereich prüfen, notfalls Sollprozess in Stufen zerlegen (Minimum Viable Process).

Vorgehensmodell im Detail: Von Pain Point bis Entscheidungsvorlage

Das folgende Vorgehensmodell ist praxiserprobt und führt in neun Schritten von der Problemdefinition bis zum Pilotplan. Es orientiert sich an klassischen Projektphasen, berücksichtigt aber die Besonderheiten einer wissenschaftlichen Arbeit.

Schritt 1: Problem präzisieren (Woche 1)

• Was ist der Schmerz?
• Wie hoch ist der Impact (Kosten, Cash, Risiko)?
• Welche Teams sind betroffen?
• Wie hoch ist das Volumen?
• Wie messbar ist das Problem (Logs, KPIs, Tickets)?

Schritt 2: Ist-Prozess aufnehmen (Woche 2 bis 3)

Methode: Interviews, Job-Shadowing, Workshops, Dokumentenanalyse, System- und Workflow-Logs.

Ergebnis: Prozesslandkarte (High-Level), detaillierter Ist-Prozess inklusive Varianten und Ausnahmen, RACI-Matrix, Übergabepunkte, Schwachstellen-Hypothesen.

Schritt 3: Messkonzept und Baseline definieren (Woche 3 bis 4)

• KPIs auswählen (Durchlaufzeit, Klärfallquote, First-Time-Right, Prozesskosten, Skontoquote)
• Datenquellen identifizieren
• Baseline erheben (Zeitraum, Stichprobe, Segmentierung)
• Zielwerte in Bandbreiten festlegen

Schritt 4: Schwachstellen und Ursachen identifizieren (Woche 4 bis 5)

Methode: 5-Why, Ishikawa, Pareto, Root Cause Analysis.

Trennung Symptom (zu langsam) von Ursache (fehlende Stammdatenregel, unklare Freigabe, Schnittstellenbruch). Evidenz durch Beispiele, Daten, Interviews.

Schritt 5: Soll-Konzept entwickeln (Woche 5 bis 7)

• Sollprozess inklusive Rollen, Kontrollen, Systemzuordnung, Ausnahmehandling
• Datenanforderungen (Pflichtfelder, Validierungen, Schnittstellen)
• Kontrollpunkte (Freigaben, SoD, Logging)
• Systemoptionen (Workflow, Integration, Validierungen)

Schritt 6: Maßnahmen priorisieren (Woche 7 bis 8)

• Business Case je Maßnahme (Nutzen, Aufwand, Abhängigkeiten)
• Bewertungsmatrix (Nutzen, Aufwand, Time-to-Value, Risiko)
• Quick Wins, mittelfristige und strukturelle Maßnahmen trennen
• Roadmap entwickeln

Schritt 7: Pilot- oder PoC-Plan erstellen (Woche 8 bis 9)

• Scope definieren (Teilprozess, Team, Zeitraum)
• Erfolgsmessung festlegen (KPIs, Vergleich zu Baseline)
• Testplan (Szenarien, Testfälle, Rollen)
• Rollout-Option skizzieren (Skalierung, Betrieb, Change Management)

Checkliste für CFOs: Voraussetzungen und Erfolgsfaktoren

Bevor eine Bachelorarbeit zur Prozessoptimierung startet, sollten folgende Voraussetzungen geklärt sein. Diese Checkliste hilft, Enttäuschungen und Leerläufe zu vermeiden.

Vor Start der Bachelorarbeit klären

• Ist der Pain Point messbar und belastbar (Logs, KPIs, Volumina)?
• Gibt es einen identifizierbaren Cash- oder Kostenhebel (Skonto, DPO/DSO, Prozesskosten)?
• Sind Kontrollpunkte adressierbar (Freigaben, SoD, Audit-Trail)?
• Ist technische Realisierbarkeit gegeben (Schnittstellen, Testumgebung, Zugänge)?
• Ist Veränderbarkeit vorhanden (darf der Prozess angepasst werden, gibt es einen Prozessowner)?

Während der Arbeit sicherstellen

• Sponsor und Process Owner sind benannt und verfügbar
• Datenzugang ist geklärt (Logs, Belege, Stichproben)
• Zeitfenster der Fachexperten ist gesichert (Interviews, Workshops, Validierung)
• IT-Freigaben für Logs, Test und Pilot sind eingeholt
• Security-by-design-Mindeststandards sind definiert (SoD, Logging, Datenschutz)
• Ownership für Betrieb ist geklärt (wer übernimmt nach Pilot)

Ergebnisse bewerten anhand

• Ist die Ursachenanalyse evidenzbasiert (nicht nur Meinungen)?
• Ist das Soll-Konzept umsetzbar (nicht nur Wunschdenken)?
• Ist der Business Case plausibel (Annahmen transparent, Sensitivitäten gezeigt)?
• Ist der Pilotplan realistisch (Ressourcen, Zeitfenster, Abhängigkeiten geklärt)?
• Ist das Übergabepaket vollständig (Backlog, Schnittstellen, Betriebsanforderungen)?

Forschungsfragen: So formuliert, dass Nutzen und Umsetzung sofort erkennbar sind

Die Forschungsfrage entscheidet über Fokus, Methodik und Akzeptanz der Arbeit. Gute Forschungsfragen zeigen sofort, welches Problem gelöst wird und welchen Beitrag die Arbeit leistet.

Beispiel 1 (Procure-to-Pay)

Welche Prozess- und Datenursachen treiben Klärfälle in der Rechnungsprüfung, und welche Standardisierungs- und Workflow-Maßnahmen reduzieren Durchlaufzeit und Skontoverluste messbar (Ziel: Klärfallquote unter 10 Prozent, Durchlaufzeit unter 5 Tage)?

Beispiel 2 (Kontrollen)

Welche Kontrollen (Freigaben, SoD, Logging) erhöhen die Nachvollziehbarkeit im Zahlungsprozess, ohne die Durchlaufzeit zu erhöhen, und wie lassen sich diese in einem Workflow-System pilotieren?

Beispiel 3 (Integration)

Welche Medienbrüche zwischen ERP, DMS und Bankprozessen erzeugen Rework, und welches Integrations- und Fehlerhandling-Konzept senkt die Ausnahmequote messbar (Ziel: Rework-Anteil unter 5 Prozent)?

Beispiel 4 (Stammdaten)

Wie verbessert eine definierte Stammdaten-Governance (Owner, Regeln, Vier-Augen, Audit-Trail) Datenqualität und Prozessperformance in P2P/O2C, und welche KPIs messen den Erfolg (Ziel: Dublettenrate unter 2 Prozent, Änderungsfehlerrate unter 1 Prozent)?

Praxisbeispiel Procure-to-Pay: Von Schmerz zu Maßnahmen und Business Case

Das folgende Beispiel zeigt, wie aus einer diffusen Unzufriedenheit ein strukturiertes Optimierungsvorhaben mit messbarem Return on Investment entsteht.

Ausgangslage

• 1200 Rechnungen pro Monat
• Klärfallquote 28 Prozent
• Durchschnittliche Durchlaufzeit Klärfall 9 Tage
• Bearbeitungszeit 50 Minuten
• Skontoverlust 45 Prozent der Fälle
• Fehlende Transparenz über Liegeorte und Verantwortlichkeiten

Ursachenanalyse

• Fehlende oder falsche Bestellbezüge (40 Prozent der Klärfälle)
• Stammdatenqualität (Kontierung, Zahlungsbedingungen, 25 Prozent)
• Unklare Zuständigkeit bei Ausnahmen (20 Prozent)
• Medienbrüche (E-Mail, Excel, 15 Prozent)

Maßnahmen

• Klärfallkategorien definieren (Bestellbezug fehlt, Kontierung unklar, Betrag abweicht, Lieferant unbekannt) plus SLA (Kategorie A 2 Tage, Kategorie B 5 Tage) und Eskalation
• Pflichtfelder und Validierungen (Bestellnummer bei Wareneingangsbuchung, IBAN-Prüfung, Kontierungslogik)
• Standardisierte Eingangswege (E-Rechnungs-Beratung kann hier helfen: eInvoice bevorzugt, OCR für Papier, klare E-Mail-Adresse, kein Excel)
• Workflow-Einführung (Status, Verantwortlicher, Fälligkeit, Eskalation sichtbar)
• Stammdaten-Governance (Owner, Vier-Augen bei Bankdatenänderung, Änderungsprotokoll)
• KPI-Monitoring wöchentlich (Durchlaufzeit, Klärfallquote, Skontoquote, Liegezeit)

Business Case

Zeiteffekt: 168 vermiedene Klärfälle monatlich, 7 Stunden Zeitersparnis, 420 Euro Zeitkosten (60 Euro Stundensatz).

Skonto-Effekt: 336 Euro monatlich (168 mal 2 Euro).

Indirekte Effekte: Weniger Rückfragen, weniger Eskalationen, höhere Lieferantenzufriedenheit, bessere Forecast-Qualität.

Summe: 756 Euro monatlich, 9072 Euro pro Jahr.

Aufwand: Workflow-Konfiguration 40 Personentage (20.000 Euro), Schulung 10 Personentage (5000 Euro), laufender Betrieb 2 Stunden pro Woche (5200 Euro pro Jahr).

Payback: 2,8 Jahre (konservativ), bei optimistischer Schätzung (mehr Skonto, höhere Zeitersparnis) unter 2 Jahre.

Fazit und Handlungsempfehlung

Eine Bachelorarbeit Prozessoptimierung ist ein CFO-relevantes Instrument, wenn sie messbar auf Cash, Kosten, Risiko und Steuerbarkeit einzahlt. Sie ist dann besonders sinnvoll, wenn hohe Klärfallquoten, Medienbrüche, lange Liegezeiten, schwankende Qualität, Skontoverluste oder Intransparenz vorliegen.

Um das volle Potenzial zu heben, sollten Sie als Entscheider folgende Voraussetzungen schaffen:

• Sponsor und Process Owner benennen
• Datenzugang ermöglichen (Logs, Belege, Stichproben)
• Klare Ziel-KPIs definieren (Durchlaufzeit, Klärfallquote, Skontoquote, Prozesskosten)
• Zeitfenster der Fachexperten sichern (Interviews, Workshops, Validierung)
• IT-Freigaben für Logs, Test und Pilot einholen
• Security-by-design-Mindeststandards definieren (SoD, Logging, Datenschutz)
• Ownership für Betrieb klären (wer übernimmt nach Pilot)

Prozessoptimierung bedeutet nicht automatisch Automatisierung. Es geht darum, Prozesse, Kontrollen und Daten zu stabilisieren, bevor digitale Lösungen greifen können. Gerade bei Zahlungsabläufen lohnt ein Blick auf Request-to-Pay-Ansätze, um Ausnahmen, Freigaben und Transparenz end-to-end zu strukturieren. Wenn Sie diese Punkte beachten, wird eine Bachelorarbeit Prozessoptimierung zu einem wertvollen Instrument für Finance und IT, das nicht nur akademischen Ansprüchen genügt, sondern echte Wirkung entfaltet – messbar, umsetzbar und mit klarem Return on Investment.