How to get the Value of Mobile without the associated complexities

Understanding the specific challenges of mobility in a High-Intensity Mobile Worker Environment, and how to address them

A whitepaper by Zetes

WWW.ZETES.COM | ALWAYS A GOOD ID 30 YEARS OF BUSINESS VALUE

ABSTRACT Over the past few years, mobile technologies have experienced real hype, driven by an ever evolving consumer market. What few The use of mobile technologies in supply chain people realise is that mobile technologies have been delivering process execution has delivered substantial substantial value to mission critical business processes for business value over the past 30 years. Recently, three decades. due to technological and cost evolution, we have seen the numbers of mobile initiatives increase, In the beginning, mobile and automatic data capture focused on often occurring as a simple extension of traditional eliminating manual data input behind a desk. Traditionally, at information systems. Whilst we regard this the end of a field operation, an administrative employee would increased attention as encouraging, there are get a pile of handwritten notes or filled out forms, and enter risks. When used by High Intensity Mobile Workers, these into a computer system, hopefully without too many errors mobile technologies present a very specific set of and delays occurring. Using mobile technologies to introduce challenges and opportunities and underestimating some form of automatic data capture in the field, close to where them is a mistake. To compare a mobile project with and when the data was generated, has led to significant cost a desktop project, or regard it as an extension of efficiencies and increased data accuracy being achieved. an existing information system and apply the same approach and tools, can create serious problems. Less costly administration and increased reliability of available data has led to better supply chain visibility, which allowed for This whitepaper addresses the key challenges reductions to buffer stocks and working capital needs, creating that arise from a mobile, as opposed to traditional further efficiencies. Information Systems (IS) project, highlighting how a failure to appreciate these differences can lead At the same time, the resulting reverse communications channel to excessive project and operational costs, even to became useful for making data available to field staff in order to project failure. The whitepaper also suggests how to empower them with the right information at the right time, so address the challenges of mobility, and what to look that the right decisions could be made at the point of activity. In for when selecting the right tools to do so. its extreme, this information could be ‘what to do next’ so that field staff workflows became driven by information systems. The focus of this whitepaper is mobile applications This has led to even greater improvements in efficiency and used by mobile workers in a process along the supply quality. chain. We will refer to such users as ‘High Intensity Mobile Workers’, or simply ‘mobile workers’. These efficiency and quality improvements have been achieved across the entire supply chain. This can include the following stages:

• On the packaging line: labelling and registering units as they leave the line; recording which boxes were loaded onto pallets. • In the : tracking goods being received, put- away and prepared; loading goods on time and in full onto the right vehicles for transportation. • On the road: delivering goods to the right location, on time and in full. • In the store: ensuring shelf availability, where and when the customer wants it.

