Yaravan — Service-Design für einen Kundendienstbetrieb, den niemand aufgeschrieben hatte

01Kontext

Eine ruhende Identität, ein undokumentierter Betrieb

Yaravan ist die Garantie- und Kundendienstmarke eines iranischen Mobiltelefonhändlers. Eine externe Agentur schrieb 2024 ihre Markenidentität, und dann wurde nichts darauf aufgebaut. Ab Juli 2026 bestand die Aufgabe darin, daraus einen funktionierenden Service zu machen: eine öffentliche Website, einen Kundenbereich und einen Mitarbeiterbereich — und darunter den Betrieb, der die Versprechen der Marke würde halten müssen.

Das bestehende Supportsystem behält die Ticket-Warteschlange und den Reparaturbetrieb. Für die Prozesse, die Yaravan verantwortet, verläuft die Beziehung umgekehrt: Yaravan ist die Referenz für den Betrieb, und das Supportsystem dokumentiert den Prozess, statt ihn zu steuern. Diese Fallstudie handelt von diesem Betrieb; das darauf aufgebaute Produkt ist eine eigene Fallstudie.

02Problem

Ein Entwurf des Soll-Zustands, keine Aufzeichnung des Ist-Zustands

Der Betrieb war nie aufgeschrieben worden. Die Anforderungen und die funktionale Spezifikation beriefen sich beide auf zwei Quelldokumente — ein Anforderungsdokument für den Kundendienst und einen CRM-Prozessbericht — als Ursprung der realen Ticket-, Reparatur- und Garantieprozesse. Keines von beiden existierte in irgendeinem Repository.

Also musste jede Prozesslandkarte ein Entwurf des Soll-Zustands sein, keine Aufzeichnung des Ist-Zustands, und die Prozesssammlung trägt diese Warnung auf ihrer ersten Seite. Unterdessen gingen die öffentlichen Versprechen der Marke bereits über den Betrieb hinaus: Die Anforderungsarbeit ergab, dass die zentralen Aussagen der alten Website nicht der betrieblichen Wirklichkeit entsprachen und dass es keine echte Garantiedatenbank gab.

Damit stand die Designfrage für den Betrieb fest: Wie zeichnet man einen Prozess, den noch niemand bestätigen kann, ohne ihn zu erfinden?

03Meine Rolle

Die Arbeit leiten, mit dem Team des Kunden

Ich leitete das Service-Design — das Reife-Audit, die Prozessarchitektur, das Rollenmodell und die Garantieökonomie. Die geschäftliche Verantwortung blieb beim Kunden: Sein Verantwortlicher für das Geschäft traf die kaufmännischen Entscheidungen, und sein Verantwortlicher für den Kundendienst trug den Supportbetrieb und prüfte die Landkarten.

Verantwortet

Anforderungen und Umfang
Das Audit der Input-Reife
Prozessarchitektur, von der Makro-Landkarte bis zur Arbeitsanweisung
Rollen, Verantwortlichkeiten und die RACI-Matrix
Garantieökonomie

Mitverantwortet

Die Umsetzung der Plattform, aus der die Landkarten abgelesen wurden, mit dem Engineering-Team des Kunden

Mitgearbeitet

Kaufmännische Entscheidungen (der Verantwortliche für das Geschäft)
Der Supportbetrieb und seine Review-Anmerkungen (der Verantwortliche für den Kundendienst)

Die Datei entstand KI-gestützt: Korrekturen aus dem Review setzte ein Agent über die Figma-Integration um, und sie wurden Thread für Thread protokolliert. Die Zeichenregeln und die Nachweisstufen, an die er sich halten musste, wurden zuerst geschrieben.

04Vorgehen

Prüftore statt Liefergegenstände

Jede Phase endete an einem Prüftor statt mit einem Dokument. Die Anforderungen stammten aus fünfzig direkten Multiple-Choice-Fragen an den Verantwortlichen für das Geschäft, einer Durchsicht der Marken- und Quelldokumente und einem Benchmark von neun Wettbewerbern, gemessen an einem einzigen Erfolgstest: Das Engineering kann beginnen, ohne eine grundlegende Frage erneut stellen zu müssen.

