Essential ERP - Current Market Trends - Part I

The growth of ERP has been a direct result of the fierce global competition, short product life cycles, highly distributed operations, and information-driven management that characterize today's business environment. The vast majority of companies have always hoped to purchase an information system as a product, not as a collection of technologies, components, and services. Leading ERP vendors have been successful so far because they have been attempting to build such a product.

A typical ERP system today offers broad functional coverage; vertical industry extensions; a robust technical architecture; training, documentation, implementation and process design tools; product enhancements; global support and an extensive list of software, services, and technology partners. While it is not a system-in-a-box yet, the gap between its desired and actual features is becoming smaller every day.

The worsening plight of most ERP vendors, caused by the market slowdown, which started in the fourth quarter of 1998, continued in full force throughout 1999. Particularly affected was license revenue, which declined more than 10% in 1999 compared to 1998. The market was dramatically less profitable than in 1998 (down 27.3%), measured in the total raw $ net income (Source TEC). We believe that the continued ERP market slowdown in 1999 was in part attributable to the following factors:

• The historical growth in sales of ERP applications has come from large, Fortune 1000 multinational corporations. This market has been highly penetrated (over 60%), and new, large-scale back-office implementations in the F1000 customer base have all but stalled.
  
  
• The relatively untapped Small-to-Medium Enterprises (SME) market has been cautious about starting new projects due to the bad publicity caused by a large number of unsuccessful ERP implementations in the past. This fear has been additionally aggravated by the need to integrate disparate systems, given that currently no single vendor can offer a complete end-to-end solution (from supplier to end customer).
  
  
• The technology paradigm shift from Client/Server to the Internet created uncertainty about investing in traditional Client/Server technologies, which are still prevalent among leading ERP players.

Consequently, we believe that the following trends in the ERP market are the direct consequence of vendors' attempts to 1) resolve current ERP functional and/or technological deficiencies, and/or 2) expand software sales both within their existing and potential customer bases, particularly in the lower-end of the market.

About This Note: This Technology Note covering the current marketing trends for ERP is presented in two parts.

The ERP Market Trends covered in this note are:

1. ERP Functional Scope Expansion
   
   
2. Sharper Vertical Focus
   
   
3. Flexibility Enabled by Adaptable Architecture The ERP Market

Trends that will be covered in Part II of this note are:

4. Web- and E-commerce Enablement of ERP Systems
   
   
5. Intensified Market Merger & Acquisition Activity
   
   
6. Advent of Application Hosting Services.

1) ERP Functional Scope Expansion:

While ERP packages excel at combining financial control with multi-plant manufacturing & distribution coordination, they generally lack extended supply chain planning and flexible execution functionalities that can enable one business process today but change rapidly to handle tomorrow's new models. They are also often found lacking when it comes to delivering special financial features such as robust budgeting or international consolidation.

Nevertheless, ERP's main functional weakness is in its planning function - master production scheduling (MPS) and manufacturing resource planning (MRP) modules that decide how and when to respond to customer demand with available resources. These modules are generally insufficient to support a real-world supply chain because they only deliver the following:

• Business transactions without much responsiveness
  
  
• Production focus without understanding demand
  
  
• Control without intelligence (decision support system)

From the flexibility point of view, the vast majority of ERP products have been designed to operate in an over-the-wall fashion. Such stovepipe logistics cannot adequately react to dynamic changes in customer demand. Moreover, at each handoff between applications, increased uncertainty leads to overstocked inventories, longer wait time and slower response. In the Internet-driven, dynamic trade environment, the following things increasingly happen:

• Services eclipse products - Companies use services such as vendor-managed inventory and direct store delivery that require on-the-fly business process change.
  
  
• Demand drives production - Companies are moving to make-to-order and late-assembly manufacturing strategies.
  
  
• Price matches market conditions - Businesses reduce inventory to maximize profits in commodity or supply-driven markets.

The key to dynamic trade is agility, which is where traditional ERP packages have stumbled in the past. Early ERP adopters discovered to their dismay that implementing these systems was only the first step toward creating a competitive information technology infrastructure. They and new users alike are now looking for significantly more comprehensive functionality - from advanced planning and scheduling (APS), to sales force automation (SFA) and customer relationship management (CRM), to business intelligence (BI) and e-commerce tools - and demanding that they be integrated into their ERP backbone. Users' visions of ERP are evolving from tactical to strategic, and users are no longer willing to choose between integration and function. ERP users who have gone live in the past three years have been making purchases of extended ERP products (bolt-ons) to provide tangible ROI for their multi-million-dollar investment.

Consequently, during the last three years, the functional perimeter of ERP systems began an expansion into its adjacent markets, such as supply chain management (SCM), customer relationship management (CRM), product data management (PDM), manufacturing executions systems (MES), business intelligence/data warehousing, and e-business. The major ERP vendors have been busy developing, acquiring, or bundling new functionality so that their packages go beyond the traditional realms of finance, materials planning, and human resources.

We believe that, within the next two years, ERP will be redefined as a platform for enabling e-business globally. Originally focused on automating internal processes of an enterprise, ERP systems will include customer and supplier-centric processes as well. The conclusive evidence of this redefinition is the move of all major ERP players into CRM and SCM applications. As a result of this trend, we predict that within the next three years, over 65% of the license revenue of the SCM market and over 50% of the license revenue of the CRM market will come from current ERP vendors (70% probability). Currently, these figures are estimated to be less than 10%.

Global financial capabilities (including support for the Euro), advanced planning and scheduling (APS), product configurations via the Web, supply chain management (SCM), customer relationship management (CRM), e-commerce, business intelligence (BI), and component-based (object-oriented) architecture will remain the order winners for the next two years. After that period of time, we believe these functional and technological features will be demoted into commodities (order qualifiers).

2) Sharper Vertical Focus:

While competitive costs (low and flexible software license pricing and implementation costs) and outstanding global service (proven fast implementations and customer loyalty) will remain important requirements for success, particularly in the lower end of the market, vertical focus will be the key factor for survival.

Vendors that will survive the next three years will have focused their business and product on particular industries, preferably those with a current low penetration (See Table 1), instead of a more generic, horizontal approach. Winning ERP products will demonstrate deep industry functionality and tight integration with best-of-breed 'bolt-on' products in a particular vertical.

Table 1 - ERP software implementation percentiles (Source: Computer Economics, June 1999)

Industry Sector	No Activity	Researching, Piloting, or Implementing ERP	ERP Already in Place
Composite for All Sectors	47	34	19
Manufacturing	24	35	41
Distribution	50	32	18
Banking & Finance	39	48	13
Insurance	65	27	8
Healthcare	65	26	10
Trade Services	51	37	12
Professional Services	48	26	26
Utilities	>50	35	15
Transportation	57	33	10
State & Local Government	63	25	13
Federal Government	76	20	4

Verticalization can be seen as part of a larger effort by ERP vendors to ease the implementation of their products. By now, almost everyone in the IT industry has heard horror stories of ERP implementations that took two or three years and cost tens of millions of dollars. That happens, in part, because the ERP packages usually arrive needing to be configured for the business and the industry entirely from scratch.

By configuring parts of the package in advance for a given industry and circumventing functions not required in that industry, vendors can shorten and ease the implementation process. The pre-configuration may be based on the size of the company, the specific hardware, or the vertical market. Rapid implementation tools and industry-specific templates add value to the ERP investment by streamlining the process-modeling phase for fast implementation and time to return on investment. In fact, software implementation time reduction is a key element of success in any enterprise-wide technology project.

Users have increasingly looked for an ERP system designed for a specific business. Software that combines industry-specific functionality with the flexibility to accommodate each company's unique processes goes a long way toward improving the functional fit and the speed of implementation. This pragmatic approach helps companies close the gap between system performance expectations and final results achieved.

Another advantage lies in the fact that industry-specific, global enterprise solutions based on open architecture and proven technology standards facilitate faster integration of companies being acquired as part of a corporate growth strategy. Typically, as companies grow and want to compete globally, multi-language and multi-currency functionality become increasingly important.

In addition to core ERP functions, integrated industry-specific applications can add significant value. Vertical focus indicates that software contains industry-specific features and that ERP vendors have certain industry expertise.

For example, in mill industries such as pulp and paper, converting, and steel manufacturing, an enterprise solution must be based on product attributes and customer specifications being active throughout the production, inventory, and order fulfillment flow. These systems also must have an integral view of the plant floor for tracking work center level costs, quality of work in progress, customer order status, and roll/product movements. Integrated trim management and rough-cut capacity planning are crucial elements for mill industry enterprise solutions in order to connect production activities to customer order fulfillment. Integrated advanced planning and scheduling (APS) and maintenance planning further optimize throughput, reduce costs, and eliminate the need for redundant systems or custom interfaces being developed between applications. In the food and beverage industry, as another example, one challenge is to provide rapid, timely information flow through global food and beverage manufacturing and distribution enterprises. Integration between ERP and process control systems or manufacturing execution systems (MES) is also of a great importance. Because of the volatile nature of the business, with consumer tastes and government regulations constantly changing, the enterprise system must also accommodate rapid product development, efficient replenishment, accurate forecasting, and customer quality demands.

