White paper. for your defense manufacturing business

Transcription

1 White paper Selecting ERP for your defense manufacturing business

2 content Program Centric Manufacturing... 1 Reporting... 3 Project MRP/Borrow Payback... 4 Conclusion... 6 About IFS... 7

3 Selecting ERP for your defense manufacturing business By Denis Lofthouse Business Solutions Consultant 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. The growing trend of all segments of the military is to subcontract as many of the logistical services associated with weapons systems and capital assets as is practical. While this trend started, many contracts were firm fixed priced. But as this new method of operation has matured, the military has learned that the 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. This means contractors logistic system must 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). In this white paper, we will discuss how the unique characteristics of a defense manufacturing operation lead to separate and distinct needs in the area of enterprise software including enterprise resources planning (ERP) and software for maintenance, repair and overhaul (MRO) and maintenance activities. Program Centric Manufacturing 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, at least in the beginning of a contract, in an engineer-to-order (ETO) environment. The company will be making something typically either as a subcontractor on a program, or directly to some echelon of the military, on a military program as the 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. 1

4 Some of those common issues are the segregation of the inventory for programs, tracking customer or government furnished inventory or equipment (GFM and GFE) or customer furnished material and equipment (CFM and CFE). Additionally, enterprise software must keep track of under what circumstances it is allowable to transfer inventory between projects or programs, and what are the borrow and payback rules 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 (WBS) 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, these costs may be difficult to attach to a particular program and analyze, as they would commonly just be considered indirect cost or overhead. That WBS, which is central to all aspects 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 WBS and substructures must be robust enough to track funding or a budget, and must also track the actual costs and time frames. Moreover, the structure must be able to provide estimated future costs and completion time frames during pursuit of and throughout the execution of the program in terms of dollars and time. Keep in mind that the whole concept of generating a bid from a budget, typically defined from an engineering bill of materials (BOM) and an estimate of the time commitments required of different skill levels, for something where you are going to be engineering a product, doing a limited production run and then executing through an ongoing production run is a little bit different because you are responsible for the operations cost of your internal resources, including the broad array of people who will touch that project. This means that the actual costs must be continuously monitored and tracked against the budget. Additionally, a WBS also needs to account for the concept of subcontracting, a practice that is growing enormously as the military and in turn its prime contractors seek to outsource more and more activity under PBL (performance based logistics) or similar types of contracts. It is not uncommon to subcontract services such as engineering to an external vendor, but that engineering work will only be one small portion of a much larger program. That subcontracted service must then become one segment of that much larger WBS. The work of that subcontractor, along with any work they pass to lower, 3rd or 4th tier subcontractors they might in turn be using, must be tracked with the same level of detail as work performed in-house. This is necessary in order 2

5 to be certain they are meeting their scheduling progress and actual costing requirements as are other aspects of the program that may be performed internally. Just as the military is moving to make contracts incentives payable according to the earned value contractors have contributed, prime contractors are pushing this requirement to perform down to their subcontractors. This cascading progression must be reflected within the WBS, and can, in many cases, become very elaborate. Enterprise software 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. There are reporting requirements related to all aspects of the program, including: progress against contracted work, tracking of inventory GFM, and GFE, tracking the degree to which supply chain partners qualify as small businesses, disadvantaged businesses, minority-owned businesses, and other classes of business, and the automatic flow down of contract terms and Defense Priorities and Allocations System (DPAS) rating information for the related purchase agreements and shop orders for prioritization, just to mention a few. Some of the more common reports that an enterprise application used by aerospace and defense contractors should as a base support include, but are not limited to: SF294 Subcontracting Report for Individual Contracts. SF295 Summary Subcontract Report. OF312 Small Disadvantaged Business (SDB) Participation Report. DD1149 Requisition and Invoice/Shipping Document. 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. 3