2 ZETES WHITE PAPER Significantly, payback periods for these types of projects are need to be split second, whether there is network coverage or often shorter than a year. not. Obviously, the requirement for near to zero-latency has consequences for how applications and user interfaces are Historically, these mobile applications have been built by people designed. with a deep understanding of the business processes, the technologies involved, and the realities of field working. The sheer number of transactions processed by a mobile worker Today, as a result of technological and cost evolution, we see It is not uncommon for a mobile worker to process 2000 very an upsurge in mobile initiatives. Attracted by this demand, similar transactions during a day, whilst standing on his feet. increasing numbers of companies and developers who have Consider an order picker gathering products to put on pallets. specialised in classical information systems endeavour to When executing 2000 similar transactions every day, it matters transfer their experience onto mobility projects. Often, these a lot if a transaction is executed with 3 keystrokes rather than companies approach mobility with the same mindset and tools 4. Ideally it is executed using no keystrokes at all. Whereas on a as they would have used in a desktop environment, frequently desktop it is acceptable to ask the user to click on a checkbox, with disastrous results. The mobile world is fundamentally select from a drop down menu, and push an OK button, on a different and this needs to be taken into consideration when mobile device, it is not. On a mobile interface one should aim undertaking a mobility project. Failing to do so creates the risk for the user to complete an entire transaction with the push of of it becoming a costly exercise, both during development and a single button, the scan of a single barcode, or even by ‘telling’ afterwards, when operating the application. Occasionally it can the system a number, allowing hands and eyes to continue even lead to outright project failure. It is important to understand handling goods in the meantime. Traditional developers do these differences, so let’s start by exploring them. not always consider the ergonomic aspects of mobile in such an environment, and not all development environments and CHALLENGES & OPPORTUNITIES SPECIFIC technologies cope well with requirements for fully optimised TO MOBILE user interfaces that use all the available interaction capabilities of a mobile device. Mobile can deliver great value but also presents specific challenges and opportunities. These need to be addressed in Mobile workers are often temporary users order to ensure that the potential value is realised and that In supply chain processes, it is not uncommon to cope with the total costs involved in creating and operating a mobile peaks in activity by employing temporary workers. Such application remain under control. workers are often only employed for weeks, if not days, which makes it uneconomical to spend more than a couple of minutes These mobile-specific challenges arise from differences in the training them on how to use a mobile application. Obviously, the User profile, differences in available resources on a mobile requirement for zero-training has consequences for how user Device, and differences in the Deployment Environment, as interaction is designed. It is an extra reason to invest in a fully compared to a classical application. optimised natural, intuitive interface, which makes use of all the available interaction capabilities of a mobile device. 1. USER Mobile workers can be very remote and isolated A MOBILE WORKER IS QUITE DIFFERENT TO AN OFFICE Mobile workers are by definition geographically dispersed. More WORKER often than not, they work far away from an IT support function A mobile worker’s expectations are substantially different and have no-one to go to for help. Again, this reinforces the need for an intuitive user interface and generates the requirement for A desktop user will happily sip coffee whilst waiting for the system a central helpdesk to remotely ‘look over their shoulder’ taking to respond, but a mobile worker will not. Often a mobile worker screen and keyboard control if necessary. is on his feet and client facing - he does not have 3 seconds spare to wait for his screen to respond with an answer. Think From a user’s perspective, there are clear, mobile-specific for a moment about the delivery man standing at your doorstep, challenges to overcome in order to achieve zero-latency, or the warehouse worker waiting for his next assignment, or high-efficiency interactions with a mobile device, intuitive ‘no- the store employee checking prices for a customer. Any system training’ user interfaces, and the availability of remote support. latency leads to irritation and lost productivity. Response times

ZETES WHITE PAPER 3 2. DEVICE As stated before, the requirement for developing a fully optimised, highly efficient user interaction has consequences AVAILABLE RESOURCES ON A MOBILE DEVICE ARE DIFFERENT for how applications are designed and what the development THAN ON A DESKTOP, AND MUCH LESS STANDARDISED platform should allow.

