PRODUCT & SOLUTIONS

Product Information

Solutions

Downloads

We're Jumping on the ITSM Bandwagon - Where do we start?

OK, one of the questions or approaches we hear quite often is "Do we start with CMDB?" and everything else will fall into place. Really???? Consulting firms and resellers will tell you this because it’s the best thing for their bottom line. CMDB is one of the most difficult and human capital intensive ITSM elements to implement. So they like it as they can bill you 10’s even 100’s of thousands of dollars. But in the end, do your customers see any direct/immediate benefit. Nope! Nada! They may over time but it’ll be the perception of “here’s IT over complicating things again”. Let’s stop over complicating things and operate from the customer’s perspective (let’s face it, without them we don’t have jobs). What we suggest is to start with Incident Management. This is the quickest win and directly impacts your user community. With a successful Incident Management rollout your user community will be happy and the organization as a whole will be more functional and possibly more profitable. How you ask? There are many metrics to justify this claim but one in particular really resonates with Incident Management – a user typically experiences 8 – 12 hours of technical difficulty every month. So think about that! That’s every user is impacted in doing their job for 8 – 12 hours a month by technical issues that Incident Management has been purposefully designed to address.

Doesn’t that seem like the most logical place to start? It directly impacts the user (your customer) and the operability of your organization. This is far more visible than some esoteric CMDB implementation that the user never really sees. Don’t get me wrong, there is a time and place for a CMDB implementation but it’s further down the road along your service management maturity path.

Incident Management is the perfect process to implement to “cut your ITSM teeth on”. Remember that ITSM is more about the process and the culture shift within your organization than the tool you implement. To be successful we as IT need to convey to the business we understand their needs and the business needs to communicate with us and trust us (us being IT collectively) that we will fulfill their requirements.

Incident management is for the consumers of IT, hence is the most visible of all ITIL / ITSM processes and may be (in most cases) the most important process for IT’s reputation. In today’s world where smart phones, tablets and cloud services are common; our reliance on these tools is substantial and necessary for our organizations to operate. Issues need to be dealt with immediately (that 8 – 12 hours we spoke of). A successful Incident Management process will place IT in a very positive light for your end users, your organization and even the C-suite.

Remember there are five basic operational characteristics to consider when defining your Incident Management framwork/structure/process:

Process flows– define measurable targets, make sure you have consistent communication and last but not least define meaningful categorization (download our white paper around this: https://www.monitor24-7.com/documentation/Service-Desk-Classification.pdf) to identify trends, quantifiable metrics/reporting, proper queuing and skills routing.
Quality control – your KPIs must be defined in line with business policies, this is where working with the business is critical, they speak KPIs and these will measure our success. You should also look at KPI’s that help you predict future incidents. Often we see companies use the KPI’s for historical purposes and shame people (not a great motivator). Your SLA’s should not be there to penalize people, they should be there to support people to do better, to see which incidents should be dealt with first and make your service organization successful.
Roles & responsibilities – Set up a framework for assigning incidents and project roles. Think this through, as it will help you manage incidents more expeditiously. You can support this with a dashboard for a visual overview
ITIL process integration – defining the incident process also needs you to think about problem, change and service level management (your next steps in service maturity). Define when you believe an incident becomes a problem and a change. Also think about your service levels and how can they support your team and benefit your organization. Make these reasonable and easy to monitor and report upon.
Policies – the policies applied in the configuration, SLA and process definition must be agreed upon at the C-level (or minimally with business buy-in) and communicated widely. Everyone must be aware.

So, when you ask a vendor where we should start with our ITIL/ITSM implementation if they don’t say Incident Management be very suspicious and ask “Why not Incident Management”? Hopefully they have some justification based on your individual requirements. The key things to think about are :

Person hours of implementation (i.e. cost)
KPI’s and success metrics
Do we have business buy-in?
Can the business understand the benefits and quantify the success metrics?

ITIL Workflow and Service Catalogue Form Designer

IncidentMonitor Service Desk Software offers a workflow designer which helps you to create the most advanced process flows within a few clicks. Combine this Graphical designer with our Graphical Service Catalogue Form Designer and you get the most advanced and flexible solution.