Blue Flower

ITIL is simply a framework for best practice. When you're walking on unknown territory, the best way for not to fall on your steps ,is always better to follow a path that has already been walked many times by other people. ITIL (IT Information Library) principles and baselines lay down for you good advise about how to manage IT services, they are not rules or regulations just best practices (all vendor neutrals) that tell you the things that work. First of all let's start with some definitions:

ITSM ;IT Service Management is a set of specialised organisational capabilities for providing value to the customers, in the form of quality IT services, that meet the needs of their business, this is basically the implementation of services that is a mix of people, process and information technology (computers, etc). Every IT department should be consider an IT service provider, and adopt the principles and practices of service management to deliver IT services.

IT Service Provider ;ITIL envision 3 different types of service providers:

  • Internal Service Provider ;located within the business unit it supports, for example the IT department of an University
  • Shared Service Unit ;located within the business but shared among other business units (still in the same organisation), for example the IT department or a large multi-divisional organisation
  • External Service Provider ;this is an outsourcing partner, who deliver their services outside of the provider organisation

Service ; service is a means of delivering value to customers, by facilitating outcomes that customers want to achieve, without them having to have ownership or to bear specific costs associated such as infrastructures. The services should be delivered at an affordable cost and acceptable level of quality and performance. The service should always be "fit for purpose", and they can be grouped according to the value they provide to the customers. A Service Package comes with three different types of services:

  • Core Services ;deliver the basic outcomes required by the customers
  • Enabling Services ;the ones that ensure the core services can be delivered successfully
  • Enhancing Services ;makes the core services more appealing or attractive to the customer

Service Level Packages are a pick-&-mix of the above packages. Ultimately, all services need to provide value to the customers

Service Value ;hey, value is most of the time in the eyes of the beholder, and in ITIL service value is determined by 3 key factors: Customer Perceptions, Customer Preferences and Business outcomes. Be aware that value involves a warranty and an utility (and a reasonable expectation of what the customer expects). The formula to calculate Service Value is: Utility + Warranty = Value

  • Utility is summarised as "what the service does" and is commonly known as 'fir for purpose
  • Warranty refers to the ability of the service to be available when needed, and have sufficient capacity to meet the customer requirements, this is commonly referred to as 'fit for use'

Process; a process is a specific set of activities designed to accomplish a specific objective; a process takes inputs (that could well be the outputs of other processes) and turns them into outputs. Once the output has been confirmed, the process can be declared as effective; if the activities utilised a minimum of resources ,the process can also be declare efficient. All Processes have four common characteristics: 1)Respond to a specific trigger. 2)Measurability, the activities's performance of each process can be measure. 3)Specific outputs, the result of a process must be identifiable and have a measure of value. 4)Customers & Stakeholders, the process should meet the expectations of the recipient

The Process Model is structured as below:

  • Process Control ;process owner, process policy, objectives, documentation and process feedback
  • Process ;the triggers, process metrics, roles, procedures, work instructions and process improvements
  • Process enablers ;process resources and process capabilities

The Process Owner/s is/are accountable for the process being fit for purpose. All processes are and can be measured, and have specific results. It is important to understand that all processes across the life-cycle are linked, and that they interact and influence one another.

Assets ;assets can be divided in Resources and Capabilities, and all processes need to have them in order to be successful. Capabilities & Resources cannot provide value on their own, it is the combination of these two that enables a process to deliver successful service management

Resources ;they are the direct inputs for the production of services, and they cover everything from money, infrastructure items, applications, people, etc ;they are considered physical assets

Capabilities ;these are the assets that allow the organisation to achieve something of value, such as the ability to coordinate, control and deploy resources in the form of a service; typically these include experience and knowledge embedded in the organisation

Functions ;in ITIL a function is defined as a group of people (and other resources or tools) that are use to carry out a process or process activities. There are well 5 defined functions in ITIL:

  • Service Desk ;single point of contact for users
  • Technical Management ;expertise of the technological infrastructure
  • Applications Management ;expertise of the management applications
  • Facilities Management
  • IT Operations Control 

Functions can be carried out by Group (number of people who perform similar activities), Team (a more formal structure number working together with a common objective), Departments (formal organisation structures within the same organisation) or Division (number of departments grouped together, often within the same organisation)

Metrics ;metrics are use for the following 4 purposes:

  • Validation ;authenticates whether the strategy and vision are supported or not
  • Justification ;ensures whether you have the right targets and metrics
  • Direction ;ensures that people can be guided to change their behaviours based on factual data
  • Intervention ;ensures that corrective actions are applied

Customers ;ITIL differentiates between internal and external customers, this is because you need to be able to differentiate between service that support an internal activity and those the deliver business outcomes. These are the 2 types of customers:

  • Internal ;they work within the same organisation as the service provider
  • External ;not employed by the organisation or employed by a separate legal entity. External customers pay for the services under agreement through a legally binding contract

Each customer is unique, and they value different things, one might value quality of services, other the prompt delivery, the cleanses, the spirit of empathy it goes with it, etc

Stakeholders ;are individual or groups that have an interest in the organisation, service or project, and that are engaged in activities, resources, target or deliverable from service management. Types of stakeholders:

  • Customers ;buy goods or services
  • Users ;use the service that is bough by the customer
  • Suppliers ;are responsible for the supply of good or service that are required to deliver IT services

