随着数字化的发展，很多企业都做起了数字化，你的企业在做数字化吗？数字化的过程中，业务和产品吵架多吗？企业的数字化失败，都体现在哪些方面？本文就此进行探讨，一起来看看吧。
你的企业在做业务数字化吗？
数字化的过程中，业务和产品吵架多吗？
如果答案都是肯定的，那你要小心了，这就是数字化失败的征兆。
你可能嗤之以鼻，毕竟从古至今，改革哪有一帆风顺的。
特别是企业内部协作，哪怕不涉及改革，也总是吵吵闹闹。
这样说也没有错，但你要透过对立的现象，深挖对立的本质。
不同的本质带来的不同的影响程度，最严重的，就会直接导致项目失败。
根据埃森哲发布的《2022中国企业数字化转型指数研究》，我国企业数字化转型取得显著成效的比例仅为17%。所以至少有一大半的企业，数字化项目都无法到达顺利的彼岸。
有鉴于此，企业必须认真对待业务和产品的对立。
以下三种对立的本质和解决方案，供你对号入座。
本质是权利对立，以分工治之。
本质是导向对立，以考核治之。
本质是思维对立，以规范治之。
业务不会自动地开始，也不会自动地结束。
从开始到结束，需要人和人之间的互动来改变现状，以达成业务结果，这就是现实世界的业务推进。我们把这一套交互方式概括为“人-人”，加入系统后，人和人不再直接互动，而是通过系统来传递信息，“人-系统-人”成为了新的交互方式。
譬如你是一家杂货店的老板，原本你向厂家订货，需要联系厂家的销售人员，说清楚需要饮料干杂零食若干，而现在厂家提供一个系统给你，你可以通过系统查看货品信息并在线下单，同样的，销售人员从系统了解到你需要什么产品，你们不再需要互相沟通。
所以说，传统的业务实现是靠“人-人”交互流通，这一过程也被称为线下流程，与之相对的线上流程，依靠“人-系统-人”交互。从线下到线上的过程，就是业务的数字化。
线下流程靠的是不同的业务人员共同推进，他们环环相扣，最终服务到客户。业务决定内部如何协作，外部如何服务客户。而通过系统，显然改变了原有的协作流程，进而剥夺了业务的部分话语权。这就造成了业务和产品之间的根本矛盾。
排斥线上化的业务人员会痛斥使用系统过程中种种不便，仿佛它是阻挡业务发展的最大敌人。同时放大了线上化的过程的负面体验，不会用，不好用成为了业务的常见托词。
反过来产品又可能因为组织赋予的责任，完全站在了业务的反面，强硬的去推广系统。同时也把业务增长归功于线上化，而轻视业务在一线的努力。
线下和线上是服务于同一个目标的不同方法，是硬币的一体两面，需要业务和产品同样付出努力，才能既做好线下，也做好线上。况且线上化是一个以年为单位的大工程，线上和线下的同时运行，也会是一个长期的过程。
所以协调好两者的权力对立，对于现在的业务是否能延续，未来的业务是否能发展有着重要的作用。
那怎样协调这样的对立呢？简单来说就是划地盘，用流程来划分权限。
把产品设计分为两个阶段，阶段A 业务设计 ，阶段B 产品设计。
前者的话语权给到业务，让业务来定义做什么事情，为什么做A不是做B，A的范畴是怎样，业务准备如何去做这样的事情。但注意，如何去做这样的事情并不是让业务拿出系统界面，来告诉产品这里增加一个页面，那里放一按钮，而是抛开系统去描述业务的实际需要。
例如，业务需要做一个客户管理系统，并不是拿着市面上成熟的CRM告诉产品抄一份。而是定义组织内部，什么是销售管理，要管理哪些角色，管理的过程是如何做的，具体要做什么事情，这些事情哪些是需要在系统上操作的，操作后需要保留哪些信息。
这一部分至少需要业务给出业务流程图-角色工作说明书-线上化需求说明书。这些文档模版后续我也会接着分享给大家。
业务给到这些基础信息后，产品接手，开始回到产品和系统的视角来定义这件事情，思考在系统的上如何满足业务的诉求。这里会暴露非常多的问题，例如线下能跑通的事情，你会发现线上就做不到或者需要换种方法做；再例如线下没有的流程，像管理、审批、风控是线上必考虑的要点；还例如线下的流程链路长，涉及角色多，是否需要划分一二三期。
这些问题和解决方案，在后续的文章中，我会接着分享。
总之，把产品设计的过程一分为二，各自确定自己范围的内容和权利，是数字化的基础。
当流程确定，业务和产品都已明确知道自己的权利和责任。
此时更容易发生的问题是在业务诉求本身，以及业务期望的实现方法。
也就是从目标——方案的推导。
这一过程是由业务确定的，但由于业务工作具有强烈的短期导向性。每月，每季度，每年都有各种指标任务，销售考核，大家会盯着各种结果数据全力奔跑，就会想尽办法由目标去推方案。
线下他们或许会采取一些不那么正规的手段，而转到线上，就延伸出一些奇奇怪怪的诉求。
举个例子，除了部分特殊业务，公司要求所有订单都进行线上化，这样客户下单后，公司统一的订单中台能看到所有渠道的所有数据。那有一些既不是特殊业务范畴，现阶段又不能线上化的订单，为了获取这部分业绩，业务希望事后导入功能可以放开权限，在公司不知情的情况下“弄虚作假”。
对于这类明显违规的诉求，产品自然应该拒绝，但还有一些在安全线内但是对长期无益的诉求，产品觉得实现这些需求是资源浪费，只能解决一时的问题，也容易和业务发生争吵。
另外还有一些诉求，业务无法证明方案的有效性，推着需求上线的时候非常着急，但是做好了又因为种种原因搁置，迫于无奈产品做了，最终证明确实是资源的浪费。
作者做过一个统计，在多家受访的企业中，大约有10%的功能上线后会被立即使用，而20%的功能会在3个月内被使用，还有40%的功能会在1年内被使用，而有30%的功能将会长期沉寂，不会为企业产生价值。换句话说，内部系统也好，SaaS也好，至少有3成的需求做了都是无效的。
综上，从业务目标到业务方案，业务会因为方案的合理性，有效性和产品产生争论，主要取决于大家的导向性问题，业务更会倾向于试错，只要完成目标，什么都可以尝试，而产品希望想明白了再去实施。
那怎么解决这个问题呢？用考核。
对于线上化的业务，不应该仅考核业务收入成本等核心数据的达成，也要考核研发资源的利用率。
既然由业务决定了一定要使用A 方案来实现目标，那最后我们就要看A方案带来的效果，以及投入的成本。现实里不乏耗费1个月，几十上百万万的研发费用，1年后回顾，个位数用户，甚至没人使用的例子。
对于产品的考核，适当把业务目标分配下来，让产品去考虑如何使用技术手段帮助业务达成目标，不需要产品像一线业务一样去做具体的事情，但会更积极的利用系统工具去想办法。
好好合作，互相配合可能是一个场面话，但绑定起来的目标能有效让大家站在一起。
业务思维以“我”为主，认为自己非常熟悉客户，熟悉公司内部，于是就能代表客户，代表内部的各个角色去对系统提出意见。
产品思维以“用户”为主，讲究的是以用户整体的特征去推导，去考虑如何设计页面符合客户共性。
曾经有产品告诉我，因为一个图标展示和业务吵了好久，因为业务认为这个图标就不能精准表达业务的定义，而产品不改动理由是：客户没有业务那么专业，是分不清图标代表的款式区别的，表达女装，那用连衣裙和短裙都没有关系，况且这个页面停留时间不足3秒内，图标的作用是让用户快速区别这个选项和其他选项的区别。
面对业务思维和产品思维的对比，我们应该怎么解决呢？
一方面沿用第一部分说的分工，既然是界面上的事情，那拍板就该由产品来做。
另一方面是给到具体的规范。
每个人都不可能全知全能，业务也不应该认为自己就懂全部的，反过来虽然产品拥有决策权，也可以听一听业务给出的信息。针对界面的争论，其实可以用一个巧妙的办法解决，也就是各自去搜集证据，来佐证自己的观点，像竞品的方案，用户交互的规范，用户的反馈都可以成为证据。
大家把证明自己的观点一一摆出来，充分讨论并取得理解。
当然，如果不能取得理解，那还是尊重产品的权利范围。
回顾文本，我们讲述了，企业数字化争论的背后就蕴含着失败的信号，这点从数字化转型的失败率来看，绝不是危言耸听。
同时，我们细分了三种对立，并提出了解决方案。
首要的是权力的争论，这也从流程设计上来划分权利。
在从目标到方案的设计上，由于两者的视角不同，建议使用考核的方法，考核业务的资源利用率，也考虑产品一定的业务达成率。
最后是在具体设计上，在界面和操作范畴，业务和产品有争论时，一方面尊重产品的最终决策权，另一方面注意拿出各种证明各自从理性说话而少用“我觉得”“我认为”“我应该”。
专栏作家
假装是运营，微信公众号：SaaS学姐，人人都是产品经理专栏作家。10年产品，专注B端，负责过行业头部SaaS产品并经历过完整的生命周期。熟悉金融、物流行业。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。