ITIL V2 Service Management - Study Notes

[TYPE THE COMPANY NAME]

ITIL Service ManagementV2

7/10/2010 ITIL Service Management is a framework of good practice me Delivering and Supporting IT Services which are aligned and business requirement. As business becomes more and more quality of its services becomes critical for the success of the proven methodology such as ITIL can drive change towards t and its success.

ContentsNo table of contents entries found.

Service DeskObjective: To provide a central point of contact for customers.

To facilitate restoration of normal service with minimal business impact and within agreed service levels.

There are 3 types of Service Desks Local Service Desk Located internally to the business in same site as the business

Centralised Service Desk Located in one site however may support the business in various regional sites.

Virtual Service Desk Located in several sites and all have access to a central database and share knowledge so there is no impact to the customer.

A Service Desk can provide the following: Single Point of Contact (SPOC) Technical Support (Depends on skill level) Functional Support (Basic access to applications, printing etc) Training Service Request process Monitoring (proactive monitoring of services) Management Reporting

Inputs: Service Requests Incident information Requests for Change (RFC) from users SLAs from Service Level Management Service Catalogue from Service Level

Outputs: Reports to other processes Problem records Request for Change to ChM Reports on performance vs SLA Reports per service

ITIL Service Management V2

Page |3

Mgt Urgency and Impact classifications from Incident logs Bus IT Service Continuity Plan from ITSCM Budget for resources from FM Cost information to FM (Function, Call etc) Incidents from Monitoring tools Closed incidents Capacity Plan Availability Plan Forward Schedule of change Release notes and install instructions

Benefits: Minimise downtime and impact on customer from incidents As the Service Desk will ensure once an incident is logged it will be directed to the correct support team for investigation and resolution this means a faster restoration of service if possible. If the Service Desk was not in place the wrong support team which does not have the relevant skills required to resolve the issue may be used and thus delay restoration of service.

Automation of manual tasks As a central point of contact it means different methods and tools can be used to identify and record incidents or requests. For example an Incident logged by the user is already logged in the system and does not require the user to call a service desk and then explain and have the Service Desk then manually enter the details into the log. Also if good monitoring tools are in place its possible incidents or threshold breaches are identified by a tool and an incident logged without a technical team using there time to constantly monitor this manually.

Management information for reporting By making one point of contact and using one database to log all requests and incidents management is able to collate valuable information which could be used for reporting and analysis.

Reduction in costs As all contacts are made to a central point the Service Desk ensures that other support teams are not interrupted and maintain productivity whilst the Service Desk classifies the Incident and then either resolves on first call or escalates directly to the support team which can assist. This reduces time spent by the business and IT in finding who is the right person. Also the information from the business is only given once to

IT and it is logged and available even after esacalation. The reduced time represents cost savings both to IT and the business in terms of wages and potentially lost revenue.

Improved customer satisfaction By providing the business with a customer facing contact point which is trained to deal with customers on a daily basis this will increase customer satisfaction and they will feel IT is listening and understanding their needs better.

Activities:

Incident Detection & Recording (Receive calls, Automated Tool detection) Recording and tracking of incidents, complaints and requests Keeping customers informed on progress of requests Make initial assessment of requests and attempt to resolve or refer them to someone with more appropriate skills based on agreed service levels Monitor and escalate as per agreed in the SLA Manage the request from registration to closure Communication short term impacts to Service Levels (maintenance outage) Co-ordinating 3rd Party suppliers support Provide management information and service improvement recommendations Identify problems Highlight customer training needs

Relationships: Incident Management: Problem Management:


Page |5

SD assists PM in identifying problems Problem Management provides known errors via the KEDB which is used by Service Desk to resolve incidents within the agreed timeframes

Change Management: ChM provides a FSC so that SD is prepared and can communicate to the users Forwards on RFC from users to ChM for processing

Configuration Management: SD can identify inaccuracies within the CMDB and could be responsible for updating sections of the CMDB CM provides valuable information via the CMDB to assist SD to identify priority of an incident and assists in finding resolution by giving access to data such as relationships between Configuration Items and also KEDB.

Release Management: SD can assist RM in testing and co-ordinating users in testing of new releases RM provides documentation of new releases including release notes and install guides for SD

Service Level Management: The Service Desk relies on outputs from Service Level Management (Service Catalogue and SLA) SD relies on Service Level Management to communicate to the customer about the Service Desk to ensure the message is passed to users benefits of the service desk and why they must use it. Provides management information to SLM via reporting so SLM can measure performance against SLAs

Financial Management: Provides the budget for the SD to pay for its resources including staff, tools, training etc Provides information on costs of supporting IT Services, wages, tools, training etc.

Availability Management:

Availability Improvement plans covering all key areas of Availability, Reliability, Maintainability, Serviceability and Security (ARMSS) which will be a driver for improvement of the Service Desk Provides management information via reporting and incident logs regarding availability performance and issues. These can be used to identify gaps between performance vs SLAs and help formulate Availability Improvement plans.

Capacity Management: Monitoring tools checking capacity levels for breaches can be automated to create incidents in a proactive attempt to minimise incidents created by capacity issues. SD can monitor as part of their proactive tasks and identify issues with capacity early on and report to capacity management to take preventive action.

IT Service Continuity Management: ITSCM provides SD with the ITSCM plan to be used in case of an abnormal emergency situation. SD will be part of testing of any ITSCM plan and also will form part of the escalation process within the ITSCM plan

Service Desk Implementation PLAN


Page |7

Where do we want to be: Business Objectives Agreed SLAs Budget

Where are we now: Assessment Baseline of current situation Assess current Staffing Skills Tools Gap Analysis

How are we going to get there? How do we know when we have arrived: Audit of process Process reports Assign roles Document new procedures

Service Desk Implementation PROJECT Where do we want to be: Business Objectives Agreed SLAs Budget




Page |9

Incident Management

Objective: To restore Service to the agreed level as agreed as quickly as possible and minimise business impact from events which cause or may cause an interruption or reduction in the quality of service.

Inputs: Incident information Information on Configuration Items from CMDB SLA targets for Incident resolution Approved workarounds Preapproved changes linked to Service Requests Known Error Database KEDB Response on RFCs linked to Incidents

Outputs: Closed incident Logged incident Reporting on incident resolution times Communication to customers on closure Communication to customers on progress Results from incident matching RFCs for incident resolution

Benefits:

Reduced business impact As incidents are processed through a clear workflow with referral to appropriate support teams as required and application of approved work-arounds where available service is able to be restored quickly and minimise the impact to the business as availability is

increased and thus productivity also increased for the business.

Availability of business focused reporting linked to SLAs By recording and capturing all data related to an incident and the corresponding SLA this information can be used to provide reporting of the performance and achievements of the IT Service against the SLA.

Better staff utilisation By correctly categorising and setting priority to incidents they will be referred quickly to the relevant support team for investigation and diagnosis. This removes the potential for users to contact other users or other IT support teams who are not skilled to resolve the issue which would reduce productivity of these staff as they try to resolve something which they are not trained to do. This will also cause double handling and a longer delay in resolution so loss of productive time to the business for the users impacted.

Capturing of All incidents and requests Without a process, trained staff and a tool in place to record all incidents and requests there would be a lot of information not being recorded and therefore any reporting would be inaccurate and management would and the business would not have a true understanding of what is happening or how and where to improve.

More accurate CMDB As each time an incident is logged IM will check the CMDB for effected CIs this is also an opportunity to review the accuracy and variances can be picked up at this stage and feedback to Config Management or updated directly where authority it given to do this.

Improved customer satisfaction By maintaining contact with the customer from logging of the incident until closure the customer will feel IT is providing a better service.

Activities: Incident Detection and Recording Record basic details of the incident (Who, What, When, Where?) Alert a specialist group if necessary P a g e | 11


Classification and initial support Categorise the Incident (HW, SW, Network) Determine priority based on Urgency and Impact assessment Match against Known Errors from KEDB Inform Problem Management of any new Unkown Errors (New Problem Record) Provide initial support Escalate to specialist group if required Advise Customer action to be taken and agreed timeframe for restoration of service

Investigation and Diagnosis Assess the details of the incident Collection and analysis of all related information Provide work-around where possible Escalation of Incident (Hierarchial or Functional) until resolved

Resolution and Recovery Apply the work-around or submit RFC to solve the incident Take recovery actions Update the incident record

Incident Closure Confirm successful restoration and closure with customer or user Update Incident status to Closed Reclassify the incident where necessary (Depends on SLA time delay may have increased priority) Detail all actions taken and meaningful information found related to the incident and its resolution

Ensure accuracy of all data in this incident log

Incident Ownership, Monitoring, Tracking and Communication Monitor incident progress Escalation of Incident (Hierarchical or Functional) until resolved Provide the user with regular updates on progress of incidents

* Note These steps are to be done throughout the lifecycle of the incident to ensure incident is progressing satisfactorily through to achieve the resolution within the defined SLA.

Relationships: Service Desk: Problem Management: PM provides information on Known Errors via the KEDB so IM can apply workarounds and restore service quickly Refers incidents with Unkown Errors (No linked Problem records) for logging and investigation by PM SD takes ownership of all incidents from end to end even if escalated to other functional groups

Change Management: ChM provides approval of RFCs for the resolution of incidents IM sends RFCs to resolve incidents

Configuration Management: CM provides information related to CIs, Known Errors to link incidents to and improve resolution times IM identifies variances in CMDB to actual in the live environment and recommends changes or updates where possible

Release Management: ITIL Service Management V2 P a g e | 13

RM will implement changes to resolve incidents IM will play a role in testing of the release

Service Level Management: SLM provides SLAs regarding response and restoration times for incidents IM provide management information by way of reports on performance achievement linked to the SLAs

Financial Management: FM Provides budget to fund process resources, tools and training IM provides costs related to Incidents, resources used, time taken and cost per incident

Availability Management: Availability Improvement Plan which would drive improvements also within the IM Process IM will provide management information on performance of availability to be measured against SLAs and can be used to identify gaps in process leading to further improvement plans

Capacity Management: Capacity monitoring tools are used to identify breaches in capacity thresholds which would then be logged as an incident. This could be automated by systems and result in an incident. IM provides reports to CapM on incidents related to capacity and can be linked to SLAs. This can be used to identify gaps and action can be taken as part of a Capacity improvement plan.

IT Service Continuity Management: ITSCM plans are provided by ITSCM to IM so they understand their role in the ITSCM plan if it is invoked. IM would be a part of any testing of the ITSCM plan

Incident Management Implementation PLAN Where do we want to be: Business Objectives Agreed SLAs Budget


How are we going to get there? How do we know when we have arrived: Audit of process P a g e | 15 Assign roles Document new procedures


Process reports

Incident Management Implementation PROJECT Where do we want to be: Business Objectives Agreed SLAs Budget


How are we going to get there? Assign roles Document new procedures

How do we know when we have arrived: Audit of process Process reports

Problem ManagementObjective: To minimise the impact of incidents and problems on the business that are caused by errors and to prevent the recurrence of incidents related to these errors. It aims to identify the root cause of incidents and initiate actions to improve or correct the situation. Inputs: Incident details From IM Configuration details from the CMDB Work-arounds identified via IM Outputs: Known Errors (KEDB) for IM RFC Problem Records Major Problem Reviews


P a g e | 17

Benefits: Improved IT Service Quality Problem Management can improve the ability of IT to restore service quickly through the application of workarounds from the Known Error database. This represents reduced downtime for a service and thus increased the quality of the service.

Reduction in volume of incidents By solving a single problem many incidents could be prevented as usually a problem is linked to several incidents. When a RFC is successfully implemented and the solution is applied to correct the known error this will prevent repeat incidents and reduce the overall number of incidents.

Gradual reduction in volume of problems As more and more permanent solutions are applied to problems over time this will reduce the total number of problems as there will not be repeats of the same problem.

Learning from past experience The concept of Problem Management encourages learning from previous experience and documenting so this can be used and passed on to other generations of staff or other functions/processes. This learning means we can prevent future incidents by tapping into this knowledge.

Increased staff productivity The time saved by applying a work-around to a known error or from a permanent solution applied to a known error will directly turn into more time that the staff within the business and support functions are productive in other areas. This can lead to additional revenue through business staff or reduced cost for support.

Better first call resolution at Service Desk By making the known errors available to the Service Desk via the KEDB they can quickly link the incident with the Known error and apply the work-around thus providing a fast and efficient service.

Activities: Reactive: Incident Matching and Analysis This is the linking of an incident record to an existing problem or known error record. This can be done via IM/SD or by other processes like Capacity and Availability through monitoring and analysis of

data. Problem Control When a problem is logged it is an unknown error until problem control can investigate and find a workaround at which point it is classed as a Known Error and is updated in the KEDB to be available for use by SD/IM to link new incidents with the Known Error and thus speed up the resolution of these future related incidents. Problem Identification and recording Description of problem and check if work-around exists.

Problem Classification Categorisation, Impact, Urgency and Priority

Problem investigation and diagnosis Identify root cause and create work-around

RFC and Problem resolution closure Submit RFC and close problem record

Error Control A known error is passed to Error Control to find the solution which could be done internally with specialist support group or via 3rd party supplier involvement. The solution is found and then a Request For Change RFC is usually submitted to correct the error and prevent future incidents related to this error. Error identification and recording Change status of Problem to Known Error

Error assessment Identify solution and submit RFC to implement

Record error solution Recording the solution to the error

Close error and associated problems Close all problem records and remove any work-arounds as they are no longer relevant.

Proactive: Trend analysis Detailed analysis of data relating to IT Infrastructure


P a g e | 19

operation with the aim of finding problems.

Targeting Preventative Action The classification and prioritisation of the problem which is then feedback to management or a RFC is submitted where possible.

Relationships: Service Desk: PM will provide recommendations for education and training of users where the problem is related to human error and therefore a change in user behaviour will result in the correction of the problem PM provides work-arounds to assist SD to resolve Incidents within agreed timeframes by updated Known Errors in the KEDB. SD links incidents with Known Errors and Problems records

Incident Management: PM finds solutions to problems to minimise incidents thus reducing the volume of workload for IM and possibly reducing cost of IM to IT. IM provides data on incidents which can be analysed by PM to look for trends in CI failures which could be linked to a problem.

Change Management: Submits RFC to correct errors in CIs which are causing problem related incidents. Approval of RFCs to correct errors in CIs PM is a member of the CAB

Configuration Management: PM once a solution has been found to a problem usually a change to a configuration item will be required to correct the problem. This will be done through the ChM process. CM will provide data on configuration items which can be used by PM to investigate root cause and find solutions to problems.

Release Management: PM

RM will provide known errors which were identified through testing and development that were not solved prior to release to the live environment. These would be logged and added to the known error database and passed to error control to find solution.

Service Level Management: SLM will provide SLAs and OLAs regarding response and restoration targets for PM to use as guide to assist is classifying and prioritisation of problem records. PM will management information related to achievements to SLM so they can communicate to the customer the level of work done to prevent future incidents and thus improve customers perception of the level of service.

Financial Management: Provides budget to finance the cost of the staffing, process, tools. Provides cost information on staffing requirements and wages and overall cost of problems to the IT Service provider.

Availability Management: AM will monitor and analyse data which could identify problems and thus create a problem record. Also AM is a proactive approach to minimising impact of incidents on the business which is directly in line with Proactive Problem management. AM also conducts SOA Service Outage Analysis which is in line with Major Problem Review.

Capacity Management: IT Service Continuity Management:


P a g e | 21

Problem Management Implementation PLAN Where do we want to be: Business Objectives Agreed SLAs Budget




Problem Management Implementation PROJECT Where do we want to be: Business Objectives Agreed SLAs Budget


How are we going to get there? Assign roles P a g e | 23


Document new procedures


Change ManagementThe process of moving from one defined state to another Objective: To ensure standard methods and procedures are used to efficiently handle changes in order to minimise impact of change related incidents on service quality and the normal operation of the business.

Inputs: Request For Change (RFC) CMDB information Forward Schedule of Change (FSC)

Outputs: Reviewed/Implemented RFC Closed change record CAB minutes

Projected Service Availability (PSA) Capacity Plans Budget for changes Status updates of Change (Release Mgt) Request to implement the change Release Documentation for Approval Benefits:

Forward Schedule of Change (FSC) Projected Service Availability (PSA) Changes to Configuration Items Approval to build (Rls Mgt) Authorisation to Implement Change Management Reports

Better alignment of IT Services to business requirements As the business can also take part in the approval of change as part of the CAB they can provide business input and perspective to ensure that any change is in line with business requirements rather than what IT is best for the business. This will improve the customer perception and will result in improved performance within SLAs which are based on business requirement and IT capability.

Improved assessment of risks This is gained by having a defined risk assessment procedure in place as part of the change process and also involving different IT functions and processes as well as the customer in making a more accurate assessment of the change. Improving risk assessments will allow any risk to be factored and managed which reduces the impact of change related incidents.

Reduced impact of changes on quality By effectively scheduling changes they can be organised so that changes which may impact availability are done outside of operating hours and therefore result in nil impact to the quality of service.

Increased productivity of users by better Scheduling of changes they can be organised so that changes which may impact availability are done outside of operating hours and therefore result in nil impact to the productivity of the user.

Better assessment of costs involved with changes By recording time spent by the different resources we are able to provide a holistic cost of a change. This will assist in justifying the cost of a change and also in budgeting for future of the process.


P a g e | 25

Greater ability to absorb higher volume of changes By planning changes effectively and having clear procedures the process becomes more effective and is able to process more RFCs and schedule them effectively so as not to create any major impacts on the business.

Enhanced perception of IT through improved quality By improving the quality of reviewing and implementing change this results in reduced incidents and eventually improved customer satisfaction levels.

Fewer changes have to be backed out As the process assesses risks in advance and authorisation is given to implement after building and testing has been evaluated then the likelihood of needing to back is reduced.

Activities: Logging and Filtering

o

RFCs should be approved or rejected by line management within the business before it is submitted. Any submitted request is then filtered for any impractical requests which are rejected with an explanation. Also any similar or repeat requests can be identified at this stage. Accepted changes are then logged.

o

o

Prioritisation and Classification

o

Define the change priority level (eg. High, Medium, Low) to decide on which RFC to assess/approve first. Define the change category (eg. Urgent, Standard, Minor, significant, major) to determine at what level approval will be required (CAB, Exec Board, Service Desk). Determine target change lead times based on priority or category.

o

o

Impact & Resource Assessment

o o o o o o

Assess impact on the business operations Effect on infrastructure and customer service as per SLAs (ARMSS) Impact on other services using same infrastructure Effect of not implementing the change Evaluate effect on current FSC and PSA Long term impact and resource requirements to support the change on-going

Approval & Scheduling

o

RFC is passed to the Change Authority for formal approval (Chg Mgr, Service Mgr ) Financial Approval Technical Approval Business Approval Schedule approved changes as a Release unit or package where possible Initiate the go ahead of the Release Create and update the FSC and PSA

o o o o

o o

Release Management

Planning Assign which technical team should build the release unit.

Building and Testing Build the release unit and conduct appropriate testing for ARMSS, Performance and Functionality.

Authorisation


P a g e | 27

o

The Change authority must ultimately give authorisation for the implementation of a release to go ahead. This can only be done after appropriate testing has been conducted with business acceptance of the above criteria.

Release Management

Implementation Changes to be implemented as per the agreed schedule (FSC). Release will normally be responsible for the actual implementation.

Review and Closure

o o o o o o o o

Change met the objectives Customer/User acceptance Review effects on ARMSS, Performance and Functionality Use of resources was as planned Change was on time and within budget The back out plan worked correctly Document feedback of reviews (eg. CAB minutes, PIR) Formally close the RFC

Relationships: Incident Management: SD receives SRFs and RFCs from the business SD submits RFCs to resolve Incidents SD may have authority to process some pre-approved changes

ChM provides IM/SD access to the FSC so they are prepared in case of incidents when changes are implemented and also so they can inform the users of upcoming changes.

Problem Management: PM submits RFCs to correct Problems or Known Errors PMgr would be part of the CAB ChM Approves and provides feedback on RFCs submitted to resolve problems and known errors

Configuration Management: CM provides relationships between CIs to assist assessing the impact of changes ChM updates the status of CIs through the change process as the CI moves through the lifecycle

Release Management: RM handles the build, test and potentially the implementation phases of the change lifecycle ChM authorises the implementation of release units/packages

Service Level Management: SLM provides support by ensuring 3rd party suppliers abide by Change control policies ChM reports to SLM on performance of the process and results of changes

Financial Management: FM assists in the Financial assessment and approval of changes ChM provides reports on costs of changes and time spent on changes

Availability Management: AM provides availability plans and requirements for ARMSS which make part of the assessment criteria for approval of the change ChM provides the FSC and uses this with the PSA to effectively schedule new changes to optimise availability with minimum need for outages

Capacity Management: CapM provides capacity modelling which assists creating change models (Std, Minor, Major) P a g e | 29


ChM will assess impact of changes based on capacity modelling created by CapM

IT Service Continuity Management: ITSCM provides the ITSCM plan which includes VBFs which is important for ChM to understand in assessing impact and priority of changes. ChM must review impact on the ITSCM plan and its components when any change is to be made to a service. If there is an impact then action must be taken to update the ITSCM plan and its components to match the live environment.

Change Management Implementation PLANWhere do we want to be: Business Objectives Agreed SLAs Budget




P a g e | 31

Change Management Implementation PROJECTWhere do we want to be: Business Objectives Agreed SLAs Budget



Configuration ManagementProvides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration Items in existence. Objective: Account for all IT assets and it configurations within the organisation and its services. Provide accurate information on configurations and documentation to support all the other Service Management processes Provide a sound basis for Incident Mgt, Problem Mgt, Change Mgt and Release Mgt Verify the configuration records against the infrastructure and correct any exceptions

Inputs: Hardware Software Documentation (SLAs, Plans, Procedures) Services Reports from Discovery tools

Outputs: Relationships between CIs VBF BCS Accurate data on CIs Cost of CI


P a g e | 33

Reports from Monitoring tools Status updates from Rls Mgt Updated Change logs Updated Problem Database and KEDB Updated incident logs Cost of CI License information Benefits:

Updated CI status Updated CI information Adding new CI

Improved availability Providing accurate information on CIs and their documentation will assist the other Service Management processes to be more effective and efficient in their roles. In particular Incident Management will be able to restore service quicker by accessing information related to the CI which helps them diagnose the cause of the incident find a relevant workaround to restore service.

Controlling valuable CIs By having discovery and monitoring tools in place to update CIs if any item was to be removed it could be noticed and prompt action could be taken. For example if a PC was stolen the tools may find this before someone physically noticed.

Facilitates adherence to legal obligations It assists in maintaining accurate records on items with legal implications. For example software licenses where if any unlicensed applications were installed there could be legal action taken against the business. Again the by using a tool to maintain the configuration of software CIs it is possible to manage them so all software in use is licensed.

Helps financial planning As there is also financial information regarding cost of CIs it is possible to use this to forecast and budget future spending. The CMDB should also hold information on license expiries and the age of items and this could provide a clear indication for when renewal or upgrades would be required and can then be budgeted for.

Reduce the use or possibility of using unauthorised software Identifying software changes in the live environment against the records could prevent incidents due to the installation of retired versions of software which are no longer supported. Again discovery and monitoring tools can facilitate this so that these can be identified quickly and

efficiently.

Better contingency planning The information in the CMDB provides a sound basis for any contingency plan. It holds all information on all CIs and so the IT Service Continuity can use this information along with understanding of the Vital Business Functions to conduct CFIAs and create an accurate contingency plan for the business and IT Services.

Better Release management Configurations management will provide a baseline for which Release Management can use as a standard version of software to fall back on if a back out plan would have to be instigated. Without this an unsuccessful release implementation may result in extended outages as a solution is investigated.

Improving security Confidentiality, Integrity and Availability can all be supported by ensuring appropriate Configuration Controls are adhered to. Also by using monitoring tools it becomes more difficult to make unauthorised changes whether they be by accident or intentionally.

Improves the ability to perform impact analysis By understanding the relationship between CIs and services an accurate assessment of impact can be made by Change Management when reviewing a RFC for approval. This reduces the risk of an incident occurring as a result of the change.

Activities:


P a g e | 35

Planning o o o o Planning and defining the purpose Scope/Objectives Policies and procedures Roles and responsibilities including the role of suppliers

Identification o o o o o o o Selecting and identifying the configuration structure for all CIs Assign Owner for a CI Document inter-relationships Documentation of the configuration Allocate version numbers Labelling each CI Entering in the CMDB

Control o Ensuring only authorised and identifiable CIs are recorded from receipt to disposal Ensure no CI is added, modified, replaced or removed without approved control documentation

o

Status Accounting o o Report all current and historical data for a CI throughout its lifecycle Updating of a CI from one state to another (live, testing, withdrawn)

Verification and Audit o Reviews and audits that verify the physical existence of CIs and check they are correctly recorded

Relationships: Incident Management/Service Desk: IM /SD regularly check the CMDB for information on CIs in relation to incidents which can act as on-going audit of CIs as any variations can be seen and corrected or feedback to CM. CM provides accurate information on CIs which allows IM to classify and prioritise incidents so they can be resolved within agreed timeframes as per the SLA.

Problem Management: PM uses the information on the relationship between CIs to investigate root cause of problems. CM link CIs with the data in the KEDB so that it can be used by other processes.

Change Management: All changes are logged in the CMDB and any change to a CI must go through ChM process CM assists ChM assess risk and impact of changes by providing accurate information on all the CIs and their relationships.

Release Management: RM provides status and version updates to software items, RM is also responsible for the DSL CM provides a baseline which can be used by RM if a back out of a release unit is required and it can return to the state as defined at the point in


P a g e | 37

time when the software item was working. Service Level Management: Financial Management: Availability Management: Capacity Management: IT Service Continuity Management: SLM

Configuration Management Implementation PLANWhere do we want to be: Business Objectives Scope Assign a Process Owner and manager Define roles and responsibilities Define structure Defines tool requirements Budget requirements

Where are we now: Assessment Baseline of current situation

Assess current Staffing Assess current Skills Assess current Tools Assess current policies and procedures Gap Analysis

How are we going to get there? CI Naming conventions Assign roles and responsibilities according to skill Document new procedures Decide on tools to be used (discovery and monitoring) Integration with other processes Awareness campaign Gain management commitment Quick Wins Obtain budget and resources Provide staff training Implement commence collecting data

How do we know when we have arrived: Audit of process Monitor use of tools Process reports Check integration of other databases to support all Service Management processes SIP to improve on any gaps

Configuration Management Implementation PROJECT

Assessing your current CM maturity and setting goals for improvement


P a g e | 39

Gathering Requirements to align ITIL with organizational needs Describing the schema of your CMDB Identifying, capturing, and organizing configuration data Choosing the best tools for your requirements Integrating data and processes to create a unified logical CMDB Implementing pilot projects to demonstrate the value of CM Moving from a pilot to wide-scale enterprise deployment Defining roles for deployment and ongoing staffing Leveraging configuration management information Measuring and improving CMDB data accuracy



How are we going to get there? How do we know when we have arrived: Assign roles Document new procedures

Audit of process Process reports

Release ManagementSoftware Release Major Release V1 Minor Release V1.1 Emergency Release V1.1.1 Release Types Delta Release A partial release of only the CIs within the release unit which have changed or are new since the last full or delta release. Full Release All components of the release unit a built, tested and implemented together Package Release Grouping together of release units to gain the benefit of more stable live environment and reduce frequency of releases and change on the business. Objective: To take a holistic view of a change to an IT service and to ensure that all aspects of a Release, both technical and non-technical are considered.

Inputs: Business Requirements Supplier product development schedules Resource availability Approved request for change RFC Forward schedule of change FSC Projected Service Availability PSA Capacity Plan CMDB information SLAs from SLM Availability Plan SIP from SLM

Outputs: Release Policy Updated CI Decommissioned CI Release Documentation Known Errors identified in testing Updated CMDB records Install guides Basic support instructions Updated DSL/DHS Build and Testing results to ChM


P a g e | 41

Benefits: A greater success rate in release of Hardware and software and therefore improved quality of service delivered to the business

Minimising disruption of the service to the business by synchronising releases as packages

Assurance that hardware or software released into the live environment is of good quality as the proper precautions have been taking through the building and testing of the release.

Better use of resources as releases are packaged this means testing time can be done at the same time rather than multiple releases taking more time away from the user and IT.

Error reduction through the controlled release of software and hardware. This results in better availability and ability to meet SLAs.

Ability to absorb high volumes of change without having to impact on the IT service quality. This is done by releasing a higher number of changes in a release package in a controlled and well understood manner.

Savings in support costs as all software is centrally recorded and or stored and therefore allows for use of consistent software requiring the same skills and knowledge to provide support.

Reduce chance of illegal copies of software being used. This is done by having all records of all software used in the DSL and can be checked against for variations in the live environment.

Fewer releases rolled out means reduced interruption to the user. By packaging releases this can minimise impact on the business and allow for a more productive user.

Activities: Definitive Software Library (DSL) A secure location in which the definitive authorised versions of all software CIs are stored and protected. Definitive Hardware Store A secure storage of definitive hardware spares which are assemblies that are maintained at the same level as the comparative systems in the live environment

Release Policy o o o o o Scope of Release Management Release naming and numbering conventions Definition of major and minor releases Policy on conducting Emergency fixes Identification of Business Critical times to avoid when implementing a release Policy on testing for each release Policy on back out plans which are required for approval by ChM The control process for Release Management

o o o

Release Planning o o o Gain consensus from all stakeholders on the contents of a release Identify and secure resources for the implementation Get quotations from suppliers for the Software, Hardware and services required Producing high level release schedule Producing the back out plan Setup a quality plan for the release to measure its success

o o o

Release Design


P a g e | 43

o o o o

Production of the high level release design Production of the detailed release design Production of the tool design requirements Engage all required resources and suppliers to complete the desing

Release Build and Configuration o o o o o o o Obtain required SW or HW from the DSL/DHS for the initial build Acquire any 3rd party SW/HW including licenses Building the release inc automated install scripts Determine support tool requirements Create detailed release assembly and build instructions Detailed test plans Store all new copies in DSL/DHS along with documentation

Release Testing and Acceptance o o o o Setup a controlled test environment Test back out procedures Verify release plans Check for Functionality, Performance, ARMSS and integration as required Get Support Testing Get User Testing Verify any changed support procedures Gain authorisation from ChM

o o o o

Release Rollout Planning o o Produce time table of events for rollout List the CIs to be installed and those to be decommissioned or

modified o o o o Producing an action plan who does what. Produce release notes and communication to end users Communication planning Schedule meetings and training Acquire Hardware and Software

Release Communication and Training o Hold meetings with stakeholders to ensure plans are reviewed and agreed Provide all plans, instructions and media to the installation staff Conduct training sessions to end users Conduct training sessions for support staff Publish the release notes Communicate problems and known errors still existing in the release

o o o o o

Release Distribution and Installation o o o o o o o Complete installation Ensure new procedures and documentation is available Ensure adequate support is provided Implement the back out plan if required Update CMDB records (updating of status) Conduct final acceptance testing Communicate to the end users the outcome of the release


P a g e | 45

Relationships: Incident Management: Release notes, KE May form part of testing of maintainability

Problem Management: Handover of problems and KE exsisting in the release Problem records can provide a basis for what testing is required on a particular CI

Change Management: Approved RFCs a must before release ChM provides authorisation for any implementation of release RM provides plans, build and test results for authorisation of a release to complete the change process through an implementation

Configuration Management: Provides a baseline for RM to use as a trusted version/configuration for a back out plan of a CI RM updates software information to add, remove or update information and media in the DSL and then provide matching information in the CMDB

Service Level Management: SLAs of a service to be used for testing ability to support within SLAs. Testing reports to inform SLM of any potential impacts on SLAs as a result of a release

Financial Management: Budget for implementing of a release Costing in terms of wages and time spent for accounting and future

forecasting Availability Management: PSA to be used to schedule releases A release may require an outage and so collaboration may be require to schedule an appropriate time and this must be updated in the PSA

Capacity Management: Capacity modelling to ensure any new release will not impact due to capacity issues Provide test results to be used by Capacity Mgt in capacity modelling

IT Service Continuity Management: New releases must be factored in the ITSCM plan ITSC should be part of the design and testing of a release

Release Management Implementation PLAN Where do we want to be: Business Objectives


P a g e | 47

Agreed SLAs Budget



Release Management Implementation PROJECT Where do we want to be: Business Objectives Agreed SLAs Budget




P a g e | 49

Service Level ManagementThe process of, Planning, Co-ordinating, Drafting, Agreeing, Service Monitoring and Reporting on SLAs,

and the on-going review of service achievements to ensure that the required cost-justifiable service quality is maintained and gradually improved. Objective: To maintain and improve IT Service Quality through constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service in line with business or cost justification. Through these methods, a better relationship between IT and its customers can be developed. Inputs: Business Requirements (Cust) Budget/Financial restrictions (FM) New Service Requests Process Reports (IM, PM, CM, AM, CapM) Development Issues Customer Feedback Service Reviews Internal & External service capabilities Financial approval Benefits: IT Service designed to meet Service Level Requirements Improved relationship with Customers Both Customers and IT organisation have better understanding of roles and responsibilities Established targets to aim for gives ability to measure service quality IT focuses on areas important to the business (SLR) Expectations of what service is to be provided is clear to Customer and IT organisation Outputs: Service Catalogue Signed SLAs, OLAs & UCs IT targets Service Achievement Reports Service Improvement Plans

Clarity on Incident severity (what is a Priority One incident) and how it should be handled By measuring performance allows for weak areas to be identified and improved Monitoring can also identify where customer/user actions are causing incidents and identify training opportunities Underpins Supplier management to ensure value for money is provided and that the supplier is providing a service which fits within the SLA Ensures internal support teams are also measured with OLAs which can identify gaps in the end to end process of providing the service SLAs can be used for charging so helps demonstrate the value for money Gradual improvement in Service quality as a result of SIP Gradual reduction in cost of service as the SLA is refined to fit within what the customer is willing to pay and the effort and resources required to achieve the service targets.

Problems: Not monitoring achievements (reporting) prior to implementing SLAs o Gathering a baseline before go live, if not possible then recommended to pilot SLA

Committing to unrealistic targets SLAs based on Customer wants rather than achievable targets SLAs based on what IT is willing to commit to rather than mix of SLR and IT Capability Lack of staff to maintain process on-going (review meetings, review process) Service Level Manager not enough authority to negotiate and push improvements SLAs not supported by OLAs or UCs Unclear SLAs SLAs not able to be monitored and measured SLAs too lengthy or complicated SLAs written in technical language so not understood by the customer


P a g e | 51

Lack of management commitment, especially when internal contracts SLAs set without factoring cost to the IT organisation in meeting the service targets

Activities: Establish Function o o o o Initial Planning activities (Setup project) Plan Monitoring Capabilities Establish initial perception of the services Plan for Underpinning Contracts and Operational Level Agreements

Implement SLAs o o Create a Service Catalogue Plan the SLA Structure Customer Based Agreement with one customer group, covering all services they use. Service Based Agreement for one service to all customers of the service Multi-Level Corporate Level Covering generic SLM issues appropriate to every customer in the organisation Customer Level Covering all SLM issues relevant to the particular customer group, regardless of the service being used. Service Level Covering all SLM issues relevant to the specific service, in relation to this specific customer group (one for each service covered by the SLA)

o o

Draft SLA (Establish SLRs & Expectations) in Business Language. Establish Monitoring Capabilities If it cant be measured it should not be in the SLA

o o

Review Underpinning Contracts and Operational Level Agreements Agree, Sign and Publish SLAs (Service Desk & User Community)

Agreed and Signed by both parties to show commitment to the SLA Communicate SLAs

On-Going Process o Monitoring and Reporting o Implement Monitoring tools Collect Service Desk logging data Operational, Exception and Periodic Reports

Service Review Meetings Periodic meetings to discuss performance Meetings triggered by exception

o

Service Improvement Programme (with Prob Mgt and Avail Mgt) Address Service issues and improve Service Levels People, Process & Technology

o

Review SLAs, OLAs and UCs (with Chg Mgt)

SLA Monitoring (SLAM) Chart

Target/Period% Service with SLAs % SLAs monitored

JANG G

FEBG G

MA RG A

APR MAYA R G R

JUNA R

JULR A

AUGG G

SEPG G

G = Green (OK) (Breach) SLA Structures Eg.

A = Amber (Threat)

R = Red

Corporate Level Covering generic SLM issues appropriate to every customer in the organisation

Customer Level Covering all SLM issues relevant to the particular customer group, regardless of the service being used.


P a g e | 53

Eg. Service Level Covering all SLM issues relevant to the specific service, in relation to this specific customer group (one for each service covered by the SLA)

Eg. The same SLA A written (mutually beneficial) agreement between an IT Service Provider and the IT customer defining the key service targets and responsibilities of both parties.

SLA Contents o Introduction Names, dates, Description of services, responsibilities, definitions.

o

Service Hours Normal hours Service is required (inc Holidays or special extended days)

o

Availability % target)

o

Reliability Number of Service Breaks, MTBF, MTBSI)

o

Support Support Hours (inc After Hours options)

o

Throughput Likely traffic volumes (Concurrent Users, No. Transactions, Amount of Data)

o

Transaction Response Times Target times for average or maximum response times (% within 60sec)

o

Batch Turnaround Times Times for delivery of input and the time and place for delivery of output

o

Change Targets for Approving, Handling and Implementing RFCs based on Priority of the Change

o

IT Service Continuity Security Mention of IT Service Continuity Plan and how to invoke Details of amended service targets should a disaster occur

o

Security Reference to the IT Security policy (passwords, licenses, virus protection, access restrictions)

o

