乐于分享
好东西不私藏

《AI即软件》第二章:我的二十年

《AI即软件》第二章:我的二十年

我在大厂IT部门做了很多年的IT产品经理。
这个头衔在外人听来,大概会联想到互联网公司那种画原型、写PRD、跟程序员吵架的角色。但在一家大型制造企业里,IT产品经理的日常远没有这么光鲜。
我做的事情,用一句话概括就是:翻译。
业务部门的人说:"我需要一个功能,当客户的服务合同到期前三十天,系统自动提醒客户经理去续签,如果客户经理七天没有响应,就升级给他的主管。"
这句话,业务人员说得很自然。但要把它变成系统能跑的东西,我需要做一系列翻译:
"服务合同"是哪个对象?它在系统里的数据模型是什么?"到期前三十天"怎么计算?"自动提醒"是发邮件还是发系统消息?"客户经理"这个字段挂在合同上还是挂在客户上?"七天没有响应"怎么判定——是没有点击提醒链接,还是没有更新跟进记录?"升级给主管"——主管是谁?怎么查?如果客户经理换了人呢?
然后我把这些问题的答案写成一份需求文档,交给开发团队。开发人员看完,再问我一轮问题。我再去找业务确认。确认完了,更新文档,再交给开发。
一个"合同到期提醒"的功能,从业务提出到最终上线,中间经历了多少轮翻译?我数不清了。但我知道,每一轮翻译都有损耗。业务人员脑子里想的那个东西,经过我的文档,再经过开发人员的代码,最终变成系统里的一个功能——它还是原来那个东西吗?
大多数时候,不完全是。
这就是为什么IT需求的实现周期是八周。不是因为代码难写——一个"到期提醒"的功能,纯写代码可能两到三天就够了。八周里,大部分时间花在了翻译上:确认需求、对齐理解、评审方案、反复沟通。
我做了二十多年这个工作。二十多年里,我翻译了成千上万个需求。我翻译得越来越好,文档写得越来越规范,流程跑得越来越顺畅。但我始终有一种感觉:我在做的事情,本质上是在用人工的方式弥补一个结构性的缺陷。
什么缺陷?业务逻辑和机器执行之间,隔着一道必须靠人来跨越的鸿沟。
这道鸿沟,不是靠"翻译得更好"能解决的。

但我不想让这一章变成一篇抱怨。事实上,在我做翻译的这二十年里,我们做成了一件非常了不起的事情。
这件事,公司以及业界,称之为“数字化”,但我,更愿意将它称之为"业务对象数字化"。
让我用我最熟悉的两个领域来解释:CRM(客户关系管理)和PLM(产品生命周期管理)。
在我刚入行的年代,"产品"这个概念在公司里是没有统一定义的。对于芯片设计部门来说,“芯片”是产品;对于操作系统研发部门来说,“操作系统”是产品;对于整机部门来说,包含了芯片、操作系统和各种元器件组合在一起的才是产品;而对于销售部门来说,多种不同的设备、软件+硬件组成的解决方案,才是完整的产品。
“客户”这个概念也是同样的逻辑。销售系统里的客户,是按客户群划分的;服务系统里的客户,是按产品线划分的;财务系统里的客户,是按法人实体划分的。同一个客户,在三个系统里有三个不同的编号、三套不同的属性、三种不同的分类方式。
当销售说"这个大客户去年的贡献是多少"的时候,没有人能直接回答。因为"大客户"在销售系统里的定义和财务系统里的定义不一样。你得先从销售系统里导出客户清单,再去财务系统里按法人实体匹配,再手工合并,再算。
这种混乱,在大企业里是常态。
我们花了十几年时间,一点一点地解决了这个问题。
怎么解决的?抽象。
我们把"客户"这个概念从各个系统中抽离出来,给它一个统一的定义:什么是客户,客户有哪些属性,客户的生命周期有哪些状态,客户和其他对象(合同、订单、服务工单)之间是什么关系。然后我们给每一个客户一个全公司唯一的编码。所有系统不再各自定义"客户",而是引用这个统一的定义。
我们也对“产品”这个概念做了重整,我们将产品做了拆解,最小的是原子层级的产品,再往上有产品族、产品线。原子层级的产品不可再拆解,但是不同部门可以按照业务层级的逻辑进行重新组合打包。
产品、物料、组织、人员、合同——每一个核心业务对象,都经历了同样的过程:从混乱到统一,从分散到集中,从各说各话到全公司一种语言。
这就是"业务对象数字化"。用更技术化的说法,叫"主数据管理"。用更时髦的说法,叫"数据中台"。但本质上,它做的事情就是:把企业里的"名词"定义清楚,管起来,让所有人说同一种语言。
这件事的价值怎么强调都不过分。没有它,任何跨系统的数据分析都是噩梦,任何跨部门的协作都要先花半天对齐"你说的客户和我说的客户是不是同一个客户"。有了它,企业第一次有了一套统一的"数字语言"。
我参与了这个过程。我亲手把CRM里的客户对象、服务工单对象、合同对象,从三四个系统的混乱定义中梳理出来,变成一套统一的数据模型。我也在PLM里做过同样的事——把"产品""物料""BOM""图纸"这些研发领域的核心对象,从各个工程系统中抽象出来,形成统一的产品数据资产。
我为这些工作感到自豪。这是实实在在的成就。

