Mit dieser Artikelreihe erörtern die Autoren Mag. Christian Gasperi und Markus Rotter, MA die Einführung, eines Comeptency Centers, in unserem Falle eines Business Intelligence Competency Centers (BICC), in die Organisationsstruktur einer KMU. Der Fokus liegt darauf seitens des Fachbereichs effektiv zu priorisieren (Fokus auf "das Richtige") und seitens der IT effizient umzusetzen (Fokus auf "das richtige Umsetzen"). Die einzelnen Fachartikel stellen dabei nicht nur ein Konzept vor, sondern stellen einen umgesetzten Ansatz im Bereich Business Intelligence dar, der sich auch auf andere Bereiche umlegen lässt.

Das BICC kann in einem Stack-Model beschrieben werden, welches folgende Grafik veranschaulicht:

Abbildung 1: Die Ebenen des BICC-Stack-Model

Neben der Kernaussage finden Sie in diesem Artikel auch einen Verweis auf die gesamten Artikel.

Ausgangsituation in vielen KMUs in der DACH-Region

Kernproblem: Das alltägliche Chaos

Die IT eines jeden Unternehmens ist maßgelbich am Erfolg beteiligt da sie als sogenannter „Enabler“ fungiert. Dabei spielt es keine Rolle ob wir von einem Konzern oder einer KMU sprechen, wobei mit aufsteigender Größe des Unternehmens auch die Prozesse linear komplexer werden. Dies beeinflusst in natürlicher Weise auch die Zusammenarbeit zwischen IT und Fachabteilungen. Um so wichtiger ist, dass die Kommunikation und Planung der angeforderten IT Arbeiten klar defniniert sind. Die Praxis zeigt jedoch, dass diese Prozesse/Kommunikation weit vom Ideal abweichen.

In den meisten IT Abteilungen ist für Development and Operations (DEV-OPS) ein Ticketsystem in Gebrauch, dass den Anforderungen der jeweiligen Organisation entspricht und von den Fachabteilungen angenommen und regelmäßig benützt wird. Betrachtet man jedoch projektbezogene Tasks, so fehlen in vielen Unternehmen konkret definierte Prozesse und Softwareinstallationen. In der Praxis, besonders bei KMU weit verbreitet aber auch ab und zu in großen Konzernen, wird Projektarbeit in einem Ticketsystem abgebildet. Dies ist oft eine Notlösung um Projekttasks abbilden zu können.

Hier möchten wir uns nicht auf etwaige Softwarelösungen des oben beschriebenen Problems konzentrieren, sondern eine mögliche Organisationsstruktur und deren Etablierung vorstellen. Dazu zeigen wir ein konkretes Beispiel: Die Einführung eines Business Intelligence Competency Center (BICC) in einem KMU.

IST-Situation:

Wie bereits erwähnt ist ein Ticketsystem in den IT Abteilungen ein etabliertes Instrument um Incidents/Fehler zu behandeln. Diese Tickets haben für alle IT Mitarbeiter die höchste Priorität und müssen in der Regel sofort bearbeitet werden. Bei Service Requests, also kleineren Änderungen am bestehenden System, ist die Priorität nicht mehr so eindeutig wie bei Incidents. Die Frage der Priorisierung stellt sich regelmäßig bei Projekten, die den größten Teil des Workloads einer IT-Abteilung ausmachen. Sind hier keine wohl definierten Prozesse vorhanden, prasseln Anfragen, egal ob Service Request oder Projektarbeit, auf die Mitarbeiter in der IT nieder und die IT droht zum Engpass, dem sogennanten Bottleneck, im Projekt zu werden.

In der Praxis wird dann oft nach dem Prinzip „First in - first out“ gearbeitet, unterbrochen von Eskalationen (Geschäftsführung/Vorstand) und daraus resultierender Arbeit an anderen Themengebieten. Eine solche Vorgehensweise führt dazu, dass die Mitarbeiter in der IT an einer hohen Frusttrationsrate und hohem Stressfaktor leiden. Sieht man sich diese Art zu Arbeiten im Unternehmenskontext an, so dauern Entwicklungen überdurchschnittlich lange, ergo steigen die Kosten für Projekte an, man hinkt der technologischen Weiterentwicklung hinterher und im schlimmsten Fall entsteht dem Unternehmen ein Wettbewerbsnachteil am Markt.

