Introduction ITSM

What is IT Service Management?

Field of daily management of applications and its necessary hardware to support a business. An IT
service is not only about an application, but also the package of choices on how you get your
application.

What is not IT Service Management?

The whole organization of developing and building an application or a IT infrastructure, which is called
the development area.

Customer and IT supplier

The customer domain (the one who demands the services) is another boundary of the field of ITSM.
To know what ICT can do and make profitable is another field that doesnt belong to ITSM. This is the
field of the Business Analyst. Advising and designing how Businesses can be effectively supported by
ICT. (The supplier is someone that gives an idea to develop, this could also be a customer)

The whole field of play of ICT (the core of ITSM can be considered the blue (lower left corner) part):

The IT organization:
The blueprint of a common IT service organization is very similar to this model. Many times there are
three big parties at play in the playing field of IT.
1) The customer with the business processes that need to be supported by applications.
2) The IT service supplier. Many times this party is a department within the customer.
 3) The IT consultancy company who provides specialists for the development of applications and
infrastructure.

Customer relationships and segregation of duties

The one who delivers the hard- and software to a business (the customer), is the IT supplier. The
customer checks if the (quality of the) delivery is according to what he asked. Because of this exchange
there will be a natural tendency to control the quality of the delivered service. Therefore it is important
to embed it in every organization. This principle of creating customer-supplier relations is called:
segregation of duties.

Best practices frameworks

The most popular best practice framework in ITSM is ITIL (Information Technology Infrastructure
Library). It consists of a number of processes to control different aspects of application and
infrastructure management (later there was more attention for application management). The driving
means of control throughout ITIL is: Work process-oriented. What really drove ITIL, is the attention
for cross-departmental processes. Because most administrators have the firm tendency to focus on the
work within their own functional department, the handling of client-requests, which requires mostly
multi-departmental solutions get frustrating.

Governance
If something is checked, it is in control, but how do you control things? How do you know what should
happen to run an IT organization smoothly? Governance frameworks answer these questions. They
define all IT processes that should be in place and you can check if these processes with their controls
are in place by comparing your processes with the ones from the framework. Well known frameworks
on this are COBIT, CMMI and also ITIL.

What does the customer (business) want?

Information demand
The customer requires a certain quality of information delivery. These requirements always relate to:
The functionality of the information system (what information does the customer need;
capability of the information system; e.g. registration, transformation of data)
The functioning (performance, availability speed, capacity) of the information system
The user support (opening hours, response service desk, change handling, service request
handling) during the use of the information system.
The customer requires supported functioning functionality to be able to process their data.

An IT service is the delivery of functioning IT functionality.

Quality demand
The quality of information delivery depends primarily on the quality of the customer, IT management,
information systems and the availability of financial resources to pay for the required IT services.

Service level agreements (SLAs) contained less and less information about the hardware that was
delivered or about the network that was deployed, and more information about the functionality in
terms of office and business applications and about the functioning of the information system.
The customer came up with more requirements, which were recorded in KPIs (Key Performance
Indicators, or performance indicators for quality). Agreements were made primarily on performance
indicators such as availability and recovery times (and sometimes response times).

Focus on services
In order to achieve the functionality that the customer needs, it must operate in a manner that meets the
customers requirements. This leads to the focus being on service delivery. The customer is less
concerned with how and what is used to make the adequate information available and more on the
results that it delivers.

Agreements on services always have to be formated properly, so they can be properly measures and
reported.

Proper is often translated to SMART: Specific, Measurable, Attainable, Relevant and Time-bound.

Requirements for the customer's

Customers must always manage their providers themselves.

These providers, whether internal or external, have to meet the same requirements. It is becoming
increasingly clear that, besides a good IT service provider (supply), you need a skilled customer
(demand) who can translate the needs of the business into the desired information delivery.

Being in control of information delivery requires a string and structural contribution from the
customer. For example, it means that the customer:
knows the relevance or value of the information delivery for his/her organization or business.
is able to determine the business requirements for the information delivery.
understands the (im)possibilities of information delivery and his/her organization takes this into
account.
has a realistic understanding of the cost of information delivery.
has clear and tailored business agreements with IT providers.
continuously monitors the performance of IT providers.
structurally aligns with IT providers regarding the delivered IT services.
monitors the efficiency, quality, and continuity of the provided information through audits and
benchmarks.
This means that the quality of information delivery is dependent on the quality of IT services.
Quality of information delivery = Management * IT Service delivery

Outsourcing
A customer that cannot meet the above requirements is not only unable to manage its own internal IT
department, but also unable to manage a third party. Many organizations that have outsourced their IT
have outsourced not only the supply function but also the demand function and its competencies.
Because of this, these organization have lost control over the information delivery.

In outsourcing of IT services the management problem is not outsourced.

Balancing the customer-provider relationships
When the maturity between the customer and provider differ too much there will be friction in the
communication. An organization that is not mature will not have mature expectations and demands
which will conflict with its IT service provider if it is mature, this also goes the other way around.

Process the process model and processes

Processes are the resources that determine the order in which activities should take place.

Definitions:
A process has a purpose, a goal.
Activities to achieve that goal.
Activities are prioritized and managed.
A process is a purposeful arrangement of activities.

Processes may not always be effective and efficient, or it leads to too much resistance and is therefore
not desirable. This may relate to the quality requirements, the size of the IT management organization
or the culture of the IT management organization.

Process goals
Every process has a specific purpose, such as the restoration of service delivery (incident management)
or changing the service delivery (change management). All activities that are necessary to accomplish
the purpose and the secondary goals are documented in the process description. Each activity should
help to meet at least one of the (secondary) goals.

