4 Modellierung von Performance Management-Anwendungen (S. 112-113)

Nachdem die wesentlichen Grundlagen von CPM und den wesentlichen BI-Werkzeugen erarbeitet worden sind, soll in diesem Kapitel der Frage nachgegangen werden, wie sich umfassende Corporate Performance-Anwendungen realisieren lassen. Die Komplexität von entsprechenden Anwendungen wird häufig unterschätzt. Insbesondere werden die Integrationsaspekte vernachlässigt. Eine Ad-hoc-Erstellung von Hyperwürfeln oder eine inkrementelle Vorgehensweise ist daher in der Praxis leider immer noch der gängigste Weg. Häufig bewirkt dieses Vorgehen Restriktionen, die bei einer systematischen Vorgehensweise vermeidbar wären. Mittlerweile setzt sich jedoch mehr und mehr die Erkenntnis durch, dass CPM-Lösungen genauso systematisch entwickelt werden müssen wie transaktionsorientierte Systeme, für die es bereits zahlreiche Entwicklungsmethoden gibt.

4.1 Mögliche Anwendungsprobleme

Auslöser für die Diskussion um die Modellbildung in der Softwareentwicklung war die mangelnde Qualität der ausgelieferten Software. Software-Erstellung wurde bis dato eher als Kunst denn als ingenieursmäßige Vorgehensweise betrachtet. Während das so genannte „Muddling Through" („Durchwurschteln") bei kleinen Projekten nicht so auffällt, sind größere Projekte überhaupt nicht ohne strukturierte Vorgehensweise mit entsprechender Projektorganisation zu bewältigen. Im Business Intelligence-Bereich findet sich die gleiche Problematik, vielleicht mit dem wesentlichen Unterschied, dass die zur Verfügung stehenden Entwicklungswerkzeuge deutlich benutzerfreundlicher geworden sind und somit die explorative Bearbeitung komplexerer Fragestellungen erlauben. Mit einer strukturierten Vorgehensweise kann man sich trotzdem einige Überraschungen ersparen.

Der Lebenszyklus der meisten entscheidungsunterstützenden Systeme ist im Vergleich zu ERP-Systemen geringer. Die schnelle technologische Überalterung der Systemkomponenten dürfte dabei nur ein Grund von mehreren sein. Häufig werden in der Entwicklung bereits gravierende Fehler gemacht. Neben den „normalen" Projektschwierigkeiten gibt es auch konzeptionelle Schwachpunkte solcher Systeme. So wirkt sich die Auswahl „falscher" Dimensionen z. B. auf die Akzeptanz und die Wartbarkeit aus. Die folgenden Punkte geben einige häufige Anwendungsprobleme wieder (vgl. auch BARC, 2005): Das wesentliche Kernproblem dürfte darin bestehen, dass sich Auswertungswünsche mit dem fertigen System nicht befriedigen lassen. Dies kann vielfältige Ursachen haben. Oft fehlen Dimensionen bzw. Dimensionselemente oder Hierarchieebenen. Aber trotz vorhandener Dimensionen ist es häufig nicht möglich, die gewünschten Antworten zu bekommen. So wurden anstatt zweier getrennter Dimensionen alternative Hierarchien innerhalb einer Dimension aufgebaut. Kreuzberichte innerhalb der gleichen Dimension sind damit nicht mehr möglich.

Durch eine ungünstige Gestaltung der Hierarchien kann das Aufbauen bzw. das Verändern von Berichten unnötig komplex werden. Insgesamt kann die Administration aufwändiger werden.

Daten werden unkritisch aus Vorsystemen übernommen. Transaktionssysteme und Business Intellegence-Systeme unterscheiden sich jedoch grundlegend in Bezug auf die Modellierung. Aus Gründen der Kontierbarkeit kann es im Rechnungswesen beispielsweise notwendig sein, eigenständige Dimensionen zu einer Hauptdimension zusammenzufassen.

Das Wissen über Systeminterna ist notwendig, um zu aussagekräftigen Zahlen zu kommen. So gibt es häufig Fakten, denen kein sinnvolles Element einer Dimension zugeordnet werden kann. Daher werden häufig Standardelemente wie „Unspecified" angelegt.

Bei anderen Dimensionen, wie häufig bei der Zeitperiode, könnte jedoch alternativ die Vereinbarung getroffen werden, zeitlose Elemente der ersten Periode zuzuordnen. Um auf zugeordnete Werte zugreifen zu können, ist ein besonderes Wissen über diese Zuordnung notwendig.

Hierarchische Beziehungen werden nicht hinterfragt. So kommt es gelegentlich vor, dass hierarchisch übergeordnete Elemente nur in Bezug auf weitere Einschränkungen übergeordnet sind. Dieses Phänomen kann auch als komplexer Begriff bezeichnet werden. Auch im Rahmen der Prozessverdichtung ergeben sich ähnliche Probleme. So ist man ursprünglich von einer Hierarchie, d. h. von einer 1:n-Beziehung zwischen Teil- und Hauptprozessen ausgegangen. In vielen Fällen werden jedoch die gleichen Teilprozesse bzw. Aktivitäten für unterschiedliche Hauptprozesse erbracht.

Beziehungen zwischen Dimensionen bleiben unklar. Sehr häufig sind die Dimensionen nicht unabhängig, sondern stehen in Beziehung zueinander. Für Auswertungszwecke ist dies meistens unproblematisch. Bei der Notwendigkeit von Eingaben kann es jedoch zu massiven Integritätsproblemen kommen.

Die Berechnung abgeleiteter Daten wird komplex, wenn die gesamten Anforderungen in einem einzigen Würfel abgebildet werden sollen. Weil die Berechnungsreihenfolge unter Umständen nicht mehr transparent ist, treten leicht falsche Ergebnisse auf. Eine weitere Konsequenz ist, dass Änderungen nur schwer einzubringen sind.

Die Berechnungslogik wird nicht ausreichend analysiert. Dann ist es häufig der Fall, dass komplexe Berechnungen ausgelagert werden, obwohl die eingebaute Regelsprache eine solche Modellierung durchaus erlauben würde. Diese „built-in"-Sprachen sind meistens wesentlich problembezogener und damit leistungsfähiger als die klassischen 3GL-Sprachen.

Das Aufdecken von Anwendungsdefekten führt zu Änderungswünschen, die dann umgesetzt werden müssen. Dies führt jedoch zu dem Folgedefekt, dass Änderungen nicht eingebaut werden können, weil die Wirkungen aufgrund mangelnder Dokumentation nicht abgeschätzt werden können. Dieses Problem dürfte bei weitem nicht so gravierend wie bei operativen Systemen sein; vernachlässigen sollte man es trotzdem nicht. Die Performance lässt zu wünschen übrig. Auch hier kann eine entsprechende Datenmodellierung helfen.