Mobile Applications and 69 Enterprise Support Questions

Often the focus of a mobile software project is on gathering the functional requirements, designing, developing and deploying the mobile solution, but little or no advanced planning is given to the question of how to support it once it is deployed. The following list contains many of the questions your IT helpdesk and support department will want and need to know:
  1. Who does the field worker call if there is a mobile device problem?
  2. Who does the field worker call if their mobile application is not synchronizing correctly?
  3. Who trains new employees on how to use the mobile device and application?
  4. If there is a mobile software problem, who fixes it - IT, consultant, contractor, your systems integrator or VAR? How do you get in contact with them?
  5. Who does the field worker call if the mobile application needs edited or upgraded?
  6. If the user downloads a new version of the mobile operating system and the mobile application doesn't work, who will fix it?
  7. How do you prevent mobile users from downloading new software applications that might break the system?
  8. How do you back-up mobile devices so the information is centralized?
  9. Who owns and defines the business process you have mobilized? They may need to approve any changes to the business process.
  10. Who controls the security of the device?
  11. How do you set-up a new user to securely access the enterprise database?
  12. What kinds of security rules must the field user follow?
  13. Do different users have different security profiles?
  14. Is there a standard set of security rules for mobile devices across the enterprise?
  15. Who controls access to the enterprise database application (a DBA)?
  16. Will the Database Administrator allow you to synchronize data directly to their enterprise database application, or do they want a "staging database" or API layer to review all data before it is loaded to the enteprise database application. They will likely be involved in any future changes to the mobile application.
  17. Are synchronizations done in real-time, near-real-time, or batch on a schedule?
  18. Does one mobile device have multiple synchronizing applications? Are they on different schedules or do they synchronize at the same time?
  19. How many different enterprise database applications are synchronizing with a mobile device? If there is a sync problem, how do you know what database applications may be impacted?
  20. If you hire an additional field worker, how do you order an additional mobile device? Whose budget covers this? Who is the vendor? What support plan or insurance plan should be included?
  21. Who decides if the new mobile device needs to be ruggedized or a consumer grade? What level of ruggedness is required for the specific user?
  22. Do different job functions require different devices, carriers and wireless data service plans?
  23. Who decides what brand of mobile devices are going to be the company standard?
  24. Where do you purchase your mobile devices if one breaks or you need to add one to your inventory? Do you have a corporate discount or volume discount agreement?
  25. How do you manage and control the variable costs of using a data plan from a local wireless carrier? What happens if the costs of the data services gets out of control? Who pays for it?
  26. Are the mobile devices or the mobile software solutions under warranty? Where are these contracts stored? Who owns them?
  27. Is there a yearly support contract IT needs to know about? How much? Whose budget?
    What is the account number the warranty is under?
  28. How do you set-up a new data plan for a new user with your wireless carrier? Who does that in the company? What is the account number so you can add subscribers? Whose budget pays for it?
  29. What happens when Microsoft releases a new Windows Mobile operating system and you can only purchase mobile devices with the new OS on them? Who is going to upgrade your mobile software solutions so they work with the new OS?
  30. What happens when the field engineer treks across 2 miles of muddy field to work at a construction site, but the battery on his handheld computer dies about 10 minutes after he gets there? What is the backup battery plan?
  31. What happens when text messages, photos, videos, music, and games claim all the memory on the rugged PDA and the Construction application becomes either too slow or unreliable because of low memory?
  32. How do you know when your mobile workers are synchronizing the latest information? You don't want mobile workers going days without synchronizing their device.
  33. When you send an updated software application to your mobile workers, how do you know who is using the new application and who is still on the old?
  34. How do you disable synchronization on a lost or stolen mobile device?
  35. How do you kill and/or protect your data on the mobile device if it is lost or stolen?
  36. How do you keep track of which workers are using which mobile devices? If there is an operating system update, or firmware update, how do you know who needs it?
  37. What is the process for bringing mobile handhelds into the IT department for repairs and upgrades? Is there a central location, or should various locations be scheduled on specific dates.
  38. If you are taking care of many different mobile field workers and many different mobile devices with a variety of operating systems, wireless carriers and screen sizes, how do you track who gets what?
  39. If you have a project manager that requires visibility to more data than other workers, how do you manage different views on the handheld computer?
  40. Some mobile projects require different levels of security, for different levels of data visibility. How would you manage and track that?
  41. Will your company standardize on 1 mobile operating systems or several (Blackberry, Microsoft Windows Mobile, Palm, Android, iPhone, etc)
  42. Some applications require barcode, RFID, GPS, digital camera and other specialized data collection accessories, while others don't. How does the IT Helpdesk track the brand, version and other details of these accessories?
  43. If a dump truck backs over your supervisor's $1800 ruggedized computer and crushes it into hundreds of unidentifiable pieces, how do you get a replacement out to the supervisor with the exact application and data that is required as quickly as possible?
  44. If a mobile device needs repaired - what is the process for keeping your field workers operating without it? Do you have a stock of spare mobile devices?
  45. Does your mobile device reseller have a replacement program?
  46. How do you deploy new mobile applications to your 1,300 mobile device users? Must they bring all their devices back to the IT department, or can you publish new applications directly to the handheld computer?
  47. How do you support the mobile device, when the user has limited computer knowledge and is sitting on the top of a utility pole? What tools can the IT Helpdesk use to remotely help and diagnose problems?
  48. How do you recognize a defective mobile device that is being shared by 12 different mobile workers? Do you have a method of identifying which problems are being reported on a particular device or are you logging support calls only by users?
  49. What is your process for dispatching work orders to service technicians when they are disconnected or out of range of cellular and wireless networks? A process needs to be defined.
  50. What is your synchronization plan for each mobile worker? Can they sync in the morning and evening at their office desk, or do they need to sync every 5 minutes or in real-time?
  51. What is the synchronization plan for a service technician that rarely has wireless network access? Does it justify a satellite up-link? (Sears Service Technicians use both)
  52. How do you know when information was successfully synchronized with a mobile device in the field? Can you see and determine the success of the synchronization from the IT Helpdesk?
  53. What is an acceptable synchronization time? Is it 20 seconds, 2 minutes, 20 minutes? Does the IT Helpdesk know what times are acceptable so they can consider this when configuring a new user?
  54. Does all data need to be synchronized in real-time, or only some. Product catalogs are an example of updates that may only be needed weekly or monthly?
  55. How much data can be synchronized in a given period of time on the chosen connectivity option? Is that an acceptable speed for the task at hand?
  56. Who determines the hardware requirements that support the mobile application and desired synchronization speeds?
  57. When a new mobile software application is developed, who tests its operating speed on different devices, processors, memory levels and connectivity options to determine what is acceptable and what is not?
  58. When you are updating or reconfiguring an enterprise database, how do you know what mobile applications and mobile users will be impacted by these changes? How do you manage this update process?
  59. How does the IT Helpdesk know which one of the 17 mobile applications on the handheld computer is having a synchronization problem?
  60. If you are supporting 174 work crews and their mobile devices around the globe, how do you know where they are located, and who is responsible for them?
  61. How does the IT Helpdesk know if a mobile device is using a cradle, modem, bluetooth, wireless, USB, satellite or Cellular connection to synchronize? The IT Helpdesk really wants to know before they begin working on the issue.
  62. What wireless carrier, technology and through-put speed is the mobile device using? Is it GPRS, GSM, CDMA, Edge or some other network configuration?
  63. Do you need to stagger the synchronization times? One of my clients had a problem with 300 mobile workers downloading large product catalogs all at the same time each month -the first Monday of the month. This caused a bottleneck and slow downloading times.
  64. What do you do with old and retired mobile handheld devices? Companies like Ryzex buy back old handheld mobile devices and recycle them.
  65. What rugged or semi-rugged cases are required to protect the mobile device?
  66. What add on assessories are supported on the mobile device? Ear pieces, GPS, add-on RFID, barcode scanners? Who supports these and where do you order replacements?
  67. Does the same mobile software application work on rugged mobile handhelds and on mobile consumer devices?
  68. What employees and roles get the different levels of rugged devices?
  69. Do you have a corporate account with a mobile device reseller that will repair all of the different mobile devices or do you work with many different vendors with different support and warranty plans.

