Why you can’t force traditional ERP and MRP to run projects
An earlier blog outlined the differences between “regular” order-based manufacturing and project manufacturing. As a reminder, order-based manufacturing is oriented around, well, orders (e.g., jobs orders, production schedules). Project-based manufacturing incorporates a number of “orders” as well (including work orders, purchase orders and other activities), and they are used as control and reporting points. But with project-based manufacturing, the information collection and reporting are enabled through a project and its ingrained structure. The project structure, often defined in a Work Breakdown Structure (WBS) follows the project’s contract terms and milestones, and supports the required reporting, billing (progress billing, cost-to-complete estimate), and schedule tracking.
To be overly simplistic about this, work orders and purchase orders are attached to specific WBS elements and the costs and schedule accomplishments are passed from the order to the WBS through this link. Project status reporting comes through the WBS, which is tied to a timeline (think PERT chart).
While this simplified arrangement ties costs and schedule to the project, it does not address some of the material and accounting requirements that are a part of many contracts, especially those for government, military and aerospace customers.
Many government contracts require clear accountability of anything purchased or made for a contract. That is to say, a part purchased or made for contract A must be reserved and tracked as part of contract A and cannot be used for contract B or co-mingled with other contracts’ parts or “stock” parts. This goes completely against the basic approach of MRP and ERP which considers a part to be just a part and usable anywhere it’s needed. MRP logic has to be modified (losing out on economic quantity and basic availability logic) to keep contract parts separate and adhere to the accountability constraint. Either that, or each contract is treated as if it was its own plant, separate from all others (multiple MRP “instances” or “environments”). Alternatively, there are rules and procedures that may allow materials to be borrowed and replaced from/to a contract, but the process somewhat cumbersome and requires extensive documentation. Borrow/replace does not eliminate the need to restrict MRP as just outlined.
The bottom line is this: it is very difficult to force-fit “standard” MRP/ERP into a project environment because it doesn’t have the necessary project structure and reporting, and it does not support the material accountability requirements of many government contracting situations.
If you are a project manufacturer, does your ERP system thrive in your environment or do you engage in a lot of “work around” and outside reporting activities to comply with your customers’ requirements?