„Ich hab´ lieber alles auf einem Slide“ – ist so einer der Sätze, bei denen sich zuerst meine Augen weiten, dann die Nackenhaare aufstellen und es mir schließlich eiskalt den Rücken herunter läuft. In diesem Artikel zeige ich sechs häufige Fehler, die IT-Spezialisten bei Präsentationen vor dem Management machen und was sie dagegen tun können.
IT-Spezialisten, Architekten, Entwickler, Engineers und Systemadministratoren müssen effektiv mit ihren Stakeholdern kommunizieren. Gerade bei komplizierten IT-Themen sollte man auf Visualisierungen setzen und den eigenen Vortrag mit Grafiken und Diagrammen anreichern. Dabei gilt es, die Präsentation auf die Bedürfnisse der Zielgruppe auszurichten.
Meiner Erfahrung nach, teilt sich aber beim Thema „Präsentation“ das Lager der IT-Spezialisten grob in zwei Bereiche: die einen fühlen sich beim Zusammenfassen von Sachverhalten sehr unwohl, meist aus ihrer Liebe zum Detail heraus und ihrem Wunsch alles (wirklich alles) korrekt darzustellen. Die zweite Gruppe hält sich für die geborenen „Slide Creators“ und fasst für das Publikum viel zu viel zusammen – sodass die Zuhörer nur noch Bahnhof verstehen.
Damit Sie ein Gefühl dafür bekommen, wovon ich schreibe: hier ein weniger gelungenes Beispiel, an dem ich die sechs häufigsten Fehler schlichter IT-Präsentationen aufzeigen werde. Ziel der Präsentation war es, für diesen IT-Architekturentwurf eine Genehmigung des Architecture Review Board zu erhalten.
Die gesamte Präsentation umfasste noch weitere Slides, auf die ich nicht weiter eingehen will. Ich konzentriere mich hier lediglich auf die Präsentation der Architektur.
Die gewählte Darstellung wird das Publikum meiner Meinung nach verwirren, weil der Präsentierende folgende Fehler macht:
1. Gleichzeitige Darstellung von Struktur- und Ablaufinformationen
Das Slide beschreibt im wesentlichen die Abläufe zwischen Akteuren (employee und external customer ganz links), zwischen Systemen (im rechten Teil) und den sachlogischen Aufbau der IT-Systeme. Somit finden wir hier also drei Kernbotschaften in einem Slide:
- Der Kunde (external customer) möchte, dass ihm künftig unterschriebene Lieferscheine und Rechnungen per Email zugestellt werden.
- Der technische Request des employee muss in mehreren IT-Systemen verarbeitet werden, damit die Email mit Attachments erzeugt werden kann.
- Am gesamtem Ablauf sind 4 IT-Systeme beteiligt (von denen eines hier nur implizit sichtbar ist).
Meine These: selbst mit einer mündlichen Erläuterung hätten Sie diese drei Kernbotschaften nicht (sofort) verstanden. Das Publikum muss hier verwirrt sein.
Ich empfehle hier eine Aufteilung in drei Slides, jedes mit seiner eigenen Kernbotschaft. Dabei haben wir zwei Kernbotschaften bezüglich des Ablaufs (einmal auf der Business-Ebene und einmal auf der technischen Ebene) und eine Kernbotschaft bezüglich der künftigen Struktur der Systeme.
2. Vertrauen auf implizite Botschaften
Hätten Sie geahnt, dass der employee ein mobiles Terminal verwendet? Nein? Ich auch nicht. Hätten Sie gewusst, dass sein Request in das Salesforce System dupliziert wird, um die Bestellhistorie zu aktualisieren? Auch nein?
Natürlich dürfen Sie ihrem Publikum unterstellen, dass sie zu den intelligenten Lebensformen auf diesem Planeten gehören. Aber Hellsichtigkeit oder wahrsagerische Fähigkeiten sollten Sie nicht voraussetzen.
Machen Sie Informationen explizit, die sich ihren Zuhörern nur aus dem Zusammenhang ergeben oder die spezifisches Vorwissen erfordern. Halten Sie den Aufbau einfach und vermitteln Sie ihre Botschaften Stück für Stück. Denken Sie so, als wüssten Sie gar nichts oder nur wenig über die Materie.
3. Verwirrende Farbgebung
Der employee ist grün – welche Bedeutung hat das? Der external customer blau, genauso wie das Email-Symbol und das Salesforce System – hängen sie zusammen? Das System SAP ECC ist rot, ebenso wie die Pfeile ausgehend vom employee rot sind. Heißt das, es sind Schnittstellen basierend auf SAP?
Wenn Ich Ihnen sage, dass das Movilizer Addon eine Komponente ist, die im System SAP ECC installiert ist – stellt sich Ihnen dann auch die Frage, warum es NICHT ROT markiert ist?
Die Farbgebung auf diesem Slide ist nicht ansatzweise konsistent und vermittelt keine klare Botschaft. Tatsächlich wollte der Autor hier mit Hilfe der Farbgebung mehrere Botschaften vermitteln: bestimmte Abläufe und Systeme gehören zusammen (z.B. gelb für das System Movilizer) UND der external customer erhält ein Ergebnis basierend auf den Daten des Systems Movilizer.
Ich habe hier folgende Empfehlungen:
- Verzichten Sie auf Farben, wenn möglich (visualisieren Sie schwarz auf weiß)
- Verwenden Sie Farben zu logischen Gruppierung bzw. der Darstellung von Zugehörigkeit und niemals für zeitliche Abläufe (Pfeile sind also immer schwarz)
- Verwenden Sie Farben zur Hervorhebung oder Betonung bestimmter Sachinformationen, am besten unter Einsatz einer Legende
Wichtig ist, dass Sie sich je Slide für eine der Möglichkeiten entscheiden und nicht mischen. Farbe sollte immer nur eine Aufgabe für den Betrachter erfüllen und nicht mehrere.
4. Verzicht auf eine Notation
Wie Sie in den Slides sehen können, gibt es dicke und dünne Pfeile, Rechtecke, Kreise und ein LKW-Symbol (haben Sie es erkannt?).
Zunächst könnte man meinen, die Rechtecke stünden für Systeme – aber manche Rechtecke sind offenbar Bestandteile anderer Rechtecke (obwohl das nicht die technische Realität abbildet). Wiederum andere Rechtecke sind eigentlich Schnittstellen.
Das LKW-Symbol ist nicht durch einen Pfeil verbunden – was sagt das aus? Was bedeutet das LKW-Symbol überhaupt? Hätten Sie geahnt, dass es eine mobile Einheit für den Fahrer darstellt?
Durch Einsatz einer Notation können Sie die Aussagekraft ihrer Präsentation erheblich aufwerten. Konzentrieren Sie sich auf wenige Symbole und verwenden Sie diese konsequent und konsistent. Hier ein Beispiel für eine Notation. Die Applikation Salesforce sendet Daten an die Applikation SAP PI.
Warum viele Informatiker trotz guter Ausbildung immer noch auf Standard-Notationen wie BPMN, Archimate oder UML verzichten und stattdessen inkonsistente Eigenproduktionen herstellen, ist mir nicht klar. Vielleicht glauben sie, Notationen überfordern dass Publikum?
Tatsächlich ist die Überforderung für das IT-Management dann am größten, wenn jeder IT-Spezialist seine eigene Darstellungsform wählt. Herr Müller verwendet Kreise um Schnittstellen darzustellen – und Herr Meier verwendet dafür Rauten.
Mein Tipp: Einigen Sie sich auf Notationen im Unternehmen. Sie müssen nicht einmal alle Symbole verwenden, sondern sich einfach nur auf die wichtigsten einigen. Damit schaffen Sie eine einheitliche Darstellungsform und reduzieren die Sprachverwirrung zwischen IT-Spezialisten und Management.
5. Unpräzise Beschriftung
Der unpräzise sprachliche Ausdruck des Autors zieht sich durch das gesamte Slide beginnend bei der Überschrift. Laut dieser handelt es sich hier um eine „to be implementation“. Wie wir aber gelernt haben, sind hier die Informationen zum Prozessablauf mit den Informationen über den Systemablauf und die Systemstruktur vermischt. Es handelt sich also NICHT um ein Slide, das eine Soll-Implementierung darstellt.
Der folgende Untertitel widerspricht dieser Aussage auch sofort, denn dort ist die Rede von einem „new process design“. Dass es sich hier nicht um ein Prozessdesign handelt, dürfte auch klar sein.
Zusammen mit der unklaren Notation (siehe Punkt 4) ist dann auch die Beschriftung der Elemente unklar und inkonsequent. Einerseits verwendet der Autor den Systemnamen (z.B. SAP ECC), dann wiederum nur einen Bestandteil eines Systems (Salesforce Order History).
Ein weiterer Faux Pax ist die Duplizierung des Requests. Der employee startet einen Request, der in zwei Systeme gleichzeitig gesendet wird. Das ergibt sich aus einer eher unklaren Formulierung „(copy)“ – und hätte besser visualisiert werden können.
Meine Empfehlung: Stellen Sie sprachliche Klarheit her, indem Sie
- Eine Überschrift als klare Aussage formulieren
- Technische Systemnamen und Begriffe einheitlich verwenden
- Visualisieren und modellieren statt schriftlich verklausulieren
6. Darstellung wertloser Informationen
Achten Sie auf die Beschriftung der Pfeile. Wie wichtig ist die Information, dass die Übertragung an einer Stelle asynchron und an einer anderen in einem 60-sekündigen Pull-Mechanismus implementiert ist? Für sich genommen ist sie aussagelos. Um es aufzulösen: der Autor wollte nur unterstreichen, dass eine sofortige Auslieferung der Email technisch nicht möglich ist. Dafür hätte es sicher einfachere Darstellungsformen gegeben.
Was sagt Ihnen, dass der Pfeil zwischen SAP PI und Salesforce in beide Richtungen zeigt? Dass es sich um eine bidirektionale Schnittstelle handelt? Warum ist das wichtig?
Wie Sie sehen, enthält das Slide eine Reihe wertloser Informationen, die das Publikum in eine gedankliche Sackgasse führen. Das hätte der Autor vermeiden sollen und können.
Mein Tip: Bevor Sie eine Information aufschreiben oder visualisieren, sollten sie sich die Frage stellen, was genau ihre Botschaft ist. Fragen Sie sich einfach aus Perspektive des Publikums: „Na und, was soll das jetzt?“
Abschließende Bewertung
Man mag hier entgegen halten, dass Präsentationen unter „Fachleuten“ einen gewissen Anspruch haben und man vom Publikum erwarten kann, sich intensiv mit dem Präsentationsgegenstand auseinanderzusetzen. Und daher sei es ja nicht weiter schlimm, wenn das Slide „auf den ersten Blick“ verwirrend und aussagelos sei. Im mündlichen Vortrag dazu werde man das schon „gerade rücken“.
Wer so denkt, dem mangelt es aus meiner Sicht schon an der richtigen Einstellung, die es für eine qualitativ hochwertige Präsentation einer IT-Architektur braucht. Das Publikum braucht Sie in aller Regel sehr viel weniger, als Sie ihr Publikum. Und sei es auch nur, damit Sie vermeiden, dass ihre Kollegen von Ihnen den Eindruck gewinnen, sie seien ein schlampiger Stümper.
Seien Sie Dienstleister für ihre Kollegen. Helfen Sie ihnen, ihr Anliegen, ihr Design, ihr Projekt so schnell wie möglich zu verstehen. Entwickeln sie eine zentrale Botschaft für ihre Präsentation und leiten Sie daraus weitere Botschaften ab. Und je Botschaft gibt es ein Slide, nicht mehr und nicht weniger.
