历年来IT信息化建设由业务驱动主导的模式，这个模式在数字化很难行得通，更别说智能化了，但多年来的习惯要改变很难，甚至这个习惯还在延续，看看现在我们做的很多数字化的建设，绝大部分还是在做报表、看板、问题发现，是利用大数据的技术提供常规业务功能，能让这些报表、看板的信息更全面、更及时；能让问题的发现更提前、更全面，等，本质上还是业务Owner想看，还是需求拉动的数字化基本技术的使用。

不是说需求拉动就是问题，但公司需要竞争力，才能有希望在市场竞争中获得生存机会，而需求拉动，很难产生重大变革，很难对公司的竞争力产生重大影响。IT若还是以需求驱动为主，那它就成为不了公司数字化转型的战略力量，这个公司的数字化转型也基本遥遥无期。

IT必须要制定技术赋能业务的竞争力的规划，要找到技术和业务的竞争力结合部，既能让当前的业务KPI得到大幅提高，远超业务需求拉动的建设成果，获得业务领导信任和支持，又能让公司产品的竞争力提升，成为公司产品特征的一部分，从而成为公司愿意持续耕耘的赛道，也能让公司数字化、智能化建设成为常态。

是不是有点天方夜谭？太难了，接下来就是我的胡思乱想了。

咱们把业务缩小到汽车供应链业务，找找规律。首先无论业务需求怎么提，业务的基本管理就是PDCA，即Plan、Do、Check、Action，其次汽车供应链业务的KPI聚焦于降本增效，如产销之间的交付满足率、单车制造成本，管理也是围绕这些KPI进行PDCA，具体来讲：

● Plan

P就是年初对这些KPI制定相比于往年更进一步的指标；

● Do

D就是各个基地按照产销计划在精益制造管理体系上进行制造，这是供应链体系的大协同，包括了我们和各个零部件供应商及配套服务商，如运输服务商；

● Check

C就是专门负责检查KPI等指标实际状态的工程师们的工作，利用各类信息化和数字化工具来全面检查，报表、大数据看板、各类例会等；

● Action

A就是物流部、质保部、ME、采购部等众多工程师的解决问题的工作，因为汽车制造的复杂，即使有强大的体系支持，信息化支持，但还是会有预想不到的事件发生，产生损失产能、质量溢出等问题，影响KPI实现，急需解决，这时候需要大批的问题解决人员，用经验来制定行动方案来快速解决问题。

所以PDCA是业务固定的几个阶段，围绕每一个KPI，都有自己的PDCA，而KPI，因为有层层分解，所以有公司级的、板块级的、部门级的、岗位级的，数量极大，业务的运作，实际上可以理解为极大数量的KPI的PDCA交织在一起，就像巨大的烧水壶，一直沸腾。

从PDCA各个阶段的投入人员，A一定是最多的，看看这些部门的岗位设定和工作实际，就可以判断，所以KPI是否能实现，负责A的工程师们是最关键的。

在业务驱动的IT建设中，PDCA的信息化程度如何？D是最多的，C其次，P有一些，而A应该是最少的，因为人员多且来自各个部门，没有明确的业务Owner，也就没有业务需求，所以也就没有信息化建设，更别提数字化、智能化了。当D和C获得每年的关注，不断获得建设投入的时候，A却被冷落了，而A却是业务人员最多的、靠每个人的经验的、没有基本信息化支撑的、和KPI密切相关的、成本和效率不受控的，简直就是吃的是草，产出的是奶啊。A才是更需要信息化、数字化和智能化支撑的阶段，只有这样，才能提炼出问题的根源，去完善P、完善D、完善C，才能真正意义上把PDCA形成闭环，试想一下这个场景：营销的一个提前要车，会涉及到众多零部件的需求变化，该如何把变化转化为成本、时间影响最小的行动步骤，来引导自动化的、或者和人工合作半自动化模式的执行，以规定步骤、规定时间来执行，这个效率是否远胜于人工凭经验来解决。再试想另一个场景，零件报废率高，A阶段的人分析下来根源是装配步骤的问题，那就可以在D的信息系统上加上正确装配步骤的提示，并在该工位的屏幕上用视频的方式提示，从而让操作工快速理解，按照正确的步骤装配，大幅降低报废率，又把信息提供给该工段的质检台，从而提示该信息并要求有一段时间针对性的检查，这就把问题的解决措施和C和D都进行了比较完美的结合。

PDCA四个环节的信息化、数字化及智能化相辅相成，齐头并进，才能把可能发生的问题发现在源头，最快时间解决，从而大幅减少A的投入，也能最大限度地保持高交付率及制造的精益性，从而可以把准时快速交付作为我们产品的特征，也可以把稳定的高质量作为我们产品的特征，从而提升产品的竞争力。

所以基于PDCA管理机制，我们把信息化、数字化和智能化和该机制结合起来，优先布局A环节，应该有机会大幅提升KPI，也能提升供应链赋予产品的竞争力。

A的场景，在交付类型的业务，就是解决执行过程中的问题，即高效解决问题，稳定交付，在产品类型的业务中，就是解决产品用户使用过程中的问题，即高效服务运营，稳定口碑。

那么对于A，数字化和智能化的方案是什么？从场景分析如下几步：

1. 问题推送和接收，需要考虑问题信息如何让接收者快速理解，而且大家都能一致的理解；
2. 问题的推送对象，如何准确？这对解决效率及成本控制都很重要；
3. 如何汇聚有利于该问题解决的相关知识；
4. 如何方便问题接收者开展协同工作，快速联系协作伙伴，快速沟通，如线上会议，快速形成沟通纪要，并按照What、Who、When进行任务拆分、精准推送、时间管理、状态收集；
5. 如何判断问题解决，需要关联D和C的系统，真实获取解决状态；
6. 问题关闭，形成问题报告，度量解决效率，更新知识，更新人员绩效。

以上这些步骤，快速、精准是成功的关键。

逐个分析每一步，我们发现，这对现有的技术平台提出了很多挑战：

1. 技术平台需要能敏捷响应新需求；
2. 技术平台要能快速的与已有系统（特别是核心业务系统）做数据对接；
3. 需要能对企业的业务知识进行智能的生成、存储和检索。

要应对这些挑战，我们需要使用合适的产品或技术。在这里我主要推荐两个：

1. Mendix 低代码开发平台，使用模型驱动的开发方法和可视化编辑器帮助企业快速开发应用，能敏捷响应新需求。Mendix内置丰富的连接器，支持与企业内外各系统进行实时数据同步，从而实现与核心业务系统的快速数据对接。它可以用来应对前两个挑战。
2. 以 ChatGPT 为代表的 LLM 技术，它是一种以神经网络深度学习为基础的自然语言生成模型。它可以对人工智能训练用的海量文本数据进行分析理解，学习企业内的业务知识与术语，然后对这些知识进行智能的生成、存储和检索。 它可以用来应对最后一个挑战。

企业数字化转型是一场万里长征，路上荆棘遍布。许多企业陷入需求驱动的误区，难以取得突破。要找到发力点，企业IT部门必须放眼长远，主动出击，并寻找技术与业务的结合点。  希望通过以上思考和建议，能为企业数字化转型的长征添砖加瓦，起到抛砖引玉的作用。数字化转型，尽在起点！