|
一边是数字化的宏伟蓝图，描绘的天花乱坠，一边是一地鸡毛，实施的怨声载地。 为什么数字化经常性失败？为什么习惯性雷声大雨点小？
因为数字化不是一件简单的事情，涉及到变革，不是单领域的事，涉及到跨组织、跨业务、从业务到技术的全领域协作。因此需要有全域的决心和领导力，需要有管控方法、设计方法，需要有跨领域能力的人来推动。 本文主要从设计方法角度来看如何将宏伟蓝图落地实现。 首先是数字化成熟度的评估及建议，一般会从业务战略、管控模式、组织职能、流程体系、风险管控、系统支撑、数据资产等维度进行分析提出提升建议，进行业务架构的重塑，信息系统的设计。 然而，管理咨询一般是不懂或半懂技术的，给出的系统及数据方面的建议大多是形式，飘在空中，难以落地，找几个实施商来实施，就从法拉利变成了拖拉机。另外，技术人员也难理解业务层面的建议，没有建成摩天大楼，只是一堆砖头的堆砌。 数字化的根本目标是支持增加收入，降低成本，提升效率，强化生存韧性（应对不确定性）。 因此，围绕以上目标可设计一套指标体系，如收入增加指标里会有提高客户转化率等子指标。 然后，根据指标体系，指导和衡量价值链上的业务能力，如营销里的获客能力，供应链里的协同能力等。 根据能力需求，设计业务流程、组织及管控模式； 到这里，传统的基本的业务架构重塑就结束了，然而，还无法落实到技术支撑。传统的做法就是直接进行需求分析功能设计。如果只是狭窄领域的需求实现，这样是可以的，如果是以数字化的目的来看，这样做缺失了业务价值的转化过程，导致系统只是操作层面的功能，业务价值消失在茫茫代码中。 要解决这个问题，关键的一环就是设计业务服务，业务服务是将业务过程中某一相对独立的业务活动作为业务服务，是业务价值的实现载体，如商品定价、 客户获取等。业务服务中会设计业务目标、业务场景、业务功能、业务流程、业务实体、业务资源、集成关系、扩展机制、运营机制、风控监管10个关键要素。
不对10个关键要素进行分析，只做业务功能层面的分析实现，丢掉了很多业务价值的内容。 这些要素， 有的转化为系统需求，如业务功能； 有的部分转化为线下运行，如业务资源、运营机制等； 有的转化为数据资产，如业务实体； 有的转化为架构设计，如扩展机制； ... 要素不是单一的转化，比如流程会分为线上流程、线下流程，企业内部流程、生态协同流程等。所以，只看线上功能的话，又丢掉了很多线下、跨域的业务价值的内容。 看看，业务价值不是丢在代码里，而是丢在了前面的“业务服务”的设计环节里。 虽然业务服务很重要，但管理咨询不会做这个，实施商也不会做这个。 因为要做好业务服务的设计，需要懂业务且深入业务，懂方法且灵活运用，懂技术且架构设计，是要求高、投入多、衡量难、且很少放在交付物里的内容。 管理咨询供应商、实施商、研发人员无论是从能力，还是自己的投入产出方面考虑，他们从不关心也不能关心业务服务的转化。 而业务服务这块恰恰是数字化落地的要点（腰点，承上启下，没有腰，行动能力大大受限）。 谁来做？升级的企业架构师。 注意，这里的架构师，不是纯技术架构师，而是企业架构师，是懂业务架构、应用架构、数据架构、技术架构、架构治理的企业架构师； 这里的架构师，是升级的架构师，不是传统的企业架构师，因为要解决的是新情况，重点在应对新时代的不确定性，而不是照搬大厂经验，需要认知和方法的升级。 举例来说：
这些不是管理咨询的交付物和考核点，他们想做的是快速交付一个漂亮的ppt交差收款； 这些不是实施商的交付物和考核点，他们想做的只是用最小的成本堆砌起最小需求的功能系统； 这些也不是研发人员的交付物和考核点，他们想做的只是系统快点上线不用加班。 其实，业务服务的设计只是数字化转化的第一步，后面还有重要的应用架构设计、数据架构设计（这里不提技术架构，不是因为技术架构不重要，而是对研发团队来说，技术架构是他们的工作内容，只要是有技术能力且负责任的团队，技术架构不是数字化的难点）。这块内容，在数字化的案例中，往往以业务中台、数据中台的形式出现，供应商拼命的灌输这些概念。对不对？这就像说我们要建设智慧交通，一个劲的说高速公路一样。业务中台、数据中台有它有用的地方，但不是所有地方都是用高速公路来解决交通问题的。有的城市适合建地铁，有的园区适合用班车，而且基本都是综合交通方式来解决问题的。 在出行时，经常会抱怨为什么这个轨道容量设计的这么小，为什么立交桥转晕了，为什么这个车道一直堵车另一个车道空着，这都是规划架构没做好，对应到数字化项目里，就是应用架构和技术架构没做好。 |
|
|
