Fallstudie: Agile Business Intelligence bei einer Körperschaft des öffentlichen Rechts

Transkript

1 Fallstudie: Agile Business Intelligence bei einer Körperschaft des öffentlichen Rechts Kontakt: TDWI Germany e.v. Lindlaustraße 2c Troisdorf Arno Tigges OPITZ CONSULTING GmbH Kirchstraße Gummersbach (Nochen) arno.tigges@opitz-consulting.com Prof. Dr. Stephan Trahasch Hochschule Offenburg Badstraße Offenburg stephan.trahasch@hs-offenburg.de Robert Krawatzeck Technische Universität Chemnitz Fakultät für Wirtschaftswissenschaften Chemnitz robert.krawatzeck@wirtschaft.tu-chemnitz.de Michael Zimmer Universität Stuttgart Betriebswirtschaftliches Institut Keplerstr Stuttgart zimmer@wi.uni-stuttgart.de Juli 2013

2 Vorbemerkungen Beschreibung des Unternehmens Auslöser und Ziele des Projekts und der BI-Anwendung Ausgangssituation Ziele Erwarteter Nutzen Projektablauf und Betrieb Projektpartner und zukünftige Nutzer Projektmanagement und Change Management Beschreibung der BI-Architektur Beschreibung der BI-Organisation Roll-out und Betrieb Maßnahmen zur Erhöhung der BI-Agilität Prinzipien Vorgehensmodelle Methoden Technologie Abhängigkeiten der Maßnahmen untereinander Erfahrungen und Erfolgsfaktoren Realisierter Nutzen und bewirkte Veränderungen Reflexion der Barrieren und Erfolgsfaktoren Lessons Learned

3 Vorbemerkungen Unter BI-Agilität 1 wird dabei die Eigenschaft der Business Intelligence, vorhersehbare und unvorhersehbare Anforderungen in Bezug auf Funktionalität oder den Inhalt einer BI-Lösung in einem vorgegebenen Zeitrahmen in angemessener Qualität abzubilden, verstanden. Agile BI hingegen umfasst alle Maßnahmen eines Unternehmens, welche durchgeführt werden, um die BI- Agilität umzusetzen. Abb. 1 stellt die beiden Begriffe BI-Agilität (als Eigenschaft der BI) und Agile BI (konkrete Maßnahmen) schematisch dar. Abbildung 1: Definition der Begriffe BI-Agilität und Agile BI Die möglichen Maßnahmen zur Steigerung der BI-Agilität lassen sich innerhalb eines Gestaltungsspielraumes, welcher durch die drei Kern-BI-Ebenen BI-Architektur (z.b. Core-Data- Warehouse-Ansatz, Unterscheidung in Entwicklungs- und Produktivsystem, ), BI- Aufbauorganisation (z.b. BICC, Governance-Regeln; ) und BI-Prozesse (z.b. Definition Ablauf Change-Requests) definiert wird, kategorisieren. Der Gestaltungsspielraum unterteilt sich in Prinzipien, Vorgehensmodelle, (Entwicklungs-) Methoden und Technologien, welche zur Entwicklung, zum Betrieb und zur Evolution einer BI-Lösung eingesetzt werden. Abb. 2 stellt die Verankerung der BI im Unternehmen sowie ihrer drei Kernebenen und ihren Gestaltungsspielraum nochmals schematisch dar. Abbildung 2: Verankerung der BI im Unternehmen mit ihren drei Kernebenen BI-Architektur, BI-Aufbauorganisation und BI-Prozesse sowie des dadurch definierten Gestaltungsspielraums zum BI-Betrieb & Evolution 1 Krawatzeck, R., Zimmer, M., & Trahasch, S. (2013). Agile Business Intelligence - Definition, Maßnahmen und Herausforderungen. HMD - Praxis Wirtschaftsinformatik,

