IT-Betriebsmodell (Run vs. Change)
DefinitionTrennt Betrieb (Run) von Weiterentwicklung/Projekten (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.
- 30%
weniger Betriebsstörungen
KMU mit klar getrennten Run- und Change-Verantwortlichkeiten reduzieren ungeplante Störungen, weil Betrieb und Weiterentwicklung sauber priorisiert werden.
- 20%
schnellere Releases
Ein definiertes IT-Betriebsmodell beschleunigt Change-Vorhaben, da Projekte nicht permanent durch operative Tagesaufgaben ausgebremst werden.
- 15%
geringere IT-Kosten
Unternehmen mit strukturierter Trennung von Run und Change senken häufig ihre IT-Gesamtkosten, weil Ressourcen, Budgets und externe Leistungen transparenter gesteuert werden.
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.
Onlineshop-Betrieb absichern und neue Funktionen getrennt entwickeln
Ein KMU im Großhandel organisiert den stabilen Betrieb seines Shopsystems mit Fokus auf Performance, Bestellabwicklung und Fehlerbehebung im Run-Modell. Parallel arbeitet ein Change-Team an neuen Funktionen wie B2B-Kundenportalen, Preislogiken oder Anbindungen an Marktplätze. Dadurch bleibt das Verkaufssystem im Tagesgeschäft zuverlässig, ohne dass Innovationsprojekte den laufenden Umsatz gefährden.
Helpdesk entlasten und CRM-Einführung sauber vom Support trennen
Ein wachsendes Dienstleistungsunternehmen trennt den laufenden IT-Support für Mitarbeiter, E-Mail und Standardanwendungen von der Einführung eines neuen CRM-Systems. Das Run-Team kümmert sich um Tickets und Benutzeranfragen, während das Change-Team Prozesse mit Vertrieb und Kundenservice aufnimmt, Schulungen vorbereitet und die Einführung begleitet. So entstehen klare Verantwortlichkeiten, weniger Prioritätskonflikte und eine planbare Umsetzung des Projekts.
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.
Wie funktioniert das Run-vs.-Change-Prinzip in der Zusammenarbeit mit Dienstleistern?
Run wird meist über klare Service-Prozesse, SLAs und ein Ticket-System gesteuert, Change über Roadmaps, Projektpläne und definierte Releases. Wichtig ist ein transparenter Kapazitätsanteil, damit Change nicht ständig von Supportfällen verdrängt wird.
Warum ist die Trennung von Run und Change für Unternehmen ohne IT-Abteilung wichtig?
Ohne Trennung dominiert oft das Tagesgeschäft, sodass strategische Verbesserungen liegen bleiben – oder Projekte gefährden die Stabilität. Run vs. Change schafft klare Verantwortlichkeiten, priorisierte Arbeit und bessere Budget- und Risikosteuerung.
Woran erkenne ich, dass mein Unternehmen ein Run-vs.-Change-Betriebsmodell braucht?
Typische Signale sind: Projekte verzögern sich wegen „Feuerwehr-Support“, häufige Ausfälle nach Änderungen oder unklare Kosten zwischen Betrieb und Projekten. Auch fehlende Dokumentation und wiederkehrende Störungen sprechen für eine klare Trennung.
Was kostet ein IT-Betriebsmodell nach Run vs. Change?
Run-Kosten sind meist monatliche Managed-Services-Pauschalen und hängen von Nutzerzahl, Systemen und SLA ab. Change wird häufig als Projekt oder Retainer abgerechnet; Kostenfaktoren sind Umfang, Integrationen, Sicherheitsanforderungen und Test-/Rollout-Aufwand.
Welche Vorteile hat ein IT-Betriebsmodell mit klarer Trennung von Run und Change?
Ein sauberes Run-vs.-Change-Modell sorgt dafür, dass der laufende IT-Betrieb stabil bleibt, während neue Anforderungen, Projekte und Verbesserungen planbar umgesetzt werden. Unternehmen gewinnen dadurch mehr Transparenz bei Verantwortlichkeiten, Prioritäten, Budgets und Reaktionszeiten – und vermeiden, dass dringende Tagesaufgaben jede Weiterentwicklung blockieren.
Wie führt man ein Run-vs.-Change-Betriebsmodell praktisch ein?
In der Praxis startet die Einführung meist mit einer Bestandsaufnahme: Welche Aufgaben gehören in den Betrieb, welche in Projekte oder Weiterentwicklung? Danach werden Zuständigkeiten, Priorisierungsregeln, Budgets und Übergaben zwischen Run und Change definiert, damit Änderungen sauber geplant und der Betrieb nicht gefährdet wird.
Muss mein Unternehmen dafür eine eigene IT-Abteilung haben?
Nein, ein IT-Betriebsmodell nach Run vs. Change funktioniert auch ohne interne IT-Leitung. Gerade für Unternehmen mit 5 bis 30 Mitarbeitern ist es oft sinnvoll, diese Struktur mit externer Unterstützung aufzubauen – zum Beispiel über eine Tech-Partnerschaft, in der ich als externer CTO Prioritäten, Zuständigkeiten und technische Entscheidungen mit dir sauber aufsetze.
Ist die Einführung eines Run-vs.-Change-Modells nicht zu aufwendig für kleinere Unternehmen?
Nicht, wenn man pragmatisch vorgeht. Statt Konzernprozesse zu kopieren, schauen wir auf deine reale Tool-Landschaft, Abläufe und Engpässe und bauen ein schlankes Modell, das zu deinem Unternehmen passt – oft als Teil eines Tech-Gutachtens oder direkt in der laufenden Tech-Partnerschaft.
Wie finde ich heraus, welche Aufgaben bei uns zu Run und welche zu Change gehören?
Genau diese Abgrenzung ist in vielen Unternehmen unscharf – und führt dann zu Chaos, Verzögerungen oder Dauerfeuer bei Ad-hoc-Themen. Im Tech-Gutachten analysiere ich deine Systeme, Prozesse und Nutzung, sodass klar wird, was operativer Betrieb ist, was Weiterentwicklung sein sollte und wo Prioritäten neu gesetzt werden müssen.
Kann ein neues System wie OrbitOS helfen, Run und Change besser zu trennen?
Ja, weil ein konsolidiertes System die technische Komplexität reduziert und Übergaben sauberer macht. Mit der Umsetzung auf OrbitOS schaffe ich eine strukturierte Arbeitsumgebung für CRM, Projekte, Content, KI und Dashboards, sodass der laufende Betrieb stabiler wird und Änderungen nicht mehr an fünf verschiedenen Tools gleichzeitig hängen.
Lässt sich KI sinnvoll in ein Run-vs.-Change-Betriebsmodell integrieren?
Ja – vor allem dort, wo wiederkehrende Run-Aufgaben automatisiert oder Change-Themen schneller bewertet werden können. In meiner KI-Beratung prüfen wir mit dem PUR-Framework, welche Prozesse wirklich KI-tauglich sind, bauen bei Bedarf passende Lösungen wie Custom GPTs oder RAG-Systeme und achten darauf, dass neue Automationen den Betrieb entlasten statt zusätzliche Komplexität zu schaffen.