and Innovation – Are Trailhead and Einstein Enough?

You know you’re on to something as a vendor when people show up to a keynote and give your speaker a raucous standing ovation when she walks on to the stage. It’s even more significant when you’re ramping up a populist developer program and your audience of developers act like they’d happily march off a cliff, if only their leader would tell them to do so.

This was the reaction when Sarah Franklin, who heads developer relations at and is the GM of the company’s pioneering Trailhead developer engagement program, hit the stage at Dreamforce for the first-ever Trailhead keynote. Her applause was well-earned – Trailhead has emerged as the most energetic and engaged community of developers in the enterprise software space, particularly among’s enterprise platform competitors, the likes of Infor, Microsoft, Oracle, and SAP, among others.

But being first in energy, enthusiasm, and even hyperbole – loves to brag about the near trillion dollar potential impact of Trailhead and its ability, potentially, to create 3.3 million jobs by 2020  — doesn’t mean has its innovation strategy problems licked. On the contrary. What all this enthusiasm and interest in Trailhead has exposed is a fundamental weakness in the overall platform/ecosystem strategy that needs to be fixed. Or Trailhead and its Trailblazers will be relegated to enabling a mere slice of the vast innovation potential that exists in the enterprise.

The weakness? A too-narrow focus on CRM for Trailhead and the company’s foundational platform and development technologies that limits who will be using’s innovation technology and what that technology can be applied to. It’s a weakness that is, so far, too deeply entrenched in the DNA of the company – starting with its stock ticker symbol, CRM – to be easily remedied. But, without a remedy, Salesforce and its Einstein and Trailhead initiatives will fail to reach their potential, and that won’t be good for the company and its partners. Customers, on the other hand, probably won’t care – which is all the more reason the problem needs to be solved soon.

The problem of who develops innovation is part of the industry-wide shift to using technologies such as AI, ML, and IoT – though these three technologies are really proxies for all the coming net-new innovation in the enterprise. The “who develops” problem is about the fact that innovation is being led, or at least partially led, by experts in lines of business who are being tapped to define and help develop the next transformational business process or app. These experts are gravitating to a combination of design thinking workshops and citizen-developer tools as a way of embodying innovation in new apps: Pretty much everything I see that is transformational is coming from this grass-roots effort inside the enterprise. IT is no longer the default starting place for innovation, though IT is generally taking a seat at the table when it’s time to do some of the plumbing and inside wiring that is needed to move from concept to working app.

From a vendor standpoint, the formula for success in this new paradigm of innovation starts with having a IaaS/PaaS platform, and some great developer tools, and has this down pat. You also need a decent and always growing innovation platform, and Einstein is arguably as good or better than most. And you need access to existing data and business processes that, at a minimum, can be used as a starting point for building new killer apps and processes. Derivative and additive are perhaps the best way to describe many of the newly emergent apps coming out of digital transformation efforts: they’re build on top of a combination existing and newly available data and processes. Very little transformation starts from a truly blank slate.

And this is where being the best CRM platform in the industry – a point co-founder Parker Harris insists on being one of the polestars of the company – and having the best engagement model for CRM developers, starts to fall short.

The seeds of digital transformation have to come from across the enterprise, and the resulting apps will span the enterprise as well. One of the most basic starting points for digital transformation is the breaking down of functional silos and the creation of cross-enterprise capabilities, and that means no single line of business will be in the lead all the time. For CRM-related transformations, those Salesforce admins who make up the bulk of the Trailhead membership could be the ones taking point, but they won’t necessarily be able to digitally transform the warehouse, the shop floor, finance, logistics, and other domains. That transformation will need input and support from experts in those LOBs, not’s CRM admins.

To be fair, not all Trailhead developers are Salesforce admins, and not all developers look to Trailhead for guidance and inspiration. Heroku, a Salesforce platform, is used by a lot of startups and developer groups for building innovative apps that have nothing to do with CRM, and the company is increasingly opening up Trailhead and other developer resources to embrace the professional developer class.

Nonetheless, professional developer tools aren’t enough of a solution to the limits of a CRM-only focus. You need citizen developer tools in the hands of LOB experts – or at least wielded by teams that include these LOB experts – to truly realize the potential of  home-grown digital innovation. And for those apps that potentially span multiple LOBs, even if the transformation is skewed heavily towards CRM, a CRM platform isn’t necessarily going to be the go-to platform that bridges those silos: The experts in those silos will have their own most-favored platform – which won’t be a CRM system – and they’ll be wanting to use their own platform tools to build their innovative apps.

Remember that account control is a myth across the enterprise software market. Virtually all medium to large-size enterprises have multiple enterprise software systems – the overlap between and Oracle or SAP is huge. And they increasingly have multiple platforms as well, including Azure, AWS, Google Cloud Platform, and others that are also competing for the hearts and minds of developers. The result is that winning – as in getting a customer to build digital transformation apps on a given platform – isn’t going to be about which vendor has the best technology stack. It’s about how many developers you can bring to a given platform vendor’s digital transformation party.

To be fair, the problem of enticing and connecting with future digital transformation developers is shared equally by’s platform competitors. SAP has a huge presence in many LOBs in many companies, but there are plenty of LOBs that don’t use and may not even like SAP. Same with Microsoft: tons of presence all over the enterprise, but not every LOB is ready to use Azure as its dev platform. As proof of how no one has a lock on innovation, I have seen the same elevator company logo on presentations about distinct digital transformation apps from both SAP and Microsoft. Different parts of the company follow different polestars and therefore use different technologies to advance them towards their innovation goals. That’s going to be what the evolution of digital transformation will look like for the next few years, if not forever.

But at least SAP and Microsoft (and Infor) are present in multiple LOBs. is another case altogether: I think it’s safe to say you won’t find a Salesforce user, much less a Salesforce admin-cum-developer, hanging out in non-sales and service LOBs ready to tackle digital innovation projects. They may be at the table – and probably should be – when the transformation at hand touches CRM, services, marketing, or any of the target LOBs that Parker’s “best CRM platform” encompasses. But will they be able to direct the development effort towards Einstein and Lightning, instead of SAP’s Leonardo and Fiori, or Microsoft’s PowerApps and Azure, or IBM’s Watson or Infor’s Coleman for an app that isn’t primarily focused on enhancing a core CRM function? It’s not likely if they’re using a CRM platform and CRM-focused tools.

This scenario is why I say that the customer won’t care one way or the other. They’ll get their apps built no matter what, using what someone in the target LOB thinks is the best platform for the job. Only their vendor will care… And the IT department, which has to make sure the new app makes technical sense and may try to influence this choice, though their influence will be limited.

What’s the solution to Salesforce’s innovation problem? That’s going to be tricky – developing a presence in the LOBs not touched by won’t be easy. There are some partners that can help – FinancialForce is a good example of an LOB-focused product set that can help Trailhead and Einstein reach other LOBs, like finance and professional services. But that probably won’t be enough to make a huge difference without some air cover from the mother ship. could definitely take a page out of SAP’s Leonardo book and showcase as wide a range of examples of innovation as possible with Einstein and other tools, emphasizing, as is possible, the applicability of the Salesforce approach outside its core LOB. I was recently at SAP’s latest Leonardo Live event, and it was the first time Leonardo was presented by showcasing a number of truly amazing new apps, instead of just going on about the theory of what Leonardo could do. Assuming Salesforce can prove its mettle in non-CRM lines of business, this will be a credible first step towards a broader developer base.

The company could also buy its way into other LOBs, though the existing candidates that could make a difference are becoming increasingly hard to find. Or it could make a more concerted push to build use cases for its platform outside CRM, and try to show by example why a new warehouse management system should be built on a Salesforce platform, instead of something else. Maybe there’s even a way to put more CRM into the warehouse that would make’s tools the logical choice. Maybe.

Of course Salesforce could just hunker down and focus on being the very best CRM platform provider – and there’s a wealth of opportunity out there in CRM-land. But I’m doubtful the company’s leadership would be content stopping there, and it’s not really a good idea to cast so narrow a shadow. The universe of potential transformative apps and processes that touch CRM is huge, but it would only be huge enough if can expect to capture a decent percent of that potential. My concern is that those apps won’t necessarily be seen as CRM apps, any more than a next-gen asset maintenance app won’t necessarily be seen as an ERP app. And’s big developer bet will hit a wall it can’t get through.

It would be a shame to see the best developer engagement program in the industry hit this kind of wall, but without some effort to be more than just the best CRM platform in the industry, I believe it will. Sarah Franklin will probably still get the applause, and the job creation stats for Trailhead will probably still be impressive, and the examples of how CRM can be extended using AI, ML, and IoT will grow at a decent pace . But if’s platform play is going to be the vehicle for expanding outside of the company’s CRM base, and growing net new revenue, and otherwise challenging its big competitors in this new digital transformation battlefield, then something will have to change. CRM as an acronym doesn’t really tell the story of where digital transformation has to go. And having the best and most engaging CRM developer story simply won’t be enough., Trailhead, Einstein, and the rest will have to figure out a way to do more. Or settle for less.

The Enterprise Software Synergy Effect, Part II: How Acquisitions Fail To Realize Their Potential

In last week’s post I began a tirade on why the book I want to publish when it’s time to retire, Josh’s Extremely Thin Book of Successful Acquisitions, would really be a very thin book. The subplot? It’s about vendors not being able to leverage the synergies in their portfolios to make acquisitions synergistic. The problem – embodied in my favorite aphorism “all the great ideas in marketing go to the field to die” – is that upselling and cross-selling newly acquired assets is hard, and it’s not all the vendor’s fault.


A big part of the problem upselling and cross-selling acquired software alongside existing assets is about getting the right decision-makers in the room when the pitch is made: Many prospective customers are too siloed or lack the vision necessary to buy into these visions of digital transformation, especially the business network vision. It’s hard to find that vp of business networks. And the CFO and CHRO aren’t always aligned in the right way to buy into, literally, a strategic, synergistic, vision of 1+1=3 in their own organizations.

Customers are also often internally siloed by vendor: the SAP crowd inside the typical heterogeneous customer (which is the majority of upper midmarket and large enterprises: single vendor account control is a myth) doesn’t necessarily hang with the Oracle crowd, the ones running older Baan manufacturing systems don’t talk to the people using Microsoft Dynamics, Salesforce admins don’t necessarily talk to the procurement people, and on and on.

