Kontinuierlicher Verbesserungsprozess

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

Die notwendigen Rahmenbedingungen

Voraussetzungen für die organisatorische Einführung eines KVP in ein Unternehmen sind:

  1. Keyuser Konzept
  2. Priorisierendes Gremium (BICC)
  3. Agile Arbeitsweise

Auf die ersten beiden Punkte möchten die Autoren nur kurz eingehen und auf die bereits bestehenden Artikel in dieser Serie verweisen.

Keyuser Konzept:

Die Grundlage des unten beschriebenen Prozesses ist ein bereits implementiertes Keyuser Konzept damit die Anforderungen aus den einzelnen Fachbereichen jeweils beim Keyuser eingelangen. Dessen Aufgabe besteht darin die bestehenden Themen fachlich abzuklären, zu priorisieren, die Sinnhaftigkeit zu beurteilen und klare Aufgabenstellungen der IT weiter zu leiten. Im Idealfall kann er kleinere Aufgaben selbstständig lösen und dazu beitragen die Mitarbeiter/-innen in der IT zu entlasten. Daher ist diese Position höher einzuorden als eine Stelle als Sachbearbeiter.

Priorisierendes Gremium:

Als zweiten Baustein muss ein priorisierendes Gremium, das in regelmäßigen Abständen tagt, vorhanden sein. Es setzt sich aus allen KeyuserInnen der Fachbereiche in einem Unternehmen und relevanten IT-ExpertInnen zusammen. Hier werden die jeweiligen Anforderungen aus den verschiedenen Disziplinen besprochen und priorisiert. Eine weitere Aufgabe ist die finale Abnahme der abgeschlossenen Arbeiten.

Agile Arbeitsweise:

Der dritte und letzte Grundbaustein für die Implementierung eines KVP ist die Agile Arbeitsweise in der IT. Eine detaillierte Beschreibung der vorhandenen Methoden wie KANBAN oder SCRUM würde den Rahmen dieses Artikels sprengen. Daher möchten die Autoren nur auf die ihnen am wichtigsten erscheinenden Punkte eingehen. 

Unsere eindeutige Empfehlung für den Start von agilen Methoden ist KANBAN, da hier schon die Grundideen der agilen Arbeitsweise gut und einfach vermittelt und implementiert werden können. Zu Beginn ist es auch nicht notwendig sich teure Softwareprodukte anzuschaffen - „good old plain analog“ ist genug. Was meinen wir damit, suchen sie sich einen Raum mit einer großen leeren Wand und beginnen Sie mit „Post-it“, das reicht für den Anfang völlig aus. 

Einige Worte möchten wir jedoch noch zur Teamstruktur, mit dem Sie agiles Arbeiten starten wollen, verlieren. Die Teammitglieder sollten zumindest alle, bzw. der Großteil, schon einmal gemeinsam an einem größeren Projekt (mehr als 3 Monate) gearbeitet haben. Des Weiteren müssen die Rollen (Stellenbeschreibungen) klar definiert sein, damit für jede Art von Aufgabe sich der/die jeweilige(n) Mitarbeiter zuständig fühlt/fühlen. 

An dieser Stelle wird sich die/der Lesende vielleicht fragen für welche(s) Projekt/Arbeiten sich eine agile Vorgehensweise eignet. Hier möchten die Autoren auf das VUCA (volatility, uncertainty, complexity, and ambiguity) bzw. das Cynefin framework oder das Stacy Komplexitäts Modell verweisen. Können Sie ihre Arbeit bzw. Projekte dort einordnen, sind Sie richtig in der Agilität. 

Zu guter Letzt noch ein organisatorischer Punkt, der wohl den wichtigsten Punkt für agiles Arbeiten darstellt. Die Führungsebene muss in den Hintergrund bei der Steuerung von agilen Projekten treten, das übernimmt das zukünftige (agile) Team. In der Praxis scheitert häufig die Einführung von agilen Methoden genau an diesem Punkt. 

Der Ablauf des kontinuierlichen Verbesserungsprozesses

Da nun die nötigen Grundlagen erläutert wurden möchten sich die Autoren nun auf die Beschreibung es KVP Prozesses konzentrieren.

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 1:  Beispielhafter Ablauf eines kontinuierlichen Verbesserungsprozesses (KVP)

Der sogenannte Sprint beginnt immer für die Experten/-innen der IT am Monatsanfang und endet am letzten Tag des jeweiligen Monats. Dieser Zeitraum wurde so gewählt, weil dieses Zeitfenster einem natürlichen Kreislauf entspricht.

