Staff Augmentation vs. Managed Services für Wartungsarbeiten

Staff Augmentation vs. Managed Services ist eine Entscheidung, die die meisten Unternehmen erst durchdenken, wenn der Wartungs-Backlog sich aufzustauen beginnt und die bisherige Vereinbarung nicht mehr funktioniert. Eine SaaS-Kundin von mir hat die Wartung zwei Jahre lang über einen einzigen Contractor auf Retainer-Basis laufen lassen. Sie hat behoben, was kaputt war, Abhängigkeiten gepatcht, wenn etwas gemeldet wurde, und jeden Monat stundenweise abgerechnet. Das funktionierte bestens, bis zu dem Monat, in dem sie in den Urlaub ging, und niemand sonst im Team den Deploy-Prozess kannte, die Eigenheiten der Staging-Umgebung oder welcher der sechs Cron-Jobs tatsächlich gefahrlos beendet werden konnte. Genau das ist das Risiko, das in Staff Augmentation für Wartungsarbeit eingebaut ist, und es ist fast exakt das Problem, das ein Managed-Services-Vertrag beseitigen soll. Der eigentliche Unterschied liegt nicht hauptsächlich bei den Kosten, selbst wenn die Rechnungen unterschiedlich aussehen. Es geht darum, wer in der Haftung steht, wenn die eine Person, die das System versteht, nicht verfügbar ist, und wer entscheidet, was zuerst behoben wird, wenn in derselben Woche drei Dinge kaputtgehen.

Wartungsarbeit besteht in der Praxis aus einer Mischung kleiner Dinge: routinemäßige Abhängigkeits-Updates, gelegentliche Sicherheitspatches, Bugfixes, die auftauchen, sobald echte Nutzer auf Randfälle stoßen, und kleine Änderungen, die ein Stakeholder wünscht und die zu geringfügig für ein eigenes Projekt sind. Nichts davon ist glamourös, und nichts davon ist langfristig verzichtbar. Die Frage Staff Augmentation vs. Managed Services für diese Art Arbeit kommt meist erst auf, nachdem ein Unternehmen eine Zeit lang mit einem Modell gelebt und dessen Grenzen zu spüren begonnen hat.

Wie Staff Augmentation für Wartungsarbeit aussieht

Mit Staff Augmentation stellen Sie eine Person ein, oder einen Teil davon, und lassen sie innerhalb Ihres eigenen Prozesses arbeiten. Sie steigt in Ihre Ticket-Queue ein, folgt Ihrer Priorisierung und rechnet die geleisteten Stunden ab: drei Stunden für die Reparatur einer defekten Webhook-Integration, zwei Stunden Warten auf eine Entscheidung, welches von zwei offenen Tickets zuerst kommt, vier Stunden Nachforschen, warum ein Cron-Job letzten Dienstag stillschweigend aufgehört hat zu laufen. Sie besitzen den Backlog, und Sie besitzen die Schätzung. Wenn aus einem routinemäßigen Abhängigkeits-Update eine halbtägige Untersuchung wird, weil es etwas Unabhängiges kaputt gemacht hat, ist diese Extrazeit trotzdem Ihre, Stunde für Stunde bezahlt.

Dieses Modell passt zu einem Unternehmen, das bereits seinen eigenen Wartungsprozess betreibt: ein Ticketsystem, das jemand tatsächlich prüft, eine Person, die eingehende Bugs priorisiert, und Prioritäten, die intern entschieden werden statt jedes Mal mit einem externen Anbieter ausgehandelt zu werden. Der zusätzliche Entwickler fügt sich in diesen Prozess ein, ähnlich wie eine Staff-Augmentation-Einstellung sich in ein Feature-Team einfügt. Die Lücke, die gefüllt wird, ist Kapazität, nicht Richtung, und genau deshalb bricht das Modell zusammen, wenn der interne Prozess fehlt. Es gibt keine Queue zum Einreihen, also fließen die Stunden in das, was an diesem Tag am lautesten ist.

Wie Managed Services für Wartungsarbeit aussieht

Ein Managed-Services-Vertrag für Software-Wartung dreht die Vereinbarung um. Sie einigen sich auf einen Umfang, etwa die Anwendung gepatcht halten, Sicherheitsupdates innerhalb eines festgelegten Zeitfensters durchführen und Produktionsbugs innerhalb einer vereinbarten Reaktionszeit beheben, und der Anbieter betreibt seinen eigenen Prozess, um diesen Umfang für eine feste Monatsgebühr zu liefern. Wird aus einem Abhängigkeits-Update ein zweitägiger Kampf mit einem Breaking Change, den niemand vorhergesehen hat, ist das die Zeit des Anbieters, die er absorbieren muss, keine zusätzliche Position auf Ihrer Rechnung. Sie kaufen ein gewartetes System, kein Stundenkontingent, und der Anbieter muss selbst herausfinden, wie er das innerhalb der kalkulierten Gebühr liefert.

Das passt zu einem Unternehmen, das Wartung nicht intern betreiben will, das Abdeckung über mehr als einen einzelnen Kalender hinweg braucht, damit ein einziger Ausfall nicht zum Vorfall wird, oder das feste monatliche Kosten will, die sich budgetieren lassen, statt variable Kosten, die davon abhängen, wie chaotisch die Bugs in einem bestimmten Monat ausfallen.

Staff Augmentation vs. Managed Services, nach dem, was jede Seite besitzt