4 1 Beschreibung des Unternehmens In dieser Fallstudie wird eine Körperschaft öffentlichen Rechts betrachtet, die mit mehr als Mitarbeitern in Bayern tätig ist. Das hier beschriebene BI-Projekt, welches nur anonymisiert referenziert werden kann, war in der Selbstverwaltung der Körperschaft angesiedelt und zwar in den Bereichen Personal und Controlling. Da diese beiden Themen inhaltlich weitestgehend generisch sind und die eigentliche Tätigkeit des Unternehmens deswegen auch keine große Rolle spielt, ist eine nähere Beschreibung des Unternehmens auch nicht notwendig. 2 Auslöser und Ziele des Projekts und der BI-Anwendung 2.1 Ausgangssituation Das Unternehmen setzt in der Verwaltung SAP in den Bereichen Finanzen, Controlling und Personalwesen ein. In der Ausgangssituation wurde das Berichtswesen im Wesentlichen auf Basis von Excel-Sheets durchgeführt. Die regelmäßig nötige Erstellung dieser Excel-Berichte war mit hohen zeitlichen Aufwänden verbunden, da aus den verschiedenen SAP Modulen Daten exportiert und anschließend in Excel konsolidiert und aufbereitet werden mussten. Neben den stets bei solchen manuellen Verfahren sich häufig einschleichenden Fehlern, die allerdings mit großer Sorgfalt und Qualitätssicherung weitestgehend vermieden werden konnten, war ein Hauptproblem, dass die Berichte nicht ausreichend zeitnah erstellt werden konnten. Das führte dazu, dass einige relativ wichtige Berichte auch nur in größeren Intervallen (typischer Weise nur alle 3-6 Monate) erstellt wurden. Außerdem wurden eigentlich alle Excel-Berichte hinsichtlich der dargestellten Perioden und Attribute auf das Nötigste begrenzt, um den zeitlichen Aufwand und die Qualitätskontrolle nicht noch weiter ausufern zu lassen. Der Vorstand und die Geschäftsführung des Unternehmens hat deshalb ein BI-Projekt aufgesetzt. 2.2 Ziele automatische und stets fehlerfreie Beladung aller nötigen Daten aus den SAP-Quellen die Möglichkeit schaffen, auch Daten aus Drittquellen einfach verknüpfen zu können weitergehende Reporting- und Analysemöglichkeiten als bisher zeitnahe Berichtserstellung größerer Nutzerkreis der Berichte erreichen, durch selektive Datenberechtigung modernes und zentrales, web-basiertes Reporting im vorhandenen Intranet 2.3 Erwarteter Nutzen Der bisherige Prozess der Berichtserstellung war durch die vielen manuellen Schritte im Unternehmen vollumfänglich quasi nur von je einer Person im Bereich Controlling und einer Person im Bereich Personalwesen durchführbar. Die Produktiveinführung des BI-Systems sollte die Risiken, die solche Kopfmonopole mit sich bringen, reduzieren. Außerdem sollten zukünftige Anpassungen und Erweiterungen im Berichtswesen einfach und damit kostengünstig gestaltbar werden. Ein weiterer erwarteter Nutzen war, das vorher stark mit der Erstellung der Berichte gebundene Personal zukünftig für effektivere Tätigkeiten einzusetzen, z.b. um die Ergebnisse zu analysieren, statt sie nur zu erstellen. 4

