Ausgestaltung und Einführung einer Reporting Factory: Unterschied zwischen den Versionen

Aus Controlling-Wiki
(Version1)
 
Keine Bearbeitungszusammenfassung
 
(25 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Die Ziele der Reporting Factory können lediglich mit einer durchdachten Ausgestaltung und einer effizienten und reibungslosen Einführung erreicht werden. Aus diesem Grund sind die Arbeiten zur Ausgestaltung der Bausteine sowie der Ansätze zur Einführung der Reporting Factory ein zentraler und wichtiger Schritt. Die abschliessende Einführungsphase, mit fünf aufeinanderfolgenden Schritten, sollte auch gebührend Aufmerksamkeit erhalten.  
{{Geprueft|+}}
 
Die Ziele der [[Reporting Factory]] können lediglich mit einer durchdachten Ausgestaltung und einer effizienten sowie reibungslosen Einführung erreicht werden. Aus diesem Grund sind die Arbeiten zur Ausgestaltung der Bausteine sowie der Ansätze zur Einführung der [[Reporting Factory]] ein zentraler und wichtiger Schritt. Die abschliessende Einführungsphase, mit fünf aufeinanderfolgenden Schritten, sollte auch gebührend Aufmerksamkeit erhalten.  


==Bausteine einer Reporting Factory==
==Bausteine einer Reporting Factory==
[[Datei:AufbauReportingFactory.png|thumb|right|Abb. 1: Grundlegender Aufbau einer [[Reporting Factory]] (Schmitz et al., 2016, S. 433)]]
Um die [[Reporting Factory]] exakt den Bedürfnissen einer Unternehmung entsprechend aufzubauen, werden Informationen über den Umfang und den Tätigkeitsbereich benötigt (Krüger & Danner, 2004, S. 218). Untenstehend wird der grundlegende Aufbau einer [[Reporting Factory]] mit den Entscheidungskriterien aufgelistet und erläutert. Als grafische Veranschaulichung finden Sie die unterschiedlichen Bausteine ebenfalls in der Abbildung 1.
Um die [[Reporting Factory]] exakt den Bedürfnissen einer Unternehmung entsprechend aufzubauen, werden Informationen über den Umfang und den Tätigkeitsbereich benötigt (Krüger & Danner, 2004, S. 218). Untenstehend wird der grundlegende Aufbau einer [[Reporting Factory]] mit den Entscheidungskriterien aufgelistet und erläutert. Als grafische Veranschaulichung finden Sie die unterschiedlichen Bausteine ebenfalls in der Abbildung 1.
'''''PLATZHALTER ABBILDUNG'''''
===Produkte und Services / Dienstleistungen===
===Produkte und Services / Dienstleistungen===
Im folgenden Baustein stellt sich die zentrale Frage, welche Reports erstellt werden sollten. Dazu gibt es zwei unterschiedliche Herangehensweisen, welche untenstehend gegenübergestellt werden.
Im folgenden Baustein stellt sich die zentrale Frage, welche Reports erstellt werden sollten. Dazu gibt es zwei unterschiedliche Herangehensweisen, welche in der folgenden Tabelle erläutert werden.


{| class="wikitable"
{| class="wikitable"
Zeile 12: Zeile 14:
!rowspan="2"| Managementreports
!rowspan="2"| Managementreports
|-
|-
| A1 | Liegt der Fokus auf der Erstellung von Managementreports, beschäftigt sich die Reporting Factory mehrheitlich mit dem Verdichten von Informationen oder der Erstellung von Output-Formaten wie Präsentationen oder Berichte.
| A1 | Liegt der Fokus auf der Erstellung von Managementreports, beschäftigt sich die [[Reporting Factory]] mehrheitlich mit dem Verdichten von Informationen oder der Erstellung von Output-Formaten wie Präsentationen oder Berichte.
Anfangs validiert, analysiert und kommentiert die Factory die generierten Daten inhaltlich. Durch die Lernfähigkeit der Reporting Factory wird Know-how im Geschäftsbereich angeeignet, welche in anderen Aufgaben aufgegriffen werden kann, so Schmitz, Lawrenz & Drerup (2016, S. 433). Langfristig kann die Reporting Factory auch im Bereich Planung und Prognosen eine unterstützende Funktion wahrnehmen.
Anfangs validiert, analysiert und kommentiert die Factory die generierten Daten inhaltlich. Durch die Lernfähigkeit der [[Reporting Factory]] wird Know-how im Geschäftsbereich angeeignet, welche in anderen Aufgaben aufgegriffen werden kann (Schmitz et al., 2016, S. 433). Langfristig kann die [[Reporting Factory]] auch im Bereich Planung und Prognosen eine unterstützende Funktion wahrnehmen.
|-
|-
!rowspan="2"| Massenreports
!rowspan="2"| Massenreports
|-
|-
| A2 | Besteht die Hauptaufgabe in der Generierung von Massenreports, definieren sich die Tätigkeiten der Reporting Factory tendenziell eher im operativen Bereich. Die Informationsbereitstellung soll weitestgehend automatisiert von Systemen generiert werden. Die aufzusetzenden Systemaktivitäten sind beispielsweise ein automatisiertes Datenmanagement, die Datenverknüpfung zwischen den verfügbaren Daten und die weitestgehend Standardisierung und Automatisierung von Datawarehouse und ERP Systemumgebungen (Schmitz, Lawrenz & Drerup, 2016, S. 434). Langfristig kann die Reporting Factory auch in ein Self-Service Business Intelligence gewandelt werden (metric-x, 2016, online).
| A2 | Besteht die Hauptaufgabe in der Generierung von Massenreports, definieren sich die Tätigkeiten der [[Reporting Factory]] tendenziell eher im operativen Bereich. Die Informationsbereitstellung soll weitestgehend automatisiert von Systemen generiert werden. Die aufzusetzenden Systemaktivitäten sind beispielsweise ein automatisiertes [[Datenmanagement]], die Datenverknüpfung zwischen den verfügbaren Daten und die weitestgehend Standardisierung und Automatisierung von Datawarehouse und ERP Systemumgebungen (Schmitz et al., 2016, S. 434). Langfristig kann die [[Reporting Factory]] auch in ein [[Self-Service Business Intelligence]] gewandelt werden (metric-x, 2016, online).
|-
|-
|}
|}
===Kunden===
===Kunden===
In direktem Zusammenhang mit den Produkten und Services / Dienstleistungen steht die Frage nach dem Kundenkreis. Die Produkte definieren nicht abschliessend welchen Kundenkreis die Reporting Factory bedient. Vielmehr ist die zu bedienende Hierarchieebene von Relevanz, so Schmitz, Lawrenz & Drerup (2016, S. 434).
In direktem Zusammenhang mit den Produkten und Services / Dienstleistungen steht die Frage nach dem Kundenkreis. Die Produkte definieren nicht abschliessend welchen Kundenkreis die [[Reporting Factory]] bedient. Vielmehr ist die zu bedienende Hierarchieebene von Relevanz (Schmitz et al., 2016, S. 434).


{| class="wikitable"
{| class="wikitable"
Zeile 28: Zeile 31:
!rowspan="2"| Managementreports
!rowspan="2"| Managementreports
|-
|-
| A1 | Der Kundenkreis der Managementreports reichen vom Vorstand bis zu leitenden Funktionen (Schmitz, Lawrenz & Drerup, 2016, S. 434).
| A1 | Der Kundenkreis der Managementreports reichen vom Vorstand bis zu leitenden Funktionen (Schmitz et al., 2016, S. 434).
Anfangs validiert, analysiert und kommentiert die Factory die generierten Daten inhaltlich. Durch die Lernfähigkeit der Reporting Factory wird Know-how im Geschäftsbereich angeeignet, welche in anderen Aufgaben aufgegriffen werden kann, so Schmitz, Lawrenz & Drerup (2016, S. 433). Langfristig kann die Reporting Factory auch im Bereich Planung und Prognosen eine unterstützende Funktion wahrnehmen.
|-
|-
!rowspan="2"| Massenreports
!rowspan="2"| Massenreports
|-
|-
| A2 | Der Kundenkreis der Massenreport ist wesentlich grösser. Detaillierte Berichte gehen zuhanden von operativen Manager und Werksleiter, die einen ausgewählten Standardberichten wünschen. Weiter werden auch darunterliegende Ebenen mit Berichten versorgt. Diese weisen jedoch einen deutlich höheren Detailgrad auf (Schmitz, Lawrenz & Drerup, 2016, S. 434).
| A2 | Der Kundenkreis der Massenreport ist wesentlich grösser. Detaillierte Berichte gehen zuhanden von operativen Manager und Werksleiter, die einen ausgewählten Standardberichten wünschen. Weiter werden auch darunterliegende Ebenen mit Berichten versorgt. Diese weisen jedoch einen deutlich höheren Detailgrad auf (Schmitz et al., 2016, S. 434).
|-
|-
|}
|}


Entfernt von der Frage nach der zu bedienenden Hierarchieebene bedingt gemäss Schmitz, Lawrenz & Drerup (2016, S. 434) auch die Anfangsphase einer Reporting Factory gebührend Aufmerksamkeit zu erhalten. Speziell in der Aufbauphase einer neuen Organisationseinheit ist die Produktivität der Mitarbeitenden noch nicht auf der vollen Leistungskapazität. Aus diesem Grund kann es Sinn machen, nur einen Teil der Unternehmung mit den Dienstleistungen und den Produkten der Reporting Factory zu bedienen.
Entfernt von der Frage nach der zu bedienenden Hierarchieebene bedarf auch die Anfangsphase gebührend an Aufmerksamkeit (Schmitz et al., 2016, S. 434). Speziell in der Aufbauphase einer neuen Organisationseinheit ist die Produktivität der Mitarbeitenden noch nicht auf der vollen Leistungskapazität. Aus diesem Grund kann es Sinn machen, nur einen Teil der Unternehmung mit den Dienstleistungen und den Produkten der [[Reporting Factory]] zu bedienen.


===Organisation===
===Organisation===
Das Generieren einer neuen Organisationseinheit bedingt auch zwingend das Erstellen eines Organigramms. Zuerst muss ein Leiter der Reporting Factory erkoren werden, welcher die Führungsaufgaben der neuen Organisationseinheit übernimmt. Anschliessend muss geklärt werden, nach welchen Kriterien sich die Organisationseinheit ausrichten soll. Im Konkreten gibt es vier unterschiedliche Ausrichtungskriterien: Kunden, Produkte und Services, interne Prozesse, regionale Aufstellung (Mellewigt & Decker, 2006, S. 72 ff.). Nachstehend sind zwei Ausrichtungskriterien exemplarisch dargestellt. In Abbildung 2 wird die Reporting Factory nach Kunden gegliedert, während in Abbildung 3 eine Struktur nach internen Prozessen durchgesetzt wird.
Das Generieren einer neuen Organisationseinheit bedingt auch zwingend das Erstellen eines Organigramms. Zuerst muss ein Leiter der [[Reporting Factory]] erkoren werden, welcher die Führungsaufgaben der neuen Organisationseinheit übernimmt. Anschliessend muss geklärt werden, nach welchen Kriterien sich die Organisationseinheit ausrichten soll. Im Konkreten gibt es vier unterschiedliche Ausrichtungskriterien: Kunden, Produkte und Services, interne Prozesse, regionale Aufstellung (Mellewigt & Decker, 2006, S. 72 ff.). Nachstehend sind zwei Ausrichtungskriterien exemplarisch dargestellt. In Abbildung 2 wird die [[Reporting Factory]] nach Kunden gegliedert, während in Abbildung 3 eine Struktur nach internen Prozessen durchgesetzt wird.
 
[[Datei:OrganisationKunden.png|thumb|left|Abb. 2: Organisationsstruktur nach Kunden (Schmitz et al., 2016, S. 437)]]
'''''PLATZHALTER ABBILDUNG'''''               
[[Datei:OrganisationProzesse.png|thumb|center|Abb. 3: Organisationsstruktur nach internen Prozessen (Schmitz et al., 2016, S. 437)]]
Abb. 2 Organisationsstruktur nach Kunden Abb. 3 Organisationsstruktur nach internen Prozessen


===Datenmanagement, Datenmodel & Systemarchitektur===
===Datenmanagement, Datenmodel & Systemarchitektur===
Nach Rahtjen (2008, S. 37) ist eine Reporting Factory primär für die Bereitstellung von Reports zuständig. Weiter ist diese Einheit aber auch im Bereich der Optimierung der Reports und der Aufwandreduktion bei deren Erstellung federführend. Dazu hat die Reporting Factory die Befugnis bestehende Reportingprozesse zu standardisieren und automatisieren.
Nach Rahtjen (2008, S. 37) ist eine [[Reporting Factory]] primär für die Bereitstellung von Reports zuständig. Weiter ist diese Einheit aber auch im Bereich der Optimierung der Reports und der Aufwandreduktion bei deren Erstellung federführend. Dazu hat die [[Reporting Factory]] die Befugnis bestehende Reportingprozesse zu standardisieren und automatisieren.
Eine Analyse der bestehenden Reporting-Inhalte ist speziell beim Aufbau einer Reporting Factory wichtig. Zentral ist die Überlegung, ob eine Überarbeitung des Reporting in Bezug auf die künftige Entscheidungsfindung zielführend ist oder nicht. Falls sich die Unternehmung entscheidet die Reports wie bis anhin zu belassen, werden die bestehenden Prozesse und Datengrundlagen mit einem Lift and Shift Ansatz übernommen (Schmitz, Lawrenz & Drerup, 2016, S. 439).
Eine Analyse der bestehenden Reporting-Inhalte ist speziell beim Aufbau einer [[Reporting Factory]] wichtig. Zentral ist die Überlegung, ob eine Überarbeitung des Reporting in Bezug auf die künftige Entscheidungsfindung zielführend ist oder nicht. Falls sich die Unternehmung entscheidet die Reports wie bis anhin zu belassen, werden die bestehenden Prozesse und Datengrundlagen mit einem [[Ausgestaltung und Einführung einer Reporting Factory#Lift and Shift|Lift and Shift Ansatz]] übernommen (Schmitz et al., 2016, S. 439).
Neben der Analyse der Reporting-Inhalte ist auch die richtige Darstellung wichtig. Eine klare Struktur, gemäss Schäffer et al. (2012, S. 52), dient dazu den Kunden auf die zentralen Inhalte aufmerksam zu machen. Deshalb ist es relevant ein standardisiertes und einfaches Layout aufzuerlegen und die Inhalte nicht nur verbal, sondern auch in geeigneten Tabellen oder Graphiken zu visualisieren.  
Neben der Analyse der Reporting-Inhalte ist auch die richtige Darstellung wichtig. Eine klare Struktur, gemäss Schäffer et al. (2012, S. 52), dient dazu den Kunden auf die zentralen Inhalte aufmerksam zu machen. Deshalb ist es relevant ein standardisiertes und einfaches Layout aufzuerlegen und die Inhalte nicht nur verbal, sondern auch in geeigneten Tabellen oder Graphiken zu visualisieren.  
Abschliessend sind auch die Datenmodelle und Systeme durch die Reporting Factory zu optimieren. Sämtliche Datenquellen werden zusammengezogen und ein neues Datenmanagement etabliert. Gemäss Kirchberg & Palenta (2012, S. 52-57) senkt eine Reduktion von unterschiedlichen Tools und Quellen nicht nur die Komplexität der Dateninformationen, sondern auch die Kosten. Letzten Endes steht das Ziel von effizienten Prozessen an oberster Stelle. Um dieses Ziel zu erreichen ist es wichtig klare Richtlinien und Vorgaben zu errichten, Verantwortlichkeiten zu zuteilen und Redundanzen zu verringern (Schmitz, Lawrenz & Drerup, 2016, S. 441).
Abschliessend sind auch die Datenmodelle und Systeme durch die [[Reporting Factory]] zu optimieren. Sämtliche Datenquellen werden zusammengezogen und ein neues [[Datenmanagement]] etabliert. Gemäss Kirchberg & Palenta (2012, S. 52–57) senkt eine Reduktion von unterschiedlichen Tools und Quellen nicht nur die Komplexität der Dateninformationen, sondern auch die Kosten. Letzten Endes steht das Ziel von effizienten Prozessen an oberster Stelle. Um dieses Ziel zu erreichen ist es wichtig klare Richtlinien und Vorgaben zu errichten, Verantwortlichkeiten zu zuteilen und Redundanzen zu verringern (Schmitz et al., 2016, S. 441).


==Ansätze zur Einführung von Reporting Factory==
==Ansätze zur Einführung von Reporting Factory==
Es gibt zwei mögliche Ansätze, wie die Reporting Factory eingeführt werden kann. Diese sind zum einen der «Lift and Shift» Ansatz und zum anderen der «Design and Build» Ansatz. Um zu wissen, welcher Ansatz gewählt werden soll, muss die Zielsetzung sowie der individuelle Reifegrad der Reportingsysteme der Unternehmung bekannt sein. Sofern die Kostensenkung priorisiert wird, sollte der Lift and Shift Ansatz gewählt werden. Bei einer Priorisierung der inhaltlichen Optimierung wird empfohlen den Design and Build Ansatz zu verfolgen (Schmitz, Lawrenz, & Drerup, 2016, S. 443-444).
Es gibt zwei mögliche Ansätze, wie die [[Reporting Factory]] eingeführt werden kann. Diese sind zum einen der «Lift and Shift» Ansatz und zum anderen der «Design and Build» Ansatz. Um zu wissen, welcher Ansatz gewählt werden soll, muss die Zielsetzung sowie der individuelle Reifegrad der Reportingsysteme der Unternehmung bekannt sein. Sofern bei der Zielsetzung die Kostensenkung priorisiert wird, sollte der [[Ausgestaltung und Einführung einer Reporting Factory#Lift and Shift|Lift and Shift Ansatz]] gewählt werden. Bei einer Priorisierung der inhaltlichen Optimierung wird empfohlen den Design and Build Ansatz zu verfolgen (Schmitz et al., 2016, S. 443–444).
 
'''''PLATZHALTER ABBILDUNG'''''


===Lift and Shift===
===Lift and Shift===
Als erstes stellt sich die Frage, ob eine Überarbeitung des Reporting notwendig ist. Falls nicht, wird der bewährte Ist-Zustand in die Reporting Factory transferiert und nach dem sogenannten «Lift and Shift Ansatz» zentral zur Verfügung gestellt. Das bedeutet, dass die Reporting Inhalte grösstenteils unangetastet bleiben (Schmitz, Lawrenz, & Drerup, 2016, S. 439). Danach erfolgt die ständige Optimierung im laufenden Betrieb nach den Leitlinien. Diese besagen gemäss Schmitz, Lawrenz, & Drerup (2016), dass ungenutzte und überflüssige Daten eliminiert werden sollen, Fokus muss auf steuerungsrelevanten Inhalten bestehen und mittels dem KVP weitestgehend optimiert werden (S. 430-440).
[[Datei:VorteileLiftShift.png|thumb|right|Abb. 4: Vorteile des [[Ausgestaltung und Einführung einer Reporting Factory#Lift and Shift|Lift and Shift Ansatzes]] (Schmitz et al., 2016, S. 440)]]
In der Abbildung 2 sind die Vorteile des Lift and Shift Ansatz zu entnehmen. Die Hauptvorteile liegen im schnellen Aufbau einer Reporting Factory sowie der Hoheit über das Reporting. Ein Nachteil ergibt sich während dem laufenden Betrieb. Das Alltagsgeschäft in der Reporting Factory mindert die Effizienz bei der Optimierung, wodurch das Endergebnis der verbesserten Reporting hinausgezögert wird (Schmitz, Lawrenz, & Drerup, 2016, S. 440-441).
Als erstes stellt sich die Frage, ob eine Überarbeitung des Reporting notwendig ist. Falls nicht, wird der bewährte Ist-Zustand in die [[Reporting Factory]] transferiert und nach dem sogenannten [[Ausgestaltung und Einführung einer Reporting Factory#«Lift and Shift|Lift and Shift Ansatz»]] zentral zur Verfügung gestellt. Das bedeutet, dass die Reporting Inhalte grösstenteils unangetastet bleiben (Schmitz et al., 2016, S. 439). Danach erfolgt die ständige Optimierung im laufenden Betrieb nach den Leitlinien. Diese besagen gemäss Schmitz et al. (2016), dass ungenutzte und überflüssige Daten eliminiert werden sollen, Fokus muss auf steuerungsrelevanten Inhalten bestehen und mittels dem KVP weitestgehend optimiert werden (S. 430–440).
In der Abbildung 4 sind die Vorteile des [[Ausgestaltung und Einführung einer Reporting Factory#Lift and Shift|Lift and Shift Ansatz]] zu entnehmen. Die Hauptvorteile liegen im schnellen Aufbau einer [[Reporting Factory]] sowie der Hoheit über das Reporting. Ein Nachteil ergibt sich während dem laufenden Betrieb. Das Alltagsgeschäft in der [[Reporting Factory]] mindert die Effizienz bei der Optimierung, wodurch das Endergebnis der verbesserten Reporting hinausgezögert wird (Schmitz et al., 2016, S. 440–441).
===Design and Build===
===Design and Build===
Bei dem Design and Build Ansatz werden die Inhalte und Systeme erst optimiert und standardisiert und danach in die Factory überführt. Somit kann die Reporting Factory die volle Effizienz ausschöpfen, bevor das Alltagsgeschäft aufgenommen wird. Dieser optimale Reporting-Ansatz kann etabliert werden, ohne die Berücksichtigung auf den Transfer oder Aufbau der Factory (Schmitz, Lawrenz, & Drerup, 2016, S. 443). Da nicht auf bereits vorhandene Lösungen zurückgegriffen werden kann, benötigt der Prozess Zeit, bis die ersten Erfolge sichtbar werden.
Bei dem Design and Build Ansatz werden die Inhalte und Systeme erst optimiert und standardisiert und danach in die Factory überführt. Somit kann die [[Reporting Factory]] die volle Effizienz ausschöpfen, bevor das Alltagsgeschäft aufgenommen wird. Dieser optimale Reporting-Ansatz kann etabliert werden, ohne die Berücksichtigung auf den Transfer oder Aufbau der Factory (Schmitz et al., 2016, S. 443). Da nicht auf bereits vorhandene Lösungen zurückgegriffen werden kann, benötigt der Prozess Zeit, bis die ersten Erfolge sichtbar werden.


==Aufbau der Reporting Factory==
==Aufbau der Reporting Factory==
Der Aufbau einer Reporting Factory basiert auf dem Projektplan, welcher die Meilensteine und den zeitlichen Rahmen festlegt. Zur Realisierung der Reporting Factory sollten eineinhalb bis zwei Jahre geplant werden, wobei Schmitz, Lawrenz, & Drerup (2016) empfehlen die folgenden Schritte in der entsprechenden Reihenfolge zu beachten (S. 443-452):
Der Aufbau einer [[Reporting Factory]] basiert auf dem Projektplan, welcher die Meilensteine und den zeitlichen Rahmen festlegt. Zur Realisierung der [[Reporting Factory]] sollten eineinhalb bis zwei Jahre geplant werden, wobei Schmitz et al. (2016) empfehlen die folgenden Schritte in der entsprechenden Reihenfolge zu beachten (S. 443–452):


===1. Ist-Analyse als Fundament===
===1. Ist-Analyse als Fundament===
Die Ist-Analyse gilt als Basis zur Bestimmung des Tätigkeitsschwerpunktes der Reporting Factory. Um die Ist-Analyse effizient zu gestalten, lohnt es sich in einem ersten Schritt, Fragebögen von den einzelnen Einheiten, bzw. Ansprechpartner der Einheit (bspw. Leiter Konzerncontrolling) ausfüllen zu lassen. In einem zweiten Schritt sollten diese ausgewertet werden und mittels Interviews Unklarheiten klären. Dies dient zur Ermittlung des Arbeitsaufwands und Verbesserungspotenzialen. Schlussendlich sollte sich ein klares Bild ergeben, welche Themen die Reporting Factory angehen muss (Schmitz, Lawrenz, & Drerup, 2016, S. 444-445).
Die Ist-Analyse gilt als Basis zur Bestimmung des Tätigkeitsschwerpunktes der [[Reporting Factory]]. Um die Ist-Analyse effizient zu gestalten, lohnt es sich in einem ersten Schritt, Fragebögen von den einzelnen Einheiten, bzw. Ansprechpartner der Einheit (bspw. Leiter Konzerncontrolling) ausfüllen zu lassen. In einem zweiten Schritt sollten diese ausgewertet werden und mittels Interviews Unklarheiten klären. Dies dient zur Ermittlung des Arbeitsaufwands und Verbesserungspotenzialen. Schlussendlich sollte sich ein klares Bild ergeben, welche Themen die [[Reporting Factory]] angehen muss (Schmitz et al., 2016, S. 444–445).
===2. Definition des Target Operating Models===
===2. Definition des Target Operating Models===
'''''PLATZHALTER ABBILDUNG'''''
[[Datei:ElementeTOM.png|thumb|right|Abb. 5: Elemente des Target Operating Models (Schmitz et al., 2016, S. 446)]]
Das Target Operating Model (TOM) bildet die Basis für einen strukturierten Aufbau der Reporting Factory. Sie beinhaltet die Elemente gemäss der Abbildung rechts. Die Bestimmung der Produkte und Services ergeben sich aus dem Tätigkeitsschwerpunkt. Als Kunden der Reporting Factory können Controller agieren oder das Top-Management des Unternehmens oder diverse andere Leiter von Organisationseinheiten. Die Entscheidung der Systeme sollte einheitlich und für alle Betroffenen zugänglich sein. Die Organisationsstruktur sowie die Governancestrukturen gilt es festzulegen. Dabei müssen Entscheidungsinstanzen bestimmt werden, welche bei kritischen Situationen und wichtigen Entscheidungen anzufragen sind (Rahtjen, 2008, S. 37). Die Kriterien für solche Anfragen sollten ebenfalls festgehalten werden. Zuletzt gilt es die Abgrenzungen und Zusammenarbeit der Einheiten festzulegen, wie beispielsweise die Reporting Factory in die Finanzorganisation eingebettet ist und wie damit zusammengearbeitet wird und welche Einheit an welche Einheit liefert, beziehungsweise von dieser bedient wird.
Das Target Operating Model (TOM) bildet die Basis für einen strukturierten Aufbau der [[Reporting Factory]]. Sie beinhaltet die Elemente gemäss der Abbildung 5. Die Bestimmung der Produkte und Services ergeben sich aus dem Tätigkeitsschwerpunkt. Als Kunden der [[Reporting Factory]] können Controller agieren oder das Top-Management des Unternehmens oder diverse andere Leiter von Organisationseinheiten. Die Entscheidung der Systeme sollte einheitlich und für alle Betroffenen zugänglich sein. Die Organisationsstruktur sowie die Governancestrukturen gilt es festzulegen. Dabei müssen Entscheidungsinstanzen bestimmt werden, welche bei kritischen Situationen und wichtigen Entscheidungen anzufragen sind (Rahtjen, 2008, S. 37). Die Kriterien für solche Anfragen sollten ebenfalls festgehalten werden. Zuletzt gilt es die Abgrenzungen und die Zusammenarbeit der Einheiten festzulegen, beispielsweise wie die [[Reporting Factory]] in die Finanzorganisation eingebettet ist.
 
===3. Ein belastbarer Business Case===
===3. Ein belastbarer Business Case===
Ein Business Case sollte zur Wirtschaftlichkeit der Gründung einer Reporting Factory erstellt werden. Bei einer Wirtschaftlichkeitsrechnung wird der Nutzen der Implementierung der Reporting Factory den Kosten gegenübergestellt (Vgl. Wirtschaftlichkeitsrechnung, LINK-WIKI):
Ein Business Case sollte zur Wirtschaftlichkeit der Einführung einer [[Reporting Factory]] erstellt werden. Bei einer [[Wirtschaftlichkeitsrechnung]] wird der Nutzen der Implementierung der [[Reporting Factory]] den Kosten gegenübergestellt (vgl. [[Wirtschaftlichkeitsrechnung]]). In der folgenden Tabelle werden mögliche Nutzen und Kosten der Reporting Factory aufgeführt.


{| class="wikitable"
{| class="wikitable"
! Nutzen !! Kosten
! Nutzen !! Kosten
|-
|-
| Optimierung innerhalb der Reporting Factory || Aufbaukosten
| Optimierung innerhalb der [[Reporting Factory]] || Aufbaukosten
|-
|-
| Reduzierung der Controller ausserhalb der Factory || Kosten zur Harmonisierung und Optimierung des Reporting
| Reduzierung der Controller ausserhalb der Factory || Kosten zur Harmonisierung und Optimierung des Reporting
Zeile 88: Zeile 89:


===4. Vorbereitung und Durchführung der Reporting Factory===
===4. Vorbereitung und Durchführung der Reporting Factory===
Bei der Umsetzung empfiehlt es sich einen Wellenansatz zu verfolgen, wobei eine Einheit nach der anderen in die Reporting Factory transferiert wird. Als Vorbereitung, wie auch bei der Umsetzung ist eine umfängliche Kommunikationsstrategie essenziell um einen reibungslosen Ablauf bei der Überführung der Systeme, Prozesse und Einarbeitung des Personals zu gewährleisten. Die Umsetzung erfolgt nach denen im TOM festgelegten Zielen.
Bei der Umsetzung empfiehlt es sich einen Wellenansatz zu verfolgen, wobei eine Einheit nach der anderen in die [[Reporting Factory]] transferiert wird. Bei Vorbereitung sowie bei der Umsetzung, ist eine umfängliche Kommunikationsstrategie essenziell um einen reibungslosen Ablauf bei der Überführung der Systeme, Prozesse und Einarbeitung des Personals zu gewährleisten. Die Umsetzung erfolgt gemäss den im TOM festgelegten Zielen.
 
===5. Realisierung von Effizienzpotenzialen und des Output-Layers===
===5. Realisierung von Effizienzpotenzialen und des Output-Layers===
Die prognostizierten Effizienzpotenziale (siehe Business Case) sollten stets überprüft und mittels dem kontinuierlichen Verbesserungsprozess (KVP) realisiert werden. Die Reporting-Anfragen werden nun direkt an die Reporting Factory gestellt. Dabei sollte ein benutzerfreundliches und effizientes Self-Service Reporting angeboten werden, wobei allfällige Analysen direkt vom Nutzer abgefragt werden können.
Die prognostizierten Effizienzpotenziale (siehe Business Case) sollten stets überprüft und mittels dem kontinuierlichen Verbesserungsprozess (KVP) realisiert werden. Die Reporting-Anfragen werden nun direkt an die [[Reporting Factory]] gestellt. Dabei sollte ein benutzerfreundliches und effizientes Self-Service Reporting angeboten werden, damit allfällige Analysen direkt vom Nutzer abgefragt werden können.


==Literaturverzeichnis==
==Literaturverzeichnis==
'''''HIER NOCH die ersten 4 korrekt machen!'''''
* Kirchberg, A. & Palenta, F. (2012). [https://doi.org/10.1365/s12176-012-0643-8 Industrialisierung im Controlling.] Controlling & Management, 56(3), S. 52–57.
* Kirchberg, A. & Palenta, F. (2012). „Industrialisierung im Controlling“. Controlling & Management, 56(3), 52–57. https://doi.org/10.1365/s12176-012-0643-8.
* Krüger, W. & Danner, M. (2004). [https://doi.org/10.1365/s12176-004-0439-6 Bündelung von Controllingfunktionen in Shared Service Centern.] Controlling & Management, 48(8), S. 110–18.
 
* Mellewigt, T. & Decker, C. (2006). [https://link.springer.com/chapter/10.1007/978-3-8349-9265-9_3 Messung des Organisationserfolgs.] In: A. Werder, H. Stöber & J. Grundei (Hrsg.), [https://link.springer.com/book/10.1007/978-3-8349-9265-9 Organisations-Controlling: Konzepte und Praxisbeispiele (S. 51–82).] Wiesbaden: Springer Gabler.
* Krüger, W. & Danner, M. (2004). „Bündelung von Controllingfunktionen in Shared Service Centern“. Controlling & Management, 48(8), 110–18. https://doi.org/10.1365/s12176-004-0439-6.
* Metric-x analytics. (2016). [https://metricx.com/blog/what-is-self-service-business-intelligence/ Report Factory vs Self-Service Business Intelligence.]
 
* Mellewigt, T. & Decker, C. (2006). Messung des Organisationserfolgs. In: A. Werder, H. Stöber & J. Grundei (Hrsg.), Organisations-Controlling: Konzepte und Praxisbeispiele (S. 51-82). Wiesbaden: Springer Gabler.
 
* Metric-x analytics. (2016). „Report Factory vs Self-Service Business Intelligence“. Abgerufen am 16. März 2021 von https://metricx.com/blog/what-is-self-service-business-intelligence/
 
* Rahtjen, P. (2008). [https://link.springer.com/chapter/10.1007/978-3-8349-9597-1_2 Transformation durch Shared Services: Im Spannungsfeld zwischen zentraler und de-zentraler Unternehmenssteuerung.] In: F. Keuper & F. Neumann (Hrsg.), [https://link.springer.com/book/10.1007/978-3-8349-9597-1 Finance Transformation: Strategien, Konzepte und Instrumente (S. 26–44).] Wiesbaden: Springer Gabler.
* Rahtjen, P. (2008). [https://link.springer.com/chapter/10.1007/978-3-8349-9597-1_2 Transformation durch Shared Services: Im Spannungsfeld zwischen zentraler und de-zentraler Unternehmenssteuerung.] In: F. Keuper & F. Neumann (Hrsg.), [https://link.springer.com/book/10.1007/978-3-8349-9597-1 Finance Transformation: Strategien, Konzepte und Instrumente (S. 26–44).] Wiesbaden: Springer Gabler.
* Schäffer, U., Weber, J. & Mahlendorf, M. (2012). Controlling in Zahlen. Vallendar: Institut für Management und Controlling.
* Schäffer, U., Weber, J. & Mahlendorf, M. (2012). Controlling in Zahlen. Vallendar: Institut für Management und Controlling.

Aktuelle Version vom 3. Oktober 2022, 09:02 Uhr

Geprüft: Positiv beurteilt

Die Ziele der Reporting Factory können lediglich mit einer durchdachten Ausgestaltung und einer effizienten sowie reibungslosen Einführung erreicht werden. Aus diesem Grund sind die Arbeiten zur Ausgestaltung der Bausteine sowie der Ansätze zur Einführung der Reporting Factory ein zentraler und wichtiger Schritt. Die abschliessende Einführungsphase, mit fünf aufeinanderfolgenden Schritten, sollte auch gebührend Aufmerksamkeit erhalten.

Bausteine einer Reporting Factory

Abb. 1: Grundlegender Aufbau einer Reporting Factory (Schmitz et al., 2016, S. 433)

Um die Reporting Factory exakt den Bedürfnissen einer Unternehmung entsprechend aufzubauen, werden Informationen über den Umfang und den Tätigkeitsbereich benötigt (Krüger & Danner, 2004, S. 218). Untenstehend wird der grundlegende Aufbau einer Reporting Factory mit den Entscheidungskriterien aufgelistet und erläutert. Als grafische Veranschaulichung finden Sie die unterschiedlichen Bausteine ebenfalls in der Abbildung 1.  

Produkte und Services / Dienstleistungen

Im folgenden Baustein stellt sich die zentrale Frage, welche Reports erstellt werden sollten. Dazu gibt es zwei unterschiedliche Herangehensweisen, welche in der folgenden Tabelle erläutert werden.

Managementreports
Liegt der Fokus auf der Erstellung von Managementreports, beschäftigt sich die Reporting Factory mehrheitlich mit dem Verdichten von Informationen oder der Erstellung von Output-Formaten wie Präsentationen oder Berichte.

Anfangs validiert, analysiert und kommentiert die Factory die generierten Daten inhaltlich. Durch die Lernfähigkeit der Reporting Factory wird Know-how im Geschäftsbereich angeeignet, welche in anderen Aufgaben aufgegriffen werden kann (Schmitz et al., 2016, S. 433). Langfristig kann die Reporting Factory auch im Bereich Planung und Prognosen eine unterstützende Funktion wahrnehmen.

Massenreports
Besteht die Hauptaufgabe in der Generierung von Massenreports, definieren sich die Tätigkeiten der Reporting Factory tendenziell eher im operativen Bereich. Die Informationsbereitstellung soll weitestgehend automatisiert von Systemen generiert werden. Die aufzusetzenden Systemaktivitäten sind beispielsweise ein automatisiertes Datenmanagement, die Datenverknüpfung zwischen den verfügbaren Daten und die weitestgehend Standardisierung und Automatisierung von Datawarehouse und ERP Systemumgebungen (Schmitz et al., 2016, S. 434). Langfristig kann die Reporting Factory auch in ein Self-Service Business Intelligence gewandelt werden (metric-x, 2016, online).

Kunden

In direktem Zusammenhang mit den Produkten und Services / Dienstleistungen steht die Frage nach dem Kundenkreis. Die Produkte definieren nicht abschliessend welchen Kundenkreis die Reporting Factory bedient. Vielmehr ist die zu bedienende Hierarchieebene von Relevanz (Schmitz et al., 2016, S. 434).

Managementreports
Der Kundenkreis der Managementreports reichen vom Vorstand bis zu leitenden Funktionen (Schmitz et al., 2016, S. 434).
Massenreports
Der Kundenkreis der Massenreport ist wesentlich grösser. Detaillierte Berichte gehen zuhanden von operativen Manager und Werksleiter, die einen ausgewählten Standardberichten wünschen. Weiter werden auch darunterliegende Ebenen mit Berichten versorgt. Diese weisen jedoch einen deutlich höheren Detailgrad auf (Schmitz et al., 2016, S. 434).

Entfernt von der Frage nach der zu bedienenden Hierarchieebene bedarf auch die Anfangsphase gebührend an Aufmerksamkeit (Schmitz et al., 2016, S. 434). Speziell in der Aufbauphase einer neuen Organisationseinheit ist die Produktivität der Mitarbeitenden noch nicht auf der vollen Leistungskapazität. Aus diesem Grund kann es Sinn machen, nur einen Teil der Unternehmung mit den Dienstleistungen und den Produkten der Reporting Factory zu bedienen.

Organisation

Das Generieren einer neuen Organisationseinheit bedingt auch zwingend das Erstellen eines Organigramms. Zuerst muss ein Leiter der Reporting Factory erkoren werden, welcher die Führungsaufgaben der neuen Organisationseinheit übernimmt. Anschliessend muss geklärt werden, nach welchen Kriterien sich die Organisationseinheit ausrichten soll. Im Konkreten gibt es vier unterschiedliche Ausrichtungskriterien: Kunden, Produkte und Services, interne Prozesse, regionale Aufstellung (Mellewigt & Decker, 2006, S. 72 ff.). Nachstehend sind zwei Ausrichtungskriterien exemplarisch dargestellt. In Abbildung 2 wird die Reporting Factory nach Kunden gegliedert, während in Abbildung 3 eine Struktur nach internen Prozessen durchgesetzt wird.

Abb. 2: Organisationsstruktur nach Kunden (Schmitz et al., 2016, S. 437)
Abb. 3: Organisationsstruktur nach internen Prozessen (Schmitz et al., 2016, S. 437)

Datenmanagement, Datenmodel & Systemarchitektur

Nach Rahtjen (2008, S. 37) ist eine Reporting Factory primär für die Bereitstellung von Reports zuständig. Weiter ist diese Einheit aber auch im Bereich der Optimierung der Reports und der Aufwandreduktion bei deren Erstellung federführend. Dazu hat die Reporting Factory die Befugnis bestehende Reportingprozesse zu standardisieren und automatisieren. Eine Analyse der bestehenden Reporting-Inhalte ist speziell beim Aufbau einer Reporting Factory wichtig. Zentral ist die Überlegung, ob eine Überarbeitung des Reporting in Bezug auf die künftige Entscheidungsfindung zielführend ist oder nicht. Falls sich die Unternehmung entscheidet die Reports wie bis anhin zu belassen, werden die bestehenden Prozesse und Datengrundlagen mit einem Lift and Shift Ansatz übernommen (Schmitz et al., 2016, S. 439). Neben der Analyse der Reporting-Inhalte ist auch die richtige Darstellung wichtig. Eine klare Struktur, gemäss Schäffer et al. (2012, S. 52), dient dazu den Kunden auf die zentralen Inhalte aufmerksam zu machen. Deshalb ist es relevant ein standardisiertes und einfaches Layout aufzuerlegen und die Inhalte nicht nur verbal, sondern auch in geeigneten Tabellen oder Graphiken zu visualisieren. Abschliessend sind auch die Datenmodelle und Systeme durch die Reporting Factory zu optimieren. Sämtliche Datenquellen werden zusammengezogen und ein neues Datenmanagement etabliert. Gemäss Kirchberg & Palenta (2012, S. 52–57) senkt eine Reduktion von unterschiedlichen Tools und Quellen nicht nur die Komplexität der Dateninformationen, sondern auch die Kosten. Letzten Endes steht das Ziel von effizienten Prozessen an oberster Stelle. Um dieses Ziel zu erreichen ist es wichtig klare Richtlinien und Vorgaben zu errichten, Verantwortlichkeiten zu zuteilen und Redundanzen zu verringern (Schmitz et al., 2016, S. 441).

Ansätze zur Einführung von Reporting Factory

Es gibt zwei mögliche Ansätze, wie die Reporting Factory eingeführt werden kann. Diese sind zum einen der «Lift and Shift» Ansatz und zum anderen der «Design and Build» Ansatz. Um zu wissen, welcher Ansatz gewählt werden soll, muss die Zielsetzung sowie der individuelle Reifegrad der Reportingsysteme der Unternehmung bekannt sein. Sofern bei der Zielsetzung die Kostensenkung priorisiert wird, sollte der Lift and Shift Ansatz gewählt werden. Bei einer Priorisierung der inhaltlichen Optimierung wird empfohlen den Design and Build Ansatz zu verfolgen (Schmitz et al., 2016, S. 443–444).

Lift and Shift

Abb. 4: Vorteile des Lift and Shift Ansatzes (Schmitz et al., 2016, S. 440)

Als erstes stellt sich die Frage, ob eine Überarbeitung des Reporting notwendig ist. Falls nicht, wird der bewährte Ist-Zustand in die Reporting Factory transferiert und nach dem sogenannten Lift and Shift Ansatz» zentral zur Verfügung gestellt. Das bedeutet, dass die Reporting Inhalte grösstenteils unangetastet bleiben (Schmitz et al., 2016, S. 439). Danach erfolgt die ständige Optimierung im laufenden Betrieb nach den Leitlinien. Diese besagen gemäss Schmitz et al. (2016), dass ungenutzte und überflüssige Daten eliminiert werden sollen, Fokus muss auf steuerungsrelevanten Inhalten bestehen und mittels dem KVP weitestgehend optimiert werden (S. 430–440). In der Abbildung 4 sind die Vorteile des Lift and Shift Ansatz zu entnehmen. Die Hauptvorteile liegen im schnellen Aufbau einer Reporting Factory sowie der Hoheit über das Reporting. Ein Nachteil ergibt sich während dem laufenden Betrieb. Das Alltagsgeschäft in der Reporting Factory mindert die Effizienz bei der Optimierung, wodurch das Endergebnis der verbesserten Reporting hinausgezögert wird (Schmitz et al., 2016, S. 440–441).

Design and Build

Bei dem Design and Build Ansatz werden die Inhalte und Systeme erst optimiert und standardisiert und danach in die Factory überführt. Somit kann die Reporting Factory die volle Effizienz ausschöpfen, bevor das Alltagsgeschäft aufgenommen wird. Dieser optimale Reporting-Ansatz kann etabliert werden, ohne die Berücksichtigung auf den Transfer oder Aufbau der Factory (Schmitz et al., 2016, S. 443). Da nicht auf bereits vorhandene Lösungen zurückgegriffen werden kann, benötigt der Prozess Zeit, bis die ersten Erfolge sichtbar werden.

Aufbau der Reporting Factory

Der Aufbau einer Reporting Factory basiert auf dem Projektplan, welcher die Meilensteine und den zeitlichen Rahmen festlegt. Zur Realisierung der Reporting Factory sollten eineinhalb bis zwei Jahre geplant werden, wobei Schmitz et al. (2016) empfehlen die folgenden Schritte in der entsprechenden Reihenfolge zu beachten (S. 443–452):

1. Ist-Analyse als Fundament

Die Ist-Analyse gilt als Basis zur Bestimmung des Tätigkeitsschwerpunktes der Reporting Factory. Um die Ist-Analyse effizient zu gestalten, lohnt es sich in einem ersten Schritt, Fragebögen von den einzelnen Einheiten, bzw. Ansprechpartner der Einheit (bspw. Leiter Konzerncontrolling) ausfüllen zu lassen. In einem zweiten Schritt sollten diese ausgewertet werden und mittels Interviews Unklarheiten klären. Dies dient zur Ermittlung des Arbeitsaufwands und Verbesserungspotenzialen. Schlussendlich sollte sich ein klares Bild ergeben, welche Themen die Reporting Factory angehen muss (Schmitz et al., 2016, S. 444–445).

2. Definition des Target Operating Models

Abb. 5: Elemente des Target Operating Models (Schmitz et al., 2016, S. 446)

Das Target Operating Model (TOM) bildet die Basis für einen strukturierten Aufbau der Reporting Factory. Sie beinhaltet die Elemente gemäss der Abbildung 5. Die Bestimmung der Produkte und Services ergeben sich aus dem Tätigkeitsschwerpunkt. Als Kunden der Reporting Factory können Controller agieren oder das Top-Management des Unternehmens oder diverse andere Leiter von Organisationseinheiten. Die Entscheidung der Systeme sollte einheitlich und für alle Betroffenen zugänglich sein. Die Organisationsstruktur sowie die Governancestrukturen gilt es festzulegen. Dabei müssen Entscheidungsinstanzen bestimmt werden, welche bei kritischen Situationen und wichtigen Entscheidungen anzufragen sind (Rahtjen, 2008, S. 37). Die Kriterien für solche Anfragen sollten ebenfalls festgehalten werden. Zuletzt gilt es die Abgrenzungen und die Zusammenarbeit der Einheiten festzulegen, beispielsweise wie die Reporting Factory in die Finanzorganisation eingebettet ist.

3. Ein belastbarer Business Case

Ein Business Case sollte zur Wirtschaftlichkeit der Einführung einer Reporting Factory erstellt werden. Bei einer Wirtschaftlichkeitsrechnung wird der Nutzen der Implementierung der Reporting Factory den Kosten gegenübergestellt (vgl. Wirtschaftlichkeitsrechnung). In der folgenden Tabelle werden mögliche Nutzen und Kosten der Reporting Factory aufgeführt.

Nutzen Kosten
Optimierung innerhalb der Reporting Factory Aufbaukosten
Reduzierung der Controller ausserhalb der Factory Kosten zur Harmonisierung und Optimierung des Reporting
Senkung von Systemkosten Systemstandardisierungs- und Optimierungskosten
Reduktion von Projektkosten Kommunikations- und Stabilisierungskosten
Hebung von Arbeitsarbitrage

4. Vorbereitung und Durchführung der Reporting Factory

Bei der Umsetzung empfiehlt es sich einen Wellenansatz zu verfolgen, wobei eine Einheit nach der anderen in die Reporting Factory transferiert wird. Bei Vorbereitung sowie bei der Umsetzung, ist eine umfängliche Kommunikationsstrategie essenziell um einen reibungslosen Ablauf bei der Überführung der Systeme, Prozesse und Einarbeitung des Personals zu gewährleisten. Die Umsetzung erfolgt gemäss den im TOM festgelegten Zielen.

5. Realisierung von Effizienzpotenzialen und des Output-Layers

Die prognostizierten Effizienzpotenziale (siehe Business Case) sollten stets überprüft und mittels dem kontinuierlichen Verbesserungsprozess (KVP) realisiert werden. Die Reporting-Anfragen werden nun direkt an die Reporting Factory gestellt. Dabei sollte ein benutzerfreundliches und effizientes Self-Service Reporting angeboten werden, damit allfällige Analysen direkt vom Nutzer abgefragt werden können.

Literaturverzeichnis

Autoren

Fischer Karin, Föhn Kimena, Franz Laura und Schelbert Silvan