jeudi 25 octobre 2012

Checklist for Determining Enterprise Readiness to Support Employee-Owned Devices

A lire sur:  http://www.gartner.com/technology/reprints.do?id=1-1BR9HS9&ct=120817&st=sb

18 June 2012 ID:G00234127
Analyst(s): Andy Rowsell-Jones, Nick Jones

VIEW SUMMARY

"Bring your own device" is proving popular with businesses in most regions around the globe, with all the attendant device management, data security and cost control issues that brings. This research provides a high-level checklist to use when implementing a BYOD program.

Overview

Key Findings

  • Bring your own device (BYOD) is an increasingly common phenomenon. It is opening up the potential of productivity gains, serving as a stimulus for employee satisfaction and seeding innovation, while exposing the enterprise to data and device management risks.
  • There are several strategies for enterprise IT with respect to BYOD, ranging from laissez-faire to lockdown. However, the most effective strategy has enterprise IT taking the lead by segmenting employees into groups, and providing access and appropriate support for each.
  • BYOD implementations can be complex for enterprise IT, with many moving parts. Therefore, there is value in leveraging the lessons from other implementers.

Recommendation

  • For enterprise IT, a BYOD program has multiple phases and touches multiple stakeholders. Use the structured approach to planning, piloting, executing and reviewing in this research as a checklist for your BYOD plans.

Table of Contents

Contents
Tables
Table 1.
A High-Level Checklist for Implementing BYOD
Table 2.
Illustrated Roles Versus Needs Matrix

Analysis

Overview

Enterprise IT is in transition again. Use of employee-owned devices in a work context is an organically emerging trend in a wide range of enterprises. The challenge for enterprise IT is to manage this transition to BYOD without exposing the enterprise to unnecessary device management, data security and cost control risks, and without stifling the innovation these devices may herald.
This research provides a high-level checklist (see Table 1) to use when implementing a BYOD program. Each step is discussed in greater detail later.
Table 1. A High-Level Checklist for Implementing BYOD
Step
Key Deliverable
1
Deciding on a BYOD Strategy
Determination of Which Approach to Adopt to BYOD
1.1
Conduct a high-level BYOD issue review to scan for showstoppers.
Initial list of roadblocks and issues that may shape your response to BYOD
1.2
Justify the program and define the goals.
Evidence and goals for sponsor and stakeholders
1.3
Define the scope and identify the sponsor.
Charter for BYOD program, definition of goals, and identity of sponsors
1.4
Identify stakeholders and solicit input.
List of stakeholders and the issues/concerns that impact them
2
Grouping Employees, and Defining Support and Access for Each
Segmentation of Employees Into Three to Six Groups, and a Package of Policies and Technologies for Each
2.1
Define employee groups.
Employee roles/needs matrix and a list of applications/services to be supported on BYOD devices
2.2
Assess employee information sensitivity for each group.
Roles/needs matrix annotated with the sensitivity of information handled by employee roles
2.3
Identify the delivery and security options for apps and services for each group.
List of options to deliver each key app or service onto an employee-owned device, as well as management and security tools
2.4
Create scenarios for device/staff/application management regimes for each group.
Possible packages of policies and technologies to address the needs of selected employee roles
2.5
Select a scenario for implementation for each group.
Detailed proposal for the selected master scenario
3
Implementation Planning
Scope of Tools, Network Services and Financing Models
3.1
Select the tools and technologies.
List of tools for application delivery, device management, security and virtual desktop.
3.2
Define the networking and connectivity strategy.
List of network services/providers, and a technical and financial policy for each supported network type
3.3
Define the app management and licensing strategy.
Guidelines and policies for application licensing, management, sourcing and funding
3.4
Define/refine financial aspects and create a cost model.
Proposed reimbursement plans, expected networking costs and a total cost of ownership model
3.5
Define employee education requirements.
Define education material for proper use and how to access corporate IT assets
3.6
Identify eligible employees.
List of employees taking part and line management approval for their participation
3.7
Analyze the risks.
Validation against social, business process, financial and data security risks
4
Project Setup
Staged Approval for BYOD Program
4.1
Create a detailed program proposal for stakeholder sign-off.
Detailed program description for stakeholder approval
4.2
Educate stakeholders and ensure their sign-off.
Approval from stakeholders and sponsors
4.3
Create policies and procedures.
Internal policy documents, procedures, staff BYOD contracts and agreements
4.4
Define support processes.
Supported principles, processes and budgets
4.5
Obtain external stakeholder deliverables.
External policy documents (such as finance policies and legal wording for contracts)
4.6
Create instructional material.
Training materials (such as presentations and webcasts)
4.7
Select employees and obtain agreement.
Lists of participants and signed employee agreements
4.8
Roll out employee education.
Rollout of education material on proper use and how to connect to corporate IT assets
5
Proof of Concept
Successful Pilot and Key Lessons
5.1
Pilot the program.
Updated program deliverables addressing issues identified in the pilot.
6
Implementation
BYOD Rollout Plan
6.1
Roll out the program.
Trained employees and related staff (such as support and managers) and replaced devices
7
Program Renewal
Periodic BYOD Health Check
7.1
Monitor and evolve the program.
12- to 18-month review of BYOD employee satisfaction, value and risk, as well as needed corrective actions
Source: Gartner (June 2012)
Table of Contents

