Ein Risiko, das niemand dokumentiert
Jede Dienstleisterbeziehung birgt ein Risiko, das alle im Grundsatz anerkennen und das nirgends aufgeschrieben ist. Gefragt, ob Ihre Plattform einen ungeplanten Dienstleisterwechsel überstehen würde, würden Sie vermutlich ja sagen, weil der Code Ihnen gehört und der Vertrag das so festhält. Gefragt, wo die Repositories liegen, wer das Cloud-Konto bezahlt und wer den Admin-Zugang zum Suchdienst hat, kämen Sie ins Stocken.
Es bleibt undokumentiert, weil die Frage wie ein Vorwurf wirkt. Wer bei einem Dienstleister, der gut liefert, das Thema Kontinuität anspricht, klingt, als rechne er damit, dass es ihn nächstes Jahr nicht mehr gibt. Also warten die Fragen auf einen Anlass. Wenn der kommt, sind die Menschen, die antworten könnten, abgelenkt oder weg.
Behandeln Sie es als Versicherung, nicht als Misstrauen. Sie versichern das Büro, ohne zu erwarten, dass es abbrennt. Jeder Dienstleister ist stabil, bis er es nicht mehr ist.
Was Sie tatsächlich verlieren können
Die instinktive Angst gilt dem Quellcode. In der Praxis ist er der am leichtesten wiederherstellbare Teil. Er liegt in einem Repository, lässt sich an einem Nachmittag exportieren, und der Vertrag sagt meist, dass er Ihnen gehört. Alles darum herum ist schwieriger.
Entscheidungen. In einem langen Projekt fallen Hunderte von Entscheidungen: warum das Produktmodell diese Form hat, warum eine Integration Daten regelmäßig abholt und eine andere auf Ereignisse wartet, warum ein Feld, das überflüssig wirkt, noch da ist. Jede wurde in einem Ticket oder einem Telefonat geklärt, und die Aufzeichnung liegt in den Systemen des Dienstleisters.
Umgebungen. Staging, Preview und Produktion unterscheiden sich in Kleinigkeiten, die niemand aufgeschrieben hat. Secrets, Feature-Flags, geplante Jobs und der eine manuelle Schritt im Deployment stecken in den Köpfen der Entwickler, die sie eingerichtet haben.
Zugänge. Konten sammeln sich an: Hosting, DNS, CMS, Suche, E-Mail-Versand, Monitoring, Zahlungsabwicklung, Analytics. Manche laufen auf Ihren Namen, manche auf den des Dienstleisters, manche unter dem persönlichen Login eines Entwicklers. Niemand hat die vollständige Liste.
Historie. Das Ticket-Backlog ist die einzige Aufzeichnung dessen, was angefragt wurde, was abgelehnt wurde und warum. In einer regulierten Branche ist es außerdem Teil Ihrer Nachweise.
Code ist in Tagen wiederhergestellt. Kontext, sofern er sich überhaupt wiederherstellen lässt, braucht viel länger.
Wo das Eigentum liegt, und wie Sie das diese Woche prüfen
Das meiste lässt sich in einer Woche klären, ohne schwieriges Gespräch, indem Sie es als Routineaufgabe behandeln. Schicken Sie dem Dienstleister eine kurze schriftliche Anfrage mit fünf Punkten:
- Jedes Repository mit Code oder Konfiguration für Ihre Plattform, mit der Organisation, der es gehört.
- Jeder gehostete Dienst und jedes Cloud-Konto, von dem die Plattform abhängt, mit Kontoinhaber und Rechnungsempfänger.
- Jede Person auf beiden Seiten mit administrativem Zugriff auf eines der genannten Systeme.
- Eine schriftliche Bestätigung, wo die Rechte am gelieferten Werk liegen, mit Verweis auf die Klausel, die das regelt.
- Wo die Projekthistorie liegt (Tickets, Entscheidungen, Dokumentation) und ob Sie sie exportieren können.
Nennen Sie es ein Zugangsinventar, das Sie künftig pflegen wollen. Ein guter Dienstleister antwortet an einem Nachmittag, weil er die Liste schon hat. Eine langsame oder unvollständige Antwort ist selbst eine Information, und Sie wollen sie, bevor es einen Grund zur Sorge gibt.
Das Muster, das Sie anstreben sollten: Repositories und Konten gehören dem Kunden, der Dienstleister erhält Zugriff, nicht umgekehrt. Wenn Ihr Team einwendet, dass niemand im Haus diese Konten betreiben kann, trennen Sie Eigentum von Betrieb. Sie können das Konto besitzen, es bezahlen und dem Dienstleister volle Rechte einräumen, es zu betreiben. Was sich ändert, ist, wer den Zugriff entziehen kann, nicht, wer die Arbeit macht.
Die Historie umziehen
Wenn die Antwort auf den fünften Punkt lautet „sie liegt in unseren Systemen“, ziehen Sie sie um. Ticket-Historie, Entscheidungsprotokolle und Dokumentation gehören in ein System, das Sie kontrollieren, und der Dienstleister arbeitet darin. Die meisten Projekt-Tools erlauben eine Gastorganisation; der praktische Unterschied ist, auf wessen Abonnement sie läuft und wer sie exportieren kann.
Das ist wichtiger, als die meisten erwarten. In den Tickets liegen die Gründe. Wenn ein künftiger Entwickler fragt, warum der Auftragsexport einen Status überspringt, steht die Antwort in einem Ticket aus dem ersten Projektjahr, und ob er es findet, macht den Unterschied zwischen einer schnellen Korrektur und einer Woche Archäologie. In regulierten Branchen ist die Historie außerdem ein Nachweis: was spezifiziert wurde, was getestet wurde, wer die Änderung freigegeben hat. Ein Auditor wird danach fragen, und „das hatte der vorherige Dienstleister“ ist eine Antwort, die niemand gern gibt.
Machen Sie den Umzug, solange die Beziehung ruhig ist. Unter Druck geht es auch, aber langsamer, und es gehen Dinge verloren, die Ihnen erst später auffallen.
Die Arbeit über einen Wechsel hinweg am Laufen halten
Wenn ein Dienstleisterwechsel kommt, ist die entscheidende Frage, ob die Arbeit weiterläuft oder stehen bleibt, während alle neu verhandeln. Sie läuft weiter, wenn drei Dinge bereits gegeben sind: Code und Konten laufen auf Ihren Namen, die Historie liegt in Ihrem System, und die Menschen, die die Arbeit machen, sind bekannt und bereit, weiterzumachen.
Wir haben aus erster Hand gesehen, mit welchen Vereinbarungen sich ein Wechsel überstehen lässt und mit welchen er schmerzhaft wird. Mehrere Kundenprogramme liefen über einen Dienstleisterwechsel hinweg ohne Unterbrechung weiter: Die Projekthistorie wurde in eine neue Instanz migriert, sodass die Aufzeichnung der Entscheidungen den Wechsel überstand, und jeder Vertrag wurde direkt mit dem Kunden neu geschlossen, jeweils mit eigener Rechtswahl. Ob ein Wechsel zu überstehen ist, hängt nicht vom guten Willen ab. Es hängt davon ab, ob die drei genannten Bedingungen bereits bestehen oder sich schnell herstellen lassen. Wo weder das eine noch das andere zutrifft, braucht jeder Schritt des Umzugs die Freigabe von jemand anderem, und die Menschen, die sie erteilen können, stehen auf der Liste, die niemand geführt hat.
Geben Sie Ihrem Einkauf dieses Argument mit, bevor Sie es brauchen. Ein direkter Vertrag mit dem Team, das die Arbeit ohnehin macht, hält die Arbeit am Laufen. Eine Ausschreibung unterbricht sie meist und übergibt die Plattform an ein Team, das sich den Kontext erst wieder erarbeiten muss. Halten Sie sich den direkten Weg offen, indem Sie wissen, wer die Arbeit tatsächlich macht, und nicht nur, welche Firma den Vertrag hält.
Klauseln für Ihren nächsten Vertrag
Die meisten Verträge regeln Lieferumfang, Vergütung und geistiges Eigentum und sagen nichts zur Kontinuität des Betriebs. Sechs Klauseln schließen diese Lücke. Ihre Rechtsabteilung wird eigene Formulierungen haben; entscheidend ist, dass jede davon vorkommt.
- Eigentum an Repositories und Konten. Code, Konfiguration und Cloud-Konten liegen in Organisationen, die Ihnen gehören. Der Dienstleister erhält Zugriff, den Sie entziehen können.
- Hinterlegung oder Gleichwertiges. Wo das Eigentum nicht bei Ihnen liegen kann, eine ausdrückliche Regelung zur Quellcode-Hinterlegung (Escrow) mit definierten Auslösern für die Herausgabe.
- Übergabepflicht. Auf schriftliche Anfrage übergibt der Dienstleister Code, Zugangsdaten, Dokumentation und Historie innerhalb einer festgelegten Zahl von Arbeitstagen, unabhängig davon, ob der Vertrag endet.
- Übergangszeitraum. Ein festgelegter Zeitraum nach der Kündigung, in dem der Dienstleister weiterarbeitet und eine Übergabe unterstützt, zum vertraglich vereinbarten Satz.
- Benannte Schlüsselpersonen. Die Personen, die den Kontext haben, werden namentlich genannt, mit der Pflicht, Sie vor ihrem Ausscheiden aus dem Projekt zu informieren und ihr Wissen dabei zu übergeben.
- Zugangsinventar als Lieferergebnis. Eine aktuelle Liste der Konten, Dienste, Personen und Rechnungsempfänger, geliefert in einem vereinbarten Rhythmus und auf Anfrage.
Nichts davon ist feindselig. Ein Dienstleister, der bleiben will, unterschreibt das ohne lange Diskussion, weil jede Klausel beschreibt, wie er ohnehin arbeitet. Die Checkliste zu diesem Beitrag lässt sich direkt in eine Anforderungsliste übernehmen.