Roles in ITIL the term role is defined as a set of responsibilities, activities and authorities that are granted to a person or a team (remember that a 'team' in ITIL is referred as a 'function'). Roles can be shared or combined, but there can only be one process-owner for each process, and as well for each service there can only be a service-owner. There are different roles to consider, these ones appear in all life-cycle stages:

  • Service Owner ,remains accountable for the delivery of the service; service owner often own more than one service, and they need to ensure that the customer's requirements are understood, thus communicating with the customer is crucial. They also need to ensure that the services follow the information security management policies
  • Process Owner, this could include the Process Manager and Process Practitioner, the one actually doing the work. The process owner is responsible for documentation and the Metrics & Measuring, ensuring that the processes they're responsible for are managed and reported correctly. They are also responsible for Improvement opportunities and strategy of the related process, and ensuring of course the process if fit for purpose
  • Process Manager ;accountable for the success of a process and for managing its day-to-day implementation
  • Process Practitioner ;the one actually doing the job and producing evidence in the form of records, the one carrying out the process activities. Process managers and process owners should seek out the views of the practitioners when attempting to identify possible improvements, they'll know for sure what is wrong 

RACI Model ; RACI is a simple method to identify potential conflicts or issues, visually in the matrix. It strands for Responsible (the people doing the work, the process practitioners), Accountable (ownership of the process), Consulted and Inform. If you're an IT Manager, do apply the RACI Model to your team: https://www.projectsmart.co.uk/raci-matrix.php These matrix are useful to represent for example Operational Level Agreements (OLAs)

Training and Competence ;training is not a one-off activity, but rather it needs to be continuous as the service evolves. The personnel need to be competent and communicate efficiently, both in speech and writing. The Skills Framework for the Information Age (SFIA) describes job roles and responsibilities here: https://www.sfia-online.org/en/framework/sfia-7/skills-home 

ROI ;Return of Investment, the formula is increased profit from service / cost

Service Automation ; this can be applied in all areas (knowledge, information, processes, etc) to enhance performance, capacity management and optimisation. To ensure that automation fulfil its promises of benefits, it is necessary to do prior preparation and clarify the exact steps that need to be carry. Automation should always be tested, and the only tasks or processes subject to automation are those that have a recognisable recurring pattern

 

The ITIL principles are framed into 5 categories, also called 101 and/or the Circle of Life for services:

1.- Service Strategy

This is the core stage of the life-cycle, as it includes the business perspective, position, future plans and activities that will reach it to deliver the services the business wants to deliver. The objectives of the Service Strategy are the following:

  • Providing an understanding of what the strategy is
  • Identifying the services and the customers who will use them, as well as opportunities for services and how to make the best of them
  • Understanding how to define value creation, the organisational capabilities to deliver the services, the level of demands and how to establish a relationship between the provider and the customer
  • Defining the processes and services that will deliver the strategic plans, and the level of investment that will be required
  • Coordinating and documenting the use of service assets, how they can be use and how to optimise their performance

During the phase of Service Strategy the following questions are answered (notice that risks are not considered at this stage):

  1. What services should we offer and to whom?
  2. How can we justify strategic investments?
  3. How do we stand out from competition?
  4. How can we create value for customers and stakeholders?
  5. How can we allocate resources and prioritize investments in the Service portfolio?
  6. How can we use financial management to control value creation?
  7. What are the Patters of Business Activity (PBA)?

The Service Strategy manages 3 processes: Demand Management, Financial Management and Service Portfolio Management

Pattern of Business Activity ;Customers are the key, identify well what the customers want and in that way you'll differentiate yourself from the competition. You can identify PBA (Pattern of Business Activity) in your own company by discovering what customers want; for example if your customers like coffee and you happens to have a coffee shop, your morning will be busy! Another PBA is Valentine's day for flower shops. PBA knowledge allows you to divert and utilise your resources intelligently

Service Portfolio Management ;this process ensures that you have the appropriate mix of services delivered by the service provider to meet the requirements of the customer, its objectives are to maintain a managed portfolio of the services provided, distribute information about these services, provide control and track organisational spend on IT services throughout the service life-cycle.

The Service Portfolio is a document or graph that should include past (or retired) services that can function as an archived, showing documentation of why services were discontinued. The portfolio should also include current services, a menu or catalogue of the services in use. Finally, a service pipeline, route-map or strategy for the future should be included too in the portfolio, so we all know where the company is heading to. The service portfolio should also include the business case that was used to create the related service, this is so that (at the time of cutting the budget) people will know what this particular service came from and why it is necessary

Retired Services are part of the portfolio, not the catalogue

Finance Management ;money is the common language between all business, no matter the nature of the business all of them will understand a 10% sale increased. There are 3 main processes to consider in finance:

  1. Budgeting, all about control in both ways of the flow, money coming in and out; budgeting consist of a periodic cycle (usually annual) of negotiation to set budgets and the monthly monitoring of the same
  2. Accounting, accounts for the way money is spent, this includes the term Return of Investment (ROI), as
  3. Charging,the process of billing our customers to get income for the services provided. You might want to setup a Cost Center that will take care of the charging and also a Profit Center

Business Case ;there are 5 categories that need to be included in a business case when applying for money for a service

  1. Introduction ;must have a killer intro, presenting the business objectives addressed by the service
  2. Methods and assumptions, defines the boundaries of the business case such as its time period used to define its costs and benefits; make it real and cover your back to ensure what will happens if ingredients change
  3. Business impacts ,the financial and non-financial results anticipated for the service initiative proposed in the business case
  4. Risks and contingencies, tell what you'd do if things don't go as expected
  5. Recommendations ,specific actions recommended that should include both financial and non-financial impacts

