你得小心BYOD这10个陷阱!

简介:

BYOD使员工可以在工作中使用他们自己个人的手机和笔记本电脑——这已经很快得到人们的接受。下面就是当你考虑如何实现自己的BYOD计划时应该避免的10个错误。

1、抵制BYOD

在一个BYOD错误的榜单中这一点似乎是显而易见的,但是抵制BYOD正在成为一个越来越站不住脚的策略。随着计算设备变得越来越个性化,试图操作用户的设备使用用途就好像告诉他们只能使用什么品牌的笔一样。

2、不支持常见设备

只支持有限的设备,或者只支持一个品牌或者操作系统,这听上去很有人;但是,提供更多而不是更少的选择,这是成功运用BYOD的关键。一般来说,BYOD的代价就是用户提供他们自己的硬件和软件支持,因此有限的设备选择通常对于改变支持要求影响很小。同样地,支持常用设备是又有道理的。BYOD应该是不止支持员工自己的手机,一旦有了针对一种设备类型的结构和策略,通常扩展到支持BYOD智能手机、平板电脑和笔记本电脑就十分容易了。

3、选择“NSA”

设备包括从工作相关的电子邮件到亲密照片。只是因为一个管理工具集允许你访问或者监控员工个人设备上发生的一切,这不意味着你就应该这么做。此外,确保对监控工具的使用是受到严格控制的,这一点很重要。这是对员工私隐的尊重,也是一个防止IT在滥用这些工具时可能引发法律纠纷的好方法。

4、不支持原生邮件和日历

一些公司试图以安全性或者管控的名义,强制在员工设备上使用非标准的电子邮件和日历。大多数现代的手机操作系统现在都可以在不同的、安全的“容器”内隔离企业邮件,避免专有电子邮件客户端所声称的好处。而且,依赖于一些不起眼的电子邮件厂商来提供比Apple或者Google更好的电子邮件体验,这是让人很无奈的。

5、试图确保端点的安全

各种BYOD方案争夺的主要领域之一,就是这些方案允许“不安全的”设备进入到企业网络中。但是,不管是否使用BYOD策略,我们都经历了那些最终用户设备被假设是安全且可信的日子。不管是员工自己的笔记本电脑还是企业发给员工的手机,允许最终用户随意进入网络都是一个糟糕的策略。确保应用和基础设施的安全,这样你就不必追逐那些确保最终用户安全的不可能的目标。

6、不促进自助支持对群组是有帮助的

因为BYOD方案通常会吸引那些精通技术的早期采用这,有助于促进这些尝鲜者们提供自助式工具。很多企业创建了内部网络或者发布机制,让特定平台的用户可以发布关于如何设置这些设备以使用企业服务的技巧文章。只是局域网上的几页文章,你就可以让你的员工成为BYOD的一线支持。

7、实行一种“我们不支持这个”的帮助台

BYOD用户面对一个很大的挫折,就是呼叫请求对一个应用问题的支持,结果却被告知“我们无法支持你”,因为用户使用的是BYOD设备。BYOD不应该成为帮助台因为发现员工使用的是个人设备就立即挂掉电话的借口。相反,最初的故障解决应该设备找出这个问题是否与设备、企业应用或者服务有关的。

8、创建移动计划的障碍

BYOD通常是从智能手机开始,对于很多员工来说,智能手机已经有效地取代了座机。作为过渡的一部分,企业雇主通常要求员工将他们的设备转向企业移动设备计划。这是一个很好的策略,让报销对于员工来说是透明的,但是你应该避免让这个过程变得过于繁琐或者昂贵。只签约一个运营商或者要求员工放弃他们的电话号码,这可能会方面你执行BYOD计划的脚步。

9、不匹配的安全风险

尽管允许员工设备使用公司服务是存在一定安全风险的,但是你必须谨慎配合这些风险的安全要求。如果你要求员工安装好多可能会让笔记本电脑速度变慢的安全应用,或者要求设置15个字符的字母数字密码,或者让手机等待30秒钟时间,那就太过了。记住,BYOD的最终目标是让员工使用他们自己选择的设备工作效率更高。当只有很少的敏感数据可能会暴露在风险的时候,提出不合理的安全要求,这通常是有些过分的。

10、没有从中获益

BYOD可能很大程度上被视为一项员工福利,但是对于IT来说也是有好处的。随着BYOD的普及,你可以高效地把硬件和软件支持过渡给你的最终用户和他们的厂商。一屋子的硬件和支持人员可以被一个装着各种充电器和一两台借来的笔记本电脑的柜子所取代。随着BYOD逐渐扎根下来,考虑考虑IT资产如何用户支持企业自己的设备以及被重新部署吧。

本文转自d1net(转载)

相关文章
|
6月前
|
安全 搜索推荐 算法
减少软件故障、防范黑客攻击,软件质量安全问题不容忽视
软件质量的重要性毋庸置疑,而对于开发人员来说,软件质量更多反应的是代码的质量。虽然有报告显示代码质量安全的行业现状显示出持续改进的态势。2022年全年,奇安信代码安全实验室对2001个国内企业自主开发的软件项目源代码进行了安全缺陷检测,整体缺陷密度为10.11个/千行,高危缺陷密度为1.08个/千行。此外,报告还研究了安全漏洞的修复过程,并展望了安全应用的未来,认为应用安全情况有所好转,漏洞的影响范围整体也在下降。
|
4月前
|
人工智能 运维 安全
危机来临,防御性编程能否帮助程序员抵御裁员风暴?
最近,一则关于使用“防御性编码”来应对大公司裁员潮的消息在职场社交平台迅速受到关注。这一策略背后的思路是,通过编写晦涩难懂、难以维护的代码,确保一旦离职,留下的代码难以被替代,从而在一定程度上提升自己的“不可取代性”。 这种方法是否真的能够成为程序员保住工作的"护城河",还是仅仅是一种对心理的安慰?或者只是一种缓解压力的调侃?
|
7月前
combineLatest 使用的一个陷阱和基于 debounceTime 的解决方案
combineLatest 使用的一个陷阱和基于 debounceTime 的解决方案
39 0
关于企业费控管理的这些陷阱,你知道吗?
快速发展的企业对费用管控的关注点应该在费用发生的合理性和有效性!因为,快速发展的企业,很难有一套体系能够适应它的变化,如果有了体系可能也就是限制了它的发展。
8599 0
|
安全
各种安全问题(杂)
StringBuilder 的方法不是线程安全的 由于 StringBuilder 相较于 StringBuffer 有速度优势,所以多数情况下建议使用 StringBuilder 类。
1093 0
|
安全 网络安全 数据安全/隐私保护
|
安全 监控 数据安全/隐私保护
|
安全 数据安全/隐私保护