I recently wrote about the failed Avon software project that saw the international home and beauty products vendor scrap the international rollout of its new order system after end users balked at just how difficult the product was to use. While SAP took much of the blame for the problem in the media, there were multiple parties involved in the project and hence it should be seen as an “enterprise software failure” rather than a “SAP failure” per se. That said, there are certainly some interesting learnings from the project which in essence failed to connect user expectations, technical affinity and technology systems themselves. Fundamentally the project seems to be an example of shoehorning people into a technology solution rather than building the technology solution in a way that works for the users.
After that post I was contacted by SAP’s corporate affairs people inviting me to speak with Sam Yen, the global head of design and user experience at SAP. While he couldn’t comment on the Avon situation directly, our discussion looked at user experience and user interface generally. Yen hasn’t got the easiest of jobs, his key deliverable is to ensure that the vendor, and the multitude of existing and new products it has in the marketplace, are designed in such a way as to meet end-users needs. This is a monstrous task – one statistic that shows this is that SAP has over 300,000 individual user interface screens, most of which were designed 15 or 20 years ago when thoughts around integration, data flows and user experience (not to mention cross-device access) were very different from what they are now.
The two main tools that SAP has to move UI into a more modern paradigm are SAP Fiori and SAP Screen Personas. A quick intro to these two tools first
- Fiori takes the most heavily used SAP user transaction screens and, in response to the fact that they were created with a plethora of different software tools, delivers them up on a consistent code base that is supported across all browsers via HTML5. Fiori isn’t about delivering on every possible use-case, it’s about refreshing the most heavily used SAP transaction screens – the 25 Fiori Apps are estimated to touch 30%-35% of the most commonly used transactions within SA and, by extension, impact upon 80% of users within a typical large SAP site
- SAP Screen Personas on the other hand is more about deconstruction of input screens and hence is more of a tool to deliver the “long tail” of less core screens. Over many years SAP has introduced more and more fields to input screens to the point where many users have to wade through many fields that are irrelevant to them. Personas makes it possible to created personalized screens for particular roles – it’s not about adding new data fields, but rather about making data entry faster through screen simplification
That’s all good stuff, both tools do a good job of modernizing some existing assets – it’s an entirely logical approach that avoids a “rip and replace” project just to get people using intuitive product. But, and here’s where it gets a little thorny, now we come to pricing. Both products are charged for, indeed Fiori costs $150 per user – not much for a core application within a large enterprise, but plenty if the application is only touched intermittently by an employee (which is kind of a situation where simplified UIs come into their own).
This fact has been the cause for much debate of late. SAPs perspective (not unsurprisingly) is that these tools deliver significant value to customers and hence can justify a fee. This is a perspective that (somewhat surprisingly) a small handful of independent commentators have agreed with, this in contrast to the vast majority of people who believe there are multiple reasons why they should be free. A recent article explained some of these reasons:
- The products help SAP defend attrition to more modern (and user friendly) products like Workday
- Customers fundamentally don’t want to pay for a UI refresh (especially not when you consider they pay rich maintenance contracts anyway)
- A flat fee doesn’t reflect the actually use case (example, an employee simply performing an approvals process with Fiori still needs to pay the $150 fee)
It seems to me there is something of a continuum when it comes to this customization topic. On the one end you have simple screen adjustments – moving fields, changing layouts etc. At the other end lies what is essentially a customization – molding core functionality to work the way a user needs it to. In terms of the former, and given the current trend of vendors introducing new UIs regularly as part of the standard release cycle, it would seem to be difficult to justify charging for this level of change. Things are obviously different at the customization end of town where it more about making sure the application meets the functional requirements of the user. I’d suggest that Fiori and Personas exists at the lighter end of the spectrum and is hence difficult to justify as a paid product.
Yen believes this isn’t the case and suggests that by making the products “cheap” (cheap being, of course, a relative term that depends on the context) the barriers to using the product are low. I’m not convinced that’s a defensible position to take going forwards – the excitement caused by Workday’s latest UI refresh (rolled out to users, as a matter of course, for free) indicates that enterprise customers are more attuned to a nice UI and consider it a fundamental part of what they want from their software.
My pick is that SAP will back down on this one – both Fiori and Personas deliver real value and, while value should rightly be paid for, since the value is primarily about modernizing applications that, frankly, are a little tired, it’s probably something SAPP should just swallow and offer to all. Time will tell.