What Defense Manufacturers Really Need in Enterprise Software

Contractors must now maintain systems that not only track all aspects of a program, but provide proof to the customer of the standing of all program based key performance indicators (KPIs). (Photo courtesy of General Dynamics Maintenance and IFS North America)If you are reading this publication, you already know that running an aerospace and defense manufacturing business is very different from running a manufacturing operation that serves the civilian sector. The differences range from the basic business model to the corporate culture, and have implications for the type of enterprise software you need to successfully compete in the market.

One reason for this is the growing trend all branches of the military to subcontract more logistical services. When this trend started, many contracts were firm fixed priced but, as this method of operation has matured, the military has learned that they most efficient way to do this is to move those contracts from fixed price to performance based. This places the onus on the contractor to perform, and to do so, at a profit. Contractors must now maintain systems that can not only track all aspects of a program, but provide proof to the customer of the standing of all program based key performance indicators (KPIs).

The unique characteristics of defense manufacturing operation is what has lead to the separate and distinct needs in the area of enterprise software, including enterprise resources planning (ERP) and software for maintenance, repair, and overhaul (MRO) activities.


Program Centric
Let us first consider how a defense manufacturer operates, and how this is different from other industrial concerns.
Aerospace and defense manufacturers are typically operating in an engineer-to-order (ETO) environment. The company will be making something either as a subcontractor on a program, or directly to some echelon of the military as a prime contractor. The business model used to support this type of relationship is commonly referred to as program-based manufacturing. Under this model some issues may arise when working with some enterprise software that is not designed to support this industry. Some of those common issues are the segregation of the inventory for programs – tracking government-furnished materials or equipment (GFM and GFE) or customer-furnished material and equipment (CFM and CFE). Enterprise software must also be able to track under what circumstances it is allowable to transfer inventory between projects or programs, and what the “borrow and payback” rules are that must be followed under those circumstances.

Typically when a company is working in this environment they will be creating and testing a prototype, so there is a lot of up-front engineering and management time that must be tracked back to the program. Appropriate enterprise software will use a work breakdown structure to track these costs to the appropriate program and activity, along with those costs that normally occur during the manufacturing phase. In systems that are not designed for this industry, those costs may be difficult to analyze, as they would commonly just be considered indirect cost or overhead. That work breakdown structure, which is central to all aspect of the program or project, will have substructures underneath it for things like engineering, project management, prototyping, perhaps a limited production run, and then the normal manufacturing run. This is done in order to determine the true cost of working on a particular program, or substructure of that program.

The work breakdown structure and substructures must be robust enough not only to track funding, or a budget, but also to track the actual costs and time frames. Indeed the structure must also be able to estimate the estimated future costs and completion time frames, during pursuit of and throughout the execution of the program dollars and in time.

During the entire contract lifecycle, starting with generating a bid from a budget, you are responsible for the operations cost of your internal resources, including the broad array of people who will touch that project. During that time, actual costs must continuously be monitored and tracked against the budget.

Additionally, work breakdown structures also need to account for the concept of subcontracting, a trend that is growing enormously as the military and, in turn, as its prime contractors seek to outsource more and more activity under performance based logistics (PBL) or similar contracts.

It is not uncommon to subcontract services such as engineering to an external vendor, but their work will only be one small portion of a much larger program. That subcontracted service must then become one segment of that much larger work breakdown structure. The work of that subcontractor, along with any work they pass to lower, third or fourth tier subcontractors, must be tracked with the same level of detail. This is necessary in order to be certain they are meeting their scheduling progress and actual costing requirements.

Just as the military is moving to make contracts incentives payable to their contractors according to the earned value they have contributed, prime contractors are pushing this requirement to perform down to their subcontractors. This cascading progression that must be reflected within the work breakdown structure can, in many cases, become very elaborate so enterprise functionality must be robust enough to accommodate the various relationships and dependencies involved.


Reporting
Defense manufacturers will need to make sure that their enterprise software will capture and allow them to access all of the data required to facilitate very specific government reporting.

