Fallstudie: Agile Business Intelligence bei einer Bank

Transkript

1 Fallstudie: Agile Business Intelligence bei einer Bank Kontakt: TDWI Germany e.v. Lindlaustraße 2c Troisdorf Eckart J. Schröer Head of Information Management Credit Uwe Müller INFORMATION WORKS GmbH Rolshover Straße Köln Prof. Dr. Stephan Trahasch Hochschule Offenburg Badstraße Offenburg Robert Krawatzeck Technische Universität Chemnitz Fakultät für Wirtschaftswissenschaften Chemnitz Michael Zimmer Universität Stuttgart Betriebswirtschaftliches Institut Keplerstr Stuttgart 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 Beschreibung der Maßnahmen zur Erhöhung der BI-Agilität sowie deren Einfluss auf die verschiedenen BI-Ebenen 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 n 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-Dataund Produktivsystem, ), BI- Warehouse-Ansatz, Unterscheidung in Entwicklungs- 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 Bei dem Unternehmen handelte es sich um eine der (damals) größten börsennotierten Banken in Deutschland. Mit mehr als Mitarbeitern, Filialen und über 9,8 Millionen Kunden zum Zeitpunkt des Projektes, war der Kunde die Nummer eins im Herzen Europas. In ihren Kernmärkten Deutschland und Österreich sowie in der aufstrebenden Wachstumsregion Zentral- und Osteuropa hatte sich die Bankengruppe als führendes Netzwerk positioniert. Sie konzentrierte sich dabei auf das europäische Privat- und Firmenkundengeschäft, ergänzt um kundenbezogene Kapitalmarktaktivitäten. 2 Auslöser und Ziele des Projekts und der BI-Anwendung 2.1 Ausgangssituation Am Anfang stand die Entscheidung, mit dem Kreditbuch des Geschäftsfelds Corporates & Markets anders umzugehen: Statt Kredite einzukaufen und auf Lager zu legen sollte das Portfolio aktiv gemanaged werden. Für diese neue Aufgabenstellung wurde im Jahr 2004 der Bereich Active Credit Portfolio Management (ACPM) geschaffen. Die etwa 30 Portfoliomanager dieser Einheit mussten mit einem verlässlichen Instrument zur aktiven Steuerung ihrer Portfolios ausgestattet werden. 2.2 Ziele Die Bank plante, ein neues Geschäftsmodell zu implementieren, das die sich in rasantem Tempo neu entwickelnden Kapitalmarktprodukte intelligent mit dem klassischen Kreditgeschäft verknüpft. Geplant war, Kreditderivate zur Absicherung von Kreditrisiken zu verwenden, die als zu groß angesehen wurden. Gleichzeitig sollte durch die Investition in gegenläufige Risikostrukturen das Gesamtportfolio besser diversifiziert werden. Es ging um die Vermeidung von Konzentrationen, eine möglichst breite Risikostreuung und das Erkennen von Korrelationen zur Verhinderung von Dominoeffekten im Fall von Kreditausfällen. Die aktive, auf die Zukunft gerichtete Portfoliosteuerung, bedeutete für die Bank zusätzlich eine große Menge an heterogenen Informationsquellen in ihre Tools und Modelle einzubeziehen. Neuland wurde beschritten. Es war damit zu rechnen, dass sich die fachlichen Anforderungen rasch weiterentwickeln oder sich entlang der "Lernkurve" kurzfristiger Anpassungsbedarf ergibt. Dazu bedurfte es einer technisch flexiblen Infrastruktur. 2.3 Erwarteter Nutzen Als wesentliche Voraussetzung wurde die zentrale Datenbasis zur Unterstützung der aktiven Steuerung und Bewertung des Kreditportfolios angesehen. Die Integration und Konsolidierung der Informationen aus 60 äußerst heterogenen internen und externen Datenquellen bildete die Basis-Infrastruktur für ein optimiertes Portfoliomanagement. Weil die Märkte sich sehr schnell weiter entwickelten, sollte der Fachbereich eine hohe Flexibilität bei der Anbindung neuer Datenquellen bekommen, um die Informationsqualität permanent verbessern zu können. Neue, zum Teil sehr komplexe Produkte mussten innerhalb weniger Wochen zum Einsatz kommen können, ein schnelles "time-to-market" war essentiell. Damit war klar, dass klassische, am Wasserfall-Modell orientierte, formalistische Entwicklungsmethoden nicht zum Einsatz kommen konnten. Durch den Einsatz moderner BI Tools erwartete man eine schnellere Entwicklungsgeschwindigkeit, bessere Transparenz, Nachvollziehbarkeit (und damit Wartbarkeit). Von größter Bedeutung war in diesem Zusammenhang die Einführung eines zentralen Metadatenmanagements. 3 Projektablauf und Betrieb Im Rahmen der Erstimplementierung bestand die Aufgabe darin, neben den eigentlichen fachlich funktionalen Anforderungen, auch eine agile Weiterentwicklung der Anwendung durch den Fachbereich selbst zu gewährleisten. So war beispielsweise sicherzustellen, dass neue Datenquellen kurzfristig in den Prozess integriert werden konnten, wenn es auf fachlicher Sicht notwendig ist. Die verschiedenen heterogenen Datenquellen mussten dazu integriert abgelegt und die 4

5 relevante Business-Logik sehr transparent und einfach änderbar umgesetzt werden. Die aus diesen Prozessen resultierenden Kennzahlen wurden schließlich über Data Marts bereitgestellt. Hier können sich die unterschiedlichen Konsumenten entweder als Power User direkten Zugriff auf die Daten verschaffen oder werden durch ein standardisiertes und automatisiertes Reporting bedient. Dies hatte letztendlich Auswirkungen auf die verwendete Technologie, die Architektur und die BI Organisation. Die zu bildende BI Organisation erforderte zur Sicherstellung des gesamten Informationsgewinnungsprozesses einen Ansatz, indem die Portfoliomanager und Information Manager eng zusammenarbeiten. Das initiale Projekt zum Aufbau der Basis-Infrastruktur wurde klassisch, nach einem linearen phasenorientierten Vorgehensmodell durchgeführt. Eine klare Trennung der Verantwortlichkeit zwischen Fachbereich und IT wurde festgelegt. Die IT stellt die Plattform bereit und administriert diese, d.h. sie ist verantwortlich für die Installation der Server und notwendigen Cluster, das automatisierte Deployment Verfahren, alle Fragen des technischen Betriebs, im Prinzip für alle technisch anspruchsvollen Aufgaben. Die agile Entwicklung der ETLs, der Datenmodelle, der Rechenkerne und Reports liegt allein in der Zuständigkeit des Fachbereichs. Information Management Team (within business unit) Define business processes Derive information needs Search for appropriate (internal or external) data sources Validate data sources (functional coverage, completeness, granularity, quality) Integrate sources with existing information (find semantic links, design overall data model and data catalogue) Extraction/Transformation/Load (graphical modelling with automated code generation) Data-management (incl. data quality) Web based BI reports IT division Design and setup of the technical environment and infrastructure (incl. technical interfaces to source systems) Deployment automation server (development test production) Security (e.g. LDAP-integration) Operation and performance tuning Technical complex challenges 3.1 Projektpartner und zukünftige Nutzer Zum Zeitpunkt der initialen Produktivsetzung hatte das System ca. 130 Anwender, davon 30 Portfoliomanager. Das als Operational Data Store bezeichnete Core Data Warehouse bestand aus ca Datenelementen in 322 Tabellen. Eingesetzte Technologien waren SAS DI Studio von SAS, Oracle 9i, Cognos und Sun Solaris 10. Verantwortlich für den Aufbau der gesamten BI Architektur war der langjährige SAS Alliance Partner INFORMATION WORKS. Als zusätzlichen Projektpartner holte ACPM den internen IT-Dienstleister ins Boot, der den Aufbau der Systemarchitektur und die Entwicklung des Deployment Servers übernahm. Weitere Unterstützung für das Projekt leisteten die SAS Professional Services: Sie waren maßgeblich an der Entwicklung des Betriebskonzeptes beteiligt und führten außerdem Schulungen für SAS ETL Studio durch. 3.2 Projektmanagement und Change Management Im Rahmen des initialen Projektes wurde eine agile BI Plattform geschaffen, die es ermöglichte, den Demandmanagementprozess agil auszugestalten. In diesem Zusammenhang werden laufend alle Anforderungen gesammelt, bewertet und geclustert. Von Kleinanforderungen, die sofort realisiert werden, bis hin zu umfangreichen Projekten. Im direkten Austausch mit den Stakeholdern werden die jeweiligen Anforderungen laufend priorisiert. 5

6 3.3 Beschreibung der BI-Architektur Unter Verwendung eines Best of Breed Ansatzes bei der Toolauswahl wurde im Bereich Credit Portfolio Management eine Data Warehouse-Umgebung aufgebaut, die Informationen aus 60 verschiedenen Quellen integriert. Es wurden Daten aus DB2, Oracle, Sybase, XML- oder Flatfiles angebunden, die von den Betriebssystemen MVS, Unix, OS/400 oder Microsoft NT bzw. XP geliefert wurden. Die Verarbeitungs-Architektur folgt einem strengen Data Warehouse-Schichtenmodell. Um einen konsistenten Datenhaushalt zu schaffen, werden alle Informationen zunächst in einem Operational Data Store (ODS), einem klassisch-relationalen Data Warehouse, zwischengelagert. Das ODS sichert die logische Konsistenz aller Daten und dient als Single Point of Truth. In einem zweiten Schritt werden die im ODS gehaltenen Daten wiederum mit Hilfe des ETL-Tools auf verschiedene Data Marts verteilt. Dort stehen sie für fachspezifische Aufgaben und für Auswertungen optimiert zur Verfügung. Die Vorteile der toolbasierten ETL Lösung waren, neben der Möglichkeit der transparenten Anbindung heterogener Quellen, die Schaffung eines Single Point of Control auf Basis des integrierten Metadatenmanagements ("In welchem Kontext wird ein bestimmtes Datenelement verwendet?" Diese Information erleichtert die Wartung erheblich und hilft dabei, Kollateralschäden bei Änderungen zu vermeiden). Zu den Kennziffern, die in den Data Marts vorgehalten werden, gehören unter anderem Kreditgrößen (Exposures), Ausfallwahrscheinlichkeiten, der erwartete Verlust (Expected Loss), Value at Risk, Eigenkapitalbindung, RAROC (Risk Adjusted Return on Capital) und börsentägliche Bewertungen von offenen Positionen am Terminmarkt (Mark-to-Market- Bewertungen), ergänzt um diverse Volatilitätsmaße. Lieferquellen dafür sind Bank-interne Systeme aus dem kommerziellen Firmenkundengeschäft und den Front-Office-Handelssystemen, aber auch externe Quellen, die Markt- und Ratingdaten bereitstellen. Ferner werden in der Plattform selbst diverse Risikokennzahlen über dedizierte Rechenkerne berechnet. 3.4 Beschreibung der BI-Organisation Das bedeutendste Merkmal der Umgebung ist die hohe Eigenständigkeit der Fachabteilung. Mit Hilfe des ETL-Tools kann der Bereich ACPM alle Lade- und Transformationsprozesse kurzfristig selbst entwickeln oder modifizieren, weil nicht mehr nativ programmiert werden muss. Früher mussten dafür der IT-Abteilung Fachkonzepte bereitgestellt, technische Detailspezifikationen abgeleitet und umfangreiche Abnahmetests im Rahmen der Produktivsetzung durchgeführt werden,. Implementierungen und Produktivsetzungen haben damit naturgemäß erheblich mehr Zeit in Anspruch genommen. Die neue Lösung bietet mehr Flexibilität bei höherer Entwicklungsgeschwindigkeit und besserer Transparenz für die Fachbereiche. Das bedeutet, der Fachbereich arbeitet jetzt mit einer vollautomatisch erzeugten, zuverlässigen Datenbasis, die Transparenz über das Portfolio, die Risikoverteilung und die Marktbewertung bietet. Auf dieser Basis können zukunftsgerichtete Portfoliostrategien agil entwickelt und umgesetzt werden. Die Weiterentwicklung des Systems inkl. Produktivsetzung und Qualitätssicherung liegt in der Verantwortung des Fachbereiches, in den die BI-Experten organisatorisch integriert sind. Deren Rolle ist hybrid: sie müssen ein sehr gutes Verständnis für das Geschäft haben, aktiv mitdenken können, erfahren in der Modellierung sein und schließlich die gefundene Lösung implementieren. Dabei entfällt der weit überwiegende Zeitanteil auf die fachliche Problemanalyse, das Finden und Verstehen geeigneter Datenquellen und 6

