企业数字化失败，和这件小事脱不开关系

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

你的企业在做业务数字化吗？

数字化的过程中，业务和产品吵架多吗？

如果答案都是肯定的，那你要小心了，这就是数字化失败的征兆。

你可能嗤之以鼻，毕竟从古至今，改革哪有一帆风顺的。

特别是企业内部协作，哪怕不涉及改革，也总是吵吵闹闹。

这样说也没有错，但你要透过对立的现象，深挖对立的本质。

不同的本质带来的不同的影响程度，最严重的，就会直接导致项目失败。

根据埃森哲发布的《2022中国企业数字化转型指数研究》，我国企业数字化转型取得显著成效的比例仅为17%。所以至少有一大半的企业，数字化项目都无法到达顺利的彼岸。

有鉴于此，企业必须认真对待业务和产品的对立。

以下三种对立的本质和解决方案，供你对号入座。

人-人 与人-机-人过程的权利对立

业务不会自动地开始，也不会自动地结束。

从开始到结束，需要人和人之间的互动来改变现状，以达成业务结果，这就是现实世界的业务推进，我们把这一套交互方式概括为“人-人”。

加入系统后，人和人不再直接互动，而是通过系统来传递信息，“人-系统-人”成为了新的交互方式。

譬如你是一家杂货店的老板，原本你向厂家订货，需要联系厂家的销售人员，说清楚需要饮料干杂零食若干，而现在厂家提供一个系统给你，你可以通过系统查看货品信息并在线下单，同样的，销售人员从系统了解到你需要什么产品，你们不再需要互相沟通。

所以说，传统的业务实现是靠“人-人”交互流通，这一过程也被称为线下流程，与之相对的线上流程，依靠“人-系统-人”交互。从线下到线上的过程，就是业务的数字化。

线下流程靠的是不同的业务人员共同推进，他们环环相扣，最终服务到客户。业务决定内部如何协作，外部如何服务客户。而通过系统，显然改变了原有的协作流程，进而剥夺了业务的部分话语权。这就造成了业务和产品之间的根本矛盾。

排斥线上化的业务人员会痛斥使用系统过程中种种不便，仿佛它是阻挡业务发展的最大敌人。同时放大了线上化的过程的负面体验，不会用，不好用成为了业务的常见托词。

反过来产品又可能因为组织赋予的责任，完全站在了业务的反面，强硬的去推广系统。同时也把业务增长归功于线上化，而轻视业务在一线的努力。

线下和线上是服务于同一个目标的不同方法，是硬币的一体两面，需要业务和产品同样付出努力，才能既做好线下，也做好线上。况且线上化是一个以年为单位的大工程，线上和线下的同时运行，也会是一个长期的过程。

所以协调好两者的权力对立，对于现在的业务是否能延续，未来的业务是否能发展有着重要的作用。

那怎样协调这样的对立呢？

简单来说就是划地盘，用流程来划分权限。

把产品设计分为两个阶段，阶段A 业务设计 ，阶段B 产品设计。

前者的话语权给到业务，让业务来定义做什么事情，为什么做A不是做B，A的范畴是怎样，业务准备如何去做这样的事情。但注意，如何去做这样的事情并不是让业务拿出系统界面，来告诉产品这里增加一个页面，那里放一按钮，而是抛开系统去描述业务的实际需要。

例如，业务需要做一个客户管理系统，并不是拿着市面上成熟的CRM告诉产品抄一份。而是定义组织内部，什么是销售管理，要管理哪些角色，管理的过程是如何做的，具体要做什么事情，这些事情哪些是需要在系统上操作的，操作后需要保留哪些信息。

这一部分至少需要业务给出业务流程图-角色工作说明书-线上化需求说明书。

业务给到这些基础信息后，产品接手，开始回到产品和系统的视角来定义这件事情，思考在系统的上如何满足业务的诉求。这里会暴露非常多的问题，例如线下能跑通的事情，你会发现线上就做不到或者需要换种方法做；再例如线下没有的流程，像管理、审批、风控是线上必考虑的要点；还例如线下的流程链路长，涉及角色多，是否需要划分一二三期。

这些问题和解决方案，在后续的文章中，我会接着分享。

总之，把产品设计的过程一分为二，各自确定自己范围的内容和权利，是数字化的基础。

短期导向和长期导向的对立

当流程确定，业务和产品都已明确知道自己的权利和责任。

此时更容易发生的问题是在业务诉求本身，以及业务期望的实现方法。

也就是从目标——方案的推导。

这一过程是由业务确定的，但由于业务工作具有强烈的短期导向性。每月，每季度，每年都有各种指标任务，销售考核，大家会盯着各种结果数据全力奔跑，就会想尽办法由目标去推方案。

线下他们或许会采取一些不那么正规的手段，而转到线上，就延伸出一些奇奇怪怪的诉求。

举个例子，除了部分特殊业务，公司要求所有订单都进行线上化，这样客户下单后，公司统一的订单中台能看到所有渠道的所有数据。那有一些既不是特殊业务范畴，现阶段又不能线上化的订单，为了获取这部分业绩，业务希望事后导入功能可以放开权限，在公司不知情的情况下“弄虚作假”。

对于这类明显违规的诉求，产品自然应该拒绝，但还有一些在安全线内但是对长期无益的诉求，产品觉得实现这些需求是资源浪费，只能解决一时的问题，也容易和业务发生争吵。

另外还有一些诉求，业务无法证明方案的有效性，推着需求上线的时候非常着急，但是做好了又因为种种原因搁置，迫于无奈产品做了，最终证明确实是资源的浪费。

作者做过一个统计，在多家受访的企业中，大约有10%的功能上线后会被立即使用，而20%的功能会在3个月内被使用，还有40%的功能会在1年内被使用，而有30%的功能将会长期沉寂，不会为企业产生价值。换句话说，内部系统也好，SaaS也好，至少有3成的需求做了都是无效的。

综上，从业务目标到业务方案，业务会因为方案的合理性，有效性和产品产生争论，主要取决于大家的导向性问题，业务更会倾向于试错，只要完成目标，什么都可以尝试，而产品希望想明白了再去实施。

那怎么解决这个问题呢？用考核。

对于线上化的业务，不应该仅考核业务收入成本等核心数据的达成，也要考核研发资源的利用率。

既然由业务决定了一定要使用A 方案来实现目标，那最后我们就要看A方案带来的效果，以及投入的成本。现实里不乏耗费1个月，几十上百万万的研发费用，1年后回顾，个位数用户，甚至没人使用的例子。

对于产品的考核，适当把业务目标分配下来，让产品去考虑如何使用技术手段帮助业务达成目标，不需要产品像一线业务一样去做具体的事情，但会更积极的利用系统工具去想办法。

好好合作，互相配合可能是一个场面话，但绑定起来的目标能有效让大家站在一起。

业务思维和产品思维的对立

业务思维以“我”为主，认为自己非常熟悉客户，熟悉公司内部，于是就能代表客户，代表内部的各个角色去对系统提出意见。

产品思维以“用户”为主，讲究的是以用户整体的特征去推导，去考虑如何设计页面符合客户共性。

曾经有产品告诉我，因为一个图标展示和业务吵了好久，因为业务认为这个图标就不能精准表达业务的定义，而产品不改动理由是：客户没有业务那么专业，是分不清图标代表的款式区别的，表达女装，那用连衣裙和短裙都没有关系，况且这个页面停留时间不足3秒内，图标的作用是让用户快速区别这个选项和其他选项的区别。

面对业务思维和产品思维的对比，我们应该怎么解决呢？

一方面沿用第一部分说的分工，既然是界面上的事情，那拍板就该由产品来做。

另一方面是给到具体的规范。

每个人都不可能全知全能，业务也不应该认为自己就懂全部的，反过来虽然产品拥有决策权，也可以听一听业务给出的信息。针对界面的争论，其实可以用一个巧妙的办法解决，也就是各自去搜集证据，来佐证自己的观点，像竞品的方案，用户交互的规范，用户的反馈都可以成为证据。

大家把证明自己的观点一一摆出来，充分讨论并取得理解。

当然，如果不能取得理解，那还是尊重产品的权利范围。

回顾文本，我们讲述了，企业数字化争论的背后就蕴含着失败的信号，这点从数字化转型的失败率来看，绝不是危言耸听。

同时，我们细分了三种对立，并提出了解决方案。

首要的是权力的争论，这也从流程设计上来划分权利。

在从目标到方案的设计上，由于两者的视角不同，建议使用考核的方法，考核业务的资源利用率，也考虑产品一定的业务达成率。

最后是在具体设计上，在界面和操作范畴，业务和产品有争论时，一方面尊重产品的最终决策权，另一方面注意拿出各种证明各自从理性说话而少用“我觉得”“我认为”“我应该”。