The Service Desk (Function)

Overview
The service desk is the window of the IT community and as such should be viewed as the single
or central point of contact for all IT products and services. This course will answer the question
"Why do we need a Service Desk?"

The service desk will provide the user with a single point of contact.

A single point of contact provides the user with one number to call for all their IT service
concerns and issues.

The Service Desk will:

 Represent "IT" to the customer and the user

 Offer the ultimate in customer satisfaction
 Prioritize highest perception of quality to its customers
 Co-ordinate people, processes and technology to deliver business services

To deliver high quality support to achieve business goals

In order to be successful, the service desk must give the customer the highest quality of support
possible while staying within budget and delivering business goals directed by management.
This can be achieved through Service Level Management.

To aid in user retention and satisfaction

Good quality service will keep customers coming back for more! As mentioned earlier, positive
perception is key to the success of the Service Desk. When a customer's needs are met, there is
no need to look beyond the Service Desk. Satisfaction can be measured not only by the speed at
which the phone is answered but also by the level at which the organization understands their
customer's business and needs.

To improve the service but reduce the cost

This can be achieved by improving the response time to the customer. Time is money, and the
faster you can move forward with a customer's concern the more cost efficient the resolution will
be.

Collecting the vital information needed to resolve the customer's request the first time (that is,
via 1st level support) will also reduce the amount of time the customer and 2nd level support has
to wait. If wrong or insufficient information is collected at 1st level then 2nd level support has to
get back to the customer or Service Desk for data collection. The Service Desk is also
responsible for ensuring that the right 2nd level support group is working on the customer's
issue. Again, making efficient use of resources will reduce costs.

To highlight customer training and education needs.

As the single point of contact, Service Desk will understand the customer's needs. All requests
for both incidents and service are filtered through the Service Desk. The Service Desk will
identify trends that highlight a possible IT need, for example, training. The Service Desk will
also be aware of new technology that will be introduced to the business and will make
recommendations on training needs based on historical data from previous software or hardware
releases.

To close incidents and confirm customer satisfaction

Before closing records/tickets, the service desk will consult the customer, giving them the
authority to ensure that their problem was resolved to their satisfaction. This is an excellent way
of confirming satisfaction with the customer. This type of service is not very common and is
very well received by customers.

Contributing to problem identification

The Service Desk staff will have a combination of both superior technical and soft skills, which
will enable them to be more involved in the problem identification process. The Service Desk
will use both experience and a knowledge base to collect data for both a work-around and
resolution. Since it is the responsibility of the Problem Management Process to resolve problems,
the Service Desk can identify previous solutions to Problem Management. Tools play a vital
role in this area. A call tracking device or knowledge base can be considered a tool.

Roles and Responsibilities

The Service Desk is responsible for accepting and recording all calls, without exception. This
information, no matter how insignificant, will be vital for statistics. All calls are important - even
if they are wrong numbers. A large number of wrong numbers coming into the Service Desk may
identify a problem with the lines or trunks coming into the Service Desk.

It is the directive of the Service Desk that own the Incident Management Process to resolve as
many calls as possible at 1st level. World class 1st level resolution is set at 85%. This can be
achieved by close co-operation with 2nd level support. As calls are being forwarded to 2nd level
support for problem resolution, the Service Desk has to ensure that information regarding
resolution is placed in the call-tracking tool. This information can be used for similar calls
received in the future. If the skill set is adjusted to allow 1st level (Service Desk, Incident
Management) to resolve the issue then the % of resolution will go up. In any case the fact that
the information is being collected will reduce the waiting time for resolution to the customer and
the research and diagnosis for 2nd level support, resulting in a cost saving and efficient use of
resources.
The Service Desk is responsible for monitoring and escalating according to all SLAs. It is a
given that on all Service Level Agreements the Service Desk is highlighted as the point of
escalation. Close monitoring of all tickets being escalated will ensure that 2nd level support does
not miss their SLA targets to resolution.

The Service Desk will keep users informed on the status and progress of their requests.
Management of the customer's expectations and informing the customer of any status changes or
progress with their requests is vital to customer satisfaction. If close monitoring of requests is
adhered to, the customer's expectations will be exceeded. In addition to keeping customers
informed the Service Desk is responsible for closure and verification of every request.

Communication of planned and short-term outages will be done when information is gathered
from either the Change Advisory Board or Service Level Management. The Service Desk will
broadcast these messages to the users using whatever means are available at the time, be they
phone messages, e-mail, broad cast messages, bulletin boards, intranet, and so on.

Co-ordination of 2nd level and 3rd party support for all customers' needs is another
responsibility. The Service Desk owns all problems being escalated. They will ensure that the
right 2nd level group is handling the customer's request. They will also ensure that the proper 3rd
party vendor is involved and providing the service within the underpinning contract.

The Service Desk has the ability to inform management on all recommendations for service
improvements. Being the single point of contact, the Service Desk will have insight into or input
from customers' needs.

Benefits:

 Improved user service, perception, and satisfaction

 Increased user accessibility via SPOC (Single Point of Contact)
 Improved quality and faster response to user requests
 Improved team work and communications
 Management of infrastructure and control
 Reduced Cost (Efficient use of resources)

Exercises The Service Desk (Function)

You are the new ITIL process owner for the ABC COOKIE COMPANY. You are assigned to set
up a service desk.

How will you apply the benefits of the service desk to the ABC COOKIE COMPANY?

1. True or false? A call to the service desk to place an order for cookies is an incident?
2. True or false? The service desk makes recommendations on service improvements?
3. Which of the following are true?
 (A) The service desk has to give the highest quality of support possible within budget

(B) The service desk has to deliver business goals directed by management

A. Both A and B
B. Just A
C. Just B
D. None

Answers

1. Any call to the Service Desk is considered an incident (True)

2. The Service Desk does make recommendation for improvements (True)
3. Both A and B

Configuration Management

Why Configuration Management?

The responsibility for businesses to deliver quality IT services economically, efficiently and
effectively is what drives Configuration Management. Configuration Management is the need
to control IT assets and services.

Terms and Definitions

Open table as spreadsheet
Term

Definition
CI Configuration Item. Anything within IT that is decided
to be within scope and can be changed should be
considered a "CI". This could be hardware, software,
service level agreements, job descriptions, and so on.
CMDB Configuration Management Database. The CMDB
holds all detail and relationship information of all CIs
associated with the IT infrastructure.
SCOPE The activities of configuration management include
identification, control, Status accounting and auditing.
 In order to be able to do this, the company has to
decide what will be within scope of configuration
management. If the scope is too big then the CMDB
might have integrity issues. If the scope is too small
then the CMDB might be useless.

Configuration management, working with asset management, will ensure that all
configuration items (Software, Hardware and Documentation) are identified, recorded and
tracked. All ITIL processes rely on information supplied by Configuration Management. The
information that will be available is:

 CI history (from the point of being ordered to retired).

 Information on all assets (what type of equipment, attributes and location, and so on).
 Information on how much assets are available when a release is being planned.
 The relationship between assets (PCs connected to server for instance).
 Call tracking data used in incident, problem and change management.
 Information on suppliers that are related to either service or asset providers.
 Information on lease management on all assets.
 Information used for auditing company assets to ensure asset management numbers.
 Information for IT Business Continuity Management Process (Base Line).

Planning Configuration Management

Planning the Configuration Management database will need a great deal of input from all IT
departments. The size of the database will depend on the information that the IT departments
need to provide and where it is coming from. The question that will pop up will be "How big or
how small will this database be?".

If the database is too small the information contained in it won't be of much use. There will be an
inability to track down certain CIs or do any trending. If it has too much information it will too
cumbersome to maintain and will soon become riddled with integrity issues. No one will want to
maintain a large database. Also, the cost of managing a large database may outweigh its value. It
really all depends on the scope and the resources to manage it.

The pertinent information may be found in a number of different databases, which needs to be
assembled into one logical format within the incident control system. In the diagram below you
will see that the service desk has access to information from five different databases. Having
access to this information depends on the incident control system tool you are using.
Processes, procedures and activities have to be defined. Who will manage it? There is going to
be a need for processes and procedures that will clearly define accountability and authority for
managing the information. Only the Configuration Management Owner can authorize people
such as the Service Desk Analyst to update or change the Configuration Management Database.
The service desk would be the likely group to do this since they are in contact with between 5 to
10 percent of the employees of a company daily.

Planning the relationship processes between Configuration Management, Change Management

and Release Management as well as third-party vendors is important. Configuration Management
contains information on all CIs within the infrastructure. This information can help with Release
Rollouts, which are directed by Change Management.

For example, if your company decides to release Windows XP into your infrastructure there are
certain elements that need to be considered:

 How many licenses do we need?

 Is the equipment on which the software will be loaded capable of handling the operating
system?
 Will any training need to take place to make the transition smoother?

If your configuration management database is planned and built properly, this information is
obtainable. A tool that can do this will need to be selected. All of the larger Help Desk / Call
Centre solutions companies are ITIL certified and will be able to supply a tool that can do this
for you.

Identification
You now have a configuration management database! So what do you need to do now? The next
step is to decide how you enter the information into your system. You have to decide on an
identifying and labeling procedure. When you decide what CIs are in the scope of your process
you either have to identify and label them yourself or have your third-party providers do that for
you. It is very important that you take care in this step. The Service Desk will need to ask this
information of a user when they call for support. If the information is not clear or understandable
then the issue will take much longer to resolve. Identifying equipment can be very
straightforward.