So alignment and pitching to the right people is as essential as it is elusive. But this isn’t a chicken and egg paradox, each side waiting for its yin to yang. The vendor is both chicken and egg, and before those things can change, the vendor’s vision needs to be marketed, shouted from the rooftops, and otherwise evangelized. Companies in the global economy need to start thinking about business networks, and companies looking to transform need to think strategically about new ways to manage their workforce. These seeds desperately need planting, and if vendors don’t plant the seeds, nothing will grow.

My beef is that pretty all serial M&A vendors fall short in planting these seeds, despite the fertile soil at their disposal. That fertile soil starts with the keynote stage, a place where synergistic visions should hammered on at every opportunity.

By the way, just because in part I singled out SAP in part I doesn’t mean this is just an SAP problem: Microsoft has been guilty of the synergy problem in the past. To their credit, the recent Ignite/Envision conference featured some decent synergistic messaging in Satya Nadella’s keynote about what LinkedIn can do for CRM and HR functions and how the Dynamics “suite” (which, other than Dynamics’s CRM functionality, came to Microsoft via acquisitions) can power process-driven, modular composite apps.

Oracle suffers mightily from the synergy problem – the lack of integration of NetSuite is the latest case in point – and IBM and HP have basically made the synergy problem a core competence. Only Infor seems to be relatively immune – their recent acquisition of GT Nexus and the synergy of having a global logistics network tied to Infor’s B2B strategy was front and center at their user event in July. Of course, CEO Charles Phillips’ tenure at Oracle – and his involvement in the Fusion fiasco – has had a lot to do with Phillips’ determination to do integrated, synergistic software the right way. Nevertheless, Infor has to turn a well-articulated strategy into real revenue – despite the fact that elements of the company’s cloud strategy are still works in progress . The execution side of Infor’s synergistic strategy is something I’ll be watching out for closely in the coming year.

This is the problem with the synergy effect: its looks good on paper, and in presentations to analysts. But if the vendor’s reflexes aren’t tuned to delivering a message about how 1+1=3 or more, then the acquisition may plug a revenue hole, but it won’t be able to realize anywhere near its potential.

This means it’s time to evoke another one of my favorite aphorisms: the biggest mistake enterprise software vendors make is that they try to sell software the way they build it, not the way the customer consumes it. The synergy problem is a version of this: in the effort to maintain the acquired brand and its customers and sales organization, acquiring companies tend to go overboard in maintaining silos instead of stressing synergies. The problem becomes baked into a company’s strategic messaging, such that during big annual customer events like SAP SAPPHIRE, or Oracle OpenWorld, the frenzy generated by each internal product or strategy stakeholder fighting tooth and nail to get their two slides into the CEO’s presentation practically guarantees that the keynotes – and therefore the primary messages – become siloed.

By pitching a product strategy that was the result of a team of rivals duking it out for keynote real estate, any hope that a real story about how to consume all the different parts of the product portfolio in a comprehensive, synergistic way gets lost in the loud music and overly enthusiastic “I’m so excited to be here” exclamations from the stage.

Without enough seeds, and enough air cover at the top about synergy, field execution becomes not just a bottleneck, but another example of the all great ideas in marketing go the field to die problem. Even if incentive programs are set up right, how can sales execs sell to a broader audience if there isn’t one, and their bosses aren’t trying hard enough to cultivate one? And even if the air cover is there, many of these individuals know how to sell either to IT or the line of business, but not both. The result is a million war stories about the one that got away, lost because a competitor could tell a more compelling but limited story or because the losing party’s more compelling story doesn’t have the audience of influencers it needs to make the sale.

It’s tempting to say that if the problem may be too entrenched to resolve, which may be why it remains unresolved within so many companies. But I’m an optimist: I think these messages can and should be told at every opportunity. How difficult can it be? Apparently very. Sometimes I wonder if the other career-ending book I  should write is Josh’s Extremely Thin Book of Successful Keynotes, but I’m willing to wait a few years on that one. It can’t be that hard, can it?



The Enterprise Software Synergy Effect: How Acquisitions Fail To Realize Their Potential (Part I)

The problem with acquisitions is that they’re always meant to add revenue and drive synergies with existing lines of business, but all too often the acquisition falls short of its original goals. Some turn out to be bad deals, or even worse: Ask HP about Autonomy (or Compaq, or Palm, or EDS, for that matter). Or Microsoft about Nokia. Or SAP about Sybase. Or Oracle, which just recently finally killed off Sun, closing a chapter on one of its biggest, and dumbest, acquisitions.

I always joke that when I’m ready to retire I’ll first write a book entitled Josh’s Extremely Thin Book of Successful Acquisitions. It’s going to be really thin and it’s going to piss off a lot of people. In truth, I’ve been writing that book my whole career, as I have watched too many deals enrich investors and shareholders (usually a select few)  and none others – not the employees, not the partners, and certainly not the customers. And that’s before there’s any attention paid to whether the acquisition is accretive, as in being worth more than its cost, as well as synergistic, as in acting as a revenue multiplier when sold in conjunction with other software and services.

And while there are definitely acquisitions that are accretive, or at least not too decremental, by all objective measures most acquisitions, even the ones that seem to go well, are plagued by the synergy problem. Sure, apply a little accounting legerdemain and the acquisition looks like its driving a healthy revenue stream to the bottom line. But the reality of what’s happening in the field, where all the great ideas in marketing go to die, (the title of another career ending book I want to write) isn’t all that healthy. The fact is that most vendors struggle to achieve the synergistic potential for their strategic acquisitions, especially the potential that was in the marketecture slides when the deal was announced.

Let me pick on SAP for a minute, though they are hardly alone in this lack of synergistic success. SAP has made some pretty big cloud bets recently, and two of them, unfortunately for SAP, its customers, and partners, are exemplars of the synergy problem. True, the two acquisitions have been successful by most measures, but their synergistic value – that’s a different story.

SAP closed the Ariba and SuccessFactors acquisitions 2012, and the synergistic potential for both was huge. Ariba was one of the biggest of the indirect procurement vendors, but, more importantly, it was the heir to a dotcom vision of the global business network (remember the term net markets?) that would have leveraged SAP’s enormous customer base and built an interconnected commerce market that spanned the globe.

The Ariba acquisition, on paper, meant that SAP could take a procurement network with thousands of suppliers, many of them already SAP customers or active suppliers to SAP customers, and bundle the whole lot into an online, interactive, global commerce network where everyone could source, buy, supply, ship, track and trace, and otherwise move B2B commerce from its relatively dumb 20th century EDI origins into the 21st century’s vision of a connected global economy.

SuccessFactors was an even more straightforward opportunity: SuccessFactors HR + SAP Finance = competitive wins and major synergistic value. The acquisition was and remains a big deal for SAP: SuccessFactors was a pioneering HRMS SaaS company that not only injected some vital cloud DNA into a moribund on-premise culture, but also provided a perfect complement to the finance functionality built into SAP’s core ERP product line. And as that ERP line moved forward into the cloud via S/4 HANA – noch besser.

A half-decade later, and the contribution of these two acquisitions to SAP’s revenues is indisputable – though there are signs that SAP management thinks they could do better. But has either brand really stepped up and optimized their synergy with the rest of the company’s products? The answer is no.

And that’s gotta hurt. For SAP, like every on-premise vendor transitioning to the cloud, any unrealized potential for cloud revenue growth is like a slow acting poison. Companies like SAP – companies that started on premise and moved to cloud – have an unhealthy reliance on maintenance revenue from their on-premise products, and the cloud has to become the place where revenue growth can be about more than getting customers to upgrade their on-premise systems. If these transitioning vendors can’t move their customers to the next shiny new thing – in most cases a synergistic collection of newly acquired assets and pre-existing or nearly developed in-house products –  the poison eventually erodes the confidence of investors and customers, and the next IBM or HP is born: a pile of disconnected, disjoint assets that look connected and synergistic on a slide or two, but aren’t successfully sold that way, to the detriment of the vendors’ revenues and market clout.

That’s why it’s so important for these acquisitions to be truly synergistic: the HR and talent functions in a company should be connected to finance, and the rest of what we still call ERP, as a prerequisite to any effective digital transformation – and the more customers do this the better it is for all, customers and SAP alike. As to the vision of a global business network: making Ariba the hub for the myriad transactions and data that constitute the backend of B2B commerce would represent another huge digital transformation potential for customers, and a huge revenue uptick for SAP.

If only…

The reason why this kind of synergy isn’t happening, both for SAP and others, is complicated. This is the problem with the synergy effect: its looks good on paper, and in presentations to analysts. But if the vendor’s reflexes aren’t tuned to delivering a message about how 1+1=3 or more, then the acquisition may plug a revenue hole, but it won’t be able to realize anywhere near its potential.

I’ll explore the reasons why the synergy effect isn’t happening for major enterprise software vendors, and where companies can start looking for solutions, in next week’s post.


Artificial Intelligence and Artificial Expectations: Enterprise Software Enters the AI/ML/IoT Morass

This is the year of hyping artificial intelligence, machine learning and the internet of things (IoT). Any vendor with any vision, which is everyone, is blanketing customers and partners with pronouncements and keynotes that highlight an increasingly large roster of products, platforms, and technologies loosely organized under the AI/ML/IoT rubric. The result is that these acronyms and the products they represent are everywhere, singing, and dancing their way to our hearts.

But not our wallets. At least not yet.

While it seems as though the primary issue at hand is how to link AI/ML/IoT to the digital transformation wave that has gripped the market, the bigger question centers around whether the revenue predictions these technologies are being associated with will ever even remotely come true? Some of these predictions seem a little hyperbolic: I’ve seen revenue predictions ranging from $20 billion to almost $40 billion over the next eight years or so, and more than one enterprise software vendor CEO has told me and his customers that these technologies will account for the lion’s share of revenues in the near future.

The likelihood of this happening is small, at least from where I sit, and the answer to the $20 – $40 billion question lies somewhere between no way and kind of/sort of. Every time I hear about billions of dollars of sales coming down the pike for these three technologies I start wondering how those numbers will ever obtain without some highly creative, budgetary gerrymandering that shifts existing spending on things like analytics, operations, and app development into the AI/ML/IoT category. Yes, lots could be spent on AI/ML/IoT, but will that really be net new spending, imparting net new growth, or will it be another revenue shell game, hopefully making investors happy but not really yielding massive net growth?

The distinction is important, because more and more big enterprise software companies, even those that are cloud natives, are living off the fumes generated by what is effectively maintenance or renewal revenue: an annuity revenue stream based on maintaining the existing, rather than moving forward to the net new. That simply cannot go on forever, particularly as core enterprise software functionality (such as ERP, HRMS, CRM, etc.) commoditizes – what we like to call these days “fit to standard” – and starts heading to the cloud. In the upper atmosphere those fumes are just going to get thinner and thinner. And In their place, if the vendors are to keep their investors happy, some new, bright shiny thing has to show up to generate billions in net new revenues from thousands of net new customers.

(As an aside, the maintenance stream is so powerful that it papers over lots of transgressions, omissions, and just plain sloppiness: it often seems that it really doesn’t matter whether a deal is a good deal, or an implementation is a good implementation, or a customer is even a happy customer, as long as it produces a steady annuity that means, effectively, that every four or five years the vendor brings in 100 percent of the original deal’s value – at a huge margin. That’s where the real profitability – for those vendors that need to show profits – is in enterprise software is today, and will be for a long time.)

So the shiny new things called AI, ML, and IoT – with snappy brand names like Einstein, Watson, Leonardo, Coleman, and others – are the latest attempt to find an innovation revenue stream that can rival what core enterprise software was able to deliver for the last few decades.

So far, I’m not sure this is the panacea the industry has been looking for.

Let’s start by making one thing very clear – AI, ML, and IoT have been around for years, decades actually, and are themselves neither new nor any easier to actually put to work today than they were when I started my tech career in the 1980s (more on that in a minute, and I don’t mean about how old I must be.)

What’s new is the raw processing power available, firehose-style and in the cloud, from the likes of Azure, AWS, Google Cloud, and others: An absolute necessity considering the underlying need to consume and process the enormous analytical models that underlie AI/ML/IoT functionality.  Also new are the quantities of data available to be applied to AI, ML, and IoT: Large datasets are needed in order to use complex statistical algorithms with any hope of statistical validity, and the sensor revolution, the growth of consumer internet data, and the increasing footprint of technology in all aspects of our personal and business lives are yielding a rich pallet of new data sources for use in AI/ML/IoT.

But….the issue of knowing what to do with these technologies, and doing the right/valid things with them, is still a massive challenge. The proofs of concept are piling up, and some of them are pretty impressive. Microsoft is doing really cool things helping elevator company ThyssenKrupp with its elevator maintenance,. And SAP is using components of Leonardo – among other technologies – to help its elevator customer, Schindler, transform their installation process.

The Schindler example is a good one: SAP’s Data Networks group worked closely with Schindler to build the Live Install app that was showcased at last spring’s SAPPHIRE user conference. That work was highly consultative in nature, and, while also highly successful, isn’t necessarily scalable to other companies (such as, one could assume, snarkily, ThyssenKrupp, though they are also an SAP customer): building an app like Live Install, with all the net new digitized processes behind it (including modeling and virtual reality visualization of what the final install will look like) can’t be done out of the box. At least not yet.

This isn’t a criticism of Data Networks, on the contrary: their mandate is to pioneer these kinds of creative use cases that are based on data already available to a customer, and Schindler is a perfect example of this. It’s just that while one can assume SAP made a profit on the project overall, and while it’s clear that there’s a tremendous amount of learning to be had by an undertaking like Live Install, projects like Live Install won’t necessarily yield standardized products that can be included as a line item in a customer contract any time soon.

And that’s because when you combine the knowledge and understanding that customers have about potentially transformative processes or apps (which is limited) with the emerging status of these technologies (which are very nascent), you end up with something that by definition has to be very consulting heavy and relatively light on the packaged, repeatable software side.

It’s the nascent status of these three technologies that poses the greatest threat to vendors looking for something to lead them to the next wave of big projects and big paydays. With pretty much every branded entry (Leonardo, Watson, Einstein, among others) existing primarily as a set of APIs to be used by developers to build highly customized apps, the question of which AI/ML/IoT “product” set to use all too often boils down to a question of which vendor the developer knows best.

And who are these developers? In general, they could be anyone: so-called citizen developers, partners, and hard-core internal coders, among others. While often very disparate in their skill sets, a deep line of business expertise is becoming de rigeur for using these technologies successfully. This expertise is fundamental to the opportunity at hand: killer apps in the AI/ML/IoT market space are by definition very LOB-focused, which is the opposite of the old-school, IT-focused developer audience of yesteryear. IT certainly gets involved, hopefully on a regular basis, but any company engaging in a design-thinking workshop about coming up with a cool, transformative AI/ML/IoT app is going be leaning very heavily on LOB staff to come with the ideas, validate them, and, increasingly, roll up their sleeves and help build a prototype. IT may step in to make sure the backoffice integration is done right, but I expect the LOB to take the lead on a majority of these projects.

This is the meta-transformation that these technologies are bringing to the enterprise: new skills are needed to figure out how to leverage AI/ML/IoT. These are skills that have been there all along, but until now they haven’t been in the room when new technology adoption is being formalized, because the people with those skills traditionally haven’t been involved in new apps development at the initial stages of the process.

Nor are they in the room when an incumbent enterprise software vendor’s shiny new technology tools are being entered, usually by their proponents in the IT department, into the “build my transformational app” sweepstakes. These vendors have always struggled to break out of their IT focus and work within the LOB organizations, even after they acquire LOB-specific vendors, and their field sales staffs tend to have a surfeit of IT connections and a dearth of LOB connections. This leaves the vendors, via their field sales staff, trying to sell tomorrow’s message to last year’s audience. Not really the best way to go-to-market with a new strategy intended to be the next ginormous thing.

Which brings us to the real problem for the enterprise software vendors looking to break new ground in AI/ML/IoT: if you’re an old guard ERP vendor, chances are you’re either not well known to, or highly unpopular with, the LOBs. They either never used your software, used it and hated it, or have just heard about how crappy traditional enterprise software vendor implementations have gone, and want none of it. So when it comes time to build a cool new transformative app, the reflexive move in the LOB is not necessarily to look at the old guard vendors’ new AI/ML/IoT tools. If they even get to hear about them. It’s much easier to start by considering the tools or platforms that are already in the LOB first. If they come with a cool new desktop experience or mobile app that LOB users are familiar with, when it comes time to look into building AI, ML, or IoT apps, the reflexive move will be to the LOB vendor, not the one that the IT folks like.

Newbie cloud-native companies have this problem in reverse: while they are beloved by their users, who usually occupy a specific LOB (sales and service, HRMS, etc.), the rest of the company’s users aren’t necessarily at all familiar with the cloud native company. Nonetheless, when a new app needs to be built that’s exclusively within the domain of the LOB, chances are the LOB cloud vendor’s tool will be used –’s Trailhead developer engagement platform is a perfect example of this: the last Trailhead conference I went to in June was replete with Salesforce admins and other LOB users avidly upgrading their skillsets in AI/ML/IoT and mobbing the presentations and demo stations with an eagerness that still makes Trailhead the best new developer outreach program in the industry.

But even Trailhead or other LOB vendor offerings have distinct limits. Could a LOB vendor expect the asset maintenance folks at a company like ThyssenKrupp to choose their LOB-focused tool when they’ve had no exposure to it? Not likely: they’ll go with what they know and are familiar with – it’s human nature to default to the known quantity whenever possible. Indeed, in the world, the fact that Salesforce has repeatedly said it’s going to provide the best CRM cloud in the business would tend to shut out developers (and ISVs) from going with Salesforce for something completely outside the CRM domain.

It’s important to note that against this backdrop of a commoditizing tools and platform approach by most vendors, Infor has taken a different tack, and I’m curious to see how this works out. Their approach is to productize their AI/ML/IoT dreams, and go to market essentially with an apps, not tools, approach. This can’t be done without working very closely with customers as well, and that of course means that Infor will have to finesse the problem of who owns the IP that goes into the finished product. That won’t necessarily be easy.  But it does represent a way in which the results of Infor’s early forays into AI/ML/IoT will yield a repeatable, scalable products business instead of more risky consulting-driven business.

Regardless of the approach, the bottom line is that it won’t be easy to convert an installed base that is familiar with an enterprise software backoffice product into the advocates for massive, enterprise-wide AI/ML/IoT projects based on that backoffice vendor’s toolset. The IT folks who know enterprise software aren’t necessarily taking the lead on these new projects, that responsibility is more and more residing in the LOB, many of which are disconnected, disaffected, and/or estranged from the IT side of the business (those of you who have ever tried to bridge the divide between IT and, for example, shop floor operations, or HR and ERP, know what I’m talking about.)

Neither will it be easy to make LOB prototypes or even first generation production apps the harbingers of massive, enterprise-wide sales either: the LOB influencers who can get approval for a POC or even that killer LOB app don’t necessarily have the clout to enforce an enterprise-wise AI/ML/IoT tool or platform standard on the company. Their counterparts in other LOBs will likely have their own tools in mind. And so the morass continues.

What may be more common is that as the POC morphs into a production app it will continue to use the same toolset/platform that it started with, providing an upsell/cross-sell path for the lucky vendor with an inside track in the LOB. Which is why it is incredibly important to be in on these early deals as much as possible in order to plant the seeds for the evolution of these POCs into full-fledged production systems. But that doesn’t mean there will be a single corporate AI/ML/IoT standard to emerge: large enterprises are incredibly heterogeneous, and much of that heterogeneity is due to the fact the LOBs have had the leeway to pick what they see as best of breed apps. I see no reason why the LOBs won’t continue to exercise this independence. And leave it to IT to clean up the mess.

Hence my skepticism about net new revenues in the tens of billions of dollars any time soon. There will certainly be some decent revenue from early POCs as they convert to production apps, and hopefully examples like those at Schindler and Thyssenkrupp will yield upsell opportunities for their respective vendors. But to date I don’t necessarily see a path from there to massive enterprise-wide deployments worth hundreds of millions of dollars. Not of  the scale to eventually supplant the aging systems now driving all that maintenance revenue.