5 Ein weiterer Nutzen sollte sich aus dem deutlich erweiterten Empfängerkreis der Berichte ergeben. Diverse vorherige Excel-Berichte in den beiden Bereichen Controlling und Personalwesen beinhalteten Daten, die nicht jedem Sichtbar sein sollten. Zum Beispiel im Personalwesen sollen die Personaldaten der Mitarbeiter nur dem jeweils Vorgesetzten zugänglich gemacht werden. Die neue BI-Lösung ermöglicht durch ein automatisch selektives Berechtigungskonzept genau diese begrenzten Sichten, auf genau die jeweiligen unterstellten Mitarbeiter (oder Kostenstellen, etc.). Bei der vorherigen manuellen Lösung wäre dies mit überproportional hohem Aufwand verbunden gewesen, weshalb solche Berichte auf Abteilungsleiterebene erst gar nicht erstellt werden konnten. Die mit dem neuen System mögliche, erheblich größere Anwenderzahl der Berichte, hat diversen positiven Nutzen für das Unternehmen. Zum einen, dass die Zahlen direkt den entsprechenden Personenkreis zur Verfügung stehen, zum anderen gibt es aber auch motivierende Faktoren, wenn mehr Informationen auch auf niedrigeren Hierarchieebenen zur Verfügung stehen. 3 Projektablauf und Betrieb 3.1 Projektpartner und zukünftige Nutzer Das Unternehmen verfügt über einen eigenen, verhältnismäßig großen IT-Dienstleister, der auch selber schon Datawarehouse Projekte umgesetzt hatte. Die Geschäftsführung beauftragte deshalb diesen eigenen internen IT-Dienstleister mit der Umsetzung des Projekts. Da bei dem Dienstleister insbesondere bezüglich einiger spezieller Herausforderungen, wie der SAP-Anbindung und den dortigen teilweise sehr komplexen Datenstrukturen, oder der selektiven Datenberechtigung kaum Erfahrungen vorhanden waren, und auch die aktuellste Version der geplanten BI-Suite bislang noch nicht im Einsatz war, wurden für die Projektabwicklung zusätzliche externe Spezialisten hinzugezogen. Des Weiteren waren wie in agilen Projekten üblich die zukünftigen Fachanwender direkt in das Projekt intensiv eingebunden. Somit waren diese drei Parteien am Projekt beteiligt: der eigene (quasi interne) IT-Dienstleister als Auftragnehmer der Geschäftsleitung des Unternehmens Personen aus den Fachbereichen des Unternehmens, die die zukünftigen Anwender und Anwenderinteressen vertreten ein externer Dienstleister als Technologie- und Projektspezialist 3.2 Projektmanagement und Change Management Da ein geeigneter Projektleiter bei dem internen IT-Dienstleister nicht verfügbar war, wurde diese Ressource durch einen Projektmanager des externen Dienstleisters gestellt, der vor allem auch in ähnlich gearteten Projekten schon diverse Erfahrungen mitbrachte. Dieser Projektleiter war darüber hinaus bereits einige Zeit in agilen Projekten tätig. Da der interne IT-Dienstleister in anderen, nicht- BI-Projekten schon gute Erfahrungen mit agilen Vorgehensweisen gesammelt hatte, und durch die Verfügbarkeit des entsprechend erfahrenen Projektmanagers, wurde das BI-Projekt nach agilen Prinzipien durchgeführt. Ein Change Management im klassischen Sinne fand nicht statt. 5

6 3.3 Beschreibung der BI-Architektur Die implementierte Architektur (vgl. Abbildung 3: BI-Architektur) lehnt sich in weiten Teilen an die klassische BI-Architektur an, die entsprechend gut auch von der eingesetzten Oracle BI Suite unterstützt wird. Dabei werden die Quelldaten (zu 95% aus SAP) zunächst in ein Staging-Layer geladen, von dort in das Foundation Layer, bestehend aus einer Kombination aus Core- Datawarehouse und Operational Data Store (ODS), und von dort schließlich in die verschiedenen Data Marts, bzw. sogenannte Themenbereiche, wie sie in der Oracle BI Suite genannt werden. Die Themenbereiche gruppieren dabei die Data Marts der jeweiligen Fachbereiche (Controlling und Personalwesen). Abbildung 3: BI-Architektur 3.4 Beschreibung der BI-Organisation Da dies das erste echte BI-Projekt im Unternehmen war, gab es keine entsprechende BI-Organisation. Im Rahmen des Projekts wurde aber eine intensive Zusammenarbeit einiger Fachbereichs-Poweruser mit den anderen Projektbeteiligten praktiziert. Vor allem bezüglich weiterer und sich ständig (agil) verändernden Anforderungen an das BI-Projekt kristallisierte sich während der Projektlaufzeit eine gewisse Federführung des Fachbereichs Controlling heraus, welches grob in die Richtung eines echten BICC ging. Die Thematik BICC wurde während des Projekts auch konkret thematisiert, eine nachhaltige Organisation in dieser Richtung wurde aber noch nicht etabliert. 6

