Mobile Application Workflows and SAP ERPs in Australia

As mobile applications become more complex and sophisticated and used by large enterprises there will be an increasing emphasis and requirement for automated mobile workflows and supported ERP business processes. I wrote about mobile application support for ERPs in this article, but today I want to focus on the automated workflow on the mobile handheld computer, Tablet PC or laptop that is used in the field. We have designed, developed and deployed a number of very powerful SAP related mobile applications here in Australia.  ERP business processes and automated workflows have been supported within the four walls of the enterprise for decades, but they often don't extend outside the four walls to the remote jobsite and/or mobile sales and service processes. That is a big problem that needs to be addressed by mobile application vendors.


Let's begin by recognizing that it is often the service technician that is face-to-face with your customers. They are the face and personality of the service company. The actions they take, the words they say, the professionalism they display and the quality of work they perform all impact the customer's perception of your company and their willingness to continue to do business with and refer your business to others. Since the activities that happen in these remote and mobile jobsite environments can have such a big impact on your business, wouldn't it be important that you ensure the best quality work and presentation of your company? This is where automated workflows on your mobile devices comes into effect.

Let me now outline a process that you may want to consider when designing a mobile application for use in the field.

1. Outline the tasks and actions you want each service technician to perform at the customers location. Examples - Greet customer by name, give business card, thank them for their business, ask about animals or children that my be in the work area, interview the customer about the problem, understand the customer's schedule, understand how the customer will pay, is there a warranty or service plan, provide estimate, complete work, get customer's signature, etc.
2. Once all of the "best practices" tasks are identified for a generic service call, complete the same process for the other kinds of service calls you may have. For example: a warranty process has 11 tasks, an annual maintenance call has 16 tasks, an emergency system repair for HVAC equipment has 19 tasks.

Once you have identified and documented these tasks, your mobile application developers can design and develop these workflows to become part of your mobile application. Once in production, these mobile applications can direct and guide each service technician through the specific best practices that the company wants completed in a standardized manner in the field. As a result, quality and professionalism can be standardized into the company's customer interactions.

What does this process look like on a mobile handheld computer?

1. The workflow processes should be a layer in the mobile application that is tied to a specific set of screens that go with the workflow. If the mobile application has multiple workflows, then the first step is for the service technician, or the service ticket itself, to identify which automated workflow is most appropriate for the needed service. This then launches the appropriate process/workflow on the mobile device.
2. If the automated workflow consists of 17 steps/tasks, then this workflow will dictate that mobile form fields including check boxes, radio buttons and data fields are completed in the right order and with valid data entries.
3. If the service technician skips a step an alert sound or pop-up message should guide the service technician to finish the process and continue it in the appropriate manner.
4. Automated scorecards can also be created to monitor the performance of service technicians to the standards and detail any exceptions to the process so they can be analyzed for process improvements over time.
5. Brief customer surveys can also be provided for the mobile handheld computer to tie the customer's opinion of the service provided with the exact service order and service technician. It is great to reward the service technician for work well done.

The mobile workflow process is specific to the role of the user and service performed. A recent report I read said up to 40% of workers are mobile. That represents a lot of remote jobsites and customer interactions. If companies want to ensure a high level of professionalism and quality customer interactions, then means of standardizing those processes need to be employed. As more and more of these mobile workers are equipped with Smart Phones and mobile handheld computers, these processes become easier to deploy.

If you would like to discuss this topic in more detail, please contact me.

48 Questions to Help You Select the Best Mobile Handheld Computers

There are a large number of very good handheld computers, PDAs, Tablet PCs, laptops and Smart Phones to select from, however, the key is to research the business purposes and the environment in which the solution will be used before making a selection.

