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—Woorking 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 month
finishing in november.
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—Woorking 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 month
finishing in november.
No comments:
Post a Comment