Release Notes - Version 4.1


Below, an overview is provided of the improvements that have been included in version 4.1 of the Alignability® Process Model. Minor changes (e.g. improvements of the layout or spelling corrections) are not listed.

Version 4.1  -  January 2006

No.

Description of Improvement

Configuration Management

1.

Added the Configuration Management procedure "CI Requisition" to ensure that the Configuration Management process covers the entire lifecycle of a CI.

2.

Renamed Configuration Management procedure "CI Registration" to "CI Receipt" because CIs are now also registered in the new Configuration Management procedure that is called "CI Requisition".

3.

Added the Configuration Management KPI "Time to update CMDB" to keep track of the efficiency with which the CMDB is updated after an update has been requested by Change Management.

4.

Renamed the Configuration Management KPI "Unregistered CIs" to "CIs not found in CMDB". Changed "support requests" to "completed support requests" and removed the word "by group" from the definition of this KPI. The latter was done to ensure that this indicator helps to provide an overview of the process as a whole. Also changed the word "database" to "CMDB" and hyperlinked the term "CMDB" to its glossary definition.

5.

Changed "hardware and/or software" to "hardware, software and/or software license certificate(s)" in Configuration Management work instruction 2.2.1. This was done to explicitly include software license certificates.

6.

Added Configuration Management work instruction 2.8.3. This was done to ensure that the master copies of software CIs are labeled and placed in the DSL.

7.

Added Configuration Management work instruction 2.8.4. This was done to ensure that software license certificates are labeled and placed in the DSL.

8.

Added the option "Address" to the Category field of the Configuration Item form. Also added the options "IP Address" and "MAC Address" to the Subcategory field of the Configuration Item form. This allows organizations to link more than one IP Address and/or MAC Address to servers, workstations, etc. This is important because servers and workstations can have more than one (wireless) network interface card. Adjusted the field utilization guidelines for the Parent CIs and Component CIs fields to cover addresses.

9.

Added the option "Row" to the Category field of the Configuration Item form. This enables organizations to link racks as components of rows, thus enabling them to browse through their computer rooms or data centers more intuitively.

10.

Added the option "Telephone" to the Category field of the Configuration Item form. This change is also reflected on the Scope page of the Configuration Management process. The 3-character code for this category has been set to "PHN". This was added to reflect the fact that more and more IT departments are taking over the responsibility for the Telephony service from facility management. Also updated the field utilization and the Whatís This? text for the System ID field of the Configuration Item form to explain that it can be used to enter the number at which the (mobile) telephone can be reached.

11.

Added the option "Fax" to the Category field of the Configuration Item form. This change is also reflected on the Scope page of the Configuration Management process. The 3-character code for this category has been set to "FAX". This was added to reflect the fact that more and more IT departments are taking over the responsibility for the Telephony service from facility management. Also updated the field utilization and the Whatís This? text for the System ID field of the Configuration Item form to explain that it can be used to enter the number at which the fax machine can be reached.

12.

Changed the name of the Configuration Item formís Category field option "Software License" to "Software License Certificate" to make it more specific. This change is also reflected on the Scope page of the Configuration Management process. The 3-character code for this category was changed accordingly from "LIC" to "SLC".

13.

Simplified the name of the Configuration Item formís Category field option "Software Package for Distribution" to "Software Distribution Package". This change is also reflected on the Scope page of the Configuration Management process. The 3-character code for this category was changed accordingly from "PCK" to "SDP".

14.

Added the subcategory option "CPU-based License" for the "Software License Certificate" CI Category. This was done specifically to accommodate Oracle licenses.

15.

Made the Site and Location fields of the Configuration Item form available for the CI categories "Software", "Software Distribution Package" and "Software License Certificate". This allows the entry of the DSL in which the master copy of the software, software distribution package or software license certificate is stored. Rewrote the utilization guidelines for the Site and Location fields of the Configuration Item form accordingly.

16.

Changed "this refers to the internal hard disk drive" to "this field refers to the total storage capacity of the internal hard disk drive(s)" in the utilization guideline and Whatís This? text for the Disk capacity (GB) field of the Configuration Item form to allow for workstations and servers with multiple internal hard disk drives.

17.

Added the CI relation type "Continuity" (see the filed utilization guideline for the Related CIs field of the Configuration Item form).

18.

Added the PO number and the Cost center fields to the Configuration Item form. These additional fields will help organizations track their costs for configuration items. Also placed the fields on the Finance tab of the Configuration Item form in a more logical order.

19.