For example: A laptop in company "ABC" located in building "10" on the "3rd" floor can be
identified as follows: ABCLT1003

 ABC - Company
 LT - Laptop
 10 - Building 10
 03 - 3rd Floor

This identification will now be associated with information related to that CI. The identification
will also include information regarding who owns the equipment and what version of operating
system is on it, as well as what server and department its associated with. All this information is
vital to understanding the impact that each piece of equipment has on the infrastructure. The
business will also have to decide what level of detail regarding each CI is appropriate - will
having information on the PC, monitor and keyboard be enough, or should the detail be at a
deeper level?

Control
The person who owns the Configuration Management Database is called the "Configuration
Librarian". This person decides who has update authority. As mentioned earlier, the Service
Desk would be very helpful in this area considering the amount of contact they have with the
users.

Only authorized CIs can be included. This means that if your standard desktop is an IBM
machine then any other manufacturers who are not recognized should not be included in the
database.

From the moment that a purchase order for equipment is signed an entry into the database should
be made. This is very important for management to understand what their infrastructure looks
like at the earliest point. Upper management should also have access to this database, in order to
find the answers to simple questions about CIs throughout the company (that is, to determine
how many computers are owned by the company). This information should include all recent
purchases. It is also important for this database to track equipment to the point at which they are
retired or disposed of. This information will be used by a number of different ITIL processes,
including IT Financial Management.

Status Accounting
Status accounting takes into consideration the state of every CI within the company. If a
computer is ordered then its status is "ordered". When the CI arrives it is now in "received"
status. When it is deployed, in "active" status, and so on.

Every CI will have historical data associated with it. This will be beneficial when deciding on a
desktop that you want to use in your company. Historical status information will let you know
the success or failure rate for all CIs. For example if you determine from the data that the current
desktops had a higher than 10% failure rate then you should consider other options for future
acquisitions.

Status accounting information can be used for audit purposes to determine the current equipment
actively being used by the company.

Verification and Audit

Verification and Audits have to be done prior to any major changes and releases to CIs. This will
give your company an idea as to what equipment or technologies are out there and compare it
with the information within the database.

On average, the Service Desk comes into contact with between 5 - 10 % of company users daily.
This means that by asking a few selected questions, they can verify the accuracy of the
information in the database.

Other Definitions
 CI Attributes (unique identifiers)
o Serial or copy number
o Model number
o License number
o Type
o Version
 Relationships
o Connected to
o Part of
o Copy of

Benefits
 Configuration Management information that supports all other processes
 Information for impact and trend analysis for problems and changes
 Assists in adherence to legal and contractual obligations
 Reduces risk of unauthorized software
 Helping with financial planning

Exercises Configuration Management (Process)

The ABC Cookie Company needs to set up a configuration management process. How will you
apply the benefits Configuration Management to the ABC Cookie Company?

1. True or false? An Oven is a Configuration Item (CI)

2. What would be an attribute of an OVEN?
3. Which of the following is true?

(A)The Configuration Management Database (CMDB) contains physical copies of

hardware, software and documentation

(B) A job description is considered to be a CI item

A. Both A and B
B. Just A
C. Just B
D. None

Answers

1. An oven is a CI (True)
2. An attribute for an oven could be a rack or thermostat
3. Just B. No physical copies of hardware can be stored in the CMDB. A job description is a CI
because it can be changed.

Incident Management

The Service Desk (function) owns the incident management (process). The goal for incident
management is to restore service as soon as possible, minimizing the disruption to the business.

Terms and Definitions

An incident is defined as any event that is not part of the expected operation of a service that
causes (or may cause) an interruption to (or a reduction in) the quality of that service. This is true
of all incidents involving hardware, applications, service requests or documentation. Most
incidents are related to either hardware or software.

Documentation is an integral part of the IT department. If documented procedures for an

operating system are changed and the supporting staff is not informed, the procedure will likely
fail due to the use of an incorrect or out of date procedure - that would be considered an incident.
Applications, hardware and service requests are within the scope of incident management
support.
Incident Management Activities:
Detecting and recording

All communications with the service desk function regarding an incident or request should be
recorded regardless of whether the service desk detected the incident or if a user reported it. The
capturing of incidents is beneficial for a number of other processes. Problem management can
use the information from all tickets to do trend analysis. Service level management can use the
information for metrics in service management. Change management can use the information to
detect if incidents occurred due to the lack of proper change management.

Classification and initial support

The service desk, through the incident management process, will classify each incident or service
request coming into the service desk. It will be determined early whether it is an incident or
service request.

If it is an incident, it will then be determined if the incident is routine (such as printer start),
known error (lack of space on server) or a known problem (blue screen of death for instance).
Each possibility will have handling processes around them.

Part of classification is to determine the priority of the incident. This is done through an
evaluation of impact, urgency and expected effort. Once the classification is determined, a
priority is assigned.

 Impact - The degree to which the business is affected by the incident

 Urgency - The speed in which the incident needs to be resolved
 Expected effort - The resources needed to rectify the incident
Part of initial support is to inform problem management of any new or unmatched incidents as
quickly as possible.

The service desk will either resolve or quickly find a resolution using the incident management
processes.

Investigation and diagnosis

Understanding the details of the incident by collecting any pertinent information related to the
incident or if available consulting a knowledge base is an important part of the investigation and
diagnosis stage. This information will determine any resolution activity, workarounds or
escalation process.

There are 2 forms of recognized escalation:

 Functional - usually from 1st line upward due to lack of skill set to resolve the incident
 Hierarchical - usually a manual escalation through authority and can be done at any time

When the right resolving group has accepted the incident and evaluated the type of work that is
needed, both the service desk and the customer must be informed of the time to resolution.

Resolution and Recovery

Incident management will use a workaround solution to resolve an incident or initiate a request
for change (RFC).

Incident closure

The incident can only be closed with the user's permission. Confirmation of incident resolution
will be made with the user and details of the resolution must be placed in the Incident Control
System.

1st, 2nd and 3rd line support

Within the incident management process there are multiple lines of support. The service desk is
usually considered 1st line support. 2nd, 3rd line and up escalation is based on what skill set is
needed, determined by the service desk.

The service desk (1st line) accepts an incident. If after recording and some initial support it is
determined that the resolution of the incident is not one that is presently known or the skill set is
not available at 1st line, the service desk will escalate based on functional escalation (skill set) to
2nd line. If 2nd line can't resolve the incident, they will escalate to 3rd line and so on. Regardless
of which line of support resolves the incident, it is the responsibility of the service desk (1st line)
to confirm closure with the customer.
Relationship between Incident, Problem and Change
Management Processes
The relationship between processes highlights the importance of ITIL within the IT environment.
The Incident Management (process) through the Service Desk (function) collects information in
the incident control system. Incident Management can resolve about 85% at 1st line. Anything
the Incident Management process cannot resolve has to be escalated to Problem Management.
Problem Management relies on Incident Management to provide enough information to create a
work-around. The work-around is for incident management to provide an interim solution to
satisfy the user. To permanently remove the incident it has to be determined what the known
error is. After the known error is determined and the CI (configuration item) at fault is identified,
a request for change (RFC) is presented to the change management process for handling.

Benefits
Reduced business impact of incidents

By having proper incident management processes in place the duration of the incident will be
reduced, resulting in the management of the customer's expectations to resolution.

Proactive Identification of beneficial system enhancements and amendments

The ability to use the Incident Control System to analyze incidents, what is causing them and
how they can be resolved (Knowledge base).

Availability of business-focused management information related to the SLA

The incident control system being used by the service desk contains information on all incidents.
There will be metrics indicating when the incident was logged, resolved and closed. This
information will be compared with the SLA requirements, which will indicate if the incidents
were resolved within SLA targets.

Improved monitoring of SLA

The service desk using the incident management process will monitor all Incident Control
Tickets being escalated to 2nd level support and up to ensure that SLA targets are met.

Improved management information

Incident management will capture all information related to incidents, both the symptoms and the
resolution. This will give management a better insight into the IT infrastructure. Information on
how many incidents for each classification are created, including what areas were affected and
how long it took for resolution.

Better staff utilization and efficiency

Incident management is responsible for ensuring that the right resources are working on the right
problems. By doing this, the resolving groups will be used more efficiently and at the correct
times.

More accurate CMDB information

Incident management will ensure that all information going into the Incident Control System
ticket is correct. The information that populates the ticket comes from the CMDB. Verification
of the information will always be done and any discrepancies will be corrected.

Improved user and customer satisfaction

The faster incidents are resolved correctly the first time the more satisfied the user/customer. The
Incident management process ensures that speed and accuracy is incorporated into the process of
incident resolution.

Exercises Incident Management (Process)

The ABC Cookie Company has set up the Incident Management process. A call came into the
Service Desk regarding an issue with one of the ovens. What activities would incident
management do to try and resolve the incident?

1. Who will close the ticket with the baker, incident management or the Service
Desk?_______________
2. If incident management could not resolve the oven issue at 1st level what kind of
escalation would be used to get the right skills working on it: Hierarchical or
Functional? _______________
3. Which of the following is not a benefit of Incident Management? ______

A. Better staff utilization and efficiency

B. Elimination of lost Incidents
C. More accurate CMDB information
D. Improved user and customer satisfaction
 E. Reduced risk of unauthorized software

Answers

1. The Service Desk is the function and it owns the Incident Management Process so the Service
Desk will close the ticket with the baker
2. Functional escalation to 2nd or 3rd level support
3. a) Better staff utilization and efficiency is not a benefit of Incident Management

Problem Management

