数字化进入深水区

数字化转型既是当前热点话题，也是个老话题。

多年前就已在提数字化转型，曾经讨论得也无比热烈。只是热过一阵后，逐渐被”ABCD”的风头盖过。

这两年由于国家推行新基建，国家领导人看重数字经济，从而让“数字化转型”再度翻红，成为大会小会的必挂词语。

有意思的是，电信运营商其实一直走在数字化的道路上，数字化的水平相比其它各行业可谓领先，但需响应国家号召，所以依然在大谈特谈“数字化转型”，找出各种对标对象，无论是互联网企业还是传统产业，进行学习借鉴。

抛开政治因素不看，对于运营商而言，更应该树立的是数字化自信，构建自己特色的“数字化升级”之路，不去跟风人云亦云的数字化转型。

设计一条持续向前的数字化升级路线，不断地实现数字化能力水平的跃升。而不是原地转来转去，转得头晕眼花迷失方向。

在延绵不绝的数字化升级的路径上，有三个维度的升级特别需要关注：

一、数字化刻画需要持续升级

数字化的刻画是从物理世界走向数字世界的基石。

过往二十多年的建设，大量的 IT 系统林立，将线下人工生产转化为系统支撑，在处理过程中，形成多维度数据。因为有了这些数据，再加上数据的关联聚合，企业运营的方方面面（客户、产品、渠道、营销、服务、资源等）得以被数字化刻画。

因为有了数字化刻画，更能快捷精准知道运营过程中存有哪些问题，需要如何优化，从而推动运营针对性调整，经营水平不断提升。

对于运营商而言，可能 80%以上的运营生产已经被数字化，但在如下方面依然需要持续改进：

数字化刻画完整度不够：线上系统可通过埋点来感知业务场景下的客户行为，线下则因为数字化程度不够仍存在一些盲点待补齐。例如线下实体触点（厅店），仅能知道厅店的销售数据，无从了解厅店的客流、动线轨迹、对厅店商品的喜好反应等。

数字化刻画更新度不够：即便有了数字化的映射，但数字世界和物理世界缺乏实时对应、存在延迟，进而导致偏差。例如无源资源的采集与对准一直是个难题，从而使得数据的准确性是搞资源人心中长久的痛。

数字化刻画的关联度不够：前后端的流程已被推动在线，但跨域的流程经常难以衔接；各域的数据大多已经在线，但跨域的数据整合存在堑沟，以至很难拼出一块完整的视图；BOM 贯通成为大家的呼声。

从体系的角度，应该针对运营全域，勾勒数字化刻画的蓝图，识别哪些是数字化刻画的空白区、盲点区；哪些是数字化刻画的加强区；不同区域之间的数字化应该能被打通，数据可以自由的流动，数据可以被准确的关联。

完整的数字化体系，应能如同魔方，根据需要，关联整合不同维度的数据，呈现出不同视角的运营画像。

二、数字化运营需要持续升级

如果说刻画感知是数字化基石，那将数字化运营定位为以流程为主线的运营，包括流程的全程设计、流程的高效执行、流程的可视监控、流程的优化增强，应该一点也不为过。

在信息化的早期，是很关注流程的，比如说 eTOM 的全域流程，比如说 CTG-MBOSS 的全域流程框架，在当时，全域流程框架很好地指引了业务推进和系统建设。

但演变到现在，管理形态、渠道触点、网络类型、业务范围均发生很大变化，大大超出原有流程框架覆盖范围，原有流程体系不再具备指导作用。

在这种情形下，大家却并没有意识到重整流程框架的重要性，而是将关注点更多聚焦在能力的提供上。

所以，在各种规划上，看到的是一个个业务能力中心，看到的是 4 层或者是 5 层的 IT 架构，看到是各种 AI 能力的引入。

不能说上述这些内容不重要，但忽略流程来谈上述这些，仿若有着强壮躯干却缺失了灵魂。

数字化刻画需要有蓝图，数字化运营则应有完整的流程体系，并且这个体系需要不断优化不断升级。

