Click Image to Enlarge
ERP Evolving Into Something More ERP's expansion today involves six elements that touch business, application, and technology strategies.
The acronym "ERP"—for enterprise resource planning—was defined in 1990 by Gartner, Inc. (Stamford, CT). That was then. This is now. Gartner's Research Director in the Business Process and Applications Group, Brian Zrimsek, sees three major changes affecting ERP now:
1. Process extensions. "Today, ERP is still for the enterprise, but the enterprise is changing. It's becoming more virtual." Consider how the OEMs are outsourcing aspects of car design and the rise in contract manufacturing. Both of these business processes span physical enterprise boundaries. "ERP starts to struggle as you outsource more activities," says Zrimsek. The build/made items in ERP become bought/purchased items. The visibility that comes from routings, work-order statuses, and work-in-process data acquisition gets lost. Hence the drive for collaborative information systems among outsource partners. But remember, points out Zrimsek, "ERP wasn't built with the Internet in mind."
2. Verticalization of functionality. ERP was initially built for manufacturing and distribution. Now, fully integrated, feature-rich, ERP systems have extensions for supply chain management (SCM), customer relationship management (CRM), warehouse management, and several other business processes. Zrimsek has seen ERP deployed in just about all industry sectors; food, petrochemical, aerospace and defense, the armed services, and even the public sector. Consequently, ERP vendors are deepening the functionality of their systems to meet the needs of the target industries.
3. Architecture. Before client-server computing in the early 1990s, which was kind of the birth of ERP, resource planning systems were very monolithic. ERP deployments were basically mainframe deployments. Upgrading meant taking out the whole thing and putting in a new system. Today, users are loathe to pay 20% to 60% of what they paid in system implementation for upgrades/migrations. This is putting pressure on ERP vendors to provide software that is open, component-oriented, and migratable in pieces—thereby leaving existing, desired, ERP components (as well as SCM, CRM, etc.) in place and functional.
Add that all together and you see why Gartner is coining the term "ERP II" to label the "next act in the evolution of ERP, which expands beyond enterprise-centric optimization and transaction processing to a new focus on improving enterprise competitiveness." So, dismiss anything written that ERP is dead. "It's not accurate to say there's nothing happening in ERP. There's lots happening. ERP is still growing and evolving," exclaims James Shepherd, Senior Vice President at AMR Research (Boston, MA). ERP is still doing what it's supposed to: provide a common database for an entire enterprise. "ERP is truly the enterprise backbone. That can't go away," says David Schaap, Product Marketing Manager for BRAIN North America, Inc. (Ann Arbor, MI). If anything, ERP is manufacturing's equivalent to Microsoft's Office Suite: lots of core functionality and changes that are far more incremental than they once were.
"What's new in ERP is no different than what has always been new in the product category currently known as ‘ERP,' formerly ‘MRP II' [manufacturing resource planning], formerly ‘MRP' [material requirements planning]: The difference has to do with what's being added to ERP," says Shepherd. That is, the scope, features, and functions of ERP continue to expand. Some of these, points out Shepherd, are invented by the ERP vendors; most are invented by small, niche vendors, later co-opted by the ERP vendors. "That's progress as usual in ERP," Shepherd adds.
And yet, ERP still doesn't fit automakers very well mainly because they have evolved their own way of doing business, which is sufficiently different than other industry sectors. However, ERP does fit the operations of the suppliers. Nowadays, suppliers are implementing ERP packages rather than writing their own systems or modifying "off-the-shelf" to some unrecognizable system state, as they did in the past. One key reason is that because automotive is a key target market for the ERP vendors; automotive-specific functionality is now the "price of admission." For example, look at Release Management from Oracle Corp. (Redwood Shores, CA). This module manages customer schedules, then reconciles demand with existing requirements. It posts shipping and sequence schedules, and generates updates to sales orders and forecasts. The module lets OEMs and suppliers automate the receipt and processing of inbound planning, shipping, and production sequence schedules. As necessary, the module generates exceptions if data is missing or invalid; valid schedules will continue to be processed. Once validated, customer schedules are archived and accessed by schedule history, original schedule date/quantity, associated sales order, and customer authorization information using the Release Management Workbench.
Several automotive companies require that trading partners use cumulative accounting; that is, send cumulative ship-to-date quantities or discrete requirement quantities with a cumulative total indicating what quantities are needed over the period. Oracle's Release Management converts these cumulative quantities into net quantities. This forecasted demand is reconciled with existing demand in Oracle Order Management and Oracle Planning. The reconciled customer demand goes to Oracle Shipping Execution, which manages picking, packing, and shipping inventory, as well as issuing the appropriate ship notice and invoice information through an EDI-related gateway to the OEM's trading partners. For non-Oracle users, Oracle's Trading Partner Architecture helps integrate trading partner-code to Oracle Release Management, Order Management, and Shipping Execution.
The recently announced Rapid Planning Matrix (RPM) from SAP America, Inc. (Newton Square, PA), is an enhancement to the production planning and detailed scheduling in SAP's Advanced Planner and Optimizer (APO). That said, RPM is more an MRP engine. Running in main memory, RPM processes vast quantities of data and spits back the exact work content of sales orders per work area, including due-dates and line positions. It can explode 100,000. . .150,000. . .whatever, fully configured car sales orders in one to 1.5 hours, a process that could take up to 10 days in R/3.
RPM lets companies run MRP after every shift, see demand for the next three to five weeks, and push consistent and accurate information down the supply chain. It also identifies potential bottlenecks and generates reliable delivery dates to users. This is crucial as automotive moves from a make-to-stock operation to build-to-order. This capability is also, says Juergen Helmle, SAP's Vice President of Automotive, the starting point of supply chain planning. "RPM is technically a part of our SCM product, not a part of R/3, but I would still call it a core ERP function."
SAP has also recently announced its Packaging Logistics module. (Delphi and other automotive suppliers call this "Label Management.") This module manages packing instructions and multi-level packing bills of material. The module lets suppliers set packing instructions about what materials are to be packed in what type of container, and in what quantity. With this, suppliers can ship different part numbers in different containers—on the same pallet. Shipping palletized containers, even with mixed parts, saves in inventory and materials management on the shop floor. The module also manages returnable packaging, including monitoring the number of returnable packaging items in circulation.
Are these ERP functions? Yes, answers Helmle, even though it runs across material management, sales and distribution, and production planning.
There are a couple of ironies with ERP. The first revolves around the very issue of system complexity and the reality that software/systems integration is both difficult and expensive—COM, CORBA, Java, .NET, XML, and Web-based technologies notwithstanding. This reality, now more than ever, supports the argument for standardizing ERP, CRM, SCM, and the rest of the alphabet soup on one or two large ERP vendors, even if the resulting system is not "best of breed." Says Paul Hebeler, Oracle's Automotive Industry Director, "There has to be a compelling reason to going with multiple packages."
(Hebeler also confirms that unlike the other major ERP vendors, Oracle plans to be the one-source provider for that alphabet soup of enterprise applications. "And don't forget, we have the database, too," he adds. When quizzed that supposedly no vendor can do it all, Hebeler responds, "That's probably true. It takes a special vendor.")
Suggests BRAIN's Schaap, "People should still be asking their ERP providers to keep them current in terms of new industry mandates, which are constantly changing, and additional incremental functionality to address the changing market." The larger ERP vendors are more apt to do this, especially as mergers, acquisitions, and outright business failures take their toll on small ERP companies. On the other hand, a niche vendor might be better able to provide software for specific ERP-related (or soon-to-be ERP-related) tasks.
This "bigger is better" approach to ERP has other ramifications. Vendors now have more "touch points" within the enterprise to sell ERP, whether that be manufacturing, finance, SCM, CRM, and so on. For customers, though, ERP is becoming—if it hasn't already—more unwieldy, more difficult, and more expensive as it tries to deal with the staggering complex problem of enterprise management.
Despite the best of intentions, concludes Shepherd, "the problem of managing a business doesn't get any simpler. Now I have to sell my products 900 ways, I have to bring lots more new products to market in a week instead of years, and I'm global instead of local. It's a much more complex environment than it used to be."