Dann lief ein Reife-Audit — und scheiterte. Über 59 Quellen und 31 Prozesse hinweg lautete das Ergebnis NOT_READY, mit 12 Blockern, 4 ungelösten Konflikten und Rollen in drei uneinheitlichen Taxonomien. Die zweite Runde stritt nicht mit dem Urteil; sie beschränkte den Umfang auf die 13 Prozesse, die die Marke tatsächlich verantwortet, und eine spätere Ergänzung erweiterte ihn auf 22, mit Annahme, Diagnose, Reparatur, Rücklieferung und Ersatzteilen.

Der kleinere Umfang hob die strukturelle Reife von 49 % auf 78 % und die Belastbarkeit der Nachweise von 58 % auf 92 % — weil sich die verbliebenen Prozesse aus ausführbarem Code und bestandenen Tests ablesen ließen.

„NOT_READY darf durch keinen positiven Prozentsatz und keine optimistische Erzählung ersetzt werden.“
— Das Audit der Input-Reife, erste Runde · Eine Regel, die vor dem Durchlauf in das Audit geschrieben wurde

Sechs Prüftore, in dieser Reihenfolge

01
AnforderungenFünfzig Fragen an den Verantwortlichen für das Geschäft; neun Wettbewerber im Benchmark
02
Reife-AuditNOT_READY: 12 Blocker, 4 Konflikte, Rollen in drei Taxonomien

05Research

Erst die Regeln zeichnen, dann die Diagramme

Die Figma-Datei enthält keine Screens: Das Interface wurde schriftlich spezifiziert, und der Designaufwand floss in den Teil, den niemand beschreiben konnte — den Betrieb. Ihre erste Seite ist kein Deckblatt, sondern eine Regelseite: eine Komponentenbibliothek aus vierzehn Teilen und sechs Hausregeln. Abläufe laufen von rechts nach links, wie die Sprache. Leerstellen werden als „noch festzulegen“ markiert, nie mit einem geratenen Namen oder einer geratenen Zahl gefüllt. Konflikte werden festgehalten, nicht aufgelöst. Farbe trägt nie allein eine Bedeutung; sie tritt immer zusammen mit einer Form und einem Icon auf.

Eine Regel bestimmt die Gestalt der ganzen Datei: Was gezeichnet werden darf, hängt von den Nachweisen dahinter ab, Aussage für Aussage. Fünf Nachweisstufen reichen von ausführbarem Code, der ein vollständiges Swimlane-Diagramm erlaubt, bis zu gar keiner Quelle, bei der Zeichnen verboten ist und nur ein Hinweis erscheinen darf. Je niedriger die Stufe, desto weniger darf gezeichnet werden.

So ist die Datei ehrlich über ihre Leerstellen. Wo eine Ebene vorzeitig endet, nennt eine Hinweistafel, was fehlt und warum, und die Hinweise zur Service-Landkarte und zu den Swimlanes rechnen ihre eigene Zählung auf 22 zurück. Ein Diagramm einer undokumentierten Abfolge wäre dieselbe Erfindung, die die Regeln verbieten — nur überzeugender.

Yaravan — der Regelteil des Designleitfadens auf Persisch: sechs Hausregeln, die Ergänzung zum Umfang und die fünf Nachweisstufen — Abbildung 02Die Regeln von Seite 00: sechs Hausregeln, die Ergänzung, die den Umfang auf 22 Prozesse erweiterte, und die fünf Nachweisstufen, die entscheiden, was gezeichnet werden darf. Zeilen, die den Händler oder das Supportsystem nennen, sind entfernt.

Yaravan — die Komponentenbibliothek der Diagramme: sieben Ablaufformen, ein Status-Badge mit vier Zuständen, Bahnköpfe, Breadcrumbs und Prozesskarten

06Sechs Ebenen

Ein Prozess, bis ganz nach unten verfolgt

