Understanding ITIL Processes For Your BAU In Simple Terms

When your house plumbing develops some snag you would see the symptoms. There would be a water leakage or no supply of water to a tap. Especially in case of concealed pipes you may find dampness in your walls. These all are the incidents that indicate that there is something wrong with the plumbing. These incidents typically would reflect an underlying problem for which the root cause is not yet known.

You would call a plumber to identify what is wrong with the plumbing, i.e. to identify the root cause. This is Problem Management. Plumber might give some filler (like m-seal) or you yourself can opt for one which is a temporary workaround. This is Incident Management where your goal is to have an asap resolution. Though it can provide a relief in terms of stopping the leakage, but this does not resolve the problem. Please note that problem is different from incident (which may simply be an indicator of something major to come). Plumber would look into identifying the source of leakage. Now you have the error and identify how it can be rectified, i.e., the resolution. This is known error.

Some part would need replacement, i.e. change, which could be a pipe, tap or combination of multiple parts. Plumber would provide you the details of parts to be replaced. This is RFC. This detail has to be taken to a hardware shop and given to shopkeeper. This is change management. Plumber may give you a time when he would come and replace the fittings. This is forwards schedule of change. Shopkeeper will validate the details and check the fitment of the parts before giving it to you. Shopkeeper may give you multiple options along with information regarding cost, quality, etc. and seek your approval for a particular type or brand. This is CAB approval. All these constitute Change Management.

You will take this to your plumber who would change the fittings, test and ensure that there is no more leakage. This is Release & Deployment Management. In case there is any warranty for the parts, you would ensure that it is properly documented and stored. This is Service Asset And Configuration Management. 

Controlling Unauthorized Changes

I have frequently come across a question – “How can we control unauthorized changes?” Some of the most common response that I have come across are:

• Discovery tool can help in identification of the change of state, which if not approved would mean the change is unauthorized. This is reactive; in reaction to a change that has already been implemented. It can help us in identifying the unauthorized changes that has already been implemented, in case that change of state is being monitored. But if that change fails, the impact to the business would have already happened.
  

• We need to embed process culture to ensure that everyone follows the defined processes and policies. Again a reactive approach if one is aware that unauthorized change has taken place. May be it can help in minimizing the probability when implemented with a severe penalty clause whereby it would be a deterrent for an individual to go against the defined process or policy. But there is a saying “Thief is not a thief till one is caught stealing”. Same applies to unauthorized changes. Many organizations realizes that unauthorized change has taken place only when that change fails and impacts the business.

• Many have voiced the combination of the above two to eventually ensure that unauthorized changes are not implemented.

Then, what can be a pro-active way whereby change management can ensure that an unauthorized change does not take place?

To answer the above question, IT Security Management process has to be tightly integrated with Change Management. As part of the IT security process and policy definition, a security policy has to defined whereby ‘write’ access to the production environment can be granted to the concerned stakeholders, including the ‘administrators’ only when a change is approved and the concerned stakeholder is responsible for the change.

The defined security policy would be implemented by Access Management. Granting and revoking access can be automated by linking the approved change, implementer ID and change schedule with the access control application.
This process would ensure that no one has the access to the environment unless the same is approved by change management, which would be an approved change request. Thereby, proactively making certain that only approved changes are implemented to greater degree of accuracy (an approved stakeholder can still make some change which is not approved in the environment one has access to for implementing an approved change but such instances would be extremely rare)

ITIL and Organizational Cultural Change

I believe that ITIL implementation or anything that changes the way you work needs a change in organizational culture. Specially in case an organization is not process oriented, then ITIL implementation in such organization demands huge cultural change.

What is culture change in an organization?

Organizational culture can be defined as a set of 'ways', 'values' and 'beliefs' that its employees has and they use these to control the way they:

• Interact with one another,
• Outside world, and
• Perform their day to day functions

A change to any of these directly impacts the day-to-day activities of the employees. This is a cultural change.

Thus, any process implementation or automation initiative results in an organizational cultural change. ITIL implementation, being a process implementation, is not an exception.

It is a human tendency to resist a change. It is embedded in the human psychology. Hence, organizational cultural change also faces a tremendous resistance from employees. The top three key factors that contribute to the overall resistance are:

1. Fear of Job Loss: It is a common perception in IT departments of organizations across the globe that their 'work' might be outsourced. Process implementation demands process adherence, a unique 'one' way of working, which further increases their fear of outsourcing.
2. My way is a better way: Every individual feels that existing way of working or the system itself is the best one. This is because they are used to the existing system and are very comfortable with it.
3. Relearning: A change would mean that the new system or 'way’ should be learned and well understood. For many of us (especially after a certain age) relearning is a difficult task.

Change in organizational culture is very important for organization’s growth. It is inevitable. A change is acceptable to any individual when its benefits outweigh the perceived troubles. Thus, a change should be properly planned; employees convinced about the benefits that it brings.

It is very important to plan organizational cultural change for an ITIL implementation initiative to be successful.

Key factors that would constitute Organizational Change strategy are:

Strategic Vision: Formulation and communication of clear strategic vision

Top management commitment: Commitment of top management is required and ‘communication’ of this commitment (following a top-down approach)

Initiation: Culture change should be started at the highest level

Organizational Re-structure: Organization restructuring should be done, if required, to support the organizational change

Control: Select ‘takers’ (those who are ready to accept change) and terminate deviants (blockers of change)

Develop sensitivity: Ethical and legal sensitivity to change should be developed.

ITIL implementation strategy should follow or encompass organizational change strategy. This will ensure that the ITIL implementation initiative is successful.