Product Lifecycle Management in Defense Organizations: Challenges and Opportunities

Transcription

1 Lifecycle in Defense Organizations: Challenges and Opportunities Thomas Gulledge, President, Enterprise Integration, Inc. and Professor Emeritus, George Mason University Wael Hafez, Senior Enterprise Architect, Enterprise Integration, Inc. Raj Iyer, Deputy Chief Technology Officer, U.S. Army Materiel Command John Nyere, Special Assistant for Supply Chain Systems, Office of the Secretary of Defense, U.S. Department of Defense Keywords: Lifecycle, Weapon System Lifecycle, Improvement, Program Support Abstract Lifecycle (PLM) presents many unique challenges in defense organizations. These challenges relate culture, organization, processes, data, and others. While some of these characteristics are not unique to defense organizations, some are specifically unique. This paper identifies and describes the challenges, and then presents an approach to requirements definition and solution design that addresses the described challenges. A closed-loop PLM model requires that the government take ownership of the product, post production, and assume every aspect of product support. This would include supply, procurement, maintenance, operations, engineering, configuration and fleet management functions. Introduction Lifecycle (PLM) in defense organizations presents a special set of challenges. The challenges are not directly related to the capabilities of PLM systems, but to unique characteristics of defense organizations. Defense organizations are typically decentralized, and acquisition practices are different across defense organizations. Even in defense organizations where acquisition policies are legally sophisticated, there is significant variability on policy implementation. In some cases product data is acquired, and in other cases it is not. The standards for product data are not consistent across defense organizations, and data quality is always problematic.

2 The organizational structure in defense organizations is also a challenge for PLM. Defense organizations are organized by stovepipes. In most cases, Acquisition is one stovepipe, and logistics is another; and in many cases this artificial division is a formidable management boundary. data is procured by acquisition experts in weapon system program offices, which are part of the Acquisition stovepipe. Weapons system sustainment is managed by logistics experts, which are part of the Logistics stovepipe. Weapon system product improvement (configuration and change management) is executed via business processes that flow across the stovepipes while interacting with the Original Equipment Manufacturer (OEM). In addition, equipment is deployed. In the field, operational readiness is the prime concern. Military personnel often reconfigure assets to optimize readiness in an environment where configuration control is minimal. Field as-maintained bill-of-material requirements are obviously different than those in an institutional depot. So, many organizations are involved, including deployed organizations, national sustainment organizations, acquisition organizations, policy organizations at multiple levels, defense agencies, research & development organizations, and the OEM. In the private sector, the artificial division between engineering and manufacturing is often cited as an impediment to successful PLM implementation. The usual approach to addressing the division is to argue for top-down executive stewardship to ensure business process standardization across the stovepipes. We argue that the situation is even more difficult to manage in defense organizations, since it is not even clear who would provide executive stewardship across the complexity. With so many organizations involved, and with a legal wall between policy and operational organizations, management of a PLM solution is a challenge. Never-the-less, out task is to devise an approach for defining and designing PLM solutions for defense organizations. We advocate the development of a defense PLM reference model that can be tailored to individual organizational requirements. The tailored customer-specific reference model, in our terminology, is called a solution. This solution defines the requirement for implanting processes, systems, and organizations structures for the successful implementation of PLM in a defense organization. The paper provides an overview of the characteristics that must be included in a PLM reference model for a defense organization. It also provides a description of an approach for transitioning from a vision, to a reference model, and on to a solution. We also discuss our strategy for completing the solution for a large defense organization. PLM and Weapon System Lifecycle Lifecycle is the process of managing the entire lifecycle of a product from its conception through its disposal. PLM is a strategic approach for