Which why I call this a morass: AI/ML/IoT are clearly among the shiniest, newest things around, and as these technologies demo well and make for compelling case studies, it’s easy and fun to showcase the early customer wins. But it’s going to be a long time before these technologies become major factors in their respective companies’ revenue streams.

The most hopeful scenario, which indeed is beginning to play out, is that every vendor – cloud native and traditional backoffice – is poised to reap enormous benefits from what I call the transition to transform opportunity. Companies running older versions of their enterprise software – and that’s usually a majority of any vendor’s customer base – will at a minimum need to move to a new backoffice platform as a means to get the ball rolling on digital transformation and the application of AI, ML, and IoT.

Those transitions could be lucrative – more will be reimplementations than upgrades, in my opinion –  and there will be net new customers coming on board as well. But transition projects are only buying time, not the future. The future isn’t in the backoffice, that much we know. Where it lies from a revenue standpoint for vendors, and what is going to induce customers to engage in the next generation of massive, high-priced projects, remains to be seen. AI/ML/IoT will have to play a role, but those technologies alone won’t be enough. Hype can only take a market so far.




Infor Drinks Koch By the Barrel While Microsoft Dynamics Sips A Thin Gruel

Apparently my blog post last month accusing Microsoft of neglecting its Dynamics product line struck a nerve. The gist of the post was that Dynamics was falling into irrelevance as Microsoft seemed to focus on bigger and better things. The evidence has been pretty definitive – no Dynamics-specific user conferences, analyst events, or, from what I could see, senior executive interest – and the results have been as expected: out of sight, out of mind. Judging from the feedback I got from all over the enterprise software market, that perception is pretty widespread among customers, partners, and my fellow analysts.

In the meantime, I was invited to New York to attend Infor’s annual user conference, Inforum. This is the showcase for the largest enterprise software company no one has heard of, but that’s all about to change. Highlighting the analyst preview day was a presentation from Infor’s newest investor and industrial partner, Koch Industries. Koch, in case you only know the name because of the Koch brothers political activism (I’m not being partisan, they’re pretty happy to highlight this on the company’s home page), happens to be one of the largest private industrial companies in the country and is now poised to become a laboratory for how far Infor CEO Charles Phillips can take his vision, his ambitions and his company.

You couldn’t find two more contrasting approaches to enterprise software than Infor and Microsoft.

Microsoft responded to my blog post with, to their credit, access to the two senior execs in charge of keeping the lights on at Dynamics, and, from what I understand, lighting a path from the rest of the company back to the core ERP, CRM, and other assets that make up the Dynamics family. What I heard was interesting, and in some ways offered a solid rebuttal to my characterization of Dynamics as the unwanted and unloved stepchild of the Microsoft cloud juggernaut.

But nothing Microsoft said or hinted at or offered under NDA can compare to what Philips was willing to share with a couple dozen analysts as part of one of the best analyst programs in the industry.

Let’s start with the Koch story. Koch’s CFO, Steve Feilmeier, took the stage in front of the analysts at New York’s Javits Center and basically hit a bases-loaded home run into the Hudson River. To set the stage, Feilmeier hammered home the enormity of what partnering with Koch Industries means: Koch is a $100 billion-plus behemoth that spans the oil, gas, paper and pulp, chemicals, and plastics industries, among its many lines of business. It has 130,000 employees, spread across 60 countries, and would be high up on the Fortune 500 if  it were a public company.

Here’s what was so impressive about Feilmeier’s talk, which he basically repeated on the main stage the next day as the conference kicked off: Koch isn’t just a passive investor, it wants to standardize on Infor’s product line across the company. That includes using Infor’s HRMS for managing a workforce slated to grow to 200,000, dropping Infor asset management software into 300 of its manufacturing plants, deploying Infor’s GT Nexus global logistics network across the company, and dumping Oracle Financials in favor of Infor’s Cloudsuite Financials. And that’s just for starters.

What this does for Infor pretty much makes the $2 billion Koch spent for a 49 percent share of Infor the least significant part of the relationship. While the investment is nothing to sneeze at, the solid endorsement of Infor’s strategy by Koch’s senior management, and the promised scale of the Infor deployment at Koch, gives Infor something that Microsoft Dynamics can’t even begin to touch, and rivals like SAP always struggle to come up with: a respected, multi-industry global company that is deploying a broad set of Infor’s products and is willing and able to become a showcase for those deployments.

The willingness – at least so far – of Koch to get on stage with both analysts and customers is not to be discounted. Every vendor is struggling to find customers who are not only willing to be spokespeople for their vendors, but can also talk publicly about deploying a comprehensive set of products – that whole is greater than the sum of the parts story –  from their vendor. And that turns out to be incredibly hard and getting harder all the time.

To be fair, this is a problem that bedevils all enterprise software vendors today. It’s one thing to boast that there are currently 6300 S/4HANA customers, as SAP is now stating  to the market. It’s entirely another thing to have a critical mass of customers deploying and speaking out about how well those deployments are going. Same with Dynamics – though their cone of silence is as much about the internal lack of momentum I mentioned as it is about an industry-wide dearth of referenceable customers. Regardless, there’s no better or more necessary and essential proof point than finding customers who will stand up, take questions and provide real answers to the world.

Neither Phillips nor Feilmeier made any commitment to transparency and access as the Koch relationship unfolds, but it’s pretty clear the challenge is on the table. It would definitely be in Koch’s interests as an investor to play this role: the credibility they lend to Infor’s strategy and products will light up Infor’s sales calls all over the world, which of course will boost the value of Koch’s investment, which just makes good business sense, etc. etc.  As long as there aren’t too many problems executing these very ambitious plans, I can’t think of a reason why Koch wouldn’t want to play that role.

Meanwhile, back in Dynamics-land, the paint is a less fresh and the colors less bright. There are definitely some cool things happening: Microsoft has plans to use the LinkedIn acquisition as the strategic cornerstone of a talent management/HR play that could be a strong player in the market. (But you knew that.) There are continuing efforts to leverage the breadth of functionality in Azure as both IaaS play as well as a developer platform play: PowerApps, Flow, and associated tools, including an well-designed data store that can be used to support rapid, “citizen developer” apps development. (Maybe you haven’t heard that one yet.) And there’s plans to push forward with a re-org of sales and go-to-market in order to drive more innovative thinking into these engagements, with Microsoft’s internal consulting arm taking the lead. (Basically, what every other vendor is doing in the age of digital transformation.)

And…that’s all I can say. Or will say. Because I still don’t really know what’s going to happen to Dynamics: a 30 minute call doesn’t really begin to tell the story, whatever that story is supposed to be. To their credit, Microsoft quickly put their execs on the phone with me after my post came out, and that call genuinely gave me the impression that Dynamics is not “missing in action”, as my post claimed. But it’s clear Dynamics is still not sure how it wants its story told.  Or what that story is about, or how it positions Dynamics competitively in the market, or what Dynamics’ role inside Microsoft is slated to be in the next few years.

In several follow-up calls and emails after my micro-mini-briefing, Microsoft made it clear that they’re not just struggling with their messaging, but whether they really want to engage in the marketplace of ideas the way their competitors do. Their line of questioning said it all: Was I sure what was under NDA and what wasn’t? Would I submit my post for review? Could we discuss this again please? I spent more time interacting about what I was going to do with the relatively sparse information they shared than I spent on the phone with their execs in the first place. Really.

Contrast that with Infor: The follow-up from Infor after a day-long session, which included a fair amount of NDA info, was a simple “thanks for attending.” Trust, Infor understands, is part of the engagement model. The contrast is so deep that, while I could probably say some more non-NDA things about Microsoft’s plans for Dynamics, I’m going to pass. I think it’s best to leave the details of what Microsoft Dynamics is up to for a time when the company is a little more comfortable playing in the marketplace of ideas.

Infor poses no such challenge. In fact, the real challenge with Infor is to distill my 25 pages of notes from the analyst day into a short, coherent analysis. Should I focus on their cloud story – almost 8500 customers, 71 million users, significant momentum in cloud-based revenue and new customer wins? Or their emerging global SI partner story, with the likes of Capgemini, Deloitte, Accenture, and Grant Thornton showing by their mere presence in the Infor market that the big deal flow is definitely starting to happen? Or the continuing growth and maturity of their XI IaaS platform, now in use by 7000 customers? Or their growing IoT strategy, which seems tailor-made to show up in those 300 Koch plants as part of Koch’s asset management strategy?

How about their continuing focus on deep micro-vertical industry functionality – which was highlighted by an almost criminally dense set of slides showing dozens of capabilities per industry? Or the momentum behind their GT Nexus business network? (Though it has to be said that GT Nexus’ focus on blending financing with the business networks – a key part of the strategy when the acquisition was announced – isn’t getting much traction.)

Or should I talk about Infor’s Coleman AI/ML strategy and its well-considered focus on building industry specific solutions instead of going to market with a general purpose platform that, frankly, would just make them the latest entry in the race to the commodity bottom of the AI platform market?

I assume you get the point, and hopefully Microsoft does. But let me spell it out succinctly in case it’s not obvious: enterprise software in the cloud is a white-hot market opportunity, made even more white-hot by Oracle’s NetSuite acquisition, which both pissed off a lot of customers who don’t relish working with Oracle as well as galvanized companies like Infor, and SAP, to step up their enterprise-in-the-cloud game, particularly but not exclusively in the mid-market where Netsuite once thrived.

Infor clearly gets it: The nice thing about being a private equity company is that there’s more breathing room for strategies to mature, and this year’s Inforum was perfect example of what happens when a comprehensive cloud strategy finally comes into its own. Public companies like Microsoft are to be excused for succumbing to the quarterly cadence of Wall Street and focusing on the big wins to the detriment of the small. Grow like a cloud company, be profitable like an on-premise company:  It’s a diktat that Wall Street continues to enforce, to the detriment of everyone.

But that’s a lousy strategy in the long run for Microsoft if t means neglecting the long tail of innovation in favor of the fat quarterly profits that the rest of Microsoft’s cloud business is turning in. While there is no doubt that Microsoft Azure and Office 365 are amazingly successful, and getting more successful all the time, there’s more to the market than the kind of cloud platform and office productivity plays that Microsoft is largely focused on.

The battle for the future of enterprise software – which is both the ultimate proving ground for the cloud, and the ultimate delivery point for differentiated value – is being fought in the lines of business, not the IT shop, which looks at platforms and desktop productivity products as largely commodity technologies. Winning in enterprise software is a matter of also getting those LOBs to use a given vendor’s tools and technologies to transform their businesses – almost regardless of what platform or platforms have been chosen by IT. And working with the LOB means looking for the small wins, not necessarily the biggest and most Wall Street-friendly deals.

The IoT/ML/AI world is a perfect example of this: Every cogent analysis shows that most of the IoT/AI/ML market momentum is based on proofs-of-concept, not enterprise deals. But it’s those POCs that are destined to become the future enterprise-wide deployments every vendor is banking on, and those IoT/AI/ML pioneers – the “citizen developers” or visionary LOB managers – are the midwives of this strategy. Which means that, as the market matures, each of those enterprise-wide deployments will have an enormous ancillary sales impact, requiring more apps, more cloud, more analytics, more integration, more data, and more and more and more.

Infor gets this, which is why they have spent so much time planting seeds that they are just now beginning to harvest. One day, Phillips knows too well, they’ll have to transition from a company that lives off a fat maintenance revenue stream into one that lives off of a fat innovation-based revenue stream. The myriad bets Infor has made, whether it’s by acquiring GT Nexus, or focusing Coleman on product, not just platform, are clearly focused on that day coming sooner rather than later.

That’s because – back to the marketplace of ideas that Microsoft is so far eschewing – It’s pretty clear that the pioneers in LOB are going to go with what they know and what’s in front of them. And they’ll most likely stick with existing providers – assuming they have the innovative tools and products the LOB is looking for – as the LOB move its POCs up the food chain to become enterprise-wide deployments. And it’s these enterprise-wide deployments which in turn mean enterprise-class revenue streams for their vendors.

So if you’re a vendor who is absent when the market is doing advanced show and tell about the future of enterprise software and how your company can transform the enterprise, you’re not just missing out on the early adopters, you’re potentially missing out on the really big prizes as well.

Infor clearly gets it, and it will be fun to watch all this vision unfold inside the domains of Koch Industries and the other companies a name like Koch can attract. Get out the popcorn, this movie is going to get real interesting real soon.

Et tu, Microsoft?


Microsoft Dynamics Who? Microsoft Pioneers a New Category: MIA Software

Microsoft is emerging as a potent force in the enterprise software market, propelled by Azure and the success of Office 365. The former provides a comprehensive cloud platform and set of services that are, as a platform for enterprise software, second to none. The latter provides an amazing productivity platform and set of services that spans a broad swath of the day to day requirements of today’s business user. And, for what it does, is also second to none.

That’s the stuff Microsoft likes to shout from the rooftops, and deservedly so. What they’re strangely quiet about is the fact that they also have market leading ERP and CRM software products that are right up there with the best of the best. At a moment in the market when public cloud offerings for enterprise software are hot, and the original offerings from leaders like Netsuite and are looking a little long in the tooth, there’s a deafening silence around Microsoft’s Dynamics product line – the mellifluously named Dynamics 365 for Operations, Dynamics 365 for Sales, and the other Dynamics products that have a legitimate shot at market leadership.

The omission isn’t just curious, it’s also tragic. Microsoft’s inability to promote of a solid set of enterprise software is a disservice to its customers and a larger enterprise software market that only gets better by increasing the choices customers can make.

Why is Microsoft so quiet about what should be a major set of assets in the highly competitive and fast-growing cloud ERP market? There’s a clue to be had in the checkered history of Microsoft’s enterprise software aspirations, starting with the acquisition of Great Plains in 2001. Since that first acquisition, and the subsequent acquisitions of Navision and Axapta, Microsoft’s senior execs kept looking at the paltry revenue and margins that these products could command relative to Windows and Office and for a long time basically shunned what later became the Dynamics product line.

That benign neglect was severe enough that there were many times when Dynamics execs confided in me that they might be better off being spun out and run as an independent company or sold to a larger enterprise software vendor. This second-class status was the norm pretty much until Kirill Tatarinov was promoted in 2007 to run the show, whereupon Dynamics began to come into its own. Even through a couple of reorgs that threatened to repeat the past pattern of  neglect, Kirill was able to keep the Dynamics flag flying.

But Kirill left two years ago as part of another reorg that put Dynamics’ fate in the hands of EVP Scott Guthrie, and that’s basically when the silent treatment began.

I don’t blame Guthrie for what looks like that same old indifference, he clearly has other and more lucrative fish to fry, such as Azure and Office 365, the latter of which now has 100 million enterprise users (which begs the question of what very large percent of the global economy runs in part on the Office 365 family – I’m sure the answer would give Microsoft some serious bragging rights.).

More importantly, however, I’m not so sure Guthrie really gets enterprise software in all its complexity and glory. Or maybe he just doesn’t get why Dynamics is that important to Microsoft. Perhaps, just like in the olden days after the Great Plains acquisition, Guthrie’s indifference may be a rehash of an historical perception at Microsoft regarding Dynamics’ limited value to the company.

Regardless, any and all scenarios that marginalize Dynamics are basically a damn shame. And it’s a shame that Dynamics has been placed in the cone of silence – no more conferences, no more analyst events, no more regular briefings – and not just because I’m an admitted enterprise software bigot who likes a dynamic (pun intended) market full of great products pushing the envelope on behalf of customers. It’s a shame simply because I think Microsoft and Guthrie are shooting themselves in the foot in the middle of a very fast and competitive race for a key enterprise software platform prize.

The prize? Leadership in the next generation public ERP cloud, the one that puts classic backoffice ERP into the cloud, straps it to a comprehensive platform full of innovation services (as in the ubiquitous trio of IoT, AI and ML, as well as microservices, etc. etc.), and leads the global economy to the promised age of digital transformation. That one.

But instead of putting Dynamics into the sweepstakes, Microsoft keeps shooting Dynamics in the foot. The latest example of friendly fire came at the Microsoft Build developers conference last month. I’ve been writing a lot about how developer outreach is the new imperative for enterprise software vendors who want to play in the cloud platform business, and I went to Build to take the measure of Microsoft’s latest efforts in this regard. The basic issue is that platform providers need developers who reflexively use their tools, services, and platforms to build those cool new apps that will transform the business world. And historically, Microsoft has done this better than most: witness the fact that Build is one of the larger –if not the largest – pure developer conferences in the industry, and Microsoft’s legions of developers are the envy of the enterprise software market.

The focus at Build on what Microsoft touts as the “intelligent cloud” and the “intelligent edge” did a great job of solidifying what I see as a true leadership position in enterprise cloud platforms. This is particularly true with respect to Amazon and Google, but also more specifically with respect to companies like SAP and, which aspire to be cloud platforms but are basically leading with their apps, not their platforms.

As such, Build was a showcase for all the cool stuff you’d expect as well as a lot of cool stuff that you might not expect, such as what happens when Microsoft pairs the graph API from Office with its newly acquired LinkedIn APIs, or how well Cortana can do live simultaneous human language translation, or Hololens, which is truly in a category of coolness all by itself.

But while Microsoft did a great job of showing off these and other components of its developer toybox/toolkit, by the end of analyst briefing sessions the day before the official start of Build I realized that, at least when it came to talking to the analysts, Dynamics wasn’t part of the developer story. The irony of this is a little mind-boggling when you think that every enterprise software vendor other than Microsoft would give up a body part or two to be able to address the Build audience and show off what their enterprise products and toolkits could do when married to Microsoft Azure APIs, the Office/LinkedIn graph, Cortana’s natural language processing, Hololens, and pretty much everything else under the hood in Redmond.

In other words, while companies like SAP and can only dream of the day when they have a developer audience of the size and scope that Microsoft can command, Microsoft is squandering a huge opportunity to use its developer network to do with Dynamics what Salesforce and SAP wish they could do with their cloud enterprise software offerings.

Like I said, I’m not sure how well the cloud enterprise software opportunity is even understood at Microsoft. As an example, I asked Scott Guthrie during an analyst Q&A session what role he saw Azure and its Lifecycle Services ALM tool playing in a multi-platform, multi-cloud, multi-cloud app world. This wasn’t meant as a gotcha, it was actually more of a friendly lob: helping customers navigate cloud “sprawl” is a top of mind issue in enterprise software, and if you ask Amazon’s SAP team this question – which I did recently – they have a lot to say about their plans to support the integration and orchestration of different vendor apps across their cloud. After all, Amazon runs SAP and Salesforce and Workday and pretty much any vendor app that needs a public cloud provider.

Just imagine if you build a custom process that spanned two different cloud properties – a CRM and an ERP product, for instance – and your cloud provider managed the full lifecycle of the process, helped manage the integration and orchestration, and made sure that the process was immunized against the different upgrade schedules of the cloud properties. And that vendor had some great IoT APIs, and serious support for predictive modeling and data visualization. Wouldn’t that be nice?

Unfortunately, Guthrie’s answer came off like a punt that sailed out of bounds. The way he launched into something about running Linux VMs and Cloud Foundry on Azure made me wonder if I hadn’t articulated the question well enough. Maybe, or maybe not. To the right audience, the question wouldn’t be halfway out of my mouth before it was being finished for me: If I was in a room full of enterprise software customers of any decent size, or the enterprise software vendors themselves, this question would have been instantly recognized as the big question in the enterprise as the move to the cloud broadens and customers are forced to confront the extreme heterogeneity in their cloud portfolios.

(Ironically, or maybe not, Kirill Tartarinov, now the CEO of Citrix, and his exec team spent a great deal of time discussing this very issue at Citrix’s Synergy user conference last month. They made the most of the term “cloud sprawl”, and their solutions to the problem, centered around their Secure Digital Workspace and Software-Defined Perimeter, were spot on. The Synergy crowd ate it up.)

