markwilson.it

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

• Part 1 was an overview/introduction.
• Part 2 covered service strategy.
• Part 3 covered service design.

This post continues by looking at the topic of the third stage in the ITIL service lifecycle: service transition.

Service Transition

Service transition is concerned with moving from service design to operation:

• Plan and manage service changes with efficiency.
• Successfully deploy the new or changed services.
• Make sure that the service changes meet the agreed requirements.
• Educate people with the appropriate knowledge and information about services and assets.
• Manage risk.

Benefits include:

• Enable more accurate cost, timing and resource requirements.
• Make it easier for people to adopt and follow.
• Reduce delays due to unexpected clashes and dependencies.
• Improve expectation setting for all stakeholders.
• Ensure that new or changed services will be maintainable.
• Improve control of service assets and configurations.

ITIL defines the following Service Transition processes, which are expanded upon in the rest of this post:

• Transition planning and support.
• Change management.
• Knowledge management.
• Service asset and configuration management (SACM).
• Release and deployment management.
• Change evaluation.
• Service validation and testing.

(the last of these are not discussed in detail for ITIL Foundation level.)

Transition Planning and Support

Focuses on the transition of the service, not the service itself. Co-ordinate resources, plan for them, make sure requirements are met, coordinate activities across service teams.

“To provide overall planning for service transitions and to co-ordinate the resources that they require.”

Terms:

• Release Policy.
  • Service assets with people, each with responsibilities for handover and acceptance of the release:
  • 3 types:
    • Major release – new functionality, maybe removing tactical changes from the past.
    • Minor release – small enhancements, fixes.
    • Emergency release – updates (usually relating to security).
  • Make sure Service Knowledge Management System (SKMS) is up-to-date.
  • Understand Service Acceptance Criteria (SAC).
• SDP Lifecycle
  • All the information including service charter, budgets, timescales, definition and design of releases, making sure everyone has what they need to succeed.

Change Management

Unexpected change is often received negatively – by managing change we can keep people happy.

“To control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption of IT services.”

Change is the addition, modification or removal of anything that could have an effect on the IT services.

One set of study materials I used referred to an Adventures of Ace, DBA comic strip by Steve Karam where multiple changes are causing issues that are hard to track down. It’s a good example of the issues that poor change management can introduce.

Terms:

• Change Advisory Board (CAB):
  • Group of people who assess, advise on and authorise changes.
• Emergency CAB (ECAB):
  • CAB for emergency changes.
• Request for Change (RFC):
  • Formal request for a change to be made.
• Change Model:
  • Approach to managing change, e.g. based on impact:
    • Normal change (follows all the steps of the change process)
    • Emergency change (needs to be implemented right away)
    • Standard change (pre-approved, rarely need additional authorisation); low risk, common procedure (work instruction) – e.g. new employee account, laptop, etc.; password reset; etc.
• Change Record:
  • Details of the change lifecycle (actions taken)
  • For both accepted and rejected changes
  • Change Proposal:
    • Overall view of the change to be introduced. High level description, details of change, business case, implementation schedules, etc.

Remediation planning:

• Ensuring there is roll-back plan to go to the previous milestone in the change.
• Not all changes are reversible so there may be another plan to move around problems.

The Change Manager is the person who administers RFCs, prepares RFCs for CAB/ECAB; authorises/rejects changes based on CAB advice.

Knowledge Management

Does everyone know what’s going on?

“To share perspectives, ideas, experience and information; to ensure that these are available to the right place at the right time to enable informed decision; reducing the need to rediscover knowledge.”

Goals:

• User, service desk, support staff and supplier understanding of the new or changed service.
• Awareness of the use of the service and the discontinuation of previous versions.
• Establishment of the acceptable risk and confidence levels associated with the transition.

Terms:

• Data, Information, Knowledge and Wisdom (DIKW) Chart:
  • Data is just the facts (e.g. logs from monitoring tools).
  • Provide context to become information (e.g. in documents, email) – need to manage to find and reuse (e.g. to deliver service). Who, what, when, where?
  • Knowledge is based on past experience, ideas, values, etc. – dynamic and context-based for decision-making. How?
  • Wisdom can be thought of as “applied knowledge” – create value through correct and well-informed decisions. Why?
• Service Knowledge Management System (SKMS):
  • Contains information needed to manage services
  • Includes Configuration Management System (CMS), which itself contains the Known Error Database (KEDB) and Configuration Management Database (CMDB)
  • Also includes:
    • Staff – experience/skills.
    • Suppliers – abilities.
    • Users – education.

Service Asset and Configuration Management

“To ensure that the assets required to deliver services are properly controlled and that accurate and reliable information about those asses is available when and where it is needed.”

Ensuring all configuration items are configured appropriately and that relationships are known.

Terms:

• Service Asset:
  • Any resource or capability of a service provider.
• Configuration Item (CI):
  • Any component or service asset that needs to be managed to deliver a service (with associated scope).
• Attribute:
  • Information about the asset: serial number, capabilities, location, etc.
• CI Type:
  • Ways to classify configuration items (hardware, software, personnel, etc.)
• Component:
  • Smaller piece of a larger environment
• Configuration Baseline:
  • Configuration that has been set and agreed upon in change management.
  • Starting point for changes, or target to roll back to in remediation.
• CMDB and CMS:
  • Store information about Service Assets
• Relationship:
  • Connection between CIs – e.g. an application relationship to a server.
  • Between CIs in scope and out of scope (e.g. between PSTN and PBX)
• Verification and Audit:
  • Making sure information is up to date and accurate.
  • Formalised check.

SACM activities – not a cycle – these are interconnected:

• Planning:
  • Define objectives, processes, procedures, scope, naming conventions, types, etc.
• Identification:
  • Inventory of what/where systems exist.
  • Creation of baselines.
  • Control:
    • Information placed in CMDB and modifications are controlled/authorised.
    • Change Management will help with this.
  • Status Accounting:
    • Reporting (during and after transition).
  • Verification and Audit:
    • Constantly ensuring items are recorded, up-to-date and have no unapproved changes.

Release and Deployment Management

What is coming when?

“To plan, schedule and control the build, test and deployment of releases. To deliver new functionality required by the business while protecting the integrity of existing services.”

Includes all of the processes, systems, functions to help package, build test and deploy release into service operation (live use). Works hand-in-hand with service validation and testing (see below).

One set of study materials uses an analogy of a film release: which is created, written, filmed – then released. Planning – which cinemas, what date, when is the red carpet premier, etc. – are all part of release and deployment management.

Terms:

• Deployment:
  • AKA Rollout
  • Activity responsible for movement of new or changed hardware/software/documentation to the live environment
• Release:
  • Change to IT service that has been built tested and deployed together.
• Release Package:
  • A set of configuration items that will be built, tested and deployed together as a single release.
  • Get from current baseline to target baseline
• Release Record:
  • The record that defines the content of the release.
  • Relationship with all configuration items affected by the release
• Release Unit:
  • The components of the service that are released together. e.g. hardware, software and associated end-user documentation.
• Build:
  • Number to refer to the configuration items that create the IT service being deployed.
  • May be a date/number.
• Definitive Media Library (DML):
  • One or more locations where authorised versions of software are placed (may include licenses, documentation, etc.)
• Release Policy:
  • Formal documentation that defines the strategy for releases (from service design).
  • Governing policy document for release and deployment.
  • What constitutes major or minor releases, deliverables, remediation policy for rollback, how/where releases are documented, etc.?

Overview:

• Service design has release policy.
• Start putting together release packages.
• Service validation and testing to make sure release packages look OK (e.g. soft release).
• Release.
• Remediate if necessary.

Deployment options:

• Parallel (big bang).
• Phased.

Four phases:

1. Release and Deployment Planning.
2. Release Build and Test:
   • To DML.
3. Deployment:
   • With change management authorisation.
