Kanban: Definition, Praktiken und Einsatz im IT Service Management

Kanban ist eine Methode, mit der Teams den Fluss ihrer Arbeit sichtbar machen und steuern: Jede Aufgabe wird als Karte durch die Arbeitsschritte eines Boards geführt, und eine Obergrenze für gleichzeitig laufende Arbeit (WIP-Limit) sorgt dafür, dass neue Arbeit erst beginnt, wenn Kapazität frei ist. Das japanische Wort bedeutet etwa „Schild“ oder „Signaltafel“. Im Toyota-Produktionssystem lösten Kanban-Karten den Nachschub von Teilen aus, nur in der Menge, die tatsächlich verbraucht wurde.

Auf Wissens- und Servicearbeit wurde das Prinzip erst Jahrzehnte später übertragen. Der Kanban Guide verortet den Ursprung der heutigen Praxis in einem Team bei der Bildagentur Corbis im Jahr 2006, David J. Anderson beschrieb die Methode 2010 in Buchform. Für die Unternehmens-IT ist Kanban interessant, weil Service Desk, Betrieb und Change-Teams nicht in planbaren Projekten arbeiten, sondern einen laufenden Strom an Anfragen bewältigen. Kanban ersetzt dabei keine ITIL-Practice, es macht sichtbar, wie Arbeit durch sie fließt und wo sie stockt.

Das Wichtigste in Kürze

• Kernidee: Arbeit visualisieren, laufende Arbeit begrenzen, den Fluss aktiv steuern und das System schrittweise verbessern.
• Zwei Referenzen: die Kanban Method der Kanban University mit sechs Praktiken und sechs Prinzipien sowie der Kanban Guide (Fassung Mai 2025) mit drei Praktiken und vier Pflichtkennzahlen.
• Messbar: über WIP, Durchsatz, Alter laufender Arbeit (Work Item Age) und Durchlaufzeit (Cycle Time).
• Im ITSM: geeignet für Service Requests, die Bearbeitung von Störungen in Fachteams, Changes und Problembearbeitung. Das Board ist eine Sicht auf die Arbeit, das führende System bleibt das Ticket.

Stand: November 2026 · Fachlich abgeglichen mit dem Kanban Guide (2025), dem offiziellen Leitfaden der Kanban University, dem Scrum Guide, Microsoft Learn und PeopleCert (Quellen am Ende des Artikels)

So funktioniert Kanban: Board, WIP-Limit und Pull-Prinzip

Ein Kanban-System besteht aus wenigen Elementen. Entscheidend ist, dass sie zusammenwirken. Ein Board ohne Begrenzung der laufenden Arbeit ist eine Aufgabenliste mit Spalten, kein Kanban.

• Board und Karten: Spalten stehen für die Arbeitsschritte, Karten für einzelne Arbeitselemente. Ein Board für Service Requests kann etwa die Spalten „Eingang“, „Geprüft“, „In Umsetzung“, „Wartet auf Freigabe“ und „Erledigt“ haben. Die Spalten bilden den tatsächlichen Ablauf ab, nicht den gewünschten.
• WIP-Limit: Für einzelne Spalten oder den ganzen Ablauf gilt eine Obergrenze. Ist „In Umsetzung“ auf sechs Karten begrenzt und voll, beginnt niemand etwas Neues, sondern hilft, Begonnenes abzuschließen. Die Kanban University fasst das in die Formel „Stop starting, start finishing“.
• Pull statt Push: Arbeit wird nicht zugeteilt, sondern in den nächsten Schritt gezogen, sobald dort Kapazität frei ist. Der Punkt, an dem das Team eine Anfrage verbindlich annimmt, heißt Zusagepunkt (Commitment Point).
• Explizite Regeln: Wann eine Karte weiterziehen darf, was als erledigt gilt, wie dringende Fälle behandelt werden und wer das Board auffüllt, steht schriftlich fest. Dringendes läuft oft in einer eigenen Serviceklasse „Expedite“ mit eigenem, kleinem Limit.

Die sechs Praktiken der Kanban Method