Added the Annual cost and the Cost type fields to the Contract form. The Cost type field has the options "Per CI Covered by the Contract" and "For All CIs Covered by the Contract". These additional fields will help organizations track their support contract costs.

Alarm Management

20.

Added the Alarm Management KPI "Backlog of alarms" to keep track of the workload of the operators.

21.

Adjusted the wording of the Alarm Management KPI "Time to acknowledge" slightly to make it easier to understand.

22.

Adjusted the first sentence of Alarm Management work instructions 3.2.3 to ensure that an incident is only tagged as a duplicate if it concerns the same service.

Incident Management

23.

Removed the customer representative role from the Incident Management Roles & Responsibilities. This role does not act in the Incident Management process.

24.

Removed the customer role from the Incident Management Roles & Responsibilities. This role triggers the Incident Management process, but does not act in this process. Because this role does not act in any of the other processes either, the Customer Profile page was also removed.

25.

Moved the on-duty manager responsibility for escalation handling from the Continuity Management process to the Incident Management process.

26.

Added the Incident Management KPI "Incident resolution effort" to keep track of the amount of time that is wasted on resolving incidents.

27.

Added the Incident Management KPI "Rejected solutions" to keep track of how often customers have rejected the solution provided for a support request.

28.

Added the Incident Management KPI "Backlog of support requests" to keep track of the workload of the service desk agents.

29.

Added the Incident Management responsibility for escalating high-impact incidents to the list of responsibilities of the service desk agent role.

30.

Added the responsibility for escalating incidents that need to be resolved through the Change Management process to the Incident Management responsibilities of the Specialist role in the Roles & Responsibilities section.

31.

Added Incident Management work instruction 1.6.1 to address the situation where a customer contacts the service desk to provide additional information for a support request that has not yet been completed.

32.

Added Incident Management work instruction 6.7.3 to ensure that the specialists receive proof of the approval to use the Emergency Change Management procedures for the resolution of an incident.

33.

Added the Time spent (min.) field to the Support Request form. This field was placed on the form just below the Reference number field. It allows the assignee to specify the number of minutes that he/she spent on the support request. When the support request is saved, the number of minutes is added to the value in the Cumulative effort field and the Time spent (min.) field is emptied out so that another value can be entered in it when additional work has been done on the support request.

34.

Added the Planned effort field to the Support Request form. This field was placed on the form just below the Maximum duration field on the Tracking & Finance tab. This field can be used to fill out the expected cumulative effort required to get the support request to the closed status. Organizations are expected to fill out this field in the support request templates to ensure that this field is automatically populated. This field was added to help organizations plan their human resources.

35.

Added the Cumulative effort field to the Support Request form. This field was placed on the form just below the Planned effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field. This field was added to help organizations keep track of the actual time spent on support requests.

36.

Added the Cost of effort field to the Support Request form. This field was placed on the form just below the Cumulative effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field in combination with the value in the Cost per hour field that is entered in the Person item of the person who entered the value in the Time spent (min.) field. This field was added to help organizations keep track of the actual cost of the time spent on support requests.

37.

Added the Cost of supplier field to the Support Request form. This field was placed on the form just below the Cost of effort field on the Tracking & Finance tab. Organizations can use this field to specify the cost for support from external suppliers that were asked to assist with the work on the support request.

38.

Added the Charge for customer field to the Support Request form. This field was placed on the form just below the Cost of supplier field on the Tracking & Finance tab. Organizations are expected to fill out this field in the support request templates to ensure that this field is automatically populated. This field was added to help organizations charge customers for requests (typically requests for supported changes) that are not covered by the SLA of the customer.

Problem Management

39.

Changed the Problem Management KPI "Incidents by service" to "Reported incidents". This indicator can be used to see whether the Problem Management process is able to keep the total number of reported incidents under control.

40.

Changed the Problem Management KPI "Problem Management activity by service" to "Problem Management activity" to ensure that this indicator helps to provide an overview of the process as a whole. Also removed the "the number of open problems" from this indicator as this information is now provided by the Problem Management KPI "Backlog of problems".

41.

Added the Problem Management KPI "Backlog of problems" to keep track of the Problem Management workload.

42.

Expanded Problem Management work instruction 1.7.8 to ensure that previously reviewed support requests that appear to have been caused by the same problem are also linked to the problem if they were not considered significant at the time of review because they signify a single service disruption that the problem manager did not expect to recur.

43.

Combined Problem Management work instructions:

1.8.1 and 1.8.2,

3.4.1, 3.4.2 and 3.4.3,

3.8.1 and 3.8.2, and

