… oder wie man von einer (konkreten) Fragestellung zu einer EAM Visualization kommt.

Kennen Sie das? Der allgemeine Druck wächst zunehmend grafisch zu kommunizieren. In diesem Beitrag möchte ich zwei Varianten vorstellen, wie Sie, ohne Druck, den grafischen Kommunikationsbedarf decken können.

Variante 1: Eine fertige EAM Visualization verwenden

Man kann uns fragen und wir greifen auf unsere Erfahrung und über 100 Fragen und deren mögliche grafische Beantwortung zurück, siehe z.B. diese typische Fragestellung.

Dieser Fundus existierte jedoch nicht „schon immer“, und nicht immer finden wir dort etwas Passendes. In beiden Fällen gehen wir nach Variante 2 vor.
Das Vorgehen hinter Variante 2 beschreiben wir in diesem Beitrag an einem Beispiel, für das wir so tun, als wenn wir die Frage Wer nutzt was wofür noch nicht grafisch beantwortet hätten.

Variante 2: Eine neue EAM Visualization entsteht

Typischerweise kommen Unternehmen auf uns zu, die gerne in der Lage wären, bestimmte Fragen grafisch zu beantworten. Diese Unternehmen kann man grob in zwei Gruppen unterteilen.

1. Die Fragen und die Art der grafischen Antwort sind definiert und die Visualisierungen müssen nur noch realisiert werden. Man schreibt (gern gemeinsam, das kürzt Vieles ab) ein Lastenheft, wir dann ein Pflichtenheft, man einigt sich und wir entwickeln eine entsprechende Software auf Basis unseres Softwarebaukastens. – Darum soll es in diesem Beitrag explizit nicht gehen.
2. In der Regel möchten mehrere Personen gerne in der Lage sein, bestimmte Fragen für ihr Tagesgeschäft grafisch zu beantworten. Es existiert meist nur eine unvollständige Liste dieser Fragen und oft keine konkrete Vorstellung davon, wie die Ergebnisvisualisierungen aussehen sollen.

Für diesen zweiten Fall gehen wir üblicherweise wie folgt vor:

1. Mit Leuten sprechen

Stakeholder werden interviewt und die für sie interessanten Fragestellungen werden protokolliert. Danach werden die Fragestellungen konsolidiert und priorisiert. Die Priorisierung ist essentiell, denn irgendwann müssen die Daten, die visualisiert werden auch noch beschafft werden, was wiederum ein zeitintensiver Prozess sein kann.

Für dieses Szenario nehmen wir an, dass am Ende die folgenden sieben Fragen übrig bleiben:

1. Welche Kernprozesse gehören zum Geschäftsfeld Geschäftsfeld 1?.
2. Aus welchen Teilprozessen bestehen die Kernprozesse Kernprozess 1 und Kernprozess 2?
3. Welche Software unterstützt Teilprozess 2?
4. In welchen Arbeitsgruppen von Abteilung 1 wird das Softwaresystem System 1 genutzt und für welche Prozesse?
5. Welche unterschiedlichen Versionen haben wir von System 2 im Einsatz?
6. Wie viele Leute nutzen insgesamt System 2, haben wir genügend Lizenzen?
7. Welche Arbeitsgruppen gibt es in Abteilung 1?

2. Modellieren

Die Modellierungsphase läuft in der Regel in vier Schritten ab, in denen der Kunde lediglich bei der Beantwortung einiger Rückfragen unterstützen muss.

1. Elemente sammeln

Aus den Fragen leiten wir die notwendigen Modellelemente ab:

• Kernprozess
• Geschäftsfeld
• Teilprozess
• Arbeitsgruppe
• Abteilung
• Softwaresystem
• Softwareversion
• Nutzer
• Lizenz

2. Beziehungen identifizieren

Zusätzlich zu den Elementen selber identifizieren wir in den Fragen Beziehungen zwischen den Elementen:

• gehört zu zwischen Kernprozess und Geschäftsfeld: Ein Kernprozess gehört also zu einem Geschäftsfeld
• besteht aus zwischen Kernprozess und Teilprozess: Ein Kernprozess besteht aus mehreren Teilprozessen
• usw.

3. Ein Modell entsteht

Dann erstellen wir ein erstes Modell, das wir auch gleich benutzten, um Rückfragen z.B. bzgl. der Modellierung zu stellen:

• Kann ein Kernprozess zu mehreren Geschäftsfeldern gehören?
• Was ist der Unterschied zwischen Kernprozess und Teilprozess? Reicht es, dass es im Modell das Element Prozess gibt?
• Müssen wir wissen welcher Nutzer in welcher Abteilung arbeitet?
• usw./li>



• Aus unserer Erfahrung heraus vermuten wir, dass sich Arbeitsgruppen und Abteilungen als hierarchisch strukturierte Organisationseinheiten und ebenso Geschäftsfelder, Kernprozesse und Teilprozesse als hierarchisch geschachtelte Prozesse modellieren lassen. Wir passen das Modell also an.
• Softwareversionen und Lizenzen können als Attribute von Softwaresystemen modelliert werden.
• Wir brauchen das Element Nutzung, um die Frage 4 eindeutig beantworten zu können. Die Nutzung setzt die Organisationseinheiten, die Software und die unterstützten Prozesse miteinander in Beziehung.