3 Repair Notification Transportation s Transportation & Distribution Planning & Preparation Asset Configuration Field Supply Work Status Work Order Engineering Drawings Configuration Change Configuration Asset Configuration Acquisition Design Specifications Data Personnel & Organization Personnel Data Control Execution Asset Configuration End Item Asset Data Supply Financial Financial Control Data Data Repair Item Transportation & Distribution Supply Field Supply Line Asset Configuration Asset Collaboration and Analytics Engineering Drawings Acquisition Asset Condition Sustain Deployed Operations Repair & Overhaul End Item Asset Data Design Specifications Supply Inspection & Quality Assurance Completion Transportation & Distribution Line Engineering Drawings Environment, Health and Safety Transportation s Transportation & Distribution Line Personnel s Data Personnel & Organization Repair & Overhaul Financial Control Data Financial Quality Force Planning Mission Informatiopn Direct Support to Operations s Planning MRO Field Line Force Planning Logistics Plan End Item Asset Data Demand Plan Acquisition Contract Supply Chain & Procurement Financial Control Data Financial Field Supply s Planning MRO Repair & Overhaul Supply Order Command and Control (C2) Deployment Plan Line Force Planning Plan Plan End Item Asset Data Inventory Shipping Information Transportation & Distribution Demand End Item Asset Data Supply Chain & Procurement Financial Control Data Financial Contract Acquisition Hazardous & Special HAzardous Order Order End Item Asset Data Inventory Shipping Information Transportation & Distribution Hazardous & Special HAzardous implementing business processes that are enabled by information systems and technologies. In general, successful implementation of the definition requires horizontal integration (Gulledge, et al., 1999) as opposed to stove piping functions into disassociated processes or systems. Hence, enterprise PLM is a requirement for maintaining alignment to the product model. Furthermore, horizontal integration is extended to customers, partners, and stakeholders; therefore, information sharing relative to business process interactions is critical; independent of geographic location. A typical weapon system sustainment lifecycle for ground equipment is depicted in Figure 1. Notice that PLM processes are a subset of the weapon system lifecycle management processes. Lifecycle is a Subset of Weapon System Lifecycle OV Supply National Supply 1 OV Field Line 1. Asset turned in for Repair Field 3. Execute Work Order 10. Replace Carcass Part 12. Close Work Order Level 1/ Process Area 7. Order Carcass from National Supply 5. Order Carcass from Field Supply 7 Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area 3/18/ :37:11 PM 2. Create Work Order 2 OV Level 2/ Main Process Level 1/ Process Area 3/18/ :21:39 PM Level 1/ Process Area OV Field Supply /18/ :49:20 PM Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area 8 6. Check Inventory Transportation View Asset Configuration and Drawings 9. Shipping of Carcass to Supply Unit Level 2/ Main Process Level 1/ Process Area 3/12/ :04:30 AM 11. Update Asset Configuration Field Supply PLM is One Segment Of the Weapon System Improvement Process 8. Shipping of Carcass from CONUS to Theatre Figure 1: PLM and Weapon System Sustainment For defense organizations to implement enterprise PLM, the government would require all intellectual property developed by an OEM and its multiple tiers of suppliers in designing, manufacturing and introducing the item. Such information would include product models, technical data packages, bills of materiel, technical documents, drawings, specifications, mechanical models, electrical models, two dimensional design files, outline drawings, engineering materials, process documentation, tooling design, routings/work instructions, qualification data, mechanical and electrical inspection procedures, fixture design, system engineering data, parts catalogs, simulation data, reliability test and quality data, training documentation, repair documentation, inspection and test data, installation drawings/procedures, and more. In the defense

4 environment, this full set of information is generally not available, and in many cases not even purchased from the OEM. In order to assemble all of the required information to execute lifecycle management for a military asset, the defense organization would require precisely the right information from the product developer. The government would need to specify the information it needed as well as the format in which the data must be delivered. This is an extremely critical task that can, if done wrong, fracture the utility of the data acquired. Furthermore, once the data is acquired, the government would have to jointly maintain weapon system configuration management with the OEM. The complexity of such an endeavor is significant, but this is precisely the environment in the defense organization. The government acquires the product in a government program office in the acquisition organization. The OEM manufactures the product, and is responsible for PDM/PLM inside OEM organizational boundaries. The government is responsible for sustaining the product in a number of internal government organizations. Furthermore, engineering change processes are constantly executed between the OEM and the government, and product configuration is constantly changing in the fielded assets. The PLM solution must be integrated with the complete sustainment solution, and the sustainment solution must be aligned with Acquisition processes and OEM processes to enable the complete weapons system lifecycle. The requirements for such a solution cannot be documented in descriptive documents or summary tables. Given the complexity, a model-based requirements definition and management approach is required. A Defense PLM Solution Definition Approach Our approach to defining a solution requires high-level scoping, cognizance of private sector best practices, and a tailoring of the model to the defense environment. We evolve a concept into a solution by leveraging a PLM reference model that we are developing from commercial open sources. Using the reference model as a guide, our strategy is to develop the solution, align data, and eventually produce an implementation roadmap. The process is depicted in the following figure.

5 To be Developed To be Developed Scoping the AMC PLM Solution (The Definition, Discovery, and Analysis Phases of s ) AMC Vision and Strategic Priorities PLM Best Practices Reference Models Places Vision and Priorities in an Organization Model AMC View PLM PLM is one Business Process in the View Defines the Desired PLM End -State Solution for AMC AMC PLM Solution SCOR/DCOR Metrics PLM Implementation Roadmap SCOR/DCOR Models are the Measurement Frameworks that Measure Design and Supply Chain Performance Project Plans for Individual Initiatives The Implementation Roadmap cannot be defined until the Desired End-State is Defined Best Practices are the Guides for Designing the AMC PLM View Data Framework Defines Data Processes and Enables Data Governance for the Materiel Enterprise Figure 2: Defining a PLM Solution for the U.S. Army Materiel Command (AMC) In the case where the government assumes control of product lifecycle management responsibilities, there are many stakeholders performing a myriad of tasks. But to be effective, all of the information related to the different tasks must maintain alignment to the product model. This paper describes how we define the requirements, design the solution, and how we propose to maintain alignment to the product model. Characteristics of a Defense PLM Reference Model A Reference model is one or more pre-engineered and integrated organizational views. For example one type of reference model might be a business process (one view of an aspect of an organization) and a depiction of the data flows (another view of an aspect of an organization) that are aligned with the business process. Enterprise software either implicitly or explicitly executes pre-defined but configurable business processes; hence, by definition such software is based on the reference model concept. The main benefit of a reference model is that certain tedious views (e.g., the data view as realized in a data model) do not have to be individually developed for every implementation. The idea is to design and develop once, and then refine and replicate many times. The reference model may have to be tailored for individual organizations, but this effort is significantly less than approaching each solution as a new project. Additional discussions of the reference model concept are provided by Gulledge (2008).

6 The reference model concept is particularly critical for PLM implementation projects. Successful PLM implementation involves defining standardized business processes that can be configured in commercial software products. People naturally resist the process of standardization, so up-form agreement on the structure is a solution is a critical success factor for successful implementation. A reference model is one mechanism that can be used as a first step for converging on an agreed solution. In effect, the reference model is a starting point for evolving the particulars of a solution. In this case the reference model represents one way that PLM might be implemented, perhaps under ideal conditions. Since every implementation environment is different, the reference model must be tailored into a customer-specific reference model (i.e., a solution), which is the requirements definition model for implementing a PLM system. This section describes many of the particulars that must be included in a PLM reference model that conforms to a defense organization and its extended enterprise. To our knowledge, a reference model for defense PLM does not currently exist. We assert that defense PLM is sufficiently different from commercial PLM, so a defense reference model is justified. Still commercial reference models can be used as best-practice guides when developing the defense model. These relationships are depicted in Figure 2 above, where we show commercial reference models as providing input into a defense model. Our strategy in this section is to define the characteristics of a defense PLM reference model for defense, leveraging characteristics from private sector best practice. In simple terms, PLM is a product centric engineering and business environment. It is also a strategy for intellectual property management, content and knowledge management from the receipt of a requirement, the creation of knowledge, updating the knowledge and sharing it. It should connect all of the product s stakeholders over the lifecycle of the product throughout the Lifecycle in Figure 3. In a defense environment, this connection almost never occurs, which is one distinguishing characteristic that must be addressed in a defense solution. The Lifecycle Planning Planning Concept Concept Definition Definition Development Development Introduction Introduction Support Support Figure 3: A Typical Lifecycle PLM effectively is the union of CAD (Computer Assisted Design) and Data processes and tools. It spans both the design chain (New Development (NPD) and change), the supply chain and manages the requirements

