Munitions Manufacturing: A Call for Modernization (2002)

The TIME program is aimed at addressing several munitions manufacturing issues, including determining the proper size of the organic production base; timely realization of affordable, complex smart munitions; and a system for rapid replenishment in national emergencies (Raytheon 2000). It seeks to address these issues through the development and demonstration of a totally integrated munitions enterprise, integrating the design engineering, manufacturing, and support functions over the life cycle of the product. Central to this effort is the development of a flexible, rapidly reconfigurable, distributed manufacturing capability that can function as a single entity on a real-time basis regardless of geographic location.

In response to these challenges, the TIME program has drafted a high-level vision that outlines fundamental concepts for the proposed integrated enterprise (Raytheon 2000). Companion documents outline the network architecture and the controller architecture. A data architecture document will also be created. As envisioned by the TIME program, this integrated enterprise will be capable of the following:

• Rapidly transitioning new products and design changes from design to production in a single iteration;

• Rapidly expanding the operations of the enterprise in times of crisis by integrating geographically separated dual-source contractors with whom the Army will have previously negotiated standby contracts;

• Seamlessly communicating orders, designs, process parameters, and other vital data between facilities having a variety of enterprise resource planning (ERP), supply chain, product design, and communications systems;

• Readily allocating raw materials and production between facilities as needed and monitoring inventory levels and production status in real time; and

• Encouraging interaction between team members and incorporating strategies that will enable optimized design and timely, cost-effective production.

The TIME enterprise architecture is a framework that defines the program vision for the entire enterprise and provides a basis for multiyear planning as TIME continues to evolve.

More important, it provides top-level definition and guidance for the selection and interconnection of hardware and software systems and components, to enable interactivity throughout the munitions enterprise (ManTech 1999). Enterprise architecture activities include the following (Burleson 1999b):

• Developing an understanding of the existing environment;

• Designing the framework for an integrated munitions manufacturing enterprise; and

• Developing a methodology and the initial architecture, including;

• An enterprise framework and development methodologies;

• Identification of enterprise core competencies for integrated product and process development;

• Selection of enterprise enablers; and

• Identification of planning requirements for an agile virtual manufacturing enterprise.

Although current funding levels are sufficient only for technology demonstrations, it is intended that the TIME program will ultimately implement this architecture using, wherever possible, the best demonstrated practices and commercial off-the-shelf (COTS) systems of the private sector. The TIME program anticipates developing enterprise integration technologies only to the extent that they are not commercially available.

Outlining this effort in Enterprise Architecture (Raytheon 2000), the TIME program defines enterprise as a unit of economic organization or activity, especially a business unit. It defines architecture as the arrangement of, and interactions among, the components of a system. Thus, enterprise architecture is the arrangement of and interactions among the components of an enterprise, containing the guidelines and rules for the representation of the enterprise framework, systems, organization, resources, products, and processes. This reference architecture has been outlined by the TIME program to serve as an initial benchmark or guide and as a means of assessing the enterprise as it is created and modified over time.

The TIME program is based, in part, on the results of an earlier program and methodology called Technologies Enabling Agile Manufacturing (TEAM). The TEAM initiative marshaled the forces of many organizations to develop a methodology for integrated manufacturing and to demonstrate that methodology in making sample products at geographically dispersed private and government sites. The TIME program has defined a hierarchical, top-down integration architecture that is designed to mesh with the bottom-up integrated product realization strategy of TEAM.

TEAM¹ was a government/industry partnership developed to create and demonstrate a methodology and a technology toolset for bringing the vision of agile, lean, and responsive manufacturing to reality. TEAM was launched in 1993 and operated until its completion in 1998. During that time, $25 million of government funding was provided. This was more than matched by in-kind contributions from industry.

TEAM was founded on the premise that manufacturing is a product life-cycle system from initial concept definition through design, production, use, and end of life. It was determined that efforts to optimize the efficiency and responsiveness of individual parts of the system must give way to optimization of the entire system, which can, on occasion, have the effect of suboptimizing some of the individual parts. Based on this vision, TEAM produced a strategic plan and a technical plan. It adopted a 3-year, three-phased approach. Because many of the technologies needed for integrated manufacturing already existed in the commercial marketplace, the first target of TEAM’s technical group was to find the best commercially available tools for their respective functions and demonstrate those tools in an integrated solution suite. The other targets of the TEAM initiative were interconnected demonstration (limited collaborative environment, partially networked infrastructure, and limited document archiving) and integrated demonstration (collaborative environment, fully networked infrastructure, and structured document archiving).

Because terms like “integrated enterprise” and “integrated product realization” were relatively new to some of the program participants, TEAM developed the models shown in Figures 2–1 through 2–3. Figure 2–1 is a simplified view of an integrated enterprise. In an integrated enterprise, all stakeholders are involved in defining and executing the business arrangement. Contracts are established, concepts are evaluated, designs are created, and products are produced, distributed, supported, and retired at the end of their life.

As the focus shifts from design to production of product in an integrated enterprise, the integrated product realization model becomes operative. In this model, concepts are designed and evaluated and a baseline “script” is collaboratively produced by the integrated design team, which includes customers and key suppliers. This script documents all information needed to define the concepts. The design options are evaluated and optimized, in the middle block of the product realization model shown in Figure 2–2, and all information needed to make the product is generated. The manufacturing script becomes the master definition and repository of all of the product information, as well as the processes required to produce and support it. The final block, manufacturing execution, depicts an intelligent environment with closed-loop processing in which all products are manufactured and certified. The entire enterprise operates on a foundation of timely shared and managed

knowledge. The top-level model in Figure 2–3 depicts the interconnected functions required for integration. Each of the functions necessary to make the product is defined, including the protocols, information requirements, and tools needed to perform the function. The models in Figures 2–1, 2–2, and 2–3 serve as guideposts for integrated product realization.

FIGURE 2–1 The integrated enterprise. Source: DoE 1999.

After development of models, the next challenge was integration, which proved to be TEAM’s greatest hurdle. For most operations, the Internet is an excellent, neutral communications tool. However, an enabling tool was needed to manage the process, and a market search did not identify a COTS product. Therefore, TEAM hired a consultant to produce a framework for the set of Internet access tools, referred to as the Web Integration Manager (WIM). WIM provided multiplatform connectivity and became the product data manager, the repository of all information, the security and configurability control tool, and the workflow manager. In short, it ensured that the project plan could be followed and that every participant in the network had access to information as needed. This Web-enabled approach has the potential to utilize existing databases and legacy hardware and software systems by coding special communication interface “wrappers” and translators. A basic premise of WIM is that any tool that can be connected and can communicate on the WIM can communicate across the enterprise.

After the initial toolset had been defined, the next task was to demonstrate that the tools could be made to operate in a collaborative environment as if they were in the same location (virtually collocated) to produce a sample finished product from design through manufacturing. Although seamless integration was the ultimate goal, expediency necessitated work-arounds for intractable issues such as connection of systems by translators and re-inputting of data, and an interconnected demonstration was designed and conducted for this purpose. A sample prototype machined part was designed and an “enterprise” was established to create it. A network of 11 organizations scattered across the country collaborated in the design of the product, the simulation and refinement of the design, and the creation of the information needed to drive the manufacturing steps. Sample parts were fabricated at General Motors and inspected at Ford. Several universities and small companies observed the demonstration project and produced parts themselves.

The interconnected demonstration validated the methodology of product realization, but it did not address the needs of the integrated enterprise. For the integrated demonstration, an aluminum head for a Corvette engine was selected. The product realization process began with requirements definition, progressed to design and planning, and culminated in production at General Motors. TEAM encountered several significant problems. For example, for the demonstration project to have real-world significance, TEAM had to manage multiple computer-aided design (CAD) systems; launch, integrate, and optimize multiprocess simulations; and drive multiple downstream computer-aided manufacturing (CAM) systems, all from the same product definition files. To address these issues, TEAM adopted an integration architecture called the product realization environment (PRE). Common Object Request Broker Architecture (CORBA) wrappers were developed to “wrap” the tools to interface with PRE. Compatibility between the PRE and the WIM was established to complete the integration. An integrated demonstration, which may be thought of as a virtual cockpit, was developed to enable real-time evaluation of design alternatives through simulation. The

simulations addressed both business and technical issues and provided cost and performance information about different options. Approximately 25, mostly COTS, tools were used in the demonstration. At the same time as creation of the Corvette cylinder head, modeling and simulation tools were used for the integrated design of a jet engine exhaust nozzle for Pratt & Whitney.

