Die vier Arten von Arbeit in der IT – und wie Kanban bei der Planung hilft

Effiziente IT-Arbeit erfordert nicht nur technisches und fachliches Know-how, sondern auch eine klare Strukturierung der anfallenden Aufgaben. In der Praxis zeigt sich immer wieder: Der eigentliche Engpass liegt nicht im Arbeitseifer, sondern in der fehlenden Transparenz über welche Arten von Arbeit überhaupt anfallen – und wie diese organisiert und vor allem priorisiert werden.

Eine bewährte Methode zur Einordnung besteht in der Unterscheidung von vier typischen und grundlegenden Arbeitstypen in der IT. Diese Einteilung ermöglicht eine bessere Planung, Ressourcensteuerung und Kommunikation – insbesondere, wenn sie mit Kanban-basierten Tools wie Microsoft Planner oder Jira kombiniert wird.

Die vier Arten von Arbeit in der IT

1. Geschäftsprojekte (Business Projects)

Geschäftsprojekte sind Initiativen, die unmittelbar auf die strategischen Ziele und den Geschäftserfolg eines Unternehmens einzahlen. Sie werden typischerweise von Fachabteilungen oder dem Management initiiert und verfolgen messbare Business-Ziele wie Umsatzsteigerung, Kostensenkung, bessere Kundenerfahrung oder gesetzliche Konformität.

Diese Projekte haben in der Regel hohe Sichtbarkeit im Unternehmen, klare Zielsetzungen und konkrete Erfolgskriterien (KPIs). Die IT ist dabei oft als Enabler oder Projektpartner involviert.

Beispiele:

• Einführung eines Kundenportals
• Automatisierung von Bestellprozessen
• Integration eines neuen CRM-Systems
• Anbindung von Großkunden über EDI-Schnittstellen
• Mobile App zur Steuerung von Produkten (z. B. Rollläden oder Smart-Home-Komponenten)

Typische Merkmale:

• Ursprung meist außerhalb der IT (z. B. Vertrieb, Marketing, Produktion)
• Hoher Termindruck durch Kampagnen, Budgetfenster oder externe Fristen
• Oft projektbasiert mit dediziertem Budget und Lenkungskreis
• Erwartung schneller Ergebnisse („Time to Value“)
• Business-getrieben, nicht IT-getrieben

Herausforderungen bei der Umsetzung:

• Kapazitätskonflikte mit anderen Arbeitstypen (z. B. ungeplante Arbeit oder technische Projekte)
• Abhängigkeiten zu IT-Grundlagen, die möglicherweise nicht auf dem aktuellen Stand sind
• Fehlende realistische Planung, da interne technische Schulden nicht berücksichtigt wurden
• „Shadow IT“, wenn Business ohne Einbindung der IT eigene Lösungen umsetzt
• Priorisierungskonflikte, wenn mehrere Business-Projekte gleichzeitig laufen

Risikofaktoren:

• Vernachlässigung notwendiger Vorarbeiten (z. B. Authentifizierung, Netzwerksicherheit)
• Fehlende Einbindung der IT in der frühen Projektphase
• Mangelnde Berücksichtigung von Betrieb & Wartung nach Projektende
• Überlastung der IT durch unrealistische Zeitpläne und knappe Ressourcen
• Geringe Nachhaltigkeit, wenn Projekte rein kurzfristig angelegt sind

2. Interne IT-Projekte (Internal Projects)

Interne IT-Projekte sind strukturierte Vorhaben innerhalb der IT-Abteilung, die primär der Verbesserung, Stabilisierung oder dem Ausbau der IT-Systeme und -Prozesse dienen. Sie werden in der Regel von der IT selbst initiiert und betreffen Themen wie Infrastrukturmodernisierung, Systemmigrationen, Sicherheitsverbesserungen oder Prozessautomatisierung.

Diese Projekte haben meist keinen unmittelbaren Bezug zu einem einzelnen Geschäftsprozess, sind jedoch essenziell für die langfristige Leistungsfähigkeit und Zukunftssicherheit der IT-Landschaft – und damit auch des Unternehmens.

Beispiele:

• Migration auf neue Systeme
• Standardisierung von Netzwerkinfrastrukturen
• Umstellung auf moderne Authentifizierungsverfahren (z. B. MFA, Zero Trust)

Typische Merkmale:

• Ursprung innerhalb der IT (Projekte aus Architektur-, Infrastruktur- oder Betriebsbedarf)
• Ziel ist die Reduktion technischer Schulden oder die Erhöhung von Effizienz, Sicherheit und Skalierbarkeit
• Nicht immer mit sofort messbarem Business-Mehrwert, aber entscheidend für Stabilität
• Werden oft verschoben oder zu Gunsten von Geschäftsprojekten depriorisiert
• Werden im schlimmsten Fall erst angegangen, wenn „das Kind schon in den Brunnen gefallen ist“

Herausforderungen bei der Umsetzung:

• Geringe Sichtbarkeit im Unternehmen – oft wird Nutzen nicht verstanden oder anerkannt
• Ressourcenkonflikte mit Business-Projekten oder operativem Tagesgeschäft
• Verdrängung durch kurzfristige Anforderungen („Feuerwehrarbeit“)
• Technische Abhängigkeiten zu anderen Projekten oder Legacy-Systemen
• Unklare Priorisierung, wenn Nutzen nicht klar kommuniziert wird

Risikofaktoren:

• Aufschieben dringend notwendiger Modernisierungen
• Technische Schulden steigen weiter – „Schleichende Instabilität“
• Sicherheitslücken durch veraltete Systeme
• Unnötig hohe Betriebskosten durch ineffiziente Prozesse
• Projekte verlieren an Momentum, wenn keine klaren Verantwortlichkeiten bestehen

3. Geplante Änderungen (Changes)

Änderungen – auch als „Changes“ bezeichnet – sind kleine bis mittelgroße Anpassungen an bestehenden Systemen, Prozessen oder Konfigurationen. Sie sind typischerweise reaktiv oder evolutionär motiviert, entstehen häufig aus dem Tagesgeschäft heraus und haben in der Regel keinen Projektcharakter. Dennoch können sie erheblichen Einfluss auf Stabilität, Benutzerzufriedenheit oder Sicherheit haben.

Changes sind ein zentraler Bestandteil im IT-Betrieb und ein wesentliches Steuerungselement in der Service-Management-Praxis, insbesondere nach ITIL.

Beispiele:

• Einspielen von Sicherheitsupdates
• Deployment von Softwarepaketen
• Anpassung von Firewall-Regeln

Typische Merkmale:

• Umsetzung konkreter Fachbereichsanforderungen
• Fehlerbehebung oder Optimierung im laufenden Betrieb
• Reaktion auf externe Ereignisse (z. B. Sicherheitslücken, neue gesetzliche Vorgaben)
• Verbesserung der Nutzererfahrung oder Entlastung des Supports
• Sicherstellung der Systemverfügbarkeit oder Datenintegrität

Herausforderungen bei der Umsetzung:

• Fehlende Standardisierung in der Durchführung
• Unzureichende Dokumentation, wenn keine Change-Prozesse etabliert sind
• Nebeneffekte oder Seiteneffekte durch ungetestete Änderungen
• Abhängigkeiten zu anderen Systemen nicht erkannt
• Kumulierte Risiken, wenn viele Changes gleichzeitig umgesetzt werden

Risikofaktoren:

• Ausfall wichtiger Dienste durch schlecht geplante Änderung
• Rückfragen oder Eskalationen, wenn Fachbereiche nicht eingebunden sind
• Sicherheitsrisiken durch unsaubere Rechtevergaben
• Unklare Verantwortlichkeiten und Rollenzuordnung
• Fehlende Rollback-Strategien bei Problemen

4. Ungeplante Arbeit (Unplanned Work)

Ungeplante Arbeit umfasst alle Aufgaben, die kurzfristig, ungeplant und häufig unter Zeitdruck entstehen. Sie sind nicht im Voraus geplant, tauchen oft als Reaktion auf akute Probleme oder Störungen auf und unterbrechen bestehende Arbeitsabläufe. Diese Art von Arbeit ist hochgradig störend und reduziert die Produktivität und Planbarkeit eines Teams erheblich.

Beispiele:

• Ausfall zentraler Systeme
• Netzwerkausfall trotz Redundanz
• Sicherheitslücken mit sofortigem Handlungsbedarf

Typische Merkmale:

• Keine Vorankündigung oder Planung
• Hoher Druck zur sofortigen Bearbeitung
• Unterbrechung bestehender Aufgaben oder Projekte
• Häufig verbunden mit Störungen oder Eskalationen
• Kann wichtige Ressourcen blockieren
• Risiko: erzeugt technischen Schulden, wenn sie nicht nachbearbeitet wird

Herausforderungen bei der Umsetzung:

• Technisches Versagen
• Fehlkonfigurationen
• Fehlende Wartung oder übersehene Warnhinweise
• Sicherheitsvorfälle
• Menschliche Fehler
• Übersprungene Tests bei Changes oder Releases

Risiken und Nebenwirkungen:

• Verzögerung geplanter Projekte und Changes
• Erhöhte Belastung von IT-Personal
• Erhöhtes Fehlerpotenzial durch Hektik und fehlende Dokumentation
• Mangelnde Transparenz: viele Tätigkeiten „verschwinden“ in der Alltagshektik
• Keine nachhaltige Problemlösung: Symptome statt Ursachen werden bekämpft

Warum hilft diese Kategorisierung?

Durch die bewusste Unterscheidung dieser Arbeitstypen lassen sich verschiedene Vorteile erzielen:

• Transparenz: Aufgaben werden nachvollziehbar und priorisierbar
• Balance: Ressourcen lassen sich besser auf geplante und ungeplante Arbeit verteilen
• Kommunikation: Stakeholder verstehen, welche Aufgaben Kapazitäten binden
• Verbesserungspotenzial: Wiederkehrende Muster bei ungeplanter Arbeit können gezielt reduziert werden