Sie sind auf Seite 1von 159
1
2
3
4
5
6
7
8
9
10
11
12
Good Practice refers to practices which have been adopted and proven to work. Best practice

Good Practice refers to practices which have been adopted and proven to work. Best practice is an ideal we‟d like to attain but good practice is that which works best. ITIL is one source of Good Practice.

Adopting good practice can help a service provider to create an effective service management practice. Good practice is simply doing things that have been shown to work and to be effective. Good practice can come from many different sources, including public frameworks (such as ITIL, COBIT and CMMI), standards (such as ISO/IEC 20000 and ISO 9000), and proprietary knowledge of people and organizations.

14
15
Service: A Service is defined in ITIL as “ A means of delivering value to

Service: A Service is defined in ITIL as “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.” For example, A customer wants fast, accurate, secure, cost effective messaging from an email service. Without having to worry about costs and risks essentially means they leave that to the service provider who will ensure it is being backed up, secured, etc.

Service Management is defined as “Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.” These “specialized organizational capabilities” include all of the processes, methods, functions, roles and activities that a Service Provider uses to enable them to deliver services to their customers.

Service management is concerned with more than just delivering services. Each service, process or infrastructure component has a lifecycle, and service management considers the entire lifecycle from strategy through design and

transition to operation and continual improvement.

