10 Mistakes to Avoid in Mobile BI Delivery

Register now

Mobile applications have gained a definitive place in enterprise adoption. The growing maturity and adoption for mobile business applications are predominantly visible with service offerings like mobile banking, mobile shopping and mobile social network connections.

The extended mobile business application for business intelligence (mobile BI) has gained momentum, with most of the BI tool vendors offering a mobile extension to the native BI suite itself. Furthermore, the variety of platform support, user-friendly devices and graphical interfaces has pushed enterprise adoption of mobile BI into the spotlight. In 2010, Gartner published a hype cycle indicating mobile BI is a climbing wave and stated that adoption will be visible in two to five years.

The important thing to remember, simply put, is that mobile BI is not just a mobile version of traditional BI; it is a mistake to overlook the unique considerations required for implementation. As a mobile BI practitioner closely following the mobile BI market dynamics, I offer 10 pointers for practitioners looking to deliver mobile BI to the enterprise.

Mistake 1: Assuming mobile BI implementation is a project, like a traditional BI implementation

The nature of a mobile BI engagement is more like a program rather than a project. It is a fact that mobile BI is an extension of enterprise BI. However, mobile BI should be focused on delivering measurable business value rather than just meeting scheduled objectives. In mobile BI engagements, it’s more important to derive effectiveness.

For a traditional BI implementation, it’s important whether the planned activities were completed within the time and budget allotted; however, for mobile BI it is more important to measure how particular information, when made available through mobile apps, can make a difference to the decision makers/users. For execution purposes, the requirements-gathering for mobile BI should be focused on identifying which reports, dashboards and alerts will be beneficial on handsets. The emphasis is on the value of the data with respect to time rather than look and feel of the reports/dashboards itself.

Mistake 2: Underestimating mobile BI security concerns

The top concern in mobile BI adoption is security, and if not designed correctly, it really can be an issue. It’s the most discussed aspect in the mobile BI world today and has a very direct impact on the rate of adoption. Security for any application beyond the enterprise firewall has always been a debate. However, the interesting fact about mobile BI security is that, when designed optimally, it can leverage more security layers and features than traditional BI apps.

  • Device level security: Utilize the handset/device security features to protect the data, including features like full-disk encryption, the ability to remotely wipe content on the device, and antivirus and firewall software.
  • Transmission level security: The security features of cryptographic shared key systems, secure socket layers and VPNs all ensure that the data can be secured at the network layer.
  • Application/network level security: The authorizations and authentications can be enforced on the applications at the infrastructure front. Most BI tools extend the same security model to mobile BI that they have designed for their native BI applications. On top of the network, policies can be enforced the same way it’s done for the enterprise.

Mistake 3: Rolling out mobile BI for all users.

Mobile BI apps should not be put in the same category as management BI reporting apps. The purpose and use of mobile BI apps are very specific and different than MIS. The most important factor is to understand who will need information at all times and what decisions will be impacted by having or not having the information always accessible.

Are these users always mobile and have only a limited amount of time to access the data, or do they have a role where they don’t need to frequently check the data? Define the user group(s) and design the mobile BI app based on these role definitions. Typical candidates for the app are users responsible for mission-critical environments, such as a data center hosting payment servers for banks, or to solve real-time problems as they arise, like power station operations. Mobile BI investment will be justified only when users and usage are understood and aligned realistically.

Mistake 4: Believing that return on mobile BI investment cannot be derived

Every investment has a justification, and a business sponsor will definitely demand one. Whenever there is cost involved, there will be a means to track it and determine the ROI. It might be challenging in mobile BI initiatives, but quantifying the business benefits can be done. Consider the following key aspects when deriving ROI:

1) Benefits associated with mobile BI. Is the initiative focused on:

  •  Increasing employee productivity?
  •  Closing sales in a much shorter time span?
  •  Lowering business costs (like material cost, reducing administrative time, etc.)?

Once these are defined, the investment can be linked with the benefit.
2) Investment associated with mobile BI, such as buying devices (handsets, iPad, etc.) or investing in infrastructure (hardware, software, maintenance, service and training).

Now an ROI can be calculated using the defined tangible and nontangible metrics.

Mistake 5: Implementing mobile BI only for operational data

The mobile BI application can be pushed to accommodate all reports/dashboards available in a traditional BI environment, but that will defeat the purpose of having an initiative like mobile BI. A categorization of the good-fit data has to be done with each initiative. This is important because the question of “which data is good for which enterprise?” is very subjective, and only respective business users can answer this. For example, a workflow approval might be critical in one environment, whereas having current currency rates handy at all times might be critical for a different user.

Operational data is definitely a strong contender for mobile BI. It’s justified because most operational data is time bound, and, especially within regulated environments, you might end up paying expensive fines for having missed critical information and reacting late to an event. Extending workflows to mobile devices might speed up process efficiency by itself. However, it’s also true that mobile BI is not limited to operational data alone. The features offered by mobile tools (such as alerts, filters, the ability to drill for additional information, etc.) enable analytical data to be extended to mobile devices.

The best scenario is the ability to demonstrate tangible analytics to a prospective customer and close the deal on the spot – that’s a win/win situation for having mobile analytics. It’s quite possible to track a trend through KPIs, and specific trends that can be useful on mobile devices include indicators of a situation getting better or worse, a scorecard value, the current value of a key metric, etc. Also, analytics for pricing and inventory will be good candidates for mobile to enable instant, informed decisions.

