Siebel Field Service Guide > Quality Management > Process of Managing Siebel Quality >

Resolving Change Requests (End User)


The engineering manager who owns an open change request (CR) assigns the CR to a team engineer. The engineer first tries to re-create the issue by following the description that the CR creator enters. The engineer debugs the issue and isolates its cause. The engineer then implements the appropriate fix, updates the CR with all relevant details, and closes the CR.

This topic contains the following related information:

This task is a step in Process of Managing Siebel Quality.

Process Flow for Resolving Change Requests

After Product Management assigns change requests (CRs) to Engineering, Engineering can proceed to resolve the CRs. Figure 28 shows the process flow for the tasks in resolution.

Figure 28. Process Flow for Resolution

More information about the tasks in this process follows:

  1. Assign Change Requests (Manager). The engineering team manager to whom the product manager assigned the CR assigns it to a team engineer. For more information, see Assigning Change Requests to Engineers.
  2. Query for My Change Requests. The engineer performs a query to find the CRs that are assigned to the engineer.
  3. Reproduce the Issue. When receiving a newly assigned CR, the engineer tries to reproduce the issue in the CR.
  4. Close Change Request. At this point, the engineer might close the CR for the following reasons:
    • The engineer cannot reproduce the issue.
    • The engineer can reproduce the issue, but the issue does not apply to the current product.

      If the engineer closes the CR for these reasons, then the engineer does not take further action. For more information, see Closing Resolved Change Requests.

  5. Create Multiple Occurrence Change Request. If the engineer determines that the CR contains a real issue with the current product, then the engineer checks to see whether the same issue occurs in multiple versions of the same product. If so, then the engineer creates a multiple occurrence CR for each product variant or version with the same issue. For more information, see Creating Multiple Occurrence Change Requests.
  6. Break Multiple Occurrence Link. If subsequent investigation shows that the issue does not occur in another product version, or occurs differently in other product versions, then the engineer breaks the multiple occurrence link. For more information, see Breaking Multiple Occurrence Links.
  7. Define Relationship. If the CR is not a multiple occurrence CR, then the engineer tries to determine whether the CR is related to other CRs in some other way. For example, correcting the issue in the CR might depend on first correcting the issue in another CR. In this case, the engineer determines the relationship. For more information, see Linking Related Change Requests.
  8. Fix Issue. The engineer then applies the appropriate fix and closes the CR. For more information, see Closing Resolved Change Requests.

Assigning Change Requests to Engineers

After the product manager assigns the change request (CR) to an engineering manager, the engineering manager assigns the CR to an engineer with the expertise to resolve the issue.