运营有三态：设计态、运行态、管理态。

在设计态，应该能规划设计出企业完整的运营流程体系。既要剖析当前流程的断点、堵点，进行衔接和优化；也要做涵盖内外部、前后端、线上线下等企业级跨域全旅程的构思设计。

这样的规划设计，不是在脑海中，也不是在纸面上，而是能被系统数字化承载、被可视展现、被范围传播。

在运行态，流程既被高效调度，也被予以数字化或者智慧化赋能。能力在流程场景中进行针对性编排，能力体系和流程体系进行动态结合。

在管理态，数字化俯瞰全域流程运转。

在传统战场，指挥官通常只能接收前方传来的战报，大致了解战局进展和兵力损失，凭借经验做出指挥。

在现代战场，指挥官不仅能实时接收战报，更能实时了解战局，从而进行精准的指挥调配。

经营管理以前有管理驾驶舱，了解经营数据，做出指挥。但在日趋竞争激烈的局面下，仅凭此已然不够。

在数字化运营进阶时代，企业各域的流程能被动态加载，集成整合到调度指挥中心。管理者基于调度指挥中心，借助对流程的俯瞰，可能直接知晓政企业务开展不顺的关键原因在产品销售过程过于繁琐，可能直接知晓新形态个客销售不顺的关键原因在于营销手段缺乏、营销活动推出周期慢长。

三、数字化支撑需要持续升级

数字化的载体是信息系统，IT 系统确实也走在持续升级的道路上，当然目前依然有关键但少有人关注之处。

IT 系统无论怎么演进，初心是没变的，快速有效地支撑业务发展及业务的变化。

要么是建一个大而全的系统，例如 97 系统，什么内容都往一个系统里装，系统变得庞大臃肿，改一发而动全身，常年处于崩溃的悬崖之边；要么是来个需求可能就建套系统，烟囱系统林立，功能重复，并且不断地在重复建设。系统之间的连接密如蛛网，难有人能理清。

无论是哪种走向，IT 响应业务的周期基本以年为单位。

意识到这个问题后，开始整体规划，系统分域拆分，同域整合。整改之后有效果，局部效率开始提升，但没有走出重功能不重能力的泥潭，过不了几年，又陆续冒出诸多烟囱。

在有了中台成功实践之后，理念进一步升级，开始注重能力的梳理、沉淀、共享以及开放。

各域的功能模块逐渐演变成一个个的业务能力中心，通过服务化的方式构建，能力成为资产，并进行数字化管理。基于能力开放平台来串接和开放。

解决了能力的沉淀和共享问题之后，又出现新的问题：当有成百上千大量的能力被透出时，如何有效使用，成为一个高门槛的事情。

于是，便需要面向不同的业务场景，基于沉淀的各种原子能力进行针对性的动态快速编排，形成模板，打造基于场景的商业能力。

以封装好的商业能力来应对商业场景。这样才能降低门槛，快速应对。

这一步已被运营商所看见，正在逐步推动落地，成效相信会逐渐显现。

但，依然不够。

毕竟即便基于商业能力来构建应用，依然要了解最新的 IT 架构，知晓各类最新的 IT 技术，涉及前端后端开发，门槛还是不低，业务推出周期也许仍然较长。

到这一步，要改变局面，可能就要改变传统的研发模式了。研发在线云，快速引入数字化的能力资产，跨团队整合协同；低代码开发，让通晓业务（而无需精通技术）的人员直接上手推出应用；可视化的软件自动化开发，从设计直接转化成代码，成倍提升效率，并提供更好的维护性。

研发模式的改变，不仅仅充分发挥能力变成数字化资产的价值，更能大幅降低数字化支撑的门槛，以及大幅提升数字化支撑效率。

从而，加速数字化运营迭代，加速数字化进化。

设计好数字化升级的路线，不必跟风人云亦云的数字化转型。

附一个周师傅整理的数字化成熟度模型，用来指引数字化升级，应是不错的参考：