Process 4: Research the Outcome
In this process, you review the outcome of your research and determine whether a workaround or fix for the problem has been discovered.
.jpg)
Figure 8. Research the outcome
Activities:Research the Outcome
Once the first pass through the research process has been completed, it is time to look at the results and determine if a viable workaround or fix has been discovered. Because of the complex nature of IT and the intricacies of highly integrated systems, you might need to perform the research process a number of times in order to achieve a workaround or fix.
If you repeat the research process, you must go through the filtering activity each time. This gives you the opportunity to re-evaluate the value of continuing the effort to resolve the problem. If the resolution to the problem becomes too difficult to find, it might be time to stop your attempts and focus on a more achievable goal.
The following table lists the activities involved in researching the outcome. These include:
- Determining if a workaround or fix has been discovered.
- Determining if a proactive action is possible.
- Closing the problem record.
Table 7. Activities and Considerations for Researching the Outcome
Activities
Considerations
Has a workaround or fix been discovered?
Key questions:
- Has a workaround or a fix been discovered?
- Are there any prerequisites to applying this knowledge?
- What level of authentication is required to use this knowledge?
Inputs:
- Problem record
- Research process
Output:
- Updated known error record with step-by-step instructions for the workaround or fix for this problem
Best practices:
- If the workaround or fix requires a change and is expected to be implemented many times, Change Control should be engaged to provide guidance on establishing a standard change. See the Change and Configuration SMF for more information.
- Workarounds and fixes should be documented in great detail. The known error record should be updated to reflect that a workaround or fix is available, and the record should be displayed when searching for problems with similar symptoms.
- Known error record usage should be tracked and reported. Counting the number of times a workaround is applied can provide justification for developing a fix. Tracking the number of times a fix is applied can provide justification for retrofitting existing systems with the fix.
- If a known error record is seldom accessed, this may indicate that the problem had a low value and shouldn’t have been pursued, or that the record is poorly documented and is not being displayed in searches, or that the record is too difficult to follow. Use this information to improve your processes.
Is a proactive action possible?
Key questions:
- Could this workaround or fix be applied proactively?
- What tools are required to deploy it?
- What is the benefit of proactive action for this error?
Input:
- Research process
Output:
- Change Management engaged to start a Request for Change (RFC)
Best practices:
All Problem Management is reactive. You cannot research and resolve an error before it occurs. However, workarounds and fixes can be applied reactively or proactively.
After Problem Management has discovered a beneficial action to alleviate the impact of an error, it can either provide the knowledge for reactive use by entities such as the Service Desk, or deploy the action proactively.
However, proactive work can sometimes require more planning, preparation, and effort than the reactive application of a workaround or fix. If the action is only beneficial to a small number of systems, it may be more economical to allow the Service Desk to address them one-by-one as the problem is encountered. If the action is beneficial to many systems or an entire department, the effort to prepare and execute a large-scale proactive deployment is justified.
To learn more about resolving problems proactively, See “Proactive Analysis” in this guide.
Close the problem record
Key Questions:
- Is there any value to be added by continuing work on this problem record?
- Has all of the appropriate known error record information been updated?
- Have all changes associated with this problem record been completed?
Input:
- Problem record
Outputs:
- Updated problem record
- Validation that all meaningful efforts for this problem have been concluded
Best practices:
Do not confuse problem records with known error records. Problem records track the work effort, actions, and decisions associated with working on a particular problem. When work on that problem has come to a close, so too should the problem record.
The known error record lives on in the known error database. That record should be tracked and reviewed and possibly updated from time to time.
Proactive Analysis
Proactive analysis activities are concerned with identifying and resolving problems before they occur, thereby minimizing their adverse impact on the service and business as a whole. This can be accomplished by reviewing:
- The current problem record database.
- All escalated events stored in an incident tracking system.
- Corporate error report data.
- Knowledge base articles containing “unknown error” state.
Selecting which problems to attempt to resolve proactively should be based on a number of factors, including:
- The cost to the business.
- The customers affected.
- The volume, duration, and cost of the problems.
- The cost of implementation.
- The likelihood of success.
Using these factors, an algorithm can be created and used to calculate the business impact of support events. This can be a useful, cost-effective way to determine which problems to address.
.jpg)
This accelerator is part of a larger series of tools and guidance from Solution Accelerators. |
| Download |
| Solution Accelerators Notifications |
| Feedback |