Ausgestaltung und Einführung einer Reporting Factory - Versionsgeschichte

Viviane.trachsel am 3. Oktober 2022 um 08:02 Uhr

2022-10-03T08:02:12Z

← Nächstältere Version		Version vom 3. Oktober 2022, 10:02 Uhr
Zeile 1:		Zeile 1:
			{{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.		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.

Salis.Matteo: /* 5. Realisierung von Effizienzpotenzialen und des Output-Layers */

2021-10-13T08:42:55Z

5. Realisierung von Effizienzpotenzialen und des Output-Layers

← Nächstältere Version		Version vom 13. Oktober 2021, 10:42 Uhr
Zeile 90:		Zeile 90:

	===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==

Salis.Matteo: /* 4. Vorbereitung und Durchführung der Reporting Factory */

2021-10-13T08:42:07Z

4. Vorbereitung und Durchführung der Reporting Factory

← Nächstältere Version		Version vom 13. Oktober 2021, 10:42 Uhr
Zeile 87:		Zeile 87:

	===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. 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 ~~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===

Salis.Matteo: /* 4. Vorbereitung und Durchführung der Reporting Factory */

2021-10-13T08:41:38Z

4. Vorbereitung und Durchführung der Reporting Factory

← Nächstältere Version		Version vom 13. Oktober 2021, 10:41 Uhr
Zeile 87:		Zeile 87:

	===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 nach denen 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, wobei allfällige Analysen direkt vom Nutzer abgefragt werden können.

Salis.Matteo: /* 3. Ein belastbarer Business Case */

2021-10-13T08:40:38Z

3. Ein belastbarer Business Case

← Nächstältere Version		Version vom 13. Oktober 2021, 10:40 Uhr
Zeile 70:		Zeile 70:

	===3. Ein belastbarer Business Case===		===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]]):		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"

Salis.Matteo: /* 3. Ein belastbarer Business Case */

2021-10-13T08:39:41Z

3. Ein belastbarer Business Case

← Nächstältere Version		Version vom 13. Oktober 2021, 10:39 Uhr
Zeile 70:		Zeile 70:

	===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]]):		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]]):

	{\| class="wikitable"		{\| class="wikitable"

Salis.Matteo: /* 2. Definition des Target Operating Models */

2021-10-13T08:38:57Z

2. Definition des Target Operating Models

← Nächstältere Version		Version vom 13. Oktober 2021, 10:38 Uhr
Zeile 67:		Zeile 67:
	===2. Definition des Target Operating Models===		===2. Definition des Target Operating Models===
	[[Datei:ElementeTOM.png\|thumb\|right\|Abb. 5: Elemente des Target Operating Models (Schmitz et al., 2016, S. 446)]]		[[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 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 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]]):		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]]):

Salis.Matteo: /* Ansätze zur Einführung von Reporting Factory */

2021-10-13T08:36:43Z

Ansätze zur Einführung von Reporting Factory

← Nächstältere Version		Version vom 13. Oktober 2021, 10:36 Uhr
Zeile 51:		Zeile 51:

	==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 [[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).		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).

	===Lift and Shift===		===Lift and Shift===

Salis.Matteo: /* Organisation */

2021-10-13T08:35:07Z

Organisation

@@ Zeile 42: / Zeile 42: @@
 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)]]
-[[Datei:OrganisationProzesse.png|thumb|right|Abb. 3: Organisationsstruktur nach internen Prozessen (Schmitz et al., 2016, S. 437)]]
+[[Datei:OrganisationProzesse.png|thumb|center|Abb. 3: Organisationsstruktur nach internen Prozessen (Schmitz et al., 2016, S. 437)]]
 ===Datenmanagement, Datenmodel & Systemarchitektur===

Salis.Matteo: /* Kunden */

2021-10-13T08:33:57Z

Kunden

← Nächstältere Version		Version vom 13. Oktober 2021, 10:33 Uhr
Zeile 30:		Zeile 30:
	\|-		\|-
	\| A1 \| Der Kundenkreis der Managementreports reichen vom Vorstand bis zu leitenden Funktionen (Schmitz et al., 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 (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
Zeile 37:		Zeile 36:
	\|-		\|-
	\|}		\|}

	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.		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.