数据赋能业务，是企业数智化的“灵魂”

那么，如何实现数据智能平台与企业业务的高度融合，避免平台和业务“两张皮”呢？可以从以下几个方面着手。

企业的组织架构就是一种决策权的划分体系，以及各部门的分工协作体系，是进行企业流程运转的结构依据。依据职能结构、层次结构、部门结构、职权结构的不同，企业的组织架构可分为直线制、职能制、事业部制、矩阵制等多种类型。组织架构的设计，与企业的人员规模、业务特点、数字化水平等高度相关。

数据智能平台，在架构设计上，要考虑到企业的组织架构，平台架构要与企业组织架构相互配合。组织架构就是企业的“骨架”，业务是企业的“血肉”，数据则是流淌的“血液”。因此，数据平台不仅要适应业务这一“血肉”，还要适应组织架构这一“骨架”。如果两个企业的组织架构差别很大，其数据平台的架构也要做出相应的调整。

需要指出的是，企业组织架构和数智化进程是相互影响的。一方面，数智化系统的架构设计需要参照企业组织架构；另一方面，数智化系统的建设，也会影响企业组织架构的设计。采用大量数字化、智能化系统之后，企业的业务流程、经营模式、管理跨度等要素都会改变，相应的组织架构也需要做出一定的调整。

主要包括两个方面：组织架构扁平化和虚拟组织。

随着数字化程度的加深，企业内部信息流动效率提高，管理跨度变大，这会导致企业组织架构的扁平化。以往需要逐层传达的指令，现在可以通过数智化系统更高效的进行沟通协作，很多中间层级变得不再必要。

根据科斯的理论，市场交易和企业内部协作是资源配置的两种方式。为了完成特定的市场目标，是通过市场交易还是企业内部协作的方式，取决于这两种方式交易成本的对比，这也决定了企业的边界。随着数智化的进一步发展，市场的信息流动效率更高，即使不在一个企业内的个人、团队，也可以很高效地进行协作。这时，社会性的团队协作会更加频繁。在社会化协作当中，虚拟组织会成为实体企业的一个重要替代者。在虚拟组织中，社会上的个人或者团队，利用线上沟通协作工具，基于共同的目标进行协作。其他个人和团队可以随时加入进来，项目完成后组织成员可以快速解散，而不再需要保持固定的组织架构。

总体上看，企业历经信息化-数字化-数智化三个阶段，每个阶段都需要管理方式、组织架构的配套转变，这需要一系列的企业管理创新。在这方面，即使是美国企业也是刚刚起步，中国企业则更是任重而道远。

数据就是企业的血液，业务是肌肉，数据赋能业务的过程，就像是血液为脑细胞、肌肉细胞输送氧气的过程。为此，要建立强健的动脉和细致入微的毛细血管体系。数据智能平台不仅要有合理的技术架构，系统各个功能点的颗粒度要足够细，与业务的匹配度要足够高。数据智能系统与企业业务的贴合度更高，采集到的数据更加详细、准确、全面，实效性更高。

与真实的企业实体相对应，需要在数据智能平台上构建起企业的一个“数字孪生”。企业发起的每一个业务流程，在数据智能平台上都有一个“数据镜像”。每一笔业务，都有数据痕迹。

通过静态数智化（将原有线下业务搬到线上系统，打通不同数据系统，构建统一的数据体系），和动态数智化（新业务完全在线上系统流转，实现业务的实时线上办理），让数据随着企业业务流程一起“流动”。数据流与业务流相互融合，相互促进。业务流不断产生新鲜数据，更新数据流；数据流不断带来新的洞见，优化决策，提升效率，赋能业务流。

如果数据智能平台的功能布局足够完善，可以很好覆盖业务需求。即使很细微的需求，都可以被数据的血液滋养到。这样，才能实现数据智能平台与企业业务体系的高度融合。

雀巢大中华区数智化运输管理系统

员工是企业业务流程的最终载体，也是数据智能平台的直接使用者。员工对数据智能平台的使用率，将直接影响平台价值的发挥。一个看似高大上的数据智能平台，如果员工在日常业务流程中却很少使用，平台本身被撂在一边“吃灰”，那这个数据智能平台肯定就是失败的，充其量是个好看一点的摆设，并不能发挥实际的价值。

事实上，很多企业都部署了各种各样的数据智能系统。企业管理层是从战略角度来要求员工，而员工是否使用数据智能平台，有自己的标准。如果一个数据智能平台不好用，不仅不能提升员工的业务效率，还会增加工作量，那员工会本能地抵制这个平台。这种情况下，即使管理层强制要求全体员工去适应平台，也必然会遇到多方阻碍。

对员工而言，愿不愿意用一个数据智能平台，关键看两个方面：好不好用，有没有用。

首先，数据智能平台一定要好用，员工的学习门槛低，容易上手。如果学习门槛高，甚至还需要一定的IT技能，那无疑会大大阻碍平台的推广。另外，平台功能的设置一定要尽可能“傻瓜化”，符合人们的思维和使用习惯，不要出现一些“反人类设计”。好用、易用的数据智能平台，并不会给员工增添很多负担，也不会增加员工在业务流程中的工作量。这样的平台，员工才心甘情愿去用。

其次，数据智能平台一定要有用，也就是要对员工的业务办理有实际的帮助。通过该平台，可以切实提升员工的工作效率，让员工有获得感。这就需要数据智能服务商在进行产品功能设计时，要从用户角度出发，以满足用户用户需求为目标。不要为了凸显平台的所谓科技格调，设置一些没什么实际价值的“鸡肋”功能。

在此基础上，企业要培养全体员工的数字化办公习惯，在数据智能平台上构建业务流程的闭环。原则上，能够线上办理的就不要线下完成。比如，可以用电子发票，就尽量不要用纸质发票。通过习惯培养，让员工将数据智能平台融入其日常业务当中。

上面提到，员工是否支持，将很大程度上决定数据智能平台是否可以在企业当中推行起来。在产品设计当中，要从用户角度出发，这很多时候都是一句正确的废话。谁都知道要从用户角度出发设计产品，关键是如何实现。

建筑领域有这样一个故事：一栋刚竣工的大楼附近需要修建人行道，但怎样设计人行道的路径才最合适呢？建筑师并不是去推测人们最喜欢的路径，而是在大楼附近种上草，让人们自由行走。没过多久，草地上就形成了一些路径，建筑师就沿着这些路径来修建人行道。这些自然形成的道路，就是最合适的路径。

同样的道理，要设计出用户最喜欢的数据智能平台，最好的办法不是去设想用户喜欢什么，而是去观察用户，收集用户真实的使用习惯，然后按照这些习惯来设计平台功能。在具体做法上，可以在数据智能平台上安装“云探针”，来收集用户使用数据。依据真实的使用数据，可以知道哪些功能是用户经常使用的，哪些功能被束之高阁，哪些功能经常搭配在一起使用。

如果数据是水流，数据平台的功能模块就相当于沟渠和堤坝。平台功能优化的一个重要方面，就是要让数据在这个体系中更顺畅的流动。通过云探针、流量监控等技术，可以知道在数据智能系统中数据的流动路径，发现数据流动过程中的“堵点”。在下一次版本迭代中，就重点打通这些“堵点”。

要实现上述目标，对数据智能平台的开发和部署方式有一定要求。数据智能平台部署在云端，甚至平台本身最好就是基于云原生开发的。云原生的平台，研发更加快捷，版本的迭代、功能的更新也更加迅速。可以通过小步快跑的方式，研发人员与用户形成良性互动。用户使用过程中发现的问题可以很快进行完善，然后通过云端一键更新，用户很快就可以用上新功能。在新功能使用过程中，又会很快产生关于新功能的使用数据，再次反馈给研发人员。对于用户而言，会明显的感觉到数据智能平台的功能设置越来越完善，越来越合心意。

此外，还需要数据智能服务商进行研发体制的变革。用户的使用数据，要能真正反馈到研发端，影响研发计划。研发部门需要建立对用户数据的快速反应机制，能从大量的数据中发现用户使用偏好，并指导接下来的研发进程。

相对于通过用户使用数据来驱动研发，客户自主开发部分功能模块的方式则更进了一步。如果只是数据智能服务商提供的功能组件，用户的创造力就被限制了。用户直接参与功能开发，则可以更大释放其创造活力，将其对业务的理解，融入数据智能平台功能当中。

应该说，以上目标是很有难度的，需要一系列条件，主要包括：

真正的无代码开发。不同行业的用户，其优势在于对业务场景的深度理解，劣势在于IT开发。不能奢求客户都是懂IT，甚至是懂AI的高手。这就对数据智能服务商提出了更高的要求，不仅要提供智能产品，还要提供好用的数据智能开发平台。这个平台要能实现无代码开发，平台本身要有足够完善的功能组件，用户可以通过拖拽式的操作，将这些组件作为“积木”，来拼装出具有复杂业务逻辑的数据智能产品。虽然低代码、无代码开发方式正在迅速发展，但离真正的无代码开发还有很长的距离。大部分软件功能开发，都是有较高技术门槛的，一般的业务人员很难达到要求。

构建活跃的用户模板交易社区，让用户也能赚到钱。要调动用户积极性，最好的办法就是让这件事情变得有利可图。用户通过参与数据智能平台的开发，将自己的业务知识“固化”到平台上，让同行业的其他企业用上自己开发的功能。同时，参与开发的用户，也能获得相关产品的销售和服务收入。这样，就将部分客户变成自己的合作伙伴。对于数据智能服务商而言，不仅可以丰富平台的功能，还拓宽了获客渠道。能够参与功能开发的客户，必然是在业内有一定实力和知名度的企业，让他们参与产品开发和利益分配，间接把这个领域的头部企业变成自己的渠道商，有助于快速打开该领域市场。

需要指出的是，这里所指的用户参与开发，与目前市场上普遍存在的软件定制开发有很大的不同。最大的区别是开发出来的功能是否可以很快复用到其他企业身上：项目定制方式开发出来的产品，与单个企业的业务是高度绑定的，很难复用到其他企业身上；而上面讲的用户参与开发，新的功能可以很方便应用到其他有类似需求的企业身上。

群众的智慧是无穷的，如果可以通过大幅度降低开发门槛，让懂业务的行业客户参与功能开发，数据智能平台与业务的贴合度必将得到很大提升。要做到这一点，除了上面说的无代码开发，还要实现通过功能组件的“解耦”，软件开发的模块化，这对数据智能服务商的技术能力提出了很高的要求。

目前来看，在BI领域，有一些服务商在尝试上述方案。一些行业客户，基于BI厂商的平台，制作一些BI分析模板，比如金融BI模板、零售BI模板等。BI厂商构建线上交易市场，把部分客户开发的BI分析模板放到交易市场，公供其他企业下载。

在其他数据智能细分领域，比如数据中台、数据挖掘、知识图谱、RPA、AI建模等，由于技术门槛更高，用户很少参与产品的开发。不过，随着低代码、无代码、云原生等技术的进一步发展，用户将越来越多地参与到部分功能的开发当中。

以上，是提升数据智能平台与企业业务融合度的一些方法。有些方法难度较低，业界开始出现一些“吃螃蟹”的数据智能厂商，比如通过深化产品功能来构建数据智能平台的“毛细血管”，培养用户使用习惯，通过云探针收集用户使用数据等；有些方法难度较高，还需要等待条件的成熟。比如，数据智能平台与企业组织架构的协同演进，需要企业管理理论的创新，这难度会比较大。真正的无代码开发短期内也很难实现，用户参与功能开发的难度也比较大。

文：凝视深空 / 数据猿

●上一篇精彩好文：

鸿蒙只是半成品，云操作系统才是终极形态