Release Notes - Version 4.0

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

1.

Removed the Address Book Management process. Its procedures have been moved to Configuration Management and Service Level Management. The Address Book Management process was removed to improve the model’s alignment with the ITIL® theory.

2.

Moved the Supplier Information Maintenance procedure from the Address Book Management process to the Configuration Management process.

3.

Made the "RAM (MB)" field on the Configuration Item form available for the CI category "Printer/Multifunction".

4.

Added the options "Pentium D", "Celeron D", and "Sempron" to the Processor field of the Configuration Item form.

5.

Added the "Hardware CIs without supplier" KPI to the Configuration Management process.

6.

Added Alarm Management procedure 3, Outage Review.

7.

Added Alarm Management work instruction 1.4.9, and the note that follows this instruction, to extend the compliance with the Visible Ops guidelines. In case of an incident, this work instruction asks the operator to check the service management application for changes implemented in the previous 24 hours.

8.

Moved the Incident Escalation Handling procedure from the Continuity Management process to the Incident Management process.

9.

Moved the arrows to Incident Management from Change Management procedure 1 to procedure 6. This ensures that support requests will not be closed out until the change to which they are linked has been completed.

10.

Added the support request status "Change Pending". Ensured in Change Management work instructions 1.3.1, 1.12.6 and 1.13.5 that support requests are not set to the status "Completed" after they have been linked to a change by a change coordinator. Instead the change coordinator sets the status of such support requests to "Change Pending". A support request will be set to the status "Completed" in Change Management work instruction 6.7.4 and Release Management work instruction 4.9.12 after the change to which it is linked has been completed.

11.

Removed the option "Passed - Passed to Change or Project Management" from the Completion code field of the Support Request form. This option is no longer needed.

12.

Made the Outage start date and Outage end date fields of the Support Request form required when the status is "Completed" or higher. Also added a UI Rule that automatically fills out these fields with the value of the Creation date, provided that the impact of the support request is different from "High - Service Down for Several Users".

13.

Added Incident Management steps 1.5, 1.6 and 1.7. This was done make the procedure easier to understand.

14.

Added Incident Management step 2.1. This was done make the procedure easier to understand.

15.

Rewrote Incident Management work instructions 2.5.1 and the note that follows it. This was done because the Group field is now automatically filled out.

16.

Added Incident Management step 2.9. This step was missing in previous versions of the process model. In this step, the service desk agent is now asked to obtain the missing information if a group coordinator rejected the support request because the information was incomplete.

17.

Added Incident Management step 2.10. This was done make the procedure easier to understand.

18.

Inserted a note after Incident Management Work Instruction 2.11.1 to clarify that, if the support request concerns and incident, a specialist will first need to determine how it is to be resolved in order to establish whether Change Management is required or not.

19.

Added Incident Management step 2.12. This was done to provide a specific path for support request that were rejected by a change coordinator because they can be completed within the Incident Management process.

20.

Split Incident Management step 2.1, Determine cause of complaint, into two separate steps. These steps are now 3.1 and 3.2. This was done make the Complaint Handling procedure easier to understand.

21.

Split Incident Management step 4.7, Determine how to resolve support request, into two separate steps. These steps are now 5.1 and 5.2. This was done make the procedure easier to understand.

22.

Added an arrow between Incident Management step 5.6 and Problem Management 1.1.Added Incident Management work instruction 5.6.5 to instruct specialists to contact the problem manager when the incident that they resolved is expected recur. Note that such a link is not needed between Alarm Management and Problem Management, as operators will only resolve incidents by following the alarm handling instructions. If such instructions were written to provide a work around for a problem, this problem will have been registered already.

23.

Added the Incident Management work instruction 6.5.2 to ensure that the service provider continues to monitor the progress of the incident.

24.

Added Incident Management step 7.5. This step was missing in previous versions of the process model.

25.

Added the Reporting tag field to the SLA Tracking tab of the Support Request form. This field can be used to improve the accuracy of SLA reporting.

26.

Split Problem Management procedure 2 into two separate procedures to provide room for additional steps.

27.

Added Problem Management steps 2.7 and 2.9. This was done make the procedure more complete and easier to understand.

28.

Added Problem Management steps 3.1 and 3.2. This was done make the procedure more complete and easier to understand.

29.

Added Problem Management steps 3.6, 3.7 and 3.8. This was done make the procedure more complete and easier to understand.

30.

Ensured that the Completion date field of a problem is filled out as soon as its status is set to "Change Pending". The value in the Completion date field will be overwritten with a new value when the status of the problem is subsequently changed to "Dead-End" or "Fixed". If the status changes to another value, the Completion date field is cleared. This causes the problems that have been linked to a change to be removed for the To Do Overviews. The Information update field becomes required when a problem is set to the "Change Pending" status.

31.

Removed the event circle "Necessity to change identified within group" from Change Management procedure 1 and also from the process diagram itself. This was done to ensure that all change requests can be passed to Release Management when that is necessary.

32.

Changed the decision diamond "Project Management Required" in Change Management procedure 1 to "Release Management Required". The conditions that need to be met in order for a change request not to be passed to Release Management are:

33.

Combined the Service Provider / Customers Representative role in Change Management procedure 3 into a new role called "CAB Member". Also adjusted the work instructions for step 3.7 accordingly.

34.

Added the option "Partially Implemented" to the Completion code field of the Change form. A change could end up being only partially implemented if the answers to the questions in Change Management decision diamonds 6.3 and 6.5 are both "No".

35.

Removed the option "Unapproved - Has Been Implemented without Approval" from the Category code field of the Change form. This was done because this option is not used anywhere in the process model.

36.

Added an arrow between Change Management step 8.4 and Problem Management 1.1.Added Change Management work instruction 8.4.4 to instruct specialists to contact the problem manager when the incident that they resolved is expected recur. Note that such a link is not needed between Alarm Management and Problem Management, as operators will only resolve incidents by following the alarm handling instructions. If such instructions were written to provide a work around for a problem, this problem will have been registered already.

37.

Replaced the "Rolled-back changes" KPI with the new "Successful changes" KPI in the Change Management process documentation as this KPI provides a more overall indication of the success of the Change Management process.

38.

Added the Release Management process.

39.

Renamed the Project form to Release, changed its fields and field options.

40.

Moved the Customer Information Maintenance procedure from the Address Book Management process to the Service Level Management process.

41.

Changed the field label "Supported tasks" to "Supported changes" in the Service Level Agreement form and adjusted its field utilization guidelines accordingly.

42.

Changed the section header "Supported Tasks" to "Supported Changes" and the term "Task" to "Change" in the Catalog Item Template. Also adjusted the explanation of a supported change and the description of each supported change example. Finally, removed the example of a "Request for Information" as most organizations do not provide a commitment for this type of request.

43.

Added the Penalties field to Service Level Agreement form. This ensures that the text from the Penalties section of a catalog item can be copied into this field after a customer has decided to obtain an SLA from the service provider organization based on the catalog item. This field has been added below the Charges field.

44.

Changed the name of the Expiry date field to "Renewal date" and adjusted its filed utilization guideline to make its purpose easier to understand. Also made this field required when the SLA status is set to "In Production".

45.

Removed the Serv. level mgr. field from the Service Level Agreement form as this field interfered with the assignment fields. As no other custom person fields are available for this form, this field could not be replaced. As soon as one more person field becomes available in HP OpenView Service Desk, this field will be reintroduced.

46.

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

47.

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

48.

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

49.

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

50.

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

51.

Added the term "Workaround" to the Glossary and added hyperlinks throughout the model to its definition. Also removed the word "temporary" in front of the word "workaround" in many cases, because that is now part of the definition.

52.

Removed the term "SMB" from the Glossary.

53.

Removed the term "Unapproved change" from the Glossary.

54.

Removed the term "Pending" from the Glossary. Replaced this term by "current" or "open" throughout the model. Also replaced "Pending" with "Open" in the HP OpenView Service Desk views.

55.

Rephrased the definition of the term "Supported task" in the Glossary. Renamed this term "Supported change".

56.

Renamed the owner of all service management processes and supporting service management application functionality to "Service Management CAB". Making the CAB of the Service Management service the owner of the processes ensures consistency with the new CAB role in the Change and Release management processes.