Insights from: Cindy Jutras (Founder Mint Jutras LLC)
The debate over "integrated suite" versus "best-of-breed" has been around as long as Enterprise Resource Planning (ERP) has existed. But as the desire grows to fill all the gaps for complete "end-to-end" solutions, it also becomes more relevant than ever.
In the early days of ERP, the trade-off used to be quite clear. To get rich functionality beyond the basics of ERP, you turned to so-called "best-of-breed" solutions and in doing so you incurred additional cost and forfeited seamless integration. And sometimes you duplicated work and sacrificed ease of use. But as the footprint of ERP has expanded and integration has become more technology-enabled, decisions aren't so clear cut.
Today, when integration is done right, it is hard to tell the difference between embedded modules of ERP and separate applications… and it probably matters little to the business user whether it is is one application or multiple. But if you screw it up, it matters a lot. You pay in terms of cost and effort You create headaches for the business and the business user. And the Information Technology (IT) staff is left to clean up the mess.
"Modules" versus Other Applications
Lest we run the risk of terminology confusing the issue, let me offer some definitions to explain the difference between a module of ERP and these other applications (extensions) that surround and extend ERP. They might or might not be best of breed. And we should first start with the definition of ERP. I define ERP as an integrated suite of modules that forms the operational and transactional system of record of your business. It includes all the master data needed to support the complete cycle from order to cash, including a full audit trail of all transactions. While this is a minimal definition, most complete ERP solutions today do much more than this.
When I say "module" many of you might immediately think of the most common components of ERP: accounts payable, accounts receivable, general ledger, inventory control, MRP, purchasing, order management, etc. And you would be correct. These indeed are typically included as modules of ERP. But then, so might customer relationship management (CRM), which is considered to be a different software category. So CRM might also be purchased as a separate, stand-alone application, hence the confusion. So what is the difference?
All the modules of ERP use a single data base model; integration is built in and there is little or no redundancy of data elements, except where there is a specific need. All modules are built with the same development tools, and the same architecture. Release cycles are all in lock step. A module can't stand-alone and one module cannot move forward independently of the rest of ERP.
Extensions (or "other applications") are developed and maintained separately, may or may not be integrated. Because they typically can stand alone, yet need data to run, they may have data redundant to ERP which must be synchronized. However, if seamlessly integrated this synchronization may be transparent to the users.
However, unlike an embedded module of ERP, it can be enhanced independently. Upgrade cycles can move ahead of ERP, providing integration moves along as well.
In the past, the easiest way to spot an extension (versus a module) was:
- You had to login or sign in to it separately from ERP
- It looked different
However, with the introduction of "single sign on" capabilities, when integrated properly, this dual login might go away. And with the consumerization of IT, the software user experience has changed dramatically. And because new, technology-enabled user interfaces are so configurable, it might be very hard to tell when you transition from one application to another. That is, if integration is done right. Certainly not all integration works this way, but newer technology certainly makes it possible.
Now, as if this wasn't confusing enough, more and more vendors are componentizing new features and functions and delivering them as "loosely coupled", allowing customers to keep existing solutions in place, while adding new functions and even replacing existing embedded features. Is this loosely coupled component a module or a separate application? The answer is: It depends. But does it really matter? Hold that thought.
As I noted above, the footprint of ERP solutions has steadily increased over the years, blurring the boundaries and making it difficult for the industry observer, as well as the actual user to distinguish between integrated modules of ERP and separate applications. In the past, modules of ERP were clearly distinguishable from separate applications (extensions), which might or might not be integrated with ERP. The core basics of ERP were always embedded while extended functionality could be delivered as a module or as separate applications (extensions.) But, as noted earlier, the world has changed.
This change even caused Mint Jutras to change the way we measure the use of ERP. We used to ask survey participants to check off - from two separate lists - which modules and extensions they had implemented. But over time more and more overlap crept into these lists. Not only has the overlap between modules and extensions grown significantly, but the integration capabilities have also made it more and more difficult to distinguish between the two.
So this year our 2014 ERP Solution Study combined them into a single list and asked which were embedded modules of ERP and which were separate applications (and we also asked how well integrated they were). Collecting data this way resulted in more accurate data but also uncovered a proliferation of disparate applications. While we weren't really surprised, we wondered what would be different if companies were starting from scratch today. So we asked, "What if?"
It is clear (and no surprise) that the vast majority would like to have an integrated, end-to-end solution. But for every participant with an overwhelming preference for a complete end-to-end solution supported by a single vendor (integration delivered out of the box is presumed), there are two that will be cautious before sacrificing functional requirements for ease off integration or the luxury of dealing with a single vendor.
This actually goes hand in hand with our findings on the top two priorities for selection criteria: ease of use and fit and functionality. The message from the potential buyers of software to the vendors is clear. The buyers are saying, "we need more features and functions, but don't make me jump through hoops to use them."
CRM and ERP: The Perfect Example
ERP and CRM provide the perfect example of the issues, as well as the potential. The sales function in particular was largely underserved by early ERP solutions. This caused sales management to look elsewhere for tools for sales force automation and customer relationship management. This created a huge demand for stand-alone CRM solutions. The market responded and these solutions have continuously evolved
For over a decade now, we've been hearing CRM vendors touting "the 360o view" of the customer. Yet without the transactions in ERP (orders, shipments, invoices, payments), how can that be? Unless you marry ERP and CRM, you can't. And I would argue that the integration must be "done right" or you will either have blind spots, or you will wind up with multiple versions of the truth. Old point-to-point integration techniques were not only costly to develop and maintain, but were hard to synchronize. Even something as simple as the customer master records can easily get out of sync. And then how do you know which version is the truth?
But modern technology, including object-orientation, message-based communication, event management and other methodologies make it much easieand makes the integration more seamless.
And all the while CRM vendors have been developing these stand-alone solutions, the ERP vendors have not been standing still. They too have sought to fill this gap, either through adding more CRM-like capabilities by adding CRM modules or acquiring or developing stand-alone CRM applications. Of course if they have developed a solution that can be stand-alone, often this is done with the forethought of seamlessly connecting it back to ERP. If purchased through an acquisition, the same integration effort is required as in purchasing a third party's solution, but presumably this integration is done once… and hopefully done right.
CRM is just one example, but the questions you need to ask yourself are the same whether you are looking for a 360o view of your customer or just have the goal of a complete, fully integrated end-to-end solution to meet your business needs. Do you go with ERP with a (CRM) solution built in, or do you go with a stand-alone application. Does it really matter? Not if the integration is done right.
The real take-away is: Don't screw it up.
About the author: Cindy Jutras is a widely recognized expert in analyzing the impact of enterprise applications on business performance. Utilizing over 35 years of corporate experience and specific expertise in manufacturing, supply chain, customer service and business performance management, Cindy has spent the past 8 years benchmarking the performance of software solutions in the context of the business benefits of technology. In 2011 Cindy founded Mint Jutras LLC (www.mintjutras.com), specializing in analyzing and communicating the business value enterprise applications bring to the enterprise.