Divide and be conquered – the pitfalls of “there’s an app for that!” in enterprise mobility
Author: Israel Beniaminy
As has been pointed out very often (see our recent post on html 5), consumer mobility is causing immense, quick and decisive changes in enterprise mobility. This is certainly a force for good: Across all business roles, people are waking up to ask “why can’t our enterprise software be as accessible, as easy to use, and as friendly as the apps I use for banking, social interaction, online purchasing etc.?”. They understand if they had such enterprise apps, it wouldn’t just make their lives and jobs easier (a worthy goal in itself): to mention just a few benefits for their employer, such apps will increase workforce agility, effectiveness and productivity; and will contribute to attracting and retaining highly skilled and motivated workers.
Some companies are quick to grasp the opportunity, identifying key business processes which would benefit most from mobilization, prioritizing them, and buying or developing an app for each such process. After all, nobody can do everything at once, so a healthy dose of dividing the “mobilization project” into phases not only makes sense – it is usually the only way to go. This common truth is even more persuasive for mobility, where the consumer world has guided our thinking to the “there’s an app for that!” idea: Take a simple need, find or create a simple app to address it, and move on to the next need and the next app – problem solved!
Well, there’s a catch. Enterprises should learn from consumers, but not blindly: they should take the good parts of the lessons they learn, an adapt them to the enterprise situation.
Here’s why: Picking an app for each task ignores a central difference between consumer mobility and enterprise mobility. As an individual, my tasks are free-form and typically involve just me or a close group of family and friends, so the ideas of “workflow” and “business process” is quite alien to how I go about these tasks. Sure, one task may interact with another – maybe I need to get to the ATM before I go to the theater; and one of my tasks may interact with somebody else’s tasks – maybe my wife and I each need to rearrange our schedules so we can get to the theater on time. Still, there does not exist a central back-office system where all these tasks and steps are planned, budgeted, coordinated, approved and monitored. Therefore, I have no problem with using one app for managing my calendar, another to find a nearby ATM and yet another to find good seats at the theater. An app for this, and app for that, and an app for yet something else – it’s good for my individual needs. Yes, it would be nice if buying theater tickets would ask if I wanted to mark the time on my calendar, but I can do without such features.
But is it a good way to run a business?
Consider a common example for a simple enterprise app: Vacation approval. Say Bob wants to take a day off next Tuesday. He touches the icon for the vacation approval app, selects the requested timing, possibly adds a few comments, and submits his request. Alice, Bob’s manager, gets an alert that prompts her to open the same app, where she sees Bob’s request. Assuming all is well, she touches the “Approve” icon and everything has been done, in the friendliest and most efficient manner. We can also assume the app has a back-end component that sends this information to the HR (Human Resources) back-office system so that Bob’s day off is properly accounted for.
If this picture initially seems bright and rosy to you, you’re not alone. But you might change your mind if you focus on the details: When you pictured Alice making the approval decision, what did you imagine her doing? Maybe she would first want to look at Bob’s currently scheduled tasks and see whether she can postpone or re-assign those tasks. Maybe she can deal with tasks already assigned to Bob, but if she looked at the forecasted workload she would see that next Tuesday is expected to be a very busy day, even though the specific tasks for that day aren’t yet known – for example, maybe next Monday is a holiday, and analytics have found that when people return from such holidays they often call in with urgent tasks. Depending on the business, there may be quite a few other things Alice needs to check before making the approval, and the simple app I’ve described does nothing to help her, because that is out of the scope of “vacation approval” when that process is considered as stand-alone (obviously, she’ll also want to check how many days off Bob has already used, but that’s within the process scope so let’s be generous and assume that the app already supports it). That’s the whole point: Is the vacation approval process really stand-alone?
Let’s take the question how will Alice check Bob’s Tuesday tasks and re-assign them to others. Can we say yet again “there’s an app for that”? Let’s try: Imagine Alice opening the planning app (possibly a project management app or a task scheduling app) to check and re-assign the tasks. To do that, she’ll need to specify at least two things: select Bob’s name, and select next Tuesday. This is because she’s in another app, not retaining the context of Bob’s request that she saw in the vacation approval app. Once Alice completes reviewing and handling the effects of Bob’s day off, she’ll need to return to the vacation approval app, select Bob’s request again, since the context has once again been lost, and approve.
This example should teach us that, when dealing with enterprise mobility, separating apps runs up against the fact that you often need to use several apps in the same context. Jumping around between apps, re-entering the same information and selection, is at best inefficient, and it can be worse – a source for errors and broken processes.
I chose a simple example to start with, but it can and does get worse. Much worse. Think of a sales person, Charlie, standing in front of a customer. Charlie’s main workhorse app is for taking orders and getting the customer’s signature – a fine and useful app. Now, what happens when the customer asks about how the details of billing for a previous purchase? Charlie will exit the order-taking app and bring up the billing app. What if the customer orders some item that requires some installation? Charlie will need to go to the inventory app, to see when the item can be delivered. Then, Charlie will go into the service scheduling app to schedule the installation, as early as possible following the delivery time. In the same way, Charlie might need the shipment-tracking app, or the knowledge management app (to answer some technical question) etc. Can you imagine going through all of this, re-entering the customer name, the item being purchased, the dates and so on? At this point, do we really have a friendly system, or will Charlie prefer to go back to his office computer where there already is a portal that combines all of this functionality into a much smoother workflow? Is this a case where the much-criticized enterprise apps are already better and friendlier than consumer-style apps?
The missing piece is context. If you can contextize all these apps, you’ll really have the best of all worlds.
So, beware of the pitfalls of “there’s an app for that!”. Naturally, it would also be unwise to rush into the other extreme and decide that you want one app that will do it all. Instead, look for an architecture that retains the context of what users are trying to do, within what work process, for what customer etc., and uses the context as you move between apps so that you don’t have to spend all your time re-entering information.
“Divide and conquer” is one of the oldest and best ways of dealing with a challenge, but it has its limits. In this case, selecting separate apps that are oblivious of each other’s presence creates the risk that you’ll be the conquered, not the conqueror. With such risks, it is worthwhile to remember the antidote to “divide and conquer”, which is just as old and just as wise: you and your apps are “insuperable if inseparable”.