The goal of problem management is to minimize the adverse effect of incidents on the business,
problems caused by unknown errors in the infrastructure and to prevent the recurrence of
incidents related to those errors.

Terms and Definitions

Getting from problem to known error is a major part of the problem management process

 Problem - the unknown underlying cause of one or more incidents.

 Known Error - when the root cause is known and temporary work around or permanent
alternatives have been identified.

Problem Management Activities

Problem Control

Problem management handles incidents that cannot be resolved by the incident management
process at first contact and directs its resources toward the root cause. Problem management will
identify the problem and record it in the knowledge base for future reference. The problem will
be classified based on the SLA. After the problem is classified, problem management will then
perform a structured investigation and diagnosis to determine the CI (configuration item) at fault.
When the CI has been identified, a RFC (request for change) will be submitted. Problem
management will then direct incident management on the best work-around and the time to
resolution of the problem.

Error Control

Now that the problem has been identified, error control eliminates known errors by working with
change management. Error control has to be aware of, monitor and eliminate known errors where
possible in a cost justifiable way.
Assistance with the handling of major incidents

Problem management will assist incident management with major incidents by alerting them of
known errors and workarounds.

Proactive Problem Management

Proactive prevention focuses on identifying and resolving problems before incidents start to
occur. This can be done in 3 ways:

 Trend Analysis
o Using metrics and incoming data to identify patterns related to incidents or CIs
indicative of a problem
 Targeting Preventive Action
o Be aware of current incidents
o Volume of incidents
o The number of customers effected
o Duration and related costs of resolving those incidents
o The cost to the business with this outage
 Providing information to the organization
o Information on the IT infrastructure that is found within the CMDB can be very
useful to the organization when they go through the exercise of selecting new
hardware

Completing Major Problem Reviews

Major problem reviews occur when the IT infrastructure has stabilized following a major
problem. In this review there will be a description of the known error and what caused it. An
example could be that the known error was a scheduled job that didn't run, which was caused by
a change to the production schedule. The major problem review will identify the actions that
were taken to resolve it and what future considerations will be taken to prevent this from
happening again.

Benefits
 Increased IT organizational service quality:
o More effective and efficient handling of incidents, problems and known errors
will result in the increase of IT service quality
o Improved IT and Business relationship
o Improved management information
 Reduction in the number of incidents and problems will improve user productivity.
 Permanent solutions:
 o Solutions that are put in place by problem management will become part of the
infrastructure and will be used by 1st level support to increase the likelihood of
resolution at 1st call.

Exercises Problem Management (Process)

The ABC Cookie Company has set up the Problem Management process. A number of incidents
have been reported to the Service Desk regarding oven 1 shutting off due to the breaker tripping
in the power room. Incident management, as a work-around, instructed maintenance to go into
the power room and reset the breaker. After problem management used the "problem control"
activity it was determined that the new oven installed last week was put on the same breaker.

1. What would you consider the incident to be?

_______________________________________
2. What would you consider the known error to be?
___________________________________
3. What would you consider the request for change to be?
_____________________________
4. Match the following two columns:

Incident Someone changed the start time to a job

Problem Same job failing every day at the same time on the
same code
Known Error Reports aren't being produced
5. Give another example of incident, problem and known error
6. What information does Problem management give to the Service Desk?

Answers

1. Incidents are oven 1 shutting off by itself

2. Known Errors are 2 ovens on the same breaker
3. Possible RFC would be to add another breaker for the new oven
4. Match the columns:

Incidents = Same Job keeps failing with same code

Problem = Reports are not being produced

Known Error = Someone changed the start time of a job

5. Give your own examples of incident, problem and known error
6. Problem Management gives the Service Desk "Known Error" Information
Change Management

Change management exists to ensure that all changes introduced into the IT infrastructure do not
negatively affect service levels. The changes have to be done using standardized methods and
procedures in an efficient and prompt manner to minimize impact.

Terms and Definitions

Term Definition
RFC (Request for A request for change is submitted for any adds, moves or changes to any
Change) CI in the infrastructure.
RFC LOG (Request for All requests for change are given a call tracking number so that each
Change Log) RFC can be monitored and referenced. The information contained in the
log will be used at post change meetings and any future requests
showing similar requirements.
FSC (Forward Information obtained from change management about any scheduled
Schedule of Change) upcoming changes. This information is vital to Projected Service
Availability (PSA).
CAB (Change A membership of people ranging from the Change Manager to support
Advisory Board) staff and Selected Subject Matter Experts (SME). These people meet
regularly to approve and assess change requests. Members can change
from meeting to meeting depending on the type of RFC.
CAB/EC (Change Selected members of the CAB committee that will be contacted in
Advisory Board extreme or urgent situations to assess and approve changes that are
Executive Committee) outside of the time lines agreed to for changes.
Board (Senior Senior level management that makes strategic decisions resulting in
Management Board possible major changes to the infrastructure. When approved, these
Level) changes will be passed to the CAB for authorization and scheduling.
CM (Change Manager) A role that has defined responsibilities:

"Cradle to grave" ownership of all RFCs, who sees them

Owner and chair of the CAB meetings and selects the attendees that will
be required for each meeting

Issues FSCs via the Service Desk

PSA (Projected Service This report is a result of the FSC. It contains details of changes to
Availability) availability in relation to SLAs. This information is also used in the
development of new SLAs.
What is a Change?
A change is an action that alters the status of a CI that is found within the IT Infrastructure
(CMDB).

Change Management Activities

Filtering

The change manager has to assess all RFCs that are presented. The assessment is based on the
content of the RFC document; that is, is there enough information on the RFC to move forward
with the change? Sufficient information will ensure the change can be implemented with limited
disruption to service levels.

The following questions will have to be answered by the Change Manager:

 Has this type of request been submitted before? The change manager will check to see if
an RFC has been submitted in the past.
 Was the previous submission rejected? Why?
 Was it successful? Why or why not? The change manager needs to understand the
direction of the proposed change.

This can only be done by the creation of a standard RFC document that will be used by all IT
departments. If the RFC is complete and is accepted by the change manager it will be put
forward to the CAB committee. However, acceptance does not equal authorization. If the change
is small enough, the change manager can authorize it him or herself. If the change manager
authorizes a change and thinks it is necessary, the CAB committee will be informed of the
changes that were authorized.

Allocating priority and classification

Now that the change manager has accepted the RFC it has to be classified and prioritized. Every
company will establish their own "change model scope" that will identify classification. As in
incident management, classification will be based on the impact and urgency of the change
request. Changes can be classified by range from miniscule to mega. For example:
Change requests are based on impact of the problem and urgency of the remedy:

 Immediate
 High
 Medium
 Low
 Immediate - Mission critical system affected or affecting a large number of users.
Immediate action required (CAB/EC)
 High - Severely effecting critical business functions and must be given highest priority
 Medium - No severe impact but correction needs to be completed prior to next release or
upgrade
 Low - Change is justified but urgency for completion is low

Authorizing

 Change managers can authorize minor changes but should inform the CAB committee of
changes that were authorized
 CAB committee will authorize medium or significant changes
 Senior Level (Board of Directors) will authorize major changes on a strategic level. After
they authorize the major changes, authorization will then go to the CAB for review.

The authorizing bodies will make an impact assessment on all change requests. The assessment
will be based on the following criteria:

 Impact upon Business

 Impact upon SLA Targets
 Other Services
 Impact of 'not doing'
 Resources and Costs (Time and People)
 Current FSC and PSA
 Release Management (What effect change has on release)
 Ongoing Maintenance of Resources

Change Co-Ordination

Throughout the whole change co-ordination process the configuration management owner is kept
up to date through updates to the RFC log. The change manager directs any updates to the RFC
log to the configuration management process owner who owns this RFC log.

 BUILD

The change manager will ensure that the correct resources are assigned to build the
change. This information will be contained within the RFC and will either identify certain
individuals or groups.

 TEST
 Testing will take place by the requester after the change build is complete. The testing
specifics should be contained with the RFC. The builder will only test emergency or
urgent changes if time permits.

 IMPLEMENT

After the testing has been complete to the satisfaction of the requestor/builder then the
change manager arranges the implementation of the change into production.

Post Implementation Review

After the change has been put into production the change manager will do a post implementation
review to see how the change process worked in regards to the implemented change. Some
questions to be answered in the review are:

 What caused the need for the change? If the change was a result of a problem then the
problem management will get involved in the implementation review process.
 What can be done to avoid the problem that caused this change?

Dealing with Urgent or Emergency Changes

There will be time when a change will be considered urgent or emergency. The change manager,
when confronted with this type of change, will initiate the process in which the CAB/EC
(Change Advisory Board Emergency Committee) will convene to assess the change. CAB/EC
will consist of selected members from the CAB who have the accountability and authority to
make higher-level decisions. Clear guidelines with an associated process need to be established
as to what is considered an urgent or emergency change. The CAB/EC will meet when alerted.
They will quickly assess the situation, authorize and co-ordinate the change. After the change has
been completed and implemented the CAB/EC will do a post implementation review.

Impact and Resource Assessment

 Impact change has upon business.

 Careful consideration is necessary regarding the change and the business units affected
by the change.
 Change impact upon Infrastructure SLA targets.
 Impact on other services.
 Impact on non-IT services.
 Effect of not doing change.
 Resources and costs (time and people).
 Current FSC and PSA.

Benefits
  Alignment - the change manager will align all IT services with business needs based on
the changes being put forward. The change manager will need to understand the impact
of every change on the business.
 Increased productivity of both users and IT personnel:
o Users - Better quality changes with fewer disruptions
o Personnel - The change manager will ensure that the right support personnel are
working on the changes resulting in better use of resources
 Risk - since change management assesses and filters all RFCs, the risk of the
implementation of bad changes is reduced
 Quality reports on information related to changes. Change management will create
reports on all changes, which will include:
o The number of changes
o Category/type
o Successful/non-successful
 Increased volume of changes - with a strong change management process, there will be
the ability to absorb high volume of changes.

Exercises Change Management (Process)

The ABC Cookie Company has set up the change management process. A number of requests
for changes have been submitted to the change manager.

1. What activity involves assessing the RFC? _____________

2. Who authorizes significant changes? _____________
3. Can the change manager make changes to the CMDB? ______
4. Put the following activities in the order of occurrence:

A. Change co-ordination
B. Allocating priority and classification
C. Filtering
D. Authorizing
E. Post implementation review

1) __, 2)__, 3) __, 4) __, 5) __

5. Can changes take place without testing? ________
6. A minor change is a change category. Name the other three.

A. ______________
B. ______________
C. ______________
Answers

1. Assessing an RFC is a Filtering Activity.

2. Significant Changes are authorized by Senior Level (Board).
3. A change manger can authorize changes but not make changes.
4. 1C, 2B, 3D, 4A, 5E.
5. Testing prior to a change should always occur. If there is no time then a change can be done
followed by the testing.
6. Change Categories (Minor, Major, Significant and Emergency).

Release Management

The goal of release management is to ensure that all requests for change management take into
consideration both the technical and non-technical aspects. For example, when a RFC involves
upgrading the operating system from Windows 98 to Windows XP, release management will
ensure that every workstation will receive software (Windows XP), hardware requirement
updates (RAM or hard drive space) and documentation (Windows XP manual and training). All
four of the change components need to be coordinated so that the user service levels aren't
interrupted.

Terms and Definitions

Term Definition
DSL (Definitive All authorized versions of software CIs must be kept in a protected and
Software Library) secure area. This could be a vault or locked cabinet for vendor software
that is contained on tapes, CDs or cartridges. Internally developed
software would be kept on a secure server, which only authorized
personnel can access. All information about the software must be kept
in the CMDB.
DHS (Definitive Surplus hardware must be stored in a protected, secure area. All
Hardware Store) information related to the hardware must be kept in the CMDB.
SCI (Software A configuration item that is software based and either developed
Configuration Item) internally or purchased externally.

Release Categories:
There are three main types of release categories:

 Major software and hardware upgrades

 Minor software and hardware upgrades
 Emergency software and hardware fixes
Release Types
 Delta Release or partial release will contain CIs that are individual components or
modules, which are part of a larger suite of applications. For example, Microsoft Word is
a component of the Microsoft Office Suite.
 Full Release - all components/modules or a complete suite of applications.
 Package Release - two delta releases or a delta and a full or any combination of both.

Activities
Release policy and planning

This policy will cover the number and frequency of releases in certain business units. All
releases must have a unique identifier so that configuration management can maintain
information on them. At this point, clarification of peoples' roles and level of authority /
responsibilities have to be determined.

Designing, building and configuring a release

Planned and documented release procedures should be used for all software releases. If possible,
reusing a previously implemented release procedure is recommended.

Points to consider:

 Release definition
 Release plan

Fit for and release acceptance

This is testing that should be done prior to any release. A test group could be used to test the
actual release plus perform any stress testing that is needed.

Rollout planning

Time lines, identifying the CIs being affected, documentation, training and communication
planning

Communication, preparation and training

Initiating the communication campaign, preparing departments and affected CIs for the release,
initiate training program per roll out plan.

Distribution and installation

Initiating the phased distribution and installation of software into the infrastructure.

Release Policy
Should include:

 Clarification of roles and responsibilities for release management.

 Could be on a document or a number for each supported system or IT service.

Should be used for:

 Large or official hardware roll-outs.

 Major software roll-outs.
 Bundling or batching related sets of changes.

CMDB and DSL

 CMDB (Configuration Management Database)
 DSL (Definitive Software Library)

DSL Considerations
 Media
 Naming convention
 Environments supported
 Security arrangements
 Scope
 Retention period
 Audit procedures

Release Lifecycle Management

Development Environment

 Release policy
 Release planning
 Design and develop or order and purchase software

Controlled Test Environment

 Build and configure release

 Fit for purpose testing
 Release acceptance
  Rollout planning
 Communication preparation and training

Live Environment

 Distribution and Installation

Benefits
Improved quality of services due to successful releases

Successful releases would improve the quality of service by improving the hardware or software
within the infrastructure. They would also reduce the possibility of outages created by releases
that were not properly managed, which would have resulted in backing the change out.

Planned use of resources

With the ability to track all software and hardware via the CMDB, DSL and DHS, all resource
usage is maximized. The correct amount of hardware and licenses are accounted for and are at
the disposal of authorized change management requests.

Managed expectation levels

Using release management, the user will receive hardware, software, documentation and training
at a scheduled time (of which they are informed).

Improved historical data concerning releases

Historical data will be kept on all releases as a knowledge base. When releases are requested in
the future, there will be data to show how past releases went.

Improved control of software and hardware assets

Release management via the DSL and DHS will know exactly where all hardware and software
CIs are. This will pertain to assets that are owned or leased.

Reduced risk of unauthorized or illegal software

Release management will only authorize licensed software, so pirated or illegal software copies
will not be a concern.

Exercises Release Management (Process)

The ABC Cookie Company has a release management process. A request came in from Change
management that there is going to be a new release of the chocolate chip module of the chocolate
chip recipe.

1. What type of release is this? (delta, full or package) _____________

2. Where would the physical change be kept? _____________
3. Where would information about the recipe be kept? _____________
4. Which of the following is not part of the development environment?

A. Release policy
B. Roll out planning
C. Release planning
D. Design and development

5. What is the relationship between the DSL and the CMDB? _________
6. What are some of the benefits of having release management in your environment?

a. ______________

b. ______________

c. ______________

Answers

1. Delta
2. Significant Changes are authorized by Senior Level (Board)
3. A change manger can authorize changes but not make changes
4. Rollout Planning
5. CMDB - Identifies the location of an asset. DSL - Is the physical location.
6. See Benefits in Release sections

Service Level Management

Overview
The goal of Service Level Management is to:

 Establish a better relationship between IT and the customer

 Maintain and improve customer service
  Establish a true partnership in which both the customer and the IT provider have
accountabilities
 Terms and Definitions
Term Definition
SLM (Service Level Management) The monitoring of required service levels.
SLA (Service Level Agreement) Specific targets identified by SLM for each unit within the
IT organization.
SLC (Service Level Contract) Specific targets identified by SLM for each unit within an
external IT supplier.
OLA (Operation Level Agreement) Specific targets for the service being supplied by internal
service providers (Network services, LAN services, and so
on).
UC (Underpinning Contract) Specific targets for the service being supplied by an
external service provider (such as, G.E. Capital, Decision
One).
Service Catalogue A collection of all the services being provided and the
customers of each.
SLR (Service Level Requirements) SLM will ask each IT customer what his/her requirements
are. This will be embedded into the SLA.
SIP (Service Improvement Program) After the review of a SLA, service improvements may be
necessary. A service improvement plan will be designed
and actioned.

Service Level Management Process Activities

Establish the function

 Initial planning activities:

o Mission statement
o SLM scope
o Objectives
 Plan monitoring capabilities:
o Tools
o Incident Control System
 Planning and implementation of the service catalogue.
 Establish customer perception of current service levels by surveying if no other method
of monitoring is in place.

Implementing the SLA

  Produce the service catalogue of all services being provided by IT.
 Draft an initial service level agreement with the customer based on the service catalogue
and what the customer's service level requirements are.
 Expectation management (satisfaction = expectations - perception).
 Negotiate the service level agreement based on the contents of the service catalogue.
 Review all the UC and OLA to ensure they support the SLA. For example: If the service
level agreement requires 7x24 coverage ensure that the OLA for Operations is 7X24.
 Produce an agreement between the customer and the service provider.
 Define reporting and reviewing procedures (duration and frequency of review meetings).
 Ensure that the SLA's existence is publicized.

Managing the ongoing process

 Monitor the statistics based on the SLA for the user. It if can't be measured then it can't
be monitored.
 On a monthly basis, report the results of how the IT infrastructure is performing against
the SLA.
 Review the results. If improvement is necessary, implement a SIP.

Periodic reviews

 Review of all SLAs need to be scheduled with the customers on regularly occurring
intervals (monthly for instance).
 Reviews of all OLAs and UCs to ensure that they are still valid and support the SLA.

The Service Catalogue

 Introduction
 List of all standard services provided
 List of all specialized business services (if any)
 Service support matrix
 Contact Persons
 Information on IT department

SLA Contents
 Introduction
 Service Hours
 Availability
 Reliability
 Support
 Throughput
 Transaction response times
 Batch turnaround times
 Change
  IT service continuity and security
 Charging
 Service reporting and reviewing
 Performance incentives/penalties

Benefits
 Both the customer and IT provider clearly understand their roles and responsibilities:
o Both parties agree to levels of service and information requirements from each
side
o Communications will be scheduled
 Service level targets will be set:
o The agreed targets will be documented and measured
 Service levels will be monitored and reviewed:
 All metrics regarding service levels will be supplied to both the service level manager
and the customer. This information will be reviewed and a SIP will take effect if
necessary.
 SLR will drive IT services.
 OLAs and UCs will be better aligned with the business requirements.

Exercises Service Level Management (Process)

The ABC Cookie Company has a service level management process in place. An agreement has
been established with the service desk regarding the type of support that will be given to the
bakers. The bakers have contracts with a delivery company to ensure the pick up and delivery of
the cookies. The marketing people have an agreement with the ABC Cookie Company's IT
department for connectivity.

1. Which part of the above case study is an example of:

A. Operational level agreement _______________________

B. Under-pinning contract ___________________________
C. Service level agreement ___________________________

2. Which of the following is not a service level management activity?

A. Establish a function
B. Implementing the SLA
C. Periodic reviews
D. Detecting and recording

3. What are some of the benefits of service level management?

 a. ______________

b. ______________

c. ______________

Answers

1. Examples of...

The agreement between the Service Desk and the cookie company

The bakers have contracts with a delivery company

The marketing people have an agreement with the ABC Cookie Company's IT department for
connectivity
2. Detecting and Recording is a Service Desk activity
3. See Benefits in Service Level Management

IT Service Continuity Management

ITSCM
IT Service Continuity Management supports Business Continuity. By establishing an IT
supporting infrastructure following a disaster or major service disruption, continuity of services
can be assured.

BCM
Business Continuity Management concerns itself with all aspects of the business service
recovery. ITSCM is a part of this.

The goal of IT Service Continuity Management (ITSCM) is to support business continuity and,
in the event of a crisis, recover the required technical services and facilities within an agreed
time frame.

Why ITSCM?
The main reason to have ITSCM in place is to ensure business survival by reducing the impact of
a disaster or major failure. A plan will analyze risks and vulnerability and put in place measures
to reduce them. ITSCM will produce an IT recovery plan, which will prevent the loss of
customers and users due to lack of confidence.
How to make ITSCM successful:

 Review the configuration and change management processes to ensure they are current.
 Ensure the whole organization is aware of the ITSCM.
 Use the latest technology and software that supports the process.
 Train individuals with specific responsibilities associated with the ITSCM.
 Test the plan to ensure that it will work when needed.

Sources of Crisis
Companies may face a crisis (a disruption of service that exceeds limits set out within a SLA)
due to hardware or software malfunction, human error, natural disaster or viruses.

Hardware malfunction

Hardware malfunctions have been the leading source of crisis over the past 10 years. There are a
number of reasons this may occur, ranging from the quality of the product to the technology
being used to incorrect specifications.

Human error

Human error is a large cause of disasters. This can be attributed to lack of training, mistakes or
malicious behavior.

Software malfunction

Software malfunctions can be caused by coding errors, improper versions being introduced into a
production environment or changes being introduced without going through change
management.

Virus

Software code specifically designed to hinder or destroy systems. Usually introduced via:

 Floppy diskette
 CD ROM
 Internet

Natural disasters

 Earthquakes
 Floods
 Tornadoes
 Volcanoes
Responsibilities
The business needs to understand the options of ITSCM, as the "buy in" from the business is
vital to the success of ITSCM. All possible solutions should be clearly documented and
explained, including costs and time lines. It is necessary to explain to the business what the
consequences are of either delaying the implementation of a plan or not having a plan in place at
all.

The roles and responsibilities have to be documented and explained to management and
individuals involved.

BCM Stage One - Initiation

 Establish a policy

The owner of the BCM process will need to ensure all members of the BCM team are
aware of their roles, responsibilities, intentions and objectives

 Identify terms of reference and scope

Clearly define the roles of management and staff through a risk assessment and business
impact analysis of their respective departments and how the departments should be run
following a disaster.

 Allocation of resources

Both financial (costs) and human resources (skill set) need to be considered to be able to
do the analysis needed in stage two.

 Definition of project organization and control structure

Both ITSCM and BCM projects are complex in nature and need to be structured using a
software tool to be able to track time lines, accomplishments and tasks/responsibilities
(MS Project). Agreement of project and quality plans will need to be completed by all
necessary parties.

BCM Stage Two - Requirements and Strategy

 Business impact analysis
o Identify critical business processes and what damage or loss to the organization
would occur if that business process was disrupted
o Identify the type of loss (for example, financial, increased cost to running
business and/or intangible)
o Identify if the outage would cause more outages if not corrected soon
 o Identify the minimum requirements for staff, technical ability and facilities
needed to restore services
o Time lines to recovery need to be identified

Risk Assessment

 Identify risks (assets that are a vital business function)

 Assess threats and vulnerabilities
o Security (from terrorism)
o IT Services being below ground near a large water source
o Locations to potential dangers, like mountains
 Levels of risk based on vulnerability and threat defined by BCM owner
o Low
o Medium
o High

Business Continuity Strategy (countermeasures)

 Using the information collected from the impact analysis and assessment, a strategy is put
in place for risk reduction. Both a risk reduction and recovery strategy are required and
should compliment each other. A cost versus benefits analysis should also be completed.
Would it cost more to put a plan in place then the recovery itself?
 Counter measures