Business Relationship Management (BRM) ;as part of your Business Strategy you need to contact your customers and ensure you know what they need. Create a strong communication channel between you and the customer, knowing the purposes and objectives of the services. "Measure twice, cut once" is the motto you should use when delivering services to your customers. Create a Business Relationship Manager (BRM) to ensure the customer's expectation are met, go on regular meetings with the customer, get feedback on our services, etc. When you provide services, you need to know 'exactly' how your customers are doing and feeling. BRM should ensure the service is 'fit for purposes', the utility functionality and the warranty capacity. The customer should see our services as a value 

 

2.- Service Design

The success or failure of any service or project is largely dependant of its initial design. If a service is unable to deliver the level of service required consistently (because of poor availability, capacity issues, insufficient security or lack of service continuity), it will have failed to deliver the warranty required. The Service Design is involved in both the planning of new services and changes to existing ones, ensuring that the new/changed services fulfils the Service Strategy by delivering the business objectives. Successful design depends on taking the time to plan ahead, identifying and managing the risks to ensure a successful outcome; insufficient planning leads to costly rework and delays

Service Design activities must be undertaken on a regular basis as they result of identifying a new or changed business requirement 

For Service Design you have Perspective, Positions (your place in the market), Plans (where you want to be) and Patters (conditions and activities to achieve your goals). These are the processes that are included within Service Design:

  1. Design Coordination
  2. Service Catalogue Management
  3. Service level Management
  4. Availability Management
  5. Capacity Management
  6. IT Service Continuity Management
  7. Information Security Management
  8. Supplier Management

Successful Service Design must consider the four key elements (also known as 4 Ps) involved in the design:

  • People ;they need to be prepare (training) to support/design the service else it will fail
  • Processes ;each one should be documented and assessed to identify whether changes are required
  • Products ;technologies and tools chosen to assist in the design or to support the service later
  • Partners ;are manufactures, vendors and suppliers, ensure they are chosen carefully to support the service

Service Design Package (SDP) enables the transition from design to live, and captures all required information. SDP consists of one or more documents, produced during the design stage that later on are passed to the Transition Stage. The components that are considered part of a SDP are:

  1. Functional Requirements
  2. Service Level Requirements
  3. Management Requirements
  4. Design and topology

The typical contents of a SDP are:

  • Original agreed business requirements, how the service will be used, key contacts and stakeholders
  • Functional, Management and Service Level requirements
  • Technical design including hardware, software, networks, data, applications, technology, tools and documentation
  • Service Life-cycle plan
  • Service Transition plan
  • Service operational Acceptance plan
  • Service acceptance criteria (SAC)

Service Acceptance Criteria (SAC) ;ensures services meet both expected functionality and quality, and that the service provider is ready to deliver the service

 

Service Level Management (SLM);it is an important area because it is through the Service Level Management that the IT service provider ensures that the services offered are aligned to the business requirements. One of the objectives of SLM is to develop appropriate targets for each IT service, these target must be specific and measurable, no room for expressions such as "as soon as possible" or "reasonable endeavours" should be used in a SLA

Operational Level Agreement (OLA) are agreements between the different departments within the same company, and when these agreements have to be made between 3rd party providers are called Underpinning Contract (UC). The OLAs should be kept simple because they are between colleagues, don't add legal jargon or any obfuscation language. Ensure you provide to the customers on regular basis Service Reports, with the number of calls being close, time responses and other metrics; you can submit these reports using SLAM Chart (Service Level Agreement Monitoring) with tables, colours, visual representations, etc

Service Level Requirements (SLRs) represent what is required by the customer for a particular aspect of the service, and are therefore based on business objectives; they relate primarily to the warranty aspects of the service, defining the capacity, security, availability and service continuity requirements.

Service Level Agreement (SLA) is an agreement between the Service Provider (SP) and the Customer. SLA should be specific, clear and unambiguous expectation, and include SLR (Service Level Requirement) and metrics that indicates whether the SP is meeting its targets. You must have measurable targets to proves the services that you provide. SLA should be written in plain language, with few technical expression as possible and a glossary included; legal terminology is unnecessary and can cause confusion. SLA should make a distinction between the service and the support provided for that service. In a SLA reliability of services can be measured with:

  • MTBF ;Meantime between failures, it measures uptime
  • MTBSI ;Meantime between Services incidents, it measures time between one failure and the next failure
  • MTRS ;Meantime to Restore Service, how long will it take to come back online after a failure; this is an important part of the availability management: a machine can go down and take 30' to fix it, but if you need 3 days to call an engineer from Germany that time should be added too; this basically measures downtime

Every commitment in a SLA should be supported by an underpinning agreement, either an OLA or UC. ITIL organises the SLA according to their structure, which could be:

  1. Service-base SLA ;the agreement refers to one service only
  2. Customer-base SLA ;the customer requests one SLA for finance, one for marketing, etc, because each department has different needs. This approach is difficult to monitor by the provider
  3. Multilevel-base SLA ;this structure prevents unnecessary duplication, and it has 3 levels: Corporate, Customer and Service

SLM interfaces with several other processes to ensure agreed services levels are met, like Problem, Availability, Capacity and Incident Management

 

Service Improvement Plan (SIP) now known as Continual Service Improvement (CSI) ;measuring the customer satisfaction level is also the responsibility of the service level management, surveys should be done and meeting should happen regularly, the temptation of avoid face-to-face meetings by sending copies of reports should be resisted. The document that contains all of these is called SIP or CSI

is a plan to improve the service that you're delivering

 

QoS is what you get (Quality of Service) when you spend the proper time designing a service  that aligns well with the customer and business need. The TCO (Time Cost Ownership) should go down when the right time is spent designing the service. There are 5 aspects that should be included in the SDP: 

  1. Service ;the services should be listed
  2. Tools ;the management information tools to manage the service
  3. Technology ;should describe the architecture that the service will use (if it is a virtual design would it be VMware, Azzure, etc)
  4. Processes ;a collection of activities describing who is responsible of what. Processes can be automated once they have been thoroughly tested ensuring that they are reliable and working
  5. Measuring ;design the metrics and the way by which the service will be measured in the Service Operation mode

 

Catalogue Management Process ;should have a portfolio that, as we know, is divided in 3 sections: pipeline, catalogue and retired services. The scope of the catalogue management process includes all services that are being transitioned or have been transitioned to the live environment. The Catalogue is the customer facing document of the company, and it should contain the following items: 

  1. Provide a single source of the services that we provide, consistent information showing what is available
  2. Make it available to those approved to access it

The Catalogue has 3 views: Customers (a view for customers group A, a view for customers group B, etc), another view for Technical Support and another view for Third Party provider. This different views of the catalogue is called Hierarchy of Services

 

Availability Management ;the term used in availability managements are Reliability, Resilience, Serviceability and Maintainability; design well from the beginning to avoid fiasco later, and be aware the failure of one component can make the whole service unavailable to the users. VBF (Vital Business Function) are to be considered and take care of (make them resilience!), as they are the most critical part of services. The availability management touches all the life cycle sections, and can be divided in: 

  1. Proactive Activity type ;planning & designing, new or changed services, risk assessment and countermeasures implementations (redundancy, firewall, intrusion detection systems, etc); testing
  2. Reactive Activity Type ;monitoring and investigations to ensure you have resilience in place

When calculating the availability of a service, 99.9% should be well understood: if the service is expected to run 24/7 then that 99.9% does not have the same impact as if the service is listed on the SLA to be available from 9am to 6pm, because a failure at 10pm of 2 hours will not affect the business, and is out of the scope of the SLA.

Availability is calculated using the formula AST-DT/AST x 100, where AST is Agreed Service Time and DT is downtime

Capacity Management ;this process has the responsibility for ensuring sufficient capacity exists at all times, the service might still work (so availability is there) but the performance could be appalling if capacity manager is not taken into consideration, it should be thought about it earlier on in the Service Life Cycle process. Capacity Management should ensure as well that, if the demand of the service fails, the capacity provided for that service should also reduced, to ensure unnecessary expenditure is avoided.

  1. Capacity Plan ; should include scenarios for different predictions (Valantine's, Christmas days, etc) including the business changes, and it should cover 12/18 months ahead so that any planned expenditure can be included in the negotiation of the annual IT budgets
  2. Guidance ;record anything that could affect performance
  3. SLAs should be included, 
  4. Diagnosis and Impact of the new services to be implemented should also be considered

Regarding utilisation you can see trends, like the lovely PRTG or Splunk. Regarding processes, there are 3 important Capacity Management sub-Processes to consider:

  • Business Capacity Management ;(strategy)what they need now and in the future
  • Service Capacity Manager ;(tactical) control, prediction and ensure the performance meets the expectation, monitoring, reporting, etc
  • Component Capacity Management ;(operational) focus on individual items of the services, ensuring all of them performs well; be proactive and identify a trend on specific components before a retention occurs

The Capacity Management Information System (CMIS) is where all these activities and changes regarding capacity are stored; the CMIS forms part of the overall Service Knowledge Management System (SKMS)

IT Service Continuity Management (ITSCM) ; this process focus on major events that have a catastrophic impact on the ability of the service provider to supply the vital services that enable;e the business to achieve its aims; what would happens when the third party chip you use to make your motherboards become discontinued, or out of stock? You need to plan for that by doing the following:

  • Business Impact Analysis (BIA) ; identify RTO (Recovery Time Objective) and have a plan for Disaster Recovery Plan (DRP)
  • Business Continuity Plan (BCP) ;you must have one in place, else what would you do is your street is cut for 2 x days due to a fire, police investigation or terrorist attack?
  • Vital Business Function (VBF) ; ensure there is a plan for Business Continuity Management (BCM)
  • Contingency Plans ; test fail-over procedures by doing Business Impact Analysis Exercises, when in doubt test it out. This section should include negotiation with third-party suppliers too

 

Risk Management ;You have threats, assets and vulnerabilities, an where they meet this is where you have a risk. The company needs to have risk identification, assessment, management and mitigation. Risk Management is a repetitive activity, and it should become part of the accepted culture of any program or initiative

Information Security Management (ISM) ;include security earlier on in the Service Design process, do this rather than later on trying to add it as an 'add-on'. A service that is insecure will not deliver the value to the customer. The principles of ISM are:

  1. Confidentiality ;data in transit should always be protected, this can be achieve using encryption, access control mechanism (AD, smart-cards,etc)
  2. Integrity ;the information should be completed and not have been tampered, we can use hash to verify integrity
  3. Availability ;the info should be available and useful when needed, for example use RAIDs, fault tolerance routing, High Availability, etc

During the Operations Cycle the Access Management takes care of the above CIA points (Confidentiality, Integrity and Availability), creating an Access Control Policy, Password Control Policy, email, internet and antivirus policy, remote access policy, Information Classification policy, document classification policy, assets disposal policy, records retention policy, etc. These policies are to be stored in the Security Management Information System (SMIS)

Security is an ongoing process, and for it to be effective it should be considered as an integral aspect of the design and operations

Service Design Supplier Management; ensures that partners and providers can continue to support our IT services. Supplier Management is on the design but it touches every area of the life cycle. Service Level Requirements (SLR), Service Level Agreements (SLA) and Service Level Management (SM) are values that are looked up when a business work with a supplier. To keep track of your supplier you use SCMIS (Supplier & Contract Management Information System) that could as well be an excel document with the supplier details.

Supplier Management does not deal with internal suppliers.

Design Coordination ;this process carry out the coordination of the many different activities of service design, acting as a single point where complications, potential sources of conflict and misunderstandings are avoided. Design Coordination checks that the design conforms to the agreed standards, that is both fit for use and purpose, try to identify any improvements and ensures consistency across the designs, thus reducing risks significantly (design coordination prevents you from using metrics while other departments are using imperial)

  

3.- Service Transition

Previously, during the Service Design stage, you would have created the SDP (Service Design Package) which is now passed to the Service Transition team, to implement the services listed in the SDP, thus reducing risks, managing changes effectively, better expectations of all parties and a increased success deployment thanks to the fact there is a SDP to follow

Service Transition is a bridge between the Design and the Operations; during the transition process we build, test, change, install, implement, configure, deploy and release the services and/or applications needed. Some of the processes of the Service Transition cycle are:

  • A) Change Management
  • B) Transition planning and support
  • C) Service Access and Configuration Management
  • D) Knowledge Management
  • E) Release and Deploy Management
  • Service Validation and Testing, not included in exam
  • Change Evaluation, not included in exam

Of all these processes, only the following 3 processes are fulfilled solely within the Service Transition phase: Change, Knowledge and Configuration (Service Assets) Management

Another hidden process is the "re-use", some apps or services that can be included in new releases, as well as "test environments" that you need to have to test the new services or releases

A) Change Management Process ;always ensure that Business Continuity is not affected when making changes to the system. ITIL defines this process as "to control the life-cycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services". Change Management keeps controls of all changes which must be authorised either by implied or explicit. The way it works is that you first present your change -Request for Change or RFC- to the CAB (Change Advisory Board) who asses and analyses the implications of the change. CAB could have some prerequisites before even accepting a change, like for example if it needed, if there a risk, can be rollback, do we have resources to implemented, as the change being tested? CAB can prioritise the changes based on these metrics.  All changes should be:

  • Approved
  • Recorded, so we know what we are changing and can rollback if needed
  • Update ,reflect the new change in the CMS (Configuration Management System) of the company, updating documentation, etc

Change control is the key of this all process, you don't want to change stuff as they pleased, no, no: uncontrolled change may trigger or be the cause of incidents in the infrastructure. ITIL framework identifies these differences between a change, request for change and change record:

  • Change ;the addition, modification or removal of anything that could have an effect on IT services
  • Request for Change ;formal proposal for altering a configuration item, it includes details of the change to be completed
  • Change Record ;a capture of the details of the life-cycle of a change, change records should reference the configuration items affected by the change and they are stored in the configuration management system or service management tool

There are different types of changes:

  1. Normal change ;this goes through the CAB as explained above, and can of course be denied if, for example, the rollback procedure is not feasible. You need to have a well-thought out practice procedure before you put forward a RFC (Request for Change)
  2. Standard change ;this is a change that has been pre-authorised by the CAB, it could be a low risk, low impact or a straight forward change; these types of changes greatly enhance the effectiveness of the Change Management Process
  3. Emergency change ;this is a change that is urgent and must be implemented asap, still it needs to be approved by the E-CAB (Emergency CAB) who will need to provide authorisation as normally these emergency changes have not been tested or don't have a proper rollback procedure. Emergency changes should obviously be few and far in between

Remember that technician just maintain, they're not allow to make any configuration changes without authorisation. Every change request should be subject to the know as seven Rs of assessment questions:

  1. Who raised the change?
  2. What is the reason for the change?
  3. What is the return required from the change?
  4. What are the risks involved in the change?
  5. What resources are required to deliver the change?
  6. Who is responsible for the build, test and implementation of the change?
  7. What is the relationship between this change and other changes?

B) Transition Planning and Support ;this process provides overall planning and coordination of resources and all of the changes, ensuring change A does not damage change B and vice verse, and that certain policies have to be followed, use this or that software for the update, etc; if there is a conflict between changes this is where it gets resolve, in the transition and planning support. During this process not only the staff members are consulted but also the business and user community.

  • Technical Management Function ;management of the IT infrastructure
  • Application Management Function ;managing applications

C) Service Access and Configuration Management (SACM) ; this relates to an inventory of all your assets as well as the relationships between them. Configuration Items (CI) are stuff that you want to track on the inventory like Operating System, memory, hard drive, etc. The SACM should be able to capture the relationship between items and to provide the Status of the items (deployed, in maintenance or maintenance history, broken, historical allocation, etc) as well as Reports, Verification (data should be accurate) and Auditing. Whenever we do changes to certain components, having this information up to date is critical because one of the way that an IT department can show its efficiency is by demonstrating that it has control over the assets it manages.  Service Assets and Configuration Management process ensures that configuration items are properly identified and managed 

Configuration Management System (CMS) is another name for an inventory, and obviously it needs to contain a Configuration Management Database (CMDB) where all changes are recorded, this includes changes to contracts, agreements or physical assets

Software Assess Management (SAM) ;a platform to record all the licenses, software, where to install, etc for the company. SAM is defined by a Definitive Media Library (DML) that keeps records of the different versions we have (1.0, 1.2, etc) all the ones that are more current, this can be understood like a folder with the latest versions of all software installed in the company

 

