Integrated Solutions: Look Before You Leap

Introduction

Smaller manufacturers prefer a system that integrates enterprise resource planning (ERP) and parts of a manufacturing execution system (MES), which, according to Manufacturing Enterprise Systems Association (MESA International) is any system that uses current and accurate data, triggers, and reports on plant activities as events occur. From electronic production management systems to shop-floor data capture, MES functions manage operations from point of order release into manufacturing to point of product delivery into finished goods.

The possibility of integrating and providing all elements of a complete manufacturing solution—at least from a same source if not a single computing platform—has always been tempting, and potentially lucrative. However, it has never been delivered, not even by once mighty automation provider Invensys, who once had the respective ERP and MES products of Baan, Marcam, Avantis, and Wonderware, under its roof, which were never delivered together (see The Name and Ownership Change Roulette Wheel for Marcam Stops at SSA Global—Part Three: Last-Ditch Effort by Invensys).

Presently, IQMS (http://www.iqms.com), a privately-held, Paso Robles, California-based (US) company, may be unique in the ERP arena, and not only within its mid-market realm. It is the developer of EnterpriseIQ, a well-attuned, extended-ERP system for small and mid-size plastic processors and repetitive manufacturers and provides the powerful IQ RealTime Production Monitoring module, which ensures plant efficiency by identifying poor machine performance before it becomes a problem. For a discussion of the benefits of a system such as IQMS offers, see Manufacturer's Nirvana Real-Time Actionable Information.

The potential benefits of the intrinsic integration of ERP with the plant floor and of achieving near real-time information are multiple. For one, such a system could transfer many data entry functions that are traditionally performed in the office, directly to the manufacturing floor. This would, for example, allow material personnel to transact the issue of resin to and from machines on-line instead of submitting the transfer paperwork to the office where it would be entered into the system the next day. Furthermore, the material could be classified immediately within the system, therefore giving production planning a real-time inventory of materials.

Production counts can also be automatically updated with the system and verified by machine operators. This can give supervisors constant feedback on how their shifts are performing. Production reports for completed jobs can then be generated and analyzed the day after the run is complete, whereby with a non-integrated system, this process would typically lag production by a few weeks.

All of this should bring the production floor and the financial and planning departments closer together because they are working "shoulder to shoulder" instead of passing outdated paper back and forth. This could also encourage discussions on how to improve and do things internally instead of both teams continuing to function in their separate worlds, which leaves the "office staff" unaware when a machine goes down or if a shift's production is far off target.

Integration Is Not Easy

While this discussion has laid out the importance and desirability of integration, developing the necessary application programming interfaces (API) between diverse applications is no small feat. It involves interfacing two or more disparate systems and getting them to "talk to one another", which is a job that often falls into the lap of the information technology (IT) department, perhaps helped by vendors. Interfaces typically resemble a batch file upload process, with data mapped between two different systems so that they can understand each other. Data mapping is almost always custom work and an unnecessary "reinvention of the wheel", since the structure of the data is always, more or less, unique between various vendors' products. The interface, once written and tested, is valid—at least until the vendor(s) change something in the software as part of a product update. When that new versioning happens, the immense customization effort (or annoyance) starts all over again.

While some larger, complex enterprises, with a variety of unrelated businesses and divisions, may need a best-of-breed solution to flexibly extend their activities into e-collaboration, managing this large application portfolio is cumbersome to say the least. Much of it involves partnering or extensive integration and customization. While the best-of-breed approach can have its merits (see Best of Breed Versus Fully Integrated Software: The Pros and Cons , Single Source or Best of Breed—The Debate Continues, and Pure-Play CRM Vendors: Choose an Integrated or Best-of-Breed Solution? ), we believe it consistently leads to additional integration costs and complicates service and support arrangements. As depicted above, interfaces between components like ERP, customer relationship management (CRM), warehousing management systems (WMS), MES, or e-business usually require significant tailoring. This can be a barrier to future changes as revising already-modified code is notoriously time consuming, costly, and risky. Moreover, there are also occurrences of these product concoctions having a different "look-and-feel" across the range.

Furthermore, the enterprise applications integration (EAI) market is still nascent and fragmented, burdened with difficulties despite the advent of service-oriented architectures (SOA) and Web services (see Leveraging Technology to Maintain a Competitive Edge during Tough Economic Times—A Panel Discussion Analyzed). These caveats speak to the complex nature of EAI software and the power struggles that are currently taking place in the market. For example, there are indications that more than a dozen dialects of extensible markup language (XML) standards exist.

To summarize, this bad news about interfaces comes from the need for continuous management and upgrade coordination, an increase in IT support staff, multiple software company maintenance contracts, and complications with report writing. Moreover, one should beware of the inancial (in)stability of multiple software providers. All involved providers may have different, even diverging individual business strategies.

Conversely, a fully integrated extended-ERP product like IQMS's EnterpiseIQ might almost completely eliminate all of the above issues for a small or medium, repetitive manufacturing enterprise with a scarcity of IT-skilled resources. Namely, when data is stored in the same database, there is no need to create and manage ungainly interfaces, because there is only one master application. Data visibility becomes inherent, since with the proper links, data can be gathered and disseminated in multiple ways, without delay.

But, in most cases, multiple databases on the shop floor (such as, quality management data, production and warehousing real-time transactions, plant maintenance data, ERP master data, etc.), are rarely in sync, making timely decision-making difficult and often inaccurate when it does occur. This holds true any time information is kept in more than one location, since without a highly advanced method of synchronization, the chances of having accurate data stored in multiple locations are small indeed.

If data are only synchronized on a daily batch mode basis, or even by shift, managers have a difficult time making timely, accurate decisions. As a result, all functions such as production planning, shipping, inventory control, and purchasing are impacted and customer service representatives are handicapped in their role as they attempt to serve customer requests about order status. In the worst cases, some data is never synchronized to the master ERP system, which creates a serious communication void and promotes the proverbial, and likely the worst situation of so-called "islands of automation". In this scenario, various groups under the same roof concern themselves with only their records and responsibilities, and never collaborate to address the total environment in a unified way.

Still More Challenges

Moreover, there is more to the best-of-breed versus integrated suite dilemma than data synchronization. Electronic data interchange (EDI) capability has become a required (and far-from-pleasant) task for some high-volume industries, like automotive suppliers. It has been made evermore dangerous by the amount of work that must be dedicated to ensure incoming and outgoing messages are handled accurately. Namely, all EDI solutions from traditional value-added network (VAN) providers like General Exchange Services (GXS), SPS Commerce, Sterling Commerce, or Inovis provide the fundamental translation process, converting incoming files (such as schedule releases and forecasts) into something readable and understandable. At the same time, it converts outbound data (such as invoices and advanced shipping notices) into an acceptable format for receipt by the supplier.

For a more inclusive discussion of this see The Pain and Gain of Integrated EDI.

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

Thus, this implies extensive use of resources on both sides of the table—the enterprise software vendor supplying the interface must write and test custom code, and the user (such as an automotive supplier or customer) must test and re-test the interface thoroughly until it works consistently. However, with an intrinsic EDI system within the ERP product, the third party software costs are virtually non-existent, and the time it takes to build the custom interface is drastically reduced, since those building the interface are working from within the ERP system. The knowledge of data structures and business logic is inherent.

Still, an "airtight" system which addresses all these challenges could also trigger a sort of "identity crisis" for the vendor. Targeting smaller enterprises with technologies and a well-rounded product that is more amenable to the upper-end of the market can be viewed by the smaller enterprises as being "too much of a good thing." Namely, the tight integrated nature of the product and high interdependence between modules, which cannot be that easily decoupled or turned on and off might be too overwhelming for some prospects that might not need many of the core modules.

Also, for example, with IQMS's EnterpriseIQ system, some transactions within the system are not reversible after a user has made an error. This makes the training and proficiency of users critical, given the gravity of an error's promulgation within the closely-knit system on Oracle Database. This might be a deterring factor despite the system's relative ease of use and the favorable ratio of software license fees versus implementation costs of 2:1. In these cases, prospects might prefer a less functional but more flexible and customizable solution on Microsoft technology. Often, buying a completely integrated solution is not an option when the companies have either an accounting or project-management system in place, which they will not simply rip-and-replace.

User Recommendations

When it comes to integrated enterprise systems, functionality is not exactly unimportant, but it rather needs to be combined within a fairly simple-to-use application set that actually gets used rather than languishes on the shelf.

Repetitive manufacturers should think carefully when selecting an ERP system. Given the maturity of the ERP market, its ongoing consolidation, and the fact that competitive advantage is hard enough for manufacturers to find, companies should not compromise on their requirements. Small and mid-size enterprises should especially ask hard questions about the scope of an ERP system, and how it supports high-volume idiosyncrasies. The less time they spend interfacing their ERP system with other software systems such as quality systems, preventive maintenance, document, and workflow management, the happier they will be. After all, a new system should always be about improving the business and not a mere technology initiative.

The vendor that listens to your needs instead of telling you what "cool things" its software can or cannot do, and speaks your language using your terminology and vernacular (e.g., cavity, family tool, a cycle time in seconds, a product weight in grams, etc. for plastic processors) is a good candidate to be a vendor that understands your business. Still, as a sort of a litmus test, prod each vendor to tell you what percentage of its sales belong to your industry. Vertical focus indicates that software contains industry-specific features and that ERP vendors have certain industry expertise.

Also, in implementing an industry-specific application, it is important to ensure that the application provider's implementation team includes members with in-depth knowledge and experience in that industry. Vendors geared toward certain industries should have solid integration skills or strong relationships with systems integrators that have industry-related expertise. This should significantly streamline implementation time by eliminating a lengthy vendor or integrator learning curve.