Betrieb nach Stundenaufwand einkaufen: eine Wette gegen Automatisierung

ISG hat im Juli einen Beitrag für Sourcing-Verantwortliche veröffentlicht, in dem ein Satz steht, den man zweimal lesen sollte: Ein Vertrag über den Applikationsbetrieb könne „vertraglich lebendig und kommerziell überholt“ sein. Die Argumentation: Verträge, die heute unterschrieben werden, laufen teilweise bis 2030. Bis dahin erledigen eingebettete Agenten Arbeit, die heute als menschlicher Aufwand abgerechnet wird, und ein Vertrag, der den Wert in Aufwand misst, misst dann das Falsche.

Für den praktischen Teil ist keine KI-Prognose erforderlich. Er gilt heute schon, und er hat mit Agenten nichts zu tun:

Wer Betrieb nach Stunden bezahlt, hat jemanden beauftragt, der nicht motiviert ist zu automatisieren, weil sein Umsatz mit jeder Automatisierung sinkt.

Das ist kein Vorwurf, sondern Arithmetik. Und es lohnt sich, sie zu verstehen, bevor du einen Vertrag über drei Jahre unterschreibst.

Der stärkste Einwand zuerst

Ein guter Anbieter automatisiert ohnehin. Reputation ist real, Kunden reden miteinander, und niemand überlebt im Schweizer IT-Dienstleistungsmarkt, der Stunden verrechnet, die ein Skript erledigen sollte. Alles richtig.

Nur behandelt dieser Einwand Automatisierung als Haltung. Sie ist eine Investition, und jemand muss sie vorschlagen.

Betriebsqualität entsteht fast immer aus Vorarbeit. Ein Alarm, der nicht mehr auslöst, ein Upgrade, das ohne Aufsicht durchläuft, ein Restore, der getestet ist statt erhofft: dahinter stehen Engineering-Stunden, die investiert werden müssen, lange bevor sie sich auszahlen. Im Stundenmodell bezahlst du diese Stunden, und das ist in Ordnung. Das Problem liegt eine Stufe früher. Vorschlagen muss die Arbeit der Anbieter, und jeder solche Vorschlag kürzt seinen eigenen künftigen Umsatz. Die Frage ist deshalb nicht, ob er automatisieren will, sondern warum er es je zur Sprache bringen sollte.

Zur Sprache bringen kann es ohnehin nur er. Du siehst deine Rechnung. Er sieht, welche wiederkehrende Handarbeit dahintersteckt und welcher Teil davon ein Skript sein könnte. Ein Vorschlag, der nie gemacht wurde, hinterlässt keine Spur: keine abgelehnte Offerte, keinen Protokolleintrag, nichts, was du im Quartalsmeeting aufgreifen könntest. Die Automatisierung, die dir fehlt, ist die, von der du nie erfahren hast.

Manche Anbieter bringen es trotzdem zur Sprache: um den nächsten Auftrag zu gewinnen, weil sich Engineers nicht beliebig einstellen lassen und frei gewordene Kapazität die einzige Art zu wachsen ist, oder schlicht, weil man gute Leute nicht hält, indem man sie jahrelang dieselbe Handarbeit wiederholen lässt. Alles real. Umsatzpositiv wird Automatisierung im Stundenmodell dadurch trotzdem nicht, bestenfalls umsatzneutral, denn die eingesparten Stunden müssen anderswo verkauft werden. Und diese Antriebe sind nicht deine. Sie stehen in keinem Vertrag, und du kannst nicht nachsehen, ob sie noch wirken.

Drei Arten, Betrieb zu bezahlen

Nach Aufwand

Du bezahlst Stunden, im Vertrag meist als Time and Material bezeichnet. Das belohnt Anwesenheit und ist ehrlich darin, was es ist: Du kaufst Zugang zu Menschen.

Das Modell passt, wenn sich die Arbeit vorab nicht spezifizieren lässt. Genau darum passt es zur Beratung und nicht zu einem laufenden Service.

Pro Ticket oder pro Incident

Du bezahlst die Anzahl der Ausfälle. Das ist noch schlechter, und es kommt häufiger vor, als es sollte, weil es nach Bezahlung von Resultaten aussieht. Belohnt wird der Anbieter, der viele Tickets effizient abarbeitet. Das ist nicht derselbe Anbieter wie der, dessen Systeme nur wenige Tickets erzeugen. ISG formuliert denselben Punkt aus Kundensicht: Der stärkste Anbieter ist womöglich nicht der, der Tickets am schnellsten löst, sondern der, bei dem Störungen gar nicht erst zu Tickets werden. Ein Vertrag pro Ticket kann die beiden nicht unterscheiden und bezahlt den ersten besser.