All of these questions are very important and need to be answered upfront. If you would like to discuss this subject in more detail please email me.


***********************************************
http://mobileenterprisestrategies.blogspot.com
***********************************************

Advice for Mobile Start-ups and Mobile Developers

There are a lot of business and technical issues to consider and points to ponder if you are developing a mobile software application to use internally or to sell, or are creating a start-up mobile software company. I have a lot of personal experience in this area and have documented much of it in over 475 blog articles on this site.

To save the reader time searching through the entire blog library, I have collected a few of the articles especially relevant to those starting new mobile application projects and new mobile start-ups.

The following link goes to a another blog article that lists many additional resources for mobile start-ups - Mobile Handheld PDAs and Mobile Software Application Resources

If you would like to discuss any of these subjects in more detail, please email me.

***Note, readers can search on specific mobile subjects within these 450 plus articles by using the Blog Search function at the top of the page.
***********************************************
http://mobileenterprisestrategies.blogspot.com/
***********************************************

Mobile Software Application ROIs for Mobile Service Businesses

The ROI (return on investment), in this context, is the term used to describe the value of a mobile software solution relative to the expense of designing, developing and deploying it. If a mobile solution cost $145,000, how do you justify the investment? Management needs to see that their investment will provide a quick and positive return. The following list contains some of the most common justifications for mobilizing business processes:
  1. Eliminate time spent in the office re-typing data collected in the field: Enable field service technicians to synchronize information directly with the office database.
  2. Eliminate time spent on the phone dispatching service tickets or work orders. Both the time of the dispatcher and the time of the service technician: Dispatch electronic service tickets direct from your work order management system in the office with the mobile device of your service technician.
  3. Save time finding each work location: Send driving directions, or links, in the electronic work order that work with the GPS and mapping software in the mobile device.
  4. Avoid the high fuel costs incurred delivering paperwork to the office and picking it up: Synchronize the data direct from the field to the central database application.
  5. Avoid the time cost transporting paperwork from the field to the office: Synchronize the data collected from the field with the push of a button.
  6. Save time and provide better customer service by providing real-time access to enterprise parts, orders, and inventory data while in the field: Enable mobile access to customer history, product documentation, warranty information, inventory information, time sheets, work schedules and much more.
  7. Save time with field data collection by using barcode scanners and barcode labels, or RFID readers and RFID tags on assets: A quick scan with a handheld computer can automatically display all stored information related to the asset for quick review, edits and additions.
  8. Save time and reduce admin costs by creating and scheduling new service tickets direct from the field:
  9. Provide immediate invoicing for faster collections and better cash management: Allow field tech to print the invoice on a mobile printer at the job site.
  10. Save time and postage costs: Print the invoice and leave it with the customer at the job site, rather than wait and bill later from the office.
  11. Document proof of work completed to reduce invoice disputes: Leave a GPS audit trail of where work was performed and include a time and date stamp. Digital photo evidence of before and after work is also useful.
  12. Reduce the introduction of errors: Paper based systems are inherently slow and error prone due to human interaction, copying and re-typing. The more human hands that touch a paper form and add or edit data, the more chances that errors can be introduced to the data which will cause invoice disputes, inaccurate records and confusion.
  13. Reduce administrative costs by ensuring complete data is sent from the field, as incomplete or inaccurate field data can take hours of work to track down and correct: Send data from the field and ensure it is complete with data integrity features on the mobile handheld computers and rugged PDAs.
  14. Reduce administrative costs by avoiding errors and misinterpretations due to poor or misread handwriting: Create electronic forms with pre-made options, check boxes and lists, and by using onscreen digital keyboards.
  15. Reduce administrative costs by ensuring the accuracy of data: Validate answers in the mobile software application on the handheld PDA.
  16. Reduce time on the phone and dangerous note taking while driving: Push documents directly from the office to the handheld.
  17. Save time and fuel by providing electronic dispatch and least cost routing: Use vehicle and/or handheld GPS tracking to view your workforce locations. Handheld computers with GPS functionality can integrate with GIS and display the location of the field worker to help managers better organize service responses.
  18. Save time by developing computation and analysis features on the rugged handheld in the field: Programmed analytics can help field users make quicker and more accurate decisions and job estimates.
  19. Save time in the field by automating business processes in the mobile software: Mobile application can be configured to perform all kinds of automated business functions, queries, computations and analytics.
  20. Enforce quality work habits: Automate “best practices” into your mobile software application and provide visibility to managers.
  21. Automate quality and best practices - Activate the appropriate business process based upon the data entered: A specific answer can trigger the required business process.
  22. Reduce inventory loss - Avoid undocumented inventory usage and unbilled time: Enforce real time data entry before clock out or work order completion.
  23. Improve job estimates: Require clock in and clock out on work to document and analyze the accuracy of work estimates.
  24. Improve technician training: Train new service technicians and inspectors with audio memos or video clips in the handheld computer application.
  25. Reduce disputes by documenting deliveries and work with digital signatures, date and time stamps and barcode scanners on the handheld computer.
  26. Save travel time and fuel cost: Query available inventory in nearby company vehicles.
  27. Increase profit per customer: Use information on handheld computers to up-sell more products and services while onsite with the customer.
  28. Provider quicker and more accurate estimates: Query latest shipping status, schedules or inventory levels via handheld computers while onsite with customer.
  29. Increase warranty revenues: Include updated customer information on the handheld computer so the service technician can sell warranty and maintenance plans, new products and upgrades.