D) Knowledge Management ;share experience and information and ensure they are available for the appropriate users; this info will allow us to execute better decisions makings for the future, thus saving money and time. Service Knowledge Management System (SKMS) is a platform that controls the access to the right individuals, inside the SKMS you can find the CMS (Configuration Management System), DLM, SLAs, as well as the Portfolio Catalogue. Please do not keep re-inventing the wheels, so we have the DIKW structure:

  • Data ;should be in the SKMS, for example an incident that has been logged of slow performance 
  • Information ;that's what data transfer to, it gives context to the data, for example the incident logged occurred for 3 hours
  • Knowledge ;is what we get from the information, for example those 3 hours happens to be during the backup process; knowledge is formed when you apply experience, context and understanding to the information analysis
  • Wisdom ;strong common sense is acquired by knowledge, for example, be 'become wise and schedule the backup for off-operations hours

E) Release and Deployment Management process ;plan, schedule and control  the deployment of software releases is the main purpose of Release and Deployment Management. Building, Testing and Deployment should be part of the SDP and should cause no harm and be compatible between versions. Knowledge and Transfer shall be present in the new deployments, so people know what the new features are and how to use them. A Release Policy should be defined to ensure effective management of releases, specifying the requirements and a definition of what is actually a release, because minor operational changes can be addressed by change management; the policy should specify the expected frequency for releases, any automation that can be applied, the entry and exit criteria for each stage of the release, etc

Release and Deployment is structured in four phases:

  1. Release and Deployment Planning ;stars with the authorisation from change management to make a release, then a plan in created
  2. Release Build and Test ;in this phase the package is built, test and checked into the DML with proper documentation
  3. Deployment ;the package is deployed to the live environment, and handover to the service operation team is done
  4. Review and Close ;this is where experience and feedback are captured, performance targets are reviewed, achievements are assessed and lessons are learned

 

Change Management authorised the changes before they are deploy in new releases  

 

4.- Service Operation

It is during Service Operation when the services are actually being delivered and optimise. The outputs from Service Strategy, Design and Transition become all visible during service operation. It consist of delivering the service efficiently and at an acceptable cost, and within the SLA previously designed and agreed. ITIL describes four functions that are part of the Services Operations life-cycle:

  1. Technical Management ;required to manage the IT infrastructure and also provide technical support  and should be involved during the technical strategy of the service
  2. Application Management ;this function shares many features with the technical management, the difference is they only relate to the management of IT application software (including external supplier applications) and not infrastructure or application development. They help in the design of the application, assist in their deployment, support it in live environment and identify and implement improvements
    1. Application Development vs Application Management ;there is a big difference between the two: while application development is normally a finite activity (it finished once the app is developed) the application management on the other hand remains involved throughout the life-cycle of the application. There is a growing tendency, however in business, to end the division between these two teams
  3. Operations Management ;its role is to carry out all the day-to-day activities that are required to deliver the services provided; operations management should always strive to optimise the use of exiting technology and exploit new technical advances to provide the required level of service at the best cost. Operation Management is mainly divided in two parts:
    1. Operations Control ;this part of Operations Management oversees the IT infrastructure, management of batch jobs (database updates, etc), carrying out backups, printing and electronic distribution, maintenance activities, patches and virus updates, etc
    2. Facilities Management ;they are responsible of the physical IT environment, like power supply and power grid, air conditioning
  4. Service Desk ;Help Desk should be the single point of contact for Customers, the one-stop shop for all the customers needs so that customers satisfaction is increased. The different structures could be:
    1. Local Service Desk ;there is a clear presence of the technical team
    2. Centralised Service Desk ;it has central and branch office reporting to the same technical support site
    3. Virtual Service Desk ;use remote access or other technology to provide support, this encapsulates offshoring 
    4. Follow-the-Sun Service Desk ;allows usually international organisation to provide 24/7 support services depending of who is awake on a given time zone; for this to work the company needs to have common tools, processes and knowledge as well as language skills 

Part of the service operation processes are (incident and problem management are among the two more important of all the ITIL processes):

Incident Management process ;incident is defined as an unplanned interruption to an IT service, reduction of the quality of the service or failure of a CI. Incident Management deals with restoring the access asap and getting tickets resolved, this sections tells you how to restore normal access and solve problems (normal as specified in the SLA). The Service Desk could use an Incident Model, a predefined document with the ordered steps they need to follow to narrow down what's happening and how to solve the issue

Major incidents and hierarchical escalation needed are part of Incident Management. Incident Resolution does not necessarily includes understanding why the fault has occurred or preventing its recurrence, these are matter or problem management, if the same incidents are recurring we need to investigate the root cause of the issues, this root-cause analysis is part of the Problem Management

Request Fulfilment process ;it is important to differentiate between request and incident when creating/analysing a ticket. This process is the 1st step users find when contacting Service Desk, it identifies whether they have an incident (printer not working) or a service request (password needs reset); this process handles the request for calls other than incidents. "Service Request" is a term generally use for many things, low risks and  that don't affect the performance or delivery of the system. The benefits of having service request are:

  • Happy users as well as general complains and enquiries, all of these are deal with the Service Request team
  • Standard channel of contact
  • Provide information regarding procedures and availability of services

Major incidents (like no Internet or router failure) need immediate attention and focus. The status of the incidents could be Open, Assigned, Allocated or In Progress, On Hold, Resolved and Closed (how about re-Open?), and the Incident Record contains all the information concerning a particular incident. Reported incidents go through a number of steps:

  1. Incident Identification ;incident management is a reactive process, therefore no problem can be solved unless it is reported first!
  2. Incident Logging ;gather and log as much information as possible of the incident, who reported, why, what, when, where
  3. Incident Categorisation ;network issue? infrastructure? application or database issue? this pipes the incident to the right team
  4. Incident Prioritisation ;if business impact is affected then it is urgent
  5. Initial Diagnosis ;service desk will look in the Known Error Database for a match of the incident, an initial routine that can be applied to troubleshooting, etc, ensure paper on the printer, turn it off then back on again
  6. Incident Escalation ;if service desk is unable to resolve the incident, it is then escalated to support groups or third parties; sometimes incidents are automatically escalated based on SLA targets
  7. Investigation & Diagnosis ;this is the major activity that takes place during the incident
  8. Resolution & Recovery ;potential incident resolutions should be tested to ensure that they actually resolve the issue completely with no unintended consequences. Once the incident is resolved, it returns to service desk for closure
  9. Incident Closure ;once resolved, service desk will contact the user to verify that the incident may be closed.