1. Deciding on a BYOD Strategy

It may seem odd to need a strategy for BYOD. After all, why should enterprise management do anything? Isn't it just a case of sitting back and waiting for employees to bring in their devices, create new business models and improve productivity? Unfortunately not.
The consumerization of IT with mobile devices and their ecosystem of applications — what we are calling BYOD — may have gone into overdrive of late, but IT leaders and their enterprises still need to make a considered trade-off between freedom of employee action, and the costs and risks of supporting these devices. In short, IT leaders need to balance a new set of potential business benefits with a new set of business risks.
One of the first considerations is what the enterprise's broad approach to BYOD should be. Options range from laissez-faire to lockdown:
  1. HR takes the lead: Ban employee-owned devices being brought onto enterprise premises and prevent them from connecting to any enterprise network assets.
  2. HR takes the lead: Allow devices on-premises but offer no access to enterprise network assets.
  3. Enterprise IT takes the lead: Allow devices on-premises but limit the connection for everyone to email, name and address book, and contacts.
  4. Enterprise IT takes the lead: Segment employees, allow the use of BYOD for enterprise business, and provide support in a way that is appropriate for each group (see "Use Managed Diversity to Support Endpoint Devices").
  5. Enterprise IT takes the lead: Segment employees. In addition, offer enterprise-purchased and enterprise-funded mobile devices to some categories of employees.
  6. No one take the lead: Allow employees to do what they like with their own devices.
Most risk-aware enterprises go into their early BYOD initiatives with enterprise IT playing a leadership role. In the rest of this research, we assume that, like most enterprises, the best strategy for you to follow is similar to Option 4.
Table of Contents

1.1 Conduct a High-Level BYOD Issue Review to Scan for Showstoppers

