News Stay informed about the latest enterprise technology news and product updates.

Planning an SAP mobile applications project

Delivering SAP mobile applications is a centerpiece of the vendor’s strategy. How can organizations align their SAP mobile strategies with SAP’s plans?

The explosion of smartphones and mobile applications has many business users demanding that their enterprise applications have the same mobile capability and ease of use they get with their consumer devices. Yet, for a system as large and complex as SAP, that requires some careful planning and prioritizing, according to industry experts.

The mobilization of SAP has changed significantly.

SAP end users want SAP mobile applications that handle work beyond field services-related processes, seeking software that will help improve customer responsiveness and increase competitiveness.

SAP mobile deployments are moving beyond the shipping dock to the sales office, targeting the “knowledge worker,” according to Chris Hazelton, an analyst with 451 Group. Users want more customer data and quick views of performance and goals – which means more CRM-related functionality, analytics and collaboration tools on their mobile devices.

However, the growing popularity of mobile applications presents several challenges for IT in planning an SAP mobile project – including accommodating different devices and operating systems, prioritizing requests for functionality and measuring the ROI of what’s deployed.

“I feel like we’re at an inflection point in terms of what mobile solutions can do,” said Warren Wilson, research director at Ovum. “The challenge is deciding what you want to mobilize, and what it takes to do that.”

Getting started with SAP mobile applications projects

First, organizations need to set mobile policy. In many companies, business users are combining personal preferences and business use cases when making mobile decisions, resulting in multiple devices, operating systems and application providers within the company and creating a challenging situation for IT.

“What’s becoming a pain point is that there are too many silos and too many autonomous things,” said Michele Pelino, principal analyst with Cambridge, Mass.-based Forrester Research. “There needs to be a strategic vision for mobile policy.”

Standardizing on one device can enable better security and control costs, Wilson said, and supporting everyone’s choice can get costly because it means applications with run-anywhere models. Device standardization has its drawbacks. Frustrated by attempts to standardize, end users often start to look for applications whose purchase they can authorize on their own, Wilson said.

In turn, many organizations question whether they should let more than one operating system through the door, Pelino said. But organizations increasingly have to deal with the reality that they’ll need to support more than one operating system. Many companies will wind up supporting three or four.

“The norm is multiple operating systems,” Pelino said. “It will get more fragmented before it gets simple.”

There are drawbacks to limiting the number of operating systems. Not all applications are ideal for a single operating system or a specific device. Organizations need to factor in device screen size, battery life, security, and usability factors when determining which operating systems are best for a specific application, Pelino said.

“If you limit usage to a single operating system,” she said, “you may also be impacting the types of mobile applications that can be provided to employees.”

SAP is working with Sybase, which it acquired in May, to mobilize business suite applications, and says it'll continue to rely on other partners like Syclo for mobilizing applications as well. Proliferation of devices, time to market and the speed at which the market is moving have all influenced SAP's decision to make partnerships with mobile vendors the main leg of its mobile strategy.

One of the challenges with SAP has been that each implementation is unique, Wilson said. There’s a great deal of variety in how SAP applications are deployed, and there’s a great deal of variety in the data schemas that underlie those implementations. To the extent that a mobile application needs to draw on a data schema, it’s almost a custom process to mobilize an SAP application in a robust way, he said.

To tackle this challenge, systems integrators such as Accenture and IBM work with the likes of Sybase to implement these applications at customer sites. SAP will point a customer toward an SI, which will then customize the applications using the tools and apps from SAP’s partners.

In most cases, a partner can take care of the vast majority of the design and implementation, Wilson said. Organizations can also buy out-of-the-box applications from mobile vendors.

SAP has made it a lot easier to find these partners with its EcoHub, an online marketplace for SAP partner products with user-generated reviews. SAP is directing its customers almost exclusively to partners when they want to mobilize SAP applications.

Prioritizing what to mobilize

In prioritizing SAP mobile applications projects, organizations should look to where they can achieve the biggest impact on their business processes, Pelino said. Determine the types of applications to think about first by deciding which workers are away from their desks the most. Who can resolve customer service issues faster?

“Many firms focus on those applications that improve employee productivity or efficiency first or address customer service and support issues,” she said, “because these applications address the overall requirement for firms to do more with fewer employees and to keep their customers satisfied and happy.”

The lines of business that are profit centers should be the first to get mobile technology, according to 451 Group’s Chris Hazelton.

Organizations should deploy applications on a process-by-process basis.

Cost centers like human resources should come afterward. For these projects, choosing out-of-the-box applications from SAP partners will save time and money, Hazleton said.

Measuring the SAP ROI

Before deploying the applications, it’s crucial to identify who should feel the benefits and how to measure them.

One method Hazelton suggests is to be sure to understand what it currently costs IT to support the sales force. Look at how much revenue they’re bringing in and what it’s costing to support them with on-premise applications. Then look at how much it’s costing to support them with mobile application and the subsequent sales revenue, Hazleton said.

Also, get ROI figures for similar customers and deployments from the vendor you’ve chosen for that mobile application. Get references from customers in comparable verticals to see how much projects cost and what their return is.

In turn, consult the end users and draw them into the development process early on to make sure what’s designed is what they want to use, Wilson said.

But don’t try to do too much. It’s one of the biggest mistakes organizations make – and makes it tough to measure the benefits.

Things like the screen size and battery life inhibit what these devices can actually do, Pelino said. Keep expectations reasonable, reminding users that it won’t replicate the desktop experience.

“Folks will want the world,” she said. “Many times, companies say, ‘We paid the price for that. We started investing tons of money and, ultimately, no one used it.’”

Dig Deeper on SAP mobility software

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.