Мы уже говорили о том, что при внедрении сервисного подхода в организации помимо самого процесса управления уровнем ИТ-услуг традиционно выстраивается взаимодействие со смежными процессами. В частности, менеджерам ИТ-услуг неплохо бы участвовать в обработке изменений, которые касаются их ИТ-услуг. Для этого нужно, чтобы кто-то их привлекал на некоторых этапах обработки изменения (например, при согласовании подходов к реализации изменения, сроков, оценки изменений в рамках PIR и т.д.).
Возникает закономерный вопрос: как узнать, кого из менеджеров ИТ-услуг необходимо привлекать при реализации конкретного изменения в инфраструктуре (например, собираемся обновлять сервер). Нужны данные о связи отдельных элементов инфраструктуры с ИТ-услугами. Если есть CMDB, то нет проблем, достаточно учитывать соответствующие связи. Если же CMDB нет, то для получения ответов на подобные вопросы её чем-то заменить. Например, заводить "паспорта" элементов инфраструктуры и в качестве одного из атрибутов вести в них перечень ИТ-услуг, на которые описываемый элемент влияет.
Однако есть и обратная задача: как узнать, на какие элементы инфраструктуры должно распространиться влияние новых требований к ИТ-услуге? Например, изменение графика предоставления, сокращения окон обслуживания и т.д. Решить эту задачу можно включив в спецификацию ИТ-услуги перечень ресурсов, которые влияют на ее работу.
Ни одно из описанных решений не позволяет ответить сразу на оба вопроса. Но оба решения требуют организации работ по актуализации информации, назначения ответственных и т.д. Т.е. избегая организации полноценного процесса управления конфигурациями, мы так или иначе приходим к тому, что и CMDB, и процесс нужны.Так может быть, лучше сразу ориентироваться на их организацию и развитие, чем выдумывать заменители-костыли и потом с ними мучиться, не имея возможности нормально развивать?
О вреде костылей на примере SLM и CMDB