7 die Konzeption einer sinnvollen Integration. Die eigentliche Implementierung und der Test sind vergleichsweise kurze Zeitabschnitte. Ein iteratives Vorgehen unter Einbeziehung des Business hat dabei insbesondere bei der Identifikation und Validierung von neuen Datenquellen große Vorteile. Für diese Aufgaben wurde im Bereich ACPM eine Information Management Abteilung gegründet, deren Mitarbeiter (rot) räumlich direkt bei den Portfolio Managern (hellblau) sitzen. BI- Team und Endabnehmer sitzen in einem Raum, Tisch an Tisch und kommunizieren eng miteinander. Damit wird das sonst oft bemängelte "Gap" zwischen Business und IT geschlossen. Anforderungen werden laufend aufgenommen und so zeitnah wie eben möglich umgesetzt. Komplexere Anforderungen werden in regelmäßigen Meetings besprochen und priorisiert. Die Hierarchien sind flach, das Team ist interdisziplinär aufgestellt. 3.5 Roll-out und Betrieb Zur Sicherstellung der Anforderungen an Agilität und damit der schnellen Produktivsetzung, konnten klassische Produktivsetzungsverfahren keine Anwendung finden. Gleichzeitig mussten aber gängige IT-regulatorische Anforderungen hinsichtlich Verfügbarkeit, Verbindlichkeit und Vertraulichkeit von Daten, sowie der Transparenz und Nachvollziehbarkeit von Prozessen genügt werden. Dies erforderte eine technische Unterstützung und hohe Automatisierung des gesamten Prozesses. Im Projekt wurde deshalb ein Deployment Server entwickelt, der untertägig jederzeit neu entwickelte oder geänderte Objekte revisionssicher in die Produktionsumgebung transportieren kann. In diesem Workflow-gesteuerten Prozess, der auch eine Einhaltung des Vieraugen-Prinzips sicherstellt, werden für eine Produktivsetzung nicht mehr als 10 Minuten benötigt. Das führt dazu, dass es praktisch keinen Tag gibt, an dem nicht eine neue und sei es auch nur geringfügig modifizierte Komponente in die Produktion gebracht wird. Dieses Prinzip der "continous integration" führt bei den Endanwendern zu hoher Akzeptanz, weil sie erkennen, das kleine Verbesserungswünsche sehr zeitnah umgesetzt werden. Das wiederum motiviert die Endanwender neue Ideen einzubringen, denn sie erkennen, dass ihre Ideen auch zeitnah Früchte tragen. Die Funktionalität wird damit iterativ permanent verbessert. Entwickelt wird auf einer gekapselten Entwicklungsumgebung. Die Dokumentation erfolgt so weit wie möglich innerhalb des ETL Tools. Sofern fachliche Zusammenhänge ausführlicher beschrieben werden müssen, wird dafür eine individuell angepasste Version eines open source Wikis benutzt. Nach Abschluss der Entwicklung startet der Entwickler den Staging-Workflow, der seine Objekte in die Test- und ggfs. auch direkt in die Produktionsumgebung transferiert. Dazu wird zwischen major und minor Releases unterschieden. Ca 90% der Stagingprozesse sind minor Releases, d.h. kleinere Modifikationen innerhalb der continous integration. Diese kleinen Releases bedürfen keines aufwendigen Tests in der Qualitäts-Sicherungs-Umgebung (QSU) und können deshalb direkt in 7

8 QSU und Produktion versorgt werden. Nur major Releases mit einer größeren Änderung des Funktionsumfangs werden zunächst ausschließlich in die QSU und von dort, nach erfolgreich abgeschlossenem Systemtest, explizit in die Produktion gestaged. Der Staging Server stellt dabei sicher, dass im Fall von Inkonsistenzen ein Rollback möglich ist. Die jeweiligen Prozesse auf den Servern sind stark automatisiert und können auf "Knopfdruck" ausgeführt werden. Gestützt werden diese Prozesse durch einen standardisierten ETL-Frame, der es ermöglicht, Prozesse ohne Änderungen von einem Environment in das nächste zu promovieren. Im Rahmen der Umsetzung sowie dem Test arbeiten die fachlich Verantwortlichen eng mit dem BI-Team zusammen. Der Interaktionsgrad ermöglicht die Reduktion von Formalismen, die den Produktivsetzungsprozess i.d.r. stark blockieren. 4 Beschreibung der Maßnahmen zur Erhöhung der BI-Agilität sowie deren Einfluss auf die verschiedenen BI-Ebenen 4.1 Prinzipien Die auszugestaltende BI Plattform wurde wesentlich durch die Agilitätsanforderungen geprägt. Die größte Herausforderung war es, alte Zöpfe abzuschneiden und neue Organisations- und Prozessmodelle zu finden, die der spezifischen Situation gerecht werden. Es musste "neu gedacht" werden. Dabei war es insbesondere wichtig, trotz der Agilitätsanforderungen eine strenge Architektur, Entwicklungs-Leitlinien und Prozessdefinitionen zu finden. Agilität muss in einem jederzeit qualitätsgesicherten Umfeld stattfinden und ist kein Freibrief für Schnellschüsse und Wildwuchs. So war die Standardisierung der Architektur und der Prozesse, neben den komplexen fachlichen Anforderungen, eine der großen Herausforderungen. Wesentliche Prinzipien, die es einzuhalten galt waren: - schnellstmögliche Schaffung von Nutzen, durch Sicherstellung von kurzen Entwicklungs- und Produktivsetzungszyklen (time-to-market). - Schaffung neuer organisatorischer Strukturen zu Sicherstellung der Agilität, durch Verlagerung der Entwicklung in den Fachbereich und Neuregelung der Zusammenarbeit mit der IT. - BI Architektur und Abläufe müssen so standardisiert und automatisiert werden, dass agile Arbeitsweisen unterstützt werden. Die Einhaltung der geschaffenen Standards liegt dabei in der Verantwortung des Fachbereichs und erfordert ein hohes Maß an Disziplin aller Beteiligten. - Schaffung eines interdisziplinären Teams bestehend aus fachlich und technisch zuständigen Mitgliedern. Die enge Zusammenarbeit in allen Phasen der Entwicklung ermöglichte den Verzicht auf klassische Formalismen und reduziert den Aufwand erheblich. - Grad der Agilität hängt von Umfang und Zeitkritikalität der Änderung ab. Der Demandmanagementprozess ist diesbezüglich so anzupassen, dass schnellstmöglich Anforderungen erfasst, bewertet und klassifiziert werden können. 4.2 Vorgehensmodelle Im Rahmen der Basisimplementierung wurde ein klassisches lineares phasenorientiertes Vorgehensmodell eingesetzt. Im Rahmen der Weiterentwicklung wird kein spezielles Vorgehensmodell angewendet, allerdings sind viele Ideen der Continous Integration eingeflossen ("kein Tag ohne ein neues Release"). Die agile Entwicklung ist durch die Aufstellung eines eigenständigen Teams (Information Management) sichergestellt; die unmittelbare räumliche Nähe zu den Stakeholdern ermöglicht eine unkomplizierte Zusammenarbeit, besseres Verständnis füreinander und eine viel höhere Identifikation aller Beteiligten mit dem Ergebnis. 4.3 Methoden Die Arbeitsweisen im Rahmen der Entwicklung entsprechen am ehesten den Konzepten des Rapid Application Development, gestützt auf strenge Konventionen. Das System wird kontinuierlich weiterentwickelt. Auf die Erstellung von umfangreichen technischen Feinkonzepten wird bewusst verzichtet. Die Änderungen werden unter den BI-Experten abgestimmt und umgesetzt. Hier kommen Methoden wie z.b. Pair Programming zum Einsatz. 8

