Business Intelligence: Strategie und Organisation · Organisatorisches 09.04. Einführung in...

Mercator School of ManagementLehrstuhl für Wirtschaftsinformatik, insb. Business IntelligenceProf. Dr. Peter Chamoni

Business Intelligence: Strategie und OrganisationSommersemester 2019

Organisatorisches

Dozent Prof. Dr. Peter ChamoniMarkus Eßwein

Website http://www.msm.uni-due.de/wi

Informationen und Unterlagenhttps://www.wi.msm.uni-due.de/lehre/lehrveranstaltungen/sommersemester-17/biso-3325

Neben den hier vorliegenden Vorlesungsbeilagen werden im Laufe der Veranstaltungnoch weitere Unterlagen für eine Fallstudie bereitgestellt. Beachten Sie bitte die An-kündigung der Dozenten in der Veranstaltung.

Kontakt

Prof. Dr. Peter Chamoni – Business Intelligence: Strategie und Organisation – Sommersemester 2019 2

Organisatorisches

09.04. Einführung in Business IntelligenceGrundlagen von (BI-)Strategie

16.04. Entwicklung einer BI-StrategieUnterstützung einer BI-Strategie durch ein BICC

23.04. Organisation und Entwicklung eines BICCBICC-Betrieb und BICC-Controlling

30.04. DatenqualitätFallstudie

07.05. Gastvortrag KPMG „Turning Data into Value“

14.05. BI-ProjektmanagementZusammenfassung

Prüfung Montag, 27.05.2019, 08.30 UhrBitte achten Sie auf die Bekanntmachungen des Prüfungsamtes, insb. in Bezug auf die Anmeldefristen.

Zeitplan (voraussichtlich)


Organisatorisches

Gansor, T.; Totok, A.; Stock, S.: Von der Strategie zum Business Intelligence Competency Center (BICC), München, 2010

• UB Duisburg: PZY42400 (29 Exemplare)

• UB Essen: PZY42400 (1 Exemplar)

Die Vorlesungsunterlagen bieten eine Übersicht über die Schwerpunkte der Veranstaltung. Es sind dennoch Präsentationsunterlagen. Sie dienen der Unterstützung der Vorlesung, nicht dem Ersatz eines Skripts oder der Lektüre der Literatur.

Literatur


Organisatorisches

Hauptliteratur Gansor, Tom/Totok, Andreas/Stock, Steffen (2010): Von der Strategie zum Business Intelligence Competency Center (BICC). München:

Hanser. Gansor, Tom/Totok, Andreas (2015): Von der Strategie zum Business Intelligence Competency Center (BICC), 2. Aufl. Heidelberg: dpunkt.

Ergänzende Literatur (Grundlagen) Apel, Detlef (2010): Datenqualität erfolgreich steuern, 2. Aufl. München: Hanser. Chamoni, Peter/Gluchowski, Peter (Hrsg.) (2010): Analytische Informationssysteme, 4. Aufl. Berlin, Heidelberg: Springer. Kemper, Hans-Georg/Baars, Henning/Mehanna, Walid (2010): Business Intelligence - Grundlagen und praktische Anwendungen, 3. Aufl.

Wiesbaden: Vieweg+Teubner.

Ergänzende Literatur (Weiterführendes) Eveleens, J. Laurenz/Verhoef, Chris (2010): The Rise and Fall of the Chaos Report Figures. In: IEEE Software, 27 (1): 30–36. URL:

http://www.math.vu.nl/~x/the_rise_and_fall_of_the_chaos_report_figures.pdf Gansor, Tom/Totok, Andreas (2014): BICC Update 2014: Strategie, Rollen, Organisation und Umsetzung. URL:

www.sigs.de/download/tdwi_2014_muc/files/W1P-1-Gansor.pdf. Gluchowski, Peter (2009): Ansatzpunkte zur Gestaltung einer Business Intelligence-Strategie. In: Götze, Uwe/Lang, Rainhart (Hrsg.):

Strategisches Management zwischen Globalisierung und Regionalisierung: Gabler: 387-402. URL: http://link.springer.com/chapter/10.1007%2F978-3-8349-8067-0_17.

Hanser, Eckhart (2010): Agile Prozesse: Von XP über Scrum bis MAP. Berlin, Heidelberg: Springer. Johannsen, Wolfgang/Goeken, Matthias (2006): IT-Governance – neue Aufgaben des IT-Managements. In: HMD - Praxis der

Wirtschaftsinformatik (250): 7–20. Schlegel, Kurt (2014): Hype Cycle for Business Intelligence and Analytics, 2014, G00262070. URL:

https://www.gartner.com/doc/2813223/hype-cycle-business-intelligence-analytics Unger, Carsten/Kemper, Hans-Georg (2008): Organisatorische Rahmenbedingungen der Entwicklung und des Betriebs von Business

Intelligence. In: Proceedings Multikonferenz Wirtschaftsinformatik (MKWI 2008): 37–38. URL: http://ibis.in.tum.de/mkwi08/04_Business_Intelligence/03_Unger.pdf.

Literaturliste


Agenda

1 Einführung in Business Intelligence

2 Grundlagen von (BI-)Strategie

3 Entwicklung einer BI-Strategie

4 Unterstützung einer BI-Strategie durch ein BICC

5 Organisation und Entwicklung eines BICC

6 BICC-Betrieb und BICC-Controlling

7 BI-Projektmanagement

8 Datenqualität


Agenda

1 Einführung in Business Intelligence• 1.1 Begriffsbestimmung BI• 1.2 Data-Warehouse-Systeme• 1.3 Präsentation und Analyse• 1.4 On-Line Analytical Processing (OLAP) • 1.5 Data Mining• 1.6 Reifegradmodelle

2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität


1.1 Begriffsbestimmung BI

Gesamtheit aller Werkzeuge und Anwendungen mitentscheidungsunterstützendem Charakter, die zur besseren Einsicht in das eigene Geschäft und damit zum besseren Verständnis in die Mechanismen relevanter Wirkungsketten dienen

Begriffliche Klammer, die eine Vielzahl unterschiedlicher Ansätze zur Analyse geschäftsrelevanter Daten zu bündeln versucht (kein neues Konzept / Produkt)

Definition


WeitesBI-Verständnis

WeitesBI-Verständnis

Analyseorientiertes BI-Verständnis

Analyseorientiertes BI-VerständnisDaten-

bereit-stellung

Daten-auswertung

AnwendungTechnik


Facetten der BI

EngesBI-Verständnis

EngesBI-Verständnis

ETLData Warehouse

Data / Text Mining Kennzahlen /

Balanced Scorecards

Standard-Reporting

Ad-Hoc-Reporting

MIS / EIS / DSSOLAP

PortaleIntelligente

Agenten

Planung / Konsolidierung

Analytisches CRM

Prozess-Schwerpunkt

Orientierung


Corporate Performance Management (CPM) Business Intelligence (BI)

Methoden, Kennzahlen, Prozesse und Systeme, um die Leistung des Unternehmens zu messen und zu steuern (Gartner Group 2002)

Im Vordergrund steht in beiden Fällen die betriebswirtschaftliche Anwendung und nicht etwa ein IT-System


Begriffsabgrenzung

Top-Down-Ansatz

Analytischer Prozess, der Unternehmens- und Wettbewerbs-daten in handlungsgerechtes Wissen für die Unternehmenssteuerung überführt

Bottom-Up-Ansatz


purchase production stock

EIS

DSS

MIS

Executive Information System

Decision Support System

ManagementInformationSystem

1990

1980

1970


Historische Entwicklung (I)


MIS MIS als automatischer Entscheidungs-generator

Datenqualität = Entscheidungsqualität

Informationsvollstän-digkeit durch IuK-Technik

Informationsbedarf a priori bestimmbar

EUS / DSSEntscheidungsvor-bereitung durch Fachspezialisten

Datenbankorientierung

Konzentration auf internes Berichtswesen

Komplexe Entscheidungsmodelle

EIS / FISEntscheidungsunter-stützend

Information auf Knopfdruck

Konzentration auf TOP-Management

Interne und externe Daten werden einbezogen

DW / OLAPEntscheidungsunter-stützend

Vorstrukturiert und interaktiv

Information„for everybody“

Vielfältige Datenquellen

Vielfältige Analysemöglichkeiten

Business Intelligence

E-Intelligence

Strategische Anwendungen

Analysecockpits

Verknüpfung mit Knowlegde-Management

CPM

1970 1980 19901960 2000

Unt

erst

ützu

ngsn

ivea

u1.1 Begriffsbestimmung BI

Historische Entwicklung (II)



Wachstum und Berufsperspektiven im Bereich BI


www.barc.de

Agenda




1.2 Data-Warehouse-Systeme

Unternehmensweites Konzept

Einheitliche und konsistente Datenbasis zur Entscheidungsunterstützung

Getrennt von den operativen Systemen

“A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions.”

[Inmon, 1993]

Data Warehouse (DW)



subject-oriented

• Ausrichtung an inhaltlichen Themenschwerpunkten (Dimensionen)

• Beispiel: Kunden, Regionen, Produkte

integrated

• Vereinheitlichung der Daten aus den operativen Systemen

• Benennung, Skalierung und Kodierung

Data Warehouse – Eigenschaften (I)



nonvolatile

• Dauerhaftigkeit, Stabilität der Daten

• Bereitstellung von Zeitreihendaten über längere Zeiträume

time-variant

• Zeitorientierung der Informationen

• Aktualität der Daten

• Schnappschuss des Unternehmensgeschehens

• Zeitbezug:

• Bestandsgrößen – Datumsangaben

• Bewegungsgrößen – Zeitraumangaben

Data Warehouse – Eigenschaften (II)



Architektur eines Data-Warehouse-Systems



ETL-Prozess



Charakteristika Operative Systeme Data WarehouseÄnderungen sehr viele, kleine Transaktionen nur durch Ladevorgänge

Zugriffsform lesend, schreibend lesend

DB-Größe Gigabytes Gigabytes bis Terabytes

Aktualität jederzeit aktuell historisch

Dateninhalte prozess-orientiert nach Aufgabenbereich

Datenstrukturen redundanzfrei mit Redundanzen

Nutzungsintensität gleichbleibend schwankend

Abfragen statisch, vorhersehbar dynamisch

Daten-Quellen intern intern und extern

Charakteristika von operativen Systemen und Data-Warehouse-Lösungen



Zentrale Data-Warehouse-Architektur

[Sinz/Ulbrich-vom Ende]



Unabhängige Data Marts




Hub-and-Spoke-Architektur



Agenda




1.3 Präsentation und Analyse

Benutzerprofile und Zielgruppen

ReportingInformations- Konsumenten

Statisches Reporting, einschließlich OLAP-Reporting

Informations-VerwenderParameterge-

steuerte Berichte

5-10%

15-25%

65-80%

Analyse

niedrig

Erforderliche Trainingsinvestition

und Kosten&

Flexibilität und Umfang der Systeme

hoch

AnalystenAd-Hoc-Queries


Operativ

Taktisch

Strategisch

BerichtswesenAnalysePlanung

Scorecard-Lösungen

Activity Monitoring

Prozessanalyse

Management Cockpit

Data Mining Tools

UnternehmensplanungOLAP

Standard ReportingBudgetierungs-

werkzeuge

Tabellenkalkulation


Betriebswirtschaftliche Anwendungsszenarien - Funktionalität



Ad-hoc-Abfragen



Einbindung in Tabellenkalkulationen



Standard-Reporting (I)



Standard-Reporting (II)


Agenda




1.4 On-Line Analytical Processing (OLAP)

Interaktive, multidimensionale Analysen

Intuitive Benutzeroberfläche

Definition der OLAP-Fähigkeit von Informationssystemen z.B. durch

• 12 Regeln von Edgar F. Codd

• FASMI (Fast Analysis of Shared Multidimensional Information)

Standard-Anforderungen• Analyse betriebswirtschaftlicher Kennzahlen (z. B. Umsatz, Kosten) entlang

verschiedener Dimensionen (z. B. Kunde, Produkt, Zeit)

• Stabile Antwortzeiten

• Mehrbenutzerunterstützung

• Intuitive Datenmanipulation

• Flexibles Berichtswesen

On-Line Analytical Processing (OLAP)



Darstellung multidimensionaler Datenstrukturen

[Hansen/Neumann (2005), S. 818 f.]



Die Navigation in multi-dimensionalen Datenstrukturen erfolgt auf Basis mehrerer Operationen. Gängig sind dabei unter anderem:

• Slice

• Rotation

• Drill-Down

• Roll-Up

OLAP (I)

45 60 56

15 54 80

23 40 45

REGIONPRODUKT



SLICE: Herausschneiden einzelner Scheiben, Schichten oder kleiner Würfel aus dem Datenraum

OLAP (II)

Reg

ion

Produkt

Regionale Sichtz.B. Gebietsleiter

Reg

ion

Produkt alle Produkte

gesamter Zeitraum

eine Region (Filter)

Produktsichtz.B. Produktmanager

alle Regionen

gesamter Zeitraum

ein Produkt (Filter)

Ad-hoc-Sichtz.B. Analyst

ein Produkt (Filter)

ein Monat (Filter)

eine Region (Filter)

Reg

ion

Produkt



Drill-Down: Untersuchen der Daten in einem feineren Detaillierungsgrad innerhalb der Hierarchie einer Dimension: Untersuchen von Detaildaten

OLAP (III)

Deutschland

Europa

Hessen



Roll-Up: Untersuchen der Daten in einem gröberen Detaillierungsgrad innerhalb der Hierarchie einer Dimension: Analyse aggregierter Werte

OLAP (IV)

Deutschland

Europa

Hessen



Beispiel Darstellung als Pivot-Tabelle (I)


Zweidimensionale Darstellung von „Zeit“ (Spalten) und „Kunde“ (Zeilen)


Beispiel Darstellung als Pivot-Tabelle (II)


Pivoting: „Zeit“ (Spalten Zeilen) und „Kunde“ (Zeilen Spalten)


Beispiel Darstellung als Pivot-Tabelle (I)


Slice: „Kunden“ (Nur „Bayern“) Drill-down: „Kunden“ (Bundesland Stadt Kundenname)

Agenda




1.5 Data Mining

Knowledge Discovery in Databases (KDD) describes the “.. non-trivial process ofidentifying valid, novel, potentially useful, and ultimately understandable patterns in data ..” [Fayyad, et al. 1996]

Knowledge Discovery in Databases (KDD) und der KDD-Prozess

DatenZieldaten-bestand

Auswahl

Vorverarbeitung

Transformation

Data Mining

WissenInterpretation

VorverarbeiteteDaten

Transformierte Daten

Muster


1.5 Data Mining

Datenbank-basierte Verfahren

• die unter Verwendung von

• Methoden der Statistik und

• Methoden der Künstlichen Intelligenz (KI)

• selbständig

• Annahmen generieren ("machine learning"),

• überprüfen und

• entsprechende Ergebnisse präsentieren.

Data Mining


1.5 Data Mining

Klassifikation

• Zuordnung in vordefinierte Klassen

Clustering

• Einteilung in Klassen gemäß einem Ähnlichkeitsmaß

Entdecken von Abhängigkeiten

• Abhängigkeitsbeziehungen von Attributausprägungen

Zielsetzungen des Data Mining (I)

[Hansen/Neumann (2005), S. 822 f.]

A B


Agenda




1.6 Reifegradmodelle

„Reifegradmodelle messen die Qualität, mit der Softwareentwicklungen in einer bestimmten Organisation bzw. deren Softwareentwicklungsbereich betrieben werden und dienen insofern zur Beschreibung von Lebenszyklen und zur Beurteilung von Qualitätsstandards bei Informationssystemen.“

Übertragen auf Business Intelligence werden Reifegradmodelle eingesetzt, um die Leistungsfähigkeit der Organisation in Bezug auf die Erfüllung der notwendigen Aufgaben zu bewerten.

Im einfachsten Fall existieren abgegrenzte, unterschiedliche Stufen (Reifegrade), die ein Unternehmen „erreichen“ kann und somit eine Rückmeldung zu seinem aktuellen Fortschritt in Bezug auf BI erhält.

Definition und Nutzen

[Schulze/Dittmar in Chamoni/Gluchowski (2006)]


[Brobst]


Beispiel: Information Evolution in Data Warehousing