In the final year of TEAM, each DoE site was charged with using the TEAM tools and methodologies to demonstrate the products for which it was responsible. The demonstrations included a radio frequency system that tested concepts in electronic design and manufacture, a gas transfer system, a metrology master, a tooling set for forming operations, a turned part, and a neutron generator system. Each of the demonstrations used the basic TEAM philosophies but different toolsets. In one of the demonstrations, 30 different software systems were integrated. The efficiencies realized were significant, but perhaps most significant was the creation of a full electronic design-to-production package. The value of TEAM’s model-driven environment was successfully demonstrated in all of the projects.

In a truly integrated enterprise, all of the tools used by all of the functions of all of the participants work together in a seamless fashion such that all required information is available in the right form to all of the users as they need it. To achieve this perfect solution, all systems and tools must comply with the same universally accepted standards. Because such universal interconnectivity and interoperability is clearly neither available today nor likely to be in the foreseeable future, TIME, in the same manner as TEAM, is striving to adopt an integration framework for the munitions enterprise that can serve as a liaison between all of the disparate systems and protocols and enable them to communicate (TEAM 1997).

Although the TEAM program considered its methodology to be a breakthrough for integrated product realization, it also recognized that this methodology was only part of the solution for a truly integrated enterprise. Product data management (PDM) for large, complex assemblies is a large undertaking and must be carefully managed. Scheduling and shop floor control issues must also be addressed. Indeed, integrated product realization is only one piece of the puzzle, albeit an important one.

Many organizations have a variety of databases, as well as new and legacy systems, all of which require integration to enable optimum organizational performance. To do this requires an integration framework or common environment (a software infrastructure having common objects, services, and interfaces) that enables plug-and-play interfacing and information sharing across all of the participating computing platforms and operating systems (TEAM 1997).

In its last year of operation, TEAM addressed these enterprise integration issues. The process of integrating the WIM with commercial PDM systems was initiated. The sharing of business data between ERP systems and the WIM was addressed. Progress was made, and these capabilities continue to be developed in the commercial sector. Although the WIM, as designed by TEAM, was a user-

friendly tool for integration, it should be pointed out that the marketplace continues to mature and that commercial tools are now emerging that have demonstrated much of the same functionality that TEAM pioneered.

Other elements of technology that were not available commercially during the TEAM program are now becoming so. Some of these are described below:

• As a result of TEAM interactions, Cognition Corporation (Bedford, Massachusetts) brought to the marketplace a new tool called Knowledge Center, which captures manufacturing logic for design advisors and automated information systems.

• The Delmia Corporation Division of Dassault Systemes (then known as Deneb) entered into an agreement that is bringing to market a CAD-driven, expert-knowledge-based programming tool for inspection.

• Several organizations have sought rights for the feature-based tolerancing and planning tools.

• A new company called VEPortals has taken the WIM to the commercial market.

• Several existing tools were also enhanced and modified based on TEAM capabilities.

The TIME program has as a goal the creation of a network that will allow secure, interactive, multimedia communication between nodes, thus enabling a concurrent engineering environment. This network will be capable of transmitting complicated product design and process data from research and engineering to manufacturing environments and will enable the production and monitoring of ammunition at multiple sites. Each node will also be functional and capable of stand-alone connection to any other node in the TIME intranet or outside the intranet using commercial service providers directly without having to go through the centralized network (ManTech 1999).

Networking activities include the following efforts (Burleson 1999b):

• Designing a centralized network architecture;

• Procuring and implementing a centralized network and services;

• Managing the centralized network;

• Designing and installing collaborative communications cells;

• Evaluating, procuring, and integrating initial tools for office functions, concurrent design viewing and collaboration, video, and audio; and.

• Demonstrating initial concept capabilities.

The TIME program has created TIME Centralized Network Architecture (LCMS 1999), a high-level guideline describing principles and objectives for the

network architecture of the program. The document identifies the high-level needs for networking connectivity and defines high-level standards, technologies, configurations, and processes that will support the network. The system described in the document is intended to evolve into a production network platform for the munitions industry.

The network described by the architecture document is to include an Internet-based wide area network, local area networks, servers, workstations, and network services. Connectivity between nodes will be established at five sites selected by the government. The goal of the TIME architecture is to define a network that is robust, reliable, secure, and scalable; that uses standard interfaces and protocols and shares resources; and that provides services in a cost-effective manner. The architecture emphasizes the use of COTS systems as well as open-standard protocols and file formats. The security architecture is defined to support an approach based on need-to-know. TIME intends to build on an evolving e-commerce paradigm using information technology (IT) standards such as data markup language, CORBA, and the Standard for the Exchange of Product Model Data; standard software; and brokers for component metadata exchange, messaging, and visualization. TIME program managers envision that budget realities will result in network deployment and interconnection over a period of many years. A demonstration of the TIME approach to the secure exchange of product data was conducted in 1999 between the Scranton Army Ammunition Plant and General Motors Powertrain. This demonstration project is discussed in more detail in Chapter 6.