但是,对象统一了,数据通了,语言对齐了。然后呢?
然后我发现,我们解决的是"名词"的问题,但企业运转靠的不是名词,是"动词"。
什么动词?"当客户的服务合同到期时,触发续签提醒。""当图纸的状态变更为发布时,关联的物料启动发布流程。""当采购申请超过五万时,升级到总监审批。"
这些"当……时,做……"的逻辑,才是企业真正运转的引擎。没有它们,客户对象只是一个静态的数据记录;有了它们,客户对象才"活"起来,才会触发服务、触发续签、触发升级、触发一系列业务动作。
这些逻辑,我们数字化了吗?
没有!
它们在哪里?在代码里。
在CRM系统里,"合同到期前三十天提醒客户经理"这个逻辑,写在Java代码的一个定时任务里。在PLM系统里,"图纸发布后触发物料发布流程"这个逻辑,写在一个工作流引擎的配置里。在ERP系统里,"采购超过五万需要总监审批"这个逻辑,写在一段ABAP代码里。
这些逻辑分散在几十个系统中,由不同的团队在不同年代用不同技术实现。它们没有统一的描述方式,没有统一的管理平台,没有任何一个人能看见它们的全貌。
业务对象有了统一的"家"——数据中台。但业务逻辑没有家。它们是散落在代码荒野里的游牧民族。
这就是天花板。
我们花了二十年把"名词"管好了。但"动词"——那些真正让企业运转的规则和流程——却是散的,无法做清晰的描述和整理。不是不想碰,是不知道怎么碰。它们太分散、太多样,隐藏在每一个系统的实现细节里。你不可能把它们全部抽出来,就像你不可能把一栋楼里所有的水管全部抽出来重新排列——除非你把楼拆了。