7 which lead to product definition, development, introduction and support. PLM, while a standalone capability, intersects with business processes to include: order to product delivery; marketing, sales, disposition, production, product introduction and customer support. Why is PLM so critical? Most products (e.g. automotive, aircraft, ships, and weapon systems) are highly complex -- both to develop, design, manufacture and sustain. In producing items, manufacturing delivers different variants as product improvements are applied to the product over time. In both the defense and global environments, products are produced to meet the local, national, or customer requirements. Similarly, when applying engineering or component changes to existing products, the as configured (maintained) product can have countless variants. In defense organizations, particularly in Repair and Overhaul (MRO) activities worldwide, not having the proper as configured product results in the following waste: 1) having to physically inspect a product to ensure the exact configuration, 2) ordering the wrong parts, 3) maintaining the wrong parts, and 4) using the wrong work instructions. All stakeholders should be cognizant of the variant that they own, operate, maintain, or provide as a service. Many defense organizations have implanted integrated standard software systems (i.e., ERP), and one would think that these commercial products would alleviate some of the data sharing problems. However, the problems continue to persist, partially because: The Enterprise is not correctly defined (Borek, 2007) Defense organizations employ terminology not associated with commercial PLM practices Defense organizations have fractured PLM-related business processes and the overall business with outdated information technologies There are very large fleets in defense organizations; e.g., in some cases more than two hundred thousand light and medium trucks with a multitude of variants and ineffective configuration management. Missing or low quality product data (BOMs, Item Masters, Catalogs and Routings) So what product data does a defense organization need? Figure 2, taken from Borek (2007), illustrates that a specific set of product data are needed to perform various business processes (the columns), using as an example an RF composite structure on a combat aircraft. Outlined in red are the data needed in a specified format to perform one process - engineering change.

8 MAKE & DELIVER MAKE Data s data requirements (in this case an RF Composite Structure for an aircraft) are determined by business process OEM Repurchase Engineering Change Second Source Repaint Remanufacture/ Repair Composite Repair RF Window Replace Inserts Application Engineering Data Specifications Y Y Y Y Y Y Y Word Mechanical Model Y Y Soldworks/Ansys Electrical Model Y Y HHFS/Proprietary 2D Design Files Y Y Y Solidworks/ACAD Outline Drawings Y Y Y Y Y Y Y Solidworks/ACAD Engineering BOM Y Y Y PDM Formatted Text Engineering s Y Y Y Word/Acrobat Manufacturing Data Process Documentation Y Y Y Y Y Word ion BOM Y Y Y Y PDM Formatted Text Tooling Design Y Y Solidworks/ACAD Routers/Work Instructions Y Y Y Y Y Word/PDF ion s Y Y Y Y Word/PDF Quality Data Qualiification Data Y Y Y Y Word/PDF MFG inspection procedures Y Y Y Y Y Word/PDF Future Designs Y Y Y Y Solidwords/ACAD Electrical Test Procedures Y Y Y Word/Acrobat Test Facility Setup Y Y Y Word/Acrobat/Visio Inspection/Test Data Y Y Y Access Installation Data Installation Drawings Y Y Y Y Y Y Y Solidworks/ACAD Procedures Y Y Y Y Y Y Y Word Figure 4: Aircraft Structure Aligned with Business Processes (Borek, 2007) Looking at the above matrix, given a single component, one can see what data may be required for the entire aircraft if the fulfillment organization owns the lifecycle (to refresh i and amend ii the product) over an extended service life. But, in actuality, the fulfillment organization only needs the appropriate product data to support its intended support concept. Consider the following examples. First, examine the simplest form with an Original Equipment Manufacturer providing a product to the military with the OEM providing contracted total logistical support. What product data would need to be provided to the government? 1. First, an as built product configuration should be provided for property accounting purposes. But once in the government s possession, the process of maintaining the product and the product s configuration must be managed in an information system, probably a government property system, for providing as maintained configuration updates as required. In addition to the as built configuration, the government should also received an item master which contains the descriptive data associated with the whole or its parts; e.g., cube, weight, disposal and information

9 related to materiel safety which are used in distribution/deployment, other property management and equipment authorization functions. As stated, in the first part of the paper, this requires joint configuration management something most defense organizations do not do. 2. The support provider (think of a commercial airlines model) won t be operating the equipment so there will be a requirement for the OEM to provide operator s manuals - no different than one s buying a car. Operators manuals will normally be linked to the actual item produced, and when the item is modified, the manuals must be updated accordingly. Operator manuals contain instructions, information, drawings and specifications so that the customer can effectively use the product or take the appropriate action to make it operational. For service/repairs the owner operator must know what to do with the inoperable equipment. 3. Last, there would need to be mechanisms in place to change the product s configuration, address deficient product, specifications, or even provide customer feedback. This is called the aforementioned amend process in the Design Chain Operational Reference-model, the corollary to the return process in the Supply Chain Operational Reference-model used by industry and software companies. In the most complex form of product support (from the government s perspective) would be the government taking ownership of the product, post production, and assuming every aspect of Support contained in Figure 1. By law, if the product is considered core under Title X U.S.C. Section 2464, the U.S. DoD must have a depot capability for the product at Initial Operating Capability (IOC) plus four years. This would include supply, procurement, maintenance, operations, engineering, configuration and fleet management functions. Doing this effectively calls for horizontal integration not stove piping functions into disassociated processes or systems hence the need for an enterprise PLM that maintains alignment to the product model and a closed loop process e.g. a product update will result in the following being changed and provided to the Supply Chain: Engineering Drawings, System Specifications, Technical Publications/Communications, Support Documentation, Parts and Items Data, Deficiency Reports, Plans, Safety Data, Operational s, Acquisition Documentation, Air Worthiness Documentation, Operational Safety Suitability and Effectiveness (OSS&E) Documentation. In assuming support, the government would need almost all of the intellectual property developed by an OEM and its multiple tiers of suppliers in designing, manufacturing and introducing the item. Such information would include product models, technical data packages, bills of materiel, technical documents, drawings, specifications, mechanical

