I’ve written many times about how conventional, premise-based, ERP seems to be evaporating and CPQ, configuration, pricing, and quoting, are business processes that illustrate the point. First, let’s all agree that ERP isn’t going extinct as it evaporates—it’s too valuable—but it is getting a haircut. Many of the functions leaving ERP are condensing back into the front office and to me that’s what’s exciting because it brings back office data closer to processes that consume it. Naturally, back office systems that are coupled with the front office, even to the point of being native to the same platform, have a distinct advantage.
CPQ embodies the value of the new front-to-back office setup. While mostly front office sales people use CPQ, the data they access has a strong back office flavor. It includes the product catalogue, price lists, and existing customer information that can drive things like cross selling. So CPQ sits at a strategic position, a crossroads, between the front and back offices and that presents its own set of challenges. For example, while sales people want and need access to ERP data very few businesses would want to give them edit and delete privileges to the back office systems.
Also, CPQ workflows involve front office personnel like sales people and their managers, not back office folks. They need to ensure quotes are right and to get approvals for discounts and other irregularities that are commonplace in sales. Top this off with the need for speed—getting an accurate quote to a customer before a competitor does and you have a strong case not only for CPQ but for keeping it closely coupled to both front and back offices so that the CRM system can get data efficiently and safely to conduct its vital processes.
There are lots of ways to do the coupling and no end of interfaces and APIs that vendors use to accomplish this. But one of the best approaches you can consider is just building the CPQ system on the same platform that the rest of the ERP and CRM apps use. We learned in geometry class that if A = B and B = C then A = C, this is the logic of building on a common platform. If everyone builds to the standards of the same platform when the time comes to cooperate there’s great commonality between systems. This won’t completely eliminate integration issues but it significantly reduces them.
The common platform approach shows its true benefits when it becomes necessary to deploy systems on more than the standard desktop or laptop, for instance on mobile device(s). Increasingly CPQ is becoming a mobile app that field reps can use to issue quotes and ask for business on the spot, wherever that spot is. But also, managers and others can make significant productivity gains inside a headquarters building using mobile technology so it’s not just the field reps who benefit from platform-centric strategies. This is also another reason to keep some distance between back office systems and mobile devices that could get lost or stolen. So, finally, it’s hard enough to build for one hardware and operating system platform but today you need to be able to define once and generate many times—another platform advantage.
Incentive compensation is another example that consumes both front and back office data. The CRM system, including sales and marketing, captures deal data while the backend records deals and issues and collects invoices. But there’s also a lot of deal specific information that must be saved that back office systems don’t usually track such as incentives, spiffs, and quotas. Compensation systems might also access employee data from the HR system, which is itself tied closely to the back office. Together, these processes (and there are many more illustrating the same points), thrive when they share a platform precisely because they must access data from across the organization.
A few years ago CPQ and incentive compensation were nice systems to have but many businesses still relied on spreadsheets for their product catalogues and compensation tracking and sneaker net to get approvals. But that era is quickly receding because the appearance of many other technologies is relentlessly accelerating the pace of business. It’s best to keep up.
It was gratifying for me to see the Salesforce announcement about the latest iteration of its SMB service desk product, Desk.com because it is so in-line with my thinking as well as my book, Solve for the Customer (I know, it’s a shameless plug). While I happily acknowledge that I advise the company from time to time, there is no causal relationship between the book and product, but sometimes, correlation is just fine. This is one of those times when correlation yields validation in both directions.
Of course there’s a press release and you can find it at Salesforce.com because it is not my intention to regurgitate it here. I prefer to focus on one new function that draws my interest and shows the parallels I mentioned, Desk.com Customer Health Monitor. Billed as a category-first among service providers, the monitor does what I’ve been advocating with minor exceptions. It tracks metrics about customers that a vendor thinks are important and reports on them thus providing alerts that help to prevent churn or attrition.
FYI, Zuora, another company I advise recently bought FrontLeaf to do much the same from a different angle. This idea is gaining traction.
This approach amounts to managing by exception. A small company can’t afford the labor or even subscribe to the systems involved in constant customer outreach and this tactic focuses on what evidence shows are customers that need an intervention, perhaps by a customer success manager. All good.
Now for some nits that need to be worked out—not in the product but methodologically. The big, and for many, hidden issue is knowing what you don’t know i.e. how does a business know what things to measure? An obvious example in the press release is what happens when a customer calls support twice in a month. Is this a sign of trouble or frustration and possibly a churn signal? It could be and the point of an alert is to call for further investigation, which leads to interrogating other metrics to triangulate the situation.
For example, new customers getting up to speed will likely call in more than established customers so it’s best to correlate frequency with other factors like seniority and possibly also products in use—did the customer just install the latest upgrade?
There are many iterations of all this and the simple point is that any company will first want to identify all of the situations that need monitoring and develop accurate metrics for them. I call the situations Moments of Truth, things that both vendor and customer care about and that must be addressed, moments of truth. So we must know our moments of truth before the rest of this makes sense.
We can safely assume we know some of our Moments of Truth but that’s no longer enough. We need to know all of them or we’ll be missing things we can help with and that’s bad because successfully negotiated Moments of Truth lead to bonding which leads to customer advocacy. We really can’t have too much bonding so we need processes that find all of the Moments of Truth and instruments them via tools like the health monitor.
Discovering Moments of Truth is likely a task for a future product release and probably other products like community and analytics. Using our brains to find the low hanging fruit will do just fine for now but suffice it to say there’s more to be done.
Not long ago a vendor asked a friend of mine to speak at a conference. Analysts speak at conferences all the time so the request was not unusual except in the conditions attached. There would be no compensation for the effort and the analyst would need to provide transportation and housing out of pocket. So the invitation was a money-losing proposition from the get go. I don’t know if the offer was accepted. There are times when an analyst might speak for no fee such as when plugging a book. But this was different, the vendor had the budget to pay for the service but just chose not to.
This happened around the time that Taylor Swift had her now famous disagreement with Apple over its attempt to recruit new listeners to its streaming music service. You can read the New York Times article about it here. Apple planned to offer 3 free months of service to new subscribers and intended not to pay the artists for the use of their music.
I wasn’t a Taylor Swift fan before because I am not very musical—I need a permit to carry an iPod. But I’ve become one because of Swift’s classy approach and principled stand. In her open post to both fans and Apple on Sunday, Swift explained that she was pulling her latest album, 1989, from Apple so that it couldn’t give away her work for free. There was no ranting, no cussing or questioning anyone’s parentage or species—just cold hard facts. I thought that was just right.
Artists earn a living, or at least try to, by making art for sale in the marketplace. They are quite comfortable with letting the market decide whether and how much to pay and sometimes that’s nothing. You can say much the same for any content provider. But such decisions are personal and not corporatized–appropriating a product and making money on it without paying the primary producers has become a form or legalized (so far) theft. I see Swift’s principled stand and my friend’s speaking invitation in a similar light.
The logic—if you can call it that—behind appropriating content without paying for it appears to be a variant of, Hey, we’ll make you famous and you can charge big next time. But next time never comes. It’s really the logic of an economic bubble and it sometimes goes by other names like the greater fool theory. Ten years ago speculators paid silly prices for real estate because it was assumed that there was a bigger fool out there ready to pay even more when you flipped the property. Every bubble has the greater fool at its core and, as we saw with real estate, it works really well until it doesn’t work at all.
I think a version of the greater fool theory is invading the analyst space. Well-paid PR firms chase analysts to take briefings from companies that pay for the PR consulting but not for the advice they get in the briefing. They very often don’t engage further than the briefing.
They seem to think we’ll look so prescient if we just write about this up-and-coming company that others will want to pay for our sage advice later. As we’ve seen others try to recruit speakers at their conferences stating up front that they won’t pay anything and that your travel expenses are yours. But consider all the exposure! The obvious problem with the greater fool theory is that it eventually ends—the music stops and the greatest fool is always left holding the bag.
I hope my friend turned down the speaking gig, I haven’t asked. Speaking for no fee is one thing, we all do it especially if there’s something real but intangible involved. For instance, I speak at CRM Evolution every year for no fee and I write a column for the magazine too. But my expenses are paid for and the magazine really has set itself up as one of the arbiters or real information about CRM. In this case our interests align because we’re both in the same business trying to disseminate information about CRM. The vendors I’ve described are, to put it nicely, looking for an endorsement.
The music business is such an economic wasteland today that songs are not being written and people are looking elsewhere to make a living. But the opportunity to write those songs will not come again. To my mind this is a dangerous time in the content business because fewer and fewer people are making a living and that’s true anywhere a form of content gets made and distributed whether in publishing, blogging, or music and it’s always been true in acting and visual art. There’s an old saying: if you can’t make money at your business then you don’t have a business, you have a hobby. What happens when we have an economy of hobbyists?
Like driving on the interstate, you can cross boundaries without noticing but after a while you just know you aren’t in Kansas any more. I had one of those moments the other day talking about mobile technology. It occurred to me that calling what we do on devices “mobile computing” was just wrong, at least linguistically, but also I think conceptually and that’s important.
Mobile has always meant a few things but mostly it implied some user at the periphery of a wireless network tied into a central server/database/hub. It was more of a master-slave relationship where the mobile user could use some but not all of the functionality available because it wouldn’t all fit on the small screen or small device. The implication was that the mobile app was a subset of the app that ran on desktops and laptops.
Gradually, mobile came to mean whatever you did on a mobile device with the understanding that devices were wireless and the apps you were using resided in a browser. It was cool stuff but over a short time, browsers have been pushed aside in favor of apps specific to a task. At some point, and I think it was when we went from web browser to app, we left Kansas and invented yet another kind of computing, which I am calling mouseless until something really sexy comes along.
A good example of mouseless computing can be found in the Salesforce Service for Apps announced this week. Powered by the Service Cloud, Service for Apps enables companies to embed customer service into apps running on mobile devices. The new designation does not come from where the apps run but what they facilitate and, to be clear, this mouseless computing is really about the ability to escape the confines of an office and a desk even if you never leave the building—perhaps especially if you never leave the building. An executive or manager with a device has the ability to run the business from the device, full stop.
There are five customer service channels or bits of functionality in the Salesforce Mobile SDK for Service for Apps that bridge computing, telephony, media, and social media and bring us to mouseless computing including: Chat; Tap to call; Knowledgebase; Case management; and a concierge service that the company continues to insist on linking with some form of disaster by associating the term SOS with it (Salesforce SOS for Apps).
A business can either build business-specific apps and embed Service for Apps into its larger CRM instances on mobile devices or it can add the Service for Apps SDK to existing business-specific mobile apps. How will this be used? Here’s what I think.
We call them apps but they are also the business ends—or customer ends—of specific processes designed to make life easier for customers. These embedded apps enable a vendor to let the customer decide when it might be necessary to step out of a more common service or support process and ask for specific assistance from a live agent or get content such as video.
Anyone worried that this technology will create a moral hazard by enabling customers to over-use live help should relax, no one (okay, no sane people) elects to get help for fun. Letting the customer decide when to jump out of an automated process is highly enabling, it tells customers that the vendor trusts them enough to let them make the decision.
It also lets the vendor off the hook for trying to come up with, and program for, every conceivable service situation. Instead, it lets the vendor say, here are our service processes, which cover most of the contingencies for this company and its products. If you need something else, please use one of these modalities to get action. This offers the real possibility that no one (okay, no sane person) will ever sully your reputation in social media or a sentiment site again simply because they were unceremoniously kicked out of a service process because no one on your side ever considered that a customer could do something unheard of in your service app.
I can see this technology used every day though not for rote processes. Its utility might be best underscored in a highly technical situation where the customer might be up to elbows in complexity and needs to access deep expertise in a context sensitive moment. I can see customers using the video chat functionality to show a service person some kind of abnormality or failure, for instance. The concierge service (SOS) may be the best example because the idea implies a high-end service for a limited number of situations.
At any rate, this constellation of functions and how they are delivered has caused me to think that we’re in new waters, thinking differently again about the vendor-customer relationship and how to solve for the customer. Did you know I wrote a book about that? It’s now available in digital form at Amazon. I have to admit though, I never considered the mouseless angle but there it is.
This is hard—moving a huge number of customers from on-premise systems to cloud systems while continuing to run the business. Hard but there are few alternatives. The last time anyone seriously tried to rip and replace was the Y2K conversion of back office systems to accommodate the new century’s date format. The effort nearly clobbered many companies.
This time vendors like Oracle have no interest in repeating the mistake so as they migrate their installed bases to the cloud, they are being careful to provide interim steps that lessen the load and the complexity though probably not the costs. In announcements made by founder, Chairman, and CTO, Larry Ellison, Oracle outlined a series of cloud services designed to help all manner of customers—from partners to enterprises—to migrate to cloud systems. But note here that migration does not automatically mean going to a multi-tenant architecture like Salesforce and many other vendors. For Oracle, moving to the cloud means only a literal translation from premise to cloud. Call it step one.
For many customers that’s enough because it will be a heavy lift moving from applications they may have been using for 15 or more years. The alternative would be to build new cloud apps on Oracle’s platform but that would take many years and dollars for some. The solution of moving the existing applications to the cloud and then contemplating a rewrite seems inelegant but in fact it makes a lot of sense. Many customers will realize significant savings by sending parts of their datacenters to the cloud—monies they can apply to new business process support.
Here are the services announced and my take on them.
Oracle Database Cloud—Exadata Service. This is very interesting because the Exadata hardware supporting this service is worth the price of admission. Exadata provides orders of magnitude speedups for most database functions because it operates in memory virtually all the time. So big reports, analytics and other database operations run much closer to memory speeds than disk speeds—in other words about a million times faster. That’s nice especially if you need to find more cycles to dedicate to data encryption for security.
Oracle Archive Storage Cloud Service. Archives are necessary and far from glamorous but somebody’s got to do it and I can see many enterprises happily paying whatever Oracle charges.
Oracle Big Data Cloud Service and Big Data SQL Cloud Service. If you need Hadoop and NoSQL databases in your enterprise, this is for you. Though this is another less-than-sexy service, its need is readily apparent for large enterprises and small. It’s also probably more than many will need but that’s likely to be viewed as a good thing.
Oracle Integration Cloud Service. Everyone needs integration services but it’s surprising to see this elevated to the scale of a cloud. Many other vendors get by with their platforms and APIs and that’s telling. If you’ve been an Oracle customer since green screens on a VAX days then this is something you might need to make sense of your less than third normal form relational DB.
Oracle Mobile Cloud Service. This is a developer tool useful in developing and deploying mobile apps. It sounds great but it begs the question, why can’t we just define apps once and generate running code for multiple target platforms? The answer is that some apps don’t have definitions that plug into code generators, they’re real code. So this is another tool for helping move and preserve what’s out there.
Oracle Process Cloud Service. I was very happy to see this because I think process orientation is where we’re all headed. The applications that are moving to the cloud in this migration and many others are built around capturing and manipulating data. But the future is about what you do with the information you glean from data that produces useful information about customers. This information will, among other things, enable businesses to better serve customers by being more intimately involved in their moments of truth resulting in bonding, the holy grail of modern business. This service is the tip of an important iceberg and it provides justification for all of the other services.
All together the Oracle Cloud Platform and Infrastructure services present a vivid picture of the state of modern business and computing. There’s a huge legacy base that has to keep working even as it is being moved. You could sniff that Oracle is enabling the legacy systems to continue operating rather than replacing them en mass but that’s an impractical idea.
The announcements Ellison made show a customer centric company focused on helping customers make generational transitions safely and economically. That might not be your first conception of Oracle. Yes, they will make money on this—I am a big fan of the motivation possible when money is involved. For many companies concerned about betting their business on new technology (been there, done that, got the scars and the Tee-shirt) this should be seen as a gradualist approach to the last generational transition of their working lives.