o Manual Backup - Usually help desks, call centers or order takers can use this
where paper alternatives can be initiated until the system is back up
o Reciprocal Arrangements - A situation where two similar organizations share the
cost of an off-site solution
o Gradual Recovery (Cold Standby - Greater then 72 hours)
o Intermediate Recovery (Warm Standby - Between 24 - 72 hours)
o Immediate Recovery (Hot Standby (Within 24 hours)
o Do Nothing (When the cost of having a recovery solution outweighs the risks)

BCM Stage Three - Implementation

 Organization planning
 Executive - Authority level (senior management) responsible for crisis management
 Co-ordination - Level below executives - responsible for the recovery effort co-
ordination
 Recovery - Teams within critical business functions responsible for executing the plans

Implementation planning

Co-ordination of the following plans: Emergency response, Damage assessment, Salvage, Vital
Records and Crisis Management/Public relations
Implement

 Risk reduction measures

o UPS, Fault Tolerant systems for critical applications, off-site storage and
archiving, disk mirroring and spare equipment.
 Stand-by arrangements
o 3rd party recovery sites like Comdisco or Sunguard
o Fully equipped company owned stand-by location
o Installing a stand by computer system

Develop

 ITSCM plans
o Administration (who, what, when and where)
o The right people need to be identified as to who will be involved in the ITSCM
plan
o IT infrastructure
o (Hardware, software, and documentation to support the business)
o The documentation needs to be written so that anyone who is not familiar with the
system can use it for system recovery
o Personnel (People related to staff and accommodation)
o Security (Instructions for fire, explosions, first aid, retrieving backups, and so on)
o Alternative location (Information - people, address, facilities, and so on)
o The plan will include actions to bring the IT infrastructure back to its operational
state
 Procedures should include:
o Hardware and network installations and testing
o Reference points to guide the restoration of software and data
o Procedures to consider time zones and multinational organizations
o What is considered a business cut off point

BCM Stage Four - Operational Management

 Education and awareness
o All staff within the IT organization should be aware of the ITSCM and BCM and
their roles
 Training
o In recovery procedures and responsibilities
 Review
o The review of the ITSCM and BCM to ensure they are current and valid
 Testing

Testing should be done:

o When the plan is complete

o Once a year
 o After every major change to the Infrastructure
 Change control
o All changes to the ITSCM or BCM must follow Change Management Process
rules. The ITSCM and BCM are considered CI items within the Configuration
Management Database

Benefits of ITSCM
 Potential for lower insurance premiums due to proactively managing the business risks.
 Business relationships improve due to closer working relationships and increased
understanding of risks and dependencies.
 Positive marketing of contingency capabilities results in higher levels of non-interrupted
service.
 Organizational credibility improves with the addition of ITSCM and BCM.
 Competitive advantage due to the ability to reduce risk and incorporate business
safeguards.

Security Management
The company needs to identify a person or team that will be responsible for either the long or
short-term security goals. This person or team will be responsible for the following:

 The creation of information security process and procedures

 Identifying potential security Incidents and an action plan to deal with them
 Establishing a security awareness in regards to the impact of lost information
 Security Levels

Security Processes and Procedures

The person or team responsible for Security Management need to work with the Business
Management Team and IT to determine what policies should be put in place to try and prevent
security breaches and what processes need to be developed to deal with the avoidance of such
breaches and what actions need to be taken if a security incident occurs.

Security Awareness

Sharing of information to the users of IT regarding the consequences of lost data due to hardware
or malicious actions. A user will only be aware of the impact of a lost hard drive after they either
experience it themselves or they are informed.

Security Incidents

A security incident is an alert to the possibility that a breach of security may be taking, or may
have taken, place. All security incidents need to be logged so that it can be evaluated later when
needed.
Security Levels:

 Top Secret - Documents that are of extremely sensitive nature. The availability of such
documents is kept to key company individuals.
 Highly Confidential - Documents that are of sensitive nature that contain information on
company process or of competition.
 Proprietary - Information that should be used by specific individuals within an
organization, such as Project Plans
 Internal Use Only - All information used between companies or departments, such as
Operation Level Agreements.
 Public Domain - All information approved for public viewing.

Exercises IT Service Continuity Management (Process)

The ABC Cookie Company has invoked an ITSCM process.

1. Match the following 2 columns:

A. Stage 1 of BCM Operational management

B. Stage 2 of BCM Initiation
C. Stage 3 of BCM Requirements
D. Stage 4 of BCM Implementation

2. Which of the following is not a counter measure?

A. Manual backup
B. Gradual recovery
C. Security
D. Do nothing

3. What are some of the benefits of IT Service Continuity Management?

a. ______________

b. ______________

c. ______________

Answers

1. Match the columns:

Stage 1 initiation
 Stage 2 Requirements

Stage 3 Implementation

Stage 4 Operational Management

2. Security is part of Availability Management
3. See Benefits in Service Level Management

Financial Management for IT Services

The goal of financial management is to provide formal cost effective stewardship of the IT assets
and the financial resources being used to provide IT services. This will have to be done in an
efficient, economical and cost effective way.

Financial Management Activities

Budgeting

Financial management supports the planning and execution of business objectives by predicting
and controlling the spending of money. Budgeting usually goes through a period of negotiating
cycles (usually yearly) while being monitored daily.

 Predicting the finances needed to operate IT service for a period of time. Using historical
data and industry standard predictions, expenses need to be established in order for
budget setting. Budget planning is usually done once a year and takes into account tabled
projects and the current cost of service levels.
 Budgeting is used to monitor performance against pre-defined targets to ensure service
levels can be maintained all year. These reviews are on-going to ensure that adjustments
are possible prior to year end.
 Review between Business and IT, calculating the cost of IT service provisions:
Discussions are necessary to determine service level requirements, the costs associated
with them, anticipated availability requirements and asset costs needed.

IT accounting

 Making cost effective decisions on service provisions is necessary to assess the service
being provided against cost. For example, "Is it more effective to outsource a service or
keep it internal?"
 Putting financial accountability into the hands of managers ensures that every cost
decision is cost justified with a business case like any other business investment.
 Provides the ability to measure under/over usage in financial terms. "We were $10,000
over budget on IT expenditures this year".
  Provide for an understanding of the cost of changes and the implications of not taking
advantage of business expenditure. "What is the cost if we do it? What is the cost if we
don't do it?"

Charging

Charging is a means of recovering costs for services rendered. Since customers pay for services,
they have the right to influence decisions on the service. Therefore, IT services should be
operated as a business unit.

 Cost - price of services rendered is the cost

 Cost-plus - price of services rendered plus % of profit
 Going rate - price compared to other internal departments or external similar
organizations
 Market rate - price matched by external suppliers
 Fixed price - a set price for a period of time based on anticipated usage

All IT costs
External services

 Outsourced Help Desk, DRP providers, contract companies

Software

 Databases, operating systems, incident control systems

People

 Payroll, benefits, fees associated with staff

Transfer

 Internal charges from other cost centers: Help Desk, LAN Services, and Operations

Hardware

 Mainframes, servers, PCs

Accommodations

 Building, Offices, Utilities, storage areas

Cost Elements
Costs can be broken into two categories: capital or operational.

Capital

The outright purchase of a software package or piece of hardware would constitute capital costs.

Operational

Day to day running of the software or hardware including staffing, utilities, and so on, would
constitute operational costs.

Each cost is part of one of three elements: Direct Costs, Indirect Costs and Unabsorbed
Indirect Costs.

Direct costs

Traced to a cost centre or department. For example:

 Servers
 Applications used exclusively by a single cost centre

Indirect costs

Traced to a cost of providing a service. For example:

 Operations staff
 Network or technical services

Unabsorbed indirect costs

Traced to a cost that can't be assigned to a customer. For example:

 IT management
 Building or facilities

Developing a Charging System

Scope

Informing the business of the need for putting the system into production. This charging system
should:

 Determine right policy for the organization.

 Recover fairly and accurately the agreed costs of services.
 Shape the behavior of customers to ensure best return on IT investments.
Charging policies will:

 Force the business units to control their own user demands.

 Reduce overall costs and highlight areas that are not cost effective.
 Match internal services to justifiable business needs through direct funding.

Recovery of costs

The recovery of costs should be simple, fair and realistic.

 Simple

Less bureaucracy with improved overall cost-effectiveness.

 Fair

Ensure that the charge for services provided reflect market value.

 Realistic

The charging policy must be designed to adjust the behavior of the business. If it is perceived
that the cost of the service is too low then it will be exploited by the business. Therefore, realistic
charges have to be implemented.

Customer behavior

Informing customers of costs can adjust customer/user behavior to make better use of IT
resources. Also, informing customers/users of costs associated with services being rendered will
make better corporate citizens. This will serve two purposes:

 Reduce the inefficient use of IT resources.

 Better control of the peaks and valleys of IT usage by adjusting charges based on usage
and times of usage.

Costing, Charging and Budgeting Cycle

An IT operational plan will contain information from the Business IT requirements and Financial
targets dictated by senior management. The outcome of this sub-process is fed into a cost model
where the costs are analyzed to determine which charging policies should be administered. The
proposed charges are then fed back to the business.

Benefits
 Reduced long term costs by budgeting, monitoring and controlling expenditures
  Increased confidence in setting and managing budgets. By using controls implemented by
financial management there will be improved accuracy and professionalism. Turning IT
into a business unit will ensure cost justification is put in place for all expenditures.
 Accurate cost information when making a business decision on investments will be made
clearer. For example, "How much did it cost to run that software, hardware or help desk?
Can it be done cheaper by using a different technology or service provider?"
 Making the organization aware of costs of doing business will result in better and more
efficient use of IT resources. This will increase the professionalism of each IT business
unit and will also make it easier to perform market comparisons with alternate service
providers.

Exercises Financial Management for IT Services (Process)

The ABC Cookie Company has invoked financial services for its services. One of its goals is to
provide cost-effective stewardship of IT assets.

1. Which of the following activities will best achieve the above goal?

A. Budgeting
B. IT Accounting
C. Charging

2. Match the following 2 columns:

Direct Cost Building

Indirect Cost Operational staff

Unabsorbed Indirect Cost Server requirements

3. Which of the following is not part of IT Accounting?

A. Cost effective service provisions

B. Justification of expenditure
C. Cost Plus
D. Measuring under/over

4. True or false? Developing a charging system will shape customer behavior?

Answers

1. IT Accounting
2. Match the columns:

a. Direct costs - Server Requirements

 b. Indirect Costs - Operational Staff

c. Unabsorbed Indirect Costs - Building

3. Cost Plus is part of Charging
4. True

Capacity Management

Overview
The goal of capacity management is to ensure that current and future capacity and performance
needs for business requirements are provided in a cost-effective way. This can be done by:

 Monitoring the performance and throughput of all IT services and the supporting
Infrastructure components.
 Tuning resources to make them more efficient.
 Understanding the present and future demands on IT resources.
 Using financial management, influencing customers on how resources are being used.
 Producing a capacity plan for IT service providers to support services that are required
within the SLA.

Capacity Management Sub Processes

Inputs to Capacity Management:

 Technology
 SLAs, SLRs and Service Catalogue
 Business Plans and Strategy
 IS, IT Plans and Strategy
 Business requirements and volumes
 Operational schedules
 Deployment and development plans and programs
 Forward schedule of change
 Incidents and problems
 Service reviews
 SLA breaches
 Financial plans
 Budgets

Business Capacity Management

Business Capacity Management is the process responsible for ensuring that the future business
requirement for IT services are considered, planned and implemented. The use of existing data
describing the way current resources are being used by all departments will help in forecasting
future requirements. Business capacity management must be:

 Responsive to change and changing requirements.

 Aware of customers SLRs.
 Involved in both Change Management and Project Management.

Service Capacity Management

Service Capacity Management is the process responsible for managing the performance of
operational IT services used by the customer. IT services are monitored and measured against the
targets within service level agreements and requirements. These measurements are recorded and
analyzed and if necessary action will be taken on IT resources to improve performance. The
advice of specialists within resource capacity management and making staff accountable and
knowledgeable in capacity management will help improve resource performance.

Resource Capacity Management

Resource Capacity Management is the process that manages single CIs within the IT
infrastructure. All resources with limited resource are monitored and measured. If necessary,
action will be taken against the data that is collected and analyzed. This action is to ensure that
all business requirements are met.

Output from Capacity Management

 Capacity plan
 Capacity database
 Baselines and profiles
 Thresholds and alarms
 Capacity reports (regular, ad-hoc and exception)
 SLA and SLR recommendations
 Costing and charging recommendations
 Proactive changes and service improvements
 Revised operational schedule
 Effectiveness reviews
 Audit reports

Capacity Management Iterative Activities

 Monitoring of all CIs.
  Data should be analyzed using expert systems (if possible) to compare usage against
thresholds.
 Recommendations made from analysis:
o Balancing services
o Changing concurrency levels
o Adding or removing resources
 Then monitoring starts again in a continuous cycle.

Capacity Management Activities

Demand Management

Demand Management is an influencing activity intended to change the capacity usage habits of
its customers. Demand management needs to understand which business units are utilizing the
resources, to what level and how often. After this information is collected, a demand
management plan can be put in place to change the level of usage or when they are using the
resources, provided the business units can be influenced to do so.

Modeling

Modeling helps in predicting the behavior of IT services under certain conditions.

 Trend Analysis (historical performance of resources).

 Analytical modeling (through use of mathematical software program).
 Simulation modeling (through use of a program to simulate computer processing it helps
in accurately sizing new applications but time consuming).
 Baseline Models (reflects the performance that is being achieved).

Application Sizing

Implemented at the project initiation and design stage for a new application. Application sizing
takes into account what resources are needed for applications being built internally or purchased
from a vendor. At the initiation stage care has to be given to ensure that enough space is given
for growth (SLR).

Production of a Capacity Plan

The capacity plan documents the current levels of resource utilization and service performance.

Forecasts and future requirements for resources are made after the analysis of the business
strategy and plan are considered. The plan should include:

 Assumptions
 Recommendations on resources required, cost, benefits and impacts
Benefits
Increased efficiency and cost savings including:

 Deferring costs of new equipment:

If the current technology is used more efficiently within the infrastructure then the need to
purchase new equipment can be deferred. This could either free up financial resources to
purchase other equipment or the financial services could be saved for future purchases.

 Economic provisions of service:

Matching capacity with business needs properly would avoid the maintenance of unnecessary
capacity, which will result in a cost saving.

 Planned buying:

Planned buying would reduce the risk of panic buying.

Reduced Risks

A significant benefit of capacity management is reduced risk. When capacity is managed

effectively then the risk of failure is reduced:

 With current applications the risk is reduced by managing the resources and service
performance.
 With new applications the risk is managed through the application sizing.
 The change advisory board should include capacity management, and should assess the
impact of changes.
 Effective capacity planning will reduce the number of emergency change increases to
capacity.

More confident forecasts

Over time, capacity planning improves due to the data collected. For example, normal operating
baselines and monitoring data collected will help in capacity planning. Using application sizing
and modeling when introducing new services will help forecast capacity needs more accurately.

Value to applications lifecycle:

Early identification of capacity needs in the development of applications should be put into the
capacity plan. This will reduce the risk of running into capacity issues when applications are in
production.

Exercises Capacity Management (Process)

The ABC Cookie Company has invoked capacity management

1. Which of the following is not an activity?

A. Application sizing
B. Modeling
C. Demand management
D. Authorizing

2. Match the following two columns:

a. Business Capacity Management Understanding each CI required

b. Service Capacity Management Understanding future requirements
c. Resource Capacity Management Understanding each service
required
3. Which of the following is an influencing activity?

A. Modeling
B. Demand management
C. Application sizing

4. True or false? Application sizing is only for internally developed applications.

Answers

1. Authorizing is a Change Management Activity

2. Match the columns:

a. Business Capacity management Understanding future requirements

=
b. Service Capacity Management = Understanding each service required
c. Resource Capacity Management Understanding each CI required
=
3. Demand Management
4. False

Availability Management

Overview
The goal of Availability Management is to:

 Ensure IT Services have the availability designed to meet the business requirements
 Optimize availability to satisfy business objectives
 Deliver to the business a level of availability in a cost-effective way
 Offer sustained levels of availability, reduced outages and to always strive for
improvement.
 Terms and Definitions
Term Definition
Availability The ability of a component within the IT infrastructure to
function at a certain level for a certain period of time.
Reliability Freedom from outage or operational failure of CIs within the IT
infrastructure. The levels of built-in redundancy, fault tolerance
or resilience put into each CI will make the service provided by
that CI more reliable.
Maintainability Maintainability is the responsibility of internal service providers
to support the availability of IT infrastructure CIs. There are
certain CIs that are supported internally, often because internal
employees built these CIs or there are job functions within the
company specific to maintaining this equipment.
Serviceability Serviceability is the responsibility of external, 3rd party, IT
service providers who are contracted to service equipment. This
normally occurs in companies with large numbers of leased
equipment or in companies who lack the certified skill set to
maintain certain CIs.
Security With the help of a Security Management Process, Security
measures are put in place to guarantee the confidentiality,
integrity and availability of certain data associated with a
service.

Availability Management Activities

 Determining the availability requirements of the business.

Determining from the business what the business requires in the way of availability is input into
availability management.

 Determining the VBF and reporting it to ITSCM.

Availability management will inform the IT Service Continuity Manager which are the Vital
Business Functions so that the Contingency Plan will have documented actions to support the
business.
  Compiling availability plan.

There is a need for specific information to develop an availability plan. This includes:

 Availability requirements
 The impact assessment for all the vital business functions
 Incident and Problem records to be used as information on IT service failures
 Monitoring data from configuration to data pertaining to each IT service and component
 Service level measurements against agreed targets

 Monitoring, reporting and improving availability.

The availability manager is accountable for all IT Availability. That person will monitor, create
reports and if necessary make adjustments prior to issues arising to ensure that availability does
not affect service levels. Availability trending will be used for improving availability in the
future

 Monitoring maintenance and service obligations.

Maintenance and service levels with both internal and third-party vendors are maintained
through the Operation Level Agreements or underpinning contracts and are up to date and
checked for validity. If there are any changes to the technology then the third-party vendor needs
to be informed to ensure the technology is covered in the event of an outage.

Availability Plan Inputs and Outputs

Create an objective for the availability plan. This objective should include what you want to
achieve, what the deliverables are and what other factors should be considered that might
influence availability (for instance, people, processes and tools).

The plan should cover:

 Levels of availability (actual versus agreed).

 What will be done in the event of availability shortfall.
 Information on how to change availability requirements to existing IT services.
 Information on how to adjust availability to new IT services.
 Information on how to adjust availability with new technology benefits to availability
(futures).

Indicators of Availability
 Mean Time to Repair
 Incident

Incident is the actual time the outage started

  Detection

The point at which the user discovered the outage

 Response Time

The time in which the outage was escalated for support

 Diagnosis

The time the outage was investigated

 Repair

The time it took to repair or replace the CI at fault

 Recovery time

The time it took to bring the machine back up to its original state

 Restoration

The time the business resumed normal operations

Benefits
Single point of accountability; the process owner is designated for Availability Management and
will ensure availability benefits the business by:

 Addressing business availability needs.

 Making availability services designed to be cost effective to meet business needs.
 Ensuring the levels of availability are sustained and measured to support SLM.
 Addressing any issues with availability and taking corrective action.
 Ensuring outages due to lack of availability are reduced.
 Helping the mindset of IT move from reactive to proactive.
 With IT support 'adds value' to the business.

Exercises Availability Management (Process)

The ABC Cookie Company has invoked availability management.

1. Which of the following is not an activity?

A. Realization of availability requirements

B. Compiling an availability plan
 C. Monitoring maintenance obligations
D. Filtering

2. Indicators of availability are:

A. Detection
B. Repair
C. Diagnosis
D. Restoration
E. Recovery

Which of the following is the right sequence for the above indicators?

b,a,c,e,d

a,c,b,e,d

a,b,c,d,e
3. A cookie vending machine has 3 functions. Which is considered a Vital Business
Function?

A. Interact function
B. Receipt Printing
C. Cookie Dispenser

Answers

1. Filtering - Is a Change Management activity

2. a,c,b,e,d
3. Cookie Dispense
Study Notes

Configuration Management
Goal

 To identify, record and report on all IT components that are under the control and scope
of Configuration Management.

Activities

 Planning
 Identification
 Control
 Status Accounting
 Verification and Audit
 Management Information

Definitions

 Infrastructure
o Includes hardware, software and any associated documentation
 CMDB
o A database which holds a record of all Configuration Items (CI) associated with
the IT Infrastructure
 CI
o It is a component of an infrastructure or an item, such as a request for change,
associated with an infrastructure, that is (or is to be) under the control of
Configuration Management
 Baseline
o A product or system established at a specific point in time which captures both the
structure and the details of that product or system and can be rebuilt at a later date
 Scope
o The range of responsibility covered by Configuration Management
 CI Levels
o The degree of detail selected to describe each CI
 Relationships
o A description of the interfaces which exist between CIs

Benefits

 Configuration Management information supports all other processes

 Information for impact and trend analysis for problems and changes
 Assist in adherence to legal and contractual obligations which will help in detecting and
deterring crime
  Reduced risk of unauthorized software
 Helping with financial planning

Problems

 CI definition: too much or too little detail

 Lack of commitment
 Process perceived as bureaucratic
 Circumvention of process

Service Desk
Goals/Purpose

 To provide a central/single point of contact

 To deliver high quality support to achieve business goals
 To aid in user retention and satisfaction
 To improve the service but reduce the cost
 To highlight customer training and education needs
 To close incidents and confirm satisfaction with the customer
 To contribute to problem identification

Roles and Responsibilities

 To accept and record all calls

 To do initial assessment of all incidents, attempt to resolve then escalate to 2nd level
based on SLA
 To monitor and escalate according to SLA
 To keep users informed on status and progress
 To produce management reports
 Managing the request lifecycle, including closure and verification
 Communicating planned and short-term changes of service levels to customers
 Coordinating second-line and third party support groups
 Providing management information and recommendations for service improvements
 Single point of contact (liaison)
 Customers and business service improvements
 Service restoration
 Skill sets and tools
 Deliver support critical for achieving business goals
 Identification of business opportunities

Definitions

 No definitions to be explained
Benefits

 Improved quality and faster response to user requests, cost of ownership, user service,
perception, satisfaction, team work and communication
 Better management of change by better management of infrastructure and control (better
managed CMDB)
 Increased user accessibility via (SPOC)
 Long term customer retention and Identification of business opportunities

Problems

 Lack of understanding of the business needs

 Not defining service objectives, goals and deliverables
 Not understanding customer requirements
 People issues (lack of training, overload/ burnout, and so on)

Incident Management
Goals

 To restore normal service operation as quickly as possible and minimize the adverse
impact on business operation

Activities

 Detection and recording

 Classification and initial support
 Investigation and diagnosis
 Resolution and recovery
 Closure
 Ownership, monitoring, tracking and communications
 Management information

Definitions

 Incident - any event which is not part of the standard operation of a service, and which
causes or may cause an interruption to, or a reduction in the quality of that service

Benefits

 Reduced business impact and interruptions from incidents by resolving them as quickly
as possible
 Proactive identification of beneficial system enhancements
 Availability of business-focused management information related to the SLA
  Improved monitoring of performance based on the requirements of Service Level
Management
 Improved management information
 Better staff utilization
 Elimination of lost incidents
 More accurate CMDB information resulting from constant audits from daily user
interaction
 Improved user and customer satisfaction

Problems

 Management or staff commitment

 Lack of knowledge for resolving incidents
 Inadequate training for staff
 Lack of integration with other processes
 No provision of agreed service levels
 Lack of clarify about business needs
 Review of working practices

Problem Management
Goals

 To minimize the adverse impacts of incidents and problems on the business that are
caused by errors in the IT Infrastructure and to prevent recurrence of incidents related to
these errors.
 Problem Management seeks to get to the root cause

Activities

 Problem control
 Error control
 Assistance with the handling of major incidents
 Proactive prevention
 Management information and problem reviews

Terms and Definitions

 Problem - a condition identified by multiple incidents exhibiting common symptoms, or

one single significant incident, indicative of a single error for which the cause is
unknown
 Known Error - a condition identified by successful diagnosis of the root cause of a
problem, when it is confirmed which CI is at fault

Benefits
  More effective and efficient handling of incidents, problems and known errors
 Increased service quality
 Improved user productivity
 Reduction in the number of incidents and problems
 Reduced chance of invoking contingency plan
 Improved management information
 Higher 1st level resolution rate and IT technical awareness
 Improved relationships between IT and the business

Problems

 Incident control procedure

 Staffing issues
 Knowledge based system
 Dealing with known errors

Change Management
Goals

 To ensure that standardized methods and procedures are used for efficient and prompt
handling of all changes to minimize the impact of change-related incidents and improve
day-to-day operations.

Activities

 Filtering (assessing) RFCs

 Classification (prioritize and categorize)
 Change approval (assess and authorize)
 Coordination (build, test, implement, Post Implementation. Review)
 Management information

Terms and Definitions

 Change - an action that results in a new status for one or more IT infrastructure CIs
 Standard Change (Pre-approved) - A change to the infrastructure that follows an
established path
 Request for Change (RFC) - form or screen used to record details of a RFC
 Forward Schedule of Changes (FSC) - a schedule that contains details of all changes
approved and their proposed implementation dates
 Projected Service Availability (PSA) - a document containing details of changes to
agreed SLAs/SLCs and agreed serviceability due to currently planned FSC
 Change Advisory Board (CAB) - a group of people who have decision authority for
significant changes
  Change Advisory Board Emergency Committee (CAB/EC) - a subset of the full CAB to
handle emergency change requests

Benefits

 Alignment - between the services provided and business needs

 Productivity - right personnel working on changes
 Risk - reduced impact by eliminating bad changes
 Volume - ability to absorb a high volume of changes
 Reports - quality reports on information related to changes

Problems

 Perceived bureaucracy
 Scope
 Dependencies
 Synchronization

Release Management
Goals

 Release Management takes a holistic view of a change to an IT service and should ensure
that all aspects of a release, both technical and non-technical, are considered together

Activities

 Release planning and overseeing

 Designing, building, configuring a release
 Release acceptance
 Rollout planning
 Communication, preparation and training
 Distribution and installation
 Management information

Definitions

 Definitive Software Library (DSL) - a secure software compound where all authorized
versions of software are kept
 Definitive Hardware Store (DHS) - an area set aside for the secure storage of hardware
spares
 Delta Release - only the CIs within the release unit that have changed
 Full Release - all the components of the release unit are built, tested, distributed and
implemented together
 Package Release - includes at least two releases, delta/full grouped together
Benefits

 Improved Quality of Services due to successful releases

 Consistency and improvement of releases
 Planned use of resources (testing and quality control)
 Managed expectation levels
 Improved historical data concerning releases
 Improved control of software and hardware assets
 Reduced risk of unauthorized or illegal software

Problems

 Initial resistance to change

 Circumvention of procedures
 Disparity of hardware and software versions at distributed locations
 Perceived bureaucracy and expense
 Unclear ownership and responsibilities
 Pressure to move forward

Service Level Management

Goals

 To maintain and improve IT service quality

 Better relationship between IT and customers
 True partnership
 Mutually beneficial

Activities

 Establish function
 Implement the process
 Manage ongoing process
 Periodic reviews
 Management information

Definitions

 Service Level Agreement (SLA) - agreement between IT provider and the IT customer
(internal)
 Operational Level Agreement (OLA) - agreement between Internal IT dept (such as
Network) and IT Service Provider
 Underpinning Contract (UC) - contract between external supplier providing services to IT
Service Catalogue - Defines services available to the customer from IT
  Service Improvement Program (SIP) - formal project undertaken within SLM, focusing
on Customer/Staff satisfaction
 Service Level Requirements (SLR) - client's service requirements that form the basis for
an SLA

Benefits

 Both the customer and IT provider clearly understand their roles and responsibilities
 Service level targets will be set
 Service levels will be monitored and reviewed
 SLR will drive IT services
 OLAs and UCs will be better aligned with the business requirements

Problems

 Verifying targets prior to agreement

 Inadequate supporting agreements
 IT based rather than business aligned
 SLAs not communicated

Availability Management
Goals

 To optimize the capability of the IT infrastructure, services and supporting organization

to deliver a cost effective and sustained level of availability enabling the business to meet
their objectives

Activities

 Determining availability requirements

 Compiling the availability Plan
 Monitoring availability
 Monitoring maintenance obligations
 Management information

Definitions

 Availability - availability of a component to perform its required function

 Reliability - freedom from operational failure
 Maintainability (Internal) - maintenance done on systems from an internal focus
 Serviceability (External) - maintenance done on systems from an external focus
(Outsourced)
 Resilience - redundancy, to allow IT's continued operation despite the incorrect
functioning of one or more of its sub-systems
  Security - confidentiality, Integrity, Availability)
 Vital Business Function (VBF) -the element of a business process considered business
