Secure Collaboration in A&D

PLM: The Critical Link between Product Data and ERP

January 29th, 2009 | Total Lifecycle Systems Management | Posted by Thomas Murphy

The following is a paragraph from a recently published OSD White Paper entitled “Product Lifecycle Management: The Critical Link Between Product Data and Operational Readiness”

One of the greatest failings in the DoD’s investment in ERP environments to-date has been the lack of corresponding investment in product data management.  Other than simple financial transaction management, it is virtually impossible to leverage the other capabilities of an ERP in the absence of authoritative product data (i.e. knowing “what’s in the box”).  A simple representative example of this would be forecasting spares inventory requirements against demand.  If one has no visibility into the actual configuration of assets that are manufactured, delivered and remanufactured over long time horizons (via  managed, structured bills of material), it’s impossible to determine how much of what will be needed.  Another example would be inserting new technology into an existing hardware platform.  Without the fidelity provided by an actively managed product data repository and visibility into the asset base, determining which assets to upgrade, estimate cost of upgrade and project planning are problematic at best.  There are hundreds of examples of inefficiency associated with this information gap within DoD and it should be obvious why this capability should be considered to be a core foundation competency.

Do you agree or disagree with the DoD’s analysis of the problem? Please provide relevant examples.

Permalink | January 29th, 2009

Comments

1. Joe Besselman Says:
   February 1st, 2009 at 10:05 am

   Absolutely. However, the Dod should implement PLM as an evolving set of commoditized Enterprise Services using computing resources inside of DISA. They should not allow the services, or worse, the depots inside the services to pursue unique, customized solutions that are absolutely duplicative and wasteful of taxpayer dollars.

   The model that should be followed is Software as a Service (SaaS), and a great example of that model is Salesforce.com. Salesforce.com offers thousands of companies commoditized Enterprise Services that effect every facet of the IT support needed to support a sales operation, large and small. The DoD could easily pilot such a capability in the PLM space and incrementally evolve its palette of Enterprise Services. This provides the warfighter incomparable delivery velocity, saves substantial funding from not allowing massive duplication, and it enables the rapid and central implementation and enforcement of policies, both logistics and security.

   PLM is also a great starting point for the DoD to embark logistics down a SaaS path. Make no mistake, the future for computing in logistics is SaaS (e.g., consider the functional slices already offered by OneNetwork…the future is here), whether you use an Industry capability inside or outside a DISA processing center. Fortunately there is a product set with overwhelming market share that can easily accommodate such a paradigm and the functionality that embodies PLM easily fits in the SaaS model.

   Taking such a path, using PLM as the pilot, the DoD could really learn how to truly do Joint Logistics and operate only Joint Logistics capabilities and end the Tyranny of the Engineers [and dubious integrators] that live for a proliferation of duplicative capabilities. After PLM, they could easily draw the migratory path to replace all of the other duplicative, stovepiped logistics capabilities with commoditized Enterprise Services.

2. William (Bucky) Buchanan Says:
   February 2nd, 2009 at 1:44 pm

   I agree with Mike…its not just the investment in ERP…but the lack of investment up front when acquiring a weapons system or platform. DON has divided up the appropriations into 2 separate entities: Buying the system (SCN) and maintaining the system (OM&N). This split continues to plaque the maintainer cause he does not have a PLM tool loaded by the system purchaser so the maintainer can support the system and the corresponding data throughout its life-cycle.

   Joe Besselman also has the right idea to invest in a enterprise wide system at a DISA facility or other Software-as- a-Service (Saas) that is robust enough to allow the system purchaser a way to load all the great data he purchased with the system. The lack of a consistent place for each Program Executive Office (PEO) to put that data hampers the maintainers ability to have that data in a consistent place and in a stable format. So the big question is who pays for that PLM? ….the system acquisition office or the maintainer? So far the maintainer has not had the resources to put up even a pilot and even though we are making progress with the disparate PEOs, there is still not a program of record for a PLM that will accomodate all the PEO’s within a hardware systems command like NAVSEA or NAVAIR. We have made great progress with the National Shipbuilding Research Program (NSRP) in setting up a “contract invokeable” specification for an Integrated Data Environment within the shipbuilding community. This was a great step forward and we are in the process of ensuring through the Navy Product Data Initiative (NPDI) that the PEO’s are onboard and conform with this specification.

   Bucky Buchanan
   Logistics Data Architecture
   Naval Sea Systems Command

3. Troy Kaper Says:
   February 4th, 2009 at 8:17 am

   All the statements above are valid points about PLM inside the DoD complex. And the point about a SaaS and additionally SOA (Service Oriented Architecture) will be a must because the actual manufactures of the weapons systems are outside of the DoD network. The weapons systems are built by those companies (Lockheed, Northrop, Boeing, L3, BAE, etc) and that is where the actual Product Data is created. In order to be practical and efficient the DoD system must have the ability to accept delivery of the Product Data as well and the actual Product (weapons system).

   I remember years ago working at GE Aircraft in Cincinnati. A good amount of the design work for the engines (fixtures, tooling, some structural design) was generated by outside vendors. But GE was not set up (neither with the systems architecture or contractually) to accept the actual 3D product data generated by the vendors. So the process went like this: The vendor would create 3D models to then make 2D drawings (standard CAD stuff) then submit the 2D drawings to GEAE. (this was in the contract) GEAE then would have their designers take the electronic 2D drawings and recreated the 3D models so they could use the models in a 3D digital mockup. This went on for years.

   The problem is that just looking at piloting a PLM system to manage product data in the DoD is not enough. There has to be some effort given to designing a system that will receive the product data from multiple design sources (CAD, Tech Pubs, Manufacturing, etc). It is not practical to demand that every OEM, Supplier, Vendor use one system for all things. That is where the SOA and SaaS focus comes into play The companies outside the DoD have been moving towards this for years. DoD needs to recognize this and move in the same direction. Don’t just stand up another set of repositories, set up another point in the supply chain. Logistics should be another stop in the rail system, not it’s own destination.

4. Mark Adams, CEO Portal Dynamics, Inc. Says:
   February 6th, 2009 at 11:04 am

   I agree with the quoted PLM white paper concerning ERP’s, and enterprise support systems’ in general, requirement for accurate, complete product data in order to be effective. Clearly, especially if the requirement of the ERP or any enterprise system is to support a product for part or all of it’s life cycle. My remarks are based on, and obviously biased by, my military operational experience and positions supporting the Strategic Systems Program (SSP) TRIDENT Program, ADUSD for CALS in OSD and presently, leading a company that specializes in collaborative information management supporting product (and process) life cycle supoprt.
   If the OSD white paper quotation is accurate, which I believe it is, why is the state of PLM support so dismal? Before we address functional pilots or technology solutions, perhaps we might explore inhibitors to product life cycle management and understand some of the reasons why the best technology, services or intentions get little or no real traction, at least in DoD. I’d like to offer my thoughts on three (of many) inhibitors to effective PLM; 1. organizational responsibility, 2. financial management and 3. contractual communications between OEMs and the product manager.
   Addressing the first inhibitor, US Title 10 and, to a greater extent, the DoD 5000 series of instructions have been relatively clear in confering product life cycle responsibility to PEO’s, DRPMs and PM’s in DoD. However, the organizational placement of lifecycle responsibility is often limited, constricted or distracted by short term requirements forced by operational needs such as the GWOT, extreme weapon deployments and warfighter risk management such as up-armor, MRAPs etc.) Relatively short our lengths for PEOs’ and PM’s compound the problem, although there is a longer management continuity with Deputy positions. The DoD, in effect doesn’t even own the entire life cycle that is supposed to be managed by the Acquisition community. OEMs control the early and most critical stages of product development within which decisions are made that have a huge multiplier effect throughout the life cycle. Additionally, acquisition managers often have little or no leverage over the sustainment community, further limiting their ability to execute true PLM. The Army took a big step towards mitigating these organizational disconnects by forming Life Cycle Management Commands (LCMC). However, even LCMCs, notwithstanding the title, experience difficulty, managing across the entire product life cycle.
   The second inhibitor, financial management is relatively straight forward – PLM responsible organizations and managers do not control the product financial life cycle. If the life cycle managers were able to control the financial life cycle, most organizational inhibitors would be marginalized. Although the PPB&E process is complex and multiple appropriations add to the financial pain of product life cycle management, centralized control or at least a majority vote held by the Acquisition manager would go far to help PLM succeed.
   The third inhibitor to shich I refer is the contractual communications between the government and OEMs that provide the products. Product data, per se, is rarely a contractual requirement at the level of completeness that would truly support a PLM responsibility. Once a contract is in place, it is extremely difficult to expect the OEM to respond to PLM driven changes outside the contract and it is equally difficult to modify acquisition contracts to be sufficiently responsive to PLM requirements. Additionally, contractual relationships in the early stages of a product life cycle have little connection or relevance to sustainment or operating support relationship. Clearly, CLS types of relationships such as the Army STRYKER program initiated does place a longer period of a product life cycle in one place (the OEM) but the Army PM is still responsible overall for PLM success and initial CLS requirements may not have invisioned or described the relationship clearly enough to adequately provide life cycle support. For example, the product data for future POM builds for the out years is not available to Army planners because of the war-time operational intensity of the STRYKERS but more importantly, the CLS contractual relationship between the OEM and the Army may not allow the appropriate product data to be developed and made available to support the POM.
   Notwithstanding my opinion of the issues above, I remain confident that all life cycle stakeholders can expect a more collaborative and integrated life cycle management environment as we learn to better describe, develop, capture and manage product data. We often rely on information technology (ERPs for example) to help mitigate core infrastructure issues I’ve discussed here. In some instances, this reliance has offered a broader life cycle capability but imposes another set of issues than often deflect management attention from the product life cycle requirements to the information systems life cycle. I believe we need to address short term issues for which information technology may help but always in the context of the larger organizational, financial and contractual relationships that are at the core of limited product data availability and effective product life cycle management.

5. Brian Bennett Says:
   February 7th, 2009 at 3:55 pm

   Within the last year, my small firm has partnered with other technology providers on a couple of DoD PLM implementation projects that utilize an IDE and employ a services-oriented approach. The IDE provides a great mechanism for sharing product data between organizations, and (via re-use/standardization) streamlines the development/deployment of similar business processes across organizations.

   I agree that SOA/SaaS is critical for providing end-to-end management of all product support data. The focus should be on building services to collect, interoperate with and provide data to/from all parties related to the program – encompassing design/development, supply, support, readiness, etc. Even within the DoD network there are many disparate organizations & data sources and a vast number of potential recipients of the rich amount of information that is (or could be) managed within the PLM environment.

6. Ars Mechanica Says:
   April 7th, 2009 at 8:36 am

   While SaaS seems like a viable methodology to breaking down the silos of information (or lack of) fostered by the disparate acquisition processes in the disparate organizations, don’t underestimate two things: the first is the difficulty in creating a the ability for existing contractor and government systems to exchange data and the second is an understanding of what data is usable. A PLM system is more than a methodology of exchanging design files; it is a record of design history as determined by policy (often the policy is from inception to grave, but many organizations only invest in documenting the middle, “active” phases, i.e. from the approval for development (skipping the investigation prior to projectization) through end of manufacturing life. The ability to understand not only the time-phased state of existance but to manage the inventory, supply base, quality, and manage those aspects as a cohesive program are the comprehensive benefits of a PLM. Working in a non-defense government agency, the concept of managing at this level is incomprehensible to management. Investment is focused on systems that do little more than associate cost with inventory, support ordering materials, and billing. The only items that have any lifecycle management are software systems, which means PLM is overlooked in favor of ALM, and ALM is split into evolution and build of application software and helpdesk/desktop support management tools – specialized subsystems of overall PLM from my experience.

   A government-wide PLM system that would allow any agency to manage “as built” IT and inventory effectively would be a tremendous bonus, as you cannot manage what you cannot measure.

Leave a Reply

You must be logged in to post a comment.