求真务实：系统要落到实处

先说结论

• 要让系统落到实处，我们先到现场弄清业务本来的样子，用现场的原话，让系统里的每一条规则都能在现场找到出处。
• 系统给出的数字要能对账：确认方案时尽量用企业自己的数据走一遍完整流程；APSer-Aps 的排程计划由确定性的约束求解器计算，写回系统之前再做一轮独立复核，大模型只在外围做解说和问答。
• 自研产品写出来的能力，都是我们能交付的；交付什么、怎么验收，签约时逐条写进合同。
• 测试通过、服务在线、页面能打开，都只是中间的一步；验收要在真实环境里用真实单据端到端走一遍。上线之后，先挑最痛的一段跑通、用起来，再往外扩。

青岛艾普仕做企业信息化，有三条价值主张：求真务实、唯有定制、随需而变。这是第一篇。

我们的第一条主张是：系统要落到实处。 一套系统值不值得做，最后看三件事：它反映的是不是这家企业真实的业务，它给出的数字对不对得上，它上线之后有没有被真正用起来。求真，是弄清事情本来的样子；务实，是让结果在现场兑现。

售前演示和概念验证。 售前演示，是用事先准备好的样例数据展示系统的标准流程；概念验证（Proof of Concept，简称 POC），是在签约或全面实施之前，用企业自己的真实数据把最关键的一段流程走通，看结果在这家企业能否成立。在我们看来，售前演示和实际落地之间的差距，多半出在演示里没有出现的三样东西上：企业自己的数据，自己的规则口径，以及日常的例外情形。

这种落差一旦出现，代价并不平均。Bent Flyvbjerg 与 Alexander Budzier 2011 年在《哈佛商业评论》上发表的研究，比对了 1,471 个 IT 项目的预算与实际成本：平均超支 27%；每六个项目里就有一个大幅失控，成本平均超支 200%，进度超期近 70% [1]。这项研究的样本以公共机构的大型项目为主，和中小制造企业的项目规模不同，但它指出的规律值得参考：风险集中在少数失控的项目上，只看平均值会低估它。所以我们主张，把验证放在签约之前，放在企业自己的数据上。

这条主张有它的来处。我们的创始人 2002 年入行，在软件公司做过开发、测试、实施、售前和顾问；2010 年起到一家千人规模的制造业外资企业做甲方 IT 主管、经理，主导过 MES 系统的改造。一边是把系统装进客户现场，一边是天天用系统、管系统，两段经历合在一起，让我们认定一件事：系统问题，归根到底是业务问题。 2018 年创办青岛艾普仕，起因也在这里：想做让客户真正用起来、用得满意的交付，让信息化、数字化、智能化落到实处。

下面分五件事，讲我们怎样把「落到实处」做成日常的做法。

一、怎样弄清业务本来的样子？

系统里的每一条规则，都应该能在现场找到出处。

所以一个项目开始时，我们先到现场，把业务的本来样子弄清楚：订单从哪里来、按什么规则插单，交期按下单日还是按物料到齐的日子算，某道工序为什么要隔夜，同一个词在销售、计划和车间嘴里是不是一个意思。这些口径，很多写在老师傅的经验里，散在表格和聊天记录里，要一条条问出来、对清楚。

我们的习惯是用现场的原话。车间把一道工序叫什么，系统里就叫什么；客户单据上的字段怎么写，界面上就怎么写。业务人员打开系统，看到的是自己熟悉的说法，确认规则时也不必经过一层翻译。

弄清业务，是整个交付里最花时间的一段，也是最值得花时间的一段。AI 让写代码的成本降了下来，判断「这条规则是不是这家工厂真实的样子」，仍然要懂行的人一条条确认。

二、系统给出的数字，怎样做到能对账？

需求讲得再清楚，也要拿真实的数据跑一遍才算数。我们确认方案时，尽量用企业自己的订单、物料和工艺数据走一遍完整的流程，让业务人员在自己熟悉的单子上检验规则对不对。

系统给出的数字，要能说清是怎么算出来的。在生产排程上，我们的做法是：计划由确定性的约束求解器计算。我们自研的 APSer-Aps 生产排程系统就是这样做的：计划写回系统之前，再做一轮独立复核，核对设备兼容、设备与工装不重叠、工序先后等硬约束，复核不通过就不写回。大模型只在外围做解说和问答，回答里的数字取自系统已经算好的结果。这样分工的理由，写在《排程为什么交给确定性求解内核，大模型只在外围工作》里。

同样的要求也放在报表和看板上：每一个数字都能顺着来源查回原始单据，同一个指标在不同页面上口径一致。数字能对账，管理者才敢拿它做决定。

选型时几种验证做法的对照

选型时，企业验证一套系统通常有下面几种做法，能看出的东西各不相同：

几种做法可以组合。越往下，越接近上线之后的真实情况，投入也越多。

选型阶段，怎样把差距提前看出来