Process control
A process is not just a series of sequential activities, it is very important that a process also include
process control. A properly executed process means that it is executed according to the process
description, the SLA (or project contract) requirements and based on current information.
KPIs that process control should meet can be linked to the tasks. (timeliness, completeness,
registration).

Process description: what: which goal and activities, relation and order.
Procedure: who executes the activities.
Work instruction: how should activities be performed.
A procedure determines the execution of a process in detail, including who performs the activity. The
involved ITSM tools are also defined. A procedure can take different forms in different organizations.

A work instruction defines how a specific call should be handled and which tools are used.

A call is a message, demand or request of an user or administrator of a service.

Processes do not change in reorganizations.

Process roles and responsibilities

Process owner: ensuring the process is fit for purpose (design, KPIs, facilitating the process,
process improvement opportunities).
Process Manager: accountable for the operational management of the process (coordination,
monitoring, reporting, improving efficiency and effectiveness).
Process Practitioner: responsible for carrying out process activities.

RACI Matrix
Responsible (for carrying out an activity)
Accountable (approves the result of the activity)
Consulted (two way communication (e.g. expertise))
Informed (one-way communication)

Incident management

Incident management supports the business by restoring normal service as quickly as possible to
prevent the impact to the user. Incident management is guided by the SLAs. The SLAs document the
expected levels of service for response targets for incident management. The incident management
process records every incident that occurs in the environment. These incidents are tracked to ensure
that no incident is lost, forgotten, or ignored, but also to ensure that they are responded to and resolved
according to the SLAs.

Purpose and objectives

The purpose of Incident Management: restore normal service operation as quickly as possible and
minimize the adverse impact on business operations, thus ensuring that agreed levels of service quality
are maintained.

The objectives are to keep the quality of the service that is provided as high as possible while
increasing the visibility and communication of incidents to business and IT support staff.

Business value
While the business may not notice that a service is operating better than expected, it definitely notices
when the service is unavailable. Incident Management strives to reduce downtime for the benefit of the
business. Proper prioritization of incidents can provide alignment between IT and real-time business
priorities. This means that the Incident Management needs process knowledge about the business
processes.
Key concepts

Incident: An unplanned interruption to an IT service or reduction in the quality of an IT service or a

failure if a CI (Configuration Item, object that belongs to the IT infrastructure).
Timescales: The amount of time each stage of the process can take. This may differ based on the
priority of the incident.
Incident models: Models with pre-defined steps for common problems that can greatly reduce the
response time.
Major incidents: Incidents with a high level of disruption to the business. These should be anticipated
and they should have a pre-defined procedure for a quick resolution.
Escalation: When the one investigating an incident is not able to determine how to resolve it.
Functional escalation: When the incident is escalated to someone with more specialized
knowledge of that service or component.
Hierarchic escalation: When the incident is escalated to someone with a higher function.
Both functional and hierarchic escalation could also occur when SLA time-frames are about to expire.

Identification: An incident might not always readily identified as one, to reduce the time to identify an
incident, monitoring tools assist with the identification. Incident Management also may determine that
the incident is actually a service request.
Logging: Every incident is logged, ensuring that all relevant information is documented to reduce
unnecessary communication and the time needed to solve future incidents and to analyze incidents.
Categorization: An incident is categorized (after being logged) to the type of incident and what it
affects. This is used for correct escalation to specialist groups, reporting and incident matching.
Prioritization: Incidents are prioritized based on urgency and impact. It may change over time.
Initial diagnosis: The service desk provides initial diagnosis of an incident.
Investigation and diagnosis: Incident matching (researching previous incidents to find an answer to
the current incident) takes place. It isnt necessary to find the root cause of the failure, but to resolve it.
Although the root cause may still be solved if that is the quickest path to a resolution.
Resolution and recovery: The resolution is performed when the appropriate action is determined, once
the incident is resolved recovery of data may be necessary to restore the service. The incident is closed
when the service desk verifies that the resolution satisfied the user expectations and the service has
been restored.
Closure: The service desk performs formal closure of the incident by verifying that the user is satisfied
with the resolution. The service desk may consider opening a problem record for further action.

Roles:
Incident manager: Ensuring all process activities are carried out; ensuring efficiency and effectiveness
of the process; developing process and procedures; managing major incidents; reporting
Support: 1st level: Service desk staff; 2nd level: administrators and specialists; 3rd level: external
suppliers.

Change management
Change requests can be generated from any place in the organization for a number of reasons
(proactive: reduction of costs, productivity/quality/service/functionality improvement; reactive: resolve
errors or adapt to a changing environment) The change management process activities are triggered by
requests for change (RFCs). An RFC is a mechanism to request a change to be made to a service.
Purpose
To control the life-cycle of all changes, enabling beneficial changes to be made with minimum
disruption to IT services.

Without an effective change management process in place, an organization cannot effectively control
changes. This results in low change rate, unplanned outages and a high number of emergency changes.

The objectives are to respond to the (changing) business, ensure that changes are recorded and
evaluated, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner,
ensure that all changes to CIs are recorded in the CMS (configuration management system), optimize
overall business risk.

Value to business
Change management provides value to the business by doing above stated objectives in order to reach
above stated (proactive & reactive) changes while protecting the business and other services by
reducing the risks and failures.

Key concepts
Regardless of the type or source of change, all changes must follow a process with specific procedures.

7 Rs of change management
Every change must be evaluated to answer the following seven questions:
Who RAISED the change?
What is the REASON for the change?
What is the RETURN required from the change?
What are the RISKS involved in the change?
What RESOURCES are required to deliver the change?
Who is RESPONSIBLE for the build, test and implementation of the change?
What is the RELATIONSHIP between this change and other changes?

