The first time I worked IT support in a professional setting, I was seventeen years old. I had gotten an internship (one day per week) with my uncle’s firm as part of my third year of vocational training, and spent a day per week with them. In the beginning, I was mostly hanging out with the IT staff, not really providing much of any use to anyone.
Over the course of the year, I gradually moved from observing, to asking questions, to being put to work. Over the last few months, I was sent to troubleshoot a lot of issues. It was a good learning opportunity for me, and it’s one of the things I am happy that we do at work today.
Why am I telling you this? Because, in addition to being my first IT job, it was also my first time being subjected to a Service Management tool. Since then, I’ve worked with a lot of different tools, from email (and no, I will never again accept a job with a company that uses any email client as its SM tool) to some of the bigger names out there (no, I will not name names).
But, really, why am I telling you this? Well, I happen to believe that one of the most important decisions you can make when implementing service management (regardless of which process methodology you choose), is what tool you choose. Here, then, are things I think are important:
- Useful out of the box
- If I can’t start using it with a minimum of configuration, I’m not interested
- Offers email, web portal, and direct entry by analysts
- Quick to use
- If I spend more time registering a ticket than I do solving an issue, you’re doing it wrong
- Has to support rich text and images
- CMDB with search in pertinent metadata fields
- Serial number, network name, assigned user are all important, and the list goes on
- Self help portal should be part of the web portal
- Mobile app is a plus
- SLA capabilities, including the capability to apply different SLAs to different customers
- Change and maintenance calendar
I will write more on that last point later. For now, suffice it to say that I am increasingly coming to believe that the change management process is perhaps the most important one for success in ITIL – not to mention DevOps – adoption.