JeffLong 270005B0Q4 Visits (9797)
IBM TRIRIGA Support works on addressing problems through a problem ticketing system where each issue is logged as an IBM Service Request (SR) or Problem Management Report (PMR). IBM TRIRIGA Support manages problems reported via this process.
This page has a Support Resources Home section that provides numerous links to some great resources, including a link to our IBM Service Request system where you can open a Service Request (SR). For convenience, the link for creating a Service Request (SR) is here: http
Alternatively, on the IBM TRIRIGA Information and Support Resources page there are also IBM Support phone numbers that can be used to call for support.
Once an SR/PMR is opened, it can be tracked for updates via the SR tool. You may also request an update at any time and this will notify the Support team to follow up with you as soon as possible.
For the most efficient IBM TRIRIGA support experience, a few guidelines should be followed:
Also, it is important to have one problem per SR/PMR because if the problem reported is determined to be a defect, we will create an APAR for it and an APAR also can only cover one distinct problem and we can only create on APAR per SR/PMR. More information about SRs, PMRs, and APARs can be found here: http
Please keep in mind that if all issues are logged as severity 1 issues, this is a misrepresentation, and IBM will be unable to provide adequate timely resolution for truly critical issues for all customers.
Keep in mind that any inside knowledge about your particular problem or environment is good to provide as well because Support deals with a wide variety of issues and test cases and might not be aware of how a particular customer has customized their envi
Finally, try to be prompt and clear in your responses as we communicate during the resolution process. Especially with high priority issues. The quicker you can reply that you have received any updates and let us know your response, the better. Again, due to the large volume of issues coming in, by quickly responding it can ensure that your issue remains at the forefront of the minds of those involved.
For additional guidance on the IBM TRIRIGA Support process, please see the following link for our IBM Support Handbook: http
JeffLong 270005B0Q4 Visits (9009)
IBM TRIRIGA Support does all that we can to assist our clients, however; there are processes in place to help ALL of our clients get a consistent level of help.
To help you understand our PMR and APAR process, please see the following:
A Service Request (SR) or Problem Management Report (PMR) is created to request assistance from IBM TRIRIGA Support to help with investigating a problem or to request an answer to a question regarding TRIRIGA.
Due to the complexities of the environments supported and the potential scope of work involved in problem investigation with enterprise software, it may take some time to complete an investigation and can result in a number of outcomes; such as the following SR/PMR resolutions:
With each of these outcomes, IBM TRIRIGA Support has completed their investigation and the SR/PMR has been resolved. What happens next?
When a SR/PMR is resolved as question answered, the PMR is closed and no further action is necessary.
When a SR/PMR is resolved as working as designed, the client is provided with the information needed to take advantage of IBM's Request for Enhancement (RFE) Community. Opening an RFE (Request for Enhancement) allows you to communicate directly with product management and community peers. This request will be reviewed and voted for by all of our clients and support will prioritize based on client response. A client can lobby for an enhancement by engaging other clients to vote and might even post a blog or forum post to gain visibility. Accepted RFEs will be scheduled for inclusion in future releases of TRIRIGA.
When a SR/PMR is resolved as being outside of the scope of support, it means that the assistance requested is not supported by the support agreement and will require a services engagement or support from another vendor. Examples of requests outside the scope of support may include requests for assistance in customizing reports or business logic. Unsupported requests also include support for 3rd party hardware and software products like web servers, load balancers, firewalls, network devices, and/or anything that is not developed and shipped by the IBM TRIRIGA Product team.
When a SR/PMR is resolved as a defect, a new record is created in the system of record to track the resolution of defects. This new record used for tracking the resolution of a defect is called an APAR (Authorized Program Analysis Report). Once an APAR is created, the investigation phase of the reported problem SR/PMR is complete and the SR/PMR record is closed.
At this point, it is now up to the IBM team to verify root cause and provide a fix for the reported issue. This support process is now being tracked and worked as an APAR since there is no more investigation to be done.
When TRIRIGA Support is working on an APAR, we guide our clients who are interested in the progress of the defect to subscribe to the APAR online. This allows them to receive notifications related to the APAR such as when the fix is available for download. We provide instructions on how to subscribe to the APAR online as part of the PMR closure process. No one is required to do this, but if you want notifications on the status of the fix for the defect, you must subscribe.
Why did you close my SR/PMR? I don’t have a fix for my defect yet!
There are times where, from a client’s perspective, they do not feel that they have been provided with a solution for their problem, even though an APAR has been created for the defect. This sometimes results in a client requesting that the SR/PMR remain open until a fix is received and verified. However, this is not how the IBM support process works, and here is why:
The SR/PMR investigation is complete once an APAR is created. At this point the SR/PMR is closed because we have completed the investigation requested and we have determined that the issue warrants either a code or documentation fix. At this point, the APAR process of working on resolving the defect begins.
When a fix is ready, IBM will deliver the fix in the form of a fixpack on IBM’s Fix Central download site. A notice will be sent to everyone who has subscribed to the APAR notifying them that the fix is available. If assistance with installing or working with the provided fix is needed, a new SR/PMR to request that assistance can be created. Sometimes our clients get caught up in the process, viewing it as being complex. However, following this process for SRs/PMRs and APARs remains the most effective process for us to do a better job for you and all of our clients.
The bottom line is, clients may have a difference in understanding about what a resolution looks like based on our support process. We can all agree that resolution is getting an answer to the question or problem. When we mark an SR/PMR as resolved, it’s not lost forever. We can still update it for up to 28 days and we can reference it for years. If an SR/PMR becomes an APAR, we are still working it, just through a different set of procedures.
The important thing to remember is, regardless of the type of record we use to track the work, IBM is committed to solving your issues and ensuring your implementation of TRIRIGA is successful. We look forward to supporting you!
For further edification on the IBM Tririga Support process you can also review our support procedures in the IBM Support Handbook at the following URL:
Chris K 270004Y3TR Visits (9599)
Having been on the customer side of the IBM Support dialog, I often wondered why I was always asked for version information for my PMRs. Now that I have been working on the IBM TRIRIGA Support team, I understand why. The purpose of this blog will hopefully shed some light on this for the customers as well as improve the customer experience with the IBM TRIRIGA support team.
What the IBM TRIRIGA support team will be doing in the weeks ahead to help make things a bit easier is ensuring we have up to date information about customer versions of the IBM TRIRIGA Application Platform, IBM TRIRIGA CAD Integrator (if applicable), and other third party components required for a running the TRIRIGA application. To that end, we will be asking for information from you if you open a PMR without including the version information for the IBM TRIRIGA issue (whether it is an application, platform, or CAD Integrator issue). Additionally, if you do not indicate what environment this issue applies to and the associated version information for that environment, we will ask for that information as well.
What you can do to help is to provide this information up front when you open a PMR. I suggest keeping a document with the environment configuration information. Having been on the client side of this picture, I know how I ended up making the IBM PMR process easier for me. Knowing that I would be asked version information right out of the gate, I kept a document which had the version information for the main product as well as versions of other products in our configuration that could have an impact, in any possible way, to the problem being reported. I found that this greatly smoothed out the initial response from the support team I was working with and also led to quicker turnaround time on the PMRs I submitted. While I cannot guarantee that the PMR turnaround time will be significantly improved, it should at least reduce multiple communications regarding the configuration of an environment. The main reason for back and forth about version information that I have seen is that the support team assumes the information provided will be all that is initially required to work the problem. While working and researching the issue, we may come to find that we need some additional version information (think operating system, 3rd party tool versions, etc...). Having the information up front when you open the PMR should prevent this from happening.
What I, and the rest of the IBM TRIRIGA Support team will do is look for this information on any new PMRs. If the information is provided in the PMR, we will check to see if the information has been stored on a customer record that we have set up in a tool we share with our L3 engineers. If you provide information and that customer record is not up to date, the engineer will update the information based on what was provided when the PMR was opened. If the information is NOT provided in the PMR, the engineer should ask for all of that information. I know that several of our clients are already familiar with that process and are providing that initially. We will do our part to smooth this part of the PMR process.
If you found this information helpful, please be sure to "like" it and be on the watch for my next blog regarding deployments.