Change priority
The priority is based on the urgency and impact. Urgency is based on the requesters needs and/or
wants. Impact is measured by disruption to the business defined outcomes (like revenue).

Types of change
Standard changes: pre-approved changes that are well understood and common, with pre-established
procedures and low risks (e.g. changing backup schedules, submitting a batch job, applying patches)
Normal changes: These changes undergo scrutiny and due diligence that are appropriate for the level
of change. It must be assured that planning and testing have been performed to minimize the risk.
Normal changes are usually initiated by a RFC and evaluated by the CAB (change advisory board).
Emergency change: A change that must be implemented in a time-critical manner in order to prevent
unacceptable loss or impact to the business. Emergency changes should have a path through the process
and should be considered before they occur.

Change advisory board

The CAB is a group of stakeholders that meets to evaluate high-impact RFCs. It consists of
representatives from IT and the business and includes customers, users, IT management, IT staff,
consultants, and vendors, if necessary. The attendees may differ depending on the changes being
considered. CAB meetings should be focused and not waste peoples time. The CAB agenda should be
published in advance of all meetings to allow the CAB members to review the proposed changes prior
to the meeting.

Emergency changes
A change that is required to be implemented in a time-sensitive manner.

Emergency changes prevent potential failure, lack or loss of functionality or revenue.

Authorization: Authority for emergency changes should be delegated and documented so it can be
understood.
Testing: Testing should be performed to the extent possible and may be done during implementation.
Documentation: Documentation must always be completed, but that may be after implementation.
Review: All emergency changes should be reviewed, they are inherently risky and steps to reduce the
number of changes should be determined.

Change models
For commonly occurring changes, change models that pre-define the steps required to conform to the
change management process can be developed.

Remediation planning
Remediation planning accepts the fact that a change may fail and plans for that contingency.
Remediation planning only needs to be done once for each change model. A remediation plan is not the
same as a back-out plan, but a back-out plan may be part of it.

Change documentation
All changes must be properly documented. The change documentation is completed as the change is
being performed and the knowledge required for the documentation is gained. It is important to ensure
that the amount of documentation required for a change is consistent with the type of change.
Otherwise the process may be deemed too bureaucratic and will not be followed.

Overall activities
While the change management process has discrete activities, there are some overall activities that
should be considered, this includes: planning communications, change and release scheduling, decision
making and authorization, remediation planning, measurement and control, management reporting,
impact assessment and continual improvement of the process.

Process activities
Not every type of change follows the same path through the change management process based on the
type of change or the change model identified for that change. Individual activities for CM:

Create and record RFC: Ensure that the RFC has been created and that it accurately reflects the
change that is being proposed.
Review RFC: The change is reviewed to ensure that it is correct and feasible.
Assess and evaluate: Establishes the appropriate level of change authority and ensures that the change
has the appropriate level of oversight. The scope of a change is determined to identify the stakeholders
of the change (these stakeholders are candidates for the CAB).
Authorize change, build and test: Change authorization ensures that the change is understood and
properly documented and is approved by all stakeholders identified for this change (may need a CAB).
Coordinate change, build and test: Change management does not actually build a change but relies
on release and deployment management to build and test the change as part of a release package.
Change management provides overall coordination of the change to ensure that it is properly managed.
Authorize change deployment: CM authorizes the deployment of the change as part of a release
package. This is done once the change has been built and checked into the DML as appropriate.
Review and close: Once the change has been completed, the change is reviewed for correctness and to
ensure that the change met its objectives. It is also an opportunity to ensure that all documentation has
been completed and saved to serve as a record of that change being performed. Change reviews should
occur for both successful changes and failed changes, as deemed appropriate.
Change proposal: A change proposal is submitted for those changes where the work to prepare the
change or obtain funds for the change must be authorized and approved.
Authorize proposal: The proposal must be authorized in order for the resources to be expended to
move the change forward. Once authorized, it may result in a series of RFCs to implement the proposal
Update CMS upon the implementation of the change, to ensure that it reflects the new environment.
Evaluation report: Every change is evaluated for correctness, this consists of an Audit to ensure that
the process has been adhered to. PIRs (post implementation reviews) maybe be conducted to evaluate
complex changes and failed changes. Every emergency change should have a PIR.

Change management process relationships

Change management is the process of managing changes that may have been identified by other
processes. All of the processes may be a source of RFCs. Specific relationships with other processes:

Service asset and configuration management records the CIs as they move through the change.
Problem management removes errors from the environment through changes.
IT Service continuity management reviews changes for impact to the continuity plan.
Information security management reviews changes for impact to information security, as well as
submits RFCs to change management to improve security.
Availability and capacity management review RFCs for impact to availability and capacity, as well
as submit RFCs to improve availability and capacity.

What is an Audit?
A means to assess if a process is in control.
How do you assess if a process is in control?
1) Make (or refer to) a control list (aspects that should be taken care of)
2) Ask (e.g. by an interview) how each aspect is been taken care of
3) Assess the answers (e.g. by common sense or by comparing them to a best practice framework)
4) Advise on improvements on each aspect.

Problem management

Problem management is the process responsible for eliminating errors from the environment and
reducing the incident volumes experienced by the users. Information that can assist with the rapid
resolution of incidents becomes part of the service knowledge management system (SKMS).

Purpose and objectives

Manage the life-cycle of all problems from first identification through further investigation,
documentation and eventual removal.
Problem management performs the RCA (root cause analysis) of problems to determine where the error
is. Problem management then converts this problem to a known error and manages the known error
through resolution. This is documented in the KEDB and reduces future incidents. It has a strong
relationship with knowledge management and provides documented workaround for the SKMS. The
goals are to prevent problems and resulting incidents, eliminate recurring incidents and minimize the
impact of incidents that cannot be prevented.

