• follow me on:

Tech Term Convergence at SuiteWorld 2014

I recently attended SuiteWorld 2014, the annual conference hosted by ERP cloud vendor NetSuite, and it was a good experience. Spending time with NetSuite almost always is, really; the applications are like Goldilocks’ porridge—not too sparse, not too overloaded with gadgets, just right. Your mileage may vary, and this is as much a personal assessment as it is a professional one.

If you’re looking for highlights of the announcements, see my Twitter stream. For me though, the big takeaway was not what had been added to NetSuite’s back-office capabilities, nor its front-office ones. Rather, it was a new set of questions about the nature of labels like CRM and ERP, and of what goes into them.

In his keynote, CEO Zach Nelson compared what NetSuite does to what CRM vendors claim to do, and suggested that customer experience and satisfaction were driven more by ERP functions than by CRM. When you contact a company, some of the most common reasons are to inquire about a bill, check on an order, or make a purchase. None of those things can happen unless the customer (or the service rep) can access data from the warehouse or the accounting department. ERP is what tells the company where your merchandise is and where the money is. From a transactional point of view, ERP is CRM.

Just as ERP fills a CRM role sometimes, so does CRM manage corporate resources. Marketing and sales materials need to be created, refined, and distributed while being tracked against budget and time. You’re planning what to do with those enterprise resources, and you wouldn’t turn to an Accounts Payable clerk to do it. Reputation and brand identity, two of the most important assets a business has (though admittedly somewhat abstract and not traditional resources) are likewise governed with technology we call CRM.

It’s wrong to say that ERP is better at CRM functions than the apps we think of as CRM, nor vice-versa. The problem is that both sides can claim to perform functions they don’t actually do. ERP is not about building relationships, anticipating needs, or managing demand, and CRM is not about getting orders packed, shipped, and paid for. Each may have some elements of the other, but they can’t replace one another in most cases.

I’m not the only person who started thinking about this. Several enjoyable conversations later, with the likes of Cindy Jutras, Laurie McCabe, and Denis Pombriant (who clarified the issue for me as only he can), I came to the conclusion that the labels are artificial, and often distracting. At some level, it’s just a matter of convenience to use those terms, some jargon that provides a rough overview of what’s in the topic.

The issue isn’t front office and back office, or CRM and ERP. It’s system of record and system of engagement. It’s where you imagine the heart of your business to reside, and how your connect it to the other parts. Multiple systems of record makes little sense—one version of the truth is enough for anybody except politicians. Multiple systems of engagement used to be acceptable, even necessary, but no longer. Presenting a unified face to the customer, and being able to server them equally in whatever channel they choose to engage, is the new norm.

Without an effective system of record, a business is chaos. Orders can’t be fulfilled, payments can’t be made or received, and there is no answer to questions. Without an effective system of engagement, you’re a shop with locked doors and windows. Customers don’t know what you offer, and you don’t know who wants to buy. Both systems are necessary, and both must work together. Whether all the applications come from one vendor, or they’re integrated from multiple sources, the result has to synergize.

I’m not going to erase the CRM and ERP labels by thinking this way, and I’m not sure I want to. What I want is for vendors, analysts, journalists, and consultants to look beyond the labels, look beyond the limitations they falsely suggest, and consider enterprise software as an ecosystem instead of a bunchasystems.