9 Das evolutionäre Vorgehen stellt dabei sicher, dass zu jeder Zeit neue Anforderungen und Prioritäten im Prozess Berücksichtigung finden. 4.4 Technologie Als ETL-Tool wurde das SAS DI Studio eingeführt. Neben den realisierten kurzen Entwicklungszeiten, überzeugte das Tool durch die zentrale Verwaltung aller Data Warehouse Elemente über das Metadaten Repository. Darüber hinaus gestaltet sich die Anbindung der unterschiedlichen Datenquellen als problemlos und äußerst transparent. Wichtigstes Ziel der Einführung des Tools war es, die bisherige Programmierung einzelner SAS Prozeduren durch einen einheitlichen, transparenten Entwicklungsprozess mit integriertem Metadatenmanagement zu ersetzen. Da das Tool ein zentrales Daten-Repository bereitstellt, liefert die Entwicklungsumgebung eine genaue und nachvollziehbare Dokumentation sämtlicher ETL-Prozesse. Wenn beispielsweise ein Element verändert wird, lassen sich Auswirkungen auf andere Einträge feststellen so können Kollisionen von vornherein ausgeschlossen werden. Beim Aufbau des Core Data Warehouse und der Data Marts profitiert die Fachabteilung insbesondere von der Möglichkeit, die Extraktions-, Transformations- und Ladeschritte grafisch zu modellieren, ohne programmieren zu müssen. Falls dies dennoch einmal erforderlich sein sollte, können Anwender auch selbst geschriebenen Code einfügen. Für die Entwicklungsumgebung wurde ein Framework für das komplette Datei-, Job- und Fehlerhandling integriert, das die Jobablaufsteuerung der SAS Prozesse standardisiert (etlworks for SAS der Firma INFORMATION WORKS). Das Framework bietet eine strukturierte Parametrisierbarkeit der Abläufe durch mehrstufige Konfigurationsdateien sowohl auf globaler als auch auf jobspezifischer Ebene. Standardisierungen für Pre-Processing, Post-Processing und Status Code Handling ( Job erfolgreich, Fehler, Fehlertypen etc.) erleichtern den Anwendern ebenso die Arbeit wie ein objektspezifisches Protokoll (Logging), das auf Job- und Transformationsobjektebene flexibel konfiguriert werden kann. Hinzu kommen spezialisierte Transformationsfunktionen z.b. für die Abbildung zu historisierender Dimensionsinformationen (Slowly Changing Dimensions), die in das ETL Tool eingebunden und so einfach über Drag and Drop nutzbar sind. Der tägliche Produktionsprozess mit hunderten von Jobs ist - ebenso wie die detaillierte Überwachung jedes Jobs voll automatisiert. Das Framework überprüft nicht nur, ob ein Job ordnungsgemäß beendet wurde, sondern auch, ob die verarbeiteten Datenmengen sich innerhalb eines Erwartungswertes bewegen. 4.5 Abhängigkeiten der Maßnahmen untereinander Eine wesentliche Herausforderung war die Durchsetzung der Eigenständigkeit des Fachbereiches im Rahmen der Weiterentwicklung und die Regelung der Zusammenarbeit mit der IT. Die Berücksichtigung IT regulatorischer und revisisionstechnischer Anforderungen war dabei sicherzustellen. Dies wirkte sich wesentlich auf die Architektur und Toolentscheidung aus. Zur Sicherstellung einer professionellen Arbeitsweise war es notwendig Architektur- und Entwicklungsstandards zu definieren. Zur Einhaltung dieser Standards ist ein sehr diszipliniertes Team aufzubauen; die Beteiligten müssen den Nutzen dieser Regelstrukturen verinnerlichen. Die Zusammenarbeit mit den Stakeholdern basiert auf hohem Vertrauen und engster Zusammenarbeit. 9