Before embarking on a BYOD program led by enterprise IT, it's useful to consider fundamental questions:
  • Is this a high-security environment that precludes BYOD for anything but personal information management (including email, contacts and calendars)?
  • Are there legal or compliance issues that preclude BYOD for anything but personal information management (for example, especially in multinational organizations governed by different legislations, this might include e-discovery, data privacy legislation, employers' requirement to provide necessary equipment for an employee to do his/her job and so on)?
  • Do issues regarding remuneration, audit, taxation, industrial relations, and employee terms and conditions make enterprise-IT-managed BYOD unattractive?
  • Do any management, technology or policy barriers prevent robust, scalable and secure access that isolates enterprise digital assets on BYOD? Do any hardware, software or bandwidth requirements threaten to scuttle BYOD?
  • Do service-level agreement and support constraints — regarding uptime, remote support, availability of applications, and business processes — limit BYOD attractiveness? Does the enterprise need to make loaner devices available to high-value workers? Can the IT organization effectively deal with a mixed support model that would blend direct support, limited support (supported applications on nonsupported platforms), community support and self-support?
  • As a principle, should the enterprise mandate insurance, warranty and maintenance contracts for all employees using noncompany devices? If so, who pays — employees or their business units?
  • As a principle, what will IT pay for — the device, telecom charges and downloaded apps? What will employees and/or their business units pay for?
  • Can employees opt out of the program? What happens if an employee doesn't want BYOD (for example, older employees who prefer simple feature phones to mobile email)? A better option might be for this to be an opt-in program, and to offer an alternative if the employee doesn't want to opt in. This entails the provision of tools to ensure that employees can do their work if they don't want BYOD. In managed diversity, this is a platform-level device (see "Use Managed Diversity to Support Endpoint Devices").
  • How will the current application portfolio be impacted by employee-owned devices (for example, whether existing applications support multiplatforms, such as Microsoft Office for Mac)? Are existing Web-based applications written to run on multiple platforms, or are they written to run on a specific browser?
  • How will future application delivery be impacted by employee-owned devices (for example, whether IT can ensure that devices and contracts are compatible with planned or likely new application versions)? What happens if new applications have substantially greater data needs that exceed an employee's personal contract limits or process needs exceed the processing capacities of the most common BYOD devices?
  • Do software licensing, hardware sourcing or support issues make BYOD unattractive (current software licenses, for example, may not extend to employee-owned devices)? Are required third-party support schemes available for the proposed BYOD scheme?
  • Should limits be placed on any existing vendor relationships to control device choice?
  • Who oversees user behavior? Who will educate users on the data risks of BYOD? These may be subsumed into a broader question: Who, if anyone, monitors social discourse in public media?
Table of Contents

1.2 Justify the Program and Define the Goals

Even though, in theory, enterprise management may see the wisdom of funding enterprise IT to play a leadership role in BYOD, when it comes to paying the check, they may change their mind. The challenge initially is that no one has experience running an enterprise-IT-managed BYOD program. In addition, the benefits case may be unclear, because adoption, business use and business value are all evolving along with the devices.
A proven way to avoid this trap is to define the BYOD program's goals and costs at a high level. To fill in the blanks, conduct a high-level strength, weakness, opportunity and threat (SWOT) analysis to identify what confronts the enterprise when employees adopt BYOD. This need not be onerous:
  • Collect evidence about the level of informal BYOD by surveys asking how many employees use personal laptops, tablets or smartphones.
  • Discuss the potential benefits (such as increased innovation, need to allow choice to recruit the best staff and displacement of support costs to employees) with key enthusiastic adopters.
  • Highlight the risks of uncontrolled BYOD (such as data loss and costs).
  • Review the network's capacity and security arrangements, and IT's ability to support employee-owned devices. Armed with the results of the SWOT, it should then be possible to fund a pilot to test out the opportunities and challenges. When conducting this analysis, be mindful that one of the biggest challenges with enterprise-IT-led BYOD is for support. Employees want anything they want and blame IT for anything that goes wrong.
If, on the other hand, the implications for BYOD are better understood, a more traditional business case approach can be used to justify investment. This business case typically features a range of benefits, such as enhanced brand image, improved field and sales effectiveness, potentially reduced cost, employee efficiency gains, employee satisfaction improvements and so on.
Table of Contents

1.3 Define the Scope and Identify the Sponsor

BYOD pilots and programs seldom involve the whole organization. Instead, it's generally sensible to choose a small subset of employees — perhaps belonging to a single department — or a few job roles to start with and to roll things out from there.
All process change demands a sponsor, and BYOD is no exception. Ideally, sponsors should come from a business background and be in a position to influence or direct employees participating in the pilot. Many organizations will find they have passionate BYOD supporters among the senior executives who may be candidate sponsors.
Table of Contents

1.4 Identify Stakeholders and Solicit Input

Any major BYOD initiative relies on many stakeholders and raises wide-ranging technical, policy, financial and legal questions. These stakeholders should be identified and contacted as appropriate to obtain inputs and opinions that will shape the program. Example stakeholders include insurers (as risks change), HR (for changes to terms of employment or contracts), IT (application delivery and deployment, support), employees and their representatives (such as unions and workers councils), lawyers (to validate contractual changes) regulators and tax authorities, enterprise architects (architecture changes), auditors, and so on.
Table of Contents

2. Grouping Employees, and Defining Support and Access for Each

A one-size-fits-all approach to BYOD is suboptimal. Instead, segment employees into three to six groups, and determine which package of policies, mobile device management and network access technologies to adopt to support employees choice of devices for each.
Table of Contents

2.1 Define Employee Groups

Diversity of employee needs and the assortment of mobile technologies mean that one-size-fits-all management is not ideal. It means costs are too high, risks are too high or both. Instead, enterprises should segment their employees into three to six groups based on how much mobility and secure access to enterprise data they need. The Gartner managed diversity model takes this approach (see "Use Managed Diversity to Support Endpoint Devices").
To do this, a good starting point is to model employee location and BYOD work style and usage pattern (which may be simplified) and their business requirements. Showing role versus business requirement as a matrix whose rows are the job roles and whose columns are the applications or services that a job role needs when mobile aids analysis (see Table 2). These employee groups should be cognizant of porous boundaries where the definition of an employee may include noncontract, part-time and ecosystem co-workers. (Think R&D communities, nomadic project and construction endeavors, marketing campaigns that attract and coalesce feedback from customers, outsourcing representatives working on internal systems, prospects outside organizational boundaries, and so on.) An intersection is highlighted when a job role needs a particular mobile service. It is also useful to capture the likely employee context for each intersection. For example, determining whether the employee is in the office, in the corporate Wi-Fi cloud or in cellular coverage will help when considering application delivery and networking options.
Table 2. Illustrated Roles Versus Needs Matrix
Mobile Email
CRM
Board Papers
Lead Tracking
Document Sharing
Meeting Notes
Risk
Sales staff
x
x
x
x
x
$
Sales manager
x
x
x
x
$$
CEO
x
x
x
x
$$$
(Add others)
Source: Gartner (June 2012)
This planning matrix can be used in many ways and provides several key pieces of information required in later steps of this process.
Table of Contents

2.2 Assess Employee Information Sensitivity for Each Group

For each job role identified, define the sensitivity of data that the role accesses. This assessment by role is necessary, because some tools (such as mobile email) may be used by staff accessing information of very different sensitivity. A coarse scale will suffice, focusing on an agreed measurement of risk, such as potential financial loss. For example, 0 equals no material loss, and 5 equals high material loss.
Table of Contents

2.3 Identify the Delivery and Security Options for Apps and Services for Each Group

To optimize application delivery and architecture across the BYOD program, consider each application or service in the planning matrix, and identify alternative options for how it might be delivered with adequate security in a BYOD context. BYOD commonly triggers changes to application architectures and, in many cases, to application delivery architecture and security.
Common methods of securing applications include:
  • Mobile device management (MDM) tools that can provide application containerization, control access, inventory security levels and generally serve to lock down a device
  • Application delivery tools to isolate business applications from the consumer side of the device
  • The use of thin-client architectures that obviate the need for a device to contain data
Other popular approaches include sandboxing (for example, email systems that separate personal and corporate email).
Table of Contents

2.4 Create Scenarios for Device/Staff/Application Management Regimes for Each Group

Now that the groups are in place, it's time to strike the right balance between employee freedom of action with respect to their devices and enterprise control for each. When doing this, bear in mind that BYOD is different. Why would anyone bother with BYOD if his or her machine (particularly if it's personally paid for) ends up weighed down with corporate security and device management software, along with stifling rules and regulations regarding its use and associated costs. BYOD is not the same as employee-purchased corporate device (EPCD).
Usually, there are several equally plausible ways to deliver and secure applications and support that have different costs, benefits and trade-offs (for example, MDM tools, thin clients, sandboxed email, virtual desktops and even not using any tool at all if the decision has been made for a very risky approach).
To determine which combination is best, develop a series of high-level scenarios that feature different approaches to device management, application delivery and application design, and funding and support. Although the scenarios may lack a highly detailed definition of a program, they do contain enough details to enable a rational selection. For example, two simple scenarios might include:
  • Scenario 1 for sales staff and sales managers: Deliver email using a sandboxed solution from Good Technology, develop thin-client HTML interfaces for all applications, and implement a system to allow access to SharePoint for secure document cloud storage. In this scenario, there is no need for MDM, provided SharePoint is configured not to allow offline downloads. Funding will be via a stipend. Although this is OK for services, stipends for devices leave the enterprise on the hook for support. Employees will be liable for networking costs, and the corporate element will be covered by the stipend.
  • Scenario 2 for all staff: Port key applications to native iPad implementations (so they can wrap and secure their own data), implement email using the new iOS 5 mailbox partitioning approach, allow employees to take meeting notes using any tool they want, but secure the device and application data using an MDM tool. Implement a board portal tool for directors only to secure sensitive meeting papers. Funding will be via a stipend. Senior staff will use company-provided cellular contracts to allow for the negotiation of roaming costs. Junior staff will use employee-liable cellular networking funded by the stipend.
