In Folge 14 geht es um die Einführung von Management Reporting Systemen. Sie erfahren wie Sie in 7 Schritten ein solches System gemeinsam mit dem Fachbereich erfolgreich einführen können.
Podcast: Play in new window | Download (Duration: 20:26 — 17.3MB)
CIO Podcast abonnieren: Apple Podcasts | Google Podcasts | Spotify | Amazon Music | Android | RSS
Folgende Aspekte werden in der Podcast-Folge besprochen:
- Was ist ein Management Reporting System? [00:00:40]
- Aufbau von Management Reporting Systemen in 3 Schichten [00:03:00]
- 7 Schritte zur Einführung von Management Reporting Systemen [00:08:30]
- Vorteile des 7-schrittigen Vorgehens zur Einführung von Management Reportings [00:17:30]
Ich freue mich über Ihr Feedback.
In 7 Schritten ein Management Reporting System einführen
In dieser Folge geht es um die Einführung von Management Reporting Systemen, und Sie als team-manager sind auf der einen Seite Nutzer von Reporting Systemen, aber auf der anderen Seite stellen Sie mit ihrer IT-Organisation auch für die Fachbereiche entsprechende Systeme zur Steuerung und zur Entscheidungsunterstützung zur Verfügung und führen eben halt diese Projekte durch.
Zum Teil stellen Sie eben da auch die Projektleitung und in der heutigen Folge möchte ich darüber sprechen, wie Sie es schaffen erfolgreich Management Reporting Systeme gemeinsam mit ihren Fachbereichen einzuführen. Vielleicht ganz kurz vorneweg.
Was ist eigentlich ein Management Reporting System?
Es ist aus meiner Sicht ein Analyse System, das Daten aufbereitet für die Entscheidungsfindung in einem konkreten Kontext dienlich ist und die Daten in aggregierter und komprimierter Form auch darstellen kann. Also Management Reporting Systeme, wenn wir jetzt ganz klein anfangen, könnten Sie theoretisch auch mit kleinen Datenbanken und kleinen Web-Frontends schon erstellen.
Darüber wollen wir heute aber gerade nicht sprechen, also über diese kleinen, ich sage – in Anführungsstrichen – Bastellösung, sondern heute soll es darum gehen, wie Sie richtige Business Intelligence Systeme, Performance Management Systeme, OLAP Systeme dazu nutzen können, ich erkläre gleich noch mal, was die einzelnen Systeme heißen, um dieses Management Reporting eben abzubilden. #00:02:01-4#
Also häufig werden ja eben verschiedene Suiten oder Software Pakete angeboten, die unter diesem Kontext Business Intelligence, Corporate Performance Management, Enterprise Performance Management, laufen. Das ist in der Regel einfach ein Software-Paket, was schon gewisse Sachen mitbringt und diese drei Schichten beinhaltet, über die ich gleich noch mal im Einzelnen sprechen werde.
Das heißt, da haben Sie sozusagen schon ein Rundum-Paket, was Ihnen gewisse Funktionalitäten schon vorneweg liefert und ein sogenanntes OLAP System, das heißt Online Analytical Processing System, ist eben so aufgebaut, dass Sie in der Lage sind, online also im Live Zugriff schon Analysen zu fahren und diese auch zur Laufzeit auszuwerten. Also, jetzt habe ich das gerade schon angekündigt.
Aufbau von Management Reporting Systemen in 3 Schichten
Der Aufbau von solchem Management Reporting Systemen, Corporate Performance Management System oder wie auch immer Sie sie nennen möchten, aus diesen Suiten, besteht in der Regel aus 3 Schichten.
Architektur-Ebene 1: Online Transactional Processing (OLTP)-Schicht
Die 1. Schicht, die nennt sich häufig OLTP Schicht, OLTP steht dabei für Online Transaction Processing Schicht. #00:03:04-4#
Das heißt also, wo Sie Ihre transaktionalen Systeme und deren Daten eben halten, das heißt, Sie haben in der ersten Schicht ihre Quellsysteme so etwas wie das ERP-System, Ihr Warenwirtschaftssystem, Kundendatenbanken, CRM Systeme und so weiter, aus denen Sie Daten ziehen möchten für weitere Auswertungen. Das ist die 1. Schicht und da werden eben alle Daten angebunden über Konnektoren zur 2. Schicht hin.
Architektur-Ebene 2: Data Warehouse (DW)-Schicht
Die 2. Schicht, die startet eigentlich mit einer Transformation, also mit der Extraktion der Daten und der Transformation um bestimmte fachliche und logische Zusammenhänge und lädt diese Daten dann in die 2. Schicht rein und führt da vor allem als Erstes in das Data Warehouse. Das Data Warehouse ist sozusagen ein Sammelbecken für alle verschiedenen Unternehmensdaten und die sind eben zu dieser Zeit auch schon harmonisiert. Das ist ganz wichtig. Die liegen also schon so vor, dass man auf dieser Basis die Daten auch schon mal vergleichen kann. #00:04:03-5#
Diese Arbeit muss man eben vorher machen. Das ist diese Transformation, wenn man die Daten dann in diese Data Warehouse Schicht lädt und auf dieser Basis auf diesem Data Warehouse basierend werden dann weitere Auswertungsschritte gemacht.
Also das heißt, ich kann aus dem großen Ganzen des Data Warehouse kleinere Teilbereiche raus ziehen und nochmal weiter analysieren und diese kleinen Teilbereiche die nennt man Data Marts. Das sind also einzelne kleine Würfel, wo ich bestimmte Datenausschnitte nochmal aufbereiten und analysieren kann und die eben vielleicht auch für bestimmte Fachbereiche aufsetzen kann.
Das heißt, ich könnte mir vorstellen, ich habe zum Beispiel ein Data Warehouse gesamt mit allen Unternehmensdaten. Dann habe ich bestimmte Data Marts, zum Beispiel ein Data Mart fürs Finanz Reporting, ein Data Mart fürs Vertriebs Reporting, ein Data Mart fürs IT-Reporting. Das wäre jetzt mal eine ganz kleine Anwendung. In den meisten Fällen hat man sogar mehrere Data Marts für ein Finanz Reporting. Allein schon mit Würfeln über Ist-Daten oder über Plandaten und so weiter. #00:05:02-8#
Das kann man sich verschieden aufbauen und fachlich konzeptionieren. Aber das ist ein anderes Thema. Es geht ja heute erst mal um den Überblick und vom Überblick her, wenn man diese Data Marts hat, dann hat man eben diesen Datenausschnitt schon für die einzelnen fachlichen Anwendungsfälle.
Architektur-Ebene 3: Business Intelligence (BI)-Schicht
Und dann geht’s auch schon zur 3. Schicht, weil aus den Data Marts werden dann die Daten generiert oder Daten auch herausgeholt. Für die 3. Schicht, die sich BI-Schicht nennt und an der Stelle habe ich über diese Schnittstellen die Möglichkeit die Daten in den Dashboards, Cockpits und wie auch immer man sie nennen möchte, grafisch aufzubereiten und die Daten eben dort auch anzuzeigen für den Nutzer.
Also an der Stelle habe ich das erste Mal wirkliche Nutzerinteraktionen, alles davor ist eigentlich – in Anführungsstrichen – die Spielwiese der IT und das sieht ja auch der Benutzer nicht. Und aus meiner Sicht ist da an der Stelle auch eben häufig die Krux, weil die meisten Anwender, die kennen, wenn überhaupt die Business Intelligence Systeme nur von der 3. Schicht. #00:06:03-9#
Also die kennen vielleicht noch die BI-Schicht und wenn Sie Glück haben und die schon mal Ad Hoc Berichte, also selber gebaute Berichte auch benutzen, dann kennen sie vielleicht noch Teile der semantischen Struktur, also dieser logischen Datenstruktur der Data Marts. Also wissen sie, welche Dimensionen hat so ein Datenwürfel und so weiter und können da drin navigieren. Aber dann hört es auch schon auf und Sie merken schon, die meisten User, die kennen das nicht. Also der Standard-Nutzer dieser Standard Reports, der kennt das in der Regel nicht.
So, was bedeutet das, wenn Sie jetzt als IT oder aus der IT-Organisation heraus derartige Projekte auch mit begleiten oder vielleicht sogar auch als Projektleiter begleiten? Der Anwender hat ein fachliches Problem vor Augen, was er gelöst haben möchte und möchte, dass die IT ihm hilft dieses Problem zu lösen, damit er später seine Daten hat, um eben bessere Entscheidungen treffen zu können. Und der sieht aber technologisch immer nur die Spitze des Eisbergs, das heißt, der sieht ja, wenn überhaupt oben an der Stelle nur, was die Berichte ihm bieten und er weiß gar nicht, was da alles drunter ist. #00:07:06-2#
Also diese anderen Schichten kennt er nicht und deswegen kann man so schön sagen, das ist für den User auch wie eine Blackbox so ein System. Der gibt irgendwo an der einen Stelle Daten rein, damit passiert irgendetwas, das weiß der auch und dann sieht er irgendwann die Anzeige und sagt, super, wunderbar, kann ich mit arbeiten.
Hat aber eben genau den Punkt, dass dadurch, dass die Benutzer häufig nicht wissen, was mit den Daten passiert und sie auch diesen Entstehungsprozess gar nicht begleiten, sind sie dann später beim Testen irgendwie völlig überfragt und sagen: ja wie soll ich das denn jetzt testen? Da kommen irgendwie Daten aus dem Vorsystem, aus meinem ERP-System, ja und jetzt sind die irgendwie anders und die werden jetzt angezeigt. Aber wie soll ich das denn testen? Wie soll ich das denn validieren und wie soll ich denn jetzt sagen, ob das alles funktioniert?
Das sind häufig so die Fragestellungen, die auftauchen am Ende solcher Management Reporting Projekte und deswegen habe ich 7 Schritte für Sie, auf die Sie achten können, damit Sie eben genau das am Ende nicht haben, sondern damit sie am Ende Nutzer haben, die Ihre Systeme auch benutzen und Management Entscheider, die eben auch mit diesen Daten etwas anfangen können. #00:08:11-2#
Und ja die richtigen Daten eben auch zur richtigen Zeit am richtigen Ort sind, also die sogenannte Informations-Logistik dann auch stimmt.
7 Schritte zur Einführung von Management Reporting Systemen
Und ja da kommen wir mal zu den 7 Punkten, ich nenne sie erst mal ganz schnell vorne weg und dann gehen wir auf die einzelnen Sachen nochmal genauer ein.
- Der erste Punkt ist, dass Sie eine klare Zielsetzung haben.
- Der 2. Punkt ist, dass Sie die Analyse Dimensionen klären.
- Der 3. Punkt ist, dass Sie die Kennzahlen klären, die angezeigt werden sollen.
- Der 4. Punkt ist, dass Sie sogenannte Use-Cases und Analyse-Pfade entwickeln für die Standardberichte.
- Der 5. Punkt ist, dass Sie überlegen, was die Ad Hoc Szenarien sind.
- Der 6. Punkt ist erst dann zu schauen, welches System passt und ob Sie vielleicht schon eins im Hause haben oder das vielleicht doch anschaffen müssten.
- Und der 7. Punkt ist dann die Anforderungen iterativ zu implementieren und da werde ich dann gleich nochmal ganz genau darauf eingehen, wie sowas denn aussehen könnte. #00:09:11-4#
Okay also im Schnelldurchlauf haben Sie die 7 Schritte schon gehört.
Schritt 1: Zielsetzung festlegen
Punkt 1, die Zielsetzung. Für welchen Zweck wird eigentlich das System benutzt und benötigt und welche Entscheidungen möchte der Anwender und der Nutzer, also derjenige aus dem Fachbereich auf der anderen Seite mithilfe dieses Systems treffen? Und das ist ein ganz wichtiger Punkt für Sie, weil, wenn Sie die Zielsetzung verstehen, dann können Sie auch überlegen, welche Daten vielleicht und welche Datentöpfe relevant sein könnten.
Ich habe das auch schon häufig erlebt, dass irgendwie dann in der IT so gesagt wird: ja, da muss mal einer die und die Daten auswerten. So. Und dann werden die irgendwie zusammengestellt und dann sind die Leute glücklich. Nur eben der Fachbereich nicht, weil der sagt: ja, hmm, ich wollte eigentlich was ganz anders mit den Daten machen. Das heißt, es ist ganz wichtig, dass auch die IT eben die Zielsetzung des Fachbereichs versteht und sagt: okay, was möchtet ihr denn eigentlich damit auswerten? #00:10:04-1#
Es geht ja nicht nur darum, dass wir die Zahlen zusammentragen, sondern was ist eigentlich das, was ihr dahinter analysieren wollt? Ich nehme mal ein Beispiel. Wenn Sie jetzt zum Beispiel in einen neuen Markt expandieren wollen, ist die fachliche Anforderung und Sie wollen jetzt wissen, ob das eine sinnvolle Entscheidung ist.
Dann könnten Sie ja sagen: okay, ich brauch mal meine Ist-Daten. Wieviel Umsatz habe ich heute in verschiedenen Märkten? Wieviel Produktionskapazitäten habe ich vielleicht noch, wenn ich ein produzierendes Unternehmen bin und an welcher Stelle habe ich irgendwo Engpässe? Und wie prognostiziert sich das in die Zukunft? So. Und wenn ich das habe, dann kann ich auch sagen, wie wahrscheinlich ist es jetzt, dass ich vielleicht mit bestehenden Produktionskapazitäten auskomme und noch genügend produzieren kann, dass ich auch noch mal einen neuen Vertriebsweg eröffne oder eben einen neuen Markt erschließe. Das mal ein Beispiel.
Oder andersrum, Sie haben vielleicht im Finanzwesen bestimmte Fragestellungen. Das kann sein, dass Sie zum einen nur die Ist-Daten berichten wollen. Es kann aber auch sein, dass Sie in die Zukunft gucken wollen, also das sogenannte Predictive Analytics machen wollen und das schon mal rausfinden möchten, wie wahrscheinlich das ist? #00:11:10-6#
Da brauchen Sie in allen Fällen eben auch diese gute Ist-Datenbasis für. Und vor allen Dingen sollten Sie, wenn Sie die Systeme entwickeln, verstehen, was eigentlich an Zielsetzung dahinter steckt. Wenn Sie jetzt ein reines Vertriebs Reporting zum Beispiel machen möchten, ja ein ganz einfaches Beispiel im Autohaus, Sie wollen jetzt, Sie sind großer Automobilhersteller und wollen jetzt wissen, wie die Autohäuser performen. Dann würden Sie sagen: okay, wieviel Autos habe ich verkauft? In was für Märkten also in was für Autohäusern? Welche Produktlinien und so weiter? Und das heißt, das würden Sie auswerten wollen und das ist die Zielsetzung.
Schritt 2: Analyse-Dimensionen klären
Da Kommen wir eigentlich auch mit dem Beispiel schon gleich zum 2. Punkt. Die Erarbeitung gemeinsam mit den Fachbereichen der Dimensionen für Ihre Management Reporting System Anwendung. Das eben auf Basis der Zielsetzung. Also ich habe das ja gerade schon mal angefangen mit dem Auto Beispiel. Ich mache da mal weiter. Zum Beispiel könnten mögliche Dimensionen sein. In welchen Märkten sind Sie aktiv, mit welchen Produkten? #00:12:05-7#
Die Produkte sind dann vielleicht noch einmal untergliedert mit einer Hierarchie in einzelne wirkliche Produkte, Produktgruppen und so weiter und geben Ihnen da noch einmal die Möglichkeit die einzelnen Fahrzeuglinien zu unterteilen oder vielleicht die Produkte, die Sie eben herstellen in Ihrem Unternehmen. Dann haben sie die Kunden. Auch da können Sie wieder natürlich gruppieren. Sie haben vielleicht Zeithorizonte. Also Sie wollen sagen, ich möchte jetzt Monatsscheiben angucken, möchte ich Jahresscheiben angucken, möchte ich das täglich berichten? Sie würden fragen wollen, ob das Plandaten sind, ob das Ist-Daten sind, was für Szenarien Sie vielleicht noch haben?
Alle diese Punkte könnten sie als Dimensionen eben erfassen und noch viele mehr. Meistens sind in den Systemen zwischen 10 und 20 Dimensionen ohne Schwierigkeit möglich. Bei mehr sollte man sich überlegen ob das noch sinnvoll ist und ob man das nicht noch irgendwo komprimieren kann, weil man ja auch, ich sage mal die Berichte und das alles noch handelbar halten sollte. #00:13:01-2#
Schritt 3: Kennzahlen definieren und festlegen
Da kommen wir eigentlich auch zum nächsten Punkt. Wenn Sie die Dimensionen soweit klar haben, dann geht es zum nächsten Schritt über zu den Kennzahlen und die Kennzahlen sind ganz essenziell, weil das sind ja nachher wieder die die einzelnen wirklichen Zahlen, die Sie anschauen wollen im Hinblick auf die Zielsetzung als Fachbereich und bei der Kennzahlenberechnung ist es wichtig, dass Sie gemeinsam verstehen, wie die Kennzahlen berechnet werden und sich zusammensetzen.
Und da ist eben aus der Erfahrung auch immer die absolute Expertise der IT gefragt, weil die Kennzahlen häufig in den verschiedenen Systemen komplett anders berechnet werden. Und das ist eben dann ein Schritt, der muss berücksichtigt werden, wenn es darum geht die Daten zu transformieren und in das Data Warehouse rein zu laden. Selbst, wenn Sie da gleiche Kennzahlen haben, die zwar gleich heißen, aber innen drin Äpfel und Birnen sind, dann vergleichen Sie am Ende eben auch Äpfel mit Birnen.
Und ich sage mal ein klassisches Beispiel ist die Zusammensetzung des Deckungsbeitrags oder sowas. Das wird häufig eben in einem System so definiert, im anderen System so definiert. #00:14:01-3#
Wenn Sie jetzt einfach den Deckungsbeitrag nehmen und den weitergeben, dann könnte es sein, dass Sie eben hinterher Abweichungen haben oder eben Äpfel mit Birnen vergleichen und damit das nicht passiert, sollten Sie gemeinsam eben schauen, was sind das für Kennzahlen? Was steckt dahinter? Und wie sind die in den Systemen abgebildet? Und können wir die einfach so übernehmen oder eben transformieren?
Schritt 4: Use-Cases und Analyse-Pfade entwickeln
Der 4. Schritt. Überlegen Sie gemeinsam Use Cases und Analyse-Pfade. Also welche Analyse-Wege geht denn der Nutzer und für diese Analyse-Wege oder Standard-Anfragen, die es eben gibt, definieren Sie dann Standard Reports. Und da ist auch wichtig, dass Sie die Standard Reports nicht überladen. Also der Klassiker, so ganz lange Tabellen, die dann meistens doch von den Leuten tatsächlich noch exportiert werden.
Aber das wollen Sie ja nicht. Sie wollen ja ein nutzbares System haben, was auch schon im System nutzbar ist und nicht erst durch Herunterladen einer Excel Datei und Überarbeitung. Das ist ja nicht Sinn und Zweck der Geschichte. Deswegen sollten Sie versuchen, nur diese Information eben in diesen Standard Reports anzuzeigen, die auch wirklich notwendig sind, eben für diesen einzelnen Use Case und sonst eben verschiedene Reports anzeigen als eben diese einzelnen Reports völlig zu überladen. #00:15:11-8#
Das kann ja auch keiner mehr verarbeiten. Oder eben diese wesentlichen Informationen da herausfiltern.
Schritt 5: Ad Hoc Szenarien durchdenken
Wir haben jetzt gerade Standard Reports abgebildet und der 5. Schritt ist, zu schauen, was sind denn Ad Hoc Szenarien, also wirklich tiefergreifende Analysen, die Sie noch machen müssten. Das ist dann häufig was für Key User, also User die dann ja noch einmal deutlich weiter in diese Reporting Welt eintauchen, die auch die Data Mart Strukturen besser kennen und die sind dann eben in der Lage auch entsprechende Ad Hoc Berichte auszuführen.
An der Stelle, wenn Sie danach überlegen, was für Ad Hoc Berichte dann zum Beispiel in Frage kämen, dann können Sie auch relativ gut testen, ob Sie alle wesentlichen Informationen, Dimensionen und Kennzahlen abgebildet haben oder ob da irgendwo noch etwas fehlt. #00:16:04-4#
Schritt 6: Systemauswahl von Management Reporting Systemen (Corporate Performance Management Suiten)
Und erst, wenn Sie diese fachlichen Anforderungen soweit aufgenommen und definiert haben, erst dann sollten Sie sich Gedanken machen über das passende System. Weil die Vorüberlegungen sind aus meiner Sicht absolut essentiell, dass Sie auch das richtige System auswählen können.
Und dann gibt es eben verschiedene Wege, da können Sie natürlich prüfen, ob Sie schon bestehende Systeme im Einsatz haben, die dazu passen und die von den Anforderungen her eben alles mitbringen und Ihre Fragestellungen abdecken können. Oder, wenn Sie da noch nichts im Einsatz haben und bisher zum Beispiel mit den klassischen Tools der Office Welt unterwegs gewesen sind, dann ist das natürlich eine gute Sache. Man müsste schauen, was diese Pakete, diese Corporate Performance Management Systeme und so weiter für Sie bieten und sich dann da eine bestehende Lösung auszuwählen.
Schritt 7: Itereative Implementierung des Management Reportings anhand von Prototypen
Wenn Sie das passende System für sich ausgewählt haben, dann ist es aus meiner Sicht absolut empfehlenswert die Implementierung iterativ, also in Schleifen prototypisch vorzunehmen.
Was heißt das jetzt konkret? Sie sollten natürlich auf der einen Seite, im Back End, also auf den verschiedenen Schichten also Schicht 1 und 2 in der OLTP-Schicht mit ihren Quell-Systemen und in der Data Warehouse Schicht mit dem Data Warehouse und den Data Marts schon konzeptionell die Daten vorbereiten und auch schauen, dass diese Strukturen sauber aufgebaut werden. #00:17:13-0#
Aber wenn Sie das machen, je nachdem wie groß die Datenmengen sind und wie umfangreich das Ganze ist, wird das etwas dauern. Und da haben Sie eben immer das leidige Thema, dass man das nicht sieht als Nutzer und als Anwender und deswegen ist mein Tipp. Bauen Sie diese Datenbasis auf, aber lassen Sie parallel dazu eben schon mal selbst, wenn bestimmte Daten eben noch nicht vorhanden sind, lassen sie schon mal einzelne Standard Berichte entwickeln und einzelne Analyse Strecken abbilden und das Stückchen für Stückchen machen. Und in diesem gleichen Schritt auch schon mit den Anwendern das Ganze testen.
Vorteile des 7-schrittigen Vorgehens zur Einführung von Management Reportings
Wenn Sie dieses Vorgehen wählen, dann haben sie 4 große Vorteile bzw. Mehrwerte.
Vorteil 1: Anwender interagieren früh mit den Systemen und Tools
Die Anwender kommen zum einen mit der Software schon in Berührung und lernen die kennen. Das senkt so ein bisschen die Barrieren.
Vorteil 2: Anwender erkennen weitere Potentiale der Lösung
Zum Zweiten. Sie erkennen die Potenziale und die Möglichkeiten durch die eigenen Erfahrungen die Sie als Anwender damit machen. #00:18:10-9#
Vorteil 3: Realitäts-Check des Konzepts und schnelle Anpassbarkeit
Und zum Dritten, die prüfen gleich, wenn Sie das benutzen, schon mal, ob alle Anforderungen, die Sie mit ihnen besprochen haben, richtig verstanden und eben auch abgebildet wurden. Ja und da geht es eben nicht darum, dass man jetzt wirklich jede Zahl im einzelnen Detail prüft, sondern, dass man schaut, ob das vom Konzept her passt.
Und wenn Sie merken das passt eben nicht, dann können Sie noch schnell Anpassungen und Korrekturen vornehmen und tun das ja schon an einer viel früheren Stelle als Sie das sonst machen würden, wenn Sie erst mal die Strukturen entwickeln und Wochen und monatelang vielleicht daran arbeiten, aber der Nutzer eigentlich gar nichts sieht.
Vorteil 4: Höhere System-Akzeptanz und Nutzerzufriedenheit durch die frühe Einbindung
Der 4. Vorteil aus meiner Sicht ist das Endergebnis und die Akzeptanz und Nutzerzufriedenheit. Die wird enorm steigen, weil die ganzen Fachbereiche eingebunden sind und die sagen dann ja nicht irgendwie: da hat mir jetzt einer soe ein System vor die Nase gestellt und jetzt soll ich das irgendwie benutzen, ist aber ganz doof.
Sondern die sind ja an dem ganzen Prozess beteiligt gewesen, haben mit Ihnen zusammen die Dimensionen definiert, haben gemeinsam entsprechende Reports getestet, haben schon mal geschaut, ob das alles funktioniert und konnten relativ frühzeitig sich einbringen und sagen: ich habe noch die und die Wünsche, müssen an der Stelle natürlich aufpassen, dass das vom Scope her immer noch passt, aber da kann man das ja eben Schritt für Schritt machen und sagen: okay, in Stufe 1 liefern wir diese Berichte und in der nächsten Stufe die nächsten Berichte und so das ganze Stück für Stück aufbauen. #00:19:21-8#
Ihr Mehrwert
Ich denke damit, mit diesen 7 Schritten, haben Sie eine gute Möglichkeit gemeinsam mit ihren Fachbereichen sehr erfolgreich Management Reporting Systeme einzuführen oder, wenn Sie schon welche haben, diese eben auch anzupassen oder zu erweitern, wenn Sie da bestimmte neue Anforderungen entdecken. Gut das war’s für heute. #00:19:55-9#
Bildnachweis: © CC0 Public Domain/ pixabay.com
Ihr Feedback
Wir freuen uns über eine Bewertung des CIO Podcasts bei Apple Podcasts und den anderen Portalen!
Fünf Sterne stehen für „gefällt mir sehr gut“. Herzlichen Dank!
Wie gefällt Ihnen diese Folge des CIO Podcasts? Senden Sie Ihr Feedback, Anregungen und Wünsche einfach über das Kontaktformular direkt an die Redaktion des CIO Podcasts (nicht öffentlich):
[contact-form-7 id=“189″ title=“CIO Podcast“]
Weitere Podcast Folgen finden Sie hier.