At Sapphire Now 2017, SAP presented its new platform, Leonardo, positioned as the building blocks for customers to design/consume apps with AI, IoT, and other capabilities (e.g. blockchain). I've jokingly referred to Leonardo as the "SAP's next-gen kitchen sink," which reflects my lack of clarity on how the different pieces fit together. SAP calls Leonardo a "digital innovation system," which they probably prefer to my quip.
But SAP isn't joking about Leonardo; this is their chance to be an essential digital partner to their customers. I heard some lofty statements from SAP execs about what Leonardo could become (bigger than S/4HANA or ERP).
Time will tell, but one overlooked piece of the Leonardo puzzle is the design capabilities. At Sapphire Now, we heard about design in the context of SAP's Build solution, which enables rapid prototyping (SAP describes Build as a cloud-based, open source tool that "enables users with no UI development knowledge to create fully interactive prototypes").
SAP Leonardo is inseparable from design services
At the Enterprise UX 2017 show in San Francisco, I got details on something that wasn't totally clear to me at Sapphire Now: design services are integrally linked with how Leonardo projects will be implemented. That presents a fresh challenge to SAP: scaling those design services.
During a podcast session with SAP's Chief Design Officer Sam Yen (SAP UX from the inside out - embedded below), Yen fleshed out how design and Leonardo connect, with back story on how Hasso Plattner elevated design thinking within SAP. I've already looked at how design is becoming a force for change (Can we get beyond incremental innovation with design?), which brings us to now.
So when SAP says "Leonardo," what do they actually mean? Yen:
SAP has always been known as an enterprise software company. Especially over the last couple years, we've been talking a lot about technology to improve enterprise software: things like advanced analytics and predictive, big data, in-memory, machine learning, and of course, IoT. We're certainly bringing those technologies to improve our existing software, but for the first time, we've actually created a brand where we take all those innovation technologies and put it together, and that's what Leonardo represents. As Hasso said in his keynote, it's a toolbox.
I don't know if Yen loved my "next-gen kitchen sink" moniker, but he went along with Leonardo as "an umbrella for a lot of cool stuff." But there's another big difference between Leonardo and the enterprise projects of the past:
You could think of the enterprise applications as somewhat off the shelf. I realize you have to configure and implement, but Leonardo is much more of a do-it-yourself type of model. Here's a bunch of technologies - and you can imagine your digital future with all these technologies.
But "imagining" is hardly enough. And that's where design comes in. SAP wants to use design to help customers move forward, partnering with them in new ways:
We don't want to just give you a bunch of technology for technology's sake. What we want to do is we want to co-invent; imagine the future with you together, and use what we've been talking about, design thinking, as the methodology to help discover the digital future together with customers.
A closer look at the Leonardo project method
SAP is taking its own internal design methodology, open sourcing it, and exposing it to customers:
We want to engage in the design thinking methodology Build as a great tool to be able to do that because, again, we've captured a lot of the artifacts and the processes that we use internally. Build is a tool that we use internally to develop our software now. And we use that as not only the methodology, but the framework in which we engage with you.
These projects have a three step process:
We would bring customers together on a one day workshop to try to identify what do they want to do. Not necessarily from a technology perspective, but from a business and a digital transformation perspective.
A key goal: emerge with short-term actions.
We try, in that explore workshop, to scope it down into some short term deliverables where we could add value in a short amount of time.
The next phase: "discover, design, and prototype." Within a couple of weeks, the scoped-down scenario goes through a design thinking process with Build:
We're actually creating interactive prototypes, getting feedback from the end users using the Build tool. By the end of that second phase, we've come up with an interactive prototype in Build.
The third phase: delivery, as in rapid.
Again, this is a process we want to do very, very rapidly. On the order of a couple weeks. we [want to be] able to come up with a fully functional solution on an SAP landscape.
Hold up. If SAP's design method will be at the core of Leonardo projects, doesn't that present a serious challenge of scale to Yen's team?
Yeah, absolutely. The old model is we have a bill of materials, or we have a list of products that we sell and the sales people would engage and say, "This is what we could sell to you." What's different now is we need to understand what is your business need, and what does your digital future look like? We have go through that exploration and discovery, the prototyping and that stuff, and then we then kind of sell the services and products and technologies to the customer.
When Yen first took on SAP's UI overhaul, I described his job as a "hot potato." Well, he's got another hot one to juggle now:
In terms of a go-to-market and an engagement model, it's something where we dramatically need to scale the design competency within our organization as well.
Leonardo is hardly the only challenge on Sam Yen's plate. Though SAP's UX overhaul has made significant progress - there are no infamous SAP GUI screens in S/4HANA Cloud - Hasso Plattner's May keynote included a bit of a rant on what to do about SAP's countless legacy screens. With the push towards voice UIs and "no UIs," Yen's team has new tech to aid in the rethink of screens and processes.
That's really what Fiori and Personas together represent, which puts SAP in the odd position of winning design awards for Fiori on the one hand, and still receiving blistering UI critiques on the other. Critics will persist, but Yen's team has quietly built up a track record of customer design engagements.
I'm always concerned when a company puts "design thinking" at the center of its plans. I'm a believer in design methods - though SAP doesn't have as much of an exclusive on these concepts as it sometimes implies with its use of ridiculous phrases like "advanced design thinking methodologies" - phrases which actually distance SAP from the practical concerns of its customers.
My issue is that design thinking is too often used to rubber stamp faux-inclusive processes that fail to take into account external and dissenting views essential to the outcome.
Yen is well aware of these shortcomings; he's a big advocate for diversity in design. Yen realizes the enormous change this collaborative model is to SAP's "always be closing" sales culture. That change was coming either way. Leonardo should pose a big test as SAP attempts to juggle quarterly numbers with forward-thinking projects. I believe SAP may have to take such partnerships further, into "skin in the game" project models.
At Sapphire Now, I got the impression SAP executives were thinking long and hard about what these kinds of partnerships mean, with plenty of new options on the table, including shared risk/investment and other forms of co-innovation. I don't know about you, but I find the potential of such models far more exciting than blockchain or AI tech in the abstract.
I'm not ready to offer a verdict on Leonardo as a whole, except to say I view it as more aspirational than ready-to-scale - with the exception of some pre-existing IoT initiatives SAP has been offering for a while, such as predictive maintenance. One area where SAP should surprise detractors is in the open source/platform aspects. There is no way SAP can assemble a next-gen tech stack by itself. SAP's deeper efforts with open source and integrations/service enablement via the SAP Cloud Platform (and Cloud Foundry) will be a story to watch.
The podcast gets into SAP's UX plans and Yen's recommendations to ERP pros who need to get further into design thinking (start now!). Yen also told me how Hasso Plattner got design religion, which led to his role in the Hasso Plattner Institute of Design at Stanford.
As Yen tells it, Plattner's light bulb moment brought him back to the earliest days of SAP, coding ERP alongside customers, on customer sites. The heart of what we call design thinking isn't fancy methods, it's elbow grease: working openly with those who will be most affected. Now we get to see if SAP can live up to its own ethos.
SAP UX from the inside out, podcast embed:
End note: for more on Sam Yen's views, check his Enterprise UX 2017 presentation, Driving Organizational Change Through Design? Do more of this and less of that. Thanks to Tobias Haug, Head of Design & Co-Innovation Center, EMEA at SAP, for informal talks at Enterprise UX that provided me with a better grasp.