Working as the CTO of Neptune Software for the last three and a half years, I have spent most of my time working with SAP mobility and User Experience, meeting and discussing with customers and helping in mobile SAP implementations all over the world. This post will look at the three major misconceptions I have observed that in my opinion dooms your mobility project.
1 - Responsive Web Design is sufficient for Enterprise Mobility
With the emergence of HTML5 and great frameworks like SAPUI5, it is possible to create responsive web pages enhanced for viewing on mobile devices and even optimized for touch events. It is tempting to view mobile web apps as the most cost efficient and best option to roll out mobility in an organization.
Unfortunately this solution is ill suited for any serious mobility project and more so in an enterprise setting. I see more and more of the SAP community considering mobility as inherent in all other topics, which is good, but I am afraid that projects downplay mobility into adding some responsive UI5 or Fiori screens. Seeing how few pure mobile sessions there were in last year TechEd && d-code and Sapphire illustrates in my opinion a dangerous trend.
User experience, authentication, security, offline capabilities (For larger amounts of data), application distribution and access to native device features are the most prominent of the reasons why web apps is not a valid option for any serious Enterprise mobility strategy. Apps dominate mobile internet usage and consumers move away from the mobile browser, as can be seen in this publication from Flurry Analytics:
You do not use Facebook, Twitter and LinkedIn in a browser on your mobile device so you should not expect your users to feel differently about your enterprise applications.
Hybrid is definitely the way to go. You get both the advantages of native capabilities and responsive cross-platform development. Today you have several options to achieve this. I recommend looking into Cordova/Phonegap that can be utilized in SAP projects using NAM from Neptune (I am working in this company) or read up on john.wargo 's blogs regarding Kapsel and hybrid development with the Web IDE.
In addition to Hybrid Apps, you need to look at how to distribute these and secure them in a user-friendly manner. Neptune has support for this but there are many options and combinations of these on the market. You can look at the SAP Mobile Secure solution, SMP (HCPMS for Cloud Version), AirWatch (WMWare), XenApp (Citrix), Mocana, Apperian and others. The trend is moving from Mobile Device Management to Mobile Application Management (Blame BYOD) and remember that security should not impact usability too severely as this will drastically reduce user adoption.
Implementing a proper mobile solution is not as difficult or costly as many customers I have met seem to believe.
2 – Use “Vanilla" apps
Customers often want a “standard” app, at least before they start implementation. I am a strong believer in adapting software to fit the individual customer. Customization and enhancement possibilities is what has made SAP great. Customizing, for instance, logistics using SAP results in major competitive advantages.
Traditionally we have been stuck with a static user interface in SAP solutions and this has been a major pain point. It is bad on a desktop but useless on a small mobile screen. The first productivity apps from SUP had this issue and I vividly remember a consultant being asked to leave a meeting some years ago after suggesting that the customer should remove WBS from their cost assignment to fit the Time Recording app.
Today we have the opportunity to create great and customized SAP UX for individual customers. We can for the first time in SAP’s history focus on the end-user regarding UI and use modern development strategies (lean, agile and iterative) to create applications that fit them perfectly.
Use design thinking, include real end-users (Super users tend to be afraid of losing functionality and clutter the app with loads of elements). Test in production with a small but relevant pilot group with iterations improving the app (With a small monitored user group you can always fix postings in the backend, and once you roll out on a large scale you have one shot, so do it right )
This is the reason we refer to our premade Neptune applications as templates. Our customers consume these, then change and transform the templates into killer apps.
One size does not fit all unless you mobilize your SAP GUI screens and you don’t want an app like this:
3 – Base your Enterprise Mobility implementations on an API first approach.
The API first approach is gaining momentum. Theorists (I’ll pay for this :wink: ) claim that it boosts development productivity and helps create multi-platform applications more easily. A few years ago, we had the same hype around the ESR (Enterprise Service Repository) and SOAP was the solution for all integration and external exposing of backend data (I returned to good old custom IDOC’s after a short time). Well it was not. Our PI systems crashed and debug was hell. Why? The services were created for certain scenarios and often complex and not optimized for large volumes. Today we look at oData through GW services, often with nested structures demanding complex client-side logic and low performance. Performance is vital in a mobile scenario.
Therefore, it is better in my experience, to create your backend access in parallel with client functionality – Consumer first approach. This will ensure that you only fetch and send the data you need in each request. This (And superior offline capabilities) has been the main reason we use native JSON bound to element attributes in the Neptune Application Designer and not taken the GW path, even though external pressure has been big.
- SAP Managed Tags:
11 Comments