To assign a change request to an engineer

  1. Navigate to the Quality screen, then the Change Request List view.
  2. Select a CR record.
  3. In the Owner field, select the engineer you want to assign to resolve the issue.
  4. Drill down on the Change Request number (#) field.
  5. In the Comments field of the More Info form, enter any comment or explanation to help the engineer to understand the issue.

Creating Multiple Occurrence Change Requests

In the course of resolving a change request (CR), an engineer might find the same problem in another testing environment, another language version, or another product release version. For this situation, users can create parent-child relationships between CRs. With this functionality, users can create multiple occurrence CRs, and link these CRs to a parent CR.

Multiple occurrence CRs have the same functional description but apply to multiple critical factors such as environment, language, or product. Alternatively, multiple occurrence CRs can describe different symptoms that originate from the same problem and that require the same resolution. Multiple occurrence CRs must have the same owner and the same files or other components to fix.

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

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 the Quality screen, then the Change Request List view.
  2. Select a CR record for the parent to multiple occurrences.
  3. In the Change Request form, click the menu button, and select Create Multiple Occurrence.

    The original record is copied with a new CR number. The number of the original CR (the parent) appears in the Primary Occurrence field.

  4. 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 the table in Closing Resolved Change Requests.

  5. In the Change Request list, drill down on the Change Request number (#) field.
  6. In the Comments field of the More Info form, record the action you took, and note any additional relevant information.

    The parent and child CRs are linked, and the new CR is a multiple occurrence CR.

Breaking Multiple Occurrence Links

In some cases, you must remove the links between multiple occurrence change requests (CRs). For example, further investigation might 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 a parent change request

  1. Navigate to the Quality screen, then the Change Request List view.
  2. Select a CR record for a parent multiple occurrence CR.
  3. Drill down on the Change Request number (#) field, and click the Related CRs view tab.

    The Related CRs list displays the CRs with child relationships to the selected primary CR.

  4. In the Related CRs list, select the multiple occurrence CR you want to remove.

    NOTE:  Child multiple occurrence CRs have a value of Multiple Occurrence in the Relationship Type field.

  5. In the Related CRs list, click the menu button, and select Delete Relationship.
  6. In the confirmation dialog box, click OK.

    The CR is removed from the Related CRs list.

You can also break a multiple occurrence link from a child change request.

To break a multiple occurrence link from a child change request

  1. Navigate to the Quality screen, then the Change Request List view.
  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. Drill down on the Change Request number (#) field.
  5. On the Comments field of the More Info form, record the action you took, and note any additional relevant information.
  6. Click the menu button.

    If the link is broken successfully, then the Go to Primary Occurrence command is unavailable.

Linking Related Change Requests

Related change requests (CRs) are useful when investigating a solution for a CR that might be similar to other CRs. Siebel Quality uses the following other designations to define the relationships that can occur between CRs:

  • Duplicate (Dup-Double Entry). The same CR is entered more than once. Not only is the functional description the same, but other critical factors such as environment, language, or product are the same.
  • Dependent Upon. You cannot resolve the CR until another CR is fixed.
  • Miscellaneous (Misc). An arbitrary relationship exists between CRs. This designation allows you to track together multiple CRs, although they might not depend on each other or match each other.

This topic includes tasks for creating and managing the related CRs. To create a relationship between 2 existing CRs, perform the following tasks.

To link a related change request from a parent change request

  1. Navigate to the Quality screen, then the Change Request List view.
  2. Select the primary CR to which you want to relate another CR.
  3. Drill down on the Change Request number (#) field, and click the Related CRs view tab.
  4. In the Related CRs list, create a new related CR 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 OK.
  6. In the Relationship Type field, select the type of relationship that the related CR has to the parent CR.
  7. In the Comments field, record the action you took, and note any additional relevant information.

You can also link a related change request from a child change request.

To link a related change request from a child change request

  1. Navigate to the Quality screen, then the Change Request List view.
  2. Select the CR record you want to link to another CR record as a child.

    NOTE:  The child CR cannot have any related child CRs. To check for related child CRs, drill down on the Change Request number (#) field, and check the Related CRs view tab.

  3. In the Primary Occurrence field, select the CR number of the parent CR.
  4. Drill down on the Change Request number (#) field.
  5. In the Comments field of the More Info form, record the action you took, and note any additional relevant information.
  6. Click the menu button, and select Go to Primary Occurrence.

    The Change Request form displays the CR record you just designated as the parent (primary occurrence).

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

Closing Resolved Change Requests

When receiving a newly assigned change request (CR), the engineer tries to reproduce the issue. At this point, the engineer can close the CR for several reasons, such as the issue applies to a third-party product, the issue is no longer applicable to the current release, or the engineer cannot reproduce the issue.

If the engineer determines that the CR is a real issue, then the engineer investigates further, implements the appropriate fix, and tests the fix. After completing the fix, the engineer 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, only close the parent CR, 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 are fixed or otherwise resolved.

To close a resolved change request

  1. Navigate to the Quality screen, then the Change Request List view.
  2. Select a CR record that you want to close as fixed.
  3. In the Change Request form, complete the following steps:
    1. Select a value of Closed in the Status field.
    2. Select the reason for closing the CR in the Substatus field. Values include:
      • FOL. Fact of Life. Because of a limitation such as dependency on a third-party product, the development team has no control over the issue.
      • No Longer Applicable. The issue applies to an older or different version of the product, and not to the current version or the version under development.
      • Not Reproducible. You cannot reproduce the issue as described. (It is recommended that before closing the CR, you contact the CR creator to obtain clarification.)
      • Fixed. You corrected the issue.
  4. In the Change Request list, drill down on the Change Request number (#) field.
  5. In the More Info view, complete the fields as appropriate.

    Some fields are described in the following table.

    Field
    Comments

    Approval

    Select a value to track approval for the stage of the resolution.

    Special Tag

    Select statuses or actions that other fields do not identify. You can use special tags for purposes such as reporting, tracking, querying, exporting, and localization. You can specify multiple tags.

    Tag Summary

    Displays all the tags that you select in the Special Tag field.

    Fixed Build

    Select the product version in which you implement the resolution.

    Files Fixed

    Type the filename and archiving location of each modified electronic file for the resolution. This field is required when the Substatus field or Integration Status field changes to Fixed.

    Integration Status

    Select the status of the CR on the integration branch. When the Integration Status field is Closed, the Integration Fixed Date field is automatically populated, and the Integration Fixed Build field is required.

    Integration Fixed Date

    Select the date and time when the resolution is implemented in the integration branch.

    Integration Fixed Build

    Select the integration branch build number in which the resolution is implemented.

    Comments

    Type a comment that explains the resolution.

You can also close a resolved parent multiple occurrence change request.

To close a resolved parent multiple occurrence change request

  1. For a parent CR, follow the steps in the procedure for closing resolved change requests in this topic.

    When you save the record, a message box appears.

  2. Complete one of the following steps:
    • Click OK to close all the associated multiple occurrence CRs with the same resolution information as the primary CR.
    • Click Cancel to close only the primary CR.
Siebel Field Service Guide Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices.