Product Lifecycle Management 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: Product Lifecycle Management, Weapon System Lifecycle Management, Product Improvement, Program Support
Abstract
Product Lifecycle Management (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
Product Lifecycle Management (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.
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. Product 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 Management
Product Lifecycle Management is the process of managing the entire lifecycle of a product from its conception through its disposal. PLM is a strategic approach for
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. Material Plan Deployment Plan Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area Shipping Information Material Demand Contract Command and Control (C2) MRO Requirement End Item Asset Data Material RequirementsPlanning Inventory Management
Hazardous & Special Material Management Supply Chain Management & Procurement Material Requirement Material Disposal Plan 3/18/2003 10:37:11 PM OV-6.1.2 Supply Management
Product Life-Cycle Management Field Supply Management Financial Management Acquisition Disposal Disposal Maintenance Repair & Overhaul
Transportation &Distribution Line Maintenance End Item Asset Data Financial Control Data Disposal Requirement Order Product Life-Cycle Management Force Planni ng Order HAzardous Material Requirement Inventory Management
Hazardous & Special Material Management Supply Chain Management & Procurement Shipping Information Material Demand Contract MRO Requirement End Item Asset Data Material Requirement Material Disposal Plan 3/18/2003 10:49:20 PM OV-6.1.5 Field Supply Management
Product Life-Cycle Management Product Life-Cycle Management Financial Management Acquisition
Disposal Disposal Transportation & Distribution End Item Asset Data Financial Control Data Disposal Requirement Supply Management Order Material Requirements Planning Field Line Maintenance Material Requirement Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area Force Planni ng Logistics Plan HAzardous Material Requirement Line Maintenance Maintenance Control
Inspection &QualityAssurance Maintenance
Completion Direct Supportto Operations Maintenance Execution ConfigurationChange Requirement Asset Condition Work Order Disposal
Requirement Repair Item Material
3/18/2003 11:21:39 PM OV-6.1.6 Field Line Maintenance
Personnel & Organization Personnel & Organization Financial Management Financial Management Disposal Disposal Asset Configuration Product Life-C ycle Management Asset Configuration Material Requirement Product Life-C ycle Management Financial Control Data Financial Control Data Personnel RequirementsData PersonnelData Work Status Transportation Requirements Transportation & Distribution Transportation & Distribution Transportation & Distribution Sustain Deployed Operations Maintenance Data Repair Notification Maintenance Requirement Mission Informatiopn Force Planni ng Maintenance Planni ng & Preparation Configuration Management Field Supply Management Material Requirement Field Supply Management Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area Life-C ycle Data Management Asset Life-C ycle Management Environment, Health andSafety
Quality Management Life-C ycle
Collaboration andAnalytics
3/12/2003 10:04:30 AM
Design Specifications
OV-6.1.9 Product Life-Cycle Management
Design Specifications Engineering Drawings Engineering Drawings Asset Configuration Maintenance Repair & Overhaul Engineering Drawings Asset Configuration Line Maintenance End Item Asset Data Acquisition Acquisition End Item Asset Data Supply Management Supply Management Transportation Requirements Transportation &Distribution
Disposal Requirement Disposal Maintenance Repair & Overhaul Line Maintenance Supply Management Level 1/ Process Area Level 2/ Main Process Level 1/ Process Area
Product Lifecycle Management is a Subset of Weapon System Lifecycle Management
1 4 5 7 8 1. Asset turned in for Repair 4. View Asset Configuration and Drawings 5. Order Carcass from Field Supply 7. Order Carcass from National Supply 8. Shipping of Carcass from CONUS
to Theatre 2 2. Create Work Order 3 3. Execute Work Order 6 6. Check Inventory 9 9. Shipping of Carcass to Supply Unit 10 10. Replace Carcass Part 12 11 11. Update Asset Configuration 12. Close Work Order Field Maintenance Field Supply National Supply Product Life-Cycle Management Transportation PLM is One Segment Of the Weapon System Product Improvement Process
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
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.
Project Plans for Individual Initiatives
Scoping the AMC PLM Solution (The Definition, Discovery, and Analysis Phases of Requirements Management)
AMC Management View AMC Vision and
Strategic Priorities
PLM Best Practices Reference Models
SCOR/DCOR Metrics
Best Practices are the Guides for Designing the AMC PLM View PLM
AMC PLM Solution
SCOR/DCOR Models are the Measurement Frameworks that Measure Design and Supply Chain Performance
PLM Implementation Roadmap
Places Vision and Priorities in an Organization Management Model PLM is one Business Process in the Management View
Defines the Desired PLM End -State Solution for AMC
The Implementation Roadmap cannot be defined until the Desired End-State
is Defined To b e D ev el o p ed Data Management Framework To b e D ev el o p ed
Defines Data Management 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).
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 Product 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.
Requirement Planning Requirement Planning Product Concept Product Concept Product Definition Product Definition Product Development Product Development Product Introduction Product Introduction Product Support Product Support
The Product Lifecycle
Figure 3: A Typical Product Lifecycle
PLM effectively is the union of CAD (Computer Assisted Design) and Product Data Management processes and tools. It spans both the design chain (New Product Development (NPD) and change), the supply chain and manages the requirements
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 Maintenance 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.
18
18
Product Data Requirements
Product 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 Materials Y Y Y Word/Acrobat
Manufacturing Data
Process Documentation Y Y Y Y Y Word
Production BOM Y Y Y Y PDM Formatted Text
Tooling Design Y Y Solidworks/ACAD
Routers/Work Instructions Y Y Y Y Y Word/PDF
Production Materials 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 M A KE M A KE & DE L IV E R
Figure 4: Aircraft Product 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
refreshi and amendii 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
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 Product 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, Product Support Documentation, Parts and Items Data, Deficiency Reports, Maintenance Plans, Safety Data, Operational Requirements, 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
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
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 Management. Configuration Management 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.
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).
Requirements Management
Requirements management is the process of scoping, identifying, eliciting, documenting, agreeing, prioritizing and analyzing requirements while controlling
changes and communicating them to relevant stakeholders. Requirements 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.
A
ct
io
n
s
Definition, Discovery and Analysis
Resolution Development
Briefing and Decision Making
Process Flow Model
Summary and Analysis Matrix IT Landscape As-Is Resolution Matrix KNOT
Workshop Workshop WorkshopIT
Analyst
Army Community
Analyst
Analyst
Opinion Need to Know
IT Landscape To-Be CoC/BPC R eq u ir em en t/ Is su e IT Workshop LAISO BPMF AMC G-6 Cost, Performance, and Schedule Impact
Analysis Matrix Kn o w B ri efi n g Decision Report
Figure 6: Requirements Management 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 Requirements Management
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
Identifies the category of action (e.g., Technical solution) as well as the relevant functional area (e.g., Asset Management)
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.
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 customer-specific 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, Product Lifecycle Management: The Critical Link between Product Data and Operational Readiness, Unpublished Manuscript, November 28, 2007.
Gulledge, T.G., Architecture-driven Enterprise Integration, International Journal of
Management & Enterprise Development, Vol. 5 #3 (2008), pp, 265-309.
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, 1999.
Gulledge, T.R., Reference Models and Processes: A Technical Note, International Journal
of Services and Standards, Vol. 4 #2 (2008), pp, 141-149.
Laporti, Viviane, Marcos R.S. Borges, and Vanessa Branholo, “Athena: A Collaborative
Approach to Requirements Elicitation,” Computers in Industry, Vol. 60 (2009), pp,
367-80.
Sauer, C. and Willcocks, L.P., The Evolution of the Organizational Architect, MIT Sloan
Management Review (Spring, 2002), pp.41–49.
i
Product 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
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.