These examples illustrate that some job roles may require additional tools or special treatment because of the applications they need or the sensitivity of the data they access. Scenario selection will be driven by many factors, including usability, cost, acceptability to employees and so on.
Table of Contents

2.5 Select a Scenario for Implementation for Each Group

In consultation with stakeholders, select plausible scenarios for implementation to support each employee group. Bundle these scenarios to create a master scenario for implementation.
Table of Contents

3. Implementation Planning

Determine the scope of tools, network services and financing models.
Table of Contents

3.1 Select the Tools and Technologies

Select technologies and vendors to implement the chosen master scenario. Examples include mobile development tools, MDM tools, VPNs, hosted desktop tools, cloud storage and so on.
Table of Contents

3.2 Define Networking and Connectivity Strategy

  • Which networking and voice technologies will be used (for example, cellular and Wi-Fi)?
  • Will personal devices be permitted to connect to corporate networks? If so, what controls and restrictions will be applied?
  • How will connectivity be funded — for example, through stipends, through the provision of corporate data accounts, through employees claiming connectivity on expenses or through some other method?
  • How will personal and corporate use of network services on the same device be managed? Some organizations may allow personal calls and data usage on corporate contracts, for example, if they can negotiate flat rate plans. Or, if the employee is liable for the data, contract reimbursement beyond the stipend may be necessary.
  • What mechanism (for example, identity management) will be used to identify the user and control application access (see "Roundup of Identity and Access Management Research, 1Q12")?
  • Are additional supporting technologies or services required (for example, VPNs, network access control systems, network auditing and monitoring systems, or telecom expense management solutions)?