Mit den geklärten Fragen aktualisieren wir das Bild:




4. Muster suchen und finden

Muster in dem Modell finden und diese, falls möglich, auf die generischen Visualisierungen abbilden (siehe Best-Practice-Visualisierungen). Falls dies nicht möglich ist, und für dieses Beispiel wollen wir das ja annehmen, gehen wir weiter so vor:

• Die beiden hierarchischen Strukturen Prozess und Organisationseinheit können wir mit unterschiedlichen Visualisierungen abbilden, z.B. mit der Graph- oder Cluster-Visualisierung. Beide eignen sich zur Visualisierung der vorliegenden Baumstrukturen.
• Das Element Nutzung setzt die beiden Baumstrukturen von Prozessen und Organisationseinheiten zueinander in Beziehung. Wenn wir die Bäume jeweils entlang einer Achse visualisieren und sich diese Achsen in einem Winkel von 90° zueinander befinden, so können die Daten der dreiwertigen Beziehung überschneidungsfrei mit ihren jeweiligen Bezugselementen der Bäume in Beziehung gesetzt werden. So ist die Matrix-Karte entstanden. Um es ein wenig schöner zu gestalten, kann man die Achse mit den Prozessinformationen auch mit entsprechenden Prozesspfeilen ausgestalten.
• Die anderen Modellelemente werden als Annotationen zu den Visualisierungselementen realisiert. Die Frage 6 von oben kann beantwortet werden, indem die Nutzerzahl als Ziffer an die Systeme und die angemessene / Über- / Unterlizensierung mit einem farbigen Symbol (angemessen: grün, über: gelb, unter: rot) deutlich gemacht wird.
• Frage 5 führt ebenfalls zu einem Attachment.

3. Eine neue EAM Visualization entwickeln

Hier liegt meist der größte Aufwand, denn die neue EAM Visualization muss programmiert werden. Je nachdem in welchem Kontext sie eingesetzt werden soll, müssen auch noch Input-Schnittstellen für Daten angepasst werden. Wichtig ist bei der Entwicklung darauf zu achten, dass alle Modellelemente korrekt und ansprechend wiedergegeben werden. Für Letzteres arbeiten wir bei Bedarf gern mit Kollegen vom Fach zusammen, da wir als Informatiker nicht unbedingt mit dem Auge für die schönen Dinge ausgestattet sind ;-).

Die neue Visualisierung und die Fragen, die zu ihrer Entwicklung und ihrem Design geführt haben, werden in unseren Fundus aufgenommen und warten dort auf ihren nächsten Einsatz. Nach diesem Vorgehen ist beispielsweise die Konsolidierungskarte entstanden.

4. Daten sammeln

Hier beginnt auf Seiten unserer Kunden in der Regel die Arbeit, die wir bei Bedarf auch unterstützen können. Denn entsprechende Datenquellen müssen identifiziert und nutzbar gemacht werden. Schließlich müssen die Daten ja irgendwie den Weg zu unserer Software finden, um visualisiert werden zu können. Typischerweise kommen folgende Quellen in Frage:

• Interviews mit Experten, Workshops
• Datenbanken anzapfen
• XML-Dateien auslesen
• Excel-Tabellen importieren

5. Visualisieren & fertig. Alle Fragen auf einen Blick beantwortet.

Wenn die Visualisierung am Ende vom dritten Schritt entwickelt ist und die Daten am Ende von Schritt vier vorliegen, dann kann unsere Software aus den Daten auf Knopfdruck ein Bild erzeugen. Es steht direkt in allen Ausgabeformaten zur Verfügung (PowerPoint, Visio 2007/2010/2013/2016, SVG, PNG). Ein mögliches Ergebnis sehen wir hier:

In der Abteilung 1 gibt es die beiden Arbeitsgruppen 1 & 2. Das System 2 wird für die Kernprozesse 1 & 2 genutzt, genauer für deren Teilprozesse 1.2 bzw. 2.1. Für den Teilprozess 1.2 wird System 2 in der Version 1.2 eingesetzt und für den Teilprozess 2.1 wird die Version 1.2 verwendet. Hier könnte man sich schon die Frage stellen, warum in der gleichen Arbeitsgruppe von der gleichen Software unterschiedliche Versionen genutzt werden (müssen)? Das grüne Nutzer-Symbol bedeutet, dass eine angemessene Anzahl an Lizenzen des System 2 vorhanden ist, um die insgesamt 50 Nutzer auszustatten. Die Systeme 1 und 3 sind leicht überlizensiert, was das gelbe Symbol andeutet (Unterlizensierung wäre schlimmer, daher ist dafür die Farbe rot reserviert).

Zusammenfassung

In diesem Beitrag habe ich unser übliches Vorgehen skizziert, das wir anwenden, wenn Kunden mit neuen Fragestellungen auf uns zu kommen, für die wir bisher noch keine fertige EAM Visualization im Köcher haben.