10 5 Erfahrungen und Erfolgsfaktoren 5.1 Realisierter Nutzen und bewirkte Veränderungen Der angestrebt Nutzen gemäß Kapitel 2.3 wurde zu 100 Prozent erfüllt. Das System befindet sich seit 2005 im Einsatz und wird seit dem kontinuierlich weiterentwickelt. Die Tragfähigkeit agiler BI Infrastrukturen wurde in vollem Umfang bestätigt. Der gewählte Ansatz erweist sich als Langzeit-stabil: auch in 2013 (und wohl auch darüber hinaus) wird das Setup beibehalten. Der innovative Ansatz wurde im Jahr 2006 mit dem Gartner Business Intelligence Excellence Award ausgezeichnet. In einer Toolkit Case Study von 2007 spricht Gartner von einer "worldclass business intelligence" Reflexion der Barrieren und Erfolgsfaktoren Die höchste Barriere war das Überwinden klassischer Denk- und Organisationsstrukturen. Es bestand die Chance relativ "frei" über neue Lösungsansätze nachzudenken, sich mit verschiedenen Methoden zu beschäftigen, um sich aus den besten Ideen einen eigenen, passgenauen Lösungsansatz zu definieren. Darüber hinaus erkannte das Team das Potential, das in den modernen BI-Tools steckt und wollte es nutzen. Der wichtigste Erfolgsfaktor war sicher ein ganzheitliches Denken unter Einbeziehung aller Aspekte (Organisation, Prozess, Technologie) zur Etablierung einer erfolgreichen agilen BI. So wurden neben den technischen, methodischen und infrastrukturellen Aspekten die organisatorischen Maßnahmen gleich zu Beginn vereinbart und damit der Projekterfolg sichergestellt. 5.3 Lessons Learned In der Nachbetrachtung lässt sich feststellen, dass es möglich und erwiesen ist, tragfähige agile BI Infrastrukturen zu realisieren, die über lange Zeit einen hohen Nutzen gewährleisten. Zur Sicherstellung des Erfolgs war es schon damals notwendig, alle Aspekte agiler BI (Technologie, Architektur, Methoden, Prozesse und Organisation) zu berücksichtigen. Darüber hinaus ist die Abschaffung von Formalismen nicht gleichzusetzen mit chaotischer Entwicklung. Das seit 2005 kontinuierlich, durch den Fachbereich weiterentwickelte System, besteht regelmäßig das Auditing durch die IT Revision und erfüllt alle Anforderung an Verfügbarkeit, Verbindlichkeit und Vertraulichkeit von Daten sowie der Nachvollziehbarkeit und Transparenz von Prozessen. Das Augenmerk liegt mehr auf der engen und vertrauensvollen Zusammenarbeit aller Beteiligten mit dem Bewusstsein gemeinsam einen hohen Nutzen für das Unternehmen zu generieren. 2 Gartner Toolkit Case Study: Unicredit Leverages BI to Create a New Business Model, ID Number: G , Publication Date: 2 April 2007, Author: Kurt Schlegel 10