Während dieser Entwicklungsphase ist es dem Fachbereich grundsätzlich erlaubt neue Themen in den Backlog zu schieben. Jedoch dürfen keine neuen Anforderungen zu dem bereits in Umsetzung befindlichen Themen gestellt werden. Sollte jedoch durch eine plötzliche Wendung die Entwicklung obsolet sein, ist dies gestattet. Es wird dann mit der Entwicklung der nächst höheren Priorität im Backlog begonnen.

Eine laufende Abnahme durch den Fachbereich ist während des Sprints möglich und erwünscht.

In der Mitte des Monats findet das BICC Jour Fixe (priorisierendes Gremium) statt. Die dort eingebrachten Umsetzungsaufgaben sind soweit ausgereift und beschrieben, dass die IT sich bereits ein Bild der notwendigen Aufgaben zur Umsetzung machen kann. Die KeyuserInnen der einzelnen Fachbereiche priorisieren gemeinsam die jeweiligen offenen Themen. Wobei zu erwähnen ist, dass es pro Priorität jeweils nur ein Thema geben kann, das heißt Priorität 1, 2, 3 kommen nur einmal vor. Sollten noch Aufgaben aus dem Vormonat in der Entwicklung bei der IT offen sein, so werden diese automatisch auf Priorität 1 gestellt. Diese Vorgehensweise soll verhindern, dass viele Aufgaben begonnen, jedoch nie beendet werden.

Des Weiteren erfolgt die finale Abnahme der bereits abgearbeiteten Themen aus dem Vormonat, die IT holt sich hier für geleistete Arbeit sozusagen das Gütesiegel des Gremiums ab. Unmittelbar nach dem BICC Jour Fixe beginnen die Abstimmungen zu noch offenen Fragen zwischen IT und Fachbereich bezüglich umzusetzender Themen, wobei hier nicht nur die Aufgabe mit höchster Priorität, sondern auch Priorität 2, behandelt werden sollen. Sobald die letzten offenen Fragen bzw. Spezifikationen zwischen IT und Fachbereich geklärt wurden kann mit der Sprintplanung begonnen werden. Hier werden die umzusetzenden Themen in möglichste kleine Aufgabengebiete unterteilt und beschrieben. In diesem Schritt sind die IT ExpertInnen nur teilweise involviert, wichtig ist jedoch, dass am Beginn des Sprints die Aufgaben klar definiert sind und die Teammitglieder sofort mit der Arbeit starten können. Die Zielsetzung hierbei ist, den Entwicklern die Möglichkeit zu bieten, während des Sprints ohne große Störungen an den jeweiligen Aufgaben arbeiten zu können. Am Anfang des Folgemonats beginnt die Umsetzung der priorisierten Themen, die Mitte des aktuellen Monats vom BICC Jour Fixe beschlossen wurden. Somit wiederholt sich der oben beschriebene Prozess.

Schlussbetrachtung

Durch die Einführung eines KVP wird mit dem BICC Jour Fixe garantiert, dass die Anforderungen des Fachbereichs sich mit der Strategie des Unternehmens decken und keine unnötigen Insellösungen geschaffen werden. Für die IT ergibt sich daraus ein klar definierter Handlungsstrang in der Umsetzung von Projekten. Dementsprechend können vorhandene Ressourcen besser geplant und auf Engpässe vorab hingewiesen werden. Dies führt zu einer besseren Planungssicherheit von (IT) Projekten. Ein weiterer Vorteil besteht darin, dass die Fachbereiche einen ständigen Fluss von gelösten (Teil) Aufgaben erhalten, dies führt unweigerlich zu Erhöhung der Zufriedenheit. Des Weiteren ist der beteiligte Personenkreis durch das monatliche BICC up-to-date bezüglich der Fortschritte der jeweiligen Projekte in der IT.

Dieser erhöhte Durchsatz an den richtigen IT-Lösungen kann zusammenfassend als signifikante Effektivitätssteigerung wahrgenommen werden.

Ü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 Artikel

Dieser Beitrag stellt die wichtigsten Erkenntnisse des BARC Trend Monitors 2019 vor.

Weiterlesen

Dieser Artikel beschreibt ein mögliches Konzept für ein Datawarehouse, welches sich an den Prinzipien der Bimodalität und der logischen Integration orientiert.

Weiterlesen

Dieser Artikel beschreibt einen Ansatz. um ein IT-Service zu definieren und zu dokumentieren.

Weiterlesen

Dieser Artikel stellt eine Möglichkeit drojekte im Reporting- und Analyticsumfeld umzusetzen dar.

Weiterlesen