[http://visualbablog.com/2013/08/29/visualisierung-goes-mobile-bi-herausforderungen-und-chancen/]


Beispiel: TDWI-Reifegradmodell (Eckerson, 2004)


Unternehmensbedeutung IS

Fachliche Validität

Unterstützung von

Analyseprozessen

Unterstützung von Planungs- undSteuerungsprozessen

Flexibilität des SystementwurfsQualität der IT-Lösung

Standardisierung der

Komponenten

Wirtschaftlichkeits-

betrachtung

Institutionalisierung / Formalisierung

systembezogener Prozesse

[Business Intelligence-Studie biMA® 2004 und 2006, Steria Mummert Consulting]


Untersuchungsfelder des Reifegrades


Fachlichkeit

Architektur/Technologie

Organisation


Stufe 1: Vordefiniertes Berichtswesen

Stufe 2: Fachbereichslösungen

Stufe 3: Unternehmensweite Lösungen

Stufe 4: Erweiterte Entscheidungsunterstützung

Stufe 5: Aktives Wissensmanagement

Reifegradstufen (biMM ®)

12

34

5

Business Intelligence-Studie biMA® 2004 und 2006, Steria Mummert Consulting



Stufe 2: BI pro Fachbereich

Stufe 3: Unternehmensweite BI


Stufe 5: Aktives Wissens-management

Inhalte werden z. T. redundant berichtet

Keine weiter-gehende Analyse-möglichkeit

Fachbereichs-bezogene Auswertungen

Keine einheitliche Semantik

Insellösungen

Ad-hoc-Analyse-möglichkeiten

Abteilungsweit gültige Semantik

Integration verschiedener Fachbereiche

Vereinheitlichtes Berichtswesen

Unternehmensweit homogenisierte Semantik

Einfache Forecast-Berechnungen

Integration externer Daten

Prozessunter-stützung

Closed-loop-Umsetzung

Erweiterte Analysemethoden (z. B. Data Mining)

Trendberechnung

Bildung komplexer Szenarien

Alternativenrechnungen

Zeitnahe Analysen bis hin zum Realtime-Betrieb

Adaptives Lernen

Enge Kopplung von quantitativen und qualitativen Wissensdomänen

Benutzerrollenkonzepte

Aktive Entscheidungs-unterstützung



Reifegradstufen (biMM ®) Fachlichkeit



Reifegradstufen (biMM ®) Technik






Statische, parametergesteuerte Berichte (häufig papiergebunden)

Einfache Darstellung (z. B. Listendruck)

Lokale Layoutstandards

Einbettung in operative Informationssysteme

OLAP-Naviga-tionsfunktionalität

Zeitreihen analysen

Daten historisierung

Automatisierung von Extraktions-, Transformations-und Ladeprozes sen

Hub & Spoke-Architektur

Metadatenmanagement

Übergreifende Normen und Standards

Hohe Verfüg barkeit

Web-Oberflächen

Automatisierte Integration externer Daten

Einbeziehung semi-strukturierter Daten

Data Mining

Planungs- und Simulationstools

Workflow-Systeme zur Unterstützung komplexer Pro-zesse

Portaltechnologien

Realtime-fähige Infrastruktur

Aktive Kompo-nenten (Push-Technologie)

Integration un-strukturierter Daten

Agentenbasierte Informations-sammlung

Verschmelzung operativer und dispositiver IV-Systeme





Reifegradstufen (biMM ®) Organisation






Keine Transparenz von Kosten und Nutzen

Manuelle, wenig organisierte Prozesse

Keine übergreifende Qualitätssicherung

Lange Informationswege

Cost Center mitProjektbudget

BI-Team mit undifferenzierter Themengesamtverantwortung

„Einmal“-Initiativen ohne Programm-Management

Unternehmensweite BI-Strategie

Kosten-/Nutzenbetrachtung pro BI-Teilprojekt

Trennung Entwicklung und Betrieb

Formales Evolutionsmanagement

Supporteinrichtungen

Beanspruchungsgerechte Kostenumlage

BI-Prozesse durchgängig institutionalisiert

Prozessausrich tung auf bedarfsorientiertes Informations- und Analyseangebot

Durchgängige Integration aller Prozesse

Betriebsführung wie bei operativen Systemen

BI als unternehmenskritischesThema

Akzeptanz auf allen Ebenen und in allen Bereichen


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie

• 2.1 Unternehmensstrategie und Informationsbedarf• 2.2 Definition und Motivation für eine BI-Strategie• 2.3 Konzeptioneller Rahmen einer BI-Strategie

3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität


2.1 Unternehmensstrategie und Informationsbedarf

Globalziele

Einzelziele

Ziele einer Unternehmung (Ausschnitt)

Quantifizierbar

• Wachstum

• Gewinn

• Rentabilität

Nicht Quantifizierbar

• Unabhängigkeit

• Risikominimierung

• Flexibilität

Markt

• Steigerung der Marktanteile

• Erschließung neuer Märkte

Finanzen

• Sicherung der Liquidität

• Minimierung des Fremdkapitals

Allgemein

• Sicherung der Arbeitsplätze

• Erhaltung des Qualitätsniveaus



Ursprünglich: Die Kunst der Heerführung (stratos = Heer, agein = führen)

„Die Strategie ist der Gebrauch des Gefechts zum Zweck des Krieges; sie mußalso dem ganzen kriegerischen Akt ein Ziel setzen.“ (Claus von Clausewitz, 1832)

„... eine in sich stimmige Anordnung von Aktivitäten, die ein Unternehmen von seinen Konkurrenten unterscheidet ...“ (Porter)

„Strategie ist die Kunst und die Wissenschaft, alle Kräfte eines Unternehmens so zu entwickeln und einzusetzen, dass ein möglichst profitables, langfristiges Überleben gesichert wird.“

(Simon et al.)

Strategiedefinitionen



Bietet eine Kompassfunktion Hat eine langfristige und systematische Ausrichtung Liefert qualitative Ergebnisse: Visionen und Missionen Dient der Erhaltung und Vergrößerung von Wettbewerbsvorteilen und

Synergieeffekten Fördert die Entwicklung von Ressourcen und Fähigkeiten Betrifft alle Stufen der Führungshierarchie

Die Vision eines Unternehmens soll durch die Strategie erreicht werden. Sie ist:• Richtungsweisend• Ansporn gebend• Plausibel• Prägnant

Merkmale einer Unternehmensstrategie

[Coenenberg/Salfeld, 2007]



Visionen bilden das Leitbild einer Strategie. Slogans sind Werbebotschaften, die einprägsam sind, aber für sich genommen nicht das „wahre Ziel“, das eine Unternehmung anstrebt, abbilden können.

Visionen und Slogans

[Coenenberg/Salfeld, 2007]

Visionen Slogans

BoeingBecome the dominant player in commercialaircraft and bring the world into the jet age. (1950er Jahre)

If It's Not Boeing, I'm Not Going.

Nike Crush adidas. (1960er Jahre) Just do it.

General Electric Number 1 or 2 in the industry.(1980er Jahre)

We bring good things to life.

VolkswagenIn der Volkswagen-Welt wollen wir die in der Qualität besten und attraktivsten Autos entwickeln, kostengünstig herstellen und erfolgreich verkaufen. (1999)

Das Auto.



Entwicklung des strategischen Managements


[http://4managers.de/management/themen/strategisches-management/]


Typen von Wettbewerbsstrategien

Typ I

Kosten-führerschaft

Typ II

Differenzierung

Typ IIIa

Kosten-schwerpunkt

Typ IIIb

Differenzierungs-schwerpunkt

Wettbewerbsvorteile

Niedrige Kosten Differenzierung

Wet

tbew

erbs

feld

enge

sw

eite

s



Informationsfunktion im strategischen Gleichgewicht/Ungleichgewicht

Strategische Vergeudung

Strategisches Gleichgewicht

Strategische Überdehnung

Strategische Verschwendung

Wirksamkeitder Informationsstruktur

gering hoch

Wirt

scha

ftlic

hkei

t de

r Inf

orm

atio

nsst

rukt

urge

ring

hoch

[Weck, 2003]



Bedeutung von IS für zwei Anbieter mit unterschiedlicher Strategie


Niedrig-Preis-Anbieter Technologieführer

Strategie: Kostenführerschaft

Strategische Ziele

Material-kosten-senkung

durch effizientere

Produktions-planung

Kapital-kosten-senkung

durch reduzierte

Lager-bestände

Gemein-kosten-

senkung im Verwaltungs-

bereich

Einsatz eines PPS-

Systems

Rechner-gestützte

Lager-haltung

BIKOS-Einsatz

Strategie: Differenzierung

Strategische Ziele

Schnelleres Erkennen von Markt-verände-rungen

Erhöhung des Produkt-

nutzens durch

Informations-komponente

Verkürzung der

Produktent-wicklungs-

zeiten

Zugriff auf externe

Marketing-daten

IKS zur Fern-

diagnoseCAD-Einsatz

Agenda





2.2 Definition und Motivation für eine BI-Strategie

Die Business-Intelligence-Strategie ist die zukunftsorientierte Gesamtplanungder Business-Intelligence-Initiativen und Business-Intelligence-Projekte abgeleitet aus der Geschäftsstrategie eines Unternehmens.

Bestandteile der BI-Strategie sind (u.a.)

• Vision und strategische Ziele

• BI-Projekt-Roadmap

• BI-Initiativen und -Maßnahmensteuerung

• Planung und Umsetzung der BI-Organisation

Definition von BI-Strategie

[nach Gansor et al., 2010]


Strategie

Planung

Planung

Budgetierung

Konsolidierung

ÜberwachungUrsachen-analyse

BerichtswesenPrognose

Ist-Wert-Erfassung

Verbuchung

LaufendeGeschäfts-prozesse

ReportingErfahrungen

Feedback

Erkenntnis

Zielfindung

Motivation I: Unterstützung des Regelkreises der Unternehmenssteuerung

BI-Fokus



Motivation II: Unklare Datenherkunft und -qualität

Einkauf Produktion Vertrieb Einkauf 2 Vertrieb 2

Intern analytisch

Intern operativ

Extern

AnalytischeFragestellung

???





Motivation III: Der Systemzoo

Einkauf Vertrieb Rechnungs-wesen

Vertrieb 2

Datawarehousing

Standardreporting

Ad-Hoc-Reporting

Advanced Analytics

Datenintegration

??




Projektbeispiel: Insellösungen dominieren im Controlling

Produktion Vertrieb F&E Personal Einkauf

Extrakte/ Transformationen

Extrakte/ Transformationen

System 1 System 2 System 3Extrakte /

TransformationenExtrakte /

Transformationen

Extrakte / Transformationen




System 4Extrakte /




Transformationen System 5

System 6Extrakte /


TransformationenSystem 7 System 7

Personal-controlling

Vertriebs-controlling

Konzern-controlling

Produktions-controlling

F&E-controlling

Einkaufs-controlling



Einkauf Rechnungs-wesen

Vertrieb Fachabteilung

IT BetriebIT Entwicklung


Motivation IV: Unklare oder fehlende Organisation für BI-ProjekteIT

Fach

anw

ende

r


Leiter Mitarbeiter



Motivation V: Unklare oder fehlende Verantwortlichkeiten und Verantwortliche

(BI-)Geschäftsprozesse Daten Projekte Lösungsentwicklung Standards Infrastruktur Standardsoftware BI-Architektur BI-Training etc.

Mögliche VerantwortlicheVerantwortlichkeiten


Fachanwender „Orga-Abteilung“ IT-Betrieb IT-Entwicklung (IT-)Einkauf Externe Betreiber Dienstleister, z.B. Berater Hersteller



Motivation VI: Wertverlust durch lange Reaktionszeiten

Zeit

Informationswert

Ereignis

Datenspeicherung

InformationsbereitstellungEntscheidung, Maßnahme

Reaktionszeit


Wertverlust



Praxisbeispiel eines Informationsflusses

Lokale DatenbankDaten extrahieren

Daten speichern

Daten aufbereiten

Report

Daten speichern

Daten aktualisieren

Quellsystem


Extraktionsblatt

Transformationsblatt

Workflow


Agenda





2.3 Konzeptioneller Rahmen einer BI-Strategie

Perspektiven auf eine BI-Strategie

Fachliche Inhalte

Enterprise

Data Warehouse

Informationsbedarf

Steuerungs-

systematik

Kennzahlen

Integrationsgrad

Rollen

Funktionen

Kompetenzen

Flexibilität

Performance

Komplexität

Standardisierung

Prozesse

Governance

Fachlichkeit


Organisation



Ziele nach verschiedenen Perspektiven

[nach Gansor et al., 2010]Prof. Dr. Peter Chamoni – Business Intelligence: Strategie und Organisation – Sommersemester 2019 75

• Aus Sicht der Anwender formuliert und erkannt

• Von Anwendern oder Stabstellen aufgenommen

• Betrifft Inhalte der Systeme sowie Verbreitungsarten und -wege

Fachliche Ziele

• Oftmals von der IT-Abteilung in den Fokus gerückt

• Sollen die technische Verwertbarkeit der Informationen sicherstellen

• Bilden Integrations- und Standardisierungsbestreben ab

• Betreffen Hardware und Software

Architektonische Ziele

• Betreffen Aufbau- und Ablauforganisation

• Beziehen sich bei einer BI-Strategie auf die langfristige Organisation der BI im Unternehmen, nicht die kurzfristige Projektstruktur

Organisatorische Ziele

• Betreffen oft die Performance der Systeme

• Sind im Gegensatz zu architektonischen Zielen konkret und weniger konzeptionell

• Bieten keine Lösung für die fachlichen Probleme sondern dienen nur zur Formulierung einer geeigneten Systemumgebung

Technologische Ziele


Ziele nach verschiedenen Perspektiven (Beispiele)

[nach Gansor et al., 2010]Prof. Dr. Peter Chamoni – Business Intelligence: Strategie und Organisation – Sommersemester 2019 76

• Verbesserung der Informationsversorgung der Entscheidungsträger

• Entwicklung einer durchgängigen Steuerungssystematik• Verbesserung des Informationsverständnisses• Vermeidung bzw. Abbau von Zahlenfriedhöfen• Stärkere Integration der entscheidungsrelevanten

Informationen• Standardisierung von Berichtslayout und -inhalten• Steigerung der Benutzerakzeptanz• Verbesserung der Datenqualität

Fachliche Ziele

• Aufbau einer Enterprise Data Warehouse Architektur (EDW)

• Schaffung eines fachbereichs- und funktionsübergreifenden Datenmodells für BI

• Vermeidung von unnötigen Insellösungen• Standardisierung der BI-Systeme und Vereinheitlichung• Reduzierung des Softwareportfolios durch Konzentration

weniger Softwareanbieter

Architektonische Ziele

• Verbesserung des Zusammenspiels zwischen Fachbereichen und IT

• Bündelung von Ressourcen und Know-how in einer Einheit

• Effizienzsteigerung im Betrieb von BI-Lösungen• Verkürzung der Entwicklungszyklen• Definition eines Standard-Dienstleistungsportfolios für BI• Outsourcing definierter BI-Leistungen• Standardisierung von Betriebs- und

Entwicklungsprozessen

Organisatorische Ziele

• Verbesserung der Systemperformance• Einführung Hauptspeicher-basierter Analysesysteme• Erweiterung der BI-Systeme für realtime-Anwendungen• Verlagerung von älteren Daten in Nearline Storage

oder Archivierungssysteme• Einsatz von DWH Appliances• Service-orientierte Implementierung ausgewählter BI-

Dienste

Technologische Ziele


Wertkette nach Porter als Geschäftsgrundlage für Informationsbedürfnisse


Unternehmensgesamtplanung

Finanzen

Rechnungswesen

Personal

Gebäudemanagement

FuE Ver-trieb

Be-schaf-fung

Pro-duktion

Ver-sand

Kun-den-ienst

Lagerhaltung

Lagerhaltung

Forschungsowie

Produkt-und Prozess-

entwicklung

Vertrieb Beschaffung Produktion VersandKunden-dienst

Administrations- und Dispositions-systeme

Planungs- und Kontrollsysteme

Finanzen

Rechnungswesen

Personal

Gebäudemanagement

Auftragsdurchlauf

Führungsinformation


Integrierte Informationsverarbeitung

[Mertens 2001]


Kritische Erfolgskennzahlen

(Key Performance Indicators)

Konsolidierung

• Innenumsätze

• Zwischenergebnis

• ....

Operative Kennzahlen

Prozesskennzahlen

Operative Prozesse

Konsolidierung

Konsolidierung


Übertragung der Integrierten Informationsverarbeitung auf einen Konzern



Konsolidierung

• Innenumsätze


• ....

• Konzern• Sparten

• Geschäftsber.• Gesellschaften


Beteiligte, Aufgaben und Kennzahlen auf den Ebenen eines integrierten Konzerninformationssystems


Vorstand

Konzerncontrolling

Geschäftsbereichscontrolling

Einzelcontrolling

Konsolidierung

• Innenumsätze


• ....

Liquiditäts-kennzahlen• Cash• Brutto-

verschuldung• Netto-

verschuldung

GuV/Bilanz-kennzahlen

• Umsatz• EBIT• Investitionen• Forderungen• …

OperativeKennzahlen• Auftrags-

eingang• Prozesskennzahlen

der Ströme• …

BI-S

trate

gie



Referenzarchitektur eines Enterprise Data-Warehouse-Systems

Frontend

Quell-systeme

Integration Layer

Output

Layer

DataStorageLayer

Externe Daten,InternetAdministrations- und Dispositionssysteme

Staging Area

OLAP-Würfel

ClosedLoop

Berichts- und Analysesysteme

Planung und Hochrechnung

ManagementCockpit

OLAP-Analysen

ERP-System

Bereichs-daten

Aggre-gationen

Planung,Forecast

Basisdatenbank(Core Data Warehouse)

ERP-System

PPS-System

…

ODS

ExtraktionTransformationLaden

Ret

rakt

ion

nach Abschluss

Met

adat

enm

anag

emen

t


Auswertungsdatenbank



Abhängigkeit der BI-Strategie von der Unternehmensstruktur

Finanz-holding

• Steuerung vorwiegend nach finanziellen Kennzahlen

• Agenda nach legalen Gesellschaften

• Monatlicher Berichtszyklus

• Lose Koppelung der IT-Systeme – keine Integration

Management-holding

• Meist Agenda nach unterschiedlichen Geschäftsfeldern

• Steuerung nach finanziellen und nicht-finanziellen Kennzahlen

• Legale und Managementstruktur parallel

• Mittlere Integration der IT-Systeme

Stammhaus-konzern

• Mutterunternehmen direkt am Markt tätig

• Relativ homogenes Geschäftsmodell

• Töchter ergänzen Geschäft der Mutter

• Einfluss in das operative Geschäft der Töchter

• Steuerung nach operativen Kennzahlen

• Starke Integration der IT-Systeme




Spannungsfeld bei der Erarbeitung und Umsetzung einer BI-Strategie

Unternehmen

Fachseite

ExterneIT-Dienstleister

IT

BI-Gremienstruktur

BI-Core Team

BI-Organisation

Unternehmen

Fachbereich

ExterneIT-Dienstleister

IT

BI-Organisation

BI-Kernteam

BI-Gremienstruktur


[Dittmar/Ossendoth]

Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie

• 3.1 Vorgehensmodelle• 3.2 Analyse• 3.3 Bewertung• 3.4 Konzept• 3.5 Maßnahmen, Management & Methoden

4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität


Definition Analyse Bewertung Konzeption Maßnahmen

Kontinuierliche Aktualisierung

3.1 Vorgehensmodelle

Kein einheitliches Referenzmodell zur BI-Strategieentwicklung vorhanden

Diverse einzelne Vorgehensmodelle aus der Praxis sind verfügbar

Zur Darstellung eines durchgehenden Entwicklungsprozesses und der zu betrachtenden Aktivitäten wird auf ein generisches, ganzheitliches Entwicklungsmodell Bezug genommen

Phasen der Strategieentwicklung




Reinvention Framework (Bloom 2009)

• Behandelt fachlichen Kontext, analytische Anforderungen, Grobkonzepte für Daten und Architektur, Deltas und Risiken, Programmplanung

• Top down oder bottom up anzuwenden

BI-Strategie-Entwicklungsprozess (biSE) (Trost/Zirkel 2006)

• Orientiert am generischen Strategieentwicklungsprozess

• Ableitung der BI-Strategie aus Geschäftsstrategie, IT-Strategie unter Berücksichtigung einer Ist-Analyse und Reifegradmodellen

cundus Business Intelligence Strategy (cuBISt) (Totok 2006)

• Orientiert am generischen Strategieentwicklungsprozess

• Ableitung der Informationsbedarfe durch eine Top-Down-Priorisierung der Unternehmensziele

Weitere Vorgehensmodelle (I)



Strategie der Informationslogistik (IL-Strategie) (Dinter/Winter 2008)

• Ordnet die Aktivitäten der BI-Strategieenticklung ein, nicht Phasen oder Ziele

• Orientierung an Source (Wer erbringt welche Leistungen?), Deliver (Wie sieht die Schnittstelle von Leistungserbringer zu Abnehmer aus?) und Make (Wie wird die Leistungserzeugung gestaltet hinsichtlich Portfolios und Produktion?)

• Kein Vorgehensmodell im klassischen Sinne

Stufenkonzept zur BI-Strategieentwicklung von BARC (Vierkorn 2008)

• 10-Stufen-Konzept zur Analyse von Ist-Situation und pragmatischen Überführung in die Soll-Situation

• Keine direkte Anlehnung an Geschäfts- oder IT-Strategie

Weitere Vorgehensmodelle (II)



Perspektiven auf eine BI-Strategie

Fachliche Inhalte

Enterprise

Data Warehouse

Informationsbedarf

Steuerungs-

systematik

Kennzahlen

Integrationsgrad

Rollen

Funktionen

Kompetenzen

Flexibilität

Performance

Komplexität

Standardisierung

Prozesse

Governance

Fachlichkeit


Organisation



Vorgehen zur Entwicklung einer BI-Strategie


Organisation

Fachlich-keit

ArchitekturTechnologie

Projektmanagement

Unt

erne

hmen

s-/IT

-Stra

tegi

e

BI-StrategieIs

t-Situ

atio

n &

Anf

orde

rung

BI-R

eife

grad

BI-K

onze

pt

BI-R

oadm

ap


Agenda





3.2 Analyse

Analyse des Unternehmens aus betriebswirtschaftlicher Sicht

Feststellen von Verfahren im Reporting oder in der Planung des Unternehmens

Aufnahme der auswertungsrelevanten Informationsobjekte, z.B.

• Kunden

• Regionen

• Produkte

• …

Ableitung des Rahmens oder der Komponenten für die BI-Strategie aus der Unternehmensstrategie

Fachliche Analyse


3.2 Analyse

Ableitung der Informationsbedarfe aus den Unternehmenszielen

Bereichsziele

Handlungs-

bedarfHandlungs-

bedarf

Bereichsziele

Strategische

Ziele

Bereichsziele

InformationsbedarfeStrategische

Maßnahmen



3.2 Analyse

Die Aufnahme der Unternehmensziele gibt den (priorisierten) Rahmen für die notwendigen Steuerungsinformationen vor.

Aus diesen Unternehmenszielen lassen sich konkrete Handlungen für die Entwicklung einer BI-Strategie ableiten

Zieldokumentation

Unternehmensziele Priorität*

Z1 Der Kunde steht im Mittelpunkt unseres Handelns 5

Z2 Wir wollen in unseren Marktsegmenten unsere Position über die technologische Innovationsführerschaft ausbauen

5

Z3 Wir verfolgen eine internationale Wachstumsstrategie –insbesondere im asiatischen Raum

3

Z4 Wir wollen verstärkt Synergien innerhalb unseres Konzerns nutzen

4

* 5: entscheidend, 4: sehr wichtig, 3: wichtig, 2: relevant, 1: wünschenswert



3.2 Analyse

Ableitung von BI-Strategieelementen aus den Unternehmenszielen

• Schaffung einer Kunden-Ergebnisrechnung auf Konzernebene

• Konzernweite Harmonisierung von Kundennummer, -struktur sowie weiterer Attribute

• Konzernweite Standardisierung der Positionen der Ergebnisrechnung (Umsatz, Erlösschmälerungen, Rabatte, Boni, etc.)

• Verfügbarkeit der BI-Systeme über verschiedene Zeitzonen sicherstellen

• Durchgängige Mehrsprachigkeit der BI-Anwendungen schaffen

• Mehrsprachigkeit der Dateninhalte durch Unicode-Unterstützung gewährleisten

Wachstumsstrategie in Asien

Kunde• Integration von externen Marktvergleichsdaten in

die BI-Systeme

• Unternehmensweit einheitliche Definition von Innovationen

• Definition von Kennzahlen zur Innovationsmessung

• Inhaltliche Abstimmung von Konzern- und Teilkonzernreporting

• Zentral koordinierte BI-Organisation mit dezentralem Key User Konzept

• Technologisch einheitliche BI-Plattform durch Redesign herstellen

Synergien

Marktführerschaft


3.2 Analyse

Aufnahme detaillierter Informationsanforderungen aus einzelnen Unternehmensbereichen

Priorisierung der einzelnen Anforderungen

Darstellung entweder

• Nachfrageorientiert: Aufnahme der Anforderungen und Ableitung der benötigten Kennzahlen, Informationen, etc.

• Angebotsorientiert: Aufnahme der vorhandenen Informationen (in den Systemen) und „Katalogerstellung“ für den Anwender (sehr aufwändig, ggf. „Information overflow“)

Überführung der Ergebnisse in eine Kennzahlen-/Dimensionen-Matrix zur Abbildung der Granularitäten der einzelnen Kennzahlen

Informationsbedarfsanalyse


3.2 Analyse

Informations-bedarf Beschreibung Nutzen

Entschei-dungs-objekt Typ Priorität Aktualität

Auf wand

Verant-wortung

Refe-renz

IB5.1.1

Reklama-tionsquote

Detaillierte Statistik nach Reklamations-gründen pro Produkt

Aufdeckung von Qualitäts-mängeln

Produkt Qualitäts-mana-gement

4 Woche 2 Service-Management

K5.1

IB5.3.1

Kundenprofil Kunden nach Eigenschaften segmentieren und Profile erstellen

Deutliche Steigerung Kundenzu-friedenheitdurch individuelle Ansprache

Kunde CRM 5 Monat 4 Key Account Management

K5.3

IB7.1.1

Profit-Center-Rechnung nach Produkten

Detaillierte Ergebnisrechnung pro PC nach Produkten detaillierbar

Verbesserte Produkt-planung

Produkt Ergebnis-rechnung

3 Woche 4 Profit Center

K7.1

IB7.3.1

Profit-Center-Rechnung nach Vertriebswegen

Ergebnisrechnung pro PC nach Vertriebs wegen detaillierbar

Verbesserte Vertriebs-steuerung

Vertriebs-weg

Ergebnis-rechnung

5 Woche 3 Profit Center

K7.3

Darstellung des Informationsbedarfs


3.2 Analyse

Die Kennzahlen (vertikale Achse) werden den Auswertungsdimensionen (horizontale Achse) gegenübergestellt

Die Kreuzpunkte werden so ausgefüllt, dass erkennbar wird, welche Daten benötigt werden

Kennzahlen-Dimensions-Matrix: Schritt 1


3.2 Analyse

Nicht benötigte Elemente werden zwecks besserer Übersicht aus der Matrix entfernt



3.2 Analyse

Strategisch relevante Kennzahlen oder Kreuzpunkte werden markiert



3.2 Analyse

Alternativ / zusätzlich wird die Verfügbarkeit der Daten markiert

Fehlende Daten zu vorhandenen Informationsbedarfen werden aufgedeckt



3.2 Analyse

Vorteile

• Kompakte Darstellung von vorhandenen Informationen und Informationsbedarfen

• Über- und Unterversorgung mit Daten wird gleichermaßen aufgezeigt

• Nur relevante Kreuzpunkte werden dargestellt, die Granularität wird sichtbar

Nachteile

• Darstellung je einzelnem Bericht nicht zweckmäßig (keine Übersicht)

• Darstellung in einer Gesamtmatrix führt ggf. zu Fehleinschätzungen und ÜberlappungenBeispiel: Strategische Planung benötigt Umsatz auf Landesebene, Operative Planung Umsatz auf Filialebene. Aus der Matrix wird der Unterschied nicht ersichtlich, außer, man splittet die Kennzahl auf zwei Zeilen, dann ist aber die Kennzahl wieder nicht einheitlich („normalisiert“) dargestellt

• Pflegeaufwand beträchtlich

• Übersicht leidet bei großen Anzahlen von Kennzahlen und/oder Dimensionen

Kennzahlen-Dimensions-Matrix: Vor-/Nachteile


3.2 Analyse

Systematische Analyse bestehender Systeme und Strukturen

Einordnung aller vorhandenen Systeme in einheitliches Raster zur Herstellung von Vergleichbarkeit

Nutzung von

• vorhandener Dokumentation, falls einheitlich vorhanden

• neuer Dokumentation, falls vorhandene Dokumentation zu stark schwankende Granularität in der Beschreibung aufweist

Die Verwendung einer Analyse auf „gröberem“ Level ist im Zweifel vorzuziehen, wenn so eine Einheitlichkeit erreicht werden kann

Analyse der Architektur/Technologie


3.2 Analyse

Dimensionen einer Architekturanalyse

Business-Konzepte

Integrations-Ebenen

Abteilung

Konzern

Partner

LieferantKunde

BusinessProzesse

Einkauf

Vertrieb FunktionalitätKomplexität

nahezu

Echtzeit täglichwöchentlich

monatlichjährlich

Business Process Management

Balanced Scorecard/

Strategy MapsKey Performance Indicator

Customer Relationship Management

ReportingAnalyse

Data MiningForecast

Knowledge

Planung

Anzahl und Artder Nutzer

GeographischeAusbreitung

Datenquellen und Datenvolumen

Systeme und Prozesse

Kosten undNutzen

ERP

Data Warehouse

DatenbankenEinzelne

Standorte

Vielzahl von

Standorten

Lizenzen

Entwicklungskosten

Betriebskosten

SLA

hoch niedrig-

AktualitätZyklen

OLAP

Gelegenheits-Nutzer

Power-User

FinanzenControlling

Marketing

ETL

Data MartsHub&Spoke

Datendistributionund -logistik

Verteilte Systeme

Insellösungen

Vernetzte Strukturen


Operativ

Taktisch

Strategisch

BerichtswesenAnalysePlanung

Scorecard-Lösungen

Activity Monitoring

Prozessanalyse

Management Cockpit

Data Mining Tools

UnternehmensplanungOLAP

Standard ReportingBudgetierungs-

werkzeuge

Tabellenkalkulation

3.2 Analyse

Einordnung von Anwendungssystemen in einen Funktionsrahmen


3.2 Analyse

Beispiel: High-Level-Dokumentation einer BI-AnwendungAnwendungsname Three Month Rolling Forecast

Technischer Name PTMRF01Beschreibung Rollierende Drei-Monats-Hochrechnung des Umsatzes für alle Vertriebsgesellschaften weltweit.

Fachlicher Betreiber Global Sales ManagementTechnischer Betreiber IT, Abteilung VertriebssystemeNutzer Sales Directors (ca. 50 Anwender) und Vertriebsinnendienst (ca. 10 Anwender)Aktualität 31.03., 30.06. und 30.09. jedes JahrKomplexität der Anwendung 3 – Mittel (ca. 60 Manntage (MT) einmaliger Entwicklungsaufwand, 10 MT Betriebsaufwand jährlich)

Technologische Basis Applikationsserver: PAPLPLAN02 (Cognos Planning 8.3, Windows Srv 2003 SP2)Datenbankserver: PRDBPLAN01 (Oracle 10.2, Windows Server 2003 SP2)

Eingehende Datenflüsse SAPSD3MFC, NAVSAL3MFCAnmerkung: Ist-Daten aus SAP ERP und Navision

Ausgehende Datenflüsse TMRFC01Anmerkung: Konsolidierte Ergebnisdatei zum Import für das Gruppenreporting

Dateninhalte Kennzahlen: Umsatz (Definition: SALESFC)Dimensionen:Zeit (Jahr, Monat) (Definition: TIMEGL)Vertriebsorganisation (Definition: SALESORGA), Produktgruppe (Definition: PROCUCTGL), Top-10-Kunde (Definition: CUSTGL)

Datenspeicherung 3MRC01, 3MRC02, 3MRC03 Anmerkung: logische Cube-Struktur, physisch abgebildet in Dateiform.

Dokumentenverweise Systemdoku 3MonthRFC.doc, ….


3.2 Analyse

Aufnahme von Aufbauorganisation und Ablauforganisation

Verwendung von gängigen Modellierungsmethoden

• Organigramm

• eEPK

Verknüpfung von fachlichen Prozessen und beteiligten Systemen

Erinnerung: BI-Strategie betrachtet den gesamtheitlichen Aufbau der Informationsversorgung, nicht nur die Systeme!

Analyse der Organisation


Agenda





3.3 Bewertung

Die fachliche Bewertung ist die Auswertung der Informationsbedarfsabdeckung

Die Bewertung erfolgt auf Basis von Formalia (Auswertung von Kennzahlen-/Dimensionsmatrizen) und auf Basis von „Expertenwissen“:

• Begutachtung des Planungsprozesses

• Prüfung der Unternehmensziele, bzw. der abgeleiteten Informationsbedarfe

• Kritische Prüfung der Prioritäten der einzelnen Bedarfe

Fachliche Bewertung


3.3 Bewertung

Zur Bewertung der Architektur können verschiedene High-Level-Analysen der verwendeten Systeme einander gegenübergestellt werden, ggf. auch gegen eine Referenzarchitektur

Ein Kriterienkatalog soll die Fähigkeiten der einzelnen Systeme bewerten (im Abschnitt „Konzepte“ wird diese Bewertung zur Softwareauswahl dargestellt)

Bewertung der Architektur/Technologie

Plattform A Plattform B Plattform C

Fachliche Verwaltung

Excel-AddinBusiness Editor

Excel-AddinExcel-

Kompatibilität Excel-Addin

Web Reporting Web Reporter Portal Report Vision

OLAP-Server Cube Services Cube ServicesOLAP Cube-Engine

App-Server BI-Services A BI-Services BReport Services

SAP BW-Integration SAP Importer BW Importer Data Importer


3.3 Bewertung

Reifegradmodelle liefern eine Einschätzung, wie weit fortgeschritten die Organisation im Bezug auf den Einsatz von Business Intelligence ist(Einige Reifegradmodelle sind in Kapitel 1 vorgestellt)

Die grundsätzliche Einschätzung der Aufbauorganisation kann durch Zuordnung zu einer Reifestufe erfolgen

Organisatorische Bewertung

InitialKein Ausweis von Reporting-Nutzen oder Kosten

UnformalisierteOrganisation

ProjektCost Center mit Projektbudget

Unterschiedliche Sichten auf Prozesse

„Einmal-Charakter“

Eigenständige BI-Organisation

Formales Evolutions-management

Support-Prozesse

Strategie vorhanden

Unternehmens-weite

BI-OrganisationVerursachungsgerech-te Kostenzuweisung

Durchgängige BI-Prozesse

Strategisches Informations-management

Volle Integration in alle Prozesse

Gleiche Behandlung wie operative Systeme


3.3 Bewertung

Als Instrument zur Bewertung aller Sichten kann die SWOT-Analyse dienen (Strengths, Weaknesses, Opportunities, Threats)

Sie stellt alle Eigenschaften der BI-Umgebung in einen Kontext und erlaubt die Bewertung, ob die momentane Struktur (oder eine mögliche Zielstruktur) ein eher positives oder negatives Bild abgibt

Beispiel: Ein Unternehmen überlegt ein anderes Unternehmen aufzukaufen und will im Rahmen der Initiative einer einheitlichen BI-Strategie bewerten, ob der Zukauf die Informationsbedarfe des Unternehmens stärkt oder stark behindert

Übergreifende Bewertung


3.3 Bewertung

Beispiel einer SWOT-Analyse nach Unternehmenszukauf

• Erfahrung im Umgang mit zwei großen BI-Plattformen

• Kurze Antwortzeiten bei Abfragen dank starker Server-Architektur

• Hochformatierte Berichte für alle Unternehmensteile

• Integration eines ausgefeilten Dashboards des neuen Unternehmens

• Übernahme des System-Know-Hows in die IT-Abteilung

• Integration der Leistungsverrechnung wie im anderen Unternehmen gehandhabt

Opportunities

Strenghts• Kein Single Point Of Truth (SPOT)

• Viele Schnittstellen

• Wenig Kommunikation zwischen Unternehmensteilen und Fachbereichen

• Medienbrüche in der Kommunikation der Unternehmen

• Unterschiedliche Bilanzierungen der Unternehmen führen zu uneinheitlichen Reports

• Bestehende Lizenzverträge müssen übernommen werden

Threats

Weaknesses


Agenda





3.4 Konzept

Das fachliche Konzept beschreibt, auf welche Art das Unternehmen in Zukunft gesteuert werden soll und welche Informationen dazu bereitzustellen sind

Je nach Verständnis einer BI-Strategie werden mehr oder weniger die einzelnen Steuerungsinstrumente fachlich definiert. Im stark ausgeprägten Fall kann die BI-Strategie die folgenden Punkte umfassen

• Übergreifendes Key-Performance-Indicator(KPI)-Konzept

• Einheitliche Darstellung von Kennzahlen und Attributen

• Prozessmodelle zur Erhebung von Kennzahlen

• Einheitlicher Kontenplan zur Standardisierung der abgefragten Informationen

• Einheitliches Stammdatenmanagement

Fachliches Konzept


3.4 Konzept

Die Bestimmung der Architektur der zukünftigen BI-Landschaft kann auf verschiedene Wege durchgeführt werden und berührt neben einer reinen Zielerfüllungskomponente auch immer eine Wirtschaftlichkeitsbetrachtung

Als Methoden können unter anderem zum Einsatz kommen:

• Ziel-Portfolio-Definition: Auf Basis eines vollständigen Bebauungsplans wird definiert, welche Applikationen welche Aufgaben erfüllen sollen und wie die Abdeckung generell gewährleistet werden soll, bzw. wo Lücken gelassen werden (können). Die Analyse greift dabei auf die erstellten oder weitere High-Level-analysen zurück

• Nutzwertanalyse: In einer Matrix werden mehrere Varianten einer Architektur spaltenwiese abgebildet. In Zeilen wird der zu erwartende Nutzen in unterschiedlichen Kategorien abgebildet. Da dieser oft nicht direkt messbar ist, werden Punkte (z.B. von 1 bis 5) vergeben. Die einzelnen Nutzenkategorien werden dann mit unterschiedlichen Gewichten versehen und so pro Architektur ein Gesamtwert ermittelt. Dieser muss in das Verhältnis zu den entstehenden Kosten gesetzt werden.

Konzept der Architektur/Technologie


3.4 Konzept

Beispiel einer Zielarchitektur

Source Layer

SAP R/3 Excel

Kunden-systeme

Liefe-rantensysteme

CRMSAPBusinessOne

ERP-Tool Sonstige

EDW Layer System XYZ

ApplicationLayer

Konsoli-dierungs-tool DEF

HRManagementXYZ

SAPBusinessOne

Web-Tool

Web-Tool

ToolABC

OutputLayer

Legal +ManagementReporting

StandardReporting(Zentrale + TK)

Financial Reporting

HRReporting

Strategische BI-Tools Tolerierte Tools Tools im Umfeld


3.4 Konzept

Beispiel: High-Level-Beschreibungen der Software im Zielportfolio

Produktname: BI Enterprise Suite Modulbezeichnung: Power ReportsAnbietername: BI Werkzeug GmbH Produktive Version: 8.01Anmerkung: Releasewechsel auf Version 8.2 geplant in Q3/20XXAnwendung 1: VertriebsreportingWöchentliches Reporting des Auftragseingangs mit verkürzter Ergebnisberechnung für Vertriebsverantwortliche der Business Units über Webbrowser.

Datenbasis: Vertriebs-Data-Mart (DMVERT1)Berichtsempfänger: 50 Berichtsersteller. 2Anmerkung: In den folgenden Jahren werden max. 60 Berichtsempfänger erwartet.Anwendung 2: BeschwerdestatistikMonatsreporting der im Servicesystem erfassten Beschwerden nach Beschwerdegründen.

Datenbasis: Service-Data-Mart (DMSERV1)Berichtsempfänger: 20 (davon 10 deckungsgleich mit Vertriebsreporting)

Berichtersteller: 1

Anmerkung: Es sind keine weiteren Berichtsempfänger geplant


3.4 Konzept

Beispiel: Nutzwertanalyse

Kategorie Gewicht Ist A1 A2 A3 A4Allgemein Flexibilität 1 2 3 1 3 2

Externer Support 2 4 4 6 4 4Mehrsprachigkeit 3 6 9 9 6 3Hochverfügbarkeit 4 4 12 12 8 4Metadaten-Verwaltung 5 10 10 15 10 5Mehrwährungsfähigkeit 1 2 2 2 2 2Standardisierung 2 4 6 6 6 2Berechtigungskonzept 3 3 9 9 9 3Migrationsfreiheit 1 2 1 1 1 3Summe 22 352 484 484 440 308

ETL 42 966 1134 966 1260 882Datenhaltung 33 528 627 627 627 561Frontend: Reporting 36 972 648 972 1008 936Frontend: OLAP 27 648 621 621 702 621

3466 3668 3670 4037 3308

Hinweis: Die in [Gansor et al.] Abgebildete Tabelle (S. 111) stellt fälschlicherweise keine Gewichtung dar.


3.4 Konzept

Nutzenermittlung bzw. Wirtschaftlichkeitsrechnung von BI-Systemen ist äußerst anspruchsvoll • Kann man aus der Verfügbarkeit von dispositiven Informationen einen direkten Wert

ableiten?• Was wird besser gemacht, wenn die Informationen vorliegen?

Beispiel: Weniger Reklamationen durch Qualitätsmonitoring• Welche Risiken / Kosten treten auf, falls dispositive Informationen nicht vorliegen?

Entwicklungs-, Betriebs- und Lizenzkosten• Können anhand einer beliebig detaillierten Spezifikation relativ genau ermittelt werden• Was kostet es, eine bestimmte Information abzurufen?• Kann das bestehende Kostengerüst reduziert werden?

Quantifizierung von Nutzen und Kosten


3.4 Konzept

Mögliche Strukturierung der BI-Kostenarten (Ausschnitt)

Hardwarekosten Softwarekosten PersonalkostenInitiale Kosten Serverbereitstellung

Erweiterung der Netzwerkinfrastruktur

Tool-Kosten Bereitstellung des Projektteams

Laufende Kosten Wartungskosten zusätzliche Terminals

Lizenzkosten Updates & UpgradesWeiterentwicklung

Internes Personal Externes Personal Schulungskosten Betreuungskosten


3.4 Konzept

Typische Kostentreiber

Endanwender

Anzahl

Know How

Heterogenität

Anwendung

Performance

Anzahl an Reports

Umfang der Funktionalität

Infrastruktur

Reifegrad der bestehenden Landschaft

Anzahl der Schnittstellen

BI-Werkzeuge

Daten

Datenvolumen

Heterogenität der Daten

Datensicherheit

Archivierung


3.4 Konzept

Die Kosten für Software AfA und Software-Betrieb wurden bei Architektur 1 dem ERP-Softwarepaket zugeordnet. In der Praxis kann eine solche Entscheidung zum „Schönrechnen“ einer Architektur führen.

Sowohl absolute als auch relative Kostenbetrachtung notwendig (z.B. Kosten pro Cube, Kosten pro Bericht)

Beispiel: Monatliche absolute Kosten für BI-Technik

Architektur 1 Architektur 2 Kombinierte ArchitekturHardware AfA 48.150 € 10.130 € 58.280 €Hardware-Betrieb 49.670 € 25.070 € 74.740 €Software AfA 0 € 29.550 € 18.180 €Software-Betrieb 0 € 85.320 € 61.990 €Ext. Dienstl. 11.080 € 20.230 € 31.310 €Summe 108.900 € 170.300 € 244.490 €


3.4 Konzept

Die organisatorische Verankerung einer (neuen) BI-Strategie führt in der Regel zu neuen Rollen im Unternehmen und/oder neuen Aufgabenbereichen

Im Rahmen dieser Veranstaltung wird ein Business Intelligence CompetencyCenter (BICC) als übergreifendes Organisationskonzept vorgestellt, dass als spezialisierte Unternehmenseinheit die Hoheit über die BI-Landschaft und deren Verwendung behält

Das BICC wird ausführlich in den folgenden Kapiteln behandelt

Konzept der Organisation


Agenda





3.5 Maßnahmen, Management & Methoden

Das BI-Portfolio beinhaltet alle Projekte, die im Rahmen der BI-Strategie (und später im Rahmen der laufenden Weiterentwicklung) durchgeführt werden sollen

Es kennzeichnet Abhängigkeiten zwischen den einzelnen Projekten, beschreibt aber auch die Spezifika der einzelnen Projekte

Folgende Punkte sollten in einer Projektbeschreibung enthalten sein:

• Inhaltlicher Schwerpunkt des Projektes (z.B. „Neues Vertriebsreporting“, „RedesignETL-Prozesse“)

• Dringlichkeit/Priorität (Abgeleitet aus Strategieprozess: 1 – „sehr niedrig“ bis 5 –„unternehmenskritisch“)

• Investitionshöhe (Bildung von Investitionsklassen: z.B. von 1 – „sehr gering“ (Budget <10 Tsd. Euro) bis zu 5 – „sehr hoch“ (200-500 Tsd. Euro))

• Nutzen (z.B. von 1 – „praktisch keiner“ bis zu 5 – „sehr hoch“, zusätzlich kurze textuelle Beschreibung worin der Nutzen besteht)

BI-Portfoliomanagement (I)



Fortführung der Projektbeschreibung

• Komplexität (z.B. nach Anzahl Schnittstellen, Umfang der Transformation, Umfang inhaltliche Verarbeitungslogik)

• Risiko (Bildung von Risikoklassen, z.B. 1 – „praktisch kein Risiko“ bis zu 5 – „sehr hohes Risiko“)

• Auswirkung auf die bestehende BI-Landschaft (Beschreibung der Abhängigkeiten zu existierenden Anwendungen, Architektur/Technologie, Organisation)

• Abhängigkeit zu anderen Projekten (z.B. notwendige Vorprojekte)

• Benötige personelle Ressourcen (z.B. erwartete Zusammensetzung des Projektteams; bestimmte interne Schlüsselpersonen, die regelmäßig Engpässe bilden).

BI-Portfoliomanagement (II)



Unterschieden werden im BI-Projektportfolio fünf Arten von Projekten, wobei nicht in jedem Portfolio alle Arten vorhanden sein müssen

• BI-Strategieprojekt: Entwicklung oder Anpassung einer BI-Strategie

• BI-Organisationsprojekt: Veränderung der von BI „betroffenen“ Unternehmensbereiche oder Einführung neuer Unternehmensbereiche (z.B. BICC)

• Fachprojekt: Konzeptionelle Arbeiten wie z.B. Kennzahlendefinitionen, Steuerungskonzeption, etc.

• IT-Projekt: Nicht direkt sichtbare Änderungen in Steuerung oder Business-Intelligence-Systemen wie z.B. Hardwaremodernisierung, Software-Updates, etc.

• BI-Projekt (im klassischen Sinne): Einführung eines Reporting Konzepts und/oder Reporting-Systems, Datenqualitätsinitiativen, etc.

BI-Portfoliomanagement (III)


Phase I Phase II Phase III …

BI-P

roje

ktFa

chpr

ojek

tO

rga-

Pro

jekt

Neues KPI-Konzept

Gemeinsamer Konzernkunde

Gründung BICC

Redesign Core Data Warehouse

Prozess-optimierungStammdaten-anlage

ImplementierungVertriebsreporting


Darstellung der Abhängigkeiten eines BI-Projektportfolios



Neben der übergeordneten Steuerung des Portfolios ist auch die effektive und effiziente Steuerung der einzelnen Projekte vonnöten

Entscheidend ist die Auswahl der Projektbeteiligten, sie kann unterschieden werden in

• Projektleiter: Ein erfahrener Mitarbeiter aus Fachbereich oder IT mit übergreifendem Wissen und Kenntnissen in Projektmanagement. Projektleiter können für einzelne Projekte auch extern rekrutiert werden, um eine initiale Projektorganisation zu etablieren und andere Mitarbeiter zu schulen

• Kernteam: Vertreter von IT und Fachbereichen, die vollumfänglich für das Projekt arbeiten und in ihren Gebieten Expertenwissen besitzen. Sie sorgen für ein permanentes Voranschreiten des Projekts

• Erweitertes Projektteam: Mitarbeiter anderer Abteilungen, die punktuell herangezogen werden um Input zu liefern oder Tests zu unterstützen. Die Einbindung von „Gegenkräften“, d.h. projektkritischen Stimmen wird hierbei unterstützt um den erwarteten Wandel frühzeitig in der Organisation zu verankern.

Projektmanagement



Projektorganisation und -kommunikation

Lenkungsausschuss

Auftraggeber / Sponsor

ggf. Vertreterexterner Partner

Erweitertes Projektteam

Kernprojektteam

berichtet an

macht Vorgaben,beschließt

WichtigePersonen

Interviewpartner/Workshopteilnehmer

Fachbereich IT

gibt Informationen befragt

Projektleiter



Risikobetrachtung für die Entwicklung einer BI-Strategie Die Entwicklung und Umsetzung einer BI-Strategie stellt möglicherweise einen

erheblichen Eingriff in die bestehenden Strukturen eines Unternehmens dar

Die Veränderung eines Unternehmens ist, insbesondere bei einer großangelegten Strategie-Initiative immer auch mit Risiken verbunden, die in verschiedene Kategorien eingeordnet werden können

Projektscope/ -planung

• Inhalt• Umfang• Zeitplanung• Budget

Menschen

• Richtige Personen

• Verfügbarkeit• Motivation

Fachlichkeit

• Komplexität der Geschäfts-modelle

• Abbilden der fachlichen korrekten Steuerungslogik

Architektur/ Technologie

• Zu vielearchitektonische Insellösungen

• Einschätzung technologischer Feinheiten

Organisation

• Objektivität in der Diskussion

• Sind die Vorschläge durchsetzbar?



Controlling einer BI-Strategieumsetzung

• Qualifizierter, wenn möglich quantifizierter Nutzen der BI-Anwendungen, z.B. Vollständigkeit der Informationsversorgung oder Integrationsgrad der Informationspyramide

• Kosten (Betrieb, Lizenzen, Entwicklung, Support, Ausbildung)

• Effizienz der BI-Organisation

• Support (Art, Anzahl und Durchlaufzeiten von Anfragen; Anteil positiv erledigter Anfragen)

• Wartungsprojekte

• Systembetrieb

• Effizienz der BI-Architektur

Interne Prozesse und Organisation

Wirtschaftlichkeit• Anwendernutzen

• Anwenderakzeptanz: Zufriedenheit mit Antwortzeiten, Datenqualität, Benutzersupport, Funktionalität, Flexibilität und Intuitivität von BI-Anwendungen

• Nutzungsverhalten, Nutzerentwicklung

• Innovative Projekte (Fortschritt, Zeit, Ressourcenverbrauch)

• Wissensstand der Anwender (Anzahl und Art von Schulungen, Analyse von Anfragen beim Helpdesk, Nutzungsverhalten)

Innovationen / Know-how

Kunde


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC

• 4.1 Definition: Business Intelligence Competency Center (BICC)• 4.2 Aufgaben und Funktionen• 4.3 BICC-Typen

5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität


4.1 Definition: Business Intelligence Competency Center

Gartner Mai 2002: “The Business Intelligence Competency Center: An Essential Business Strategy”

“The BI competency center's (BICC's) role is to champion the BI technologies and define standards, as well as the business-alignment, project prioritization, management and skills issues associated with significant BI projects.”

[Gartner 2003]

“… a BICC is a cross-functional team with a permanent formal organizational structure. It has defined tasks, roles, responsibilities, and processes for supporting and promoting the effective use of BI across an organization.”

[Miller et al. 2006]

Ursprung und Historie



„Ein Business Intelligence Competency Center (BICC) ist eine Organisationsform, die Verantwortlichkeiten und Aufgaben wahrnimmt und entsprechende Rollen und Prozesse durch ein interdisziplinäres Team ausfüllt, um den effektiven Einsatz von Business Intelligence in Unternehmen zu fördern.“

[Gansor et al. 2010]

Dies erfolgt durch

• Standardisierung und Organisation

• Unterstützung der BI-Strategie

• Portfoliomanagement

• Weiterbildung und Beratung

• Projektunterstützung

Definition



BICC: Einflussfaktoren und Gestaltung

BICC

BI-Strategie

BI-Operationa-lisierung

Unternehmens-dynamik

Umfeld

Unternehmens-größe

BisherigeOrganisation

Unternehmens-kultur

Mitarbeiter



Die Einführung eines BICC erfordert Diskussionen über verschiedene organisatorische Aspekte

Diese betrifft zum einen das BICC „intern“:

• Wie ist das BICC aufgebaut?

• Welche Funktionen sollen übernommen werden?

• Welche Rollen sind vertreten?

• Wie laufen die Prozesse ab?

Aber auch die Einordnung des BICC in das Unternehmen muss geklärt werden:

• In welcher Form wird das BICC in die Aufbauorganisation eingebaut?

• Handelt es sich um eine interne oder externe Einheit?

• Wie wird das BICC „abgerechnet“ (Budget, ProfitCenter, …)

BICC im Unternehmenskontext


Agenda





4.2 Aufgaben und Funktionen

Ableitung der Funktionen

Aus der BI-Strategie

Organisatorische Ziele: Umsetzung u.a. durch BICC

Fachliche Ziele: Typischerweise in Fachprojekten, Allerdings Priorisierung und Abgleich durch BICC-Funktionen

Architektonische Ziele: Projekt- und Fachübergreifend, daher typischerweise in BICC-Funktionen

Technologische Ziele: Wie architektonische Ziele

Aus der BI-Operationalisierung

Unterschiedlichste Aufgabenstellungen in BI-Strategie-Projekten, Fachprojekten, IT-Projekten, BI-Projekten)