Der Leitfaden der Kanban University nennt sechs allgemeine Praktiken: Arbeit visualisieren, laufende Arbeit begrenzen, den Fluss steuern, Regeln explizit machen, Feedbackschleifen einrichten sowie gemeinsam verbessern und experimentell weiterentwickeln. Dazu kommen Prinzipien für die Veränderung, allen voran „Start with what you do now“: Kanban beginnt beim heutigen Ablauf, mit den bestehenden Rollen, und verbessert ihn schrittweise. Diese Haltung unterscheidet Kanban von Einführungen, die zuerst eine neue Organisation festlegen.

Der Kanban Guide: drei Praktiken, vier Kennzahlen

Der Kanban Guide von Daniel Vacanti und John Coleman beschreibt Kanban knapper als Strategie zur Optimierung des Wertflusses durch einen Prozess. Er verlangt drei Praktiken (Workflow definieren und visualisieren, laufende Elemente aktiv steuern, Workflow verbessern) und eine „Definition of Workflow“. Zu ihr gehören Start- und Endpunkte, die Zustände dazwischen, die Art der WIP-Steuerung, explizite Regeln und eine Service Level Expectation. Für Organisationen, die mehrere Teams einheitlich aufstellen wollen, ist diese Definition ein brauchbares Raster.

Kanban und Scrum: Unterschiede und Kombination

Kanban und Scrum werden oft als Alternativen genannt, setzen aber an unterschiedlichen Stellen an. Scrum ist laut Scrum Guide ein Rahmenwerk mit festen Verantwortlichkeiten und Sprints von höchstens einem Monat. Kanban schreibt weder Rollen noch Iterationen vor, sondern regelt den Fluss der Arbeit. Beides lässt sich kombinieren, Scrum.org hat dafür einen eigenen Kanban Guide for Scrum Teams veröffentlicht.

In der Unternehmens-IT laufen beide Ansätze oft nebeneinander: Entwicklungsteams planen in Sprints, Betriebs- und Supportteams arbeiten mit Kanban, weil sich Störungen nicht auf den nächsten Sprint verschieben lassen. Wichtig ist eine saubere Übergabe zwischen beiden Welten, etwa wenn aus einem Problem ein Fehler im Produkt-Backlog wird. Mehr dazu im Glossarartikel DevOps.

Kanban, Lean und ITIL 4

ITIL 4 schreibt keine Arbeitsmethode vor, seine Leitprinzipien passen aber zu Kanban: „Start where you are“ entspricht dem Kanban-Grundsatz, beim heutigen Ablauf anzusetzen, „Progress iteratively with feedback“ den Feedbackschleifen und „Collaborate and promote visibility“ der Visualisierung. Laut PeopleCert übernimmt auch ITIL (Version 5) die Leitprinzipien. Die Wurzeln im Lean-Denken teilt Kanban mit Kaizen, der Idee der kleinen, stetigen Verbesserung.

Kanban im IT Service Management

Kanban wirkt im ITSM am besten dort, wo Arbeit in wiederkehrenden Schritten abläuft und Wartezeiten entstehen, die bisher niemand sieht. Vier Einsatzfelder haben sich herausgebildet:

• Service Request Management: Standardanfragen wie Zugänge, Hardware oder Softwareinstallationen durchlaufen feste Schritte. Ein Board zeigt, wie viele Anfragen auf Freigaben oder Lieferungen warten.
• Incidents in Fachteams: Die Erstannahme bleibt im Service Desk mit seiner Priorisierung. Für die Bearbeitung in Netzwerk-, Server- oder Applikationsteams hilft ein Board mit WIP-Limit und einer Expedite-Spur für Störungen der höchsten Priorität.
• Change Enablement: Changes ziehen von „Beantragt“ über „Bewertet“ und „Freigegeben“ bis „Überprüft“. Das Board ersetzt die Bewertung und Freigabe nicht, es macht sichtbar, wo Changes liegen bleiben.
• Problem Management: Ursachenanalysen ziehen sich oft über Wochen. Ein eigenes Board mit wenigen gleichzeitigen Problemen verhindert, dass jede Root Cause Analysis begonnen und keine abgeschlossen wird.

