• April 20, 2017
  • They say it can take a product idea ten years from concept to mass-market appeal but that might be only an optimist’s viewpoint. Some of the best ideas in CRM right now have been marinating for at least that long and for some, much longer. Two great examples are analytics and CPQ that companies like Oracle and Salesforce and others have embraced with passion. Interestingly, each technology has traversed a path that needed other technologies to become fully mature.

    Analytics—and by this we mean business intelligence, data mining—an old term for what we now call machine learning—and big data needed a lot of hardware improvements to make itself prominent. For example, way back in the 1990s Kendall Square in Cambridge, MA, next door to MIT, became known as AI Alley for all of the startups there that were going to enable us to know customers’ minds before they did. Those pioneering companies are mostly gone now but their ideas generated big R&D throughout the tech sector.

    One of the major drawbacks of any kind of advanced analysis is the need for processing power on specific data. To do that you need fast CPUs but also, your data can’t be static and sitting on a disk. So the AI movement influenced not only speedups for CPUs such as multi-processors and federated computing but also in-memory databases and very dense memory.

    So of course it took twenty years to make all this happen but today we’re reaping the benefits of all that investment and research. Now we really do have the ability to probabilistically know what customers in the aggregate will think and we can act by putting next best action suggestions on a smartphone. That’s pretty cool.

    Analytics have come a long way but the ultimate benefit will likely be felt in the IoT as machines increasingly communicate with machines with rich data streams that have to be monitored for exceptions.

    CPQ or configure, price, quote software is even more of a now or in the moment idea. It was once a standalone category that could be grafted on to SFA for companies that needed it. But every company needs CPQ and without it many are reduced to relying on spreadsheet apps that often collapse under their own weight.

    Consider the spreadsheets involved in proto-CPQ. We all developed spreadsheets in-house to deal with needs not addressed elsewhere for the product catalog including prices and descriptions. Businesses also needed a spreadsheet for each deal, which would be updated multiple times within a sales process. Quarterly updates to the product spreadsheet and random updates to quotes invited all kinds of problems.

    Sales reps are known for their ability to seek out the shortest distance to close and we love them for it. But often the path went through using old quotes modified for new deals that often used old product catalogs and price lists and possibly the wrong discounting. In this scenario, management has to patrol every bid, every deal, and that’s getting to be hard to do. Management would rather be promoting the new product line with new pricing and other things that add greater value.

    There’s also the issue of turning the catalog lose on a website so that customers can configure their own solutions. But you can’t begin to do this unless you can build business rules into the process such as Product A is always sold with 2-Product B’s or 1-Product C plus services. Other forms of front office automation, like SFA, make it possible for reps to handle increasing territory responsibilities. This decreases the number of reps needed but leaves their managers with the same amount of work reviewing manually created quotes. The front office strategy today is to manage the exceptions—SFA with analytics and good reporting makes managing the territory easy. But spreadsheet-based CPQ is not a good fit for analytics so CPQ becomes the weak link in an otherwise improved sales process. Spreadsheet CPQ is impossible to manage by exception leading to slow turnaround on quotes and lost deals. To manage quotes by exception, the same as you manage a territory, you need a CPQ system.

    Not surprisingly, this is where analytics and CPQ cross paths. Analytics tools are great at finding the exceptions based on the business rules we set up. Rather than a manager scanning all deals or offers, a rules and analytics based CPQ system can simply flag outliers such as overly generous discounts or incorrect pricing. There might be legitimate reasons for the exceptions but there should also be easy ways to find and deal with them without having to sift through the majority of plain vanilla deals too.

    More than just saving labor or improving accuracy, a business that can more easily pivot on a customer’s quotation request and do it first, is in a better position to win. It’s a form of business agility, an idea much in the news today. Agility is supposed to be about flexibility and the capability to change and evolve rapidly to meet market demands accurately without incurring a great deal of overhead. Business agility is important because, while it might be possible to manually respond to a single special need, it’s not a good idea to base a business model on it. Specifically, responding to special needs—good! Doing it manually over the long run—not so much.

    Last point, if business agility is important to your business then software agility ought to be important too. This means, where possible, using solutions built on the same platform so that they use the same objects and data naturally, without having to rely on massive integrations. In my experience, many point solution integrations take a toll on IT that should be avoided if you expect to maximize your business’ agility.

    CPQ and analytics have come a long way over decades to provide us with some of the needed components of a truly agile business approach today. Spreadsheets have barely changed. In a more competitive world it makes great sense to ensure that every part of your key business processes (there’s nothing more core than sales) is supported by a system, not a spreadsheet, and the best way to do this is with platform based components like CPQ.

    Published: 7 years ago

    finance-spreadsheetAs a former sales and marketing guy I am more than familiar with spreadsheets as a not-so-good tool for managing the avalanche of data generated by the front office even before the big data craze. Name a department or function in business and you can easily find someone using a spreadsheet to manage it—often poorly but through no fault of their own. Consider this list: financial reporting, revenue management, professional services automation, human capital management, compensation management, contract management, order fulfillment, CPQ, inventory management, supplier management, and I am sure there are more examples.

    Spreadsheets’ shortcomings are well known. They capture a moment in time and when you change the data in a cell, it’s a new deal—there is no database supporting the data so there is no historic record of anything unless you go through an elaborate process of saving repeated versions of each spreadsheet. If you do that, good luck reconciling anything.

    CRM fought the spreadsheet wars at the beginning of the century with SFA gradually replacing spreadsheets in about half of all sales organizations. That’s right half, I bet you thought SFA’s penetration rate was higher but there’s still a lot of white space. CRM or SFA were relatively easy things to sell. After all SFA dealt with revenue generation and who doesn’t want to improve revgen?

    But there are large numbers of business processes, especially in the back office still under the weight of spreadsheets (see above), despite the fact that there are now quite good applications to support them.

    This point was brought home to me last week when I was invited to serve as a judge for FinancialForce.com’s Customer Excellence awards to be given out at Dreamforce. I don’t know who won so don’t ask. But in use study after use study I was both impressed and a bit taken back by the number of business processes these companies had relied on spreadsheets to perform. They replaced spreadsheets with inexpensive cloud apps and all of them came out winners.

    What was most revealing to me though were the impressive results that came from freeing a business from the overhead of recording data in spreadsheets, managing the sheer number of them, extracting information and compiling reports all through brute force methods. Companies routinely reported enormous reductions of time and costs resulting in better information flow to managers, more timely responses to customers, and ultimately greater profitability in part because things didn’t go missing.

    In the old days you could look at all of this and say, yes, but a spreadsheet is virtually free and software to run in my data center is a million bucks. It was a persuasive argument.

    Curiously, I think spreadsheets have filled their niche for so long precisely because they filled it well. It’s the niche that’s changing and that’s causing big problems. Spreadsheets with their snapshot view of reality turn out to be just right when you operate in a transaction environment. They record the data of the moment in time when the transaction took place before everyone moved on.

    But today we’re transitioning aggressively into process orientation and data needs to be collected throughout a process so that analytics can assess the next best offer or action. These are all things that require more data and that spreadsheets are bad for.

    The introduction of cloud computing and software platform technologies has made having access to competent applications cheap and easy. Moreover if you still want to build rather than buy, development on a platform has never been easier. This isn’t a column about Salesforce per se, but go to Dreamforce and look at all of the components available in the Lightning product set for rapid codeless application development.

    Now with a solid knowledge of a business any businessperson can define an application as easily as that same person might have developed a spreadsheet just yesterday. The payback that businesses are likely to reap from adopting a platform strategy and using development tools and point solutions built for the platform is potentially huge. I think of it as the next big iteration of IT, the next automation revolution that will boost profits and drive productivity. A release from the tyranny of spreadsheets is a revolution indeed.



    Published: 8 years ago

    finance-spreadsheetSpreadsheets suffered a body blow  when Salesforce announced new platform functionality last week. Soon all spreadsheets will be good for is financial analysis. This sounds funny because the spreadsheet has for several decades been the unofficial IT prototyping tool. Actually, it was the end user prototyping tool, the default thing they used to capture data when IT was famously too busy maintaining the legacy systems they got from a spaghetti factory. But with the introduction of Lightning Components, Lightning App Builder, and AppExchange for Components, it’s now easier to build your prototype app with these tools than it is to build a spreadsheet.

    Salesforce glommed onto lightning terminology as a way to convey the idea of fast development and because it sounds so much better than blitz. The idea in total reminds me of object oriented programming from 30 years ago but with much less emphasis on tedious coding and libraries. Salesforce has brought to market tools that can take a back seat to your creativity and rather than obsessing about how to do some technical trick, the developer, or increasingly the end user, can think about the business need. It’s as fundamental as an artist mixing a color without giving it a lot of conscious thought. That’s what’s happening here with components. Let us unpack.

    To me the more important part of the announcement involves components and what you do with them. A component is sort of like a widget—to some, they share a pedigree of not being terribly well defined. But for the record, a component, according the press release is a reusable building block based on JavaScript. Components can be simple or complex and include such things as e-signature, compensation calculators, maps, calendars and more, or they can just be single UI elements or micro-services with embedded data and logic. The important point is that components keep you from actually coding so that you can think about your business. This also opens up the development world for non-coders just like spreadsheets.

    Ok, so the really cool thing to me is that components will become another category in the AppExchange. They can be built by anyone and if they can be built they can be bought and sold. Of course you can spend a week building one yourself but having the functionality available on the AppExchange for pennies (ok, whole dollars) will make everyone think twice when making build vs. buy decisions.

    Components come together in the Lightning App Builder a place (I believe they refer to it as a canvas in keeping with my art analogy) where a developer goes to assemble (I think they say compose) the business app. I suppose you could think of the canvas as a blank spreadsheet if that helps.

    But the difference between a spreadsheet and a functioning app is huge. It goes without saying that unlike a spreadsheet, a Lightning app has a real database behind it. And as usual with Salesforce, apps built on the platform inherit all of the other Salesforce capabilities like workflow, Chatter, and security schema and everything else.

    A few years ago you could look at the mountain of legacy code and wonder how it could ever be rewritten for handheld devices or replaced to take advantage of all the new capabilities coming on stream. Those capabilities are substantial because, more than the transaction-oriented applications that are rapidly being replaced, they focus on various aspects of process.

    Thus the answer to the how question above has two parts. First, we aren’t going to replace those transaction systems, we will supersede them with process support that goes wider and deeper, made possible by pre-built components and subsystems. Second, we will do this because the market demands it. No one is waving a flag to that effect but I don’t think you can be in business in a social, mobile, big data world any more and not know that if you can’t leverage those things you will need to find a new job.

    Finally, and also in answer to the how question above, all of this is now possible because we have the ability to generate apps replacing man-centuries of work in hand coding. With this as the fuel of business innovation, I am excited to contemplate where it takes us.


    Published: 9 years ago