Der Launch-Tag fühlt sich wie das Ende des Projekts an. Die Devices senden, die Dashboards sind grün, der Kunde hat die Abnahme unterschrieben, und das Projektteam wechselt zum nächsten Auftrag.
Die Menschen, die das System erben, waren am Aufbau nicht beteiligt. Sie haben den Schwellenwert 7,5 für den Tank-Alarm nicht festgelegt, sie wissen nicht, warum zwölf Devices den Tag “pilot” tragen, und der Alarm für niedrigen Batteriestand, der um 2 Uhr nachts auslöst, geht an einen Ingenieur, der im März aus dem Projekt ausgestiegen ist. Sechs Monate später kann niemand sagen, wie viele Devices noch senden. So verfällt ein funktionierendes Deployment. Nichts fällt aus. Das Wissen, das es am Laufen hielt, versickert mit jedem Abgang ein Stück.
Die Lösung ist ein Übergabepaket und eine Übergabephase, vor dem Launch vorbereitet und nicht danach aus dem Gedächtnis zusammengesucht. So sieht das Paket aus, das bei TagoIO-Deployments nach unserer Erfahrung funktioniert, egal ob das Betriebsteam aus Mitarbeitern des Kunden besteht oder aus der Support-Rotation des Integrators.
Beginnen Sie mit einer Zuständigkeitsmatrix
Die meisten Übergaben scheitern an einer Frage, die niemand gestellt hat: Wer ist für welchen Teil des Systems verantwortlich? Erstellen Sie eine Tabelle auf einer Seite, mit einer namentlich genannten Person (kein Team-Postfach) pro Zeile:
- Devices: wer sie hinzufügt, ersetzt und außer Betrieb nimmt, und wer angerufen wird, wenn eines verstummt
- Dashboards und das TagoRUN-Portal: wer ändert, was Endnutzer sehen
- Alarme: wer welche Action empfängt, wer einen Schwellenwert ändern darf
- Nutzer: wer TagoRUN-Nutzer und deren Berechtigungen anlegt und entfernt
- Abrechnung und Limits: wer die Service-Nutzung im Blick hat und Plan-Änderungen genehmigt
- Code: wer für den Payload Parser und jedes Analysis-Skript verantwortlich ist
Steht in einer Zeile kein Name, ist die Übergabe nicht fertig. Steht in jeder Zeile der Name des Projektleiters, ist es keine Übergabe.
Ersetzen Sie geteilte Logins durch echte Zugriffe
Die häufigste Abkürzung beim Launch ist ein Admin-Login, das sich das ganze Betriebsteam teilt. Eine Woche lang geht das gut, danach ist nichts mehr nachvollziehbar: Niemand weiß, wer den Schwellenwert geändert hat, und wenn jemand das Unternehmen verlässt, können Sie ihm den Zugang nicht entziehen, ohne alle anderen auszusperren.
Legen Sie TagoRUN-Nutzer für das Betriebsteam an und geben Sie jeder Rolle über Access Management Policies genau das, was sie braucht: Ein Servicetechniker sieht die Device-Liste und das Health-Dashboard für seine Standorte, ein Supervisor kann Alarme quittieren und Schwellenwerte über ein Formular anpassen, ein Administrator kann Nutzer anlegen. Formulieren Sie Policies über Device-Tags (Standort, Kunde) statt über Device-IDs, damit sie auch noch gelten, wenn nächstes Jahr Device Nummer 300 dazukommt. Die Admin-Konsole bleibt den Entwicklern vorbehalten, und die Liste der Admin-Nutzer bleibt kurz und wird schriftlich festgehalten.
Schreiben Sie ein Runbook für jeden wiederkehrenden Alarm
Ein Alarm ohne Runbook ist Lärm mit Zeitstempel. Schreiben Sie für jede Action, die einen Menschen benachrichtigt, einen kurzen Eintrag: was der Alarm im Klartext bedeutet, was zuerst zu prüfen ist, was zu tun ist, wenn die Prüfung das Problem bestätigt, und wann und an wen eskaliert wird. Gelesen wird das um 2 Uhr nachts auf dem Handy, also halten Sie es kurz.
Richten Sie danach das Routing der Actions passend ein. Eine TagoIO Action kann E-Mail, SMS oder Push-Benachrichtigungen an TagoRUN-Nutzer senden oder eine Analysis aufrufen. So erreicht der Alarm für ein offline gegangenes Gateway den Techniker im Bereitschaftsdienst, während eine Nutzungswarnung an den Verantwortlichen für die Abrechnung geht. Prüfen Sie bei der Übergabe jede Empfängerliste, denn fast immer steht dort noch das Projektteam.
Bauen Sie die Device-Health-Ansicht, die das Betriebsteam täglich prüft
Das Projektteam weiß, dass die Flotte gesund ist, weil es zugesehen hat, wie sie Device für Device in Betrieb ging. Das Betriebsteam muss diese Sicherheit von einem Bildschirm ablesen können: ein Health-Dashboard, getrennt von der Ansicht für Endnutzer, mit dem letzten Meldezeitpunkt pro Device, dem Batteriestand, wo die Hardware ihn sendet, und der Zahl der Devices, die länger als ein definiertes Zeitfenster offline sind.
In TagoIO ist das meist ein Blueprint Dashboard, gesteuert über Device-Tags, sodass ein Dashboard alle Standorte abdeckt. Ein Table Widget, sortiert nach letztem Meldezeitpunkt, schiebt stille Devices nach oben. Ergänzen Sie eine Action, die auslöst, wenn ein Device länger schweigt als sein erwartetes Intervall. Dieser eine Alarm fängt leere Batterien, versetzte Gateways und vergessene Firmware-Updates ab. Wenn die Ansicht länger als eine Minute zum Lesen braucht, vereinfachen Sie sie.
Dokumentieren Sie die Logik, die im Code steckt
Der Schwellenwert liegt bei 7,5, weil der Verfahrenstechniker des Kunden sagte, 8 sei zu spät und 7 habe im Juli Fehlalarme ausgelöst. Diese Begründung existiert nur im Kopf einer Person, solange sie nicht neben dem Wert steht. Kommentieren Sie jeden Skalierungsfaktor und jede Einheitenumrechnung im Payload Parser. Geben Sie jedem Analysis-Skript einen Kopfkommentar: wodurch es ausgelöst wird, was es liest und schreibt, und wer es angefordert hat. Wo Schwellenwerte in Device-Parametern oder einem Dashboard-Formular liegen, führen Sie eine Tabelle mit den aktuellen Werten und der Begründung für jeden einzelnen.
Schreiben Sie die Namenskonventionen auf: wie Devices benannt werden, welche Tags Pflicht sind (Standort, Kunde, Hardware-Modell, Installationsdatum), wie der Parser Variablen benennt. Wenn die halbe Flotte mit Site A getaggt ist und die andere Hälfte mit site_a, bricht jede Policy und jeder Blueprint-Filter, der darauf aufbaut.
Legen Sie fest, wie Änderungen ablaufen
Deployments bleiben nicht so groß, wie sie beim Launch waren. Irgendwann kommt ein Standort dazu, wird ein Sensormodell getauscht oder ein neuer Alarm gewünscht. Ohne Änderungsprozess wird daraus jedes Mal ein Anruf beim Projektteam, und das Betriebsteam lernt, am System vorbei zu arbeiten statt mit ihm.
Der Prozess passt auf eine Seite: wie man ein Device hinzufügt (welcher Connector und welches Network, welche Tags, wie man prüft, dass es im Health-Dashboard auftaucht), wie man eine Schwellenwertänderung beantragt und wer sie genehmigt, wie man einen TagoRUN-Nutzer anlegt, und wofür weiterhin das Projektteam gebraucht wird. Führen Sie ein Änderungsprotokoll, ein geteiltes Dokument genügt, damit im Oktober bei einem Fehler jemand nachsehen kann, was im September geändert wurde.
Planen Sie ein monatliches Review
Kosten und Limits verschieben sich leise. Devices kommen dazu, eine Analysis läuft häufiger, fünfzig Nutzer öffnen ein Dashboard mit langem Zeitraum, und die Data-Input- und Data-Output-Nutzung des Profils kriecht in Richtung Plan-Limit. Tragen Sie ein monatliches Review von 30 Minuten in den Kalender des Abrechnungsverantwortlichen ein: Service-Nutzung gegen den Plan prüfen, bestätigen, dass die Einstellung für Data Retention noch zum Bedarf des Kunden passt, die Devices zählen, die seit 30 Tagen nicht gemeldet haben, und offene Punkte im Änderungsprotokoll durchgehen. Integratoren, die die Betriebsrolle selbst behalten, machen das ohnehin als Teil eines wiederkehrenden Service. Genau dieses Review hält einen Managed Service profitabel, statt ihn langsam ausbluten zu lassen.
Begleiten Sie zwei Wochen, bevor Sie gehen
Das Paket oben ist notwendig und nicht ausreichend. Dokumente werden einmal gelesen, Gewohnheiten entstehen durch Tun. In den zwei Wochen nach dem Launch betreibt das Betriebsteam das System, während das Projektteam auf Abruf bleibt: Es bearbeitet jeden Alarm, fügt das nächste Device hinzu, hält das erste monatliche Review ab. Das Projektteam beantwortet Fragen und, nützlicher noch, korrigiert das, was in den Dokumenten fehlt, solange das Wissen frisch ist.
Schließen Sie mit einem kurzen Meeting ab: die Zuständigkeitsmatrix noch einmal durchgehen, bestätigen, dass jeder Alarm in einem Test ausgelöst und die richtige Person erreicht hat, dann das Projektteam aus den Empfängerlisten und aus allen Admin-Zugängen entfernen, die es nicht mehr braucht. Dann ist das Projekt fertig.
Checkliste für die Übergabe
- Zuständigkeitsmatrix mit einer namentlich genannten Person pro Zeile
- TagoRUN-Nutzer und Access Management Policies pro Rolle; geteilte Logins entfernt
- Runbook-Eintrag für jede Action, die einen Menschen benachrichtigt; Empfänger geprüft
- Health-Dashboard (letzte Meldung, Batterie, Anzahl offline) mit Alarm für stille Devices
- Kommentare im Payload Parser und im Analysis-Code; Schwellenwerttabelle; Tag-Konventionen
- Änderungsprozess auf einer Seite und ein Änderungsprotokoll
- Monatliches Review zu Nutzung, Data Retention und Offline-Devices
- Zweiwöchige Begleitphase mit Abschlussmeeting
