最近和几位企业创始人/高管聊了聊數位轉型，大家明明都认同它是趋势，但谈及投资又极为犹豫。

一位创始人对他们的状态做了个极为形象的比喻：“（數位化）这东西现在就像保健品，大家都知道肯定有用，但哪种适合我、哪种又是智商税？现在缺的是告诉我分辨它们的逻辑和方法，而不是直接跟我卖药。”

这确实是症结所在，对没经过临床实验的方法，大家都需要观望；病急乱投医的需要见效快的特效药不是保健品；而财大气粗已经买买买过的可能还是以成败论英雄。

结合领导们对“數位轉型”的预期，讲解概念或让立项更容易获得支持，可以从以下三个角度进行回答：

1、经营管理上，數位化如何提高企业对自身业务的运营和管理能力？

2、业务模式上，如何利用市面上已经成熟的互联网能力形成更具竞争力的打法？

3、行业生态上，數位化能力能否帮企业占据主导权？

---

企业经营/管理的數位化

领导第一个疑问大概率就是，公司管理上到底需不需要數位轉型，判断的标准是什么？

一个定性且直观的标准就是：当前组织运营所使用的数据，是否满足管理层“对业务进行评价”和“决策介入时机/方式”的需要。

这么讲可能还是有些抽象，不如用一个TW的模拟案例来讨论企业的管理模型与數位化的关系：

模拟案例：

TW是一家咨询公司，商业模式可以简单的理解为甲方立项与TW签署采购顾问人天的合同，待项目完成后，TW根据完成项目所消耗的实际人天收取费用。

所以TW在经营管理上，就需要协调无数个项目之间对顾问资源需求的冲突，而决策的依据，很重要的一部分依赖于顾问时间安排、项目利润等数据。

以上机制可以被简化示意为下图：

业务团队执行过程的大部分行政工作可以被统一抽象成为企业管理进行“数据采集”的步骤，行政/管理部门对这些采集到的数据再进行“数据处理”，结合实际情况从中得到“趋势/洞见”，最终管理层形成战略/规划：

结合历年数据，TW从营收表现上将项目归纳为3类业务：

业务类型A项目周期长，回款慢，但能保证长期稳定的持续项目；

业务类型B项目周期短，回款迅速，但利润很低，不过有40%能带来C类型业务；

业务类型C利润极高，但强依赖于不同客户、不同年份的预算，以及B类型项目的结果。

而从时间点上看：

业务类型A全年项目数量处于较稳定的低数量；

业务类型B受甲方立项时间影响大，年初极少，年尾聚集；

业务类型C波动介于A、B之间，但其波动对公司现金流影响巨大。

于是TW做出战略调整：

加大对业务类型A的投入，扩大市场；

调整B类业务在年尾的项目侧重为售前，以增强业务类型C的项目延续性；

做出决策后，通过目标拆解使各部门配合执行，最终成果会表现在下一轮的数据结果上。

「目标执行的过程存在很多来自外部的约束，所以企业倾向于在具体执行上放权给业务部门，管理上加强对数据解读的能力，从而衡量和评价业务成果，这也是數位化成为必然趋势的内因。」

那么TW对战略执行时要回答以下问题：

TW管理组织如何界定对业务进行介入的时机和开关？

TW针对不同业务的介入方式有区别么？

TW如何衡量管理行为对业务的实际影响？

如果组织领导也被上述问题所困扰，那么其管理上往往就需要考虑把“數位轉型”作为一种解决问题的手段。

至于數位轉型会如何解决企业问题，首先需要理解企业管理模型与數位化的关系。

管理模型与數位化

对上文TW的案例进行抽象，可以得到如下图所示的管理结构：

这里就需要形成两个闭环：

一是从业务执行的“数据采集”到管理层进行“数据预测”，再根据预测结果介入业务执行过程的“预测环”。

另一个是从业务执行结果的“数据反馈”到管理层根据结果调整管理办法的“反馈环”。

假设TW大部分项目的结算周期为3个月，而企业运作的现金流周转，需要以月为单位对资金进行核算，那么每个月都需要对至少未来3个月的风险进行评估和准备，同时季度、年度、特殊时间点（淡季）都需要根据真实反馈结果调整预测模型或业务策略。那么TW的“预测环”最好小于1个月，“反馈环”则有季度、年度等不同形式

「当“预测误差”不影响管理层对趋势进行判断时，企业就可以根据数据预测实时对业务成效进行判断并调整业务策略，结果反馈则用来定期优化和迭代预测模型，这也是數位轉型在企业管理上成功的形态。」

