Response Time

You can use service response time to calculate the start date and time of a work request generated through 'Work Request. Quick Entry' (MOS185), 'Maintenance CO. Quick Entry' (COS130), or through APIs.

Configuration settings within the organization define how a request must start based on factors such as priority, equipment, service, and other criteria.

Limitations

These conditions limit the response time calculation:

  • If you specify the start date and time in the input function, the response time is not calculated in the system.
  • The agreement is excluded from the search.

Setup

Use 'Service Response Time. Open' (MOS341) to configure how service response time is determined based on these sorting orders:

  • Sorting order 1-'Priority' by Item number and Serial number

    You can create a record with blank item number and serial number. In this case, the service defines the effectivity.

  • Sorting order 2-'Item number' by Customer and Agreement

Follow these steps

Follow these steps in (MOS341) to set up the criteria used to calculate service response time:

  1. Start (MOS341).
  2. Click Create.
  3. Specify the criteria to determine the response time:
    1. Specify an equipment or an item number in the 'Item number' field.
    2. Specify a unique serial number for each item in the 'Serial number' field.
    3. Set the criticality class. The default value from (MMS240) or (MOS440) is used in the 'Criticality cl' field, if position-based.

      This field indicates a user-defined classification of items in relation to their significance for performance and reliability.

    4. Set the order priority in the 'Priority' field using these rules:
      • From (COS130): The priority is always set to 5 on the Maintenance Customer Order (MCO) header (COS100), which is then inherited by the planned Work Order (WO).
      • From (MOS185): You can manually specify the priority. If left blank, the default value from the WO type or (MMS240) is used in the priority.
      • From (MOS170MI): You can pass the priority as input. If left blank, the default value from the WO type or (MMS240) is used in the priority.
    5. Specify the error code in the 'Error code 1' field. The error code describes the cause of the problem detected during fault isolation.
    6. Set the product number in the 'Product' field. This is determined by the service product, which is based on the service category. For example, item, blank, or sales model.
    7. Specify the product structure type in the 'Structure type' field. You can define more than one product structure per product and facility.
    8. Specify in the 'Service' field whether the service involved is internal or external, such as subcontract work or repairs.
    9. Set the unique identification of a customer. The default value from (MMS240) is used in the 'Customer' field, unless specifically provided in the input transaction.
    10. Specify a 10-digit alphanumeric agreement identity in the 'Agreement' field.
  4. Specify this information from the 'Details' menu:
    1. Optionally, specify a name.
    2. Specify the required description describing the purpose or scope of the record.
    3. Specify the response time in hours.
    4. Specify the downtime, for informational purposes only.
  5. Click Next.
Note: If more than one record matches, the match with the most fields filled in is prioritized according to the matching sequence, beginning with the rightmost field.

As an exception, during fallback searches, 'Serial number' is ignored after the 'Customer' field is cleared.

Search Logic in Maintenance

The system attempts to match records using these fields:
  • 'Company' (CONO)
  • 'Item' (ITNO)
  • 'Serial number' (SERN)
  • 'Criticality cl' (AESC)
  • 'Priority' (PRIO)
  • 'Error code 1' (FCLA)
  • 'Product' (PRNO)
  • 'Structure type' (STRT)
  • 'Service' (SUFI)
  • 'Customer' (CUNO)
If no match is found, the fields are cleared one by one in this order:
  1. 'Customer'
  2. 'Serial number'
  3. 'Service'
  4. 'Structure type'
  5. 'Product'
  6. 'Error code 1'
  7. 'Criticality cl'
  8. 'Priority'
  9. 'Item'

If there is still no match, the search is restarted using only the 'Customer' as the key, clearing 'Item number' and 'Serial Number'.

Then, it clears fields again in this order:
  1. 'Service'
  2. 'Structure type'
  3. 'Product'
  4. 'Error code 1'
  5. 'Criticality cl'
  6. 'Priority'
If no match is found, then these specific combinations are verified:
  • 'Priority', 'Error code 1', 'Product', 'Service', 'Customer'
  • 'Priority', 'Error code 1', 'Product', 'Structure type', 'Service', 'Customer'
Lastly, the system verifies if a record exists with only one of these fields filled:
  • 'Priority'
  • 'Error code 1'
  • 'Product'
  • 'Service'
  • 'Customer'
Note: To ensure a successful match and to retrieve a valid response time, the setup must strictly follow this search hierarchy. Any record with a different combination of filled fields does not result in a match.
Related topics