Die Architektur hat sechs Ebenen, und jede beantwortet eine andere Frage. Die Garantieaktivierung durch den Kunden ist einer der wenigen Prozesse, die auf jeder davon gezeichnet sind, und zeigt deshalb den gesamten Aufbau. Auf der Makro-Landkarte ist sie eine Karte mit Verantwortlichem, Ergebnis und Status. Auf Ebene 1 wird sie zur End-to-End-Karte: Auslöser, Verantwortlicher, Start- und Endereignisse, vier Phasen, die Entscheidungspunkte, was sie aufnimmt und weitergibt, die Kontrollen, die der Code durchsetzt — und ein KPI und ein SLA, markiert als „noch festzulegen“, weil in keiner Quelle eine freigegebene Formel oder Zeit existiert.

Ebene 2 ist ein Service-Blueprint: die Aktionen des Kunden, die Touchpoints und was Mitarbeitende und Systeme auf beiden Seiten der Interaktionslinie, der Sichtbarkeitslinie und der Linie der internen Interaktion tun, bis hin zu den Aufzeichnungen und Kontrollen, die jeder Schritt hinterlässt. Hier zeigt er, dass das gedruckte Etikett, von dem der Kunde ausgeht, ein Touchpoint ist, den das System nicht kontrolliert — der Druck erfolgt außerhalb des Systems. Die Datei zeichnet auch diesen Touchpoint: eine druckbare Garantiekarte, Vorder- und Rückseite, in zehn Varianten. Ebene 3 macht aus derselben Abfolge ein Swimlane-Diagramm mit einer Bahn für jeden Akteur.

Die Ebenen 4 und 5 sind für die Menschen, die ihn ausführen. Die Verfahrensanweisung deckt vier Prozesse zugleich ab — Verfahren und Prozesse entsprechen einander nicht eins zu eins — und trägt den Stempel „nicht freigegeben“; freigebende Person und Überprüfungsdatum stehen auf „noch festzulegen“. Die Arbeitsanweisung besteht aus den sieben Schritten des Kunden selbst, mit einer eigens für ihn geschriebenen Checkliste: Das Code-Alphabet enthält keine Null, kein O, keine Eins, kein I und kein L, sodass nichts auf dem gedruckten Etikett falsch gelesen werden kann.

Jede Ebene darf aufhören. Nur vierzehn der 22 Prozesse haben ein Swimlane-Diagramm und nur sechs einen Blueprint; die übrigen haben einen Hinweis, der sagt, warum, und die Hinweise rechnen ihre eigene Zählung auf 22 zurück.

Yaravan — die Vorderseite der druckbaren Garantiekarte auf Persisch: Gerätemodell, Garantiecode, Ablaufdatum, ein leeres Kontaktfeld und ein unscharf gemachter QR-Code — Abbildung 04Wo die Aktivierung beginnt: die Vorderseite der druckbaren Garantiekarte auf Seite 11, eine von zehn Varianten. Die juristische Person, die Adresse und die Telefonnummer sind entfernt, und der QR-Code ist unscharf gemacht.

Yaravan — die End-to-End-Karte der Garantieaktivierung durch den Kunden, auf Persisch: Auslöser, Verantwortlicher, Phasen, Entscheidungspunkte, Inputs und Outputs, Kontrollen sowie ein KPI und ein SLA, die als „noch festzulegen“ markiert sind — Abbildung 05Ebene 1 — die Garantieaktivierung durch den Kunden von Anfang bis Ende: Auslöser und Verantwortlicher, vier Phasen, die von rechts nach links verlaufen, die Entscheidungspunkte sowie ein KPI und ein SLA, die noch keine Quelle definiert.

Yaravan — der Service-Blueprint der Garantieaktivierung durch den Kunden, auf Persisch: vier Schritte über die Ebenen von den Aktionen des Kunden bis zu den Nachweisen, getrennt durch die Interaktionslinie, die Sichtbarkeitslinie und die Linie der internen Interaktion — Abbildung 06Ebene 2 — der Service-Blueprint: vier Schritte vom Lesen des Etiketts bis zur aktiven Garantie, über die Interaktionslinie, die Sichtbarkeitslinie und die Linie der internen Interaktion hinweg.

Yaravan — das Swimlane-Diagramm der Garantieaktivierung durch den Kunden, auf Persisch: Bahnen für Kunde, System und SMS, eine Entscheidung und zwei Endzustände — Abbildung 07Ebene 3 — das Swimlane-Diagramm: Kunde, System und SMS-Gateway in drei Bahnen, mit der einen Entscheidung, die einen bereits verwendeten Code zur Ablehnung schickt.