台灣互联网产业催生出的“运营”岗位就是數位化帮助实现精细化管理的产物，产品设计者通过识别“点击率”、“页面停留时间”、“退出率”等数据与业务的关系评价某一个功能/活动是否对用户有吸引力，一方面将流量更多地引导到粘性内容；另一方面运营人员对产品策略的执行，也有更明确的目标和针对性。

从这个愿景出发，數位化能力当前在企业管理上的主要实践目标可以抽象为：

“通过将数据采集的动作固化到流程和工具上，降低管理成本和人员能力要求。”

比如在TW项目过程里，每个业务团队在执行具体项目时都需要进行的一系列固定动作：

1、项目确认后使用“Margin Tool（项目应收款 - 人力成本 - 差旅支出等）”预测该项目的利润；

2、在“Resource Tool”上创建项目，assign给确定的顾问并锁定其人天；

3、项目执行过程中，顾问定时在“Time Tool”上填写在客户现场实际消耗的人天，在“Expense Tool”上填写报销费用；

这些数字工具即减轻了数据采集因行政成本带来的阻力，也是精细化管理的重要组成部分。

比如TW采集数据的动作，最终就把“顾问”、“项目”和“营收”等数据绑定在一起。企业做管理和绩效设计时，对于注重稳定性和抗风险的A类业务团队，就可以调高顾问工作天数与Margin数据波动的权重；调整B类项目对C类项目的带动作用，就可以调高C类项目数量对B类团队绩效的权重；注重项目延续性和Margin金额的C类项目，就可以调高Margin绝对数值和特定月份项目数的权重。

最终數位轉型过程完成的就是一套将企业“业务执行”、“管理”、“战略设计和执行”结合的管理体系，无论是大型企业或成熟业务的规模化管理，还是敏捷小团队的响应性管理，都可以基于这套体系生长出不同的管理办法。

管理体系和数字工具之间的关系可能是一个“先有鸡还是先有蛋”的问题，从管理视角看面临的问题为“如何设计管理方法”和“管理体系如何落地”，2而转化成數位轉型过程中面对的实际困难则是“采集什么数据”以及“如何保证数据的真实性”。

市面上的3种解决方案

解决这类上述管理问题，当前台灣市场上有三种常见的打法：

传统管理咨询的做法是引入一套标准的方法论和培训，方法论和实践的背后就是一套数据采集和分析的框架，通过规范业务执行动作，让方法论体系下的指标发挥衡量业务成效的作用。

但每个企业有自己的企业文化和各种或浅或显的行为及管理方式，管理咨询公司试图在培训的过程中完成配适企业业务特征的调整，受限于方法论和实践的约束条件，想产生效果往往需要持续的投入（然而企业这种组织形式天生不待见这种ROI充满不确定性的投资）。

数字解决方案提供商的做法是将方法论固化到产品上，配和方法论销售产品（如飞书与OKR）；通过产品配合方法论让用户对产品的使用方式更符合设计者对企业管理的抽象和构想；

又或者鼓吹数据中台，试图全量采集所有数据，指望可以依靠大数据/AI能力代替人完成业务理解。

AI能力或许在未来可以更容易快速地被业务应用起来，但在眼下，受限于技术缺陷、数据采集手段和积累的局限，起到真实价值的实际应用场景并不多。

现在做智能医疗设备的公司，能测量人体健康相关的很多数据，但最终还需要医生配合其他手段来进行解读，AI并不能直接给出建议，一个是因为很多人体特征比如“舌苔颜色”很难采集并量化，另一个是“居住环境”、“饮食习惯”等可能的影响因素加难了判断逻辑。

当前比较成熟的，有诸如在工业领域的设备管理，比如在昂贵的设备上安装一个外接的传感器，采集其诸如“振动频率”、“温度”等数据，然后可以比较容易地实现设备异常状态的监控和预警。

当然很多方案提供商还会强调自己产品的AI能力可以实现故障的自动定位，但本质上还是将有迹可循的一些数据表现与故障相关联，背后的逻辑关系还需要领域专家定义和解释。

更有趣的是，AI发挥作用的依赖，其实正是将领域专家解读数据的过程數位化。也就是“专家在识别某些数据变化，进而给出相应反馈”的这个过程，才能训练AI能力，而不是单纯的靠拥有数据。

數位化管理实践的基本原则