U.a. Anforderungsanalyse, Konzeption, Design, Implementierung, Testen, Rollout, Schulung, Coaching, Binnenmarketing, Betrieb etc.

Sowohl dezentrale aus auch zentrale Abbildung möglich

Ergebnis: Typen des BICC



Funktionen eines BICC

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur

Fachliche Architektur

Technische Architektur

BI-Unterstützung

BI-Personalentwicklung

BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC



Übernimmt die Ausgestaltung des BI-Programms (Projekte, Maßnahmen, Initiativen)

Management des BICC intern, des Innenverhältnisses (zum eigenen Unternehmen) und im Außenverhältnis (zu Drittanbietern, z.B. Software-Anbietern)

Verantwortlich für die Umsetzung von BI-Programm und BI-Strategie

Verwendet Methoden oder Elemente aus den Bereichen

• Multi-Projektmanagement

• Qualität- und Risikomanagement

• Wissensmangement

• Networking und Kommunkation

• Personalführung

BI-Management (i.e.S.)



Stellt einheitliche Vorgehensweise und methodische Konzepte bereit

Sichert die Einbindung der Business Intelligence in zentrale Prozesse und Systeme des Unternehmens

Verantwortlich für BI-Governance

Hauptziel ist die Unterstützung der BI-Operationalisierung, d.h. das Schaffen eines Rahmens, in dem BI-Projekte, -Initiativen und –Maßnahmen ohne wiederkehrende organisatorische Fragestellung durchgeführt werden können