Die praktischen Unterschiede laufen auf drei Fragen hinaus, und die meisten Streitigkeiten zwischen Kunde und Anbieter lassen sich auf eine Unstimmigkeit bei einer dieser Fragen zurückführen: Wer priorisiert, wer schätzt, und wer trägt eine Überschreitung.

	Staff Augmentation	Managed Services
Wer priorisiert den Backlog	Sie	Der Anbieter, gegen vereinbarte Reaktionszeiten
Wer schätzt jeden Fix	Sie, mit Input des Entwicklers	Der Anbieter, als Teil des festen Umfangs
Wer trägt einen Fix, der länger dauert	Sie, stundenweise	Der Anbieter, innerhalb des Vertrags
Was Sie kaufen	Kapazität	Ein gewartetes Ergebnis
Wo es zusammenbricht	Niemand besitzt die Triage, Tickets stauen sich	Umfang zu eng für das, was tatsächlich kaputtgeht

Staff Augmentation für Wartung bricht genauso zusammen wie bei Feature-Arbeit. Wenn auf Ihrer Seite niemand die Triage besitzt, arbeitet der zusätzliche Entwickler entweder an dem, was in dieser Woche am lautesten ist, oder sitzt untätig und wartet auf Anweisungen, und Sie bezahlen den Tagessatz in beiden Fällen.

Managed Services bricht zusammen, wenn der Umfang zu eng geschrieben wurde. Ein Vertrag, der nur Sicherheitspatches abdeckt, deckt nicht die Datenbankmigration ab, die sich als notwendig herausstellt, um einen dieser Patches anzuwenden, und ein Anbieter, der den Umfang still erweitert, ohne das zu melden, bereitet damit einen späteren Streit über eine Nachtragsrechnung vor. Der Ausweg ist dieselbe Disziplin, die für jede Festpreis- oder Retainer-Vereinbarung gilt: schreiben Sie vor der Unterschrift fest, was als im Umfang enthalten zählt, nicht erst nach der ersten strittigen Rechnung.

Was tatsächlich auf der Rechnung steht

Staff Augmentation rechnet nach Zeit ab, also bildet die Rechnung ab, was tatsächlich in diesem Monat passiert ist. Ein ruhiger Monat ohne Vorfälle kostet wenig. Ein Monat mit drei Produktionsbränden und einem erzwungenen Framework-Upgrade kostet viel, und Sie erfahren erst, wie viel, nachdem die Arbeit bereits erledigt ist.

Managed Services rechnet eine Pauschale ab, unabhängig davon, wie der Monat verläuft, aufgebaut auf einer Schätzung der durchschnittlichen Last über ein Jahr. In manchen Monaten macht der Anbieter mehr Marge, als die Arbeit gerechtfertigt hätte. In anderen Monaten, wie dem Monat des erzwungenen Framework-Upgrades, nimmt er einen Verlust auf den Vertrag in Kauf. Anbieter kalkulieren diese Schwankung ein, weshalb ein Managed-Vertrag pro durchschnittlicher Stunde meist mehr kostet als die Rate, die Sie einem einzelnen zusätzlichen Entwickler direkt zahlen würden. Der Aufpreis kauft die Vorhersagbarkeit, und dafür, dass jemand anders die schlechten Monate trägt statt Sie.

Anzeichen, dass Sie das eine oder das andere brauchen

Ein paar Situationen machen die Wahl recht klar, sobald man genau hinsieht.

Wenn Sie schon einen Entwickler haben, der Bugs triagiert, Priorität entscheidet und nur mehr Hände braucht, um die Queue abzuarbeiten, ist Staff Augmentation für Wartung meist die günstigere und flexiblere Option. Sie behalten die Kontrolle über Prioritäten und zahlen keinen Aufpreis für Vorhersagbarkeit, die Sie nicht brauchen, weil Ihr eigener Prozess sie bereits schafft.

Wenn niemand intern das System tatsächlich besitzt, oder die Person, die es eigentlich besitzen sollte, ständig von neuer Feature-Arbeit abgezogen wird, sobald etwas kaputtgeht, beseitigt Managed Services diese Unterbrechung statt sie nur stundenweise weiterzugeben. Sie zahlen nicht mehr die Aufmerksamkeitskosten eines Entwicklers durch ständiges Kontextwechseln, sondern bezahlen einen Anbieter für ein Ergebnis, das Sie gegen eine schriftliche Reaktionszeit einfordern können.

Eine kleinere Zahl von Teams will am Ende beides gleichzeitig: einen Managed-Vertrag für die Basis-Instandhaltung, mit einem zusätzlichen Entwickler für einen definierten Zeitraum, wenn eine größere Legacy-System-Bereinigung mehr Hände braucht, als der Wartungsvertrag je abdecken sollte. Diese Kombination funktioniert, solange die beiden Umfänge separat schriftlich festgehalten werden, damit später niemand streitet, welcher Vertrag welches Ticket abdecken sollte.

Wenn Ihr Wartungsaufwand aus einem einzelnen Retainer herausgewachsen ist, oder Sie nicht sicher sind, welches Modell wirklich zu der Art passt, wie Ihr Team heute arbeitet, schreiben Sie an hello@wolf-tech.io, und wir schauen uns gemeinsam Ihr aktuelles Setup an. Mehr dazu, wie wir laufende Wartungsarbeit handhaben, finden Sie auf wolf-tech.io.