The vision of the TIME program architecture document is to create a backbone into which virtually all communications and data functions can be connected. It is a vision of interconnectivity and interoperability. Connectivity involves the ability of multiple software applications, running on the same or different computer systems, to transfer information from one to the other and then take appropriate action using the transferred information. The committee knows of no government-owned/government-operated (GOGO) munitions manufacturing operations where the envisioned computer systems and software applications are in place. Indeed, they have yet to be specified and identified in a detailed plan by TIME. The implementation of connectivity cannot begin until these computer systems and software packages are specified, identified, and installed.

For most commercial operations with a typical level of technical support, just the selection of comprehensive, integrated computer systems and software is a complex and risky task requiring several years of concentrated effort. ERP systems are only as good as the information they process, the user definitions of where the information is needed, and the formats in which the information will be used. To create an appropriate information infrastructure, as-is information flows must be clearly documented, describing what information is processed, where it comes from, and where it goes. Human interaction and decision processes must be similarly documented, including what is done with the information and why. Even these basic, preliminary tasks take time and effort. In a medium-sized operation, they can involve hundreds of people. Often the information available to them and the resulting actions will conflict, requiring discussion to resolve these conflicts.

After the information and data are defined, it is necessary to determine how the information should flow and what results are needed by each department and function. Experts in IT must work closely with key personnel from all participating enterprises and functions during this period to evaluate options and optimize the system. Appropriate commercial hardware and software systems must be identified, investigated, compared, and selected. Finally, this process of system definition, procurement, installation, and debugging can cause disruptions in an organization, so people issues must be considered.

The Army munitions enterprise, in contrast to most commercial operations, is very large. It starts with the deputy director of Strategic and Tactical Systems (Munitions)² in the Pentagon and extends through all of the arsenals and prime contractors, down their supply chains through multiple tiers of subcontractors. Fortunately, many of the commercial operations have already performed these tasks for their own operations and installed their own systems.

Recommendation: Because the high-level enterprise and network architectures have been defined for the integrated munitions enterprise, the TIME program should focus next on defining information requirements and flows and then defining the requirements for enterprise and supply chain systems.

Some of the methodologies and tools that TIME is endorsing for connectivity were originally identified by the TEAM program. Although TEAM successfully applied some of these methodologies in the design and manufacture of several types of sample products, they are still considered to be in alpha (initial) evaluation and will pose some risks until they are thoroughly validated. They may, however, help the Army with its integration task and should further validate the worth of the TEAM initiative.

Designing the system and selecting the components for extensive integration of computerized product development and business management tools is a major goal of the TIME program. It would be tempting to say that all computers in this enterprise system must be interconnected. That might be a good technical measure, but experience has shown that it is not necessarily a good predictor of system success. Careful study of successful integration programs reveals that it is not often the physical connection of computers that gives the greatest benefit or the lack of physical connection and associated software that causes the worst problems. Thus, the percentage of interconnections may be a poor metric for the success of the TIME program.

The attraction of total system interconnection is that information can be moved from one place to another quickly. The disadvantage of massive interconnection is often its cost. It is sometimes possible to avoid a lot of cost if slight delays in information transfer can be tolerated. For example, if it takes a millisecond for a sensor to tell a milling machine controller that the cutter has broken, that is acceptable performance. If it takes a minute, that is unacceptable performance. But if a manufacturer is informing a supplier that next month’s

shipping requirements will be increased by 10 percent, there is little difference in value between a delay of a millisecond and one of an hour.

For example, an electronics manufacturer in Ohio wanted to more closely integrate the scheduling of its assembly operations with those of a company that supplied their parts. The two companies saved over $100,000 on the project by not connecting their computers together. Instead, after each master schedule meeting, the assembly superintendent faxed his notes on the assembly schedule revisions to the supplier, who interpreted the changes and adjusted his parts delivery plan. The two were well integrated but their computers were not connected. From a business viewpoint, TIME should be evaluated by determining whether information moves as fast as is useful or necessary, not by whether computers are physically connected. Cost-benefit analyses can be extremely useful in the regard.