7 3.5 Roll-out und Betrieb Durch das agile Vorgehen im Projekt wurden ständig neue Releases der BI-Anwendung über den systematischen Weg durch die drei Umgebungen Entwicklungsumgebung, Abnahmeumgebung und Produktivsystem in den Live-Betrieb übergeben. Die für den Betrieb verantwortliche Abteilung hat mit den kurzen Release-Zyklen anfangs große Probleme gehabt, insbesondere da Anfangs der Rollout Prozess noch mit vielen manuellen und fehleranfälligen Schritten verbunden war. Im Laufe des Projektes wurde der Prozess aber kontinuierlich optimiert und an die weitestgehend standardisierten Roll-out-Prozesse der nicht-bi-projekte angepasst. So wurden gegen Projektende die häufigen Deployments auf die unterschiedlichen Umgebungen nicht mehr als Last empfunden, sondern als hilfreiche Möglichkeit, schnell auf kurzfristige Veränderungen oder auch auf auftretende Fehler reagieren zu können, ohne die Sorge zu haben, dass die Qualität im Produktivsystem sinkt. Ein Anforderung, welche während der Projektlaufzeit nicht umgesetzt werden konnte, sind möglichst automatisch funktionierende Regressionstests. Diese Tests verursachten noch verhältnismäßig großen manuellen Aufwand, und wurden deshalb oft auch nur in Stichproben durchgeführt. Eine Lösung für automatische und so gut es geht vollumfängliche Tests wurde im Rahmen eines Folgeprojekts aber inzwischen eingeführt. 4 Maßnahmen zur Erhöhung der BI-Agilität 4.1 Prinzipien Bei Projekten ab einer gewissen Laufzeit ist es normal und üblich, dass sich während der Projektabwicklung Veränderungen ergeben, z.b. im eigentlichen Prozess, den Umsetzungsmethoden, etc. Insbesondere bei agilen Projekten ist dies normal und sogar beabsichtigt. Durch regelmäßig durchgeführte Retrospektiven werden stetig Verbesserungspotentiale gefunden, Fehlentwicklungen frühzeitig aufgedeckt oder gleich vermieden, und die Projektabwicklung letztendlich dadurch kontinuierlich verbessert. Die im hier beschriebenen BI-Projekt erfolgte kontinuierliche Verbesserung wurde dabei stets an die für das Projekt wichtigsten Werte ausgerichtet: Der letztendliche Unternehmensnutzen der erstellten BI-Plattform ist wichtiger, als das strikte einhalten von Architektur-Paradigmen. Beispiel: Die direkte Anbindung einer in Excel gepflegten Planungsdatei und Verwendung der Werte auf einem Dashboard hatte einen entsprechenden hohen Nutzen für das Unternehmen, somit wurde das auch tatsächlich direkt angebunden, und es wurde nicht erst der vollständige Weg durch alle architektonischen Schichten beschritten und die Daten erst in SAP überführt um von dort erst in das DWH zu laden. Das schnelle und frühzeitige Reagieren auf Veränderungen ist wichtiger, als das befolgen eines vorher definierten Plans. 7

8 Beispiel: Das von einem Fachbereich im Vorfeld erstellte Anforderungsdokument mit einer Anzahl von genau definierten Berichten sollte ursprünglich im Rahmen des Projekts umgesetzt werden. Im Laufe des Projektes zeigte sich, dass viele Berichte in genau der spezifizierten Form nicht mehr sinnvoll waren. Somit wurde das Anforderungsdokument nur noch als Road-Map genutzt, die meisten der Berichte wurden im Projekt zwar deutlich abweichend aber immer genau nach Wunsch und zur Zufriedenheit des Fachbereichs umgesetzt. Die direkte und intensive Einbindung des Fachbereichs ist wichtiger, als die Einhaltung vorgegebener Prozesse und Formalitäten. Beispiel: Statt Berichte von den Entwicklern erstellen zu lassen und diese mit einem mehrstufigen Freigabeprozess vom Fachbereich abnehmen zu lassen, wurden regelmäßig Termine mit Workshop-Charakter im Projektbüro abgehalten. Key-User des Fachbereichs haben hierbei gemeinsam mit den BI Entwicklern (zu zweit vor einem Bildschirm) die neu entwickelten Kennzahlen verifiziert und direkt die Berichte und Dashboards gemeinsam zusammengeklickt. Wenn der Bericht fertig war, war die Freigabe damit erteilt und wurde nur noch mit kurzer E- Mail im Anschluss formalisiert. 4.2 Vorgehensmodelle Das eingesetzte Projektvorgehensmodell war ein grob an SCRUM angelehntes Modell folgenden Besonderheiten: mit den Die Iterationen (Sprints) hatten keine tatsächlich feste Dauer (Time-Box), sondern es gab eine maximale Dauer, nach der spätestens ein Sprint abgeschlossen sein musste. Meistens wurde aber, sobald die geplanten funktionalen Änderungen/Neuentwicklungen produktionsreif umgesetzt waren, schon vorher das Sprintergebnis auf die Testumgebung ausgerollt und damit der Sprint beendet. Anschließend wurde bereits mit dem nächsten Sprint begonnen. Die Dauer der Sprints lag zwischen 1 Woche bis maximal 3 Wochen. Pro Sprint wurden stets nur 1 oder 2 User-Stories eingeplant (in Abhängigkeit der Verfügbarkeit der Teammitglieder und des Fachbereichs), priorisiert nach Vorgabe des Fachbereichs, welcher die Rolle des Product Owners besaß. Andere Punkte aus SCRUM wurden 1:1 übernommen: das Produkt-Backlog, das Daily Meeting, Durchführung von regelmäßigen Retrospektiven, die generelle Rolle des SCRUM Masters, die interdisziplinäre Besetzung des Teams, und vor allem das Prinzip, das am Sprintende immer eine funktionierende (produktionsreife) Version ausgeliefert werden muss, die dem Endanwender einen zusätzlichen Nutzen stiftet. 4.3 Methoden Im Projekt wurden alle ETL-Programme ausnahmslos mit dem Oracle Warehouse Builder implementiert. Dieses Repository-basiertes Werkzeug ermöglicht ETL-Programme und 8

