1

10

11

12

Good Practice refers to practices which have been adopted and proven to work. Best practice is an ideal wed 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.

13

14

15

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.

16

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.

17

18

19

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.

20

The Service Desk is a function. A specialised group of people who log calls and communicate with Users amongst other activities. They are often responsible for specific outcomes, like closing calls.

21

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.

22

23

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

24

25

26

27

28

29

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

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

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

30

31

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

32

33

34

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

35

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.

36

37

38

39

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 Services 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

40

41

42

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 colocated but this is not always the case. This co-location can be seen as both a benefit and a problem.

43

44

Understanding of the concepts of role, aim & overlap is important for the Foundation Examination. Technical Management supports the Organisations Business Processes through: well designed & highly resilient technological topology the use of technical skill to optimise technology swift diagnosis & resolution of technical failures

45

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.

46

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.

47

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 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.

61

What is the Vision ? - identifying the Whats 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 Ps (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

62

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.

63

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 (CSFs) and their related Key Performance Indicators (KPIs) 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. KPIs 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).

64

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.

65

66

67

68

69

70

71

72

73

74

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 - 3rd Party Supplier providing IT Services (an outsourcer)

75

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.

76

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.

77

78

79

80

81

82

83

84

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.

85

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 of ITIL Service Management as a practice is about preparing and planning the effective and efficient use of the 4Ps. The 4Ps represents the infrastructure required to deliver services to the Business.

103

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 cant measure it, then you cant 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.

104

105

106

107

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.

108

109

110

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.

111

112

113

114

115

116

117

118

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.

119

120

121

122

Availability: Often measured and reported as a percentage: (Agreed Service Time (AST) downtime) Availability (%) = ---------------------- X 100 % Agreed Service Time (AST) 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)

123

124

125

126

127

128

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.

129

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 agreed and is managed through the Change Management process. A Configuration Baseline is used as a basis for future Builds, Releases and Changes.

142

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.

143

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

144

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.

145

Where do changes come from? There are a number of possible areas...new 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.

146

147

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.

148

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.

149

150

The Definitive Media Library (DML) is the secure library in which the definitive authorised versions of all media CIs 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

151

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

152

Handover to operations and early life support

152

153

154

155

156

157

158