Another predominant reporting requirement for aerospace and defense manufacturers today is wide area workflow (WAWF). WAWF is a DoD-wide application designed to turn the receipts and acceptance of DoD contracts into a paperless process so defense contractors and DoD personnel can create invoices, receive reports, and access contract related documents electronically.

In a DoD contracting environment, in order to receive payment, three documents are required to make a payment – the contract, the receiving report, and an invoice. Using WAWF, these documents are shared electronically, which helps ensure they are kept together and accessible to all stakeholders.

Under WAWF, DoD makes contracts available through electronic document access (EDA). Individual contractors then have electronic options – including web portals, FTP or electronic data interchange (EDI) – for submitting invoices and receiving contract information. This replaces an assortment of manual processes, including the DD250 material inspection and receiving report. In the past, when a military contractor shipped parts, they would do it through the DD250, but they are now going online and entering things directly with the WAWF.

Most aerospace and defense manufacturers today are not opting into EDI, the most automated of these three options, but they still need to make sure that their enterprise software gives them the option of moving in that direction. Even more critical than this is the requirement that the enterprise software package actually captures all of the data points required for WAWF, or other government transactions. Fields for all requisite data for WAWF and other reporting requirements need to be embedded in an enterprise wide application, used by aerospace and defense manufacturers, in order to avoid an endless process of manually chasing bits of information in disparate systems.


Borrow Payback
Within the framework of program-centric manufacturing, there are a number of even more exacting and unique requirements enterprise software must meet.

In the world of program-based manufacturing, real-time information is absolutely critical. As projects unfold, variations from a budget or timeline need to be noted as soon as possible, so that corrective action can be taken. The work breakdown structure we have discussed above is central to all aspects of this program management activity. For this reason the entire manufacturing process must automatically connect to that work breakdown structure. In this way, all of the information from those lower level supply transactions – manufacturing, subcontracting, and purchase – will roll up in real time, into the WBS. When there is any kind of deviation or exception, from the supply plan, the system needs to throw up an alert, providing clear visibility to the problem so that it may be efficiently dealt with. Aerospace and defense manufacturers require this level of traceability up and down the WBS as it relates to the entire manufacturing and purchasing cycle.

To accomplish this, standard materials requirement planning (MRP) is not enough. Project-based MRP or PRP (project resource planning) is also required. Not every enterprise software vendor attempting to sell to aerospace and defense manufacturers has this, and there are a lot of workarounds they may offer up to conceal this problem from prospective customers. Oftentimes, a software vendor attempts to run normal MRP by physical or logical locations, as a substitute for project MRP. This, of course, is only a work around and ultimately leads to problems as it does not consider logic such as a common inventory pool or borrow/payback between programs. Both the concept of a common inventory and the ability of project materials requirement planning (PMRP) to create at least suggested transfers to facilitate borrow/payback is not only essential for midsize or large aerospace and defense manufacturers, but should be a consideration for smaller companies interested in growing their involvement in the industry.

Adequate borrow/payback functionality gives a manufacturer the ability to define rules for what programs and, more specifically, what activities within programs can share inventory with what other programs. For example, you might have two programs – Program A and Programs B – for the U.S. Air Force. Program A needs a specific raw material on a given date, and Program B has that inventory. Additionally, Program B is not scheduled to consume that inventory until after it can be resupplied, therefore, you may be allowed to transfer that inventory into Program A. Once transferred into Program A, Program B will create a new demand for resupply. On the other hand, if you had a program for the U.S. Air Force and a second program for a different customer, regardless of whether the inventory is present and can be replenished in time, it may be against the rules to transfer it.


Conclusion
The needs of aerospace and defense manufacturers are substantially different from those of manufacturers serving other sectors. Similarly, enterprise software, like ERP, that is designed specifically for the defense contractors will exhibit a number of unique traits.


IFS North America
Brookfield, WI
ifsworld.com