Im eigentlichen Sinne keine „Management“-Aufgabe, aber dem Management direkt untergeordnet und abhängig von einer starken Management-Unterstützung zur Durchsetzung der Standards

Zur Umsetzung empfehlen sich definierte Projektvorgehensmodelle, Ordnungsrahmen, Best-Practice-Empfehlungen

Sicherstellung, dass das BICC die unternehmensweit akzeptierten Werkzeuge verwendet und nicht im BICC selbst „Wildwuchs“ entsteht

BI-Standardisierung



Abteilungsübergreifende Definition einer fachlichen Architektur

Im direkten Wechselspiel mit der technischen Architektur

Modellierung analytischer Unternehmensdaten und -datenflüsse, z.B.

• Grundlegende dispositive Datenarchitektur

• Basismodell der Geschäftsobjekte für Analysezwecke

• Basismodell der Datenakquise, -integration und -versorgung

Kontinuierlicher „Realitätscheck“: Sind die geforderten Informationsobjekte auch aus den Quellen ermittelbar und für alle Abteilungen einheitlich definiert/verfügbar?

Umsetzung durch

• Referenzdatenmodelle

• Architekturmodelle aus fachlicher Sicht (Organisationssicht)

• Nutzergruppen-/Nutzungsartendarstellungen




Technisches Pendant zur fachlichen Architektur

Umfasst Hardware- und Software-Management

Legt fest, in welcher Form Rechnersysteme vorzuhalten und einzusetzen sind (z.B. physisch oder virtuell)

Legt fest, welche Datenbanksystene, ETL- und Integrationssysteme, Frontends und BI-Kern-Systeme (OLAP, Reporting, Advanced Analytics) verwendet werden

Herausforderungen durch Standardisierung und gleichzeitige Sicherstellung von Innovation, durch Skalierbarkeitsanforderungen und durch Abhängigkeit von externen Quellen/Technologien (Software, Veränderungen im Hardwaremarkt, z.B. Cloud-Computing, etc.)

Sicherstellen der Datenversorgung auf Basis der fachlichen Modellierung, d.h. Abbildung der relevanten Informationsobjekte in den Systemen

Umsetzung durch Referenzarchitekturen, Testsysteme und Best-Practice-Ansätze




Umfasst Personalplanung, -akquise und –entwicklung für

• das BICC

• „BI-nahe“ Mitarbeiter, d.h. in Projekte involvierte Mitarbeiter, Key-User, Support-Stellen

• Fachanwender, d.h. die Nutzer der Systeme

Erfordert Einbindung in die relevanten Unternehmensbereiche, die sich mit diesen Fragestellungen „ohne BI“ beschäftigen, z.B. Personalabteilung, IT-Abteilung

Die Entwicklung kann vorangetrieben werden durch

• Interne Beratung (Coaching bei Projekten)

• Schulungen (intern oder Vermittlung nach extern)




Unterstützung der Fachanwender und/oder Projektteams

Supportform abhängig von Reifegrad der Lösung (in Entwicklung <-> in Betrieb)

Unterscheidung in verschiedene Support-Level

• First-level-support: Einfache Fragestellungen der Anwender, Bedienungshilfen

• Second-level-support: Fachliche oder technische Hürden, die Expertenwissen benötigen

• Third-level-support: Oft „Fehlergetrieben“ und nur von Entwicklern/Systemherstellern zu lösen. Der Third-level-support kann entsprechend durch externe Quelle erfolgen

Vorteil eines BICC-integrierten Supports ist die direkte Rückkopplung mit Architekten und Personalentwicklung

Unterstützung der Prozesse durch Bug-Tracking-Systeme (Fehlermanagement)

BI-Support



Planung und Durchführung von BI-Projekten

Sicherstellung der Einhaltung von Architekturvorgaben und Standards bei der Entwicklung

Vollständige Begleitung aller Projektphasen mit ggf. unterschiedlichem Einsatz und Unterstützung durch andere Abteilungen/Partner

Zurückspielen der Projekterfahrungen an das gesamte BICC zur Anpassung und Verbesserung der BI-Strategie

Die BI-Entwicklung ist oft der größte, nicht im BICC direkt verankerte Teil, da Kompetenzen in den IT-Systemen in anderen Abteilungen größer sind oder von extern bezogen werden.

BI-Entwicklung



Sicherstellung der Nutzbarkeit der entwickelten Lösungen

Vornehmlich technische Aufgaben, die im Zusammenspiel mit der IT-Abteilung bewältigt werden können/müssen

Anpassungen an Berichten, Layouts und Inhalten zur Widergabe veränderter externer Einflüsse oder Nutzeranforderungen

Enge Kopplung mit dem BI-Support, da Anforderungen und Probleme oft zusammenfallen, Lösungen aber ggf. technisch entwickelt werden müssen

Oft als eigene Abteilung organisiert, da der (zeitliche) Betrachtungshorizont auf die Systeme ein anderer ist und die Dynamik der Systeme sowie die Intensität der Systemveränderung deutlich geringer sind

BI-Betrieb


Agenda





4.3 BICC-Typen

BI-Volldienstleister

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC


4.3 BICC-Typen

Abdeckung aller Funktionen im BICC

Stellt eine durchgängige Betrachtung aller relevanten Aufgaben und Funktionen sicher

Ist in der Lage, Standards zu entwickeln und einzuhalten

Schafft Konkurrenzsituation zu mehreren anderen Abteilungen• IT-Abteilung besitzt für gewöhnlich „Umsetzungshoheit“ und

dominiert technische Architektur-Aspekte

• Personalabteilung verfügt über eigene Methoden und Konzepte zur Personalentwicklung

• Anwender- und Systemsupport sind für andere Systeme schon vorhanden

Schafft damit auch Dopplung von Ansprechpartnern für die Nutzer von Systemen im Unternehmen

BI-Volldienstleister


4.3 BICC-Typen

Interne Beratung

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC


4.3 BICC-Typen

Klammert die Funktion der BI-Umsetzung aus

Übernimmt alle Tätigkeitsfelder, wirkt ggf. jedoch nur beratend (z.B. im Bereich Personalentwicklung)

Gerät in keinen Handlungskonflikt zwischen strategischer Ausrichtung (Hoheit BICC) und operativen Erfordernissen oder Projekthürden (Hoheit Umsetzungsprojekte und Betrieb)

Läuft Gefahr, „nicht gefragt zu werden“ und Strategien zu entwickeln, die in der Umsetzung nicht beachtet werden

Organisatorische Einordnung, Weisungsbefugnis, Personalbesetzung, Vernetzung im Unternehmen und Mitarbeit auf Projekten sind erfolgskritische Faktoren

Interne Beratung


4.3 BICC-Typen

Koordinierungsstelle und Umfeld

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC


4.3 BICC-Typen

Im Kern ein „Minimal-BICC“ mit (reiner) Vermittlungsfunktion zwischen den beteiligten Abteilungen

Durch Ausbau und Einbezug des Umfelds erweiterbar in eine zentrale Schaltstelle für die eigentlich durchführenden Abteilungen

Schneller Aufbau möglich, da wenig Personal benötigt wird, wenn Aufgaben nicht selbst übernommen werden

Durchgriffsmacht eingeschränkt, da nur als Vermittler tätig oder nur als „Standardgeber“ ohne Möglichkeit, die Umsetzung oder das Management zu treiben

Koordinierungsstelle und Umfeld


4.3 BICC-Typen

Anwendungscenter

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC


4.3 BICC-Typen

Support-getriebener Ansatz, der vor allem in den späteren Phasen des Lebenszyklus von BI-Systemen zum Einsatz kommt

Bündelt Anforderungen und leitet Ansprüche für kommende Systeme ab

Kann ad-hoc-Analysen oder -Berichte unterstützen

Verfolgt (anders als die anderen Typen) nicht das Hauptziel einer Strategieentwicklung und –ausgestaltung

Herausforderung bei der Einführung eines Anwendungscenters ist die Kombination mit einer „strategischen“, konzeptionellen Stelle, die die Erfahrungen aufnimmt und bei weiteren Entwicklungen mit in die Planung einbringt

Anwendungscenter


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC

• 5.1 Rollen in einem BICC• 5.2 Aufbauorganisation eines BICC• 5.3 Planung eines BICC• 5.4 Entwicklung eines BICC• 5.5 Einführung eines BICC

6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität


5.1 Rollen in einem BICC

Eine Stelle ist eine „organisatorische Einheit, die aus der Stellenbildung hervorgeht und im Rahmen der Aufbauorganisation den Kompetenzbereich eines gedachten Handlungsträgers gemäß der Stellenbeschreibung abgrenzt. [Sie ist ein] Element des organisatorischen Teilbereichs.“

Eine Rolle ist im Gegenzug die Einordnung in die Ablauforganisation, d.h. die Beschreibung einer Menge von Funktionen, die ein oder mehrere Stelleninhaber ausführen. (Ursprünglich stammt der Begriff aus der Sozialpsychologie und ist ein „Bündel von Verhaltenserwartungen, die an eine soziale Position gerichtet werden.“)

Stellen und Rollen sind dabei abstrakte Konstrukte, die von einer oder mehreren konkreten Personen exklusiv, in Teilen und/oder gemeinsam ausgefüllt werden

Unterscheidung „Rollen“, „Stellen“ und „Personen“

Vgl. Gabler Wirtschaftslexikon, Informatik-Begriffsnetzwerk



Ein BICC ist eine Einheit in einem Unternehmen, die sich über die zu erfüllenden Aufgaben definiert und in verschiedensten Ausgestaltungen angetroffen werden kann (vgl. Kapitel 4)

Eine mögliche Aufbauorganisation richtet sich daher vorrangig nicht an „klassischen“ Strukturen aus (z.B. Bereichsleiter, Abteilungsleiter, Unterabteilungsleiter, Sachbearbeiter) sondern an den Gegebenheiten im Unternehmen wie der Größe und den existierenden Abteilungen

Zur Definition der Beteiligten eines BICC empfehlen sich daher Rollen

Die vorgestellten Rollen sind beispielhaft und können unternehmensspezifisch ausgeprägt, gestrichen und/oder ergänzt werden

Rollen und die Aufbauorganisation



Ein Beispiel-BICC-Rollenkonzept

Leiter BICC

Repräsentant Fachseite

Datenqualitätsverantwortlicher

BI-Architekt

BICC-Analyst

Data Scientist

Anwendungsverantwortlicher

Systemverantwortlicher

BI-Anwendungsentwickler

Außenbeauftragter

BI-Wissensmanager

[nach Gansor et al., 2010/2014]Prof. Dr. Peter Chamoni – Business Intelligence: Strategie und Organisation – Sommersemester 2019 161

BI-Modellierer

BI-Missionar

Trainer

BI-Projektleiter

Zusatzrollen

Kernrollen



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Trägt die Verantwortung für das BICC

Fokussiert auf Kommunikation nach außen (insbesondere nach „oben“)

Verantwortet die BI-Strategie (Planung, Entwicklung, Umsetzung)

Nimmt Führungsaufgaben wahr, die konkrete Ausgestaltung ist abhängig von der Aufbauorganisation


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Ist primärer Know-How-Träger für

Geschäftsmodell

Geschäftsprozesse

Informationsbedarfe

Verantwortet die fachliche Architektur

Besitzt BI-Wissen

Übernimmt Kommunikation in die Fachbereiche und trägt Ideen der Fachanwender vor


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Ist technischer Ansprechpartner und Wissensträger

Verantwortet die Erstellung der technischen Architektur und die Berücksichtigung der weiteren technischen Gegebenheiten im Unternehmen

Unterstützt den Support (falls vorhanden) in Fragestellungen zu Architektur und technischer Weiterentwicklung


BICC-Analyst

BI-Modellierer


Die Kernrollen sind vom Grundsatz her leicht zu unterscheiden:

• Der Leiter spiegelt die Management-Sicht und die BI-Strategie wider und ist die Schnittstelle in Richtung Vorstand

• Der Repräsentant der Fachseite vertritt die Belange der Anwender und verantwortet die fachliche Korrektheit der BI-Architektur

• Der BI-Architekt ist der technische Gegenpart zum Repräsentanten der Fachseite und verantwortet die technische Korrektheit der BI-Architektur

Die Kernrollen sind nicht miteinander kombinierbar und werden von unterschiedlichen Personen wahrgenommen

Besetzung der Kernrollen


Leiter BICC


BI-Architekt

Kernrollen


Zusammenspiel von Repräsentant der Fachseite und BI-Architekt

RepräsentantFachseite BI-Architekt

Business IT

Architekturschichten

Auswertung

Datenversorgung

Unternehmensprozesse

Analysebedarf

Informations-verfügbarkeit

Prof. Dr. Peter Chamoni – Business Intelligence: Strategie und Organisation – Sommersemester 2019 166[nach Gansor et al., 2010/2014]



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Ist das operative Bindeglied zwischen Repräsentanten der Fachseite und BI-Architekt

Hat ebenso Kenntnis von Geschäftsprozessen wie von BI-Architekturen und Modellierungstechniken

Verfügt i.d.R. nicht über tiefstes Detailwissen in beiden Bereichen

Konzentriert sich stark auf die analytische Seite, den „outputlayer“, nicht auf die Datenbewirtschaftung


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Ist das Gegenstück zum BI-Modellierer auf Ebene der Daten (nicht der Analysen)

Fokussiert die Datenbereitstellung, -haltung, -sicherheit und -qualität

Besitzt tiefe Kenntnisse der notwendigen Modellierungs- oder Datenflusstechniken

Hat grundlegende Kenntnis von Geschäftsprozessen im Sinne der Datenflüsse (Abteilungsübergreifend)


BICC-Analyst

BI-Modellierer


Zusammenspiel von BI-Modellierer und Datenqualitätsverantwortlichem

Business IT


Auswertung

Datenversorgung


Analysebedarf


Datenqualitäts-verantwortlicher

BI Modellierer



Überschneidung von Kompetenzbereichen und Arbeitsfeldern

Business IT


Auswertung

Datenversorgung


Analysebedarf




BI Modellierer




Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Unterstützt die fachliche Konsistenz der BI-Architektur

Ermittelt die fachlichen Anforderungen für BI-Lösungen

Ermittelt fachliche Potenziale für Lösungen, die durch das BICC bereitgestellt oder betrieben werden

Vermittelt zw. Fachbereich u./o. Fachseitenrepräsentant und BICC bzw. BI-Projekten


BICC-Analyst

BI-Modellierer


Überschneidung von Kompetenzbereichen und Arbeitsfeldern

Business IT


Auswertung

Datenversorgung


Analysebedarf




BI Modellierer




Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Entwickelt komplexe analytische Lösungen und (Prognose-)Modelle

Erstellt (im Rahmen eines Service) analytische Auswertungen

Unterstützt andere Rollen in BICC-und BI-Strategie-Projekten hinsichtlich Fragen der Datenanalyse, Interpretation und Modellbildung

Spezialisiert auf analytische Verfahren (Exploration, Analyse, Modelle und Visualisierung)


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist



BI-Missionar

Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Verantwortet die (Weiter-) Entwicklung, die Nutzung und den Betrieb einer BI-Anwendung (Anwendungsverantwortlicher)

Verantwortet die (Weiter-) Entwicklung, die Nutzung und den Betrieb eines BI-Systems (Systemverantwortlicher)

Betreut die Anwendung /das System im kompletten Lebenszyklus


BICC-Analyst

BI-Modellierer


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Erstellt konkrete Lösungen für einzelne Fragestellungen ohne an der gesamtheitlichen Architektur weiterzuentwickeln

Besitzt tiefe Kenntnisse von BI-Anwendungen und Entwicklungsprozessen

Wirkt bei Forschungsaufgaben des BICC durch Prototyp-Erstellung mit


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Stellt den Kontakt zu Unternehmen und Partnern außerhalb des Unternehmens (nicht nur außerhalb des BICC) her und hält ihn aufrecht

Sammelt auf externen Veranstaltungen Wissen über mögliche Entwicklungen und Techniken und gibt dieses an das BICC weiter


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Leitet sich nicht direkt aus einer Funktion ab

Steuert die Erkennung, Dokumentation und Erhaltung des Wissens der BICC-Beteiligten

Organisiert Vorlagen, Vorgaben und best practices


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Keine direkte Zuordnung zu einer Funktion des BICC

Übernimmt „Werbeaufgaben“ für das BICC

Hat gute Kenntnisse von Geschäftsmodell und -prozessen sowie von den Möglichkeiten und Vorteile von BI-Systemen

Entwickelt aus dem Feedback seiner „Werbekunden“ Visionen für zukünftige BI-Einsatzgebiete


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Besetzt den Bereich Personalentwicklung

Erstellt, koordiniert und hält Trainings zu den Systemen oder grundlegenden BI-Themen

Kann auch von extern besetzt werden um temporär einen Wissensmangel abzufedern


BICC-Analyst

BI-Modellierer



Leiter BICC


BI-Architekt

Data Scientist




Außenbeauftragter

BI-Wissensmanager


BI-Missionar

Trainer

BI-Projektleiter

Leitet einzelne Projekte, die aus dem BICC heraus entstehen

Besitzt tiefe Kenntnisse im Bereich des Projektmanagements und Projektcontrollings

Stellt eine Rolle dar, die rollierend besetzt werden kann und nur temporär (für die Dauer eines Projektes) besetzt wird


Mögliche weitere Rollen in einem BICC

• Data-Mining-Spezialist• Enterprise-Architecture-Spezialist• Security-Spezialist• Compliance-Spezialist• Analytical-CRM-Spezialist• Analytical-SCM-Spezialist• Vertriebsbeauftragter• Fachbereichskoordinator• Berichtsgestalter• (Statistiker)• (Mathematiker)

• Projektleiter• Repräsentant Auftraggeber• Fachbereichsanwender• Repräsentant Quellsysteme• Systemanalytiker• Systementwickler• Projektadministrator• Tester• Testentwickler• Lösungsarchitekt

Als Teil des BICC oder Teil von BI-Projekten



Die Multidimensionale Skalierung reduziert Datenpunkte, die durch mehr als zwei Dimensionen definiert sind (oder bei denen nur Ähnlichkeitsmaße vorhanden sind) auf eine 2-dimensionale Darstellung

Für die Darstellung von konkurrierenden, komplementären und unterstützenden Rollen (vgl. Gansor et al., S. 134) können „Distanzpunkte“ vergeben werden

Durch eine MDS wird eine Darstellung der „Verwandheitsgrade“ der einzelnen Rollen entwickelt

Darstellung der Rollen mit Hilfe Multidimensionaler Skalierung (MDS)

Punkte (weniger ist „näher“):• Selbst 0• Komplement und Unterstützung 1• Komplement 2• Unterstützung 4• Nicht verwandt 6• Kollidierend aber unterstützend 8• Kollidierend 10


