From the perspective of information cross coupling; the type extend lists identified within this module specify how all issue management information modelling concepts defined within the schemas of the issue management domain are coupled together via type extends within the issue management domain.

NOTE    A large repository of information relevant to users and implementers of the STEP capabilities used in common by Ap239 and 80% of AP233 is at http://docs.oasis-open.org/plcs/dexlib/oasis_cover.htm.

F.1 Suitability of model for real-world scenarios

The following are a sampling of real world situations that arise from issue.

1. Renegotiation of contract for cost;
2. Renegotiation of contract for time of one or many deliverables;
3. Change to business strategy;
4. Major schedule changes with significant resource change;
5. Introduction of a new partner or supplier to help with problem;
6. Schedule for change including notification and involvement of customers in fix;
7. Risk remediation plan and schedule (sets up alternatives);
8. Temporary fix with permanent fix to follow and notification of customers;
9. Temporary fix with permanent fix to follow in next release of product and notification of customers;
10. Temporary fix with permanent fix to follow, product recall, and notification of customers;
11. Work around notice to customers;
12. Issue evaluations that involve suppliers and customers.

The model works for most of these scenarios, though it could do with an extra module for Work_request_relationship and the type extends need checking. Contract changes and business strategy should wait.

F.2 Scenarios 1, 2

• Renegotiation of contract for cost;
• Renegotiation of contract for time of one or many deliverables.

Contracts and contract conditions have been out of scope for STEP. There is a Contract entity, but so far it has only been used to identify a context for work. It's not versionable and does not have properties. There is no associated scheme, although I think it can be cited from a scheme, so that a scheme, schedule or plan can have the context of a contract.

F.2 Scenario 3 Change to business strategy

STEP so far has concentrated on Product, and has no concept of business strategy.

F.3 Scenario 4 Major schedule changes with significant resource change

My guess here is that the root is an Activity which represents "doing the work". This would have as its method a Scheme (as schedule) to which resources are assigned. Since schemes have versions, there is a mechanism for controlling version change. To do this would therefore require that a Work_request can identify a Scheme as a thing to be changed - which is allowed for in PLCS. The one oddity about doing this is that the PLCS usage was for Scheme as a product (small p) of the project - that is, the scheme as maintenance schedule, as a deliverable of the project (e.g. change oil every 6000 miles) or as the definition of a particular plan (e.g. take SS Fred into dry dock on 1st July). The usage here is slightly different in that it is changing the schedule that is actually scheduling the project itself, rather than generating schedules about the product.

F.4 Scenario 5 Introduction of a new partner or supplier to help with problem

This is essentially the same as questions 1 and 2 about versions of a contact. There is nothing in STEP that cares whether an organization associated to a work_request is "new"

F.5 Scenario 6 Schedule for change including notification and involvement of customers in fix

Schedule is a new element in STEP, and has not been associated with driving change. My guess is that the change itself would be broken into a set of subchanges using Work_request_relationship (which does not exist). The primary Work_request would be associated to the scheme, while the subchanges associated to the scheme_entries, either directly, or more likely, as controlling the Activities that are the scheme_entries.

F.6 Scenario 7 Risk remediation plan and schedule (sets up alternatives)

There are two possibilities here. Either the risk remediation is a set of activities, or it is one or more alternative product configurations. Either would be suitable as targets for building schedules.

F.7 Scenarios 8, 9, 10 and 11 Modeling methodology discussion

• Temporary fix with permanent fix to follow and notification of customers;
• Temporary fix with permanent fix to follow in next release of product and notification of customers;
• Temporary fix with permanent fix to follow, product recall, and notification of customers;
• Work around notice to customers.

F.8 Model is good for:

a) Temporary fix with permanent fix to follow:

The issue generates two work requests. The first generates a work_order for the temporary fix with a dated effectivity start - as soon as embodiment possible, end = start date for second work_order. The second work request is for the permanent fix, with dated effectivity to start at the end_date for the first.

In the case where the product is controlled by serial numbered of lot effectivity, the translation from dated effectivity to serial numbered effectivity is determined by the production schedule.

In the case where the permanent fix is to be retrofitted into products having the temporary fix, a third work_request is required to devise the task_specification and resources required for the retrofit.

In the case where the permanent fix is to be retrofitted to existing products, and additional work order is required to devise the retrofit task.

NOTE    the exact details will depend on company processes. Actual embodiment against fielded products could be managed through PLCS.

b)Temporary fix with permanent to follow on next release of product:

Pretty much the same as above, except that one needs to sort out the way effectivity links to Product_concept and Product_version.

c) Work round notice - work_order with document (work round notice) as the product.

F.9 Scope Question: Customer

Customer management is not usually in the scope of STEP. The first comment is that there are two types of customers: end-product customers, and design customers, who pay for product development, and subsequently may or may not buy some of the production run. For example, in car manufacture, the end-product customer is Mr Joe Public, whereas the design customer is usually the marketing department. In the whoosh-bang market (e.g. interceptors, missiles, tanks), the two customers are often the same.

My guess would be that a design customer would be modelled as an organization related as "customer" to a design concept, and is in scope of AP 233. The end-user customer would be an organization related as "customer" to a product-as-realized. This would give product-to-customer traceability, and allow the list of customers to be generated. AP233 is likely to be interested in the design customer, AP 239 the end-product customer. To be able to notify the customer list - either or recall or other notice - other than a text note to do it in the work description, the only mechanism I can see is to create a Document which is the notification, and possibly associate a set of organizations to it as something like "intended_recipients" - this could be one organization "customers", which may be linked to the customer base through organization _relationships

F.10 Scenario 12: Issue evaluations that involve suppliers and customers

The association of an organization to the activity "issue-evaluation" is straightforward. Further, the role that the organization plays in the meeting (customer, supplier) is identified by the classification of the organization_or_person_organization_assignment associating them to the meeting. Note, the assignment not organization is classified, since the organization is not, in itself, a customer or supplier.

F.11 Overall Conclusion

The model is not far off standing up to most of the questions, and Work_order and Work_request seem to be able to do the job.

The only obvious thing to add to the model is Work_request_relationship, to allow the decomposition of Work_requests into individually controllable and schedulable packages. The selects connecting Work_order and Work_request to Activity and Activity_method and its subtypes in Task_specification and Scheme should be checked, as should the way Resources are tied to schedules (probably by being applied to the Activity_method associated to each Scheme_entry.

The creation of Work_request_relationship would require an additional module. Changing the integrated resources needed to create the mim would be a killer, but there is a versioned_action_request_relationship in the action_schema, which means no change is needed.

Dealing with contract changes would require major surgery on Contract to make it a versionable item, and would probably require some negotiation with the rest of STEP. It would be best to leave this out of the scope of the CD.

F.12 Business strategy - no way.

F.13 Implementation strategy - no way.

The normal mechanism for linking an Issue_item to the item referenced is the attribute Issue_item.item[i], in which case the attributes access_comment, item_identifier and item_type of Observation_item should be populated with the string "/IGNORE". In all other cases, the mechanism for linking the Issue_item to the item referenced will necessarily be implementation specific. Observation EXAMPLE 1 gives an example for a part 21 file.

© ISO 2011 — All rights reserved