10 models, electrical models, two dimensional design files, outline drawings, engineering materials, process documentation, tooling design, routings/work instructions, qualification data, mechanical and electrical inspection procedures, fixture design, system engineering data, parts catalogs, simulation data, reliability test and quality data, training documentation, repair documentation, inspection and test data, installation drawings/procedures, and more. There can be many different bills of materiel when the PLM spans the design, engineering, manufacture, product introduction and sustainment phases of the product lifecycle (e.g. design BOM, engineering BOM, manufacturing BOM, as manufactured BOM, as configured BOM, provisioning BOM, repair BOM, etc, each tailored to satisfy a different set of parts to do a specific function in the lifecycle of a product). Even software to support the product is included in the product s lifecycle management process. The government would need to specify not only what information it needed, but it would need to specify what format in which it wanted it be delivered (as per Figure 4). This is an extremely critical task that can, if done wrong, remove intelligence from the data acquired (a 2D drawing or a 3D?). Also, the acquiring organization must develop modern and effective contracts that do not specify archaic forms for product data. For example, in the case of the Mine-Resistant, Ambush-Protected (MRAP) vehicles, the U.S. Defense Logistics Agency was provided paper documentation (technical data packages and drawings) for the DoD Catalog /Materiel Master (the Federal Logistics Information System). In a recent aircraft carrier procurement, drawings were specified to be produced on aperture cards (which 3M has not produced a reader or printer for in over a decade). That is precisely why PLM is critical for defense organizations. In the case where the government assumes product lifecycle management responsibilities, there are functional stakeholders. In most defense organizations information is segregated into four functions which are not under integrated change control. 1. Engineering Cognizance (or Cognizant Field Activity). Cognizant Field Activity is a Navy term that includes supply and the management of the engineering functions associated with products. In this support case, many of the tasks performed originally by the integrator/oem are now performed by the government. Said a different way, Engineering Cognizance would include: research, design, integration and amend processes of the Design and Supply Chains. When we make engineering changes to a product, we must effectively communicate those changes to those who source, repair/overhaul and manage the product s configuration. We often don t. 2. Sourcing. In supply chain terms, this is the process of bringing materiel (raw materials or finished goods) into inventory. Whether it is an OEM repurchase, the ordering of a part for maintenance/repair, or qualifying a

11 second source, the right information must be available to effect obtainment of the material. To do this effectively, supply and purchasing activities must still be aligned to the product model (the variant for which we are ordering parts) and stay abreast of engineering change. The information DoD has related to supply and purchasing include: supply bulletins, catalogs, publications, item masters, bills of material, specifications, drawings (outline/installation), procedures, qualification data, tech data packages. But to bring on a second source for a major component or an actual weapon system, much more data will be required (see Figure 4) to include essentially the same information used to design, manufacture and introduce the actual item. One critical element of sourcing, which needs improvement in DoD is the catalog. 3. Maitenance/Repair and Overhaul. In supply chain terms, this is the process of bringing materiel back to specification. In DoD we have technical publications (technical (tech) Manuals, tech orders, tech bulletins) which essentially tell different levels of maintenance how to fix their item. Additionally, we have such devices as IETMs (Integrated Electronic Tech Manuals). MRO requires data that provide routings/work instructions, specifications, parts drawings, inspection procedures, installation drawings, procedures, bills of materiel, engineering materials, and process documentation, to return the item to spec. Differing degrees of tech data will be configured to meet the differing requirements for different levels of repair but again, these technical documents will need to be in constant alignment with the configured product. 4. Configuration. Configuration is the process of governing the product (revision control) and capturing the product make up. Different product configurations exist to include as designed, as built, as maintained and even an objective (to be configuration). In the DoD this can be a monumental task requiring full and accurate contributions by engineers, supply, maintenance and owner/operators since some fleets (small and medium trucks) exceed 200,000 units. In every function above, be it engineering, maintenance, supply, procurement, configuration/fleet management, staying aligned to the product model (the configuration of the actual item) is absolutely paramount. The PLM process cannot fracture the processes listed above: engineering, sourcing (supply), maintenance and configuration management nor can it fracture the information in disconnected stovepiped repositories. Industry realized this more than a decade ago. Industry has developed software to support this. For defense organizations, it is now a question: Can PLM be implemented to achieve parity with industry.