1. What environment will you be working in - is it hot, cold, wet or dusty?
2. Are there explosive vapors or explosive powders?
3. Is it a clean office environment, or a muddy and rugged outdoors environment?
4. Is the user in and out of vehicles all day?
5. Is your software application focused exclusively on bar code scanning, RFID reading, GPS, or do you need a multi-purpose data collection device?
6. Will the hardware configuration ever need to be changed? Some handhelds can be configured at will; others are locked and can only be used with the original configuration.
7. Will the device be used as a primary phone, or is it focused on data collection?
8. What hardware requirements does your mobile application require?
9. Will the battery last long enough to complete your daily work between charges? Do you need back-up batteries? Can you use batteries purchased at the local market, or are they vendor specific?
10. What is your budget? What does the value of using a handheld computer justify spending?
11. Do you have enough budget to purchase or develop the mobile software and hardware you need?
12. Does your budget only allow for low cost consumer devices?
13. How many replacements(of a consumer device) does it take to equal the cost of a ruggedized handheld?
14. How do you replace broken devices? Can you get a replacement service in 24 hours, or must you wait a week?
15. What kind of support contracts and warranties are available?
16. How long will your new handheld computer be supported, serviced and manufactured by the vendor? Is it near end of life and being discounted for a reason?
17. Can you upgrade the operating system when Microsoft releases a new version of their mobile operating system?
18. Can you use standard laptop data cards in the handheld, or do you need to pay for high priced vendor specific cards?
19. Can you view the screen effectively in the sunlight?
20. Does the bar code scanner work effectively in real-world environment? Some scanners cannot scan effectively through glass or plastic.
21. Is the size and weight of the handheld appropriate for the user and environment?
22. Can your handheld computer support all the add-ons you require at the same time? Some devices can only support a specific number of add-on components so you are forced to choose. Some cannot support both a GPS and a data card at the same time. Some devices cannot support both a bar code scanner and a GPS add-on. This is an important consideration.
23. Do you need only a touch screen and navigation pad, a number pad or a full QWERTY keyboard? This is very important for user acceptance.
24. Is the handheld device also going to be used as a phone? Is a 2 pound industrial grade handheld really a usable phone?
25. Does your low cost consumer grade PDA need a rugged case like the ones Otterbox sells?
26. If you only have a budget for a low cost device, does it support the battery life and add-on components you require?
27. How will the device be transported around a job site? Will it strap to a belt, swing from a shoulder strap, sit in a holster or be mounted to the dashboard of your truck? Does your device support your chosen method?
28. Where is the closest inventory of extra handheld computers? Where is the closest repair depot?
29. Will your vendor loan you a device on trial?
30. Can you rent the handheld if you only need it for a short-term project?
31. Does your vendor take trade-ins on your old handheld computers?
32. Can you get the same exact handheld, under a different brand name for less?
33. How will your handheld computer send data back to the office? Cradle sync, WiFi, bluetooth, wireless data card, GPRS/GSM, CDMA?
34. What size screen do you need? Some devices like the Jett-Eye have a "landscape view" others a "portrait view" many have different sized screens. What do you require?
35. Do you need an integrated digital camera? Do you need a low or high resolution camera and does your device support it?
36. Does a refurbished device from Ryzex make better sense that a new device?
37. Where is your vendor's office? Are they in the neighborhood or on the other side of the planet? Does their location offer you the support and attention you deserve?
38. Does your handheld computer run on the same operating system that your mobile software solutions requires? I have had customers order Windows CE devices for their Windows Mobile application. It did not work.
39. Does your handheld computer come with a pistol grip or other straps that help you avoid dropping it?
40. Can you comfortably hold the device in your handheld and complete your work? Some devices have scanners on the side, on the end or underneath.
41. Can you effectively view the data you need? Some jobs simply require a full keyboard and a full screen for viewing large CAD files or Maps. Does your screen size match your requirements?
42. Where will you store the device when you use the washroom? One of my customers used Tablet PCs and they kept breaking when they slipped off of the sinks in the bathrooms.
43. Does the mobile device you select support the RFID reader you need for distance and accuracy?
44. Does the battery in the mobile handheld last long enough after you have added on all the additional hardware accessories? Each added radio uses more energy.
45. If you have dozens of handheld computers, how will you charge them all at the same time? Do you have a docking station that allows for all of your devices to both charge and synchronize at the same time?
46. Do you need wireless data plans, or does batch synchronziation after each shift work?
47. What wireless carrier and data plan provides the best service and cost for you? Does that wireless carrier support your mobile device?
48. Does the wireless carrier have sufficient coverage for your workers?

If you would like to discuss this topic in more detail please contact us.

11 Steps to a Successful Mobile Software Development Project

Companies here in Australia are looking for ways to do more with less. Many recognize that their mobile workforce is being managed inefficiently and extending business process automation to mobile field workers is becoming a priority. The following 10 steps identify how you can get started automating and mobilizing these business processes.


Step 1 – Understand the ROI/Scope of the Project and Plan Ahead

“What’s the number one reason a mobile project fails?” is a common question we get asked. The answers are that many companies don’t put enough upfront thought into defining the requirements, scheduling testing resources and planning a deployment strategy. The results of these deficiencies are project scope creep, cost overruns, missed deadlines, poor user acceptance and sometimes even complete project failure.

Step 2 – Build a Team of Stakeholders

Make sure the members of your team have the right roles and responsibilities to help the project succeed. Mobile solutions usually tie into other corporate IT assets and business processes, therefore impacted members of your IT department and business units need to be on the project team. In addition, a representative mobile field worker(s) should be included on the project team to provide valuable “real-world” insight.  Don't forget the folks running the IT helpdesk.  They are likely to get called when the mobile handheld PDA runs out of battery, memory or needs repaired or replaced.

Step 3 – Select a Partner That Specializes in Mobility Solutions

Performing successful data synchronization from mobile computing devices can be a challenging and complex task. There are many variables that can affect the results of synchronization. To insure you get your solution done correctly the first time, you need experienced experts in mobile technology. You need technologists in Australia, who specialize in the design, development, deployment and support of enterprise mobile solutions.

Step 4 – Know Your Target Users and Their Environment

During the planning and scoping phase of your mobile project, take time to experience the working environment of your mobile workers and observe the business processes in action. Pay specific attention to how information is collected and exchanged between the office and the mobile workers. These observations can significantly impact the design, development and deployment of a successful project! Evaluate the physical environment of the work. How do moist, cold and dirty environments impact the mobile devices? How does low light or bright sunlight affect visibility of the screen? Can workers read the small text on the PDA screen, or does the text need to be larger? Step 5 – Don’t Underestimate the Complexity of Synchronizing Field Data

Step 5 - Understand the technical challenges and issues

One of the biggest mistakes a project planner or IT department can make is to underestimate how complex data synchronization can be. Part of designing a solid and reliable mobile solution is to select robust synchronization middleware and to spend time designing and testing the data synchronization. Without the right middleware and design your end users could encounter issues such as extra long sync times (hours, not minutes), duplicate records, incomplete data, lost data and even database corruption. Every one of these issues will trickle down to your support department, so designing it right the first time is very important.

Step 6 – Build in Phases

Most successful projects involve a series of phased implementations. Each phase can be developed, tested and implemented in an orderly manner. Once a phase is deployed and proven, additional phases can be layered on top that include more features and added complexity. Remember, the more data requirements that you add the more data you must synchronize, and the longer each synchronization session will take. Only synchronize data that your remote users require in the field. In addition, most mobile devices don’t have the same CPU power or memory as a PC/laptop, so be aware of how the performance of your solution will be affected by a smaller, lower powered device.

Step 7 – Evaluate Your Hardware and Connectivity Needs

