This chapter is from the book
This chapter is from the book
This chapter is from the book
Techniques for Working with the Analyst
Working with an Oracle Support analyst is an acquired skill, but it can produce excellent results if you use a few simple techniques. The support analyst cares about your problem and has access to powerful tools that can solve most problems quickly. Remember, the analyst is not the person that caused the problem or who is responsible for the bug you are trying to fix.
The support analyst has several responsibilities. The analyst works with a queue of about 20 issues. The analyst answers new calls coming in (real-time) and answers call-backs on existing TARs. The analyst calls customers back to work on issues and researches solutions to TARs.
TIP
Being polite works. Try not to transfer your stress to the analyst. You can still create a sense of urgency by briefly explaining the unfavorable impact the TAR is having on your business.
Keeping Them on the Phone
If a support call lasts longer than about 50 minutes, the analyst might start to get very nervous. She might be under some measurement or instruction to keep calls under one hour. This can work to your advantage because you can use her urgency to move the solution along. If the analyst tries to take the call offline for further research, let her know that you will not abandon the problem and that this might be a good time to escalate it to a supervisor, commonly called the Duty Manager. Be polite but be firm that you are dedicated to defining and solving the problem. When she knows this problem is your top priority, she will have to stick with it or escalate the problem. Keep the deductive process going, introduce new evidence, and redefine the problem statement.
If the analyst convinces you there is nothing more that can be done without research, make sure the analyst can repeat the problem back to you and can re-create the problem on her own system. The analyst will show the problem to a supervisor or more experienced colleague. If they can't re-create or understand the problem, you must define it better.
TIP
If you do get off the phone, make sure you have an action plan for continuing to work toward a solution for your TAR. You and the analyst should know who is responsible for further action and when that action should take place.
It is your responsibility to follow up and get back on the analyst's priority list. Many new Oracle customers will wait for the analyst to call back and after three to five days become very frustrated by the poor service. The no–call-back problem is caused because customers abandon TARs without closing them, and the analysts work on their current problems before they work on the one you might have abandoned three days ago. Your goal is to always be a current problem.
If you have a problem that will take several days to reach a solution, know which support center is handling your call and the work schedule of your analyst. Call your analyst every morning (her time) and leave a voice mail if necessary. Let her know you are still working on the problem, and it is still unfavorably impacting your business. Try to submit new information or devise a tactical plan for closing the issue. The squeaky wheel does get the service.
Searching for Keywords in the Knowledge Base
Understand and use the right vocabulary of the Oracle Applications. This technique will help you get a hit in the TAR history database. Try to think using the same terminology that Oracle or other customers with a similar problem would use to describe and define it. For example, all executable components of the applications have a module name. You should understand which module is misbehaving and search for references by module.
Also, use the documentation descriptions to describe what is happening. Be precise, but use general business terms as an outsider might describe your business. You are trying to find a match on a problem that some other business has already solved. That match is the fastest way for you to leverage the work some other Oracle customer has already done and fix your problem.
Partitioning the Problem
Breaking the problem into component parts often eliminates large parts of the system that are working and need no further investigation. For example, say that you have a printing problem with a report. If other reports are printing, you might be able to eliminate the hardware and the operating system as part of the problem. If the process worked earlier but is now broken, check out system changes, configuration parameters, the data, and user error.
TIP
If the problem you are having with the system worked earlier, try to determine the last time the errant function worked correctly and then locate all patches applied since that time. Regrettably, some patches introduce new bugs at the same time they are fixing other problems.
Focus the analyst on where you think the problem is, and don't let him go astray. However, allow the analyst to introduce other areas for partitioning the problem. Your job is to know when he is just guessing and get the analysis back on track. Give the reason for your rationale—in this example, perhaps reports print just fine.