Функциональный компонент «Контроль изменений» Change Control Functional Component

Простыми словами

Это компонент-держатель жизненного цикла всех RFC: он решает, в каком состоянии находится предложенное изменение, и следит, чтобы изменения шли стандартизованно и с возможностью аудита. Разделяйте роли: RFC — объект данных (что именно меняем), Change Control — компонент (кто ведёт его состояние), а поток данных «RFC» между компонентами — то, что передаётся. От «Configuration Management» отличается предметом: Change Control знает о предложенных изменениях, Configuration Management — о фактическом состоянии услуги. Особый случай: стандарт называет именно этот компонент примером компонента, который ядро более чем одного потока создания ценности, поэтому его синий прямоугольник рисуется в каждом из них.

Определение из первоисточника

Основные параметры

Атрибуты этой сущности по справочнику источника.

• Функциональные критерии стандарта: Shall act as an authoritative system of record for all change request information. Shall manage the state and lifecycle of the change. Shall facilitate communication with stakeholders. Shall assess the risk of proposed changes and their implementation. Shall support the impact and risk assessments to minimize risk of production disruptions involved when rolling out changes. Shall enable management of organizational changes and training needed for making a new release a success (which may include oversight that ensures that these tasks are included as part of the deployment package). Shall enable notification of all affected change stakeholders and facilitate their collaboration on change execution. May support automation of changes so that human participation is reserved for the highest added value and most complex change work. For example, the Event functional component or Incident functional component may use a manual or automated Run Book to resolve well understood issues without an active RFC. These classes of pre-approved RFCs will vary by company and by criticality of service. For these pre-approved RFCs, it is assumed that the RFC is recorded and that the Change Management process has access to that information. A typical example would be a Run Book automation script that both fixes the issue and logs what was changed as a closed RFC record. The relationship to the Actual Service is maintained to allow Configuration Management to have access to change information. Shall enable RFC management against a change calendar and avoid change collisions. Shall check and steer conflict resolutions between parallel planned deployments. Can provide change data to the Event and/or Service Monitoring functional components to facilitate root-cause analysis process in the context of the impact changes may have. Объекты данных компонента: RFC.

Связанные понятия