The term “mobile devices” can have many different interpretations. Today, laptops, Tablet PC’s, UMPCs, PDAs and Smart phones are all identified with this term. When determining the best mobile device for your project you will want to consider screen size, data storage capacity, security, physical working environment, required hardware accessories such as barcode scanners, GPS, digital cameras, RFID, and the ability to upgrade the device with updated hardware and software components.

How do you connect your mobile device to your enterprise database applications? You have many options including cradle, WiFi, satellite, Bluetooth, wireless, dial-up modems and satellite uplinks to name a few. The method(s) you choose will be affected by how often your mobile workers need to send/receive data. How much data will be transmitted and will they always have connectivity. Study each option, your working environment and consult your mobility partner to make the best selections.

Step 8 – Deploy to a Limited Focus Group, Evaluate and Improve

Once you have completed version 1 of your mobile solution and you are ready to deploy in the real world, roll out your solution to a small group of trusted and motivated users. Define a specific period of time to evaluate the solution, document the results and identify any required changes and improvements. The result of this evaluation should be an improved mobile solution that is ready for wide deployment.

Step 9 – Set and Enforce Hardware and Security Policies

Mobile devices are small computers with the ability to store sensitive corporate data, communicate this data over the Internet and even catch viruses. You must clearly communicate how mobile devices are to be used and for what purpose. Establish and publish guidelines for using mobile devices.

Step 10 – Provide Full Support for Mobile Users

Mobile devices are guaranteed to break. What is your plan for keeping a mobile worker productive and communicating business critical information when their mobile device ceases to function or gets misplaced? These are inevitable issues that are best planned for in advance. Have a plan and a documented back up process.

Step 11 - Select a technology partner that understands your business applications and ERP.

If you use SAP, make sure that the mobile technology partner you select is also an expert in SAP mobile.

If you would like to discuss in more detail please contact us.

SAP and Mobile Software Application Workflows in the Field

The way business processes are designed, implemented and standardized within a company can often mean the difference between success and failure. If often takes years of trial and error, and sometimes flashes of brilliance to come up with just the right business process that will mean success and competitive advantages.

Once the perfect business process is proven it needs to be implemented and automated. Why automated? Because humans are forgetful and have even been known to be from time to time lazy. They want to cut corners and avoid that which is tiresome. Automation enforces and manages the perfect business process.

For years software vendors and ERP developers like SAP have developed applications that help design workflows and workflow engines to run them. These provide the technology infrastructure within the enterprise to automate these business processes and to ensure they are followed, however, once an employee exits the building and drives away in a company van to perform a task remotely, the automated business process breaks down. Suddenly, the business processes that you have spent years perfecting are useless. The employee has broken the "connection" and walked out the door to freedom.

Even today, most mobile field service workers leave the building with a clipboard and a stack of paper service tickets or work orders. How they perform their work, in what order and the processes they utilize in the field are now unsupervised and up for interpretation. The field service technicians often don't much care for the business processes designed by the teams of MBAs in suits at the office. They have their own preferences and opinions about how things should be done, and in remote jobsites who is going to argue?

Many large companies have up to 40% of their employees working remotely and/or in the field on jobsites. How can the SAP or other ERP Business Process Expert design and implement business processes that can be utilized and enforced in mobile and remote locations? This is a challenge worth resolving.

Think about it, a company pays tens of millions of dollars implementing SAP internally and designing business processes and workflows to operate their enterprise. Yet for many services based businesses the money is earned outside the office at remote locations. The location where the customer interaction takes place and where the money is made is often devoid of best in class business process automation.

Mobile applications that need to synchronize with ERPs, should implement mobile workflow support. This requires a client server architecture whereby the mobile client software understands that a workflow or event manager is associated with a particular process and the server also understands that it is both producing and consuming data with the mobile device that is part of an event or workflow. Let me provide a scenario.

A service technician has a ruggded PDA or other mobile device on his belt. He receives an alert that he needs to be dispatched to a jobsite. This initiates a business process with a workflow associated with it. A series of tasks that make up the dispatch and completion of a service ticket are now initiated. The tasks may include:

1. Dispatch receives a service call
2. This initiates a series of tasks including estimating the availability and analyzing the location of all service technicians in the area.
3. Once the nearest available service technician is identified a service dispatch can be sent
4. Service technician confirms availability and accepts the job
5. Least cost and fastest routing information is sent
6. Service technician arrives at the jobsite and pushes a button on his mobile device annoucing his arrival.
7. Arrival message synchronizes with the server workflow or event manager notifying dispatch of his location on site.
8. The workflow may include an inspection, detailed findings, proposed solution, repair and collection of the fee
9. Any parts needed will be automatically deducted from the service vehicle's inventory
10. The workflow can also include sales and marketing activities such as promoting an Annual Service plan or equipment upgrade to the customer
11. The repair is complete, the customer's digital signature is captured and dispatch is notified
12. The service technician is available for another job

In this scenario, the mobile client application using a workflow engine that interacts with the server side application steps the service technician through the various tasks included in the business process. These steps can be directions in the form of alerts, messages, next steps, data fields that require input, and feedback from the dispatch office. Each step of the workflow required input from the service technician to confirm that the step had been completed and this information was in turn synchronized with the server side workflow engine. This enables the best practices supported by the company to be practiced and supervised in the field.

SAP has a solution called Event Manager. It is designed to manage activities happening across a geographically dispersed supply chain. It requires data input via B2B and EDI data communications. Similarly, mobile applications can feed data into a centralized workflow or event management solution that helps support and ensure best practices across remote jobsites.

A workflow engine and a mobile client version of a mobile workflow engine is required by companies that want to standardize business processes in the field where interactions with customers take place and where revenue is earned.

To discuss this subject in more detail or other mobile applications we have implemented in Australia please visit our website or contact us.

SAP ERP and Mobile Applications for IT

The following press release was issued today concerning Redwood Software's announcement of a mobile application for IT staff to receive and respond to real time alert notifications on their mobile devices. This software application works with SAP and other ERP systems. This announcement follows an earlier one that is stated to be the first iPhone business application for enterprise process automation. I am a strong believer that the future of enterprise mobile applications must include a business process automation component as discussed in this article.

MORRISVILLE, NC -- 08/17/09 -- Redwood Software, an industry leader in delivering enterprise and mobile software, today announced immediate availability of the Cronacle Mobile(TM) Alerting Service for the iPhone(TM) and iPod® touch. The Cronacle Mobile Alerting Service enables IT staff to receive and respond to alert notifications in real time on their mobile device. With Redwood's new service, customers' IT departments using SAP® solutions gain unprecedented portability, visibility and control of business processes and the enterprise systems that underlie them.

Today's announcement of the Cronacle Mobile Alerting Service follows Redwood's recent launch of Cronacle Mobile, the first iPhone business application for enterprise process automation and job scheduling. The Cronacle Mobile Alerting Service extends the capabilities of Cronacle Mobile by taking advantage of the new Apple Push Notification Service (APNS) to deliver time-critical system information immediately to the iPhone or iPod touch.

"We are very excited to deliver a solution to our customers that is as mobile as they want or need to be," says Tijl Vuyk, CEO and president of Redwood Software. "With our new alerting service we extend our mobile platform so customers can monitor their systems, and receive real-time notifications wherever they are and whenever issues require their attention."

Cronacle Mobile Alerting extends the benefits of mobility and remote management to any back-end systems which run Redwood's industry leading process automation and job scheduling solutions, including Redwood Cronacle® and the SAP Central Process Scheduling application by Redwood. All SAP and Redwood customers can use Cronacle Mobile Alerting to manage their entire enterprise landscape, including both SAP and non-SAP applications.

If you would like to discuss this topic or other custom mobile applications for SAP please contact us.

Mobile Applications - Hosted or Not?

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 that you want to connect to your 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.

If you would like to discuss this topic in more detail please email.