Introduction
I created this material to aid in the study and implementation of ITIL Service Delivery and Service Support. The content are my interpretation and may be flawed. Thus, no warranty is offered or implied as to the suitable of this material for use. If you find errors or discrepancies, please send an email and I will do my best to correct the situation. Please understand, however, that this is a voluntary work in progress.

Also, please remember that this is a supplement, not a replacement for the ITIL Service Delivery and Service Support guides. While this material may aid your study and implementation, I strongly emphasize the importance of reading the actual OGC materials.

Robert Perrine, PMP, ITIL-SM, MBB, CISA
robert@RobertPerrine.biz
Fall 2004 - 2007
Irvine, California, United States of America

Copyright
Fall 2004 - 2007, Irvine, California, USA, copyright by Robert E. Perrine, PMP, ITIL-SM, MBB, CISA.
Offered as is, with no warranty regarding the accuracy or suitability of this material. Copyright reserved. Please, however free to copy and share these documents with the following restrictions.

• You may not charge for use or distribution of this material.
• Your usage of this material is conditioned upon your compliance with the PMI Code of Ethics.
• All distributions must be made with the intent to further the collected wisdom of humanity.
• You may not remove my name or my copyright notices from these documents.

Collaboration
The Collaborative sections documents the responsibilities for those key processes that span multiple disciplines.

Collaboration of Change, Configuration and Release Management

INPUTS	CHANGE	CONFIG	RELEASE	OUTPUTS
Proposed Request for Change (RFC)	Filtering			Accept or reject the proposed RFC
RFC	Registration	Record		RFC entered into CMDB and linked to relevant details
RFC linked to appropriate configuration details	Assess risk	Assess impact	Assess resource	Risk, Impact and Resource assessments
RFC with risk,impact and resource assessments	Categorization	Track	Monitoring	RFC updated with Category, Impact, Urgency and Priority and assigned to Change Authorization Model
RFC with assessment and business justification	Approval through appropriate Change Authorization Model	Track	Planning	Forward Schedule of Changes (FSC), Projected Service Availability (PSA) and Release Schedule (RS)
Procurement planning	Track	Track	Make or buy evaluation	Issue purchase orders or do in-house design
Authorized RFC with RS	Track	Load the build documentation into the Configuration Management Database (CMDB)	Build	Monitor build progress and verify conformance with requirements
Release Unit into clean test area	Track	Record results in the CMDB	Fit-for-Purpose Testing	Coordinate user acceptance testing
Documented back-out plan	Track	Record results in the CMDB	Test the back-out plan	Sign off on the suitability of the backout plan
Release Unit into clean test area	Track	Track	Integrity	Ensure release is licensed, secure, traceable and as per authorization
User documentation	Track	Check documentation into the Definitive Software Library (DSL)	Training	Coordinate user and support training
Fit-for-purpose test results	Track	Record results in the CMDB	Release Acceptance	User acceptance testing sign off
RFC, FSC, RS and user acceptance testing sign off	Authorization	Notification	Track	Notification to all that will be impacted by this change
Release Unit with proper licensing and documentation	Track	Check release into the DSL and/or Definitive Hardware Store (DHS)	Distribution	Release Unit into DSL/DHS and distributed as required
At the appropriate time	Implementation	Track	Implement	Release Unit installed and ready for User evaluation
Release Unit installed and ready for User evaluation	Evaluation	Track	Audit integrity as installed	User sign off or agreement to back-out
Either change is in effect or it is cleanly backed-out	User acceptance	Track	Activate release or execute the back-out process	Stable production environment along with list of change induced incidents
Stable production environment along with list of change induced incidents	Ensure the RFC is properly documented and closed	Make the updates in the Configuration Management Database	Ensure configuration details are properly updated	Configuration details updated and RFC closed with status. If the Change was backed-out, then create a new RFC and start over.
Periodically as defined in the Change Management policies	Post Implementation Review	Track		Review all changes in the recent period and initiate appropriate corrective actions

Dependencies
The dependency sections list the relationships and dependencies between the ITIL disciplines. These entries are directly based upon the text of the ITIL Service Delivery and Service Support guides.

Service Desk with Incident Management
Service Desk can be the customer interface to the ITIL processes (2.11)
Service Desk can implement Incident Management (2.11)
Service Desk can provide life-cycle management of Incidents including: receive, record, classify, prioritize, triage, notify, escalate, track, communicate status and report.
Tools, such as the list of Known Errors, used by Service Desk also support Incident Management.
Second level and third level Incident Management may be outside the Service Desk.
Service Desk should document issues that impact the SLA.
Service Desk should define the relationship to “Super Users”.
Service Desk should implement and publish customer satisfaction surveys.
Service Desk can feed Incidents into the Incident Management process
Service Desk is responsible for the monitoring and resolution of all Incidents
Second level and third level Incident Management may be outside the Service Desk.
Service Desk is responsible for registering all Incidents
The Service Desk will generally be responsible for Incident resolution and often handles up to 85% of the Incidents
The Service Desk monitors the progress on all registered Incidents
Service Desk assigns the Priority
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
Incident closure should be handled by the Service Desk even if the resolution was determined outside of the Service Desk
Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that records can be shared (2.9)
Changes may create new Incidents (2.9)
There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)

Service Desk with Problem Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk interfaces with Problem Management include Problem identification, escalation and enforcement of SLA/ OLA requirements.
Service Desk should escalate to Problem Management when it is unclear how to proceed with Incident Management.
Problem Management must only accept Problems from the Service Desk or the Service Desk will loose control of the process
Service Desk is responsible for disseminating the information about the work-around or resolution once Problem Management defines it
Problem Management must be kept separate from the Service Desk due to conflicts in interests.

Service Desk with Configuration Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk should be integrated with Configuration Management.
Service Desk is dependent on the Configuration Management tools.

Service Desk with Change Management
Service Desk can be the customer interface to the ITIL processes (2.11)
Service Desk should be integrated with Change Management.
Even self-service style “Service Desk” functionality must integrate with Change Management.
Service Desk might act as the focal point for Requests for Change from the Users, distribute the Forward Schedule of
Change on behalf of Change Management and keep the Users informed regarding the progress of their Changes (2.11)
The Service Desk may be given delegation to implement standard Changes to circumvent Incidents within its sphere of authority. The scope of such Changes should be predefined and the Change Management function should be informed about all such Changes. Prior approval of Change Management is essential before Changes of specification of any
Configuration Item are implemented (2.11)
Change Management can delegate authority to the Service Desk to implement changes
The Service Desk is usually asked to handle customer notification regarding Changes
Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management
The Service Desk must be kept informed of the details of each Change (2.7)

