Every IT organizations has processes. They may not focus on them after they are created but they do exist. The process includes the steps and decisions that are made to achieve a specific outcome for a customer. In IT, we often see processes relating to managing incidents, fulfilling requests, managing projects, managing change, etc.
Most IT organizations focus on operations at various points in time but improving processes generally means making small changes as a result of some sort of metric or process failure. Rarely do organizations look at how a process can radically change to increase the value that is offered to the customer. When assessing and making changes to processes, if the required results is to dramatically change the IT customer experience, deliver faster results through technology, or significantly reduce the cost of providing service, IT needs to embed innovation into the process. While many IT organizations focus on continual service improvement (CSI), few take the extra steps required to support process innovation.
Supporting process innovation requires enabling thinking outside of the box. Leaders and staff must work to produce results without considering the organizational boundaries that normally exist. Companies that support this type of activity are generally measuring employees on the amount of value they create or sustain vs merely completing specific tasks. IT leaders and staff often have difficulty understanding how IT can be innovative with their processes. It is much easier to understand how IT can support business innovation by allowing for new products, faster delivery of a business service, or automation which supports a cost reduction.
Consider the IT organizations that have focused on finding a way to offer a more consistent, continuous delivery of value to their business. Their efforts are part of the movement we now know as DevOps. DevOps required process innovation as radical change was needed to the change management process by modifying the archaic bureaucratic change management process which required numerous signatures to move code into a production environment. A change management process was still very valuable to an organization as it helped them understand and manage risk but the process had to change to become more nimble and allow for a continuous delivery model which supported a much faster pace of change occurring in the production environment. Many organizations are still evaluating how to make this transition and how this is managed is unique with different companies but modifying change management to support DevOps requires out of the box thinking. It is a great example of process innovation in IT.
When conducting problem management, some organizations merely complete root cause analysis but others have gone a step further. They look at the root cause of customer impact. This is an innovative step that allows them to potentially take dramatically different actions to improve the customer experience. With standard root cause analysis, IT staff evaluate what caused an outage so they can decide if it makes sense to resolve the root cause and reduce the opportunity for a similar outage to occur. When looking at root cause of customer impact, IT is evaluating how they could eliminate the root cause of why the customer even know there was an outage at all. This type of analysis allows IT to significantly reduce the opportunity for the customer to be impacted going forward. An application or system issue can still occur but the customer isn’t aware of the issue and they would still be able to work as if there is nothing wrong with the technology. Root cause of customer impact analysis is another example of process related innovation in IT.
Process innovation rarely occurs unless an organization focuses on how to make dramatic changes which create substantive value for the customer. The standard continual service improvement practices used by information technology organizations do not incorporate the steps necessary to achieve dramatic change. IT organizations should not ignore the opportunity that is created by instilling innovation into how they manage the day to day operations of their business. Taking the time to radically change the “IT process status quo” can not only improve the customer experience and lower the cost of providing service, it can result in increased employee satisfaction and engagement.
Supporting process innovation requires changes to both process development and continual service improvement processes. The more significant change is to the mindsets that exist in the IT organization. Making this leap requires that leaders recognize that not every change will be successful and failure is a necessary part of any innovation. Failure allows staff to test changes, learn from the process, and develop a stronger solution.
Join our mailing list to receive the latest insights on culture, innovation, process, and strategy!
At AdOPT, we focus on culture, strategy, process, and innovation to improve performance, increase customer and employee satisfaction, and reduce costs.
It is time to break away from the status quo when developing ITSM processes.
Most organizations view the various processes associated with IT service management (ITSM) as internal IT related processes meant to help the IT department be more structured and efficient. They implement processes without considering how they impact the customer and the company. The adoption of best practices isn’t linked to an overall strategic plan and the value of the processes being implemented is never fully recognized. In many cases, the processes may help IT but they become detrimental to the broader organization and they negatively impact customer satisfaction.
When developing processes, it is fairly standard to identify the process purpose and description, inputs, activities, outputs, roles and responsibilities, and policies without really considering the true opportunity that exists and how all of the associated work can benefit the customer and the larger organization.
A significant opportunity exists when you step back and take the time to look at the problem that needs to be solved rather than following the standard practice of developing and implementing ITSM processes. Consider how the processes may change if you first approach the problem in the context of the overall business. This creates an opportunity to find innovative solutions that contribute to the business achieving their objectives which will ultimately improve customer satisfaction with the IT organization.
Rather than merely focusing on processes from the perspective of IT, reevaluate the problem you are trying to solve in the context of your corporate objectives and your customer objectives. Defining a problem statement is a good place to start and it will change how you go about determining the solution and ultimately, defining ITSM processes.
Let’s look at an example for incident management. What is the problem you are trying to solve? Many organizations will say the problem is reducing downtime for the customer. Is the problem we are trying to solve reducing downtime? This is an objective. It isn’t the problem. Why do you want to reduce downtime? The problem could be that technology challenges and outages cause a lack of productivity or loss of revenue. When looking at the problem, look at the bigger picture in terms of the broader organization and the customer.
If the problem statement is too narrow or if there are assumptions made about the problem, the resulting solution will be fairly stagnant. The opportunity to find a new or innovative solution is significantly diminished. If the problem statement is incorrect, the solution will not have the anticipated impact.
The conversation and solution associated with reducing downtime versus technology challenges and outages causing a lack of productivity or a loss of revenue will vary greatly. Framing the problem statement from the corporate and customer viewpoint will open up the opportunity to find a very different, innovative solution. As a result, often there are changes to the activities associated with a process, new roles and responsibilities identified, additional processes implemented, and existing process deficiencies illuminated.
Many IT organizations struggle with the concept of framing the problem based on the company and the customer. They worry that the solution will not be based in the reality they face relating to resource constraints, technology, or funding. Every department faces similar challenges. If boundaries are noted when defining a problem, the opportunity to be innovative is immediately eliminated. A bit of realism can easily be applied as your processes are being developed but it should not be used as a limitation when defining the problem statement.
Beginning your process development work by defining a problem statement for each process will result in an overall stronger process set that supports business objectives and improves customer satisfaction.
Don’t miss our next blog when we discuss why a vision and strategy is critical to the success of any best practice adoption effort. Join our mailing list to stay connected!