Finally, 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.

3) Flexibility Enabled by Adaptable Architecture:

The rapid pace of global business today places a unique set of challenges on companies looking to improve and automate their operations, and at the same time, remain poised to adapt quickly to change. With increased competition, deregulation, globalization, and mergers & acquisition activity, buyers will increasingly realize that architecture plays a key role in how quickly vendors can implement, maintain, expand/customize, and integrate their products.

The product architecture is going to do much more than simply provide the functionality, the user interface, and the platform support. It is going to determine whether a product is going to endure, whether it will scale to a large number of users, and whether it will be able to incorporate emerging technologies, all in order to accommodate increasing user requirements.

An adaptable architecture is the least common denominator for a flexible ERP system. Although a component-based architecture is not an explicit requirement for ERP flexibility, component-based applications generally provide greater flexibility than their monolithic counterparts. Further prerequisites for flexibility will be the abstraction of technical complexity (manifested via the use of intuitive tools, aids, or wizards that guide user through a set of steps to achieve a desired end result) and an intuitive, easy-to-use user interface.

Componentization refers to the act of breaking up large, monolithic ERP systems into individual modules or components that would work together. It is the practical embodiment of object-oriented programming (OOP). Object-oriented software design and programming were developed to enhance software maintainability and to simplify the creation of advanced GUIs (Graphical User Interfaces).

Object orientation means that design, linkages, etc., use objects as their basic building blocks, which is a radical departure from traditional 'procedural' design and coding methodologies. An object class is a combination of data and processing logic. The data for a class may correspond to a relational database table, but this is not necessarily the case. The processing logic comes in methods, which are similar to subroutines or procedures. By maintaining processing logic with the associated data, programmers have an easier time finding reusable pieces. Therefore, object-oriented systems can be significantly smaller and easier to maintain than classical procedural code in which procedures and data are separated.

By breaking up the large applications into components, vendors are able to more quickly fix or add functionality. The accounts payable component, for example, could be enhanced without having to touch any other financial components or any of the other modules, such as planning or logistics. And once the ERP vendor has established a component architecture, it becomes easier and safer for IT to customize the systems. Componentization will prove to be crucial to enable ERP systems to support e-business activity since the new e-commerce capabilities are being delivered as individual components. Componentization also helps the vendors extend the core ERP system with supply chain, CRM, and SFA solutions.

Interest in componentization, however, began long before e-commerce. The perception at the time was that ERP applications were too big and unwieldy, and that they needed to be more flexible. Componentization would not only make it easier for the ERP vendors to enhance their solutions, but also make it easier for customers to upgrade the software. With componentization, a customer could incrementally upgrade only selected components without having to upgrade the entire ERP solution, which usually would entail a substantial effort.

In summary, a component-based architecture is beneficial for the following reasons:

1. It allows a developer to create a composite application in which a Web-based user interface accesses functionality in the packaged application.
   
   
2. It can enable message-broker-based integration of several disparate packages or legacy systems.
   
   
3. It allows a vendor to roll out new versions of the application in a modular, incremental fashion rather than all at once.
   
   
4. It may drastically reduce the total application code.

Componentization is thus necessary for vendors to move their ERP systems intto e-commerce and to provide other capabilities. Therefore most vendors insist they remain fully committed to it, although progress has been slow. The reason for this lies in the fact that componentization is enormously difficult to achieve even when the commitment is solid. At best today, some vendors have succeeded in creating large-grain proprietary components, which are simply large function modules.

For example, SAP has made progress in breaking its core R/3 system into large-grain components and all new pieces are being added as components. J.D. Edwards embarked on a rewrite of its WorldOne ERP suite when the component craze broke, so the company incorporated componentization into its redesign. Oracle also rewrote large amounts of code and has managed to componentize to a large extent. Baan, cash strapped, considered a component game and made only initial steps in the Baan Series release, but completion is still a long way from reality (it has been delivering component-based external APIs to internal business functionality, which still relies on its non-component-based 4GL). IFS, Intentia, Symix, JBA, and Psipenta are some of mid-market ERP vendors that have either entirely or to a significant degree componentized their products.

