Speed Of Delivery

/in /by

What’s the percentage of standard changes to total changes at your organization?

I maintain that a mature ITSM organization should have standard changes be 60-75% of total changes.

This is for a few reasons:
1. allowing speed-to-delivery for low-risk changes.
2. allowing the CAB & change authorities to focus on higher risk changes.
3. allowing the organization to utilize a risk-based approach
4. allowing for an easier discussion on what is a change.. This is one of the more difficult areas for Change Management/Enablement.

There are more reasons but these are just a few.

So, does your organization push the use of standard changes?

Rates of Change

/in /by

The rates of change will only increase.

When we think of how things will be different in the future, the changes will be driven by technology. RPA, AI, NLP, and everything in between.

These innovations will drive how we do things on the process side of business outcomes.

Think of how AI will impact:

Knowledge Management – knowing which knowledge article is most likely to be needed based on searches, incidents, and implementations.

Service Desk – knowing the likely topic of calls before the users pick up the phone.

Event – connecting the event system to everything so the events drive responses even before humans know there is an issue

There are many more that I will dive into in the future like Problem, Change, CMDB, etc.

Chatbots

/in /by

Everyone wants more chatbots.

Few want to invest in the Knowledge Management that it takes to do chat right.

Bad chatbots are MUCH worse than no chatbots.

Sure, technology can enable chatbots, but not ensure their success.

We Need Improvement

/in /by

The more I talk to people during and after an ITSM tool implementation, the more I fervently believe we – as an industry – are missing something.

Let me first say this is not directed at individuals or companies but the general practices of how things are done.

Companies not doing Service Management well buy a tool so they can improve. Great first step.

The tool implementer’s focus is on the tool, data, groups, workflows, etc. This is all an improvement for the company.

But, it never addresses why the company is struggling with Service Management. Here are some specific things I have seen recently:

– no understanding or push for Standard Changes
– poor Emergency Change process
– poor Major Incident process
– Incidents misprioritized
– poor response time on Service Requests
– poor Self-Service Catalog
– poor CMDB governance
– poor CAB attendance and standardized decisions
– poor management of IT hardware
– poor Service Management governance
– the list goes on.

We must do better.

What happens next is that the company thinks the issue is the tool. They ponder getting a new tool.