Value to business
Problem management is where the reduction in known errors in the environment occurs, resulting in
improved availability and fewer incidents. It also documents workaround to improve resolution times.

Key concepts
Problem: the cause of one or more incidents; a fault in the infrastructure for which no solution has
been found.
Problem models: Models for commonly re-occurring problems (activities, time-scales, escalations etc)
Known error: a fault in the infrastructure for which a permanent solution or temporary workaround
has been found; KE = problem with root cause + workaround. (known error database = KEDB)

Tools and techniques:

Techniques are utilized by problem management to assist with the analysis of problems, these include:

Chronological analysis: documenting the order of events to determine how they relate to the problem.
Pain value analysis: Analyzing the broad view of the impact of the problem.
Kepner and Tregoe is a technique for formal problem investigation.
Brainstorming: presenting ideas without regard to context and then applying the context.
Ishikawa diagrams analyze the cause and effect of events leading to a problem.
Pareto analysis: Charting the symptoms of a problem to determine the main pain points.

Activities
Activities in this process are important to manage problems and known errors through resolution.

Problem detection: Incident records are used for trends that may identify potential problems.
Problem logging: Ensures that all information regarding the problem is recorded.
Problem categorization: Problems are categorized to determine which support group to route the
problem to. The categorization scheme for problems is usually identical to that of incidents.
Problem prioritization is similar to that in incident and change management (urgency, impact etc.).
Problem investigation and diagnosis is where the root cause is determined. Once determined, a
known error is created and linked to its associated workaround or fix.
Implement workaround: The appropriate workarounds are documented and recorded in the KEDB.
Raising a known error record: The known error, and its workaround are documented within KEDB.
Problem resolution: Once the problem is resolved, its resolution is tested and verified with the user to
make sure that it resolves the problem and the error is removed. If the problem resolution involves
modifying the environment, an RFC is raised and the associated change is performed through CM.
Problem closure: Formally closed to ensure that all associated documentation has been completed.
Major problem reviews: Some problems are large enough in scope so they may require reviews.

Other activities
Activities outside of this process flow to enable the management of problems throughout their life-
cycle.
Recording errors from development: Any outstanding errors in newly released software or services
should be recorded in problem management to ensure that they are managed through resolution.
Monitoring and tracking of problems throughout its life-cycle ensures that the problem obtains the
appropriate attention that it needs.

Kepner Tregoe:
Describe the problem as good as possible (what, where, when, extent etc..). Quantify the
problem.
Use comparison of the problem situation with the normal situation.
Use what IS (NOT) the problem: identifying what is not the problem also gives information.
Identify all probably causes.
Verify all possible causes.
Address the possible causes that can be verified quickly and simply first.
Assess each possible cause, the easy ones first.

Root Cause Analysis (RCA):

Define the problem, qualitative and quantitative properties.
Establish a time-line of events.
In case of data-mining: search for patterns that might lead to a cause and check with experts.
Ask why to identify the causes that resulted in the effects.
Identify all other factors that could be root causes.

Fault Tree Analysis:

Define the undesired event (problem).
Identify all possible causes.
Order the causes.
Construct a fault tree.

5 Whys method
Start with the undesired outcome, the problem.
Ask why that situation occurred.
About the answer you ask again: Why?
Repeat this 5 (more or less) times. There can be multiple answers so in most cases a tree will
be shaped.
Do you have to find out the whole tree?
Work level by level, find evidence for each possible cause.
Watch out for multiple causes, so check each branch.
If you found a cause, search for a solution.
Beware of latent/underlying causes.

Configuration Management

Service asset and configuration management is the process that provides control to the infrastructure.
Through the creation of a configuration model, the relationships between components are recorded to
ensure that the environment is documented and well-understood.
Purpose and objectives
Ensure that the assets required to deliver services are properly controlled, and that accurate and
reliable information about those assets is available when and where it is needed.

The purpose is to provide a logical model of the IT infrastructure. The objective is to define and control
the components of services and infrastructure and maintain accurate configuration information on the
historical, planned and current state of the services and infrastructure.

Ensure that assets under control of the IT organization are identified, controlled and properly cared for
throughout their life-cycle.

Key concepts
Configuration model
Shows the services and how the individual components, systems and applications are related to provide
these services.
Service: Top level in the conf. model and should be linked to the business service that it supports.
Systems: provides the service that makes up this system level to support the service.
Applications are not services themselves, they may support more than one, and the other way around.
Components level represents the individual component (soft- & hardware) used to provide the service.

Configuration management system

The CMS (configuration management system) is a set of tools and databases that are used to store a
service providers configuration data. The records stored are called CI (configuration items) (related
incidents/problems/known errors/change records and release documentation) that contain component
details, as well as their relationships to each others.

Configuration Item
Any asset, service component, or other item that is, or will be, under the control of Configuration
Management.

Anything could potentially be a CI if it is required to provide a service. Each CI has a set of attributes
about the CI and has a life-cycle that shows where they are in their individual lives.

Configuration baselines
The configuration baseline is similar to a master image of a configuration. Configuration baselines
are very useful to other processes in order to prepare for disaster recovery, make changes to the
infrastructure, or plan for improvements.