Yaravan — der Steckbrief der Verfahrensanweisung für Aktivierungscodes, auf Persisch: Entwurf in Version 0.3, freigebende Person und Überprüfungsdatum noch festzulegen, und der Status „nicht freigegeben“

Yaravan — die Arbeitsanweisung zum Aktivieren eines Garantiecodes, auf Persisch: Kenndaten, Voraussetzungen, der Pfad im Panel und sieben nummerierte Schritte

07Was die Landkarten fanden

Eine Landkarte, die unvollständig zurückkommen darf, ist ein Forschungsinstrument

Das Zeichnen des Betriebs brachte Befunde hervor, die kein Dokument enthielt. Von den vierzehn als Swimlanes gezeichneten Prozessen versenden nur zwei überhaupt eine SMS — der Anmeldecode und die Garantieaktivierung —, also kamen die Entwürfe der Nachrichtentexte in genau diese beiden Landkarten. Vier Prozesse auf der Makro-Landkarte haben keine Karte, weil die für sie angeführten Quellen nicht existieren.

Wo sich eine Ebene nicht ehrlich zeichnen lässt, tritt ein Hinweis an ihre Stelle. Sechs Arbeitsanweisungen lassen sich noch nicht schreiben, jede aus einem benannten Grund: kein Mechanismus zum Zurücksetzen, kein Weg für Eigentumsstreitigkeiten, kein Format für Rechnungsnummern, ein offener Konflikt, kein Fotostandard, keine Richtlinie für nicht abgeholte Ware. Die Verfahrensanweisung zur Reparaturqualität erhielt überhaupt keine Arbeitsanweisungsnummer — eine für ein Verfahren zu reservieren, dessen Ausführender noch offen ist, wäre selbst schon eine Aussage.

Die Datei prüft sich auch selbst. Eine Abdeckungsmatrix stellt jeden der 22 Prozesse seiner Quelle, den vorhandenen Ebenen und dem Fehlenden gegenüber: sechs vollständig, sechs unvollständig, einer im Konflikt, neun noch festzulegen. Sie öffnet drei Lücken wieder, die als geschlossen markiert waren — geschlossen ist nicht dasselbe wie von der Organisation gelöst —, und sie zieht ihre eigenen Quellenverweise zurück, wo sich herausstellte, dass eine Quelle nicht sagt, wofür sie angeführt worden war.

Yaravan — drei Hinweistafeln auf Persisch, von den Seiten zur Service-Landkarte, zu den Swimlanes und zu den Arbeitsanweisungen, die jeweils auflisten, was nicht gezeichnet ist und warum — Abbildung 09Leerstellen, gezeichnet: die Hinweise auf den Seiten zur Service-Landkarte, zu den Swimlanes und zu den Arbeitsanweisungen, die jeweils nennen, was fehlt und warum. Zeilen, die den Händler nennen, sind entfernt.

Yaravan — die Abdeckungsmatrix auf Persisch: eine Tabelle mit 22 Zeilen, die Prozesse ihren Quellen, Ebenen und Lücken gegenüberstellt, darunter die Anzahl je Status — Abbildung 10Seite 08: die Abdeckungsmatrix — jeder der 22 Prozesse im Abgleich mit seiner Quelle, den vorhandenen Ebenen und dem Fehlenden, darunter die Anzahl je Status. Zellen, die Personen, das Supportsystem oder eine Schwachstelle im Code nennen, sind entfernt.

08Rollen

Rechenschaftspflicht ist eine organisatorische Tatsache, keine technische

Acht Rollenkarten legen für jede Rolle Zweck, Aufgaben, exklusive Rechte, bewusste Ausschlüsse und Lücken dar, mit KPI und SLA auf jeder Karte als „noch festzulegen“ markiert. Manche Karten bestehen überwiegend aus Fragen. Eine Rolle existiert im Code und hat Zugriff, aber kein Geschäftsdokument, kein Organigramm und keine Verfahrensanweisung definiert sie, also ist ihre Bahn gestrichelt gezeichnet, bis das Geschäft entscheidet, ob sie real ist oder ein anderer Name für eine bestehende Rolle.

