Service Support

As we mentioned earlier, IT Service Management consists of Service Support and Service Delivery modules. Service Support is known as an ITIL Red Book, and if you are starting in ITIL, this is the first book you will reach for.
Starting support organizations in an unconsolidated, firefighting phase are usually first interested in Service Desk and Incident Management. We will discuss this later, but let's mention all ITIL Service Support disciplines here:

• Service Desk - point of contact function for all IT customers for service requests. SD reports customers on statuses of their requests and informs them on any outages of relevant IT services planned in the change process
• Incident Management - a reactive process of restoration of IT services into a state before the incident. Closely connected to Problem and Change Management
• Problem Management - a very simple process: finds the underlying common cause of a few similar incidents, creates a workaround or temporary fix, and defines a permanent fix, usually as a result of previously initiated change. Implementation of PM is often omitted due to lack of resources, since it requires expensive educated staff, and by default these people much more like to play Warcraft or visit dirty web sites than to analyze Problem Root Causes.
• Change Management - this one is the toughest: plan and manage all changes in IT infrastructure. Basically, it deals with the problem of convincing IT people (mostly geek prototypes) that corporate IT infrastructure serves to more important stuff than their childish need to play with it. Involves risks analysis and impacts of changes to business IT services.
• Release Management - here is another long shot: after you plan changes, someone has to actually go on the field and perform them. Usually there are more changes implemented at the same time, mostly due off-work hours and weekends. RM task is to coordinate IT people with no life for it's dark non-human low purposes.
• Configuration Management - here I will stop with my feeble intentions to be funny: here is the cornerstone of all ITSM talk, it begins at incidents and here is where it ends. I am STRONGLY convinced that knowing A. what you have, B. where it is and C. how it works is the cause and a mean to all ITSM gibberish. Keeping your CMDB up-to-date is something you should do as if your life depends on that. And if you are a ITSM professional, it does.

What should be the implementation order of these functionalities in our business? Do we implement one by one, all at once, or in few phases? Let us discuss that in the next post.