Work-Transformation-Suite

Claude urteilt, Skripte rechnen

Die Trennung ist die eigentliche Idee der Suite. Claude liest Quellen und urteilt: Extraktion, Prozessaufnahme, Bewertung, Agentenbündelung, Soll-Entwürfe, Prozesswert, Pilotpläne. Alles andere machen Python-Skripte, ohne Zufall und ohne Zeitstempel: IDs, Zusammenführung, Normalisierung, Klassifikation, Abdeckung, Deltas, Dashboard. Auch die Deltas eines Soll-Szenarios schreibt niemand von Hand — sie fallen aus den Schritten des Entwurfs an.

Gleiche Eingabe, gleiche Ausgabe

IDs sind SHA1-Hashes normalisierter Namen, Listen sortiert, JSON-Schlüssel sortiert. Zwei unabhängige Läufe derselben Eingabe erzeugen byteidentische Dateien.

Regeln statt Bauchgefühl

Modus, HAS-Level, Horizont, Disruptionstyp, Abdeckung und Priorität sind Formeln mit Konstanten am Kopf von score_roles.py. Wer kalibrieren will, verschiebt dort die Konstanten und nicht einzelne Bewertungen.

Menschen korrigieren und entscheiden an je einer Stelle

Fachexperten schreiben Korrekturen in overrides.csv, Freigaben in decisions.csv — mit Name, Datum und Begründung. Beide gewinnen dauerhaft und überleben jeden Neulauf. Im Graphen selbst wird nie von Hand editiert, auch kein Status.

Fünf Schritte, ein Datenformat

Alle Schritte arbeiten auf derselben work-graph.json in einem Projektordner. Jeder Schritt, der etwas ändert, legt eine neue Version an. Ein Schritt ohne Änderung meldet „Unverändert“.

Claude + Skript

work-graph-builder

Liest Stellenbeschreibungen aus 00_input/, extrahiert Rollen, Aufgaben, Zeitanteile und Skills, erzeugt den Graphen und die Review-Liste für Fachexperten.

Claude + Skript

task-scorer

Bewertet jede Aufgabe nach sechs Werten der Rubrik und leitet ab: Modus, HAS-Level, Zeithorizont, Disruptionsscore und -typ je Rolle, bleibende und sinkende Skills.

Claude + Skript

agent-mapper

Bündelt Aufgaben zu 6–15 wiederverwendbaren Agenten und rechnet Abdeckung je Rolle, FTE-Äquivalent, Build/Buy/Hybrid, Horizont und Priorität.

Claude + Skript

process-redesigner

Entwirft je Prozess drei Szenarien — konservativ, ausgewogen, agent-nativ — mit sechs Operatoren, rechnet die Deltas gegen den Ist-Prozess, priorisiert mehrdimensional statt nach FTE und erzeugt Pilotkarten mit Guardrails.

Nur Skript

transformation-dashboard

Baut ein einzelnes, offline lauffähiges HTML-Dashboard mit Ist/Soll-Vergleich, die CSV-Exporte und einen Bericht. Farben kommen aus einer Theme-Datei.

00_input/ Quellen (Mensch) │ Claude extrahiert → 10_extraction/extract_*.json ▼ build_graph.py → 20_graph/work-graph_vNNN_builder.json │ make_review_list.py → 30_review/review_vNNN.md ← Fachexperten → overrides.csv ▼ apply_overrides.py │ Claude nimmt Prozesse auf → 10_extraction/process_*.json [optional] ▼ build_processes.py → Prozesse, Schritte, Kanten, Kontrollen, Kennzahlen │ Claude bewertet → 20_graph/scores.json ▼ score_roles.py → Modus, HAS, Horizont, Disruptionstyp │ Claude bündelt → 20_graph/agents.json (+ Capability Contracts) ▼ compute_coverage.py → Abdeckung, FTE, Sourcing, Priorität │ Claude entwirft → 20_graph/blueprints.json (3 Szenarien je Prozess) ▼ build_blueprints.py → Soll-Kennzahlen und Deltas │ Claude bewertet Wert → 20_graph/process_value.json ▼ score_processes.py → Prioritätsbänder mit Sensitivität │ Claude plant Piloten → 20_graph/experiments.json ▼ make_experiments.py · compare_scenarios.py · apply_governance.py ▼ build_dashboard.py → 40_output/dashboard.html, CSV, report.md

python3 skills/work-transformation/scripts/run_pipeline.py --project projekte/kundenservice führt alle Skript-Schritte hintereinander aus. Fehlt eine Claude-Eingabe, stoppt der Lauf mit Exit-Code 3 und einer klaren Meldung. Derselbe Befehl ist das „weiter machen“ nach jeder Korrektur.

Die sechs Skills

Jeder Skill bringt SKILL.md, deterministische Skripte und Referenzen mit. Gemeinsame Bibliotheken liegen als identische Kopien in jedem Skill, damit keiner vom anderen abhängt. check_suite.py prüft die Kopien.

Skill	Aufgabe	Ergebnis
work-transformation	Orchestrator: sagt, welcher Schritt dran ist, und hält die Arbeitsteilung sauber	Pipeline-Lauf, Suite-Check
work-graph-builder	Extraktion aus Quellen, Zusammenführung, Review-Liste, Overrides, Stellen-Import	`work-graph.json`, `review.md`
task-scorer	Aufgabenbewertung nach Rubrik, Rollenaggregation, Kipp-Analyse, Kalibrierung	Modus, HAS, Horizont, Disruptionstyp
agent-mapper	Agentenbibliothek nach Mustern, Abdeckung, Sourcing, Priorisierung, Capability Contracts	`agents.json`, Verträge als JSON und Markdown
process-redesigner	Drei Soll-Szenarien je Prozess, sechs Operatoren, Prozesswert, Pilotkarten	Blueprints mit Deltas, Prioritätsbänder, Experimente
transformation-dashboard	Visualisierung und Export, Ist/Soll-Vergleich	HTML, CSV-Exporte, Bericht

eliminiert transformiert augmentiert entstehend stabil

eliminieren vereinfachen zusammenführen parallelisieren automatisieren Human Gate erhalten

Sagt, wie belastbar das Ergebnis ist

Sechs Vorkehrungen, damit aus einer Analyse kein Scheinergebnis wird.

Belastbarkeit je Rolle

Jede Rolle trägt eine Stufe: belastbar, teilweise geprüft, ungeprüft. Sie folgt aus der Quelle der Zeitanteile, der Expertenprüfung, dem Anteil abgeleiteter Aufgaben und dem bekannten Headcount. Eine Rollenkarte, in der alles „ungeprüft“ ist, ist ein Gesprächsangebot, kein Ergebnis.

Kipp-Analyse

Maschinenanteil, Urteilsbedarf und Fehlergewicht werden je Aufgabe um ±1 variiert. Das Ergebnis sagt, ob eine Einstufung stabil, grenznah oder wackelig ist, und nennt die Aufgabe, an der sie hängt. Genau die prüft der Experte zuerst.

Stellen statt Prozessrollen

positions.csv ordnet Stellen mit Anteilen den Rollen zu und rechnet Vollzeitäquivalente und Headcounts. Ohne Personennamen.

Kalibrierung

calibrate.py vergleicht Expertenkorrekturen mit den generierten Werten. Wenn die Experten systematisch anders liegen, verschiebt man den Anker in der Rubrik statt weiter einzeln zu korrigieren.

Geschätzt, bestätigt, gemessen

Jede Kennzahl trägt ihre Belastbarkeit mit und eine Fundstelle. Wer „gemessen“ behauptet, ohne sie zu belegen, kommt am Validator nicht vorbei. Ein im Pilot gemessener Wert überschreibt den Ist-Ausgangswert ausdrücklich nicht — sonst vergliche sich der Soll-Zustand mit sich selbst.

Bänder statt Rangliste

Prozesse landen in „Jetzt“, „Als Nächstes“, „Später“ oder „Zurückstellen“. Zu jedem wird geprüft, ob das Band schon kippt, wenn ein einzelner Faktor um ±1 danebenliegt. Wenn ja, steht das im Dashboard — eine Reihenfolge auf zwei Nachkommastellen wäre hier eine Lüge.

Installation

Voraussetzung: Python 3.9 oder neuer, keine zusätzlichen Pakete.

In Claude (Cowork / claude.ai)

Die sechs .skill-Dateien aus dist/ einzeln in den Chat ziehen und auf „Skill speichern“ klicken. Reihenfolge egal.

