And yet, most employees are stuck in a mobile app time warp, limited to doing only email and calendars on their smartphones. Consumer apps have beautiful interfaces that utilize touch and deliver data in one or two clicks. Employee-facing apps have tiny fonts, ugly interfaces, and endless menus that require minutes of navigating to get data. In fact, an employee may need to access several applications before he or she has enough data to make a business decision.
Why? It's easy to blame security and compliance issues for holding companies back. But it's not the only reason we're seeing a digital divide between well-served consumers and neglected employees. There are at least three issues a company wrestles with as it looks to offer business apps to employees.
First, what should the company mobilize? Companies have dozens, if not hundreds, of apps, many of them custom built. IT already is wondering if it should kill some of those applications outright, consolidate them, or replace them with cloud-based software services. They don't want to spend money mobilizing a legacy app that they end up replacing. Also, the company needs to mobilize a whole process, not just an app. Mobilizing one app may allow an employee to complete only a portion of a process--finalizing a sale, for example, is often composed of transactions from multiple apps, such as CRM, inventory, and purchasing.
[ Keep on top of changes in the mobile industry. Read 5 Biggest Mobile Stories Of 2011. ]
Second, how should I mobilize these apps? Does IT build apps that are native to the device, embrace an HTML5 mobile Web experience, or build a hybrid of native and Web? If it selects native app development, it also has to choose which mobile operating system platforms. Does it support Apple iOS, Google Android, RIM Blackberry, and Microsoft Windows Phone? What companies are learning is that there's no single software development model that works for every mobile scenario. Most businesses will use a mix of native, hybrid, and mobile Web. The decision will depend on the depth of functionality the app requires.
Third, what are the top priorities for mobile development? In selecting processes to mobilize, a business must decide what parts of which apps will be available on a mobile device, and which apps will be done first. Just taking an app that was created for desktop use and making it accessible on a mobile device won't work. IT must understand what functions of the app should be accessible on a mobile device, and how much they need to be revised for mobile work. These are complex questions that can stall IT efforts.
To get over these humps, a successful mobile strategy requires IT to work with each business unit to define which processes will deliver the greatest business benefit. IT should select a short list of processes and mobilize these to prove the business case. Get a quick win and move on from there.
IT also needs to help the company rethink what an app is. Many businesses try to replicate the entire desktop app for a mobile device. For an initial mobile rollout, it is perfectly acceptable to pick one or two functions of the application and deliver those well. However, the days of a one-year (or more) application development cycle are over. Don't let "feature creep" get in the way delivering those one or two functions quickly. And once the mobile app is live, be prepared to listen to employees, hear what's missing, and quickly add new features.
Of course there are other issues to resolve such as the security issues of employee-owned devices, management of mobile devices and applications, and the cost. But until the basic questions of what and how to mobilize are resolved, there will continue to be too big a digital divide between what a person can achieve with consumer apps versus what they can achieve with an enterprise mobile app.