В редакцию портала поступил вопрос по процессу управления проблемами:
Если в качестве решения проблемы возможны:
- изменение настроек компонетов системы
- доработка (те реализация дополнительных функуций, которые не были в ТЗ)
1 и 2 относятся к процессу управления изменениями? или это разные процессы, какие?
Можно добавить ещё один разрез для рассуждений – с т.з. связей с другими процессами и сущностями, которыми они управляют.
Формально, управление изменениями работает с КЕ. Нет КЕ – нечего и изменять.
Т.е. опять же формально – если настроек компонет системы
и объектов доработки нет в CMDB (или SKMS), то нет и изменения, т.к. изменению нечем управлять, затем релизить и т.д.
“Нет тела – нет дела” 🙂
Исходя из поставленного вопроса и отсутствия дополнительной информации о инфраструктуре и условиях ее обслуживания, а также о ИТ-услугах и условиях их предоставления, я бы ответил на этот вопрос так:
1. “Изменение настроек компонентов системы” – не относится к процессу управления изменениями, а проводится в процессе управления инцидентами/ стандартными запросами на обслуживание.
2. “Доработка (те реализация дополнительных функций, которые не были в ТЗ)” – может быть проведена по процессу управления изменениям если система сдана в эксплуатацию и принята на поддержку, или если система находится на стадии внедрения, то тогда в рамках Проекта, по дополнительному заданию к нему.
Попробуем ответить, двигаясь от общего к частному.
Изменение – создание/модификация/вывод объектов ИТ-инфраструктуры, участвующих в предоставлении ИТ-услуг, свойств объектов, их взаимосвязей.
Согласно этому общему определению – все вышеперечисленное будет изменениями.
Снижаемся к процессу.
Процесс управления изменениями нужен компаниям, которые хотят уметь проводить изменения быстро, с контролем операционных и иных рисков.
Поскольку любой формальный процесс потребляет ресурсы, то компании стремятся сделать процесс управления изменениями рациональным. Организации сами управляют охватом применяемого процесса: выделяют виды изменений, системный контроль за выполнением которых важен. Все прочие работы по изменениям, не попавшие в охват процесса, могут быть выполнены обособленно, в рамках или вне рамок других ИТ-процессов.
Ответ на вопрос, являются ли перечисленные работы изменениями для вашей компании, лежит в ваших определениях и положениях регламента процесса, описаниях применяемых у вас моделей изменений.
Процесс в организации служит своему назначению и сфокусирован на наиболее значимых для нее областях и целях. То, что все организации и, тем более, их текущие приоритеты отличаются, объясняет отсутствие “универсального, не абстрактного” определения изменения, границ охвата процесса для всех.
На практике, п.1 иногда может быть исключен из охвата процесса, если определенные виды изменений не несут заметного риска и влияния (пример: настройка пользовательских отчетов во внутреннем конструкторе отчетов). Подобные работы по изменениям “вне охвата” могут выполняться в рамках инцидентов (без регистрации связанного изменения), запросов на обслуживание (стандартное изменение., предоставляемое как часть предложения каталога запросов по услуге), проблем (т.к.процесс упр.проблемами может сам управлять своими работами). П.2. в жизни чаще является изменением, хотя и здесь тоже бывают исключения.
Надеюсь, что удалось ответить.