Die Frage lautet nun: Wie dieses Problem lösen?

Wir möchten drei verschiedene Ansätze aufzeigen und konzentrieren uns in dieser Serie auf Szenario drei; das BICC.

1. Aufstockung der IT Mitarbeiter

Eine Aufstockung des Personalstandes, um die oben beschriebene Situation zu lösen ist eine Variante, schlägt sich aber mit hohen Kosten für das jeweilige Unternehmen zu Buche. Außerdem ist dieser Lösungsansatz nur Symptombehandlung, da langfristig damit zu rechnen ist, dass mehr Anforderungen/Projekte erfasst werden, da mehr Personal vorhanden ist. Im Handumdrehen befindet man sich wieder in der gleichen Situation wie zuvor.

2. IT und Projektmanagement: Einführung einer konzernweiten Projektmanagementabteilung unter dem Dach der IT

Dieser Ansatz sieht vor, dass eigenes Personal für die organisatorische Ebene der Projekte eingestellt wird. Dies verursacht natürlich Kosten für das Unternehmen, ist aber im Ansatz nachhaltiger als Szenario 1. Der Vorteil dieser Variante ist, dass durch die Nähe zur IT und dem dort vorherrschenden Prozessdenken eine Symbiose entsteht. Des Weiteren werden keine Projekte ohne die Planung und Freigabe des Projektmanagements freigegeben. Es muss eine enge Abstimmung (Pflichten-/Lastenheft etc.) zwischen Fachbereichen und IT vor Entwicklungsbeginn erfolgen. Dies bedeutet aber einen zusätzlichen Overhead von ca. 30 bis 40 % in der Dauer von Projekten.

Vor Entwicklungsbeginn ist eine enge Zusammenarbeit zur genauen Definition der Requirements zwischen Fachexperten und IT notwendig. Nach Entwicklungsbeginn gibt es so gut wie keinen direkten Kontakt mehr zwischen IT und Fachbereich bezüglich Entwicklung.

Setzt man auf agile Methoden wie z.B. Scrum, wird die Koordination von Fachabteilung und Entwicklern ausschließlich von einem Productowner übernommen.

Ziel dieses zweiten Ansatzes ist es, den direkten Kontakt zwischen Entwicklern und Fachabteilung auf nötiges Minimum zu beschränken.

3. Einführung eines Competency Centers

Voraussetzug für ein Competency Center ist die Installation von Keyusern, die organisatortisch in den jeweiligen Fachbereichen situiert sind. Für diese Herangehensweise ist es zwingend notwendig, dass diese Person zsätzlich zur fachlichen Kompetenz auch eine IT-Affinität aufweist.

Im Vergleich zum 2. Ansatz wird der Kontakt zwischen Keyuser und IT Abteilung intensiviert, wobei alle Fehler, Anforderungen und Projekte nur mehr über diese Rolle kommuniziert werden. Im Gegensatz zu Ansatz 1 und 2 ist hierfür weniger zusätzliches Personal erforderlich.

Eine genauere Beschreibung des Keyuser Konzepts und Einführung eines Competency Center in eine Organisationsstruktur, in diesem Fall im Bereich Business Intelligence, erfolgt in unseren später folgenden Artikeln der Serie.

Keyuserkonzept

Durch das Einführen eines Keyuserkonzepts wird ermöglicht, dass seitens des Fachbereichs effektiv priorisert werden kann, wohingegen sich die IT voll auf das effektive Arbeiten konzentrieren kann. Die wichtigsten Punkte kurz zusammengefasst:

• Sämtliche offenen Punkte an einer zentralen Stelle gesammelt (Backlog)
• Priorisierung der Punkte mit Fokus auf die Punkte, welche für die Organisation am relvantesten sind
• Weniger Verluste durch Ineffizienzen und redundante Arbeiten
• Change Management bei der Einführung essenziell
• Keyuser-Lifecycle zur Sicherung der Nachhaltigkeit

Folgende Grafik fasst die Kernelemente zusammen:

Abbildung 2: Das Keyuserkonzept

Den gesamten Artikel finden Sie hier.

Das priorisierende Gremium (BICC)

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 3: 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. 

Den gesamten Artikel finden Sie hier.

Der Ablauf des kontinuierlichen Verbesserungsprozesses

Basierend auf ein implementiertes priorisierendes Gremium im Business Intelligence Competency Center (BICC) wird in diesem Fachbeitrag ein kontinuierlicher Verbesserungsprozess (KVP), der den jeweiligen Strukturen in den einzelnen Unterabteilung einer IT entsprecht beschrieben. In unserem Fall im Bereich Datenanalyse und BI. Jedoch kann das hier vorgestellte Grundgerüst auf jeden beliebigen IT-Prozess (Servicedesk, Serveradministration...) mit geringem Aufwand adaptiert werden. Im ersten Schritt werden die Autoren die notwendigen Rahmenbedingungen für die Implementierung erläutern. Im zweiten Schritt wird genauer auf den Ablauf des kontinuierlichen Verbesserungsprozesses (KVP) eingegangen. 

Das unten vorgestellte Modell soll überwiegend bei Projekten, Anpassungen (Changes) verwendet werden und soll nicht als Ersatz für das klassische Ticketsystem, in dem Incidents bearbeitet und gelöst werden, dienen.

Da wir uns in einem agilen Entwicklungsumfeld bewegen, müssen wir den Begriff eines Sprints kurz erklären. Ein Sprint ist eine definierte Zeitangabe, z.B.: 6 Wochen in denen die  definierten Arbeiten erledigt werden sollen. In unserer Implementierung eines BICC ist das ein Monat. In diesem Monat hat die IT die übergebenen Aufgaben des priorisierenden Gremiums zu vollenden. Für die Prozessbeschreibung beginnen wir am Anfang eines Monats, siehe Abbildung unten.

Abbildung 4:  Beispielhafter Ablauf eines kontinuierlichen Verbesserungsprozesses (KVP)

Eine nähere Beschreibung des Prozessablaufs finden Sie im Artikel zum KVP.

Die Definition von Kennzahlen

Bevor man an die Erstellung neuer oder Adaptierung vorhandener Kennzahlen denken kann, müssen diese ordentlich definiert werden.

Wichtig dabei ist, die Kennzahlen sinngemäß zu gliedern und eine unmissverständliche Interpretation zu gewährleisten. Die Relevanz von Metadaten und deren Verwaltung wird an dieser Stelle nicht näher beschrieben, ist aber für die Informationsarchitektur und den Erfolg des Umgangs mit Daten, nach Meinung der Autoren, von zentraler Bedeutung.

Neben betriebswirtschaftlichen Aspekten der Formel, Interpretation und Gliederungsmöglichkeiten, sollten auch technische Informationen (technische Bezeichnungen, Systemherkunft, etc.) definiert werden. Ebenso sollten an dieser Stelle auch die Anwender und das darauf aufbauende Berechtigungskonzept ebenfalls thematisiert werden. Ebenso zur Datenherkunft sollte auch die Datenverwendung ordnungsgemäß dokumentiert werden

Eine nähere Beschreibung des Prozessablaufs finden Sie im Artikel zur Defintion von Kennzahlen.

Change Management / Implementierung

Die Erstellung von Konzepten kann bereits sehr herausfordernd sein. Die Implementierung ist definitiv noch schwieriger, da diese neben fachlichen Fähigkeiten auch ein entsprechendes Repertoire an Soft-Skills erfordern. Viele Firmen nutzen hierzu externe Hilfe, um den Erfolg dieser Unternehmung zu gewährleisten. Denn schlechtes (oder nicht vorhandenes) Veränderungsmanagement kann die besten Konzepte zum Scheitern bringen. Dieser Artikel beschreibt die Vorgangsweise der Autoren, um mittels eines Leuchtturmprojekts, das Business Intelligence Competency Center (BICC), ein Keyuserkonzept voranzutreiben.

Folgende Grafik stellt den Prozess schematisch dar:

Abbildung 5: Ablauf der Einführung eines Keyuserkonzepts am Beispiel eines BICC

Es ist von zentraler Bedeutung für dieses Konzept, dass jegliche Veränderung in der Organisation einen Mehrwert darstellt, also keine Veränderungen nur der Veränderung wegen angestrebt werden. Die Schritte lassen sich in einmalige Prozessschritte (blau) und kontinuierliche Verbesserungszyklen (grün) einteilen. Zunächst wird, zum Beispiel in einem Workshop, eine Bedarfserhebung durchgeführt. Sollte Bedarf für ein derartiges Konzept bestehen, werden Prozess- und Umfeldanalysen durchgeführt, welche danach in weiteren Workshops mit Lösungsansätzen versehen werden. Nachdem die Rahmenbedingungen und Lösungsansätze klar sind, kann mit der (Projekt)Planung begonnen werden. Danach wird diese der Geschäftsführung präsentiert und nach dem Commitment (unerlässlich für den Erfolg) erfolgt eine Information über das Vorhaben an die weiteren Abteilungen. Gemeinsam werden nun die Lösungsansätze für jeden Bereich besprochen und angepasst. Die Einführung eines Prototypen dient als „Leuchtturm“, also als positiver Verstärker im Veränderungsprozess. Danach kann der Regelbetrieb aufgenommen werden.

Eine nähere Beschreibung des Prozessablaufs finden Sie im Artikel zur Nutzung eines BICC als Leuchtturmprojekt im Change Management.

Technische Umsetzung des Backlogs mit einem Ticket-Issue-System

Nachdem die organisatorischen Abläufe geklärt wurden, kann mit der Digitalisierung der Abläufe begonnen werden. Hierzu müssen die fachlich definierten Vorgänge in technisch abbildbare Prozesse überführt und die entsprechenden technischen Rahmenbedingen dafür geschaffen werden. Zusätzlich ist es sinnvoll, sich dabei an Rahmenwerken wie der IT Infrastructure Library (ITIL) zu orientieren.

Zur Veranschaulichung dient folgendes Beispiel:

Die/Der zuständige KeyuserIn für den Vertriebswürfel verwaltet drei Domänen: Kosten, Verkäufe und Preisfindung. Die AnwenderInnen  im Controlling haben ein schweres Problem mit den Daten und einen Verbesserungsvorschlag, ein/e ExpertIn im Vertrieb hat ein leichtes Problem und ein/e MitarbeiterIn im Pricing hat einen Verbesserungsvorschlag.

Folgende Grafik stellt diese Sachverhalte schematisch dar:

Abbildung 6: Schematischer Ablauf der Abhandlung von Problemen und neuen Anforderungen im Sales-Cube

Probleme werden im ITIL-Fachjargon als „Incidents“ und neue Anforderungen als „Changes“ bezeichnet. Oftmals kommt es zu Ineffizienzen, wenn diese Begriffe von MitarbeiterInnen ohne ITIL Know-How nicht korrekt abgegrenzt und falsch gehandhabt werden. Zum einfachen Verständnis werden Probleme in der Grafik in roter Farbe und einem „Totenkopf“ dargestellt, wohingegen neue Anforderungen und Ideen in grüner Farbe und einer „Glühbirne“ abgebildet werden.

Zur besseren Übersicht und Priorisierung nutzen größere Organisationen System, welche eine Verwaltung ermöglichen -> oftmals als "Ticketsystem" bezeichnet, aber eigentlich Issue-Tracking-System. Ein Incident oder Change wird in diesem System als „Ticket“ erfasst und mit allen notwendigen Informationen zur Bearbeitung versehen. Diese Tickets ermöglichen eine Priorisierung bzw. auch die Überwachung der Fortschritte und generell Informationen zur Zuverlässigkeit der IT-Systeme.

