物业线上季演讲 | 常红平：物业数字投入与价值

常红平（融创服务集团总裁助理兼 CIO）：我们经常讲数字化转型过程中的投资和预期的价值往往产生落差，一年到头下来可能实际的数字化建设收益可能不是自己想要的。那为什么会这样呢？我总结大致来自这么几个方面。

首先是要想清楚数字化转型预期的价值是什么？举个例子，物业现在都在做智慧社区，但可能有物企一开始并不是要做全国推广，而是为了品牌宣传效应。后来要做全国推广的时候，可能是希望能够降本增效，能够直接减人。但在真正推广后，会发现很多场景达不到减人的效果，减人就会影响品质，影响满意度。那么智慧社区能带来的真正价值是什么呢？我认为是提升管理效率，它并不一定让一线员工的数量减下来，而是让一线员工都能够按照集团的管理规定执行，从而让全国几千个项目达到品质均好。

第二就是企业投资的组合，不同的企业战略是不一样的，它所处的数字化转型阶段也是不一样的，一开始做信息化，到后面做数字化，每家企业的实现路径也不同。这个投资组合跟我们的企业战略、所处数字化的阶段是有关系的。

还有就是系统开发完，有可能最终的系统不是我们自己想要的。尤其是在一些外包项目上，可能业务部门提一个需求，需求就是一句话，但是细节并没有。找一个外包方做完这个项目之后，验收时才发现外包方提供的东西跟业务部门想要的东西不一样。

但即使需求定得非常清楚，讨论得非常详细，仍然有可能系统上线后用户用不起来。比如说物业管理过程中工单是非常基础的一个系统，但是即使这么基础的系统也并不是所有公司的工单系统就应用得非常好。比如说我们要求所有的报事都要进工单，那么假如我发现一个防火门没有关，我是不是就应该先拍个照片报工单，然后把门关上，再拍个照片去关单，告诉管理者说我完成了这个任务？肯定不是。那我们又如何去避免很多工作应该报工单但没有报，造成体外循环，这个业务的管理逻辑要定清楚，才能实现工单系统的价值。

还有内外部的环境，今年无论是地产还是物业发生了非常大的变化，从一个资本方都追捧的行业跌到了谷底，现在又已经开始在回升了。当内外部环境发生了很大变化时，公司的战略也在发生变化，我们的目标也在变，就更容易就发生投入和预期价值不一样的地方。

其实不止是物业管理行业投入和预期价值产生落差，我觉得各个行业只要在做数字化转型，都会面临这样的挑战。

为什么预期的价值不能实现呢？我们再深挖一下。之前在做信息化的时候好像并没有这么多问题，也没有那么难。因为做数字化要比信息化难得多，我们做传统信息化，无论是上OA、ERP还是CRM，其实都是比较成熟的产品，有成熟的流程，用标准化的套件，IT建设的难度相对是比较低的。但是做数字化不一样，各个企业的数字化的方案和路径都是不一样的，所有企业都是在摸着石头过河。当你看到行业中有数字化做得不错的物企，你照抄行不行？肯定是不行的，因为各个企业都有各自的特点，照抄过来的系统也会水土不服，应该是千企千面。

因为这样一个千企千面的特点，数字化转型就不能依靠外力，或者说仅依靠IT部门来完成，它不是一个交钥匙工程，不是把这个系统交给业务部门就可以了，而是要跟业务部门一起打磨。业务部门要把整个业务流程梳理清楚，技术部门把系统按照业务流程做好优化。

第二，还是因为千企千面，项目的复杂度是以指数级增高的，而实现价值的确定性是大幅降低的。我们是需要一套方法来保证我们在项目执行过程中，始终锚定着价值。

第三，我们身处在VUCA时代，环境变化非常快，有时候项目做完了，你会发现整个项目的环境已经发生了很大的变化。如何才能持续地快速调整，去适应这种变化，这是企业要成功实现数字化转型、在市场中竞争胜出的一个核心要素。

如何破局？根据刚才讲的三个问题，有三个解决办法：第一是业务协同，技术部门要跟业务部门一起协同做数字化转型。第二是我们要持续以价值驱动数字化转型，第三是要建立敏捷组织，通过把整个组织变得更敏捷来应对变化。

分别讲一下这三个点。

业务协同并不只是建立个数字化BP机制，或者搞一个技术部门和业务部门的协同办公就可以了，它并不是那么简单。整个数字化转型过程中，有的项目可能是业务来牵引，有非常明确的业务流程转变的规则，有的可能是技术牵引，通过技术来驱动业务。但无论是谁来牵引，都要保证技术与业务的目标是一致的，要保证力出一孔。同时在目标一致之后，还要在整个项目执行过程中保障这个目标永远是协同一致的，对项目的执行结果，业务部门和技术部门要共担、共赢。

融创服务通过一套叫做数字化KPI的机制来保证技术与业务部门的目标一致、协同。说到目标一致协同，大家可以想下什么是比较好用的目标管理工具，尤其是保证跨部门拉通、跨部门目标一致呢？对，大家可能会想到了OKR。数字化KPI就来源于ORK，但是我把它做了一些调整。

数字化KPI是业务部门和技术部门对数字化系统的业务和技术目标的共同承诺，首先我们先要有一个共同的目标，从业务的视角来看，要达成一个什么样的目标，再把这个目标进行拆解。对技术部门来讲，需要设定产品的建设目标，也就是需要在什么时间点开发出什么样的产品功能，用户体验方面如何保证，系统的稳定性如何保证等等。同时业务也必须要承诺，在产品做出来之后，业务需要把这个产品推广到一个什么样的广度，要覆盖多少项目，或者覆盖多少部门，然后对于产品功能要怎么用，业务流程是什么样的，要不要改变。业务部门通过产品可以具备或者提升什么样的业务能力，或者提升什么业务操作效率。这些目标我们都是量化的。有这些目标之后，我们再来看怎么协同去实现。

从大的方面来讲，技术部门或者数字化部门负责整个数字化转型的方向、路线图，提供适合业务、成本具有竞争力的数字化产品。融创服务的数科部门在做产品之前都要对标，这个产品我们自己去研发，整个成本是什么样的，如果我们去找外包，或者我们去市场上购买，这个成本是什么样的，我们一定要保证自己做的产品的成本一定是低于市场的成本。

同时还要针对数字化产品来提出对业务流程进行优化和人员配置的建议，我们虽然不是业务最终的决策者，但对于业务流程如何优化，技术部门要提出自己的建议。

与之相对的，业务部门要从大的方向提出业务的转型方向，他们要主责业务流程的优化、重构，包括他们的组织如何转型，组织架构是不是要调整等等。

然后要针对每个产品如何使用，制定相关的业务体系文件、业务SOP等等，思考如何最大化地发挥产品能力。

我们还要做到定期复盘。我们现在是每季度会做一个复盘，针对每个产品的目标，晾晒这些量化的产品建设目标和量化的业务目标是否达成了。如果没有达到预期目标，就看到底是哪方面出了问题，是产品的问题还是业务的问题，或者是其他的什么问题，一起来做改进。

第二是价值驱动。价值驱动是指在任何决策的时候都应该是以数字化建设的价值实现为第一优先级。这句话听起来好像是比较稀松平常，大家会说肯定应该是这样呀，但是仔细想想可能并不一定是这样。我们回想一下，当业务部门在提需求的时候，业务部门可能会说，这个我要，那个我也要，这些我都要。或者领导一拍脑袋说，这个项目必须在630上线，或者必须在930上线。再或者我们在做项目招投标的时候，经常是低价者中标，招投标的技术分占比是比较低的。所以我们在实际执行过程中可能就会忽略掉对价值的重视。

所以我们应该是把传统项目转换成敏捷项目的思考模式，永远以价值实现为决策第一优先级。价值是什么呢？价值就是我们产品能够上线，并且能够产生业务价值。

当然还有质量，质量在某种程度上也代表一种价值。这个质量包括产品的外在质量，系统是可靠的，功能是好用的；另外也包括内在质量，系统本身是易维护的，当我们有新的需求出现的时候，能够让这些需求更快地实现。

所有其它的条件，刚才讲到的项目进度、排期、成本，其实都是约束条件。当约束条件和业务价值产生冲突时候，我们更多应该从价值的角度思考，就是要具备价值驱动的意识。

在执行过程中，首先，在判断一个项目的价值的时候，要对齐企业的战略目标。我们每年年底在制定了企业第二年的战略目标之后，要做战略解码，要看每个部门如何配合，以共同达成整个企业的战略目标。战略解码之后，会形成一个清单，投拓做什么、运营做什么、多经要做什么。企业总体的方向是降本增效、还是要增加营收、增加利润，这是首先要考虑的。

这个清单有了之后，就要做再进一步的目标分解。我们就可以使用数字化KPI的机制来看业务部门要做这些事情，这些业务目标哪些需要通过系统实现，就会形成我们的产品建设优先及列表，这就是在预算阶段的目标分解全流程。

预算有了之后，下面就开始执行了，执行的过程中，实际上并不是每一个产品在优先级列表中就默认它会启动，我们还是要在每个产品的建设启动之前，进行正式的立项汇报。立项汇报的目的是，再一次跟业务部门拉齐我们的共同目标是什么，这个目标是以价值为驱动的目标，并不只是产品上线就可以了，所以在立项之前，我们要把量化价值目标定下来。如果我们发现这个量化目标非常难定，可能就是因为这个项目太大，或者这个价值本身说不清楚，或者说还要进一步做一些试点，才能把这个价值讲清楚。或者当项目范围过大的时候，我们可以把它拆成几个比较小的项目分步执行，来保证我们每走一步都能把项目价值讲清楚。

在产品开发试点过程中，业务团队和技术团队要共同对项目的达成结果负责，而不是对计划执行本身负责。比如说我定了个计划，我要在930上线什么功能，达成什么样的价值。上线功能和上线时间实际上是计划的本身，但它并不是计划达成的结果，达成的结果是价值的实现。如果当我们发现在执行过程中发生了一些偏差，要判断如何去纠偏的时候，永远还是锚定这个价值本身，要让这个价值能够尽快实现出来，而不是一定要锚定上线日期或者上线功能。融创服务所有的项目都是用敏捷开发的方式，用短迭代来尽快实现业务价值，来验证业务价值。

产品上线之前一定要经过几个项目的试点，再推到全国。在试点过程中，一定要把我们所预想的业务价值验证通过，在试点项目中确实看到业务价值实现了，再进行推广。而且在推广过程中，我们尽量不用行政命令来强推，当然有些时候我们为了一定效率，可能也会用一些行政命令，但是不能只靠行政命令去强推。我们要让用户能够喜欢使用，尤其是在To C的产品上，要让用户主动喜欢使用。

产品上线之后要持续地运营产品。通过刚才提到的数字化KPI机制，对产品的使用覆盖范围、使用深度、产生的价值等等，不断地复盘，来看它是否达成了预期价值，如果没有达成，还要不断地优化，这样就形成一个闭环。

我们在做产品开发试点、推广运营过程中，如果中间发生了偏差，要重新看产品立项时预期的价值是否正确，中间也可以叫停。执行过程中还要不断对标年初做的预算，可能预算本身也要做一些调整。这是在融创服务的价值驱动的数字化转型全流程。

最后说下敏捷，大家可能也注意到了，前面无论是在讲业务协同还是在讲价值驱动，我都提到了一个反馈环，就是通过持续迭代、持续优化来不断纠偏、试错。很显然我们持续纠偏和试错的频率越快，效果就会越好。在目标不变的情况下是这个样子，如果目标本身发生了变化，就更是如此。在VUCA时代，我们做数字化转型的核心就是在变，内外部环境在发生改变，为了应对这个改变，我们自己的企业目标、业务模式、业务流程、组织架构都要发生相应的调整，才能让数字化转型成功。所以响应变化的速度是企业的核心竞争力之一，敏捷也是提升企业响应速度最佳的方法。

我把敏捷分成三个层次，第一个层次是大家经常听到的，就是研发敏捷。我们的研发团队如何把开发敏捷起来，让我们的产品上线能够更快，这里面会涉及到一些DevOps、自动化等等实践，把需要快速迭代的项目，或者说不确定性非常高的数字化项目从项目制能够变成产品制，然后来提升产品的开发交付速度，降低成本、降低整体项目风险。

第二个层次是业务敏捷，相关的实践有刚才提到的技术业务协同，还有设计思维、精益创业方法等，这些实践保证技术部门跟业务部门协同起来持续实现业务价值，让我们的业务部门能够有能力，低成本快速进行业务试错，以及进行业务模式创新。

第三个层次也是最难的层次，就是企业级敏捷，包括敏捷战略规划、战略解码、整个企业是否可以用OKR方式达到企业级别的协同、力出一孔，包括敏捷组织转型等等。通过企业级的敏捷，实现人才团队的转型，组织架构随着业务模式变化，目标绩效管理的模式也要发生转型，包括财务预算模式是否可以变得更敏捷，还有整个企业的文化，都要发生变革。

刚才总结了应对数字化转型中预期价值不能实现的三个方法：业务协同、价值驱动、和组织敏捷。希望这些方法能够帮助大家来对抗整个环境的不确定性，来争取更多的确定性，让大家的数字化转型有更高的成功率。