These are just some of the common areas where enterprise mobile applications have been found to provide significant value. The issues and costs of designing, developing and deploying the mobile software applications and handheld computers are discussed more in this article.

If you would like to discuss this subject in more detail please email me.
***********************************************
http://mobileenterprisestrategies.blogspot.com/
***********************************************

Mobile Software SDKs and Toolkits for Handheld PDAs and Smart Phones

In the recent article by Peter Wayner of InfoWorld called iPhone development tools that work the way you do, he describes the value of using a mobile application SDK or framework. He lists 4 new toolkits to help mobile application developers develop applications faster for use on handheld PDAs and Smart phones. This is a market in which I am intimately familiar.

The challenge with the market for mobile application frameworks and SDKs is that very few developers want to spend money on an SDK from a small vendor, and even fewer companies want SDKs or are willing to fund long term custom development and support projects internally. Companies want a finished product that works with their ERPs, database and accounting applications. They don't want to invest in a non-standard mobile framework. They want mobile extensions to their enterprise applications. SAP is addressing this with their NetWeaver based mobile infrastructure. This provides SAP users with a standardized method for extending their applications out to mobile devices, but it does not address how to develop the mobile application code. This theoretically creates an opportunity for mobile SDK vendors.

Appforge and Dexterra are two very BIG examples of how challenging it is to be a successful vendor of mobile application frameworks and SDKs. It is yet to be proven that there can be a successful business model as the author of these mobile application frameworks, unless you are a giant like Microsoft or Apple. Dexterra bet the house that Microsoft would acquire them and they lost.

