Kaizen: Bedeutung, Prinzipien und Einsatz im IT Service Management

Kaizen ist eine Managementphilosophie, nach der eine Organisation ihre Abläufe in kleinen, stetigen Schritten verbessert, und zwar unter Beteiligung aller Mitarbeitenden, von der Leitung bis zur ausführenden Ebene. Das japanische Wort setzt sich aus den Schriftzeichen für „ändern“ (kai) und „gut“ (zen) zusammen und bedeutet schlicht „Verbesserung“. Im Toyota-Produktionssystem gehört die tägliche, schrittweise Verbesserung durch alle Beschäftigten zum Alltag.

Einem breiten Publikum außerhalb Japans hat Masaaki Imai den Begriff 1986 mit seinem Buch „Kaizen: The Key to Japan’s Competitive Success“ bekannt gemacht. In deutschen Unternehmen ist der Ansatz meist als kontinuierlicher Verbesserungsprozess (KVP) verbreitet. Für die Unternehmens-IT ist Kaizen mehr als eine Haltung: Die Continual-Improvement-Practice in ITIL 4 und die Verbesserungsanforderungen in Managementsystemnormen beruhen auf denselben Grundgedanken.

Das Wichtigste in Kürze

• Kernidee: viele kleine, geprüfte Verbesserungen statt seltener Großprojekte. Jede bewährte Änderung wird zum neuen Standard.
• Werkzeuge: der PDCA-Zyklus, die Frage nach dem Warum (5 Why), der Blick auf den Ort der Arbeit (Gemba) und das Erkennen von Verschwendung (Muda).
• Abgrenzung: Kaikaku steht für sprunghafte, radikale Veränderung. KVP ist die deutsche Umsetzung von Kaizen, CSI und Continual Improvement sind die ITIL-Fassungen.
• In der IT: wirksam bei wiederkehrenden Störungen, Service Requests, Wissensartikeln und Changes, wenn Verbesserungen zentral erfasst und gemessen werden.

Stand: November 2026 · Fachlich abgeglichen mit dem Lean Enterprise Institute, dem Kaizen Institute, Toyota, PeopleCert und dem BSI-Standard 200-1 (Quellen am Ende des Artikels)

Die Prinzipien und Werkzeuge von Kaizen

Kaizen ist keine einzelne Methode, sondern ein Bündel von Grundsätzen. Fünf davon tragen den Ansatz und lassen sich direkt auf Serviceorganisationen übertragen.

1. Ohne Standard keine Verbesserung

Verbesserung braucht einen Ausgangspunkt. Das Lean Enterprise Institute beschreibt standardisierte Arbeit als dokumentierten Ist-Ablauf, der zugleich „Gegenstand der kontinuierlichen Verbesserung durch Kaizen“ ist. Für die IT heißt das: Erst wenn ein Ablauf beschrieben ist, etwa als Workflow oder Standard Operating Procedure, lässt sich eine Änderung bewerten und auf alle Teams übertragen.

2. Der PDCA-Zyklus als Taktgeber

Jede Kaizen-Verbesserung durchläuft den Zyklus Plan, Do, Check, Act: Ziel und Änderung planen, im Kleinen umsetzen, das Ergebnis messen und die Änderung bei Erfolg standardisieren. Der Zyklus geht auf Walter A. Shewhart zurück. W. Edwards Deming brachte ihn in den 1950er-Jahren nach Japan, 1951 formte die Japanese Union of Scientists and Engineers daraus die heute bekannte PDCA-Form. Deming selbst sprach später von PDSA, mit „Study“ statt „Check“.

3. Gemba: dorthin gehen, wo die Arbeit stattfindet

Gemba bedeutet „der tatsächliche Ort“. Gemeint ist die Stelle, an der Wert entsteht. Im Service Desk ist das die Ticketbearbeitung selbst: Wer verstehen will, warum Anfragen lange dauern, liest Tickets, hört bei Telefonaten zu oder begleitet eine Technikerin beim Einsatz, statt nur Berichte auszuwerten.

4. Verschwendung erkennen: Muda, Mura, Muri

Toyota unterscheidet drei Formen: Muda ist alles, was Ressourcen verbraucht, ohne dem Kunden zu nutzen. Mura ist Ungleichmäßigkeit, Muri Überlastung. Typische Muda in der IT sind Rückfragen wegen unvollständiger Anfragen, doppelt erfasste Daten, Wartezeiten auf Freigaben und Tickets, die mehrfach weitergeleitet werden. Mura zeigt sich als Ticketspitze nach jedem Patchday, Muri als dauerhaft überbuchtes Second-Level-Team.

5. Ursachen statt Symptome: die 5-Why-Methode

Taiichi Ohno, der Architekt des Toyota-Produktionssystems, empfahl, bei jedem Problem so lange nach dem Warum zu fragen, bis die Grundursache erreicht ist. Die Zahl fünf ist dabei nach dem Lean Enterprise Institute nicht entscheidend. In der IT ist das die Logik des Problem Managements und der Root Cause Analysis: nicht das Symptom beheben, sondern die Ursache, damit der Fehler nicht wiederkehrt.