12 Defining a Customer-specific Reference Model A customer-specific reference model is in popular parlance is called a solution. A solution is the collection of processes, organizational structures, data, systems, or other objects that are properly configured so solve a particular problem. One approach to defining a solution is described by Gulledge (2008). As indicated in Gulledge (2008), the approach requires deep knowledge of the organization as well as deep expertise in the software products that are being implemented. We don t reproduce the work of Gulledge (2008) here, but we note that this approach is similar to the organizational architecting approach that is advocated by Sauer and Willcocks (2002). s s management is the process of scoping, identifying, eliciting, documenting, agreeing, prioritizing and analyzing requirements while controlling changes and communicating them to relevant stakeholders. s management is a continuous and never-ending process. Outcomes (products or services) should conform to requirements that are defined during the requirements management process. The definition of requirements involves elicitation and documentation. This is not an easy task, since users, analysts, and process owners have different mental models, viewpoints, and expectations (Laporti, et al, 2009). The documentation can only occur if negotiations among the stakeholders stabilize, so agreement is critical. For documentation, issue resolution and agreement is critical. The process of issue resolution and agreement must be documented, and it must be reproducible. Our approach documents all critical items that we know and we think we know about a possible solution. We then document the critical items that we think we need to know to complete the solution. We summarized all of this information in specially designed templates so that it is available for future analysis and issue resolution. Most of this effort is from a business perspective, but system knowledge is critical for completing the templates. These relationships are depicted on the left hand side of Figure 5. It is beyond the scope of this paper to go into every detail of the figure, but the important point to note is that we have developed a structure approach for documenting PLM requirements that flows from reference model, to customer specific reference model, to documentation & issue resolution at the business level, and eventually to system and data requirements.

13 Briefing Actions Kno w /Issu e Definition, Discovery and Analysis BPMF LAISO AMC G-6 Workshop Workshop IT Workshop IT Workshop Process Flow Model Summary and Analysis Matrix IT Landscape As-Is IT Landscape To-Be Resolution Development Briefing and Decision Making Analyst Resolution Matrix Analyst Opinion KNOT Cost, Performance, and Schedule Impact Analysis Matrix Need to Know Analyst Decision Report Army Community CoC/BPC Figure 6: s Methodology Overview After issues are resolved and agreement is reached, a decision packaged is produced. For each alternative that affects the proposed solution or the detailed requirements, all analytical results are reproducible so that a final decision can be reached. Benefits of the Structured Approach to s These are some of the benefits of following the approach that we have developed. The approach Focuses the discussion on the real mission objectives (e.g., unit readiness) Identifies the variables needed to analyze the root cause of specific problems as opposed to application-specific or generalized problems Identifies all the participants (decision makers, analysts, stakeholders, customers, etc.) upfront Allows for visualization and collaboration Documents the relationships among policies, activities, data, system, and organizations Provides supporting documentation for the final recommendations as well as for future problem solving Provides documentation so that analytical results are repeatable Delineates actions needed to manage a requirement or resolve an issue

14 Identifies the category of action (e.g., Technical solution) as well as the relevant functional area (e.g., Asset ) Allows specific assignment of responsibility Allows better tracking of what has been completed Need for PLM Governance Structure The final step in the solution definition process is the establishment of the PLM governance structure. PLM implementations within the Government are complicated due to a number of issues previous discussed. These issues underscore the importance of an efficient organizational governance structure to ensure successful implementation and deployment. Such a governance structure can bring together the following stakeholders in the PLM process the business process owner(s) (often separate owners within engineering, logistics and manufacturing), the Chief Information Officer/Chief Technology Officer, weapon system program managers, and other policy generation organizations. External stakeholders can include OEMs, strategic partners in supply chain management (such as Defense Logistics Agency within the DOD) and PLM software vendors. Of the above stakeholders, the upper tier governance structure must include a close partnership between the business process owner and the CIO/CTO. Most defense organizations struggle to find the right balance between the roles of the CIO/CTO and the business process owner. While the business process owner is responsible for defining the process requirements the CIO/CTO must work concurrently to identify the solution based on a structured and integrated business-technical architecture. Many organizations fail to go through this critical step to map the technical solution to the business process models leading to unanswered questions on what functional requirements are truly being met or not being met by the solution. On the flip side, powerful CIO/CTOs within many defense organizations often try to push technical solutions on the business purely based on technical merit such as better integration, interoperability or total cost of ownership. Although these are noble objectives, only a true partnership between the CIO/CTO and business process owner can lead to tradeoffs that are needed by both sides to reach an optimal solution. Market data has shown that without a strong push-pull relationship between these two critical stakeholders, PLM projects often fail due to organizational conflict and lack of unified vision and direction. The PLM executive champion(s) must also be able to define Key Performance Indicators (KPI) for the business and how PLM relates to these KPIs. Many defense organizations struggle to make this connection with PLM often leading to PLM being implemented after a failed ERP implementation or as a silo solution that offers little enterprise value.