Die Verantwortungsmatrix ließ sich nur zu drei Vierteln ableiten. Responsible, Consulted und Informed ergaben sich aus dem Code; Accountable nicht, denn der Code sagt, wer eine Aktion ausführen kann, nicht, wer für ihr Ergebnis einsteht. Die Matrix wird mit dieser Spalte offen und einem Banner ausgeliefert, das genau das sagt, und sie markiert bewusste Ausschlüsse — Funktionstrennung — in Rot, damit sie nicht mit Lücken verwechselt werden: Die Rolle, die die Stornogrenze festlegt, kann keine Stornierungen genehmigen, weil sie sonst ihre eigene Grenze anheben könnte.

Das Zugriffsmodell wurde genauso behandelt. Eine Seite legt acht strukturelle Kontrollen dar, die der Code durchsetzt — standardmäßige Verweigerung, ein 404 statt eines 403, damit eine Rolle nicht erfahren kann, dass eine Seite existiert, und keine erfundenen Standardwerte: „Einen Standardwert zu erfinden heißt, stillschweigend eine Richtlinie zu veröffentlichen, die niemand freigegeben hat.“ Daneben wird der eigene Rollenvorschlag der Mitarbeitenden des Kundendienstes — acht Rollen, 76 Punkte — Punkt für Punkt am Code geprüft, Seite an Seite, „nicht zusammengeführt, nicht abgeglichen“. Drei der 76 sind vollständig umgesetzt, zwanzig stehen im Konflikt mit einer freigegebenen Architekturentscheidung, und die Seite nennt ihre eigene Grenze: Sie fällt kein Urteil darüber, ob der Vorschlag richtig ist.

Yaravan — die Rollenkarte für den Garantiebetrieb, auf Persisch: ein rotes Banner, das sagt, dass die Rolle im Code existiert, aber in keinem Geschäftsdokument, und jedes Feld als „noch festzulegen“ markiert — Abbildung 11Eine Rolle, die nur im Code existiert: Jedes Feld ihrer Karte lautet „noch festzulegen“, und das Banner richtet die Frage an das Geschäft.

Yaravan — die RACI-Matrix auf Persisch, mit einem roten Banner, das die Spalte „Accountable“ als offen markiert, und roten Zellen für bewusste Ausschlüsse — Abbildung 12Die ersten elf Zeilen der Matrix über 22 Prozesse. Die Hauptspalte wird leer ausgeliefert und sagt, warum. Das Banner benennt die Lücke und wer die Entscheidung trägt; der Name ist hier ausgeblendet.

Yaravan — zwei Boards auf Persisch: acht strukturelle Zugriffskontrollen, die im Code durchgesetzt werden, und der Kopfbereich des Vergleichs zwischen dem aktuellen Modell und dem Vorschlag der Mitarbeitenden — Abbildung 13Seite 10: die acht strukturellen Kontrollen, die der Code durchsetzt — standardmäßige Verweigerung, 404 statt 403, ein Modul hinter Menü, Seite und Server — über dem Kopfbereich der Gegenüberstellung mit dem eigenen Vorschlag der Mitarbeitenden.

09Entscheidungen

Sechs Regeln, um zu zeichnen, was niemand bestätigen konnte

Der größte Teil der Methode betrifft das, was die Datei bewusst nicht zeichnet.

01
Nur so weit zeichnen, wie die Nachweise reichen
Fünf Nachweisstufen, festgelegt pro Aussage statt pro Dokument, entscheiden, was gezeichnet werden darf: Ausführbarer Code erlaubt ein vollständiges Swimlane-Diagramm, gar keine Quelle erlaubt nur einen Hinweis. Ein Diagramm behauptet, die Abfolge, die Bedingungen, die Fehlerpfade und die Bahngrenzen zu kennen — eines ohne Nachweise zu zeichnen, ist Erfindung, die bloß überzeugender aussieht.
Alternativen
Jeden Prozess aus Interviews und Absichten in derselben Tiefe zeichnen
Abwägung
Die Datei wirkt ungleichmäßig: Manche Prozesse enden bei einer Karte.
02
Leerstellen markieren, nie erraten
Keine geschäftliche Information wurde erfunden. Wo ein Name, eine Zahl oder eine Zeit fehlte, lautet das Feld „noch festzulegen“ — bei jedem KPI, jedem SLA und den meisten freigebenden Personen —, damit sich die Lücken zählen und zuweisen lassen.
Alternativen
Plausible Platzhalterwerte
Abwägung
Stakeholder sehen sehr viel Orange.