Physical constraints under the hood From a development perspective, if not tackled well, the use Mobile CPU, memory and storage have improved a lot in recent of multiple I/O can become costly. Often these peripherals are years, but are still not equivalent to what one would expect to find somewhat complex to program. To make things worse, the way on a desktop. Although in certain geographical areas bandwidth to address these peripherals is typically not standardised across has become less of a constraint, battery capacity has not. And devices. This means that one might end up redeveloping the use the more radios communicate, the more the battery drains. of every peripheral for every new device type, for every new OS, and for every new release of a device. Without the necessary These physical constraints lead to the requirement for tools, this often leads to trade-offs between maximising user optimised use of resources, which has consequences for productivity and minimising development cost. Avoiding this application architecture, database set up and the configuration trade-off generates the requirement for an abstraction layer of communication protocols. to allow all the capabilities available on a device to be easily accessible without having to learn device specifics. For high-performance mobility, one needs to work in a Client/ Server setup, where User Interaction logic and static data sits Compatibility & Interoperability on the device, ensuring maximum user responsiveness. What In a desktop world, devices are typically standardised across goes over the air is application-controlled so that it can be different brands. This means that if you develop once, there is a limited to what should be really required and as such ensures high chance that one can deploy on different desktops from the maximum battery life. same brand, on desktops from different brands, and on evolving versions of operating systems, all without having to change a Generic approaches that assume an ‘always powered, always single line of code. connected’ desktop are not usually a good fit for mobile. Neither are generic database synchronisation technologies. The mobile world has not yet reached this level of maturity. There are differences between devices coming from different vendors, Screen and Keyboard are substantially smaller, if they exist differences between families of devices coming from the same at all. Multiple other means of input/output are available, but vendor, and differences between devices within the same family not always easy to integrate of devices. There are even differences in subsequent iterations The physical limitations of screen and keyboard limit the of the same device. To complicate matters even more, there are possibilities for classical interaction and for providing extensive also differences in the Operating Systems (OS) and amongst help. Again this reinforces the need for a natural, intuitive user different implementations of the same OS. interface, where one does not need a help function, and where one maximises the use of other input means to avoid having One consequence of this is potentially having to redevelop an to use often far too small keys. For an optimal user dialog, application for each new device type, or even worse, for every one should consider all possible means: barcode scanning, iteration of the same device type. And although the business RFID bursts, image capture, voice input, touch screen and logic can usually stay the same, the code to address the typical accelerometer for input. Plus screen, vibration, sound, light and peripherals that come with mobile i.e. barcode capturing, tactile speech for output. screen for signature capture, RFID or voice, usually cannot. And without a proper abstraction layer, the effort to drive peripherals Furthermore, on a desktop one can live with multiple tools that can easily run up to 80% of the total effort. This is true for the do different things in different windows, and the user is expected initial development, and even more so when redeveloping for to alt-tab between windows, or even kill windows if a process new devices. With the right tool, one can avoid being locked-in hangs. In mobile it is good practice for the app to be vertically to one specific device without having to do costly redevelopment. integrated, so that everything can be done from within a single app. This has the additional benefit of eliminating the risk of So from a device perspective, there are clear mobile-specific multiple apps fighting for the same limited resources. challenges due to physical constraints, and due to lack of compatibility and interoperability.

4 ZETES WHITE PAPER 3. ENVIRONMENT Need for agility Mobility in supply chain processes is often a critical part of A MOBILE USAGE ENVIRONMENT IS QUITE DIFFERENT FROM an operational process and means that one needs to be able A DESKTOP USER ENVIRONMENT to adapt and deploy quickly when requirements change. We Devices are not permanently connected, which creates have observed instances where suddenly, a new barcode type application design and management challenges appeared in goods-in and required a rapid response to adapt. If this can be completed in a matter of 30 minutes, whereby Although mobile operators and wifi providers want us to believe the application gets changed, tested, redeployed, and made that coverage is ubiquitous and bandwidth always sufficient, operational in that time, it is possible to avoid ending up with all in reality this is not the case, and needs to be taken into kinds of exception processes, such as returning goods. In order consideration. Consider: to do this, tools to enhance agility without being dependent on a remote vendor or changes in a WMS are required. • A delivery man in a remote rural area, ready to capture a signature for receipt of goods, but without 3G coverage. This need for agility creates the requirement for a toolkit that allows your own staff to easily make changes to an application, • A salesman meeting in the basement of a hotel visiting the and deploy, without the need for lengthy or complex training. restaurant chef and checking the stock. • A maintenance worker executing work orders near Interaction with central systems equipment that generates a high level of interference. Mobile applications hardly ever exist in isolation. There is almost always data exchange with central systems, e.g. a WMS* The application needs to ensure that the mobile worker can or ERP*, an In-Store system, an MES*, or any combination of continue operations, finalise a transaction and retrieve the next these. Building such interfaces from scratch can be lengthy and task, all without having to rely on being continuously connected. error prone. This drives the requirement for a tool that allows Clearly this has consequences for application architecture and each of these systems to connect in an easy way. design. The architecture needs to ensure that transactions can be buffered, and flushed as soon as coverage is available again. NOT ADDRESSING MOBILE-SPECIFIC This intermittent connectivity also creates challenges for device CHALLENGES CAN HAVE HIGH COSTS management. So there are quite a lot of mobile-specific challenges to consider, Remote / Distributed and not addressing them upfront with a clear mobile mindset and appropriate tools can prove very costly in the long run: Mobile users are by definition often geographically dispersed. They may work alone as in the case of a delivery van, or clustered per store in the case of an international retailer. 1. Users risk being faced with user interfaces that are far from optimised, and that are not using the full capabilities of the Besides support challenges, geographical spread also creates devices the company has invested in. This leaves efficiency challenges for deployment of new application versions. For example, opportunities on the table, too much room for error, and can how do you ensure that every device gets the right applications, in seriously slow down adoption rates. Occasionally it can even the right language, for the right country, as soon as possible? How do lead to project failure. you ensure that this does not happen in the midst of a transaction? 2. IT-staff risk spending 80% of their time on technicalities Or how do you take into account that not all devices are always and mobility specific challenges, instead of adding value by connected? And how can one ensure this works correctly when optimising the user interface and adding new business process dealing with 9000 devices spread over 1800 stores in 63 countries, functionalities. Not just initially, but every time a new device or in 40 languages, with 17 different user types? How will it cope in an version of a device arrives, and every time a new version of the environment where there is no IT support function in-store? app needs to be deployed. Because of that, IT-staff risk being under continuous pressure from operations, who have ever Managing all this manually would quickly revert to chaos, with changing requirements due to ever changing environments and skyrocketing deployment costs and big delays in deploying new a continuous quest for competitive advantage. functionality in the field. Clearly this drives the requirement for a capability to setup an automated, rule based schedule for deploying new versions.