Roles
Configuration management involves several roles, often performed by different people. Other roles
involve other processes to ensure that the relationships between asset and configuration management
and the other processes are maintained.
Service asset manager: manages the asset management to ensure conformance to the process.
Configuration manager: ensures that the configuration management processes are adhered to.
Configuration analyst: support the conf. man. plan by ensuring accuracy of information in the CMS.
Configuration Administrator/Librarian: controls the receipts, identification, storage etc and
withdrawal of all CIs in the CMS and definitive media library (DML) and provides information.
CMS/Tools administrator: responsible for evaluating and maintaining the tools used.
Functional application management
Applications support Business processes, as businesses changes continuously, so do business processes
and so should the application supporting this business. Nowadays applications are quite complicated,
this results in special super users appointed to tune applications and educate others about it.

The Dutch approach

The international field of Functional application management is not strongly acknowledged. In the
Netherlands this was undesirable and the BiSL (Business Information Services Library) framework
came to life, exclusively for executing Functional Application Management. Another framework is
ASL (Application Services Library) but it overlaps a lot of BiSL and ITIL, therefore the added value of
this framework is limited and not widely accepted. In this field, probably the most important skill is
test management. Therefore an article on this topic is part of this reader.

An introduction to BiSL

It was introduced in 2005 as a library for business information management. The library consists of
publications describing the process framework for business information management and a large
number of best practices, white papers, articles and presentations.

Why BiSL?
The demand side of IT also had specific needs that were not addressed sufficiently by existing
frameworks, there was a justification for a framework on this domain. One of the most important
benefits of the framework is that a common language and terms of reference are provided to the
market. Business information management was discovered to be the most important organizational
function in the information (technology) domain, since it is at the beginning of the information
provisioning chain.

BIM and BITA

IT started getting pressured to come up with IT services that better served the needs of the business.
Meanwhile the business became more aware of the fact that they had the responsibility to define what
they needed from the IT providers. This describes the concept of Business IT Alignment (BITA) and
relates it to one of the central themes in this publication, business information management (BIM), the
domain for which BiSL is developed.

Alignment can be achieved in two dimensions: strategic fit (external vs internal domain) and functional
integration (business domain vs IT domain). The potential strategic impact of information technology
requires both an understanding of the critical components of IT strategy and its role in supporting and
shaping business strategy decisions and a process
of continuous adaption and change.

Maes generic framework for business IT

relationship can be used to discuss the mutual
responsibilities, roles, processes and relationships
between the demand and supply side of the
information provisioning.
The generic framework gives a clear indication of the issues to be considered at the different levels.
The middle column and the middle row are most important to business-IT alignment. The middle
column coincides with the business information management domain.

Recent ideas relation to business information management

This section considers four developments, which have also had an effect on the nature of BiSL.
1) Business information management as a key between business processes and the information
provisioning.
2) Thinking in terms of business processes and not in terms of information systems.
3) Business information management as a portfolio holder.
4) The essence of the interrelationship of domains.

What is BiSL?
It is a vendor independent public domain library for the implementation of business information
management in the broadest sense of the word. BiSL aims to professionalize the demand function.

The BiSL Framework

BiSL indentifies processes at the following three levels:
operational the operational processes involve the day-to-day use of the information
provisioning, and designing and effecting changes to the latter;
managing the management processes involve costs, benefits, planning and quality of the
information provisioning and arrangements with IT supplies;
strategic the processes at the strategic level define the nature of the information provisioning
in the long-term and also how its management should be structured.

BiSL consists of 7 clusters and a total of 23 processes on three levels. Within the framework the three
levels, seven process clusters (a, b, ) and a number of processes () are:
1. Operational:
(a) Use management (3)
(b) Functionality (4)
(c) Connecting processes at operational level (2)
2. Managing:
(a) Management processes (4)
3. Strategic:
(a) Information strategy (4)
(b) I-organization strategy (5)
(c) Connecting processes at strategic level (1)
These 7 processes clusters are discussed in detail in the following section.

Use management cluster

The use management cluster distinguishes three processes; these are directed towards ensuring an
optimal and continuous support in daily use of the information provisioning by end users.
End user support: Help users; answering user requests. Inform and train users.
Business data management: Administration of central tables and regulations; ensure data integrity.
Provision of ad-hoc data (reports).
Operational supplier management: Managing SLAs (requirements on availability, capacity and
continuity). Controlling service levels IT supplier.
Functionality management cluster
The processes that are part of the functionality management cluster cover the following two areas of
focus:
the design functionality management focuses on the design of the required changes in
functionality. These processes are of a substantive nature;
the transition functionality management involves preparation for and the initiation of the
requisite transition and the implementation of the required changes.
Specify information requirements: Translating functional requests for change into (technical)
solutions. Record these changes.
Design non-automated information systems: Creating and maintaining relevant documentation for
everyday use (procedures, work instructions manuals).
Review and testing: Changes are tested: Facilitating and executing User Acceptance Test (GAT) (FAT)
Prepare transition: Establishing required conditions as to implement changes without any problems.

Connecting processes on the operational level

The synchronization of focus and communication between the two processes above occurs through
linking processes. The linking processes are change management and transition management.
Change management: make correct decisions about introducing small and big changes
Transition management focuses on actual deployment of the change to the end users.

Management processes
The management of the information provisioning in an organization entails the control of the substance
and functionality (what), the costs (how much), the schedule (who and when) and the supply (how and
with what). These four types of management produce four distinct processes:
1. Planning and resource management: providing resources as to support the information
processes.
2. Financial management: cost effective financial support of the information processes (business
cases).
3. Demand management: ensuring quality of the information provisioning.
4. Contract management: monitoring and improving the SLA with the IT supplier.

Information strategy cluster

Aimed at defining policy concerning the information provisioning in the medium and long term.
The establish business process developments process maps out the development that will occur in an
organization and its business process in the long term.
The establish information chain development process involves the determination of chain
developments and focuses on the information provisioning within and between multiple organizations.
The establish technological developments process determines whether any technological
developments are occurring which, when viewed from a business perspective, could have an impact on
an organization and its information provisioning.
The objectives of the information life-cycle management process are to create a strategy for
information provision, translating into actions and investments and ensuring this is implemented.
The information portfolio management process ensures the overall coordination and uniformity of
the entire information provisioning throughout an organization.

I-organization strategy cluster

Compromises four processes which focus on defining the manner in which the management of
decision-making concerning the information provisioning is structured.
The strategic supplier management process determines which IT suppliers are the most suitable ones
to contribute the resources and expertise required for the information provisioning. In addition, this
process determines the roles and responsibilities required by the IT suppliers that are chosen.
The purpose of the strategic user relationship management process is to define and control the
consistency, cohesion and communication between the information provisioning function and the users
organization. In addition, the communication channels between the users and BIM-organizations are
defined by this process.
The Strategic information partner management process enables information to be exchanged
between various organizations.
The aim of the Define I-organization strategy process is to define the required structure of the
functions which regulate the information provisioning within an organization.

Connecting processes at the strategic level: Information coordination

Align the different information plans which are drawn up by all other BiSL processes, manage the
overlaps.

What can you do with BiSL?

BiSL provides guidance to help you to structure and visualize the activities that take place within your
business information function and to locate any gaps between the supply and demand function within
your organization. BiSL can also help as a communication between the supply and demand functions
within your organization.

Service Level Management

A process-driven way of working to align the service (requirements) of the customer to the provisioning
of IT services by the IT provider.

The SLM (service level management) process is the conduit between IT and the business to represent
the operational capabilities of IT to the business.

In short: To make agreements about IT services.

Purpose
Ensure that all current and planned IT services are delivered to agreed achievable targets.
Ensure that all operational services and their performance are measured in a consistent professional
manner throughout the IT organization and that the services and the reports produced meet the needs
of the business and customers.

This is accomplished through a constant cycle to define, document, agree, monitor, measure, report and
review the level of IT services provided with the representatives of the business.

Main objective: define, document, agree, monitor, measure, report and review the level of IT services
provided with the representatives of the business.

Scope
SLM manages the SLAs and provides reviews and negotiations for services to the business. SLM
produces SLRs (service level requirements) that represents the business interests and requirements for
IT to satisfy through levels of service.
The scope of SLM is to provide a service for the customer and improve that service based on customer
needs. To do this, SLM must establish a relationship with the business and ensure that relationship is
maintained. SLM is a document-intensive process and ensures that SLAs, SLRs, OLAs and
underpinning contracts are established to support the service in accordance with business needs.

SLM strives to ensure that services meet the needs of the customer through providing high-quality
services, proactively preventing service failures, reviewing SLAs and SLA breaches, investigating
failures to services, and coordinating a service improvement program (SIP).

Business relationship management and service level management

Business relationship management is focused on a more strategic perspective of identifying the
customer needs and service level management focuses on the operational relationship between the
service provider and customer.

Key Concepts
Service level management is a document-intensive process. The documents produced and managed by
SLM include those described below.

Service level agreements

A SLA is a writing agreement between an IT service provider and the IT customer to define the key
service targets and responsibilities of both parties. SLAs are viewed as guidelines instead of
agreements. IT service management strives to understand the needs of the business and to meet those
needs. SLAs document these needs and the providers response to these needs.

Service-based SLAs cover the relevant issues of a specific service for all customers of that service.
Customer-based SLAs address all services for a single customer.
Multi-level SLAs: SLAs can be multi-leveled. Multi-level SLA structures may be developed to
customize a level of service for customers while still retaining re-usability and consistency.

Service level requirement

A SLR is a customer requirement for an aspect of an IT service. SLRs are based on business objectives
and are used to negotiate agreed SLTs (service level target).

Service level target

A SLT is a commitment to a specific level of service derived from SLRs. SLTs identify objectives. An
SLA documents one or more SLTs.

Operational level agreements

An OLA is an agreement between internal parts of the same organization to support services. OLAs
document the responsibilities of the various groups in IT. Through OLAs, the organization understands
its objectives, and roles are more clearly defined.

Underpinning contracts
An underpinning contract is an agreement between IT and an external third party. Underpinning
contracts help to support (or underpin) the agreements that IT has in place to deliver a service to the
business. SLM assists the supplier management in the review of these contracts to ensure that they are
appropriate for, and support, the needs of the business.
Activities
SLM is responsible for representing the capabilities of IT to the business as well as representing the
requirements of the business to IT.

The activities involved include:

Determining, negotiating, documenting and agreeing requirements for new or changed services
in SLRs, and managing and reviewing them through the service life-cycle into SLAs for
operational services
Monitoring and measuring service performance achievements of all operational services against
targets within SLAs
Producing service reports
Conducting service reviews, identifying improvement opportunities for inclusion in the CSI
register, and managing appropriate SIPs
Collating, measuring and improving customer satisfaction, in cooperation with business
relationship management
Reviewing and revising SLAs, service scope, and OLAs
Assisting supplier management to review and revise underpinning contracts or agreements
Developing and documenting contacts and relationships with the business, customers and other
stakeholders, in cooperation with the business relationship management process
Providing appropriate management information to aid performance management and
demonstrating service achievement
Logging and managing complaints and compliments, in cooperation with business relationship
management.
Designing SLA frameworks
Developing, maintaining and operating SLM procedures, including procedures for logging,
actioning and resolving all complaints, and for logging and distributing compliments
Making available and maintaining up-to-date SLM document templates and standards
Assisting with the design and maintenance of the service catalog
SLM does not perform all these activities itself, but works closely with other processes.

