A problem well stated is a problem half solved: EPITED helps to solve issue
smo_ 100000NR1V Comment (1) Visits (10013)
When escalating an issue, it is useful to have a structured method to describe it. “Telling a story about the problem” may be good but this may not reveal the key points.
A predefined structure helps to create a clear problem description and is likely speed up its resolution.
IBM created, several years ago the EDANT pattern to describe an issue and ensure the key points are not omitted using the keywords Environment, Description, Action done, Next action, Test cases.
IT environments are becoming more and more complex and the impact of an IT failure can be dramatic. Customer expectation changes rapidly over the time (today’s expectations are tomorrow’s norms) it is therefore important to include these important factors in a structured problem description as well.
EPITED structure helps to efficiently state a problem and to setup the right focus.
Is not only
The description of an environment should contain the locations, the devices/components that are involved and how they are interconnected. The code level of the components may help to spot rapidly a known issue and information about redundancy can help the Support Team to provide an adequate recovery action plan.
In addition, a layout diagram may help in the understanding of this
Here is an example of a useful SAN layout with information about the impacted components:
Is not on a
But provides a
A problem description should mention what happened, when it starts and how the problem was noticed.
Is not only a description of the
The description of the technical Impact and the business impact will help to understand how important it is to have the problem solved.
Most IT companies assign severity / priority levels to assist the escalation of issues.
IBM’s definition of Severity and Priority are as follow:
Severity: The code that indicates the business impact of the problem to the customer.
Priority: The priority code indicates the urgency and order in which the customer needs the problems to be resolved and levels of comm
Not only the
The description of the troubleshooting actions already performed by the local team may be useful to the Remote Support Team.
This description will help to avoid mixing the symptoms of the original error with the symptoms of any recovery actions or from any troubleshooting steps taken.
Is not only
In a long running problem, the expectation is sometimes forgotten.
This may sound obvious: The client needs the solution. Sometimes the client’s expectation is not so obvious. Expectation, may include prioritization on what need to be solved first. It is important that the priority in which systems and services are restored is determined by the customer and not a well intentioned guess by the support teams. As an example, a local ‘in country’ system may be more vital to the customer that a world-wide service.
Is not only
To allow troubleshooting, Support Engineering needs system logs collected during the issue or as soon, as possible, after the issue.
Issues can involve many layers and components as: Applications, File systems, Multi pathing, HBA drivers, Fibre channel controllers, back end disks, network etc.
See also " Are
This blog entry describes how to make troubleshooting more efficient using the EPITED pattern.
If you use this structure you will be more than halfway to the solution. In addition, communication and escalation will be facilitated.
Tiny url for this blog post http