Charging Details of the charging formula and periods

o

Service Reporting and Reviewing Content, Frequency and Distribution of Service Reports Details of Frequency and who shall attend Review Meetings

o

Performance Incentives/Penalties Details of any agreement regarding Financial Incentives or Penalties based upon performance against Service Levels.

SLM ProcessEstablish Function

Planning


P a g e | 55

Implementations

Implement SLAs

Catalogue of Services Draft Negotiate Review UCs and OLAs Agreed SLAs

Manage On-going Process

Periodic Reviews

Service Monitoring & Reporting Review Meetings Service Improvement

Review SLM Process Review SLAs, OLAs and UCs

KPIs Number or % of services covered by signed SLAs % of SLAs with matching UCs and OLAs in place Are SLAs being monitored and reports produced on time Are review meetings being held on time and documented minutes Are issues raised at Review Meetings followed up via SIP (Documentation) Are SLAs, OLAs and UCs current and reviewed on time What number or % of Service Targets are being met What is the number of severity or service breaches in a period

Are Service Level achievements improving Are Customer perception statistics improving

Relationships: Incident Management: SLM provides Service Level Catalogue and Service targets for incident response and resolution IM provides reporting on Incident related service targets IM conducts training for users where user actions is the cause found via SIP IM conducts customer surveys and provides customer feedback to SLM

Problem Management: SLM provides service targets and sets OLAs with internal support functions for resolution times PM reduces incidents and recovery times through problem and error control which helps meet SLAs PM provides reporting on Problems and Errors solved which can be used in Service Review meetings

Change Management: SLM improvement programmes result in RFCs SLM provides service targets for approving and handling changes ChM provides reports on average time for approval and handling of changes

Configuration Management: SLM provides SLA documentation and attributes which should be added to CMDB and linked to CIs and services to enable reporting CM provides access to information on services and CI relationships and who supports them which can be used to identify where OLAs and UCs are required


P a g e | 57

Release Management: SLM provides in SLAs the peak or critical times for the customer where Releases are not to be implemented RM Implements changes to solve errors or reduce recovery times to help meet SLAs

Financial Management: SLM provides SLRs and draft SLAs to be reviewed by FM for cost impacts FM provides financial approval on cost of IT organisation to meet SLAs FM provides charging based on SLAs FM provides recommendations for Incentives/Penalties to be included in SLAs

Availability Management: SLM works on SIP with Availability Mgt to meet service availability targets AM provides availability reporting for service targets on availability

Capacity Management: SLM provides SLRs for Capacity to produce Throughput and Capacity projections Capacity provides Throughput projections to be included in SLAs

IT Service Continuity Management: SLM adds Service Continuity Plan information and how to invoke into SLAs SLM provides SLAs on amended service targets in case of disaster ITSCM provides the ITSC Plan to be communicated to the customer and in part included in the SLA

Service Level Management Implementation PLAN Where do we want to be: Appoint Service Level Manager Create a mission statement Define Business Objectives and scope Awareness campaign Define roles, tasks and responsibilities Quantify activities, resources, funding and quality criteria Identify any risks Plan a Service Catalogue and SLA structure Draft an SLA format Identify support tools (Service Monitoring)


P a g e | 59

Set and agree on Incident Priority Levels and escalation paths (with Customers, Problem Management and Service Desk)

Financial Management

Objective: To provide cost-effective stewardship of the IT assets and resources used in providing IT Services.

Inputs: Draft SLAs Business IT Requirements IT Budget (from the business) Process Plans Usage Reports from CapM & Avail Mgt

Outputs: Proposed charges to the business Cost Benefit Analysis Cost of IT Services Charging policies Invoicing IT Budgets Financial Reporting Profit and Loss Statements

Benefits: Ensuring the business provides sufficient funds to run the IT Services it requires More efficient use of IT Service throughout the organisation Recovering IT Costs in a fair manner which can be justified by usage Provides accurate management information on the cost of providing an IT Service Allows the IT Organisation to make better and cost-effective decisions on how its run Investment decisions are based on accurate cost information and Cost Benefit analysis Influencing customer behaviour and expectations Allowing comparison with alternative service providers

Cost Types People Accommodation Software Hardware External Services Transfer Costs

Activities: Budgeting: The Process of predicting and controlling the spending of money within the organisation and consists of periodic negotiation cycle to set budgets (annually). Estimate the cost of Budget Items Estimate the cost of workload dependant Budget items


P a g e | 61

o

Enables IT to predict the money required to run IT Service for a given period Ensures actual spend can be compared with predicted spend at any point Reduces risk of overspending Ensures that revenues are available to cover predicted spend

o

o o

IT Accounting: The set of Processes that enable the IT organisation to account fully for the way its money is spent (ability to identify cost by customer, service & activity). It usually involves ledgers and should be overseen by trained accountancy professionals. Establish Financial Structure o o o Cost Centre Recovery Centre Break-even Profit Centre

Build a Cost Model Investment Appraisals

o o