Leiter BICCRep. Fachseite

BI-Architekt

BI-Modellierer

DQ-Verantw.

BICC-Analyst

Data Scientist

AnwSys-Verantw.

BI-Entwickler

Projektleiter

Trainer

BI-MissionarAußenbeauftr.

Wissensmgr.

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10





BI-Architekt

BI-Modellierer

DQ-Verantw.

BICC-Analyst

Data Scientist

AnwSys-Verantw.

BI-Entwickler

Projektleiter

Trainer


Wissensmgr.

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10




Kernrollen


BI-Architekt

BI-Modellierer

DQ-Verantw.

BICC-Analyst

Data Scientist

AnwSys-Verantw.

BI-Entwickler

Projektleiter

Trainer


Wissensmgr.

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10




Management und Kommunikation

Technische Domänen

Fachliche Domänen

Projekt-geschäft

Agenda





5.2 Aufbauorganisation eines BICC

Als Aufbauorganisation bezeichnet man das „statische System der organisatorischen Einheiten einer Unternehmung, das die Zuständigkeiten für die arbeitsteilige […] Erfüllung der Unternehmungsaufgabe regelt.“

Ein BICC übernimmt verschiedene Aufgaben, füllt mehrere Rollen aus und ist daher in der Organisation entsprechend zu verankern.

Eine reine Projektorganisation ist nicht zweckdienlich, da sie per Definition zeitlich begrenzt ist, die BI-strategischen Aufgaben aber dauerhaft wahrgenommen werden müssen

Für die Einordnung kommen neben den klassischen Organisationsformen (Linie, Stab, Matrix) auch eine Ausgestaltung als eigene Einheit, virtuelle Einheit oder externe Einheit in Frage

Definition Aufbauorganisation

Gabler Wirtschaftslexikon, 2012


Leitung

Abteilung 1

Unterabteilung 1.1

Unterabteilung 1.2

Unterabteilung 1.3

Abteilung 2

Unterabteilung 2.1

AbteilungBICC

Unterabteilung 2.3


Linienorganisation



Stabstelle

Leitung

Abteilung 1

Unterabteilung 1.1

Unterabteilung 1.2

Unterabteilung 1.3

Abteilung 2

Unterabteilung 2.1

Unterabteilung 2.2

Unterabteilung 2.3

Stabstelle BICC


Leitung

Region 2

Region 3

Region 1

Produktion VertriebEinkauf IT BICC

Verrichtungsprinzip

Objektprinzip


Matrixorganisation, Einordnung nach Verrichtungsprinzip


Leitung

Region 2

Region 3

Region 1

Produktion VertriebEinkauf IT

Verrichtungsprinzip

Objektprinzip


Matrixorganisation, Einordnung als Querschnittsfunktion

BICC

Andere Querschnittsfunktionen



Vor- und Nachteile der klassischen Organisationsformen für ein BICC

Bei starker Methodenorientierung oder Technikorientierung z.B. in IT-Abteilung gut einzugliedern

Von Abteilungsweisungen abhängig

Schwere Wahrnehmung der Koordinationsfunktion

Eingeschränkte Kommunikation

Konsequente Ausrichtung an strategischer Bedeutung

Entlastung der Leitung

Keine Weisungsfunktion

Kein direkter Zugriff auf Abteilungsmitarbeiter

Wissensdifferenzen zwischen BICC und ausführenden Mitarbeitern

Klare Positionierung des BICC als Querschnitts-funktion möglich

Bei Verrichtungsprinzip gute Aufteilung in objektorientierte Spezialisten möglich

Bei Querschnitt: Gefahr einer Tensororganisation(Einführung weiterer Betrachtungsdimensionen)

Unsicherheit über Zuständigkeiten und Verantwortungen

Linie Stabstelle Matrix


Primärorganisation (Linie, Matrix, Hybride..)

Leitung

Region 2

Region 1

Produktion VertriebEinkauf

Zentrales BICC


Zentrales BICC (echte Organisationseinheit)

Andere QuerschnittsfunktionenIT EntwicklungIT Betrieb




Vor- und Nachteile der Organisationsform als zentrales BICC

Stellen werden entsprechend der Möglichkeiten geschaffen und besetzt

Vorstandsnahe Organisation unterstützt Management-Support

Klarer Verantwortungsbereich

Direkte Ansprechmöglichkeit der betroffenen Abteilungen durch übergeordnete Agenda

Erfolgsmessung wird vereinfacht

Ggf. überbordende Verantwortung für einzelne Mitarbeiter, da viele Rollen in einer Abteilung zusammenfallen

Gefahr eines „Elfenbeinturms“

Zugriff auf einzelne Abteilungen umgeht ggf. Leitungsebenen und schafft Intransparenz

Einführung einer neuen Abteilung erfordert Aufwand

Kopplung von Strategie und operativer Arbeit muss explizit gefördert werden

Zentrales BICC


Abteilungsleiter


Virtuelles BICC


Leitung


IT Entwicklung

IT Betrieb

Für BICC abgeordnet

Virtuelles BICC



Abteilungsleiter


Grenzen der Mehrfachunterstellung


Leitung


IT Entwicklung

IT Betrieb

Für BICC abgeordnet

Virtuelles BICC


Fachprojekt



Vor- und Nachteile der Organisationsform als virtuelles BICC

Ressourcen können nach Bedarf akquiriert werden und freigegeben weden

Starke Nähe zum operativen Geschäft und aktuellen Geschäftsprozessen vorhanden

Klare Verantwortlichkeit für die BI-Themenstellungen werden in den Abteilungen verdeutlicht

Geringe organisatorische Änderungen vonnöten

Breites Wissen verschiedener Mitarbeiter verfügbar

Freistellung von Mitarbeitern aus der Primärorganisation in das BICC ggf. kompliziert

Interessenskonflikte zwischen Abteilungen und BICC, die einzelne Mitarbeiter belasten

Zuordnung der Aufwände wird erschwert durch Teilzeit-orientierte Arbeit der BICC-Mitarbeiter

Leitung eines virtuellen BICC ist aufwändig und von Interessenkonflikten geprägt

Starke Abhängigkeit von Verfügbarkeit der Mitarbeiter

Virtuelles BICC



Externes BICC (Nutzung von Outsourcing)

Unternehmen (betrachtete Organisation)

Leitung


IT Entwicklung

IT Betrieb Externes BICC



Gemeinsame Marktaktivitäten

Unternehmen

GF

Unternehmen

GF

Unternehmen

GF

Unternehmen

GF

ExternesBICC

Holding, Dachverband, Interessengemeinschaft o.ä.

Gemeinsame Strategie


Externes BICC (unternehmensübergreifend)


Wertschöpfungsnetzwerk



Vor- und Nachteile der Organisationsform als externes BICC

Managementholding: Kann die strategische Komponente mit klarer Verantwortung betreiben

Finanzholding:kann die Unabhängigkeit durch ein BICC bewahren, wenn einzelne Unternehmen das BICC als „Service“ zur Verfügung stellen

Stammhauskonzern:Kann einen zentralen Bereich für die Töchter schaffen

Outgesourcte BICCs: Schaffen Freiraum bei Größe und Kostengestaltung

Je nach Betrachtungspunkt und Organisationsform kann es zu Missverständnissen, Konkurrenzsituationen oder Leistungsunterschieden kommen, wenn das BICC nicht „dem eigenen“ Unternehmen angehört

Outsourcing bringt gerade für die strategische Komponente die Gefahr des Wissenverlustsohne eigenen Wissensaufbau mit sich

Kooperationsaufwand, Budgetierung, Erfolgsmessung und Transparenz sind sehr schwierig abzubilden und zu kontrollieren

Externes BICC


Kleinst-unternehmen Mittelstand Gehobener

Mittelstand Konzern Wertschöpfungs-netzwerk


BI-Organisation

Outgesourctes BICC

Unternehmensübergreifendes BICC

BICC als echte Organisationseinheit

Virtuelles BICC

BI-Strategie-Beauftragter

keine formale BI-Organisation


BI-Organisation vs. Unternehmensgröße und -form



Agenda





BI-Strategie

BICCplanen & entwerfen

BICCentwickeln

BICCeinführen

BICC betreiben

Anforderungen ausder

BI-Operationalisierung


Ausgangszustand Übergangszustand Zukünftiger Zustand

Aufbau von Strukturen Änderung von Prozessen

BICC anpassen

Organisationsplanung Organisationsgestaltung

Projektmanagement

5.3 Planung eines BICC

Übersicht des Planungs- und Entwicklungsprozesses




Die Einführung eines BICC ist ein Projekt, dessen Planung und Durchführung in großen Teilen mit allgemein bekannten Projektmanagementmethoden bewerkstelligt werden kann

Im Bereich der Planung kann allerdings unterschieden werden nach

• Planung des Projektes „Einführung eines BICC“

• Planung der Organisation des BICC

Zur Planung des Projektes sollten grundlegende Aspekte daher ebenso betrachtet werden wie BICC-Spezifika

Im Folgenden wird ein Modell aus fünf Teilaspekten vorgestellt, das durch Beantwortung von Kernfragen die Vollständigkeit der Planung sicher stellen soll (vgl. Gansor et al., S. 178)

Grundlagen der Planung



Gestaltung und Personalauswahl

Funktionsbereiche eines BICC

BI-Strategie BI-Operationalisierung

Rollen

Personal Defizite

Volumen/ Komplexität

Andauernde AktivitätenEinzelmaßnahmen(Projekte)




Aspekte bei der Planung


Beteiligte und Betroffene

Budget und Ressourcen

Termine und Zeiträume Ergebnis

Kommunikation


Aspekt: Beteiligte und Betroffene

Fragestellungen Beispiele Teilpläne

Wer sind die betroffenen Key-Player und wer sind mittelbar betroffene Personen?

• Keyplayer: Leiter BICC, CIO

• Mittelbar betroffen: Leiter und Mitarbeiter von Fachabteilungen, die BI-Anforderungen stellen, z. B. im Controlling

Projektplanung(Ressourcenplanung)

Organisations-planung(Veränderung der Aufbau- und Ablauforganisation)

Inwieweit sind sie und ihre Arbeit durch das neu einzuführende BICC betroffen?

• Re-Definition des Aufgabengebiets,• Machtgewinn/-verlust, • Entlastung, Zusatzbelastung

Wer sind die Beteiligten, die an der Gestaltung und Einführung des BICC mitwirken?

• IT-Leiter, • Mitarbeiter aus IT und Fachbereichen (z. B.

Controlling)

Wie können Betroffene evtl. zu Beteiligten werden?

• Mitwirkung von Support-Mitarbeitern bei der Gestaltung von BI-Support-Prozessen

• Mitwirkung von Fachabteilungsmitarbeitern bei der Gestaltung von Anforderungsprozessen

• Mitwirkung von IT-Entwicklern bei der Gestaltung von Standardisierungsprozessen



Aspekt: Budget und Ressourcen


In welchem Kostenrahmen kann das BICC-Einführungsprojekt realisiert werden?

• Festes Budget, • Kopplung von Budgetfreigaben an

Meilensteinerreichung,• Nachfinanzierung während des Betriebs

Projektplanung(Kosten, Zeit, Ressourcenplanung)Welche internen und

externen Ressourcen stehen zur Projektdurchführung zur Verfügung?

• Fachabteilungsmitarbeiter, • IT-Mitarbeiter, • externe Berater und Trainer,• Mitarbeiter anderer Konzernteile



Aspekt: Termine und Zeiträume


Zu welchen kritischen Terminen muss das BICC aktiv sein?

• Terminvorgaben für Outsourcing, Termine aus Merger & Acquisitions, Termine aus anderen strategischen Initiativen (Einführung neues ERP, Einführung IT-Governance-Strukturen)

Projektplanung(Zeitplanung)

Welche Zeiträume sind besonders für die BICC-Einführung geeignet?

• Saisonbedingte geringe BI-Nutzung (z. B. im Handel)

• Produktionsbedingte geringe BI-Nutzung (z. B. in den Werksferien)

• Zeiträume, in denen das Unternehmen keine anderen größeren Organisations-maßnahmen durchführt, also Regelbetrieb stattfindet



Aspekt: Ergebnis


Wie ist die erwartete Qualität der BICC-Einführung (Service-Qualität nach derEinführung)?

• Qualität der bearbeiteten Unterstützungsanfragen

• Qualität der Beratungsleistung• Qualität der Inhaltsbereitstellung des BICC

(z. B. Standardisierungsdokumentation, Vorgehensmodell)

Projektplanung(Qualitätsplanung)

Wie wird der Erfolg bzw. Misserfolg gemessen und bewertet?

• Feedback-Verfahren

• Messverfahren (Anzahl gelöste Support-Fälle, Leistungssteigerung im DWH, Antwortzeitverhalten von Ad-hoc-Analysen, Nutzungsgrad von BI-Lösungen)



Aspekt: Kommunikation


Wie werden die organisatorischen Anpassungen an die Betroffenen und Beteiligten kommuniziert?

• Fortlaufende kleinteilige Kommunikation vs. punktuelle umfassende Kommunikation

• Bringschuld vs. Holschuld

Kommunika-tionsplanung

Zu welchen Zeitpunkten und mittels welcher Medien soll die Kommunikation erfolgen?

• Zyklisch, an festen Tagen • E-Mail, Newsletter, Rundschreiben,

Informationsveranstaltungen, Intranet, Webcasts

Welche Inhalte werden in welcher Form kommuniziert?

• Pläne, Details, Werkstattbericht (Blick hinter die Kulissen) vs. freigegebene finale Inhalte

• Besonders kritisch: Personalentscheidungen

Wie werden unterschiedliche Adressaten im Unternehmen angesprochen?

Zielgruppenorientierung• nach Beziehung zum Unternehmen: Mitarbeiter,

Management, Konzernmitarbeiter, Dienstleister, Unterauftragnehmer

• nach Funktion: Einkauf, Produktion, Vertrieb, Finanz-u. Rechnungswesen


5 Ableitung der BICC-Organisation aus der BI-Strategie und dem organisatorischen Kontext

4 Ableitung der Aktivitäten aus der BI-Operationalisierung

3 Ableitung der Aktivitäten und Maßnahmen aus den Zielen der BI-Strategie

2 Begründung des BICC

1 Entwicklung einer BI-Strategie


Organisationskonzept

Erfolgt auf Basis einer Ist-Situationsanalyse und deckt den Handlungsbedarf auf, der bis zur gewünschten Zielsituation aus der BI-Strategie erforderlich ist

Aufgreifen der fachlichen, architektonischen, technologischen und organisatorischen Ziele aus der BI-Strategie

Entwicklung von Handlungsfeldern und Aktivitäten und dafür benötigter Rollen und Personen

Widerspiegeln des Konterparts zum einmaligen Projekt-Geschäft, das sich aus der Strategie ableitet: Definition der andauernden Aktivitäten bei der Unterstützung und Betreuung vorhandener Systeme

Je nach Unternehmen kann die eine oder andere (Misch-)Form einer Aufbauorganisation sinnvoll sein

Bestimmung der besten Form durch einen Kriterienkatalog


Obligatorische Grundlage für jede Einführung, da ohne Strategie keine (langfristigen) Ziele für ein BICC definiert sind

Agenda





BI-Strategie


BICCentwickeln

BICCeinführen

BICC betreiben






BICC anpassen


Projektmanagement

5.4 Entwicklung eines BICC





Hauptziele der Entwicklung eines BICC

Verändungs-prozess steuern

Servicequalität erhalten

Veränderung dokumentieren

Schrittweise Veränderungen an der Organisationsstruktur müssen dokumentiert werden

Zwischenstände in der Entwicklung sollen nachvollziehbar sein

Services, Analysen, Datenaufbereitungen und weitere Tätigkeiten, die bereits vor Einführung eines BICC durchgeführt wurden, müssen weiterhin durchführbar sein

Ggf. ist externe Unterstützung als Puffer einzuholen

Sicherstellung der geplanten Änderungen durch einen transparenten Änderungsprozess (Statusanalyse)

Projektmanagement und Organisationsmanagement werden angeglichen



Techniken der Organisationsanalyse

Checklisten (Faktenerfassung, keine personenbezogenen Daten)Techniken

Persönliche Informationserhebung (Interviews und Workshops)

Dokumentation und Modellierung (Organigramme, Prozessbilder, etc.)

Dokumentationsanalyse (Ist-Situation anhand Protokollen und Dokumenten)

Ursache-Wirkungs-Diagramme (Komplexe Zusammenhänge verbildlichen)

Kreativtechniken (Brainstorming, Mind Maps, …)

Nutzwertanalyse (Analyse komplexer Handlungsalternativen)



Beispiel Checklisten




+

–

+

Kosten externe Dienstleister

BI-Berater, BI-Trainer

+

KostenOrganisation

BICC+

+

Legende: proportional umgekehrt proportional+ –

Anschaffungs-kosten

BI-Anwendung

Implementie-rungskosten

BI-Entwicklung –

Schulungs-kosten

Fachbereich Controlling

?


Beispiel Ursache-Wirkungs-Diagramm



Evolution zum BICC

BICCBICCAus der IT-Entwicklung

Aus dem IT-Betrieb

Aus einem Fachbereich

Aus einer Organisations-

abteilung



Einfache Abdeckung technischer Funktionen Potential zum Volldienstleister, wenn übergreifende Bereiche (Personal,

Management) mit einbezogen werden können

Abdeckung der Funktionen nach Evolutionsursprung – IT-Entwicklung

BI-ManagementBI-Management

BI-ArchitekturFachliche Architektur

BI-UnterstützungBI-Personalentwicklung

BI-UmsetzungBI-Entwicklung

BI-Betrieb

BICC

BI-Standardisierung


BI-Support



Abdeckung unterstützender Funktionen, schwierig ist das fehlende tiefe fachliche Know-How

Potential zum Anwendungscenter (oder Volldienstleister)

Abdeckung der Funktionen nach Evolutionsursprung – IT-Betrieb





BI-Betrieb

BICC

BI-Standardisierung


BI-Support



Gute Fachkenntnisse (aber ggf. nur in eingeschränktem Bereich) und starke Unterstützungskompetenz

Schwierige Integration der technischen Aspekte, daher eher Koordinierungsstelle

Abdeckung der Funktionen nach Evolutionsursprung – Fachbereich





BI-Betrieb

BICC

BI-Standardisierung


BI-Support



Hoher Durchsetzungsgrad aber schwache fachliche und technische Kompetenzen Charakter einer Koordinierungsstelle mit Potential zur Ausgestaltung nach

Vorstellungen des Managements

Abdeckung der Funktionen nach Evolutionsursprung – Organisationsabteilung





BI-Betrieb

BICC

BI-Standardisierung


BI-Support


Agenda





BI-Strategie


BICCentwickeln

BICCeinführen

BICC betreiben






BICC anpassen


Projektmanagement

5.5 Einführung eines BICC





Die Einführung eines BICC ist in hohem Maße identisch zu anderen organisatorischen Änderungen, so dass die sich ergebenden Anforderungen allgemein beschrieben werden können• Klare und überzeugende Diagnose (Durchführen von „sicher“ richtigen Maßnahmen)

• Beachtung weicher Faktoren (Kommunikationsstil, Motivation der Mitarbeiter, …)

• Betroffene zu Beteiligten machen (Ängste nehmen, Verhindern von Missgunst)

• Auswahl und Einbindung von Schlüsselfiguren (Verbreitung des „Neuen“)

• Aktiver Umgang mit Widerstand und Konfliktsituationen (ggf. durch Projekt-Externe)

Change Management




Beteiligung Betroffener in einem BICC-Projekt


Betroffener Motivation BeteiligungsmöglichkeitenFachabteilungsleiter, z.B. Leiter Controlling

Einflussmöglichkeiten auf den Werkzeugeinsatz, genauer: die Umsetzung von Fachanforderungen bewahren

Einbindung bei Gestaltung des Anforderungsmanagementprozesses(Funktion BI-Entwicklung)

IT-Einkäufer Einflussmöglichkeiten auf die Tool-Auswahl hinsichtlich kaufmännischer Vorteile bewahren

Einbindung bei der Gestaltung des Softwareportfoliomanagement-Prozesses(Funktion BI-Standardisierung)

Projektleiter für BI-Projekte

Mehr Verantwortung, ggf. mehr Einfluss

Besetzung von Schlüsselrollen im neuen BICC (z. B. als BI-Architekt)

Fachabteilungs-mitarbeiter (BI)

Bewahren der bewährten Do-It-Yourself-Lösung

Besetzung von Schlüsselrollen im neuen BICC (z. B. als Repräsentant der Fachseite)

Support-Mitarbeiter Entlastung von unliebsamen fachlichen Support-Aufgaben

Einbindung bei der Gestaltung des technischen und fachlichen Support-Prozesses

Externer Dienstleister Faire Weiterbeschäftigung Entlastung von Moderations-aufgaben zwischen Unternehmensteilen

Mitwirkung bei der Erstellung von SLAs (BICC vs. Unternehmen, Unternehmen & BICC vs. externe Dienstleister)


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling

• 6.1 Orientierung der Ablauforganisation an Standardprozessen• 6.2 Anpassung und Betrieb eines BICC• 6.3 Leistungsvereinbarung und -verrechnung• 6.4 Controlling eines BICC• 6.5 Werkzeuge für ein BICC

7 BI-Projektmanagement 8 Datenqualität


6.1 Orientierung an Standardprozessen

Die Ablauforganisation verlangt immer nach einheitlichem Vorgehen

Ein organisatorisches Rahmenwerk ist eventuell bereits im Unternehmen im Einsatz und schafft bei weiterer Verwendung Vorteile

• Gemeinsame Nutzung statt „das Rad neu erfinden“

• Einfache Einführung durch Zurückgreifen auf Bekanntes

Best Practices und Experten können auch außerhalb des Unternehmens gefunden werden, die Suche nach Personen für offene Stellen wird vereinfacht

Standards werden weiter entwickelt, das Unternehmen profitiert davon

Standards werden auch durch Software unterstützt

• Templates, Schablonen

• Abläufe

BI-Prozesse – Warum Standards adaptieren?



Die „IT Infrastructure Library“ (ITIL) ist eine Best-Practice-Sammlung (keine Monographie!) mit Beschreibungen für die Umsetzung von IT-Management

Enthält Beschreibungen für Anpassung von „Business und IT“

Das „ITIL V3 Core Framework“ gliedert sich in unterschiedliche Bereiche

ITIL als Orientierungsrahmen für BI-Prozesse

Service StrategiesVerzahnung von Geschäfts- und IT-

Strategie

Service DesignEntwicklung und Gestaltung von Service-Lösungen und -Prozessen

Service TransitionPlanen und Einführen von Veränderungen an Services

Service OperationUnterstützung eines effektiven und effizienten

