BYOD

BYOD Should Be About More Than Email

Yesterday, I posted an article on Forbes that discussed the multiple definitions of Bring Your Own Device (BYOD) which you can read here.  In short, I said that analyst numbers (mine included) don’t accurately reflect what is happening in BYOD.  In effect, BYOD largely means a business is allowing an employee to access email — not applications — over a mobile device.  

If you are a business embarking on the BYOD challenge, there are several items you should consider and several questions that you should answer before you get started.  First and foremost, you should be thinking about more than email. If you are going to go through the effort to support email, what other apps make sense for a broad cross-section of your employees? For example, expense report management and customer relationship management may be applicable to a wide range of your employees.

Second, what is your security strategy for allowing your users to access email and then other apps?  If you don’t think of a portfolio of apps you may pick a solution that is geared largely to email management instead of mobile application management. Many firms that are doing BYOD are enabling corporate access via a mobile VPN? If so, what does that experience look like? Does it feel seamless or clunky?  I’ve seen VPN implemented well and poorly.  If you decide to use VPN access, you must make the log-in appear seamless to the end user. If they have to type in lots of digits, you’re service is dead.  Also, are you offering BYOD on any platform or just on “iDevices” (e.g. iPad, iPhone, iPod).  Many firms say they do BYOD but only for certain operating systems and device models.

Third, what is your plan for accessing legacy application data on a mobile device?  Do you really think desktop virtualization on an iPad is the experience your users want?  No, what they want is an app that has been designed to work the way consumer apps do.  Employees want two clicks to data.  Employees want to swipe and pinch and in some cases navigate via voice.  These features require you to reengineer apps to work on mobile devices.

We can say we truly support BYOD when we have business processes running on employee-owned devices.

Be Sociable, Share!
Posted in BYOD, Mobile Applications, Mobile devices, Mobile security and tagged , , , , , . Bookmark the permalink.

Related Posts

3 Responses to BYOD Should Be About More Than Email

  1. Sean McManus says:

    Maribel,

    Good article as it sheds light on the “lunch bag letdown” firms face when they actually start to provide so-called BOYD services to the masses,

    e.g. “…Do you really think desktop virtualization on a [tablet] is the experience your users want? No, what they want is an app that has been designed to work the way consumer apps do. ”

    This affect all endpoints and requires people to think about breaking human habits as well as redesigning workflow and software.

  2. Nukona_Walt says:

    Couldn’t agree more, Maribel. Properly enabling BYOD for e-mail should create opportunities to leverage those devices with business apps. If you’re not pushing that advantage as a company, you’re really wasting a good effort.

    - Walt

  3. Maribel
    Thank you for bringing so much concrete information on BYOD! This creates a huge tête à tête in so many different companies and prevailing silo thinking and authoritarian management often do not understand the power behind it! As a matter of fact the mobility tsunami started with the I-technology is not to be stopped anymore: either mobility will have to be embraced or else company will lose customers, advocate and all together footage and probably for some of them reluctant to the changes their “raison d’être” all together! Kind Regards from over the pond Hamburg Germany!

Leave a Reply

Your email address will not be published. Required fields are marked *


1 + six =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>