ChangeManagementStrategyV0.5 Final

Change Management Integration Strategy
A requirement for the integration of Ford Systems
Initiate Change
Identify Problem
Approve Problem
<
Solve Problem Determine Impact
<
Approve Solution Verify Solution
<
Implement Solution Check Implementation
<
Complete Change
Originator: GPC IT/dnaranj2 Ford Motor Company Proprietary Record Type: Official/25.01
Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12
Table of Contents
1. Document
1.1 1.2 1.3 1.4 Development Team Document Reference Summary of Changes Status
4
4 4 4 5
2. Introduction 3. Definition and Nature of Change Management

3.1 Scope of this document 3.1.1 Concept Ownership 3.2 Key Components of the Architecture 3.2.1 Authoring Environment 3.2.2 Single Conceptual Model
6 8
9 9 10 10 10
4. Recommended Approach for Integration

4.1 Overall Basic Design Requirements 4.1.1 Information Change using Versions and Snapshots 4.1.2 Managing Multiple Objects 4.1.3 State 4.2 Advanced Design Requirements 4.2.1 Maturity 4.2.2 Effectivity 4.2.3 Workflow/Approvals 4.2.4 Indicator 4.2.5 Combining Workflows and Indicators 4.2.6 Alternation 4.2.7 Version Specific Structure 4.2.8 Latest Version Structures 4.2.9 Latest Version Behavior 4.2.10 Version Specific Filtering 4.2.11 Change Coordination 4.2.12 Change Dissemination 4.2.13 Interacting with Information Domains 4.3 Impact Assessment and Traceability 4.3.1 Impact Assessment 4.3.2 Traceability
11
11 11 13 15 21 21 22 28 30 31 32 34 35 36 39 39 39 40 42 42 43
5. Change Management Objects

5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 Issue Change Request Change Order Change Objects Problem Solution Change Solution and Change super-object Flexibility; Configurable Business Rules
45
49 49 50 51 52 54 55 55 56
Originator: GPC IT/dnaranj2 Ford Motor Company Proprietary Record Type: Official/25.01 Page i
6. Use Cases
6.1 6.2 6.3 6.4 6.5 6.6 6.6.1 6.6.2 6.6.3 6.6.4 6.6.5 6.6.6 6.6.7 6.6.8 7.1 Interaction of Version, Status and Maturity in the BOM Use of Investigation and Solution in Change Management Small Change in a Plant Cross-Vehicle Change Use of the Impact Assessment and Traceability in Change Management Embedded Software Change Managing the Feature Configuration (Subset A) Managing the Prototype Part requirements (Subset B) Managing the Production Part Requirements (Subset C) Business Architecture Use cases for POC Design a Flexible Function Audit a change to a Business Object Execute a Flexible Function Determine the lifecycle process state for a set of change requests Bill of Material
59
59 59 59 59 59 61 63 64 65 66 66 66 66 66
7. Change Management in Different Domains 8. Glossary
67
67
72
Originator: GPC IT/dnaranj2 Ford Motor Company Proprietary Record Type: Official/25.01 Page ii
Table of Figures
Figure 1 Change Management Implementation Scope ...................................................................................... 9 Figure 2 Variation of Attribute P Over Time................................................................................................ 11 Figure 3 Versioning and Snapshotting example .............................................................................................. 13 Figure 4 The use of a Change Grouping Object .............................................................................................. 14 Figure 5 Status............................................................................................................................................... 16 Figure 6 Different View of Object (Part) Maturity .......................................................................................... 17 Figure 7 Variable Change Rigor..................................................................................................................... 18 Figure 8 Characteristics of Different BOM Structure Types ............................................................................ 20 Figure 9 Overlapping Program Effective Points.............................................................................................. 26 Figure 10 Composition of Workflow & Tasks ................................................................................................ 28 Figure 11 Use of Indicators in a Change Management Process Flow .............................................................. 31 Figure 12 Combining Workflows and Indicators ............................................................................................ 32 Figure 13 Change Management Construct Usage............................................................................................ 41 Figure 14 Use of Information Constructs in a set of Workstreams ................................................................... 42 Figure 15 Use of the Impact Assessment and Traceability in Change Management ......................................... 44 Figure 16 Change Management Object Types ................................................................................................ 48 Figure 17 CM Strategy Review and Alignment with Architecture ................................................................... 49 Figure 18 Use Case - Engineering Change Management ................................................................................. 60 Figure 19 Use Case - Embedded Software ...................................................................................................... 61 Figure 20 Embedded Software Use Case Divided into Subsets ....................................................................... 62 Figure 21 Embedded Software Use Case - Subset A ....................................................................................... 63 Figure 22 Embedded Software Use Case - Subset B ....................................................................................... 64 Figure 23 Embedded Software Use Case - Subset C ....................................................................................... 65
Originator: GPC IT/dnaranj2 Ford Motor Company Proprietary Record Type: Official/25.01 Page iii
1. Document
1.1 Development Team
Name
Alan Fisk Steve Ray Igor Reznick Gary Wallace
Organization
GPC IT AD GPC IT PD
1.2 Document Reference

Digital assets captured in this document are referenced here and archived on SharePoint. Title
Change Mgmt Strategy Updated Figures, Images
Location
BOM Change Management Architecture PoC (BOM CMPoc)
1.3 Summary of Changes

Version
0.10 0.2 0.3 0.4 0.5
Summary of Changes
First draft Second draft, with a complete set of initial change constructs and a sample use case on Embedded Software Management Third draft, with more details on constructs mapped against information domains and workstreams Fourth draft add considerable detail to Change Objects, Structure versioning, as well as minor updates in many areas Recreated and updated drawings, diagrams, process flows; Updated Table of Figures and Updated Fields; Inserted a rerference Glossary of key terms.
Originator: GPC IT/dnaranj2 Ford Motor Company Proprietary Record Type: Official/25.01 Page 4
1.4 Status
Section
1 2
Title
Document Introduction
Page
4 6
Author
A. Fisk D. Naranjo A. Fisk D. Naranjo A. Fisk T. Bayne L. Victor D. Naranjo A. Fisk T. Bayne L. Victor D. Naranjo T. Bayne L. Victor D. Naranjo T. Bayne L. Victor D. Naranjo T. Bayne L. Victor D. Naranjo T. Bayne L. Victor D. Naranjo TBD TBD
Status
Complete Ready for review
Definition and Nature of Change Management
Ready for review
Recommended Approach for Integration
11
In development
4.3
Impact Assessment and Traceability Change Objects
42
Complete
42
Complete
Use Cases
59
Software use case ready for review Complete
Change Management in Different Domains TBD TBD
67
8 9
TBD TBD
TBD TBD
2. Introduction
Managing change to business artifacts and their associated data within and across Enterprises is a critical business function that takes place either formally or informally in all organizations. For example, an engineer may need to make a change to the Bill of Material for a suspension assembly. This might require that a component part is replaced by a different part, and that the assembly itself is also re-identified with a new part number because of fit/finish/function reasons. Not only is it important that the old parts are deleted from the product, and the new ones added, but that the timing of the change, and any approvals required are properly managed, and communicated to affected organizations. This is the role of Change Management. It applies to all information domains, such as CAD, BOM, Product Direction, Build Process etc. and to all organizations in the company, as well as external groups, such as suppliers. A principal impact from emerging business pressure, which targets reductions in both time to market and total cost, increases not only the rate of change of information but also the amount of overlap of change that must be confronted. An engineer may be working with the latest version of a part in a virtual simulation. A prior version may be undergoing physical testing while the current program status may be at a third level. Collaborating with multiple organizations, on multiple versions of product data, requires a more rigorous approach to managing change. Simple approaches, such as single information release points at well-spaced intervals of time, are no longer appropriate. Effective management of change therefore requires that the following tasks be accomplished both rapidly and precisely: Managing cutover from one state to the next Synchronization of change with other associated processes, events, and data Review/Approval of change Feedback from Reviewers/Approvers/Implementers Notification of change, both before and after the change itself Management of historical data, in particular being able to reproduce the data in context in prior states Determination of the impact of the change, both before and after the change Development of the change proposal
Change Management makes use of a number of unique business objects of its own in order to manage the business objects in a particular information domain. For instance, a Change Request object is used to authorize an investigation into a Product, which may result in the issuing of a changed Product Letter. The Changed Product Letter may need to be bundled with other related changes.This could be accomplished by linking the changed Product Letters with a Change Order, or Change Notice as it is sometimes known as. The management of these change objects could be facilitated by use of a set of standardized workflows. These are also business objects used in the change process. There may be multiple types of change objects, possibly an engineering change order for managing changes to product documentation, such as bills of material, product letters etc. and a purchase change order for managing changes to purchasing documents, such as purchase notifications, requests to quote, target agreements etc. Not all changes to business documents require that much rigor, especially early in a products lifecycle, so much of the use and detailed design of these objects and their associated methods falls into the area of business architecture/process design. This document will define a high level set of objects and methods that can be broadly applied throughout the enterprise. The use cases that provide context and texture to the abstract definitions will be focused on the industrial backbone, where a consistent approach should yield improvements in the speed and accuracy of managing change. This is version 0.5 of a living document which establishes the Change Management Integration Strategy.
3. Definition and Nature of Change Management

We define Change Management to be a structured and systematic set of processes, methods, information constructs and tools used to initially release and change/upgrade business entities (data, documents, requirements, designs, etc.) over time in a closed loop manner. The nature of the change processes will vary by organization (culture), the lifecycle phase of the information within its broader business context, and the severity of the business impact of the change. The nature of the information may also vary; possibly because of different change processes, possibly because of the need to consume earlier versions of the data, while the newer information coexists with it, or possibly because the information is at different stages of maturity or publication. For instance, Engineering may be in the process of publishing a new part version, while Manufacturing is still assembling products with the old level, meanwhile Finance may be evaluating the impact on profit over time, and may consequently be using multiple versions of the information. In order to better manage these various levels of process and information, some standardization of method, process, and information is required. To date this has tended to be done independently within each organization, whether regional or functional, or even product related. Operating as One Ford requires that the current state be normalized, and that a consistent process and information architecture is defined and governed. Additionally, as Ford interacts with a complex set of unique Enterprises--Dealers, Suppliers, Regulatory Bodies, etc.--some attempt at operating within industry norms seems to be attractive.
3.1 Scope of this document

For the purposes of this document the conceptual scope will be restricted to defining the methods and information constructs that can be used to implement processes and tools within Ford Motor Company. The implementation scope is shown in Figure 1 Change Management Implementation Scope. As can be seen, the scope extends throughout the Industrial Backbone, and is assumed to include both Ford and External Partners.
Data Repository
Assumptions
CAD
TCm
GSPAS
GPD (ACM)
AVBOM
WERS
CMMS
WIPS
Pt Ctl
Requirements
CAE
Broadcast
OTD
Pricing
Information Domain
Prod Assump Prod Reqts Prod Defn Product Finance
BOM
CAD
CAE
Target Setting
Mnfg Proc
Plnt Flr
Order Mgmt
Pricing
Plnt Sched
Service
Figure 1 Change Management Implementation Scope
3.1.1 Concept Ownership

