Federal Contract Management and Vendors' Readiness Part One: Entry of Small Vendors into Federal Contracts

Event Summary

In the market for application software there is a large number of small, highly focused vendors. The business model for these vendors focuses on a relatively small, tightly defined market with specific requirements that cannot be met with more generic products. These specialists, boutique, or niche vendors (neither of these terms is meant in a derogatory manner) will compete by having in-depth product functions and intimate knowledge of their market place, or by offering services (with regard to content or location) not available from the Big Few or large independent service providers. When these vendors go for enterprise resource planning (ERP) and like solutions to help improve the business of small, midsize, and large aerospace and defense (A&D); engineer-to-order (ETO); contract manufacturing; maintenance, repair, and overhaul (MRO); and like project-oriented manufacturing companies they may face the need to meet government contract requirements.

Despite arguably still ongoing difficult economic times in most sectors, the growth of government contract manufacturing has continued largely unabated. For instance, while the commercial aircraft industry may have suffered following the dreadful 2001 terrorist attacks and stalled economic activity afterwards, it is quite the opposite case in the defense and government industries (see Fed Warms Up to ERP Spending, but Will Contractors and Their ERP Vendors Comply?).

The federal market opportunity thus comes as no surprise given that it has long been the segment with low penetration of off-the-shelf, integrated enterprise applications, since during the salad days of economic boom and federal surplus, agencies, contrary to their private sector or commercial counterparts, have not had many qualms about devising large-scale, fragmented, homegrown, maintenance-intensive informational systems from scratch. The times have drastically changed almost overnight and cost-cutting remains one of the most important reasons why agencies are implementing ERP systems.

The other reasons why ERP has recently become a far more attractive option for the federal market might be the fact that this market has benefited by vicariously learning from mistakes and failed ERP implementations in many commercial companies in the past. Additionally, many ERP systems are now componentized, which provides phased implementations in more manageable chunks—instead of a traditional big bang' approach—in addition to vendors' developed implementation methodologies, which are based on bypassing the usual traps of past failures.

Meanwhile, many ERP systems have also been Web browser-enabled, which also allows for a quicker and simpler implementation, because client machines do not have to be configured time and again. Further, the leading ERP vendors have incorporated customer relationship management (CRM), supply chain management (SCM), business intelligence (BI) and analytics, and many other extended-ERP modules by developing them in-house, by acquisition, or through strategic partnerships with the best-of-breed vendors.

This is Part One of a three-part tutorial.

Part Two will cover dealing with the federal government.

Part Three will discuss the challenges and make user recommendations.

Project and Contract Manufacturing

The A&D opportunity has rigorous requirements involving project- and contract-based complex manufacturing industries. As an illustration, A&D producers are typically high-tech or electronic manufacturers, and must handle complex production processes and large, complex supplier networks, albeit the supplier integration is still seriously lagging in the industry. Sophisticated customer order management applications are typically not required. Instead, customer service needs are more oriented toward precise contract management and cost reporting. Frequent changes force contract supplier engineers and original equipment manufacturer (OEM) engineers to be in constant collaborative communication throughout the design and production cycle of the unit.

One of the most manual functions in a supplier organization is the sell-side request for quote (RFQ) management, which usually revolves around a few key individuals who have direct knowledge of the product or who can manually pull together the diverse information sources into a unified document. The combination of outsourced manufacturing with increasingly common construct-to-order (CTO) or build-to-order (BTO) production environments is making unit-level data management an increasingly high priority for contract manufacturers and the companies that retain them, while additional tracking and reporting requirements are another big issue.

A number of articles on the TEC site have incisively depicted the peculiar traits of ETO and project-based manufacturing, such as Project-Oriented Versus Generic GL-Oriented ERP/Accounting Systems and Caution! Will A Traditional ERP System Help You Deliver Projects?

The APICS dictionary defines ETO as "products whose customer specifications require unique engineering design, significant customization, or new purchased materials. Each customer order results in a unique set of part numbers, bills of material, and routings." A closely related term to ETO is project manufacturing, which is defined as "a type of manufacturing process used for large, often unique, items or structures that require a custom design capability (ETO). This type of process is highly flexible and can cope with a broad range of product designs and design changes "

As already stated in TEC's earlier research article ERP Systems and the ETO Manufacturing Market, a vast majority of manufacturing-oriented ERP systems have been largely amenable to repetitive, volume-based manufacturing environments that rely on the movement of materials either through functionally-oriented work centers or product-oriented production lines, and are designed to maximize efficiencies and lower unit cost by producing products in large lots. Standard products with similar routings are therefore made using virtually the same process, while production is planned, scheduled, and managed to meet a combination of actual sales orders and forecast demand.

Thus, vendors that will prosper in any given market segment will have focused their business and product on a few particular manageable industries (possibly only a single one for the smallest vendors), instead of a more generic, horizontal approach. There is a general consensus in a number of diverse industries that generic solutions require longer implementation timeframes, more customizations (or, possibly even worse, workarounds, and related dreaded backdoor knowledge just to keep the system running), and the complication of add-on solutions. Winning ERP and other enterprise applications products will thus demonstrate deep industry functionality and tight integration with best-of-breed bolt-on' products in a particular vertical, which also means adding sector-specific, fine-grained capabilities.

As a matter of fact, verticalization can be seen as part of a larger effort by most enterprise application vendors to ease the implementation of their products. That happens, in part, because the larger, generic ERP packages usually arrive needing to be configured for the business and the industry entirely from scratch. At least by configuring parts of the package in advance for a given industry and circumventing functions not required in that industry, these vendors can shorten and ease the implementation process.

Watch Out For the Fatal Flaws

This brings us to the so-called "fatal flaws", which are missing functions that may make it extremely difficult if not impossible for the application software to run the physical business. For more details, see Find the Software's Fatal Flaws To Avoid Failure. The fact remains that ERP products built for repetitive manufacturing need a lot of customization to even begin to adequately handle the peculiar, often one-time requirements of custom-engineered products.

A number of these ETO fatal flaws or showstoppers are close engineering, manufacturing, and purchasing collaboration and management as to collapse product lifecycles; project management and scheduling capability; the ability to compare actual and estimated or budgeted costs; revenue recognition and progressive billing by milestones; management of an immense number of engineering changes; strong estimating and quotation capabilities that include freight and duty; support for subcontracting (or nowadays the less popular word "outsourcing"); part numbering flexibility (to such a degree that bills of material [BOM] can be created even without part numbers); handling shipment straight from work in progress (WIP) and without posting to inventory; ability to attribute costs to projects as to financially quantify modifications upon customer request that varies from the original specification; visibility of proposals, open orders, and materials (including the estimated-to-complete); and so on.

As indicated earlier, the unique business needs of project-oriented organizations, when addressed by large ERP vendors that offer general-purpose enterprise software, typically require heavy customization in order to work. On the other hand, when project-oriented organizations turn to small off-the-shelf project management solutions, these solutions are soon outgrown by the user company. These organizations are looking for systems to support the project manager, who is responsible for sharing and tracking the revenue, expense, and profitability of a project.

Project-oriented organizations have many project-specific business and accounting requirements, including the need to track costs and profitability on a project-by-project basis, to provide timely project information to managers and customers, and to submit accurate and detailed bills or invoices, often in compliance with complex industry-specific and regulatory requirements. Yet, traditional generic general ledger (GL)-oriented ERP or accounting systems have not been designed with project phases, work breakdowns, or detailed time capturing in mind, and thus, they merely can report how much it has been spent or collected, but not why certain project is losing or winning money.

Typically, a project control module lets users associate inventory items, sales orders, work or production orders, purchase requirements, and purchase orders with each project, while with project-oriented material requirements planning (MRP), often called project requirements planning (PRP), users have the flexibility to plan by project or not. Certain common or standard items can logically be planned without regard to projects to increase purchasing or manufacturing efficiencies. Still, the project control module will control allocation of material or finished subcomponents to any specific projects, and, ultimately, each manufacturing work order and purchase order line will be associated with an individual project.

To that end, project-oriented organizations are looking for systems that offer maximum efficiency in project-oriented environments, including capabilities that enable advanced estimating, measuring, controlling, and reporting by department, project, and, if required for some projects, at the task or work breakdown levels. In other words, going a mile further or so, the software's capability to use time-stamped data for all time-sensitive activities including inventory, costs, shop orders, etc., helps managers examine costs against time-lined budgets, right down to the task level.

This concludes Part One of a three-part tutorial.

Part Two will cover dealing with the federal government.

Part Three will discuss the challenges and make user recommendations.