4. Review and close:
   • Experience, feedback, lessons learned, etc.

Change Evaluation

(Not covered in ITIL Foundation.)

Once changes have been deployed, how are they working out? Goes hand-in-hand with Change Management.

Service Validation and Testing

(Not covered in ITIL Foundation.)

Make sure all is working. Goes hand-in-hand with Release and Deployment Management

Wrap-up

The next post in this series will follow soon, looking at service operation.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

• Part 1 was an overview/introduction
• Part 2 covered service strategy

This post continues by looking at the topic of the second stage in the ITIL service lifecycle: service design.

Service Design

“To design IT services, together with the governing IT practices, processes and policies to realise the service provider’s strategy and to facilitate the introduction of these services into supported environments, ensuring quality service delivery, customer satisfaction, and cost-effective service provision”

Service design’s value to the business is:

• Reduction in total cost of ownership.
• Improvement of quality of service, consistency, implementation of new or ongoing services.
• Business/organisation strategic alignment.
• Improvement in IT governance.
• Streamlined IT processes.
• Efficient decision-making and ITSM.

It translates the concepts in the service strategy into hard and fast design.

There are four perspectives of ITSM:

• People – need input from stakeholders, end users, others.
• Products – services (not always physical products).
• Processes – to create the service design package.
• Partners – to work with in delivery (e.g. suppliers).

The output from service design is one or more service design packages (SDPs) containing:

• Requirements.
• Service design.
• Organisational readiness assessment.
• Service lifecycle plan.

There are five aspects of service design:

1. Service solutions – for new or changed services – from the service portfolio.
2. Management information solutions – able to support new or changed services.
3. Technical architectures – frameworks used to make sure service solutions are designed, implemented and consistent across the entire organisation.
4. Processes – skills, processes, responsibilities to roll out new or changed services.
5. Measurement methods and metrics.

ITIL defines the following Service Design processes, which are expanded upon in the rest of this post:

• Supplier management.
• Service level management.
• Service catalogue management.
• Availability management.
• Capacity management.
• Information security management.
• Design coordination.
• IT Service continuity management.

Supplier Management

“Ensures that suppliers and the services they provide are managed to support IT service targets and business expectations. Also, it obtains value for money from suppliers and contracts, while ensuring contracts with suppliers are aligned to business needs.”

Terms:

• Supplier – any third party supplying goods or services required to deliver services.
• Supplier and Contract Management Information System (SCMIS) – tools used to support supplier management, integrated with the Service Knowledge Management System (SKMS).
• Underpinning Contract – contracts with third parties for supply.
  • Basic terms and conditions.
  • Service description and scope – constraints etc.
  • Service standards – minimum levels that constitute acceptable performance and quality.
  • Workload ranges – which standards for what pricing.
  • Management information – data to be reported by supplier on performance – critical success factors and/or key performance indicators.
  • Responsibilities and dependencies – obligations of third party supplier and organization.

Supplier categorisation is used to assess how much time to spend on each supplier – either value/performance-based or risk/impact-based:

• Strategic – significant partners in immediate and long term.
• Tactical – business interaction and a lot of contact; manage performance.
• Operational – needed for day-to-day work (e.g. software licence provider).
• Commodity – low-level products that could be bought from many locations.

Supplier management activities deal with underpinning contracts (UCs):

• Define any new suppliers (e.g. to meet new needs).
• Evaluate new suppliers (make sure contract will be good).
• Place contracts into SCMIS (categorised).
• Supplier contract management (ongoing) to ensure service level criteria are being met (checking quality/cost, periodic reviews), manage relationship.
• Contract termination/renewal.

Service Level Management

Hitting the targets that supplier and customer have agreed on.

“Ensures that all current and planned IT services are delivered to agreed achievable targets. This is accomplished with a constant cycle of negotiating, agreeing, monitoring and reviewing IT Service Targets and Achievements.”

Terms:

• Service Improvement Plan (SIP):
  • Formal plans to help improve a process or service due to SLA breaches, training needs, weak systems, customer complaints, etc.
