Release Notes - Version 5.0


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

Version 5.0  -  September 2006

No.

Description of Improvement

General

1.

Adjusted the formatting of all process and procedure diagrams, to ensure that the action boxes, event circles and decision diamonds provide sufficient space for an extra line of text. Also, the shapes are now filled with a color to make the diagrams easier to read.

2.

Removed the word "step" from the text above arrows that come from, or point to, another procedure. This makes the diagrams easier to read.

3.

Renamed the Detail button to "Forms" to make it more intuitive. Also simplified the text on each Forms page.

4.

Moved the Role button upwards so that it is now placed above the Forms button. This is a more logical position as the roles are more important than the forms.

Configuration Management

5.

Replaced the controller as beneficiary of the Configuration Management process with the service level administrator to ensure compliance with the Financial Management process.

6.

Limited the recommendation underneath the Configuration Manager profile to "One specialist per group." It is typically not necessary to assign this role to one specialist per service as it is not too much work to maintain the CMDB for an entire group (even when the group is responsible for multiple services).

Alarm Management

7.

Rewrote Alarm Management work instruction 1.2.2 to make it easier to understand.

8.

Adjusted Alarm Management 1.9.1, 2.9.1 and 3.10.1 to account for the fact that the Group field of a support request is automatically filled out based on the selected service or CI.

9.

Added "Do the same when it is currently after the group's normal office hours and it is important that a specialist already starts to work on the support request." to Incident Management work instruction 1.9.3. Also swapped the position of the words "page" and "telephone" to indicate that it is more logical to first try to call rather than to page.

10.

Removed the arrows to Incident Management 4.1 from Alarm Management 1.9, 2.9 and 3.10. These arrows are now covered by the arrow within Incident Management procedure 2 that points to Management 4.1.

11.

Changed "prevented" to "filtered out" in the name of Alarm Management step 2.5 to make it more intuitive and consistent with the name of Alarm Management step 3.7.

Incident Management

12.

Rewrote the work instructions for Incident Management step 1.10 to make it clear that the support request is not resolved in this step.

13.

Simplified Incident Management procedure 2 by removing steps 2.1 and 2.10. These steps are now covered by step 2.5. A note has been added below Incident Management work instruction 2.5.1 to provide a special instruction for the group coordinator of the service desk.

14.

Added a note underneath Incident Management work instruction 2.3.1 to explain how a support request template can assist the service desk agent while making the decision.

15.

Added "Do the same when it is currently after the group's normal office hours and it is important that a specialist already starts to work on the support request." to Incident Management work instruction 2.4.3. Also swapped the position of the words "page" and "telephone" to indicate that it is more logical to first try to call rather than to page.

16.

Corrected the table header above the work instructions for Incident Management step 2.8. The header now correctly refers to the service desk agent role, rather than the group coordinator role.

17.

Added Incident Management work instruction 2.11.2 to ensure that the group coordinator telephones or pages the specialist if the support request needs to be dealt with right away.

18.

Corrected the step number from "2.7" to "2.8" in the text above the arrow from Release Management in Incident Management procedure 7.

19.

Removed the reference to the Continuity Management process in Incident Management work instruction 4.11.1.

20.

Added a note underneath Incident Management work instruction 7.1.1 to explain how a support request template can provide the necessary instructions for resolving the support request.

21.

Added Incident Management work instruction 7.2.4 to explain that if the workaround of an open problem was used to resolve the support request, the support request needs to be related to this problem.

22.

Removed the bullet "Information regarding support requests for the update of customer information." from the service level administrators on the Beneficiary page of the Incident Management process. Such updates do not need to be requested by registering a support request (see Service Level Management procedure 3, Customer Information Maintenance).

23.

Replaced the controller as beneficiary of the Incident Management process with the service level administrator to ensure compliance with the Financial Management process.

24.

Added the Support Request Gathering Sheet to facilitate the collection of support request template information.

25.

Added the group coordinator role to the Service Desk group in the Role Assignment presentation and in the Service Desk Roles document. This was done to ensure that one person at the service desk always monitors the To Do Overview of the service desk. It is important that someone of the service desk handles support requests that have been assigned to the service desk (e.g. after a service level manager has registered a request for change for a customer or when a web form has been submitted that automatically generated a support request that is assigned to the service desk.

Problem Management

26.

Replaced "problem" with "root cause" in the fourth paragraph of the description of the second Problem Management procedure to be more specific.

27.

Removed "requiring a workaround" from the text in the first decision diamond of Problem Management procedure 2, as this text was superfluous.

28.

Rephrased Problem Management work instruction 2.3.3 to allow for the fact that a practical workaround could not be found earlier and that it is still not possible to find one.

29.

Extended Problem Management work instruction 2.6.4 to ensure that workarounds are removed as part of the structural solution implementation of a problem if this is necessary. For example, if the workaround of a problem is to reboot a server every night, the structural solution should also ensure that the server is no longer rebooted every night.

30.

Rewrote Problem Management work instruction 3.1.2 to ensure that the problem manager checks the Information field, rather than the solution field, to determine whether or not the structural solution has already been implemented by the specialist. The Solution field should only be filled out by the problem manager in Problem Management step 4.3.

31.

Split Problem Management work instruction 3.4.1 into two separate work instructions.

32.

Changed the name of Problem Management step 4.2 from "Structural solution successfully implemented" to "Has problem been fixed" to allow for the fact that the problem might not have been fixed even though the implementation of the requested structural solution (e.g. an upgrade to a new version of an application) was successful. Adjusted the work instruction for this step accordingly.

33.

Corrected the step number from "2.7" to "2.8" in the text above the arrow from Release Management in Problem Management procedure 4.

34.

Rewrote the description of the fourth Problem Management procedure to allow for the fact that a successful change implementation may not have fixed the problem.

35.

Rewrote the first responsibility for problem manager role in the Problem Management process to be more specific.

36.

Added the responsibility for the problem manager role in the Problem Management process for the periodic review of dead-end problems.

37.

Replaced the controller as beneficiary of the Problem Management process with the service level administrator to ensure compliance with the Financial Management process.

Change Management

38.

Added the change status "Approval Requested" to help the change manager distinguish between changes for with approval still needs to be requested and changes for which approval has already been requested. Added change management work instruction 3.7.8 to explain the usage of the additional status to the change manager. Also adjusted the filter of the "Changes To Be Approved" view to ensure that changes with the status "Approval Requested" are listed in the view.

39.

Rewrote Change Management work instruction 5.1.4 to ensure that the specialist tests the new release him/herself in a separate environment if one has been made available for this purpose. Also added the possibility to perform regression testing in this work instruction.

40.

Extended Change Management work instruction 5.5.2 to ensure that the new approval work orders are added if the transfer to production is going to be delayed due to the additional work.

41.

Extended Change Management work instruction 5.5.5 to ensure that the Target date field of work orders that were planned earlier, and which need to be completed after the new work orders have been executed, gets updated as needed.

42.

Adjusted Change Management work instruction 5.5.6 to ensure that none of the new work orders are assigned if the change needs to be approved again first.

43.

Added Change Management steps 5.6 and 5.7 to ensure that approval for the change is obtained again when the transfer to production needs to be rescheduled after the test of the new release failed.

44.

Rewrote Change Management work instruction 5.8.1 and split it into a work instruction and a note. Explicitly stated in the note that the master copy of the new release is prepared for the DSL.

45.

Extended Change Management work instruction 6.7.2 to ensure that the necessary work orders are created to request approval again for the change.

46.

Extended Change Management work instruction 6.7.7 to ensure that the Target date field of work orders that were planned earlier, and which need to be completed after the new work orders have been executed, gets updated as needed.

47.

Removed the word "implementation" from Change Management work instruction 6.7.8 because both implementation as well as approval work orders are added to the change in this step.

48.

Added Change Management work instruction 6.7.9 to ensure that the change coordinator specifies in the Information update field that the change needs to be approved again.

49.

Extended Change Management work instructions 6.5.2 to be more specific.

50.

Rewrote the work instructions for Change Management step 7.2 to ensure that the specialist tests the new release him/herself in a separate environment if one has been made available for this purpose. Also added the possibility to perform regression testing.

51.

Replaced the controller as beneficiary of the Change Management process with the service level administrator to ensure compliance with the Financial Management process.

52.

Added the Change and Work Order Template Gathering Sheet to facilitate the collection of change and work order template information.

53.

Rewrote the final sentence of the field utilization guideline for the Result field of the Work Order form. This was done to ensure that assignees can be asked to fill out the result field of a work order, even when it was successfully executed as requested.

Release Management

54.

Split Release Management work instruction 2.7.5 into two separate work instructions and specified in work instruction 2.7.6 that the release manager needs to assign the new work order to him/herself.

55.

Added Release Management work instruction 2.8.5 to ensure that the rejected change requests are unlinked from the placeholder change.

56.

Rewrote Release Management work instruction 2.9.10 to make it easier to understand.

57.

Added Release Management work instruction 2.9.11 to ensure that the change requests, which requirements are to be fulfilled by the new release, are unlinked from the placeholder change.

58.

Added to Release Management work instruction 2.10.7 that the information is to be added in the Information update field of the work order. This was done to be more specific.

59.

Changed the name of Release Management step 4.3 from "Change implementation successful?" to "All change requirements fulfilled" to be more specific.

60.

Changed "coordinators" to "coordinator(s)" in the name of Release Management step 4.4 to allow for the fact that only one change that is coordinated by a change coordinator might be linked to the release. Adjusted the work instructions for this step accordingly.

61.

Corrected "cost and effort" to "cost and/or effort" in Release Management work instruction 4.4.2.

62.

Added Release Management work instruction 4.4.3 to ensure that changes that should no longer be implemented are completed with the Completion code field set to "Request Withdrawn by Customer".

63.

Changed the order of the work instructions for Release Management step 4.9. Work instruction 4.9.7 is now 4.9.10 and work instruction 4.9.8 is now 4.9.9. This was done to make the order more logical.

64.

Corrected Release Management work instruction 4.9.8 by changing the reference to the Solution field of the Problem form to the Information update field. The Solution field should only be filled out by the problem manager in Problem Management step 4.3.

65.

Ensured in Release Management work instruction 4.9.10 that problems, which requirements were not (fully) met, are unlinked from the change to which the change request(s) for the release are linked.

Service Level Management

66.

Corrected the text in the decision diamond between boxes 2 and 3 of the Service Level Management process diagram. It now also covers the update of existing customer information.

67.

Rewrote the description of Service Level Management procedure 5, SLA Review and Request Handling to make it easier to understand.

68.

Rewrote the work instructions for Service Level Management steps 5.1 and 5.2 to make them easier to understand. Also changed the name of step 5.1 to ensure that is not confused with the step 5.5.

69.

Adjusted Service Level Management work instructions 5.8.9 and 5.11.9 to account for the fact that the Group field of a support request is automatically filled out based on the selected service or CI.

70.

Simplified Service Level Management work instruction 5.9.2 by removing "or group of individual customers".

71.

Replaced the controller as beneficiary of the Service Level Management process with the service level administrator to ensure compliance with the Financial Management process.

72.

Changed the term "finance manager" to "financial manager" in Catalog Item Template to better align with the ITIL® terminology.

73.

Added the "Charge Review" section to the SLA Template to ensure that it is aligned with procedure 3 of the Financial Management process.

Availability Management

74.

Replaced "in terms of skills and availability" with "in terms of skills, availability and access rights" in the description of the second Availability Management procedure to be more specific.

Capacity Management

75.

Replaced "in terms of skills and availability" with "in terms of skills, availability and access rights" in the description of the second Capacity Management procedure to be more specific.

Continuity Management

76.

Adjusted Continuity Management work instructions 2.9.1, 2.10.1, 2.11.2 and 2.12.1 to improve the distinction between the term "service" and the term "service infrastructure".

77.

Removed the arrows to Incident Management 4.1 from Continuity Management 3.5, 4.1 and 4.8. These arrows are now covered by the arrow within Incident Management procedure 2 that points to Management 4.1.

78.

Adjusted Continuity Management work instructions 3.5.9, 4.1.10 and 4.8.9, to ensure that they take account of the fact the Group field is filled out automatically.

79.

Rewrote Continuity Management work instruction 5.15.1 to make use of the option "Partially Implemented" of the Completion code field of the Change form.

Financial Management

80.

Added the Financial Management process.

Glossary

81.

Explained in the glossary what the abbreviation "CAB" means.

82.

Added the term "Charge" to the Glossary.

83.

Added the term "Cost" to the Glossary.

84.

Added the term "Regression testing" to the Glossary.

85.

Added the term "Rollback" to the Glossary.

86.

Removed the word "configuration" from the glossary definition of the term "Change" as this word is almost synonymous to "modification".

87.

Added "CIs and/or" to the glossary definition of the term "User" to include usage of individual configuration items.