Eine Möglichkeit für die Duchführung eines Proof-Of-Concept für ein Datawarehouse

Bei größeren technischen Umstellungen sollte vor einem Implementierungsprojekt eine entsprechende Analyse des Nutzens und der Machbarkeit durchgeführt werden. Dazu kann ein „Proof of Concept“ (PoC) durchgeführt werden. Dieser Artikel beschreibt die Vorgangsweise des Autors bei einem PoC für die Implementierung eines neuen Data Warehouse Lösung. Das Vorgehensmodell kann aber auch auf andere Projekte umgelegt werden.

Der PoC sollte dabei in mehreren Phasen umgesetzt werden:

  • Planen des PoC
  • Organisatorische Rahmenbedingungen klären
  • Architektur erstellen
  • Infrastruktur bereitstellen
  • System konfigurieren
  • Implementierung durchführen
  • Auswertung der Ergebnisse

Folgende Grafik fasst diese Phasen zusammen:

Abbildung 1: Zusammenfassung der Vorgangsweise des PoC (Quelle: eigene Darstellung)

Ein PoC sollte meist im Rahmen eines kleinen (ev. informellen) Projekts durchgeführt werden (Anmerkung: Natürlich gibt es immer Ausnahmen und man sollte sich im Bedarfsfall nicht gegen ein notwendiges Projektmanagement zum PoC sträuben). Es ist in der Regel nicht notwendig daraus einen klassischen Projektstrukturplan zu erstellen oder umfangreiche Projektmanagementmethoden anzuwenden. Eine Darstellung wie oben mit hinterlegtem Zeitplan sollte sich im Normalfall aber als ausreichend erweisen. Zum besseren Verständnis wird die Analogie eines Hausbaus gewählt.

Analyse

Bevor konkrete Schritte eingeleitet werden, ist es sinnvoll sich die Zeit für eine ausreichende Planung und Analysen zu nehmen. Bei einem Hausbau sind nach der Entscheidung zum Bau auch einige Aufwände zur Planung und Analyse notwendig.

Mit der Analyse kein Lieferanten- oder Toolscreening gemeint (das sollte schon im Vorfeld gemacht worden sein), sondern eine konkrete Ablaufplanung des PoC. In diesem Schritt werden die Umfeldanalysen nochmals geprüft (oder erstellt, falls noch nicht vorhanden) und konkrete Zielgruppen definiert. Hier ist zu unterscheiden, ob es sich um einen rein technischen PoC handelt, oder ob auch Fachbereiche mitwirken sollten.

Nachdem das Gesamtbild und die Rahmenbedingen definiert sind, sollten der Umfang und die Ziele des PoC definiert werden. In diesem Schritt sollte geklärt werden, was am Ende gemessen und bewertet werden soll. Hier sollte auch ein Zeitplan erstellt und notwendige Ressourcen definiert werden.

Im letzten Schritt werden nun die Anwendungsfälle (UseCases) ermittelt und dokumentiert. Hier ist es wichtig konkrete Anwendungsfälle möglichst genau zu beschreiben, um den Mehrwert der potenziellen Implementierung bewerten zu können. Dabei sollten zum einen fachliche und technische Elemente bewertet werden. Für das konkrete Beispiel eines Datawarehouse wären das Erstellen und Präsentieren neuer Auswertungen, nutzbarer Standardinhalt oder das Verbinden mehrerer Quellen zur Betrachtung der Zusammenhänge Beispiele für fachliche Anforderungen, während die Anbindung, Implementierungszeiten, Prozesslaufzeiten, Bulk-Loads, Anpassbarkeit, Sicherheitsmerkmale, Disaster recovery, etc. Beispiele für technische UseCases sind. Die fachlichen UseCases können dabei sehr wohl auch technische Inhalte aufweisen.

Organisatorisches

Nachdem die notwendigen Rahmenbedingungen für das Haus geklärt worden sind, müssen diese in der Folge nun ermöglicht werden. Es wird geplant, welche Leute (im Regelfall sind oftmals Verwandte oder Freunde die glücklichen) einen Beitrag zum Hausbau leisten können und welche Kosten anfallen.

Für den PoC bedeutet das, dass nun die personellen wie finanziellen Ressource angefordert und freigeben werden. Das Projektbudget und der Zeitplan sollten ebenfalls genehmigt werden. Hierbei ist es wichtig dies mit einer entsprechenden Vorlaufzeit durchzuführen, damit die benötigten Ressourcen zur Verfügung stehen, wenn diese benötigt werden.

Architektur

Nachdem nun der Plan erstellt wurde und die entsprechenden Mittel zur Umsetzung bereitstehen, kann mit dem Design der Architektur begonnen werden. Ohne entsprechende Pläne des Grundstücks und des geplanten Hauses, macht das Hausbauen wenig Sinn

