Customer Adoption of NWBC
During the recent SAP TechEd in Madrid, I participated in several sessions and discussions on the NetWeaver Business Client (NWBC). One of the most interesting discussions I had was during (and after J) an Q&A expert session with Peter Barker, Felix Hoefer and Claudia Binder from NWBC product management. The discussion was really focusing on the level of adoption of the NWBC at customer sites. With ‘level of adoption’, obviously was meant a (let’s be careful here) “somewhat disappointing” adoption of the NWBC as SAP’s new UI technology at customer sites. The question raised by SAP product management was basically ‘what is holding back customers to adopt this new UI technology?’ Here I would like to summarize some of the arguments that were put forward by several participants, including myself.
Let’s make clear that we are talking here about the perception of customers, so the arguments do not necessary have to be true, but they do describe how customers evaluate the product and are therefore key arguments for the (non)adoption of the NWBC.
Uncertainty on SAP’s UI strategy
The User Interface has never been SAP’s strongest offer, and customers have seen a lot of initiatives from SAP to improve the user experience. The past couple of years SAP has delivered a broad scale of UI Clients (GUI client, GUI WebClient, Portal, Business Explorer, …), UI Technologies and Tools supporting the development and maintenance of these different clients and technologies.
NetWeaver Business Client is put forward by SAP as a new User Interface but does not replace any of the existing alternatives (GUI, Portal), which confuses customers. Furthermore new initiatives are presented as the way forward including mobile applications, SAP UI5 (HTML5), free UI development based on integration through Gateway and during TechEd we even saw the Microsoft Silverlight based SAP Personas making its entrance. This confuses the customer even more on the direction SAP is taking with their UIs.
All these initiatives claim to be targeting another user group, with specific characteristics, but for partners and customers it seems more like different product teams are developing UI technologies in parallel whilst proper alignment of these initiatives is missing. No clear goal or overall strategy seems available that ties these different initiatives together. They have their own roadmaps, their own tools, their own technology and no clear joint target they are aiming at.
So, customers sit back and wait to see which client, technology and tools will prevail before making an investment.
Anyone who has been implementing NWBC (whether for evaluation, life or demo scenarios) will recognize the hardship it takes to get the ‘out-of-the-box’ NWBC content working. The implementations we went through show different areas of hardship, which are recognized widely by customers and partners alike.
- Role and profile maintenance: Presented as a new UI Client for improved user experience, implementation of the NWBC turns out to be a core User and Role (authorization) maintenance project (in combination with an implementation of required backend functionality). Based on the promise of re-usability of existing roles, the dismay of customers can be understood when the impact of an implementation goes way beyond that. Of course the existing roles can be used, but none of the perceived improvements (work centers, business context content) will then be available. Getting those improvements in place requires a much stronger effort from the user management and authorization teams.
- Content availability: The general availability of required content for implementing and developing the NWBC roles is perceived as (to say the least) problematic. Technical requirements for content availability are fulfilled at few customer sites and when they are met, the activation and configuration of all relevant business functions (sets), data sources, services and so on are sometimes difficult. This (combined with the limited and scattered documentation, see below) definitely limits the availability of sidepanel content, work centers and POWLs for usage in the customer scenarios.
- Documentation: A commonly noticed problem is that documentation on the implementation of NWBC roles and the related backend functionality is really scattered around multiple areas. For the basic configuration of the NWBC and related backend functionality the documentation is fine. The issues with regard to NWBC documentation are however related to the content required for a proper implementation. The information required for
- finding relevant POWLs and Chips,
- activation and configuration of backend functionality,
- identifying dependencies between POWLS, Chips and backend configurations
- required configurations to get Chips and POWLs up and running
is sometimes ‘somewhat hard to find’. To get the information required for the implementation of a single end-user scenario, you have to go on a journey through documentation of best practices, business functions (sets), implementation and upgrade guides, Chip catalogs, SAP Notes and so on. Just when you think you are almost there, a small sentence in the documentation will make you shiver: “Configure systems as described in the SAP Standard documentation for SAP ERP EHP6″. This will basically mean to go through another implementation effort in activation of business functions, struggling through implementation guides, finding relevant SAP notes and configuration the backend system.
Having to deal with several implementations and configurations when implementing the end-user scenarios for NWBC is understood since new backend functionality is required, for customers this is however a non-expected challenge when what they perceive as the introduction of a new UI client.
The available Rapid Deployment Solution for Sidepanel content in SAP NetWeaver Business Client v2.0 should address several of these needs. Our experience (which I will write about in another blog) is that after implementation of this RDS there is still a lot of work to be done for customers (or partners) to incorporate the NWDS roles and profiles in the existing user management and to configure the backend systems properly.
Although customers are usually impressed by the looks of NWBC and see real added value in the workcenters and business context related content in the sidepanels, they struggle in making the business case.
- How does NWBC fit into their current UI landscape which usually includes SAP GUI and Portal implementations?
- What features are offered by NWBC that cannot be achieved with existing, available technologies and tools?
- What clients, technologies or maintenance activities are being replaced with the new product?
- Will NWBC offer end users simplified access to their activities and tasks?
These are very valid questions which are heard often when showcasing NWBC to customers and usually the answers are somewhat disappointing.
Added value is perceived mainly from the workcenters, the sidepanel (business context content) and the look and feel. The (implementation) effort and (technical) requirements for the realization of this added value are however high and usually one step too far for the customer.
SAP is really missing the spot in marketing the NWBC. It promises a lot that cannot be achieved easily and shows ‘out-of-the-box’ content that is hardly representative for the customer’s needs or environment. Furthermore SAP fails to mention the effort and impact the implementation of NWBC will have on the User and Authorisation Management within the customer’s environment. This leaves the customer with high expectations and wrong presumptions on what NWBC can do for them. Expectations encountered at customers regarding NWBC are:
- NWBC will replace the SAP GUI (since we don’t see the SAP GUI in the demo)
- NWBC can be implemented as thin client (yes, but not when we want to provide any added value such as sidepanel content)
- NWBC will allow me to simplify the UIs used (no, although this is commonly shown during demos, this is not a feature of NWBC. Nwbc only shows the simplified WebDynpro application (usually custom build))
- We can use our current SAP roles (sure, but that will only show SAP GUI dynpros in an NWBC frame, probably not what you intended)
- After installing NWBC on the desktops we are good to go (no, definitely not. You still have to design the NWBC specific roles, define (business context) content, determine relevant POWLs, workcenters and Chips, configure backend systems, activate new functionality, ……)
- NWBC provides additional content such as NWBC roles, POWLs, Chips and workcenters to improve the user experience (no, this is actually provided with support packages, upgrades and activation of business functions (sets), NWBC can only use them from the backend configurations.
So, many expectations that customers have from presentations, sales meetings and showcases are not fulfilled. This is not necessary a problem, since all the expected can be realized. This will however require a much bigger effort and have a bigger impact than the customers had perceived.
In short, a lot of customers are delighted to see the NWBC being showcased (demos) and find the new look and feel, the workcenters approach and the business context functionality i n sidepanels very promising. However, when the customer starts to realize what the implementation effort (including role redesign and technical prerequisites) should be, how much dependencies there are on activated and configured backend functionality and how many expectations cannot be fulfilled, they back down and remain at the current UI solution (usually the plain old SAP GUI).
In my opinion, the issues mentioned above should be addressed by SAP and its partners before a better adoption rate for the NWBC can be realized. The technology is there, the available business content is growing every day as is the understanding of the NWBC. It’s actually a good concept, build on available technology and available expertise within customer organizations. It is however eminent that the delivery of content and documentation must be improved before the NWBC can deliver on promise.