Service Desk with Release Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk should be integrated with Release Management.
Even self-service style “Service Desk” functionality must integrate with Release Management.
Service considerations must be included in release planning.
The Service Desk must be informed about any changes in the vendor support agreements
Release Management should inform the users when there are changes to the vendor support agreements, but the Service Desk may need to repeat that communication
Problem Management and Service Desk personnel must be trained to use and support the new Release

Service Desk with Service Level Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk uses Service Level Agreements and can provide enforcement on the Service Level Agreement and
Operational Level Agreement requirements.
Service Desk uses the Service Catalog to define agreed expectations and identify the appropriate support process.
The Service Desk is in the direct firing line of any impact on the SLAs and as such needs rapid information flows (2.11)
Service Desk Incident Records can be used to identify the services when constructing a Service Catalog
Verify that the Service Level Agreements are achievable before agreeing
It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the time allotted in the Service Level Agreement
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer’s perception of Availability
The Service Desk can monitor Incident response times and Incident resolution times
The Service Desk can monitor compliance with the Underpinning Contracts
The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation
The Customer’s perception of response time should be recorded and Problem Management should investigate repetitions
Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements

Service Desk with Financial Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk can integrate with Financial Management.
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
Training materials must be produced to explain the IT Accounting and/or Charging system. The Service Desk might be one of the users of this documentation (SD 5.6.1)
Sources of data for the costing / charging model are Service Desk calls, workload data from the Capacity Management
Database, inventories from the Configuration Management Database and planned acquisitions (Capacity Plan) (SD 5.6.2)

Service Desk with Capacity Management
Service Desk can integrate with IT Service Capacity Management.
Service Desk can recommend improvements to Capacity Management.
Service Desk may refer performance related Incidents to Capacity Management to assess (SD 6.2)
Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)

Service Desk with IT Service Continuity Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk can integrate with IT Service Continuity Management.
Service Continuity will interface with Service Desk for statistics on prior activities (SD 7.1.8)
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)
The Service Desk has an important role to play if business continuity is invoked (2.4)

Service Desk with Availability Management
Service Desk can be the customer interface to the ITIL processes.
Service Desk and Incident Management handling of an Incident can significantly impact how this Incident affects
Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)
Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)
The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)
Every component should have a designated maintenance strategy (planned downtime) incorporated into the service agreements (SD 8.5.6)
Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)
Available Management can use the Expanded Incident Life Cycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

Incident Management with Problem Management
The Incident Management process includes searching for matches against open Problems, Known Errors and resolution details
Incidents are linked to Problem Records when there is a match
Incident Management can generate a Problem Record when the cause of the Incident is unknown
Incident Management is responsible for finding a resolution or a work-around
When Incident Management finds a work-around they should pass it to Problem Management for evaluation
When Problem Management finds a work-around or resolution they need to pass it over to Incident Management
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
Problem Management should be notified if there is a Major Incident
Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that records can be shared (2.9)
Changes may create new Incidents (2.9)
There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)
Incident Management forwards Incident details and workarounds to Problem Management
Incident Management uses the documentation on known errors and workarounds
Problem Management reacts to Incidents when escalated
Problem Management should proactively examine the history of Incidents and find trends
Improvements in the Knowledge database should allow Incident Management to resolve more Incidents and do so more quickly
Problem Management should be implemented in parallel with Incident Management, or after Incident Management
Problem Management needs to work closely with Incident Management to create and update the Categories
Problem Management can create or deploy diagnostic tools and then train the Incident Management team on how to use

Incident Management with Configuration Management
Incident Management utilizes the Configuration Management Database and links Incidents to Configuration Items
Incident Management may uncover discrepancies in the Configuration Management Database
Inconsistencies in the Configuration Management Database should be reported to Configuration Management
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
Incident Management should use the Configuration Management database to assess the number of users impacted by an Incident
Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that records can be shared (2.9)
Changes may create new Incidents (2.9)
There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)
Provide an accurate representation of the infrastructure to support other ITIL processes
Configuration Management must be able to report on all Configuration Items impacted by an Incident or a Problem
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
The Configuration Management Database is used to link Incidents, Problems and other records to the Configuration Items and the Users (2.6)

Incident Management with Change Management
Requests for Change are not regarded as Incidents.
Incident Management will use the response from a Request for Change to implement a work-around or resolution
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
Replacing faulty hardware is not considered a Change
Incidents, Problems, Known Errors, Requests for Change should all be stored or linked into the Configuration Management Database so that records can be shared (2.9)
Changes may create new Incidents (2.9)
There should be a close interface between Incident, Problem, Change Management and the Service Desk (2.9)
Incident Management is authorized to make corrections, but should seek authorization for Changes

Incident Management with Release Management
It is recommended that all five Service Support processes and the Service Desk be implemented as a unit
The Definitive Hardware Store can be used in the event of a Major Incident
Problem Management and Service Desk personnel must be trained to use and support the new Release
Release procedures may be an integral part of Incident and Problem Management (2.7)

Incident Management with Service Level Management
The detailed history that Incident Management maintains on each Incident is helpful when evaluating Service Level Agreement breaches
Functional Escalation should occur before the Service Level Agreement time has expired
Hierarchical Escalation occurs when the Service Level Agreement time is likely to expire
Service Level Management defines the time to resolve goals, often based upon Categories
Incident Management uses the time to resolve goals and the Category to determine Urgency
Incident Management gathers the data for the evaluation of Service Level Agreement compliance
Incident priorities and escalation procedures need to be agreed as part of the Service Level Management process and documented in the Service Level Agreements (2.9)
Service Desk Incident Records can be used to identify the services when constructing a Service Catalog
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
Recent Incidents and long-standing Problems often cloud the negotiation on Service Level Agreements
Verify that the Service Level Agreements are achievable before agreeing
It is important that the Customer reports Incidents promptly so that the Incident can be resolved within the time allotted in the Service Level Agreement
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer’s perception of Availability
The Service Desk can monitor Incident response times and Incident resolution times
The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation
The Customer’s perception of response time should be recorded and Problem Management should investigate repetitions
Some of the most important targets set in the Service Level Agreements relate to service Availability and thus require Incident resolution within agreed periods (2.1)

Incident Management with Financial Management
Incident Management needs to update Incident Records with appropriate costing codes and hours worked
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

Incident Management with Capacity Management
Incident Management often finds options for beneficial system enhancement
The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)
Other Service Management processes can refer Incidents and Problems to Service Capacity Management when there is a breach or a risk of a breach against a Service Level Agreement. Service Capacity Management will then refer those Incidents or Problems to Resource Capacity Management (2.3, SD 6.2.2, 6.2.3, 6.7)
Reports from the Capacity Management Database are useful to many of the other Service Management processes, but especially so to Service Level Management when reviewing Service Levels and to Incident and Problem Management when investigating and diagnosing Incidents and Problems (SD 6.3.5)
It is necessary to review the Capacity Management Database to ensure the data collected is at the appropriate level and for the appropriate values so that the monitoring is not wasting resources and not missing data vital to the Incident and Problem Management processes (SD 6.6)
Incident Management must inform Capacity Management regarding all Incidents related to capacity or performance (SD 6.7.1)
Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)

Incident Management with IT Service Continuity Management
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)

Incident Management with Availability Management
A history of prior Incidents and Problems is used in Availability planning to assess component failures
Availability Management is dependent upon the maturity of Incident, Problem and Change Management
It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)
Service Desk and Incident Management handling of an Incident can significantly impact how this Incident affects
Availability (processes, notifications, escalations, diagnostics, detection) (SD 8.5.4)
Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)
The Incident should only be closed when the Users have verified that Service has been restored (SD 8.5.4)
Incident and Problem Management should provide input into the Availability reports to highlight Problem “black spots” and areas for increased preventative maintenance (SD 8.7.7)
Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)
Available Management can use the Expanded Incident Life Cycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

Problem Management with Configuration Management
Problem Management utilizes the Configuration Management Database to identify details about the Incidents and Problems
It is sometimes necessary to create dummy Configuration Items to allow tracking of Problems
All support documentation must be made available to the Problem Management team
Problem Management should use the contact information in the Configuration Management Database to determine who needs to know about a work-around or resolution
Provide an accurate representation of the infrastructure to support other ITIL processes
Configuration Management must be able to report on all Configuration Items impacted by an Incident or a Problem
Problem Management uses the Configuration Management Database during trend analysis
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
The Configuration Management Database is used to link Incidents, Problems and other records to the Configuration Items and the Users (2.6)

Problem Management with Change Management
Request for Change is submitted in order to implement a resolution
Problem Management should examine records of recent changes to see if those changes contributed to the Problem
Problem Management should advise Change Management as to the urgency of the Problem and can escalate if the Problem becomes more critical
Requests for Change can encompass processes as well as hardware and software
Problem Management only leads to a change when there is “a state different from a previously defined condition”
Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management

Problem Management with Release Management
Problem Management records should trace from Incident to Problem to Known Error to Request for Change to Release and change implementation
A Release is typically designed to resolve problems and enhance services
An Emergency Fix generally resolves a small number of Problems
A Minor Release generally supersedes by inclusion prior Emergency Fixes as well as incorporating a few enhancements
A Major Release often includes enhancements that make prior Problem fixes redundant
A Package Release bundles multiple Releases, often from different applications, together into one Release
Procedures need to be defined for Problem escalation as related to the Release process
Once the Release is successful, Problems and enhancement requests resolved by the Release should be closed
Problems caused by the Release should be linked to the Release
Problem Management and Service Desk personnel must be trained to use and support the new Release
Release procedures may be an integral part of Incident and Problem Management (2.7)

Problem Management with Service Level Management
Problem Management needs to be aware of the impact that Problems are having on Service Levels
Problems reported to vendors need to be monitored to insure that the vendor responds in a reasonable time or within the time defined in the Underpinning Contract when defined there
Problem resolution needs to be measured against the Service Level Agreements
Problem identification and resolution is easier when Service Level Management has built a strong relationship between IT and the IT Customers
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
Recent Incidents and long-standing Problems often cloud the negotiation on Service Level Agreements
It is best to pilot the Service Level Agreements with a Customer group that has a small number of Problems
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer’s perception of Availability
The Service Level Agreements related to Incidents and Problems must be clearly visible in the Service Desk tool to facilitate communication, monitoring and escalation
The Customer’s perception of response time should be recorded and Problem Management should investigate repetitions
Service Review meetings should be held monthly, or at least quarterly to review the results and initiate a Service Improvement Program if warranted

Problem Management with Financial Management
Resolutions need to be cost effective
Some Problems do not justify the expenditure required for resolution
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
Financial Management should conduct periodic audits to ensure that the Change and Problem Management processes are strictly followed (SD 5.7.11)

Problem Management with Capacity Management
Capacity Management should be the “focal point” for all performance and capacity Problems (SD 6.1.1, 6.1.3)
The history of Incidents and Problems is a key input into Capacity planning (SD 6.2)
Proactive Changes and Service Improvements are key outputs from Capacity Planning (SD 6.2)
Capacity Management should preempt performance Problems (SD 6.2)
Other Service Management processes can refer Incidents and Problems to Service Capacity Management when there is a breach or a risk of a breach against a Service Level Agreement. Service Capacity Management will then refer those Incidents or Problems to Resource Capacity Management (2.3, SD 6.2.2, 6.2.3)
Service and Resource Capacity Management must be proactive, anticipate the impact that Changes will have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3)
Reports from the Capacity Management Database are useful to many of the other Service Management processes, but especially so to Service Level Management when reviewing Service Levels and to Incident and Problem Management when investigating and diagnosing Incidents and Problems (SD 6.3.5)
Capacity Management should reduce the number of urgent Changes and reduce the risk of Problems (SD 6.4.2)
It is necessary to review the Capacity Management Database to ensure the data collected is at the appropriate level and for the appropriate values so that the monitoring is not wasting resources and not missing data vital to the Incident and Problem Management processes (SD 6.6)
Capacity Management works with Problem Management to give Incident Management diagnostic tools, automated alerting and updates to Known Errors (SD 6.7.1)
Problem Management expertise may be called on to assist in resolving Problems related to capacity or performance (SD 6.7.2)
The Capacity Management Database needs to be linked into the Configuration Management Database to assist Service Management in assessing proposed Service Level Agreements and Problem Management in diagnosing Problems (SD 6.7.5)
Slow performance and capacity Problems can result in Unavailability of the Service to the users (SD 6.7.9)

Problem Management with IT Service Continuity Management
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
Criteria need to be established in advance as to when an Incident or Problem will be escalated to Service Continuity Management (SD 7.3.5)

Problem Management with Availability Management
Much of Availability Managements work is in the detection and avoidance of Problems
Fragility of components
Problem Management needs to work closely with Availability Management to identify trends and instigate remedial action (2.9)
A history of prior Incidents and Problems is used in Availability planning to assess component failures
Availability Management is dependent upon the maturity of Incident, Problem and Change Management
It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)
Diagnostic tools can help Problem Management resolve faster (SD 8.5.4)
Scheduling multiple Changes within one downtime can increase Availability, but it has the risks of increased complexity in Release Management and increased complexity for Problem Management when something goes wrong (SD 8.5.6)
Incident and Problem Management should provide input into the Availability reports to highlight Problem “black spots” and areas for increased preventative maintenance (SD 8.7.7)
Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)
Available Management can use the Expanded Incident Life Cycle and work closely with Incident and Problem Management to insure that failures are not repeated (SD 8.9.9)

Configuration Management with Change Management
Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)
Verify that no Configuration Items are modified without going through the Change Management process
Configuration Management works together with Change Management and Release Management to deploy new and updated deliverables
Policies should be jointly developed by Configuration Management, Change Management and Release Management
Configuration Management is responsible for assessing the impact from proposed changes (2.6)
Configuration Management needs to document the history of changes for each Configuration Item
Configuration Management is responsible for verifying that the environment is compatible with the proposed change
New builds should be verified against the specifications and documented as an “as-built” configuration
Audits should be conducted by Configuration Management to insure that all changes have gone through the proper process
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (2.6, 3.2)
It is best practice to implement Change and Configuration Management at the same time
Configuration Management is responsible for assessing the impact from proposed changes
Configuration Management needs to document the history of changes for each Configuration Item
The manager of the Configuration process can also manage the Change process
Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management
Change Management depends upon the accuracy of the configuration data to ensure the full impact of making Changes is known (2.7)

Configuration Management with Release Management
Provide an accurate representation of the infrastructure to support other ITIL processes
Configuration Management works together with Change Management and Release Management to deploy new and updated deliverables
Policies should be jointly developed by Configuration Management, Change Management and Release Management
Release Management is responsible for populating the Definitive Software Library
Release Management must insure that all changes are reflected in the Configuration Management Database
Details about the build process and build environment should be recorded when a build is moved into the Definitive Software Library
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
Release Management is dependent upon the success of Configuration Management (2.6)
Release Management is to insure that the required software, hardware, documentation, etc are properly archived (DSL, DHS, etc) and that only authorized versions are installed
Release Management coordinates all Changes with Configuration Management and Change Management (2.8)
Release Management works with Configuration Management and Change Management to insure that the Configuration Management Database is accurately maintained (2.7)
Release Management should work to update the Configuration Management Database during the build cycle in anticipation of the release
When a Release is managed in phases, the Configuration Management Database should use a unique identifier to link the individual releases into one Release
The Definitive Software Library must be protected from unauthorized change
All additions to the Definitive Software Library must have corresponding entries in the Configuration Management Database
The Configuration Management Database should designate where the Release is to be applied
The Configuration Management Database should be updated with status to indicate receipt of the media, etc.
The detail description on how to build the Release should be a Configuration Item
The detailed description of the test environment should be a Configuration Item
The process for disposing of retired assets must be documented
Configuration Management should ensure that all pre-requisites have been met
Configuration Management should ensure that the Release has been successfully applied to all designated locations
Configuration Management and Release Management can work as one organization or can be combined with Change Management
Minimizing the number of variants will make Release Management easier
Ideally the users should be able to quickly determine the version of every component on their desktop from one screen

Configuration Management with Service Level Management
Provide an accurate representation of the infrastructure to support other ITIL processes (2.6)
Service Level Management can use the Configuration Management Database to house details about the services and link those services to Configuration Items
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
The Service Catalog can be stored as Configuration Items in the Configuration Management Database
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer’s perception of Availability
Changes to a Service Level Agreement must be reflected in the Service Catalog
Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements

Configuration Management with Financial Management
Configuration Management is responsible for verifying receipt of new Configuration Items
The Configuration Management Database describes the corporate assets
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
Financial Management needs to know the components utilized by each business unit especially when Charging is in place (2.6)
Financial Management works with Capacity, Configuration and Service Level Management to estimate the costs for the desired Capacity (2.2, SD 5.1.5)
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Cost is an attribute of a Configuration Item (SD 5.1.5)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and Service Level Management (SD 5.5.9)
Financial Management should conduct periodic audits to ensure that the interfaces into Configuration, Capacity and
Service Level Management are working and provide the necessary workload information (SD 5.7.11)
Financial Management should work with Configuration Management to ensure that the Configuration Items are up-to-date and accurate (SD 5.7.11)

Configuration Management with Capacity Management
Provide an accurate representation of the infrastructure to support other ITIL processes
The Capacity Plan and other Service Management Plans should be identified in the Configuration Management Database
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
Capacity Management should work with Change, Configuration and Release Management to create and implement
Requests for Change to ensure that appropriate Capacity is available (2.3)
The performance requirements for a Service should be recorded as Configuration Items (SD 6.2.1)
The capacity and configuration of Configuration Items should be accessible from both the Capacity Management Database and the Configuration Management Database (SD 6.2.1)
The Capacity Management and Configuration Management Databases can be merged into one database (SD 6.2.1)
Capacity Management monitoring is linked through the Configuration Management Database to Changes both to predict the probable impact and to asses the actual impact (SD 6.3.2)
The Capacity Management Database needs to be linked into the Configuration Management Database to assist Service Management in assessing proposed Service Level Agreements and Problem Management in diagnosing Problems (SD 6.7.5)

Configuration Management with IT Service Continuity Management
Provide an accurate representation of the infrastructure to support other ITIL processes
The definition of the Configuration Items and the copies in the Definitive Software Library can be used during disaster recovery
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
Service Continuity and Availability Management rely on the Configuration Management Database to identify components to perform risk analysis and component failure impact analysis (2.6)
Configuration Management should verify that the restored configuration matches the prior configuration
A successful Service Continuity program is dependent upon rigorous Configuration and Change Management processes (SD 7.1.4)
Service Continuity is dependent upon Configuration Management for the definition of the core infrastructure (SD 7.1.8)
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
Recovery planning requires an in-depth understanding of the relationships between the components in the infrastructure (SD 7.3.3)

Configuration Management with Availability Management
All of the ITIL processes should be entered into the Configuration Management Database as Configuration Items and subject to Change Management (3.2)
Configuration and monitoring data on each component is used in Availability planning
The Configuration Management Database serves Availability Management through definitions of the configuration and by recording Incidents, Problems and Requests for Change (SD 8.8.2)

Change Management with Release Management
Change Management authorizes the change while Release Management implements the change
Groups of concurrent changes should be bundled into a Release
Pre-defined “standard” changes do not need to go back to the Change Advisory Board as the process is pre-approved
Effective Change Management relies on the Service Desk and Configuration, Problem and Release Management
Release Management works with Change Management to agree to the contents of each Release
Release Management coordinates all Changes with Configuration Management and Change Management (2.8)
Release Management works with Configuration Management and Change Management to insure that the Configuration Management Database is accurately maintained
A Release is defined by the Requests for Change that are resolved in it Change Management should ensure there is User Acceptance of the build before it is released
The policies and procedures also need to be under Change Management
The organizations Release policies is normally incorporated into the Change Management plan
Updates to the environment, such as the addition of new hardware, operating systems or languages, often require changes to the release policy
Standard processes can be pre-authorized such as a process for the installation of specific software onto desktops
The detailed Release plan should be included in the Change Management plan
The status of the release should be tracked through Change Management, including failures
The status on the Request for Change and the status on the Release should be tracked through the same tool
Require users to go through a Change Management process to add any software to their desktops

Change Management with Service Level Management
Service Level Management can initiate a Request for Change based upon feedback from a customer
The Service Level Manager should be on the Change Advisory Board
Availability, Capacity, Continuity and Service Level Management should evaluate the probably impact from each Change
A properly implemented Change Management process will have a positive impact on Service Level compliance
The customer needs to be included in the process, as appropriate
The Change Management process should be documented in the Service Level Agreements so that Users know the procedure for requesting a Change, the projected target time and the impact of implementing a Change (2.7)
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
The Change Management (and Release Management) tracking tool must support whatever tracking is agreed to in the Service Level Agreement
The Service Level Agreements must be subject to a Change Management policy
Changes to a Service Level Agreement must be reflected in the Service Catalog
Operational Level Agreements and Underpinning Contracts must be managed through a Change Management process and reviewed at least annually
The Service Level Agreement can include targets for implementing Requests for Change
Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements
Service Level Management is responsible for assessing the impact of Changes on service quality and Service Level Agreements both before the Change and after (2.1)

Change Management with Financial Management
Each Change must be reviewed to ensure the Change is within the budget or that the Change can be justified through benefit/cost analysis
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Most business separate core services from optional services and charge separately for Changes, except where those Changes are part of the process of meeting the Service Level Agreements (SD 5.4.3)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and Service Level Management (SD 5.5.9)
Financial Management should attend the meetings of the Change Advisory Board and process all Changes to the Financial Management Process through the Change Management process (SD 5.7.1)
Changes to the infrastructure and Services must be processed through Change Management and may require Changes to the Financial Management processes (Accounting and Charging) and to the Service Level Agreements (SD 5.7.2)
Financial Management should conduct periodic audits to ensure that the Change and Problem Management processes are strictly followed (SD 5.7.11)

Change Management with Capacity Management
Capacity Management identifies and recommends changes to meet the business needs
Improvement in Availability or Capacity need to go through Change Management
Capacity Management can assist by building a model of the proposed change to study the impact on the infrastructure
Availability, Capacity, Continuity and Service Level Management should evaluate the probably impact from each Change
Capacity Management assists Change Management by assessing the impact a Change will have on Capacity requirements (SD 6.1.1, 6.2)
Change Management needs to feed Capacity Management the Forward Schedule of Changes (SD 6.2)
Proactive Changes and Service Improvements are key outputs from Capacity Planning (SD 6.2)
Capacity Management needs to work through Change Management when a Change will require Changes to insure sufficient Capacity (2.3, SD 6.2, 6.7.3)
Capacity Management may recommend Changes to take advantage of new technology, in response to the retirement of components or Services, in response to Changes or in response to business needs (SD 6.2.1)
Capacity Management should have a representative member on the Change Advisory Board (SD 6.2.1, 6.7.3)
Service and Resource Capacity Management must be proactive, anticipate the impact that Changes will have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3)
Resource Capacity Management should evaluate technology updates and recommend cost effective Changes (SD 6.2.3)
Capacity Management monitoring is linked through the Configuration Management Database to Changes both to predict the probable impact and to asses the actual impact (SD 6.3.2)
Once Capacity Management identifies tuning opportunities, those recommendation must be processed through Change Management (SD 6.3.4, 6.5.3, 6.7.3)
Capacity Management is responsible for “application sizing” to estimate the resources required for a new application and works with Application Management to plan for resiliency (SD 6.3.8)
Capacity Management should have representation on the Change Advisory Board to asses the risk in Changes and thus preclude Problems (SD 6.4.2)
Capacity Management should reduce the number of urgent Changes and reduce the risk of Problems (SD 6.4.2)
The Capacity Management Database must be encompassed within a Change Management policy (SD 6.5.2)
Implementation and updates to the monitoring for Capacity Management must be managed through Change Management (SD 6.5.3)
Changes recommended by Capacity Management must be cost justifiable (SD 6.7.7)
The Service Continuity aspects of Changes to Capacity must be assessed by Capacity Management so that IT Service Continuity Management can evaluate updates to the continuity planning (SD 6.7.8)
Resiliency improvements must be assessed for their impact on Capacity, while Capacity improvements must be assessed for their impact on Availability (SD 6.7.9)

Change Management with IT Service Continuity Management
Change has the potential to impact continuity
Availability, Capacity, Continuity and Service Level Management should evaluate the probably impact from each Change
A successful Service Continuity program is dependent upon rigorous Configuration and Change Management processes (SD 7.1.4, 7.6)
Change Management processes must be used to ensure the currency and accuracy of the Continuity Plan through established processes and regular reviews (SD 7.1.8, 7.3.4)
Service Continuity is not focused on long term risks such as competitive pressures. Those types of risks must be managed through business strategy and worked through an on-going Change Management process (SD 7.2.2)
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
Resiliency improvements must go through the Change Management process (SD 7.3.2)
Change Management is a risk reduction activity (SD 7.3.2)
Each Change must be assessed for the effect it may have on Service Continuity plans, and those plans may need to be revised and retested (SD 7.4.1)

Change Management with Availability Management
Change has the potential to impact continuity
Improvement in Availability or Capacity need to go through Change Management
Availability, Capacity, Continuity and Service Level Management should evaluate the probably impact from each Change
Each Change should be evaluated for security implications
Availability Management will give Change Management guidance on the agreed maintenance schedule
Change Management should give Availability Management the Forward Schedule of Changes
Availability Management is dependent upon the maturity of Incident, Problem and Change Management
Planning for Availability early in the design will avoid the expense of making Changes later in the project (SD 8.4.1)
It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)
Every component should have a designated maintenance strategy (planned downtime) incorporated into the service agreements (SD 8.5.6)
Scheduling multiple Changes within one downtime can increase Availability, but it has the risks of increased complexity in Release Management and increased complexity for Problem Management when something goes wrong (SD 8.5.6)
The time allotted for a Change (preparation, implementation, verification) should be defined as a Service Maintenance Objective (SD 8.5.6)
Change Management should report on the impact from poor planning and the number of Changes that have overrun the Service Maintenance Objective (SD 8.7.7)
Service Desk, Change and Problem Management should provide data on downtimes (planned and unplanned), but this should be augmented by automated monitoring (SD 8.8.1)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)