4.5.2 and 4.5.3.

44.

Added a note to explain how a problem needs to be passed from one group to the next if the group of the problem manager who is currently responsible for the problem cannot analyze it. The note was added below Problem Management work instructions 1.8.1, 3.4.2 and 4.5.2. Edited the note following Problem Management work instruction 3.3.1 accordingly.

45.

Added Problem Management step 2.5 to illustrate that it is not always possible to find a root cause. Adjusted the work instructions for step 2.4 accordingly.

46.

Added Problem Management work instruction 2.4.4 to ensure that specialists review the workaround for the problem, and improve it if possible, after the root cause has been found.

47.

Added Problem Management step 2.7 to illustrate that it is not always possible to find a structural solution for a problem. Adjusted the work instructions for step 2.6 accordingly.

48.

Added Problem Management step 3.7 to ensure that the problem manager reviews the problem before it is passed to a specific specialist for change implementation.

49.

Added a note underneath Problem Management work instruction 4.1.2 to indicate that the problem manager should work with a user if he/she does not have the access rights to verify the structural solution.

50.

Removed the option "Registered" from the Status field of the Problem form. This was done because problem managers often forget to change the Status field value to "Assigned" when the analysis needs to start.

51.

Added the Time spent (min.) field to the Problem form. This field was placed on the form just below the Reference number field. It allows the assignee to specify the number of minutes that he/she spent on the problem.

52.

Added the Planned effort field to the Problem form. This field was placed on the Tracking & Finance tab. This field can be used to fill out the expected cumulative effort required to work on the problem. Organizations are expected to fill out this field in the problem templates to ensure that this field is automatically populated. This field was added to help organizations plan their human resources.

53.

Added the Cumulative effort field to the Problem form. This field was placed on the form just below the Planned effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field. This field was added to help organizations keep track of the actual time spent on problems.

54.

Added the Cost of effort field to the Problem form. This field was placed on the form just below the Cumulative effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field in combination with the value in the Cost per hour field that is entered in the Person item of the person who entered the value in the Time spent (min.) field. This field was added to help organizations keep track of the actual cost of the time spent on problems.

55.

Added the Cost of supplier field to the Problem form. This field was placed on the form just below the Cost of effort field on the Tracking & Finance tab. Organizations can use this field to specify the cost for support from external suppliers that were asked to assist with the work on the problem.

56.

Ensured that the Service and CI fields of the Problem form are also required when the Status field is set to "Change Completed".

Change Management

57.

Moved the arrows to Service Level Management step 1.1 and Configuration Management step 1.1 to a position after step 4.2 in the diagram of Change Management procedure 4. This allows the Service Level Management and Configuration Management steps to be performed in parallel with Change Management step 4.3.

58.

Moved the arrows to Service Level Management step 1.1 and Configuration Management step 1.1 to a position after step 5.4 in the diagram of Change Management procedure 5. This allows the Service Level Management and Configuration Management steps to be performed in parallel with Change Management step 5.6.

59.

Moved the arrows from Configuration Management step 5.7, Capacity Management step 1.8 and Continuity Management steps 5.14 and 6.8 to a position after step 6.8 in the diagram of Change Management procedure 6. This allows the Configuration Management, Capacity Management and Continuity Management steps to be performed in parallel with Change Management step 6.8.

60.

Moved the arrows from Configuration Management step 5.7 and Capacity Management step 1.8 to a position after step 8.7 in the diagram of Change Management procedure 8. This allows the Service Level Management and Configuration Management steps to be performed in parallel with Change Management step 8.7.

61.

Added the Change Management KPI "Backlog of changes" to keep track of the Change Management workload.

62.

Adjusted the Change Management KPI "Time to approve" to include a hyperlink to the field utilization guideline for the Status field of the Change form.

63.

Adjusted Change Management step 1.2 to allow the bundling of multiple change requests from Problem management into a single change.

64.

Corrected the reference to the Information update field in Change Management work instruction 1.6.2. This now refers to the Solution field. Also rewrote the end of this work instruction to account for the fact that the Status field is automatically set to "Completed" and to explain that the service desk will inform the customer.

65.

Added Change Management step 2.4. This step for the change coordinator was missing.

66.

Rewrote the work instructions for Change Management steps 2.1, 2.5, 5.5, and 6.7 to ensure that change coordinators cannot dictate work to other groups without first discussing this with the group coordinator concerned, to include the possibility of assigning work orders to supplier organizations and to make the instructions more specific.

67.