* See lexicon p.7 ZETES WHITE PAPER 5 3. The Operational Owner risks seeing the project not delivering WHAT SHOULD YOU BE LOOKING FOR IN A according to initial objectives, and risks ending up with a monolithic application where every change takes a couple of TOOLKIT TO DEVELOP, DEPLOY AND MANAGE months to develop and deploy. The operational owner also APPLICATIONS FOR HIGH-INTENSITY MOBILE risks not being able to switch to more cost-effective devices WORKERS IN A SUPPLY CHAIN EXECUTION with greater capabilities because of the costly redevelopment needed. Such high switching costs generate a lock-in and put ENVIRONMENT? device manufacturers in a powerful position. Now that we know the specific challenges of mobility in a High- 4. And finally, as a result of the above, Finance risks seeing much Intensity Mobile Worker environment and the principles to follow lower project returns than anticipated. to achieve operational as well as IT-success, what should we look for in a Toolkit to develop, deploy and manage mobile applications?

WHICH PRINCIPLES ADDRESS MOBILE 1. You need a layer of abstraction on top of the technicalities SPECIFIC CHALLENGES? of peripherals such as a Barcode Reader, RFID Writer, or a communications module, to focus on business functionality If these are the challenges and risks, then which principles do and optimising the UI. The abstraction layer should ensure that we need to follow if we want to address these mobile specific the technicalities of addressing specialised peripherals are challenges and make our mobility project for high intensity taken care of, so you can tap into the capabilities of a device by mobile workers a success, whilst keeping development, using simple high level concepts such as “give me an EAN13 deployment, management and hardware costs under control? barcode”, “ask the user for a signature and store the image”, “ask the user to TELL me a check digit”, “send records back to Operational success means: SAP”. Without an abstraction layer like this, valuable time is lost learning multiple SDK’s (Software Development Kits) at a very • Heavily optimised, natural user interface for maximum detailed bit-level every time a new device is being considered. productivity, maximum accuracy, and maximum adoption. 2. You need an abstraction layer above the multi-device, • Near to zero training needed. multi-OS layer, so that IT efforts can be focused on business • Well supported users. functionality and UI optimisation, instead of figuring out the technical details for every device and OS, and for every flavour of • Fast response to changing requirements, short time-to- the former. Without an abstraction layer like this, it is easy to get value. locked into a certain device type, having to trade off the impact • No lock-in to specific devices, which is typically the largest of re-developing the overall application versus not having the part of total cost. capability to upgrade to next generation hardware. Instead, you want to be able to migrate to next generation hardware without IT success means: having to change a single line of code. For example, on the OS- • Easy, fast development and easy access to all of a device’s side, we have seen people take a year to decide upon Windows functionalities. Mobile versus Android, worried about the future evolution of both. With a good tool, this should not be a concern and you • Easy to deal with multiple device types and multiple OS certainly should not lose a year. types. Avoid having to make OS-bets. • Easy, no-hassle deployment. 3. You need a design tool that allows every little detail of the UI to be optimised to achieve maximum user efficiency and • Easy remote, ‘over-the-shoulder’ support and user adoption. If your mobile workers are executing the same management. transaction 2000 times a day, having to waste a second on a single unnecessary keystroke is too long. This means having • Easy integration to central systems. access to all device capabilities in order to fully optimise the user • No extensive re-training or recruitment needed. interface. Failure to do so means loss of productivity, frustrated users and an extra source of potential error. Traditional browser • Avoid having to deal with ‘nitty-gritty’ technical details and based applications are not good at this and are hence not suited the complexities of limited device resources. for a High Intensity Mobile Worker scenario.