Release Management with Service Level Management
A Release can be a change in procedures or agreements and is not limited to hardware and software deployments
Policies must be defined on how to deal with failures
Policies must be defined to describe the Service Level impact when a Release applied to one component impacts a Service that is dependent on that component
Service Levels must be considered with each Release, especially if new hardware or software is to be acquired
A Release may require the re-negotiation of vendor support contracts
It is best to link the Incident Records, Problem Records, Requests for Change, etc. to defined Services
The Change Management (and Release Management) tracking tool must support whatever tracking is agreed to in the Service Level Agreement
Planning for a new Service should include the Service Desk, Change, Configuration and Release Management to verify resource and training requirements

Release Management with Financial Management
The release may require acquisition of resources
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)

Release Management with Capacity Management
It is necessary to plan for the growth of the Definitive Software Library
Must insure there is sufficient space in both the build, test, distribution and live environments for the release
Release Management needs guidance from Capacity Management both when planning how to deploy a Release and immediately prior to executing the Release to avoid impacting the capacity of disk space, network bandwidth, etc. (SD 6.7.4)
Capacity Management should work with Change, Configuration and Release Management to create and implement Requests for Change to ensure that appropriate Capacity is available (2.3)

Release Management with IT Service Continuity Management
It is important that the Definitive Software Library be protected so that it can be available for recovery
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)

Release Management with Availability Management
The Security implications must be evaluated with each Release
The integrity of the update must be ensured whether transmitted through media or over a network
The integrity of the Definitive Software Library must be maintained
It might be necessary to improve upon the Incident, Problem, Change and Release Management processes to achieve higher levels of Availability (SD 8.5.3)
Every component should have a designated maintenance strategy (planned downtime) incorporated into the service agreements (SD 8.5.6)
Scheduling multiple Changes within one downtime can increase Availability, but it has the risks of increased complexity in Release Management and increased complexity for Problem Management when something goes wrong (SD 8.5.6)
The time allotted for a Change (preparation, implementation, verification) should be defined as a Service Maintenance Objective (SD 8.5.6)