1. 写下最痛的一段流程和它的例外。 比如急单怎么插、缺料时怎么办、同一物料在不同系统里叫什么。演示通常走的是主流程，落地的差距多出在例外上。
2. 准备一份自己的真实数据。 一段时间的订单、物料和工艺路线，必要时先脱敏。样例数据是干净的，真实数据里的缺漏和口径不一，才是落地要面对的。
3. 请交付方用这份数据走完整流程。 由业务骨干在自己熟悉的单子上核对结果，因为最有资格判断结果对不对的，是天天经手这些单子的人。以我们的 APSer-Aps 为例：订单可以用 Excel 或 CSV 批量导入，系统逐行校验、识别重复订单、输出异常清单；导入后自动做一次预排试算，只在内存里计算、不写回，对比这批订单进来前后的交期和各车间负荷，再由您决定是否排产。
4. 追问关键数字的来历。 交期、负荷、齐套这些数字是怎么算出来的，能不能顺着查回原始单据。说得清来历的数字，上线之后才能对账。
5. 把交付范围逐条写进合同。 签约和验收以合同里写明的能力与验收标准为依据。这样双方对「交付什么」的理解一致，事后少争议。

三、产品能力写到什么程度？

说到自研产品能做什么，我们守一条：写出来的，都要能交付。

能交付：产品里已经做好的能力直接用；一家工厂需要、产品里还在打磨的能力，在定制交付中按这家工厂的需要实现。演示数据和模拟账套不算作能力，用户可以自行开启的配置项，写成「可以开启」。

写进合同：交付范围和验收标准签约时逐条写清，验收只按写清的来。产品里没有、交付中也做不到的，就不写。

对外文章里的数字同样如此：有出处的给出处，拿不出出处的就不写。客户问到我们不确定的事，我们会直说「不确定」，同时说明打算怎样核实。

如实，是信任的起点。一句写满的话，客户迟早会去核对；所以写出来的能力都要能交付，交付什么、怎么验收，签约时就逐条写清。

四、验收时应该看什么？

一项改动从写完到交付，中间有好几道检查：代码检查、自动测试、上线、真实验收。每一道都有它的作用，我们也都做；但只有最后一道，回答的是「这件事在客户那里是不是真的成了」。

所以我们给自己定了一条规矩：测试通过、服务在线、页面能打开，都只是中间的一步。 验收要在真实环境里，用真实的单据端到端走一遍，亲眼看实际产出的结果：排出来的计划车间能不能照着干，报表的数字和手工核算的是否一致，打印出来的单子格式对不对。代码、测试、上线和验收，分别留下记录，事后可以核对。

这条规矩来自我们自己踩过的坑：自动检查全部通过、汇报说完成了，放到真实环境里一看，结果并不对。原因是用一个临时的小例子，代替了真实环境里的实际结果。从那以后，没有在真实环境里看过实际结果的事，我们都不算完成。

复盘时还有一条值得分清：坏的决定和坏的运气。《权力与预测》一书借扑克选手的说法讲过这一点：好的决定也可能碰上坏结果，坏的决定也可能侥幸过关；只看结果调整做法，久而久之会越调越差 [2]。所以我们复盘一次上线，先看当时的依据和检查是否到位，再看结果。

五、上线之后，怎样让系统真的用起来？

上线那一天，是系统开始接受检验的一天。

我们主张先挑最痛的一段，把它真正跑通、用起来，再往外扩。中小企业的预算有限，只能小步快跑，这是我们 2020 年在一次公开课上讲中小企业信息化难题时说过的第一条；一段真正用起来的系统，是后面每一步扩展的基础。

上线之后的头几个月，是系统能不能扎下根的关键期：员工会遇到新问题，业务会冒出没想到的情形，数据会暴露出原来的疏漏。这时候要有人陪着，把问题一个个接住，把系统调到现场认可为止。系统上线之后由谁照看、要做哪些事，我们在《系统上线之后，谁来对它负责》里专门写过。

以下是我们的看法

以下内容是我们的观点，供您参考。

第一，求真是一种成本，值得付。 多问一句口径，多用真实数据跑一遍，多在真实环境里核一次，每一件都要花时间。这些时间花在前面，省下的是上线之后的返工和信任。

第二，数字的价值在于能对账。 一个说不清来历的数字，再好看也不能用来做决定。能顺着来源查回去的数字，才是管理的依据。

第三，衡量一套系统，看它有没有被真正用起来。 衡量的标准落在每天打开它的人身上：车间照着计划干了，管理者照着报表做了决定，系统才算落到了实处。

青岛艾普仕以制造业深度定制化交付为主业，做过注塑、五金、电子整机、铸造、假发、化工等行业，自研 APSer-One 制造运营管理平台与 APSer-Aps 生产排程系统。如果您希望手里的系统真正落到实处，欢迎预约交流。

---

本系列其它篇：《唯有定制》《随需而变》

参考来源