Added a note after Change Management work instruction 5.4.1 to ensure that all bugs identified during the test of a new release that has been approved for transfer to production are registered in the service management application as problems.

68.

Added the text "creating a master copy of the new release for the configuration manager," to Change Management work instruction 5.6.1. This is necessary when a copy of the new release is to be placed in the DSL.

69.

Moved the first note following Change Management work instruction 6.1.4 upwards to ensure that it follows Change Management work instruction 6.1.3. This needed to be done because this note applies to work instruction 6.1.3 instead of 6.1.4.

70.

Changed the name of Change Management step 6.2 from "Implementation successful?" to "All change requirements fulfilled?" Also rewrote work instruction 6.2.1 to make it more specific.

71.

Added Change Management step 6.5 to ensure that the change coordinator is informed about unsuccessful change implementations.

72.

Changed the name of Change Management step 6.6 from "Can implementation be salvaged?" to "Can all requirements still be fulfilled?" Also transferred the responsibility for this step to the change coordinator to ensure that the specialist does not need to make this decision. Rewrote the work instructions for this step accordingly.

73.

Adjusted Change Management work instruction 6.8.5 to ensure that the change coordinator uses the Information update field, rather than the Solution field, of the Problem form to inform a problem manager how the change was implemented. Also ensured that the Information update field is required after the change coordinator has set the status of a problem to "Change Completed". This ensures that the change coordinator does not forget to fill summarize what has been changed, and also removes the conflict with Problem Management work instruction 4.3.1, which asks the problem manager to fill out the Solution field of the problem.

74.

Rewrote the work instructions of Change Management step 6.9 to ensure that the change is not closed until all work orders are completed that can be executed (in this new version) in parallel with step 6.8.

75.

Rephrased Change Management work instruction 8.4.5 because the Status field is automatically set to "Completed" after a value has been selected in the Completion code field.

76.

Added the Time spent (min.) field to the Work Order form. This field was placed on the form just below the Reference number field. It allows the assignee to specify the number of minutes that he/she spent on the work order.

77.

Added the Planned effort field to the Work Order form. This field was placed on the Tracking & Finance tab. This field can be used to fill out the expected cumulative effort required to execute the work order. Organizations are expected to fill out this field in the work order templates to ensure that this field is automatically populated. This field was added to help organizations plan their human resources.

78.

Added the Cumulative effort field to the Work Order form. This field was placed on the form just below the Planned effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field. This field was added to help organizations keep track of the actual time spent on work orders.

79.

Added the Cost of effort field to the Work Order form. This field was placed on the form just below the Cumulative effort field on the Tracking & Finance tab. This field is automatically populated using the values entered in the Time spent (min.) field in combination with the value in the Cost per hour field that is entered in the Person item of the person who entered the value in the Time spent (min.) field. This field was added to help organizations keep track of the actual cost of the time spent on work orders.

80.

Added the Cost of supplier field to the Work Order form. This field was placed on the form just below the Cost of effort field on the Tracking & Finance tab. Organizations can use this field to specify the cost for support from external suppliers that were asked to assist with the execution of the work order.

81.

Renamed the Change formís Category field option "Distinct - Approved Change Template not Available" to "Non-Standard - Approved Change Template not Available". This was done to make the option more intuitive.

82.

Added the option "Request Withdrawn by Customer" to the Completion code field of the Change form to allow changes to be closed out whenever the customer decides that it is no longer necessary to implement it.

83.

Adjusted the security settings for the Downtime field of the Work Order form to ensure that it is no longer required when the status of a work order is "Registered" or "Cancelled". This ensures that change coordinators no longer need to specify the expected downtime when the risk and impact analysis has not even started yet or when a work order is cancelled.

84.

Ensured that the change manager gets notified via email after an approval work order has been set to the status "Waiting for…", "Completed" or "Failed". This was necessary because otherwise the change manager is not able to keep track of changes for which approval has been requested. Also ensured that approval work orders that have been set to the status "Rejected" are reassigned to the Change Manager.

85.

Added a basic set of work order templates and linked them to the default change template in the HP OpenView Service Desk settings for the Alignability® Process Model. This change template can be used for infrastructure changes for which a specific change template does not exist. It can also be used as the basis for defining specific change templates for infrastructure changes.

86.

Added a basic set of work order templates and linked them to a new change template in the HP OpenView Service Desk settings for the Alignability® Process Model. This new change template can be used for application changes for which a specific change template does not exist. It can also be used as the basis for defining specific change templates for application changes.

87.

Added a change template, along with related work order templates, for emergency changes to the HP OpenView Service Desk settings for the Alignability® Process Model.