Kaizen, Kaikaku, KVP und CSI im Vergleich

Rund um Kaizen kursieren mehrere Begriffe, die sich überschneiden. Die wichtigste Unterscheidung betrifft das Tempo und die Größe der Veränderung. Das Lean Enterprise Institute stellt Kaizen dem Kaikaku gegenüber, der radikalen Neugestaltung eines Ablaufs, die auch „breakthrough kaizen“ genannt wird.

Beide Formen schließen sich nicht aus. Der BSI-Standard 200-1 beschreibt für das Sicherheitsmanagement dasselbe Muster: Ergebnisse der Erfolgskontrolle führen zu Korrekturen, und bei größeren Veränderungen beginnt der Managementkreislauf mit einer neuen Planungsphase.

KVP und Kaizen-Workshop

Der kontinuierliche Verbesserungsprozess (KVP) ist die in Deutschland übliche Bezeichnung für Kaizen im Unternehmen, oft mit Vorschlagswesen und festen Verbesserungsrunden. Davon zu unterscheiden ist der Kaizen-Workshop: eine Gruppenaktivität, die laut Lean Enterprise Institute meist fünf Tage dauert und einen Ablauf in dieser Zeit analysiert, umbaut und standardisiert. Der Workshop ist ein Werkzeug, Kaizen selbst ist die tägliche Praxis.

Kaizen, CSI und Continual Improvement in ITIL

In ITIL v3 hieß die Verbesserungsphase Continual Service Improvement (CSI). ITIL 4 hat die Lebenszyklusphasen aufgegeben. Kontinuierliche Verbesserung ist dort eine Komponente des Service-Wertsystems, eine Aktivität der Wertschöpfungskette („Improve“) und eine eigene Practice (Continual Improvement). Laut PeopleCert übernimmt auch ITIL (Version 5) die Leitprinzipien aus ITIL 4 und behält Continual Improvement als Practice. Kaizen liefert dazu die Kultur, ITIL den organisatorischen Rahmen mit Verbesserungsregister, Verantwortlichkeiten und Bezug zu den übrigen Practices.

Kaizen im IT Service Management umsetzen

In einer IT-Organisation mit mehreren Teams und Standorten entscheidet nicht die Zahl der Ideen über den Erfolg, sondern ob Verbesserungen erfasst, priorisiert, umgesetzt und übertragen werden. Vier Ansatzpunkte haben sich bewährt:

• Wiederkehrende Incidents: Häufen sich Störungen mit gleichem Muster, wird daraus ein Problem mit Ursachenanalyse. Der bekannte Fehler und sein Workaround landen in der Known-Error-Datenbank, bis die Ursache behoben ist.
• Service Requests: Rückfragen deuten auf fehlende Pflichtangaben hin. Ein angepasstes Formular im Self-Service-Portal beseitigt die Ursache für alle künftigen Anfragen.
• Wissensartikel: Jede Lösung, die ein zweites Mal gesucht wird, gehört in die Wissensdatenbank. Veraltete Artikel werden überarbeitet oder entfernt.
• Changes: Verbesserungen, die Systeme betreffen, laufen über das Change Enablement. Wiederkehrende, risikoarme Änderungen lassen sich als vorab genehmigte Standard-Changes festlegen.

Standardisieren und skalieren

Damit Kaizen über ein Team hinaus wirkt, braucht es ein zentrales Verbesserungsregister mit Auslöser, Maßnahme, verantwortlicher Person, Status und Wirkung. Teams verbessern ihre eigenen Abläufe selbstständig. Betrifft eine Verbesserung einen gemeinsamen Prozess, entscheidet der Process Owner, ob sie für alle Standorte gilt. So entstehen keine lokalen Varianten, die später niemand mehr pflegen kann.

Beispiel: Fünfmal Warum im Service Desk

Angenommen, der Service Desk eines Industrieunternehmens erhält jeden Montag auffällig viele Meldungen, dass das VPN nicht funktioniert. Warum? Die Clients können sich nicht anmelden. Warum? Ihr Gerätezertifikat ist abgelaufen. Warum wurde es nicht erneuert? Die Geräte waren über Wochen nicht im Firmennetz. Warum fiel das nicht auf? Niemand überwacht das Ablaufdatum der Zertifikate. Warum nicht? Die Aufgabe ist keinem Team zugeordnet. Die Verbesserung liegt also nicht im Service Desk, sondern in einer klaren Zuständigkeit und einer Überwachung mit Vorwarnung. Erst wenn die Montagsspitze ausbleibt, wird der neue Ablauf zum Standard.

ky2help^® bildet die dafür nötigen Abläufe ab: Workflows passen Sie im Prozessdesigner ohne Programmierer an, Problem Management und Known-Error-Datenbank gehören zum Funktionsumfang, und die zentrale Wissensdatenbank hält Lösungen für alle Teams bereit. Die Auswirkung einer Änderung verfolgen Sie über Messgrößen ab Werk mit DrillDown-Funktion.

Prozesse automatisieren

Kennzahlen, Erfolgsfaktoren und typische Fehler