让我讲一个真实的故事,来说明这个天花板有多硬。
有一段时间,我负责PLM产品的重构。公司的产品线极广——从软件到硬件,从2B的大型设备到2C的消费终端,从芯片到整机,从底层操作系统到上层应用。几十种不同形态的产品,每一种都有自己的开发流程、自己的状态定义、自己的状态变迁规则。
PLM作为产品生命周期管理系统,要管所有这些东西。芯片的设计流程和整机的设计流程不一样,软件的状态变迁和硬件的状态变迁不一样,2B产品的发布审批和2C产品的发布审批不一样。这些差异,全部要在PLM系统里适配。
怎么适配?代码!if/else。
如果产品类型是芯片,走这套状态机。如果产品类型是整机,走那套状态机。如果是软件产品,检查项是这些。如果是硬件产品,检查项是那些。如果涉及出口管制,加一层审批。如果是终端产品,再加一层复用性校验。
一层一层的if/else,堆了十几年。
每一次公司级的管理变革——比如"所有产品发布前必须增加信息安全评审"——都意味着要在这一堆if/else里,找到所有相关的产品类型,逐一修改,逐一测试。一个变革下来,开发团队加班一个月,上线后还是会漏掉几个边角case,然后紧急补丁。
产品团队苦不堪言。
然后,我们在一次系统重构中,发现了一段奇怪的代码。
那段代码做的事情很简单:研发在启动试制加工时,把一个Part(物料)的状态从0改成1,然后再从1改回0。
就这么一个操作。先改成1,再改回0。最终结果等于没变。
没有人知道它为什么存在。
开发团队不知道。我是后面接手的,我不知道。业务部门不知道。数据团队不知道。这段代码没有注释,没有对应的需求文档,没有任何历史记录能解释它的来龙去脉。它就像一块化石,嵌在代码的地层里,谁也不知道它是哪个年代、因为什么原因沉积下来的。
"大概是历史遗留的废代码吧。"重构团队的人说。
于是我们删了它,版本上线发布了。
第二天,生产部门的紧急电话打过来了。他们的计划调度系统无法为正在研发中的产品进行试制加工,系统跑不了了。
排查下来,原因让人很崩溃:生产部门的调度软件,在读取Part状态时,依赖的是一个"状态变更事件"。
生产系统在将Part组合并进行加工生产时,要求Part状态为1。但是,状态为1,标记着这个Part是“已发布”状态。但实际上,这个Part还在研发中,只是启动试制加工,试制出来的产品验证通过以后才允许最终修改为“已发布”的状态,这其实是研发的规则和生产的规则的冲突。
两条规则都没有错。但它们打架了。而没有任何一个系统、一个流程、一个角色,负责"管理"这种打架。
所以,为了解决这个问题,有了这么一段代码:将Part状态修改为1,触发生产的Part组合进行试制加工,再将状态修改回来0,使状态又能够遵循研发对Part状态的定义。
那段"0改1再改回0"的代码,它的真正作用不是改变状态,而是制造一次"状态变更事件",让下游的生产系统知道"这个Part被处理过了,你可以开始试制加工了"。
一个没有人理解的、看起来毫无意义的操作,实际上是一条跨系统的隐性通信协议。
它藏在代码里。没有文档。没有人知道。删了它就炸。

这件事给了我很大的震动。
不是因为它有多复杂——技术上它很简单。让我震动的是:一段承载着真实业务逻辑的代码,在整个组织中没有任何人理解它。它不是被"管理"着的,它是被"遗忘"着的。它之所以还在运行,仅仅是因为没有人动过它。
如果业务逻辑不是藏在代码里,而是被显式地、可理解地描述出来——比如,写成一句话:"Part完成设计后,触发生产调度系统启动试制加工"——那么任何人看到这句话都能理解它的含义,任何人要修改它都知道会影响什么,任何人要删除它都需要经过审批和评估。
但它不是一句话。它是一段"0改1再改回0"的代码。
从那天起,我开始反复想一个问题:有没有一种方式,能让业务逻辑从代码里走出来?不是写在Visio流程图里(那东西机器跑不了),也不是写在Java代码里(那东西人看不懂),而是写成一种人和机器都能理解的形态?
一种"业务语言",直接描述业务逻辑。然后有一个"翻译器"——不,不是翻译器,是一个"执行器"——直接把这种业务语言变成机器能跑的东西。不需要产品经理翻译,不需要程序员翻译。业务人员写出来,机器直接懂,直接跑。
这个想法,后来变成了我的一次认真的尝试。我试图创造一种"流程描述语言"。
那次尝试失败了。
但失败本身,教会了我一些东西。而真正的答案,要到很多年以后,在一个完全不同的场景中,以一种我完全没有预料到的方式,突然出现在我面前。
那是后话了。