Business Application Research Center

Experten für Business Intelligence, Analytics, Big Data, CRM und ECM

BARC-Newsletter

Warum Unternehmen neue Anforderungen nicht zufriedenstellend umsetzen können

Warum Unternehmen neue Anforderungen nicht zufriedenstellend umsetzen können

RssRss

15.07.2020

Warum Unternehmen neue Anforderungen nicht zufriedenstellend umsetzen können

Probleme und Lösungsansätze

Die Erfahrung aus verschiedenen BI-Strategie-Projekten bei unterschiedlichen Firmen und Branchen zeigt: Unternehmen tun sich schwer, neue Anforderungen umzusetzen. Fachbereichsseitig wird die Zufriedenheit des BI-Leistungsangebots nach wenigen Betrachtungsweisen erhoben. Dazu verwenden wir ein Kurz-Assessment oder einen strukturierten Fragebogen.

Durchschnittliche Zufriedenheit mit dem BI-Leistungsangebot über alle Unternehmen, sowie Bandbreite der Unternehmen-Ergebnisse (N=223)
Abbildung 1: Durchschnittliche Zufriedenheit mit dem BI-Leistungsangebot über alle Unternehmen, sowie Bandbreite der Unternehmen-Ergebnisse (N=223)
(5 = sehr zufrieden | 4 = zufrieden | 3 = geht so | 2 = unzufrieden | 1 = extrem unzufrieden)

Bei der Vertiefung in Workshops und in direkten Interviews zeigen sich immer wieder die gleichen Muster, die zu Unzufriedenheit führen. Wobei teilweise auch die Erwartungen etwas zu hoch sind: Wenn die Erwartungen als RfC (RfC = Request for Cange) formuliert sind, wünscht man sich die Lösung wäre gleich implementiert. Warten ist verpönt.

Nur teilweise liegen die Probleme in einer schlecht orchestrierten Architektur oder nicht zweckmäßigen Tools. Etwas häufiger sind technische Schulden die Ursache (siehe dazu mein früherer Blogbeitrag «Technical Debt – der langsame Tod für jedes Data Warehouse»).

In den meisten Fällen sind es jedoch organisatorische und methodische Mängel, gruppiert in vier Arten von Hindernissen.

Hindernis 1: Projekt- und Vorgehensmethodik

Eines der größten Problemfelder ist die Projekt- und Umsetzungsmethodik. Hier gibt es verschiedene Varianten der ineffektiven Vorgehensweise, von Pseudo-Agile bis Quick-and-Dirty.

In der Praxis haben sich zwar offiziell agile Vorgehensmodelle durchgesetzt, so zumindest die Meinung der Firmen. So hat ein Kunde mir vor kurzem erklärt, dass sie jeweils genau drei Sprints benötigen, die sie Spezifikation, Realisierung und Testen nennen.

Es ist ein typisches Beispiel dafür, wie weiterhin in den Phasen des traditionellen Wasserfall-Modells gearbeitet wird, nur das Wording wurde leicht angepasst. Agil ist höchstens der Lackanstrich der Projektmethode, also Pesudo-Agile.

Andere Unternehmen setzen zwar auf Scrum, jedoch mit zu kurzen Sprints von manchmal nur einer oder maximal zwei Wochen Dauer. Neben internen Meetings, Sprint-Start, Review und Retrospektive bleiben häufig nur noch ein paar wenige Tage zur Bearbeitung der Inkremente.

Das heißt, die eigentliche produktive Zeit für die Realisierung steht in einem krassen Missverhältnis zum Projekt-Overhead und zu Interna. Ein permanentes Deployment, beispielsweise auf der Basis von DevOps, wäre an dieser Stelle eine effektivere Lösung.

Viele Probleme entstehen nicht erst bei der Umsetzung, sondern schon deutlich früher. Nämlich durch ungenau definierte Anforderungen, ohne Priorisierung. Dadurch es kommt zu nachträglichen Abklärungen, Missverständnissen und unnötigen Changes. Durch die fehlende Priorisierung müssen zu viele Vorhaben realisiert werden.

In der Folge ist das BICC oder die IT permanent überlastet. An allen Themen wird zwar gearbeitet, nichts ist fertig und es entstehen unnötig viele Leerzeiten, um von einem zum anderen Task zu springen (Swap Time).

Hindernis 2: Priorisierung von Betrieb und Support

Interessanterweise wird der Betrieb in den meisten Firmen als gut bis sehr gut empfunden. Dies betrifft sowohl die Verfügbarkeit der Plattform als auch den Support. Genau hier liegt eine weitere Ursache: Übliche BI oder Analytics Competency Center (Abkürzung BICC) sind für Betriebsaufgaben und die Umsetzung neuer Vorhaben zuständig.

Dabei gilt die oberste Maxime: «Der Betrieb muss reibungslos laufen». Dies führt dazu, dass vereinbarte SLA-Leistungen deutlich übererfüllt werden (SLA = Service Level Agreement). Die Auswertung von vielen Incident-Statistiken zeigt, dass die Lösungszeit von Incidents üblicherweise deutlich unterschritten wird.

Ein weiterer großer Zeitfresser sind Service Requests und User Support. Meistens sind es ungenügend ausgebildete Anwender, die sich telefonische Unterstützung im BICC holen.

Diese nicht planbaren Arbeiten können schnell mehrere Stunden in Anspruch nehmen. Insbesondere dann, wenn es um Anfragen von ungenügend ausgebildeten Power Usern an das BICC geht. Zuerst benötigen diese Poweruser Unterstützung bei der Suche nach den Daten und danach muss schrittweise die Erstellung einer Analyse erklärt werden.

Diese Unterstützung wird zwar sehr geschätzt, doch es stellt sich die Frage, ob User Guidance überhaupt eine vereinbarte Aufgabe im Rahmen des SLAs ist.

Durch die obigen Aufgaben fehlt regelmäßig die Zeit, neue Vorhaben umzusetzen. Ein ausgewogenerer Umgang mit allen Aufgaben wäre wünschenswert.

Das bedeutet, dass ein marginaler Incident, der vielleicht nur punktuell zu einem Komfortverlust führt und das Weiterarbeiten in keiner Weise behindert, auch ein paar Tage liegen bleiben darf, anstelle von einer kurzen Lösungszeit, die nur für einen Notfall-Szenario angemessen ist.

Hindernis 3: Kein oder zu wenig Self-Service

Unternehmen nutzen die Möglichkeiten von Self-Service noch zu wenig, respektive durch die IT oder ein BICC behindert. Obwohl die Mitarbeiter in einem BICC permanent überlastet sind, wollen sie Aufgaben nicht abgegeben. Meistens aus der unbegründeten Angst, überflüssig zu werden und den Job zu verlieren. Dies wird dann versachlicht formuliert, mit Argumenten, wie «die Fachanwender kennen sich in den Datenmodellen zu wenig aus» oder «um diese Abfragen zu erstellen, sind Programmierkenntnisse notwendig».

Heutige Frontendtools sind in der Lage, genau diese Aufgaben zu kapseln und von Endanwendern fern zu halten, mittels semantischen Zugriffslayer, Automodelling-Funktionen oder Code-Generatoren mit grafischer Oberfläche.

Effektives Self-Service benötigt jedoch eine zentrale Koordination und verschiedene Formen der Unterstützung, wie Power User Circles, Aus- und Weiterbildungsangebote oder Self-Help-Portale und Wikis. Diese Aufgaben müssen ausgewählte Mitarbeiter im BICC steuern. Sie müssen sich vom Toolexperten zum Coach weiterentwickeln.

Andere Mitarbeiter werden dadurch entlastet und haben nun genügend Kapazität für IT-spezifische Aufgaben und neue Themen, beispielsweise Data Science und Advanced Analytics.

Hindernis 4: Ungenügende Qualität

Regelmäßig wird die abgelieferte Qualität von neuen Funktionen kritisiert. Bei einer genaueren Überprüfung zeigt sich, dass meistens die Kritiker auch gleich die Ursache sind. Anforderungen wurden zu unpräzise formuliert und in vielen Fällen fehlen messbare Akzeptanzkriterien, eine vollständige «definition-of-done». Somit erfolgt eine Umsetzung auf Annahmen und ein zielgerichtetes Testen ist nicht möglich.

Dazu kommen noch eine ungenügende Infrastruktur und ein zu geringes Wissen über Modelle und Methoden für effektive Tests. Das Ergebnis sind erhöhte Incidents nach dem Go-live.

Was zu einem effektiven Testmanagement gehört, habe ich in meinem früheren dreiteiligen Blog «Testen von BI- und DWH-Systemen» beschrieben. Hier die Links zum Nachlesen:


Ein weiteres Problem sind sogenannte Quality Gates. Diese wurden als Punkte zur Überprüfung der Qualität im Entwicklungsprozess durch ein Expertengremium definiert und haben den gleichen Zweck wie Meilensteine. Diese Überprüfungen finden jedoch nur in gewissen Zeitintervallen statt, beispielsweise nur alle zwei Wochen. Somit wird der Entwicklungsprozess immer wieder durch Wartezeiten unterbrochen.

In Kombination mit einem geringen Testreifegrad des Unternehmens, sind viele dieser Quality-Gates nicht effektiv und sie sind reine Spaßbremsen. Bei einem Kunden konnte aufgezeigt werden, dass diese Quality Gates den Entwicklungsprozess, je nach Timing, zwischen sechs bis zehn Wochen verzögern.

Bei agilen Vorgehensmodellen muss eine integrierte Qualitätssicherung angestrebt werden. Das heißt, sämtliche Quality-Gates sind konsequent abzuschaffen.

Lösungsansätze

Es gibt nicht das eine Patentrezept. Notwendig sind die Prüfung und Steuerung von mehreren organisatorischen Maßnahmen und die Veränderung der Methodik:

  1. Konsequentes Anforderungsmanagement (Requirement Engineering): Nur vollständig beschriebene Anforderungen werden priorisiert und frei gegeben. Die Erarbeitung der Anforderungen ist eine gemeinsame Aufgabe der Fachbereiche und des BICC’s.
  2. Agile Methoden mit integrierter Qualitätssicherung kompromissfrei anwenden: ohne Vermischung mit Wasserfall-Modellen oder Behinderung durch Quality Gates, lange Release-Zyklen, usw.
  3. Ausgewogener Ressourcen-Einsatz: keine einseitige Priorisierung von Betriebs- oder Supportaufgaben. Zukünftig werden Leistungen nur im Rahmen der SLA-Vereinbarungen erfüllt und nicht mehr übererfüllt.
  4. Entlastung schaffen durch effektives Self-Service: Das BICC muss nicht mehr alles selbst machen!
  5. Eliminierung von «Technical Debts», die zu Behinderungen und Workarounds bei der Entwicklung führen.

Gerne unterstützen wir Sie bei Fragen der Aufbauorganisation, Prozessgestaltung oder (Self-) Service-Modellen. Kontaktieren Sie uns.