15 Summary and Conclusions This paper provides our approach for defining and document a PLM solution for a defense organization. Even though many defense processes are similar to commercial processes, we argue that defense organizations are sufficiently different, and PLM requirements must include the special characteristics of defense organizations. The paper describes the special characteristics of defense organizations, and proposes a defense reference model for PLM. This reference model can be tailored into a customerspecific reference model for each organization that is implementing PLM. In our terminology, the customer-specific reference model is called a solution. We also describe a methodology that we have developed for refining the proposed solution into a detailed set of business requirements. This requirements definition process is documented using models and other artifacts, but its core is issue resolution and agreement. One the business requirements are defined, our approach extends to include system and data requirements. A proposed solution is not complete without the inclusion of a governance approach. A discussion of a proposed governance approach is presented in the final section of the paper. References Borek, Kevin, Lifecycle : The Critical Link between Data and Operational Readiness, Unpublished Manuscript, November 28, Gulledge, T.G., Architecture-driven Enterprise Integration, International Journal of & Enterprise Development, Vol. 5 #3 (2008), pp, Gulledge, T.R., R.A. Sommer, and M.M Tarimcilar, Cross-Functional Process Integration and the Integrated Data Environment, In J.D. Elzinga, T. Gulledge, and C.-Y. Lee (Editors), Business Process Engineering: Advancing the State of the Art. Boston: Kluwer Academic Publishers, Gulledge, T.R., Reference Models and Processes: A Technical Note, International Journal of Services and Standards, Vol. 4 #2 (2008), pp, Laporti, Viviane, Marcos R.S. Borges, and Vanessa Branholo, Athena: A Collaborative Approach to s Elicitation, Computers in Industry, Vol. 60 (2009), pp, Sauer, C. and Willcocks, L.P., The Evolution of the Organizational Architect, MIT Sloan Review (Spring, 2002), pp i Refresh [The Supply Chain Council s Design Chain Operational Reference-model. Version 2.0, 2010.] is the process of changing the product to meet new specifications which usually result from updating the product and/or inserting product improvements/ components. In a computer, it could mean incorporating the next generation of a processor or disk drive. It includes research, design and integration sub processes. It can also result from amending the

16 product (see footnote 3 below). The research component of refresh includes the identification of sources of supply, sourcing and validation of materials/products against requirements. The Design management process of refresh encompasses the refresh of definition, creation, analysis, testing and release of form, fit and function of an existing product. This includes reviewing and adjusting sourcing, manufacturing, testing, servicing and disposal processes. The Integrate management process encompasses releasing refreshed product and product definitions to Supply Chain for execution (sourcing, manufacture, and delivery) and releasing refreshed design documentation to Marketing and Support organizations. ii Amend [The Supply Chain Council s Design Chain Operational Reference-model. Version 2.0, 2010.] includes: a) addressing product fallout (The process of gathering, analyzing and addressing products manufacturability). The process is triggered by feedback that manufacturing quality and process standards/metrics cannot be met. This includes regulatory compliance issues. It includes an Engineering Change Order (ECO) and ends with an engineering change notice (ECN); b) addressing deficient product - the process of gathering, analyzing and addressing a product's technical design deficiency. The process is triggered by feedback that the products performance, behavior and/or appearance do not meet the products specifications as published. This includes tolerances for safety, It also includes and ECO and ECN; c) The activities associated with Specification Change. Where the process is triggered with the gathering of an issue and or introduction of revised product specifications. This process culminates with the publication of a Specification Change Order (SCO) and notification.