Service Level Management with Financial Management
Service Level Agreements form a foundation for Charging
Charging will help control the Customer’s expectations
When Charging is not in place, senior management must assist in managing the Customer’s expectations
Insure the service vendors can support the Service Level Agreements
Charging arrangements and penalties should be described in the Service Level Agreement
Financial Management works with Capacity, Configuration and Service Level Management to estimate the costs for the desired Capacity (2.2, SD 5.1.5)
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
The Manager of Financial Management may be the same person as the Manager of Service Level Management (SD 5.1.2, 5.5.7)
Current best practice for Charging is to charge a fixed amount for an agreed Capacity, determined by the service agreed in the Service Level Agreement (SD 5.1.2)
Financial Management must work closely with Service Level Management to determine the cost of the services as an input into the development of the Service Level Agreements and Charging structure (SD 5.1.5)
The more flexibility there is in the Service Level Agreement, the more flexibility there will be in Charging -- but the complexity of each adds an overhead to those Processes (SD 5.1.5)
Charging can help regulate the Customers usage, but it also entitles the Customer to influence the decisions about the Services (SD 5.1.6)
It is important to do a Workload estimate and forecast when preparing a Budget. Such estimates and forecasts are also required for the preparation of Service Level Agreements and for Capacity Management (SD 5.2.3, 5.5.4)
Service Level Agreements must be in place and be representative of actual service before implementing Charging (SD 5.4.2)
To be market competitive, the infrastructure resources must be properly managed, costs well controlled and service delivered according to expectations (SD 5.4.2)
Most business separate core services from optional services and charge separately for Changes, except where those Changes are part of the process of meeting the Service Level Agreements (SD 5.4.3)
The Customer needs forecasted pricing to help in establishing their Service Level Requirements (SD 5.4.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and Service Level Management (SD 5.5.9)
Changes to the infrastructure and Services must be processed through Change Management and may require Changes to the Financial Management processes (Accounting and Charging) and to the Service Level Agreements (SD 5.7.2)
Service Level Agreements must include statements about what to do if the Customers workload changes above or below threshold levels (SD 5.7.5)
Change to Services and to Service Levels should be handled by Service Level Management and must incorporate the impact to Financial Management (SD 5.7.8)
Financial Management should conduct periodic audits to ensure that the interfaces into Configuration, Capacity and
Service Level Management are working and provide the necessary workload information (SD 5.7.11)
Audits of Financial, Capacity and Service Level Management should be synchronized and conducted every quarter initially and every six months subsequently (SD 5.7.11)

Service Level Management with Capacity Management
The Service Catalog should be the starting place for a Business Impact Analysis, Workload Analysis or Capacity Management evaluation
Verify that the Service Level Agreements are achievable before agreeing
Insure that every item in the Service Level Agreement can actually be monitored accurately
The Capacity Plan should identify how the service provider plans to comply with the Service Level Agreements (SD 6.1, 6.2.3)
Service Level Agreements, Service Level Requirements, Service Level breaches and the Service Catalog are key inputs into Capacity Planning (SD 6.2)
Recommendations on Service Level Agreements and Service Level Requirements are outputs from Capacity planning (SD 6.2)
Proactive Changes and Service Improvements are key outputs from Capacity Planning (SD 6.2)
Capacity Management is responsible for ensuring that all metrics identified in the Service Level Agreements are monitored, evaluated and reported, and together with Resource Capacity Planning, identifying appropriate actions to correct any deficiencies (SD 6.2, 6.7.6)
Capacity Management is responsible for implementing Changes in order to prevent Service Level breaches (SD 6.2)
Capacity Management is responsible for insuring that the Service Level metrics are measurable and achievable (SD 6.2.1)
The primary focus of Service Capacity Management is on managing service performance to ensure it achieves the targets in the Service Level Agreements and Service Level Requirements (SD 6.2.2)
Service Capacity Management informs Service Level Management of breaches or near-misses against the Service Level Agreements (SD 6.2.2, 6.6)
Other Service Management processes can refer Incidents and Problems to Service Capacity Management when there is a breach or a risk of a breach against a Service Level Agreement. Service Capacity Management will then refer those Incidents or Problems to Resource Capacity Management (SD 6.2.2, 6.2.3)
Service and Resource Capacity Management must be proactive, anticipate the impact that Changes will have on the infrastructure and take action to preclude Problems (SD 6.2.2, 6.2.3, 6.7.6)
Resource Capacity Management should evaluate technology updates and recommend cost effective Changes (SD 6.2.3)
The monitoring performed by Resource Capacity Management must support the metrics required by Availability
Management for Service Level Agreement verification (SD 6.3.1)
The monitoring data should be used to identify the baseline and to identify trends both to identify Service Level
Agreement breaches and near misses and also to predict future resource usage and predict business growth patterns (SD 6.3.2)
The Capacity Management Database should house all of the metrics required to support Service Level compliance as well as the thresholds established for the Service Level Agreements and Service Level Requirements (SD 6.3.5, 6.5.2)
Reports from the Capacity Management Database are useful to many of the other Service Management processes, but especially so to Service Level Management when reviewing Service Levels and to Incident and Problem Management when investigating and diagnosing Incidents and Problems (SD 6.3.5)
Planning for Capacity Management should include a review of the as-is and requirements from the other Service Management areas especially Service Level, Availability and Financial Management (SD 6.5.1)
Capacity Planning should be worked in conjunction with planning for the other Service Management processes, especially Service and Availability Management (SD 6.5.2)
The Capacity Management Database needs to be linked into the Configuration Management Database to assist Service Management in assessing proposed Service Level Agreements and Problem Management in diagnosing Problems (SD 6.7.5)
Capacity Management should assist Service Level Management with Operational Level Agreements (and Underpinning Contracts) as well as Service Level Agreements (SD 6.7.6)
Capacity Management should work with Service Level Management when there is a Service Improvement Program to address a weak area (SD 6.7.6)

Service Level Management with IT Service Continuity Management
The Service Catalog should be the starting place for a Business Impact Analysis, Workload Analysis or Capacity Management evaluation
Service Continuity must work with Service Level Management to ensure there is a clear understanding of the obligations of IT Service Delivery (SD 7.1.8)
Service Continuity, Implementation Planning must evaluate each Service Level Agreement to determine which will remain in effect in the event of a disaster and what the business implications are for failing to meet that SLA during the recovery (SD 7.3.3)

Service Level Management with Availability Management
The Service Catalog should be the starting place for a Business Impact Analysis, Workload Analysis or Capacity Management evaluation
Verify that the Service Level Agreements are achievable before agreeing
Insure that every item in the Service Level Agreement can actually be monitored accurately
Many organizations use their Service Desk linked to a comprehensive Configuration Management Database to monitor the Customer’s perception of Availability
Service Review meetings should be held monthly, or at least quarterly to review the results and initiate a Service Improvement Program if warranted
It is better to include Unavailability measures than Availability measures in the Service Level Agreement
Some of the most important targets set in the Service Level Agreements relate to service Availability and thus require Incident resolution within agreed periods (2.1)
All new Service Level Requirements, Service Level Agreements, Operational Level Agreements and Underpinning Contracts should consider Availability (SD 8.? and 8.5.3)
Low rate of failure and rapid resumption of service after an Incident are keys to consistently meeting the Service Level Agreements on Availability
Availability Management provides guidance on the achievable Availability level to Service Level Management for new Services and for changes (SD 8.? And 8.5.1)
Service Level Management feeds Availability Management the Service Level Agreements so that Availability Management can implement monitoring and reporting
Regular reviews conducted by Service Level Management should also consider the current level of Availability (SD 8.4.1)
The Service Level Management reports can describe the cost of Unavailability as number of users, number of transactions, or preferably as the cost of the Unavailability (SD 8.4.2)
It is important that the Service Level Agreement clearly define the meaning of Availability (SD 8.5.1)
Service Level Management communicates with the business and represents Availability Management (SD 8.5.1)
Every component should have a designated maintenance strategy (planned downtime) incorporated into the service agreements (SD 8.5.6)
Service Level Management provides input into the Availability Plan regarding future business needs (SD 8.6.3)
A Service Improvement Program is an output from Service Management and it is a project focused on IT quality while an Availability Plan is a long term plan but it is focused on Availability (SD 8.6.3)
Service Desk, Incident, Problem, Change and Service Level Management provide inputs into a Service Outage Analysis (SD 8.9.8)

Financial Management with Capacity Management
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
IT Accounting can be used to determine the exact costs of resource usage down to CPU, file store and bandwidth but it is rarely advisable to use this as the basis for Charging as the costs of so doing may outweigh the benefits (SD 5.1.2)
Current best practice for Charging is to charge a fixed amount for an agreed Capacity, determined by the service agreed in the Service Level Agreement (SD 5.1.2)
Financial Management works with Capacity, Configuration and Service Level Management to estimate the costs for the desired Capacity (2.2, SD 5.1.5)
It is important to do a Workload estimate and forecast when preparing a Budget. Such estimates and forecasts are also required for the preparation of Service Level Agreements and for Capacity Management (SD 5.2.3, 5.3.11, 5.3.14, 5.5.4)
It is best to calculate the Standard Rates and leave them in place for a year, or until the discrepancy exceeds some threshold, and absorb Changes during the year (SD 5.3.11)
Charging can be used to assist with Demand Management (SD 5.4.2)
To be market competitive, the infrastructure resources must be properly managed, costs well controlled and service delivered according to expectations (SD 5.4.2)
Most business separate core services from optional services and charge separately for Changes, except where those Changes are part of the process of meeting the Service Level Agreements (SD 5.4.3)
Senior manager must be prepared to specify what they require from the systems and how these systems should interface with other systems in the organization (e.g. Capacity Management) (SD 5.5.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
The IT Accounting group must be trained on the fundamentals of Capacity, Change, Configuration and Service Level Management (SD 5.5.9)
Service Level Agreements must include statements about what to do if the Customers workload changes above or below threshold levels (SD 5.7.5)
Financial Management should conduct periodic audits to ensure that the interfaces into Configuration, Capacity and Service Level Management are working and provide the necessary workload information (SD 5.7.11)
Audits of Financial, Capacity and Service Level Management should be synchronized and conducted every quarter initially and every six months subsequently (SD 5.7.11)
Capacity Management should work with Financial Management to assist in influencing future demand (SD 6.1)
Capacity Management should work with Financial Management to aggregate the corporate need into purchasing leverage, improve long range planning and phase the purchasing (SD 6.1.1)
Costing and Charging recommendations are key outputs from Capacity Planning (SD 6.2)
Business Capacity Planning is responsible for forecasting future business needs (SD 6.2)
Capacity Management is responsible for implementing Changes in order to prevent Service Level breaches (SD 6.2)
Capacity Planning requires financial data to accurately plan the cost of proposed upgrades (SD 6.3.5)
Demand Management can use Charging to influence usage patterns (e.g., time of day) or curtain excessive usage, but this must be managed carefully to avoid antagonizing the users (SD 6.3.6, 6.6, 6.7.7)
Proper Capacity Planning will help preclude unwarranted expenditures and assist in deferring required purchases until shortly before they are needed (SD 6.4.2)
Capacity Management monitoring must itself be cost justifiable (SD 6.4.3)
Planning for Capacity Management should include a review of the as-is and requirements from the other Service Management areas especially Service Level, Availability and Financial Management (SD 6.5.1)
Financial data, such as the cost of devices, should be extracted into the Capacity Management Database to support modeling and planning (SD 6.5.2)
Changes recommended by Capacity Management must be cost justifiable (SD 6.7.7)

Financial Management with IT Service Continuity Management
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
IT Accounting must be planned for in the Service Continuity Plan. Either IT Accounting can be dropped during the recovery period, or IT Accounting must be tested as part of the Disaster Recovery testing (SD 5.6.5)
Individual contingency plans for aspects of the infrastructure need to be unified and focused on the critical business functions to ensure that the available budget is applied in the most appropriate way (SD 7.3.1)
The recovery options chosen must balance the potential impact against the cost of the recovery (SD 7.3.2)
The balance between expenditures on resiliency and those on a comprehensive fail over strategy depends upon how much impact can be caused by a short term disruption (SD 7.3.2)
The benefits and costs of each recovery option must be evaluated (SD 7.3.2)
Insurance is important to Service Continuity (SD 7.3.2)

Financial Management with Availability Management
Financial Management assists the other ITIL Processes in assessing the cost-effectiveness of decisions (SD 5.1.6)
Service Desk and integrated Service Management processes are likely to be able o provide data to be input to cost calculation (SD 5.5.8)
Availability Management gives Financial Management data on the cost of Unavailability
Financial Management provides Availability Management with the costs for propose upgrades (SD ? And 8.6.3)
Higher Availability requirements will cost more and must be cost justifiable (SD 8.4.1, 8.6.1)
Planning for Availability early in the design will avoid the expense of making Changes later in the project (SD 8.4.1)
Financial Management can use profit/cost models to assist in quantifying the cost of Unavailability (SD 8.7.7)

Capacity Management with IT Service Continuity Management
Capacity Management should work with Service Continuity to assess the capacity requirements for the Vital Business Functions (SD 6.1.1, 6.7.8)
The Service Continuity aspects of Changes to Capacity must be assessed by Capacity Management so that IT Service Continuity Management can evaluate updates to the continuity planning (SD 6.7.8)
Service Continuity must work with Capacity Management to ensure that business requirements are fully supported through appropriate IT hardware resources (SD 7.1.8)

Capacity Management with Availability Management
Resource Capacity Management works with Availability Management to assess and improve the resiliency of the infrastructure (SD 6.2.3)
The monitoring performed by Resource Capacity Management must support the metrics required by Availability Management for Service Level Agreement verification (SD 6.3.1)
The monitoring data should be used to identify the baseline and to identify trends both to identify Service Level Agreement breaches and near misses and also to predict future resource usage and predict business growth patterns (SD 6.3.2)
The Capacity Management Database should house all of the metrics required to support Service Level compliance as well as the thresholds established for the Service Level Agreements and Service Level Requirements (SD 6.3.5)
Capacity Management is responsible for “application sizing” to estimate the resources required for a new application and works with Application Management to plan for resiliency (SD 6.3.8)
Planning for Capacity Management should include a review of the as-is and requirements from the other Service Management areas especially Service Level, Availability and Financial Management (SD 6.5.1)
Capacity Planning should be worked in conjunction with planning for the other Service Management processes, especially Service and Availability Management (SD 6.5.2)
Slow performance and capacity Problems can result in Unavailability of the Service to the users (SD 6.7.9)
Resiliency improvements must be assessed for their impact on Capacity, while Capacity improvements must be assessed for their impact on Availability (SD 6.7.9)
A history of prior Incidents and Problems is used in Availability planning to assess component failures
Configuration and monitoring data on each component is used in Availability planning
Availability Management should complete a Component Failure Impact Assessment to help Capacity Management plan resiliency for new Services or components
Capacity Management should give Availability Management the details regarding how resiliency will be achieved
Capacity Management provides input into the Availability Plan regarding scenarios for changing the infrastructure
The Availability Plan and Capacity Plan are complementary and should be aligned with the budget cycle (SD 8.6.3)
Capacity Management may provide reports such as Response Time analysis to augment the Availability metrics and highlight Capacity issues (SD 8.7.6)
The Capacity Management Database serves Availability Management by housing performance data and by providing input into planning (SD 8.8.2)

IT Service Continuity Management with Availability Management
Service Continuity works with Availability Management on resiliency and other risk reduction measures (SD 7.1.4, 7.1.8, 7.3.3)
Service Continuity is not focused minor technical faults unless that fault can cause a major impact on the business.
Those risks are to be worked through Incident and Problem Management, addressed through Availability and Problem Management and resolved through Change and Configuration (and Release) Management (SD 7.2.2)
The Service Continuity process is often managed under the department responsible for Security (SD 7.2.3)
Individual contingency plans for aspects of the infrastructure need to be unified and focused on the critical business functions to ensure that the available budget is applied in the most appropriate way (SD 7.3.1)
BSS 7799, the British Standard on Information Security Management, includes Service Continuity (SD 7.3.1)
The balance between expenditures on resiliency and those on a comprehensive fail over strategy depends upon how much impact can be caused by a short term disruption (SD 7.3.2)
Resiliency improvements must go through the Change Management process (SD 7.3.2)
Risk reduction measures must be evaluated for Security implications. For example, out sourcing may reduce the internal risk, but increase the exposure of confidential data to an outside party (SD 7.3.2)
Availability Management must work with Service Continuity to ensure the data can be recovered using mirroring, RAIDs, backups, off-site storage, etc. (SD 7.3.2, 7.5)
Availability Management is not responsible for Business Continuity Management, but the two processes have much in common
The Business Impact Analysis is a key input into Availability Management planning
Service Continuity works with Availability Management to determine which Services are Vital Business Functions
Service Continuity works with Availability Management to assess and improve resiliency
Service Continuity provides input into the Availability Plan regarding business impact and resiliency improvements (SD 8.6.3)
Service Continuity works with Availability Manage to balance between recovery options and risk reduction measures (SD 8.9.1)