• Service Level Agreement (SLA):
  • Based on underpinning contract and OLA (see below).
  • Types:
    • Service-based (SLA to provide a single service).
    • Customer-based (SLA for all services used by a customer – e.g. by geography).
    • Multi-level (SLA for Corporate, Customer and Service levels).
• Common elements:
  • Introduction.
  • Service Description.
  • Mutual Responsibilities (service goes both ways – there may be requirements on the customer too).
  • Scope (defining targets).
  • Service Hours.
  • Service Availability.
  • Customer Support Information.
  • Contacts and Escalation Policy.
  • Security.
  • Costs and Charging Methods.
• Service Level Requirement (SLR):
  • Based on customer business objectives.
• Service Level Agreement Monitoring (SLAM) Chart:
  • Regular reporting.
• Organisation Level Agreement (OLA):
  • Sometimes referred to as underpinning agreements.
  • Make sure that internal suppliers (e.g. support teams) will help meet the SLA targets agreed with the customer.

Service Catalogue Management

“To provide and maintain a single source of consistent information on all operational services and those being prepared to run operationally. To ensure that it is widely available to those who are authorised to view it”

The Service Catalogue is a database or structured document with information about all live IT services, including those available for deployment. It is the only part of the service portfolio that is published to customers:

• Deliverables.
• Prices.
• Contracts.
• Ordering and Requests.
  • How to make the request – not the request itself!

Two views:

• Business Service Catalogue:
  • Customer-facing services.
• Technical Service Catalogue:
  • Support services, configuration items, etc.

Availability Management

“To ensure that the level of availability delivered in all IT services meets the agreed availability needs and/or service level targets in a cost-effective and timely manner. This is both current and future needs of the business.”

Objectives:

• Provide advice and guidance to all other areas of the business and IT on availability.
• Produce an up-to-date availability plan.
• Help diagnose and resolve problems.

Respond with:

• Reactive activities:
  • Monitoring.
  • Looking back at past incidents.
• Proactive activities:
  • Planning, designing, updating.

Terms:

• Availability:
  • Ability of the IT service or configuration item to perform its agreed function when required. Usually calculated as a percentage.
• Availability Management Information System (AMIS)
• Downtime:
  • Time when not available (e.g. when performing maintenance).
  • = Mean Time to Restore Service (MTRS).
  • Includes detection time, diagnosis time, repair time and restoration time.
• Reliability:
  • How long can perform without interruption (uptime).
  • = Mean Time Between Failures (MTBF).
• Resilience:
  • Coping with interruptions/time between issues.
  • = Mean Time Between System Incidents (MTBSI).
• Response Time:
  • Time taken to respond to an incident.
• Risk:
  • An event that can cause harm or loss to an objective (a threat). Conversely, opportunities are about the possibility of doing something.
  • So risk is associated with the impacts of doing or not doing something (including mitigations).
• Vital Business Function:
  • Any critical thing that you have to have.
• Serviceability:
  • Ability of suppliers to meet terms of contracts.

Capacity Management

“To ensure that the capacity of IT services and the IT infrastructure meets the agreed capacity and performance related requirements in a cost-effective and timely manner. It meets both the current and future capacity and performance needs of the business.”

Objectives:

• Produce and maintain an appropriate/up-to-date plan.
• Assist with diagnosing and resolving performance/capacity issues.
• Ensure all performance achievements meet all of their agreed targets.

Terms:

• Capacity:
  • The maximum amount of delivery ability that an IT service can provide (e.g. bandwidth, storage).
• Capacity Management Information System (CMIS).
• Modelling:
  • Predicting future behaviour of a system or service item, e.g. if increase use of the service.
  • Analyse using performance monitoring data.
• Tuning:
  • Customising the use of resources in appropriate quantities.
  • Analyse using performance monitoring data.
• Business Capacity Management:
  • Plan to meet business needs and requirements.
• Service Capacity Management:
  • About performance of the services themselves.
  • Prediction of end-to-end performance.
• Component Capacity Management:
  • About the capacity of individual components (network, servers, applications, etc.).
• Performance monitoring:
  • Monitoring performance of components of the service.
• Demand management:
  • Comes from service strategy.
  • Balance costs and required resources; supply and demand.
• Capacity planning:
  • Forecasting when more (or less) capacity will be needed.
• Application Sizing:
  • Ability to support new or modified applications and know what their capacity requirements will be.

Information Security Management

“To align IT security with business security and ensure that the confidentiality, integrity and availability of the organisation’s assets, information, data and IT services matches the agreed needs of the business.”

Terms:

• Confidentiality:
  • Ensuring information remains confidential.
• Risk Management:
  • Assess and manage/control risks.
• Security Management Information System (SMIS).
• Information Security Policy:
  • A list of rules/requirements to follow.
• Threat:
  • Exploits vulnerabilities (e.g. denial of service).
• Vulnerability:
  • Weakness exploited by threats (e.g. open network ports).

The Information Security Management System:

• Guides the development and management of an information security programme.
• Formal process.
  • Cycle of:
    • Plan: identify measures, procedures, requirements (e.g. regulatory), etc.
    • Implement: put the above in place.
    • Control: making sure documentation is present, all in order.
    • Evaluate: audit for compliance.
    • Maintain: making sure agreements are documented and improved upon (CSI).
• Includes:
  • Physical security (e.g. of devices).
  • Procedural security: how to secure things.
  • Organisational security: security policies, etc.

Design Coordination

“To provide and maintain a single point of co-ordination and control for all activities and processes within this stage of the service lifecycle.”

Includes:

• Activities relating to the overall service design lifecycle stage.
• Activities relating to each individual design.
  • Based on service design packages (SDPs).

IT Service Continuity Management

Dealing with “Disaster Recovery”.

• Business Continuity Plan:
  • Business Impact Analysis.
• IT Service Continuity Plan:
  • Triggers, actions, etc.

Recovery Operations (in order of urgency):

• Immediate: hot standby/swap (e.g. load balancing/mirroring).
• Fast: recover within a few minutes.
• Intermediate: warm standby (e.g. restore data from backup).
• Gradual: cold standby (restore non-critical services over time).

Roles:

• Board: crisis management and company-level control.
• Senior management: direct and co-ordinate; authorise spending money.
• Management: reporting on progress.
• Supervisors and staff: execute plan.

Wrap-up

The next post in this series will follow soon, looking at service transition.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

A few days ago I published the first in a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification. Part 1 was an overview/introduction. This post continues by looking at the topic of the first stage in the ITIL service lifecycle: service strategy.

Service Strategy

“The purpose of the service strategy stage is to define the perspective, position, plans and patterns that a service provider needs to be able to execute in order to meet an organisation’s business outcomes”

“Strategy is a complex set of planning activities in which an organisation seeks to move from one situation to another in response to a number of internal and external variables.”

Henry Mintzberg defined 5 Ps of strategy. ITIL uses 4:

• Perspective – view of selves, vision and direction.
• Position – where we are in relation to the rest of the market.
• Plans – details for supporting and enhancing perspective and position.
• Patterns – define the conditions and actions that need to be in place, and need to be repeatable to meet the objectives of the organization.
• Ploy is the 5th P, not used in ITIL.

Customer perception and preferences drive expectations. Quality of product, ambience, etc. affect service value.

Utility + Warranty = Value

• Utility is about “fit for purpose” – support performance, remove constraints.
• Warranty is about fit for use – availability, continuity, capacity, security.

ITIL defines the following Service Strategy processes, which are expanded upon in the rest of this post:

• Service portfolio management.
• Business relationship management.
• Financial management.

There are two more processes that are not discussed at ITIL foundation level:

• Demand management.
• IT strategy.

Service Packages, Service Level Packages and Service Assets

Service packages are the things that we offer to our customers:

• The Core Service Package provides what the customer desires – the basic outcome.
• Enabling services allow the core service to be provided.
• Enhancing services are the extras that aren’t necessary to deliver the core service but make the core service more exciting or enticing.

Sometimes customers want more warranty or more utility – Service Level Packages provide choice:

• Warranty:
  • Availability levels.
  • Continuity levels.
  • Capacity levels.
  • Security levels.
• Utility:
  • Features of the service.
  • Support of the service.

Levels will relate to price.

Service Assets:

“A resource or capability used in the provision of services in order to create value in the forms of goods and services for the customer.”

• Resources are tangible (e.g. inputs to a process) – boxes, method of taking payment, etc.
• Capabilities are intangible – people with knowledge, behaviours, processes, etc.

Service Portfolio Management

Service Portfolio Management is about managing the service portfolio – not the services, processes, assets, etc.:

“To ensure that the service provider has the right mix of services and the investment in IT with the ability to manage or meet your business outcomes.”

Service portfolio is a database of services managed by a service provider – the complete set of services, including:

• Service Pipeline – IT services of the future; being developed, not available to customers (yet).
• Service Catalogue – database or document of current IT services – customer-facing or support services (internal IT).
• Retired services – all IT services that are no longer useful for customers or internal organisation,

When looking at service portfolio, may need to consider service investments:

• Transform the business (TTB): new market, ventures, high risk.
• Grow the business (GTB): gain more customers, increase value, capture more market space (moderate risk).
• Run the business (RTB): status quo, focus on core services (low risk).

Service portfolio management is about establishing or including services – 4 phases:

• Define – document and understand existing and new services to make sure each has a documented business case.
• Analyse – indicate if the service will optimise value and to understand supply and demand.
• Approve – make sure that we have enough money to offer this service (retain, rebuild, refactor, renew or retire).
• Charter – authorise the work to begin on a project.

Financial Management

Balances requirements between IT and business requirements: balance cost of service against the quality of the service. Looking for highest quality for lowest cost.

• Budgeting – about the future (for things in pipeline, and for current services).
• IT Accounting – make sure we know where we are spending our money. Group costs to see what part of service provision is costing most, rebalance/adjust as necessary “the process responsible for identifying the actual cost pf delivering the IT services compared with the costs in managing variance”. EV-AC=CV (expected value – accumulated cost = current value).
• Chargeback – charge customers for use of IT services. Notional accounting where no money changes hands (e.g. internal showback).

Service valuation is about charging an appropriate price for a service based upon costs.

Business case to justify costs, benefits, risks, etc. with methods, assumptions, business impact, etc. (or a business impact analysis – BIA – i.e. what is the implication if we don’t offer the service).

Business Relationship Management

“To establish and maintain a business relationship between the service provider and the customer based on understanding the customer and their business needs.”

“To identify customer needs and ensure that the service provide is able to meet these needs as business needs change over time and between circumstances. BRM ensures that the service provider understands the changing needs. BRM also assists the business in articulating the value of a service. Put another way, BRM ensures that customer expectations to not exceed what they are willing to pay for and that the service provider is able to meet the customer’s expectations before agreeing to deliver the service.”

Service Level Management deals with service level agreements (SLAs) cf. BRM is concerned with understanding business needs – goal is customer satisfaction for both but measured in different ways. For BRM measured in improvement or recommendation of services.  BRM is about a positive relationship and defines the service catalogue.

Different types of relationship:

1. Internal service provider.
2. Shared service provider – to more than one business unit (still internal).
3. External service provider – to external customers. Business Relations Manager talks to clients.

Business Relationship Manager will use:

• Customer portfolio – database of information about customers and potential customers who will consume a service (commitments, investments, etc.).
• Customer agreement portfolio – database of current contracts with clients (services delivering, with SLAs).

Activities include:

• Marketing, selling and delivery.
• Working with Service Portfolio Management to properly respond to customer requirements.

Wrap-up

The next post in this series will follow soon, looking at service design.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.