critical

Benefits

 Single point of accountability

 Design for high level of availability
 Availability designed to fully support service level management
 Reduction of failures, duration and frequency
 Error correction to service enhancement
 Add value to the business by addressing business requirements

Problems

 Organizational
 Management responsibility
 Got problem and change, why this?
 Appropriate authority levels
 Lack or resource
 Support tools

Capacity Management
Goals

 To ensure that all the current and future capacity and performance aspects of the business
requirements are provided cost effectively

Iterative Activities

 Monitoring, tuning, analysis of IT throughput

 Implementation of changes
 Storage of data

Activities

 Demand management
 Modeling
 Application sizing
 Production of Capacity Plan
 Management Information

Definitions
  Capacity Database (CDB) - database used to record activity within Capacity Management
 Demand Management - trying to influence clients to use systems at different times as
workloads can be better controlled
 Resource Management - evaluates new technology and provides insight into the
infrastructure and calculates the investment
 Modeling - techniques can determine how to achieve optimal capacity
 Application sizing - calculates new software requirements and can determine new
hardware for applications that are being developed

Benefits

 Increased efficiency and cost savings

 Reduced risk
 More confident forecasts
 Value to applications lifecycle

Problems

 Over expectation
 Vendor influence
 Lack of info
 The distributed environment
 Monitoring levels