The proper data has to be identified for the best fit for mobile BI to cater to the right users. The data selection in mobile BI is a much more serious affair than in traditional BI, because the user community for mobile BI is small but has a great need to make decisions based on timely, available information.

Mistake 6: Assuming that mobile BI is appropriate for all kinds of data

Mobile BI should be more focused on the near-term data rather than future-planning data. “Should I be opening a new store in a particular location next year?” is not the right kind of data to analyze with mobile BI. It’s more useful to analyze something like, “Should I order a particular inventory immediately?” This near-term information will help bottom-line sales figures. All data mining activities should be kept away from mobile, as it is not a good fit.

Be careful to pick variables upon which you are performing analysis from a quality perspective. If you have to analyze too many variables, then doing so on the big screen is better.
Not all data is useful in handsets, and identifying which data is suitable for mobile BI should be done very carefully. If the data categorization selected is not appropriate, no matter what technology and skills you engage, it’s going to be a failure. Having extra information on the move will help users make better decisions. Suitable data for mobile BI allows the user to:

  • Answer critical questions;
  • Take quick actions, like approving or passing on the information/alert to someone who will take immediate action on the event;
  • Close the sale with all information handy (like rates, offers, etc.); and
  • See mission-critical data where key metrics are tracked every few minutes.

Situations that require examining pages of documents or understanding a complex diagram are not optimal for mobile. Similarly, reports that are detailed and generated only on a periodic basis are definitely not candidates for mobile. It’s not that they can’t be put on mobile, but the usability and benefit behind making them mobile will not be worth the investment of time and money.

Mistake 7: Designing mobile BI similar to traditional BI design

A different focus is required for designing mobile BI applications. Mobile BI design has special considerations when compared to BI report and dashboard design. Technically, everything available in enterprise BI can be extended to mobile. However, the design varies when it comes to formatting and fitting it on the small screens. For example, the design changes you would make for an iPad or other tablet will be different from the design considerations for mobile phone like iPhone or BlackBerry. The dashboard design best practice for mobile BI is clean and uncluttered presentation. Limit the objects to be placed on dashboards.

Furthermore, the design for mobile should take care of the categorization of which reports and dashboards are suitable for small screens to navigate, from a size perspective and ultimately from a usability perspective. As a mobile BI app, the expectation is to have all capabilities that a BI has, such as drill-through, drill up/down, filter, rank, etc. The size of the handset and the little key strokes in it might increase complexity and reduce ease of use if not carefully designed.

Mistake 8: Assuming that BI is the only data source for mobile BI

While focusing on designing the mobile BI apps, a special focus should be to analyze the kind of data being brought to mobile. Mobile BI should not be treated as just an interface for accessing traditional BI. One should be able to clearly identify specific questions that the data is going to answer when extended to mobile. All the data sources that cater to traditional BI can be utilized in mobile BI, including databases, enterprise resource planning, Web services, spreadsheets, etc. The design should be robust enough for a presentable and stable form on the device.

Apart from this, mobile BI is a program, and one should always hunt for those nontraditional information sources which, when integrated to the mobile platform, will increase the clarity of the decisions. The combination of multiple data sources will produce the best real-time results. Change is the only constant, and mobile BI apps should be designed and built with scalability in mind as a priority.

Mistake 9: Believing mobile BI implementation is a one-time activity

Mobile BI is very dynamic in nature and is heavily dependent on what information has priority at what time and who the users are. This might change from time to time. Hence, a word of caution: It’s not wise for mobile BI implementers to tie the implementation strategy to a specific technology or platform. It might not always be possible to keep a framework design, per se. However, at every step, best practices can be imposed to keep mobile BI apps ready to be ported to any other platform as seamlessly as possible. Remember, the mobile BI platform may be small, but it has a bigger impact when integrated with traditional BI.

All the options of having a browser-based app or a thick client-based approach should be evaluated. There will always be pros and cons to each approach. Evaluate which compromise the users are willing to make temporarily and in the long-term. For example, having only a client-based app would require frequent upgrades in the future when compared to the browser-based approach.

Mistake 10: Claiming that any device is good for the mobile BI app

There are many mobile devices and platforms available today. The list is constantly growing and so is the platform support. There are hundreds of models available today, with multiple hardware and software combinations. The enterprise must select a device very carefully. The target devices will impact the mobile BI design itself because the design for a smartphone will be different than for a tablet. The screen size, processor, memory, etc. all vary. The mobile BI program must account for lack of device standardization from the providers by constantly testing devices for the mobile BI apps.

Some best practices can always be followed. For example, a smartphone is a good candidate for operational mobile BI. However, for analytics and what-if analysis, tablets are the best option. Hence, the selection or availability of the device plays a big role in the implementation.

Moving Forward

Mobile BI was a hot topic in 2010 and was in ramp-up in hype cycles. There is a big buzz about the adoption of it, as well. However, what’s important to achieve success in making faster decisions is to start the mobile BI implementations with the right questions being asked of the right people. Regardless of which vendor, technology or device creates a buzz in the market, a careful evaluation of the combination of considerations is required before investing. The right questions have to be asked of the right users, who will then lead the selection of the right data and tool for making the right decisions faster.

For reprint and licensing requests for this article, click here.