The ITIL4 Four Dimensions and incident management
Frequently, organizations concentrate excessively on a specific aspect of their initiatives, inadvertently overlooking other areas.
For example, technology improvements may be planned without proper consideration of the people. I have seen countless times the implementation of a process that people do not like to follow or a technology with no proper training for the people to use it.
The Four Dimensions of Service Management were introduced in ITIL4. These perspectives stand as fundamental pillars within the new best practice framework for service management, emphasizing that organizations should maintain a balanced focus across each dimension
Those are:
- Organizations and people
- Information and technology
- Partners and suppliers
- Value streams and processes
Effective IT management is much more than managing technology.
1. Organizations and people
This dimension of service management encompasses the human resources and organizational structures essential for managing and executing the tasks needed to deliver services.
Effective incident management, is not just about the process followed and the technology on the service that needs to be restored, but also about the people who design, manage, deliver, and consume the support service.
- Have the people the appropriate skills and competencies❓
Not only technical skills but also soft skills like communication and leadership.
- Are they communicating and collaborating correctly ❓
Often, miscommunication is the source of trouble.
- Is the workforce adequately planned ❓
The right people with the right skills and roles not only need to exist but also be available.
- Are employees embedded in the organization’s culture ❓
They should align progress with the organization’s mission and values to foster productivity.
2. Information and technology
It covers information management, knowledge management, tools for communication and collaboration, as well as technology and information security management. This encompasses the infrastructure, applications, and data linked to services and service management.
It incorporates the relationships between different components of the process, such as the inputs and outputs of the different activities.
Knowledge management is usually a key part of the efficiency of the Service Desk. Before bursting into writing knowledge articles, you can start considering:
— What information and knowledge will help support and deliver the services?
— How will this information and knowledge be protected, managed, archived and disposed of?
When considering to using a new technology for your incident management, you may want to ask yourself the following, which I unfortunately learned in practice:
- Is this technology compatible with the current architecture of the organization and its customers ❓
You might want to introduce a tool that the organization is not technically ready for, or for which there are not yet enough skilled employees to roll it out.
- Does this technology align with the strategy and vision ❓
While introducing a change, you will always need sponsors, and not being aligned with the strategy will hardly get you enough. The technology and information employed by an organization should align with its business needs and strategic objectives.
- Does the implementation of this technology bring about any potential risks or limitations ❓
For instance, it might result in vendor lock-in.
3. Partners and suppliers
It relates to an organization’s relationships with the other organizations involved in supporting and delivering the services.
Partners and suppliers ought to be recognized as collaborators in value creation since they are not merely offering a product or service but actively engaging in delivering value to stakeholders.
From a management perspective, that includes establishing clear expectations on how to handle the practices and follow the processes, setting up mutually beneficial contracts, monitoring and managing performance, resolving issues, and continually improving the relation.
I have performed roles as a contractor and as an external supplier, and I have also been working for organizations whose main sources of service support are external partners and suppliers. From those experiences, if there is only one thing I would advise, it would be: Treat the external support colleagues as if they were part of your organization to the maximum extent that is possible. Nothing hinders motivation and collaboration more than not feeling part of the group.
4. Value streams and processes
It is essential to design and visualize the value stream to comprehend the creation and delivery of value. This involves mapping out every step, process, and touchpoint that contributes to the generation of value.
Your value stream and processes are interconnected activities that collectively contribute to the creation of value.
Understand your process — the set of interrelated activities that transform inputs into outputs of your incident process.
The design of these value streams should prioritize the customer, involving an understanding of their needs, expectations, and how they perceive value.
Constantly improving the incident process is a critical success factor for this practice. Examine how the work is performed, map the value streams, and then analyze their current state to identify barriers to workflow and non-value-adding activities.
For example, I once worked in an organization that was accumulating a backlog because users were particularly non-responsive.
Their workflow implied fixing the issue (restoring the service) and leaving the incident record on hold awaiting caller, waiting for the user to agree with the solution provided. Once acceptance is gathered, incident was marked as resolved.
At one point, this was consuming loads of effort and generating confusion with incidents for which a fix has not been provided yet.
By adjusting user acceptance activity on the value stream, we reduced the number of activities / steps and efforts required for incident resolution.
A well-defined process can improve productivity within and across organization.
Putting all together, I will present a simple and real case:
System A integrates with system C via system B. In order to work correctly, all systems need to have a synchronized password.
One day, for security reasons, system A needs to update the password.
They tell system B.
Both change the password and leave behind system C, resulting in integration failure.
There is a technical root cause: Data inconsistency, since the security password in systems A and B was different from the password in system C. Incident is resolved by updating the password.
But there is much more.
There is a process root cause: No one had previously designed and aligned a process for that configuration update to happen. That can be improved by creating a process for the next update.
There is an organization and people root cause: Communication and collaboration between teams failed, since they left system C colleagues aside. That can be improved by fostering collaboration between teams and avoiding working in silos.
There might even be a partners and supplier root cause, since it might happen the support for one of the systems is provided by an external provider, which happened to have some difficulties getting along with the rest of the support teams.
CONCLUSION
Once again, effective incident and problem management is much more than managing technology.
The four dimensions embody a comprehensive approach to service management, emphasizing that organizations should maintain a balanced focus across each dimension.