Recommendation: The TIME program should perform appropriate cost-benefit analyses for each system interconnection for purposes of creating a cost-effective system and to establish priorities for required interconnections. Cost-benefit analyses should also be performed for software integration and for data integration.

Many essential networking and connectivity details have yet to be addressed by the TIME program. For example, large organizations, including the DoD and major corporations, are creating increasingly complex firewalls to inhibit hackers and to guard proprietary information. The TIME program will need to make a major effort to define and implement systems that allow its communications to move through the disparate, evolving firewalls of the participants while not compromising the security of their proprietary information.

The TIME program is facing a substantial challenge in attempting to define the high-level architecture needed for a very large, diverse, and complex integrated enterprise. Most enterprise integration efforts to date have involved the integration of functions within individual enterprises, perhaps at multiple, geographically dispersed divisions and often having a variety of new and legacy operating systems. Some enterprises have gone a step beyond and have begun to integrate their supply chains.

The TIME program is attempting to take enterprise integration to yet another level. It is attempting to define a system for managing the Army munitions procurement enterprise. This system must, in turn, be interoperable with the following systems:

• Numerous other existent and future DoD operating systems, such as payroll and logistics;

• Still-to-be-developed operating software that will be required at the Army’s GOGO arsenals and munitions plants;

• Present and future enterprise management systems and supply chain management systems at prime munitions manufacturing contractors, as well as such systems at all of the contractors’ suppliers and, in turn, throughout the multiple tiers of each supplier’s many supply chains;

• Present and future enterprise management systems and supply chain management systems at all dual-use contractors that will be used for replenishment, as well as such systems at all of the dual-use contractors’ suppliers and, in turn, throughout the multiple tiers of each supplier’s many supply chains.

Thus, the enterprise, network, and data architectures must be capable of defining a path for the simultaneous integration and interoperability of many hundreds of systems, each of which is subject to periodic upgrades or replacement by their primary users.

Creating a truly integrated enterprise has proven to be a daunting task for many commercial manufacturing enterprises. Newspapers and trade publications have, for the past several years, printed numerous stories about enterprises large and small, many of them reputed to be very well run, that have undergone massive struggles in their attempts to integrate their enterprises using COTS ERP systems. Some of these enterprises have given up completely after huge expenditures of resources. Additional challenges have been encountered by enterprises attempting to integrate their supply chains using COTS supply chain integration software and COTS CAD/CAM systems. In short, the creation of an integrated munitions enterprise will involve several layers of complex challenges:

• Working with COTS ERP and supply chain management systems that, for the most part, have themselves yet to be thoroughly validated;

• Achieving successful interconnections and interoperability between evolving, disparate systems used within enterprises;

• Integrating such systems among the enterprises, both corporate and government, in supply chains;

• Bringing GOGO facilities up to date in these capabilities; and

• Selecting and implementing an Army munitions ERP system that must be (1) tied to other DoD systems, and (2) integrated with all of the conventional munitions industry’s GOGO, GOCO, research labs, and prime contractors, as well as all of their supply chains.

The TIME program is attempting a very large enterprise integration effort. Furthermore, funding to date has been sufficient to support technology demonstrations but not full-scale integration across the MIB. The committee is impressed by the enormity of the enterprise integration task being addressed by TIME.

As the committee reviewed the enterprise and network architecture documents, which are well designed to provide high-level guidance for integrating the munitions enterprise, one fact became clear. Because TIME is embarking on the creation of a massive and highly complex supply chain, the addition of technical

approaches for management and integration of supply chains to the architecture documents would be most worthwhile.

A large part of the enterprise integration effort of the TIME program will properly fall into the category of supply chain management. “Supply chain” is a term increasingly used by logistics professionals to describe all of the efforts associated with producing a product, from the ultimate customer (in this case the war fighter) to the extraction of raw materials, and all of the process steps and supporting functions in between. Thus, in the case of the munitions industry, the effort includes product design and development; assessment of routine inventory requirements and potential replenishment requirements; management of both routine and potential surge capabilities for manufacturing and assembly; stockpiling of raw materials and parts; warehousing of finished product; order entry and management; and distribution and delivery to stockpiles and the ultimate users.

Efforts to optimize, integrate, or manage the performance of a supply chain typically focus on assessing the value added by each step and function in the supply chain rather than on the overall performance of the individual enterprises. Thus, “supply chain management” can be defined as “A business strategy to improve shareholder and customer value by optimizing the flow of products, services and related information from source to customer” (Warner et al. 2000). An “integrated supply chain” can be defined as “an association of customers and suppliers who, using management techniques, work together to optimize their collective performance in the creation, distribution, and support of an end product” (NRC 2000). Thus, in the approaches being implemented by leading major companies today, each participant in the supply chain is expected to optimize its effort so as to achieve overall improvement in the cost of the finished product and responsiveness of the supply chain to evolving customer needs. All of the participants must be aware, ideally in real time, of changing customer needs and delivery requirements, as well as changes in the operating conditions and capabilities of all of the other participants. Thus the right quantities of goods and services can be made available at the right times and places throughout the supply chain without creating excess inventories or the need for excess manufacturing capacities.

According to an analysis by the Gartner Group, companies that invest in the integration and management of their supply chains can expect to achieve the following business improvements (Kulkarni 2000):

• 150 to 250 percent increase in profits,

• 30 to 70 percent reduction in order cycle time,

• 5 to 25 percent improvement in customer service levels,

• 10 percent reductions in inventories,

• 600 percent increase in inventory turns,

• 25 to 30 percent increase in distribution personnel productivity, and

• 50 to 60 percent reduction in errors made in trying to predict demand.

These types of business improvements can result in dramatic reductions in cost and enhanced response to customer needs. For example, Dell Computer Corporation’s dramatic success in the highly competitive personal computer industry was made possible, in large measure, by its focus on the management of its supply chains (NRC 2000).

Strategically managing the supply chain to reduce total costs and to optimize the availability of materials and process capabilities is a central focus of TIME. Determined to pay the lowest possible price for goods and services, both defense and commercial customers have traditionally attempted to maximize competition and have negotiated hard for concessions on price, inventory stockpiles, and delivery. In many cases, especially in the defense industry, this has weakened suppliers and reduced the industry’s interest in serving defense needs.

In contrast, modern supply chain management techniques recognize that adversarial relationships between customers and suppliers are not necessarily in the customer’s best interests, and instead they emphasize win-win relationships between customers and suppliers. Benefits to the customer can often be maximized by nurturing of long-term relationships, even if the supplier skill sets are only used on a contract-by-contract basis. Such partnership approaches can require supply chain participants to change their attitude from the traditional attitude: What’s in it for me? to a new attitude: How can we maximize our common good, and what can I do to help us achieve our mutual goals? This change in philosophy can be extremely difficult to accomplish, especially in defense industries, and cannot be created merely by negotiating legal contracts. It requires trust and a spirit of giving, both of which are difficult to develop in competitive industries, where companies may be fighting for their very survival. In the defense industry, developing these cooperative relations and optimizing supply chain performance for the mutual benefit of all participants are in many cases made more difficult or not allowed by Federal Acquisition Regulations and contract law, both of which flow down fiduciary responsibility (i.e., each supplier is directly accountable for its portion of the work as defined in the contract or purchase order) (NRC 2000, pp. 14–15).

Recommendation: The Army should follow the current industrial practice of developing long-term mutually beneficial relationships with both its routine munitions suppliers and its replenishment suppliers. It should also take advantage of changes in government procurement regulations to optimize the performance of its munitions supply chains, especially when needed for replenishment.

One of the key principles of supply chain optimization is the implementation of technologies that support multiple levels of decision making and provide a clear view to all participants of the flow of products, services, and information. Such a system must be able to handle daily transactions, schedules, and e-commerce across the supply chains and thus enable short-term balancing of supplies, inventories, capacity utilization, and demand among participants. It must also support longer-term planning, scheduling, and investment in resources and capabilities. Most important to the munitions industry, it must support strategic

planning and an integrated network model capable of synthesizing data for use in high-level “what-if” scenario planning and capacity assessments.

To date, few corporations in commercial industry, despite huge investments in technology, have succeeded in acquiring and extensively deploying a full complement of these capabilities. According to a late-1998 Grant Thornton survey, only 11 percent of all manufacturers, mostly the largest ones, have adopted ERP. Among mid-size ERP users, only 43 percent reported that their integrated IT system was fully functional (Braunstein 1999). Major problems have included system defects, difficulties in redesigning business practices to conform to the systems, and difficulties in interoperability between systems (e.g., enterprise management systems and supply chain management systems).

ERP systems, which typically focus on the internal systems of one corporation, such as planning, production, and finance, alone are not sufficient, as they generally cannot provide the bridge between the multiple systems of suppliers and customers that is required for dynamic scheduling and inventory optimization. Hence, participants must look beyond ERP to supply chain management systems capable of integrating the entire organization. ERP vendors such as SAP, Oracle, and Baan³ are increasingly developing supply chain management modules and are assisting in integrating with third-party solutions.

Supply chain management systems by vendors such as Manugistics, i2 Technologies, and ProMIRA are finding increased acceptance. In many cases, substantial improvements have been made in operations within individual corporations (enterprise management), and to a lesser extent the performance of supply chains has been improved, primarily in the areas of inventory reduction, order integration, and logistics. However, tremendous opportunities still exist in commercial industry for the improvement of enterprise operations, supply chain operations, and the synergy that can be created by developing a system of systems as these disparate, complex systems and their interoperability are improved and more extensively utilized.

This discussion of the shortcoming of COTS enterprise and supply chain integration systems should not in any way be interpreted as a message that the efforts of TIME should be abandoned. Quite the contrary, TIME, if properly executed, offers the potential for huge savings to the taxpayer and dramatic improvements in the responsiveness of the munitions enterprise to U.S. defense needs, but the challenge should not be underestimated.

Although creation of high-level architectures can serve to define and guide the enterprise integration efforts, one of the critical next steps is the appropriate definition and documentation of the existing munitions industry. This will be critical because the steps in creating the enterprise will properly start from the bottom and will only later be integrated at high levels. The TIME program must, for instance, thoroughly understand the current munitions industry. The capacity and the

capability of all government and commercial munitions plants and how long it will take to activate various capacities must be entered into a common database. Prenegotiated dual-use capacities must also be entered into the database along with scenarios for workforce recruitment and training.

For this approach to be viable, it will be necessary for DoD to negotiate agreements with potential replenishment suppliers and to establish an assessment of the capabilities of the MIB. The TIME program should avail itself of this information, assist in keeping it up-to-date, and assist in getting it stored in a format compatible with the TIME enterprise architecture, so that it is readily accessible by participants in the integrated enterprise that have a need to know. This database should serve as a foundation for TIME’s efforts to integrate the enterprise and should prove useful in establishing program priorities.

Another example of problem definition faced by the TIME program is that of precisely defining its objectives in communicating with the shop floor. According to Keith Nosbusch, president of Rockwell Automation Control Systems, the capability to communicate from the Internet to the shop-floor control and to remotely monitor and control the shop floor is already available, but, except for hazardous processes such as refinery operations and energetics processing, no one wants to do it (McCormack 1999). From his perspective, this capability is not going to be extensively implemented in the near future because resolving the question of who gets to make changes on the shop floor and how they are to be controlled represents both a culture shift and a security and safety shift. Control of changes is a far more substantial issue than remote monitoring and diagnostics, which are real capabilities that are implemented today in a variety of commercial industries. To give a controls engineer at the Armament Research, Development, and Engineering Center, for example, the capability to make changes on the factory floor of a remotely located commercial supplier is not likely to be accepted by commercial participants in the munitions supply chain for the foreseeable future. Remote monitoring is far more likely to be accepted. Presentations to the committee by participants in the TIME program have failed to make clear the extent to which the program intends to implement these capabilities. The committee believes that it is important that the TIME program present a clear, consistent picture of its intent on important issues such as these. Furthermore, although the committee is supportive of efforts to use COTS technologies to monitor the status of munitions manufacturing operations and inventory levels, especially in times of national crisis, the committee believes that remote control of all but the most hazardous operations represents unacceptable safety risks to shop floor personnel and damage liability to the U.S. taxpayer.

The high-level architecture is described quite well and appears to the committee to be a solid, state-of-the-art approach. However, no details have been provided about how it will be integrated. This is a significant weakness of the program. The TIME program must take steps in the near future to define its enterprise integration methodology (business-to-business) and to devise a means

for modeling the integrated system. Although not the highest priority for TIME during the next several years, dynamic modeling will be required to test the behavior of the system under many conditions.

The following elements remain to be well defined in the context of the enterprise architecture as part of the integration effort:

• Role of the enterprise infrastructure;

• Role of integration hubs;

• Role of extensible markup language (XML) as an integration methodology for enterprise-level information exchange;

• Middleware for integration, including message-oriented middleware;

• Details regarding enterprise-level database integration;

• Communication technologies for middleware integration, such as CORBA or the Distributed Component Object Model;

• Role of information brokers in enterprise integration; and

• Role, if any, of online trading techniques.

The TIME program correctly views the enterprise as a constantly changing and dynamic environment. However, there are no provisions in the approach for understanding its dynamic nature and characteristics. No tools or methodologies are identified to discover and evaluate the available enterprise-level static and dynamic capacity and capability. In addition, the TIME program should outline a bridge or roadmap between the present state of the munitions enterprise and the long-term vision of TIME. With the completion of the initial high-level architectures, the TIME program has correctly determined that a next key step is the assessment of the capabilities of the munitions industry and its multitiered suppliers, to determine which pieces of the integrated enterprise are already in place and which specific pieces will be needed (McWilliams 2000b). Prioritization must come next.

The TIME program has done a good job of developing the vision and describing the enterprise architecture and its components. However, it is the committee’s view that very little effort has been put into clearly outlining the details of the TIME integration methodology. Integration of the extended enterprise must, due to budget constraints, be implemented in a well-prioritized, cost-effective manner so as to create the maximum benefit for U.S. security for the taxpayers’ investment.

New approaches are emerging that could affect the way an enterprise can be integrated. Value stream analysis (Hines 1999) is one such approach, in which value streams are defined across enterprises and then integrated. The development of XML and its ability to define extended private tags is an example of an emerging technology that can facilitate enterprise integration. Development of integration hubs is another. These approaches are maturing at a rapid pace and may be available for COTS use in the near future.

Conclusion: The TIME enterprise architecture document presents a high-level vision for the integrated munitions enterprise. However, the program provides little insight into detailed operational characteristics and selection criteria for key components. TIME must prepare detailed plans for networking and interconnection of the myriad systems that will make up the integrated enterprise.

The magnitude of the integrated enterprise must be kept in context. Its completion, as presently envisioned, can require a massive investment. In contrast, the TIME budget is adequate only for technology demonstrations. It is, therefore, only reasonable to assess the plans of the TIME program against standards for current practice in management of industrial supply chains in large organizations. It is the opinion of the committee that TIME is identifying and attempting to demonstrate the use of integration tools that are consistent with current enterprise resource management directions and emerging integration architectures while offering cost-effective views for integration of manufacturing operations. These tools are being used in demonstration projects, which can serve as an effective way to influence the funding and direction of the program. These demonstration projects also serve to create a focused intensity and unity of purpose within the program that cannot be achieved in any other way. The committee believes that this is a good strategy and that the Army should understand it and reinforce its effectiveness.

There are enough commercial systems of sufficient capability on the market today to enable the TIME program to begin to create the munitions enterprise of the future. However, the tools required to enable these systems to function in an interoperable manner in an integrated enterprise are still lacking in some ways, although appropriate commercial tools are being developed at a rapid rate. The Web Integration Manager, selected by TIME, is an excellent example of such a tool. The emphasis of the TIME program should be placed on defining and prioritizing needs; identifying the appropriate interoperable toolsets; and beginning its implementation at low levels, based on an appropriate prioritization process that identifies critical capabilities and assesses returns on investment.

Recommendation: The enterprise integration effort should begin with well-defined, high-priority low-level work. For example, standardized databases containing supplier and subsupplier capabilities and capacities should be developed and kept updated. This includes the workforce skill base, not just the manufacturing base. A PDM system is essential. The focus of the efforts should be on integrating people, business practices, and partner relationships, not just on computers and networking.

The committee recognizes that the costs of implementing the integrated munitions enterprise will be high. Although major commercial participants typically will have invested in their own systems that can be networked into the TIME architecture with little cost to the government, many small participants cannot afford such capabilities on their own. Some large contractors, such as Lockheed-Martin, have solved this problem by negotiating large licenses with vendors of systems such as CAD and then giving small participants in their supply chains free seats so that they can concurrently participate in product development (Morris 2000).

GOGO facilities have no such capabilities, and many small participants in the munitions industry supply chains probably have few of these capabilities. Thus, implementation, which can include significant costs for site licenses, hardware, employee recruitment and training, communications and interoperability capabilities, and system validation, can add up to a significant investment by the taxpayer. In establishing priorities for implementation, DoD should look across the entire spectrum of munitions needs, from ammunition to smart munitions, and place priorities on those segments of the industry that are most critical to future national needs.