Enables IT to account for money spent in providing IT Services To calculate the cost of providing IT Services to internal and external Customers Perform cost-benefit and ROI analysis (recognise and evaluate the options and flexibility available from modern technology. Identifies the cost of Changes

o

o

Charging: The set of processes required to bill Customers for the services provided to them. To achieve this requires sound IT accounting, to a level of detail determined by the analysis, billing and reporting processes. Enables IT to recover the cost of the IT Services from the Customer Enables the IT organisation to operate as a business unit Influences the user and Customer behaviour

Cost Model Determine Cost Type o o o o o o People Accommodation Software Hardware External Services Transfer Costs

Define Cost Element o o Hardware WAN, LAN, Disk Storage, PC, Servers Software Finance Applications, Monitoring Applications, Business Applications.

Classify cost elements o Direct Costs - Clearly linked to a particular Customer (eg. Dedicated Service) Indirect Costs - Costs for items which are shared and must be split per Customer (eg. CPU Seconds) o Capital Expenditure Annually depreciated to allow for decreasing value of items Operational Expenditure Day to day cost of running the IT Services

o

o

Allocate Cost Centres for each business groups Determine depreciation method of capital costs o o Straight Line Equal amount every year Reduced Balance - % of the total value every year


P a g e | 63

o

By Usage Written off based on usage per year

Assigning Costs o o Cost Per Customer Cost Per Service

Reducing the Effect of Changes to Cost Calculations o o Average Cost Standard Rate (Estimate based on forecast)

Charging Model Identify the costs of providing the IT Services Select a pricing method o o o Cost Full Cost Recovery Cost-plus Cost + % Margin Going Rate Price is comparable to that provided by other Internal IT of other similar organisation (benchmarking) Market Price Price match other 3rd party suppliers Fixed Negotiated Price Set Price for Service

o o

Setup Billing o o Monthly, Quarterly Invoices Notional Invoices

Problems: Complex and ineffective Charging systems which result in no benefit and confusion Availability of Other Process information and Plans for budgeting Lack of skilled staff in IT and Finance Business Requirement projections may not be available so Capacity requirements not accurate Lack of Management commitment to charging (seen unnecessary as

added admin cost) Cost of system becomes more expensive than the value of information produced Monitoring tools providing usage is inaccurate

KPIs: Budgets provided for all Services Budgets are delivered on time Accuracy of Cost Projections Accurate Cost Recovery to cover expenses All costs associated with IT Service are accounted for and justified Charges are considered as fair Income is collected on time Customers are not over or under charged

Relationships: Incident Management: IM can provide reporting on SLAs which may be used for charging FM assigns funds from the budget to resource the Service Desk

Problem Management: PM provides resource requirement information for accurate budgeting FM assigns funds from the budget to resource the Service Desk

Change Management: CM is required if any change to Budgeting, Accounting or Charging (Systems, Tools, Procedures) FM assigns funds from the budget to resource the Service Desk FM assess the Financial Impact of RFCs before CAB approval.

Configuration Management: Config Mgt provides information on all assets to FM via the CMDB


P a g e | 65

FM accesses and updates cost information of all assets in the CMDB

Release Management: RM provides resource requirements for accurate budgeting FM assigns funds from the budget to resource the Service Desk

Service Level Management: The more flexibility in a SLA the higher the overheads of Budgeting, IT accounting and charging (if used). FM provides guidance on the cost of meeting the Customers requirements so SLAs are cost effective FM provides the charging policy which can influence customer behaviour

Availability Management: Capacity Management: Cost information can be used to estimate the costs of Capacity and Availability. The more the customer pays (revenue) the more can be spent on Capacity and Availability FM provides Cost Benefit analysis for investments recommended by CapM CapM provides recommendations of new hardware investments to meet capacity projections and requirements

IT Service Continuity Management:

Financial Management Implementation PLAN Feasibility Study: Plan: Do: Setup cost centres and cost units Setup data recording Select, install and test software tools Awareness Campaign Decide Scope & Objectives Produce Project Plan Design and Develop IT Accounting and Charging systems Document procedures Benefits Analysis and recommendation of Cost and potential Charging Policies Evaluate Support Tool requirements Risk Assessment Set Goals for Implementation

Check: Pilot the system Monitor if charging has influenced customer demand Monitor the costs Adjust the system


P a g e | 67

Act: Implement Review and set Improvement Plan

Availability Management

Objective:

Inputs:

Outputs:

Benefits:

Activities:

Relationships: Incident Management: Problem Management:


P a g e | 69

Change Management: Configuration Management: Release Management: Service Level Management: Financial Management: Availability Management: Capacity Management: IT Service Continuity Management:

Availability Management Implementation PLAN Where do we want to be: Business Objectives Agreed SLAs Budget


How are we going to get there? ITIL Service Management V2 P a g e | 71 Assign roles Document new procedures


Availability Management Implementation PROJECT Where do we want to be: Business Objectives Agreed SLAs Budget


How are we going to get there? Assign roles

Document new procedures


Capacity Management

Objective: To ensure that cost justifiable IT Capacity always exists and that it is matched to the current and future identified needs of the business. Good capacity management ensures NO SURPRISES! Inputs: External suppliers of new technology Business Strategy (SLM) Business Plans (SLM) Outputs: Monitoring Data Capacity Management Database (CDB) Verification of IT capabilities against


P a g e | 73

Budgets and Financial Plans (FM) Cost Benefit Analysis (FM) Incidents & Problems relating to performance SLAs, OLAs and UCs Business Requirements (SLRs) Change Requests to be assessed CI information on (Specs, Relationships, etc) Benefits:

SLRs Projected HW/SW requirements (FM) Capacity Plan Capacity Projections Purchase Recommendations Capacity Models

Increased efficiency and cost savings o Deferred Expenditure By redistributing workload new equipment purchases can be delayed Economic Provision of Services Capacity matched to business need Planned buying Allows time to source value and specifications required

o

o

Reduced Risk o o o o By managing the resources available New applications will not impact on existing environment Participate in impact assessment of Changes Reduction of Urgent Changes to increase capacity

More confident forecasts Value to applications lifecycle

Activities: Monitor: Identify components to Monitor Identify the data required for Service and Resource Level Capacity Establish a baseline performance and capacity from historical data Establish Thresholds for each component and service Breaches should raise Alarms and be included in Exception Reports

Implement Monitoring of Response Times o Build coding within Client and Server Applications Monitor transactions and provide Actual User Response Times

o

Using Robotic Scripts Simulate transactions and provide Representative User Response Times

o

Using Distributed Agent Software Test connections to a website from different locations and provides Representative User Response Times

o

Using Passive Monitoring systems Insert Sniffers at different points in the network and provides Representative User Response Times

Analyse: Analyse the data from monitoring and exception reports for: o o o o o o Contention between data Inappropriate distribution of workload across available resources Inappropriate locking strategy Inefficiencies in application design Unexpected increase in transaction rates Inefficient use of memory

Evaluate the data over Short (24hrs), Medium (1-4wks) and Long Term (Annual)

Tuning: Balancing Workloads o Balancing to load amongst the available resources

Balancing Disk Traffic o Storing data efficiently on disk

Definition of accepted locking strategy


P a g e | 75

o

Specify when locks are necessary and the appropriate level, delaying the lock until an update is necessary may provide benefits

Efficient use of memory o May require increase or reduction in memory utilisation

Implementation: Implement changes via RFCs through Change Management o o o o Reduces impact on Users Increases User productivity Increases IT staff productivity Reduces need for Backing Out of changes due to Capacity issues

Demand Management: Understanding which Services utilise the resources and to what level and when. Make decisions to influence use of resources by, o o Physical Constraints Blocking or limiting access to users. Financial Constraints Where charging is in place reducing cost of off-peak demand periods could influence users/customers to spread their usage times.

Capacity Modelling: Trend Analysis o Use historical utilisation data to forecast future Service or Resource utilisation

Analytical Modelling o Calculating response times through mathematical formulas produced by a software package after entering in the components and structure of the configuration, and the utilisation.

Simulation Modelling o Simulating actions at any point in time or multiple transactions at one time

Baseline Modelling o o Create a baseline model that reflects current performance Apply What If? scenarios to project future outputs or requirements

Application Sizing: When designing a new application: Scalability Fit for Purpose Costs Manageability

Build it to be able to meet the SLA/SLRs.

Capacity Plan: Introduction Scope of the plan Methods Used Assumptions Made Management Summary Business Scenarios Service Summary o o Current and recent service provision Service Forecasts

Resources summary Options for Service Improvement Cost Model


P a g e | 77

Recommendations

Capacity Management Database (CDB): Inputs, Business Data o Current & Future - Utilisation and Requirements

Service Data o Data to measure user experience (eg. Response Times)

Technical Data o Technical limitations and threshold settings

Financial Data o o o o Financial Plans IT Budgets Cost of current CIs Cost of New CIs from suppliers

Utilisation Data

Outputs, Service and Component Based Reports Exception Reports Capacity Forecasts

Business Capacity Management: Identify and Agree Service Level Requirements o Required Response Times

o o o o

Expected Throughput Patterns of Usage Number of Users Volume of Usage

Design, Procure or Amend Configuration o o Design new services Recommendations on Procurement of SW/HW for performance and capacity Assess RFCs for Capacity Obtains cost of proposed Solutions to balance Cost vs Capacity

o o

Update CMDB and CDB o o Update new or amended CIs in the CMDB Update the CDB with CI technical specifications (Capability & Expected Demand)

Verify SLAs o o o o Check SLA for Service Throughputs and Performance Requirements Ensure ability to Monitor the Service Targets Confirm Service Design meets the SLRs Conduct Capacity Modelling to ensure room for growth

Sign SLA o Use Capacity Modelling to verify Service Performance before SLM signing

Service Capacity Management: Once SLA is agreed monitor to ensure meeting them Identify thresholds and monitor any report on any Service Breaches Respond to Incidents/Problems referred to CapM Analyse trends and use projections to pre-empt difficulties

Resource Capacity Management: ITIL Service Management V2 P a g e | 79

Identify and understand the Capacity and utilisation of each component in the IT Infrastructure Monitoring on Components of Hardware and Software on an on-going basis Analyse trends and use projections to pre-empt difficulties Recommendations on Procurement of SW/HW for performance and capacity

Cost vs Capacity The need to ensure that processing Capacity that is purchased is not only cost justifiable in terms of business need, but also the need to make the most efficient use of those resources. Supply vs Demand Making sure that the available supply for processing power matches the demands made on it by the business, both now and in the future. It may also be necessary to manage or influence the demand for a particular resource. KPIs: Resource Forecasts o o o Timely production Accuracy Alignment with business plans

Technology o o o Ability to monitor performance Alignment with business requirements Outdated technology does not result in breach of SLAs

Cost Effectiveness o o No significant over-capacity (under utilisation) Accurate forecast of planned expenditure

Capacity Management Relationships:

Incident Management: IM informs CapM about Incidents related to Performance and Capacity CapM resolves and documents Capacity related incidents

Problem Management: CapM provides diagnostic scripts and monitoring tools to support IM and PM CapM provides support to identify, diagnose and resolve Capacity related problems

Change Management: The cumulative effect of changes is monitored by CapM for an Capacity impact CapM contributes as part of the Change Advisory Board

Configuration Management: The CDB is either part of the CMDB or has the same information Technical, service, utilisation, financial and business data used by CapM


P a g e | 81

are attributes of a CI Release Management: CapM helps determine the Distribution Strategy, especially when it is done over the network Capacity information is used to plan capacity into the design and build of releases.

Service Level Management: CapM assists SLM in reviewing capabilities for Capacity and Performance CapM supports SLM to ensure performance and capacity targets can be achieved for new or changed requirements

Financial Management: CapM is concerned with providing cost justified service to meet the requirements of the business FM provides cost benefit analysis and ROI for proposed Investments CapM provides recommendations for procurement as part of Capacity plans FM provides budgets to compare against when reviewing any investment proposals

Availability Management: Performance and Capacity problems result in reduced Availability Several interdependencies The same monitoring tools used and Improvement Plans should result in improvement for both processes if planned together. Both use Component Failure Impact Analysis (CFIA) and Fault Tree Analysis (FTA) technique

IT Service Continuity Management: CapM determines the Capacity required for all recovery options used Capacity Plans should include IT Service Continuity

Capacity Management Implementation PLAN Review current Capacity Management components Plan (design) the process

o o o o o

Structure of the process (organisation) Monitoring (HW, SW, Network) Capacity Management Database (CDB) Integration into other processes Production of Capacity Plan

Implement the process o o o o o Train staff Establish monitoring and CDB Business Capacity Management Service Capacity Management Resource Capacity Management

Review the Process (Metrics, CSFs and KPIs)





P a g e | 83


IT Service Continuity Management

Objective: To support the overall Business Continuity Management process by ensuring that the required IT technical and services facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk) can be recovered within required, and agreed business timescales.

Inputs: Business Continuity Plan Business Critical Systems Vital Business Functions Agreed service levels during interruption Risk reduction measures Changed CIs required to update in ITSCM plan Definition of the core IT infrastructure CI dependencies, relationships & criticality Security data and requirements Benefits:

Outputs: Risk reduction measures ITSCM Plan Awareness campaign for Service Continuity Updates to ITSCM plan as a result of change Tested recovery plan

Management of risk and reduction of impact of a disruption to the business Potentially lower insurance premiums Meeting mandatory regulatory requirements Create a better understanding of the business requirements/priorities and

the capability of IT to support them Positive marketing of contingency capabilities Improve service perception Reduction in the number of major outages and reduced impact on the business By identifying the Vital Business Functions and building in resilience Ability to recover services from a disaster in a controlled manner

KPIs:

Time to get pre-defined team of core staff and minimum facilities recovered Accuracy of ITSM Plan Business, User and IT requirements adequately reflected in the plan Staffing requirements met and staff are trained Support contracts are in place with suppliers and they meet the requirements Regular tests of the contingency plan Test results are documented and published Changes are reflected in the ITSCM Plan

Activities: Stage 1: Initiation Initiate Business Capacity Management o o o o Establish Policies Define scope Allocate resources Define project structure (eg. PRINCE2)

Stage 2: Requirements & Strategy Business Impact Analysis o Establish Business Critical Functions (BCFs)

Risk Assessment (CRAMM)


P a g e | 85

o o o

Identify Assets > Threats > Vulnerabilities Assessment of Level of Risk Risk Reduction Measures (Availability Mgt) Of-site storage Eliminate Single Points of Failure Outsourcing services to multiple providers Building resilient systems Security controls

Business Continuity Strategy o Information from the Impact Analysis and Risk Assessment enables the Business Recovery Strategy to be developed Manual Work Arounds Reciprocal Arrangements Gradual Recovery (> 72hrs) Intermediate Recovery (24-72hrs) Immediate Recovery (< 24hrs)

Stage 3:

Implementation Organisation o o Executive Who has authority and control Co-ordination Responsible for co-ordinating Recovery efforts Recovery Teams Service & Support teams to recover BCFs

o

Implementation Planning High Level: o o o Emergency Response Plans Damage Assurance Plans Salvage Plans

o o

Vital Records Plan Crisis Management / Public Relations

Operational: o o o o o o Accommodation and Service Plan Computer Systems and Network Plan Telecommunications Plan Security Plan Personnel Plan Finance and Administration Plan

Implement Stand-by Arrangements o o Negotiate 3rd Party Recovery facilities Purchase standby resources (HW/SW)

Implement Risk Reduction o o o Setup Back-up Power Back-up Storage Spare equipment

Develop Recovery Plans Develop Procedures Initial Testing o o o Time to restore Staff Awareness of procedures Supplier Awareness and responsiveness

Stage 4: Operational Management (On-going) Education and Awareness Review and Audit


P a g e | 87

Testing (Scheduled & after any changes to ITSCM Plan) Change Management Training Assurance

Responsibilities: Normal Operation: Board o o o o o o o Initiate BCM & ITSCM Allocate Resources Set Policy Direct and Authorise Manage IT Service Continuity Accept ITSCM Deliverables Communicate & Maintain Awareness Integrate with BCM across the organisation Conduct IT Service Continuity Analysis Define ITSCM Deliverables Contract for services Manage, Tests, Reviews and Assurance Develop ITSCM Deliverables Negotiate Services Perform, Tests, Reviews and Assurance Develop and Operate Procedures

Senior Management

Management

o o o

Supervisors and Staff

o o o

Crisis Structure: Board Senior Management Management o o o o o o o Supervisors and Staff o o Crisis Management Corporate/Business Decisions External Affairs Co-ordination Direction and Arbitration Resource Authorisation Invocation of Continuity or Recovery Mechanisms Team Leadership Site Management Liaison and Reporting Task Execution Team Membership Team and Site Liaison

Relationships: Incident Management: Problem Management: Change Management: Configuration Management:


P a g e | 89

Release Management: Service Level Management: Financial Management: Availability Management: Capacity Management: IT Service Continuity Management: IT Service Continuity Management Implementation PLAN Initiation: o o Define and set policies on executive level Define and agree project plans and organisation

Requirements Analysis & Strategy Definitions: o o o Requirements Risk Assessment Recovery and Risk Mitigation Strategy

Implementation:

o o o o o

Organisational and implementation planning Implement standby arrangements Initial recovery testing Education, Training and Awareness Go Live

Service Level ManagementObjective: To maintain and improve IT Service Quality through constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service in line with business or cost justification. Through these methods, a better relationship between IT and its customers can be developed.


P a g e | 91

Capacity ManagementObjective: To ensure that cost justifiable IT Capacity always exists and that it is matched to the current and future identified needs of the business. Good capacity management ensures NO SURPRISES!

Financial ManagementObjective: To provide cost-effective stewardship of the IT assets and resources used in providing IT Services.

IT Service Continuity ManagementObjective: To support the overall Business Continuity Management process by ensuring that the required IT technical and services facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk) can be recovered within required, and agreed business timescales.

ITIL V2 Service Management - Study Notes

Documents

Transcript of ITIL V2 Service Management - Study Notes