 |
 |
| Simon Morris |
Simon Morris, vice president of marketing at ClickSoftware, with the final five common mistakes to avoid when selecting and deploying a mobile solution.
Research firm IDC predicts that some 1.2 billion workers will be using mobile enterprise tools by 2011, representing roughly a third of the total global workforce (February 2010). Some of these people are almost exclusively mobile, whereas some will only occasionally use mobile enterprise tools.
Whatever the case, there are very few who would argue against the fact that investing in mobility has the potential to raise productivity, accessibility and visibility.
Here, we take a look at what common mistakes are often made in selecting and deploying a mobile solution, and how to avoid them.
Planning a mobile project with only one phase
As basic as it may sound, planning the mobile project to be done in a single phase means you will not have a second chance to fix things, no planned time to evaluate real user feedback, and a much riskier project.
From my experience, projects with three to four phases have the tendency to receive a higher satisfaction rate at the end. Even if the entire project take longer to fully rollout.
Tip#6: Plan a project with a few phases; assign enough users in early phases to ensure you get the most feedback.
Creating an inconsistent mobile environment
A mobile application integrates with several backend systems. Consequently, the complexity of building a mobile solution is always high. It should interact with the CRM/ERP, parts management, asset management, GIS, HR, and more.
It's very easy to get lost in the forest of features and functions and create an inconsistent beast, where every feature behaves differently, the workflows are not well defined and the entire user experience is problematic.
Tip#7: When integrating so many capabilities into one application, ensure consistency and a single framework, otherwise things will become too messy and buggy in the end.
Expecting too much out of the technologies
A funny thing happens when switching from the evaluation to the implementation process. The scenarios, workflows and structured requirements that were all used to examine the different vendors, turn into detailed features and functional items to be implemented by the vendor.
It's very easy to get lost in the endless lists of features. This may result in some perfect modules that are not properly tuned to work together.
Tip#9: When testing the mobile application, do not only test features and modules. Test complete workflows, scenarios, used with wireless networks and real devices, in the actual working environment.
Leaving security to the end
I promised myself I would not fall for this one and I just did...
Security is so important for mobile systems, yet, for many organisations, it is often an afterthough.
For some reason, after evaluating and investigating all security aspects, the following happens; the system is built, configured and tested, all in a few testing environments and a week or two before the go-live date. Then someone tries to set it up on the production machines, and surprise, surprise, nothing works.
Production systems always have additional complexity that relates to security, scalability, legacy systems and more. It's naïve to think everything will just work smoothly.
Tip#10: When planning a mobile project, make sure to have a specific milestone for building a secured environment that will simulate the production farm. It has a better chance to uncover and solve problems in advance that would otherwise occur at the last minute just before the go-live.
ClickSoftware is a provider of automated workforce management and optimisation solutions for every size of field service business. http://www.clicksoftware.com/