A CONFIGURATOR GENERATES CUSTOMER SALES AND MFG-ORDER DEMANDS FOR HOST

At the host location, the configurator server is gatewayed, linked, or included with the ERP system and independently maintains complete rule sets for all further processing. Each independent rule set volume should be separated for ease of maintenance compilation and security. It is very unlikely that certain rule data such as manufacturing costs will be allowed to go to the field. Likewise, complete B/M and routing rule sets are rarely deployed in the field. Upon receipt of the attribute string at the host site, the complete rule set of the configuration system can be automatically reprocessed, re-editing the field input for specifi­cation completeness and revision level conformity. A configurator server backlog file of all processed host line-item attribute strings must be maintained in either a quote or booked order status to accommodate any customer changes prior to shipment. Not surprisingly, experience has shown that subsequent change processing often more than triples the volume of original quote/order entry transactions.

With the same configurator software at both the field and host site, reprocessing then develops all of the to-order specification data such as (1) sales line-item pricing, (2) acknowledgment text, (3) cost-of-sales buildup, (4) B/Ms, (5) routings, (6) shop instructional text, and (7) CAD drawing attributes. This data is automatically updated in the host ERP/CAD/PDM system at the appropriate integration points as transactions occur. Normal ERP order entry often continues as if the onetime line items were normal finished goods part numbers with pre­determined B/Ms and routings for any configured variation. Manufac­turing orders can then be released to work-in-process (WIP) for classic material and labor tracking. Caution must be observed to accommo­date the huge amount of onetime structure records that build up in the host ERP system that may never be found or used again. Also, the exorbitant amount of maintenance that is associated with this approach should not be trivialized.

Various upload transaction files are developed by the configurator and formatted for acceptance by the host. First, the most time-critical transaction is the sales order entry (SOE) line item. There is often a need to keep sales order line items in the same sequence as the customer's original purchase order request (with intermixed stocked line items), or a desire to keep host control of the order number, credit checking, full order discounting, and so on. The home office order may then be started in the host system by setting up the normal header information from the customer file. As line items are entered, the host SOE system automati­cally passes control to the configurator as product families are entered that require configuration. Upon completion of the con­figuration editing, pricing, and acknowledgment text for­matting, the configurator immediately passes the trans­action back to the SOE system for inclusion in its back­log file. Any changes subsequently processed by the configurator over the life of the quote or order formats a replacement upload transaction for insertion into the SOE file.

If the SOE system is capable of processing EDI transactions, the upload procedure is drastically sim­plified. The configurator merely formats a conventional EDI transaction for host input and processes it in ac­cordance with regular EDI scheduling.

DRASTIC SIMPLIFICATION SEEN FROM MIGRATION TOWARD TO-ORDER FLOW FOCUSED FACTORIES!

As the host server configurator processes all rule sets, it generates formatted DEMAND output transactions (B/M-Rtg's for Mfg-orders) that can subsequently be uploaded to the host ERP system. A proprietary "BURBS™" (bottom-up/rules-based structuring) con­figuration engine architecture immediately generates these time-phased demands against load centers and real parts (instead of pseudos or phantoms) at the low­est "down-to" stocking levels. These transactions are generated asynchronously and can be uploaded on any frequency that the host can accommodate.

When the FLOW Focused Factory version of the configurator is in use (see option C, figure 2 and fig­ure 3), there is no longer any need to upload nor main­tain hard I/Ms, B/Ms, routings, or mfg-order files in the host ERP system. In the absence of these struc­tures (but with the availability of down-to componen­try on-hand balances and standard costs), the configu­rator will build up a configured line item cost-of-sales (COS) on the fly. It is then transferred as additional input data embedded in the line-item upload or EDI transaction.

All B/M and routing time-phased demands (allo­cations) are generated and selected by the configura­tor for immediate calculation of real-time scheduling: ATP (material available-to-promise) or CTP (simulta­neous material and cell loading for capable-to-prom-ise). The material and loading demands are jointly al­located, timed to the customer's request date in both a backward and forward scheduling process. There is also an option to calculate the critical path of all se­lected demands, so that material is not scheduled until it is required at the consuming operation. Any change to a sales order line-item backlog string processes as a complete pegged deletion and subsequent real-time reallocation of CTP demand.

Industrial-strength configuration systems that execute classic ERP demand planning and execution functions, without ever leaving the configuration software, were pioneered in the mid '90s. It is not incon­sequential that the pioneers of MRP (see About the Author) have been the first to re-architect this integration of configuration and demand file structure processing. It eliminates the need for cumbersome MRP host WIP file maintenance and batch processing. It takes a unique in­dustrial-strength configurator architecture to provide this event-driven regeneration and maintenance of the entire customer specified to-or-der component demand file. It replaces the need for MRP netting and lot-sizing of in-process levels.

The original '61 MRP process model, now inherent in all ERP sys­tems, was designed (by this author) for level-by-level gross-to-net (GNETS) requirements explosion. Replenishment lot-sized calculations were generated at each stocked or lot-sized level to further explode and drive requirements to lower levels. In customer-driven, "to-order" FLOW Focused Factories, this process is unnecessary since "gross-equals-net." The configurator now generates pegged demand directly against stocked or purchased to-order levels of raw materials and componentry. This eliminates the need to net inventory balances at intermediate levels. Most componentry are provisioned at these "down-to" levels through JIT (kanban and order-point) visual replenishment techniques! The benefits of this simplified approach are enormous!
As key down-to component inventory location balances and cell loading constraints are made available to the configurator (downloaded or ODBC-readable), CTP is calculated considering the entire backlog of pegged demands for any affected component or cell schedule. Any time-phased scheduled receipts can also be considered in the CTP logic; however, they may not always be applicable in JIT replenishment en­vironments. Since most of these in­tegrations over the past 10 years have been with legacy (non-ODBC) host systems, it has normally not been practical, from a gateway perfor­mance standpoint, to read the loca­tion balances or costs directly from the host. Instead, a small file of se­lected key down-to component bal­ances is normally downloaded each night along with the component costs. As host systems become ODBC compliant, these integrated reads and backflush updates can be performed directly to the ERP host within the same server as if it were in the same system.

To Be Continued

For balance of this article, click on the below link:

Lean Manufacturing Articles and go to Series 01