Diagnose: die Evidenz für die KI-Marketing-Transformation schaffen
Diagnose ist die erste Phase des kōdōkalabs Transformation System. Sie schafft eine belegbare Ausgangsbasis zu Strategie, Workflows, Wissen, Technologie, Governance, Kompetenz und Messung der Organisation, bevor ein künftiges Operating Model entworfen wird.
Eine Diagnose ist kein allgemeines Audit, keine Tool-Inventur, kein als Analyse verkleidetes Angebot eines Anbieters und kein Reifegrad-Wert ohne Belege. All das liefert eine Meinung darüber, wo eine Organisation steht. Eine Diagnose liefert Evidenz: mit Quellen, nach Belastbarkeit gekennzeichnet und so aufbereitet, dass die Geschäftsleitung genau sieht, worauf sie sich stützt, bevor sie einem Umbau zustimmt.
Zusammenfassung für die Geschäftsleitung
Diagnose gibt es, weil Entscheidungen zur KI-Marketing-Transformation ohne dokumentierte Ausgangsbasis dazu neigen, von Begeisterung, Anekdoten oder dem Tool getrieben zu sein, das ein Wettbewerber gerade eingeführt hat, statt von Belegen dafür, was die Leistung tatsächlich bremst. Die Phase untersucht sieben Bereiche (strategische Ausrichtung, Workflow-Realität, Wissen und Datenreife, Technologie und Integration, Governance und Risiko, Menschen und Kompetenzen sowie Messung und Wertbeitrag), kennzeichnet jede Erkenntnis nach ihrer Belastbarkeit und liefert ein Entscheidungspaket, das der Geschäftsleitung sagt, ob sie stoppen, pilotieren, zu Architect übergehen oder weiter untersuchen soll. Diagnose ist die Evidenzphase und nicht die Lösungsphase. Der Umbau findet in Architect statt.
Das Wichtigste in Kürze
- Diagnose liefert Evidenz, keine Meinung. Jede Erkenntnis ist nach Belastbarkeit gekennzeichnet.
- Sieben Evidenzbereiche werden gemeinsam bewertet und nicht als isolierte Audits.
- Die Phase liefert ein konkretes Entscheidungspaket und keinen allgemeinen Eindruck davon, „wie KI-reif“ die Organisation ist.
- Eine Diagnose unterscheidet sich von einem verkaufsorientierten Audit darin, was sie zu schlussfolgern bereit ist, auch „jetzt nicht“ oder „das nicht“.
- Diagnose fließt direkt in Architect ein. Nichts wird entworfen, bevor es diagnostiziert ist.
Was ist die Diagnose-Phase?
Diagnose ist die Phase des kōdōkalabs Transformation System, in der die Evidenz aufgebaut wird. Bevor ein Workflow neu gestaltet, ein Tool ausgewählt oder ein Budget verteilt wird, stellt Diagnose fest, was über den aktuellen Zustand der Organisation tatsächlich stimmt: nicht, was die Geschäftsleitung annimmt, nicht, was ein Anbieterangebot nahelegt, und nicht, was ein allgemeiner KI-Readiness-Test aus ein paar selbst eingeschätzten Antworten schätzt.
Das ist wichtig, weil die drei häufigsten Ersatzlösungen für eine echte Diagnose alle den Evidenzschritt überspringen. Eine Tool-Inventur erfasst, welche Software installiert ist, und sagt wenig darüber, ob sie konsequent und gut genutzt wird. Ein Anbieterangebot diagnostiziert in der Regel genau das Problem, das das Produkt des Anbieters löst. Und ein Reifegrad-Wert ohne Belege liefert eine Zahl, die autoritativ wirkt, sich aber nicht hinterfragen lässt: Niemand kann fragen „auf welcher Grundlage?“
Warum die KI-Marketing-Transformation eine Ausgangsbasis braucht
Ohne dokumentierte Ausgangsbasis passieren zwei Dinge. Erstens lassen sich spätere Verbesserungen nicht glaubwürdig belegen: Wenn niemand den Zustand „vorher“ festgehalten hat, gibt es keinen belastbaren Weg zu zeigen, dass „nachher“ tatsächlich besser ist und nicht nur anders. Zweitens, und das wiegt schwerer, werden Prioritäten der Transformation von Begeisterung und Sichtbarkeit bestimmt statt von Evidenz: Das lauteste Problem, die zuletzt diskutierte Technologie oder die Initiative, die ein Wettbewerber verkündet hat, bekommt Ressourcen, während die Lücke mit dem größten Nutzen oder dem höchsten Risiko unbearbeitet bleibt, weil sie nie gemessen wurde.
Eine Ausgangsbasis löst beide Probleme. Sie gibt Measure (Phase 5) etwas Konkretes, woran sich später vergleichen lässt, und sie gibt Architect (Phase 2) einen dokumentierten, belastbaren Startpunkt für die Priorisierung statt einer Reihe von Annahmen.
Was Diagnose untersucht
Der Diagnose Evidence Stack von kōdōkalabs gliedert die Diagnose in sieben Evidenzbereiche. Es ist die eigene Methodik von kōdōkalabs, eine Diagnose zu strukturieren, und kein extern validierter Branchenstandard.
Strategische Ausrichtung
Ziele, ideales Kundenprofil, Positionierung, Wachstumsprioritäten und Entscheidungsrechte im Management. Ein Transformationsvorhaben, das von den tatsächlichen Geschäftsprioritäten abgekoppelt ist, verliert trotz technischer Qualität tendenziell die Aufmerksamkeit des Managements, sobald konkurrierende Prioritäten auftauchen.
Workflow-Realität
Wie Arbeit tatsächlich durch die Organisation läuft, einschließlich der Ausnahmen, Übergaben, Verzögerungen, Nacharbeiten und Freigaben, die eine dokumentierte Prozesslandkarte oft auslässt. Die Lücke zwischen dem, wie ein Workflow laufen soll, und dem, wie er tatsächlich läuft, ist häufig der Ort, an dem der eigentliche Engpass liegt.
Wissen und Datenreife
Qualität, Zugang, Verantwortung, Struktur, Sensibilität und Abrufbarkeit der Quellen. KI-gestützte Arbeit ist nur so verlässlich wie das Wissen, auf das sie zugreift. Dieser Evidenzbereich klärt, ob dieses Wissen tatsächlich nutzbar ist und nicht nur irgendwo in der Organisation theoretisch vorhanden.
Technologie und Integration
Tools (auf Englisch), Lizenzen, Datenflüsse, Zugriffskontrollen, Doppelungen und technische Einschränkungen. Das geht über eine einfache Inventur hinaus und untersucht, wie Tools miteinander verbunden sind (oder nicht) und wo redundante oder widersprüchliche Systeme Reibung erzeugen.
Governance und Risiko
Richtlinien, Risikoklassen, Anforderungen an die menschliche Prüfung, Datenschutz, Sicherheit, geistiges Eigentum und Verantwortlichkeiten. Eine Organisation kann hochentwickelte Technologie einsetzen und trotzdem erhebliche, nicht erkannte Risiken tragen, wenn die Governance nicht Schritt gehalten hat.
Menschen und Kompetenzen
Rollenklarheit, praktische Fähigkeiten, Hürden bei der Einführung, Anreize und Bereitschaft zur Übernahme von Verantwortung. Technologie und Workflow-Design scheitern, wenn niemand geprüft hat, ob die Menschen, die das Ergebnis betreiben sollen, dazu überhaupt in der Lage sind.
Messung und Wertbeitrag
Aktuelle Ausgangswerte, Kosten, Qualitätssignale, kommerzieller Beitrag und Lücken im Reporting. Dieser Evidenzbereich fragt, ob die Organisation den Wert ihrer Marketing-Aktivitäten derzeit überhaupt belegen kann. Erstaunlich viele können das nicht, ganz unabhängig von KI. Wenn heute keine glaubwürdige Messbasis existiert, ist diese Lücke selbst ein vorrangiger Befund, denn jede spätere Aussage zu KI-bedingten Verbesserungen stünde vor demselben Beweisproblem.
Diese sieben Bereiche werden bewusst gemeinsam bewertet, weil sie sich gegenseitig beeinflussen. Ein Workflow kann für sich genommen reif für eine KI-gestützte Neugestaltung wirken und doch auf Wissen aufsetzen, das nicht gut genug strukturiert ist, oder auf einer Governance, die mit dem neuen Risiko nicht mitgewachsen ist. Wer die Bereiche isoliert betrachtet, wie es ein enges „KI-Readiness“-Audit oft tut, übersieht genau diese Wechselwirkungen, und dort liegen häufig die wichtigsten Befunde.
Welche Evidenz eine KI-Marketing-Diagnose braucht
Jede Erkenntnis aus Diagnose wird nach den Evidence Strength Levels von kōdōkalabs gekennzeichnet: vier ausdrücklich definierte Stufen, kein externer Standard:
| Stufe | Definition |
|---|---|
| Asserted (behauptet) | Jemand hat es gesagt; es gibt noch keine Dokumentation oder Beobachtung dazu |
| Observed (beobachtet) | Ein Mitglied des Diagnoseteams hat das Verhalten oder den Zustand direkt gesehen |
| Documented (dokumentiert) | Es gibt schriftliche Belege (eine Richtlinie, ein Workflow-Dokument, einen Datensatz) |
| Measured (gemessen) | Mit einer definierten Methode quantifiziert, idealerweise gegen einen Vergleichswert |
Ein vorrangiger Befund sollte sowohl die Evidenz dahinter als auch die Folgen eines Irrtums zeigen: Ist eine Erkenntnis nur „behauptet“, wird das offen gesagt und nicht als größere Gewissheit getarnt. Das ist wichtig, weil Entscheidungen auf Basis behaupteter Evidenz deutlich riskanter sind als solche auf Basis gemessener, und die Geschäftsleitung diesen Unterschied sehen sollte, bevor sie auf eine Empfehlung hin handelt.
Wie das AI Marketing Maturity Model genutzt wird
Diagnose nutzt das AI Marketing Maturity Model, das Framework von kōdōkalabs mit sieben Stufen und sieben Dimensionen, als einen Input der Diagnose und nicht als die ganze Diagnose. Das Maturity Model schätzt, wo die Organisation in denselben sieben Dimensionen steht, die auch der Diagnose Evidence Stack untersucht, und liefert so eine vergleichbare Struktur. Es ersetzt aber nicht die Detailtiefe auf Workflow-Ebene mit gekennzeichneter Evidenz, die eine vollständige Diagnose liefert. Es ist ein Rahmen innerhalb eines größeren Prozesses der Evidenzsammlung und kein Ersatz dafür. Das interaktive AI Marketing Maturity Assessment bietet einen leichteren, selbst bewerteten Einstieg für Organisationen, die noch nicht für eine vollständige Diagnose bereit sind.
Wie Workflows und Anwendungsfälle bewertet werden
Im Evidenzbereich Workflow-Realität werden einzelne Workflows und mögliche KI-Anwendungsfälle an sechs Kriterien gemessen:
Geschäftsrelevanz
Hängt dieser Workflow mit einer echten Geschäftspriorität zusammen, oder ist er nur ein bequemer Kandidat, weil er sichtbar ist oder sich leicht besprechen lässt?
Häufigkeit und Aufwand
Wie oft läuft dieser Workflow, und wie viel Aufwand verursacht er heute? Häufige, aufwendige Workflows liefern bei einer Neugestaltung tendenziell den klarsten Beleg für den Nutzen. Selten laufende Workflows rechtfertigen die Investition kaum, unabhängig vom theoretischen Verbesserungspotenzial.
Anforderungen an Wissen und Daten
Was muss dieser Workflow wissen, um gut zu laufen, und ist dieses Wissen heute in nutzbarer Form zugänglich?
Risiko und Umkehrbarkeit
Was passiert, wenn dieser Workflow ein falsches oder schädliches Ergebnis liefert, und wie leicht lässt sich das korrigieren? Workflows mit geringer Umkehrbarkeit und hohen Folgen brauchen erheblich mehr Governance als risikoarme, leicht korrigierbare.
Anforderungen an menschliches Urteilsvermögen
Welche Teile dieses Workflows verlangen echte Ermessensentscheidungen, und welche folgen einem definierten Prozess? Daran zeigt sich, welcher Anteil realistisch KI-gestützt laufen kann und was in menschlicher Hand bleiben muss.
Messbarkeit
Lässt sich die Leistung dieses Workflows mit vorhandenen Daten tatsächlich messen, oder müsste dafür erst neue Messinfrastruktur aufgebaut werden?
Wer an der Diagnose beteiligt ist
Eine glaubwürdige Diagnose braucht mehr als die Sicht einer einzelnen Person. Typischerweise beteiligt sind ein Executive Sponsor (verantwortlich für die Transformationsentscheidung), eine Business-Verantwortung (zuständig für das Ergebnis, das die Transformation erreichen soll), eine Workflow-Verantwortung (tägliche Zuständigkeit für den untersuchten Prozess), Fachexpertise (Domänenwissen, das dem Diagnoseteam fehlen kann), eine technische Vertretung (Einblick in Systeme, Daten und Integrationsgrenzen), Governance-Stakeholder (Datenschutz, Sicherheit, Recht oder Compliance, wo relevant) und die finale Entscheidungsinstanz (die tatsächlich auf die Empfehlung der Diagnose hin handelt).
Fehlt eine dieser Rollen, entsteht meist ein typischer blinder Fleck. Wer zum Beispiel statt der Workflow-Verantwortlichen nur das Management befragt, bekommt häufig eine Diagnose, die den Prozess so beschreibt, wie er dokumentiert ist, und nicht so, wie er tatsächlich läuft. Fehlen Governance-Stakeholder, wirkt die Diagnose bei Workflow und Technologie vollständig, entdeckt aber eine Datenschutz- oder Compliance-Lücke erst, wenn Architect bereits um die Auslassung herum entwirft, und das ist ein weit teurerer Zeitpunkt.
Es müssen nicht alle Rollen in jedem Gespräch dabei sein. Wichtig ist, dass jede Perspektive irgendwo im Evidenzregister festgehalten ist, bevor die Diagnose als abgeschlossen gilt, und dass die Quelle jedes Beitrags dokumentiert ist: Die Beobachtung einer Workflow-Verantwortlichen hat ein anderes Gewicht als die Behauptung aus dem Management, und die Diagnose sollte klar machen, was was ist.
Ergebnisse der Diagnose-Phase
Diagnose liefert ein definiertes Decision Package und keine allgemeine Zusammenfassung von Befunden:
- Problemstellung für die Geschäftsleitung
- Karte des Ist-Zustands
- Reifegradprofil je Dimension
- Inventar der Workflows und Abhängigkeiten
- Governance- und Risikolücken
- Backlog der Chancen
- Evidenzregister
- Ausgangswerte der Kennzahlen
- Priorisierte Empfehlungen
- Eine ausdrückliche Entscheidung: stoppen, pilotieren, zu Architect übergehen oder weiter untersuchen
Dieser letzte Punkt zählt so viel wie jedes andere Ergebnis. Eine Diagnose, die immer nur „weiter zur nächsten Phase“ empfiehlt, arbeitet nicht als echte Evidenzsammlung: Manchmal spricht die Evidenz dafür, zu stoppen oder einen bestimmten Bereich erst weiter zu untersuchen, bevor man sich auf irgendetwas festlegt.
Abschlusskriterien der Diagnose
Die Phase ist erst abgeschlossen, wenn die Geschäftsleitung konkret sagen kann: welches Problem gelöst wird; welche Evidenz die Diagnose stützt; welche Rahmenbedingungen am wichtigsten sind; welche Chancen ein Design verdienen; was nicht weiterverfolgt werden soll; welche Ausgangsbasis später verwendet wird; und wer die Entscheidung über Architect verantwortet. Kann die Geschäftsleitung diese Fragen nicht konkret beantworten, sondern nur mit allgemeinen Eindrücken, ist die Diagnose nicht fertig, egal wie viel Zeit bereits hineingeflossen ist.
Ein hilfreicher Test: Ist die Antwort auf eine dieser Fragen eine vage Wiederholung des ursprünglichen Geschäftsziels („wir wollen mit KI das Marketing voranbringen“) statt einer konkreten, belegten Aussage („Workflow X verbraucht Y Stunden pro Woche bei Z Prozent Nacharbeit, und die zugehörige Wissensbasis ist undokumentiert“), sind die Abschlusskriterien noch nicht erfüllt, selbst wenn ein Bericht vorliegt und eine Besprechung stattgefunden hat.
Typische Fehler in der Diagnose
- Tool-zuerst-Assessments: Der Ausgangspunkt ist „welche Tools sollten wir einführen“ statt „was bremst uns laut Evidenz tatsächlich“. Das ist der mit Abstand häufigste Fehler, vor allem weil es die Frage ist, die sich am schnellsten beantworten lässt und bei der die meisten Anbieter gern helfen.
- Selbst eingeschätzter Reifegrad ohne Evidenz: Die Einschätzung der Geschäftsleitung zum eigenen Reifegrad wird übernommen, ohne sie an beobachteter oder dokumentierter Evidenz zu prüfen. Die Sicht der Führung auf die eigene Organisation fällt tendenziell optimistischer aus als das, was die Beobachtung an der Basis hergibt, besonders bei Governance und Wissensreife.
- Fehlende Workflow-Verantwortliche aus der Praxis: Es wird nur auf Basis von Management-Interviews diagnostiziert, und die Realität des Arbeitsalltags bleibt unsichtbar. Das Management beschreibt häufig den dokumentierten Prozess, die Workflow-Verantwortlichen beschreiben den tatsächlichen, Ausnahmen inklusive.
- Ignorierte Governance: Governance und Risiko werden als Nebensache behandelt statt als einer der sieben zentralen Evidenzbereiche. Eine Diagnose, die Governance auslässt, kann ein technisch solides Redesign liefern, das sich bei der Umsetzung als deutlich riskanter erweist, als es jemand ahnte.
- Erfundene Benchmarks: Die Organisation wird mit nicht verifizierten oder frei erfundenen Branchenwerten verglichen statt mit der eigenen dokumentierten Ausgangsbasis. Vergleiche mit dem eigenen früheren Zustand sind fast immer belastbarer als der Vergleich mit einer unüberprüfbaren externen Zahl.
- Empfehlungen vor den Befunden: Zuerst steht die bevorzugte Lösung fest, dann wird gezielt Evidenz gesammelt, die sie stützt. Dieses Muster ähnelt am stärksten einem Verkaufs-Audit statt einer echten Diagnose, und eine Organisation erkennt es ohne Außensicht oft am schwersten selbst.
Von Diagnose zu Architect
Diagnose übergibt Architect ein konkretes Paket: das Evidenzregister, das Reifegradprofil, das priorisierte Chancen-Backlog und die ausdrückliche Entscheidung darüber, was ein Design verdient. Architect diagnostiziert nicht neu. Es nutzt die Erkenntnisse aus Diagnose als Input für den Entwurf eines Ziel-Operating-Models. Stellt Architect bei der Designarbeit fest, dass die Diagnose in einem bestimmten Bereich unvollständig war, ist das ein Signal, für genau diesen Bereich zu Diagnose zurückzukehren, und kein Anlass, auf einer Annahme weiterzumachen.
Häufige Fragen zur Diagnose-Phase (FAQ)
Warum zuerst diagnostizieren, statt einfach KI-Tools auszuwählen?
Weil eine Tool-Auswahl, die auf Annahmen statt auf Evidenz beruht, tendenziell das falsche Problem löst oder ein reales Problem, das für die Organisation gar nicht der wichtigste Engpass ist.
Was sollte ein KI-Marketing-Assessment abdecken?
Dieselben sieben Bereiche wie der Diagnose Evidence Stack: strategische Ausrichtung, Workflow-Realität, Wissen und Datenreife, Technologie und Integration, Governance und Risiko, Menschen und Kompetenzen sowie Messung und Wertbeitrag.
Welche Evidenz braucht es für eine verlässliche Ausgangsbasis?
Eine Mischung aus behaupteter, beobachteter, dokumentierter und gemessener Evidenz über alle sieben Bereiche. Dabei legt die Diagnose offen, welche Stufe jeden Befund stützt, und stellt nicht alles mit gleicher Sicherheit dar.
Wer muss an der Diagnose beteiligt sein?
Mindestens Executive Sponsor, Business-Verantwortung, Workflow-Verantwortung, Fachexpertise, technische Vertretung, relevante Governance-Stakeholder und die finale Entscheidungsinstanz. Siehe „Wer an der Diagnose beteiligt ist“ weiter oben.
Wie bewerten Sie Ihre Workflows und KI-Anwendungsfälle?
Anhand von sechs Kriterien: Geschäftsrelevanz, Häufigkeit und Aufwand, Anforderungen an Wissen und Daten, Risiko und Umkehrbarkeit, Anforderungen an menschliches Urteilsvermögen und Messbarkeit.
Wie verändern Risiko und Governance, was zuerst angegangen wird?
Workflows mit höherem Risiko und geringerer Umkehrbarkeit brauchen mehr Governance-Design, bevor sie für eine Neugestaltung priorisiert werden, ganz gleich, wie attraktiv ihr Nutzenpotenzial für sich genommen aussieht.
Was liefert die Diagnose-Phase?
Das vollständige Decision Package: Problemstellung, Karte des Ist-Zustands, Reifegradprofil, Workflow-Inventar, Governance-Lücken, Chancen-Backlog, Evidenzregister, Ausgangswerte, priorisierte Empfehlungen und eine ausdrückliche Entscheidung über den nächsten Schritt.
Wie geht Diagnose in Architect über?
Das Decision Package der Diagnose ist der wichtigste Input für Architect. Architect entwirft das Ziel-Operating-Model auf Basis dessen, was Diagnose gefunden hat, und beginnt nicht bei einem leeren Blatt oder bei einer Annahme.
Kann unser eigenes Team die Diagnose durchführen?
Im Prinzip ja: Der Diagnose Evidence Stack und die Evidence Strength Levels sind eine Methodik, die ein internes Team anwenden kann. In der Praxis stoßen interne Diagnosen häufig an dieselben blinden Flecken, bei denen eine Außensicht hilft, besonders beim selbst eingeschätzten Reifegrad und bei Governance-Lücken, auf die innerhalb der Organisation niemand ein Interesse hat hinzuweisen.
Wie unterscheidet sich eine Diagnose von einem Verkaufs-Audit?
Ein Verkaufs-Audit ist darauf angelegt, bei einer vorab feststehenden Empfehlung zu landen, meist beim eigenen Produkt oder der eigenen Leistung der Prüfenden. Eine echte Diagnose ist bereit, „stoppen“ oder „das nicht“ zu empfehlen, und zeigt ihre Evidenz auf jeder Vertrauensstufe, auch dort, wo sie schwach ist.
Bereit, die KI-Marketing-Reife Ihrer Organisation zu diagnostizieren?
Wenn Sie genug von zersplitterten, Keyword-zentrierten Strategien haben, ist es Zeit für ein Fundament, das Algorithmus-Änderungen übersteht. Wir beginnen mit dem Entwurf, der eine Umsetzung mit hohem ROI sicherstellt.Kontakt aufnehmen