Implementing a fully component-based architecture requires that vendors completely redesign their applications and then rewrite it using C++, Java, or a component-based 4GL, and run it under COM, CORBA, or Enterprise JavaBeans (EJBs). Some vendors who attempted this approach, specifically Marcam Solutions and SSA, experienced a harrowing, time- and-resource-consuming, make-or-break transition which resulted in their being acquired. We believe that less than 35% of ERP vendors will deliver a completely component-based architecture within the next four years (70% probability). We also believe that the first vendors who deliver a truly open, modular system will capture the lion's share of the remaining non-penetrated ERP market.

While ERP customers may not be fully aware of the benefits of componentization as yet, they have been embracing the more open interfaces and improved integration capabilities that the vendors are providing, capabilities also intended for the componentization effort. During the past few years, ERP vendors have opened up their tightly interwoven modules and created application programming interfaces (APIs) to connect to 3rd-party best-of-breed systems.

SAP, for example, has created over 1,000 business application programming interfaces (BAPIs) for use in integrating third-party products with the core ERP system. This requires open APIs to enable the integration of third-party data reporting and analysis tools as well as other above-mentioned ERP extension tools.

Instead of the costly, risky move to full componentization, most ERP vendors have selected a safer approach. They use component-based APIs to construct a "fa�ade" for their existing application. When done properly, these APIs provide programmatic access to common business objects (e.g., an order, a business partner, a delivery), which are mapped to the existing application's functionality in a way that shields users from the complexity of the underlying code.

However, APIs alone are not sufficient. To bridge the differing semantics and business processes enabled within each participating application in an extended ERP environment, either vendors or users must employ message broker technology (a special-purpose, preferably 4GL tool that can readily transform and route data as it moves between applications).

Despite the user preference for a single, 'one-stop shop' vendor, componentized software products, interoperability standards and Internet technology will lead to fewer large-scale projects and an ongoing stream of smaller ones. Moreover, vendors will increasingly attempt to conduct system integration and consulting work themselves, which will further decrease the industry average license revenue/total revenue ratio.

The shift in the packaged applications market toward component architectures will place new planning and implementation requirements on user organizations. In particular, existing customers will have to make a choice about when to implement components and how much of their application can be safely componentized. We strongly advise customers to take a slow but steady approach to componentization. A "big bang" component implementation would likely be too risky for most companies to undertake.

Nonetheless, we recommend that ERP customers at least begin to think about the changes that componentization can bring on.

Summary and Overall User Recommendations:

Without a doubt, ERP remains the information backbone for contemporary manufacturing enterprises. However, today's ERP systems are required to address more than the processes taking place within the walls of an enterprise. They must be able to address the players and processes involved in extended enterprise - the people and partners that the manufacturers collaborate and coordinate with in their supply chains.

Users' need to understand their business requirements and critical business processes can never be overemphasized. Not knowing their present business state of affairs as well as their strategic intent and direction will disqualify any future ERP system implementation from being a success. Clarifying this should help users create a long list of vendors to include in an ERP package selection. Precedence should be given to vendors with a proven vertical focus on the user's industry.

Users should also be aware of consolidation in the ERP market, and corporate viability should play a prominent role in every selection process. Virtually all software selection teams appreciate the importance of product functionality and product technology requirements in making the right decision. Too often, however, these are the only criteria that play a role in the decision-making process. Other often overlooked factors can determine the eventual success or failure of a new system, including vendor corporate strategy, global service and support capabilities, financial viability, and, of course, cost.

After receiving the final proposal from each of the vendors included in the negotiation stage, users may want to put into action any counter-proposal or negotiation steps, which may include a combination of the following: a request to lower initial software costs, a decrease in maintenance fees, negotiating the license fee per module, negotiate discounted license fees for casual users, provision for future incorporation of "extended ERP" components by bundling them into the contract now at negotiated license fees, etc. 'Bolt-ons' should be selected only from official business partners of the primary ERP vendor, after making sure that partnership is not a mere marketing pitch.

Finally, users should ensure that their critical requirements are unequivocally spelled out in a contract with a selected ERP vendor. Future clients are also advised to request the vendor's written commitment to promised functionality, length of implementation, and seamless future upgrades, particularly for recently released products and products whose release date is due in the near future.