Dies ist auch für einen PoC notwendig, da auch hier ein Start ohne Plan kaum verwertbare Ergebnisse verspricht. Hier werden nun die Datenquellen für die UseCases definiert und ein entsprechendes Diagramm für jeden UseCase erstellt. Ebenso werden die benötigte Infrastruktur, Systemlandschaft und weitere technische Rahmenbedingungen definiert, um eine Bereitstellung in entsprechender Qualität zu ermöglichen.

Dieser Schritt kann auch Parallel zu der organisatorischen Abklärung stattfinden, sollte aber nicht vor einer konkreten Freigabe gemacht werden, um versunkene Kosten (sunk costs) zu vermeiden.

Infrastruktur

Wie beim Bau eines Hauses kann es nun nach der Fertigstellung der Architektur mit der Umsetzung des Rohbaus beginnen.

Das bedeutet für den PoC, dass entsprechende Server bereitgestellt werden. Danach kann eine entsprechende Testumgebung für das Datawarehouse eingerichtet werden. Dazu gehört das Einrichten einer Instanz und gegeben falls das Installieren von notwendigen Modellierungstools und Präsentationstools für den Fachbereich.

Konfiguration

Nachdem das Haus äußerlich fertig gestellt ist, kann es „konfiguriert“ oder angepasst werden. Das bedeutet, dass nun die Arbeiten innerhalb des Hauses stattfinden. Es werden Böden gelegt, Leitungen verlegt, Türen eingebaut, etc.

Für den PoC werden hierbei nun die Verbindungen zu den Quellsystemen hergestellt und notwendige Anpassungen (Customizing) durchgeführt. Dies kann von grundlegenden Systemeinstellungen, über Benutzeranlagen bis hin zu Sicherheitseinstellungen alles bedeuten. Erst nach einer kompletten Konfiguration, kann mit dem „Einzug“ begonnen werden.

Implementierung

Nachdem das Haus bezugsfertig ist, kann mit der Einrichtung begonnen werden. Hier werden nun die leeren Räume mit Möbel bestückt und das Haus bewohnbar gemacht.

Im Kontext des PoC bedeutet das, dass nun die definierten UseCases modelliert werden. Die Modellierung sollte so durchgeführt werden, wie dies für den Echtbetrieb vorgesehen ist, auch wenn dies unter Umständen mehr Aufwand als notwendig produziert. Die Bedingungen sollten aber so nah wie möglich an der Realität liegen. Parallel dazu sollten schon Schulungsunterlagen angefertigt werden, um einen Wissenstransfer im Falle einer Inbetriebnahme zu ermöglichen.

Nach der Modellierung sollten nun Tests durch die Fachbereiche oder andere Zielgruppen durchgeführt werden. Dabei sollten die bekannten Anforderungen auf Umsetzung kritisch geprüft werden. Abgerundet wird diese Phase durch die Generierung technisches Daten und Kennzahlen, welche dann im Folgeschritt bewertet werden.

Auswertung

Nach dem Bezug des Hauses wird nach einiger Zeit automatisch eine Zufriedenheitsanalyse durchgeführt. Das ist ein völlig natürlicher Vorgang. Hier endet die Brauchbarkeit der Analogie des Hausbaus, weil an dieser Stelle kaum jemand nach erfolgreichem Test ein weiteres Haus für das tatsächliche Wohnen bauen wird.

Für den PoC bedeutet das, dass nun die gewonnenen Erkenntnisse bewertet werden. Die UseCases werden nach vorher definierten Kriterien bewertet und die technischen Benchmarks mit bekannten Werten verglichen. Ein Ziel könnte zum Beispiel sein, dass die Präsentationsmedien eine Datenkonsumation nach den FASMI-Regeln (Das Akronym steht für Fast, Analysis, Shared, Multidimensional, Information) möglich ist.

Sollten die technischen und fachlichen Anforderungen erfüllt sein, müssen nun die Gesamtkosten für die geschätzte Lebensdauer der Lösung bewertet werden. In der Praxis wird hierzu gern der Total-Cost-of-Ownership-Ansatz (TCO) verwendet.

Da nun alle Aspekte bewertet wurden, kann nun über eine Weiterverfolgung der realen Implementierung nachgedacht werden. Im Idealfall lässt sich dabei einiges aus dem PoC wiederverwenden.

Schlussbetrachtung

Die hier skizzierte Vorgangsweise stellt keine Best-Practise dar, wurde vom Autor jedoch schon mehrmals (in adaptierter Form) angewandt. Diese Vorgangsweise kann nach inhaltlicher Anpassung eine gute Basis für andere PoC-Projekte außerhalb des Analytic- und Business Intelligence-Bereich darstellen.

Über den Autor

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.

Zurück

Übersicht der Artikel

Dieser Artikel fasst einen wissenschaftlichen Beitrag der ERP Future Research Konferenz 2017 zusammen und befasst sich mit einem Konzept über ein "Lean BI Framework für KMU"

Weiterlesen