Fixpreis pro Instanz, pro Service oder pro Service Level

Du bezahlst ein laufendes Ergebnis, kalkuliert, bevor jemand weiss, wie viel Arbeit darin steckt. Damit wechselt die Automatisierung die Seite der Bilanz. Jede verhinderte Störung, jedes automatisierte Upgrade, jeder wegoptimierte Alarm senken die Erbringungskosten des Anbieters, und die Differenz behält er. Dein Preis bewegt sich nicht. Dein Service Level auch nicht. Was sich ändert, ist das Ziel des Anbieters: weniger Störungen statt mehr verrechenbarer Stunden. Diese Ausrichtung kaufst du ein, und sie ist mehr wert als der Rabatt, den du sonst verhandelt hättest.

Das ist unser Modell für den laufenden Betrieb. Application Operations wird pro Applikation und pro Service Level Indicator verrechnet, ab CHF 800 pro Monat. Ein schlechter Monat wird also nicht zur grösseren Rechnung. Deshalb können wir den Vergleich auch offen hinschreiben: dieselbe 24×7-Abdeckung intern aufzubauen heisst vier bis sechs Engineers zu je CHF 150’000 bis 200’000 pro Jahr, und wir liefern das Äquivalent für weniger als die Kosten einer halben Vollzeitstelle. Diese Zahl ist nur möglich, weil die Automatisierung bei uns auf der Margenseite statt auf der Umsatzseite liegt.

Sei skeptisch gegenüber jedem, der behauptet, sein Modell komme ganz ohne Stundenanteil aus, uns eingeschlossen. Bei uns verläuft die Grenze entlang der Schichten, und sie wird von der Zuständigkeit, nicht von der Technik, gezogen. Plattform und Infrastruktur, also der Kubernetes-Unterbau, die Managed Data Services sowie Server, Storage und Netzwerk darunter, sind im Fixpreis gepatcht, change-managed und gesichert. Ein Plattform-Patch, der etwas kaputt macht, ist unser Problem, also spielen wir ihn ein, ohne zu fragen. Dein Container-Image bleibt deins, weil nur deine Testsuite weiss, ob dein Produkt eine aktualisierte Extension überlebt. Applikationsspezifische Engineering-Arbeit, die du zusätzlich beauftragst, etwa CI/CD, Observability oder einen Business-Continuity-Test, wird separat offeriert, ebenso die Beratung.

Der übliche Einwand darauf lautet: dann sind unsere Abhängigkeiten unser Problem. Die brauchbare Antwort ist Renovate in deiner CI/CD. Updates kommen als Pull Requests an, deine Tests sind das Tor, dein Team merged. Automatisiert von deiner Seite, ohne die Entscheidung zu verschieben.

Entscheidend ist deshalb nicht, ob ein Anbieter je nach Anzahl der Stunden verrechnet, sondern ob er den laufenden Betrieb deines Service nach Stunden verrechnet. Der Anreiz wirkt auf der fixen Schicht, und dort entsteht der grösste Teil der Arbeit.

Wie sich das von aussen zeigt

Das Preismodell deines Anbieters siehst du nicht direkt. Du siehst seine Symptome. Monatliche Change Freezes. Ein Jira-Ticket für einen DNS-Eintrag. Vier Wochen Vorlaufzeit für eine Konfigurationsänderung, die zehn Minuten dauert. Das sind die Spuren eines Prozesses, den niemand einen Grund hatte zu automatisieren, und sie kommen in der Schweizer Unternehmens-IT häufig genug vor, dass „Change Freeze vermeiden“ als Suchbegriff eingetippt wird.

Bei diesen Symptomen geht es nicht nur um fehlende Automatisierung im Hintergrund, sondern darum, wer den Knopf drücken darf. Ein Anbieter kann den DNS-Eintrag intern längst automatisiert haben und dich trotzdem ein Ticket schreiben lassen. Interne Automatisierung spart ihm Kosten. Dir Selbstbedienung zu geben, streicht eine Position von der Rechnung. Im Stundenmodell gibt es dafür keinen Grund und pro Ticket erst recht nicht.

Vorsicht ist hier bei der Kausalität geboten: Blast Radius, Funktionstrennung und Auditpflichten sind echte Gründe, eine Produktionsänderung durch eine Kontrolle zu führen. Die Frage ist nicht, ob es eine Kontrolle gibt, sondern ob sie eine Leitplanke oder eine Warteschlange ist. Eine Leitplanke ist ein Pull Request mit Policy-Prüfung, Freigabe und Audit-Trail: dein Team führt die Änderung selbst aus, und die Kontrolle greift innerhalb weniger Minuten. Eine Warteschlange ist derselbe Anspruch ohne die Vorarbeit. Leitplanken kosten den Anbieter einmal Engineering-Zeit und danach nichts. Warteschlangen verrechnen sich pro Vorgang.

Dasselbe gilt für den Change Freeze selbst. Er entsteht auch aus echtem Risikomanagement, aus Audit-Fenstern und aus dünner Testabdeckung, und ein gut geführter Anbieter kann aus guten Gründen einen haben. Die lohnende Frage ist deshalb nicht, ob es den Freeze gibt, sondern ob er kleiner wird. Ein Anbieter, dessen Ökonomie Automatisierung belohnt, kann dir sagen, dass seine manuelle Oberfläche kleiner ist als vor drei Jahren, und ungefähr um wie viel. Ein Anbieter, der nach Stunden verrechnet, hat keinen solchen Trend zu berichten und misst ihn meist gar nicht.

„Fixpreis heisst doch nur, dass gespart wird“

Die ehrliche Fassung dieses Einwands lautet: ein Anbieter, der gleich viel erhält, ob er gut oder schlecht arbeitet, driftet Richtung schlecht.

Die Antwort ist das Service-Level-Agreement. Verfügbarkeitszusagen und Service Credits bepreisen den Nachteil in der Rechnung des Anbieters selbst, sodass zu wenig Investition als Rechnung auftaucht, die er sich selbst stellt. Das ist ein echter Mechanismus, und er ist der Grund, warum der Fixpreisbetrieb überhaupt funktioniert.

Genau darum ist ein Fixpreisprojekt etwas anderes. Ein Projekt endet. Danach gibt es nichts mehr in der Hand, keine Gutschrift einzufordern, und das Betriebsmodell danach ist dein Problem. Laufender Betrieb ist die einzige Konstellation, in der der Anbieter im dritten Jahr noch dasteht, wenn die Abkürzung aus dem ersten Jahr sichtbar wird.

Wo Beratung genau richtig ist

Nichts davon heisst „keine Berater beauftragen“. Wir verkaufen selbst Beratung, zu CHF 250 pro Stunde, und tun nicht so, als wäre es anders.

Stunden sind das richtige Instrument für eine abgegrenzte Veränderung: ein Architektur-Review, eine Migration, ein Plattform-Assessment, die Ausbildung deines Teams. Der Umfang ist offen, das Mandat endet, und Aufwand zu bezahlen ist die einzige ehrliche Art, etwas zu bepreisen, dessen Form man vorher nicht kennt.

Der Fehler ist eine Kategorienverwechslung, kein Lieferantenproblem. Er besteht darin, den laufenden Betrieb als offenen Stundenstrom einzukaufen und sich im zweiten Jahr zu wundern, warum derselbe Alarm immer wieder ausgelöst wird. Plane die Veränderung als Projekt. Kaufe den Betrieb als Service. Unser eigenes Partnernetzwerk funktioniert genau nach dieser Trennung: Beratungsunternehmen konzipieren und bauen die Plattform, wir betreiben sie, weil 24/7-Betrieb innerhalb eines Beratungsgeschäfts still und leise die Beratungsmarge auffrisst.

Die Exit-Frage, die fast niemand stellt

Hier steht der schärfste Gedanke des ISG-Beitrags. Jede Exit-Klausel, die du je gelesen hast, deckt die Daten ab. ISGs Fassung geht einen Schritt weiter: Kann der Kunde die Intelligenz behalten, die im Betriebsmodell steckt?

Nach drei Jahren Betrieb ist der wertvolle Gegenstand nicht der Datenbank-Dump. Es ist alles, was über den Betrieb deiner Workload gelernt wurde: die Runbooks, die auf deinen realen Traffic getrimmten Alarmschwellen, das Upgrade-Verfahren, das den Kontakt mit deinen Extensions überlebt hat, der Restore-Test, die Infrastrukturdefinitionen. Liegt das alles im proprietären Werkzeugkasten eines Anbieters, dann berechtigt dich dein Exit-Recht zu deinen Daten und zu einem Neuanfang bei null. Du baust drei Jahre Betriebswissen neu auf und entdeckst es auf demselben Weg wie beim ersten Mal, nämlich durch eine Störung nach der anderen.

Stelle die Frage also direkt: ist die Automatisierung, die meinen Service betreibt, Open Source, und bekomme ich sie?

Bei uns ist die Antwort in guter Form, weil das Werkzeug öffentlich zugänglich ist. Project Syn und Commodore, die die Cluster konfigurieren und betreiben, AppCat, das die Managed Services selbst definiert, und K8up, das die Backups fährt, liegen offen auf GitHub, unter BSD-3-Clause und Apache-2.0. Dein Team oder ein neuer Anbieter kann nachlesen, wie dein Service betrieben wird, und dieselben Werkzeuge einsetzen, ohne uns zu fragen. Was deinen Service betreibt, ist keine Blackbox zur Miete, sondern ein GitOps-Repository, das dir gehört. Was am Vertragsende genau übergeben wird, gehört in den Vertrag und nicht in einen Blogbeitrag. Aber ein Anbieter mit proprietärer Automatisierung kann darauf keine gute Antwort geben, wie auch immer die Klausel formuliert ist.

Wo weiterhin ein Mensch entscheidet

ISGs zweite nützliche Korrektur: „Human in the Loop“ ist zu unbestimmt, um eine konkrete Bedeutung zu haben. Die bessere Frage ist, welche Entscheidungen einen benannten Menschen erfordern. Diese Frage gehört schriftlich beantwortet, bevor sich das Betriebsmodell ändert, und nicht erst, wenn die Verantwortung strittig wird.

Naheliegende Kandidaten: die Freigabe eines Releases in Produktion, die Gewährung einer Sicherheitsausnahme, die Annahme von Produktionsrisiko und die Ausrufung eines Major Incidents. Lass dir von deinem Anbieter seine nennen. Sei skeptisch gegenüber einer Floskel als Antwort und noch skeptischer gegenüber einem Anbieter, der seinen Betrieb als autonom bezeichnet. Unserer ist es nicht. Er ist automatisiert, was eine andere und besser prüfbare Aussage ist, und für eine regulierte Organisation ist es die, die ein Audit übersteht.

Was du vor der Unterschrift fragen solltest

1. Bewegt sich mein Preis mit den Stunden, die ihr aufwendet, oder mit dem Service, den ich erhalte?
2. Wenn ihr euren Aufwand auf meinem Konto nächstes Jahr halbiert, wer behält die Differenz?
3. Was messt ihr ausser der Verfügbarkeit und der Wiederherstellungszeit? Irgendetwas zur Vermeidung?
4. Bekomme ich beim Weggang meine Daten, oder meine Daten und die Automatisierung, die sie betrieben hat?
5. Ist diese Automatisierung Open Source oder eure?
6. Welche Entscheidungen verlangen bei euch immer einen benannten Menschen, und welche bei mir?
7. Welche Teile davon sind ein abgegrenztes Projekt und welche sind laufender Betrieb? Werden sie unterschiedlich bepreist?
8. Wie viel von dem, was ihr heute für mich tut, war vor drei Jahren manuell? Was hat sich geändert, und könnt ihr mir den Verlauf zeigen?
9. Was kann mein Team ohne euch ändern, und ist diese Liste in den letzten zwei Jahren länger oder kürzer geworden?

ISG hat recht damit, dass das grösste Risiko nicht in Applikationen liegt, die sich selbst verwalten. Es liegt in einem langfristigen Vertrag, der sich nicht anpassen lässt, wenn sie es tun. Die kurzfristigere Fassung kommt ganz ohne Prognose aus: unterschreibe keinen Betriebsvertrag, der deinen Anbieter dafür bezahlt, nicht zu automatisieren.

VSHN betreibt seit 2014 Open-Source-Infrastruktur für regulierte Schweizer Organisationen. Wir sind der erste CNCF Kubernetes Certified Service Provider der Schweiz, Red Hat Premier Certified Cloud and Service Provider sowie ISO-27001-zertifiziert. Der laufende Betrieb wird pro Applikation und pro Service Level verrechnet, nicht nach Stunden. Kostenschätzung für den Betrieb deiner Applikation anfordern.

Quellen:

• ADM 2030: When Applications Manage Themselves. Dr. Daniel Gerster, ISG, 28. Juli 2026
• VSHN Service Levels und Support Plans. VSHN Produktdokumentation
• Project Syn und AppCat, BSD-3-Clause, und K8up, Apache-2.0. Lizenzen am 4. September 2026 auf GitHub geprüft