本数字化转型系列的前面几篇文章中介绍了“什么是数字化转型（WHAT）”、“为什么要做数字化转型（WHY）”、“数字化转型应关注哪里（WHERE）”、以及“如何做数字化转型（HOW）”，本篇则聊一下WHO及与WHO相关的内容：
1. 由谁来主导数字化转型？
- 什么样的组织架构有利于数字化转型？
- 数字化转型组织需要具备什么样的能力？
- 数字化转型需要什么样的人才？
- 如何给数字化转型在组织文化层面和员工能力层面赋能？
2. 由谁来主导数字化转型？
数字化转型与IT关系很大，大家首先想到的一般是应该由CIO来主导，的确有不少企业的数字化转型是以IT为主导的，但正如我们之前所说的，数字化转型与传统的企业信息化不同，需要跨越企业边界，延伸至企业所处行业的整个生态，传统的IT部门主导就会显得力不从心。也有些企业会设立首席数字官CDO（Chief Digital Officer）这样的岗位，以组织业务部门和IT部门推动数字化转型。这些做法都有利于推动企业数字化转型，但由于数字化转型的终极目标是创造业务价值、推动业务模式创新，笔者认为无论是CIO还是CDO，其职责和权限都无法帮助企业实现这一目标，只有具备企业家精神的企业最高长官CEO，其原生的对企业的使命感及其对企业的全面掌舵，才能真正把握企业的数字化转型方向，并持续推动，当然CDO或者CIO则是帮助CEO具体推进转型的不可或缺的重要力量。
其实笔者在此想强调的是，CEO任命CDO或CIO做数字化转型时，千万不能做甩手掌柜而在数字化转型方面懒政，专业的事情全权授权CDO或者CIO去推进，但CEO自身必须把数字化转型作为企业经营战略的重要组成部分，时刻把握转型方向，关注转型效果,并在必要时纠偏。值得庆幸的是，目前有很多企业一把手不管是否有科技背景，但都有强烈的数字化转型意识，把企业的数字化转型作为经营战略中不可分割的重要一环，重点关注。
3. 数字化转型组织架构
一直以来，我们大多处于确定性世界。所谓确定性世界，简单来说就是指事物的发展是有较为固定的发展规律，未来是可预见的，人们可以借鉴以往的经验和已知规律或既定规则去做预测判断。
传统的金字塔形架构及传统管理理论都是基于确定性的假设来制定的，塔尖管理层做决策（做正确的事），塔底员工执行流程（正确地做事），自上而下决策意识和决策权逐层减弱。这些管理模式诞生于100多年之前，当时，失误所造成的成本损失很高，且只有企业最高管理者才能掌握全面的信息。这些管理者的首要目标就是降低成本，确保只有掌握大量信息的少数总裁级人物才有权决策。在这种传统的“指挥——控制”式企业结构中，信息自下而上流动，而决策则由上而下传达。当企业必须一直加速时，这种结构就会失灵，阻碍企业发展。
来源：网络
但是在现今数字化世界，数字化转型过程中的不确定性显著增强，不确定性是常态，很多事情处于不确定状态，没有现有的流程或者解决方案可参照，需要员工从业务价值角度自行去判断并寻找解决方案。企业必须学会在不确定性环境中用不确定性的方式来解决不确定性的问题，正如在此系列专辑的“【企业数字化转型】系列 － WHERE”文章中所讲，数字化转型要求员工职责自下而上由流程执行转向业务驱动，组织高度授权一线员工去做决策（权力下放给战场炮火第一线），这就要求组织由金字塔形向扁平化发展，便于快速决策。
无论是阿米巴（Amoeba）经营模式所倡导的小而美组织架构、亚马逊创始人贝索斯的两个披萨原则，还是前几年比较盛行的合弄制（Holacracy），都体现出扁平化的敏捷团队能够让一线员工成为主角，通过量化授权，充分发挥团队中每个人的创造性和想象力，进而效率大幅提升，快速决策、快速试错，也可大幅降低风险，灵活应对市场环境变化而迅速调整。
（有兴趣的读者，可以深入阅读一下稻盛和夫的阿米巴经营相关书籍。而关于合弄制，可以阅读布赖恩·罗伯逊的《重新定义管理——合弄制改变世界》）
虽然深入程度和成熟度不同，但目前各行各业都在推进数字化转型，笔者认为，数字化转型做的比较好的行业有零售快消及汽车。在我所服务过的客户中，有两家德系高端汽车厂商做的比较好。这两家车企在数字化转型之前，对应于ItO（Idea to Offer）、OtO（Offer to Order）、OtD（Order to Delivery）、DtCC（Delivery to
Customer Care）等各个业务部门， IT部门分别有相应的IT团队支持其IT系统开发和运营，IT和业务部门、IT团队内部各自专注所属领域，相对独立。但近几年为了因应数字化转型的变革要求，他们首先在IT团队内部进行了扁平化改造，员工原有级别体系予以保留，但汇报关系扁平化，另外根据DevOps思想将IT团队内部的系统建设团队和运营团队进行了整合，并在此基础上在重点领域又组建了由业务和IT团队成员参与的数字化转型虚拟团队。令笔者印象最深的是：这样的组织进化使得员工职责自下而上由流程执行转向业务驱动。具体表现在：IT团队不再像以前那样单方面等待和接收业务部门的IT需求，组织供应商进行系统建设以交付业务系统，而是会积极主动地去与有实力的供应商沟通交流，寻求外部赋能，并结合企业内部业务部门的实际情况，向业务部门积极提案，探讨数字化转型的业务场景，以求创造业务价值。
4. 数字化转型组织需要具备的能力
企业的数字化转型能力是指将企业数字化转型策略、场景及项目方案转换成实际可执行的机制和技术平台的能力。传统的项目推进采用的都是瀑布模型（Waterfall）这样的“过关制”(Gate-based Approach)，需要在项目一开始就界定好范围并明确具体业务需求，而后才能进入开发实施阶段，如此一来就需要较长的项目周期，以致于系统建成后即告落后，而数字化转型是业务和技术的联合创新，既不仅仅是新技术在企业的试点，也不是对业务需求的简单被动响应，团队需要具备产品经理思维，运用设计思维的方法，在需求不明确的情况下发现需求，再采用敏捷交付模式（Agile Approach），结合实际情况灵活运用领域驱动设计DDD、测试驱动设计TDD、DevOps等具体的方法论及相应工具，创建最小可用性产品MVP，小步快跑、快速迭代，逐步完善。
在上述提及的两家德系车企中，其IT项目的传统交付模式就是瀑布模型（Waterfall）的“过关制”（Gate-based Approach）。业务部门提出需求，IT部门承接，交由IT供应商开发实施，中间逐步经历业务设计、编码实现（含单体测试）、集成测试、系统测试、验收测试等阶段，各阶段都有相应的关卡（Gateway）会议来判定是否可以进入下一阶段。一般项目都需要半年左右时间内，有的需要一年甚至超过一年的时间系统建设才能完成并投入使用，这显然不能满足业务应对多变的市场的需求。在对组织结构进行调整后，项目推进采用了敏捷推进方式，IT、业务甚至供应商一起共创初步的业务场景（Use Case），确定优先级，快速开发出MVP，交由业务部门使用，并对后续的业务场景进行优化调整，并快速迭代逐步上线，大大缩短了业务部门开始使用系统的时间，也给予业务部门进行需求调整的灵活性。这样的方式对于业务部门来说是大受欢迎的，但同时也给予IT及供应商在项目成本预估及管控方面的挑战。目前还没有完美的应对方案，原则上可以采用工时盒子（TimeBox）进行灵活调整的方式，但前提是双方具有足够的信任程度，同时保持工时消耗评判的透明性和合理性。
关于需求发现，再多说两句。请注意我在这里的措辞是“发现”需求而非“创造”需求。需求是客观存在的，有就是有，没有就是没有，只能被“发现”而不能被“创造”。不知道大家是否了解KANO模型，有过产品经理经验的人都熟知此模型。该模型是受行为科学家赫兹伯格的双因素理论的启发，由东京理工大学教授狩野纪昭（Noriaki
Kano）在70年代末80年代初率先创建并提出，有效地解决了当时日本的产品质量和企业服务提高的难题，后来则由互联网从业者特别是产品经理完美地应用在了产品功能需求的开发上。
此模型将产品的功能属性分成以下五类：
必备属性：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度则会大幅降低；
期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度则会降低；
魅力属性：用户意想不到的需求。如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会大幅提升；
反向属性：用户根本就没有此需求，提供后用户满意度反而会下降；
无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意。
应用KANO模型识别出产品的上述五大属性的功能需求后，首先要全力以赴满足顾客的必备需求，并尽力满足顾客的期望型需求，提供顾客期待的额外服务或产品功能，最后争取实现顾客的魅力型需求，增强产品的竞争性。不在无差异性需求上投入过多精力，并慎重引入反向属性的需求。这里需要注意，对于无差异性需求（如客户无感的数据收集）和反向需求（如产品中降低客户体验的广告），出于运营和商业模式的考虑，有时候是不可避免的，不能一棒子打死，完全摒弃，但是需要慎重对待。
（关于KANO模型的细节，有兴趣的读者可以阅读相关书籍）
数字化转型中的关键一环是创新，而技术洞见能力可以开拓视野、助力创新。技术洞见力可以是内部拥有，但维持成本较高，而且难度较大，一般是通过与外部交流借助外脑，但前提是企业要具备这个意识。
5. 数字化转型需要什么样的人才？
在讨论数字化转型需要什么样的人才问题之前，我想先和大家探讨一下对于“人才”的理解。曾经有位企业家朋友问我:
“你认为什么样的人可以称之为人才？”。当时我并没有给出清晰的答案，大概的意思是说具备相关领域知识和经验，较强的学习能力，具有坚忍不拔的品格等等。现在我可以给出简单明确的答案：能够解决问题的人就是人才。由此类推，能够解决数字化转型问题的人就是数字化转型方面的人才。这个回答虽然有点笼统且有投机取巧之嫌，但回答了问题的本质。
如前所述，数字化转型团队需要具备产品经理思维、设计思维、敏捷开发、领域驱动设计DDD、测试驱动设计TDD、DevOps等具体的方法论及相应工具的能力，很多人也就相应地认为企业的数字化转型只需要掌握以上方法和工具的人才。诚然，企业数字化转型人员需要熟悉这些方法论和工具，此处不再赘述，但是不能简单地认为企业在做数字化转型中只需要熟悉这些工具和方法的人才。原因很简单，这些方法论和工具的掌握可以通过培训或学习来获取，掌握上述方法论及工具的员工只能说是知识型人才，但他们是否就可以解决数字化转型的问题呢？我看不一定。数字化转型不同于传统的信息化，其关键一环是数字化创新，可以说有无数字化转型创意精英（Smart Creative）决定了企业数字化转型能做多深，能走多远。
创意精英必须是复合型人才，不仅需要具备社会心理学、认知心理学、经济学包括行为经济学等方面的知识，懂得如何使用专业工具，出色的逻辑思考能力，也正如Google前CEO艾里克·施密特在《重新定义公司》一书中所述，创意精英还必须具备商业头脑、创造力和实践经验。创意精英有分析头脑，对数据运用自如，可以利用数据做出决策，同时也懂得数据的误导性，不会沉迷其中。创意精英有用户头脑，自身就是“超级用户”，对自己的兴趣并非浅尝辄止，而是近乎痴迷，身先士卒试用产品。创意精英一丝不苟，对细节掌握精确。创意精英充满好奇心，成长型思维，喜爱冒险,不怕失败,独立思考，善于从各处发现问题，自信解决问题的人非自己莫属。创意精英天生具有自驱力，而且心态开放，善于沟通，可以自由地与他人合作。并非每个创意精英都能同时具备以上所有的特质，实际上同时具备上述所有特质的人凤毛麟角，但是，所有的创意精英都必须具备商业头脑、复合型专业知识、创造力以及实践经验这些基本特质。
具备这些特质的团队，可以从战略高度一直到执行落地来解决企业的问题。这也可以解释目前市场上做企业数字化转型服务的公司的动态：传统管理咨询公司如MBB及四大会计师事务所的管理咨询团队将自己的业务向技术层面的落地实施延伸，而传统IT咨询公司如IBM、埃森哲、德勤、凯捷等则也都拥有自己的战略咨询团队。
因此，数字化转型需要具备创意精英的某些特质、掌握数字化转型的方法和工具这种可以解决数字化转型问题的复合型人才。
6. 如何赋能组织和员工？
现代管理学之父彼得·德鲁克把过去200年的组织创新总结为三次革命。第一次是工业革命（Industrial Revolution），机器取代了体力，技术超越了技能。第二次是生产力革命（Productivity Revolution），工作被知识化、标准化，可度量。第三次是管理革命（Management Revolution），知识成为超越资本和劳动力的最重要的生产要素,和体力劳动相比，知识工作者是否努力工作很难被直接观察和测量，而管理的重心转向激励。
未来的组织会演变成什么样，很难看清，但区别于此前的三次革命，未来组织最重要的功能已经越来越清楚，那就是赋能，而不再是管理或激励。甚至可以说，是员工使用了组织的赋能服务，而不是公司雇用了员工，两者的关系发生了根本性的改变。
那么企业应该如何给组织及员工进行数字化转型赋能呢？
在本专辑“【企业数字化转型】系列 － WHERE”篇中，我们提及：企业为了赋能组织和员工，需要进行企业文化的转变（赋能组织）和员工培训（赋能员工）。
在企业文化方面，首先需要在企业中建立成长型思维模式，自上而下渗透，形成成长型思维的企业文化。关于成长型思维本身，是一个比较独立的话题，在此不予展开，笔者曾经在美国接受过这个主题的培训,合适的时候今后我再写文章介绍。同时，需要建立企业的数字化文化，从高层的经营管理者到日常工作层面的普通员工，要形成数字化优先思维，遇到任何问题时，首先考虑如何用数字化的方式解决。
其次，员工职责自下而上由流程执行转向业务驱动。在传统企业中，组织架构大多是金字塔结构，塔尖管理层做决策（做正确的事），塔底员工执行流程（正确地做事），自上而下决策意识和决策权逐层减弱。而在数字化转型的组织中，很多事情处于不确定状态，没有现有的流程或者解决方案可参照，需要员工从业务价值角度自行去判断并寻找解决方案。
为了使员工能够从业务价值角度自行判断并寻求解决方案，具有自行判断的意识和能力，企业需要搭建数字化工作环境和数字化学习平台，并结合前述数字化转型需要的能力和人才类型，在相应领域给员工培训赋能，内容涉及知识层面和方法论层面，方法论的培训一般需要采取实操训练营的方式进行。
到目前为止，我们已经探讨了数字化转型5W1H中的4W（WHAT、WHY、WHERE、WHO）1H（HOW），作为本专辑完结篇，后续会继续探讨最后一个W：“【企业数字化转型】-WHEN”，也就是企业数字化转型的时机，敬请持续关注后续更新。
- End –
【声明】部分图片来自网络，版权归原作者所有。