- Chapter 30: Working with Oracle Support
- Diagnosing the Problem
- Creating the Technical Assistance Request
- Techniques for Working with the Analyst
- Working with an Inexperienced Analyst
- Getting Results
- The Bug Database
- The Bug Process
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Creating the Technical Assistance Request
When you contact Oracle World Wide Support, you are connected to one of several support centers, and you begin an exercise in communication with a support analyst. The better you communicate the definition of the problem, the higher the odds are that you will find a solution. The TAR record is the minutes and permanent record of your conversations and interaction with the support analyst. Ideally, the TAR record will show a definition of the problem and a series of steady steps toward resolution of the problem.
TIP
If you are going to be doing complex weekend work and only have low-level support, log a TAR on Friday so that you can use that to get past the answering system and connect with an analyst.
Creating an iTAR Using MetaLink
Now, 80% of TARs are initiated at the Oracle Support Internet site. You can create and update a TAR (Oracle calls it an iTAR) through your account on the Oracle MetaLink Web site. The process takes a few minutes, but is generally more efficient than waiting on hold and giving the information to a support analyst verbally. After you have defined your problem, but before it becomes an official TAR, MetaLink will search the knowledge base and suggest some resolution possibilities. Since about 50% of all problems are solved at this point, it is well worth paying attention to the results of the knowledge-base search.
The advantages of using the iTAR process are
You get to state your problem in your own words and you can include more detail than if you were giving dictation to an analyst.
You can log an iTAR 24 hours a day, 7 days a week. The problem definition part of the problem starts faster.
You control the severity level assigned to the TAR.
You can gather information about the problem offline—not on the phone.
If you create an iTAR late in your workday, it might be assigned to an analyst at a support center opposite your time zone who is just starting work. In this case, the analyst might research your problem overnight, and you could have the answer in your e-mail the next morning.
MetaLink has status reports so that an implementation team project manager can rapidly determine which TARs are not being resolved and initiate alternate action.
You can set up profiles to automatically answer all the version and system configuration questions for your system. Remember to update your profile options when you upgrade your system. This is easy to do if you choose "Values from my last TAR" as a profile.
After setting up an iTAR on the Internet, you can still call in to an analyst to discuss the issue.
The disadvantages of the iTAR process are significant, and Oracle still has quite a bit of work to do to improve this process:
The process is generally slower (sometimes a lot slower) to resolve problems because there are many wait states instead of an interactive and continuous conversation with an analyst.
You have to wait 20 minutes to an hour after entering your iTAR before it is assigned to an analyst. Although you could be on hold for 20 minutes waiting for an analyst under the old conversational system, if you got through, you could often have the problem solved in that amount of time.
If your iTAR is assigned to an analyst in a foreign support center, you may have a protracted, asynchronous correspondence by e-mail or TAR update messages with someone who doesn't communicate well with you and who is 12 time zones away from you. You can easily lose a week just starting on the problem definition.
The analyst can hide behind the Internet and e-mail systems to create the impression that something is moving forward when actually little progress is being made. It's easier to gauge the experience of your analyst if you have been talking to him for an hour. Escalations from inexperienced analysts are much slower using iTARs and e-mail.
If the analyst gives the wrong answer in response to an iTAR, the burden of proof to redefine the problem and understand the situation shifts to you. You will lose a lot of time reopening and proving that the analyst totally misunderstood your problem.
Tar Record Statuses and Shorthand Codes
A TAR will be in one of three states: Support, Customer, or Development. Each time someone updates the TAR record, the responsibility shifts to someone else. If the support analyst updates the TAR record, the system waits on you. If you respond or update the TAR record, the system starts to prompt the analyst to go back to work on the problem. Oracle is able to track and summarize the time each TAR spends in each status.
When you look at your TAR record on MetaLink, you may see several shorthand codes. Here are the common codes and their meanings:
NEW—New TAR
XFR—TAR Transfer
ASG—Assigned
WIP—Work in Progress
RVW—Review
1CB—First Call Back
2CB—Second Call Back
IRR—Immediate Response Required (Third call)
INT—Awaiting Internal Response
WCP—Waiting for Customer to Apply Patch
CUS—Waiting on Customer
SLP—Sleep Until Customer Available (maximum is 999 days)
LMS—Left Message
SCL—Soft Close
HCL—Hard Close
DEV—Assigned to Development
Creating a TAR the Old Fashioned Way
Of all TARs, 20% are still created manually and initiated by a phone call. Oracle will try to persuade you to use the iTAR process described previously. I have been told by senior managers in Oracle Support that the best analysts are assigned to iTARs because their productivity is higher.
In theory, this is the way the manual support process is supposed to work:
You contact Oracle World Wide Support and provide information for a TAR record. This information includes the version of the application, the platforms (database, middle-tier, and client), and the name and version of the form or report or process that is giving the error or the incorrect results. You can perform this step by phone or online at the MetaLink Web site. Because Oracle does not track your system configuration or upgrade projects, you must provide this information every time you initiate a new TAR.
The analyst gathers information and attempts an early statement and diagnosis of the problem.
The analyst reviews the existing knowledge base of previous problems with similar keywords. If the analyst cannot find references to similar TARs, you must decide to restate the problem, continue the diagnosis, or escalate to a more skilled analyst.
If the problem is identified, the analyst determines whether a solution is available. If a patch is required, the analyst sends the patch to you. You apply the solution to a test system and determine whether the problem is resolved. You close the TAR.
If the analyst can't identify the problem, you perform additional research and perhaps bring in additional resources. If progress becomes difficult, you must decide whether the business impact and experience level of the analyst justify escalation of the problem.
If a solution is not available, the analyst creates a bug record and forwards the problem to Oracle Development. At this point, you lose visibility of the problem resolution because neither you nor the analyst can affect Development. Development might respond with a patch or a determination that the release works as designed. If the program works as designed, the issue must be processed as an enhancement request.
This process works pretty well, and your job is to lead Oracle Support through this process. Often in the real world, however, the analyst first determines your revision level of the executable causing the problem. He then recommends without further analysis that you upgrade to the latest certified revision for that executable.
This shortcut is often not in your best interest. When the analyst recommends an upgrade, it might involve multiple (dependent) patches or a Family Pack. Although this strategy might work well for low severity problems, it represents a lot of work on your part and might not even make any sense. You get the latest version of a program, but you might patch and test for hours or days before realizing you didn't adequately diagnose the problem, and you must start all over again. This procedure can cause lots of stress in the case of an important problem.