Board und Ticketsystem: ein führendes System

Der häufigste Strukturfehler ist ein zweites System. Wenn Teams Tickets im ITSM-Tool führen und parallel Karten in einem separaten Board-Werkzeug pflegen, entstehen zwei Wahrheiten, und SLA-Uhren, Historie und Kennzahlen hängen am falschen Ort. Das Board sollte deshalb eine Sicht auf die Tickets sein, nicht eine Kopie. Für die Skalierung über mehrere Teams gilt: Statusbegriffe und Start- und Endpunkte einheitlich definieren, WIP-Limits aber je Team festlegen, weil Teamgröße und Arbeitsart variieren.

Beispiel: Arbeitsplatz-Services mit Kanban

Angenommen, das Team Arbeitsplatz-Services eines Industrieunternehmens mit mehreren Werken bearbeitet Service Requests für Notebooks, Software und Berechtigungen. Es definiert fünf Schritte, begrenzt „In Umsetzung“ auf acht Anfragen und macht die Spalte „Wartet auf Freigabe“ sichtbar. Nach einigen Wochen zeigt das Alter der Karten, dass nicht die Umsetzung bremst, sondern ausstehende Freigaben durch Vorgesetzte. Die Verbesserung liegt dann außerhalb des Teams: eine Erinnerung im Workflow oder vorab genehmigte Standardanfragen. Ohne Board wäre der Engpass im Team gesucht worden.

In ky2help^® bilden Sie solche Abläufe als Workflows im Prozessdesigner ab. Zeit- und aktionsgesteuerte Workflows, SLA-Überwachung mit Benachrichtigung und ein flexibles Eskalationsmanagement gehören zum Funktionsumfang. Arbeiten Entwicklungsteams mit Jira, ist die Schnittstelle dorthin im Standard enthalten.

Workflows automatisieren

Flusskennzahlen und typische Fehler

Der Kanban Guide schreibt vier Kennzahlen vor. Sie messen das System, nicht die Leistung einzelner Personen:

• WIP: Anzahl der begonnenen, aber nicht abgeschlossenen Elemente.
• Durchsatz (Throughput): Anzahl der abgeschlossenen Elemente pro Zeiteinheit, etwa pro Woche.
• Alter (Work Item Age): Zeit seit dem Start eines noch offenen Elements. Diese Kennzahl zeigt Probleme, solange sie sich noch beheben lassen.
• Durchlaufzeit (Cycle Time): Zeit vom Start bis zum Abschluss eines Elements.

Die Kennzahlen hängen zusammen. Nach dem Gesetz von Little gilt in einem stabilen System im Mittel: Durchlaufzeit = WIP ÷ Durchsatz. Ein Rechenbeispiel: Sind dauerhaft 60 Anfragen in Arbeit und werden 20 pro Arbeitstag abgeschlossen, dauert eine Anfrage im Durchschnitt drei Arbeitstage. Wer die Durchlaufzeit senken will, ohne mehr Personal einzusetzen, muss deshalb die laufende Arbeit verringern.

Service Level Expectation und SLA

Die Service Level Expectation (SLE) ist eine Prognose des Teams, etwa „85 % der Elemente sind in acht Tagen oder weniger erledigt“, berechnet aus den bisherigen Durchlaufzeiten. Ein Service Level Agreement ist dagegen eine Vereinbarung mit dem Kunden. Liegt die SLE dauerhaft über dem vereinbarten SLA-Ziel, ist das SLA mit dem heutigen System nicht erreichbar, und das ist früher erkennbar als über verletzte Fristen.

Fünf typische Fehler

