Slide-Teardown: Die Zielarchitektur-Slide im IT-Consulting
Die Zielarchitektur-Übersicht ist die Slide, an der IT-Beratungen ihre Kernkompetenz zeigen — und die im Termin am häufigsten mündlich erklärt werden muss, weil sie sich nicht selbst erklärt. Sie wird im Angebot gezeigt, im Architektur-Board diskutiert und im Lenkungskreis entschieden. In diesem Teardown zerlegen wir eine typische Zielbild-Slide eines ERP-Programms in ihre vier zentralen Produktionsprobleme und zeigen das Redesign.
Hinweis zur Methodik: Die gezeigte Ausgangs-Slide ist ein rekonstruierter Archetyp — das Zielbild einer fiktiven ERP-Transformation mit vier Streams, einem Plattform-Kern und den zugehörigen Umsystemen. Die Muster stammen aus realen Architektur-Präsentationen.
Die Ausgangslage
Der Kontext: die Zielbild-Slide eines ERP-Programms — vier Streams für Core-ERP, Integration, Daten und Analytics, ein Plattform-Kern, die Umsysteme und die begleitenden Architektur-Prinzipien. Inhaltlich ist die Slide bemerkenswert vollständig. Sogar die Erzählstruktur ist vorhanden: die Prinzipien, die Programm-Zielsetzung und eine Kernaussage, die das Zielbild in einem Satz zusammenfasst. Das Problem: Der Titel verspricht ein integriertes Zielbild, die Slide zeigt ein Nebeneinander. Die Ordnung, die im Inhalt steckt, ist im Bild nicht zu erkennen.
Die Diagnose: Vier Produktionsprobleme
Wie immer vorab: Keines der folgenden Probleme ist ein Inhaltsproblem. Die Architektur ist richtig gedacht, die Streams sind sauber geschnitten, kein Baustein ist zu viel. Bei Architektur-Slides ist der Preis der fehlenden Produktionsebene allerdings besonders hoch, denn diese Slide hat einen doppelten Auftrag: die Lösung erklären und dabei zeigen, dass der Dienstleister Komplexität beherrscht.
1. Der Plattform-Kern ist nicht als Zentrum erkennbar
Die zentrale Aussage der Slide steht im Titel: vier Streams, ein integriertes Zielbild. Das verbindende Element dieser Integration ist der Plattform-Kern — Business Tech, Daten-Layer, API-Gateway und Event-Mesh. Auf der Vorher-Slide steht dieser Kern als gewöhnlicher Kasten in der Ecke: gleiche Größe, gleiche Kontur, gleiche Typografie wie alles andere. Die Integrations-Logik existiert damit nur im Text. Ein Betrachter, der die zentrale Rolle des Kerns nicht sehen kann, muss sie sich erklären lassen — und genau das passiert dann im Termin.
2. Zusammengehörige Elemente sind nicht als Gruppen erkennbar
Die Slide enthält klar definierte Gruppen: vier Streams, vier Ebenen des Plattform-Kerns, zehn Umsysteme, sieben technische Enabler. Auf der Vorher-Slide sind Umsysteme und Enabler zu einer ungeordneten Fläche kleiner Kästen vermischt - gemischte Reihenfolge, springende Größen, drei verschiedene Füllfarben, ein Label für zwei verschiedene Gruppen. Kein Element steht falsch, und keine Zuordnung wurde verändert. Aber der Betrachter kann die Gruppen, die die Architektur definiert, aus dem Bild nicht rekonstruieren. Im Architektur-Board führt das zu genau den Rückfragen, die der Termin nicht braucht.
3. Kernaussage und Prinzipien sind nur als Fließtext gesetzt
Das Bemerkenswerteste an dieser Slide: Die Erzählung ist komplett vorhanden. Drei Architektur-Prinzipien, die Programm-Zielsetzung, die Nutzenversprechen und die Kernaussage, alles steht darauf. Aber die Kernaussage steht als kursiver Absatz unter dem Untertitel, die Nutzenversprechen als graue Textzeile, und die Prinzipien als durchgehender Textblock am linken Rand. Die stärksten Argumente der Slide sind damit typografisch am schwächsten gesetzt. Der Betrachter nimmt sie als Begleittext wahr — nicht als das, was sie sind: die Begründung des Zielbilds.
4. Die Typografie ist pro Kasten entschieden
Die vier Stream-Titel stehen in vier verschiedenen Schriftgrößen — der längste am kleinsten, weil er in seinen Kasten passen musste. Die Aufzählungen wechseln zwischen 7 und 7,5 Punkt, die Füllfarben zwischen Weiß, Grau und Blassblau, ohne dass die Farbe etwas bedeutet. Jede dieser Entscheidungen ist unter Zeitdruck nachvollziehbar. In Summe erzeugen sie eine zweite, unbeabsichtigte Bedeutungsebene: Größere Schrift liest der Betrachter als größere Wichtigkeit — auf einer Slide, deren vier Streams gleichrangig sind.
Das Redesign
Die Entscheidungen dahinter
Die Plattform steht jetzt im Zentrum
Als gerahmtes Element zwischen den Streams, mit seinen vier Ebenen als klar gestapelte Bausteine. Die Integrations-Logik des Titels ist damit im Bild angekommen: Vier Streams, die erkennbar auf einen gemeinsamen Kern einzahlen.
Die Gruppen haben jetzt eine erkennbare Zugehörigkeit
Die vier Streams als identisch aufgebaute Karten, die Umsysteme als geschlossene Reihe, die technischen Enabler als eigene Reihe darunter. Keine Zuordnung wurde verändert — sie wurde erstmals gezeigt. Rückfragen zur Zugehörigkeit beantwortet jetzt das Bild.
Kernaussage und Prinzipien wurden hervorgehoben
Die Kernaussage als abgesetztes Statement-Band, die Nutzenversprechen als Chip-Reihe, die Prinzipien als einzelne Karten mit Icons. Wortgleicher Text — aber der Blick des Entscheiders läuft jetzt die Route, die das Angebot braucht: Prinzipien, Zielbild, Nutzen.
Die Ops-Rechnung
Architektur-Übersichten gehören zu den teuersten Slide-Gattungen im IT-Consulting — nicht wegen des ersten Aufbaus, sondern wegen der Änderungslogik: Kommt ein Baustein hinzu oder wird eine Gruppe anders geschnitten, muss die halbe Slide von Hand nachgezogen werden. Eine Übersicht wie diese kostet initial 60 bis 90 Minuten und danach 30 bis 60 Minuten pro Änderungsrunde — und sie durchläuft viele: Angebotsversion, Workshop-Version, Board-Version, Lenkungskreis-Version.
Über ein Programm hinweg kommen für eine einzige Architektur-Sicht leicht 15 bis 25 solcher Runden zusammen. Bei vollbelasteten Kosten von 95 bis 120 € pro Stunde sind das 1.500 bis 3.000 € Produktionsaufwand pro Sicht — erledigt von Architekten und Senior-Beratern, deren Zeit der Ziellösung gehört, nicht dem Nachrücken von Kästen.
Fazit
Die Zielarchitektur-Slide hat einen doppelten Auftrag: Sie muss eine komplexe Lösung erklären und dabei belegen, dass der Absender Komplexität beherrscht. Eine Architektur-Slide, die selbst ungeordnet wirkt, verliert beide Aufträge gleichzeitig — unabhängig davon, wie gut die Architektur dahinter ist. Das Redesign hat kein Wort und keine Zugehörigkeit verändert. Es hat die Ordnung sichtbar gemacht, die der Architekt längst gedacht hatte: den Kern als Zentrum, die Gruppen als Gruppen, die Begründung als Begründung. Der Unterschied zwischen einer Slide, die erklärt werden muss, und einer, die sich selbst erklärt, liegt vollständig in der Produktionsebene.
Wenn Ihnen die Vorher-Slide bekannt vorkommt, ist das kein Kompetenzproblem Ihrer Architekten, sondern ein Produktionsproblem. Ihre Experten liefern das Zielbild — die Produktionsebene lässt sich systematisieren, mit fester visueller Ordnung, CI-Compliance und Turnaround-Zeiten, die zu Programm-Rhythmen passen. Ein guter erster Schritt ist unser PresentationOps-Audit.
