From Chaos to Organization: Einführung eines BICC in einem KMU

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.

Ausblick auf die weiteren Artikel

Dieser Artikel befindet sich noch in im Aufbau.

Es werden noch folgende Konzepte behandelt:

  • Mögliche Stolpersteine

Ü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

 

Zurück

Übersicht der Leitartikel

Effiziente bzw. vor allem effektive Bearbeitung von IT-Anforderungen aus dem Fachbereich umsetzen

Weiterlesen