Is implementing ITILreally simple? It is easy to hear about ITIL from a consultant or read from a blog or even attend an ITIL course, but the hardest part comes while implementing those processes in an environment. Not all processes end up being successful. Each and every organization is different; they vary with people, processes, environment, type of support they provide, help desk and much more. It is very important to implement them at the right time; also, the help desk should be matured enough to handle the process, or else there is every chance that the whole attempt would end up in a disaster. Things which have worked for one help desk will not necessarily work for another. This white paper is intended to help the ITmanagers to self assess their help desk and its maturity level in order to implement the right process at the right time.
As you all know, ITIL is about good practices; it gives you the varied learnings of other IT peers from over the years. ITIL is like a messenger bringing those good practice messages to you, and by implementing it incorrectly you are just shooting it, ending up blaming the consultants or ITIL concepts. So ask these questions before you implement the process.
Here are some hard realities which I have seen in my consulting experiences; these are realities which are not addressed in any book or courses.
Implementing ITIL is very different from what you read or hear from people. It is a whole different ball game in reality. Several influencing elements come to play:
Managing people is very complicated; it is one of the most important and most difficult jobs. When a major change is planned to be rolled out say, as a new process, it is important to make the right choice of people to implement it. Design the process for the people and engage them based on their capabilities. Pick the right process owners and give them responsibilities to run the show
I have come across several implementation scenarios that failed clumsily owing to unexplainable attitude of employees.
There was this particular company where I was helping with CMDB implementation. The IT guy who was responsible for this process had two options to discover CIs - scanning them or installing discovery agents. However, to scan the CIs certain firewall ports had to opened. Else, asset discovery agents had to be installed in every individual asset. This implementation involves approval of either of these processes by an authorized approver. Unfortunately, neither was approved. The approver neither agreed to opening the firewall ports nor was he ready to install the discovery agent; and he did not have valid reasons to reject these actions.
Proper communication was lacking between the team players - neither the technician nor the approver gave relevant reasons for their suggestions . The benefits of CMDB should have been documented, raised as a change request and submitted for approval. This way, the benefits could have been clearly communicated to the approver who could have seen value in opening the ports or installing the agent.
The purpose of defining a process is to make sure it is been handled in a systematic and strategic manner. However, in some cases, people misinterpret it in the name of protocols, procedures, and so on making it very complex. The process that is supposed to make things easier ends up becoming complex, killing the whole purpose behind it. Handle these scenarios with common sense which will change the complex process into simple solutions.
The main purpose of help desk tools is to keep simple things simple.
In one particular organization, I came across this rather old-fashioned process of maintaining physical records for Service Requests. This involved a very long process where the end user (requester) had to fill in paper forms, send them to the IT department, the ITteam then submits them for approval by authorized people. Forms signed by the approver is then scanned, imported into the help desk application, documented and delivered. The Service Request is simultaneously raised as a request in the help desk and documented there too!
In the above scenario, Service Request process is complicated by managing each request twice. Instead, paper forms can be dropped to avoid the lengthy process of submitting for approver's signatures and scanning it back into the help desk application. A single Service Request can be raised with exact requirements, approved, documented and delivered through the help desk application.
Implementing ITIL is like baking a cake. You have to make sure the timing is appropriate and the right ingredients are added at the right time. Similarly, implementing ITIL processes at the right time is also necessary; you cannot push a process over your team, they should be ready to accept the change and you should also consider if that process is necessary at that time. With all these factors ignored you will definitely get KNOCKED OUT...
I have witnessed something as simple as Problem Management being implemented at the wrong time. Asmall business organization was very interested in implementing ITIL processes. Incidents were fixed and closed with no proper categorization or documentation. But the IT Manager was very keen in implementing Problem Management. Analysis of the problem was tough without proper details about the associated incidents.
The purpose behind Problem Management is to identify the root cause and eliminate it. And this can be done smoothly only if incidents are properly classified, categorized and documented. Without this, reporting and analysis of the problem is tedious. Implementing Problem Management before implementing proper Incident Management leads you to trouble.
The core purpose of IT department is to ensure smooth functioning of business services. All the processes of IT have to be aligned for business service and should not burden the same. So it is important to know what the basic elements which are necessary to run a IThelp desk.
Evaluate your Help Desk with this questionnaire and know if your help desk has these basic processes in place.
Easier channels in which the end users can report/request services to your Help Desk?
|[ ]||[ ]|
Categorization and Prioritization of all incoming requests based on their criticality
|[ ]||[ ]|
Effective Knowledge Base with Known Issues, Workarounds and Solutions
|[ ]||[ ]|
Service Level Management for timely response & resolution?
|[ ]||[ ]|
|5||Basic Change Process with Approvals||[ ]||[ ]|
|6||Proper Documentation, Reporting & Analysis.||[ ]||[ ]|
Not sure where your help desk stands now? Not sure what you should do next?
I have tried to classify help desks into different types. This classification is based on factors like number of Technicians/users /CI's managed and age of the help desk. See where your help desk fits and shared are some tips on how you should proceed further.
|Help Desk Type||Number of Technicians||Number of End Users||Number of CI's Managed||Necessary ITIL Processes|
|Platoon||Less than 10||Less than 50||Less than 100||Incident Management, Knowledge Base, Service level Management,|
|Battalion||Less than 25||Less than 500||Less than 1000||Platoon + Change Management + Asset Inventory + Service Catalog|
|Brigade||Less than 100||Less than 3000||Less than 5000||Battalion + Problem Management + CMDB & Release Management|
|Corps||More than 100||More than 3000||More than 5000||Brigade + Change workflows & E n v i r o n m e n t S p e c i f i c other Processes.|
Implementing ITIL differs for each environment, the realities really come hard on you with many factors as we discussed. You can overcome these hard issues only by knowing your IT well, their strengths, weaknesses, people and their ability. A successful ITIL implementation means making process operations easier than before. The processes should be well accepted by everyone and unlike typical cold it should never go away.
It should ensure smooth functioning of business services and should not burden them instead.
When Reality Hits ITIL Implementation - View PDF.