We can define conceptual architecture that can be applied to any domain. Alan G Fisk subsequently qualified this "any domain" generalization by indicating the target is changes to items part of the Industrial Backbone (for example, not for HR change management). These concepts will not necessarily be implemented in one systems. There should be one set of concepts, and the concepts are mastered/owned by the Change Management Foundation "system."
Also, CMF (Change Management Foundation) is the master/owner of CM business

architecture concepts. Certain objects (e.g., version) will be implemented in various
domain systems, other objects may be implemented in various domain systems and other objects might only be implemented in the CMF system. We would expect objects to be (sub)typed for various domains. For example, we have a "Change" object. It will have a type: ECN to be used for engineering changes.
3.2 Key Components of the Architecture

3.2.1 Authoring Environment
The approach for Change Management assumes that Change Authoring will be conducted inside the existing domain tools, such as BOM, CAD, PDO etc. As a single change may require action to be taken in multiple domains, it is possible that a domain that has not been integrated into the new architecture may require a central change tool. The conceptual architecture should therefore allow for multiple loosely coupled authoring environments. The changes can be called in by the respective application, which will trigger the Change Management System to act and upon success, the respective changes will be saved in the respective application that called / initiated the change.
3.2.2 Single Conceptual Model

The architecture calls for a single conceptual model for change management. This includes both the model of the change objects themselves, plus shared elements in other domains, such as effectivity, maturity etc. The architecture outlines a number of common objects and services which would be provided out of a single logical Change Management Foundation. The transition approach for each domain is beyond the scope of this document. Although this Model will help us in tackling Change Management for anything in the Industrial Backbone and can be defined as a Ford CMF solution which acknowledges cross-company change management, we should not keep in mind that, we do not have the maturity to define system and data interfaces for coordinating a seamless change management process among systems operating at different companies.
4. Recommended Approach for Integration

4.1 Overall Basic Design Requirements
We take the approach that in order to manage change we must introduce both standards for how change is represented, as well as how the process itself is conducted. The fundamental architecture is detailed below. The initial set of concepts will be detailed in this section, and further advanced concepts treated following that. We claim that the set of basic concepts has introduced sufficient capability to meet the requirements of our first two bullet points outlined in Section 1.
4.1.1 Information Change using Versions and Snapshots

All information changes through time. In order to manage and coordinate information, this continuum of change must be broken into discrete units that can be identified, tracked, configured and retained. The version is the discrete unit of change. The below figure is intended to be an icon or logo associated with change management . It is not meant to represent a logical change management flow. We consider that some Information Entity A has an Attribute P, with a value 3 at Time T1. By time we imply some wall clock time and date, such as 2:31pm on Monday Feb 11 . . . , or some time based event, or some non-time-based sequence, such as VIN Number. This is shown in Figure 2 Variation of Attribute P Over Time.
T1 time
T2
T3
Entity
Entity
Entity
Attribute
Value
Attribute
Value
Attribute
Value
Figure 2 Variation of Attribute P Over Time At some future point, say Time T2, P may now have a value of 4, and then at T3 P may have a value of 5. Further, we want to ensure that times T1 and T3 have a greater
significance, that is that they are points where we wish to be able to exactly reproduce the information relationships between A and other associated entities. We therefore freeze these relationships and attribute values, and commit them to a permanent record with greater precision than the change at T2 , where we are concerned only with the second value of P. So entity A at T1 and T3 (shown as AT1 and AT3) has a global significance, whereas AT2 has a local significance. In Information Systems parlance, terms such as Version and Revision are often used to describe these concepts, unfortunately the terms are often used interchangeably. To avoid this we will refer to AT1 and AT3 as Versions and to AT2 as a Snapshot. AT1 will be referred to as Version 1, and AT3 will be referred to as Version 2. In order to manage this global freeze of A, we must capture the value of all attributes of AT1 and AT3, including those attributes/relationships between A and other entities that define the context of A within the domain that we are interested in. Conversely for AT2 we can just capture the value of attributes that changed, and if required the time itself. Snapshot is a behavior that is activated for select attribute(s) on an object. So on Part object , I have snapshot turned on for cost but not for the attribute weight. Each time cost value is changed, a snapshot of that attribute, and not an entire object is created. This is not the case for the attribute Weight . This concept is valid without having introduced Version concept. Version applies to the object as a whole, in contrast to snapshot, which applies to an attribute.
Version Vs Revision : In this document, we promote using one of these concepts VERSION. In past, survey of communities at Ford has led to even split of whether people think that versions are within Revisions or whether Revisions are within Versions. Conclusion is that there is no agreed understanding of these two terms, so only we have decided to use only one.
Building on this, and adding further attributes and times, we show an example in Figure 3 Versioning and Snapshotting example
T1 time
T2
T3
T4
T5
Entity
Version
Entity
Version
Entity
Version
Entity
Version
Entity
Version
Attribute
Value
Attribute
Value
Attribute
Value
Attribute
Value
Attribute
Value
P
Attribute
3
Value
P
Attribute
4
Value
P
Attribute
5
Value
P
Attribute
6
Value
P
Attribute
5
Value
Q
Attribute
6
Value
Q
Attribute Value
Q
Attribute
6
Value
Q
Attribute
Q
Value Attribute
10
Value
Figure 3 Versioning and Snapshotting example We can now see how P has varied over time, and can associate the changes to the values of Q and R at T1 and T3 without the overhead of managing the intermediate values of Q and R. It is worth noting at this point, that our scheme is explained conceptually, the physical implementation may--based on the domain needs--include more or less of the physical data, such as excluding non-changing attributes of versions, or including all attribute data in a snapshot, along with other entity relationships. Consider that this versioning behavior would typically be in the domain system, not in the Change Management system. Each domain may have its own set of business rules when an object is versioned (e.g., a particular attribute changes, a version is published and frozen).
4.1.2 Managing Multiple Objects

We next consider how to manage information across multiple objects. We introduce a Grouping object that links multiple changes in order to control their synchronous behavior. In this case, shown in Figure 4 The use of a Change Grouping Object, the two entities A and B are linked by attribute R; the example here might be some type of foreign key or pointer type structure; in which case we would always wish the objects to be published as a synchronous pair.
The grouping object is what makes them behave as a synchronous pair. Providing a Grouping Object, in this case linked to an Engineering Change Order, allows for the notion that the two or more objects should be updated together, and related to some formal change document. The reason to link to an Engineering Change Order is because, earlier, we allow a grouping object without the need for a change object. So, Grouping object likely needs to be a separate object. (Note : Consider that Wizard and CMF use the Bundling concept).
Change Group
Change Object Engineering Change Order
Entity Scope
A, B
Entity
Version
Entity
Version
Attribute
Value
P
Attribute
3
Value
Entity
Version
Entity
Version
2
Attribute
Q
Attribute
6
Value Attribute Value
P
Attribute
5
Value
Value
Q
Attribute
6
Value Attribute
10
Value
10
Figure 4 The use of a Change Grouping Object The linkage to a change document is controlled by business practice; the need to synchronize change may or may not require this, as indeed the set of changes itself may not need to be managed as a synchronous event. A grouping object would not be attached to multiple change objects, but it is conceivable. Although unlikely, that a change object (Change Order) might be allowed to have multiple grouping objects.
4.1.3 State
The next construct that we introduce is that of State. In section 4.1.2 for example it becomes important to understand which particular record is now the current one, and which has passed into history. We could do this with the version, always picking the newest version, however this does not make a distinction between what is current, and what is now being worked on and will eventually become the current record. In order to do this we define an indicator or flag, Status, which takes the values: Work in Progress, Published, and History. Use the Grouping Objects to act on both version getting changed to Publish and previous version getting changed to History. This results in both objects going through state change at same time. May also have Replace and Replaced By chains/relationships. This allows us to manage multiple versions of an object explicitly, and avoids ambiguities in interpreting records. The business process for the most part will dictate when an entity has to be published, although system to system communication needs may also overlay that. For instance, if information is to be passed to another IT domain and managed there in parallel, possibly even with a federated capability to update the record, it is important to freeze and publish the record before transmitting it. We also note, that snapshot data itself will not be frozen, but continue to evolve, either with a series of records (possibly including a timestamp) being stored, or just as a current value. Again business information and process needs will define requirements on an attribute by attribute basis.
Entity
Version
Entity
Version
Entity
Version
A
Status
1
Time
A
Status
2
Time
A
Status
3
Time
H
Attribute
1
Value
P
Attribute
3
Value
W
Attribute
6
Value
P
Attribute
3
Value
P
Attribute
5
Value
P
Attribute
5
Value
Q
Attribute
6
Value
Q
Attribute
6
Value
Q
Attribute
4
Value
10
Current Published Record
Figure 5 Status So we can look at the example in Figure 5 Status, and it is clear that AT3V2 is the current published record. Without the status indicator we would have to examine the object's content and try to determine which one might be current from a business perspective. (LV : The perspective here refers to the Engineering Intent. There is work ahead and work behind various organizations and activities) Motivation for Versioning: Ability to go back and understand the state of something in the past. Engineering are often working at different speeds, so there are different levels of maturity of their parts. (Work ahead and work behind) While doing development, we typically use Milestones to coordinate or tie together the different paces of development for related parts. We may also want to use date-based views as a perspective to look at a collection of items/parts. For example, four engineers and their parts were all in sync on Wednesday but they have diverged again by Friday. I want to have a Wed view of all these parts. Also consider that each item (e.g., part in development) may have Alternatives active at various times.
Milestone-A Indicator State of all items intended for the low Obj/part maturity milestone . Date-based Perspective State of all items on a particular date. Consumers responsibility to know whether items are in sync at that point . Milestone-B Indicator State of all items intended for the higher Obj/part maturity milestone . Milestone Perspective State of all items intended for a particular milestone .
T I M E
Alt B of Object Ceased further development on this path

T I M E
Figure 6 Different View of Object (Part) Maturity
When I have multiple objects, there are often relationships among the objects. Snapshot captures an attribute in an object, but it does not necessarily capture the relationships of the object. (One of the open questions is whether a relationship should be treated as an attribute and therefore could be accessible to snapshot.) Grouping Versioning These two constructs are collectively used to manage changes to several objects and their relationships to one another. PoC should look at building these out in a flexible way that allows business to change/morph over time. AGF asserts that we do not want to continue implementing certain aspects at the database level. WERS allows for multiple WIP versions. In WERS, the version of a part is actually implemented as a Notice number (no sequential number). (In WERS, a Notice provides both grouping and versioning.) So WERS must maintain pointers to the order of Notices that are the versions of a part. This means that when two WIP versions are active, we need to reorder/shuffle the predecessor version pointers (to Notices) when a later WIP gets Published before a prior WIP. This changes the baseline for the version still at WIP. Figure 3. Versioning and Snapshotting example We discussed and debated this diagram and this section for a while. AGF: This figure was drawn such that it shows every time any attribute was changed. So this means Q and R did not change values at T2, T4, or T5.

