My answer--the easy one--is that it depends on the customer's needs. Some customers need the wide breadth of functionality that the Tier I vendors, such as SAP and Oracle, offer. But now well-known analyst Judith Hurwitz comes along and questions the whole idea of packaged ERP software. Her premise? It just doesn't exist anymore.
Hurwitz tells the story of the CIO of a large corporation that decided to replace a number of legacy applications with a major ERP system (she doesn't mention which one):
The idea was correct – the company needed a system that would implement business process and best practices to support the business in a uniform and efficient manner. The problem, in my mind was two fold – first the cost. To purchase and then implement this software cost the company $500 million dollars. Obviously, a considerable part of this expense was for professional services. And maybe that is the point. The idea that a company can purchase a packaged ERP system that is really packaged software is a misnomer. In reality, packaged software is not really packaged. It is a set of tools, a set of templates and processes that are linked together based on marketing and promise. The CIO I was speaking with provided some insight into the complexity of this implementation. It required a lot more customization than anyone had anticipated. The promise of out of the box implementation was a myth. Once the customization was applied to this package, the concept of a packaged environment was gone. Therefore, it should not have come as a shock when the next time the base platform of processes and tools had to be upgraded; it cost the company an additional $50 million.Her solution? She has five recommendations, but they basically come down to this: business software should be based on software components (services) that can be can be linked together to support individual processes, configured specifically to the organization's business.
Service-Oriented Architecture
What Hurwitz describes, quite well, is the essence of a service-oriented architecture (SOA), and it is at the heart of SAP and Oracle's current development efforts. SAP's Netweaver is simply an SOA platform, allowing functionality to be more easily deployed and composite applications to be built on the fly. And Oracle's Fusion middleware uses SOA to integrate its newly acquired products, and SOA is the foundation of its next-generation Fusion applications.
SOA is also the core strategy of other vendors, such as Lawson, Microsoft, IFS, and many others. For example, long before SAP and Oracle announced their SOA strategies, IFS had already built its applications on a component-based architecture--beginning in the late 1990's. When you drill down into IFS Applications, what you find at the bottom is not modules and programs but processes. These processes are then linked together to support specific business processes within the application. They can also be linked by the customer into other or different processes--exactly what Hurwitz is calling for.
Lawson, another Tier II vendor, is also transitioning its application portfolio to SOA, using its Landmark development environment, featuring domain-specific specific languages. The vendor has already released some functionality built on Landmark, including some HR and strategic sourcing applications, and it is working on others.
Microsoft is also incorporating SOA in its Dynamics line of ERP systems, and even Infor is claiming use of SOA as part of its strategy to link the many products in its portfolio.
An evolution in ERP
In years past, the winning vendor was the one that could check the most boxes on the customer's RFP. Today, many vendors can check most if not all of the boxes (though "how" vendors meet requirements often differs). The result is software that has enormous functionality but requires thousands of decisions to implement, especially in large companies. Today, customers have heard all the war stories, and they do not have an appetite for large, complex, risky, implementations--especially in today's economic climate. Speed, simplicity, and flexibility are the attributes that appeal to buyers today. Of course, the key requirements still need to be met. But the question to the buyer often comes down to, which system can we implement quickly and more easily?
The short-term approach of most vendors has been to simplify implementation through preconfiguring their systems for specific industries and so-called best business practices. SAP's approach is its "All-in-One" offerings. Oracle's is through use of "implementation accelerators." Both vendors have good references to demonstrate the success of their approaches, especially with small and midsize firms. These efforts are commendable.
But ultimately, the real answer is to transition completely to service-orientation--both by vendors and by customers. The good news is that most ERP vendors are already in this transition to, in effect, unpackage ERP. The transition will not be rapid, but it is taking place.
Update, Oct. 31. Floyd Teter gives his take on Judith's analysis. Floyd thinks there is a risk inherent with SOA--organizational stovepipes--and suggests social networking as a solution.
Related posts
Update on Lawson's strategy
Payback begins from SAP's Netweaver strategy
The death of packaged software
Blogging from the Lawson user conference
Latest from the IFS World conference
3 comments:
As enterprise software has grown to cater for more and more diversity, for so many different industries and markets, the concept of selecting the pre-defined options in a pre-packaged application is now so complex that it is counter productive. To circumvent this problem, enterprise vendors are offering rapid development tools embedded in the various application areas. These tools are simple graphical IDEs with a relatively small and focused repertoire of functionality. So rather than trolling through a huge list of options hoping to find one that suits, you simply build your own visually. This is not to say the pre-defined options no longer serve a purpose, but it is nice to have the option of building your own rather than having to write a complex technical specification for hand-code development.
A related phenomenon concerns the separation of business rules from the application logic, rather than simply removing the need for hand coding. The advantage of this is that a functional analyst can update the ever-evolving business rules without having to change the application itself. However there is more to be gained from this approach for some business processes than others, because some business processes are much more static than others. So where business rules don't change so often, embedding the rules directly in the application might not be such a bad idea, particular if it can be done code free.
In regards to SOA, the most significant benefit, in my opinion, is to allow an organization to progressively evolve their enterprise solution so that a “big bang” approach and the risks that come with it are avoided. Many organizations are frightened of upgrading their solution because of the risk a change made to one part of the solution might have an unexpected impact on another part of the solution. SOA effectively quarantines each part of the solution, so changes to one part can be tested in isolation to the other parts of the solution.
Matt
that´s why I really think that SOA must come with BPM
Sorry but IFS Applications is supposed to be components built accordin to the vendor. I have never heard about any customer who would have linked its porcesses in a different way (as the original one).
On the other hand, from my research, I found out that IFS has engaged in a web services strategy since 2001/2002 which is really a nice one that could help companies in using and integrating the swedish ERP in their IT landmark.
Vincent LIEFFROy
Post a Comment