p. 360 · PDF 366

2-2-4 Control Process

p. 361 · PDF 367

Control process is a group of processes for managing the configuration elements of the services delivered and ensuring to implement changes to the configuration elements.

[Group of processes of control process]

1) Configuration management

2) Change management

3) Release and deployment management

(1) Configuration management

In configuration management, the definition is made for CI (Configuration Items), such as hardware, software, and documents that constitute a service, and accurate configuration information is managed and maintained. In configuration management, configuration items are identified, and the records are made concerning information of configuration items and related incident information and/or change information in the CMDB (Configuration Management Database). The following is an example of information to be recorded in the configuration management database.

Item Number	Item	Contents
1	Configuration item number	Code that uniquely identifies a configuration item
2	Configuration item name	Name of configuration item
3	Classification	Classification such as hardware and software
4	Classification details	Detailed explanation of classification (e.g., hardware → printer)
5	Supplier	Supplier or vendor of configuration item
6	Model number	Model number of supplier (i.e., manufacturer)
7	Warranty period	Warranty period of supplier
8	Management representative	Management representative of configuration item
9	License number	License number of configuration item
10	Delivery date	Delivery date of configuration item
11	Current status	Current operation status
12	Planned status	Planned operation status
13	Installation location	Installation location of configuration item
14	Incident information	Information on incident related to configuration item

View original table · p. 361

Enlarge original table

p. 362 · PDF 368

15	Problem information	Information on problem related to configuration item
16	Error information	Information on error related to configuration item
17	Change information	Information on change management

View original table · p. 362

Enlarge original table

Configuration management is the asset management process that manages service assets, such as software assets and hardware assets. A special attention should be paid to manage the model number and installation location of the hardware, and the license and version information (i.e., edition) of the software. (For software management, it is recommended to refer to Software Management Guidelines provided by Japan’s Ministry of Economy, Trade and Industry.)

(2) Change management

In change management, a decision is made whether or not to accept the RFC (Request For Change), and the approved changes are deployed according to the change schedule. After the implementation of the change, a review is performed with certainty to avoid risks arising from change. In change management, a change management policy is established that defines the following.

• • Configuration items (CIs) which are under the control of change management
• • Criteria to determine changes with potential to have a major impact on services or the
  customer.

[Change with potential to have a major impact]

• • Removal of a service
• • Transfer of a service from the service provider to the customer or a different
  party, etc.

In change management, the request for change is approved according to the following procedure in order to control the changes. Release and deployment management process takes over implementation and testing of changes.

1) Record of request for change and assessment of appropriateness All requests for change are recorded, and their appropriateness is assessed. · 1 question

2) Prioritization of changes An appropriate priority ranking (e.g., urgent to postpone) is decided according to the contents of request for change. After the definition of emergency changes is documented, it must be agreed on with the customer.

p. 363 · PDF 369

3) Classification on the basis of the extent of impact of change Requests for change are classified according to the extent of impact (e.g., severe to minor). Requests for change classified as having the potential to have a major impact must be managed by using the design and development/transition of new or changed services process.

4) Approval of changes The service provider and interested parties must make decisions on the acceptance of requests for change. This decision-making must take into consideration the risks, the potential impacts on services and the customer, service requirements, operating profit, technical feasibility, and financial impact. For example, there may be situations, such as “some bugs come to the surface by adding functions to the system” and “system or application can no longer be used because of version upgrade of OS.” Therefore, the situations must be checked in advance as much as possible.

5) Preparing schedule of change A schedule of change containing details of the approved changes and their proposed deployment dates must be prepared and communicated to interested parties.

6) Implementation and testing of changes

7) Evaluation of changes The changes by review are evaluated, and if the changes are unsuccessful, the unsuccessful changes are reversed or remedied. If the changes are successful, information is updated in the configuration management database.

(3) Release and deployment management

In release and deployment management, the changes approved in the change management process are deployed in the live environment as a release. (Release means the approved changes themselves, and deployment means actually applying the approved changes.) In release and deployment management, the service provider establishes a release policy and agree on it with the customer.

[Description of release policy]

• • Frequency and types of releases
• • Naming convention and acceptance criteria of release, etc.

In release and deployment management, the release is deployed in the live environment according to the following procedure.

p. 364 · PDF 370

1) Release and deployment planning The service provider must plan with the customer and the interested parties the deployment of the new or changed service and service component (i.e., one of the units constituting a service) on the basis of the schedule of change. Similar to emergency change, the service provider must agree with the customer on the definition of an emergency release.

2) Designing and building of release The releases are designed and built according to release policy and release and deployment plan. (This task can be outsourced to the development department or an external company.)

3) Release acceptance The release is verified and approved before deployment on the basis of the agreed acceptance criteria. An approved release is stored in DSL (Definitive Software Library) if it is software or in DHS (Definitive Hardware Store) if it is hardware.

4) Release deployment The release is deployed into the live environment so that the integrity of hardware, software, and other service components is maintained. In this case, if it is required, training is conducted for staff members and the customer.

5) Evaluation of release deployment In order to evaluate success or failure of release deployment, the release is monitored and analyzed. If the deployment of the release is unsuccessful, it must be reversed or remedied. If the deployment of the release has succeeded, the evaluation of change or the updated information to configuration management database is provided to the change management process.

Incidents and problems detected in the incident and service request management process are carried over to the problem management process and the change management process. They are resolved fundamentally in the release and deployment management process.