Das Projekt ist abgeschlossen, die neue Schnittstelle funktioniert und die letzten Aufgaben sind erledigt. Trotzdem kann technisch noch vieles aktiv sein: Benutzerkonten eines externen Dienstleisters, API-Schlüssel, Webhooks, Testzugänge, Automationen oder gemeinsam genutzte Dateien. Projektabschluss und technisches Offboarding sind deshalb nicht dasselbe. Ein sauberer Prozess klärt, was weiter benötigt, intern übernommen, geändert oder abgeschaltet werden muss.
1. Warum endet ein Projekt technisch nicht mit der letzten Aufgabe?
Während eines Projekts entstehen häufig technische Verbindungen, die für die Umsetzung notwendig sind.
Beispielsweise erhält ein externer Dienstleister Zugriff auf ein System. Für eine Schnittstelle wird ein API-Schlüssel erstellt. Ein Testbenutzer wird angelegt. Ein Workflow verbindet Formular, CRM und E-Mail. Ein Webhook überträgt neue Datensätze an ein anderes System.
Nach erfolgreicher Umsetzung geraten solche Details leicht aus dem Blick.
Das Projekt gilt organisatorisch als abgeschlossen, während technisch weiterhin:
- Benutzerkonten bestehen,
- API-Schlüssel gültig sind,
- Automationen ausgeführt werden,
- Webhooks Daten übertragen,
- Testzugänge Zugriff ermöglichen,
- externe Dienste mit Unternehmenssystemen verbunden sind.
Ein technisches Offboarding soll deshalb nicht nur „alte Zugänge löschen“.
Es soll beantworten:
Welche technischen Bestandteile gehören inzwischen zum laufenden Betrieb – und welche wurden nur für das Projekt benötigt?
2. Was sollte beim Offboarding erfasst werden?
Der erste Schritt ist eine Bestandsaufnahme.
Je nach Projekt können unterschiedliche technische Elemente betroffen sein.
| Element | Was sollte geklärt werden? |
|---|---|
| Benutzerkonten | Wer besitzt Zugriff und wird dieser nach Projektende noch benötigt? |
| Rollen und Berechtigungen | Sind vorhandene Rechte für den späteren Betrieb noch erforderlich? |
| API-Schlüssel und Tokens | Wem gehören die Zugangsdaten, wo werden sie verwendet und müssen sie ersetzt werden? |
| Webhooks | Welche Systeme senden oder empfangen weiterhin Daten? |
| Automationen | Welche Workflows gehören zum produktiven Prozess und wer betreut sie? |
| Testkonten | Werden sie noch benötigt oder können sie entfernt beziehungsweise deaktiviert werden? |
| Externe Dienste | Welche Tools, Apps oder Plattformen bleiben mit Unternehmenssystemen verbunden? |
| Dateien und Dokumentation | Wo liegen Konfiguration, Prozessbeschreibung und relevante technische Informationen? |
Die Liste sollte sich am tatsächlichen Projekt orientieren.
Nicht jedes Projekt verwendet APIs oder Automationsplattformen. Umgekehrt können bei komplexeren Integrationen weitere technische Abhängigkeiten bestehen.
3. Welche Benutzerzugänge können entfernt werden?
Ein externer Projektmitarbeiter benötigt während der Umsetzung möglicherweise Zugriff auf CRM, Website, Hosting, Projektmanagement oder andere Systeme.
Nach Projektende sollte für jeden Zugang geprüft werden:
- Wird die Person weiterhin für Support oder Betreuung benötigt?
- Welche Systeme kann das Konto erreichen?
- Welche Rolle beziehungsweise Berechtigung besitzt es?
- Ist der Zugriff persönlich oder wird ein gemeinsames Konto verwendet?
- Gibt es laufende Prozesse, die technisch an dieses Konto gebunden sind?
Der letzte Punkt ist besonders wichtig.
Ein Konto sollte nicht einfach deaktiviert werden, wenn beispielsweise ein produktiver Workflow, eine Integration oder ein technischer Eigentümer daran gekoppelt ist.
In diesem Fall muss zuerst geklärt werden, wie diese Abhängigkeit auf einen geeigneten betrieblichen Zugang übertragen wird.
Das Ziel ist daher nicht:
Projekt beendet → alle Konten löschen.
Sondern:
Projekt beendet → Zugänge prüfen → Abhängigkeiten übertragen → nicht mehr benötigte Rechte entfernen.
4. Was passiert mit API-Schlüsseln und technischen Zugangsdaten?
API-Schlüssel, Tokens und andere technische Zugangsdaten werden häufig während eines Projekts eingerichtet, damit Systeme miteinander kommunizieren können.
Beim Offboarding muss deshalb zuerst festgestellt werden, wofür ein Schlüssel verwendet wird.
Eine einfache Zuordnung kann beispielsweise enthalten:
- betroffenes System,
- Zweck des Zugangs,
- zugehöriger Workflow oder Prozess,
- technischer Verantwortlicher,
- Ablage beziehungsweise sichere Verwaltung,
- betroffene Berechtigungen,
- Entscheidung nach Projektende.
Danach können unterschiedliche Maßnahmen sinnvoll sein.
Schlüssel bleibt bestehen
Wenn der Zugang ausschließlich für einen weiterhin benötigten produktiven Prozess verwendet wird und bereits sauber unter Verantwortung des Unternehmens verwaltet wird, muss er nicht allein wegen des Projektendes ersetzt werden.
Schlüssel wird ersetzt
Wenn ausscheidende Personen einen Schlüssel weiterhin kennen oder nutzen könnten, muss auch dieser Zugang in der Übergabe berücksichtigt werden. Planen Sie seine Ablösung und stellen Sie die benötigten Verbindungen kontrolliert auf den neuen Schlüssel um. Ein persönliches Konto zu deaktivieren reicht nicht aus, wenn daneben weiterhin nutzbare Zugangsdaten bestehen.
Schlüssel wird widerrufen
Wird eine Integration vollständig beendet und besteht keine weitere technische Abhängigkeit, kann der nicht mehr benötigte Zugang widerrufen werden.
Wichtig ist die Reihenfolge: Erst Abhängigkeiten feststellen, dann ändern oder widerrufen.
5. Welche Automationen müssen weiterlaufen?
Eine Automation, die während eines Projekts entwickelt wurde, kann nach Projektabschluss Bestandteil des normalen Geschäftsprozesses sein.
Beispiele:
- Website-Anfrage wird ins CRM übertragen.
- Ein bestätigter Auftrag legt einen Projektvorgang an.
- Dokumente werden einem Kunden oder Projekt zugeordnet.
- Bestimmte Daten werden zwischen zwei Systemen synchronisiert.
- Bei einem definierten Ereignis wird eine interne Aufgabe erstellt.
Solche Workflows dürfen beim Offboarding nicht versehentlich wie temporäre Projektbestandteile behandelt werden.
Für jeden produktiven Workflow sollte geklärt sein:
- Was löst ihn aus?
- Welche Systeme sind beteiligt?
- Welche Zugangsdaten werden verwendet?
- Unter welchem Konto läuft der Prozess?
- Wer erkennt einen Fehler?
- Wer darf Änderungen vornehmen?
- Was passiert, wenn ein beteiligtes System nicht erreichbar ist?
Wie Unternehmen mit ausgefallenen Workflows und betroffenen Vorgängen umgehen können, zeigen wir im Beitrag Automatisierung läuft nicht mehr: Fehler erkennen und Vorgänge nachholen.
6. Wer übernimmt die Verantwortung nach Projektende?
Während der Umsetzung ist häufig klar, wer zuständig ist: Projektleiter, Entwickler, Agentur oder externer Dienstleister.
Nach der Übergabe kann diese Klarheit verschwinden.
Deshalb sollte für produktive technische Bestandteile mindestens ein verantwortlicher Bereich oder Ansprechpartner festgelegt werden.
Je nach Unternehmen können unterschiedliche Verantwortlichkeiten sinnvoll sein:
| Aufgabe | Zu klärende Verantwortung |
|---|---|
| Fachlicher Prozess | Wer entscheidet, wie der Geschäftsprozess funktionieren soll? |
| Technischer Betrieb | Wer prüft und betreut die technische Verbindung? |
| Zugänge | Wer darf Benutzer und Berechtigungen ändern? |
| Fehler | Wer wird informiert, wenn ein Workflow nicht funktioniert? |
| Änderungen | Wer darf einen produktiven Workflow anpassen oder freigeben? |
Diese Rollen müssen nicht zwingend von unterschiedlichen Personen übernommen werden.
Entscheidend ist, dass die Verantwortung nach der Projektübergabe nicht nur implizit beim ehemaligen Projektteam verbleibt.
7. Welche Dokumentation sollte übergeben werden?
Eine technische Übergabe muss nicht aus einer umfangreichen Dokumentensammlung bestehen, die später niemand verwendet.
Sie sollte jedoch genügend Informationen enthalten, damit ein verantwortlicher Mitarbeiter nachvollziehen kann, was produktiv läuft.
Je nach Prozess gehören dazu beispielsweise:
- Zweck der Automation oder Integration,
- beteiligte Systeme,
- Auslöser und wesentliche Prozessschritte,
- verwendete technische Konten,
- Speicherort beziehungsweise Verwaltung von Zugangsdaten,
- wichtige Feldzuordnungen oder Regeln,
- bekannte Ausnahmefälle,
- Fehler- und Benachrichtigungsweg,
- zuständige Person oder Rolle,
- Vorgehen bei Änderungen.
Zugangsdaten selbst sollten dabei nicht ungeschützt in einer allgemeinen Projektdokumentation stehen.
Die Dokumentation kann stattdessen festhalten, wo und unter wessen Verantwortung die benötigten Zugangsdaten sicher verwaltet werden.
8. Wie wird sicher abgeschaltet?
Nicht mehr benötigte technische Bestandteile sollten kontrolliert entfernt werden.
Eine sinnvolle Reihenfolge kann so aussehen:
- Abhängigkeit prüfen: Welche Prozesse oder Systeme verwenden den Zugang noch?
- Verantwortlichen bestätigen: Wer entscheidet über die Abschaltung?
- Ersatz herstellen: Falls erforderlich, produktive Prozesse zuerst auf einen neuen Zugang oder eine neue Verbindung umstellen.
- Funktion prüfen: Sicherstellen, dass der weiter benötigte Prozess nach der Umstellung funktioniert.
- Alten Zugang deaktivieren: Nicht mehr benötigte Konten, Schlüssel oder Verbindungen entfernen beziehungsweise widerrufen.
- Ergebnis dokumentieren: Festhalten, was beendet, ersetzt oder weitergeführt wurde.
Bei kritischen Prozessen kann zusätzlich sinnvoll sein, nach der Änderung gezielt zu prüfen, ob erwartete Vorgänge weiterhin verarbeitet werden.
Das verhindert einen typischen Fehler: Ein alter Zugang wird korrekt entfernt, aber erst später fällt auf, dass ein produktiver Workflow genau diesen Zugang noch verwendet hat.
9. Praxisbeispiel: Externer Dienstleister verlässt das Projekt
Ein fiktives B2B-Unternehmen hat gemeinsam mit einem externen Dienstleister einen Prozess zwischen Website, CRM und Projektmanagement automatisiert.
Nach erfolgreicher Einführung endet das Projekt.
Während der Umsetzung wurden angelegt:
- ein Benutzerkonto für den externen Dienstleister,
- ein API-Zugang zum CRM,
- eine Automation für neue Kundenanfragen,
- ein Testkonto im Projektmanagement,
- mehrere Webhooks zwischen den Systemen.
Variante ohne geregeltes Offboarding
Die Abschlussrechnung wird bezahlt und das Projekt geschlossen.
Das externe Benutzerkonto bleibt bestehen. Niemand weiß genau, wem der API-Schlüssel gehört. Die Automation läuft weiter, wird aber technisch weiterhin dem ehemaligen Projektverantwortlichen zugeordnet. Das Testkonto bleibt aktiv.
Solange alles funktioniert, fällt dies möglicherweise nicht auf.
Variante mit technischem Offboarding
Vor Projektabschluss wird jedes Element geprüft.
- Der produktive Workflow wird einem internen Verantwortlichen zugeordnet.
- Es wird dokumentiert, welche Systeme und Zugangsdaten der Workflow benötigt.
- Der externe persönliche Benutzerzugang wird nach der Übergabe entfernt.
- Der API-Zugang wird entsprechend der festgelegten betrieblichen Verantwortung geprüft und gegebenenfalls erneuert.
- Das nicht mehr benötigte Testkonto wird deaktiviert.
- Die produktiven Webhooks bleiben bestehen und werden dokumentiert.
- Der Fehler- und Benachrichtigungsweg für den laufenden Prozess ist festgelegt.
Das Projekt ist anschließend nicht nur fachlich abgeschlossen. Auch der technische Betrieb hat einen definierten Zustand.
10. Checkliste für das technische Projekt-Offboarding
- Konten: Welche persönlichen, technischen und Testkonten wurden für das Projekt angelegt?
- Berechtigungen: Welche Zugriffe werden nach Projektende noch benötigt?
- API: Welche Schlüssel, Tokens oder technischen Zugangsdaten sind aktiv?
- Abhängigkeiten: Welche produktiven Prozesse verwenden diese Zugangsdaten?
- Webhooks: Welche Systeme senden weiterhin automatisch Daten?
- Automationen: Welche Workflows gehören jetzt zum laufenden Betrieb?
- Eigentümer: Wer ist nach der Übergabe fachlich und technisch verantwortlich?
- Fehler: Wer wird informiert, wenn ein produktiver Prozess ausfällt?
- Dokumentation: Sind Zweck, Systeme, Regeln und Zuständigkeiten nachvollziehbar beschrieben?
- Secrets: Werden Zugangsdaten sicher verwaltet und nicht ungeschützt in Projektdokumenten abgelegt?
- Rotation: Müssen Zugangsdaten wegen geänderter Zuständigkeiten erneuert werden?
- Abschaltung: Welche temporären Konten, Schlüssel und Verbindungen können kontrolliert entfernt werden?
- Test: Funktionieren die verbleibenden produktiven Prozesse nach den Änderungen weiterhin?
Ein Projekt ist erst sauber übergeben, wenn auch der technische Betrieb geklärt ist
Eine erfolgreiche technische Umsetzung endet nicht damit, dass die neue Funktion einmal funktioniert.
Nach Projektabschluss muss klar sein, welche Zugänge und Automationen Bestandteil des laufenden Betriebs werden, wer dafür verantwortlich ist und welche temporären Bestandteile entfernt werden können.
Dafür braucht es nicht zwingend einen komplizierten Offboarding-Prozess.
Eine nachvollziehbare Bestandsaufnahme, klare Verantwortlichkeiten, kontrollierte Änderungen und eine kurze betriebliche Dokumentation können bereits verhindern, dass vergessene Zugänge oder herrenlose Workflows dauerhaft bestehen bleiben.
Kubertino betrachtet bei Automatisierungsprojekten deshalb nicht nur die technische Verbindung zwischen Systemen. Entscheidend ist auch, wie ein Prozess betrieben, kontrolliert, geändert und an verantwortliche Mitarbeiter übergeben werden kann.