Prozessdatenmanagement in der Entwicklung

Die Idee zu diesem Konzept stammt noch von meinem letzten kommerziellen Projekt, wo in einer frühen Produktentwicklungsphase grundsätzliche Fragen des Data-Loggings zu klären waren. Die damaligen Arbeiten waren sehr pragmatischer Natur, im Hintergrund wirkte aber schon die Idee eines durchgehenden Datenmanagements, von der Entwicklung bis zur Serienproduktion. Die damals noch vage Idee möchte ich in diesem mehrteiligen Artikel zu einem Konzept konkretisieren, das Sinn und Nutzen sichtbar werden lässt.

Überblick

Zielvorstellung

Auch die Entwicklung von Produkten oder Verfahren kann als Prozess gesehen werden. Warum also nicht, die Daten die dabei anfallen, als Prozessdaten bezeichnen? Die Masse wird wohl von den Messdaten bestimmt werden, die Relevanz kommt aber von den zugehörigen Metadaten. Wie soll man mit diesen Daten umgehen?

Ich denke die meisten kennen das: ein Projekt wird gestartet, eine Ordnerstruktur auf einem File-Share wird definiert und einige Templates werden erstellt. Und los geht’s. Bald darauf gibt es einen Zoo von Excel-Files, den keiner mehr überblickt. Wie eine Auswertung über viele Excel-Files machen? Die Frage der Automatisierung wird immer dringender. Excel VBA-Programmierung wird gestartet. Irgend ein Mutiger beginnt vielleicht mit Access. Der Weg zur Hölle hat begonnen.

Diese Vorgehensweise hat gravierende Nachteile. Es werden in der Entwicklung Weichen gestellt, die später, in der Produktionsüberleitung, nicht mehr geändert werden, weil sie die Validität und die Vergleichbarkeit der Daten in Frage stellen würden. Die Folgen sind bekannt:

• schlecht strukturierte Datensätze
• unzugängliche Metadaten
• unvollständige Auswertungen
• schwierig durchzuführende Korrelationen

Dem entkommt man nur, wenn man von Beginn an einen radikal anderen Ansatz der Strukturvorgabe verfolgt. Beginne mit:

• nachdenken
• Know-How erwerben
• Aufgaben definieren

Dabei das Zeit- und Kosten-Budget nur unwesentlich zu strapazieren, ist die Herausforderung. Ich behaupte, es geht! Den Nachweis möchte ich mit einem Lösungsvorschlag erbringen, der auf einer Data-Warehouse-Technologie beruht. Die wichtigsten Designkriterien aus der Sicht des Projektmanagements sind:

• Start mit wenigen, einfachen Elementen
• Skaliert ohne Systembruch bis zur Großserienfertigung
• Initialkosten gering
• Initial-Know-how überschaubar

Dem sind noch die Anforderungen des Anwenders hinzuzufügen:

• alle benötigten Datenquellen sollen eingespeist werden können
• alle benötigten Daten sollen einfach und schnell bereitgestellt werden

Vor allem die Anwenderanforderungen führen direkt zu einem Data Warehouse. Ein Data Warehouse lässt sich sehr gut mit einem Markt vergleichen.

Der Markt ist ein Platz, der viele Anbieter mit vielen Kunden vernetzt. Nicht zu unterschätzen ist auch die Funktion des einheitlichen Standplatzes, die für Übersichtlichkeit und einfache Zugänglichkeit sorgt. Dieselben Merkmale weist auch ein Data Warehouse auf. Es ist wirklich verblüffend, wie gut die Analogie von Markt | Stand | Kunde zu Data Warehouse | Data Mart | Anwender funktioniert. In den späteren Beiträgen wird das noch klarer hervortreten.

Die technischen Vorteile eines Data Warehouses im Vergleich zu Excel-Files oder Einzel-Datenbanken sind evident. Doch wie hoch sind die Kosten und wie steil ist die Lernkurve für den Anwender wirklich? Braucht es eine IT? Sind die Nachteile vernachlässigbar oder beeinträchtigen sie die Vorteile erheblich? Um diese Fragen geht es bei den Folgebeiträgen.