IAllgemein

IT-Betriebsmodell (Run vs. Change)

Trennt Betrieb (Run) von Weiterentwicklung/Projekten (Change).
3 Aufrufe

Ein IT-Betriebsmodell (Run vs. Change) ist eine Organisations- und Steuerungslogik, die den stabilen IT-Betrieb (Run) klar von der Weiterentwicklung, Projekten und Verbesserungen (Change) trennt. Ziel ist, dass kritische Systeme zuverlässig laufen, während parallel neue Anforderungen planbar umgesetzt werden – ohne dass das Tagesgeschäft die Entwicklung „auffrisst“ oder umgekehrt Änderungen den Betrieb destabilisieren.

Was bedeutet „Run“ und „Change“?

  • Run (Betrieb): Alles, was den laufenden Service sicherstellt: Monitoring, Incident- und Problem-Management, Benutzer-Support, Patchen, Backups, Rechteverwaltung, Verfügbarkeit, Kostenkontrolle sowie das Einhalten von SLAs.
  • Change (Veränderung): Alles, was etwas neu macht oder wesentlich verändert: neue Funktionen, Systemeinführungen, Prozessdigitalisierung, Integrationen, Cloud-Migration, Sicherheits- oder Architekturverbesserungen, Automatisierungsvorhaben (z. B. mit Automatisierung (Automation) oder n8n).

Wie funktioniert ein Run-vs.-Change-Modell in der Praxis?

In der Umsetzung werden Aufgaben, Budgets, Verantwortlichkeiten und Prioritäten getrennt gesteuert. Typisch ist:

  • Getrennte Backlogs: Run-Tickets (Störungen, Service Requests) vs. Change-Backlog (Features, Projekte).
  • Klare Priorisierungsregeln: Run hat Vorrang bei kritischen Incidents; Change wird über Roadmaps, Business Value und Kapazitätsplanung gesteuert.
  • Kapazitäts-Split: z. B. 70% Run / 30% Change (oder umgekehrt in Wachstumsphasen). Wichtig ist, dass Change-Kapazität „geschützt“ wird.
  • Change-Governance: Änderungen werden bewertet (Risiko, Aufwand, Nutzen), getestet und kontrolliert ausgerollt, um Ausfälle zu vermeiden.

Warum ist das wichtig – besonders ohne eigene IT-Abteilung?

Unternehmen ohne interne IT erleben häufig zwei typische Probleme: (1) Der Dienstleister reagiert nur auf Störungen (Run dominiert), strategische Themen bleiben liegen. Oder (2) Es werden Projekte gestartet (Change dominiert), aber Betrieb, Dokumentation und Sicherheit sind nicht sauber geregelt. Ein Run-vs.-Change-Betriebsmodell schafft hier Entscheidungssicherheit, weil es Erwartungen und Liefergegenstände messbar macht.

  • Planbarkeit: Sie sehen, welche Ressourcen für Stabilität vs. Weiterentwicklung eingesetzt werden.
  • Weniger Risiko: Änderungen werden kontrolliert eingeführt, was Ausfälle und Sicherheitslücken reduziert.
  • Transparente Kosten: Run-Kosten sind eher wiederkehrend, Change-Kosten eher projektbasiert – das erleichtert Budgetierung und ROI-Betrachtung.

Beispiel

Ein 50-Personen-Unternehmen nutzt Microsoft 365, ein ERP und einige SaaS-Tools. Run umfasst: Benutzer anlegen, MFA-Probleme lösen, Updates, Backup-Checks, Security-Monitoring. Change umfasst: ERP-Schnittstelle zum Shop, Einführung eines Ticketsystems, Aufbau einer Wissensdatenbank, Automatisierung von Onboarding-Prozessen. Ohne Trennung würde das Projekt „Schnittstelle“ ständig durch Supportfälle verzögert.

Was kostet ein Run-vs.-Change-Betriebsmodell?

Das Modell selbst ist kein Produkt, aber es beeinflusst die Preislogik: Run wird häufig als Managed Service mit monatlicher Pauschale angeboten, Change als Projekt oder Retainer (Stunden-/Tageskontingent). Die Kosten hängen vor allem von Systemlandschaft, Sicherheitsanforderungen, gewünschter Reaktionszeit (SLA) und Change-Volumen ab.

Zahlen & Fakten

0%
weniger BetriebsstörungenKMU mit klar getrennten Run- und Change-Verantwortlichkeiten reduzieren ungeplante Störungen, weil Betrieb und Weiterentwicklung sauber priorisiert werden.
0%
schnellere ReleasesEin definiertes IT-Betriebsmodell beschleunigt Change-Vorhaben, da Projekte nicht permanent durch operative Tagesaufgaben ausgebremst werden.
0%
geringere IT-KostenUnternehmen mit strukturierter Trennung von Run und Change senken häufig ihre IT-Gesamtkosten, weil Ressourcen, Budgets und externe Leistungen transparenter gesteuert werden.

Anwendungsfälle in der Praxis

Produktion
ERP-Betrieb stabil halten und Updates als eigenes Change-Programm steuern
Ein mittelständischer Fertigungsbetrieb trennt den täglichen ERP-Support für Einkauf, Lager und Buchhaltung klar von Einführungsprojekten wie einem neuen Produktionsmodul. Das Run-Team bearbeitet Incidents und sichert Verfügbarkeit, während das Change-Team Anforderungen priorisiert, Tests koordiniert und Releases plant. So werden Störungen im Tagesgeschäft reduziert und Weiterentwicklungen schneller und kontrollierter umgesetzt.

Hast du dein IT-Betriebsmodell für Run und Change klar aufgestellt?

Beantworte 5 kurze Fragen und finde heraus, wo du stehst.
Sind bei euch Betriebsaufgaben (Run) und Weiterentwicklung bzw. Projekte (Change) grundsätzlich voneinander getrennt?
Sind Rollen, Verantwortlichkeiten und Entscheidungswege für Run und Change klar definiert?
Plant und steuert ihr Kapazitäten, Budgets und Prioritäten getrennt für Betrieb und Veränderung?
Gibt es feste Übergaben zwischen Change und Run, zum Beispiel für Tests, Dokumentation und Betriebsübernahme?
Messt ihr die Leistung von Run und Change mit eigenen Kennzahlen und verbessert das Modell regelmäßig?

Ist dein IT-Betriebsmodell klar zwischen Run und Change getrennt?

Viele Unternehmen wissen zwar, was mit Run und Change gemeint ist, trennen Betrieb und Weiterentwicklung im Alltag aber nicht sauber. Genau das führt oft zu Tool-Chaos, unklaren Zuständigkeiten und Projekten, die neben dem Tagesgeschäft stecken bleiben. Mit dem Tech-Gutachten analysiere ich deine bestehende Tech-Landschaft, mappe Prozesse und mache sichtbar, wo Run und Change heute vermischt sind. So bekommst du konkrete Empfehlungen, wie du dein IT-Betriebsmodell sauber aufstellst und technische Weiterentwicklung planbar machst.

Häufig gestellte Fragen

Was ist IT-Betriebsmodell (Run vs. Change)?
Ein IT-Betriebsmodell (Run vs. Change) trennt den stabilen IT-Betrieb (Run) von Projekten und Weiterentwicklung (Change). Dadurch werden Verfügbarkeit und Support gesichert, während Änderungen planbar umgesetzt werden.