Business Process Optimization for Mobile Handheld PDAs

How do you improve upon a paper forms-based business process? The plumber, electrician and appliance repair person have been using a clipboard with paper work orders and service tickets forms forever. How do you improve upon this tried and true process? Let me provide some ideas for your consideration:

1. The office can wirelessly dispatch new work orders directly to a handheld device
2. Small service companies, with an owner/operator, can take calls from customers while on the road and enter new work orders on their mobile PDA phones. These work orders can be synchronized with the office and dispatched immediately to other service technicians
3. Wireless work orders can be integrated straight into office database applications and accounting systems so there is no additional paperwork to be entered
4. The wireless work orders can contain all the information on the customer, warranties, equipment type and model, history of the account, driving directions, etc. No need to call the service technician on the phone and dictate all the information.
5. Re-prioritize work orders automatically from the office to the mobile handheld device
6. Print invoices directly from the handheld using a mobile printer and give to the customer
7. Get a digital signature from the customer on the electronic work order
8. Take digital pictures of the work both before and after and integrate with the wireless work order
9. Get an automatic date and time stamp on the work order when it is opened at the customer's site
10. Track the time it took to complete the work - record for job scheduling and cost analysis
11. Wirelessly synchronize completed work orders directly to the office accounting system for instant invoicing.
12. Send parts orders directly to the office via the mobile handheld for quick processing
13. Parts and inventory can be queried from the field. Do we have the needed part in stock either in the office or another van? If it is available in another van, where is the van? Can you drive over and retrieve it?
14. If you implement a GPS system on your handheld computers, the office can see the location of all service technicians and optimize job dispatch
15. The service technician can schedule future service visits on his mobile handheld computer and synchronize back to the office
16. The service technician can estimate a new job on the handheld computer and sync this information back to the office for reference and database integration
17. The service technician can record parts, equipment and services sales on his handheld for immediate syncing with the office
18. The service technician can view past work orders on his handheld device for improved customer service

I heard a story about why Sears Service Technicians implemented a wireless work order system in their service vans. They wanted to be able to increase the sales of warranties, parts and other appliances while at the customer site. The results are said to be impressive. There is no better time to sell additional services, parts, warranties and other products than when you are with a happy customer in their home. The wireless mobile computer enabled them to fill out product and service orders at the point of work, reference online product catalogs, check shipping status and a variety of other customer friendly activities.

MobileDataforce develops wireless work order systems. If you would like to discuss your business and your requirements please contact us here or visit our website.

Saving Time Developing Mobile Software for Handheld PDAs

It is important to recognize that mobile software applications for handheld PDAs are not just developed by 1 person in a dark room with a computer. The business unit manager can order a mobile software application to be developed, but someone must design it, develop it, test it and approve it. Do you really want the programmer to complete the entire application on his/her own, or do you want a person who understands the business to be involved? Here are some considerations:

1. Do you want the mobile software application to look exactly like the paper form in use today? If you don't specify differently, the programmer may design it to look like a small piece of paper on a mobile handheld PDA.


2. Do you want the programmer to dictate your business process, or do you want to tell the programmer how the business process should work?


3. Do you want the programmer to tell the field workers how, when and where they should sync the mobile application, or do you want the business users to tell the programmer.


4. Do you want the programmer to select the mobile handheld PDAs, or do you want the business unit to describe their requirements to the programmer?


5. Do you want the programmer to tell the business unit when the mobile software application is complete and final, or do you want to test it and approve it?

Most of these questions have obvious answers. The business unit, the organization that will benefit or suffer from the mobile application, needs to have active input into the design, development, testing, deployment and support of the application. It is not a 1 programmer job.

The problem many development projects suffer from is this active involvement was not anticipated or planned, therefore, it either does not happen or comes as an inconvenient surprise. However, you have now been warned in advance so this will not happen on your project, right?

You Should Not Develop a Mobile Application - Just Because You Can

We often receive calls from software developers asking about our mobile software development environment. The developers often ask the question, "Why should I use your development platform when I can develop my own mobile software application for handheld PDAs?" That is a good and fair question. I will usually follow their questions with my own:

1. How many mobile software applications have you already designed, developed, deployed and supported successfully for handheld PDAs? Is your employer comfortable with having you learn on the job or are they risk adverse? Are they willing to be patient with your learning curve? If it takes you 4 months longer to develop your own, does the business suffer?
2. Have you created a full synchronization engine successfully in the past? This is very complicated and software companies like MobileDataforce have spent years optimizing these. What are the chances you will get it right and optimized on the very first project?
3. Do you have experience developing and configuring a variety of connectivity options such as cradle sync, wireless sync, satellite sync, bluetooth, etc.? Does the business manager know which one is needed in every case? Should you develop one, or develop multiple methods? Are the business requirements likely to change in the next 3 years?
4. Have you developed a full database integration manager for mobile solutions? Do you need an API or will your DBA allow you to directly populate the database? If you can directly populate the database, then the data better be validated in the mobile software application on the handheld pc. Did you set aside time for that?
5. Do you have experience designing scalable and reliable mobile applications? This is simply an experience thing. You don't know what you don't know.
6. Do you have support for a Pocket PC 2003, Win CE, Microsoft Mobile 5 & 6? How are you going to upgrade and support next year's mobile OS from Microsoft? Is this built into your project plan and budget?
7. Have you developed mobile applications that run on a large variety of different mobile handheld devices? This takes a lot of work and thought. Every week new mobile handheld devices are being delivered with new technologies and add-on components. The device selected today, will likely not be available next year at this time. How do you keep current?
8. Do you have experience developing interfaces for third party hardware? Mobile applications often need additional third party technology integration like bar code scanners, RFID, GPS, Digital Cameras, etc.
9. Have you thought through and developed dashboards for managing mobile application security, users, applications publishing, etc?
10. Do you have a development environment set up exclusively for mobile applications development that may include short-cuts, libraries, screen designs and scripts?
11. Do you have experience creating a helpdesk dashboard for sync logs, users, applications, device management, etc.?

Most often the developer was only interested in creating the screens for the mobile application, not a complete mobile application platform and support system. They had not considered the full end-to-end solution requirements when volunteering to develop a mobile handheld application.

Now the NMS 5000 Rugged Tablet PC I Like!

I came across this ruggedized tablet pc today and am a fan. I love the right hand buttons for short-cuts. Perhaps because I am right handed - sorry left handers. Many field data collection projects involve maps, blueprints and other files that benefit from a larger screen in a rugged case.

NMS 5000

The NMS 5000 provides data collection technology ideal in several applications including field service, military, industrial / manufacturing, medical, parking management, public safety, utility services and retail. More...

MobileDataforce's software for field data collection can be found here.

Chossing Between a Rugged PDA or Industrial Grade Handheld?

My sales team is asked hourly for recommendations for mobile handheld computers, smartphones and PDAs. The customer is always looking for the most cost effective solution. Cost effective must include value, reliability, usability, flexibility, expandability and much more - the total cost of ownership. There is a document you can download here that lists all the questions you need to ask before making the purchase.

I was reading about the industrial grade handheld PDA M3 today and their description points to some of the rugged features that users need to consider.

M3 Industrial PDA M3’s rugged design and IP54-rated sealing ensures continued use and uptime by protecting against dust, moisture and extreme temperatures (-20°C ~ 50°C), And, whether working inside or out, it has a drop spec of 1.5m to concrete across vast temperature ranges, reducing equipment and maintenance costs.More...

A lot of your decision needs to be based upon what kind of mobile software application you are going to use and what operating system it requires. Do you need a large screen to read drawings, blueprints and maps, or a simple data form?

Microsoft's Mobile Software Industry Growth Projections

Microsoft and Palm talk about the latest trends in the mobile software, smartphone and handheld PDA industry in this webinar.

New Palm Treo 500v Smartphone

Palm has released a new version of the popular Treo series Smartphone - Palm Treo 500v. It sounds like it will be available in Europe in October and available from Vodafone. It will be using Windows Mobile 6.0. I think the Palm OS may be going away soon in favor of Windows Mobile for PDAs.