9 Datenbewirtschaftungsabläufe grafisch zu erstellen. Die eigentlichen ETL-Programme werden dann von einem Generator erstellt. Durch die ausnahmslose Anwendung dieses Werkzeugs ergibt sich automatisch auch ein gewisser Grad an technischer Dokumentation, die im Tool selber genutzt werden kann und hinreichend ist, damit eine Weiterentwicklung oder Korrektur stets möglich ist, auch von Entwicklern, die am Projekt selber nicht beteiligt gewesen sind. Die Kennzahlen und Berichte sowie Dashboards wurden in den entsprechenden Tools stets in enger Zusammenarbeit mit entsprechenden Key-User aus den Fachbereichen erstellt, quasi wie Pair-Programming, also zu zweit vor einem Bildschirm, wobei aber jeweils ein Entwickler und ein Fachanwender ein Paar bildeten. Automatisiertes Testen wurde in diesem Projekt noch nicht eingesetzt, wie aber bereits beschrieben, wurden inzwischen im Rahmen eines weiteren Projekts positive Erfahrungen mit automatisierten Regressionstests gemacht. 4.4 Technologie Das BI-Projekt wurde mit der Oracle BI Suite Enterprise Edition umgesetzt und basiert demnach vollständig auf dieser Technologie. Besondere Bedeutung hat dabei das Common Enterprise Information Model, ein von Oracle geprägter Name für das verwendete drei-schichtige Metadaten Modell. Dieses Modell definiert eine zentrale Zugriffsschicht, die in der Lage ist, aus den verschiedenen BI-Architektur-Ebenen Daten zu lesen. Dieses Modell ist sehr hilfreich dabei, ein agiles BI-Projekt umzusetzen. Es ist mit einfachen Schritten möglich, z.b. Datenquellen oder Kennzahlen anzupassen, ohne dabei bereits erstellte Berichte, Dashboards, Alerts o.ä. verändern zu müssen. Außerdem werden eine große Anzahl an Datenquellen (sogar Excel-Dateien, siehe Beispiel oben) unterstützt, die im Einzelfall auch direkt angebunden werden können. 4.5 Abhängigkeiten der Maßnahmen untereinander Alle in den vorherigen Abschnitten 4.1 bis 4.4 beschriebenen Aspekte wurden in dieser Form erstmalig im Unternehmen eingeführt, mit dem Ziel, eine entsprechende BI-Agilität zu erreichen. Insbesondere müssen zunächst die agilen Prinzipien klar sein und in ihrer Wichtigkeit prinzipiell von allen Projektbeteiligten verstanden und umgesetzt werden. Bezüglich des Vorgehensmodells bietet sich an, sich auf grundsätzliche Bestandteile von vorhandenen bzw. etablierten agilen Vorgehensmodellen zu stützen. Die 1:1 Übertragung solcher Modelle funktioniert auch in der klassischen Softwareentwicklung meistens nicht vollumfänglich, in diesem agilen BI-Projekt wurde deswegen ein entsprechend adaptiertes Modell verwendet, welches die Hauptvorgabe hatte, sich an den oben beschriebenen agilen Prinzipien auszurichten und insgesamt in das Unternehmensumfeld zu passen. Die im Projekt verwendeten Methoden sowie die Technologien mussten insgesamt in der Lage sein, alle Anforderungen an das agile Vorgehen zu erfüllen. Vor allem die Möglichkeit, ohne negative Nebeneffekte auf die Schnelle Anpassungen vornehmen zu können und diese dann in Produktionsumgebungen auszurollen, war hierbei von großer Bedeutung. Die Abhängigkeiten zwischen den Maßnahmen sind in diesem Projekt somit sehr deutlich und wesentlich gewesen. 9

