30/60/90 Tage Plan: so bringt eine Kanzlei 1 Workflow sauber produktiv

Warum ein 30/60/90 Plan besser ist als "wir automatisieren mal"

Automatisierung wird oft als Projekt mit Start- und Enddatum gesehen. In der Praxis ist erfolgreiche Automatisierung ein Betriebssystem: Status-Tracking, Ownership, Monitoring, Dokumentation und kontinuierliche Verbesserung.

Die Kanzleien, die bei Automatisierung scheitern, teilen gemeinsame Muster:

• Sie versuchen, alles auf einmal zu automatisieren
• Niemand ist nach dem Launch für den Workflow verantwortlich
• Es gibt kein Monitoring, bis etwas kaputt geht
• Dokumentation existiert nicht oder ist veraltet

Mit einem 30/60/90 Plan verhindert ihr diese Fehler, indem ihr Fokus erzwingt, Ownership definiert und operative Disziplin aufbaut, bevor ihr skaliert.

Die Philosophie: Ein Workflow richtig gemacht

Das Ziel ist nicht "so viel wie möglich automatisieren." Das Ziel ist "einen Workflow in stabilen Produktivbetrieb bringen."

Warum das wichtig ist:

• Ein funktionierender Workflow lehrt euch mehr als fünf halbfertige
• Operative Muster (Monitoring, Fehlerbehandlung, Dokumentation) übertragen sich auf zukünftige Workflows
• Ihr baut interne Glaubwürdigkeit mit messbaren Ergebnissen auf
• Partner sehen Automatisierung als zuverlässig, nicht als experimentell

Die 30/60/90 Struktur:

• Tage 0-30: Bauen und validieren
• Tage 31-60: Stabilisieren und operationalisieren
• Tage 61-90: Messen, lernen, Skalierung vorbereiten

Tage 0-30: Ziel, Scope, erster Prototyp

Output am Ende von Tag 30

Ein Workflow, der in kontrolliertem Umfang mit echten Daten läuft.

Woche 1: Erfolg definieren

Ziel-KPI Auswahl
Wählt EINE Metrik, die zählt. Beispiele:

• Antwortzeit auf neue Anfragen: < 12 Stunden
• Dokumentenerstellung: < 30 Minuten
• Datenerfassungsgenauigkeit: > 95%
• Follow-up-Abschlussrate: 100%

Der KPI muss sein:

• Messbar (ihr könnt ihn heute tracken)
• Bedeutsam (er beeinflusst Mandantenerlebnis oder Umsatz)
• Beweglich (Automatisierung kann ihn realistisch verbessern)

Scope-Definition
Zieht eine klare Grenze, was dieser Workflow tut und nicht tut.

Woche 2: Prozess mappen

Ist-Zustand Dokumentation
Vor dem Automatisieren verstehen, was heute passiert:

1. Was triggert den Prozess?
2. Welche Schritte erfolgen (in welcher Reihenfolge)?
3. Wer macht welchen Schritt?
4. Woher kommen Daten und wohin gehen sie?
5. Welche Entscheidungen werden von wem getroffen?
6. Was kann schiefgehen?

Minimales Statusmodell
Definiert 3-5 Status, die den Fortschritt tracken:

• Neu (gerade eingegangen)
• In Bearbeitung (wird verarbeitet)
• Wartet auf Antwort (auf Mandant wartend)
• Abgeschlossen (fertig)
• Fehler (braucht Aufmerksamkeit)

Woche 3: Prototyp bauen

Einfach halten
Die erste Version sollte peinlich einfach sein. Wenn ihr mehr als 2 Systeme integriert, überkompliziert ihr.

Testfälle
Erstellt 3-5 Testfälle aus echten historischen Daten:

• Happy Path (alles funktioniert)
• Edge Case (ungewöhnliche aber valide Eingabe)
• Error Case (ungültige Eingabe, fehlende Daten)
• Boundary Case (hohes Volumen, große Dateien)

Jeden Testfall manuell durchlaufen, bevor automatisiert wird.

Woche 4: Kontrollierter Launch

Pilotgruppe
Startet mit einem Anwalt oder einem Rechtsgebiet. Nicht der ganzen Kanzlei.

Parallelbetrieb
Den manuellen Prozess 1-2 Wochen parallel zur Automatisierung weiterlaufen lassen. Ergebnisse vergleichen.

Tägliche Check-ins
Jemand schaut sich jeden Tag den Workflow-Output an. Keine Ausnahmen.

Anti-Patterns vermeiden

Integrations-Overload: "Wenn wir schon dabei sind, verbinden wir auch noch das Abrechnungssystem, den Kalender und die Dokumentenverwaltung." Nein. Eine Integration nach der anderen.

Perfektions-Paralyse: "Wir können nicht launchen, bis wir jeden Edge Case abdecken." Launcht mit 80% Abdeckung, behandelt Ausnahmen manuell.

Unsichtbare Automatisierung: "Das läuft einfach im Hintergrund." Jede Automatisierung braucht sichtbaren Status und Logging.

Tage 31-60: Stabilisieren (Betrieb)

Output am Ende von Tag 60

Betrieb ist "ruhig" - der Workflow läuft zuverlässig mit minimalem Eingriff.

Woche 5-6: Monitoring und Alerting

Was monitoren

• Ausführungs-Erfolgs-/Fehlerrate
• Verarbeitungszeit pro Item
• Queue-Tiefe (wartende Items)
• Fehlertypen und Häufigkeit

Alert-Philosophie
Nur auf handlungsrelevante Items alerten. Wenn ein Alert feuert und die Reaktion "ignorieren" ist, Alert entfernen.

Alert-Stufen

Woche 7-8: Fehlerbehandlung