operativen IT-Managements

Continual ServiceImprovement

Systematische Verbesserung der Qualität bestehender Services



Lebenszyklusbetrachtung von Services nach ITIL



Die angebotenen best practices von ITIL V3 können in Bezug zu den Funktionen eines BICC gesetzt werden

Dabei existiert für einige Bereiche eine sehr hohe Überlappung, bzw. ein hohes Hilfestellungspotential, während in anderen Bereichen wenig Gemeinsamkeiten erkennbar sind

ITIL-Prozesse für BI adaptieren

vs.



Servicekatalog-Managementzentrales Leistungsverzeichnis von standardisierten BI-Services

Service-Level-ManagementVereinbarung von Leistungen mit den Kunden

Availability / Capacity ManagementInformationen über die Verfügbarkeit der BI-Services

Supplier-ManagementZulieferungsvereinbarungen mit externen Dienstleistern

u.a.

Bereich „Service Design“

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC

Sehr starke Unterstüzung Gute Unterstützung

Schwache Unterstützung (Fast) keine Unterstützung



Event-ManagementMonitoring von Software im laufenden Betrieb zur Entdeckung von Fehlern und deren Ursachen

Incident-ManagementGewährleistung eines störungsarmen Betriebs, Aufnahme von Fehlern und Abarbeitung der Lösungen

Access-ManagementSicherung des Zugriffs und Bereitstellung eines Authorisierungskonzepts

u.a.

Bereich „Service Operation“

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC





Change-ManagementAblaufsteuerung bei Veränderungen

Release-ManagementOrganisation der Bereitstellung neuer Software-Versionen

Service Validation and TestingÜberprüfungen der Wirksamtkeitangebotener Services

Knowledge-ManagementSystematische Dokumentation von Wissen im Bereich BI

u.a.

Bereich „Service Transition“

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC





Bestimmung der ServicequalitätAbgleich von Anforderungen und deren Erfüllung

DatenerhebungMesspunkte für Prozessergebnisse und Abfrage der Messdaten

Datenanalyse und AuswertungKennzahlenerstellung und -aufbereitung

KorrekturmaßnahmenFeedback an ausführende Stellen, Betrieb und Entwicklung

u.a.

Bereich „Continual Service Improvement“

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC





Beispielprozess Incident-Management (I)



Beispielprozess Incident-Management (II)



Eine unzureichende BI-Nutzung oder mangelnde Anwenderzufriedenheit resultiert u.a. aus unpassenden BI-Prozessen

Auch BI-Prozesse außerhalb eines BICC müssen aufbereitet und gestaltet werden

ITIL eignet sich als Basis, allerdings insbesondere für den BI-Betrieb (und für die anderen Bereiche nur eingeschränkt)

ITIL ist für fachliche BI-Prozesse eher ungeeignet

ITIL hat zudem weitere Lücken, oder ist eher unkonkret (z.B. in Bezug auf die BI Architektur)

Weitere Frameworks/Standards können eine sinnvolle Ergänzung darstellen

Anwendbarkeit, kritische Würdigung ITIL


Agenda





BI-Strategie


BICCentwickeln

BICCeinführen

BICC betreiben







Projektmanagement

6.2 Anpassung und Betrieb eines BICC




BICC anpassen


Trennung von Entwicklung, Betrieb und Produktion

BI-Management

BI-Management

BI-Standardisierung

BI-Architektur



BI-Unterstützung


BI-Support

BI-Umsetzung

BI-Entwicklung

BI-Betrieb

BICC


?


System-/Anwendungsentwicklung mit externen Kräften oder als Gewerk

IT-Betrieb: Hardware, Netze, Betriebssystem, Datenbanken, Middleware in einer ausgeprägten Organisation für Produktion (ggf. Outsourcing / Hosting von großen Teilen der Produktion)

Herausforderung: Standards und Schnittstellen, SLAs, Feedback

Trennung von Entwicklung, Betrieb und Produktion


BICC

[nach Gansor /Totok, 2014]

BI-Umsetzung

BI-Entwicklung(-skoordination)

BI-Betrieb-(skoordination)

System-/Anw.entwicklung

IT-Betrieb

Extern (z.B. IT-Abteilung)

BI-Strategie


BICCentwickeln

BICCeinführen

BICC betreiben






BICC anpassen


Projektmanagement






Einflussfaktoren für eine Anpassung oder Neugestaltung

Gestaltung des BICC


Umfeld

Unternehmens-kultur

BI-Operatio-nalisierung

Bisherige Organisation

MitarbeiterUnternehmens-dynamik

BI-Strategie

BICC anpassen / weiterentwickeln BICC verändern / neu aufsetzen



Agenda





6.3 Leistungsvereinbarung und -verrechnung

Verrechnung setzt Leistungsdefinition voraus

Anfallende Kosten eines BICC

Verteilung Verrechnung

• Behandlung als Gemeinkosten

• Verteilung nach Schlüsseln, z.B. Mitarbeiter, Anzahl BI-Systeme, etc.

• Unabhängig von erbrachter Leistung

• Schlüssel liegt „im Vorhinein“ fest

• Behandlung als Einzelkosten oder Einzelkosten-ähnliche Kosten (im Sinne der Kostenstellenrechnung)

• „Schlüssel im Nachhinein“

• Setzt voraus, dass Leistungen erfasst werden

Leistungen müssen definiert werden



Der empfängerunabhängige Leistungskatalog eines BICC

• umfasst alle Dienste und/oder Produkte, die das BICC den Abteilungen des Unternehmens (oder dem externen Markt) anbieten kann und

• richtet sich an der Ausgestaltung des BICC aus (Interne Beratung vs. Volldienstleister)

Die Leistungen eines BICC können dabei mehrfach vorhanden sein aber unterschiedlich ausgeprägt werden (z.B. Berichtserstellung: Einmalig vs. Kontinuierliche Mitarbeit)

Ein empfängerabhängiger Leistungskatalog eines BICC

• umfasst alle Dienste und/oder Produkte, die das BICC einem konkreten Empfänger anbietet

• ist Teil eines Rahmenvertrags, bzw. eines Service Level Agreements (SLA) und

• legt die zu veranschlagenden Kosten und die Verteilung/Verrechnung fest.

Erstellung eines Leistungskatalogs



Dimensionen der Leistungserbringung eines BICC




Beispiel: Ausschnitt Leistungskatalog

Leistungskatalog fürService-Bezieher vonService-Anbieter

Gültigkeit vom 01.01.2012

bis zum 31.12.2013

Inhalte des Leistungskatalogs1. BI Management…………………………...……………………………................................1

a. Strategisches Anforderungsmanagement……………….....................................1

b. Projektmanagement…………………................ .................................................2

2. Fachlicher Betrieb………....………………………............................................................5

a. Datenqualitätssicherung (täglich, wöchentlich, etc.)...……………......................4

b. Stammdatenmanagement................................ .................................................7

c. Change Management

a. Neue/geänderte Kennzahlen......……………...........................................8

b. Neue/geänderte Berichte ......……………................................................9

3. Technischer Betrieb………………….……………………................................................10

a. Load Management….………………………………………………………..……..16

b. Laufende Performancesicherung und -optimierung ………...............................17

4. Schulung ………………….……………………..............................................................20

1. Basisschulung ......……………..........................................................................21

2. Fortgeschrittenenschulung ......…………….......................................................22



Abteilungen eines Unternehmens beziehen Leistungen von anderen Abteilungen (IT oder BICC) oder von extern

Tritt das BICC nicht als Lieferant auf, kann es als Berater auftreten oder selbst als Empfänger (z.B. von der IT)

Ein Rahmenvertrag zwischen Anbieter und Auftraggeber regelt die grundsätzliche Kooperation,

Service Level Agreements (Einzelverträge) regeln die Details für einzelne Angebote (Rechte/ Pflichten/ Kosten)

Konzept der Leistungsvereinbarungen




Leistungsvereinbarungen durch Service Level Agreements

Übergeordneter Rahmenvertrag Rahmen für Einzelvereinbarungen Grundsätze zu den Austauschbeziehungen

zwischen Fachbereichen, BICC und IT

Support• 1st Level Support• 2nd Level Support

Schulungen• Standardnutzer• Power User

Fachbetrieb• Berichtserstellung• Kennzahlenaufbau

BI-Management• Strategische

Anforderungen• Projektmanagement

Service Katalog



Beispiel: Ausschnitt Rahmenvertrag

Rahmenvertrag zwischenService-Bezieher vonService-Anbieter


bis zum 31.12.2013

Inhalte des Rahmenvertrags1. Erklärung zur Bereitschaft der Kooperation…………………………………….................1

a. Vorstellung der Vertragsparteien ……………………..........................................1

b. Ziele des Rahmenvertrags ……………………...................................................4

2. Rechte und Pflichten der Vertragsparteien ………...………………….............................5

a. Leistungen und Auftragspflichten des Service-Anbieters...……….....................4

b. Mitwirkungspflichten des Service-Beziehers………….......................................7

c. Einsichtsrechte des Service-Beziehers.....……………......................................8

d. Zahlungs- und Informationspflichten ....…………….........................................10

3. Rechtliche Rahmenbedingung …………………………….............................................14

a. Ort der Leistungserbringung ....…………….....................................................14

b. Haftung und Haftungsausschluss ....…………….............................................15

c. Arbeitnehmerüberlassung ....……………........................................................16

d. Einbeziehung von Sub-Unternehmern…………..............................................15

e. Kündigungsbedingungen ………….................................................................15

f. Gerichtsort und Schlichtungsverfahren …………............................................15



Beispiel: Ausschnitt SLA

Service Level Agreement zwischenService-Bezieher vonService-Anbieter


bis zum 31.12.2013

Inhalte des Service Level Agreements1. Service Definition…………………………...…………………………….............................1

a. Beschreibung des zu erbringenden Services………………...............................1

b. Zielsetzung der Vereinbarung……..…………………………….....…...................2

c. Abgrenzung des Leistungsspektrum...……………….........................................4

2. Bedingungen der Leistungserbringung………....………………………............................5

a. Beschreibung von In- und Output……………………....……………....................4

b. Beschreibung des Vorgangs der Leistungserstellung........................................7

c. Rollen und Verantwortungen…......……………..................................................8

d. Entscheidungs- und Eskalationswege....…………….......................................10

e. Leistungskriterien und -messung ....……………..............................................12

f. Verfügbarkeit des Services (Service-Zeiten)…………………………….....…...15

3. Rechtlich/kommerzieller Rahmen ….……….……………..............................................16

a. Preise für die Leistung….………………………………………………….....…...17

b. Erweiterung und Anpassung des Service………..............................................17

c. Ersatzansprüche bei nicht sachgerechter Leistungserbringung (Pönale)…..19



Beispiel: Formular eines einzelnen SLA

RACI-Beschreibung:ResponsibleAccountableConsultedInformed



Von der Leistungs- zur Kostenbetrachtung (Kostentreiber im BI-Umfeld)

Endanwender• Anzahl• Know-How• Heterogenität

Anwendung• Performance• Anzahl Reports• Umfang der

Funktionalität

Infrastruktur• Reifegrad der

bestehenden Landschaft

• Anzahl der Schnittstellen

• BI-Werkzeuge

Daten• Datenvolumen• Heterogenität der

Daten• Datensicherheit• Archivierung




Phase 1Vorgaben

Phase 2Ist-Analyse

Phase 3Definition der Produkte und sichtbarer Komponenten

Phase 4Erstellung des internen Leistungs- und Kostenmodells

Phase 5Planung und Kalkulation (kontinuierlich)

Vorgehen der Leistungsverrechnung – Phase 1

Quelle: Klesse 2008

Erstellung des Grundgerüsts der Leistungsvereinbarung (Dimensionen der Leistungserbringung)

Rahmenbedingungen / Rahmenvertrag

Prüfen existierender Verrechnungsmodalitäten




Analyse der bestehenden Leistungen seitens des BICC

Festlegen der (möglichen) Leistungsempfänger

Bestimmung von Mitwirkungspflichten oder Voraussetzungen für die Leistungen


Quelle: Klesse 2008

Phase 1Vorgaben

Phase 2Ist-Analyse






Vollständige Formulierung aller zu erbringenden Leistungen

Definition der Verrechnung, Bezahlung, Kostenübernahme, etc.

Einbezug zukünftiger Leistungen, sofern schon erkennbar


Quelle: Klesse 2008

Phase 1Vorgaben

Phase 2Ist-Analyse






Definition der endgültigen Verrechnungsgrundladen

Bestimmung von

• Prozesskosten

• Kostentreibern

• Fremdleistungen

Möglichst konkrete Kosten für Leistungen


Quelle: Klesse 2008

Phase 1Vorgaben

Phase 2Ist-Analyse






Ständige Fortplanung der Leistungserbringung (intern)

Controlling der anfallenden Kosten und Abgleich mit berechneten Leistungen und Kosten


Quelle: Klesse 2008

Phase 1Vorgaben

Phase 2Ist-Analyse





Verteilungs-/Verrechnungsarten – Verteilung über Gemeinkosten

Anfallende Kosten eines

BICC

Verteilung über Gemeinkosten

Fallweise VerrechnungKombination

Klare Abrechnungsmodalität

In der Regel einfach zu definierende Schlüssel

Alle Abteilungen können die Services als „Grundausstattung“ nutzen

Sehr pauschal und nicht nutzungsabhängig, daher Über-/Unterbelastung von Abteilungen

Zu wenig leistungsorientiert, schafft zu wenig Kostenbewusstsein und Transparenz (auch für das BICC selbst zum Marktvergleich)

Definition eines Verteilungsschlüssels, z. B.

• Anzahl Nutzer

• Anzahl Systeme

• In der Abteilung genutzte Berichte



Verteilungs-/Verrechnungsarten – Fallweise Verrechnung


BICC



„Fair“: Nur, wer Services nutzt, zahlt auch dafür

Hohe Transparenz und einfaches internes Controlling

Ggf. hoher Abrechnungsaufwand Führt zu „Spareffekten“ bei Fachbereichen:

Nutzung des BICC wird durch Kostenhürde geschwächt

Geringere Planungssicherheit für das BICC

Berechnung nur von angeforderten Leistungen

Je nach BICC-Typ werden Preise für Hardware, Software, Support, etc. ermittelt und als transparenter Leistungskatalog verfügbar gemacht

Metriken für Leistungen können sehr unterschiedlich sein (h, MB, Anzahl Bericht, …)



Verteilungs-/Verrechnungsarten – Kombination beider Varianten


BICC



Keine direkte Kostenhürde der BICC-Nutzung Die Intensität des BICC-Einsatzes wird

berücksichtigt, die Kosten gerecht verteilt Strategische Planungsaspekte fließen ein,

Forcierung von BI-Initiativen ist gezielt möglich

Schwieriger Umgang mit größeren Plan-/Ist-Abweichungen, wenn z.B. strategische Projekte verschoben werden

Die Nutzung des BICC wird z. B. jährlich geplant und das BICC zu einem Planschlüssel umgelegt

Insbesondere planerische Berücksichtigung der strategischen BICC-Projekte der Roadmap



Verrechnung von IT-Dienstleistungen (in Deutschland)

[Gadatsch/Mayer 2006]


Agenda





6.4 Controlling eines BICC

Das BICC leistet in vielen Fällen ähnliche Aufgaben wie die IT (auch dann, wenn es nicht als Teil der IT organisiert ist)• Bereitstellung von

abteilungsübergreifenden Services• Support-Abteilung• Infrastruktur-Bereitstellung• Beratende Tätigkeiten• Projektmanagement• …

Das Controlling eines BICC entspricht daher in großen Teilen den Controlling-Zielen und -Methoden des IT-Controlling

BICC-Controlling im Kontext von IT-Controlling

Unternehmensweites Controlling

IT-Controlling

BICC-Controlling



Begriff und Ziele des IT-Controlling

Führungssystem

Informations-versorgungssystem

Primäre Führungsfunktionen

Sekundäre Führungsfunktionen

Planung Systembildung

SystemkopplungEntscheidung

Steuerung

Kontrolle

IT-Controlling



Einordnung der Controlling-Objekte im BI-/IT-Controlling

Controlling-Objekte

Strategisches Controlling

Operatives Controlling

Produkt-Controlling

Projekt-Controlling

IT-Infrastruktur-Controlling

Portfolio-Controlling



Controlling-Objekte im IT-Controlling übertragen auf ein BICC

Portfolio-Controlling

Projekt-Controlling

Produkt-Controlling

BI-Infrastruktur-Controlling

• System zur Planung Steuerung und Kontrolle von Kosten, Terminen und Leistungen der BI-Projekte

• Bereitstellung von Methoden zur erfolgreichen Projektabwicklung

• Laufende Begleitung eingeführter Produkte (z.B. Analysewerkzeuge) über deren gesamten Lebenszyklus

• Effektive und Effiziente Nutzung eines betrachteten Produkts

• Planung der langfristigen technologischen Versorgung des Unternehmens

• Erstellung des BI-Infrastruktur-Budgets, Verrechnung der Kosten

• Zusammensetzung des BICC-Portfolios• Überprüfung: Stimmen aktuelle und geplante BI-Projekte mit der BI-

Strategie und der Unternehmensstrategie überein?



Erfolgsmessung im BICC

Datenqualität, Qualität von Analysen

Effizienz (in der Umsetzung, in der Nutzung von BI)

Zuverlässigkeit (von Lösungen, von Analysen)

Mitarbeiterzufriedenheit

Akzeptanz

Unternehmenskultur

Risikominimierung

…

IT-Performance

IT-Kosten, Total Cost of Ownership (TCO)

BI-Nutzung (Anzahl Anwender, Anzahl Berichte)

BI-Prozesse (z.B.: Dauer von Entscheidungsprozessen)

Konkrete geschäftliche Vorteile(aus Fachprojekten), die ausInitiativen des BICC folgen

…

Quantitativer Erfolg Qualitativer Erfolg



Messung quantitativen Erfolgs: Beispiel eines Kennzahlenbaums



Betrachtung aller Kosten, die für eine Lösung über den gesamten Lebenszeitraum anfallen (nicht nur Investitionskosten, bzw. direkt messbare Kosten)

Total Cost of Ownership

Anschaffungs- bzw. Leasingkosten für Hardware

Lizenzkosten und Supportkosten für Software

Infrastrukturkosten, wie z.B. Netzwerk

Entwicklungskosten von firmenspezifischen Add Ons, wie z. B. Customizing des BI-Frontends hinsichtlich zentraler Unternehmensvorgaben, Entwicklung eines Security-Plug-Ins

Verwaltungs- und Wartungskosten, z. B. durch eigene Mitarbeiter oder Externe bei Outsourcing.

Schulungskosten und Coaching-Dienstleistungen

Versteckte Benutzerkosten wie z.B. Arbeitszeitverlust durch Kollegenschulung, Trial-and-Error-Schulung

Versteckte Benutzerkosten durch Mehrarbeit oder manuelle Aufwände, weil bspw. eine bestimmte Analysefunktion nicht gegeben ist oder bestimmte Daten manuell ins System eingegeben werden müssen

Produktivitäts- und Arbeitszeitverlust durch technische Probleme wie z.B. Netzwerk-probleme, mangelhaftes Antwortzeitverhalten eines Ad-Hoc-Systems, Serverausfall, fehlende Daten durch abgebrochene ETL-Läufe, etc.

Indirekte Kosten(im Rechnungswesen unsichtbar)

Direkte Kosten(im Rechnungswesen sichtbar)



Strategisches BI-Controlling mit Hilfe einer Balanced Scorecard (BSC)

Innovationen und Know-howStrategischesZiel Maßnahmen

Mess-größen Zielwerte

KundenStrategischesZiel Maßnahmen


Interne Prozesse und OrganisationStrategischesZiel Maßnahmen


WirtschaftlichkeitStrategischesZiel Maßnahmen


Visionund

Strategie



Inhalte der einzelnen Perspektiven der BSC

Anwendernutzen Anwenderakzeptanz Nutzungsverhalten Nutzerentwicklung

Nutzen Kosten

Wirtschaftlichkeit Kunden

Innovative Projekte Wissensstand der Anwender

Effizienz der BI-Organisation Support Wartungsprojekte Systembetrieb (Effizienz der BI-Architektur)

Interne Prozesse und Organisation Innovationen und Know-how



Wirtschaftlichkeit

Einmalige Kosten• Lizenzen• Initiale Entwicklung, Test, Rollout• Ausbildung

Periodische / laufende Kosten• Betrieb• Weiterentwicklung• Support• Laufende Ausbildung und

Coaching Indirekte Kosten

• Manuelle Aufwände• Arbeitszeitverlust

Qualifizierter (wenn möglich quantifizierter) Nutzen der BI-Anwendungen aus Sicht des Unternehmens, z. B.:

• Vollständigkeit der Informationsversorgung: Höhere Fundierung von Entscheidungen durch ein vollständiges und detailliertes Informationsangebot

• Integrationsgrad der Informationspyramide

Nutzen Kosten



Kunden

Antwortzeiten Datenqualität Benutzersupport Funktionalität Entwicklungszeiten

Für den Benutzer individuell erkennbarer Vorteil

Aufwand für Informationsaufbereitung bzw. Recherche

Reduktion Informationslatenz

Anwendernutzen Anwenderakzeptanz

Anzahl und Art der Benutzer Anteil dauerhaft benutzter Berichte Anzahl Ad-hoc-Analysen Anzahl tatsächlich am System

arbeitender Benutzer Anzahl von manuell erstellten

Berichten

Nutzungsverhalten Nutzerentwicklung



Interne Prozesse und Organisation

Art, Anzahl und Durchlaufzeiten von Anfragen

Anteil positiv erledigter Anfragen

Art, Anzahl und Durchlaufzeiten von Anforderungen

Auslastung der Mitarbeiter Umfang und Art angebotener Treffen

der BI Community

Effizienz der BI-Organisation Support

Technisch gemessenes Antwortzeitverhalten

Verfügbarkeit Anzahl Fehler, Fehlerklassen pro BI-

System bzw. Anwendung

Fortschritt Zeit Ressourcenverbrauch

Wartungsprojekte Systembetrieb



Innovationen und Know-how

Innovative Projekte Wissensstand der Anwender Anzahl und Art von Schulungen,

erfolgreiche Zertifizierungen Analyse von Anfragen beim Helpdesk Nutzungsverhalten

Projekte, die Bestandteil der BI Roadmap sind

Projekte, die entweder bestehende Anwendungen entscheidend verbessern oder zum Aufbau neuer Anwendungen dienen

Projektcontrolling• Fortschritt• Zeit• Ressourcenverbrauch


Agenda





6.5 Werkzeuge für ein BICC

„Reine“ BI-Werkzeuge wie z.B.

• Cockpits

• Dashboards

• Reporting-Anwendungen