Table of Contents

3.3 Define the App Management and Licensing Strategy

BYOD models also pose challenges in application licensing and funding. These include:
  • Licensing existing software products for potential access by many more endpoint devices: This is more complex under BYOD because it includes a mix of personal and corporate devices. Review license agreements and ensure that cost models reflect the true cost to provision (see Section 3.4).
  • Funding essential mobile apps: Do the app store owners offer a bulk licensing arrangement? How will bulk licensing be managed (the options differ between app stores and even countries)? What should you do about apps that are not available for corporate licensing? Establish guidelines for each jurisdiction and ensure that cost models reflect the true cost to provision.
  • Employees expensing the cost of certain apps for personal devices: Expensing apps can be complex. Because most apps are of low value, treat them like any other expense. Establish guidelines by jurisdiction, instruct employees to submit expense claims as usual, and instruct local management to approve the expenses if they are within the guidelines.
  • Apps purchased by employees who then leave the enterprise: If an employee leaves the organization, what happens to the apps and content on his or her personal device that were purchased with corporate funds (many mobile app vendors have no mechanism for transferring licenses on low-cost apps, so the investment may be lost)? Because most apps are of low value, most enterprises are willing to write off these small sums, as they would for employee-purchased books and other small items.
  • Required apps as part of a mobile application management (MAM) solution: Some organizations choose to adopt a MAM solution as part of their BYOD strategy —essentially a minimum set of apps that should be present on all BYOD devices. This may be provided in several ways (for example, by a dedicated corporate app store product or as a feature of an MDM tool).
  • Common app management among multiple platforms: One of the challenges of BYOD is that it is highly likely multiple different devices will be in use from different vendors. Identify the most common devices in use, and create different app stores, different settings for MDM tools, different platforms and different policies for each.
  • Apps purchased from consumer stores that have different and inconsistent licensing terms and conditions: Although this is true, and may well be an issue surfaced by the audit or finance departments when considering the enterprise's BYOD, in practice, few consumer apps represent a real licensing issue. A realistic risk assessment and measured advice (as a policy) on what to do if you are an employee with one of the shortlist of problem apps is appropriate.
Table of Contents

3.4 Define/Refine Financial Aspects and Create a Cost Model

The goal of this step is to produce a detailed cost assessment for future approval by stakeholders. At this stage, we know and can cost the technology and processes required for proposed BYOD scenarios. We also know and can address issues such as employee data requirements and stipends. Nevertheless, issues remain that may make BYOD unattractive from a tax perspective. These include:
  • Software licensing: Some license agreements are based on endpoints (device licenses), which may imply substantial additional costs as new endpoints are added (such as employee-owned tablets).
  • Tax implications: There are two broad tax implications of BYOD. There is no ability to write off against tax devices the organization does not own. An employee may also face an increased tax bill if the enterprise provides taxable benefits to employees to fund corporate use of personal devices.
Table of Contents

3.5 Define Employee Education Requirements

Although users shouldn't need enterprise IT to tell them how to use the devices, they still require education on acceptable use policies, as well as how to connect to and use corporate information assets and networks.
Table of Contents

3.6 Identify Eligible Employees

In many organizations, not all employees, qualify for participation in an enterprise-IT-led BYOD program. Identify groups, and seek line management approval.
Table of Contents