UTILITY is derived from the attributes of the service. (In other words, the service does

UTILITY is derived from the attributes of the service.

(In other words, the service does what the customer wants it to, making it easier for users to do their jobs).

WARRANTY is derived from the service being available when needed in sufficient capacity.

UTILITY is what the customer gets & WARRANTY is how it is delivered.

18
19
Measurable The performance of the process is incredibly important. Managers will want to measure the

Measurable

The performance of the process is incredibly important. Managers will want to measure the cost & quality. People involved operationally with the process are concerned with how long it takes and how easy it is.

Specific Results

The result of the process must be individually identifiable and countable.

Customers

Customers / stakeholders may be internal or external to the organisation but the process must meet their expectations.

Responds to a Specific Event

While a process may be ongoing or iterative, it should be traceable to a

specific trigger.

The Service Desk is a function. A specialised group of people who log calls and

The Service Desk is a function. A specialised group of people who log calls

and communicate with Users amongst other activities. responsible for specific outcomes, like closing calls.

They are often

A key characteristic of a process is that all related activities need not necessarily be

A key characteristic of a process is that all related activities need not necessarily be limited to one specific organisational unit.

Since processes and their component activities run through an entire organisation, individual activities should be mapped to defined roles. The roles and activities can then be coordinated by process managers.

Once detailed procedures and work instructions have been developed, an organisation must map the defined roles and the activities of the process to its

existing staff.

To assist with this task, an authority matrix is often used within organisations indicating roles & responsibilities in relation to processes and activities. The RACI Model is such a matrix.

Only one person is accountable for an activity, although several people may be responsible for executing parts of the activity.

In this model, responsible means end-to-end responsibility for the process. Responsibility should remain with the same person for all activities of a process.

The authority matrix clarifies to all involved which activities they are expected to fulfil, as well as identifying any gaps in process delivery and responsibilities. It is especially helpful in clarifying the staffing model necessary for improvement.

23
These roles are referenced again in the CSI section of the course though of course

These roles are referenced again in the CSI section of the course though of course all processes should have an owner.

25
26
27
28
29
 Who ? (other IT teams, Users, Internal Customers, etc.)  What ? (shift handover,

Who ? (other IT teams, Users, Internal Customers, etc.)

What ? (shift handover, performance reports, changes, etc.)

How ? (e-mail, phone, pager, fax, text message, etc.)

31
Event Management & Monitoring are closely related, but slightly different in nature. Event Management is

Event Management & Monitoring are closely related, but slightly different in nature.

Event Management is focused on generating & detecting meaningful notifications about the status of the IT Infrastructure and Services.

Whilst Monitoring detects & tracks such notifications, its scope is somewhat broader.

For example, monitoring tools will check the status of a device to ensure that it is operating within acceptable limits, even if that device is not generating Events.

Event Management works with occurrences that are specifically generated to be monitored.

Monitoring tracks these occurrences, but it will also actively seek out

conditions that do not generate Events

33
34
An Incident Model is a standardised way of dealing with incidents that have happened before.

An Incident Model is a standardised way of dealing with incidents that have happened before.

The term „ Service Request ‟ is used as a generic description for many varying

The term „Service Request‟ is used as a generic description for many varying types of demands that are placed upon the IT Department by the Users.

Many of these are actually small changes low risk, frequently occurring and low cost (such as a request to reset a password or install additional software).

Their scale and frequency and low risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident & Change Management processes.

37
38
39
Access Management provides the rights for Users to access Services, executing policies defined in Availability

Access Management provides the rights for Users to access Services, executing policies defined in Availability & Security Management.

Access to the level and extent of a Service‟s functionality or data that a User is entitled to

Identity of Users that distinguishes them as an individual, which verifies their status within the Organisation

Rights (also called privileges) of the actual settings through which a User is provided access to a Service or group of Services (read, write, execute, change & delete)

Directory Services of a specific type of tool that is used to manage Access & Rights

41
42
The KEY aspect of a Local Service Desk is that the users/customers and the Service

The KEY aspect of a Local Service Desk is that the users/customers and the Service Desk are in one location. Typically support groups will also be co- located but this is not always the case. This co-location can be seen as both a benefit and a problem.

44
Understanding of the concepts of role, aim & overlap is important for the Foundation Examination.

Understanding of the concepts of role, aim & overlap is important for the Foundation Examination.

Technical Management supports the Organisation‟s Business Processes through:

well designed & highly resilient technological topology

the use of technical skill to optimise technology

swift diagnosis & resolution of technical failures

Understanding of the concepts of role, objectives & overlaps is important for the Foundation Examination.

Understanding of the concepts of role, objectives & overlaps is important for the Foundation Examination.

IT Operations Management divides into two main areas IT Operations Control & Facilities Management.

IT Operations Control oversees the execution and monitoring of the operational activities and events in the IT Infrastructure typically with the assistance of an Operations Bridge or Network Operations Centre.

They are tasked with performing the activities of console management, job scheduling, backup & restore, print & output management and ongoing maintenance activities on behalf of technical/application teams.

Facilities Management manage the physical IT environment, such as a data centre or computer room & recovery sites together with all power and cooling equipment. In some cases the management of a data centre is outsourced, in such cases FM refers to the management of the outsourcing contract.

IT Operations Management is responsible for executing the activities and performance standards defined during Service Design and tested during Service Transition.

Understanding of the concepts of role, objectives & overlaps is important for the Foundation Examination.

Understanding of the concepts of role, objectives & overlaps is important for the Foundation Examination.

Application Management plays a role in all applications, whether purchased or developed in-house. One of the key decisions that they contribute to is the decision of

Application Management operates in two ways:

- acting as a custodian of technical knowledge and expertise related to managing applications and

- providing the resource to support the IT Service Management Lifecycle

This ensures that the organisation has access to the right type and level of human resources to manage applications and thus to meet Business

objectives.

This starts in Service Strategy, is expanded in Service Design, tested in Service Transition and refined in Continual Service Improvement.

48
49
50
51
52
53
54
55
56
57
58
59
60
Consistent, ongoing improvement sits at the core of CSI thinking but how do we achieve

Consistent, ongoing improvement sits at the core of CSI thinking but how do we achieve this ?

The Deming Cycle is critical at the implementation of Service improvements drawing on all four stages (Plan, Do, Check & Act).

With ongoing improvements, CSI utilises the Check & Act stages to monitor, measure, review and implement initiatives.

The cycle is underpinned by a process-led approach to management where defined processes are in place, the activities are measured for compliance to expected values and outputs are audited to validate and improve the process.

What is the Vision ? - identifying the What‟s In It For Me (WIIFM) and

What is the Vision ?

- identifying the What‟s In It For Me (WIIFM) and selling the improvement to the

stakeholders and establishing the mutually agreed desire & intent (including when &

where to start)

Where are we now ? - establishing a baseline across the 4 P‟s (People, Process, Partners, Product) and benchmarking against standards (such as ISO20000)

Where do we want to be ?

- undertaking the Gap Assessment, developing the Business Case and setting the short, medium, long term goals & objectives

How do we get there ?

- identifying how are the changes going to be achieved, defining the scope and Terms

of Reference (TOR) for the project along with project plan (including the critical path, milestones, specific deliverables)

How do we know we have arrived ?

- using metrics and conducting a Post Implementation Review (PIR)

How do we stay there ?

- applying the CSI principles through on-going review & audit

There are four reasons to monitor & measure: • to validate previous decisions • to

There are four reasons to monitor & measure:

• to validate previous decisions

• to set direction for activities in order to meet set targets

• to justify the requirement for a course of action

using appropriate evidence

• to identify the suitable point of intervention along with the required changes & corrective actions

When measuring we should take baselines

Baselines act as an initial data point to determine if a Service or process actually needs to be improved. For this reason it is essential to collect data at the outset, even if the integrity of

the data is in question. They should be documented,

recognised & accepted throughout the Organisation.

An Organisation will need to collect to metrics regarding Technology, Process & Service in order

An Organisation will need to collect to metrics regarding Technology, Process & Service in order to support CSI activities.

There are three types of metrics that an organisation will need to collect to support CSI activities:

Technology Metrics such as the performance and availability of components and applications etc.

Process Metrics – captured in the form of Critical Success Factors (CSF‟s) and

their related Key Performance Indicators (KPI‟s)

Service Metrics the results of the end-to-end Service (usually based on component metrics)

Knowledge Management (KM) uses the KPI metrics to track trends, productivity, resources and much more.

KPI‟s provide answers to the questions around quality, performance, value & compliance. CSI uses these metrics as input in identifying improvement opportunities for each process.

To be effective, metrics & measurement should encompass the whole organisation (the strategic as well as tactical level).

The role of a process owner and process manager may be separate or combined. The

The role of a process owner and process manager may be separate or combined. The process manager will often be in charge of actually running the process on a day to day basis. The process owner does NOT do this job.

66
67
68
69
70
71
72
73
74
This achieved using three KEY types of Service Provider which represent an organisation supplying services

This achieved using three KEY types of Service Provider which represent an organisation supplying services to one or more Customers.

There are three types of Service Provider:

Internal - embedded within a Business function, provides specialised IT Services (a team managed by and developing applications for just one business function)

Shared Service Unit (SSU) - provides Services to Business Units as Customers (a Service Desk supporting the whole organisation)

External - 3 rd Party Supplier providing IT Services (an outsourcer)

The Service Portfolio covers all services - whether in development, live or retired. The Service

The Service Portfolio covers all services - whether in development, live or retired.

The Service Catalogue deals with live and retired services and the Service Pipeline deals with services in development.

The Business Service Catalogue: containing details of all the IT services delivered to the customer,

The Business Service Catalogue: containing details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalogue.

The Technical Service Catalogue: containing details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. This should underpin the Business Service Catalogue and not form part of the customer view.

78
79
80
81
82
83
84
A User Profile is a pattern of User demand for IT Services. Each User Profile

A User Profile is a pattern of User demand for IT Services. Each User Profile includes one or more Patterns of Business Activity. In other words, if you can predict how users will use services, you an predict the associated infrastructure needs.

86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
Many designs, plans and projects fail through a lack of preparation and management. The implementation

Many designs, plans and projects fail through a lack of preparation and management. The implementation of ITIL Service Management as a practice is about preparing and planning the effective and efficient use of the 4P‟s.

The 4P‟s represents the infrastructure required to deliver services to the Business.

Designing the service solutions includes understanding and agreeing the Business‟ functional requirements including the

Designing the service solutions includes understanding and agreeing the Business‟ functional requirements including the capabilities needed and all the resources required. Every time a new service solution is produced it needs to be checked to ensure that it will integrate and interface with all of the other services in existence.

Service Management systems & tools like the Service Portfolio are essential for the management and control of services through their lifecycle.

The design of the technology & management architectures represents the

development and maintenance of IT policies, strategies, architectures, designs, documents, plan and processes for the deployment and subsequent operation and improvement of IT services and solutions.

Only measurements that encourage progression towards meeting business objectives or desired behavioural change should be selected but if you can‟t measure it, then you can‟t manage it.

Services and the processes behind them should be “fit for purpose” so our metrics must be created to measure the „quality‟ of the solutions against the Business requirements in terms of Progress, Effectiveness, Efficiency & Compliance.

105
106
107
The generic process shows data entering the process ( INPUTS ), moving through the process

The generic process shows data entering the process (INPUTS), moving through the process (PROCESSING), and exiting the process (OUPUTS), the outcome being subject to measurement & review.

This very basic description underpins any process description. A process is always organised around a set of objectives.

The main output from the process should be driven by the objectives and should always include process measurements (metrics), reports & process improvement.

For Example:

The objectives of a Change Management process may be to make a change which solves a problem, within time & cost constraints.

Each process should be owned by a process owner who should be

responsible for the process and its improvement and for ensuring that a

process meets its objectives. The objectives of any IT process should be defined in measurable terms and should be expressed in terms of business benefits.

109
110
The key objective of the Service Catalogue Management process is To ensure that a Service

The key objective of the Service Catalogue Management process is To ensure that a Service Catalogue is produced and maintained, containing accurate information on all operational services and those being prepared to be run operationally.

112
113
114
115
116
117
118
Business Capacity Management This sub-process translates business needs and plans into requirements for service and

Business Capacity Management

This sub-process translates business needs and plans into requirements for service and IT infrastructure, ensuring that the future business requirements for IT services are quantified, designed, planned and implemented in a timely fashion.

Service Capacity Management

The focus of this sub-process is the management, control and prediction of the

end-to-end performance and capacity of the live, operational IT services usage

and workloads. It ensures that the performance of all services, as detailed in service targets within SLA's and SLR's, is monitored and measured, and that the collected data is recorded, analysed and reported.

Component Capacity Management

The main objective of Component Capacity Management (CCM) is to identify

and understand the performance, capacity and utilisation of each of the

individual components within the technology used to support the IT services. This ensures the optimum use of the current hardware and software resources in order to achieve and maintain the agreed Service Levels.

120
121
122
Availability: Often measured and reported as a percentage: (Agreed Service Time (AST) – downtime) Availability

Availability: Often measured and reported as a percentage:

(Agreed Service Time (AST) downtime) Availability (%) = ———————————---------------------- Agreed Service Time (AST)

X 100 %

Note:

Downtime should only be included in the above calculation when it occurs within the Agreed Service Time (AST). However, total downtime should also be recorded and reported.

Reliability:

the reliability of the service can be improved by increasing the reliability of individual components or by increasing the resilience of the service to individual component failure (i.e. increasing the component redundancy, e.g. by using load-balancing techniques). It is often measured and reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between Failures (MTBF)

Maintainability:

a measure of how quickly and effectively a service, component or CI can be restored to normal working after a failure. It is measured and reported as Mean Time to Restore Service (MTRS)

124
125
126
127
128
Produce a clear Statement of Requirements (SoR) that identifies the Business Requirements together with the

Produce a clear Statement of Requirements (SoR) that identifies the Business Requirements together with the mandatory facilities and those features that it would be „nice to have‟.

Also identify the site policies & standards to which the product must conform.

Such standards may include it running under particular system software or on specific hardware.

130
131
132
133
134
135
136
137
138
139
140
141
Configuration Baseline is defined as “ A Baseline of a Configuration that has been formally

Configuration Baseline is defined as “A Baseline of a Configuration that has been formally agreed and is managed through the Change Management process. A Configuration Baseline is used as a basis for future Builds, Releases and Changes.”

Often, data and information is collected with no clear understanding of how it will be

Often, data and information is collected with no clear understanding of how it will be used and this can be costly.

Efficiency and effectiveness are delivered by establishing the requirements for information. In order to make effective use of data, in terms of delivering the required knowledge, a relevant architecture matched to the organisational situation and the knowledge requirements is essential.

The CMS typically contains configuration data and information that combines into an

integrated set of views for different stakeholders through the Service Lifecycle. It therefore needs to be based upon appropriate web, reporting and database technologies that provide flexible and powerful visualisation and mapping tools, interrogation and reporting facilities.

Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and optimise costs.

Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB and subsequently to compare the actual „Live‟ configuration with the information and records stored in the CMS.

High-level activities for SACM are shown in the diagram. Typical roles to achieve effective and

High-level activities for SACM are shown in the diagram.

Typical roles to achieve effective and efficient SACM include:

Service Asset Manager to design & maintain the Asset Management Systems and to implement Service Asset Management Policy & Standards

Service Knowledge Manager to design & maintains the Knowledge Management Strategy, Process & Procedures

Configuration Manager to design & maintains the Configuration Management System, to agree the scope of the process, identify naming conventions, etc.

Configuration Analyst to create processes & procedures and provide training

Configuration Librarian to control receipt, identification & storage of CI‟ and master copies of software

CMS Tools Administrator to amend the database to suit Business Requirements and undertake regular housekeeping

Service Change is defined as “ The addition, modification or removal of anything that could

Service Change is defined as “The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation, etc.”

Where do changes come from? There are a number of possible areas service and amendments

Where do changes come from? There are a number of possible areas

service and amendments from the Service Portfolio, Service Desk, Service Level Management and the users. System enhancements from service provider staff can be added to many break/ fix types changes coming from areas such as Problem Management, Incident Management.

new

147
The above questions must be answered for all changes. Without this information, the impact assessment

The above questions must be answered for all changes.

Without this information, the impact assessment cannot be completed, and the balance of risk and benefit to the live service will not be understood. Responsibility for evaluating major Change should be also be defined.

Final responsibility for the IT service including Changes to it will rest with the Service Manager and the Service Owner who control the funding available and will have been involved in the change process through direct or delegated membership of the Change Advisory Board (CAB).

The latest versions of these documents will be available to stakeholders within the organisation, preferably contained within a commonly available Internet or intranet server. This can usefully be reinforced with a proactive awareness programme where specific impact can be detected.

The Change Advisory Board (CAB) is defined as “ A group of people that advises

The Change Advisory Board (CAB) is defined as “A group of people that advises the Change Manager in the Assessment, prioritisation and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, the Business, and Third Parties such as Suppliers.”

The Emergency Change Advisory Board (ECAB) is defined as “A sub-set of the Change Advisory Board who make decisions about high impact Emergency Changes. Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.”

Remediation is defined as “Recovery to a known state after a failed Change or Release.” This gives rise to the term “Remediation Planning”. This ensures that contingency exists in case of a failed change. This might be as simple as reverting to a previous software version or to a known state after a major infrastructure change where reversion may not be possible.

150
The Definitive Media Library (DML) is the secure library in which the definitive authorised versions

The Definitive Media Library (DML) is the secure library in which the definitive authorised versions of all media CI‟s are stored and protected. It may consist of one or more software libraries or file-storage areas, separate from development, test or live file-store areas and contains the master copies of all controlled software in an Organisation.

The DML should include definitive copies of purchased software (along with licence documents or information), as well as software developed on site.

Master copies of controlled documentation for a system are also stored in the DML in

electronic form.

The DML will also include a physical store to hold master copies (e.g. a fireproof safe).

Only authorised media should be accepted into the DML, strictly controlled by SA&CM.

Definitive Spares These spare components & assemblies are maintained at the same level as the comparative systems within the Live environment.

Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS.

These can then be used in a controlled manner when needed for additional systems or in the recovery from Incidents

Release Unit is defined as “ Components of an IT Service that are normally Released

Release Unit is defined as “Components of an IT Service that are normally Released together. A Release Unit typically includes sufficient Components to perform a useful Function. For example one Release Unit could be a Desktop PC, including Hardware, Software, Licenses, Documentation etc. A different Release Unit may be the complete Payroll Application, including IT Operations Procedures and User training.”

A Release Policy establishes the rules around a release:

Unique identification

Roles and responsibilities

Frequency of types of releases

Major

Minor

Emergency

Approach to accepting and grouping changes into a release

Mechanisms for effective and efficient handling of release stages

Use and maintenance of configuration management database

Entry and exit criteria leading to authorization of a release

Handover to operations and early life support

153
154
155
156
157
158