Change Request: Here is a problem. Is it enough of a problem that you want someone to fix it? Change Order: Here is the fix. Do you agree with the fix?
LEVEL OF RIGOR TIME

Change Business Object
Need Change Order
Need Alternatives
Need Investigation Then Change Object
Need Change Request
Figure 7 Variable Change Rigor
The level of rigor around change management increases over time. If a change involves many vehicle programs at different levels of rigor in the figure above, then change would need to take most rigorous path of all affected vehicle programs. See slide 17 Variable Change Rigor for examples of factors that affect the required rigor. (Change Coordination Concept Maps.ppt) So early on, you are capturing change but not capturing the reason for the change. There can also be certain attributes on an object that can be changed without change management. For example, there are some admin attributes on objects in WERS, and the value of these attributes can be changed by admin even after the object if frozen and published. Change Invest --> business obj Soln Informal desc. objects Chng Order --> bus obj Point of PoC is for flexibility and business configurability of controls and constraints around what objects and relationships among the objects over time.
We don't manage part "versions" across the shipping/plant dock, so this leads us to use part Change level Indicator to manage a change (e.g., cost change to a part, material change to a part) even when there is no form, fit or function change to a part. We should not mix up the version concept in CM Integration Strategy with way part suffix numbering/behavior in handled in enterprise. Part numbering is the most pervasive numbering standard and where you would expect the most sophistication in "versioning" concepts. VIN and Orders would also be pervasive. Other standards tend to be less complex. Product Creation Architecture (PCA) is considered guidance by AGF. We are taking from it selectively. We never implemented the Placeholder structure in the PCA. (business did not find this a natural way to work.) Most of the other BOM concepts in PCA we tend to follow. The CAD portions of PCA do not have consensus and are not followed today. In TeamCenter, Placeholder made it into literature but was populated by CPSC. Glossary PLM Study done in 2004 Build out all the concepts. Concept Maps with hyperlinks to definitions. AGF and Gary W worked on Change Management, BOM Parts, BOM Management, Change Management, Basic Object Management. Get Concept Maps for Change Management and Object Management from AGF.
Grouping Object
What is the value of Grouping Object?
Case A: Implicit Structure

A AA AAA AAB AB ABA ABB
I can understand relationships based on naming conventions. The relationships exist because of the data in the objects. (implicit pointers) I can tell AA is a child of A. AAA is a child of AA. AAB is a sibling of AAA. YES. I can publish AA and its children (AAA, AAB) without Grouping Object
Case B: Explicit Structure

A B D E C F G
Must walk structure to understand relationships.
Case C: No Structure
A F B G E D C
No relationships.
YES
NO
Can also use Grouping Object (GO) to publish objects that do not have direct relationships. For example, AAA and AAB.
Can also use Grouping Object (GO) to publish objects that do not have direct relationships. For example, D and G.
Can use Grouping Object (GO) to publish objects that do not have direct relationships. For example, D and G.
Figure 8 Characteristics of Different BOM Structure Types
Product Direction: Case A. Content of a feature string. Varies by Product Type. When I publish a PDL, I must publish at Product Type and Vehicle Line level. My structure is already in force, so do not need a Grouping Object. CPSC: Case A PADB PAF Tree: Case B Part Assembly Structure: Case B Collection of unstructured obj: Case C I MUST have a grouping object for these. Note: Implicit structures involve a level of risk since the relationships are not necessarily robust and the business practices may change. The up side of implicit structures is that the business and humans can grasp the meaning and work with the structure independent of relying upon a computer system. Business rules and structure (explicit or implicit) is not ignored or negated by existence of grouping object. We use Grouping Object as needed in addition to any business rules related to structure. If structure is sufficient for grouping in a given scenario, no need to also use Grouping Object.
4.2 Advanced Design Requirements

4.2.1 Maturity
Maturity is a contextual object by object construct; there is no consistent global set of values applicable to all objects through time. Rather, there is a set of values for each object; sub-types of objects would most normally inherit directly from the object. Maturity defines how far through its lifecycle an object is, usually by reference to the use that may be made of the information in its current state, for example: Bill Of Material Part Usage Maturity has a possible value of Study, this implies that the use of that part may be studied, but prototype tooling, prototype material, production tooling, or production material for that part may not be purchased. Other forms of attribution may also be used. There are different attributes that may be used to define maturity depending on the object. For CAD, Dimensional Tolerance (accuracy of CAD model to final geometry) is relevant to maturity. ) such as Dimensional Tolerances; for instance, all dimensions are within 5mm of the expected final size and shape for a part. The set of values for a specific object form an ordered list, starting at the lowest level, and increasing through the most mature. Maturity values must be an ordered list, since a sense of progression is required. For example, the present set for BOM Part Usage Maturity is U Unauthorized, SStudy, F Facilities, T Tooling, and P Production. Typically an object will be created at the lowest level of maturity, such as U, for a BOM Part Usage. Then, when the next version of the object is created, it will default to the value of the prior version of the object, but may be increased per the business process, so the next published version might be raised to S, or T for example.
4.2.1.1 Hierarchical inheritance of Maturity

Not all objects require an explicit statement of maturity, as this may be derived up or down through some hierarchical structure. For instance, in today's Bill of Material the Part Usage Object has a Maturity, but the part itself does not. The maturity of the part is derived from all of the usage statements. In this case the summation of the maturity statements informs the consumer of the information about the maturity of the use of the part, as opposed to the actual part itself. If a true indicator of the maturity of the part itself--absent its use--were required, a new indicator would be required, with potentially a unique set of values.
Sometimes we manage Maturity higher up or lower down in a hierarchy, and then Maturity is inherited (either up or down). One of challenges of BOM processing is deep hierarchies and relationships. Touching one object reveals many other objects are connected to it (stickiness of objects). Hard to delineate boundaries. We apply the term hierarchy to both peer-to-peer objects (e.g., assembly and component relationship of parts) and unlike objects (e.g., part and usage for part).)
4.2.1.2 Legacy maturity schemes

Product Definition currently manages Maturity through multiple sets of Product Types. Ideally, it would be represented by a single Product Type, such as Car, and a Maturity Identifier. The Maturity Identifier may pertain to any of the following: Early Engineering/Immature, Approved for Sale/Production, and, Approved for Service Only.
4.2.2 Effectivity
Effectivity is an important construct that identifies when in time information is valid, or is to be consumed. Effectivity provides a correlated view across many domains of information; however it alone cannot sustain a threaded view of causation. For example, knowing that two Parts will be used in a Plant on the same day to build two successive products does not tell us if the genesis of the parts is in any way linked, so we cannot imply a linkage that the change to one part would require a change to a mating part, or that prior versions of the parts may have restrictions as to the combinations in which the parts may be assembled together. In practice this type of causative link is established either by creating a master timing record, and pointing slave effectivity statements to it, or by linking at a higher level of hierarchy, such as at a change object later in the document. Master timing record for one part with other dependent (common cause) parts using slave effectivity to point to other part so that if one moves (changes date, they all must change). From systems perspective, master vs. slave is arbitrary. From business perspective, they have reason to select one as master. This causative link would be in the context of Implementation effectivity.
Design Effectivity is an Indirect Effectivity technique, as it establishes the effectivity of a controlling record, that itself points to a further construct that establishes when the content of that first document is used, i.e. its Implementation Effectivity. . Design Effectivity is indirect because it is managing the effectivity of the document/data structure that manages the implementation effectivity. Both types of Effectivity, Design and Implementation, are required for full reconstructive capability of historical records. This statement has flavor of Implementation Effectivity. Design Effectivity does allow history reconstruction. This may be needed in highly collaborative environments with multiple parallel and overlapping workstreams where it may be important to be able reconstruct the complete view of the information as it would have appeared at its point of release. Many implementations will likely select a single mode, in order to simplify the authoring process, at the expense of some manual reconstruction when required.
4.2.2.1 Design Effectivity When the document that describes the product (or parts) is to be valid.)
Design Effectivity determines when a business entity is released or changed; so for instance on Monday September 12 Version 3 of a design document will be replaced by Version 4. Design Effectivity is more like when the engineering direction is published and becomes valid, not about when the engineering direction is targeted to be implemented in production/service. It is about the document (Design E), not the content of the document (Implementation E) .
4.2.2.2 Implementation Effectivity Means when the data will be consumed in the context or product execution.
Implementation Effectivity determines when the content of a business entity is released or changed; so for instance on Monday November 18 the product assembly process will be revised to start using the new part that is defined by the current Version of its design document which on September 11 would have been V3, and on September 12 V4. The fact that both V3 and V4 were released with implementation effectivity of Nov 18 suggests that the design is still being refined by the product owner)
4.2.2.3 Effective Points

Effective Points are milestones within a Product Program which are used to determine specifically when a business entity is released or changed. The points refer to a specific date equivalent. The data equivalent can change if program timing is adjusted or delayed) .The Effective Points are structured to refer to a Product Type/Vehicle Line Pair, a Model Year/Partial Model Year, a Product Program, and an Implementation Location (Plant for instance). Effective Point Types: Although not in context of BOM, any of these types might be used for Implementation effectivity. Program Milestone e.g. Start of Mass Production
Calendar Dates (Probably only use Calendar Dates for Design Effectivity).
Change Document (e.g. Coordinated with Engineering Change Number 123474384) Vehicle unit, or range of units Sales events
Effective Point Extensions: Giving manufacturing a better view from engineering of when a change can be implemented and/or how much flexibility there is in implementing change (go ahead and use up stock before implementing change). Somewhat like comparison operations such a <= or >= to indicate when you may make change.) Before a milestone After a milestone
4.2.2.4 Filtering by Design Effectivity

Version Filters are used to select the appropriate version of an object. The "appropriate version" depends on what the purpose is. Examples of "appropriate versions" include: Latest Frozen information Frozen Information as of a specific date
Work in Progress information Version filters are used to select the appropriate version. Structures can be viewed using different filters. A default version filter will be automatically applied by the system. The user can select an alternate version filter to display a different configuration of the structure. Only one version filter can be applied to a structure at a time.
4.2.2.5 Implementation Effectivity Streams

