It seems lately I have been hearing a lot about “loosely coupled” business applications. It started about a year ago at Infor’s customer event (Inforum) and then continued at SAP’s SapphireNow. More recently, with SAP’s introduction of Financials OnDemand, I heard it again. Financials OnDemand is a derivative of SAP Business ByDesign, a cloud-based, tightly integrated suite (that some might call ERP). SAP pulled out the financials that were previously embedded in Business ByDesign so they could stand on their own and be “loosely coupled” to other applications.
But is this what its customers and prospects are looking for? That’s hard to say because it is very unlikely its typical prospect or customer really understands the intended “benefits” of loosely coupled. In fact, when you start talking about “looselycoupled” to CFOs you are likely to produce that glazed look that says, “I don’t know what you’re talking about… and I don’t really care.” If you refer to“loosely coupled” in contrast to “tightly integrated” you might get a glimmer of understanding, but not an immediate acceptance of the concept.
CFOs might intuitively understand the value gained from tightly integrated applications, particularly in reference to an integrated suite of modules like ERP. After all, who wouldn’t want a complete solution, one whereall the pieces just sort of fit and work together, with no integration effort required and no redundant data? While there might be some inherent value to having a loosely coupled solution, that value is not intuitively obvious to a CFO. Yet the opposite is true for both Infor’s CEO Charles Phillips and representatives of SAP, including former SuccessFactor CEO, now SAP’s chief “cloud” guy, Lars Dalgaard. They see enormous value in loosely coupled. As a result they eitherdon’t see a need to explain it, or they have difficulty in explaining something they just intuitively “get.” Either way, the message is just not very clear to your typical financial executive.
So let me try to explain. The biggest reason “loosely coupled” might be of very significant value to a CFO is because things change. Markets change. Companies expand (or shrink). Software is enhanced. Technology innovation happens. In fact, technology innovation often results from change but is also often the catalyst for change. Yet responding to change is hard.
Let me give you an example that should resonate with a CFO. Let’s say you are the CFO of a mid-size manufacturer who has helped your company expand over the past 10 years. You implemented an ERP solution back when you were small and your accounting needs were rudimentary. You chose a solution for its strength in managing inventory and production. While you started out operating from a single location, you have expanded globally and now operate in 6 different countries around the world. While the financial modules of your ERP met your needs when you first implemented it, now you struggle with compliance and tax regulations, multiple legal entities, multiple currencies and consolidation. This is a very real scenario. Our latest Mint Jutras survey on ERP indicates 75% of companies today operate with more than one location. Even small companies (those with annual revenues less than $25 million) have an average of 2.6 locations and this average grows to 7.5 in the upper mid-market (revenues from $250 million to $1 billion).
You’d like to move to a newer, more feature-rich accounting solution, but your ERP is still satisfying the needs of manufacturing and since you are continuing to grow, you don’t want to disrupt the business by ripping it out and replacing it. The very thing that attracted you to your solution is now holding you back. Because it is tightly integrated, you can’t just replace a piece of the puzzle without replacing the whole thing.
To make matters worse, your older ERP solution is not really meeting your needs for customer relationship management (CRM). This is not surprising. While the footprint of ERP has been steadily expanding over the past 10 years, the needs of sales and service organizations were not front and center from the beginning. If these needs had been met with early versions of ERP, companies like Salesforce.com would never have taken off like they have. Maybe you too are considering adding a stand-alone CRM to the mix. If so, SAP might be pitching its Customer OnDemand solution in addition to Financials OnDemand.
So is this building a case against tightly integrated, in favor of stand-alone solutions that might need to be integrated? Not necessarily. In a tightly integrated solution there is only one of anything – one chart of accounts, one customer master file, one item master, one supplier master, etc. But these master files are shared across different functions. Purchasing needs to access the supplier master to place a purchase order. But accounts payable also needs a supplier master in order to make a payment. Sales and order management need to maintain information in the customer master, but accounts receivable needs a customer master to apply cash receipts. Pull the accounting solution out and you still need the suppliers and customers. Does the new accounting solution have its own supplier and customer files? Does this mean maintaining two of each? Does the new CRM add yet another customer master? If so, how do you keep them in sync? Or maybe you don’t. But this adds all sorts of new wrinkles.
“Loosely coupled” applications could very well make your life easier. But what’s the difference between “loosely coupled” and what used to be called “best of breed?” This is where it gets harder to explain and I am not entirely convinced all vendors that claim to deliver it are talking about exactly the same thing. It took SAP several tries before I really saw the difference, and I live and breath this stuff. Your typical CFO doesn’t.
In trying to understand SAP’s definition of “loosely coupled” I described the scenario above to the solution marketing team for SAP’s cloud-based Financials OnDemand and Customer OnDemand would address this issue of redundancy. If each were sold separately (i.e. not delivered as the integrated suite of Business ByDesign) would the customer wind up with two different customer master files? SAP’s answer was no.
Here’s how it works: Think of the customer (master data) as a business object. An older ERP solution will build that customer master file (the business object) right into the solution. Instead, these OnDemand solutions treat the customer master as a separate business object that lives outside of the application. By doing this, both applications can point to, access and reference the same business object.
But what about maintenance? Instead of building the maintenance functions directly into each application, SAP treats that function as a separate function as well. Instead of building that directly into Financials OnDemand and Customer OnDemand, SAP builds it once and puts it in a “business process library” which both (and other) applications can use. The term “business process library” might be a bit confusing because most think of business processes in the context of processes like “order-to-cash” or “procure-to-pay” or “plan-source-make-deliver”. These are workflows that string together different functions. But in this case the business process is much more granular. It refers to the process of maintaining the customer master data.
So by loosely coupling these two applications, the customer still winds up with one customer master file. And both applications use the exact same functions to access and maintain it. These external business objects sort of plug into these applications.
This solves an important problem, but in our scenario, where we are replacing the accounting applications of an existing ERP solution, it is only half of the problem. If that existing ERP is still managing customer orders, it too needs to access the customer master file and it probably assumes the customer master file is the one that is delivered embedded in the ERP. So until or unless you do some potentially invasive surgery to the existing ERP, you are going to have to deal with some redundancy of data.
Of course if you replace that tightly integrated ERP solution with a newer or upgraded solution that has been assembled with loosely coupled external business objects, this problem goes away. In the meantime, SAP, and potentially other solution providers are beginning to re-architect their solutions to make this much easier. They are essentially performing this surgery and delivering applications that make better use of underlying supporting technology to make this happen. Remember the $6 million man and the bionic woman? They were still people, but with some of their “parts” significantly enhanced. Think of it as bionic ERP.