10Ökonomie

Eine Garantie ist eine Verbindlichkeit, keine Dienstleistung

Der Betrieb musste auch beantworten, was sein zentrales Versprechen kostet. Eine Garantie erbringt am Tag ihrer Ausstellung keine Dienstleistung — nur ein Versprechen, dass jemand zahlt, wenn das Gerät innerhalb eines bestimmten Zeitraums ausfällt. Ob ein Garantiefall eintritt, wann und wie viel er kostet, ist an diesem Tag völlig unbekannt, also muss jetzt Geld dafür zurückgelegt werden, sonst steht hinter dem Versprechen nichts.

Das Deck verfolgt die Verpflichtung von der Ausstellung bis zum Abschluss und legt dar, wer sie finanzieren könnte — und jede Antwort sagt, was die Marke ist: Trägt der Händler die Kosten, ist sie ein Kostenzentrum; kaufen Verkäufer die Codes, ist sie ein eigenständiges Geschäft; zahlt der Importeur, ist sie ein Partner, der das Netzwerk betreibt. Die Empfehlung ist als „ein Vorschlag, keine Entscheidung“ gekennzeichnet.

Es endet mit Steuerungshebeln, nach Kosten geordnet — der günstigste ist ein einzelnes Feld —, und zehn Entscheidungen mit Verantwortlichen und Optionen, von denen acht heute getroffen werden können, ganz ohne Zahl.

Die einzigen Zahlen, die im Deck erlaubt sind, stammen aus dem Code, sind ausdrücklich als hypothetisch gekennzeichnet oder sind ein externer Benchmark mit Quelle, Grundgesamtheit, Datum und Belastbarkeit — und jede Folie trägt ein Badge, das sagt, welche davon.

Yaravan-Garantieökonomie — eine Folie auf Persisch: Eine Garantie ist ein Versprechen mit drei Unbekannten im Moment der Ausstellung — ob, wann und wie viel — Abbildung 14Das Deck beginnt mit dem Konzept: Am Tag ihrer Ausstellung ist eine Garantie drei Unbekannte — ob ein Garantiefall eintritt, wann und zu welchen Kosten.

Yaravan-Garantieökonomie — fünf Steuerungshebel auf Persisch, vom günstigsten zum teuersten geordnet, jeder mit seinem heutigen Status — Abbildung 15Fünf Steuerungshebel, vom günstigsten zum teuersten geordnet, jeder an den Faktor der Kostengleichung gebunden, den er bewegt.

Yaravan-Garantieökonomie — die Board-Landkarte des Decks auf Persisch: der Erzählbogen und eine Tabelle aller Folien mit ihrer Botschaft und ihrem Nachweis-Badge

Yaravan-Garantieökonomie — der Glossar-Anhang auf Persisch: ein fester persischer Begriff für jedes Konzept, mit seiner Definition

11Ergebnisse

Ein gezeichneter Betrieb, dessen Lücken Verantwortliche haben

Es gibt keine Geschäftskennzahlen, und es sollte auch keine geben: Das Produkt läuft auf Staging, und die vereinbarten Kennzahlen haben noch keine freigegebene Formel und keine Datenquelle. Was die Arbeit verändert hat, ist das, was die Organisation über sich selbst weiß. Im Juli gab es keine schriftliche Darstellung des Kundendienstbetriebs; jetzt gibt es eine gezeichnete, in der jede Lücke markiert, gezählt und zugewiesen ist — und die drei Punkte, die die Integration blockieren, sind als Entscheidungen benannt, nicht als Engineering.

