Process management
The most widely used framework for IT process management is ITIL v3. ITIL was created because there was a need for ITSM best practice in the late 1980’s and it has since become the de facto framework used by many organizations across the world. The current version of ITIL incorporates an IT service lifecycle that has five parts: Strategy, Design, Transition, Operations and Continual Service Improvement.
1. Service Strategy
This is the start of the IT service lifecycle and is typically the area that needs most attention in IT organizations. Most organizations today focus on the Transition or Operations processes, and while these do provide benefits to the business, especially with regards to keeping the lights on, these are fairly well understood processes. Instead, there needs to be a shift to thinking more strategically about delivering value to the business, and this value creation starts with service strategy.
If IT can start thinking strategically in terms of how they add value to business outcomes, their mindset and culture will transform from a technology focus to a business focus.
Service Strategy helps to align business and IT strategies. It establishes priorities, confirms resource allocation, identifies constraints and risks, develops IT service portfolios and focuses on the reasons why the organization should do something, rather than the how.
Processes covered in this part of the lifecycle include: Strategy Management for IT services; Service Portfolio Management; Financial Management for IT services; Demand Management and Business Relationship Management.
2. Service Design
This stage in the IT service lifecycle takes the service strategy and turns it into a plan for delivering the business objectives. The old woodworking principle about ‘measure twice, cut once’, applies here. All too often IT spends insufficient time on Design and ends up building and implementing something that does not meet business needs. If the business, IT Enterprise Architecture, Development and Operations teams spent more time working together at this stage, the organization would save money: It is much more cost effective to resolve an issue identified in Design than waiting until Transition or Operations.
Service Design includes the whole IT organization, including internal/external service providers, process, people and technology. Thinking about all these areas ensures that the organization has an end-to-end plan for supporting the new or changed service once it is built in Transition and moved into live Operations.
Processes covered in this part of the lifecycle include: Design Coordination; Service Catalog Management; Service Level Management; Availability Management; Capacity Management; IT Service Continuity Management; Information Security Management and Supplier Management.
3. Service Transition
This takes key outputs from Service Design such as the Service Design Package (SDP) and prepares the new or changed services to go live in Service Operations. It helps to control and manage risk through the build and test phases.
Service Transition is about creating transition plans, testing services against the acceptance criteria developed in Design, controlling risk and preventing undesired consequences, and capturing and managing knowledge. It ensures that new or changed services meet the needs of the business as documented in the earlier lifecycle phases of Strategy and Design.
Processes covered in this part of the lifecycle include: Transition Planning and Support, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing; Change Evaluation and Knowledge Management.
4. Service Operations
This is where the rubber hits the road. It is where the value identified in Service Strategy, finally gets realized by the business. This lifecycle is the one that has received most attention, with Incident Management probably being the most popular process for improvement activities, which makes sense as it is the most visible process to the business and end users.
Service Operation is all about maintaining a stable IT environment through reactive and proactive means. This ‘Keeping The Lights On’ typically takes a lot of IT’s budget. Service Operation coordinates and executes the processes required to deliver and manage the end to end services agreed with the business.
This lifecycle is the one that mentions functions as well as processes; the Service Desk being the most well-known function. The other functions are Technical Management (The IT infrastructure resolver groups), IT Operations Management (Data Center and facilities) and Application Management.
Processes covered in this part of the lifecycle include: Event Management, Incident Management, Request Fulfillment, Access (Identity) Management and Problem Management.
5. Continual Service Improvement (CSI)
Taking the services from Strategy through Design, Transition and Operations is not the end point. All of the lifecycles are subject to improvement and the CSI lifecycle provides guidance and best practice for incremental and large scale improvements. There are many inputs to CSI, some examples include service level breach reports, process compliance exceptions, incident and problem trending, customer complaints etc. It is advised that using a closed loop system such as Deming’s Plan-Do-Check-Act, provides some structure for identifying and managing potential improvements.Using additional tools from lean and Six Sigma, work really well with CSI.
Processes covered in this part of the lifecycle include: 7 step improvement process; Service Reporting; Service Measurement.
Managing People
In order to make the best use of ITSM, the real change has to be effected by people. Processes and technology are key components of ITSM but only people change will sustain the improvements necessary. People change starts with education, and the ITIL v3 Foundation certification provides everyone with the right language and basic understanding to get things going. Every successful ITSM transformation begins with training the staff.
If you can get the ITIL process owners and process Design teams trained before you begin the process Design, you should be in a good place. Then you can train as many of the remaining IT teams as possible. Once Foundation training is complete, training the process owners to an ITIL Intermediate level will increase their level of understanding to that required for a Subject Matter Expert.
Communications is another key driver to facilitate behavioral change. People need to understand the ‘What’s In It For Me’ aspect and this can be achieved with a well-structured change framework:
- Making it essential –ensuring a sense of urgency and commitment is felt across the organization, and that individuals feel that change is essential for them personally as well as for the organization.
- Making it ready – identifying and influencing the levers for change across the organization, with appropriate underpinning planning - individuals feel prepared and equipped to absorb the change.
- Making it happen – driving and releasing implementation of the change initiative against the change plan, flexing as things change, during the change.
- Making it stick – ensuring measures are in place to continuously sustain and improve the benefits, and fine tuning the new ways of working to ensure they are reinforced sufficiently to become the norm.
The roles of service owner and process owner are critical in ITSM transformations:
Service owner
This person is accountable for the delivery of a service and acts as the key customer contact for all service related queries and issues. They need a detailed understanding of the end to end service and all the components that make up the service. They should develop the Total Cost of Ownership (TOC) model for the service. They interact with appropriate process owners; serve as the escalation point; understand and develop the capabilities to deliver the service, make improvements to the service and ensure the ongoing service delivery meets the agreed requirements of their customers.
Process owner
This person is accountable for making sure the process is fit for purpose and that it follows the documented process flows and narratives. They sponsor initial process Design; manage and sign off any changes to the process and process Key Performance Indicators (KPIs); address issues with process adherence; identify and manage improvement initiatives; conduct process maturity assessments, provide technology requirements to automate the process if feasible, and ensure process practitioners have all the required knowledge to conduct the process.
Technology
Most ITSM initiatives need service management tools to be successful but immediately purchasing a tool and thinking it will solve all the issues, is wrong but unfortunately a common mistake. The tool must support the process, not the other way round. A better approach would be to use the following phased approach: develop a process governance framework; Design your process; develop technology and data requirements and finally implement a technology solution.
Process Governance
The following activities should be undertaken: Establish process accountability; select and launch process improvement team; draft the project charter and plan; draft the communication plan; educate stakeholders with an executive overview and provide foundations training.
Process Design
The following activities should be undertaken: Document / review Supplier-Input-Process-Output-Customer (SIPOC); perform Voice of Customer (VOC); conduct Failure Modes Effects Analysis workshop to identify and prioritize waste; conduct Value Stream Mapping workshop to identify value; document current state (as-is Process) and identify process gaps; develop new process flow; develop metrics and baseline data; understand existing artifacts tools.
Technology/data Design
The following activities should be undertaken: Gather business requirements; develop conceptual solution architecture; develop logical solution architecture (if applicable); develop data model; develop physical solution architecture
Implementation
The following activities should be undertaken: Update to-be process as appropriate; implement solution; develop sales and operations plans (SOPs), training plan process controls; update process repository; develop continuous process improvement plan; capture lessons learned.
Common management challenges
Service Strategy
Not putting enough time and effort into this lifecycle stage is the key issue. IT has to move away from being looked at as a cost center and it will only do this when it stops becoming silo’d and becomes an end-to-end service-based organization that focuses on business outcomes and business values.
If we consider the output from an ATM service as being cash, does IT design and deliver end-to-end services to support this outcome, or does it focus on the silo’d technology for the service?
Service Design
Integration with the software development life cycle (SDLC). The Service Design Package can be integrated with the SDLC framework, so that all programs and projects follow the same common approach. The Design should include organizational readiness assessments so that thinking about knowledge transfer, KPIs and reports, the service model etc., is not left until the last minute.
All too often, thinking about the resources required to manage the new or changed services and what measures and metrics will be used to manage the services, is also left until the last minute. Designing and planning for this early in the service lifecycle is much more efficient and much more likely to result in the business receiving the outcomes they expect.
It is also difficult to develop the ability to define services and their SLA targets in business terms. As an example, how many IT organizations provide reports on revenue or compliance impacting incidents rather than the standard P1-P4 incident reporting? More work needs to be put into understanding the business and their language.
Service Transition
There are many challenges within Service Transition but with the way businesses are changing in today’s fast paced world, managing the dichotomy of maintaining a stable production environment and reacting quickly to business needs is one of the most difficult challenges. The emergence of DevOps versus legacy waterfall type IT approaches is only going to exacerbate this challenge.
Service Operation
This lifecycle helps IT to fix the basics and earn the right to deliver further IT services. It is essential for improving the actual and perceived performance of IT. If IT can improve incident management across all priorities, not just the P1’s and P2’s, and if IT can improve request fulfillment, especially onboarding, it has a genuine chance of satisfying the business and their end users. And this is where the main challenge is: Improving the service request and low priority incident performance. Most IT organizations focus on the big outages: P1 and P2 incidents and do not focus on the higher volume, low impact incidents and requests.
With the service desk (SD) function in Service Operations, effectively being the window into IT, anything that impacts the SD is an issue. If the relationship between the development teams and the operations teams is not good, this can be a big issue, especially if the development team throws new services over the wall’ to IT and leaves it to operations to run with. These teams need to communicate very well and make sure that each is fully involved with onboarding new or changed services.
Continual Service Improvement (CSI)
Management commitment is a challenge also applicable to all the other lifecycles but particularly for CSI. IT normally has its hands full putting out fires and keeping the lights on and it doesn’t have much time for proactive CSI activities. Leadership can energize this area by allocating a CSI manager and giving them the resources to instigate improvement initiatives.
Once this hurdle has been overcome, attention can then go to ensuring CSI has the right data to do its job and this means having reports with meaningful content. Garbage in really does mean garbage out (GIGO) for CSI. If you are attempting to analyze trends in incident resolution and the incident records are incorrectly classified, you will be trying to trend with bad data. Bad data is one symptom of immature processes and maturing the processes to at least a basic level will help CSI improve them further.
