Skip to Content

Enterprise Mobility Project – 5 Key Decisions

In last one year, enterprise mobility as a topic in general and SAP mobility in particular has drawn lot of attention. With global mobile phone subscribers base expected to cross 5 billion in 2010 (source International Telecommunications Union) and mobile data becoming cheaper (especially in India) a lot of enterprise software firms are lining up their “bolt-on” solutions for mobilizing various processes. At the same time there have been a series of discussions / blogs / whitepapers on this topic explaining the benefits of mobilizing your processes.

However even with all this information and solutions, it’s a very big problem for customers to adopt enterprise mobility in their organizations. In my view this is mainly due to complexity involved in enterprise mobility technology and low awareness of the same. In this blog I will highlight the 5 key decisions one has to make before starting and Enterprise Mobility Project and my view on the same.


DECISION 1 – Processes and user groups to be mobilized

This is a very important and strategic decision an organization has to make because all processes and user groups might not be fit for mobility. For ex – A process that requires a lot of data entry is not fit for mobility because users will be reluctant to use such application on mobile devices.

Therefore this decision should be made after a lot of internal brainstorming and analysis. There are many examples of processes and user groups that can be and should be mobilized.

In my view the few Processes that can be mobilized across all industry segments are Approvals, Alerts and Dashboards, Quality Inspections, Sales Order Entry, Service Order Fulfillment etc

Few User Groups that should be mobilized are Mobile Managers, Sales Force, Service Force, Warehouse Agents, Quality Inspectors etc


DECISION 2 – Type of mobile application

What is type of mobile applications? In my view based on the type of connectivity and data storage required, the mobile applications can be classified into two types:

·        Always Connected – A thin client application that allows user to view and transact on data ONLY when it is connected to business systems is termed as “Always Connected” application. These applications do not store any transaction data on the mobile device

·        Occasionally Connected – A thick client application that allows user to view and transact on data even when it is NOT connected to the network is termed as “Occasionally Connected” application. These applications store transaction data on the mobile device and synchronize it with your business systems occasionally.

To decide on which type of application you need, answer a simple question:

Does your user needs the application when there is no network connectivity to your business system?

If the answer is yes, you need occasionally connected application else always connected application should be fine. The below example will clarify the point:

Company A receives all goods at their warehouse that is Wi-Fi enabled. To mobilize their GR process an always connected application on a device with Wi-Fi support will do the job

Company B receives goods at their warehouse that is 50Km outside the city and in an area where even GPRS connectivity is disruptive. To mobilize their GR process an occasionally connected application is required as the network connectivity to your business systems cannot be guaranteed from such places

This decision is important because the cost of always connected application is less than occasionally connected applications


DECISION 3 – Device, OS and Network Provider

As on date there are

·         Hundreds of device manufacturers – Nokia, Samsung, Sony Erickson, HTC, RIM, Apple etc

·         Lots of OS – Symbian, Windows, BlackBerry, Android, iPhone, Linux

·         Multiple network provider in each country

Hence to make a decision on these 3 parameter is very difficult. Moreover these parameters will have the largest impact on the overall cost of the mobility solution. Here is the list of key points that needs to be considered togetherwhile deciding on the same

·        Device – The typical factors that one should consider while selecting a device are

o    Cost

o    Touch/Qwerty/Non Qwerty

o    Screen Size

o    Processing Power

o    Database Capacity

o    OS of the Device

o    Availability –  If the number of mobile users grow in future one should be able to buy the same model from manufacturer or a new model that will run the existing application


·        OS – The typical factors that one should consider while selecting an OS that will be supported are

o    Openness of the OS platform (Manufacturer controlled Vs Association Controlled)

o    Availability of native and OS agnostic SDKs for the OS platform

o    Support Cost of application on the selected OS

o    Security provided by the OS

o    Availability of Developers for the OS Platform


·        NetworkThe typical factors that one should consider while selecting a network are

o    Connectivity while travelling and in remote areas

o    Data Speed

o    Cost

In my view an organization should start rollout on a single OS with max 2-3 device models and one network. This will ensure that IT Team has less issue while supporting the users using the devices.


DECISION 4 – Mobile Enterprise Application Platform (MEAP)

Mobile Enterprise Application Platforms (MEAPs) enables an organization to develop multiple applications to mobilize various processes on different devices/OS that work on all networks