In der IT sollten Incidents grundsätzlich den Vorzug gegenüber Changes erhalten, da diese den Tagesbetrieb einschränken. Mit installierten Power- und KeyuserInnen ist es aber nicht notwendig sämtliche Incidents direkt an die IT weiter zu leiten. In erster Instanz kümmert sich der/die PoweruserIn um das Problem. Sollte es nicht lösbar sein, geht dieses an die/den HauptexpertIn der Domäne, der/dem KeyuserIn. Sollte dies auch nicht lösbar sein, so wird dieses Ticket an die IT weitergeben. Im Beispiel bedeutet das, dass das Problem im Vertriebsbereich (Domäne 2) direkt von dem/der PoweruserIn gelöst wurde und das Problem in der Kostenrechnung (Domäne 1) an die IT weitergegeben wurde. Der/Die KeyuserIn hat hierbei den vollen Überblick, wie viele und welche Probleme auftreten bzw. auch über den laufenden Bearbeitungsstatus. Die Changes werden in einen Pool gesammelt und der/die KeyuserIn kann danach über die Umsetzung entscheiden. Die wichtigsten Punkte werden in das Backlog überführt und dann die Umsetzung gemeinsam mit den KeyuserInnen der anderen Domänen (z.B.: Logistik, Human Ressources, etc.) priorisiert. Durch die transparente Abbildung der Changes und Incidents ist die Auslastung leichter greifbar und das Verständnis für Wartezeiten wird dadurch erhöht.

Weiterführende Informationen dazu finden Sie im Hauptartikel Technische Umsetzung des Backlogs mit einem Ticket-Issue-System.

Implementierung eines IT-Portfolio in ein Ticket-Issue-System

Ein funktionales Ticket-Issue-System ermöglicht die effiziente Verwaltung von IT-Agenden. Wenn das Ticket-System aber für weitere Agenden darüber hinaus verwendet werden kann, so steigert sich der Nutzen erheblich. Auf dieser Seite wurde bereits ein IT-Management-Portfolio thematisiert. Wenn das Ticket-Issue-System eine schnelle Erfassung von internen Aufgaben und die Darstellung aller Tickets in Form eines KanBan-Boards zulässt, so haben Sie eine großartige Möglichkeit zur abteilungsübergreifenden Steuerung geschaffen. Durch den gemeinsamen Zugriff mit den KeyuserInnen werden auch die Transparenz und die Zusammenarbeit verbessert.

Folgende Grafik stellt diesen Prozess schematisch dar:

Abbildung 7: Prozess der Abarbeitung von Tickets

Weiterführende Informationen dazu finden Sie im Hauptartikel Implementierung eines IT-Portfolio in ein Ticket-Issue-System

Erfolgsfaktoren und Stolpersteine

Veränderungsmanagement (Change Management)

Derartig tiefgreifende organisatorische Umgestaltungen sollten auf jeden Fall mit einem passenden Veränderungsmanagement (Change Management) durchgeführt werden. Dazu müssen die treibenden Kräfte entsprechende Fähigkeiten und Fertigkeiten haben.

Ebenso muss sich die Geschäftsführung, nach einer Kosten-Nutzen-Analyse, zu einer derartigen zukünftigen Handlungsweise bekennen und zunächst die oberen Managementebenen darauf einstimmen. Danach muss der Nutzen für die Organisation auf Fachkraftebene in den einzelnen Bereichen erkannt werden. Ein ganzheitliches Bekenntnis vereinfacht die Einführung bzw. beschleunigt vor allem den Prozess des Nutzengewinns. Das Ziel ist eine Ausrichtung dieses Prozesses an den Unternehmenszielen bzw. eine allgemeine Relevanz für die Anspruchsgruppen (Stakeholder).

Eine adäquate Kommunikationsstrategie (offen, regelmäßig und zielgruppenorientiert) ist hierbei ein zentraler Bestandteil des „Stakeholder Managements“, welches neben dem Projektmanagement einen zentralen Erfolgsfaktor darstellt. Es sollten dabei stets die passenden Methoden genutzt werden und die Aspekte der Organisation mit den Stärken der jeweiligen Methode im Change Management abgeglichen werden. Es macht beispielsweise keinen Sinn agile Methoden nur der Agilität willen zu nutzen, die Organisation muss einen Nutzen daraus ziehen.

Im Sinne der kontinuierlichen Verbesserung (siehe dazu KVP-Prozess) ist eine regelmäßige Betrachtung notwendig, auch nach Projektabschluss. Im Zuge dessen sollte auch eine ausreichende Dokumentation vorhanden sein.

Des gesamten Artikel finden Sie hier.

Ü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