Release Notes - Version 3.2

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

1.

Moved the Service Level Management process from the Core module to the Advanced module. Moved the Alarm Management process from the Advanced module to the Core module. Renamed the "Core" and "Advanced" modules to "Service Support" and "Service Delivery" respectively. This improves the alignment between the two Alignability® modules and the two sets of processes described by ITIL®.

2.

Combined procedures 1 and 2 of the Address Book Management process to ensure that this process does not rely on custom-built web-based functionality. The combined procedure is called "Customer Information Maintenance". It handles the maintenance of contact information for both individual customers, as well as customer organizations.

3.

Removed the decision "Supplier organization information still accurate?" from the Supplier Information Maintenance procedure of the Address Book Management process. This was done because the configuration manager already asked this question in the Configuration Management process (steps 1.8 and 3.2).

4.

Added the event circle "Contact information update received from supplier" to the Supplier Information Maintenance procedure of the Address Book Management process, as well as a step to ensure that supplier information also gets updated when suppliers inform the service provider organization of changes in their contact details.

5.

Added a third procedure to the Configuration Management process for the registration and update of support contracts. This procedure is called "Support Contract Administration". The existing process description, procedure descriptions and work instructions have been adjusted according.

6.

Moved Configuration Management step 1.10 to procedure 2, where it became step 2.1. This makes the Configuration Management procedures easier to follow as it removes one arrow between procedures.

7.

Added steps 1.3 and 1.4 to the Service Level Management process to ensure that service level managers will be able to explain why SLO violations occurred and what will be done to prevent their occurrence in the future.

8.

Rewrote procedure 2 of the Service Level Management process. It has been split into 3 separate procedures (Service Catalog Maintenance, Service Activation and Service Termination).

9.

Added the Continuity Risk Assessment Scorecard in Microsoft Word format to the "Details" section of the Service Level Management process. This form can be used by the service level manager in steps Service Level Management 1.6 and 1.10 to help a customer organization determine the appropriate level of continuity coverage for a service infrastructure that it plans to start using.

10.

Added the Catalog Item template in Microsoft Word format to the "Details" section of the Service Level Management process. This will help the service level administrator prepare a catalog item as described in Service Level Management step 2.3.

11.

Added the SLA template in Microsoft Word format to the "Details" section of the Service Level Management process. This will help the service level administrator prepare an SLA as described in Service Level Management step 3.4.

12.

Adjusted the naming convention of services and SLAs to ensure that the services registered in the HP OpenView Service Desk application actually represent service infrastructures.

13.

Added the Service Dependencies tab page to the Service form. This page shows the supported and supporting services.

14.

Renamed the "Support Fulfillment" KPI of the Incident Management process to "Incident Resolution" to emphasize the fact that this KPI only takes into account support requests of the category "Request for Incident Resolution".

15.

Added the Incident resolution field on the Metrics tab page of the SLA form. This field allows service level administrators to enter the minimum percentage of incidents that are to be resolved before their resolution target.

16.

Reintroduced the Reliability field on the SLA form as it was found that the MTBF metric cannot be used to replace it. This field has been placed on the Metrics tab page.

17.

Rewrote the field utilization guidelines of the Service Desk Metrics and the Report Results fields of the SLA form to ensure that they are only used for availability. This was necessary because the other metrics cannot be calculated accurately with this functionality.

18.

Switched the Metrics tab page with the Customer tab page on the SLA form. This ensures that the customer information does not appear in the middle of the SLA details.

19.

Renamed the Service Level Mgr. field of the SLA form to "Service level mgr" to be consistent in the use of capitals.

20.

Added Incident Management work instruction 1.8.6, and the note that follows this instruction, to comply with the Visible Ops guidelines. In case of an incident, this work instruction asks the service desk agent to check the service management application for changes implemented within the past 24 hours.

21.

Added the "Alarm" option to the Source field of the Support Request form. This is now the default option for people whose account has been linked to the Operator role. Updated Alarm Management work instruction 1.4.7 and 1.7.7 accordingly.

22.

Changed the Incident form Source field option "Electronic Form" to "Web Request Form". This makes the relation between the web request forms and this option more intuitive.

23.

Added the Problem status "Known Error" to make the Problem Management process easier to correlate with the ITIL® guidelines. The definition of the term "Known error" has also been added to the Glossary. Problem Management work instruction 2.4.2 has been extended with the text: "and set the Status field to "Known Error"."

24.

Split Change Management procedure 4 into two separate procedures; one for the implementation of infrastructure changes and the other for the implementation of application changes.

25.

Added steps 1.4, 1.5 and 2.5 to the Change Management process to allow the flow to continue after a template was used to register a change.

26.

Split Change Management step 3.9 into two steps as this decision included an action. The action is now described by step 3.12.

27.

Added the term "Continuity risk assessment scorecard" to the Glossary.

28.

Simplified the Glossary definition of "Support" from "The activities performed by persons of the service provider organization to ensure that the functionality of its services is provided…" to "The activities performed to ensure that the functionality of the services are provided…". This was done to ensure that the definition also applies to support provided by external suppliers to the service provider organization.

29.

Removed the word "the" from the Glossary’s definition of the term "Supported task" between "based on" and "catalog item(s)".

30.

Rewrote the code of the entire model for support of a cascading style sheet. This allows more efficient customization and allows the model to be configured for the support of the U.S. Federal Government Rehabilitation Act, Section 508.

31.

Hyperlinked the process names (in the upper horizontal frame) to their respective process drawings to make navigation through the model more efficient.

32.

Hyperlinked the process logos (the small frames in the upper left-hand corner) to the diagram of the model so that user can quickly return to the model's home page.