IT Service Continuity Management

Goals

 To ensure that the required IT Technical and Services facilities can be recovered within
required and agreed timescales.

Activities

 Risk analysis
 Risk management
 Management of the Contingency Plan
 Testing the Contingency Plan
 Initiation
 Requirements analysis and strategy
 Implementation
 Operational management
 Management information

Definitions
  ITSCM - part of the overall BCM, for continuity of IT Services only
 BCM - managing risks to ensure that the business can operate at all times
 Crisis - exceeds threshold values agreed to within the SLA/SLC

Benefits

 Management of risk and the reduction of consequences due to the impact of a failure
 Potential lower insurance premiums
 Business relationship improvement due to better business focus and awareness of impacts
and priorities
 Positive marketing of contingency capabilities both internal and external
 Organizational credibility by reduced outages
 Competitive advantage by customer confidence

Problems

 Will not remove all sources of risk

 Might not address organizational facilities
 Not all damage is financially quantifiable
 Contingency plans may be required by law

Financial Management for IT Services

Goals

 To provide cost-effective stewardship of the IT assets and resources used in providing IT

Services

Activities

 Budgeting
 IT Accounting
 Charging
 Management information

Definitions

 Direct Costs - costs which are clearly attributable to a single customer

 Indirect Costs - costs incurred on behalf of all, which have to be apportioned
 Variable Costs - costs which vary with some factor such as usage/time
 Unabsorbed Overhead - any indirect costs which cannot be apportioned
 Cost Elements (TCU, ECU, OCU, ACU, SCU) - hardware, software, people,
accommodations and transfer

Benefits
  Confidence in setting and managing budgets
 Accurate cost information to support IT investments, determining cost of ownership for
ongoing services
 More efficient use of IT resources throughout the organization
 Increased professionalism of staff within the IT organization

Problems

 New Disciplines
 IT/Accountancy skills
 Poor strategic objectives
 Costs and charges
 Cost outweighs benefit

The Service Desk (Function)

Chapter relevance 1% Show AllFetching ToCHide All Configuration Management

Chapter relevance 1% Show AllFetching ToCHide All Incident Management

Problem Management

Change Management

Release Management

Service Level Management

IT Service Continuity Management

Financial Management for IT Services

Capacity Management

Availability Management

Study Notes