3.7 Analyze the Risks

BYOD programs introduce new risks, including financial, security, data loss and employee satisfaction risks. Validate the proposed program from at least four directions:
  • Test against likely scenarios. Examples include lost or stolen devices, failure of key vendors and invalid assumptions (for example, about how much data employees might need).
  • Validate from each of the four (somewhat conflicting) goals of a BYOD program:
    • Social: Will the employees be happy?
    • Operational: Can the process continuity be assured?
    • Financial: How are costs controlled and managed?
    • Risk management: What bad things could happen, and how will they be prevented?
  • Ensure that all key stakeholder issues identified in Section 1.4 have been addressed (particularly any legal issues — for example, whether it is acceptable to wipe an employee's personal device).
  • Consider implications of corporate applications and device usage coexisting with personal applications and device usage.
Table of Contents

4. Project Setup

Gain final approval for the proposed BYOD approach. Set up conditions to run the pilot.
Table of Contents

4.1 Create a Detailed Program Proposal for Stakeholder Sign-Off

Create a BYOD proposal with sufficient details for stakeholders to approve it. This should follow your usual project proposal format and process.
Table of Contents

4.2 Educate Stakeholders and Ensure Their Sign-Off

Submit your BYOD proposal to all the stakeholders identified in Section 1.4 for comment, discussion and ultimate approval. Ensure that all are aware of their responsibilities in a BYOD program (for example, IT staff can't roll out new applications without first understanding whether they might cause employees to exceed personal contract data caps; if employees travel abroad, additional reimbursement procedures may be required if stipend models are inadequate for roaming data charges). Iterate as required.
Table of Contents

4.3 Create Policies and Procedures

All device management is a blend of policy and technology. In consultation with legal, audit, HR, insurance groups and so on, extend these to include BYOD-created ones (for example, to define the permissible use of corporate data, to allow e-discovery, to audit devices and to permit wiping personal devices). See "Toolkit: BYOD Mobile Device Policy Template" for a powerful tool to define BYOD policies.
On a related topic, given the rate of evolution of employee-owned devices, specification (which forms part of a BYOD policy) that describes the minimum device features should be issued at least every two years (the practical useful life of a smartphone or tablet). The danger of not doing so is that, if no update is issued, employees may perceive that they can keep their device and enjoy the same level of access and support indefinitely. If this situation occurs, it is highly likely that the device would slip below the specification needed to match the requirement for enterprise applications.
Table of Contents

4.4 Define Support Processes

New support principles and processes must be defined. BYOD demands a new tiered approach to support. No organization can afford an open-ended commitment to fix any problem on any device. When a device is unsupported, alternatives include increased use of peer support and social networks, and techniques such as time-boxed support to limit costs (see "Gartner's View on 'Bring Your Own' in Client Computing").
Table of Contents

4.5 Obtain External Stakeholder Deliverables

Some deliverables must be created by external stakeholders (for example, changes to reimbursement processes and updates to contracts of employment). Ensure that all the necessary external deliverables are available.
Table of Contents

4.6 Create Instructional Material

It's likely that employees participating in a BYOD program will need training in new policies and procedures. Create the necessary material.
Table of Contents

4.7 Select Employees and Obtain Agreement

Identify employees who will participate in the program or pilot. Ensure that they understand it and sign any necessary agreements.
Table of Contents

4.8 Roll Out Employee Education

Roll out education material on proper use and how to connect to corporate IT assets developed in Section 3.5.
Table of Contents

5. Proof of Concept

Conduct a pilot, learn from the results and adjust the implementation as required.
Table of Contents

5.1 Pilot the Program

Typically, organizations run a pilot involving a limited number of users and/or device types before fully deploying their BYOD program.
Table of Contents

6. Implementation

Roll out the BYOD program.
Table of Contents

6.1 Roll Out the Program

On completion of a successful pilot, rollout activities will include training, perhaps reclaiming corporate devices, rolling out new tools and applications, configuring tools such as MDM, and providing additional support for employees.
Table of Contents

7. Program Renewal

Periodically monitor the progress of the program.
Table of Contents

7.1 Monitor and Evolve the Program

It's unlikely that the first version of a BYOD program will be perfect. Even if it is, circumstances change. Regularly track costs, support issues and security issues, and conduct surveys regarding employee satisfaction. Every 12 to 18 months, review the results, and be prepared to tune the program as issues are discovered.
Table of Contents
Publié par à

Aucun commentaire:

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)