Release Management

88.

Added the Release Management KPI "Backlog of releases" to keep track of the Release Management workload.

89.

Removed the reference to the Incident Management en Problem Management processes from Release Management work instructions 1.3.2, 1.3.3, 1.5.3, 1.5.4, 1.6.1, 1.6.2, 2.7.2 and 2.7.3. This was done to avoid confusion, because from the release managerís point of view, the change requests were received from the Change Management process.

90.

Added a note after Release Management work instruction 1.6.2 to clarify that the change request will be reviewed in procedure 2 during the next CAB meeting.

91.

Adjusted the work instructions of Release Management steps 2.1, 2.2, 2.3 and 2.7 to ensure that a work order is used to prepare and facilitate the CAB meeting.

92.

Adjusted Release Management step 2.7 and its work instructions to ensure that the CAB meeting minutes are linked to the work order that was used to prepare and facilitate the CAB meeting. Also made sure in the work instructions that such a work order is registered for the next CAB meeting.

93.

Swapped the order of Release Management steps 2.7 and 2.8 to make the flow more logical.

94.

Corrected the reference to the Information update field in Release Management work instruction 2.8.3. This now refers to the Solution field. Also rewrote the end of this work instruction to account for the fact that the Status field is automatically set to "Completed" and to explain that the service desk will inform the customer.

95.

Added two work order templates to the list in Release Management work instruction 2.9.5 to ensure that all work orders are there for the release managers to coordinate releases.

96.

Rewrote Release Management work instructions of steps 3.10 and 3.11 to ensure that the approvers of the rejected business case are informed.

97.

Added the option "Placeholder for Change Requests Awaiting CAB Review" to the Category field of the Change form.

98.

Added the option "Support for Release Manager" to the Reason field of the Change form.

99.

Added a change template, along with related work order templates, for the coordination of releases to the HP OpenView Service Desk settings for the Alignability® Process Model.

100.

Added a change template, along with a related work order template, to the HP OpenView Service Desk settings for the Alignability® Process Model. This change template can be used to quickly prepare a change that will act as a placeholder for a serviceís change requests that still need to be reviewed by the CAB of the service. The work order template can be used to register work orders for preparing and facilitating CAB meetings.

Service Level Management

101.

Rewrote the work instructions for Service Level Management step 5.4 to ensure that the Reporting tag field of the support request form is used before finalizing the SLA review reports. To ensure that service level managers can use the Reporting tag field, the settings for the Service Level Manager role has been adjusted.

102.

Added Service Level Management work instruction 4.4.1 to ensure that the hardcopies of the SLAs are also updated.

103.

Corrected field utilization guideline for the SLA field of the Service form to ensure that multiple SLAs can be linked to the service if there are multiple customers using the service infrastructure that the service item represents.

Availability Management

104.

Corrected Availability Management work instruction 2.1.1 to ensure that the overview includes all service infrastructures of the service for which the availability manager is tracking the availability and reliability.

105.

Corrected Availability Management work instruction 2.1.3 to ensure that the affected SLAs are found in the Service form.

Continuity Management

106.

Added the arrow from Incident Management to Continuity Management procedure 2 in the Continuity Management process diagram. This arrow was missing.

Glossary

107.

Added the term "DSL" to the Glossary and added hyperlinks throughout the model to its definition.

108.

Added the term "Firmware" to the Glossary.

109.

Added the term "Hardware" to the Glossary.

110.

Added the term "Software" to the Glossary.

111.

Changed the name of the term "Distinct change" to "Non-standard change" in the Glossary and throughout the model. This was done to make this term more intuitive.

112.

Changed the words "Software licenses" to "Software license certificates" in the glossary definition of the term "CI".

113.

Changed the word "customer" to "user" twice in the glossary definition of the term "Performance". Hyperlinked the first occurrence of the word "user" to its glossary definition.

General

114.

Added the Cost per hour field to the Person form. This field was placed at the bottom of the Memberships tab. To avoid confusion, the Memberships tab was renamed to "Service Desk User Details". The Cost per hour field should be filled out for every person with an HP OpenView Service Desk account that includes the Specialist (or Specialist for Change Coordinator) role. This field is used for the "Cost of effort" calculation in the Support Request, Problem and Work Order forms.

115.

Add the Service Provider role to HP OpenView Service Desk settings for the Alignability® Process Model. This role is allowed to view and modify the value in the Cost per hour field of the Person form. This role is also allowed to view the Cost of effort field on the Support Request, Problem and Work Order forms.