Effectivity streams define a high level and conceptual object within an application partitioning scheme. They provide both a high level orientation to the consumer of the information, as well as a means to manage control of "dead" objects when considering copying and carry forward methods within an application. This refers to hierarchical data. When attempting to do a cut and paste or copy forward, One would possibly want to leave dead (effected out) objects behind and not include them in the resulting collection/structure. This is independent of using state. Here , largely a copy forward issue is being addressed, not as much a BOM solve issue. One use of Steams is to manage Effective Points in order to control overlapping effective point equivalents generating incorrect results when conducting point-in-time analysis within a Bill of Material. The requirement for streams and the unique sets of streams will likely vary by information domain. Initial BOM Effectivity Streams are Production and Physical Prototype Initial Product Definition Streams would be Engineering, Production and Sales
The diagram in Error! Reference source not found. depicts a typical a typical situation where the effective points of the 2013MY program overlap with the 2015MY program. By assigning the effective points to streams the overlap is eliminated.
Notice that prototype build data for 2015MY is before J#1 for 2013MY. So if 2013 part is effected out at 2015MY prototype build and new/replacing part is effected in at 2015 MY prototype build, we would end up dropping the 2013 part from our structure/file/next release before ever getting to 2013MY J#1. We get around this today by putting fudge (out in future) dates in for prototype build effective points and then correcting for this fudge in GPIRS. WERS was not originally designed to handle and manage prototype parts.)
PS 2013MY
PS
FDJ FDJ
PS
J1
FDJ
Jan 2010
T0
T1
T2
T3
T4
Overlapping Program Effective Points

FDJ
Apr 2011 Jun 2013 Virtual

PS
Streamed Program Effective Points

PS
J1
2015MY
PS
May 2012 Jul 2014 Proto

FDJ FDJ
FDJ
Prod
J1
Figure 9 Overlapping Program Effective Points
The Streams would become part of the key for a Line of Usage. This would allow for multiple LOUs on a part that are each oriented toward a different stream within the same vehicle program. This would make BOM Solve more complicated, but it would actually allow BOM Solve to work without us performing gyrations and fudging data related to effective points. This Stream concept is in the BOMF data model, but it is not being used as intended. We are still relying upon the serialization approach taken from AVBOM. There is also work to do on the UI to accommodate this Steam concept. This work was not prioritized in 2012) Splitting contiguous usage across streams, such as a Part Usage that is Effective from a Physical Prototype Build through Production Job Last could result in an increase in the lines of data that must be managed. This effect should be eliminated from a user perspective by managing single In and Out Effective Points, with an In Point in one stream and an Out Point in another Stream. So while we may be storing two or more Lines of Usage (each with a different Stream value), we could present the information to the user in a consolidated way )
4.2.2.6 Cross-domain Mapping of Effectivity

Effectivity dates are more granular than the effectivity used by the PDL Therefore which PDL to go to for Effectivity should be known, since there is not a PDL for each model year.) The complete set of Effective Points may not in all cases be used to Release or Change Manage Enterprise Data across different Information Domains. It will be essential to define mapping rules in order to link the entities. For instance if a Part is released with a Line of Usage that is Effective In August 1st 2017, it will be important to map the date to the effective date for the PDL, which will likely be released to a Model Year. Equally if the Line of Usage is released to say MY2017, and PDLs have been published only for 2015 and 2020, it will be necessary to explicitly map the usage to the earlier Program Direction Letter (PDL).
4.2.3 Workflow/Approvals
Workflow (have a flow) Type (Approve CR) Activity (set of named things to do) Data (data associated with workflow) Transient Cond (relationships between the set of activities) Role (who) )
Task (user does by themselves; internal) Figure 10 Composition of Workflow & Tasks from CM Strategy Review and Alignment with Architecture
This drives process and allows Indicator calculation (e.g., Create CR is complete, in Comment CR
Compose:
-- Workflows -- Tasks -- Information (objects)
Authority/Governance Pre <FDJ> Pre <FDJ> Workflow, Tasks & Objects
Compose allows Indicator : Phase of an object lifecycle for product program

-- Probably need to maintain table of PD methodology for each Product Program
Create CR Comment CR Approve CR Solve CR
Workflow, Tasks & Objects
Completeness for each Workflow and Task and Objects So Compose => Indicator (phase of product program )
Consideration: What happens to objects in process (in workflow) when business changes configuration (table) over weekend?
Figure 10 Composition of Workflow & Tasks
Workflow is a means to automate a pre-defined set of procedures where information and/or tasks are passed between a ^&prescribed set of participants according to an agreed set of rules, in order to achieve a business goal, such as approval of a new release of a product design document. For the purposes of this document we ignore a number of more physical requirements, such as the need to orchestrate workflows across heterogeneous environments, the choice of a specific industry reference model to enable implementation, etc. The roles of workflow execution engines and workflow gateways are also considered to be beyond the conceptual scope of this document. There are five key elements that need to be enumerated to identify a conceptual orthogonal canonical reference model.
4.2.3.1 Workflow Type

This consists of a high level descriptor for the workflow itself, a version indicator to allow for change of the definition over time, start and termination conditions for the workflow, and control data to manage security and audit needs.
4.2.3.2 Activity
This defines a set of named and typed activities that comprise the workflow. Each activity itself may describe some manual set of tasks that need to be accomplished, or may Invoke a set of Internal or External Applications, such as approving the publication of a new Product Letter. An activity, similar to the Workflow as a whole, may have start and termination conditions, control data, etc.
4.2.3.3 Data
This defines the set of data that is used by a specific Activity. It may point to some external repository, an internally attached document, the specific instance of data that an Invoked Application is to use, etc.
4.2.3.4 Transition Conditions

The activities will have a set of flow or execution conditions, allowing for a Petri Net like structure, supporting choice, iteration, and concurrency of activities. Examples would include:
Serial/Parallel routing Nested routing Conditional branching
4.2.3.5 Role
Each Activity will have associated with it one or more Names and or Organizational entities that define the participants in the activity.
4.2.4 Indicator
Indicator is derived, not directly manipulated. State can be one or the other (directly manipulated or derived), but it can be confusing to be both (e.g., Concert status behavior). Rules for determining an Indicator value may change over time. It is even possible for something that is an Indicator today to become a directly manipulated attribute in the future because the business rules change and it can no longer be automatically derived. An indicator is a dynamic attribute of a business object that is systematically derived from its contents. The list of values are not necessarily an ordered list, taking into consideration that object may move backwards, there may be branching,,etc) and the algorithms to calculate them are specific to the object type. Some examples of indicators are: An icon on a part that indicates whether the part (or assembly, if the part has children) has any open issues associated to it. The color of the icon would reflect the severity of the issue(s). As the issue status changes, the indicator dynamically updates to reflect the change. An indicator that identifies whether a part has later versions available. An indicator could be used to show the current lifecycle state of the process flow of an Engineering Change for instance. See Figure 11 Use of Indicators in a Change Management Process Flow for an example. Possible values (Based on the VDA SASIG process) might be: Create ECR/O, Technical Analysis, Commenting on ECR/O, Approval in Process, Approved/Rejected.
Figure 11 Use of Indicators in a Change Management Process Flow
4.2.5 Combining Workflows and Indicators

It should generally only change the lifecycle state at the conclusion/completion of a Workflow. Also both Tasks and Workflows (conclusion of Workflow, not an Activity within a Workflow) can be mapped to a lifecycle state) One powerful use of workflows and indicators is automating the change to process lifecycle state indicators. Historically the lifecycle indicators and the object status have been both overloaded into a single field, and also manipulated directly. The WERS Concern status is an excellent example of this approach. Over time as lifecycle states and status have grown in complexity other indicators were added, such as the Program Management flag. Sometimes the status was directly manipulated, such as moving the Concern Status from W (Work private to Originating Activity) to P (Preview sent to Manufacturing Change Control) or A (Approved sent to Engineering Change Control). Other times the Status was changed indirectly, such as moving it from A to C (Concurred at least one Engineering Activity has accepted the Concern) or X (Rejected by Engineering), by inspecting the values and associated dates of the Engineer Response field. This resulted in a mish mash of indicators, and methods for managing them, with consequent difficulties in both user comprehension and reporting utility. We advance here the notion that we should orthogonally separate the notions of publication Status/State and Process Lifecycle, and have a consistent approach to managing the lifecycle and status, preferably through indirect manipulation, based on business sensible tasks being initiated or completed. A detailed example will be provided in the use cases.
We define then two new ideas, that of allocation and that of completeness. In order to determine when to change the lifecycle indicator we allocate a task or set of tasks to each state. Note: These are tools to make it more straightforward to know when lifecycle state changes. The tasks may then be tested for completeness, and if complete the change lifecycle indicator can be advanced. The allocation of tasks could either be a specific set of actions taken within the context of one or more business objects, such as filling out a pre-specified set of data fields within a business object, or it might be responding to a set of workflow requirements. We envision that the task may be stated as a conditional business rule that might for instance require different actions at different points in the product lifecycle. The below diagram is taken from CM Strategy and Alignment with Architecture.
Make change
<Create><Commit><...> <Investigate>
<Describe>
<Com>
<Approve>
...
<Change Request>
<Solution>
<Change Order>
Indicator
Workflows Named instance (evaluates Completeness) Tasks: Objects: --CR --CO
We might have Workflows that are different (tasks, objects) base on program timing: <PS> TO <FDJ> <FDJ> TO <J1> <J1 TO <JL>
Vehicle Issues CR1 CR2 CR3
Indicator X Y z
Figure 12 Combining Workflows and Indicators
4.2.6 Alternation
Most of the time, work on an object proceeds as a single linear sequence of versions. However, in some situations, work on an object must proceed in parallel on more than one direction at the same time, for example in the case of design alternatives.
When parallel development is required, a new alternative is created for the object. An example is shown below.
At time t1, it was determined that an alternative approach should be explored. A version branch from M.1 was used to create A.1. Work progressed on the main design with versions M.2, M.3 and M.4. In parallel, work progressed on the alternative track with versions A.1 andA.2. At time t2, it was determined that another alternative approach should be explored based on version M.2. Another version branch was used to create B.1. Work continued on all three alternatives through versions M.4, M.5, A.2, A.3, B.1 and B.2. At time t3, the main approach and two alternatives were reviewed and it was determined that Alternative A should become the main approach. A Version Replace was used to merge version A.3 back into the main design as version M.6. When creating a new version of an object you have the option to: Create a new version Create a new alternative (version branch) Merge with the main design (version merge) Here are a few general comments about alternative tracks: The system will be able to identify all the alternative tracks for a given object. There can be multiple alternative tracks for a given object. A version must be frozen (Review or Published state) before a version branch can be created from it. When a version branch is created, a link is retained from the first version of the new track (A.1 in the example above) to the version on the previous track that it was created from (M.1 in the example above).
A version branch can be created from any frozen version, not just the latest version (see B.1 in the example above). In order to do a version replace (or merge), both the source version (A.3 in the example above) and the version being replaced (M.5 in the example above) must be frozen (Review or Published state). The version replace operation creates a new version (M.6 in the example above) using a copy of the source version (A.3 in the example above). This new version has a Work In Progress state and can be modified and/or frozen like any other version. When a version replace is done, a link is retained from the new version (M.6 in the example above) to the source version (A.3 in the example above). Version replace can be used to bring forward a previous version of the object as a new version (see diagram below).
4.2.7 Version Specific Structure