Now the question is do you really need it? Gartner’s “rule of three” can help you find this answer. A MEAP offers significant advantages in three situations:

  1. When      there are 3 or more mobile applications
  2. When      there are 3 or more targeted operating systems or platforms
  3. When      they involve the integration of 3 or more back-end systems

There are lot of MEAP players in market like Sybase, Antenna, Dexterra and Syclo etc.

Since SAP has acquired Sybase, the leader in MEAP providers, it becomes a natural choice for SAP Customers. As on today Sybase integrates its SUP server with SAP NetWeaver Mobile 7.1 server (mobile middleware) that has native integration with SAP Business Suite. Going ahead SAP plans to offer one integrated server to its customers. This new product will be available by mid of 2011.

However this does not means you should defer your mobility plans to next year. In my view any customer looking to start mobility project right now can start with SAP NetWeaver Mobile 7.1. Since both SAP and Sybase have existing products on this platform, most likely SAP will protect their own investments by supporting these on new platform.


DECISION 5 – Develop or Buy

As on today there are plenty of SAP ISVs offering solutions on SAP EcoHub for the processes listed above (see DECISION 1). So it’s a big challenge for customers to decide whether they should buy an existing solution or develop on their own. Some of the factors that should be considered are:

·         Investments in R & D, tools and skills required for in-house development of Mobile Application

·         Scalability and Stability of the Readymade Solution

·         Cost of the Readymade Solution

·         Time taken for ROI in both options

In my view a customer may start by buying the first solution as this will ensure that ROI is much faster. Moreover during the course of their first project, they will become familiar with challenges of enterprise mobility and will be better equipped to deal with the same once they decide to develop the second app in-house



  • In      this blog I have shared my own views based on experience gained while working on enterprise      mobility projects. You are free to disagree and share your views on the      same so that all of us can benefit and learn more on this topic
You must be Logged on to comment or reply to a post.
  • Hi Shubham,
    Really nice and informative blog.
    The next year is definitely going to be very exciting for Mobility lovers as SAP-Sybase are planning to dish out new products into the platters of the customer.

    Mobility is definitely on the rise and sooner the vendors realize, it would better for them.

    • Thanks Sanjay. I think the ISVs have already realized the same. Its time that customers realize the power of mobility and start adopting the same.
  • Having worked on developing a mobile solution myself, there is one more area of development which you did not really mention. Overall, your decision making summary is excellent ( I went through pretty much the same process myself)  but just missed one potential opportunity. You kind of allude to the idea but do not point it out.  In the area of occasionaly connected applications, there is a distinction betweeen a thin  client application and a browser based application.  As the mobile browser wars heat up – there is going to be more competition to get different applications working via browser – as zero footprint applications with no installation needed.  There is significant push in the market to make browser based application more of the norm.
    Thanks for posting !
    • Hi Michael,

      Thanks for pointing the same.

      I think the idea of browser based application works well in countries where
      – Data connection is available even in remote areas
      – There is no disruptions in data connection while on the move due to tower hops

      The countries where both these problems exist one needs a thin/thick client to store the data on devices.


  • Nice break-down of the decisions. You can use BSP for mobile browser applications. Check out a Youtube demo of our BSP application at You don’t need to buy new technology. BSP was available ten years ago.

    I agree that targeting one mobile OS is a good idea. You need to optimize the applications for the device to get the best user experience.

    • Hi John,

      I like the idea of browser based application irrespective of language (BSP/WebDynpro/HTML) but only if the user experience is NOT compromised due to mobile network disruptions which is beyond might control.

      I believe you will agree that a end user will blame the app and not the mobile n/w if they are unable to use the app when they want to use it

      Hence I feel the need of a thin/think client and a middleware for the same


      • Hi Shubham,

        I agree with you about the slowness of mobile networks. Many mobile applications will be used on WiFi connections within the company network. They should not have too many latency issues.

        The key to a high quality browser application is client side caching of data using technologies like AJAX and HTML 5. Using these technologies, you can get similar performance to a native application without the hassles of being approved by the mobile vendor (e.g. Apple store).

        Remember that SAP is a real time system. There is no offline SAP GUI for your laptop that caches master data and transactions. If you want an offline report, you can always schedule a job to email the output from your reporting system. These offline reports can be accessed from your phone while offline. When posting transactions, most SAP scenarios require real-time access. For example, ATP checks or MRP require real-time access to the system to work.

        Thanks for your blog post. I think this is a common debate at many SAP customers right now.