Problem Management process ;looks at the root-cause analysis of the previously reported incidents, this is normally not as urgent to resolve as any Incident Management issue, and therefore it takes a slow approach to problem-solving, being more proactive than reactive. Generally, one or two similar incidents of the same nature lead to a Problem Management analysis. Known-error databases are a place to look for previous errors. Problem Management aims to reduce repeated incidents and to reduce the frequency of failures. Problem Management contain a number of steps, as follows:

  1. Detecting Problems ;first identify that a problem actually exist; problem could be reported reactively (the user tells you) or proactively (event monitoring sends you an alert before the item fails)
  2. Logging Problems ;the problem record must contain all relevant information
  3. Categorising Problems ;
  4. Prioritizing Problems ;all problems need to be allocated a priority in relation to the impact to the business
  5. Investigating and Diagnosing Problems ;resources might need to be diverted to solve problems; when test environments exits they can be use to re-create the fault and try solutions
  6. Identifying a workaround ;although the aim of Problem Management is to find and remove the underlying cause of incidents, sometimes the development of a workaround is needed
  7. Raising a Known Error Record ;when the problem has been identified and documented, the information should be added to the Known Error Database (KEDB)

Lessons can be learned from what went well as well as from what went bad; on problem closure a review should be actioned

Problem Management interacts with other stages of the lifecycle as follows:

  • Service Strategy:
    • Financial Management for IT services ;possible solutions or workaround must be financially justified
  • Service Design:
    • Availability Management ;availability management has similar aims to problem management: to prevent downtime, and by proactively identifying the risks a problem could be prevented
    • Capacity Management ;as with availability, problem management can supply information about hte success of any measures taken
    • IT Service Continuity Management ;when a significant problem is causing or will cause major disruption to the business, it may be necessary to invoke the ITSCM plan until the problem is resolved
    • Service Level Management ;service level manager has to report to the business about any failures and what is being done to avoid them in the future
  • Service Transition:
    • Change Management ;when a change is required to resolve a problem or implement a workaround, it is submitted to change management in the form of an RFC
    • Service Asset and Configuration Management ;CMS provides the identification of faulty CIs, as well as to which CIs are common to several incidents, hence helping Problem Management
    • Release and Deployment Management ;when a change to solve a problem is approved, it is the Deployment Management that will implement it in the live environment
    • Knowledge Management ;The KEDB is an essential input into knowledge transfer, the SKMS may hold both problem recoreds and the KEDB
  • Continual Service Improvement:
    • The 7-step improvement process ;the 7-step process can be used by CSI or Problem Management to identify and resolve underlying problems

Event Management process ;failures do occur and you need to have systems in place that notify you when changes of status are occurring; PRTG is a great example of this. Event management can also include fire detectors, software licensing expiration detectors, intrusion detection on the network or on the building, etc. There are two types of event monitoring tools:

  1. Active Monitoring tools, they poll/ask devices to check that they are working correctly
  2. Passive Monitoring tools, they don't send polling messages; they detect events generates by CIs

Monitoring and Event Management are different activities, as follows:

  • Event Management ;concerned with generating events and detecting notification that have been produced
  • Monitoring ;detects notifications and actively checks the CIs to ensure they are working correctly, whether or not an event has been generated

We can have different types of events like Informational (a users has login, and e-mail has been sent, etc), Warning (cpu goes to 90%, still can operate but is worrying, storage used up to 90%, etc) and finally Exceptions (critical errors that need your immediate action, for example an attack being detected, a VM that has failed, etc)

Request Fulfilment process ;this process is responsible for managing the lifecycle of all service requests from the users, its objective is to provide efficient fulfilment of simple requests to meet the requirements of the business, like for example keyboards or mice

Access Management process ;controls the access to data, requesting access to a service, and ensures only those authorised have got access to the data; it follows the CIA (Confidentiality, Integrity and Accessibility) principles to the data. The users needs to identify themselves correctly before access to the data is granted. This sections also defines the creation of roles where permissions are set (role-based access control). Access should be revoked once the user leaves the organisation

The decision of how to control the access (either AD, LDAP, multi-factor, fingerprint, etc) should have been made in the earlier process, and should be with the SDPP

 

   

In the ITIL universe "functions" are just a team of people; the Service Operations functions are:

  • Service Desk ;users need to know where or whom to go for help
  • Technical Management ;the team that supports the service
  • IT Operations Management ;execution of the daily activities to ensure the services are always available, IT Ops can be further divided in:
    1. IT Ops control ;do routine tasks, monitoring, etc
    2. Facilities Management ;the maintenance of the space where the IT services are, data center, server room, etc
  • Application Management ;managing applications, software patches, etc

Communications ;this is a key function of the business, teams need to be able to communicate issues to one another effectively and quickly; setup an intranet or another meaning where users can check the status of the services. Communicate projects, changes, exceptions, emergencies, performance monitoring, etc

 

Advertising ;make it easy for users to report to the Service Desk, a single phone, single point of contact, etc  

   

5.- Continual Service Improvement