In a version-specific structure, a specific version of an assembly references specific versions of parts. If a part is versioned, the assembly must also be versioned. This is sometimes referred to as bubble-up change or version precise. You can do design in context without first versioning the assembly by allowing the WIP version of the part to be replaced in the assembly but preventing it from being made effective in the frozen version of the assembly. To complete the change you must version the assembly and then make the latest version of the part effective in the latest assembly version. The diagram below shows an example: P6 can be changed in context, but the change cannot be made effective until all parts in the branch have been versioned and replaced as required in a version specific structure.
4.2.8 Latest Version Structures

In latest version structures, the change management is fully delegated. Assemblies always use the latest version of their constituent parts. This means that the child parts determine the assembly contents in terms of which versions are referenced. (e.g., I version my part; you get the latest version in your assembly). This is sometimes referred to as version imprecise. The diagram below shows a version imprecise structure. P6 is versioned and replaced in the structure without P4 having to be versioned. Each time P6 is versioned, the latest version is replaced as the default in the structure.
4.2.9 Latest Version Behavior

The content of the structure is represented by links between a parent object and its children. From a change management point of view, the links are part of the parent object. As a result, changes to the content of a structure require a new version of the parent. Examples of changes to a structure are: Add parts Remove parts Replace children with different parts Change position of parts Change quantity of parts Change variant expressions The following sections illustrate the behaviors of latest version structures for these cases.
4.2.9.1 Content Changes

In the example below, the left diagram shows the contents of the data model. On 4/25, the Tapping Plate was added to the Rail Assembly. On 5/15, the Reinforcement was removed
from the Rail Assembly. The right diagrams show the result of applying date-based version filters for three different points in time.
4/20 4/20 View View Rail Assembly 001 Frozen 3/15 doc Rail 002 Frozen 4/02 Reinforcement 002 Frozen 3/30
doc
Complete Complete Set Set of of Information Information
Rail 001 Frozen 3/15 Rail 002 Frozen 4/02 Reinforcement 001 Frozen 3/15 Reinforcement 002 Frozen 3/30 Tapping Plate 001 Frozen 4/25
doc
Rail Assembly 001 Frozen 3/15
doc
4/30 4/30 View View
Rail 002 Frozen 4/02 Reinforcement 002 Frozen 3/30 Tapping Plate 001 Frozen 4/25
doc
Rail Assembly 002 Frozen 4/25 Rail Assembly 003 Frozen 5/15
doc
doc
doc
doc
doc
5/20 5/20 View View Rail Assembly 003 Frozen 5/15
Rail 002 Frozen 4/02 Tapping Plate 001 Frozen 4/25
doc
doc
56
4.2.9.2 Geometric Position Changes

Geometric positioning information is carried on the link between the parent and the child. As with changes in content of the structure, changes to the geometric position of a child require a new version of the parent. In the example below, the left diagram shows the contents of the data model. On 4/02, the Rail was repositioned in the Rail Assembly. The right diagrams show the result of applying date-based version filters for two different points in time.
Complete Complete Set Set of of Information Information Rail Assembly 001 Frozen 3/15 1 1 Rail 001 Frozen 3/15 doc
1 1
Rail 001 Frozen 3/15 Reinforcement 001 Frozen 3/15
doc
doc
2 Reinforcement 001 Frozen 3/15
2 1
doc
Rail 001 Frozen 3/15 Reinforcement 001 Frozen 3/15
doc
doc
4.2.9.3 Quantity Changes

57
Like geometric positioning, quantity is carried on the link between the parent and the child. As with changes in geometric position, changes to quantity require a new version of the parent. In the example below, the left diagram shows the contents of the data model. On 4/02, the quantity of wheels was changed from 5 to 4. The right diagrams show the result of applying date-based version filters for two different points in time.
Complete Complete Set Set of of Information Information Part Instance 4 001 Frozen 3/15
3/20 3/20 View View Rail Assembly 001 Frozen 3/15 Wheel 001 Frozen 3/15
Quantity = 5
Quantity = 5
Part Instance 4 002 Frozen 4/02
Quantity = 4
Wheel 001 Frozen 3/15
4/20 4/20 View View Part Instance 4 002 Frozen 4/02 Wheel 001 Frozen 3/15
Quantity = 4
58
4.2.10
Version Specific Filtering
Version Filters are used to select the appropriate version of an object. The "appropriate version" depends on what the purpose is. Examples of "appropriate versions" include: Latest Frozen information Frozen Information as of a specific date Work in Progress information Version filters are used to select the appropriate version. Structures can be viewed using different filters. A default version filter will be automatically applied by the system. The user can select an alternate version filter to display a different configuration of the structure. Only one version filter can be applied to a structure at a time.
4.2.11
Change Coordination
As was briefly mentioned in the section describing Effectivity, it is important to be able to relate change causation, in order to create persistent linkages between related sets of changes. The term Change Causation means that I have a set of changes that MUST be performed together. Thus it is the same meaning as change dependency. This takes the approach of linking change documents, so that a change emanating from one organization (master change object) that requires a related change from another organization (slave change object) to be implemented concurrently is managed appropriately. Two techniques are applied together to accomplish this: First the change objects are cross-linked. In today's Engineering Change environment (WERS) this is done by sharing the same Notice Base Number. It may be more appropriate to use explicit linked structures to accomplish this in a future implementation. Secondly a master set of timing data is released in the master change object. The slave change object point to the master object for its effectivity statement, thus if the master change varies over time, the slave objects follow along.
4.2.12
Change Dissemination
Change dissemination is the set of functions associated with both publishing and subscribing to information changes within a specific domain of interest. For instance, an engineer making a change to a suspension arm may be required to notify their manufacturing counterpart that the change has now been published, and is available to implement.
This set of functions can be conveniently broken down into three key topics: Defining the domain of interest The set of services for publication The set of services for subscription
Defining the domain of interest is at its most simple the statement of a specific instance of a class of information, such as Part Number 12B4 123A567 AA. This can be extended by referring to a set of instances of a class that is classified in some way, such as the set of all parts that are owned by particular engineer, or are used in a particular product. The process of defining the domain of interest may be more complex than can be defined by simple statements; an example might be a buyer who needs a list of parts for a vehicle program, once the list is 80% complete. In this case, the calculation of the 80% is nonobvious, as there is no definition of what 100% represents. An approximation might be made by counting parts on a similar product, say the outgoing vehicle. Some form of information analytics has to be provided to be used to define the domain of interest therefore, and this may be applied to either the publication or the subscription functions. The services for publication would comprise the ability to define information recipients and describe some type of action that is required, such as confirmation of receipt of the notification, and attach the recipient list to a domain of interest, either as a one-time action, or on an ongoing basis, as the domain of interest varies over time. The service for subscription would be similar, but would probably lack the action statement. There is some overlap with publication and workflow/approval, and it is assumed at the service level that the publication actions are conceptually implemented as simple workflow actions.
4.2.13
Interacting with Information Domains
In today's environment each information domain tends to be buffered from other upstream and downstream processes. Information is passed on, without regard to the ability to consume it, and without understanding the implementation state. Moving forward we envision a future state that is more connected, and that provides for feedback of information, as well as more rigorous use of common information repositories; such as the repository defined in the UBOM Strategy. We also anticipate a more cohesive security approach to information.
In order to achieve this each domain will be required to implement change in a consistent manner (i.e. the constructs defined in this document, such as Effectivity, Maturity, Version, Status etc.), as well as to use corporate services for a number of key constructs:
JL PS
Security Change Objects and their Relationships Workflow orchestration

PSC PTC PA FDJ VP FEC J1 JL
Target Setting and Management Product Direction Authoring and Management Bill of Material Authoring and Management Global Tooling CAD BOM Alignment
Uses
Uses
Uses
Effectivity Version Status Change Objects

Owns
Workflow Alternation Indicator Usage Part

Owns
Maturity
Defines
Change Management Foundation BOM Foundation Information Standards
Figure 13 Change Management Construct Usage This is partially illustrated in Figure 13, where two Foundations, BOM and Change Management are shown. Each Foundation owns, and by implication defines a number of objects, in this case BOM is shown to own two, Part and Usage, and Change Management owns the Change Objects. Other constructs are not objects in their own right, but are implemented as extensions and behaviors of objects owned by other Foundations; examples like this include Version, Status, and Maturity. A third class of construct may be objects, but objects are not at this time implemented as an Independent Foundation. Workflow is an example of this. Each Information Domain, and by extension Workstreams related to them, will use a number of these constructs. This is shown graphically in
Figure 14, where a set of possible workstreams (horizontal blue bars) are shown with a set of possible Information Constructs (vertical yellow bars). The intersection of the two, shown by a checkmark indicates that that construct will be used in that workstream. The specific set of Change Management Constructs used in each domain is represented in tabular form in Section 7, Change Management in Different Domains.
Figure 14 Use of Information Constructs in a set of Workstreams ADD CHECK TO PDO/ALTERNATION A further aspect of managing change across domains is the concept of coupling. In principle we would expect that the domains would be linked using loose coupling techniques. Examples of this approach may be found in the Use Cases.
4.3 Impact Assessment and Traceability

4.3.1 Impact Assessment
Assessing the potential impact of a change is an important step in the process that is usually associated with the creation of one or more solution sets. For a given solution a typical impact statement might include the cost of resolving the change, the scope of affected parts, the timing associated with implementation of the solution, together with any changes in the key product attributes.
The ability to model the impact is expected to be facilitated in the set of information domain applications specific to the problem, such as a CAD system, a CAE system(s), a BOM system, etc. These systems should be able to take the solution description as a primary input and together with additional data compute the impact. The output should be stored locally, but a link provided back to the change management environment that supports viewing/exploring the result. Integrated environments (e.g. vehicle cost/weight analysis) will provide a more interactive capability, supporting direct modeling of the change impact for potentially multiple alternatives. The results should be readable with a standard Ford client (possibly browser-based), however unique clients may be required for full functional collaboration, e.g. a finite element post-processor.
4.3.2 Traceability
It should be possible to trace changes in data in information domains back to each individual Change Request. In addition it should also be possible to see the difference in the actual change compared to the planned change (Solution vs. Change Order), and also the resulting differences in the impact matrix.
CR1
Note that CR to Solution relationship can be M :N. A given Solution may be related to more than one CR.
Solution C Solution B Solution A
F
Cost Weight Strength Temp
Impact Analysis details: Should certain impacts such as Cost and Weight be performed in the Change Management tool itself instead (e.g., CMF prototype ) of in the domain systems?
CR2
Add PtA Delete PtB Change PtC
Impact Assessment B&C
B
Impact assessments performed in domain specific tools with domain-specific knowledge. Tool examples: Nastran, mainframe.
Change Order
R
Impact Analysis might be captured as PDF, HTML, or.?
Will we store a complex tradeoff matrix for integrated Impact Assessment? Attach rendering to Change Order ?
Figure 15 Use of the Impact Assessment and Traceability in Change Management
5. Change Management Objects

