Idee: CIs werden beim Change bereits vor der Umsetzung des Change in der CMDB/MIR als “inaktivˮ angelegt und mit der Ausführung des Changes aktiviert. Die CIs dienen nicht nur der nachträglichen Dokumentation, sondern vielmehr als Steuer-Objekte für die Automatisierung. Wir brauchen sie also vom Start des Lebenszyklus an. Die SOLL-Definition steht in den Attributen des CI inkl. aller Relationen, die man braucht, um Zuständigkeiten zu erkennen, Benachrichtigungen zu senden, Service-Zuordnung zu erkennen, Kundenzuordnung zu sehen, zu verrechnen, usw. Die „Automatisierung" (Workflow-Engine, RPA, …) greift direkt auf die CI-Daten zu und steuert die Management-Werkzeuge an (VMware, IPAM, AD, IAM, usw.) Der Workflow (= USM Service Request) schließt nach erfolgreichem Durchlauf den Service Request ab und setzt das CI auf einen vorab definierten Status. Dieser signalisiert, dass es „ready for testing“ (oder whatever) ist. Generell ist die Definition einer CMDB als Ort der verbindlichen SOLL-Konfiguration, aus der das IST geschaffen wird, schon recht alt und wird in mehreren einschlägigen Papers gut beschrieben.
Die gängige Beratungspraxis weicht leider davon ab: Die technische Umsetzung (Einführung einer CMDB) erfolgt meist von Consultants, die nur eine Antwort auf CMDB kennen: Discovery. Das ist ein erfolgreiches Geschäftsmodell, eventuell auch eine brauchbare Lösung für die erste Baseline - indem wir die IST-Daten als SOLL annehmen und ohne lange zu fackeln in die CMDB speichern. Discovery bzw. Inventory und das regelmäßige Überschreiben der IST-Daten ist jedoch keine alleinige Lösung für die Abbildung eines CI-Life Cycle!
Zum Thema Life Cycle von CIs kann in diesem Fall auf Vorarbeit zugegriffen werden: Im CSDM White Paper von ServiceNow https://www.servicenow.com/community/common-service-data-model/it-is-time-csdm-4-0-draft-white-paper/ta-p/2309441 ist der CI Life Cycle (als auch der Asset Life Cycle) definiert und beschrieben (CSDM CI Life Cycle Processes)
Conclusio: Es gibt einen Branchenprimus, der einen komplett definierten CI Life Cycle erarbeitet hat. Der beginnt bei „Ideation“ und nicht erst bei „Operation“. Von diesen verfügbaren Dokumenten und Lösungen können wir lernen.
Diese Idee ist also „approved and very good practice“ in reifen Service Organisationen 😉 Im Übrigen kann man das auch mit Open Source Software und ein paar Scripts umsetzen - man braucht nicht zwingend einen Rolls Royce, um von A nach B zu kommen. Es ist nur komfortabler.
Weitere Erkenntnisse zum Thema CI Lifecycle: