Last modified by Keith Swenson 11/15/2009
Public Description (Wiki Format)
Trouble Ticket Scenario
Below is the descriptions of the steps in the process
Step 1: Recording the Problem -
The problem may be found by an internal or external person. There are two ways that a problem can come from the external person: by phone or by email.
For the internal person, there must be a screen that can be called up without delay that presents a form for entering the details of the problem. Submitting this form will cause the creation of the workflow process, and at the same time generate a unique ID for the trouble ticket.
A phone call from an external person will be handled by an internal person, who uses essentially the same form mentioned above, but needs to be able to search for registered customers a couple of different ways. Again, submission of the form will create the process and assign an id. The ID of the trouble ticket must be produced by the system and be immediately available (within 10 seconds) in order to let the external person know the trouble ticket ID. The ID is used as a way to call up the trouble ticket when that person calls in again to check on progress.
Finally, email may be sent to a particular address. This email is automatically picked up, and a trouble ticket started, which includes the body of the email as part of the data. No attempt is made to automatically analyze the body of the message, but the sender's email address is retrieved from the header. The first step of the process is for some internal person to read the message, and to fill in some of the other fields on the form with real values, and then submit it. The system should be able to look up the registered user from the email address. When the trouble ticket is submitted, an email confirmation is sent to the external person, and the process goes to step 2.
Step 2: Reproduce the Problem
This step is designed to check the trouble ticket report, and to see if it describes accurately a reproducible problem. This activity is simply to follow the instruction on the report, and to see if the described behavior occurs. If the trouble ticket comes from an internal person, then this activity must be assigned to someone else so that the recording and reproducing of the problem are not done by the same person. If it comes from an external person, this activity may be done by the same person who enters the report. If the behavior can not be reproduced, then this process goes to step3, otherwise it goes to step 4.
The problem may be identified at this stage. If there is a known solution to the problem it should be entered or referred to at this stage, and then communicated back to the originator by going to Step 6. If the problem is recognized as a duplicate of another problem, it should be able to be recorded as such, and go to step 5.
Step 3: Correcting the Report
This step is reached only if the problem can not be reproduced. This step is assigned to the originator if internal. If external, this must be assigned to a person who can contact the originator and get more clarification on the problem. There are two results of this step, either back to Step 2, or to give up on the process and go to step 6.
Step 4: Identifying the Problem and Resolution
This is where the specialist is called in. The problem details should narrow down the area of the problem. If the expert determines that the area is wrong, it should be able to be reassigned, and the person assigned to the activity should change. The problem stays in this state until a resolution is determined. Either the problem is identified and it will be fixed, or it be fixed later due to schedule constraints, or it is determined to be a misunderstanding and is actually the correct behavior. In all cases the resolution must be communicated to the originator, either via email, or else through a phone call. It goes to step 5.
For this organization, accomplishing this activity require invoking a subprocess. The development team has its own workflow process that handles this in a manner that fits the way they work. The exact route of this sub process is not the subject of this scenario, only that it is started, it is given data, and at some time later it reports that it is complete and returns a set of data.
The subprocess for the development team was implemented before the trouble ticket scenario, so it already has a set of field with meaning appropriate to that task. This means that the trouble ticket process must translate the fields into the field used by the sub process. The details of this is defined below.
Step 5: Verifying the Resolution
When the problem is resolved, then it waits for the resolution to become available. When it is available, the resolution is verified. If the resolution was "fixed," and the problem is not actually solved, then the process can be sent back to step 4. Otherwise the process goes to step 6.
Step 6: Communicate Results
The results of the process are communicated back to the originator here. This step contains a rule that the result must be communicated within 3 days of being known. If not, an email message is sent to the support manager.
Step 7: Audit and Record
This step may happen before or after Step 6, but must happen before the end of the process. It involves someone looking at the process and determing whether the question/answer should be included in a monthly newsletter to the user community. This step is started in parallel with Step 6 since it does not depend upon it, and might happen before it.
Screen Shots
Here is the process implemented in Fujitsu's Interstage BPM:
Interstage BPM again, but showing the "classic" (non-colored) view mode:
TIBCO view with Defaults:
TIBCO view without defaults:
XPDL Files
The XPDL file generated from Fujitsu's Interstage BPM product is attached below in a file named "TroubleTicket.xpdl". Click on the attachment link to download it.