Roles
The service level manager is responsible for ensuring that the activities within SLM are being
performed. The specific service level manager responsibilities include:
Understanding customer requirements.
Establish SLAs.
Negotiating to service Levels.
Assisting to services portfolio and service catalog.
Produce reports.
Evaluate and improve services and the process.

Service level management process relationships

SLM is the process that represents the service to the customer. SLM must work with all other processes
to understand how a service is operating. Specific processes that SLM must work closely with:
Change management: SLM reviews the forward FSC (schedule of change) to communicate with the
customer. SLM assists with the impact assessment for changes to minimize impact to the business.
Service asset and configuration management: SLM refers to this to understand the composition of
the service.
Information security management
The management process within the corporate governance framework, which provides the strategic
direction for security direction for security activities and ensures objectives are achieved.

Central to ISM is the identification and mitigation of risks to the security of the organizations
information. The ISM process ensures that all security aspects are considered and managed throughout
the service life-cycle.

Organizations operate under an overall corporate governance framework, and ISM forms part of this
framework, ensuring risks are managed and the objectives of the organization are achieved.

Purpose, objectives, and scope of information security

Purpose: Ensure that IT security meets the requirements of the Overall Business Security
Objective: To protect the interests of those relying on information, and the systems and
communications that deliver the information, from harm resulting from failures of confidentiality,
integrity, and availability.

Information must be available only to those with the appropriate access rights.
Data must be protected from corruption and unauthorized alteration (integrity).
Identification and mitigation of risks to the security of the organizations information.
It ensures that all security aspects are considered and managed throughout the service life-cycle.
Data must be available when required (availability).
Secure exchange of data between organizations.
Business should define the scope: what is important and what is not.

Producing an information security policy

Understanding all security issues within the organization: business security policy, current and future
plans, risks, regulations.

Overall security policy specific security policies.

Must be authorized and sponsored by senior management!

IT security policies should include the following:

Use and misuse of IT assets policy.
An access control policy.
An email policy.
An Internet policy.
An anti-virus policy.
An information classification policy.
A document classification policy.
A remote access policy.
A policy with regard to supplier access to IT service, information, and components.
A copyright infringement policy for electronic material.
An asset disposal policy.
A records retention policy.
They must be widely available to all customers and users, and their compliance should be referred to in
all SLRs, SLAs, OLAs, underpinning contracts, and agreements.
They are stored in the SMIS (security management information system), the SMIS forms part of the
overall service knowledge management system (SKMS).

IT security manager
Tasks:
Making IT security policies.
Establish controls to manage access of third parties.
Manage deletion data of obsolete hardware.
Encrypt data devices.
Constantly reviewing potential threats.

ITIL
ITIL is a framework of best-practice guidance for IT service management. It is structured by a Service
Life Cycle approach, consisting out of five main phases:
1) ITIL Service Strategy.
2) ITIL Service Designer.
3) ITIL Service Transition.
4) ITIL Service Operational.
5) ITIL Continual Service Improvement (not treated in the extract below).

Service strategy
The service strategy of any service provider must be grounded upon a fundamental acknowledgement
that its customers do not buy products, they buy the satisfaction of particular needs. To achieve a deep
understanding of the customer needs the service provider needs to understand the wider context of the
current and potential market places that the service provider operates in. All providers need a service
strategy.

To thrive in the long term by building a clear strategy, i.e. a precise understanding of:
What service should be offered.
Who the service should be offered to.
How the internal and external market places for their services should be developed.
The existing and potential competition in these marketplaces, and the objectives that will
differentiate the value of what you do or how you do it.
How the customer(s) and stakeholders will perceive and measure value, and how this value will
be created.
How customers will make service sourcing decisions with respect to use of different types of
service providers.
How visibility and control over value creation will be achieved through financial management.
How robust business cases will be created to secure strategic investment in service assets and
service management capabilities.
How the allocation of available resources will be tuned to optimal effect across the portfolio of
services.
How service performance will be measured.
Key processes and activities:
Financial management covers the function and processes responsible for managing an IT service
providers budgeting, accounting and charging requirements. Many parts of the organization interact to
generate and use IT financial information.
Service portfolio management (SPM) involves proactive management of the investment across the
service life-cycle. It is an ongoing process which includes: define, analyze, approve and charter.
Demand management: Understand and influence customer demand for services and the provision of
capacity to meet these demands. A service level package (SLP) defines the level of utility and warranty
for a service package and is designed to meet the needs of a pattern of business activity (in other words
it can detect at which times there is not much demand and recommend to use the services at that time).

Key roles and responsibilities

Business Relation Manager (BRM): BRMs establish a strong business relationship with the
customer by understanding the customers business and their customer outcomes. BRMs work
closely with the Product Managers to negotiate productive capacity on behalf of the customers.
Product Manager (PM): PMs take responsibility for developing and managing services across
the life-cycle, and have responsibilities for productive capacity, service pipeline, and the
services, solutions and packages that are presented in the service catalogs.
Chief Sourcing Officer (CSO): the CSO is the champion of the sourcing strategy within the
organization, responsible for leading and direction sourcing office and development of the
sourcing strategy in close conjuction with the CIO.

Service design
The design of appropriate and innovative IT services, including their architectures, processes, policies
and documentation, to meet current and future agreed business requirements.

Main goals:
Design services to meet agreed business outcomes.
Design processes to support the service life-cycle.
Identify and manage risks.
Design secure and resilient IT infrastructures, environments, applications and data/information
resources and capability.
Design measurement methods and metrics.
Produce and maintain plans, processes, policies, standards, architectures, frameworks and
documents to support the design of quality IT solutions.
Develop skills and capability within IT.
Contribute to the overall improvement in IT service quality.

Key processes and Activities

Service catalog management (SCM) provides a central source of information on the IT services
delivered to the business by the service provider organization, ensuring that business areas can view an
accurate, consistent picture of the IT services available, their details and status.
Service level management (SLM) negotiates, agrees and documents appropriate IT service targets
with the business, and then monitors and produces reports on delivery against the agreed level of
service. The main information provided by the SLM process includes SLA, OLA and other support
agreements, and the production of the SIP and the Service Quality Plan.
Capacity management: Provide a point of focus and management for all capacity and performance-
related issues, relating to both services and resources, and to match the capacity of IT to the agreed
business demands. The Capacity management information system (CMIS) is the cornerstone of a
successful Capacity Management process.
The purpose of Availability management is to provide a point of focus and management for all
availability-related issues. It should take place at two inter-connected levels and aim to continually
optimize and proactively improve the availability. There are two key aspects: reactive activities
(monitoring, measuring, analysis and management of events, incidents and problems involving service
unavailability) and proactive activities (proactive planning, design, recommendation and improvement
of availability). It should consider the availability of services supporting Vital Business Functions
(VBFs). It should be based around an information system (AMIS).
IT service continuity management (ITSCM): Maintain the appropriate on-going recovery capability
within IT services to match the agreed needs, requirements and timescales of the business.
Information security management (ISM): Aligns IT security with business security and ensure that
information security is effectively managed in all service and service management activities, such that
information is: available and usable when required, observed by or disclosed to only those who have a
right to know is complete, accurate and protected against unauthorized modification.
Supplier management: Ensures that suppliers and the services they provide are managed to support IT
service targets and business expectations. The Supplier and Contract Database (SCD) is a vital source
of information on suppliers and contracts should contain all of the information necessary for the
management of suppliers.

Key roles and responsibilities

Service Design Manager: responsible for the overall coordination and deployment of quality
solution designs for services and processes
IT Designer/Architect: responsible for the overall coordination and design of the required
technologies, architectures, strategies, designs and plans
Service Catalogue Manager: responsible for producing and maintaining an accurate Service
Catalogue
Service Level Manager: responsible for ensuring that the service quality levels are agreed and
met
Availability Manager: responsible for ensuring that all services meet their agreed availability
targets
IT Service Continuity Manager: responsible for ensuring that all services can be recovered in
line with their agreed business needs, requirements and timescales
Capacity Manager: responsible for ensuring that IT capacity is matched to agreed current and
future business demands
Security Manager: responsible for ensuring that IT security is aligned with agreed business
security policy risks, impacts and requirements
Supplier Manager: responsible for ensuring that value for money is obtained from all IT
suppliers and contracts, and that underpinning contracts and agreements are aligned with the
needs of the business.
Service transition
To deliver services that are required by the business into operational use.

Service Transition focuses on implementing all aspects of the service, not just the application and how
it is used in normal circumstances. It requires sufficient understanding of:
Potential business value and who it is deliver to/judged by.
Identification of all stakeholders within supplier, customer and other areas.
Application and adaption of service design, including arranging for modification of the design,
where the need is detected during transition.

Key processes and activities

The whole life-cycle processes are: change management, service asset and configuration management,
and knowledge management.
Processes focused on service transition, but not exclusive to the stage are: transition planning and
support, release and deployment management, service validation and testing, and evaluation.

Service asset and configuration management (SACM) supports the business by providing accurate
information and control across all assets and relationships that make up an organizations infrastructure.
It is to identify, control and account for service assets and CIs.
Knowledge management: Ensure that the right person has the right knowledge, at the right time to
deliver and support the services required by the business. This delivers: more efficient services with
improved quality, clear and common understanding of the value provided by services, relevant
information that is always available.
The goals of transition planning and support are to: plan and coordinate resources and to identify,
manage and control the risks of failure and disruption across transition activities.
Release and deployment management: To assemble and position all aspects of services into
production and establish effective use of new or changes services.
The key purpose of service validation and testing is to provide objective evidence that the
new/changed service supports the business requirements, including the agreed SLAs.
Evaluation: Ensuring that the service will be useful to the business is central to successful Service
Transition and this extends into ensuring that the service will continue to be relevant.

Service operation
Purpose
To deliver agreed levels of service to users and customers, and to manage applications, technology and
infrastructure that support delivery of the services.

It is important to balance conflicting goals:

Internal IT view versus external business view.
Stability versus responsiveness.
Quality of service versus cost of service.
Reactive versus proactive activities.

Event management process: depends on monitoring, but it is different. It generates and detects
notifications, whilst monitoring checks the status of components even when no events are occurring.
Request fulfillment process: to enable users to request and receive standard services; to source and
deliver these services; to provide information to users and customers about services and procedures for
obtaining them; and to assist with general information, complaints and comments.
Access management process: to provide the rights for users to be able to access a service or group of
services, while preventing access to non-authorized users. It helps to manage confidentiality,
availability and integrity of data and intellectual property.
Common service operation activities: monitoring and control; console management/operations
bridge; management of the infrastructure; operational aspects of processes from other life-cycle stages.

Key functions
Service desk function: to provide a single central point of contact for all users of IT. It usually logs
and manages all incidents, service requests and access requests and provides an interface for all other
Service Operation processes and activities.
Technical management function: Technical management helps to plan, implement, and maintain a
stable technical infrastructure and ensure that required resources and expertise are in place to design,
build, transition, operate and improve the IT services and supporting technology.
Application management function: Very similar to Technical management, but with a focus on
software applications rather than infrastructure.
IT operations management function: Responsible for the management and maintenance of the IT
infrastructure required to deliver the agreed level of IT services to the business. It includes two
functions: IT Operations control and Facilities management.