As I discussed in another blog, many organizations are rushing to adopt and implement AI-enabled technologies within their ITSM environments. AI can have a significant positive impact on an organization’s ITSM environment.
But if an organization isn’t practicing good ITSM, introducing AI will just make bad ITSM habits worse.
Excuse me…your bad ITSM is showing
In my experience, many organizations that are practicing bad ITSM don’t realize it. Here’s some examples of bad ITSM:
- Services are not defined. Service definitions describe how people, processes, and technology are used to deliver business value and business outcomes, as well as the specific costs and risks that are managed by IT. But without defined services, there is no shared understanding of the business impact of service interruption, no formal way to determine if existing services can be used to enable new business value, and no way to quantify the contributions of the IT organization – in business terms – to organizational success. The lack of defined services can also be a factor contributing to technical debt.
- Using the wrong practices and expecting good results. Practices have defined purposes and produce defined results. Using the wrong practices produces unreliable results, as well as unnecessary human effort. For example, practices like registering all contacts to a service desk as “incidents”, then manually reviewing those contacts to determine if they are actually service requests. Or using “service requests” to manage deployments of laptop computers. This just scratches the surface of practice abuses that I’ve encountered.
- No defined workflows for fulfilling service requests. Many self-service portals are nothing more than a way for consumers to fill out their own service request tickets or initiate an email for requesting service offerings. The result is someone in IT must take manual action to fulfill service requests.
- Rubber-stamping requests for change (RfCs). I recall reading a blog from Rob England (from his days as The IT Skeptic) wherein he described “change management theater” – entertaining, but nothing really happens. Sadly, this is an appropriate description for what many organizations call “change management”. Changes are pushed through without proper review or the CAB meeting becomes a formality, approving changes without sufficient scrutiny or understanding of potential impacts.
- Lack of post-action reviews. The step for reviewing the success and impact of a change or an incident or other ITSM event, and learning from any issues, is skipped due to time constraints or perceived lack of value. Never mind that opportunities for learning and improvement are missed.
- Poor CMDB practices. Updates to the CMDB are done manually and are not integrated with change, release, or deployment management practices, potentially making the information contained within the CMDB suspect. Or an organization will conduct a “discovery” of its computing environment and call that its “CMDB”. Discovery is a way to validate a CMDB and not a way to create and maintain a CMDB. Discovery will never find the logical or non-physical elements of the computing environment that are critical for effective service management.
- SLAs are not. I’ve discussed the problem with many SLAs before. Not only do many SLAs not discuss services, they also don’t discuss business results and value.
- Taking a “technology-first” approach – While technology is a needed enabler for ITSM, good service management is more than just implementation of a tool. Taking a technology-first approach typically limits ITSM design to the capabilities of the tool and not based on the requirements of the organization.
Why is bad ITSM a problem for AI?
To become effective, AI solutions must go through a period of learning. An AI “learns” by identifying patterns through repeated exposure to huge quantities of data and uses algorithms to learn from that data. The effectiveness of any AI solution is dependent on the quality of the underlying processes and data.
AI solutions must also be made aware of business rules. Business rules define specific criteria and policies that guide the AI system’s decision-making process to ensure alignment with organizational goals and other requirements.
But if IT processes and workflows are not well-defined or are no longer aligned with business needs, AI will do the wrong thing right. If services and associated SLAs are not defined in terms of business outcomes, that means that business rules are missing within the ITSM environment. Those training the AI will lack business-based criteria to guide the AI’s decision-making process to ensure alignment with organizational goals and other requirements.
So, when an organization practices bad ITSM and then tries to apply AI to what they call “ITSM”, well…bad things will happen.
- AI has no rules to follow. An AI system, particularly one designed for automation, needs a clear framework to operate within. If you don’t define a “troubleshooting workflow for a printer issue,” the AI has no way of knowing what steps to take. It can’t classify a ticket, route it, or suggest a solution if it doesn’t understand the process.
- Automation becomes chaos. Instead of improving efficiency, you risk creating more problems. An AI might take an action that is technically correct but disrupts a broader, unwritten process. Without defined criteria for success or failure, it’s impossible to know if the AI’s actions are helping…or just adding to the mess.
- No way to measure success or failure. Without defined evaluation criteria, you can’t tell if the AI is working. Is a 10% reduction in average resolution time good? Is it a result of the AI, or something else? If you don’t have a baseline or a goal, you can’t justify the investment or prove the value of the AI solution.
- Ineffective training of AI models. AI models, especially machine learning models, are trained using historical data. If that data reflects inconsistent or ad-hoc processes, the AI will learn and replicate that inconsistency.
4 things to help clean up your bad ITSM practices
This is not the first time that I’ve discussed the impact that bad ITSM will have on good AI. Here are four things to do to start for cleaning up bad ITSM practices:
- Define and document the business rules. How is the organization making decisions? What is the criteria for making those decisions? What are the goals and objectives of the organization? The answers to these questions provide decision-criteria that should be used in the design of good ITSM practices.
- Map value streams. Not just value streams found inside of IT, but organizational value streams. Those value streams become the basis for identifying and defining services.
- Map workflows. All of them. Start with analyzing historical data to identify and understand the most common incidents and requests. Don’t forget to also go to the Gemba to understand how work is currently being done to identify where procedures are not meeting the business need. These workflows form the foundation for process models.
- Define business-oriented KPIs. How does your organization know what ITSM success looks like? IT metrics alone will not tell the story. You need metrics that reflect business results and value.
Incorporating AI into an organization’s ITSM capabilities offers massive transformative potential. Unfortunately, many expect that AI adoption will magically solve all their ITSM problems. Others are pursuing AI-enabled ITSM solutions because of the fear of missing out. Without first addressing existing ITSM bad habits, AI will amplify, rather than solve underlying issues, resulting in more work for humans and poor business results.
Share 