Apple's iOS products may be garnering the most attention these days, but many professionals prefer their Androids. Some docs use their own, under ‘bring-your-own-device” programs, but a few healthcare organizations are actively looking to the iPhone alternative as another nifty tool for physicians and healthcare professionals.
In fact, some have gone so far as to argue the Android outsmarts the iPhone in terms of options and flexibility. But just as sure as its popularity will grow, the implementation techniques and deployment plans will vary as well.
MobileIron, in a recent whitepaper, outlined five keys for Android deployment.
1. Appoint an Android expert. There's a greater discrepancy along operating system, device and apps for the Android than for both the iOS and "Blackberry ecosystems," the report read. And since the Android is consumer-driven, the ecosystem tends to change rapidly – at "consumer speed" and not traditional enterprise speed. "An essential best practice is to designate one individual on the [team] to be the Android expert," the report read. "More and more of the overall IT team should gain Android familiarity…but [people] need one point person whose charter is keeping up with the rapid evolution of the Android ecosystem." Otherwise, the report continued, the department's Android knowledge base can become obsolete quickly. "Assigning a point person to keep up with the Android is the first step to devising an effective rollout strategy."
2. IT should understand what end users want and need. According to the report, the push for Android devices will come from employees and not IT, "so before developing a deployment strategy, IT must first understand what end users want and need," it read. The report listed questions users should answer to gauge their level of expectation. They included which Android devices they're buying in their personal lives, why they opted for an Android, and what types of apps they're using. "If user preference is based on factors other than price, or your company is planning BYOD programs, then this basic user research feeds the development of the initial short list for Android device selection," the report concluded.
3. Determine capability requirements. Many IT professionals assume the Android behaves similarly to Apple's iOS but, "that is not the case," read the report. "In addition…there are variances across devices themselves." So, in addition to assigning an Android expert, the report advises that IT should determine the baseline capability requirements for certifying Android devices. Some of the most common: lost device security, encryption, enterprise email, and security connectivity. "Setting a baseline…will break through the initial confusion and establish the minimum level of enterprise functionality required for each phase of Android application," read the report. "For example, remote lock/wipe, password enforcement and encryption may be sufficient for an Android pilot, though greater functionality would be required for a wider production deployment."
4. Set the "support boundary." IT needs to decide what to support and what not to support, and for the Android, this could mean modifying an organization's mobile initiatives. The report broke it down according to device support boundary, app support boundary and enterprise access support boundary. "These support boundaries must be clearly communicated to the user community in order to set expectations appropriately about the use of Android for work," it read. Including these boundaries in an organization's mobile user agreement is necessary for legal enforcement, it continued, but not adequate for the end user. "Mobile IT will need to develop supplemental forms of communication, like posters, alerts and wikis, to educate employees on what is supported, what is not supported, and the simple logic underlying those support decisions."
5. Go with a phased approach. According to the report, a three-phased approach works best for most companies. "They limit the possibilities at first and then add devices and functionality over time," it read. The three phases it outlined included the pilot period of three to four weeks, the "pilot plus" period of three to four weeks, and the production period. "The path to production deployment for Android will likely be more controlled and more constrained initially than it was for iOS," it added. "But this final phase is also when the company can truly start to realize the potential of Android."
Follow Michelle McNickle on Twitter, @Michelle_writes