When EDI Goes Native, Everything Falls in Sync with IQMS

The Pain and Gain of Integrated EDI

IQMS, a small, privately-held company operating out of Paso Robles, California (US) has marked itself differently from other enterprise resource planning (ERP) vendors by offering native modules where other vendors only provide third-party solutions. Generally, embedded third-party solutions are leerily regarded, especially by small and medium enterprises because third-party batch interfaces tend to be cumbersome. IQMs' use of native modules is, therefore, a welcome achievement.

Part Five of the IQMS Prospers by Helping Enterprises Work Smarter series.

However, while its native modules provide a "single view of the truth", there is more to this best-of-breed versus integrated suite dilemma than data synchronization. Being electronic data interchange (EDI) capable has, for some high-volume industries like automotive suppliers, become a required, though far from pleasant task. It is made even more dangerous with the amount of work needed to ensure that incoming and outgoing messages are handled accurately. EDI solutions from traditional value-added network (VAN) providers like GXS, Sterling Commerce, or Inovis provide the fundamental translation process, converting incoming files, such as schedule releases and forecasts, into something readable and understandable. Simultaneously, it converts outbound data, like invoices and ASNs into acceptable formats for receipt by the supplier.

Still, this readable data is only partly good for ERP systems, since the real action is in merging the new data with existing information that is already being processed within the ERP system. The ensuing challenge is to make sense of the daily, constant flood of EDI messages. In high volume environments, this can consist of hundreds of records affecting the releases and forecasts of hundreds of parts. It becomes infeasible to manually enter this data into the system, and therefore, an additional interface must be developed and tested. Yet, unlike an interface that updates or synchronizes inventory levels or product quality information, this interface has to do more than statically map data. It typically involves the extensive use of business rules and logic established between every customer and supplier. That is to say, the highly personal nature of the data means that no two interfaces are exactly alike, further complicating the matter.

Thus, resources must be extensively used on both sides of the table—the enterprise software vendor supplying the interface must write and test custom code, and the user must test and re-test thoroughly until the interface is working consistently. This is taxing not to mention expensive, especially for SMEs with limited IT staff and resources. However, with an intrinsic EDI system within an ERP product, the third-party software costs are virtually non-existent. Moreover, the time it takes to build the custom interface is drastically reduced, since those building the interface are working from within the ERP system, and have inherent knowledge of data structures and business logic.

Consequently it is amazing that the small ERP vendor, IQMS, such a module. Its native IQ EDI module supports ANSI X12, EDIFACT, and Odette file formats. Taking into account the importance of emerging technologies (see EDI versus XML—Working in Tandem Rather Than Competing?), IQ EDI is XML-enabled and supports file transfer protocol (FTP) for the transmission and receipt of files. The system generates and processes virtually all commonly required transaction sets. For inbound X12 format, and DELFOR (a delivery schedule message from a buyer to a supplier about product requirements) and DELJIT (delivery just-in-time message which relays the precise delivery sequence of a JIT schedule) EDIFACT transactions, the system supports remittance advice (820); planning/release schedule (830); purchase orders (850); change orders (860); shipping schedule (862); order status report (870); receiving advice (861); functional acknowledgement (997); cash application (824); and text message (864). For outbound transactions, it supports invoicing (810); planning/release schedule (830); shipments (ASN) (856); order acknowledgement (855); and vendor shipping schedule (865). Functional acknowledgement (997) for X12 and DESADV (dispatch advice message)—a message specifying details for goods dispatched or ready for dispatch under agreed conditions—is also supported.

Further, due to inherent integration with the rest of the EnterpriseIQ ERP suite, outbound transactions are sent directly from the system, that also includes template-mapping tools. Moreover, the need for third-party translators—which are a default for the vast majority of ERP systems requiring third-party EDI solutions—is eliminated. Demonstrating its industry savvy, the suite is based on the AIAG supply chain business practices and a number of flexibility business rules generate exceptions. For example, flags and reports can be sent when there are dramatic quantity changes in EDI transactions or to identify when user-defined limits (set either as a range or a percent) on quantity increase or decrease has been hit. Logically, the orders that comply with the rules are passed through to the sales module, while the orders that do not comply, get flagged.

Finally, rules can be setup either for each EDI transaction code number or for each customer. IQ EDI is an integrated component within EntepriseEQ, supporting the capability to translate files that are downloaded directly from a Web site or through the traditional EDI mailbox setup with a VAN provider. One should note, however, that IQMS does not provide communication nor maintain the mailbox. This is one instance where a third-party communications system (i.e., VAN) is required to perform this service.

Nonetheless, adding to its list of EDI accomplishments, IQMS successfully completed the EDI certification process for Honda North America, whose extensive testing and certification process ensures that suppliers meet the automaker's exact specifications for JIT manufacturing with seamless communication and data integration. To that end, IQMS completed the multistep test procedure with its EnterpriseIQ ERP software in less than six months, finishing in November.

This is Part Five of a six-part note.

Part One presented the company background.

Part Two began a discussion of the market impact.

Part Three continued the discussion presented more product differentiation.

Part Four covered the single database system and quality management.

Part Six will present challenges and make user recommendations.

Miscellaneous Utilities