1. Wunschprozess statt Realität: Das Board zeigt den dokumentierten Ablauf, nicht den gelebten. Wartezustände fehlen, und damit die eigentlichen Engpässe.
2. Keine oder ignorierte Limits: Ohne WIP-Limit entsteht kein Pull-System. Ausnahmen sind erlaubt, sie müssen aber als Regel festgelegt sein.
3. Auslastung statt Fluss: Volle Auslastung aller Personen verlängert Wartezeiten. Die Kanban University vergleicht das mit einer Autobahn im Berufsverkehr.
4. Zweites System: Ein separates Board neben dem ITSM-Tool führt zu doppelter Pflege und widersprüchlichen Kennzahlen.
5. Kennzahlen als Leistungsbeurteilung: Werden Durchsatz und Durchlaufzeit zur Bewertung Einzelner genutzt, werden Karten zerlegt oder spät angelegt, und die Daten verlieren ihren Wert. Passende KPIs setzen am System an.

Häufige Fragen zu Kanban

Was ist Kanban einfach erklärt?

Kanban ist eine Methode, um Arbeit auf einem Board mit Spalten sichtbar zu machen und nur so viel gleichzeitig zu beginnen, wie ein Team abschließen kann. Neue Aufgaben werden erst gezogen, wenn ein Platz frei wird. Das verkürzt Wartezeiten und macht Engpässe sichtbar.

Was ist der Unterschied zwischen Kanban und Scrum?

Scrum arbeitet in Sprints von höchstens einem Monat und legt Verantwortlichkeiten wie Product Owner und Scrum Master fest. Kanban kennt weder feste Iterationen noch vorgeschriebene Rollen und steuert die Arbeit über WIP-Limits und einen kontinuierlichen Fluss. Beide Ansätze lassen sich kombinieren.

Was ist ein WIP-Limit?

Ein WIP-Limit ist die Obergrenze für Arbeitselemente, die sich gleichzeitig in einem Schritt oder im ganzen Workflow befinden dürfen. Eine feste Formel gibt es nicht. Ein pragmatischer Einstieg ist, die heutige Zahl paralleler Arbeit zu beobachten, das Limit etwas darunter anzusetzen und es anhand der Kennzahlen anzupassen.

Welche Kennzahlen gehören zu Kanban?

Der Kanban Guide nennt vier Pflichtkennzahlen: WIP, Durchsatz, das Alter laufender Elemente (Work Item Age) und die Durchlaufzeit (Cycle Time). Aus den bisherigen Durchlaufzeiten leitet das Team zudem eine Service Level Expectation ab, also eine Prognose, wie lange ein Element in der Regel dauert.

Eignet sich Kanban für den Service Desk?

Ja, vor allem für Service Requests, die Bearbeitung von Störungen in Fachteams, Changes und Problembearbeitung. Dringende Störungen laufen dabei in einer eigenen Serviceklasse mit eigenem Limit. Wichtig ist, dass das Board eine Sicht auf die Tickets ist und kein zweites System neben dem ITSM-Tool.

Kann man Kanban mit ky2help® umsetzen?

In ky2help^® legen Sie die Arbeitsschritte Ihrer Serviceprozesse als Workflow im Prozessdesigner fest, SLA-Überwachung und Eskalationen gehören zum Funktionsumfang, und im Live-Dashboard erstellen Sie individualisierbare Reports. Wie sich ein Kanban-Vorgehen mit WIP-Limits und Flusskennzahlen in Ihrer Organisation abbilden lässt, klären wir am besten in einer Live-Demo.

Quellen und weiterführende Artikel

Quellen

• Vacanti, Coleman: The Kanban Guide (Fassung Mai 2025)
• Kanban University: The Official Guide to The Kanban Method
• Schwaber, Sutherland: The Scrum Guide (November 2020)
• Scrum.org: Kanban Guide for Scrum Teams
• Microsoft Learn: Informationen zu Kanban-Boards (Azure Boards)
• PeopleCert: ITIL 4 Foundation und FAQ zu ITIL (Version 5)
• Toyota Motor Corporation: Toyota Production System
• Little, J. D. C.: Little’s Law as Viewed on Its 50th Anniversary. Operations Research 59 (3), 2011

Weiterlesen im Glossar und in der Wissenswelt

• Scrum, Sprint und Backlog
• Kaizen und Continual Service Improvement (CSI)
• IT Service Management (ITSM) und ITIL
• KPI und Service Level Agreement (SLA)
• Der agile Service Desk: klassisch vs. agil nach ITIL 4