22 Prozesse auf sechs Ebenen: Makro-Landkarte, End-to-End-Karten, Service-Blueprints, Swimlanes, Verfahrensanweisungen und Arbeitsanweisungen — 145 Boards auf 13 Seiten.; Gelieferter Output
Ein Rollenmodell und eine RACI-Matrix: Acht Rollenkarten und eine Matrix über 22 Prozesse, bewusste Ausschlüsse markiert und die offene Spalte eingestanden.; Gelieferter Output
Eine Abdeckungsmatrix, die sich selbst prüft: Jeder Prozess im Abgleich mit seiner Quelle, seinen Ebenen und dem, was fehlt; geschlossene Lücken wieder geöffnet und Quellenverweise korrigiert.; Gelieferter Output
Ein Modell der Garantieökonomie: Verbindlichkeit, Finanzierung und Steuerung, dargelegt ohne eine einzige erfundene Zahl.; Gelieferter Output

Was geliefert wurde

Reife-Audit
Makro-Prozesslandkarte

12Gelernt

Eine Disziplin, auf jedem Board

01
Die Lücke zu veröffentlichen ist besser, als sie zu übertünchen
Derselbe Instinkt zieht sich durch jedes Artefakt: NOT_READY statt eines Prozentsatzes, „noch festzulegen“ auf den Prozesskarten, eine leere Spalte „Accountable“ mit einem Banner, das das sagt, und ein Nachweis-Badge auf jeder Folie.
02
Eine Landkarte, die unvollständig zurückkommen darf, ist ein Forschungsinstrument
Zu zeichnen, was niemand beschreiben konnte, brachte Befunde hervor, die kein Dokument enthielt: welche Prozesse dem Kunden wirklich Nachrichten senden, welche Rollen nur im Code existieren, welche Spalte sich nicht aus Berechtigungen füllen lässt. Eine Landkarte, die fertig aussehen muss, ist Dekoration.
03
Ein Reifewert bedeutet nichts, solange der Umfang nicht ehrlich ist
Das erste Audit scheiterte, weil es einen Betrieb maß, den dieses Produkt nicht verantwortet. Die Beschränkung auf die Prozesse, die die Marke verantwortet, senkte den Maßstab nicht — sie hob die Belastbarkeit der Nachweise auf 92 %.
04
Jeden Review-Kommentar in eine Regel verwandeln
Einen Kommentar zu beantworten, korrigiert einen Knoten; die Regel dahinter zu benennen, korrigiert jeden künftigen. Ein Hinweis zur persischen Rechtschreibung wurde zu einer benannten Regel und einem einzigen Durchgang über 1.088 Textknoten auf allen dreizehn Seiten.

Sprache

Yaravan — Service-Design für einen Kundendienstbetrieb, den niemand aufgeschrieben hatte

Yaravan — Service-Design für einen Kundendienstbetrieb, den niemand aufgeschrieben hatte

Eine ruhende Identität, ein undokumentierter Betrieb

Ein Entwurf des Soll-Zustands, keine Aufzeichnung des Ist-Zustands

Die Arbeit leiten, mit dem Team des Kunden

Verantwortet

Mitverantwortet

Mitgearbeitet

Prüftore statt Liefergegenstände

Sechs Prüftore, in dieser Reihenfolge

Erst die Regeln zeichnen, dann die Diagramme

Ein Prozess, bis ganz nach unten verfolgt

Eine Landkarte, die unvollständig zurückkommen darf, ist ein Forschungsinstrument

Rechenschaftspflicht ist eine organisatorische Tatsache, keine technische

Sechs Regeln, um zu zeichnen, was niemand bestätigen konnte

Nur so weit zeichnen, wie die Nachweise reichen

Leerstellen markieren, nie erraten

Eine Garantie ist eine Verbindlichkeit, keine Dienstleistung

Ein gezeichneter Betrieb, dessen Lücken Verantwortliche haben

Was geliefert wurde

Eine Disziplin, auf jedem Board

Die Lücke zu veröffentlichen ist besser, als sie zu übertünchen

Eine Landkarte, die unvollständig zurückkommen darf, ist ein Forschungsinstrument

Ein Reifewert bedeutet nichts, solange der Umfang nicht ehrlich ist

Jeden Review-Kommentar in eine Regel verwandeln

Konflikte festhalten, nicht auflösen

Die Spalte „Accountable“ offen lassen

CRM als Urteil pro Prozess, nicht als Feature

Persisch auf der Arbeitsfläche, lateinisch im Frame-Namen