When deploying a mobile solution for your company, whether big or small, there are several key factors to consider when planning, deploying, testing and maintaining the technology. How the system is deployed can play a major role in both short-term and long-term success. In this two part e-book, we will review key factors to consider when deploying and maintaining mobile computing solutions.
Table of Contents
Part One: GoLive: Deploying Mobile Solutions
Part Two: StayLive: Supporting Deployment
Part one explores the deployment process, and covers:
• Defining, documenting and building the solution
• The importance of a deployment plan
• Who should play which part in a deployment team
• Creating a successful deployment scheduling and order
• How to stage devices
Part two outlines how to support the solution, and covers:
• Requirements needed once the deployment is completed
• The importance of a support plan for ensuring solution adoption
• Who should be on your support team
• Which services should be included in a support program
Part One: GoLive: Deploying Mobile Solutions
Competition is a Good Thing.
It makes companies stronger, creates new opportunities and separates the innovators from the imitators. One commonality between all innovators is that they continually strive to get closer to their customer (the user of their goods or services). Often, this means connecting associates that regularly interact face-to-face with customers (sales people, field workers, store associates, etc.) with the ability to provide meaningful information such as updated pricing, out of stocks, appointment schedules and hundreds of other items. In many cases, the most cost-effective method for equipping these associates is through the introduction of mobile computing and wireless networking technologies that enable associates to access all of your corporate information from the palm of their hand, anytime, anywhere.
However, this is often easier said than done. First, comes identifying the opportunities; building internal consensus, creating budget, defining the ROI, not to mention writing applications, building interfaces and selecting hardware. In most cases, defining, documenting and building the solution can take six to twelve months or more and when completed the team is ready to take a deep sigh of relief. However, building mobile solutions is only the first phase of the process. In order to achieve the intended results of these systems, they must be deployed, adopted and supported for many years. The remainder of this article will address the second and third phase of mobile computing solutions; deployment and maintenance.
How you go about deploying a mobile solution can significantly affect both its short-term and long-term success. Regardless of how many pilots you perform during the development phase, the deployment phase is when the majority of your users will see the system for the first time and their initial experience will greatly affect the systems adoption rate. With over 25 years
in the mobile solutions business, we have seen great solutions fail due to poor deployment programs and mediocre systems have great adoption all based on how well the deployment phase was planned and executed.
Great deployments are all planned well in advance of the start date and most are designed during the development phase, as there are many aspects of great deployments that require specific elements to be decided and included during the solution development phase. Future application upgrading is one example. Today’s mobile solutions are complicated and ever evolving. Unlike 15 years ago when you would design a mobile solution and simply deploy it and run it unmodified for 10 or more years, today’s world is much more dynamic. Driven by consumer technologies, today’s mobile computing solutions require frequent updates to accommodate OS patches, security updates and application enhancements. Defining and designing in these capabilities during the development phase creates the foundation for smooth deployments and ongoing support.
Resources
When designing your deployment plan here are some items to consider:
Whether you have one location or many, effective deployments require resources. These resources can come from within the company or contracted from third party vendors. In either case, these resources need to function as a team with one common goal — timely and effective solution deployment with a high user adoption rate.
Project Management
Mobile deployments are complicated technology deployments consisting of multiple pieces and types of hardware, applications, installation and training from multiple vendors. As such, ensuring that all the pieces and people are at the right place at the right time is a critical element to every great deployment.
User-plus User Adoption Sponsor
I cannot overstate how important user adoption is when talking about mobile deployments. If the users do not adopt the solution into their daily work routine, the system will not provide the intended results and ROI. The User Adoption Sponsor wears several hats. First, they are responsible for working with the development team to make sure that User concerns are addressed. Second, they work with the deployment Project Manager to ensure that the deployment schedule does not conflict with daily activities and if there are conflicts that the appropriate accommodations are made. Finally, they are responsible for all communication with the user community. This includes advanced communication about the projects benefits, timeline and user responsibilities as well as project updates throughout the deployment and finally providing the users with a voice to address issues during the deployment.
Installation Team
Depending on the solution requirements and number of locations you may or may not have installation needs:
Things to consider include;
- Need for Wireless
- Wired Networking Infrastructure
- AC power requirements
- Location for Charging and
- Storage of Mobile Devices when not in Use
All of these items may require capabilities that are beyond that of your facilities associates. If you are contracting the installation to a 3rd party vendor, you also need to ensure that they carry appropriate insurance levels, government certificates and can provide union labor if required. Also, depending on the schedule and geographic distances between locations multiple teams may need to be trained and managed simultaneously.
Training Team
User training goes a long way towards creating positive and rapid user adoption. There are many methods for user training and all can be effective.
The key is to match the training method with the complexity of your application and existing skill sets of your users. If you have a fairly simple application and are deploying it to users that are familiar with the task, a simple training guide many be sufficient. Whereas, highly complex applications being delivered to new employees or employees unfamiliar with mobile computing technologies may require an extended classroom setting. In either case, make sure that there is at least one employee that is highly skilled in the use of the solution so that other employees can go to them for guidance as needed. Setting up a support hotline is another approach to elevate user adoption.
Staging Team
There is nothing more frustrating and adoption damaging than having users or an installation team arrive on site to find that a device is misconfigured, or pieces of the system are missing. We highly recommend “staging” systems for each location and then shipping them together. The staging process includes all the necessary steps to configure and kit/package the solution components for each site in a standardized process, then ship the entire solution to the location for final installation. This process ensures that each device is properly configured, all peripherals are included (batteries, cables, cradles, etc.) and that the solution was tested so that everything will come up as expected. In addition to ensuring a quick, error free installation, this process also ensures that you are able to capture and correlate hardware serial and asset numbers to the correct destination, thus providing a know state for ongoing asset management tracking.
Deployment Architect
As mentioned earlier, today’s mobile solutions are complex. It is not enough to install the software and forget about it. You need a technical architect familiar with mobile computing applications, operating systems and support tools to design and build the software image(s) that are installed on the hardware devices. The architect should not only be familiar with your mobile solution(s) but he/she needs to understand your mobile employees working environment. By understanding the application as well as the user, the architect will be able to not only determine the best methods for installation software, but also be able to configure the user parameters such as display time out, screen lock down, volume and power management settings to ensure that your users obtain the best possible application experience.
We refer to the inclusion of applications and configuration settings as the “gold Image.” The gold image is the reference point by which we ensure that all devices arrive and operate out-of-the-box as intended.
Deployment
Deployment Pilot(s)
Even the best deployment plans may have missing steps or were created with incorrect assumptions. For these reasons, it is important to pilot your deployment prior to beginning your roll-out. The number of pilots should be based on the number and types of facilities you are deploying to. If you have a single large site, you may want to pilot one section of the site before committing to the entire site. When deploying to multiple sites of differing types (size, location, employee count, etc.), it is often wise to group your sites by similarities and pilot at least one of each grouping.
Deployment Order
When deploying to multiple locations, it will often save time and money if you deploy geographically located sites in a series, as this reduces travel costs and enables installation teams to leverage the knowledge gained on prior sites forward.
System Staging
Successful deployments require that every device is in a known and approved state prior to deployment. Whether deploying barcode scanners, mobile computers, wireless access points or any other intelligent device, they all require some type of software configuration. It may be as simple as setting configuration settings, or as complex as determining the specific applications, network setting, and installing security keys. Regardless of the device, the first step of the “Staging” process is defining the image details, testing the final configuration, documenting the installation process and creating the “Golden Image” that will be installed on every device. “Golden” images contain all applications, device settings, operating systems and other environment variables that are required for the hardware device (mobile computer, barcode scanner, wireless infrastructure, etc.) to operate in the intended fashion.
Defining Image Details
The image definition process is an iterative exchange between the customer, software providers and the Deployment Architect. During this process, the Architect works with the appropriate solution partners to define all of the device configuration and application requirements to ensure that the device(s) will function as desired during the deployment phase. Image details include such things as operating system version, patch releases, configuration settings and device parameters, as well as installed applications and security settings. Depending on the device and complexity of the solution, this process can take from 1 day to several weeks.
Creating Golden Image
Once all of the configuration and application requirements are gathered, the Deployment Architect will combine these components into a digital image(s) that can be installed (software loading) on each device. Once completed, this image will be tested in the customers environment in order to ensure that the device works as expected.
Documenting Installation Process
Once the image has been created, the next step is for the Deployment Architect to document the installation process. The purpose of this process is to ensure that every device is “staged” using the same process, as there is often more than one method to stage device images and history has proven that differing methods can produce different results.
User Acceptance Testing
Upon completion of the previous steps, the Deployment Architect will supply a device that has been staged following the documented procedure to the Customer for Final User Acceptance Testing. This step will ensure that the “standard configuration” for the device has been properly established.
Staging Team Training
The final step in the process is knowledge transfer to the staging team. This process includes archiving project specific documentation and images so that they can be followed for each new deployment phase as well as training the staff on the process.
Hardware Inspection
Upon receipt of mobile devices, barcode scanners, RFID and/or wireless infrastructure, the staging team needs to conduct a thorough inspection of each asset to ensure damage did not occur during shipping.
Software Loading
Following the defined process, the staging team will load the software onto each device.
System Testing
As final confirmation that the device is ready to be kitted, a thorough System Test is conducted.
Kitting
The hardware is ultimately packaged with the required accessories and documentation in preparation for shipment to the deployment location(s) based on Deployment Schedule.
Shipping and Delivery Tracking
Shipping equipment is only the first part of the process. The deployment team should also track each shipment to ensure that it arrives at the intended location on the intended date, as well as working with the carrier to resolve any shipment issues.
Conclusion of Part 1
Starting your deployment planning early, identifying and assigning the needed resources and ensuring that you include the other topics included in this article will help ensure that you not only have a successful deployment, but that you also create positive user experiences and rapid solution adoption.
Part Two: StayLive: Supporting Deployment
Requirements Needed
In Part 1 of this series, we focused on the resources and tasks required to successfully deploy technology solutions while creating great user experiences and rapid solution adoption. In this article, we look at the requirements needed once the deployment is completed. Specifically, how to support and maintain these solutions going forward.
So, you built a great mobile application that solves several business needs, improves your customers experience and reduces your employees’ time to complete labor intensive tasks. You have deployed the solution throughout your organization, the kinks are worked out and it has been successfully running for the past 60 days. Time to move onto the next adventure, but not just yet. While the system is running as intended, we all know that it is only a matter of time before something goes awry. It may be a broken piece of hardware, latent application bug, on-boarding of new employees or one of a hundred other issues.
Building a strong support plan is critical to ensuring that the solution adoption and positive user experience you created continues and grows as the organization continues to grow. Good support plans, like deployment plans, begin before they are needed and in many cases, the tools and skill set you used to deploy the solution can be re-purposed for use by the support team.
When designing your deployment plan, here are some items to consider:
Resources
Whether you have one location or many, effective solution support requires resources. These resources can come from within the company or contracted from third party vendors. In either case, these resources need to function as a team with one common goal (timely and effective issue identification and resolution).
Application Support Team
Mobile applications do not operate in a vacuum. Without exception, mobile applications by nature interact with other business systems to exchange information. For this reason, your application support resources must not only be familiar with the mobile application(s), but also the business applications that they interface with. Mobile solution users tend to think of the mobile application as a single entity and as such, their problem descriptions when reporting issues do not often directly relate to the actual underlying issue. Without the knowledge of how the mobile application interfaces with its dependent applications, the support team will have a difficult time identifying, thus resolving the root cause.
Hardware Support Team
One universal truth is that computer hardware will eventually fail and require repair or replacement. With mobile computing devices, this truth is amplified due to the hostile environments that many of these devices are used in. Here again, the user may or may not be able to adequately identify the root cause of their issue. Most can identify a broken display or cracked case, but less obvious issues can be hard to remotely diagnose. For example, “my device is not working” can have many causes from a dead battery, failed motherboard or application update that did not install correctly. For this reason, we highly recommend the use of a mobile device management tool (MDM) so that the support team can remotely access devices that do not have obvious hardware issues in order to attempt to identify and resolve the issue without having to take the device temporarily out of service.
Infrastructure Support Team
In todays connected world, the majority of mobile computing solutions rely on the use of wireless networks (Wi-Fi and cellular being the most prevalent). Issues with these networks are often first noticed by the mobile computing users as their applications are not able to send or receive the required information. Once again, the mobile user is likely to present the issue “my mobile device does not work” when in fact, it is the lack of a network connection which is creating the undesired condition.
New Hire On-boarding
During the deployment phase, all of your users were trained. However, as new employees enter the organization you need to make sure that they get the required training as well. Re-purposing your deployment training is a great way to train new employees. This may be as simple as providing them with the previous user guide, or videotaping prior training sessions and providing them as online material.
Support Services
The following support services need to be included in all support programs:
Help Desk – Tier I
Tier I Help Desk services is the first line of support for your users. In most organizations, this function is managed by internal resources and is used to resolve simple issues and/or identify and route the user to the appropriate Tier II support desk.
Help Desk Tier II
Tier II Help Desk services provide in- depth technical support for your mobile, barcode scanning and RFID systems. In addition to supporting hardware and application issues, the infrastructure support team often resides in this organization as well. Many customers outsource all or part of their Tier II needs to qualified 3rd party providers.
Help Desk Hours
In addition to evaluating the Help Desk teams’ technical capabilities, it is also important to identify their standard and extended support hours of operation and make sure that they line up with the work hours of users they are supporting.
Asset Visibility
Mobile computing equipment is costly and due to its mobile nature, can easily get lost or stolen. Keeping track of your mobile assets is not only a good financial move, but it also ensures that the correct amount of gear is available to support each location. Leveraging an asset management system to track your assets will save time and money in the long run. Additionally, investing in a solution that can track asset movement in real-time, as well as capture the reason for each movement, provides valuable insights on the overall health and operating status of your environment.
RMA Support
Hardware failure is inevitable and having an efficient and seamless RMA process will not only provide your users with increased uptime but also reduce the spare inventory investment required to support temporary hardware outages. RMA process planning should include provisions for the following:
- Next day delivery of a configured replacement device
- Spare pool management
- Complete device repair cycle management
- Multiple RMA generation methods (online, email, phone, etc.)
Enterprise Mobility Management (EMM)
As stated earlier, the user of a mobile device management (MDM) tool is essential for remotely diagnosing issues, as well as for performing software updates in the field. Whether you perform this function with internal resources or outsource to a partner, EMM should be thought of as a necessity for any medium to large mobile solution deployment.
Manufacture Device Contract Management
Ensuring that your entire device population is properly ensured through an extended warranty program with the hardware manufacturer can be a time-consuming task. New device additions and damaged device replacements or removal creates significant tracking and contract management headaches. However, there is nothing worse than sending a device in for repair only to find out that it is no longer on contact. The time required to get these devices back on contract or repaired on a time and material basis will adversely affect the devices in your spare pool, which may result in a delay of replacement devices in the field.
Conclusion:
In order to create long-term success, it is important to effectively deploy and support a mobile solution. By creating comprehensive deployment and support plans, you will not only increase the likelihood of creating a positive user experience and rapid solution adoption, but also resolve issues in a timely and cost effective approach.
Have a deployment in your future? We can help make you the hero.