Now, it is true that to make these finished mobile software applications, there is a need for powerful mobile SDKs, but these SDKs are very costly to development and there is yet to be a good and proven business model for small independent vendors of such.

Some vendors of mobile application frameworks want to sell you a toolkit and then charge you a license fee for every mobile device you deploy on. This is not a good model, unless the application is an off-the-shelf mobile application. It makes sense to pay for syncing technology and mobile databases, but a per deployment model for code that you create is hard to swallow.

The biggest challenge vendors of mobile application frameworks and mobile SDKs face is getting the economies of scale that all software companies seek. Who is the real market? Developers? They seek to work in the sexy high profile technologies from the big name companies so they can pad their resumes. They do not want to take a chance on learning an SDK from a very small company that no one knows and they are unlikely able to leverage in the future. They may use an SDK to deliver their cool mobile application, but there is simply not enough of these developers willing to buy your SDK for significant amounts of money to be profitable.

Does the IT department in a company want to buy your SDK, a few but not enough to build a profitable long term software business as an SDK vendor. Again, companies will always seek a finished mobile application that extends their internal IT investment. If SAP has a mobile framework, they want that. If SAP didn't have the mobile extension, then the company would want a finished mobile application that is already integrated with SAP.

In summary, there are many examples of companies developing very cool mobile SDKs and mobile frameworks, but very few with successful business models. Companies want to extend internal applications with mobile extensions developed by the owner of their internal applications. In the event there are no mobile extensions from their key vendor, then they want a finished mobile application that is pre-integrated with their ERP or back-office applications. SDKs are cool, but a successful business model remains elusive.


***********************************************
http://mobileenterprisestrategies.blogspot.com/
***********************************************

Hosted or Non-hosted Mobile Software Applications for Handheld PDAs and Smart Phones

Many companies have asked whether a hosted or non-hosted enterprise mobile software application would be best for them. The answer may be best determined by the following questions:
  1. Is the enterprise software application in the office that you want to communicate with, via mobile handhelds, an off-the-shelf application like SAP, SAGE, MS Dynamics or Quickbooks?
  2. Is the mobile software application simply a mobile front end (GUI) to the back-office application? Does it do basically the same thing you would do on the office application, but in a mobile environment?

If the answer is NO to any of the above, then you are into a custom development environment that is difficult to support in a hosted model. Companies that host applications need volume and reusability. Custom projects may be uploaded to a hosted data center, but there is no business case for the software vendor/developer to pursue this as a business model. However, if the mobile software application is custom, but the database application that it synchronizes with is sold as an off-the-shelf application, then there may be a business case.

Here is a real life scenario. SAP ERP does not handle work orders or service tickets well if they are not associated with a pre-approved purchase order. This is a problem in the oil fields as contractors and service technicians are often called to perform unanticipated work to fix or repair items. Since SAP does not like to receive unexpected invoices, Field Service software vendors have responded to this need by developing applications that convert these unexpected invoices into acceptable SAP formats that are integrated with SAP using standard integrations. These same vendors have created mobile work order applications that synchronize with their work order management systems. They have a standardized model that can be sold in a hosted environment.

Since the work order management application was an off-the-shelf software package, with a standardized integration to SAP, it could be offered in a hosted environment with a good business model.

If the work order management system was custom, and the back-office application or ERP was custom, then the mobile software application would need to be custom and there is no efficiencies in this scenario for a hosted solution.

***********************************************
http://mobileenterprisestrategies.blogspot.com/
***********************************************

Interviews with Kevin Benedict