ITSM for smaller organisations, without a large budget

ITSM sounds like something for organisations with a forty-strong IT department and a process architect on the payroll. That is a shame, because organisations without an IT department of their own get the most out of it. They are the ones who can least afford things going missing.

The misunderstanding is in the approach. ITSM tends to be presented as a complete model — ITIL has thirty-four practices — and everyone understandably switches off. Whereas three processes already capture eighty per cent of the benefit.

What three processes already solve

1. Incident management: make sure nothing gets lost

It sounds almost too simple, but the biggest gain in smaller organisations is that questions arrive somewhere they will not get lost. Not in a personal mailbox, not in a chat message, not in the corridor.

The minimum you need: one entry point, an owner per ticket, a status that is accurate, and a reporter who knows where their question stands. Nothing more. Categories, priority matrices and escalation paths come later — and introducing them too early mostly gets them ignored.

The trap is the category tree. Nearly every organisation starts with too many categories, after which nobody can find the right one and everything lands under “other”. Start with five to eight, and only expand once your own figures show it is needed.

2. Change management: know what changed

When something breaks, the first question is always: what changed? Without change records that is guesswork, and guesswork costs hours.

For a smaller organisation that need not mean a CAB with a weekly meeting. The minimum: every change to a system is recorded, with who, when and why — plus a rule for what may not happen without consultation. That is it. A change process heavier than the changes themselves gets circumvented, and then you are worse off than with nothing.

3. Knowledge management: write down what you explain twice

This is the process most often skipped and the one that returns the most. The rule is simple: if you explain something for the second time, write it down. First for your colleagues, later for users themselves.

In a small organisation this is also your only defence against the departure of the person who knows everything. As long as knowledge lives only in heads, every holiday is a risk.

What to deliberately leave alone

Equally important is what you postpone until you genuinely need it:

• A full CMDB. A configuration database that is not kept current is worse than no CMDB at all, because people trust it. Start with the assets that genuinely matter — laptops, phones, licences — and only expand once you have automated the upkeep.
• Problem management as a separate process. Below a certain volume you will spot recurring problems perfectly well without a procedure. Introduce it when you notice the same outage returning for the third time with nobody looking into it.
• An elaborate SLA structure. Different resolution times per priority per category per customer group sounds professional and is mostly work. Start with one target and see whether you hit it.

Where the real gain is: automation

Once those three processes run, the biggest return is not in more process but in less manual work. Modern ITSM tools can do far more than most smaller organisations use.

In TOPdesk you automate inside the tool with Events and Actions: a ticket that routes itself to the right agent based on category, a confirmation to the reporter, an escalation when an SLA is at risk, a status that moves on by itself. That saves hours a week rather than minutes, and it is work you configure once.

What falls outside that goes through the API. The integration that returns the most in smaller organisations is with the HR system: joiners, movers and leavers automatically creating the right tickets and tasks. A new employee means a laptop, an account, a phone and an access badge — four things you do not want to create by hand, and certainly do not want to revoke by hand.

The order

If you were starting today, the order would be:

1. One entry point for all questions, with an owner per ticket.
2. Five to eight categories, no more.
3. Record changes: who, when, why.
4. Write down what you explain twice.
5. After three months: look at what the figures say and only then refine.
6. Automate whatever comes back every week.

That is not an ITIL implementation. It is six months of work, most of it in the first month, and it delivers more than a model that is complete on paper and unfollowed in practice.

Measuring whether it works

Three numbers are enough to know whether things are heading the right way: how many tickets are open and whether that number is rising or falling, how long tickets stay open, and how many tickets get reopened. That last one is the most underrated: a reopened ticket means someone closed it too early, and that is exactly the behaviour you get when you steer on speed alone.