So where does this “deafening silence” leave Dynamics? Right now they’re deep in the damn shame category of technology marketing. I had the opportunity to meet with their CRM head, Jujhar Singh, at a CRM conference in April. In presentations to a small group of analysts, and then later at dinner, the message that Dynamics CRM had made some extraordinarily huge functional leaps came in loud and clear. The upshot of the 30 minutes we analysts had with Jujhar was that 30 minutes wasn’t enough time to be begin to touch on all the cool new stuff, and the consensus around the room was that the cone of silence was a huge lost opportunity for Dynamics.

This is true across the product line: at this point it’s becoming hard to recommend or even pass judgement on such a stealthy product line, and from where I stand this is keeping Dynamics out of a deal flow that by rights it should be deep in the mix of. Whether it’s a question of showing off the next gen enterprise software process flows that can be enabled by combining Dynamics, Office, Azure, and the rest of the stack, or simply competing head to head in the public cloud market against the likes of SAP, Oracle,, or Financial Force, Dynamics is increasingly showing its unfortunate leadership in special category of enterprise software that can best be described as MIA, for missing in action.

There was a time when Dynamics was recognized internally for its ability to be the staging ground for the rest of Microsoft’s technology: if you wanted to see what the full complement of Microsoft’s  desktop, cloud, infrastructure and systems software could do, all you had to do is find a decent-sized Dynamics ERP customer. It gave Dynamics a lot of internal cred, and that cred allowed Dynamics to have a seat at the Microsoft table as a legitimate division worthy of some mention.

Apparently that cred is gone, and with no senior exec actively advocating for Dynamics, a market leading product set is left to languish. There’s not a lot of precedent for success with this model of MIA marketing, and, for the sake of the customers and the Microsoft employees who still bleed for Dynamics, the company should get back on the road and start talking about Dynamics again. Or sell it before missing in action morphs into irrelevance or, worse, DOA. As in dead on arrival.

The Fog of Innovation Marketing: SAP Obscures S/4 HANA’s True Competitive Advantage

If you walked away from SAP’s recent SAPPHIRE event scratching your head about which version of S/4 HANA your company should deploy, you’re not alone. There seems to be a fair amount of confusion about the differences between S/4 HANA On-premise/Private Cloud and S/4 HANA Public Cloud. And  that confusion threatens to derail the growing momentum around the company’s flagship cloud products.

The problem is that SAP is trying to get S/4 HANA Cloud to punch above its weight class by claiming it can meet the needs of a large enterprise, and in the process the company is setting the stage for some serious customer confusion about which version of S/4 HANA is the right one for the job. The irony of these efforts is that in sowing this confusion SAP fails to see that the very thing they’re trying to hide by overselling S/4 HANA Cloud is the very thing that actually imbues the overall S/4 HANA product line with the exact attributes that customers need.

Unfortunately, SAP only has itself to blame for the confusion. The official messaging, to be perfectly honest, seems designed to obfuscate rather than enlighten. I had to go three rounds with SAP to get the story straight, and at times it felt like I was deposing a reluctant witness, rather than having a forthright conversation about what will always be a complicated decision for SAP’s customers.

Here’s the gist of the problem. SAP’s official storyline is that S/4 HANA Cloud is as well-suited to run a large, global enterprise as the on-premise and private cloud versions. This is due to the simple fact, SAP officially maintains, that the on-premise and private cloud  editions of S/4 HANA are built off the same code line as S/4 HANA Public Cloud, which means that a customer can chose either one for their upgrade or migration because they are functionally equivalent.

Those italicized words, however many times SAP executives repeat them – and they were repeated to me more than once  — won’t be true for quite a while, if ever. It’s kind of like saying that a Honda Fit is functionally equivalent to a Honda McClaren Formula 1 race car. Both have tires and engines and transmissions, etc., and both can transport you from here to there. But if you’re going compete on a Grand Prix track,  you might want to leave the Honda Fit at home. And if you’re trying to take your kids to the water park or need to hop to the grocery store for a gallon of milk, I’m pretty sure a carbon-fibre, 220 mph Formula 1 race car wouldn’t be the right choice.

Similarly, if you want to run a global company using a standardized set of business processes, S/4 HANA Cloud is your Honda Fit. But if you want to do something more – run an industry solution like Retail, or a fully-functional warehouse management system, or run the fully functional versions of GRC or GTS, for instance – you’re going to need that race car, and that means running S/4 HANA on-premise and either managing it yourself or having a service provider run it for you in a private cloud.

Notice the deliberate use of the words “fully functional.” Read this carefully: the public and private cloud editions are different, the scope of what they can offer is different, and there are very different deployment use cases depending on what your business goals are. The two products’ roadmaps promise a good deal of convergence in the coming years, and the similarities at some point may outweigh the differences. But it’s highly unlikely they will ever be functionally equivalent: the market demand for some industry solutions may never be big enough to move that part of the code line to the public cloud. We shall see.

What I’m baffled about is the thought that SAP thinks there’s something wrong with this kind of full disclosure. From where I sit this is a huge strategic advantage, particularly because of S/4 HANA’s secret weapon: code equivalence.  Both versions do spring from the same code line, which means that any of the “fit to standard” functionality that a customer deploys today in S/4 HANA Private Cloud can be moved, pretty much seamlessly, to S/4 HANA Public Cloud any time the customer wishes. Of course, the above bells and whistles like GRC or EWM – said facetiously: these are hugely important pieces of functionality for some of SAP’s biggest customers – might have to stay in private cloud mode. But, that’s what SAP Cloud Platform is for, right?

This ability to keep the strategically advantageous parts of the S/4 product line in a private cloud and  move the  rest of the company to a public cloud version while running a single code line is something one other company can do. Who? Well, it’s certainly not Oracle, which possesses one of the best examples of cloud code sprawl in the industry. And the rest of the major competitors are cloud-only companies, no private cloud options available.

Only Microsoft can do something similar, to the extent that the Azure Stack offering allows a company to run a complete version of Azure in a private cloud, meaning that its cloud ERP product, Dynamic 365 for Operations, can also run in said private cloud. But I’m not sure there would a business case for splitting a company into pure cloud and Azure Stack versions of Dynamics 365, certainly nothing similar to the mixed S/4 HANA scenario above.

A further advantage of the SAP approach is that a single code line means process equivalence. This means, for instance, that a new “fit to standard” business process in S/4 HANA, version whatever, could be stress-tested and perfected in one location – say in your offshore subsidiary – and then moved around to world to your other locations in a way that would vastly simplify the change management issues inherent in any new process change. Are these other entities running S/4 HANA on prem or in the cloud? Who cares? If it’s available as “fit to standard”, an identical configuration of the one you’ve created for one line of business can be deployed anywhere pretty much as-is.

In other words, SAP customers can separate the strategic decision to go with a migration or upgrade to the S/4 HANA family from the deployment question of cloud or on-premise, at least for a significant percent of their needs. Start with the real questions about managing the technical and business changes needed to thrive in the coming years, look carefully at what customizations need to move to the new platform, and then figure out what has to run where and how: Cloud vs on-premise, migration versus upgrade, cohabitation of ECC and S/4 HANA vs. HEC, etc. etc. If you’re like most large companies – and many smaller ones – you’re probably going to have to mix it up. Or maybe not. These are hard questions to answer, but they’re much easier to deal with once the more salient business and customization issues have been sorted out.

Ironically, underneath this functional equivalence stuff, SAP overall has pretty much has these goals in mind: Leading customers down a decision path that starts with “what do you want to accomplish” and leaving out the issues of which version can meet their functional needs until the time for such a decision is ripe. To help out, SAP has some pretty robust tools, such as S/4 HANA Readiness Check and the Transformation Navigator, both of which can help customers make careful choices dictated by their particular IT and business realities rather than blindly follow some overreaching marketeering that is clearly intended to push SAP’s cloud market status as much as possible, and to hell with the consequences.

If only SAP would stop pretending that all roads lead to S/4 HANA Cloud. SAP should instead embrace the strength and depth of its offerings and stop claiming that this diverse set of offerings is somehow functionally equivalent, before it gets into hot water with its customers. Pretty much every vendor/customer dispute can be boiled down a couple of simple problems, one of the most important of which is mismanaged expectations. Overselling, underdelivering, obfuscation, confusion – these are the paths to customer dissatisfaction and competitive disadvantage. In this case, this functional equivalence concept is made all the more useless by the fact that what SAP is trying to hide – a product line, based on a single code line, as diverse as the customers it’s trying to serve – just happens to be its biggest strength.

Just tell the truth, the whole truth, and nothing but the truth. It’s really that simple..

SAP Goes to SAPPHIRE 2017, part II

(We’re back, discoursing on the challenges SAP will face as platform proliferation and the shifting of the edge app issue into the hands of the LOB developer influences what vendor’s tools and platform will be used to power its customers’ digital transformations. Where we last left off, I was about to illustrate SAP’s dilemma with a true-to-life story.)


I recently had an experience that, in a nutshell, summarizes the gist of the SAP challenge. I was speaking with an LOB manager working at long-standing SAP customer with a field maintenance problem it needed to solve. The problem was a classic digital transformation story: transform how field maintenance is prioritized by trying to understand what the cost of having a particular asset offline for a particular period of time would actually be. If it turned out that there was no impact, maintenance could be delayed, saving a ton of unnecessary expense and resources. And if maintenance was needed online immediately, the decision to spend the extra time and effort in overtime or other costs could be well-justified.

This meant understanding everything about the asset as well as the demand side of the market in which the company operated. As you can imagine, in its ultimate form this is the ultimate edge app: take existing on-premise data about the asset (ERP data), add real-time operations data about the asset (IoT data), marry it to external market data (unstructured web data), get information about the availability of maintenance people (talent management data) and parts (warehouse management), and plug it into a model (based on AI/machine learning algorithms), and, voilà, you’ve digitally transformed asset maintenance.

Sounds like a Bill McDermott/Bernd Leukert/Rob Enslin dream come true. Except for one little sticking point: this customer isn’t building this on SAP’s platform, nor is it using SAP’s tools. There’s a small license to be paid for accessing SAP’s APIs (because who wants the audit police to show up and ruin everyone’s day), but that’s it. The customer went with another vendor’s dev tools, which meant using that vendor’s platform, and, when the time is right, that vendor’s ML and IoT interfaces.


This is why the elevation of Rob Enslin to the title of Mr. Cloud is so important. Rob’s new title is effectively an asset maintenance transformation at the executive level in its own right. The new role is an acknowledgement that SAP’s manifold assets may be in wide use across many medium and large-size enterprises, such as the one I just mentioned, but that doesn’t mean they’re ubiquitous or even well-known by the SAP crowd. In too many cases the SAP ‘crowd’ consists of the SAP ERP people at the company – full stop – while the customers using SAP’s non-ERP assets don’t think of themselves as SAP customers, a position encouraged by other non-SAP user constituencies who still think that SAP is synonymous with “poured in concrete.”  Rob’s job #1 will be to convert the SuccessFactors, Ariba, Concur, Fieldglass customer base into seeing themselves as SAP influencers, and help convert the non-SAP non-believers to the one true religion.

If he doesn’t, then there will be more and more cases where individuals like the one above, with no particular connection to SAP and a connection to another platform vendor, opts to choose something other than SAP for the next digital transformation project: The more disconnected a user is from SAP the more likely that user is to not opt for SAP technology when the time comes to step up to something transformative.

Among Enslin’s many challenges is to undo this disassociation and build SAP brand loyalty inside these non-ERP and non-SAP assets. And then use that loyalty as the jumping off point for making sure SAP has a seat at the table when digital transformation projects get the green light from LOB management. This won’t necessarily be easy. There’s a lot of incumbency in the non-SAP world too, and SAP’s competitors – and Microsoft in particular – are doing a good job on maintaining their respective cozy positions with their respective line of business users. And I was reminded at the recent SuccessFactors analyst summit that, for many non-SAP ERP users, the SAP brand is seen as anathema: it’s not just that the positives as too low, it’s that the negatives are also too high.

This is why’s Trailhead and Microsoft’s PowerApps are so dangerous for SAP. If the LOB is looking to build a transformative app, Trailhead and PowerApps provides a way to at least get started. And, considering how well both companies are doing marketing these tools, getting a similar reflex motion towards SAP and Build will be problematic.

Which of course is where Bernd Leukert and newly appointed CTO Bjoern Goerke come in. SAP has to not just build great platforms and middleware and apps, it also has to offer great development experiences that are both accessible and known to be accessible. The emphasis on known to be is essential: SAP has been pretty stealthy making its developer outreach programs as well-known to the market as those of and Microsoft. Build’s market awareness is pretty low too – ask most developers what build is and they will tell you it’s Microsoft’s developer conference, currently taking place in Seattle.

In contrast to the massive Microsoft Build event, and must-have, oversold, three day orgy of Microsoft tech products and direction, to date SAP’s developer efforts have been pretty stealthy. I was surprised to find out recently that SAP ran 140 developer events last year, and that one third of the attendance at those events was by developers new to the SAP ecosystem. In fact, to its credit, SAP’s approach has been quite global. But they seem to have missed a few important places where they might be better seen, such as Silicon Valley.

I mention this not because I believe that Silicon Valley is the center of the tech universe, which it isn’t, but because of its perception as the center of the tech universe. While SAP’s rest-of-world efforts are laudable, the PR value of being in the Valley as a means to capture developer mindshare is significant: capturing developer and VC mindshare is essential to being a platform player in search of an army of developers and ISV partners, and the Valley is a key place to go hunting for that mindshare. So job number one, IMO, is to be much more public and visible in the competitive landscape with what developers can do with SAP.

(To its credit, SAP has been touting is new relationship with Apple, and I’ve heard more than one SAP exec talk glowingly about unleashing an army of IoS developers to develop on the SAP Cloud Platform and Fiori. If only such an army existed. I think a regiment might be a better characterization – I think it’s safe to say the percent of IoS developers capable of building enterprise apps is directly proportional to the number of enterprise-class apps in the Apple Store. But early indications are that there is a critical mass of IoS developers building mission critical apps.)

SAP also has to be more out in front of the commerce side of being a platform vendor, and that means more presence for its digital store assets, such SAP’s Digital Store, its AppSource store (which is a showcase store, not a place to actually buy apps the way the Digital Store is) , and, unfortunately, the other stores that constitute platforms for selling partner wares to the SAP ecosytem. A digital store experience is an essential part of the overall transformation of SAP: if SAP is going to be a platform vendor, and attract waves of developers and internal LOB users, and make its mark as the go-to company for digital transformation, then it needs a place to market partners’ assets that is easy for partners to tap into and is intended for a more public commercial audience.

This is a key capability that could help SAP capture LOB users might otherwise go elsewhere. If they find what they’re looking for – or close to it –  in an SAP store they may not be tempted to go running off building new edge apps with other vendors’ tools. Likewise, newly recruited IoS developers will find a familiar commercial outlet for their creativity. In other words, SAP would begin to be seen as a big-tent vendor with broad appeal and not just another ERP vendor gone cloud.

All of which brings us back to the story of the SAP customer who digitally transformed without SAP. Each of these touchpoints – better synergy between SAP assets, better identification with SAP outside the traditional SAP ERP customer base, better developer experiences, more reflexive moves to Build and Cloud Platform – needs to be shored up in order to stop the bleeding of edge apps development from SAP to the competition.

This is what I’m looking for at SAPPHIRE this year, much more than more demos of IoT proofs of concept and machine learning whiz-bang predictive analytics apps. Don’t just show me that you can build great next-gen edge apps, show me why building them with SAP’s platform, dev tools, and Cloud Platform APIs makes them better. Because without the uniqueness of SAP’s advantages leading the message, SAP’s ability to capture the attention of that next non-SAP LOB manager with an IoT or ML problem to solve will continue to… what’s the technical term? Suck.

Messrs. McDermott, Leukert and Enslin have an enormous pallet of assets to assemble into a coherent message worthy of SAP’s total value to its customers. The challenge reminds me of William Gibson’s famous admonition: The future is already here, it’s just unevenly distributed. SAP’s future is already here, but the understanding and use of that future isn’t well-enough distributed, both inside and outside SAP.

The time for that to change is now.

SAP Goes to SAPPHIRE 2017, part I

Part of the fun and challenge of following SAP is that its present and future are defined by the intersection of its own peculiarities and the peculiarities of the markets it lives in. This interplay means that SAP, like many large software companies, isn’t just a single company with a single overarching strategy: it’s really many companies with many strategies. The trick for SAP is to make sure they overlap more than they contradict each other.

SAP is kicking off SAPPHIRE next week – its annual May user conference held in conjunction with the ASUG user group’s Annual Conference – with an interesting mix of overlap and contradictions at play. It’s a cloud company that has to play to an on-premise user base and a platform company that is striving to be relevant in an increasingly crowded platform market. It’s the guardian of a 30-year legacy of industry-specific business process leadership trying to understand what these processes look like in the context of digital transformation at the edge of the enterprise. And it’s a leading-edge technology company looking to differentiate what being on the leading edge with SAP really means.

SAP is hardly alone in this regard, and not just because its competitors from the legacy days are facing a pretty identical set of challenges. This is also because its customers – ASUG members and non-members alike – are struggling with a reverse image of the same set of problems. There are some big issues on the table for customers surrounding digital transformation and all that entails (which sometimes seems as though it comprises everything and anything new and different.) And if digital transformation is the answer du jour, then the question boils down to understanding where the technology to enable a company to digitally transform –platform, development environment, interfaces to data from all over the universe, APIs for IoT, ML, AI, and the like — will come from.

Here’s the trick for SAP (and the rest of the market): If SAP’s customers, and its prospects, can be enticed to respond with “SAP” every time a tech decision involving some aspect of anything remotely smelling like digital transformation takes place, all will be right with the world and SAP’s stock price. If those reflexes are tuned to respond with some other vendor’s products, there’s going to be trouble.

To refine this dilemma more clearly: digital transformation for an existing company requires two phases, transition and then transformation. Transition involves the necessary upgrade to go from 20th century on-premise (and UX challenged) IT systems to 21st century, largely cloud-based systems. Transition, particularly to the cloud, is what started big time in 2016 as issues like security and privacy drove companies large and small to embrace the cloud and the vendor-managed security that it provides. It’s sort of Y2K all over again: While Y2K was bogus, digital transformation is or will soon be very real, and the effect is similar in terms of the ensuing market-wide upgrade.

Transition to the cloud presents a problem, however, when it comes to setting the stage for fulfilling those vague digital transformation mandates: cloud means “fit to standard”, which means no more customization, which means that if technology is put to use providing unique competitive advantage – which is what the transformation phase is about –  it’s going to have to be built on the “edges” of the newly transitioned cloud back office.

Transition, however widespread it is, has become problematic for incumbent vendors, SAP among many others. The reason is that SAP has enough customers running older versions of SAP ERP with enough customizations that, for some, their transitions are no longer upgrades, they’re full-blown implementations. That’s problematic for incumbents: if a company has to effectively reimplement to transition, then maybe it’s worth looking into changing back office vendors the way Seibel CRM customers jumped ship when CRM went to the cloud with So much for incumbency.

But, leaving aside the panic-inducing thought that all this talk about digital transformation is forcing customers to think about changing vendors, the even bigger issue comes when a company is done transitioning, or at least setting it in motion, and wants to start the actual digital transformation process. Because, as if things weren’t complicated enough, when a company starts to move to transform and build those killer edge apps that strategically differentiate the company, SAP’s path to glory starts getting muddier.

Mudpuddle number one is that SAP has never been the exclusive enterprise provider for the majority of its customers, and all those other non-SAP enterprise systems are in a forced transition too. This means that any given SAP customer of any size and longevity is also transitioning the non-SAP parts of the company to other cloud  products, each replete with a platform, dev environment, and interfaces to all the cool ML/AI/IoT stuff that transformation is supposed to be all about. Result: platform proliferation.

Mudpuddle number two: In addition to platforms for non-SAP software, SAP now runs or will soon run on four non-SAP platforms, Amazon’s AWS, Microsoft’s Azure, Google’s Google Cloud, and IBM’s Softlayer (Softlayer? Sounds like a fancy mattress cover to me. Considering how it stacks up against the others, it might as well be.)  This means that each of these cloud vendors’ non-SAP “stuff” is available to the SAP crowd, and a good part of that “stuff” is the “stuff” SAP expects its customers to use to build those edge apps. Result: platform conflict in the cloud.

Mudpuddle number three is that the core ingredients for creating and staging the next generation of software, be it “packaged” or custom developed, are becoming commodities before the market opportunity has even begun to move from POC to massive enterprise-wide investments. IoT is the best example of this: GE started down the IoT road with Predix in 2013, basically trying to boil an ocean that had no water in it. Now that there’s a trickle of IoT projects seeing the light of day, IoT as a platform has become a commodity such that at this point in 2017, IoT is a checklist item on comparison tools like the Rightscale one in the link above. Result: questions about the revenue stream from edge-enabling technologies abound.

Final, deepest, and messiest mudpuddle: the emerging influence of the line of business developer. While each vendor has their particular advantages, and SAP is chock full of them, all this cloud/platform/dev tools/API stuff has changed an important dynamic, to the detriment of traditional incumbent vendors like SAP. At a crucial moment in the market when edge app development efforts are small, largely tactical undertakings, as opposed to large, enterprise-wide undertaking that readily translate into big sales, the line of business manager or developer now has the decision-making power and the tools to take the lead on these edge projects. Most of the competing platforms have heavily promoted so-called “citizen developer” tools – SAP has its own, called Build – and while I firmly believe that the citizen developer market is somewhat mythological, these tools give LOB managers much more freedom in terms of how they develop apps and how much IT resources need to be commandeered to do so.

Needless to say, having the LOB in charge isn’t necessarily good for incumbent “legacy” vendors – the LOB folks lack the brand loyalty that IT has cherished in regard to its incumbent ERP systems – even if those vendors are successfully transitioning older back-office systems to their new cloud+platform offerings.

For SAP, this confluence of non-SAP app upgrades and platforms, the commoditization of “edge” technology, and rise of the LOB developer is threatening to rain on the quarterly successes that SAP has been reporting to Wall Street and its partner ecosystem.

And therein lies a tale.

Which, because this post is already too long, will be continued shortly.

SAP’s S/4 HANA: Looking Good, Trying to Look Better

SAP’s S/4 HANA has been called many things, but to characterize it as the future of SAP is far from hyperbole. SAP has minced no words in affirming that the path from R/2 to R/3 to ECC eventually leads to S/4 HANA. The question is not an “if”, but a “when.”

When, however, has been the tricky question  – when will the customers sign on in droves, when will SAP put in the critical mass of the functionality customers need in S/4 in order for the transition to make sense, and when will S/4 become a significant revenue-maker for SAP? Considering the literally billions of dollars at stake on the SAP and customer side, predicting the answer to when has become the SAP watcher’s equivalent of finding the northwest passage or the Higgs Boson. It’s a complicated question to answer, and precisely because of both its difficulty and value, it’s the number one question looming over SAP and its ecosystem today.

Which is why the recent release by ASUG, the SAP user group, of a comprehensive survey of customers’ attitudes and intentions towards S/4 HANA falls at an extremely propitious moment. That release was made all the more propitious by a peak I was given into SAP’s plans to clean up a major problem that has bedeviled customers’ efforts to plan their S/4 projects: The lack of a clear, well-defined and easily accessible path, based on the current and future state of a company’s SAP landscape, that will lead customers to the S/4 HANA promised land.  Based on the briefing I received, SAP has some interesting plans to fix that problem, and those plans could potentially make the next ASUG survey results look very different indeed.

The good news from the ASUG survey is that, at least in North America, SAP customers’ current uptake and intention to buy S/4 HANA is actually higher than many of us, including myself, though it to be. According to ASUG’s data, 61 percent of the customer base will have purchased S/4 HANA by next year, with 40 percent already on board or expected to have been on board by the end of 2016. Only 19 percent said that they are categorically not planning to purchase S/4 HANA, with 20 percent coming under the “don’t know/not sure” rubric.

These numbers are tempered by the problem that has bedeviled SAP’s intentions for S/4 HANA since it was first offered to the market – there’s a big difference between “bought” and “deployed”. Only 8 percent said they were currently live, with another 15 percent in the process of implementing. This has been the story all along – SAP did a good job, maybe too good a job, of selling the first licenses of S/4 HANA. But all too many of those licenses weren’t immediately put to use: for many the S/4 HANA license was used as leverage to get a better deal on other functionality that the customer was more eager to implement, and that meant the S/4 license sat on the shelf.

Assuming there’s a license that’s going to be used, implementing what is the next big question: SAP needs its customers to not just go live, but to go live with as much functionality as possible, or least with as much of the software they actually licensed as possible. The ASUG data shed some light on this question as well: 34 percent are primarily implementing finance, while 26 percent said they were planning to implement the full suite. Other deployments options including supply chain, manufacturing, and HR. Another 26 percent said they didn’t know.

The numbers in the “don’t know” category are important to consider when looking at how SAP plans to help customers discern the correct path to S/4 HANA. With 20 percent of customers not knowing whether they will deploy S/4 HANA, 26 percent not knowing what part of S/4 HANA they plan to deploy, and 33 percent not knowing if they will deploy on-premise or in the cloud – the uncertainty factor looms large in the overall issue of when S/4 HANA crosses that proverbial river to the promised land.

Of course, ASUG asked about the obstacles to S/4 HANA adoption, and their data confirmed what many of us have been saying for a while: S/4 HANA lacks a clear roadmap (15%), details about versions and functionality are lacking (12%), it’s unclear how to get from an existing ECC system to S/4 (13%), and it’s unclear how S/4 can benefit a given company (18%).

Which makes the initiative SAP plans to roll out later this year to help customers figure out the path to S/4 all the more significant, and well-timed considering the ASUG report. The initiative, called the SAP Transformation Navigator, is intended to provide customers with a self-service online tool that lets them define the current state of their ECC 6 implementation and receive recommendations on what the ideal S/4 HANA implementation should look like. The goal is to give a solution architect a starting point for planning the “transformation” based on a qualified assessment of how to get to the optimal S/4 promised land.

Based on the demo I was shown, there’s a lot going on in this tool to address the obstacles that the ASUG data highlights: after entering the current state of their ECC 6.0 system, customers will be able to see what S/4 HANA alone can cover for them as well as what modules such as Ariba or hybris might do for them. Each proposed new module has a pop-up that defines integration scenarios, a roadmap, other information on functionality and how S/4 HANA can benefit a particular company via information from the module’s “value map.”

On paper – or, more precisely, on PowerPoint – the Transformation Navigator takes a swipe at pretty much every potential obstacle to S/4 adoption in the ASUG survey. Roadmap? Check. Version details? Check. How to get there from here? Check. Benefits? Check. If I didn’t know better (but I do) I would say that SAP took the survey results and then created the tool – no matter that the survey just came out last week and the Transformation Navigator has been in the works for months. Credit ASUG for holding up the mirror, and credit SAP for taking a deep long look.

What the confluence of the ASUG data and the functionality promised by the Transformation Navigator gives the SAP ecosystem is important. On the one hand, the ASUG data show that SAP’s existing customers aren’t opposed to S/4 HANA, but it’s clear they could use a lot more help in making the case for why they need to move from ECC and how to do it. That need more than justifies the development of the Transformation Navigator, and, if it lives up to its billing, it’s going to be a welcome tool in the customer’s decision-making processes. On the other hand, ASUG has now thrown down the gauntlet to SAP, setting a baseline for the problems and prospects regarding S/4 HANA that everyone will be able to use to judge the relative effectiveness of the Transformation Navigator and SAP’s other S/4 HANA efforts.

If SAP hasn’t moved the needle in the next ASUG survey, we’ll know that at least one of two things happened: Either the Transformation Navigator wasn’t up to the job, or SAP failed to fill out S/4 HANA’s functionality enough to align it with customer requirements, or some combination of both. Neither would be a happy moment for SAP. Importantly, Transformation Navigator won’t be enough if SAP can’t meet expectations and eventually flesh out S/4 HANA enough to become the replacement for ECC that it one day must become.

Other things could still go wrong for SAP’s plans: buying S/4 means replacing everything (SAP and non-SAP) with S/4 for 55 percent of the customers, according to ASUG’s data.  But only half that many have implemented or will soon implement any S/4 HANA at all, and most of those have just done finance. In other words, the intention is clearly in favor of a broad application of S/4, but it’s a future intention, not a present commitment.

This is one area I’ll be watching closely – if these customers start to fall off the wagon, the repercussions could be serious. The 45 percent that aren’t going full-bore S/4 are planning to do a mix of two-tier and “partial” migrations, both pragmatic strategies that on the one hand make a lot of sense but on the other hand mean that S/4 HANA is not as important or strategic as SAP would like. The ASUG data still show that SAP and S/4 HANA are still clearly important overall, and we don’t know from the ASUG report whether the 11 percent who responded “other” to the implementation/migration question are looking at non-SAP solutions, particularly for tier-two implementations. But if the “other” category grows in size as more customers go from planning implementations to realizing them, or the 55 percent who are going all S/4 start to waiver, SAP’s plans for S/4 HANA will be endangered.

Which highlights the importance of the ASUG report and SAP’s Transformation Navigator. ASUG has an important role in bringing to voice the kinds of problems that SAP hopes to mitigate with Transformation Navigator, and how well Transformation Navigator does in meeting those needs will tell the world a lot about how S/4 HANA is aligning with customer needs. That alignment will improve in time when the Navigator adds non-SAP software to its “before” picture: considering how predominant non-SAP software is in the SAP customer base, showing what S/4 can do to replace and, maybe, improve on the functionality of a heterogeneous environment will be a further boost to SAP’s plans, and provide more fodder for ASUG’s surveys as well.

2017 is turning out to be one of those pivotal years when SAP has to consolidate a lot of new products and technology, along with a logjam of acquired products, and show its customers how the sum of the parts is greater than the whole. Transformation Navigator is just one piece of the puzzle, there’s much more work to be done. But if all SAP did in 2017 was solidify the S/4 HANA story and route to adoption for its customers, and they responded with their dollars and euros, it would be a watershed year.

According to ASUG’s data, the die is cast. What’s on the other side – as S/4 HANA matures and Transformation Navigator starts to do its job – we can only guess.

Until the next ASUG survey comes out.