In addition to the IQ EDI, EnterpriseIQ also offers a number of useful utilities, such as the IQAlert notification system, with many nifty business activity monitoring (BAM) features (see Business Activity Monitoring— Watching the Store for You). For example, appropriate persons are alerted of low inventory levels, missed shipments, late or pending purchase order receipts or other burning issues. It can also schedule unsupervised tasks like running an MRP engine, EDI processing, or creating database backups late at night.

Another notable utility is IQ Enterprise Plant for multiple facilities or companies. EnterpriseIQ provides extensive interplant capabilities for complex organizations throughout all modules. Accordingly, this allows multiple plants or companies to use a single database to centralize data storage, and administration and reduce redundant activity across multiple sites. That is to say, multiple divisions can exist in a single company, and multiple companies can exist in a single business entity, whereby each division contains its own BOMs, tools and dies, inventory, cost, supply, schedules, and production records. This allows for multiple facility and distributed manufacturing, because sales and purchasing operations can be centralized and de-centralized concurrently, while forecasting, master scheduling, and MRP can function separately for each division (or across divisions) for interplant requirements.

Users can view location-specific or plant-wide information, while financial statements will then show the financial condition of each company, as well as any combination of companies within the business entity, since interplant transfers are streamlined with the GL rollup. From a technology side, the system uses Windows Terminal Server (with Citrix Metaframe) operating across wide area network (WAN).

Other utilities worth mentioning include the e-mail capability, label generation and printing, internal/external document linking, data export capability, user defined fields/forms, the UPS shipping link, an underlying security system, detailed transaction log, external file import capability, external payroll interfaces, and so on.

More about Repetitive versus Project-based Requirements

Although IQMS focuses on repetitive environments, there are some basic job shop and simple project capabilities JobShopIQ and Project Manager modules have that help create, track, and manage discrete manufacturing projects from quote creation through work order completion. For example, it can track a special sales order for a special tooling. Accordingly, these modules feature manufacturing resource planning (MRP) and scheduling capability with exception requirements, multiple level tasking with financial rollup for task-by-task detail tracking and up-to-date project-based financials. They also have direct links to labor reporting, inventory, preventative maintenance, accounting and purchasing.

Still, EnterpriseIQ has 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 by using virtually the same process, while production is planned, scheduled, and managed to meet a combination of actual sales orders and forecast demand. As a result, production orders stemming from the MPS and MRP planned orders are "pushed" out to the factory floor and into stock. External suppliers also work to support planned production, while materials management often relies on maintaining sufficient inventory, using a make-to-stock (MTS) as well as a make-to-order (MTO) or occasionally with the assemble-to-order (ATO) approach of keeping standard items or sub-assemblies in stock.

In these manufacturing environments, the time and cost of changeover to produce different products is high, as are the costs of inventory, planning, and expediting. The focus is thus on the efficient scheduling of production lines rather than on managing individual orders. Minimal necessary reporting points are also used to determine average or standard costs, and occasionally standard cost variances. Consequently, goods are pushed through production at levels determined by (often inaccurate) scheduling and forecasting tools common in MRP/ERP systems. These levels then often exceed demand, resulting in building excess finished inventory. In a flow/lean/JIT environment, orders are pulled through the process based on actual demand, which may alleviate the above inventory conundrum (see Pull versus Push: a Discussion of Lean, JIT, Flow, and Traditional MRP). Also typical of repetitive environments is the purchase of material for inventory and the issue of material for work-in-process (WIP). When manufacturing is complete, the finished goods are moved from WIP to the finished goods inventory before the shipment to the customer.

Further, although prior to any manufacturing, there is extensive work in the product definition phase (such as estimation, design, and engineering) before anything can be made or bought/delivered. The major difference is that within complex engineer-to-order (ETO) or project-based companies, the product design is an integral part of production, and at times, even continues during the site installation and commissioning. In the case of repetitive, standard items, the design is typically completed and handed "over the wall" to manufacturing well before the production starts. Therefore, in volume manufacturing the product definition work will be amortized (recovered) over the items' life cycles, which are often measured in thousands of items and over several years of commercial use.

Whilst a time overruns can potentially effect the product's time-to-market, which is often a competitive advantage (strategy) and lowers costs for repetitive manufacturers, the overrun has no effect on the overall lead-time of any particular sales, job, or project order. Thus it is not handled in the same way. Moreover, the extensive costs of product definition are absorbed into the company overhead or standard product costing, so that an overrun of costs can be managed in the context of a long term pricing strategy.

In the rigid systems of repetitive manufacturing, implementing a change to a bill of materials (BOM) or routing requires canceling all the effected open, closed, and in-progress orders and re-creating them with the new information. This in itself can create countless hours in administering the ERP system. Changes are handled differently in the case of project manufacturing, in terms of deep, multilevel ETO BOMs versus flat BOMs for repetitive items. However, by no means does this imply that in repetitive manufacturing planning and re-planning are simple activities, given one has to take the maximum or optimal utilization of plant, equipment and absorption of overheads into account. Both have their complexities.

This concludes Part Five of a six-part note.

Part One presented the company background.

Part Two began a discussion of the market impact.

Part Three continued the discussion presented more product differentiation.

Part Four covered the single database system and quality management.

Part Six will present challenges and make user recommendations.