Retry-Logik
Nicht jeder Fehler ist permanent. Automatische Retries für transiente Fehler bauen:

• API-Timeouts: 3x Retry mit exponentiellem Backoff
• Rate Limits: Retry nach Verzögerung
• Netzwerkfehler: 2x Retry

Dead Letter Queue
Items, die alle Retries fehlschlagen, gehen in eine Dead Letter Queue für manuelle Prüfung. Niemals Fehler stillschweigend verwerfen.

Graceful Degradation
Wenn ein nicht-kritischer Schritt fehlschlägt, Workflow fortsetzen und für Follow-up flaggen. Nicht den gesamten Prozess blockieren.

Woche 7-8: Dokumentation

Runbook-Minimum
Eine Seite, die beantwortet:

1. Was macht dieser Workflow?
2. Wie weiß ich, ob er funktioniert?
3. Was tue ich, wenn er kaputt ist?
4. Wen kontaktiere ich für Hilfe?

Architektur-Diagramm
Visual das zeigt: Trigger, Schritte, Integrationen, Outputs. Muss nicht hübsch sein. Muss akkurat sein.

Ownership-Modell

Primärer Owner
Eine Person verantwortlich für Workflow-Gesundheit. Sie bekommt Alerts, sie fixt Issues, sie genehmigt Änderungen.

Backup Owner
Eine Person, die bei Urlaub/Krankheit einspringen kann. Auf Runbook trainiert, hat Zugang zu allen Systemen.

Eskalationspfad
Wenn Owner und Backup nicht lösen können: Wer wird als nächstes angerufen?

Die 10-Minuten-Regel

Wenn ihr ein Problem nicht innerhalb von 10 Minuten diagnostizieren und anfangen könnt zu fixen, ist der Workflow nicht produktionsreif. Das bedeutet:

• Logs sind zugänglich und durchsuchbar
• Fehlermeldungen sind aussagekräftig
• Rollback-Prozedur existiert und ist getestet
• Jemand versteht, wie der Workflow funktioniert

Tage 61-90: Skalieren (ohne Komplexitäts-Explosion)

Output am Ende von Tag 90

1-2 weitere Use Cases identifiziert und gescoped. Operative Muster für Wiederverwendung dokumentiert.

Woche 9-10: Messen und Lernen

KPI-Review
Ziel-KPI vor und nach Automatisierung vergleichen:

• Baseline (vorher): Was war die Metrik?
• Aktuell (nachher): Was ist sie jetzt?
• Delta: Was hat sich geändert?
• Attribution: Wie viel ist auf Automatisierung zurückzuführen vs. andere Faktoren?

Operative Metriken

• Wie viele Items verarbeitet?
• Wie hoch ist die Fehlerrate?
• Wie viel manueller Eingriff nötig?
• Was sind die Kosten pro Item (wenn messbar)?

Lessons Learned
Dokumentieren was funktioniert hat, was nicht, was ihr anders machen würdet. Das informiert den nächsten Workflow.

Woche 11-12: Skalierung vorbereiten

Engpässe identifizieren
Was limitiert den Durchsatz?

• Datenqualitätsprobleme upstream
• Manuelle Genehmigungsschritte
• Integrations-Rate-Limits
• Verarbeitungskapazität

Zweiter Use Case Auswahl
Potenzielle nächste Workflows scoren nach:

• Impact (gesparte Zeit, betroffener Umsatz)
• Machbarkeit (Daten verfügbar, Integrationen möglich)
• Risiko (was passiert bei Ausfall)
• Abhängigkeiten (was muss sich noch ändern)

Die Option mit höchstem Impact/Machbarkeit und niedrigstem Risiko wählen.

Muster-Dokumentation
Was von diesem Workflow kann wiederverwendet werden?

• Monitoring-Setup
• Fehlerbehandlungs-Muster
• Dokumentations-Templates
• Test-Ansatz

Erfolgskriterien-Checkliste

Tag 30 Checkpoint

• Ziel-KPI definiert und Baseline ermittelt
• Scope dokumentiert (drin/draußen)
• Workflow läuft mit Testdaten
• 3-5 Testfälle bestehen
• Pilotgruppe identifiziert

Tag 60 Checkpoint

• Monitoring-Dashboard live
• Alerts konfiguriert und getestet
• Fehlerbehandlung implementiert
• Runbook geschrieben
• Owner und Backup zugewiesen
• 10-Minuten-Regel verifiziert

Tag 90 Checkpoint

• KPI-Verbesserung gemessen
• Operative Metriken getrackt
• Lessons Learned dokumentiert
• Zweiter Use Case gescoped
• Muster für Wiederverwendung dokumentiert

Häufige Fehlermodi

"Dokumentieren wir später"

Dokumentationsschulden kumulieren. Wenn ihr den Workflow heute nicht erklären könnt, könnt ihr ihn morgen nicht warten.

"Es funktioniert, shippen"

Funktionieren ist nicht dasselbe wie produktionsreif. Monitoring, Fehlerbehandlung und Ownership müssen vor "fertig" existieren.

"Lass uns noch ein Feature hinzufügen"

Scope Creep killt Timelines. Der 30/60/90 Plan handelt von Disziplin. Ergänzungen gehen in den nächsten Zyklus.

"Der Anbieter kümmert sich drum"

Anbieter liefern Tools, keine Ergebnisse. Interne Ownership ist nicht verhandelbar.

Nächster Schritt

Mappt euren ersten 30-Tage Scope:

1. Einen Workflow mit klarem KPI wählen
2. Scope-Grenzen definieren
3. Pilotgruppe identifizieren
4. Owner zuweisen

Klein starten, Wert beweisen, dann skalieren.

Leitfaden: KI-Automatisierung für Kanzleien

Passend:
Use-Case Scoring Modell