The Palm Treo 500v and the Palm 750w (available in the USA from AT&T) are good examples of "convergent" devices. Devices that can handle both your work and your play. For companies like MobileDataforce, devices like these mean more business owners, managers and field technicians will be using mobile devices capable of handling mobile field service applications. Good job Palm!

Don't Start a Mobile Software Development Project Yet

In Steven McConnell's book, "Code Complete" he describes why a person should not jump right in and start developing code for a mobile software solution for use on handheld PDAs on the first day that the business thinks it is a good idea. Often business motivations help drive a sense of urgency to start coding a software application immediately, but there are also business motivations NOT to start today. Coding without gathering ALL the requirements and architecting the system has a high cost.

Here is an excerpt from McConnell's book that is very interesting and true:

Explicit requirements help to ensure that the user rather than the programmer drives the system’s functionality. If the requirements are explicit, the user can review them and agree to them. If they’re not, the programmer usually ends up making requirements decisions during programming. Explicit requirements keep you from guessing what the user wants.

Explicit requirements also help to avoid arguments. You decide on the scope of the system before you begin programming. If you have a disagreement with an other programmer about what the program is supposed to do, you can resolve it by looking at the written requirements.

Paying attention to requirements helps to minimize changes to a system after development begins. If you find a coding error during coding, you change a few lines of code and work goes on. If you find a requirements error during coding, you have to alter the design to meet the changed requirement. You might have to throw away part of the old design, and because it has to accommodate code that’s already written, the new design will take longer than it would have in the first place. You also have to discard code and test cases affected by the requirement change and write new code and test cases. Even code that’s otherwise unaffected must be retested so that you can be sure the changes in other areas haven’t introduced any new errors.

...Data from numerous organizations indicates that on large projects an error in requirements detected during the architecture stage is typically 3 times as expensive to correct as it would be if it were detected during the requirements stage. If detected during coding, it’s 5-10 times as expensive; during system test, 10 times; and post-release, a whopping 10-100 times as expensive as it would be if it were detected during requirements development. On smaller projects with lower administrative costs, the multiplier post-release is closer to 5-10 than 100 (Boehm and Turner 2004).

McConnell lists 5 steps in the software development process:

1. Requirements
2. Architecture
3. Coding
4. System Test
5. Post-release

There is simply NO way to bypass these steps for the purpose of saving time and money. If there is an urgent need for the mobile software solution, then there needs to be an urgent need to define the requirements, and architect the system so coding can begin.

An Interesting ROI for Mobilizing Business Processes Using PDAs and Handhelds

Here are 2 new and unusual ROIs (return on investment)that came in this week for a mobile solutions customer of MobileDataforce's.

1. They don't want their inspectors taking up parking spaces at the office. The parking space is limited so they would rather synchronize data out to the mobile inspectors than have them come to the office.


2. They don't have anymore office space for the inspectors. They want them to work from the field.

I had never considered these 2 reasons on my article entitled 28 Reasons to Mobilize that is available to download. Make that 30 Reasons to Mobilize.

Why Do Some Companies Use Mobile Software and Others Don't?

Daily we receive calls from companies wishing to use mobile software on handheld PDAs for their work orders, inspections, asset tracking or delivery services. Although we receive many calls, these companies are unique. For every company that calls my mobile software solutions team, many others in the same markets regretfully do not. Is it because my marketing budget is finite and they simply don't know MobileDataforce exists? Perhaps, but I am inclined to think there is more to the story.

The companies calling us are dissatisfied. They are dissatisfied with their existing business processes. They see inefficiencies and they are annoyed. They have seen the capabilities of mobile solutions and recognize what they mean to their business and profit margins. They are focused on growth and business process improvement. They have ambitions to accomplish more, capture more profits and to improve customer service. They call my team with questions like these:

• How can I put a work order solution on my Palm Treo 750?


• How can I dispatch a work order to my mobile device?


• How can I accomplish instant invoicing?


• How can I take digital photos of my work?


• How can I get "proof-of-delivery" using a mobile handheld PDA?


• How can I take these paper forms and convert them to mobile solutions?


• My paper process is costing me $234,000 per year. Can I mobilize this process?