How are you finding out about the problem?

How much time is spent resolving a problem is largly determined by how it's presented. A well defined problem is presented in writing with screen shots and if you're having a lucky day it was written by someone familiar with PassPort and/or the business process involved. PassPort is a large complicated product performing many many business processes. If you're a coder and don't know about Material Requests becoming Requisitions and Requisitions becoming Purchase Orders you're going to struggle if the problem involves Supply Chain and is not presented in a detailed manner or an analyst isn't sitting in the general vicinity. Indus expends a lot of resources writing their product specifications and they are very detailed, but again it's very easy to get lost in all the business process threads.

Sometimes there's not an application problem, sometimes it's crossing all the t's and dotting all the i's to implement a new process. It's best to have a development or sand box region to try things out in with complete freedom.

Copy the Indus product CDs to a server for everyone to have access to. Cripes life is difficult enough without having to go root around for information. RTFM only has meaning if the person it's addressed to actually can.

If it's new functionality just introduced to PassPort, that can be a factor. The Indus developers miss minutia because many times they don't have a production environment where things fall out. There's nothing that can replace real users banging away at keyboards. If you suspect this might case, find the Indus SR number in the PassPort version release notes where the process was introduced and do scans through the code looking for references to the SR number. This works best for recently implemented SR's. Now find the business process in the product specifications, example im_spec_v3.pdf. If the process was recently introduced, the spec changes describing it should be in red.