Mobile is a word, which we use a lot at Integrated Change. For good reason too as this is one of our key service offerings.
In a recent presentation to business leaders we asked the audience what springs to mind when I use this term. The vast majority of people said the handset or the device. They would be right of course but here at Integrated Change, we think about the user behind the device, the technology piece comes much later.
Now, this user can be Joe Public (the consumer) or the user behind the device could be one of your employees. In this post, we will concentrate on the second aspect of this statement – the employee. For this is what Enterprise Mobility is all about and if we want to keep it simple and we should, then lets refer to Enterprise Mobility as Mobile apps for employees. To help you navigate through this minefield, we will describe to you what we call the Hierarchical Enterprise Mobility Structure, or HEMS for short. So lets begin.
The company journey
Before we begin, it’s important to be clear that whether you like it or not, your staff are bringing in their consumer devices, such as smartphones into your work environment. This is nothing new. It has been happening for several years. We brought our feature phones into work then our multimedia devices, then our laptops and now our smartphones.
The difference in the later is the sheer capability and ‘rich toolkit in your pocket’ that a smartphone delivers. They are relatively inexpensive and are now becoming ubiquitous. In the UK, smartphone penetration is at 65% and will only set to rise.
In a recent survey of US and UK enterprises, Antenna Software found that 60% of respondents are currently working on a mobile app for employees, up from only 42% last year whilst Gartner predicts that 70% of professionals will conduct their work on a personal smart device by 2018.
Companies are now realising that mobile can play an important role in the workplace, fuelled by the development of mobile apps for employees. When you think about the list it’s actually quite extensive and here are just a few suggestions
Field sales –
-Converting product catalogues into feature rich, interactive client sales tools.
-Keep employees updated via push messaging direct to the device – sales incentives, product updates, training dates, new wins.
-3D demo’s and live video conferencing with remote technical teams.
-Provide sales staff with the up-to-date real-time statistics and literature.
-Generating an order form instantly and obtaining a client signature on the device.
-Integration of sales forecasting, pipeline management and CRM systems.
Maintenance engineers –
-Logging and tracking of equipment failures.
-Ordering of parts on the go.
-Checking and Tracking of parts on the go.
-Geo-fence the areas engineers operate within and send them new jobs based on their location via push messaging.
-GPS tracking of engineers and delivery schedules.
-Housing inspections and tenancy agreement compliance.
-Drug adherence and interactive, one-2-one patient tools.
-Delivery of clinical advice direct to the device, reducing waiting lists, readmission rates and treatment intervals.
-Promote achievement and motivation through targeted push messaging.
-Monitoring of health indicators and chronic conditions.
-Remote management of patients.
-Live, real-time sales figures.
-Regional sales breakdown and performance.
-Interactive and engaging data presentation.
-Send managers sales reports, update, messages and new sales wins tailored just to their location.
-Live commentary of the figures.
-Equipment delivery notifications.
-Push notifications of sales targets reached.
The list goes on. I am only skimming the surface here.
But before you embark on the journey of creating mobile apps for your employees, there are a number of considerations you need to make. We have defined this as the Hierarchical Enterprise Mobility Structure, or HEMS for short.
1. The Problem
Mobile is an exciting realm. Full of shiny new technology, exciting announcements, new software updates, HD screens and daily market statistics to make your eyes water. It’s all too easy to be lured into this fanfare of excitement but you must be restrained.
No enterprise mobile app project should be entered into without a thorough analysis of the problem you are trying to address. You will only be wasting time and money trying to create a solution that in effect doesn’t do anything.
When we started to become involved in mobile apps for the enterprise and healthcare sectors, the number of companies just wanting an ‘app’ to obtain a tick in the box was extraordinarily high. It’s still the case today but without a problem to solve then surely what is the point? Taking healthcare as a prime example, Juniper research predicts that the remote patient monitoring market could save up to $36 billion by 2018 by introducing mobile health (mhealth).
Start the discussion on productivity and flexibility. Ask your staff, managers, directors, board members and suppliers. Survey and listen to them. Ask your customers and look at current processes. Can improvements be made to them through mobile? To be clear, you must link up the benefits to the ROI when creating mobile apps for employees.
Targeting your efforts on the problem at this early stage will help to focus the development efforts on producing a mobile app that serves its original objective. Dismiss this at your peril.
So, we know what the problem is we are trying to solve and we know that mobile can do this but now we must make sure that we know who will be using it. If you don’t know the profile of the intended user then you should create one. Use the problem as the core driver and identify what the employee’s needs and wants are from the app.
You must be prepared to design for change and product iteration.
If it’s going to be used by multiple departments, make sure you have the user stories logged. A sales person will want something different than somebody in the financial or ordering department. You must conduct all of the aspects that design and User Experience commands and there are many. Without spending dedicated time on the user phase you will only end up spending more time in a continuos development loop and less time concentrating on the Minimum Viable Product. Not a good place to be.
Often overlooked, occasionally disregarded and sometimes dissatisfied with policy control, the user is an important layer within the hierarchy. Just because it’s for internal employee mobile doesn’t mean that the User Experience (UX) should be overlooked. User Experience and design is immensely vital to success.
Antenna Software reports that 43% of companies (1,000 were surveyed from the UK and US) had to extend their design and build cycles to achieve the desired results.
So, UX and design in this layer is critically important which, is driven by a solid understanding of the user. After all we want the employee to be productive and at ease in using the mobile application. We want to make the experience as intuitive as possible and for them to ‘engage’ rather than ‘disengage’.
Get it wrong at this stage and you will lose valuable time in deployment, increase the cost and reduce the chances of strong levels of adoption.
3. Policies & Security
Distinguishing between work and play is a major factor. Like it or not, Bring Your Own Device (BOYD) is here to stay. If it is not supported, it will be done anyway. The reality of the situation is that employees feel comfortable using their own devices; they can be more productive but it must be managed.
Consumer devices are proliferating in the corporate workplace. Enterprise authentication is high on the agenda for companies which points to a BOYD movement emerging.
BOYD has created the need to protect your company information and to manage the process. Gartner predict that 70% of mobile professionals will conduct their work on personal smart devices by 2018 and that 38% of companies plan to stop providing devices to workers by 2016 – rising to 50% by 2017.
Management of the device is more important than the device itself. There are many solutions in existence to help with this. MDM (Mobile Device Management) and EMM (Enterprise Mobile Management) solutions are abundant in the market along with Mobile Containers that will authenticate the device when it’s opened.
Once complete, a secure and encrypted virtual environment. Apple is rumoured to be developing MDM into the inner workings of iOS7. These are just two examples.
How are you going to launch the app and make it available for download? You could use the app store, like Apple’s or Google’s and if you do what will happen if a random stranger comes across the app and downloads it? Do you have password protection to prevent use or will apply for an Enterprise distribution or custom b2b app license with Apple for example? Maybe you are going to create your own app store?
For sure, you need a policy and for sure you need to protect your data. It can sometimes be a struggle between IT departments being seen as an enforcer and wanting control of the data to the employee not feeling that they are being monitored ‘big brother’ style. Companies need to firstly make sure they know where and how their data is stored and then who has access to it and at what levels. Secure integration is key as is the network that it goes over.
However, ownership of the data and the IP once an employee has left introduces a few challenges. As point out by Andi Scott of Incoming Thought, wiping all of the data, including personal data from the device could contravene the Human Rights Act (article 8). Finding the balance between ruling with an iron fist and being too open isn’t easy.
So it isn’t just IT that needs to be involved. Creating a policy and securing your data requires HR involvement too. These stakeholders will have their needs ands goals from the final application so make sure you create a profile them as well when tackling this layer.
Now that the planning layers have been completed, the next layer to approach is development. Firstly mobile development is both an art and a science. This is a complex, bespoke process with many unknowns and variables. Secondly and speaking from experience, you may be wise to build some contingency into your development plans – both cost and time.
If you had completed the previous layers of the hierarchy then you will know what the Minimum Viable Product will be in order to achieve success. You will have validated the user, the environment and the market. You would have addressed any gaps and be clear on the content. You will know what API’s are required to be developed, how will they be integrated and what they should return. You may have also created a BOYD policy or provided handsets to employees. You should also know what the device landscape looks like in your organisation, This will be a catalyst in deciding how device agnostic you want to be.
The costs to develop a mobile application will vary as will the time it takes to complete. This variation can catch companies out so it’s best to fully understand what each development sprint consists of, the time it will take to be delivered and the cost.
From this you can pull out user stories. These will then become feature requests each with a priority (Must, Should, Could) and a time estimate. Throughout this layer, the priority of these tasks may change regularly so be prepared with iterative planning. Then based on the time estimates provided by the development team, you can decide how many of those tasks can be included in the very first development Sprint.
From here, we take everything penciled in for Sprint 1 and make a maximum of 60% of the ‘Musts’ and the rest ‘Shoulds’. This allows for possible over-run on the Musts that could mean some ‘Shoulds’ are not completed.
This may sound familiar to you but what I am describing is the Agile development process. Whilst each developer is different, we deploy this process at Integrated Change as we feel it provides closer engagement with stakeholders, allows for rapid change and focuses on the end user.
Development must incorporate a testing plan. If it doesn’t it will be destined to fail. So keep testing and test again and keep testing. We cannot stress how important this is. You may want to refer to an earlier post we wrote on testing mobile apps before unleashing them onto to your customers here.
Do not move into the development layer unless you have fully completed and re-qualified the previous layers.
It is now time to present to the board. They want to know what has happened to the budget they allocated six months ago. Have we tackled the very first layer from the hierarchy and how can you tell? They don’t care for technical jargon or creative fluff. They want answers and you should be in a position to tell them.
However, this is a long game – mobile is not a quick fix or a sticky plaster and sometimes from high up, it can be seen like that. So set expectations early, put in the metrics that can be reported on and measure the data that is only useful. Remember, extracting the data is the goal but you need to understand it well enough to explain it and equally discount it when its simply not relevant.
If you are in control, then you should be seen as the person who holds the insights. A person who doesn’t deliver reports but tells a story around them.
You should have a good understanding of the metrics and KPI’s at this point from the completion of the early layers. You should also know what each department is looking to measure. For certain, this will be different.
Successful measurement will ensure longevity for the project. It will ensure that everyone is on-board for the right reasons and if they are not, then move back through the early layers to validate why.
The mobile app is out in the field. The app is being used and it’s been measured. It doesn’t mean you must stop. You must keep adapting and changing.
You must have a support framework in place that is both prepared to accept and act upon feedback and help employees when they are stuck. Schedule monthly workshops, feedback sessions and organise new testing panels based on their usage.
This alone can have dramatic effects on adoption rates.
Iteration is a key success factor and it may lead to the identification of other opportunities to improve workflow, staff productivity, moral, and flexibility and client engagement. It may even lead to your company developing your own app store – just for use by your employees.
You may think this sounds outwardly ridiculous but more than 1 in 3 enterprises now have their own app store. They now have more control. They have designed for change and can rapidly adapt.
A common failing of many large organisations is not sharing best practice. Make sure you know the reasons why the project is a success or not (layer 5 will help) and make sure that you share them amongst all stakeholders.
We hope that you have enjoyed some of the points we have raised within this article. Do any of these ring true for you? Are you currently thinking about what mobile can do for your company? If so, we would love to hear from you!