Siebel Field Service Guide > Quality >

Resolving Change Requests (Engineering End User)


The engineering manager who owns an open CR assigns the CR to an engineer on her team. The engineer first tries to re-create the issue by following the description entered by the CR creator. He debugs the issue and isolates its cause. He then makes the appropriate fix, updates the CR with all relevant details, and closes the CR.

Assigning Change Request to Engineers (Manager)

After the product manager assigns the CR to an engineering manager, the engineering manager assigns the CR to an engineer who has the right expertise to resolve the issue.

To assign a change request to an engineer

  1. Navigate to Site Map > Quality.
  2. The Change Requests view appears.

  3. In the Owner field, select the engineer you want to assign to resolve the issue.
  4. In the Comment field, enter any comment or explanation that might be necessary for the engineer to understand the issue.

Creating Multiple Occurrence Change Requests

In the course of resolving a CR, an engineer might find the same problem in another testing environment, another language version, or another product release version. For this situation, your Siebel application allows end users to create parent-child relationships between CRs. With this functionality, end users can create multiple occurrence CRs and link them to a parent CR.

CRs are multiple occurrences when they have the same functional description but are logged against more than one critical factor such as environment, language, or product. Alternatively, multiple occurrence CRs can describe different symptoms that originate from the same problem and require the same resolution. Multiple occurrence CRs must have the same owner, and the files or other components to be fixed must be the same.

The ability to create multiple occurrence CRs allows end users to manage related issues from one source, eliminate double-counting of product issues, and track the linked CRs together.

To create a new multiple occurrence CR (child) for an existing primary occurrence CR (parent), use the following procedure.

To create a multiple occurrence change request

  1. Navigate to Site Map > Quality.
  2. The Change Requests view appears.

  3. Select a CR that will be the parent to multiple occurrences.
  4. On the Change Request form, click the view menu button and choose Create Multiple Occurrence.
  5. The system creates a copy of the original record with a new CR number. The number of the original CR (the parent) appears in the Primary Occurrence field.

  6. In the new CR record, change the field values for information that is different from the original CR. Some fields in the Change Requests view are listed in Table 117.
  7. In the Comments field, record the action you have taken and note any additional information that may be relevant.
  8. The parent and child CRs are linked and the new CR becomes a multiple occurrence CR.

Breaking Multiple Occurrence Links

In some cases, links between multiple occurrence CRs need to be removed. For example, further investigation may reveal that multiple occurrence CRs are not related to each other.

You can break a multiple occurrence link either from a parent CR or from a child CR. To break Multiple Occurrence links, use the following procedures.

To break a multiple occurrence link from the parent change request

  1. Navigate to Site Map > Quality.
  2. Select a CR record for a parent multiple occurrence CR.
  3. Click the Related CRs view tab.
  4. The Related CRs list displays the CRs with child relationships to the selected primary CR.

  5. In the Related CRs list, select the multiple occurrence CR you wish to remove.
  6. NOTE:  Child multiple occurrence CRs are identified by a value of Multiple Occurrence in the Relationship Type field.

  7. In the Related CRs list, click the view menu button and select Delete Relationship.
  8. In the confirmation window, click OK.
  9. The CR is removed from the Related CRs list.

  10. In the Comments field, record the action you have taken and note any additional information that may be relevant.

To break a multiple occurrence link from the child change request

  1. Navigate to Site Map > Quality.
  2. Select a CR record for a child multiple occurrence CR.
  3. Delete the value in the Primary Occurrence field. (The value in this field is the parent CR.)
  4. In the Comments field, record the action you have taken and note any additional information that may be relevant.
  5. Click the menu button.
  6. If the link was broken successfully, the Go To Primary Occurrence option is unavailable.

Linking Related Change Requests

In addition to multiple occurrence, Siebel Quality uses several other designations to define the relationships that can occur among CRs. Related CRs are useful when investigating a solution for a CR that may be similar to others.

This section contains procedures for creating and managing the related CRs. To create a relationship between two existing CRs, use the following procedures.

