ITSM: Top Four Myths About Service Management

Everyone has an anecdote or two about an ITSM project. It went bad, led to huge expenses along the way and ended up delivering little.

You can’t visit an IT forum or attend a webinar without hearing a nightmare tale about some process.

Or it might be other that supposed to create massive amounts of efficiency but did just the opposite.

Whether all these stories are true or not doesn’t matter.

The fact is that there are plenty of myths floating around out there about ITSM, most of which focus on negatives.

 

 

Debunking these bits of misinformation isn’t an easy thing.

It begins with taking a direct look at the specific falsehoods and pointing out why they don’t make sense.

Any list of myths or mistakes is only as good as its suggestions about how to avoid errors and speak truth to mythology.

Here are the most common myths regarding ITSM.

How many have you heard, and would you know how to debunk or bust them on the spot?

 

Small Companies Can Ignore ITSM

If you work for a small entity, don’t be surprised if management views ITSM as nothing more than a glorified service desk or slightly evolved help desk.

Actually, it’s quite common for new and medium-sized organizations to think this way and to take the only big corporations need ITSM attitude.

The contrary is true.  

Those large companies have the resources to do whatever they need in terms of service management solutions.

It’s the startups, smaller, and medium-size outfits that desperately need to begin evolving their ITSM capabilities as soon as possible.

The earlier they begin, the better. 

There’s not a more appropriate way to streamline all the company’s operations and processes for its users.

Nor is there a more intelligent way to manage all the cloud-based vendor relationships and get the most out of technology.

One of the key benefits of the cloud is that high-level ITSM processes are accessible to companies of all sizes.

 

ITAM Instead of ITSM as Part of Finance and Accounting

Unfortunately, many companies do not integrate their asset management software and reporting processes within the wider ITSM.

Just because you’re dealing with assets, that does not mean a finance/accounting department should oversee the function.

ITAM reporting lines should neither be part of direct-to-CIO reporting path.

Keep in mind that IT teams manage the entire scope of services delivery to internal customers, end-to-end.

Simply put, that means everything, including ITAM software and its related processes, should fall under the realm of ITSM.

In fact, that large umbrella also includes creation, delivery, design, and support of all the varied IT services.

 

Design of the Incident Form Is Unimportant

It’s typical to hear those who are not involved in designing incident forms downplay the importance of the form’s arrangement.

There’s no other single document that contains all the pertinent information about an incident, including exactly what’s gone awry and how best to correct it.

A well-designed incident form can work wonders.

Not only does it have the power to prioritize relevant pieces of disparate information, but it also serves to assure users and managers that nothing will be left out or skipped over.

One of the more subtle but no less important features of the form is its user-friendliness.

When you remember that virtually everyone related to a particular incident sees the form, it becomes clear that logical, efficient design is essential.

No matter how large or small a company is, an efficient form will contain at least six components:

• title
• description
• impact
• affected service
• work-around information
• number of people involved or affected.

The title should clearly indicate the problem, while the description provides more details about it.

Using a priority matrix is the secret to objectively figuring out what the impact is.

And knowing what the specific performance issue are can help IT pros get to the root of the problem more quickly.

Finally, many issues are not of the hard variety. That’s where temporary work-arounds come in.

And, of course, the number of people affected has a direct relation to the priority of the ticket.

 

There’s No Need to Be Proactive

IT service management has a reputation as being mostly reactive in the way it addresses problems and incidents.

However, the proactive side is probably more important even if less visible.

Internal customers typically see incident reports and think in terms of quick solutions that avoid down time.

Anyone who has ever reported an incident knows that frame of mind well.

The less public side of the issue is that it’s vital to find root causes of problems and learn how to fix them.

Eventually, you build up an internal set of skills and intelligence that can stop those common problems from arising at all.

You can design more robust systems, focus on prevention, and know what to expect before small issues become larger ones.

Like a good auto mechanic, IT pros strive for preventive solutions, which nearly always save more time and money than reactive fixes.