6 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 EDI (Electronic Data Interchange) 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 methods, but still ought to make sure that their enterprise software gives them the option of moving in that direction. Even more critical than this, though, is the requirement that the enterprise software package actually captures all of the data points required by the given 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. Project MRP/Borrow Payback Within the framework of program-based manufacturing, there are a number of even more exacting and unique requirements enterprise software must meet in order to facilitate profitable completion of programs and adherence to government rules on handling inventory. 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 WBS 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 WBS. This allows all of the information from those lower level supply transactions (manufacturing, subcontracting and purchase) to 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. The most logical place to provide that visibility is directly from the graphic representation of the WBS. This indicator, having outlined where in the WBS an exception has occurred, must then allow the program manager to drill into the detail of that exception. For example, a program manager looks on their portal to 4

7 check that status of the programs they are responsible for, and in doing so, perhaps that program manager finds an exception on one of the subprojects in the structure. Drilling into that subproject and then further on into the exception, the program manager may find that a shop order is now scheduled to complete late. Drilling into that shop order directly from that same WBS, the program manager finds the reason that the shop order is late is due to a material shortage. Drilling from the shop order, he now sees that the purchase orders on their long lead time items are late and additionally the expedition of those PO lines has caused the dollar amount to exceed the budget. Knowing this, the program manager can take the appropriate actions to insure the situation is corrected. In a non-real time environment or worse, one in which several disparate systems are used it could be days or even weeks before the issue is realized. 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 level of real time visibility, standard materials requirement planning (MRP) is not enough. Project-based MRP (or PRP) 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 workaround that 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 PRP 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. So for example, you might have two programs for the US Air Force, and Program A needs a specific raw material on a given date, and Program B has that inventory, and additionally that program B is not scheduled to consume that inventory until after it can be resupplied, then 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. There may also be rules regarding which program will bear any increases in the raw material price. Typically the borrowing program will bear that increased cost. On the other hand, if you had a program for the US 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. To efficiently manage this type of logic the system must be able to define and enforce the rules, automatically, or with automated workflow between the programs. 5

8 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. The points above, if considered during enterprise software selection processes, will help determine which products will best serve your needs. A final consideration mentioned last but far from least in importance is a history of past performance, proven success. Nothing succeeds like success, and a history of successful implementations and usage in the aerospace and defense industry may be one of the best predictors of how well a particular vendor s solution will perform in your own organization. In the end, there are many different mechanisms that may be applied to accomplish the level of control defined above, but in the end, your defense contractor s customer really wants to know: Will my inventory be available, where I need it, when I need it? This is in fact the reason why subcontracting within the DoD is on the rise, so that the military can get on with their business and not be forced to apply needed resources to become expert in managing manufacturing, supply chain and MRO businesses. Denis Lofthouse is a Business Solutions Consultant at IFS North America working in the Defense Group. Denis holds a degree in Computer Electronics Engineering and a CPIM from APICS. Denis has been working in the defense industry providing logistic solutions and consulting for over 20 years. 6

9 About IFS IFS is a public company (OMX STO: IFS) founded in 1983 that develops, supplies, and implements IFS Applications, a componentbased extended ERP suite built on SOA technology. IFS focuses on agile businesses where any of four core processes are strategic: service & asset management, manufacturing, supply chain and projects. The company has 2,000 customers and is present in more than 50 countries with 2,700 employees in total. Net revenue in 2009 was SKr 2.6 billion. More detales can be found at For further information, to info@ifsworld.com Americas Argentina, Brazil, Canada, Mexico, United States Asia Pacific Australia, Indonesia, Japan, Malaysia, new Zealand, Philippines, PR China, Singapore, Thailand Europe east and central asia BALKANS, Czech Republic, GEORGIA, Hungary, Israel, KAZAKHSTAN, Poland, RUSSIA, Slovakia, Turkey, UKRAINE Europe Central AUSTRIA, Belgium, GERMANY, ITALY, netherlands, SWITZERLAND Europe West France, Portugal, Spain, United Kingdom Middle East and africa India, South Africa, Sri Lanka, United Arab Emirates Nordic Denmark, Norway, Sweden Finland and the Baltic area Estonia, Finland, Latvia, Lithuania This document may contain statements of possible future functionality for IFS software products and technology. Such statements of future functionalit y are for information purp oses only and should not be interpreted as any commitment or representation. IFS and all IFS product names are tr ademarks of IFS. The names of actual c ompanies and products mentioned herein may be the trademarks of their respective owners. IFS AB 2010 En Production: IFS Corporate Marketing, March 2010.