Note: This section reflects accurate hierarchy of Change Objects (classification, then typing). Also, the terms in this section reflect the terms that the business (Ford) uses today to conceptualize change management. Management of Change requires a set of objects to manage change itself, as well as to depict the change in the various domains of interest. We will define the conceptual relationships between these entities using the context of BOM management, and define a basic set of information and functional properties.
Issue Business Documents Issue Problem Concern Solution Change Order Change Order WERS AVBOM/CMF Verification artifacts Changes that require validation
is a
is a
identifies is a
Investigation Problem Report

Change
Set of Possible Solutions
Statement of Change
Points to business objects Points to external documents Solution
identifies
Request
modeled by is a identifies modeled by is a
Change
Agreement to resolve
Issue
Points to assessments & final solution Change Order

identifies
Impact assessment Alternative & final solutions
Problem
Points to business objects Point to Change(s)

identifies
Points to durable hierarchy Point to Problem(s) Has workflow Point to Change(s) Has Approvals Point to Problem(s) Has Collaborations
with identifies
identifies
Informal statement of solution
Points to one-time hierarchy
Changes that require publication
Has workflow Circle Of Friends
Has approvals
Alternation Coordination Multiple changes Multiple Domains
Discussion with Architecture: What about security configuration and administration for these objects and this behavior? Legend for Change Objects figure: Yellow: Object class structure AGF would expect each of these to be a blob in an ORM diagram. Pink: Concept map that describes what is going on. Light blue (turquoise, cyan): A set of business documents in the context of their current state system landscape.
These are not necessarily the system names for the documents (e.g., Change Order instead of WERS Notice). Darker bluish (lavender, purple): Intended to be a set of capabilities, functionalities (fairly granular), or desired behaviors. In order to manage the business change process we identify a consistent set of documents that record and promulgate problems, requests to change business entities, and the changes to the entities themselves. Specifically, we call out three documents: Issues, Change Requests, and Change Orders. In the context of an information domain these names may be particularized, such as Engineering Change Request, or Engineering Change Notice. In the present Ford IT context, these objects are shown below, against WERS (Formal or Mature BOM Management), and AVBOM (Informal or Early Management using CMF (Change Management Facility). CMF terminology uses Alternative as the equivalent of the set of possible Solutions (solution as defined in this document). With the introduction of CMF we see the use of an explicit Solution object, as further described below:
Business Documents
Issue Issue
Concern Problem Solution
Change Order Change Order
WERS AVBOM/CMF
Changes that require validation Verification artifacts
is a
is a
is a Investigation
identifies
Problem Report
Statement of Change
Points to business objects Points to external documents
identifies
modeled by is a
Concern identifies
Solution modeled by is a Solution
Impact assessment Alternative and final solutions

identifies
Problem
Issue
Change
Change Order
Points to business objects
Point to Change (s)
identifies
Points to durable hierarchy Points to Problem (s)

Has workflow
identifies
Points to one-time hierarchy Point to Change (s)

Point to Problem (s) identifies
Has Approvals
Has Collaborations with Circle Of Friends Has workflow

Has Approvals
Alternation Coordination Multiple Changes Multiple Domains
Mature Early
Business Documents
Issue Issue
Notice Change Order
WERS AVBOM/CMF
The AVBOM/CMF row actually includes other systems in Early as well, such as AIMS for issues. Same is true for Mature row. Other types of structured communication, such as Alerts, also need to be categorized; these will be considered in a later version of this strategy. Definition of Alerts: Below listed are the examples of Alerts. Can't Make Can't Process Manufacturing Line Trial Fix Part Process Modification (PPM) Use Part Process Modification (PPM)
Change Management Objects "has" (abstract classification): Problems [what I am trying to resolve] "is a" o Change Requests (Concerns) o Issues Changes [what I am doing to fix it (Problem)] "is a" o Investigation (due to critical business practice and need for strong "firewall" to distinguish between action that is not intended for P (production) authority. Action taken via Investigation cannot be released a P authority. If I later want to use that object/part for production, I will need to release it again at P authority.) o Solutions o Change Order (might have subtypes of Engineering Change Order, Purchasing Change Order, . May or may not do this in PoC. Seems it should be done early on in implementation.) Classification: Telling you the type of animal you have. It may be nonhierarchical. Typing: Indication of shared attributes and behaviors. Hierarchy. Like OO inheritance. Problems and Changes are a classification of Change Objects. The five items are "typing" of Problems and Changes.
Problems has subtypes (Change Requests, Issues). Changes has subtypes (Change Order, Investigation, Solution). Problems and Changes are not necessarily subtypes of the overall concept Change Objects. Keep in mind that these objects are based on business architecture, but we need to We may have a Change Request without having Issues. A Change Request can stand alone. There is a many-to-many relationship between Concern and Notice. We might want to insist there is a one-to-many relationship between So in general, we have 0..infinity <=> 0..infinity relationships among most objects, and then we configure via business rules how those relationships should behave.
Change Objects Problems Changes

classification
typing
Issues
Change Requests
Investigations
Solutions
Change Orders
Figure 16 Change Management Object Types
The below diagram is taken from CM Strategy Review and Alignment with Architecture)
Change Request Initial Assessment PrtA PrtB ? Change Order Change Impacts
CR1
CO1
PrtA
+$2
Different Change Orders since PrtA and PrtC are owned/changed by different organizations .
CR2
PrtA PrtC
CO2
PrtC
+$1
How do we account for the costs of implementing the Change Order ? We do not have an answer for this today . CR2 could not have been resolved without changing PrtA , nor could CR 1. So how do we divide the cost for this fix?
12 Fold Way (discussed by Wayne Collier) 7 Dimensions (Wayne Collier). What you need to do PLM : 1. State 2. Maturity 3. Effectivity a. Temporal b. Geographic 4. Ports/Interfaces 5. Version 6. Variation 7. Hierarchy
AGF believes Effectivity should be broken into two distinct items, so 8 Dimensions . In Ford, we have inappropriately merged some of these concepts , such as State and Maturity . State: Measure of progress . Examples: WIP, Published , History. Maturity: What it is good for.
Figure 17 CM Strategy Review and Alignment with Architecture
5.1 Issue
An Issue is a stand-alone document that allows the business to identify and describe a specific problem; such as a product development problem, for instance a design clash between two components that requires one to be re-positioned. Other examples might include a problem such as a rattle that was identified during a proving ground trial, or a broadcast specification that is incorrect. An issue might also include an informal statement of a solution, especially when resolution is rapid, and requires little or no expense.
5.2 Change Request

A Change Request is a document that is used to both formalize and group a set of Issues, or to formalize a standalone product problem not previously identified as an Issue. This
allows multiple issues to be addressed with a single iteration of re-design, as well as providing a platform for formalizing the process. Early in the design life-cycle, when the design process is more organic, such formalization may not be required; closer to mass production this may be a mandatory process. In many instance the Change Request is extended to include a statement of potential solutions to the problem, as well as a recommendation or agreement to the final solution. Typical key data constructs of a Change Request might include: Change Request Number Change Request Name Change Request Author Change Request Date Change Request Creation Date Description Alternative Solutions Solution Impact Assessments Affected Commodities Affected Parts Affected Products ( LV : Products are Vehicle programs, engines, transmissions, etc) Affected Activities ( LV : Includes Plants) Approvals
5.3 Change Order

