Regardless of which vendor you talk to, the pricing model still revolves around the same basic unit of measurement: bums on seats. That doesn't work in an interconnected world and solutions are thin on the ground.
Paradoxically, I believe SAP has an opportunity to take the bones of Project Trust and turn this into a model that will work for customers in the long haul.
In the good old days
When enterprise software licensing became a thing, principally after Microsoft started selling the Office Suite but used by just about every vendor since then, the originating thought was that software would be installed on single computers and should, therefore be licensed per seat.
Fraud and theft aside - where users grabbed any old copy of what was lying around - was quickly managed through license keys but the principle pricing mechanism remained unchanged.
That really didn't matter too much, even for large organizations, because they could strike deals that were an 'all you can eat' situation where the practicalities of attempting to count users and user types was unrealistic. Hand over one large check each year and knock yourself out with all the goodies the vendor throws at you. This is a system that has served the world's largest consumers of IT very well, even if some of the numbers are eye-watering to lowly plebs like me.
But even then, the main thinking was the constrained. When you distilled it down, these 'all you can eat' style licenses were only meant to cover the internal operations of an organization. They certainly did not envisage the machine-to-machine world we are close to finally getting around to implementing and which connect much more than the whole of an enterprise's technology estate. These models certainly didn't consider a business model change of the kind we are witnessing across multiple industries.
You can argue that all this changed with the Internet but as we have seen over many years, Bill Gates words:
Most people overestimate what they can do in one year and underestimate what they can do in ten years.
remain as true today as they did many years ago.
In high tech, we often get caught up in hype cycles that promise the Next Big Thing, only to discover a changed reality once we buckle down to making whatever the Next Big Thing du jour might be.
In SAP terms, the idea of the wholly connected and integrated enterprise stretches back well into the past. some might argue it was the company's founding vision but which, to this day, has yet to be seen as a reality. Even among SAP's largest customers, I defy anyone to point me to an end to end SAP landscape that covers the full customer lifecycle. Even so, today, and despite the lack of depth among hundreds of solutions in the SAP price book, that vision is alive and well. But the pricing model hasn't really caught up. Just as it hasn't for anyone else.
What has changed?
While you can point towards the rise of the connected business and the ubiquity of cheap computing resources in the shape of Amazon Web Services as a vague starting point for change, what you also have to realize is that ERP is no longer the holy grail of a CIO's life.
Over the 40 years during which ERP has been in development, I can readily argue that there really isn't that much more to do. In that sense, ERP has become a utility-commodity and should be priced accordingly.
Some colleagues argue that there is plenty to do among industry verticals. I get that but I'm not convinced that is the only place where vendors should place their bets. Why? Business models are changing and at a rapid pace. Check out the carnage Stuart regularly reports in the retail sector as an example. The reasons are unimportant for this discussion but we now see much more talk about services-oriented models where the customer outcomes are deemed much more important than the initial transaction that sold a good. Benioff's toothbrush springs to mind. You can add to that the burgeoning topic of robotic process automation fuelled by machine and deep learning where the explicit goal is to replace human interaction with machine to machine processes.
In those terms, arguing that you have the most efficient, robust and scalable ERP doesn't cut it anymore. SAP (and other vendors of similar ilk) know this but are wedded to a perpetual license model with attceched maintenance costs of 22% pa. It was great while it lasted but as vendor CFOs will acknowledge, such models may be fantastically lucrative, but they are incredibly lumpy when it comes to forecasting revenue.
Consumption based pricing is the way of the future
When you look at how utilities evolve over time, you quickly discover that the informed buyer ends up paying on a consumption basis from a choice of a few competitors. Whether that's power, water, or any other commodity, you pay for what you use.
In SAP terms, Project Trust is the first real step in that direction and it fits well with what we consider the future of enterprise computing pricing models will look like.
Today, we think nothing of paying for power on a per KW hour basis but how do we adjust to a software consumption model which, in SAP's indirect access case, is per line item processed? It's not easy to parse, albeit SUGEN and SAP believe this leads to predictable and transparent cost going forward.
I know that SAP likes 'predictable' because Luka Mucic, SAP CFO mentions this on just about every call I have with him. It appeals to the accountant who doesn't want to worry about variable income forecasts within ranges she can't control. SAP is hoping that 'predictable' will appeal to customer CFOs just as much. It will require some education but it should do.
Those who have invested vast amounts in getting their ERP's tuned just the way they want, operating under the legacy model will resist this type of change because they are reaping the benefits of those past investments and will not wish to give them up. But - when you are deriving value because of the ability to do something new - primarily through a fresh tranche of automation and wide-ranging third-party integration that enables you to change the business model - then should that not be reflected in the pricing model for the supplying vendor? What about the fsaact that under cloud/SaaS model, you have passed all the infrastructure and maintenance costs back to the vendor?
Where is value created?
The problem comes when you start to consider the topic of value. In ERP terms, a unit of value is created when a transaction is processed. That is easy to understand because, despite all talk to the contrary, money still talks, especially when it's in the bank. But it's not the only place that value is created.
Today, business sees value created in the things that are much harder to measure or quantify. There are for example no standard, well understood and reliable ways to measure customer happiness, regarded as a key ingredient in securing long-term relationships with customers who will continue to buy goods or use services. In short, there is no universal 'like' button I can press that tells a vendor much of use for the purposes of that assessment. And in any event, how does that relate to largely static back office systems? It doesn't, except when I'm no longer buying.
You could, therefore, argue that current efforts to produce better predictive behavioral models are where the value action is located. In those cases, you can also argue that the potential for value delivery is so high, that there is no business value delivery model on which customers can rely other than one where there is shared risk/reward. Personally, I believe that is the correct model for current development that takes advantage of advanced analytics and the artificial forms of intelligence from which predictive models can be usefully built.
But that still brings us back to the question of ERP and its pricing.
What next for SAP pricing?
I recall during one of the many conversations I've had on indirect access pricing that I suggested the emerging SAP indirect access pricing model could be the start of getting the SaaS model right for SAP customers moving to its cloud-based ERP and other systems. While no-one explicitly agreed, no-one argued against that thought. And in any event, a wholesale move among customers to SAP's cloud is years away.
In my mind, SAP has opened the door to that discussion and should actively pursue research on those lines because, if done well, it serves the customers best interests while securing its own future.
While colleagues will likely yell at me to check the AWS model, SAP could do worse than take a look over the shoulders of Acumatica. Its pricing model is interesting because it addresses precisely this problem. From its pricing page:
Acumatica allows unlimited users by following a consumption based pricing model – you are charged based on the resources your company requires for the transactions you anticipate. And you can always increase or decrease these resources when necessary.
Start with what you need now to handle the transaction volumes you expect and adjust resource levels and data storage as your business grows, to maintain the correct service levels as you add users and increase transactions. The Acumatica pricing model comes in incremental tiers and can be adjusted as needed.
Simple? Sure. Customer friendly? Jon Reed can tell you more about that, but so far the messages coming back suggest customers like this model. Predictable - not now maybe for SAP customers but certainly over time.
Today, we are focused on how SAP and its customers get from under the many contradictions swirling around the variety of contract in place where there is an indirect access component. I'm aware that SUGEN has a whole separate discussion on the matter of contract simplification that will likely drag out into the future.
But...I'd really like to see SAP Project Trust as a stepping stone towards a more expansive vision of consumption based pricing. If realized, it will make life a whole lot easier and predictable for everyone concerned. It will in short, me body what we all implicitly know - technology is integral to every business model, it is a cost fo doing business and should be recognised as such.