从上述几种市面上较普遍的解决方案上，可以看出“将业务过程产生的数据，与业务结果形成逻辑关系”是數位化帮助业务实现精细化管理的必要条件。翻译成领导常挂在嘴边的话就是：“要加强对业务的理解能力”。

这里也面临着与AI应用一样的难题，采集的数据可能不足以进行解读，或对解读数据的人要求过高，而解决这件事眼下是没有捷径可走的。

一：數位化是过程，不是一套标准答案

当前时代背景下，“數位化”是企业从传统管理模式向精细化管理转型的必要过程，研发數位化工具辅助领域专家解读数据，即是完成數位轉型的必要动作，同时数字工具也会产生更多的数据可以用于补充解读逻辑。

就好比淘宝在有了收藏夹、购物车、收藏店铺等功能后，策略型产品经理根据用户购买商品时使用这些功能的数据，进而判断有什么样数据表现的商品更受欢迎，又可以对搜索权重进行迭代。

“數位化”辅助精细化管理的手段，就是像互联网产品一样在业务过程中采集更多准确、相关的数据。

随着數位化程度的加深和数字工具的使用，用户在系统上操作产生的数据会帮助孵化出更多当前未曾设想过的管理手段和思路。

有这样的洞见后，每次工具/产品的迭代，都可以在用户的痛点中获得更多对业务的理解；每次对用户体验的优化，都是结合管理诉求迭代出更精细管理方法的契机。

比如从TW的B类业务历史数据中发现，当一个项目上对顾问的人天消耗变得琐碎时（过去3周超过10个顾问上过项目，同时每人消耗人天在3天以内），项目结算后实际营收与预测时差距就特别大。

管理上，就需要有能力及时发现类似的数据表现（人工或大数据自动预警），并根据实际情况进行不同方式的干涉；如果每次干涉的结果也都能被数字系统记录，就可以将其中干涉成功的案例/模式沉淀为管理手段，再次有相似数据表现的业务被触发后，就能由数字产品给予建议，从而降低对管理人员能力的要求和门槛。

上述数字管理体系的落地，不能偷懒指望外部力量能够提供一个可以“无脑跟随”的答案。前文提到的3种方案都有各自的局限，组织需要根据自身情况，设计思路和执行方案。

二：从用户视角出发，而非管理视角

虽然是以管理为目的的數位轉型，但出发点还是要以“用户体验”为核心，一方面是降低推广的难度，更重要的是为了保证产品上数据的准确性。

我见过很多从领导视角出发的管理办法和工具，比较典型如手动记录的销售追踪系统：销售进行客户访问后，需要手动在系统中按模版要求记录过程和结果。由于工作量极大，且对销售人员本身没有帮助，所以往往使用率极低，且系统上的訊息也不准确，最终也没办法帮助管理者建立全局视角。

用统计学去解释上述案例中管理者常常陷入的误区就是，“拜访客户数量”与“签单数”有相关性，管理者直觉上容易认为通过对“拜访客户数量”的追踪可以更好地预测团队的工作成效。

如果想将该办法有效的执行，常常是将这个指标加入KPI中，但由于两个数据间并没有因果关系，同时，为了获得“拜访客户数量”这个数据，极大的增加了行政成本，最终很可能会发现“签单数”不见得有正向的变化，而“拜访客户数”与“签单数”的比例则大幅降低。

一个企业管理上的缺陷往往都会表现在其管理所使用数据的真实性上。

所以，數位化要帮助企业实现精细化管理的基本原则就是要“以帮助执行人员提高工作效能为核心设计或挑选數位化工具”。

三：从实践切入，而非直接照搬全套方法论

方法论不能不信，更不能全信。

企业管理是个复杂的系统问题，尤其是对业务领域复杂的大型企业，没有任何一家供应商敢拍胸脯说自己清楚这些大企业的业务全景。

所以各家的方法论说的其实是特定领域、理想情况下的管理办法。最好的例子莫过于，“技术管理领域”现在普遍提倡的敏捷实践和工具。

敏捷（Agile），可以当作是大家在传统瀑布式开发模式下，已经历过验证，并能被普遍接受的一种精细化管理的方法论。

用本文的逻辑看，Scram Master可以当作是敏捷模式里的管理人员，需要决策何时介入开发过程，并对整体进度和阻碍负责；全功能团队这种形式，可以当作是辅助这套方法的一种组织架构；敏捷工具被设计用来支撑和保证敏捷实践和协作效率；数字工具采集的过程指标也可以牵引团队改进实践。