6 ZETES WHITE PAPER 4. You need design tools to make it easy to change the So the ultimate goal should be to try and achieve the full business application, so that in case of changing requirements, you can value that mobile has to offer, but at the same time, saving minimise Time-To-Value. You want a tool where if needed, you the time, effort and money of development, redevelopment, can change the application yourself. In a matter of minutes, not deployment and management of a set of mobile applications, days. And by yourself, so that when speed is of the essence, users and devices. With the right toolset, it is easy to save 80% you are not reliant on a 3rd party. Failing to do so means costly across each of these activities. A toolset, that allows speed- dependencies. to-value and user-efficiency to be maximised, without having to lose time on technicalities and other challenges linked to 5. You want a tool that makes deployment easy, so that even if you mobile. A toolset, that allows you to get maximum value from are running 9000 devices spread over 1800 stores, 63 countries mobile, with none of the complexity. and 42 languages, your effort and time-to-value are minimal. Failure to do so means massive amounts of extra work, long delays before functionality reaches the field, and potentially nice improvements not being implemented because the effort HOW CAN WE HELP? to deploy is too high. For over 30 years, Zetes has been developing, 6. You need a tool that makes it easy to manage users and the deploying and providing fully managed mobile functionality they need to see, so that every user can focus solutions for major manufacturers, on his applications, without having to weed through irrelevant providers and retailers across EMEA. Zetes is ‘stuff’. also the n°1 partner of all leading manufacturers of mobile devices for usage in the supply chain in 7. The tool should allow easy management and support of users . The result of this expertise is reflected in based remotely in the field, so that you can maximise availability our collaborative supply chain solution suite: a from anywhere, even if devices and applications are spread over set of 6 solutions that answer specific challenges 63 countries. Typically you would like parts of MDM functionality in the supply chain, from the manufacturing plant to be built into the tool, following the Pareto principle that 20% to store. All solutions can be interlinked to achieve of functionality delivers 80% of the value. MDM-functionality end-to-end traceability and are powered by the needs to be built in and not separate for at least 2 reasons. MCL Mobility Platform™, a cloud-based Mobile When built in it allows you to also monitor application metrics, Enterprise Application Platform (MEAP) dedicated not just technical aspects. Secondly, it allows the app to be in to supply chain process execution. full control of the device, so that it is not competing with an MDM tool for shared resources. Lacking these capabilities will The MCL Mobility Platform™ is unique because it lead to excess support costs and frustrated users. combines two features that create unrivalled synergy for supply chain customers. Firstly, it is dedicated 8. The tool should allow control over how communication is to supply chain process execution; and secondly, it handled, in order to deal with gaps in connectivity and to remain allows customers to build, deploy, run and manage in full control of the limited resources. mobile applications, devices and users faster and from virtually anywhere, regardless of OS or mobile 9. The tool should provide bridges to host systems, making it device. This approach removes the complexity easy to set up data exchanges with leading enterprise systems. associated with managing a mobile infrastructure by reducing development time and deployment 10. You need a stable and focused supplier. Stable because you costs and avoiding unnecessary investment in IT want the supplier to continue operating independently and infrastructure. focused as you want them to continue focusing on the mobility business. Continuity can only be guaranteed when these Want more information? Our mobile supply chain characteristics are combined. specialists will be happy to advise you. Find your local contact at www.zetes.com /contact

LEXICON ERP: Enterprise Resource Planning MES: Manufacturing Execution System WMS: Warehouse Management System TMS: Transportation Management System ZETES WHITE PAPER 7