10 5 Erfahrungen und Erfolgsfaktoren 5.1 Realisierter Nutzen und bewirkte Veränderungen Der größte realisierte Nutzen des BI-Projekts war letztendlich, dass die Anwender wortwörtlich genau das richtige bekommen haben, genau das, was tatsächlich notwendig war, und nicht dass, was irgendwann im Vorfeld mal als die vermeintlich richtige Lösung angedacht war. Während des Projektverlaufs wurde die Veränderung spürbar, dass die Fachbereichsanwender wachsendes Vertrauen bekamen, dass am Ende doch ein nutzbares Produkt entsteht. Anfangs vorhandene verhältnismäßig große Skepsis bei einigen Anwendern konnte nach und nach abgebaut werden. Eine besondere Veränderung war, dass selbst die Autoren, die mit viel Aufwand und Mühe vor Projektbeginn ihre Anforderungen in Form von Konzepten niedergeschrieben hatten, zu dem Schluss kamen, dass das agile Vorgehen diese Arbeit weitgehend überflüssig macht und dabei letztendlich trotzdem hervorragende, wenn nicht sogar bessere (weil besser passende) Ergebnisse erreicht werden können. Eine weitere wichtige Veränderung war, dass fortan die BI-Experten aus der IT-Abteilung nur noch Kennzahlen/KPIs zur Verfügung stellen. Die eigentlichen Berichte und Dashboards werden durch Key-User im Fachbereich eigenständig erstellt und die IT wird nur im Bedarfsfall noch angefordert. Doppelter Nutzen: weniger Aufwand für IT und mehr Nutzen für Fachbereich. 5.2 Reflexion der Barrieren und Erfolgsfaktoren Wichtiger Erfolgsfaktor des Projekts war insbesondere, möglichst viele geeignete Personen im Projekt auf allen Seiten zu haben. Die Bereitschaft und auch ein Stückweit Mut war bei den Beteiligten des Auftraggebers nötig, ein Projekt auf diese Weise durchzuführen. Vor allem zum Projektbeginn war der Fortschritt nicht so schnell, wie manche erwartet hatten. Das agile Vorgehen hat am Ende auch keine Kosten gespart, weil es nicht schneller als ein klassisches Vorgehen gewesen ist. Der Nutzwert war am Ende aber insgesamt deutlich größer als erwartet. 5.3 Lessons Learned Ein gewisses Problem war, dass das Verständnis für agiles Vorgehen nur langsam gewachsen ist, und dies auch unterschiedlich schnell bei den verschiedenen Stakeholdern. Als Erfahrung aus dem Projekt kann man mitnehmen, dass ein entsprechendes Stakeholdermanagement sinnvoll und hilfreich ist. Eine weitere Lesson Learned ist, dass man agiles Vorgehen durchhalten muss. Auch wenn nicht gleich der Erfolg eintritt. Sehr wichtig für den Projekterfolg: es müssen alle Entwickler örtlich sehr nah, am besten in einem Raum, zusammenarbeiten (alte Erkenntnis aus klassischem agilen Projekten, was sich vollständig auf agile BI übertragen lässt) Das erste agile (BI) Projekt in einem Unternehmen sollte möglichst nicht scheitern! Architektur muss für agile Anforderungen geeignet sein (also on-the-fly Zwischenlösungen müssen problemlos umgesetzt werden können) 10