To link a related change request from a parent change request

  1. Navigate to Site Map > Quality.
  2. Select the primary CR to which you want to relate another CR.
  3. Click the Related CRs view tab.
  4. In the Related CRs list, create a new record.
  5. In the Add Change Request dialog box, select the CR you want to relate to the primary CR as a child and click Add.
  6. In the Relationship Type field, select the type of relationship the related CR has to the parent CR.
  7. In the Comments field, record the action you have taken and note any additional information that may be relevant.

To link a related change request from a child change request

  1. Navigate to Site Map > Quality.
  2. Select the CR you want to link to another CR as a child.
  3. NOTE:  The child CR cannot have any related child CRs of its own. To verify this, check its Related CRs view tab.

  4. On the Change Request form, in the Primary Occurrence field, select the CR number of the parent CR.
  5. In the Comments field, record the action you have taken and note any additional information that may be relevant.
  6. Click the view menu button and choose Go to Primary Occurrence.
  7. The Change Request form displays the CR you just designated as the parent (primary occurrence).

  8. Click the Related CRs view tab.
  9. In the Related CRs list, select the child CR you just linked to the parent as related.
  10. In the Relationship Type field, select the type of relationship the child CR has to the parent CR.

Closing Resolved Change Requests

Upon receiving a newly assigned CR, the engineer tries to reproduce the issue. At this point, the CR may be closed for several reasons, such as the issue being with a third-party product, no longer applicable to the current release, or the engineer being unable to reproduce it.

If the engineer determines that the CR is a real issue, he investigates further, makes the appropriate fix, and tests the fix. When the fix is complete, he closes the CR and enters relevant information about the fix.

When closing a primary occurrence CR, an engineer can close a parent CR and all its child CRs at once, close the parent CR only, or close a child CR independently of its parent.

When closing a CR, the engineer enters information in the right side of the Change Requests form, labeled "Resolution." Use the following procedures to close CRs that have been fixed or otherwise resolved.

To close a resolved change request

  1. Navigate to Site Map > Quality.
  2. Select a CR record that you want to close as fixed.
  3. Set the Status field to Closed.
  4. In the Comments field, add a comment explaining the resolution.

Complete the other fields as needed. Some fields in the Change Requests view are listed in Table 118.

Table 118.  Fields in the Change Requests View
Field
Comments
Approvals
Allows the employees involved in processing the CR to mark and track approvals for the stages of the fix.
Files Fixed
Filename and archiving system location of each electronic file modified for the fix. Becomes a required field when the Substatus or Integration Status changes to Fixed.
Fixed Build
Product version where the resolution is implemented.
Integration Fixed Build
Integration branch build number in which the fix was made.
Integration Fixed Date
Date when the fix was made in the integration branch.
Integration Status
Status of the CR on the integration branch. When the Integration Status field is set to Closed, the Integration Fixed Date field is automatically populated and the Integration Fixed Build field becomes required.
Special Tag
Allows you to select statuses or actions that are not identified by the other fields. Special tags may be used for purposes such as reporting, tracking, querying, exporting, and localization. You can select one or more values.
Substatus
Reason for closing the CR. Some values are as follows:
  • FOL. Fact of Life. Because of a limitation such as dependency on a third-party product, your company's development team has no control over the issue.
  • No Longer Applicable. The issue applies to an older or different version of the product, but not to the current version or the version under development.
  • Not Reproducible. The issue cannot be reproduced as described. (In cases where the CR issue cannot be reproduced, Siebel Systems recommends that before closing the CR, you contact the CR creator directly to obtain clarification.)
  • Fixed. The issue has been corrected.
Tag Summary
Displays all the tags selected in the Special Tag field.

To close a resolved parent multiple occurrence change request

  1. Follow the steps of To close a resolved change request for a parent CR.
  2. When you save the record, a message box appears.

  3. Do one of the following:

 Siebel Field Service Guide 
 Published: 21 April 2003