Kaizen ohne Messung bleibt Meinung. Vor jeder Änderung wird ein Ausgangswert erhoben, danach wird geprüft, ob die Wirkung eintritt und anhält. Geeignete KPIs im ITSM sind:

• Wiederholungsquote: Anteil der Incidents mit bereits bekannter Ursache.
• Wiedereröffnete Tickets: Hinweis auf Lösungen, die nicht tragen.
• Lösung beim Erstkontakt: zeigt, ob Wissen und Berechtigungen dort liegen, wo Anfragen ankommen.
• Durchlaufzeit je Anfrageart: macht Wartezeiten auf Freigaben und Rückfragen sichtbar.
• Umgesetzte Verbesserungen: Anzahl und Alter offener Einträge im Verbesserungsregister.

Lernen ohne Schuldzuweisung

Kaizen setzt voraus, dass Fehler offen angesprochen werden. Google beschreibt in seinem SRE-Handbuch das Prinzip der „blameless postmortems“: Die Nachbetrachtung eines Vorfalls sucht beitragende Ursachen, ohne Einzelne oder Teams zu beschuldigen. Wer für Fehler bestraft wird, meldet sie nicht mehr, und damit fehlen die Ansatzpunkte für Verbesserungen.

Fünf typische Fehler

1. Vorschlagswesen ohne Umsetzung: Ideen werden gesammelt, aber nicht entschieden. Nach kurzer Zeit kommen keine mehr.
2. Kaizen als Sparprogramm: Wird jede Verbesserung in Stellenabbau übersetzt, beteiligt sich niemand mehr.
3. Kein dokumentierter Standard: Ohne beschriebenen Ablauf fällt das Team nach wenigen Wochen in alte Muster zurück.
4. Nur Workshops: Ein jährlicher Verbesserungstag ersetzt nicht die laufende Arbeit an kleinen Hindernissen.
5. Kennzahlen gegen Personen: Werden Kennzahlen zur Bewertung Einzelner genutzt, werden Daten geschönt, und das System bleibt unverändert.

Häufige Fragen zu Kaizen

Was bedeutet Kaizen?

Kaizen ist japanisch und bedeutet „Verbesserung“. Als Managementansatz steht der Begriff für die kontinuierliche Verbesserung in kleinen Schritten, an der alle Mitarbeitenden beteiligt sind, von der Leitung bis zur ausführenden Ebene.

Was ist der Unterschied zwischen Kaizen und KVP?

Inhaltlich meinen beide dasselbe. KVP, der kontinuierliche Verbesserungsprozess, ist die in Deutschland verbreitete Bezeichnung für die Umsetzung von Kaizen im Unternehmen, häufig verbunden mit Vorschlagswesen und festen Verbesserungsrunden.

Was ist der Unterschied zwischen Kaizen und Kaikaku?

Kaizen verbessert einen bestehenden Ablauf in kleinen, laufenden Schritten. Kaikaku ist eine radikale, schnelle Neugestaltung, etwa der Umstieg auf ein neues System. Viele Organisationen nutzen beides: Kaikaku für den großen Umbau, Kaizen für die Feinarbeit danach.

Welche Methoden gehören zu Kaizen?

Zu den verbreiteten Werkzeugen zählen der PDCA-Zyklus, die 5-Why-Methode zur Ursachenanalyse, 5S für geordnete Arbeitsplätze, standardisierte Arbeit, Gemba Walks und der Kaizen-Workshop. Welche Werkzeuge passen, hängt vom Problem ab.

Wie hängen Kaizen und ITIL zusammen?

ITIL 4 verankert kontinuierliche Verbesserung im Service-Wertsystem, in der Wertschöpfungskette und als eigene Practice (Continual Improvement). In ITIL v3 hieß die Verbesserungsphase Continual Service Improvement (CSI). Kaizen liefert die Haltung dahinter: kleine, gemessene Schritte unter Beteiligung aller.

Wie unterstützt ky2help® Kaizen im IT-Service?

ky2help® bietet einen Prozessdesigner, mit dem Sie Workflows ohne Programmierer anpassen, dazu Messgrößen ab Werk mit DrillDown, eine Known-Error-Datenbank und eine zentrale Wissensdatenbank. Wie sich ein Verbesserungsprozess in Ihrer Organisation abbilden lässt, zeigen wir in einer Live-Demo.

Quellen und weiterführende Artikel

Quellen

• Lean Enterprise Institute: Kaizen, Plan, Do, Check, Act (PDCA), Kaikaku, Kaizen Workshop, Muda, Mura, Muri
• Kaizen Institute: What is KAIZEN (Definition und Geschichte, Masaaki Imai)
• Toyota Motor Corporation: Toyota Production System
• PeopleCert: FAQ zu ITIL (Version 5)
• BSI: BSI-Standard 200-1 Managementsysteme für Informationssicherheit
• Google: Site Reliability Engineering, Kapitel 15: Postmortem Culture

Weiterlesen im Glossar

• Continual Service Improvement (CSI) und ITIL
• Root Cause Analysis und Standard Operating Procedure
• Kanban und DevOps
• KPI und Balanced Scorecard
• IT Service Management (ITSM) und Change Management