Joined: May 09, 2007 Posts: 22 Location: Bangalore
Posted: Wed May 09, 2007 10:09 pm Post subject: White Paper Improvement Assistance
I have created a White Paper on the title "Why do companies need ITIL"
I have used a real-time scenario to make the idea clear. However I need assistance in improving to make it really good for beginners to understand and digest the concept of ITIL.
Please consider it as a "Open" Document and improve it.
How can I provide it for review and improvement?
How do I attach the white paper?
Joined: May 09, 2007 Posts: 22 Location: Bangalore
Posted: Wed May 09, 2007 10:38 pm Post subject: White Paper: [b]Why do companies need ITIL[/b]
Can anyone help me to make this a really good whitepaper. I need inputs, suggestions, feedback, criticism. Anything is accepted. Let them pour in like a "major incident"
The Need for ITIL
I like abrupt beginnings, without much introduction jumping straight to the point and then elaborating on the same. It will sound very hazy and unclear at the start and may fail to drag you to the point, but as more things are said it becomes clear as it should be.
That said, you might just start to wonder if I am at all struck the point! Well I have not, but my point is about what has caused companies these days to look towards ITIL.
If you want to know why, then think about what was happening. I cannot place it chronologically as to when companies really started making dives into IT & ITES (Information Technology (& enabled services)).
#*That I thought should be mentioned in the IT style *#
But companies did, and many did because they saw a clear revenue objective in the end, but many others followed suit for the “in-thing” and as it became a necessity for companies to invest in IT as much as it was important for grabbing clients, it started out to be a challenge to manage the IT spend.
What the companies envisioned as business-generating, business-supporting, became a major source of drain of income when it came to the bottom line. There was sure more business coming thanks to IT, but IT would never be satisfied with the IT spends and wanted more. What if the employee was eating up all the profits he made? That was what IT was doing, eating up the profits that it enabled the company to achieve. It was when, the companies wanted to control the expense to make IT more business oriented.
The reason IT was inviting more expense in maintaining is not because it truly demanded so, but because IT spends were never controlled. There was no system or if there was one, it was not efficient to understand the IT requirements in detail. The decisions either came from people who knew only IT, or it came from those who understand only business or a combined decision of the aforesaid group. This resulted in bad IT decisions and expensive ones were made where it could have been strategically avoided. Some decisions only back-fired and some did not solve the problem at hand.
IT spends curbed: Chronologically my research is poor and it should be evident when I say that there was a sudden curb in IT spends before long, and I know not when it started or how long it lasted. Business felt a sure need for cutting down IT spends. Some job cuts were made to make business bottom lines in the green and if that could be done there was definitely need for making IT contribute to the greener pasture in the financial books.
It was soon realized that it was not a good decision to curb the IT spending as it did not help and made matters worse, and a more controlled spending was the strategically better decision.
Looking towards IT spend-control frameworks:
Companies soon started looking towards IT spend-control methodologies and ITIL stole the limelight at this stage. ITIL is Information Technology Infrastructure Library. As the last word indicates, it is a library of the best practices that IT could follow. It is not a collection of rules, but a collection of “suggestions” as ITIL wants it to be described as. The methodology is broken down into components and these components collectively help in decision making - easy, efficient, business-friendly, customer-oriented ones.
A topic as this should always be described in general, but I dislike to let you know that I have to bring specifics to move further to describe the ITIL principles. But I like to also let you know that the scenario that I will adopt will help in elaborating the point more clearly.
SAP BW is an ERP application that will help in pulling out reports of different kinds, like the Head-Count Report, the Financial Info-catalogue reports, the HR reports etc that help in decision making. The reports can be pulled using hundreds and thousands of criteria.
Scenario (Before ITIL):
Consider that there is an IT Helpdesk that answers user questions, reports user issues back to the IT team and SAP BW users are calling in reporting performance issues.
The first few issues go un-noticed in terms of any further action taken, but with established known resolutions or work-arounds provided to the users. But if these kinds of issues are spiraling to an alarming number then we know that it is time to do some ground research to see what is happening?
In the absence of a framework like ITIL, I guess that such issues will solely be dealt with by the SAP development team and post investigation the SAP team conclude as follows:
SAP BW Users facing Performance Issues.
Resolution: SAP BW users are facing performance issue, upgrade server capacity to help customers run reports faster.
Scenario (After ITIL):
ITIL has more defined approach and it has more decision makers who will contribute towards the “Resolution” statement. This is where ITIL strikes the magic. To begin with, ITIL has the following “Management” groups that will work together to handle issues. We will now cease to call them issues, but term them as “incidents” that the users report to the Helpdesk. In ITIL terminologies Helpdesk also will be re-christened as Service Desk. IT Helpdesk is part of the “service” framework that will service implemented applications and deployed infrastructure in the IT department.
A few more components are not mentioned here as it is beyond the scope of this paper.
A quick rewind to the Service Desk that receives end user incidents of SAP BW performance issues will guide an approach where the incidents are associated to a whole lot of items. The items are those hardware or software components that will enable the users in performing their tasks in SAP BW. These are in ITIL terminologies called as “configuration items (CI)”. An easy way to remember the concept of CI, is to think in terms of hardware or software configuration, just that a configuration item classifies itself to be termed so, should be above a certain “dollar” value.
Once incidents are associated to different configuration items, it provides more intelligent information that helps in considering the factors that could be affecting the incidents. The factors could even include customer locations drilled down to the office at which they are working from. The factors can also be linked to user skills, user knowledge and training provided to them to use these configuration items. These factors can also be associated with the incidents. Based on such associations, the Incident Management team could raise a Problem Request (PR) that escalates to the Problem Management team.
The Problem Management team is skilled at their end to use tools & methodological approach like Root Cause Analysis (RCA) and other statistical ways to determine the Root Cause of the problem.
Based on the Root Cause the PM team could come to a “Resolution” as follows:
SAP BW users in “South Africa” are facing performance issues as they are not drilling down the search criteria. Please ask users to use more specific search criteria and the issue should be resolved. If the issue is not resolved, please get the following details from the user etc
The above is called as a work around or a known-error resolution step that is communicated to the Incident Management team. Please note that as against the “Before ITIL” model, the resolution has saved the expenses for upgrading the server at this point of time.
Now consider that the known error is not resolving the problem, and the associations still say that the SAP BW users in South Africa are facing performance issues. A PR is again raised and the PM team finds that the memory in the user systems should be complimented.
At this point of time, the Problem Management team raises a Change Request with adequate requirements for the Change to the Change Management team. The Change Management team meets through CAB (expanded as the Change Advisory Board) meetings and decides if this Change is required. Without expanding any further here, I leave it up to your imagination that the CAB will refer something called as a Configuration Management Database (CMDB), inputs from finance, inputs from the users, business continuity plans and a lot of other factors based on which they could even disapprove the request. It is worth informing that“disapproval” will result in another work around or solution that will be updated in the “Known-error database”. The Known-error database is the source of reference for the Incident Management team as the CMDB is for the Change Management team. The Known error database is owned by the PM team while the CMDB is owned by the Configuration Management team.
As against the above situation if the CR is approved by the CAB, then the approval will result in an action of change, which is executed by the Release Management team. The Release management team is usually constituted of the LTS, TI, GNOC, GDN (ATIS terminologies) teams. These are “Yes” men, who will execute the requests that are signed off by the CM team. Any change act that is performed by the Release Management will result in an updation of information in the CMDB performed by the Configuration Management team as there is a change made in the CI. The other specific duties of the RM, CM, Config M, teams are beyond the scope of this paper.
In effect, back to our point, you see that a few set of incidents had two different consequences in the scenarios before & after ITIL. The before ITIL scenario resulted in a more costlier IT spend, namely in upgrading the server which could have resolved the problem, but had a more cost effective resolution available when ITIL framework played its part. The actual problem was first resolved temporarily by a work around and further investigation resulted only in a memory change at the user end.
Before I sign-off I might guess that the reader may perceive a delay in the “After ITIL” scenario as described above. If you think so, then I should remind you that ITIL Change Management processes assigns due priority for the Change Requests, and each CR has is classified with due speed of action required. A virus attack related action will go through the CM team much quicker than a server upgrade CR. That said, please remember that every single change has to go through the CM team and their approval, each of the approved action implemented by the RM team and the consequent updation of information made in the CMDB by the Confi M team.
There is now a sense of hurry for the companies to implement ITIL. There is a strong possibility that the need for ITIL implementation is not clearly permeated among the different teams involved in the ITIL framework as the focus to educate the stakeholders is not successfully completed by most companies. For a successful ITIL implementation all the coordinating parties should be fully aware of the objective and the need for the adoption of this renowned framework.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum