Die Verantwortung für die Genauigkeit von Daten und Probleme in der Berichterstattung bei der Erweiterung von Legacy-ERP- oder CRM-Systemen mit BI liegt beim Business-Verantwortlichen für Datenqualität und Definitionen, während IT und BI für die technische Umsetzung und Transformationslogik zuständig sind.
Verantwortlichkeiten bei ERP-Reports
Bei der Modernisierung von ERP-Reports ist es entscheidend, Verantwortlichkeiten und Zuständigkeiten klar festzulegen. Dies verhindert, dass technische Teams für Entscheidungen verantwortlich gemacht werden, die sie nicht treffen können.
- Bestimmen Sie für jedes Datenobjekt und jeden KPI einen formellen Business-Verantwortlichen für semantische Definitionen.
- Weisen Sie technische Verantwortlichkeiten wie Datenextraktion und Transformationslogik der IT oder einem Softwarepartner zu.
- Implementieren Sie eine automatisierte Triagekette, um Verantwortlichkeiten bei Abweichungen zu verdeutlichen.
- Stellen Sie vor dem Go-live eines Systems eine formelle UAT-Abstimmung durch den Fachbereichsverantwortlichen sicher.
Wer ist für Fehler in ERP-Reports verantwortlich?
Ein Fehler in einem ERP-Report hat selten nur eine technische Ursache und gehört daher auch nicht automatisch in den Zuständigkeitsbereich eines technischen Teams. Sobald eine Organisation Daten aus einem Legacy-ERP oder CRM über Business Intelligence mehreren Abteilungen zugänglich macht, entstehen mindestens drei getrennte Verantwortlichkeiten. Das Business bestimmt, welches tatsächliche Ereignis in der Quelle erfasst wird und welche betriebswirtschaftliche Bedeutung eine Kennzahl hat. Die IT trägt die Verantwortung für den technischen Betrieb der Umgebungen und Schnittstellen. Das BI-Team verwaltet die Reporting-Logik, die Quelldaten in ein Modell, eine Berechnung oder ein Dashboard überführt. Diese Abgrenzung zeigt, wo eine Abweichung tatsächlich entsteht, anstatt die Reporting-Schicht als Standarderklärung zu verwenden.
Im Kern geht es um die Unterscheidung zwischen technischer Verfügbarkeit und semantischer Verantwortung. Ein Dashboard kann technisch korrekt Daten abrufen und die vereinbarte Berechnung ausführen, während eine ausgewiesene Marge oder ein Umsatz dennoch nicht den Erwartungen von Finance oder Operations entspricht. Wenn nicht formell festgelegt ist, wer die betriebswirtschaftliche Bedeutung dieser Kennzahlen verantwortet, werden IT oder BI stillschweigend für die Richtigkeit eines Ergebnisses verantwortlich gemacht, das sie nicht eigenständig bestimmen können. Dadurch wird eine Entscheidung über Definitionen oder Quellerfassung auf ein Team verlagert, das nicht das Mandat besitzt, diese Entscheidung zu treffen.
In dezentral organisierten Unternehmen wird diese Grenze besonders deutlich. Eigenständige Standorte können im selben ERP unterschiedliche Buchungsgewohnheiten haben. Ohne zentrales Master Data Management entstehen lokale Interpretationen von Feldern und Statuswerten. Die BI-Schicht führt diese Unterschiede zusammen und macht sie vergleichbar, kann jedoch nicht im Namen der Organisation entscheiden, welche lokale Eingabe maßgeblich ist. Die Verantwortung für die Harmonisierung bleibt daher beim benannten Business-Verantwortlichen des Datenobjekts; IT und BI machen die Unterschiede technisch sichtbar und beherrschbar.
Eine praktikable Aufteilung weist die Quellqualität dem Prozessverantwortlichen zu, der die Eingabe und Arbeitsweise beeinflussen kann, die technische Kontinuität der IT und die Ausführung dokumentierter Berechnungs- und Transformationslogik der BI. Die formelle Freigabe der Bedeutung eines KPI liegt bei der Business-Funktion mit Mandat für diesen KPI. Ein Softwarepartner kann eine komplexe Legacy-ERP-Umgebung über eine maßgeschneiderte Zwischenschicht modular erschließen, ohne laufende Prozesse zu stören, übernimmt dadurch jedoch nicht die betriebswirtschaftliche Verantwortung für Umsatz, Marge oder Auftragsstatus.
Quellen zu diesem Abschnitt: DAMA-DMBOK: Data Management Body of Knowledge
Warum entstehen Probleme bei ERP-Reports?
Probleme in ERP-Reports entstehen häufig nicht, weil ein Dashboard an sich unzuverlässig ist, sondern weil ein Report einen Unterschied zwischen Abteilungen offenlegt, für den keine verbindliche Entscheidung besteht. Finance und Operations können beispielsweise in einer Besprechung dieselbe Kennzahl verwenden, aber unterschiedliche Annahmen darüber haben, was darin enthalten ist. Solange kein expliziter Sign-off-Mechanismus für Definition, Zweck und Akzeptanz dieser Kennzahl besteht, erhält die Reporting-Schicht eine Rolle, die sie nicht erfüllen kann: Schiedsrichter in einem internen Prozesskonflikt zu sein.
Dieses Muster verstärkt sich, wenn die Verantwortung für die Quellerfassung unklar bleibt. Denken Sie an eine Situation, in der Abteilungen Auftragsstatus unvollständig oder nicht einheitlich in einem Legacy-ERP erfassen. Ein BI-Dashboard kombiniert diese Statuswerte anschließend zu einer operativen Durchlaufzeit. Das Ergebnis weicht von den Erwartungen einer Abteilung ab, woraufhin der Verdacht schnell auf die Transformationslogik fällt. Die tatsächliche Ursache kann jedoch in der Quellerfassung liegen. Wenn niemand formell für die Vollständigkeit und konsistente Anwendung dieses Status verantwortlich ist, fehlt auch die Instanz, die die Abweichung beurteilen und beheben kann.
Die Folgen betreffen mehr als die tägliche Berichterstattung. Ein Dashboard, das von verschiedenen Teams unterschiedlich gelesen wird, erhält keine klare Akzeptanz. Die Einführung des Reports kann dann blockiert werden, nicht weil ein technischer Fehler nachgewiesen wurde, sondern weil keine Instanz befugt ist, die Definition oder die Quellerfassung als Grundlage zu bestätigen. Die IT kann in einer solchen Situation die Datenverfügbarkeit untersuchen. BI kann aufzeigen, wie Felder übersetzt werden. Keines der beiden Teams kann jedoch eigenständig bestimmen, welche operative Interpretation gültig ist.
Dies erklärt auch, warum Schuldzuweisungen so oft auf der falschen Ebene landen. Die sichtbare Abweichung steht im Dashboard, daher scheint die Reporting-Software die Ursache zu sein. Die zugrunde liegende Entscheidung darüber, was eine Kennzahl bedeutet und welche Quellerfassung dafür akzeptabel ist, liegt jedoch in der Verantwortung der beteiligten Business-Funktionen. Eine formelle Abstimmung zwischen Finance und Operations verlagert das Gespräch von „Welches Team hat einen Fehler gemacht?“ zu „Welche Definition und Erfassung akzeptieren wir als Organisation?“. Dadurch entsteht Raum für eine überprüfbare Bewertung des Reports, anstatt für eine Eskalation auf der Grundlage von Erwartungen, die nie festgelegt wurden.
Quellen zu diesem Abschnitt: COBIT: Control Objectives for Information and Related Technologies
Häufige Verantwortungslücken bei ERP-Reports
Eine Verantwortungslücke entsteht, wenn die Partei, die eine Abweichung feststellt, nicht dieselbe ist wie die Partei, die die Ursache beeinflussen oder eine inhaltliche Entscheidung treffen darf. In ERP-Reports tritt dies in zwei erkennbaren Formen auf. Die erste betrifft Quelldaten: Eine Finanzkennzahl weicht ab, aber niemand ist ausdrücklich dafür benannt, die Vollständigkeit des relevanten Quellfelds zu überwachen. Die zweite betrifft Definitionen: Teams verwenden denselben KPI-Namen, ziehen jedoch unterschiedliche Grenzen dafür, was einbezogen wird. Beide Lücken machen eine technische Ebene für eine organisatorische Entscheidung verantwortlich.
Das Muster, bei dem das Datenteam als Sündenbock fungiert, zeigt dies deutlich. Data Engineers oder ein Softwarepartner können für fehlerhafte Finanzkennzahlen verantwortlich gemacht werden, obwohl die Ursache fehlende Einkaufspreise im ERP sind. Die Reporting-Schicht kann diesen fehlenden Wert sichtbar machen oder ihn nach einer vereinbarten Regel verarbeiten, kann jedoch nicht bestimmen, welcher Preis hätte erfasst werden müssen. Wird diese Unterscheidung nicht getroffen, richtet sich die Korrekturarbeit auf die falsche Stelle. Die Diskussion dreht sich dann um ein Reporting-Ergebnis, während die Quellerfassung und der dahinterliegende Prozess außer Betracht bleiben.
Eine weitere Lücke ist die Definitionsblockade zwischen Finance und Sales. Sales möchte möglicherweise nicht verbindlich beauftragte Aufträge in ein Dashboard einbeziehen, während Finance ausschließlich verbindliche Buchungen akzeptiert. Beide Sichtweisen können aus der jeweiligen Arbeitspraxis nachvollziehbar sein, führen jedoch zu keinem einzigen, von der Unternehmensleitung genehmigten KPI, solange niemand eine Entscheidung trifft. Das Dashboard verbleibt dann in einem vorläufigen Zustand. BI erhält Anfragen zur Änderung von Berechnungen, ohne dass klar ist, welche Version zur gültigen Geschäftsdefinition wird. Die technische Implementierung wird dadurch zu einem Ersatz für Entscheidungsfindung.
Diese Verantwortungslücken haben eine klare Grenze. Ein Datenteam kann eine Abweichung untersuchen und nachvollziehbar machen; es ist nicht die Partei, die einen fehlenden Einkaufspreis einträgt oder festlegt, ob ein nicht verbindlich beauftragter Auftrag Umsatz darstellt. Finance und Sales können ihre jeweiligen Interpretationen erläutern; ohne bestimmte Entscheidungsinstanz bleibt der KPI unentschieden. Die praktische Konsequenz ist, dass ein Problem nicht nur als „Reporting-Fehler“ erfasst werden kann. Es muss als Quellqualität, Definitionsentscheidung oder Ausführung der Reporting-Logik klassifiziert werden. Erst dann fällt die Verantwortung dem Team zu, das tatsächlich handeln oder entscheiden kann.
Quellen zu diesem Abschnitt: DAMA-DMBOK: Data Management Body of Knowledge
Wichtige Entscheidungsfaktoren für Verantwortlichkeiten bei ERP-Reports
Die Zuweisung von Verantwortlichkeiten wird praktikabel, wenn die Organisation für jedes Datenobjekt und jeden KPI festlegt, wer letztverantwortlich ist und wie viel Governance nötig ist, um zu einer Entscheidung zu gelangen. Die folgenden Faktoren verhindern, dass eine RACI-Übersicht zu einer allgemeinen Rollenverteilung ohne Wirkung auf konkrete ERP-Reports wird.
| Entscheidungsfaktor | Bedeutung für die Verantwortung | Folge für die Ausgestaltung |
|---|---|---|
| Objekt oder KPI als Abgrenzung | Ein Datenobjekt und eine KPI-Definition erfordern jeweils einen klar erkennbaren Gegenstand der Entscheidungsfindung. Eine breite Bezeichnung wie „Reporting“ ist zu weit gefasst, um festzustellen, wer wofür verantwortlich ist. | Halten Sie getrennt fest, wer etwa Entscheidungen über eine Quellinformation trifft und wer die Definition eines bestimmten KPI verantwortet. Dadurch wird eine Abweichung auf der richtigen Ebene beurteilt. |
| Eine formell letztverantwortliche Person | Für jedes Datenobjekt oder jede KPI-Definition sollte genau eine formell letztverantwortliche Person bestimmt werden. Mehrere letztverantwortliche Personen führen zu diffuser Entscheidungsfindung: Alle können konsultiert werden, aber niemand muss einen Konflikt beenden. | Bestimmen Sie eine Rolle oder Person, die eine Definition bestätigt, eine Änderung akzeptiert oder einen inhaltlichen Streit entscheidet. Andere Beteiligte können beitragen oder informiert werden, ohne eine zweite endgültige Entscheidung zu bilden. |
| Risiko von Eskalationsschleifen | Wenn ein Problem zwischen Teams zirkuliert, fehlt in der Regel nicht weitere Analyse, sondern eine befugte Entscheidung über Verantwortung oder Definition. | Nutzen Sie die benannte letztverantwortliche Person als Endpunkt für Streitfälle, die nicht durch technische Kontrolle gelöst werden können. So wird aus Abstimmung eine Entscheidung, der die Reporting-Logik folgen kann. |
| Umfang des Governance-Prozesses | Ein umfassendes theoretisches Governance-Programm kann so viel Analyse erfordern, dass konkrete Verbesserungen ausbleiben. Gleichzeitig lässt eine schnelle Dashboard-Bereitstellung ohne klare Verantwortlichkeiten offen, wer spätere Fragen bearbeitet. | Beginnen Sie iterativ mit Kern-KPIs und den zugehörigen Datenobjekten. Dieser schrittweise Ansatz liefert frühzeitig eine nutzbare, abgegrenzte Vereinbarungssammlung und verhindert, dass alle Definitionen im Voraus vollständig ausgearbeitet werden müssen. |
| Flexibilität bei Änderungen | Eine KPI-Definition kann während der Modernisierung Klärungen erfordern. Flexibilität bedeutet hier nicht, dass jede Abteilung eigene Änderungen vornimmt, sondern dass Änderungen über eine klar erkennbare verantwortliche Instanz laufen. | Halten Sie die erste Reihe von Verantwortlichkeiten kompakt und erweitern Sie sie je Kern-KPI. Dadurch kann die Organisation aus konkreten Reporting-Fragen lernen, ohne die Entscheidungsbefugnis zu verwässern. |
Quellen zu diesem Abschnitt: DAMA-DMBOK: Data Management Body of Knowledge
Ein praktisches Framework für Verantwortlichkeiten bei ERP-Reports
Eine praktikable Ausgestaltung beginnt mit einer begrenzten Zahl konkreter Reports und legt nicht nur Rollen fest, sondern auch die Nachweise, anhand derer ein Ergebnis beurteilt werden kann. Die folgenden Schritte verbinden Quellerfassung, Reporting-Logik und formelle Akzeptanz, ohne vorauszusetzen, dass ein Legacy-ERP zuvor vollständig bereinigt sein muss.
- Erfassen Sie abweichende Feldbefüllungen zuerst. Legacy-ERP- und CRM-Systeme verfügen häufig nicht über strenge Validierung an der Quelle. Operative Nutzer können historische Felder daher für einen anderen Zweck wiederverwenden. Dokumentieren Sie für jedes relevante Feld, welche abweichenden Befüllungen vorkommen und welches KPI-Ergebnis dadurch scheinbar fehlerhaft sein kann. Dies verhindert, dass eine BI- oder Laravel-Reporting-Schicht angepasst wird, bevor klar ist, welche Quellnutzung die Abweichung verursacht.
- Verknüpfen Sie die Quellqualität mit der beeinflussbaren Arbeitspraxis. Weisen Sie die Verantwortung für ein Quellfeld der Business-Funktion zu, die dessen Erfassung und Anwendung bestimmen kann. Die Aufgabe besteht nicht nur darin, einen Verantwortlichen zu benennen, sondern festzulegen, welche Eingabe für das Reporting akzeptiert wird. Die technische Ebene kann anschließend aufdecken, welche Werte abweichen und wie sie im Reporting verarbeitet werden, ohne im Namen des Business eine inhaltliche Interpretation zu wählen.
- Dokumentieren Sie die Transformation vom Feld zum KPI. Halten Sie fest, welche Quellfelder verwendet werden, welche Umwandlung stattfindet und wie diese Umwandlung in einem Dashboard erscheint. Diese nachvollziehbare Data Lineage ermöglicht es, bei einer Abweichung den Weg von der ERP- oder CRM-Quelltabelle zurück zum Report nachzuverfolgen. Dadurch wird die Untersuchung konkret: Ein Team kann feststellen, ob die Fragestellung in der Quellerfassung oder in der angewendeten Regel liegt.
- Machen Sie die Nutzerakzeptanz zur betriebswirtschaftlichen Prüfung. Formelle UAT-Sign-offs verbinden die technische Umsetzung mit einem genehmigten Geschäftsergebnis. Das Business beurteilt dabei nicht nur die Darstellung eines Dashboards, sondern auch, ob das Ergebnis der festgelegten Bedeutung des KPI entspricht. So wird Akzeptanz nachweisbar, und eine technische Lieferung bleibt nicht an informellen Erwartungen hängen.
- Führen Sie neben dem Reporting ein Verantwortlichkeitsregister. Erfassen Sie für jedes Datenobjekt und jeden KPI, wer verantwortlich ist, welche Transformationen gelten und welche Freigabe erteilt wurde. In Umgebungen mit formellen Kontrollen stellt das Fehlen eines solchen Registers, einer nachvollziehbaren Data Lineage und eines formellen UAT-Sign-offs ein Risiko für schwerwiegende Auditfeststellungen beim Jahresabschluss dar. Das Register verdeutlicht außerdem, welches Team eine Änderungs- oder Korrekturanfrage inhaltlich beurteilen muss.
- Behandeln Sie jede Abweichung als nachvollziehbare Fragestellung. Beginnen Sie bei der Kennzahl im Dashboard, verfolgen Sie die dokumentierte Transformation zurück zur Quelle und bestimmen Sie anschließend, ob die Korrektur bei der Eingabe, einer genehmigten Regel oder der Reporting-Ausführung erfolgen muss. Diese Reihenfolge verhindert, dass eine sichtbare Abweichung unmittelbar als Softwarefehler klassifiziert wird, obwohl die Grundlage in einem historisch genutzten ERP-Feld liegen kann.
Quellen zu diesem Abschnitt: DAMA-DMBOK: Data Management Body of Knowledge, COBIT: Control Objectives for Information and Related Technologies
Häufig gestellte Fragen zu Verantwortlichkeiten bei ERP-Reports
Zwei Einwände treten häufig auf, wenn eine Organisation Verantwortlichkeiten rund um Legacy-ERP-Reports festlegen will: Verlangsamt dies die Dashboard-Bereitstellung, und muss das Quellsystem dann zunächst vollständig bereinigt werden? Beide Fragen betreffen einen realen Zielkonflikt zwischen unmittelbaren Ergebnissen, operativen Störungen und späterem Korrekturaufwand.
- „Können wir nicht zuerst Dashboards bereitstellen und Verantwortlichkeiten später regeln?“
Das kann kurzfristig sichtbare Ergebnisse liefern, doch ohne festgelegte Verantwortlichkeiten entsteht Governance-Schuld. Bei der nächsten Abweichung ist dann unklar, wer eine Quellinformation korrigieren darf, wer eine KPI-Definition bestätigt und wer eine Änderung freigibt. Die Kosten verlagern sich auf einen späteren Zeitpunkt, wenn Dashboards bereits genutzt werden und sich Unterschiede in der Interpretation verfestigt haben. Ein begrenzter erster Umfang mit klaren Verantwortlichkeiten verhindert nicht jede Folgefrage, aber verhindert, dass das Reporting ohne Instanz für inhaltliche Entscheidungen übergeben wird. - „Muss der Legacy-ERP-Kern vollständig bereinigt werden, bevor BI starten kann?“
Eine vollständige Quellbereinigung kann kostspielig sein und operative Störungen verursachen. Eine Alternative besteht darin, Validierungs- und Korrekturregeln in einer Laravel-Middleware oder Integrationsschicht zu automatisieren, damit die Reporting-Schicht schneller nutzbare Daten erhält. Diese Entscheidung verlagert jedoch nicht die inhaltliche Verantwortung: Das Business muss die angewendeten Regeln formell genehmigen. Andernfalls wird eine technische Korrektur später angefochten, weil nicht festgelegt ist, welche historische Eingabe als gültig oder abweichend gilt. - „Wer entscheidet dann über eine Regel, die einen Mangel in der Quelle ausgleicht?“
Die formelle Akzeptanz liegt beim Business, das die Bedeutung der betreffenden Information und des KPI verantwortet. IT und BI können die Regel umsetzbar machen und sichtbar machen, was sie bewirkt, doch eine automatisierte Korrektur ist kein neutraler technischer Eingriff, wenn sie eine geschäftliche Interpretation festschreibt. Die Frage ist daher nicht nur, ob die Regel technisch funktioniert, sondern auch, ob die Organisation diese Interpretation als gültige Grundlage für ihr Reporting akzeptiert.
Quellen zu diesem Abschnitt: DAMA-DMBOK: Data Management Body of Knowledge
Wichtige Überlegungen für Verantwortlichkeiten bei ERP-Reports
Die Qualität von Verantwortlichkeiten zeigt sich nicht in einer RACI-Tabelle, die nur Funktionen nennt, sondern darin, wie eine konkrete Abweichung untersucht, genehmigt und abgeschlossen werden kann. Für ERP-Reports auf Basis von Legacy-Systemen bieten die folgenden Merkmale eine überprüfbare Grundlage für die Zusammenarbeit zwischen Business, IT und einem Softwarepartner.
- Nachvollziehbarkeit auf Feldebene macht Verantwortung überprüfbar.
Eine nutzbare Reporting-Lösung kann nachweisbar zeigen, wie eine Kennzahl aus ERP- oder CRM-Quelltabellen über Transformationen in ein Dashboard gelangt. Auditierbare Logs und End-to-End-Data-Lineage machen dabei sichtbar, welches Quellfeld, welche Umwandlung und welches Reporting-Ergebnis zusammengehören. Dies verwandelt eine Diskussion über Datenrichtigkeit in eine überprüfbare Kette: Ein Business-Verantwortlicher kann die Quellbedeutung bewerten, während IT und BI die technische Verarbeitung nachweisen können. Ohne diese Nachvollziehbarkeit bleiben Teams von Annahmen darüber abhängig, wo sich eine Kennzahl verändert hat. - Formelle Validierung macht Änderungen und Eskalationen steuerbar.
Ein im Voraus genehmigtes RACI-Validierungsprotokoll legt fest, wie UAT durchgeführt wird, wer für KPI-Anpassungen zeichnungsberechtigt ist und über welchen Eskalationsweg ein Konflikt verläuft. Wenn diese Vereinbarungen zwischen IT, Business und Softwarepartner vertraglich festgelegt sind, ist auch bei einer Änderung klar, wer beurteilt, wer ausführt und wer die endgültige Akzeptanz erteilt. Dies begrenzt nicht nur Verzögerungen durch wiederkehrende Diskussionen, sondern auch finanzielle und operative Risiken. Ohne festgelegte Zeichnungsberechtigung kann eine Änderung der KPI-Logik umgesetzt werden, ohne nachweisbare geschäftliche Akzeptanz, während die Folgen später in Steuerung, Kontrollen oder beim Jahresabschluss sichtbar werden.