In Claude Code

Als Plugin: /plugin marketplace add GodModeAI2025/Work-Transformation-Suite, dann /plugin install work-transformation-suite@work-transformation-suite. Oder Ordner skills/ nach ~/.claude/skills/ kopieren oder projektbezogen nach <repo>/.claude/skills/. Zusammen in einen Ordner legen, damit die Skills sich über den Geschwister-Pfad finden.

Ohne Claude

Alles läuft auch als reines Kommandozeilenwerkzeug. Die Urteilsschritte macht dann ein Mensch, indem er die JSON-Vorlagen ausfüllt.

git clone https://github.com/GodModeAI2025/Work-Transformation-Suite.git
cd Work-Transformation-Suite
python3 skills/work-transformation/scripts/check_suite.py        # → Suite OK
python3 -m unittest discover                                     # → 83 Tests, OK

# Referenzbeispiel vollständig durchrechnen
python3 skills/work-transformation/scripts/run_pipeline.py --project examples/order-to-cash

python3 skills/work-graph-builder/scripts/init_project.py \
  --project projekte/kundenservice \
  --name "Kundenservice Pilot" --organization "Meine Firma" \
  --scope "Kundenservice – Vertrag und Abrechnung"

Der Ablauf ist am Pilotbereich mit 20 bis 40 Rollen entstanden und bereits mit über 200 Rollen in einem Dashboard gelaufen. Projektdaten liegen außerhalb des Repositories. Dort stehen nur die Skills.

Grenzen

Was die Suite nicht kann, steht hier, damit niemand es im Piloten herausfinden muss.

Kein Freigabeworkflow mit Rollen und Rechten. Freigaben sind ein nachvollziehbares Log mit Name, Datum und Begründung — mehr nicht.
Keine Integration in SuccessFactors oder andere HR-Systeme.
Kein Tracking der Agentennutzung nach dem Rollout, keine Prozess-Mining-Anbindung.
Ein umbenannter Task bekommt eine neue ID und verliert Bewertung und Overrides. Namen also stabil halten.
Ein Soll-Prozess aus Interviews und Stellenbeschreibungen ist ein Entwurf, keine Prognose. Aus Rollendaten allein lässt sich kein Unternehmen verlässlich „neu bauen“. Dafür braucht es Prozessbeobachtungen, Systemdaten und gemessene Ausgangswerte.

Für die ersten drei Punkte verkaufen kommerzielle Plattformen ihr Produkt. Für die Frage, ob eine solche Analyse für einen Bereich überhaupt belastbare Ergebnisse liefert, reicht die Suite. Bis über 200 Rollen ist sie bisher gelaufen. Und wo Zahlen geschätzt sind, steht das dran — in jeder Ausgabe.

Methodische Quellen

Die Metriken stammen aus veröffentlichter Forschung und aus dem, was kommerzielle Transformationsdashboards messen.

Stanford, „Future of Work with AI Agents“ (Shao et al. 2025, WORKBank, Human Agency Scale H1–H5, arXiv 2506.06576)
Anthropic Economic Index, Automation gegen Augmentation auf O*NET-Task-Ebene
ESCO v1.2, die EU-Skill-Taxonomie
Metriken kommerzieller AI-Transformation-Dashboards: Automation Potential, Human Judgment, Disruption Score, Rollentypen
ESIA-Schule der Prozessneugestaltung (eliminieren, vereinfachen, zusammenführen, automatisieren), hier um Parallelisierung und den ausdrücklichen Kontrollpunkt erweitert
MIT Sloan zur Verkettung von Aufgaben (Demirer, Horton, Immorlica, Lucier): Wert entsteht auf der Ebene des Ablaufs, nicht der Einzelaufgabe
MIT Sloan zur Produktivität hochqualifizierter Arbeit: außerhalb ihrer Fähigkeitsgrenze verschlechtert KI Ergebnisse — deshalb sind Human Gates Teil des Entwurfs
SAP zu generativer KI in der Prozessexzellenz: vom Geschäftsziel und der Wertschöpfungskette aus entwerfen
Artikel 14 der EU-KI-Verordnung, wirksame menschliche Aufsicht — Vorbild für die Regel, dass ein irreversibler automatisierter Schritt einen benannten Kontrollpunkt braucht