7 rules of ITIL process design.
When it comes to IT service management (ITSM) few would argue that ITIL has become the de facto standard for defining processes. But it might surprise you to learn that you can become ITIL certified right up to the “expert level” without ever learning how to effectively design a process? This is further compounded because ITIL, as a best practice framework, is by its very nature not "implementable". Okay, so what exactly does that mean?
If you dig into the ITIL documentation you will get a lot of guidance on what should be in your processes but you will get very few specifics on how to implement those processes in your own organisation. A best practice by definition is devoid of any organizational, cultural and technological specifics. It has to be. What good would a best practice be if it was specific to the ACME Corp. that uses BMC Remedy, especially if your company was organized around using a SaaS application like ServiceNow. So no matter what anyone tells you, you need to spend time designing your IT services so that they meet the specific needs of your company (See my post: The problem with ITIL and the 'one size fits all' approach!).
1. Thorough GAP analysis - Before you set off on designing a process its important to understand what the current gaps are. Let’s use Incident Management as an example. What’s working with the process and what isn’t? Are there issues registering the calls or are the gaps with escalation to second level support. Is there inconsistency in how the process is currently executed? Are the users happy with the results of the process?
It is also very important to understand what is working well with the process - because you don't want to lose that. The best way to do this homework is by asking questions, performing observations and base lining process activities against a known standard. The important thing is that it needs to be done prior to redesigning your process (see my posts: What do you mean 'toolkit ready' & Why ITIL evolution strategy is important).
2. Don’t re-invent the wheel - Many people make the mistake of believing that their organization is so unique that it would be better off designing their processes from scratch. While I did say earlier that a best practice like ITIL is not implementable, it doesn’t mean you can’t leverage what is there. ITIL does a pretty good job of identifying the things you should have in your process. It’s up to you to translate that into the specifics required for implementation.
3. Get the right people - There is an old saying that goes something like, “If you want something done right you have to do it yourself." But that doesn’t mean by yourself. ITSM processes are fundamentally about people, and more specifically the hand-offs of activities, tasks and information between people. Sure, tools are important but they just facilitate the communication between people.
Keep your core design team to the fewest number of people as possible. Bring in expertise as required. Communicate to the broader audience of stakeholders through personalised updates and status reports.
4. Understand the technology - Yes, a process is primarily about people but, when all is said and done, those people will need to interact with a tool effectively. If done right, your process design will translate into a set of technical requirements for tool implementation, for example: mandatory fields, dropdown's, start and stop triggers, workflows, reporting etc.
If you already have an ITSM tool, or you have one in mind, make sure you invite the tool specialists to your process design sessions. There is no point designing a utopian process that can’t be implemented in your tool (see my post: What do you mean 'toolkit ready').
5. Validate via CSI - Iterative process design is one of the best ways to stay focused and to demonstrate progress. You never want to be in a situation where you’ve spent weeks of time designing a process only to find out that stakeholders have issues with it.
6. Training - One of the best ways to ensure consistency and adherence in your processes is to educate your staff. Whenever I deliver training on a process, I make sure I have lots of screen shots, documented procedures and, most importantly, all the reasons why this new process will make work-lives easier.
7. Governance - I’ve saved the most important one for last. You can spend hundreds of hours designing a process, tens or even hundreds of thousands of dollars on tools, but it’s all meaningless if people refuse to adhere to the process.
The value derived from your processes will be directly proportional to the degree to which they are followed. There is no sense in having a Change Management process if every change is urgent and few are documented. Good governance requires that you establish accountability for the process, assign the appropriate tasks and measure that they are actually getting done.
--------------------------------------------------------------------------------------------
Stratton Consultants are leading ITIL experts that specialise in creating centre of excellence status for our clients, we talk your language and work with your business objectives to deliver your needs. Contact us today to find out how we can help your organisation: [email protected] or visit www.strattonconsultants.co.uk for more information on our services.
Digital Marketing for Startups | IT Lead Generation | Tech Sales
8 年Quite an informative read on the how & what of ITIL process design... https://www.dhirubhai.net/company/wings2i-it-solutions-private-limited
Process Maturity Preacher, ServiceNow DevOps Ingenieur
8 年Hello Philip, thank you for the nice article. I often see an ITSM Tool is implemented as a set of "out of the box processes", without streamlining or even defining existing processes first. One of most sad outcomes of that I heard, was that after go-live organisation run the process "normal way" with e-mails and calls, and than re-run them in their Tool for reporting needs. No attention was paid to process definition during the implementation project, as you could guess. I would like to read your article What do you mean 'toolkit ready', which probably touches this problem, but the post is not there (Error 404). Help?