• ETL-Tools

• Etc.

finden sich in den Unterlagen zu Kapitel 1

Im Rahmen des BICC werden weitere Werkzeuge eingesetzt

Administrative/projektübergreifende Werkzeuge zur Unterstützung eines BICC



Übersicht der Themenbereiche

Modellierung und Dokumentation

Metadatenmanagement

Datenqualität

Stammdatenmanagement

Vorfallmanagement

Portfoliomanagement

Projektmanagement

Daten-, Organisations-, Prozess-und Funktionssicht

Vordefinierte Methodensets Primär grafische Modellierung Zentrales Metadaten-Repository Unterstützung von Teamarbeit durch

Check-in-/Check-out-Mechanismus Abgestufter Freigabeprozess bei

Modelländerungen Abgestuftes Berechtigungskonzept Webbasierte Darstellung im

Unternehmensintranet Exportmöglichkeiten

(z. B. XML, BPEL, DDL)





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

„Daten über Daten“ Integration und Normierung

Unterschiedliche Quellen für Metadaten werden integriert

DokumentationDie zusammengeführten Metadaten dienen als Basis der Dokumentation

Analyse und AuswertungDie Gesamtheit der Metadaten wird für Auswertungen und Analysen zur Verfügung gestellt

Information und PublikationDas Metadaten-Repository stellt die einzige gemeinsame Informationsquelle für Metadaten dar





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

Zentral/Dezentral Vordefiniertes Datenmodell Benutzerschnittstelle Synchrone/asynchrone

Kommunikation Schnittstellen Automatisierung Zugriffsberechtigungen Versionierung Nachvollziehbarkeit Reporting Vordefinierter Content





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

Data Profiling Analyse der inhaltlichen

Ausprägungen Generierung für Regeln zur

automatisierten Validierung Data Cleansing

Automatisierte Bereinigung inhaltlicher Defizite

Anwendung von Fuzzy Logic Spezialgebiet: Bereinigung von

Kunden und Adressdaten Siehe Kapitel 9





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

Vorfallerfassung (=„Fehlermeldung“) Zuordnung Ablaufsteuerung Auswertung Kommunikation Dokumentation Arbeitsplanung und Steuerung Bugtracking





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

Projektportfoliomanagement Priorisierung Abhängigkeiten Roadmap

Anforderungsmanagement Release Management





Metadatenmanagement

Datenqualität


Vorfallmanagement

Portfoliomanagement

Projektmanagement

Phasen und Aktivitäten Aufwand und Kosten Ressourcen Zeit Siehe Kapitel 10


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement

• 7.1 Eigenschaften von (BI-)Projekten• 7.2 Projektorganisation• 7.3 Phasengestützte Vorgehensmodelle• 7.4 Agile Vorgehensmodelle

8 Datenqualität


7.1 Eigenschaften von (BI-)Projekten

Häufigkeit von Projekten Projekte nehmen einen immer größeren Anteil am Geschäft von Unternehmen ein

Betrachtet man die Anfragen nach IT-Projektmanagern bei GULP, der führenden Vermittlungsplattform für IT-/Projektexperten, lässt sich über 15 Jahre eine Steigerung von 449,96% feststellen

+ 449,96 %

GULP IT-Projektmarktindex, März 2015


0

20.000

40.000

60.000

80.000

100.000

120.000

140.000

160.000

180.000

200.000

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014


Definition eines Projekts Ein Projekt kennzeichnet sich durch mehrere Aspekte, die es von der

„gewöhnlichen Geschäftstätigkeit“ einer Unternehmung abgrenzen

• EinmaligkeitEin Projekt ist ein einmaliges Vorhaben und wird nicht regelmäßig wiederholt

• Start- und EndzeitpunktEin Projekt hat einen klar definierten Beginn und ein klar definiertes Ende(!)

• RessourcenEin Projekt benötigt Arbeitskraft und Budget zur Durchführung

• ZielEin Projekt hat ein klar definiertes Ziel, dessen Erreichung den Projekterfolg bestimmt

• KomplexitätEin Projekt ist keine triviale Aufgabe, die als geringer Bestandteil der „alltäglichen“ Arbeit erledigt wird



Spezifika eines BI-Projekts Projekte im Bereich „Business Intelligence“

• weisen grundsätzlich die Eigenschaften eines Projektes auf

• können sich mit organisatorischen und/oder systemischen Fragestellungen beschäftigen

• beinhalten in der Regel eine IT-Komponente

• betreffen üblicherweise mehr als eine Abteilung (Fachbereichsabteilung(en), IT-Abteilung, …)

Die Einführung eines BICC ist ein Projekt im BI-Umfeld, aber kein „klassisches BI-Projekt“, da hier erst die Organisation für weitere Projekte eingerichtet wird

BI-Projekte sind z.B.

• die Einführung/Änderung eines Data Warehouse

• die Einführung/Änderung eines Analyse-Systems

• die Erarbeitung von entsprechenden Standards, Strukturen, etc.

Fokus dieses Kapitels



Projektmanagement Projektmanagement ist der Einsatz von Ressourcen zur Erreichung eines

Projektziels. Es umfasst die Planung, Organisation und Steuerung der Beteiligten.

Aufgaben des Projektmanagements sind daher

• Planung von Kosten, Zeit, Ressourcen und Aufgaben

• Führung des Projektteams und Berichterstattung an den Auftraggeber des Projekts

• Kontrolle der Planung und der Ist-Erreichung

• Risikomanagement

Je nach Betrachtung (personenbezogen oder aufgabenbezogen) kann „Projektmanagement“ als

• die ausführende Stelle oder

• das generelle Vorgehensmodell verstanden werden (Gegenstand dieser Veranstaltung).

[nach Kerzner, 2008]



Die Erfolgsmessung von IT-Projekten zeigt nur geringe Verbesserung, allerdings sind die entsprechenden Studien stark umstritten (vgl. Eveleens/Verhoef (2010))

Erfolgsmessung

Erfolgsquote 1994 – 2012 (in %)

32

ErfolgreichGescheitert Verzögert

[Standish Group, 2013]


0

10

20

30

40

50

60

70

80

90

100

1994 1996 1998 2000 2002 2004 2006 2009 2010 2011 2012


Die Messung von Erfolg ist höchst subjektiv und kann aus verschiedensten Perspektiven erfolgen

Ist ein Projekt erfolgreich, wenn…

• das Budget eingehalten wurde?

• alle vorher definierten Ziele vollständig erreicht wurden?

• der Zeitplan eingehalten wurde?

• die Beteiligten mit dem Ergebnis zufrieden sind?

• der Auftraggeber mit dem Ergebnis zufrieden ist?

• der Nutzen des Projekts die Kosten übersteigt?

• …

Erfolgsmessung



Jedes Projekt soll in möglichst kurzer Zeit mit möglichst geringem Budget möglichst viele Funktionen liefern

Die Ziele behindern sich dabei gegenseitig

Je weiter man sich im „magischen Dreieck“ in eine Richtung bewegt, desto mehr entfernt man sich von den anderen Zielen, da Budget und Zeit endlich, der mögliche Funktionsumfang aber nahezu unbeschränkt ist.

Das magische Dreieck (engl.: The Iron Triangle)

Funktionen

ZeitBudget



Das magische Dreieck bildet die Grundlage für diverse Weiterentwicklungen, die einzelne Aspekte hervorheben oder ergänzen

Neben den endlichen Projektressourcen wird oft das Merkmal der Qualität betont

Das Teufelsviereck nach Sneed


Agenda



8 Datenqualität


7.2 Projektorganisation

Einordnung in die Unternehmensorganisation

Einbindung in Linie Stabstelle

Matrixorganisation Projektorganisation



BI-Architekt

BI-Modellierer

DQ-Verantw.

BICC-Analyst

Data Scientist

AnwSys-Verantw.

BI-Entwickler

Projektleiter

Trainer


Wissensmgr.

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10


Einordnung des Projektgeschäfts in ein BICC


Management und Kommunikation

Technische Domänen

Fachliche Domänen

Projekt-geschäft


Rollen in der Projektorganisation

Lenkungsausschuss

Teilprojektleitung

Projektleitung

Teilprojektleitung

Projektmitarbeiter

Projekt Management Office

Projektmitarbeiter

Projektmitarbeiter

Projektmitarbeiter

Projektmitarbeiter

Projektmitarbeiter

• Verantwortet Projekterfolg,• Entscheidet Projektfortführung oder -abbruch

• Führt Projektteam• Erstellt Projektplan und –controlling• Entscheidet Vorgehen

• Übernimmt organisatorische Aufgaben für die Projektleitung

• Steuert Projektmitarbeiter• Verfügt über mehr Fachwissen als Projektleitung

• Verrichtet operative Arbeit• Besitzt vorwiegend Fachwissen / Abteilungswissen / Spezialfähigkeiten



BICC-Rollen in der Projektorganisation (mögliche Aufteilung)

Leiter BICC


BI-Modellierer

BI-Architekt



BI-Projektleiter

…

Lenkungsausschuss

Teilprojektleitung

Projektleitung

Projekt Management Office

Projektmitarbeiter

Projektmitarbeiter

Projektmitarbeiter


…

Agenda



8 Datenqualität


7.3 Phasengestützte Vorgehensmodelle

Phasengestützte Vorgehensmodelle oder „Phasenmodelle“ zeichnen sich durch eine Aufteilung des Gesamtprojektes oder der Teilprojekte in einzelne Abschnitte (sogenannte Phasen) aus

Phasen (in Reinform) sind gekennzeichnet durch

• Inhaltliche / funktionale Abgeschlossenheit

• Zeitliche und inhaltliche Sequentialität

• Klar definierte Phasenergebnisse

• Eindeutige Ergebnis-Verantwortungen

Eigenschaften von Phasenmodellen (I)



Phasenmodelle tauchen in der Literatur und Praxis in unterschiedlichsten Varianten auf, betrachtet werden hier Phasenmodelle vor dem Hintergrund der Einführung oder Änderung eines BI-Systems

Ihnen allen gemein ist die grundlegende Trennung von

• Analyse (Ist-Analyse / Bedarfsanalyse / Handlungsanalyse)

• Design

• Fachlich (Zielbildentwicklung, Kennzahlendefintion, Berichtsdefinition, …) oft wird das fachliche Design in der Analysephase als Anforderungsdefinition untergebracht

• Technisch (Architekturentwicklung, Oberflächengestaltung, …)

• Umsetzung (Programmierung, Customizing, …)

• Test

• Auslieferung (Installation, Schulungen, …)

• (Betrieb: Wird teilweise ausgeklammert, weil das „eigentliche“ Projekt abgeschlossen ist)

Eigenschaften von Phasenmodellen (II)



Das Wasserfallmodell ist das älteste und „reinste“ phasenbasierte Vorgehen

Alle Elemente „fallen“ von einer Phase in die nächste, die Phasen werden streng sequentiell abgearbeitet

Eine allgemein gültige und eindeutige Beschreibung und Phasendefinition („Referenzmodell“) ist nicht vorhanden

Wasserfallmodell

Analyse

Design

Umsetzung

Test

Auslieferung



Den Abschluss jeder Phase bildet in der Regel ein Meilenstein mit einem fertigen Werk, das als Grundlage für die nächste Phase dient

In Phasenmodellen wechselt mit der Phase oft auch der Leistungserbringer (z.B. wird die (fachliche) Analyse von der Fachabteilung durchgeführt, das (technische) Design dann aber von der IT geleistet und die Umsetzung ggf. noch an Dritte vergeben)

Meilensteine

AnalyseDesign

UmsetzungTest

Auslieferung

LastenheftAbschluss-werk Pflichtenheft Programm Abnahme Freigabe



Phase I: Analyse Analyse

Design

Umsetzung

Test

Auslieferung

Ziel Eigentliches Projektziel ist festgelegt Angestrebtes Projektergebnis ist definiert Schwachstellen sind identifiziert und Soll-Zustand ist definiert

Tätigkeiten Befragung der Beteiligten auf gewünschte Leistung des BI-Systems Aufnahme des aktuellen Systemzustands und Leistungsportfolios sowie der

vorhandenen Dokumentation Erstellung einer Zielzustandsspezifikation

Beteiligte Projektleitung (Aufsetzen des Projekts, Einbinden der anderen Beteiligten) Fachbereich (Definition der Anforderungen, Schreiben der Spezifikation)

Hilfsmittel Projektplan Strukturierte Interviews Leistungskataloge

Ergebnis LastenheftDie Gesamtheit der Forderungen des Auftraggebers (Fachbereich) an die entwickelnde Stelle (z.B. IT oder BICC)



Phase II: Design

Ziel Die zukünftigen Inhalte des Systems sind spezifiziert Die Architektur des System ist festgelegt Klare Umsetzungsbedingungen existieren

Tätigkeiten

Detail-Spezifikation der gewünschten Leistungen und Einsetzen aller Anforderungen in einen Gesamt-Kontext Umsetzungsvorgehen beschreiben und funktionale sowie nicht-funktionale

Anforderungen an das System verschriftlichen Aufwand schätzen

Beteiligte Fachbereich (Definition der Anforderungen, Bewerten der Spezifikation) Zukünftiger Umsetzer/Auftragnehmer (Schreiben der Detail-Spezifikation)

Hilfsmittel Modellierungstechniken Schätzverfahren (Delphi-Verfahren, Function Points oder „Erfahrung“) Templates

Ergebnis Pflichtenheft Das „Umsetzungsversprechen“ des Auftragnehmers an den Auftraggeber

mit vertraglich zugesicherten und belastbaren Leistungen sowie Aufwänden

Analyse

Design

Umsetzung

Test

Auslieferung



Phase III: Umsetzung

Ziel Ein funktionsfähiges System existiert Alle spezifizierten Funktionen sind in der gewünschten Form im genannten

Budget (Zeit und Geld) realisiert

Tätigkeiten Architekturaufbau für das Zielsystem Einrichtung / Customizing / Programmierung des Zielsystems Dokumentation der Programmierung

Beteiligte Projektleitung (Operatives Management und Controlling des

Umsetzungsfortschritts) Umsetzer (Entwicklung und Anpassung des Programms)

Hilfsmittel Entwicklungswerkzeuge Architektur-/IT-Landschaftspläne Strukturierte PM-Methoden Vorgegebenes Projektcontrolling

Ergebnis Fertig entwickeltes Zielsystem Vollständige Dokumentation der Systemfunktionen

Analyse

Design

Umsetzung

Test

Auslieferung



Phase IV: Test

Ziel Das System ist vollständig getestet Der Auftraggeber hat das System abgenommen

Tätigkeiten

