SDPHere is a scenario which clearly explains the life cycle of an Incident, leading to various process & modules which can also be used as a story involving all modules for a demonstration or training of a IT Helpdesk Tool.
Incident Management:
When an end user reports an incident all the servicedesk gets to hear is that they cannot connect to the internet so the ServiceDesk checks for the basic troubleshooting from the knowledge Base and start analyzing from the End User configuration like proxy settings,credentials and so on and if it is found that the problem is not on the client side then it is escalated to the technician who in turn does a manual check over the Access point and resetting the AP fixes the issue temporarily and closes the ticket.
The issue occurs again after a month and similarly resetting the access point fixes the Issue.Every time huge number of incidents are created if the access point goes down.So to analyze it with a bigger picture a problem is created and root cause is analyzed.
Problem Management:
After the root cause analysis the problem team analyzes the situation and finds out that equipment is faulty and the impact due to this behavior is calculated from CMDB where this asset is linked with 20 Users and 20 other assets.So as a workaround all the assets are routed to a different access point and replacing this access point is the possible solution.
Change Management:
A change request is raised to replace the access point and implement it in a controlled environment.An approval request can be raised and sent to Change advisory board for recommendations and based on their comments the change Manager approves the change and proceeds in implementing the change request.If the equipment is available in the store it can be immediately replaced if not a purchase request has to be raised.
Purchase Request:
A purchase request is raised which leads to a purchase order and after the approval the item will received and replaced.Then the change and problem can be closed.
Arvind
You might be familiar with Service Level Agreements which are
service contracts where the level of service is formally defined in terms of
time.
Lets see a scenario where the SLA & OLA comes into play.
For example:
Let’s say that the SLA defined for printer issue is 6 hours after which it is considered as a case of SLA violation. But when an end user reports an issue where he is unable to print, the problem can be anywhere and many teams need to be involved to resolve it.
In this scenario the Network team analyzes the issue and realizes that the issue doesn’t lie within their segment. Following this, the Hardware team checks the printer and announces the need for equipment replacement. The Store checks the availability of a printer, replaces the faulty one followed by necessary configurations.
Each team has their own time limitations to achieve the SLA promised to an end user. The deadline which the team binds to is called OLA.
SLA VS OLA
The difference between a Service Level Agreement (SLA) and an Operational Level Agreement (OLA) is what the IT organization as a whole is promising to the customer (SLA), and what the functional IT groups promise to each other (OLA).
Arvind
Twitter, Twitter, Twitter… The world is reeling around this 7 letter word. I even called it as the 9th wonder in my personal blog. Guess what is the 8th wonder ? (will tell you at the end of the post). For the unknown, Twitter is a micro blogging site, where you have to give your updates in 140 characters.
Although the concept is simple, the amount of information transfers and viral spread of news has made it in to a virtual world of information. Some even claim it to be the next big thing in public relations and the normal PR would eventually die.
But I am seeing this as the next wave of communication platform, like the email, phone and chat. Twitter has evolved as a communication platform for discussing problems and solutions. Any company, which doesn’t have a social media support is actually looked like primitive company. Nobody would have forgotten the recent Amazon’s blunder.
As it becoming a communication platform, it eventually becomes a part of a Help Desk. What does an help desk do in an organization? The support people are needed to answer the queries of the customers (be it internal or external). So you need to answer the queries in Twitter too. For example, one of my colleagues caught up with a frustrated user of his product in twitter. He DMed (Direct Messaged, you should know if you are using twitter) and eventually gave good solution to his problem. The customer was happy and that would be the primary work of a help desk.
Knowing this Zen Desk has added a twitter widget to its host of widgets, Salesforce has added Twitter to its service cloud. With Salesforce, you can sync the contacts of Twitter and Salesforce, you can also import the Twitter threads to Salesforce as an request. This sync of data is going to become the seed for the next generation of help desk. Twitter gives you up to second information and you can’t say that you were not aware of the problem.
There are some companies which are using Twitter to help their customers, like Starbucks, Jet Blue and even Zoho for that matter of fact. I can imagine a day when Twitter becomes the complete help desk solution.
P.S: The 8th
Wonder, what else than the iPhone. Ah follow me in twitter at www.twitter.com/sylvianpatrick
"The primary goal of problem management is to reduce
adverse impacts caused by incidents and to avoid the recurrence of
problems related to these incidents."
Consider a scenario where a "wi-fi not connecting" incident is reported. The
technician suggests basic troubleshooting tips to resolve the issue.
However, over a period of time, the incident occurs again and again. To
eliminate this issue permanently, the root cause of the incident is to
be found and resolved. A problem involving a group of incidents should be created for this purpose and
assigned to an appropriate technician.
Eliminate root cause; avoid déjà vu
Rules of engagement for Problem management:
Which rule do you think applies best to while approving a change. There were a couple of instances during my consulting and training sessions where there were debates on suitable change management approval techniques.
So let me explain the two scenario's.
Dictator Rule.
Consider that a particular change is rejected by majority of the people in Change Advisory Board (CAB). But the Change Manager can still approve the change stating his own reasons for the approval. Many tools in the market now has the option to approve the change even if it is been rejected by the CAB.
Democracy Rule.
Here the Change Advisory Board is in the driver's seat and based on maximum number of CAB approvals the Change Manager is forced to approve or reject the change.
Who do you think is the decision maker - the CAB or the Change Manager?
Post your comments.
Arvind
