Wondering about where an SAP mobile deployment can go wrong, the pitfalls and common mistakes of early adopters?
"How much time do you have?" asked Jack Gold, of J. Gold Associates LLC, a Northborough, Mass.-based consulting firm.
The ways a mobile SAP project can fail are many. That's not particularly surprising given the size and complexity of SAP itself and the difficulty in translating enterprise applications to the mobile world. Besides, SAP is not exactly well known for its friendly user interface.
Organizations considering a mobile SAP deployment confront what Sheryl Kingstone, program manager for customer-centric strategies at the Boston-based Yankee Group, calls the "consumerization of the enterprise." Accustomed to the simplicity and ease of use of things like Amazon.com and the iPhone, users are coming to expect the same of their enterprise applications. It adds one more hurdle for a mobile deployment.
"A lot of companies say that workers aren't using applications on the desktop, so why the mobile phone?" Kingstone said. "Maybe it's because the desktop app sucks."
Therein lies one of the major contributors to the failures of mobile SAP projects -- simply moving the SAP interface to a mobile device is not going to work.
"The whole notion of usability on a smartphone changes from that of a PC," Gold said. "Many companies fail to realize this. If you try to use the existing SAP UI on a mobile device, chances are almost 100% you are going to fail."
Another factor is that many organizations are moving to more of a cloud-based, Web browser-based environment for their applications, which presents issues of its own. If it's a cloud-based application with no offline function and a user is stuck somewhere he can't get a connection, the device is of no use.
For a deployment that involves mobile field service workers traveling to remote locations, that's a significant issue.
Aside from the basic look and feel, organizations also need to carefully consider how much SAP data they want to put on a device. What seems like a common enough step -- consulting mobile workers on what it is they want and need from a mobile deployment -- is often skipped. It's not a matter of putting SAP on a mobile device but rather finding out what workers want to be mobile and using SAP to deliver it.
"There are companies that, because they don't study it up front, wind up spending a huge amount of money in rebuilding the application after they deployed it, because it doesn't do what they thought it would do," Gold said. "If the user isn't more productive, why would they use it? They'll find a way around it."
And do not discount screen size, fonts and workflow in that discussion.
"You still need to make sure the UI is easy to understand, that the information is readable -- and that it's not overly complex," Kingstone said. "It's not just taking your traditional application and mobilizing it. It's thinking out of the box with new features that add value, such as GPS or metadata for the call."
Tactical projects can be disastrous
Problems arise not just in what data to deliver but which applications as well. That will mean the ability to access more than just SAP data.
"Rarely will you find a mobile user who only needs one app," Gold said. "Maybe if you're delivering beer or chips that's all you need, but a typical knowledge worker may need to get into email, SAP, expense, calendar. Everyone says put everything in SAP, but many companies aren't like that."
An all too frequent point of failure for mobile SAP projects is neglecting to take a strategic approach to the applications that will be mobilized both short- and long-term.
"One of the things I found is that few companies do an adequate job of building out a complete mobile strategy," Gold said. "Most companies will pick a project like expense management, but they won't necessarily architect an infrastructure that allows them to expand."
A lone department or division will often undertake a mobile SAP project and build a mobile application that fits only its own needs and can't integrate data or business processes from across the organization.
Those deployments can be costly to adapt. Companies embarking on a mobile SAP project need to be aware of the organization's mobile needs or start with an application with broad implications, such as expense reporting, Gold said.
"Do that within the scope of what else you are going to do," he said. "Let's not build a one-off app. It'll cost you more to build an app that will fit well with others, but it's worth it."
And when the SAP mobile project goes wrong, it's usually IT that takes the blame, fairly or not.
"I've seen companies that had totally incompatible applications," Gold said. "The department that paid for it says, ‘That's great,’ but no one else can use it. I can't tell you how many companies I've seen do that."
Pick a partner
Developing mobile versions alone is generally not a good idea either, Gold and Kingstone agree. They suggest enlisting a mobile middleware provider or SAP itself. SAP's much-heralded decisionto partner with RIM to run SAP CRM on the BlackBerry two years ago has been scrapped, largely because most companies need to support more than one device. SAP also recently acquired Sybase, and development of mobile applications is top amongst its plans. Without the mobile middleware layer, users can force themselves into a corner.
"What they're going to get is a mobile application-centric UI versus a process-centric one," Kingstone said. "When you're talking about an SAP user, you may want to consume bits and pieces of information across multiple applications."
But as always when an organization brings in outside help -- whether that's a mobile middleware provider, an SI or a consultant -- it's important that all the integration is well documented.
"The big problem is defining your connection points -- APIs to SAP and into whatever tool or UI for the device," Gold said. "Make sure you understand how those things go together. It's generally hard to just throw everything over the wall. You can do it. You're just going to write a big check at the end of the day."
The integration discussion also needs to include considerations over data, devices and speed.
"The integration comes in with legacy applications," Kingstone said. "You don't know what you can expose easily. So what do you expose? How much information and at what refresh rate? Is it real time? Is it browser-based? Is it downloaded to the device? All of these are going to depend on the business process, complexity of integration and what version of SAP you're actually on."
Companies building mobile applications on their own face another problem beyond just their internal data and process requirements. Many are not paying attention to the sheer number of mobile devices emerging and the pace at which they're being released.
"If you're writing a custom app and building it with homegrown tools, you're never going to keep up," Kingstone said. "You might as well look at a middleware player to take some of that work off the table."
Finally, ensuring continued success requires continuous monitoring of the initial mobile SAP projects.
"Make sure you don't throw it out there and move to the next project," Gold warned. "Find out what you did well and didn't do well, what users liked and didn't. Make sure productivity has improved. Yes, it will cost money, and it's hard to get funded, but how else do you know what you don't know?"