A Change Order is a document that promulgates a released or changed business entity to a community of interest. A Change Order may group a number of business entities, as well as grouping a number of Change Requests. The grouping capability is used in order to both collect related entities together, as well as to move them through a consistent set of information states synchronously; thus ensuring that hierarchies of information maintain integrity. For example an assembly together with its components may be grouped, as well as the assembly with its usages, and the components with their next assembly structures.
( LV : While both Change Order and Change Request have grouping capabilities, Change Request references (e.g., pointing to Change Orders) whereas Change Order groups business objects so they can be managed together (e.g., effectivity, casation).
Typical key data constructs of a Change Order might include: Change Order Number Change Order Name Change Order Author Change Order Date Change Order Creation Date Description Solution Solution Impact Assessment Affected Commodities Affected Parts Affected Products Affected Activities Approvals
5.4 Change Objects

We identify two business objects that may be used in order to create and manage the business documents (Problem and Change). We further note that in particular the notions of Issue and Change Request are somewhat over-leveraged in practice, and can be accommodated with single object Problem, with a minimal sub-typing to allow for the minor addition of the informal statement of the solution. The notion of an Opportunity ( LV : Opportunity : this may be at the wrong place in the document. This needs to be mentioned earlier in the document)can also be considered to be a Problem, as it represents a lack of present capability that is addressed in the same manner as a problem. The possibility of sub-typing into problems and opportunities will be addressed in a later version of this document. The Change is also sub-typed, to allow for Investigative work that may require low maturity business objects to be published (such as a prototype release to allow for a physical product verification); the Solution sub-type permits alternation and final selection of a resolution to the problem; the Change Order sub-type allows full maturity business objects to be published (such as a Production Engineering
Release in BOM). The Use Case examples will provide a comprehensive look at how these objects are configured and used to meet business needs. We believe that the three key sets of business documents are Problem, Solution, and Change. Each will be described in subsequent sections.
Business Documents Issue Issue Concern Problem Solution Change Order Change Order WERS AVBOM/CMF Changes that require validation Verification artifacts
is a is a is a identifies
Investigation Problem Report Set of Possible Solutions Statement of Change Points to business objects Points to external documents Concern
identifies is a identifies
Solution
modeled by is a
modeled by
Solution Change Order

identifies
Problem Issue
Change
Points to business objects Point to Change (s)

identifies
Points to durable hierarchy Points to Problem (s) Has workflow Has Approvals Point to Problem (s) Has Collaborations
with
identifies

identifies
Has Approvals
Business Documents
Issue Issue
Notice Change Order
WERS AVBOM/CMF
is a
is a
is a
Problem Report
Statement of Change
5.4.1 Problem
A Problem object would have at a minimum the following general properties: An owner A description of the problem
A creation date A set of workflows to communicate, approve, and request resolution of the problem A way to link the problem to a set of business objects that are related to the problem (for instance for BOM this might be the parts and usages) A way to link the problem to one or more solutions and/or changes
Business Documents
Issue Issue
Notice Change Order
WERS AVBOM/CMF
Changes that require validation Verification artifacts
is a
is a
is a
identifies
Investigation Problem Report Set of Possible Solutions Statement of Change Points to business objects Points to external documents Concern
identifies is a identifies
Solution
modeled by is a
modeled by
Solution Change Order

identifies
Problem Issue
Change
Points to business objects Point to Change (s)

identifies
Points to durable hierarchy Points to Problem (s) Has workflow Has Approvals Point to Problem (s) Has Collaborations
with
identifies

identifies
Has Approvals
As suggested in the figure, we go back and consider to what extent an issue identifies a solution.
Issue Business Documents Issue Problem
Concern
WERS AVBOM/CMF
is a
Problem Report
Change
Request
modeled by is a identifies
Issue
Problem
Point to Change(s) Point to Problem(s) Has workflow Has Approvals Has Collaborations
with
identifies
Circle Of Friends
Change Request identifies an agreement to resolve from the perspective of the happy path. Its acceptance reflects our intention to address the problem.
5.4.2 Solution
A Solution would have at a minimum the following general properties: An owner
A description of the solution A creation date A set of workflows to communicate and approve the solution A method to link the solution to the set of business objects that are related to the solution (for instance for BOM this might be the parts and usages), and to identify projected impact A method to link the solution to a set of change objects that are related to the solution, that will be used to formally publish the updated business objects (for instance for BOM this might be the parts and usages) Also, It is not the Solution itself that is updating the business objects; rather it is the associated Change Order(s) or Investigation(s) that are updating business objects. A method to link alternate solutions , and then to identify the final solution that has resulted from evaluation of the alternatives
5.4.3 Change
A Change would have at a minimum the following general properties: An owner A description of the change A creation date A set of workflows to communicate and approve the change A method to link the solution to a set of business objects that are related to the solution (for instance for BOM this might be the parts and usages), that will be used to formally publish the updated business objects. A method to link coordinated changes in order to ensure that appropriate implementation actions are taken
5.4.4 Solution and Change super-object

There is a great deal of similarity between the solution and change properties. Even though Solution and Change are separate pink items (business documents), we are going to model them as a single system super object (yellow items).
This (at least at a conceptual level) will be represented by a super-object which is then specialized as either a solution or a change. The following properties appear to be common An owner A description A creation date A set of workflows for communication and approval A method to link the super objects A method to link the super objects to business objects A method to allow individuals to subscribe to a change object, either by becoming a member of a circle of friends, or by attributes of the change, such as product, CPSC, PAF, etc. A method to allocate a set of individuals to a change object who will be informed of changes at appropriate points in the publication lifecycle A method to determine a set of business rules that govern change objects belonging to certain classes, such as Products, Programs, etc. These rules would then enforce business process, such as requiring that a Concern be raised if a change is required on a Program that is past <PSC> for example.
5.4.5 Flexibility; Configurable Business Rules

Provide flexible change management approaches that apply to both early and post<FDJ> BOM management, as well as demonstrating a capability to extend to other domains, such as Product Definition, CAE, CAD etc. Flexibility needs for PoC solutions include: Data attributes change with context Some attributes are relevant at different points in timeline/lifecycle. Consider: absence, presence, validation rules, maturity. Data relationships change with context
Example: Early in program, I may not know value for an attribute. Later in program, I expect that attribute and will use it as a foreign key in a relationship (IT technical implications).
Business Process rules change with context
Example: Before <FDJ> you don't need to raise a Change Request, you can just create a Change Object. This would ideally be scripted in a rules engine that the business could manage. The context for these business rules could be "anything" (e.g., program milestone, part material). Business content (attributes) may be driven/valued based on rules.
Example: If this change is over $50k of investment or over $x of variable price increase, then it must be signed off by Chief Engineer of engine. Using a set of rules to fill in rest of data in that it determines how it should be routed for review and approval.
Notes on Flexible Data Attributes from Todds Notes : CM Strategy Review and Alignment with Architecture.
Flexible Data Attributes

We need to investigate the trade offs. AGF sees this as largely applying to change objects, not the domain objects.
Maybe we allows nulls and less constraints early in a program. Maybe we agree that certain queries/filters/actions that rely on those attributes are not supported at certain points in the program, whereas they are allowed later in the program when the attributes/relationships/keys of interest are populated. Potential Agreement on constraints: Only attributes that will not be indexed could be "flexible" in this way. We have 25+ years of CM experience with WERS, so we can rely on that to discern what element are likely not to change (stable) in the BOM change management domain.
6. Use Cases
6.1 Interaction of Version, Status and Maturity in the BOM
TBC
6.2 Use of Investigation and Solution in Change Management

TBC
6.3 Small Change in a Plant

TBC
6.4 Cross-Vehicle Change

TBC
6.5 Use of the Impact Assessment and Traceability in Change Management

In this Use Case we look at the Engineering Change process. We consider a change that affects three parts, for which the engineer is tasked with developing a range of solutions. For each solution an Impact Assessment is made, and the results of these are used to determine and approve the optimal solution. The solution is then developed, and verified, and then a detailed Engineering Change Order is prepared. The Change Order is then approved. Part of this process is to trace the final Design solution and its Impact against the prior approved Change Request, in order to ensure that any deviations are agreed to as part of the approval phase of the Change Order.
Figure 18 Use Case - Engineering Change Management
CR1
Note that CR to Solution relationship can be M :N. A given Solution may be related to more than one CR.
Solution C Solution B Solution A
F
Cost Weight Strength Temp
Impact Analysis details: Should certain impacts such as Cost and Weight be performed in the Change Management tool itself instead (e.g., CMF prototype ) of in the domain systems?
CR2
Add PtA Delete PtB Change PtC
Impact Assessment B&C
B
Impact assessments performed in domain specific tools with domain-specific knowledge. Tool examples: Nastran, mainframe.
Change Order
R
Impact Analysis might be captured as PDF, HTML, or.?
Will we store a complex tradeoff matrix for integrated Impact Assessment? Attach rendering to Change Order ?
Note: Same figure page 46 to be confirmed it should be removed because it appears in an earlier section.
6.6 Embedded Software Change

In this Use Case we consider a change to the PDL where two existing product capabilities that were offered separately are now to be made available together. The process flow is shown diagrammatically below in Figure 19.
Determine Changed Embedded Software Reqt Determine Changed Part Variation Requirement Release New Part Variant to Prototype Verify New Part Variant Load New Software in Prototype Part
Change Product Direction Letter
Change Software Configuration
Change Order Guide
Develop New Software Load
Update Broadcast Specification Produce New Product Verify in Production Release New Software to Production Notify Dealers Update Service Instructions/ Catalog Release New Part to Production
Figure 19 Use Case - Embedded Software As a result of the PDL change the responsible engineer determines that the embedded software in the product will need to be changed; there is also a requirement to update the order guide to support the revised feature availability. The engineer updates the software configuration, and as a result it becomes apparent that a further part variant will be required, that supports the vehicle build when both features are ordered together. The engineer develops the new software load and releases a new part number, with appropriate usage to support the prototype build. The new prototype part is created with the updated software, and the new part is verified. Upon successful verification of the prototype and the publication of the revised order guide the broadcast specification is updated. Further, finalization of the verification process initiates the release of the new part to production, as well as the release of the software. These actions permit the verification of the production process, as well as the update of Service Instructions and Catalogs. Service Instructions and Catalogs tend to reflect engineering release/intention, not necessarily exact time that manufacturing implemented the change. Service will more accurately reflect mfg when a recall is donesince we must be robust about handing a recall. Final steps are to notify dealers of the changes and commence production. Note: this process flow is simplified for the purposes of this document; other more detailed aspects will be included in further use cases.
We will now break the use case down into 3 subsets (A, B, & C) and examine the key information constructs at each step.
A
Determine Change Embedded Software Reqmt Change Product Direction Letter
B
Determine Changed Part Variation Requirement Release New Part Variant To Prototype Load New Software In Prototype Part Verify New Part Variant
Change Software Configuration Change Order Guide
Develop New Software Load
C
Produce New Product Verify in Production
Update Broadcast Specification
Release New Software to Production Notify Dealers Update Services Instruction/ Catalog
Release New Part to Production
Figure 20 Embedded Software Use Case Divided into Subsets
6.6.1 Managing the Feature Configuration (Subset A)

The first step in the process shown in Figure 21 Embedded Software Use Case - Subset A is to issue a change to the Product Direction. For simplicity's sake we will assume that the Product Direction and the Product Direction Letter (PDL) are synonymous. We form a second version of the PDL, the prior version being available so that in a collaborative environment consumers who are working to the earlier version can continue to use it. We show just the configuration of the two Features F1 and F2; note that the combination where both F1 and F2 are 0 is not valued i.e. at this point in the program lifecycle it is indeterminate, we neither force it to be present nor to take a value. At some later point a business rule may require it to be present and valued. In the example we change the last row from a value of F, False, to a value of T, True. In other words, the features F1 and F2 may be offered on the product in combination. Our assumption based on the Software Modules table, is that each Feature requires two software modules to fulfill the required functionality, so Feature F1 for instance would require that both software module 1 and module 2 be installed in the product.
A
Change Product Direction Letter
Determine Changed Embedded Software Reqt
Change Software Configuration
Change Order Guide
Product Direction Letter V2.0 F1 V1.0 Product Direction Letter F1 0 1 1 0 F2 11 01 1 F2 1 T0 T1 F T T T Software Configuration V1.0 Configuration 1 2 Module 1,2 3,4
Software Configuration V2.0 Configuration 1 2 3 Module 1,2 3,4 1,2,3,4
Software Modules V1.0 Module 1 2 3 4 Feature F1 F1 F2 F2
Figure 21 Embedded Software Use Case - Subset A
Based on the valid feature and module to feature configurations, we see the need for a third software configuration. We therefore add a new row to a second version of the table Software Configuration V2.0.
6.6.2 Managing the Prototype Part requirements (Subset B)

Having taken care of the release of the new Software Configurations we turn our attention to the management of the Prototype Part Requirements, as shown in Figure 22. In this use case we have assumed that the software is to be loaded into the control module part offline, and delivered to the plant with a unique part number for each Software Configuration. Previously two Parts, A, and B were released at P (Production) level Maturity. We now see that a third Part, C is released; this is for verification purposes only at this point in the life-cycle, it is therefore released at U (Unauthorized) Maturity. In addition to managing the parts, we also see that new software that combines Modules 1 4 in a unique load is developed, and this is made available for loading into the prototype parts required for verification.
B
Software Modules V1.0 Module 1 2 3 4 Feature F1 F1 F2 F2 Develop New Software Load Load New Software in Prototype Part Determine Changed Part Variation Requirement Release New Part Variant to Prototype Verify New Part Variant
Software Configuration V2.0 Configuration Software Configuration V1.0 Configuration 1 2 Module 1,2 3,4 Bill of Material V2.0 ECN: 0003 Part Bill of Material V1.0 ECN: 0002 Part A B Usage F1 AND F2* F1 AND F2 Maturity P P Effectivity In: Job 1 In: Job 1 Configuration 1 2 A B C Usage F1 AND F2* F1 AND F2 F1 AND F2 Maturity P P U Effectivity In: Job 1 In: Job 1 In: VP8 Configuration 1 2 3 1 2 3 Module 1,2 3,4 1,2,3,4
F1 = NOT F1
Figure 22 Embedded Software Use Case - Subset B
6.6.3 Managing the Production Part Requirements (Subset C)

The final steps in the process require that the Part, now that it is verified, is released at P Maturity. In order to manage this new Software Configuration/Part downstream the Software load is made available, as well as the revised Order Guide, Broadcast Specifications (Codes), and Service Catalogs/Repair Instructions. These are verified for accuracy, completeness, and manufacturing/service process compatibility. Once this is established Dealers are notified, and the new product configuration is launched.
Change Order Guide
Order Guide V2.0 Order Guide V1.0 F1 F1 0 1 1 0 F2 11 01 1 F2 1 T0 T1 F T T T Notify Dealers Update Service Instructions/ Catalog Produce New Product Verify in Production
Update Broadcast Specification
Release New Software to Production
C
Bill of Material V2.0 ECN: 0004 Part Bill of Material V2.0 ECN: 0003 Part A B C Usage F1 AND F2* F1 AND F2 F1 AND F2 Maturity P P U A B Effectivity C In: Job 1 In: Job 1 In: VP8 Usage F1 AND F2* F1 AND F2 Configuration F1 AND F2 1 2 3 Maturity P P P Effectivity In: Job 1 In: Job 1 In: Job 1
Release New Part to Production
Configuration 1 2 3
Figure 23 Embedded Software Use Case - Subset C
6.6.4 Business Architecture Use cases for POC 6.6.5 Design a Flexible Function 6.6.6 Audit a change to a Business Object 6.6.7 Execute a Flexible Function 6.6.8 Determine the lifecycle process state for a set of change requests
7. Change Management in Different Domains

Each domain will select the appropriate set of constructs and methods. The following tables, which show the key information entities, change constructs, and methods, provide an initial suggestion for a number of the key domains in the Industrial Backbone.
7.1 Bill of Material

Bill of Materials (BOM) is the most pervasive information artery in Ford Motor Company; it drives Engineering, Manufacturing, Supply, and Service. Without BOM information, the company would not be able to operate. With so many functions relying on BOM information, for so many purposes, it is not surprising that multiple overlapping, function-specific BOM tools have evolved. Despite the drive to satisfy these niche BOM requirements, the underlying BOM concepts and information constructs employed remain common across the fragmented BOM solutions. The specific information entities that define the BOM are identified below. Note: This is not a structured table, and repeating entitles such as CPSC are shown once.
INFORMATION ENTITIES #
1 2
Entity
Part ID Part Number (Engineering)
Key Structure
Numeric (38) Alphanumeric 6-8-8 (Info Std FAP 3-145A)
3 4
Part Number (Manufacturing) Part Number (Service)
Alphanumeric 7-9-8 Alphanumeric 6-8-8 Note: FINIS Code is a Numeric(7) alias
Line of Usage ID
Numeric (38) Business Key: Effectivity Stream, Feature Condition, Quantity, Effectivity (In), Maturity, Owning Activity
INFORMATION ENTITIES #
6
Entity
Feature Condition
Key Structure
Alphanumeric 17 Fixed + 200 Variable (WERS and BOMF) Numeric 5 (CMMS SFI) (Partial Info Std Vehicle Class Data Set)
Quantity
Numeric, plus some Alpha for Unit of Measure(AR, RF etc.) Alphanumeric 17 (WERS and BOMF) Date (CMMS)
Effectivity
Maturity
Alphanumeric 1 (WERS and BOMF) (Ordered Set (U, S, F, T, P)
10
CPSC
Numeric 2-2-2 (Info Std CPSC Code) Occurs at Line of Usage ID and Assembly ID
11
PAF
Alphanumeric (10) (Info Std PAF Code) Occurs at Line of Usage ID and Assembly ID
12
Assembly ID
Alphanumeric (38) (Part ID) Business Key: Part ID, Quantity, Maturity
13
Plant
Alphanumeric 5 C (Info Std GSDB Code)
INFORMATION CHANGE CONSTRUCTS #

1
Entity
Part ID
Constructs used to manage change

Version Status Change Order The Part number is the business key of Part ID Attributes managed by Snapshot early in the lifecycle, transitioning to full Version, Status, Change Order.
2 3 4
Part Number (Engineering) Part Number (Manufacturing) Part Number (Service)
This could be managed using the Snapshot technique, however as it is a Business Key it would be more robust to manage using full versioning Version Status Change Order*
5 6
CPSC PAF
Managed by Snapshot early in the lifecycle, transitioning to full Version, Status, Change Order.
7 8 9 10 11
Line of Usage Feature Condition Quantity Effectivity Maturity
Version Status Change Order* Attributes managed by Snapshot early in the lifecycle, transitioning to full Version, Status, Change Order.
INFORMATION CHANGE CONSTRUCTS #

12
Entity
Assembly ID
Constructs used to manage change

13
Plant
Change Order*: The use of the Change Order is business process controlled, probably not present during the early part of the lifecycle
INFORMATION CHANGE METHODS #

1 2 3 4 5 6 7 8 9 10 11
Entity
Part ID Part Number (Engineering) Part Number (Manufacturing) Part Number (Service) Line of Usage ID Feature Condition Quantity Effectivity Maturity CPSC PAF
Method
Part ID is primary object identifier Part Numbers are considered to be solely nomenclature, however their continued use as a Business Key is likely to persist internally to the Enterprise as well as within the extended Enterprise (Suppliers, Dealers etc.) Line of Usage ID is primary object identifier These attributes form the Business Key of the Line of Usage. Early in the lifecycle of the object they can be changed without changing the Object ID.
These two fields form part of the Instance definition of the Final Assembly, but are purely attributes of the Component Next Assembly relationship. However the BOM assembly structure is flat, and there is no hierarchy implied by CPSC, so technically it is still an attribute of the Final Assembly. Part ID is the primary object identifier of the Assembly ID, and provides the structure definition via the Next Assembly relationship managed there. Source and Use Plant identify the Supply Chain relationship. The Use plant identifies the Plant BOM Structure, and is managed appropriately.
12
Assembly ID
13
Plant
8. Glossary
Term Alternative Definition Equivalent of the set of possible solutions. Work on an object proceeds as a single linear sequence of versions, however, in some situations, it must proceed in parallel on more than one direction at the same time. When parallel development is required, a new path for the object is created and a new version emerges. This version exists as one branch option that can be pursued. A method to link alternate solutions, and then to identify the final solution that has resulted from evaluation of the alternatives. A classification of Change Objects. What is being done to fix a problem. Typically, the action results in an Investigation, Solutions, or a Change Order. Three sub-types are Change Order, Investigation, Solutions. See Figure 16 Change Management Object Types. Refers to the change management mechanism /container /coordinator, not the various domain objects that are being changed. As a sub-type of a Change, it is a document used to manage the business change process in order to record and promulgate problems; to enable requests to change business entities, and the changes to the entities themselves . Two other documents, Issues and Change Requests, also are used to provide an identical benefit. Problems have two subtypes (Change Requests, and Issues). See Figure 16 Change Management Object Types. A document used to manage the business change process in order to record and promulgate problems; to enable requests to change business entities, and the changes to the entities themselves . Two other documents, Issues and Change Orders, also are used to provide an identical benefit. Problems have two subtypes (Change Requests, and Issues). See Figure 16 Change Management Object Types.
Alternation
Change
Change Object
Change Orders
Change Requests
Term Conceptual Architecture
Definition Applicable to "any domain" generalization by indicating the target is changes to items part of the Industrial Backbone (e.g., not for HR change management). The concept states this will not necessarily be implemented in one system. There should be one set of concepts, and the concepts are mastered/owned by the Change Management Foundation "system." An important construct that identifies when in time information is valid, or is to be consumed. It provides a correlated view across many domains of information; however it alone cannot sustain a threaded view of causation. Both types of Effectivity, Design and Implementation, are required for full reconstructive capability of historical records. An object that links multiple changes in order to control their synchronous behavior. Providing a linked Grouping Object suggests that two or more objects should be updated together, and related to some formal change document. A dynamic attribute of a business object that is systematically derived from its contents . The list of values and the algorithms to calculate them are specific to the object type. Action due to critical business practice and a need for a strong firewall to distinguish between action that is/is not intended for P (production) authority. Action taken by this course cannot be released by a production authority. It is also a sub-type of a Change. See Figure 16 Change Management Object Types.
Effectivity
Grouping Object
Indicator
Investigations
Issues
A document used to manage the business change process in order to record and promulgate problems; to enable requests to change business entities, and the changes to the entities themselves . Two other documents, Change Requests and Change Orders, also are used to provide an identical benefit. Problems have two subtypes (Change Requests, and Issues). See Figure 16 Change Management Object Types.
Term Maturity
Definition A contextual object-by-object construct; there is no consistent global set of values applicable to all objects through time. Rather, there is a set of values for each object; sub-types of objects would most normally inherit directly from the object. Also, it defines how far through its lifecycle an object is, usually by reference to the use that may be made of the information in its current state. Based on business architecture, Problems have two subtypes (Change Requests, Issues) and Changes has three subtypes (Change Order, Investigation, Solution). Problems and Changes are not necessarily subtypes of the overall concept Change Objects. A classification of change objects. two subsets are change requests and issues. In many instances the Change Request is extended to include a statement of potential answers to a problem, as well as a recommendation or agreement to the final action taken. It is also a sub-type of a Change. See Figure 16 Change Management Object Types. As a indicator or flag, which takes values (Work in Progress, Published, and History) used to establish which particular record is now current, and which has passed into history. Unlike a version, it generates a distinction between what is current, and what is now being worked on and will eventually become the current record. This allows management of multiple versions of an object explicitly, and avoids ambiguities in interpreting records. A discrete unit of change that can be identified, tracked, configured and retained. As information changes through time, it must be managed and coordinated as useful information. In levels of maturity, when the next version of an object is created, it will default to the value of the prior version of the object, but may be increased per the business process , so the next published version might be raised to the next unit of change.
Object Types
Problems
Solutions
State
Version

ChangeManagementStrategyV0.5 Final

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ChangeManagementStrategyV0.5 Final

Hochgeladen von

Copyright:

Verfügbare Formate

Change Management Integration Strategy

A requirement for the integration of Ford Systems

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

2. Introduction 3. Definition and Nature of Change Management

4. Recommended Approach for Integration

5. Change Management Objects

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

7. Change Management in Different Domains 8. Glossary

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

1.2 Document Reference

1.3 Summary of Changes

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Definition and Nature of Change Management

Ready for review

Recommended Approach for Integration

Impact Assessment and Traceability Change Objects

Software use case ready for review Complete

Change Management in Different Domains TBD TBD

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

3. Definition and Nature of Change Management

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

3.1 Scope of this document

Figure 1 Change Management Implementation Scope

3.1.1 Concept Ownership

Also, CMF (Change Management Foundation) is the master/owner of CM business

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

3.2 Key Components of the Architecture

3.2.2 Single Conceptual Model

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

4. Recommended Approach for Integration

4.1.1 Information Change using Versions and Snapshots

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

4.1.2 Managing Multiple Objects

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Change Object Engineering Change Order

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Current Published Record

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy

Alt B of Object Ceased further development on this path

Figure 6 Different View of Object (Part) Maturity

Version: 0.5 Revision Date: 01/09/2013 Retention Period: S+12

Change Management Integration Strategy