Dieser Fachartikel der Autoren Mag. Christian Gasperi und Markus Rotter, MA ist Teil der Artikelserie zum Thema "From Chaos to Organization: Einführung eines BICC in einem KMU”. 

Basierend auf einem implementierten Keyuserkonzept wird in diesem Fachbeitrag ein priorisierendes Gremium (im Bereich Datenanalyse das Business Intelligence Competency Center) beschrieben, welches die Geschäftsanforderungen beschreibt, priorisiert und das Ergebnis nach erfolgter Evaluierung freigibt. Im ersten Schritt behandeln die Autoren die notwendigen Rahmenbedingungen und mögliche Zielsetzungen. Danach wird das Business Intelligence Competency Center (BICC) beschrieben und wesentliche Prozesse veranschaulicht. 

Das vorgestellte Priorisierungsparadigma wurde für den Business Intelligence- bzw. Analyticsbereich entwickelt, kann jedoch auf andere Bereiche adaptiert werden. Zum Beispiel könnte man anstatt der Datenwürfel auch Module eines ERP-Systems zum Gegenstand machen. 

Der BICC-Regelkreis

In der Fachliteratur gibt es verschiedene Ansätze ein BICC aufzubauen. Es ist wichtig, hierbei kein generisches Modell zu nutzen, sondern die bestehende Organisation und die daraus resultierenden Bedürfnisse zu berücksichtigen. Der ERP-System-Anbieter SAP hat im Jahr 2013 bereits einen Ansatz beschrieben, wie ein BICC umgesetzt werden kann (den Artikel finden Sie hier). Dieser Aufbau ist im Bereich eines Konzernes durchaus angebracht, für KMUs und deren aktuellen Reifegrad erscheint den Autoren eine vereinfachte Form passender. Folgende Grafik stellt diesen dar: 

Abbildung 1: Der BICC-Regelkreis 

Die KeyuserInnen, welche die einzelnen Datenwürfel im Datawarehouse (DWH) fachlich verantworten, treffen regelmäßig zusammen und besprechen die wichtigsten Punkte der Gesamtheit der Anforderungen in den Backlogs (der einzelnen Würfel). In dieser Runde wird im Beisein relevanter IT-Experten die Priorisierung der offenen Punkte durchgeführt. Die IT setzt diese Anforderungen dann um. Die umgesetzten Anpassungen werden im Gremium dann final abgenommen. 

Es ist entscheidend die optimale Umsetzungsmethode zu wählen. Die Autoren empfehlen hierzu die Anpassungen nach Neuartigkeit und Komplexität zu bewerten. Ein gutes Modell hierzu ist das “Stacy Komplexitäts Modell”. Die Umsetzung ist Gegenstand des Folgeartikels der Autoren und wird an dieser Stelle nicht behandelt. 

Rahmenbedingungen

Für die Umsetzung ist es erforderlich für entsprechende Rahmenbedingungen zu sorgen.  

Bei Neuanpassungen („Changes“) ist das BICC der einzige Ansprechpartner (Single Point of Contact) zur IT. Diese Changes können auch von den PoweruserInnen in ein Ticketsystem oder ein vergleichbares Tool eingetragen werden. Vor der Weiterleitung an die IT werden diese Anfragen zunächst mit der/dem KeyuserIn abgestimmt und im Rahmen des BICC priorisiert und freigegeben. Direkte Zurufe von Nicht-KeyuserInnen werden von der IT nicht berücksichtigt. Dies gilt nur für Anpassungswünsche, Probleme werden nach wie vor direkt im 3rd Level Support behandelt. Daher ist eine entsprechende Disziplin bei der Erstellung der Tickets sehr wichtig. 

Des Weiteren ist es wesentlich, dass für die Keyusertätigkeit ausreichende personelle wie finanzielle Ressourcen zur Verfügung stehen. Die Tätigkeit der KeyuserInnen ist von zentraler Bedeutung für die effektive Ausrichtung der IT an die Bedürfnisse der Fachabteilungen, daher müssen diese wertvollen MitarbeiterInnen über ausreichend Zeit und Mittel für die Ausübung der Tätigkeit bzw. für Schulungen verfügen. Ebenso muss ein Wissenstransfer an die PoweruserInnen stattfinden können. Zu guter Letzt muss diese Stelle auch entsprechend dotiert sein. 

Die EntscheidungsträgerInnen (KeyuserInnen) sind hierarchisch auf der selben Stufe wie die anderen KeyuserInnen der anderen Fachgebiete und innerhalb ihrer Domäne mit voller Entscheidungsbefugnis hinsichtlich der Prioritäten und Planungen ausgestattet. Es müssen Entscheidungen ohne Rückfragen möglich sein und das „Ober sticht Unter“-Prinzip bzw. politische Entscheidungen sind in diesem Gremium nicht gestattet. Besonderes Augenmerk muss auch auf die Koordination bei domänenübergreifende Themen gelegt werden, denn diese werden ohne fehlende Hauptzuständigkeit gerne vergessen. 

Das BICC kommt in einem definierten Rhythmus (z.B.: monatlich) im Beisein der IT zusammen. Dabei gilt das Grundprinzip, dass bereits gestartete Aufgaben grundsätzlich erledigt werden, bevor neue begonnen werden. Halbfertige Zwischenlösungen darf es nicht mehr geben. Die Aufgaben im Backlog können jedoch laufend neupriorisiert werden, um die Effektivität zu wahren.  

Es muss eine Verpflichtung aller Beteiligten zum Fokus auf die Ziele des BICC geben. Dabei wird stets versucht emotionslos „das Richtige zu tun“, also das Prinzip der Effektivität als oberste Direktive zu verankern. Wissenstransfer muss stattfinden und die „Datenwahrheit“ gewährleistet sein. Wenn die umgesetzten Arbeiten das „Gütesiegel“ des BICC erhalten, dann ist gewährleistet, dass die Daten stimmig sind und gruppen- oder konzernweit ein einheitliches Verständnis der Kennzahlen vorliegt. Es gibt keine Kennzahl in Berichten, ohne das Wissen des BICC. Die optimale Arbeitsweise muss stets angestrebt werden (nicht immer ist z.B.: agil auch die beste Methode) und die IT hat einen kompetente(n) AnsprechpartnerIn. 

Der Measure-Cycle

Die Kennzahlen in den Berichten werden nun mittels eines laufenden Prozesses (die Autoren nennen diesen den „Measure-Cycle“) von der Idee bis zur Deaktivierung betreut.

Folgende Grafik stellt diesen Prozess dar: 

Abbildung 2: Der Measure-Cycle 

Ähnlich wie bei Projekten beginnt alles mit einer Idee oder einem Bedarf. Diese Idee wird zunächst domänenintern (z.B.: eine neue Bewertungsmethodik des Service Grads im Supply-Chain-Management Datenwürfel) besprochen. Sollte die/der KeyuserIn entscheiden dies weiterzuverfolgen, wird diese Idee nun im BICC besprochen und über eine Umsetzung entschieden. 

Bei positivem Entschluss wird der IT der Auftrag zu Umsetzung erteilt. Dabei ist wichtig, dass bereits in diesem Schritt eine ordentliche Dokumentation durchgeführt wird (an dieser Stelle verweisen die Autoren auf einen anderen Artikel zur Dokumentation von IT-Services). Danach wird mit der Entwicklung begonnen und eine Abnahme durchgeführt. 

Um die Nachhaltigkeit zu gewährleisten, müssen die Kennzahlen laufend auf fachliche Richtigkeit geprüft und gegebenenfalls adaptiert werden. Eine gute Dokumentation bzw. ein Verwendungsnachweis der Kennzahl sind hierzu zwingend zu nutzen, um Schiefstände zu vermeiden. 

Sollte diese Kennzahl nicht mehr benötigt werden, wird diese deaktiviert und aus sämtlichen Berichten entfernt. 

Schlussbetrachtung

Das BICC stellt aus Sicht der Autoren eine sehr gute Möglichkeit dar, die Integrität eines Datawarehouse zu gewährleisten und dabei stets auf die Anforderungen der Unternehmung zu reagieren. Die geschilderte Vorgangsweise kann auf andere Domänen (z.B.: ein ERP-Modul, Datenaustausch mit Office 365, etc.) umgelegt werden. Die Basis hierzu ist das bereits geschilderte Keyuserkonzept.  

Das hier vorgestellte BICC stellt einen Startpunkt dar und kann mit der Zeit und bei Bedarf um weitere Agenden wie z.B.: Data Governance oder Metadaten-Management erweitert werden. Die Autoren werden im Folgeartikel dieser Serie einen agilen Ansatz zur Umsetzung von Anforderungen und Projekten erläutern. 

Über die Autoren

Mag. Christian Gasperi	Markus Rotter, MA
Mag. Christian Gasperi ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit Business Itelligence, Datawarehousing, Geoinformatik, Datenbanken, IT-Architkur, Systemarchitektur, Projektmanagement und lateraler Mitarbeiterführung gemacht.	Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.
Homepage	Homepage
Xing Profil	Xing Profil