The future of enterprise tech lies in apps -- largely mobile apps that deliver the same functions across virtually every platform for mobile devices, desktops and online. But the past, as in legacy processes and app portfolios that are sometimes decades old, can still get in the way of that future.
Modernizing an app portfolio is never easy, but done right, it can be a boon for a company (or school or other organization) by boosting productivity, employee engagement and customer satisfaction.
While many organizations now routinely focus on rolling out mobile solutions, usually developed for deployment in the cloud, not every effort is successful. Sometimes employees or customers reject new apps. In other cases, users decide to work around enterprise apps so they can get things done without even using them.
When app initiatives fail, they usually do so for a handful of reasons. Simply put, IT shops and enterprise developers looking to embrace a new way of doing things fail to plan ahead.
Here are five of the most common reasons development efforts can fail -- and how to avoid them.
Building instead of buying
One of the biggest misconceptions when defining an enterprise app strategy is thinking you have to build everything in-house. The need for custom apps designed for specific internal processes that are proprietary is a long-held view. For years, if not decades, this level of in-house development wasn't a choice. It was a need. Even when third-party solutions were part of the equation, many required extensive customization. The result: many large organizations still assume that they must build their own apps.
Not so.
In today's mobile-centric and cloud-based world, this approach is largely outdated. With highly capable and flexible cloud services that offer their own APIs and SDKs, it's easy to take existing products, link them and devise solutions in a much shorter time. The core need here is to truly understand the workflows of users.
There are also apps that companies can now roll out with minimal customization. Things like Concur, the cloud-based expense management solution, ADP or even Google's suite of tools are pretty much fully formed solutions that easily fit into a mobile app strategy; there's no need to put in the work of developing anew when existing tools are available and updated regularly.
Starting out too big
When it comes to deciding which apps to deploy, think small. That helps avoid a big mistake, with big being the operative word. Many organizations try to shift their most important and widely used apps to mobile (and the cloud) first. Or they try to develop too many apps at the same time. Or they do both. This is a mistake. It's important to start small and simple. That way developers, the IT team and end users can get their feet wet with the changes being made, learn as they go, and meet challenges in small-scale situations -- not in mission-critical systems.
The other advantage is that you can notch an easy win. If you pick a problem that's relatively simple to solve, one that will make the lives of users much better, you get the experience you need while showing you can manage the development of apps and the transition to a mobile-first business approach. That earns you political capital that can be crucial in getting support (and funding) for future and larger projects.
Not involving users
The consumerization-of-IT trend involves letting users take technology into their own hands to craft solutions and workflows on their own. This makes it crucial to recognize that the end users of enterprise apps are the most important stakeholders in every app project. The reason is simple: if an app doesn't fit their needs, or has a kludgy user experience, users won't use it. Worse yet, they'll find solutions that may be less secure and unable to integrate with other solutions.
Involving users can be as simple as inviting them to a meeting or two. You need to understand their job functions, requirements, pain points (that you should try to resolve) and workflows. Shadowing users for a few days or a week, asking questions, and being completely engaged with them will allow you to truly understand what an app needs to do.
Another way to understand what a mobile app should do is to look at the original specs and requirements of its existing desktop counterpart (if one exists). These notes, and institutional knowledge, can yield an even deeper understanding of what's needed -- and it may even lead you to develop an app much more effectively than by simply seeing how users work.
Not ensuring the right backend/infrastructure is in place
This mistake is often made with any app deployment, whether for mobile, desktop or the web. Regardless of the backend systems your app(s) will need to connect to -- on premise, private cloud, public cloud, external vendor, etc. -- you need to be certain it can handle the load of new users. You also need to be certain that your wireless infrastructure is robust enough to handle additional the traffic that an app will generate. As with any such deployment, one of the best options is a phased rollout where discreet groups of users receive access in separate periods. That allows you to view traffic needs and tweak infrastructure as you go.
Not testing across devices
This mistake is often a particular challenge. When developing an app or considering an existing product for deployment, testing is critical. In the desktop era, this was pretty easy. You had a set number of workstation configurations that IT had complete control over. Simply test on the appropriate desktops and you were good.
Mobile and BYOD have turned that approach on its head. Now, companies have to deal with a range of devices with varying hardware specs, screen sizes, OS versions, user-installed apps, carriers and other networks, and accessories. In the case of BYOD and mixed-use devices, you also need to contend with personal data being on devices, as well as user behavior. Testing has become more critical.
This problem is particularly acute with Android, which is one reason iOS is more common in enterprise environments. The fragmentation of the Android OS with a wide range of versions in use (you can still find devices shipping with Android KitKat) as well as manufacturer and carrier customizations and a rather draconian update process that complicate things. There are thousands of differing Android variations in use, meaning your app may work great on more common devices -- say, the Pixel or the latest Galaxy phones -- but fail to run on some older or low-end devices.
iOS is a bit less challenging because there is a limited set of devices and Apple directly provides OS updates, ensuring that the vast majority of iPhones and iPads are running the latest version. (At this week's WWDC, Apple announced that 86% of iOS devices are already running iOS 10.) Still, there can be issues with some older Apple devices with differing screen sizes and hardware.
Then there are mobile platforms like Windows 10 Mobile or even just Windows 10 tablets. While small in numbers, testing software on them still makes sense if at all possible.
The test hardware should ideally include every current and recent flagship phone, a selection of the most common mid-range devices from major manufacturers, and if possible a handful of low-end devices. The mix should include a range of OS versions dating back over the past three years as well as different hardware configurations.
Putting it all together
Enterprise apps are an exciting prospect with enormous potential for almost every organization. They offer new and better ways to accomplish tasks, increase efficiency and productivity, and create better engagement for employees and customers. But they present a challenge. If they don't function well or meet the needs of users, they risk alienating employees and executives. Avoiding these five mistakes ensures you're on the right track to a successful app strategy.