企业突破数字化转型黑暗面的关键法则

【51CTO.com原创稿件】如今，越来越多的企业，正在富有开拓精神和领导力的CEO带领之下，开启野心勃勃的数字化转型之路。但是，管理者常常沮丧地发现，不菲的投入换不来显著的业绩提升，反而在“大象”转身的不经意间闪了腰。

2011年，美国通用电气公司（GE）开启数字化探索之旅。从工业物联网到平台经济，从数字主线到数字双模，一路走来，GE数字化路径可谓为无数公司立下经典式范本。

不过遗憾的是，在七年烧完40亿美金之后，GE这家百年老店并未在数字化转型中尝到甜头，反而随着前CEO杰夫·伊梅尔特的离去和跌去一半的股价迎来新的挑战。 

[[224018]]

（杰夫·伊梅尔特）

与GE并称为数字化转型双子星的“全球最佳数字奢侈品牌”——巴宝莉，同样未能走出业绩泥潭的困境。在2017年第四季度，Burberry零售销售额同比下跌2%至7.19亿英镑，如今，昔日奢侈品巨头正因前路未卜以至再次陷入被收购的漩涡。

诸如数字化转型失败的案例很多，而导致了这些失败的原因不外：

缺乏关注业务目标、需求定义不明确、战略方向模糊、预算缩减、管理和架构混乱、工作不稳定以及糟糕的项目和产品管理、甚至体制之外文化和信仰上的问题。

同时，在数字化转型过程中，关于如何建立自然的项目检查点、利益相关方反馈回路以及系统调整机制，企业依然缺乏关键方法。

成功数字化转型项目的七种关键方法

确立项目治理和利益相关方参与机制

在现有的实践过程中,由于对项目利益相关方角色能力界定不清晰或者相应角色的人或部门不具备相应角色能力,从而导致项目任务无法按时完成,而且当出现问题时各利益相关方又不愿意承担责任,相互推诿,严重降低了项目完成的效率。

因此, 确立项目治理和利益相关方参与机制，是建立和维护项目利益相关方之间规制关系的过程,该过程可以减低治理角色承担的风险,为确立项目以及实现项目目标提供可靠的管理环境,项目利益相关方在参与项目时动态地承担不同的治理角色同样也是实现项目目标的重要方式。

逐步实施和启动项目

数字化转型失败往往是企业对大型变革项目太过“急于求成”而导致。这种“一蹴而就”的做法存在种种弊端：

●利益相关方常常在他们了解项目之前事先提出需求，以至于初始开发后改变系统牵涉的方面更加广泛，导致成本增加；

●利益相关方在提出初始要求后常常并不参与实施过程，因此几乎没有时间对项目如何影响其工作有所准备，从而产生抵触情绪。

相比之下，逐步实施和启动的项目会有更高的成功率，在逐步实施的过程中，也更易让用户适应业务变化，从而减少最终用户采用的阻力。此外，逐步实施让企业得以事先投入较少的资金，逐渐衡量投资回报。

用最快、最简明的方式建立可用的产品原型

最小可行产品（Minimum Viable Product，简称MVP）是一种避免开发出用户并不真正需要的产品的开发策略。该策略的基本想法是，快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。 

MVP是最符合敏捷思想的产品迭代开发方法。MVP首先着眼于基本的用户需求，快速构建一个可满足用户需要的初步产品原型。部署之后，通过用户反馈，逐步修正产品设计和实现，最终达到完全满足用户需要。而最关键的是，在各个迭代过程中，做出来的产品始终是可为用户所用的产品，而不是只有一部分功能却不能让用户使用。

鼓励团队学习和采用新技术

从20世纪80年代开始，在企业界和管理思想界，出现了推广和研究学习型组织的热潮，并逐渐风靡全球。美国的杜邦、英特儿、苹果电脑、联邦快递等世界一流企业，纷纷建立学习型组织。

而在数字化转型项目实施的过程中，新技术则需要技术和业务人员共同学习。一方面，开发人员、测试人员和管理员需要尽快熟悉技术。而另一方面，业务分析师、业务发起人和最终用户需要了解该技术可以支持什么。

同时，在项目初次投入之后，早期应用者、乐于接受变革并在内部备受尊重的员工应重点接触项目：他们更有可能成功采用新技术和方法，并可以在企业内部担任变革推动者。如果很难找出早期采用者，不妨制定相关的激励机制。同时为员工提倡为什么需要转型，转型给业务带来的价值和战略机遇。

逐步显示成果，营造发展势头

利益相关方的看法往往会影响整个项目的成败，因此充分利用敏捷开发方法有助于形成良好的发展势头，减少利益相关方的负面看法。

比如说，新的系统可能每季度更新一次，关键利益相关方每隔几周需要看到表明进度的演示版。这些演示版可更加直观的征集宝贵的反馈意见，确保开发的功能否满足业务需求。此外，逐步实施期间进行的小幅修正比全面实施后修正来得更容易、更省钱、更快速。

依赖项优先

大家都知道，并行工作的关键就是要让每个任务处理尽可能没有依赖，这样每个任务就可以单独进行下去。但是，任务之间往往不可避免存在各种依赖项，依赖项使任务的执行变成了串行。

在项目中，每个人每天的任务往往很多，这些任务中有些是独立的，早点完成还是晚些完成对别人没有影响。有些任务是被依赖的，如果自己不完成，他人也就不能完成。依赖项优先的原则就是要求整个团队的各成员树立一个意识：始终优先解决他人对自己的依赖项。一个这样做，还看不出效果；但是如果整个团队都能真正奉行这一原则并落到执行的实处，那么整个团队的协调工作量就会大为减少，整个团队也就会持续保持在较高的工作效率状态。

案例：测试人员A等着需求人员B为其提供一个功能检查清单f 才好对某个模块进行有效测试。那么f 是A对B的一个依赖项。如果B手头的其他事都只影响自己的工作，这是时候需求人员B应该优先完成f，以免测试人员A无法进行自己的工作。

这里也有另外一个问题值得一提，那就是，每个人有应该清楚，如果自己的工作发生了依赖项，除了协调对方尽快去解决外依赖项外，还应该明白，自己绝对不应该就这么干巴巴等着。而应该切换去处理其他工作，一旦依赖项被解除，再切换回原来的工作。

注重组织变更管理和最终用户的采用

需求和技术执行方面要尽量注意与利益相关方和最终用户之间的沟通，并让他们参与起来。系统只有得到部署、采用并创造业务价值，才取得成功。

采用这些方法有利于对利益相关方加强宣传和进行培训，以便了解项目。相比在一次性构建和部署的系统上进行修正，能够根据利益相关方的重要反馈意见进行逐步调整可以确保最终用户采用，同时降低成本。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】

【编辑推荐】