Test der Funktionen (Tut das System, was es soll?) Test der nicht-funktionalen Anforderungen (Sicherheit, Bedienbarkeit, …) Test von Verhalten und Last / Performance-Tests (Ist das System schnell

und stabil genug?

Beteiligte Auftraggeber (Test der Funktionen, Fehlerprotokolle und Abnahme) Umsetzer (Beheben auftretender Fehler)

Hilfsmittel Testpläne Testfälle Bug-Tracking-Anwendungen Last-Generatoren

Ergebnis Abnahmedokument (Der Auftraggeber erklärt die ordnungsgemäße

Erfüllung der Anforderungen und nimmt das Werk ab)

Analyse

Design

Umsetzung

Test

Auslieferung



Phase V: Auslieferung

Ziel Das System ist im Unternehmen an allen geplanten Einsatzstellen verfügbar Alle Benutzer des Systems sind im Umgang mit dem System geschult Das System ist im produktiven Einsatz

Tätigkeiten Installation des Systems / Freigabe des Produktivsystems Überführung von Alt-Daten in das neue System Schulungen der Benutzer Einrichtung und Bekanntmachung einer Support-Stelle

Beteiligte Projektleitung (Koordination der Auslieferung) Fachbereich (Nutzung und Erlernung des Systems) Betreiber (z.B. IT: Bereitstellung der Systemressourcen)

Hilfsmittel Schulungen (Externe) Trainer Unternehmensspezifische Verteilungsmechanismen (z.B. für die

Dokumentation)

Ergebnis Freigabe (Der Auftragnehmer verkündet die vollständige Benutzbarkeit des Systems für alle Benutzer)

Analyse

Design

Umsetzung

Test

Auslieferung



Diverse Modelle adaptieren das Wasserfallmodell und ergänzen Komponenten wie z.B. das Projektmanagement als nebenlaufende Tätigkeit…

Vorgehensmodell für BI-Projekte nach Hüsemann

[Dr. Bodo Hüsemann, Informationsfabrik GmbH]



…oder eine Initialisierungsphase zu Beginn des Projekts

BI-Projektmanagement-Vorgehensmodell nach König

[Prof. Stefan König, FH Hannover]



Auch Modelle mit überlappenden Phasen werden eingeführt, z.B. um die harte Trennung von Konzeption und Analyse aufzuheben und Erkenntnisse aus der Modellierungsphase wieder zu ergänzen und zu erweitern

PR/IT-Rahmenmodell mit überlappenden Phasen

[myconsult GmbH]



Einige Modelle brechen trotz grundsätzlich sequentieller Abarbeitung mit dem Meilenstein des „Pflichtenhefts“ und erlauben Re-Spezifizierungen

BI-Lifecycle-Vorgehensmodell mit Rückkopplungsmöglichkeiten



Vor- und Nachteile eines Phasenmodells

Klare Regelung der Verantwortlichkeiten in den einzelnen Phasen Auftraggeber kann unmissverständlich und vollständig den Funktionsumfang definieren Bei fixem Funktionsumfang kann nichts vergessen werden oder entfallen

(Steuerungssoftware für Kernkraftwerke/Flugzeuge/Banktresore aber auch Bilanzierungssoftware oder Controlling-Instrumente für Unternehmensfinanzen)

Aufwand kann vorher bestimmt werden

Auftraggeber kann (meist) nicht unmissverständlich und vollständig den Funktionsumfang definieren (obwohl er darf) – dazu müsste er ein vollständiges Bild des Zielsystems noch vor Erstellung des Pflichtenheftes im Kopf haben

Aufwand kann (meist) nicht vorher bestimmt werden – dazu müssten alle Veränderungen/Erweiterungen (vor allem des Projekt-Umfelds) vorher bekannt sein

Nach Umsetzung des Systems muss „gehofft“ werden, dass im Test keine großen Abweichungen auftreten, Änderungen führen zu „change requests“, d.h. mehr Budget

Die erfüllten Funktionen entsprechen immer einem „alten Stand“ der Anforderungen



Beispiel: Abbildung eines Projektplans in einer PM-Software

Dargestelltes Werkzeug: MS Project



Das V-Modell XT („Extreme Tailoring“) ist ein Entwicklungsstandard der Bundesrepublik Deutschland

Es ist eine verbesserte und erweiterte Variante des ursprünglichen V-Modells (siehe Grafik)

Besonderheit: Das V-Modell XT (I)



Das V-Modell XT verschiebt die starre Aufteilung hin zu zwei parallel durchgeführten „V“-Projekten, einem für den Auftragnehmer und einem für den Auftraggeber, beide sind durch definierte Schnittstellen und Übergabedokumente eng miteinander verflochten

Besonderheit: Das V-Modell XT (II)



Entscheidend ist, dass

• Bausteine aus dem V-Modell XT entfernt werden können, z.B. wenn das Projekt sehr klein ist (Tayloring),

• das V-Modell XT nur die Ergebnisse vorgibt, jedoch nicht den konkreten Weg hin zu den Ergebnissen.

Das V-Modell XT ist damit nur ein Rahmen für ein Systementwicklungsprojekt, aber keine konkrete Vorgehensweise

So können die Bausteine (im V-Modell-Jargon: „Produkte“), wie z.B. ein Softwaremodul durchaus mit agilen Methoden entwickelt werden

Besonderheit: Das V-Modell XT (IV)


Agenda



8 Datenqualität


7.4 Agile Vorgehensmodelle

„Agile Softwareentwicklung“ ist ein Überbegriff für Werte, Prinzipien und Methoden, um durch Flexibilität und Schnelligkeit bei der Systemerstellung einen Beitrag zur Erreichung der Geschäftsziele zu leisten

Das agile Manifest als Grundlage aller „agilen“ Vorgehensmodelle

Agiles Manifest (2001): Was bringt mehr WertMerkmale Frühe und häufige

Auslieferung von Software(-Komponenten)

Viel Kommunikation zwischen allen Beteiligten

Rückkopplungen und Anpassungen

Individuen und Interaktionen

Lauffähige Software

Zusammenarbeit mit Anwendern/KundenReaktion auf Veränderungen

Prozesse und WerkzeugeUmfangreiche Dokumentationen

Vertragsverhandlungen

Planverfolgung

istwichtiger

als

[Bleek/Wolf, 2009]

[agilemanifesto.org]



In der klassischen Vorgehensweise sind die Funktionen der Maßstab, benötigtes Budget und benötigte Zeit lassen sich daran abschätzen und sind von den Funktionen abhängig

Highsmith gibt Budget und Funktionen vor („Budget-Boxing“) und formuliert darauf aufbauend das Ziel einen Wert (ein Produkt) zu schaffen, dass einer akzeptablen Qualität und bestimmten Bedingungen (Zeit, Budget) genügt

Das magische Dreieck für agile Vorgehensmodelle nach Highsmith

Funktionen

ZeitBudget

„Klassisches“ Dreieck

Funktionen

Zeit

Budget

„Klassisch“ für agil

Wert

BedingungenQualität

„Agiles“ Dreieck



Das von Highsmith genannte Modell wird kritisiert, weil es die eigentliche Aussage des Dreiecks (Bindung an Zeit, Budget und Funktionen) verschleiert

Eine alternative, näher am „klassischen“ Dreieck orientierte Deutung dreht das Dreieck ebenfalls, setzt aber den Funktionsumfang in Abhängigkeit von Zeit und Budget

Das magische Dreieck nach Cottmeyer

Funktionen

ZeitBudget

„Klassisches“ Dreieck

Funktionen

ZeitBudget

„Agiles“ Dreieck



Im Unterschied zu phasenbasierten Vorgehensmodellen gibt es für agile Vorgehensmodelle kein einheitliches Grundmodell

Es existieren aber gewissen Leitlinien, die sich in allen agilen Vorgehensweisen wiederfinden

• Das Projekt kann in viele kleine, einzeln zu bearbeitende Arbeitspakete untergliedert werden, entweder im Vorhinein oder zur Laufzeit des Projekts

• Der Gesamtumfang der Anforderungen kann sich während des Projekts verändern und erweitern

• Die Entscheidung für die nächsten zur Umsetzung anstehenden Funktionen fällt in kontinuierlichen, nicht zu langen (max. wenige Wochen) Zyklen

• Sobald ein Baustein fertig ist (d.h. inkl. Test durch den Entwickler!), wird er dem Anwender zum Test übergeben

• Es findet eine durchgängige, bewusste Interaktion von Entwickler und Anwender statt

Eigenschaften agiler Vorgehensmodelle



Scrum als Beispiel für ein agiles Framework

[Nach Lakeworks]

Gesamtheit aller bekannten Anforderungen („User Stories“)

Menge aller im nächsten Sprint

(„30-Tage-Periode“) umzusetzenden Anforderungen

Fertig umgesetzte Bausteine des Zielsystems

Tägliches, kurzes Meeting aller Beteiligten



Je Sprint (großer Iteration) kann dargestellt werden, wie viele Anforderungen geplant/tatsächlich abgearbeitet wurden

Burndown-Chart



Scrum ist nur der Rahmen, in dem gearbeitet wird, und enthält keine Informationen über• Konkrete Umsetzungarten• Programmierweisen• Testarten

XP weist detaillierte Spezifikationen für die Umsetzung von Software auf und liefert vor allem die „User Stories“ als einfachste Form von Anforderungsdefinitionen

Scrum und Extreme Programming (XP)

"Als <Rolle>, möchte ich <Ziel/Wunsch>, um <Nutzen>"

"Als Controller, möchte ich die Umsatzzahlen monatlich als Balkendiagramm sehen, um den Monatsbericht zu erstellen.“



Scrum und das V-Modell XT liefern jeweils nur einen Rahmen für die eigentliche Umsetzung der Anforderungen

Das V-Modell XT entstammt einem phasenbasierten Vorgehen und „erlaubt“ agile Entwicklungsmethoden, solange die Schnittstellen und Ergebnisse eingehalten werden

Scrum definiert ein agiles Vorgehen, „erlaubt“ aber theoretisch eine Wasserfall-basierte Umsetzung innerhalb der Sprints

Scrum und das V-Modell XT

V-Modell XTPhasenweise (hellblau) Umsetzung von drei

Anforderungen (dunkelblau)

ScrumAutarke Umsetzung von Anforderungen

(hier in Phasen)

[Schematische Darstellung]



Die Beteiligten in einem agilen Vorgehensmodell sind die selben wie in einem Wasserfallmodell

Die Rolle und die zeitliche Taktung variieren jedoch: Statt punktuell hoher Belastungen entsteht eine Grundlast

Die Verteilung kann dazu führen, dass

• Die Beteiligten parallel ihren Alltagsaufgaben nachkommen können und nicht durch eine Spezifikations-/ Umsetzungsphase herausgerissen werden

• Die Beteiligten ihren Alltagsaufgaben nicht mehr nachkommen können, weil die Grundlast zu hoch ist und permanent Aufmerksamkeit erfordert

Zur Reduzierung der Belastung des Anwenders kann eine „Zwischenschicht“ nützlich sein, die insbesondere bei der Formulierung/Verschriftlichung der vollständigen Anforderungen und dem Test hilft

Projektbeteiligte in einem agilen Vorgehensmodell



Indikatoren für die Auswahl der passenden MethodeWasserfall-

modellAgile Methode

Erwarteter Wechsel der Anforderungen selten häufig

Zeitdruck gering hoch

Erwartung der Vollständigkeit 100% „80:20“

Wechsel der Anwender und Auftraggeber selten häufig

Dynamik im externen Umfeld gering hoch

Mitwirkungsmöglichkeit der Anwender gering hoch

Bedeutung von formalen Prüfkriterien hoch gering

Akzeptanz von agilen Methoden gering hoch

Releasestrategie „Big Bang“ iterativ

Reifegrad und Referenzen der Software hoch gering

[Horváth & Partners]



Indikatoren für die Auswahl der passenden Methode - Beispiele

Erwarteter Wechsel der Anforderungen

Zeitdruck

Erwartung der Vollständigkeit

Wechsel der Anwender und Auftraggeber

Dynamik im externen Umfeld

Mitwirkungsmöglichkeit der Anwender

Bedeutung von formalen Prüfkriterien

Akzeptanz von agilen Methoden

Releasestrategie

Reifegrad und Referenzen der Software

selten häufig

gering hoch

100% „80:20“

selten häufig

gering hoch

gering hoch

hoch gering

gering hoch

„Big Bang“ iterativ

hoch gering

selten häufig

gering hoch

100% „80:20“

selten häufig

gering hoch

gering hoch

hoch gering

gering hoch

„Big Bang“ iterativ

hoch gering

Umsetzung eines Systems zur Legalkonsolidierung mit SAP ECCS

Abbildung eines neuen fachlichen Planungsprozesses mit SAP BPC

Wasserfallmodell Agile Methode[Horváth & Partners]



Vor- und Nachteile einer agilen Vorgehensweise

Die Anforderungsdefinition erfolgt nicht von sondern mit den Nutzern, so dass Anforderungen plausibilisiert und nachträglich geändert werden können

Insbesondere bei BI-Anwendungen, in denen eine starke Visualisierung im Fokus steht, können schnelle Ergebnisse zu frühen Korrektureinsichten bei den Anwendern führen

Eine Fehlentwicklung oder Unmöglichkeiten in der Entwicklung werden nicht erst in einer abschließenden Testphase sondern sehr früh bemerkt

Je nach Vorgehensweise können Budget und Zeithorizont fix genannt werden

„Doing agile is not being agile“ formuliert die größte Hürde: Ein als agiles Vorgehen „getarntes“ Projektmanagement verschleiert die mangelnde Bereitschaft zur Dokumentation oder sauberen Anforderungsaufnahme

Sofern keine Erfahrungen mit agilen Vorgehensweisen bestehen kann der Wechsel zu agilen Methoden eine bestehende Organisation lähmen und Projekte gefährden

Agile Methoden sind kein Allheilmittel und eignen sich insbesondere dann nicht, wenn die Lösungen einen fixen Funktionsumfang aufweisen müssen, „koste es was es wolle“, wie z.B. bei Legalkonsolidierungen


Agenda

1 Einführung in Business Intelligence 2 Grundlagen von (BI-)Strategie 3 Entwicklung einer BI-Strategie 4 Unterstützung einer BI-Strategie durch ein BICC 5 Organisation und Entwicklung eines BICC 6 BICC-Betrieb und BICC-Controlling 7 BI-Projektmanagement 8 Datenqualität

• 8.1 Arten, Ursachen und Auswirkungen• 8.2 Organisatorische Unterstützung von Datenqualität• 8.3 Messen von Datenqualität• 8.4 Data Profiling• 8.5 Data Cleansing


8.1 Arten, Ursachen und Auswirkungen

Definition des Datenbegriffs Die Definition von Daten geht einher mit der Definition von Wissen und

Informationen

Zur Unterscheidung der drei Begriffe wird die Semiotik als allgemeine Zeichentheorie herangezogen, die drei Untersuchungsebenen kennt

• Syntaktik (Sprachliche/Formale Richtigkeit)

• Semantik (Inhaltliche Richtigkeit)

• Pragmatik (Nützlichkeit, Zweckorientierung)

Je nach Quelle kann dann ein leicht abweichender Zusammenhang über diese drei Felder zwischen den drei Begriffen (Daten, Wissen, Information) hergestellt werden



Daten

• Maschinell verarbeitbare Informationen [Vgl. DIN 44300]

• Folge von Zeichen, über deren Bedeutung weitestgehend Konsens besteht, d.h. die verstanden und prinzipiell von einer Person aufgenommen werden können(Voß und Gutenschwager 2001)

Information

• Kenntnis über bestimmte Sachverhalte oder Vorgänge [Vgl. DIN 44300]

Wissen

• die Gesamtheit aller Kenntnisse und Fertigkeiten auf einem bestimmten Gebiet(Stickel 2001)

Daten, Information und Wissen



Daten

• syntaktische Dimension

• z. B. .RB3720W1703G7

Information

• semantische Dimension

• z. B. Regionalbahn 3720 fährt werktags um 17.03 Uhr von Gleis 7 ab

Wissen

• pragmatische Dimension

• z. B. Bisher fuhr die Regionalbahn 3720 um 17.10 Uhr ab; Umsteigende aus dem Zug IR317 erreichen den Anschluss nun nicht mehr

Beispiel verschiedener Ebenen



Definition des Datenbegriffs

Daten

Maschinell verarbeitbar Nicht maschinell verarbeitbar

Ohne Zweck Mit Zweck Mit Zweck Ohne

Zweck

Informationen

Wissen

Syn-taktik

Prag-matik

[Nach Gabriel/Weber] [„Semiotisches Dreieck“ nach Hinrichs]

Daten (Syntaktik)

Informationen (Semantik)

Wissen (Pragmatik)



Qualitas (lat.) = „Eigenschaft“ oder „Beschaffenheit“ (weder positiv noch negativ)

Laut DIN-Norm 55 350-11:

„Qualität [ist] die Gesamtheit von Eigenschaften und Merkmale eines Produktes oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung festgelegter oder vorausgesetzter Erfordernisse beziehen.“

Qualität kann in unterschiedlichen Feldern auftreten und je nach Bezug unterschiedliche Auswirkungen haben (objektive Qualität eines Werkstoffes vs. gefühlte Qualität durch den Kunden vs. prozessuale Qualität bei der Herstellung)

Aus der Kombination der beiden Begriffe „Daten und „Qualität“ ergibt sich

Datenqualität ist ein Maß für die Eignung von Daten einen definierten Zweck zu erfüllen, um Informationen oder Wissen zu generieren oder zu erlangen, unter der Bedingung, dass die Eignung vom Zeitpunkt der Betrachtung und den jeweiligen Bedürfnissen des Betrachters abhängt.

Definition des (Daten-)Qualitätsbegriffs



Taxonomie von Datenqualitätsdimensionen

dgiq: Deutsche Gesellschaft für Informations- und Datenqualität



Zeitnähe• Daten stehen nicht oder zu spät zur Verfügung (Anlieferungsproblem)• Daten sind veraltet (Inhaltsproblem)

Korrektheit• Daten sind „falsch“ (Inhaltsproblem)• Daten können nicht interpretiert werden (Formales Problem)

Konsistenz• Daten aus verschiedenen Systemen sind nicht identisch• Daten, die aggregierte und detaillierte Strukturen beschreiben passen nicht zusammen,

z.B. ist der Gewinn ungleich Umsatz minus Kosten

Vollständigkeit• Daten sind im Zuge der Anlieferung verloren gegangen• Die angelieferten Daten bestehen aus unvollständigen Datensätzen und haben

fehlenden Einträge (z.B. Personen ohne Vornamen)

Ausprägungen schlechter Datenqualität für vier Datenqualitätskriterien

[nach Apel et al.]



Datenerfassung• Nutzer tragen falsche Daten oder Daten falsch ein (z.B. beim Abtippen von Formularen)

Prozesse• Geschäftsprozesse führen zu unvollständiger oder unrichtiger Datenübergabe (ggf.

wegen des Datenschutzes sogar gewollt, wenn Externe beteiligt sind) Architektur

• Die verwendete Systemstruktur ist fehlerhaft, z.B. weil ETL-Prozesse nicht korrekt implementiert sind oder Datenfelder in Datenbanken falsch deklariert sind (1 „1“)

Definitionen• Unterschiedliche Beteiligte verstehen die Daten falsch und tragen nicht konsistente

Werte ein (z.B.: Brutto-Gewinn vs. Netto-Gewinn vs. Jahresüberschuss vs. EBIT) Datenverwendung

• Verwendung unterschiedlicher Systeme zur Datenveränderung führt zu Inkonsistenz Datenverfall

• Z.B. sind Adressdaten irgendwann veraltet

Ursachen schlechter Datenqualität

[nach Apel et al.]



Kosten schlechter Datenqualität

[http://www.cio.de/knowledgecenter/bi/838449/, abg. März 2012]

Beispiel Versandhandel10.000.000 registrierte Kunden

2 Kataloge pro Jahr

5% Rückläufer

Herstellkosten und Porto: 4€ / Katalog

Überschüssige Kosten durch Fehler in Adressdatenbank:

10.000.000 x 2 x 0,05 x 4€

= 4.000.000 €



Präventionskosten

• Personalkosten, wenn Mitarbeiter bei der Eingabe ein „Vier-Augen-Prinzip“ anwenden

• Schulungskosten zur Mitarbeitersensibilisierung

• Systemkosten für unterstützende Früherkennungsmechanismen

Entdeckungskosten

• Personal: Erstellung von Plausibilitätsberichten, die dann ausgewertet werden müssen

• System: Maschinelle Analyse

Bereinigungskosten

• Personal: Korrektureingaben

• Personal/System: Automatische/algorithmische Korrektur

Kosten zur Verbesserung der Datenqualität



Kostenschaukel für Datenqualität

Kosten

Datenqualität

Kosten durch schlechte Datenqualität

Kosten durch Maßnahmen zur Verbesserung

Sinnvolles Ziel für Datenqualität

[nach Apel et al.]

100%80%


Agenda




8.2 Organisatorische Unterstützung von Datenqualität

Rollen im Datenqualitätsmanagement

Umsetzung

Strategie/ Koordination

Datenqualitätslenkungsausschuss

Datenqualitätsmanager (zentral)

Data Stewards (dezentral)

[nach Apel et al.]

Vision/Strategie



Übergreifendes Gremium, das mit Vertretern von IT- und Fachseite besetzt wird

Entscheidung über Datenqualitätsstrategie und –maßnahmen

Koordination der Maßnahmen unterschiedlicher Bereiche

Enge Abstimmung mit der Linienorganisation und den operativen Datenqualitätsbeauftragten

Datenqualitätslenkungsausschuss



Unternehmensweite Koordination des Datenqualitätsmanagements

Information der Data Stewards über Änderungen der Strategie oder durchzuführende Maßnahmen in einzelnen Abteilungen

Kontrolle der Datenqualitätskennzahlen im Unternehmen (vgl. Abschnitt zur Datenqualitätsmessung)

Erste Schlichtungsstelle bei operativen Uneinigkeiten

Datenqualitätsmanager



Vertreter des Datenqualitätsmanagements in den einzelnen Abteilungen

Fachliche Data Stewards

• Z.B. in Controlling, Einkauf, etc. angesiedelt

• Festlegung von Verantwortlichkeiten für einzelne Systeme, Datensätze und Merkmale (z.B.: Wer pflegt den Produktstamm? Der Vertrieb oder die Produktion?)

Technische Data Stewards

• Definieren Datenflüsse und Messpunkte der Datenqualität

• End-to-end Betrachtung eines Systems und der Datenflüsse darin, d.h. Überprüfung, ob die erzeugten Daten und die eingegebenen Daten zusammenpassen

Data Steward


Einordnung je nach Organisationsform des BICC (virtuell, eigene Abteilung)


Verknüpfung der Rollen mit dem BICC-Rollenmodell

Leiter BICC


BI-Modellierer

BI-Architekt



…

Datenqualitätsmanager

Rollen fallen zusammen

Rollen unterstützen sich

Data Steward (fachlich)

Data Steward (technisch)


Agenda




8.3 Messen von Datenqualität

Datenqualitätskriterien alleine liefern nur den Überblick, was geprüft werden soll

Um Datenqualität messbar zu machen, müssen Datenqualitätsmaße eingeführt werden („Metriken“), die gewissen Ansprüchen genügen

• NormierungDie Ergebnisse jeder Messung müssen sich im selben Raum befinden, sonst kann ein Vergleich keine Aussage liefern

• KardinalitätDie Werte sollten zahlenmäßig gut erfassbar sein um eine zeitliche Vergleichbarkeit zu ermöglichen

• SensibilisierbarkeitMetriken müssen konkrete Anwendungen unterstützen können, allgemein formulierte Fragestellungen decken keine tatsächlichen Missstände auf sondern umschreiben sie

• Fachliche InterpretierbarkeitDer Ergebniswert (z.B. „5“) muss zu der Fragestellung eine sinnvolle Interpretation zulassen und nicht auf Basis willkürlicher Umrechnungen entstanden sein

Voraussetzungen



Messpunkte für Datenqualität


1

2

3

4

1. QuellsystemeErfassung der Daten (gültige Datumsformate, etc.)

2. ETL-Prozess / Staging AreaPrüfung der Ladeergebnisse auf Plausibilität, Vergleich zum letzten Ladeprozess

3. Data Warehouse (Datenbank) Kennzahlberechnungen, Geschäftslogiken, Aggregationen

4. Frontend-AnwendungenBerechnungen in Berichten, (manuelle) Schnittstellen zu weiteren Systemen


Metriken (Kennzahlsysteme) bilden die Grundlage für die Kennzahldefinition und lassen sich in drei verschiedenen Arten einteilen

• Formal-technischz.B. Anzahl der Datensätze, Anzahl der fehlerhaften Felder, Anzahl der NULL-Werte, Vergleichswerte

• Inhaltlichz.B. Häufigkeitsverteilungen (z.B. Benfordsches Gesetz für Häufigkeit der ersten Ziffer, Zeitreihenvergleiche, Min/Max-Validierungen)

• Qualitativz.B. Visuelle Prüfungen durch Anwender, Feedback der Nutzer/ Fachbereichsverantwortlichen

Metriken für Datenqualität


Agenda




8.4 Data Profiling

Einordnung

Data Profiling

Data Validation

Data Cleansing

Data ProfilingAnalyse vorhandener Datenbestände mit Hilfe automatisierter Verfahren zur Erkennung von Inhalt, Struktur und Qualität der Daten

Data ValidationPrüfung der Verwendbarkeit der Daten und Filterung von fehlerhaften/ nicht verwendbaren Daten (kann als Teil der beiden anderen Schritte verstanden werden)

Data CleansingEndgültiges Entfernen von Daten oder Ersetzen durch andere Daten/ Standardwerte/ Ableitungen, bzw. Anreichern der Daten zur Nutzbarmachung


8.4 Data Profiling

Attributsanalyse an einer Beispieltabelle

FeldName PERSON_ID NAME_ID BIRTHDATE INCOME CHILDREN

FeldTyp NUMBER TEXT DATE TEXT NUMBER1 Müller 1984-05-02 56.000 32 Schulz 1956-08-17 62.000 33 Meier 12.06.1977 51.000 14 Müller 1984/02/05 56.000 35 Fischer 1966-05-04 67.000 0

Attributnamen-Analyse

Frage: Passen Name des Attributs und Verwendung zusammen?

Fehler: „NAME_ID“ deutet auf einen Schlüssel hin, Schlüssel ist aber nur „PERSON_ID“

Datentyp-Analyse

Frage: Passen Typ des Attributs und Verwendung zusammen?

Fehler: „INCOME“ enthält nur Zahlwerte, ist aber als Text hinterlegt


8.4 Data Profiling

Attributsanalyse an einer Beispieltabelle

FeldName PERSON_ID NAME_ID BIRTHDATE INCOME CHILDREN

FeldTyp NUMBER TEXT DATE TEXT NUMBER1 Müller 1984-05-02 56.000 32 Schulz 1956-08-17 62.000 33 Meier 12.06.1977 51.000 14 Müller 1984/02/05 56.000 35 Fischer 1966-05-04 67.000 0

Wertebereichs-Analyse

Frage: Ist der Wertebereich stimmig in Bezug auf die erwarteten Daten?

Fehler: „CHILDREN“ hat überproportional häufig den Eintrag 3 (in größerer Datenmenge besser darstellbar)

Musteranalyse

Frage: Sind die Daten alle gleichartig eingetragen und damit auswertbar?

Fehler: „BIRTHDATE“ ist nicht immer im gleichen Format. Identische Datensätze („Müller“) sind damit nicht erkennbar


8.4 Data Profiling

Tabellenanalyse auf referentielle Integrität

FeldName PERSON_ID NAME_ID BIRTHDATE INCOME CHILDREN CITYFeldTyp NUMBER TEXT DATE TEXT NUMBER NUMBER

1 Müller 1984-05-02 56.000 3 42 Schulz 1956-08-17 62.000 3 23 Meier 12.06.1977 51.000 1 14 Müller 1984/02/05 56.000 3 45 Fischer 1966-05-04 67.000 0 5

FeldName CITY_ID NAME STATE COUNTRYFeldTyp NUMBER TEXT TEXT TEXT

1 Duisburg NRW Deutschland2 Essen NRW Deutschland3 Düsseldorf NRW Deutschland5 Stuttgart BaWü Deutschland


8.4 Data Profiling

Tabellenanalyse auf referentielle Integrität

FeldName PERSON_ID NAME_ID BIRTHDATE INCOME CHILDREN CITYFeldTyp NUMBER TEXT DATE TEXT NUMBER NUMBER

1 Müller 1984-05-02 56.000 3 42 Schulz 1956-08-17 62.000 3 23 Meier 12.06.1977 51.000 1 14 Müller 1984/02/05 56.000 3 45 Fischer 1966-05-04 67.000 0 5

FeldName CITY_ID NAME STATE COUNTRYFeldTyp NUMBER TEXT TEXT TEXT

1 Duisburg NRW Deutschland2 Essen NRW Deutschland3 Düsseldorf NRW Deutschland5 Stuttgart BaWü Deutschland

4 31

25

Erkennung „verwaister“ Daten


Agenda




8.5 Data Cleansing

Bereinigungsarten Löschen von fehlerhaften Datensätzen

Alle Datensätze, die mindestens einen fehlerhaften Eintrag enthalten, werden gelöschtProblematisch ist dabei

• Der mögliche Verlust vieler korrekter Daten

• Der Verlust, dass überhaupt eine Information bestand

• Die möglicherweise große Menge an Daten, die entfernt werden

Als Beispiel sei eine Kunden-Tabelle mit 30 Attributen (Name, Vorname, Letztes Bestelldatum, …) gegeben. Unter der Annahme, dass 5% aller Felder fehlerhaft sind, werden bei einem reinen Löschen ganze

1 – 0,9530 = 1 – 0,2146 = 0,7854 = 78,54% aller Daten gelöscht.


8.5 Data Cleansing

Bereinigungsarten Ersetzen durch andere Daten / Nachbilden von Daten

• Kundennummer kann ggf. über Name, Vorname, Adresse nachvollzogen werden

• Ort und PLZ durch externe Datenbanken abgleichen

Ableitung aus anderen Daten• Bilden eines Mittelwerte und Einsetzen dieses Wertes (z.B. für „Regelstudienzeit“ bei

Studiengängen, problematisch bei individuellen Auswertungen)

• Nachbilden von Summen durch Addierung von Einzelposten

Verwendung von Standardwerten• Z.B. Einstellungsdatum von neuen(!) Mitarbeitern auf „heute“ setzen

• Studienausweis: Verbleibende Laufzeit im Zweifel immer auf „Vier Jahre“ setzen


Date post:	18-Aug-2019
Category:	Documents
Upload:	vokiet
View:	214 times
Download:	0 times

Business Intelligence: Strategie und Organisation · Organisatorisches 09.04. Einführung in...

Documents