CSI does not work in isolation, it is actually the key to success because organisations do not stay static in their requirements. Reviewing performance and identifying improvement opportunities allow the continued development of higher-quality, lower-cost services.

CSI uses the business data to understand the vision and the needs of the business and what it is trying to accomplish, once it has identify where the company wants to go, it questions where are we know, and it sets a baseline. Where do we want to be? Measurable targets are needed to know whether we are getting close or not to the destination. It could take a long time -a decade, etc- to achieve the final goal of the company, but annual goals can be set and regular appraisals. Measurement is critical to the success of continual improvement

The adoption of ITIL will result in controlled, gradual and maintainable improvements. In the life cycle diagram Continual Service Improvement (CSI) circle all the other sections as it intends to look for improvements in all the areas. Some of the purposes of CSI are:

  1. Increase efficiency
  2. Maximise effectiveness
  3. Optimising the cost expenditures

The recommendation is to create a CSI Register where all individual improvements can be recorded

 

Service Reporting are great to know is we are improvement or not, and to pin point where the improvements need to be made. Have an anonymous box where user can report what needs to be improved.

CSI Register ;a document where you save all the ideas for improve, this document is normally kept inside the SKMS 

Deming Cycle (PDCA) ; Edward Deming quote "Without data you're just another person with an opinion" summaries the principle he created.  There are four basis steps for quality improvement in this continuous process cycle: Plan (project plan)> Do (do the project) > Check (audit) > Act! (new actions)

Critical Success Factor  ;CSF is something that must happen if an IT service, process, plan or other activity is to succeed, they are measurements using KPI, key performance indicators. Measurement is a fundamental part of all processes, because all processes must be measurable; CSI cannot take place without the results of the measurement. To be useful, measurements must be objective

It is recommended that a service or process have no more than 2 to 5 CSF, and that each CSF have no more than 2 to 5 KPIs for measuring success. Performance Indicators should be relevant and provide useful information. KPIs can helps asses 4 areas: quality, performance, value and compliance in following the process. There are two types of KPIs:

  • Qualitative KPIs ;improving service quality, their metrics is original customer satisfaction while the measurements is incident handling survey score
  • Quantitative KPIs ;reducing IT costs, their metrics are costs or handling incidents while their measurements are time and resources spent on the incident

Metrics ;a metric is a scale of measure that allows you to define what is to be measured; there are 3 types of metrics that an organisation will need to collect to support the activities of CSI and other service management processes:

  1. Technology Metrics ;associated with managing components, monitoring systems, etc
  2. Process Metrics ;they are captured in the terms of the CSFs and KPIs
  3. Service Metrics ;they measure end-to-end service performance, and consist of the results produced from the technology and process metrics

Baselines are used to provide a clear starting point for any improvement activity, so it is important that when capturing a baseline you ensure that it is accurate

Seven-Step Improvement Process ;the ITIL Service Improvement involves 7 well identifies steps, based on baselines that validates, set direction of activities, justify and intervene at the right place to strength the weakest link in the change; these 7 steps are:

The purpose of the 7-step is to successfully implement improvements. One of the key considerations is that the improvement should be cost effective: if the cost of the implementation outweighs the benefits then the improvement must be carefully assessed.

  1. Identify the Strategy for Improvement ;create business plans and strategy, service review meetings, vision and mission statements, customer satisfaction surveys, CSI register, etc
  2. Define what you will measure ;SLRs and targets, Service Portfolio and Catalogue, Budget Cycle, Benchmark data, baseline data, risks assessments and risks mitigation plans
  3. Gather the data ;the inputs are existing SLAs, new business requirements, trend analysis reports, etc
  4. Process the data ;the processing take care to consider the frequency of processing the data, tools and system use for the processing, evaluation techniques to verify the accuracy of the data 
  5. Analyse the Information and data ;inputs include existing KPIs and targets, results of monitoring data, information and perception from customers satisfaction surveys
  6. Present and Use the Information ;there are four common audiences types: the Customers , Senior IT Management, Internal IT and Suppliers
  7. Implementing Improvement ;inputs include agreed-upon implementation plans, CSI register, knowledge gained from presenting and using the information

There is an association between the DIKW model and the 7-step improvement process:

  • Data ; 2)define what you'll measure 3)gather the data
  • Information ; 4)process the data 
  • Knowledge ; 5)analyse the information and data 6)present and use the information
  • Wisdom ; 7)Implement improvement 1)Identify Strategy for improvement

There is also an association between the PDCA model and the 7-step improvement process:

  • Plan; 1)Identify Strategy for improvement 2)define what you'll measure 
  • Do; 3)gather the data 4)process the data 
  • Check; 5)analyse the information and data 6)present and use the information
  • Act; 7)Implement improvement 

References

Continual Service Improvement is NOT a Service Lifecycle Stage ;https://www.thinkhdi.com/library/supportworld/2017/continual-service-improvement-not-service-lifecycle-stage.aspx  

http://www.cmnogueira.pt/2013/05/10/an-introduction-to-itil-part-55-continual-service-improvement/

https://www.invensislearning.com/resources/itil/overview-of-itil-csi-and-the-7-step-improvement-process

https://www.thinkhdi.com/library/supportworld/2017/continual-service-improvement-not-service-lifecycle-stage.aspx 

https://www.balancedscorecard.org/BSC-Basics/Articles-Videos/The-Deming-Cycle

https://www.hci-itil.com/ITIL_v3/books/3_service_transition/service_transition_ch4_3.html

 https://www.wikiwand.com/en/ITIL 

 http://www.theitsmreview.com/2016/04/dikw-model-knowledge-management/ 

 

London, 2 October 2019

 

Print Friendly, PDF & Email

Comments powered by CComment