IT-Betriebsmodell (Run vs. Change)

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.