在上述理想的环境下，敏捷的方法论似乎无懈可击。然而问题是，在国内大型企业的研发部门里，这种环境是几乎不存在的，不仅组织架构缺乏全功能团队的空间，业务上也缺乏敏捷的动力。

以手机制造业为例，每年每条产品线只需要发布一款产品，软件作为手机卖点的辅助，也只需要配合着做一次大版本的更新。业务上对研发的要求就是卡着产品发布会的时间节点倒推的，所以产品研发流程上IPD这种卡着时间节点验收的流程就被广泛采用。

在这种环境下，敏捷工具和方法论很难起到作用，我们最常看到的现象就是把敏捷工具硬生生用成了审批工具：

策划在线下用Word写需求文档，在验收节点前把整个文档上传并设置交付deadline；研发与策划线下对接，根据自己对需求的理解，单独再维护一份技术Task的excel；技术组长分配Task给不同的开发人员，在deadline之前才一起做合并，全程脱离敏捷工具，仅在完成后将需求状态改为“已交付”...

在这种实际业务对工作方式要求与敏捷环境有差距时，越是标准的敏捷工具，反而越难被团队应用起来。工具上的数据不仅不能被使用，整个管理办法也会向着给研发人员增加负担的方向跑偏，而不是帮助提高效率，甚至由于存量指标的积累，加剧团队调整的难度，甚至各种管理手段都无法生效。

更合理的做法不是一开始就搭建好管理体系和工具，而是找到一个切入点，牵引团队建立一套work的合作模式，然后以此为基础，用过程指标牵引团队一点点改进关键问题。

这个切入点就可以从敏捷实践中去找，比如先把依赖相对最轻的需求管理尽量做标准，通过需求进入不同阶段的相应数据建立团队管理办法。

方法论工作往往都存在前提，忽视这些前提照搬方法论，以试图规避设计一套配合组织文化、业务特点的管理体系，往往会导致各协作环节相互“锁死”而积重难返。不如从优秀实践出发，一点点构建适合团队特点的管理模式。

數位化管理的执行路径

遵循上述原则，可以归纳出企业管理數位轉型的落地步骤：

一，利用市面上现有的产品，以帮助执行人员提高工作体验为核心把一系列工具先使用起来；

二，将工具的产出和数据通过协作软件或权限体系沉淀到自己的数据能力中；

三，从核心业务出发，逐渐打通上下游工具，从管理体系设计思路出发形成工具链；

四，迭代工具链和实践，让团队使用工具的方式与企业管理体系更匹配。

由于国内2B领域SaaS发展远弱于2C产品，大部分业务领域都缺少好用的产品，如welink、钉钉这些产品就没有动力做开放的平台，大型企业在工具上往往一开始就选择自建（这也可能是前文许多问题的根源）；

至于小微企业，条件允许的话，可以多考虑一些国外的SaaS产品。

与国内封闭的生态不同，国外2B SaaS产品的趋势之一就是开放，Slack的崛起，不得不说很大程度上归功于此。

通过与第三方及内部构建的软件应用程序的集成,Slack 的用户能够轻松地访问来自其他应用程序的訊息,并在其渠道中进行交互。这提高了 Slack 用户的工作效率,并增加了其他软件程序的价值。例如,用户可以通过Slack获取在 Salesforce 中存储的客户訊息，或通过Slack 获知GitHub部署状态的更新。

这样的产品形态，不得不说一定程度上也符合本文构建數位轉型的路径，只不过是通过开放的生态由不同的软件企业共同推进了整个社会的數位轉型。

办公软件另一个趋势就是从客户端向云端的转移，从早期google doc对Microsoft的逐步取代，到近几年越来越多专业性软件/服务（尤其是软件研发相关）都由云端能力提供，比如ux软件从sketch到figma，和竞争更激烈亚马逊云、阿里云提供的软件研发相关服务；

很有可能未来的企业IT不再需要专人来进行维护，公司资料的安全也不需要进行电脑上的物理隔绝，所有的工作都通过企业账号在云端完成。

更重要的是，所有员工从入职开始便习惯于所有的协作通过云端工具完成，而不会脱离工具，组织的协作方式自然会受工具的影响，配合工具的使用方式调整管理方式（數位轉型被工具牵引完成）。

台灣自有自己的国情，完成整体的數位轉型现在看还为期尚远；希望走在前面的企业和产品公司，能从欧美该行业的集体选择上尽快找到自己的出路。那时，企业管理的數位化就不再是个成本高昂的问题。