Quicker PMR resolution

Body

We all want quicker resolution for PMRs.  Customers want their problems resolved sooner and their questions addressed more efficiently.  Analysts want to comply.  I thought I’d write a little about how to help your analyst work with you to resolve PMRs more quickly.

The support process is for an analyst to come to an understanding as to what is needed, and then to provide the assistance that is needed.  Most of the time I spend on a PMR is in understanding the issue and its causes.  This always begins in the same way, which is a problem description provided by a customer.

Beginning: A PMR should begin with a concise, meaningful statement providing what problem is occurring or what information is needed or what assistance is required.  It should pinpoint the issue as much as possible.  An example of a good opening for a PMR might be one of these:

1. Assistance request: I have to configure a new AS2 partner.  My partner requires HTTPS for both inbound and outbound communications.  Can you help me to set this up?
2. Problem report: Since yesterday morning I am having trouble accessing my Sterling B2B Integrator dashboard.  The issue is intermittent, it happens once or twice per hour, and all of my co-workers are affected too.
3. Question: Does Sterling B2B Integrator version 5.2.5_11 support SHA-2 signing?

One more thing, a PMR should be for one problem description.  Both the customer and the analyst have some leeway in determining what should be resolved as part of the PMR.  The scope of the problem should be discussed early during the information gathering stage of the PMR so that all parties clearly understand the expectations and goals.  The scope may be changed as discussion progresses, if new information is uncovered and additional factors have to be included.

Please realize that new add-in questions, topics, problems, errors, and side issues will mean a longer time to resolution of the original issue.  The original issue is usually the most critical one.

It’s also important for both analysts and customers to understand that some issues are very complex.  Sterling B2B Integrator uses many components together to process data.  If we’re focusing on one issue, there should be no reason to open multiple PMRs to address it, even if it involves different components of the product or the issue requires assistance from support for other IBM products.

Details:

A PMR for a problem description should then include all relevant details that help to identify the issue.  This is the same process used in writing any description of anything; a newspaper story, a report to a manager, a letter, etc.  It should include Who, What, Where, When, Why and How, as follows:

Who is having the problem?  Who is affected?  Who saw the issue occur?

What happened?  What was being done?  What is the impact on you and your company?  What do you want your analyst to do about it?

Where did the problem appear?  Is there an error message on your screen?  If so, what does it say?  Can you provide a screen print so we can see exactly what you see?  Did you observe an error in a log file?  What log file?  Can you send the log file that has that error?

When did it happen?  When was the first time you saw it?  How often has it happened?  Does it happen under specific circumstances, so that when you do X, then Y happens and that’s the problem.

Why did it happen?  This is often the hardest thing to know, but once we know it, the solution often follows immediately.  What has changed since you were able to do whatever it is that you are trying to do?  Try to be very thorough in telling us about anything that has changed that might have an impact.  Changes in the network, database, operating system, or version of SI can cause issues.  If we know about those things, it can help a lot in helping to resolve an issue.

The #1 answer we receive when we ask, “What has changed?” is, “Nothing has changed.”  Please note that every issue for which something worked once, then stopped working, is caused by a change.  Also, every time something isn’t working, then it starts to work, something changed to cause that to happen.  We understand that many issues have causes that are hard to discover but discovering it or them is the focus for most problem descriptions.

How did you discover the problem?  How do you know it’s happening?  How will you know when it is resolved?

Further Details:  For tough issues, any other details and information you can provide will be very useful.  All business processes, log files, input data, custom configurations, maps, and service configurations could be important.  We may ask for specific information such as the output from dump_info.sh/cmd, thread dumps taken while the issue was occurring, network traces, and other data. 

Must Gathers:  We have put together lists of “Must Gather” information.  We understand that these lists can seem like bothersome hoops that we make our customers endure as part of reporting an issue.  I apologize for that!  Further, under some circumstances, we might want different information.  An analyst may have a different style of working than what is specified in the Must Gathers.  However, the information requested in a Must Gather is very helpful to us when we address an issue, and so we ask for it.  You do not have to send it in order to open a PMR, but if you do, it will often help a lot in coming quickly to a resolution.

Here are the must-gather articles from the knowledge base:

https://www-304.ibm.com/support/docview.wss?uid=swg21661568

Resolution:

A resolution may include the answers to your questions, analysis of any issues that happened, and for Sterling B2B Integrator to do what you want it to do.  We want to close PMRs quickly, but much more importantly, we want to fully resolve them before we do so.  If you have additional questions, please ask them before agreeing to close your PMR.  If you are not satisfied that the issue is resolved, please make that clear.

In the event the same issue comes up again shortly after the PMR is closed, you can re-open a PMR within the next 28 days.