在深圳做企业AI数智化转型服务商，过去三年我见过最多的场景，不是算法不够先进，而是客户请了一堆系统，却没留出一条让数据走通的路。CRM、ERP、MES、WMS全都上了，财务、销售、生产却各自为政，等AI项目进场时才发现连最基础的客户编码都对不齐，模型训练用的数据样本七零八落。最后花几个月搞出来的智能预测大屏，业务部门瞄一眼就再也不碰——这就是我们常说的“系统孤岛”加“AI摆设”。

这篇文章不打算讲一堆抽象概念，而是把这两个问题的成因、识别方法和落地路径说透。尤其适合三类人看：正在做数智化选型的企业管理者、负责数字化转型的项目负责人，以及服务商里负责售前和实施的项目经理。无论你是甲方还是乙方，只要不想让钱白花，下面这些内容都值得认真读完。

1. 先搞清楚：系统孤岛是怎么把你的AI项目拖垮的

1.1 孤岛不是偶然，是一笔笔“合理采购”堆出来的

很多深圳企业，尤其是民营制造和外贸型企业，从来没有做过整体架构规划。销售觉得客户信息管不好，先上一套CRM；仓库积压严重，搞了一套WMS；生产交期混乱，车间申购了MES；财务月底对不上账，又补上了ERP。每一套系统在采购当年都是“合理决策”，问题是没人会在买系统时问一句：它跟其他系统怎么对接？

结果就是典型的多系统并存。我接触过一家电子元件工厂：销售下订时在CRM里录一遍，计划员在ERP里再录一遍，车间拿着MES工单排产，三者之间的订单号规则还不一样。月底想算某个客户真正贡献了多少毛利，财务只能从三个系统里导数据到Excel，再手工拼。这里有个很土但特别准的判断方法：去客户月度会议看看，有多少张报表是靠人工从不同系统导出来拼接的。只要这种手工Excel比系统自带报表还多，孤岛问题就不是某一套系统的毛病，而是整个信息化建设的结构性缺陷。

还有一种孤岛是“时间错位”。有的系统早就实时刷新了，有的还停留在T+1凌晨同步。计划员早上九点排产时，看的还是昨晚的MES快照，中间车间却发生了换线、停线、插单，排产依据已经过时一两个小时。在深圳这种“昨天谈需求、今天要交付、明天要上量”的订单节奏里，这种误差足以让任何AI预测失去意义。

1.2 孤岛是如何具体“杀死”AI项目的

AI项目的本质，是从一堆历史数据里找规律，再把这规律实时应用到新数据上。前提是历史数据要全、要准、要同一口径。孤岛状态下，这三个条件几乎全部被破坏。

一是数据不全。客户的退货单在售后系统里，质量部门的返工记录在Excel里，订单主数据在ERP里。模型想学习“什么样的客户容易退货”，特征散落四处，根本拼不出一张完整的分析表。二是数据不准。同一个“订单状态”，ERP里可能已经标成“已完成”，MES里却还在“生产中”，因为两边更新不同步。拿ERP的标签去训练模型，等于拿错误的答案教学生。三是口径不一致。含税价、不含税价、销售单位、库存单位、主单位，一旦开始没对齐，后面所有特征工程都是空中楼阁。

我在项目里常跟客户讲一句话：AI模型就像一条饥饿的鱼，你要先让鱼塘的水流动起来、把水质管好，再谈投喂算法饲料。孤岛状态下的AI，大概率只能做两件事：一是拿局部数据做“自嗨式预测”，效果图看着很华丽，放进真实决策环节一碰就碎；二是靠人工导数据再手工跑模型，AI沦为高级计算器，连摆设都算不上。

2. “AI摆设”的三种常见病，你中了几个

2.1 演示型AI：发布会结束就吃灰

很多企业对AI的期待，是“老板来视察时有一个大屏能展示智能预测曲线”。于是服务商快速做个驾驶舱，配几条AI预测趋势线，演示现场很有冲击力。可上线三个月回访，登录人数只有两三个，还集中在IT部门，业务人员从不主动打开。这种我称为“演示型AI”。

识别方法很简单，打开系统日志看几个维度：每周活跃用户数、核心功能点击次数、预测结果被查看次数。如果这些指标持续走低，基本可以断定系统已经沦为汇报工具。更扎心的做法是直接问业务人员：“你上次看这个预测结果是什么时候？”如果答案是“上线培训那几天”，那它就是在吃灰。

2.2 花瓶型AI：指标好看，业务数字没变化

还有一种项目，模型精度很高，预测曲线非常优雅，但企业的收入、利润、交付率、库存周转率没有任何改善。这种我称为“花瓶型AI”。原因很典型：预测得到的结果没有触发任何业务动作。

举个例子，模型预测某款物料未来两周会缺料，预警也推送给采购员了，但采购员没有权限紧急调拨，系统也不会在预警之外自动生成采购申请单。结果缺料还是缺料，只是缺料之前系统就“知道”了，但没人被要求处理。破解办法很简单：AI建议必须转成业务动作。预警不只是发消息，要自动派发任务工单、规定响应时效、超时自动升级。算法负责指出问题，流程负责解决问题，两者必须闭环。

2.3 报表型AI：只展示问题，不解决问题

第三个常见形态是报表型AI。企业以往做可视化大屏，现在换成“AI增强分析”，自动生成文字结论、异常归因，看起来很智能，但本质上还是报表。系统告诉你“订单A可能延迟”，却不告诉你“要不要调整优先级、调整哪道工序”，它只是把事情说出来了，没有把事办了。

真正能创造价值的AI，必须嵌进日常运营动作里。它可以是自动化的库存再平衡建议，可以是排产引擎推荐的最优产线方案，可以是质检模型直接拦截缺陷图片。判断标准其实很朴素：没有AI之前和有了AI之后，一线员工的操作方式是否发生了实质改变？如果没有，技术指标再好看，也只是升级版看板。

3. 告别孤岛和摆设：服务商落地的四条主线

3.1 摸清系统家底，画好数据流转图

任何一次AI数智化转型，都不建议从算法开始。服务商进场后的第一个星期，应该先做一场“数据摸底”。不要只坐在办公室里看甲方提供的系统清单，那些清单经常过时半年；一定要去财务、仓库、车间、客服工位现场问三个问题：你日常做决定要打开哪些系统？有哪份数据是你手工整理的？哪份报表你最不放心？

把回答整理成数据流转图：从客户下单到交付回款，识别每一环节产生的数据、存储在哪个系统、更新频率如何、是否存在手工补录。很多企业的真实流程里，Excel和微信才是高频数据通道，ERP反而是事后退账。这张流转图画出来，孤岛在哪、断点在哪，基本一眼可见。

这里有个服务商特别容易踩的坑：只依赖IT部门的接口人。IT部门能告诉你系统有什么表，但未必知道业务实际怎么用。一定要安排业务侧访谈，至少覆盖销售、计划、采购、生产、仓库五个岗位。只有把一线的人调动起来，后续推进数据治理时才有“同道人”，而不是全公司都在配合一个外包团队表演“数智化”。

3.2 数据治理：先统一主数据，再谈特征工程

很多项目死掉，并不是死在模型选型，而是死在数据没洗干净就开始调参。数据治理不必追求一步到位，但上线场景所依赖的数据域，至少得达到“可用”状态。我理解的可用，要满足三个统一：编码统一、口径统一、质量统一。

编码统一最折磨人。同一个客户，CRM里叫“客户编号10086”，ERP里叫“CUS_1008”，Excel里可能又写“某某电子厂”。解决办法是建一张主数据映射表，把所有来源的ID关联到一个统一客户维度。物料也是这样，有的按规格编码，有的按型号编码，有的把父子件拆开单独编码。在跑AI分析前，得先用清洗脚本把重复、大小写、空格问题全处理掉。

口径统一主要指金额、数量、时间的口径。例如采购单价与含税价要不要区分？原料单位是按公斤还是按个？一线填写的日期是提交时间还是计划时间？这些细节看起来很低级，但如果定义不清楚，训练样本的标签一定会出现偏差。这里我建议用增量清洗代替一次性全量清洗：每天对新增数据做质量规则校验，每周补跑一次历史数据修正脚本。清洗任务里的异常记录，全部落到数据质量监控表里，由专人在每周出具处理规则。数据清洗不是一次性项目，而是长期运维机制。

下面是一个洗数据的伪代码示例，逻辑上基本覆盖了日常最常用到的三步操作：

# 伪代码：订单明细清洗示例 import data_toolkit as dt raw = dt.read_source("ods_order_line") # 1. 去重：同一个订单行只保留一条推最新状态的记录 raw = raw.drop_duplicates( subset=["order_no", "line_no"], keep="last" ) # 2. 字段标准化：物料编码去掉空格、转大写 raw["sku_key"] = raw["sku_code"].str.strip().str.upper() # 3. 过滤异常值：数量、金额不可能小于等于0 raw = raw[(raw["qty"] > 0) & (raw["amount"] > 0)] # 4. 落库到清洗后的明细表 dt.write_target("ods_order_line_clean", raw)

3.3 用统一数据平台沉淀数据资产，避免点到点蜘蛛网

打通孤岛不是简单地把A系统数据接到B系统。如果每个需求都做一个点对点接口，系统之间的连接会变成一张蜘蛛网，后面想改都不敢改。正确做法是引入一层“统一数据平台”，所有原始数据先抽取到中间层，再按统一标准清洗、存储、对外提供数据服务。

对多数深圳中小企业，我个人不建议一上来就搭几十个节点的超大数据中台。更稳妥的方案是“轻量数据仓库加API服务层”。原始数据通过开源同步任务定时或准实时入仓，明细表做成ODS库，在此基础上加工成主题宽表、聚合指标表。对外，统一由API服务层提供接口，业务系统要数据不再直接连数据库，而是调用API。这样既解耦了系统依赖，也让AI训练时拿到的是单一、稳定、可追溯的数据源。

选型层面的原则是：别盲目追大厂全家桶，先看自己的团队能不能维护。如果企业未来只有两三个AI场景，一台高性能服务器外加开源组件就足够支撑。更关键的是把“数据地图”和“血缘关系”这些基础管理做起来，否则平台建完三个月，没人记得每张表是干什么的，治理又会重新乱起来。

3.4 小切口起步，让AI在业务流程里长出来

数据装备好了，不要一上来就做“企业级智能大脑”。我管这种想法叫“雄心下得太早”。务实的做法是选两三个小切口场景，先跑通一个闭环再说。

小切口的选择有三个标准：高频发生、痛点明确、数据积累足够。比如订单交付风险预测每天都会发生，痛点直接是罚款；智能问答客服每次客户问询都会触发，痛点是人手不够；视觉质检每次生产测产都会触发，痛点是不良率。选定切入点后，必须设计“决策闭环”：模型输出的结果要直接进入业务系统，生成待办、开单、告警，而不是等某位领导想看了再打开大屏。

我把这个阶段叫“让AI先活下来”。一旦某个小场景在真实业务里跑通，并产生可量化的收益，企业内部对后续扩展的信心会完全不一样。接下来再从一个点径向复制到更多场景，比如从订单交期预测扩展到采购齐套预测、产能规划、库存健康度分析。

4. 一个可复现的落地案例：交期预测如何从孤岛数据里长出来

4.1 场景与企业现状

为了不让前面的内容变得太干，我还原一个比较有代表性的项目骨架（企业信息已泛化）：深圳一家电子元件制造企业，产品给通信设备做配套，2000人规模，年营收大约3亿元。它的问题很典型：销售在报价交期时基本靠几个资深销售和计划员拍脑袋；车间插单频繁，计划一变，承诺全乱。最终交付逾期率最高冲到27%，客户投诉和违约成本非常难看。

这家企业的系统状态也很典型：CRM管客户资料，ERP管订单和采购，MES管车间工序，WMS管仓库。四套系统之间没有统一接口，订单号在CRM、ERP、MES里规则各不相同。此前另一家服务商给做过一套“智能驾驶舱”，号称能做交付预测，但因为数据只从ERP取，没有MES和WMS的实时进度，预测结果一放到真实订单上就失真，半年后默默下架。这基本上把前面说的两种病都占齐了。

我们入场后，先用两周做系统摸底和业务访谈，画出订单从创建到关闭的完整流程，找到所有手工转运数据的节点。核心问题被锁定为：销售承诺交期之后，计划、采购、生产、仓库的执行信息不能实时反馈回来，所以预测无法及时更新。这个判断直接影响后续数据方案的设计。

4.2 数据集成和数据治理的具体实现

项目的落地遵循先抽取、再清洗、再映射三大步。先把四套系统的核心表按“每日全量加增量”策略抽取到统一的ODS层。MES这类对实时性要求较高的系统，用变更捕获方式让生产进度表能在五分钟内进入数据仓库；ERP、CRM则保持T+1批量同步，降低成本。

ODS层先建两张核心明细表：一张订单行项目明细，一张生产工序进展明细。订单行包含订单号、行号、SKU、数量、承诺交期、计划完工日、实际完工日、客户维度、产品系列等；生产工序表包含工单号、SKU、工序号、计划开工、计划完工、实际开工、实际完工、报工数量、异常标记等。有了这两张表，下游就能拼出“每个订单对应哪些工序、做到什么程度”的宽表。

清洗阶段处理了典型的脏数据：客户编号位数不一、物料编码大小写混用、同一SKU存在新旧两个编码、部分订单行重复入库。我们用一张主数据映射表，把旧编码和新编码关联到统一KEY，并从历史明细里剔除重复行。清洗任务每天自动跑一次，遇到新异常就落库到“数据质量监控表”，由数据专员每周确认处理规则。这个细节很关键：数据清洗不是一次性项目，而是长期运维机制。

4.3 特征、模型与上线方式

这个场景的目标是：在销售创建订单后的十分钟内，给出“按承诺交期交货”的概率，并输出主要延阻原因。预测结果嵌到ERP订单评审页面，销售提交订单时自动出现风险等级、延期天数和原因摘要，计划员可以在页面一键查看详情。

特征设计上，我把它分成四个组：

• 订单特征：SKU数量、产品线、订单量、交期紧迫度；
• 物料特征：当前齐套率、关键物料库存可用天数、在途采购预计到货时间；
• 产能特征：当前车间负载率、瓶颈工序排队数量、换线频次；
• 历史特征：同一产品线历史订单平均延期天数、该客户历史交货表现。

所有特征必须落在“预测时刻”之前的数据上，这是为了防止时间穿越。这里我踩过很深的坑：一旦不小心用到未来信息，训练时评价指标会特别高，上线瞬间崩盘。所以特征工程做完，一定要检查“特征生成时间”和“标签时间”的关系。

算法上并没有追求大模型，用的是梯度提升树模型。训练时按时间做滚动切分：用前18个月训练、中间6个月做验证、最后3个月做测试。评价指标不适合只看准确率，因为按时交付样本占大多数，很容易出现“全预测会准时也依然有90%准确率”的假象。我重点看召回率和AUC，另外把“高风险订单预测命中率”作为业务指标。上线时用模型服务接口方式，订单数据一旦传入就返回预测结果，单次预测耗时控制在200毫秒以内。

4.4 复盘：为什么它没有变成“摆设”

项目上线六个月后，订单交付逾期率从27%下降到9%，订单评审时间从平均2小时缩短到20分钟。更重要的是，系统真正有人用，而不是业务部门迫于领导压力偶尔打开看看。原因不在于模型本身多强，而在于我们把输出接入了业务流程：风险订单会生成跟进任务单，计划员必须在4小时内复核并给出对策，否则会自动升级给生产负责人。销售下单时看到高风险提示，会主动调整承诺交期，避免后续违约。

这件事给了我一个特别深的感受：AI落地不是纯技术工程，更像是组织变革。那些“摆设”项目，问题八成不在算法，而在于没有设计“模型输出、角色动作、流程闭环、绩效反馈”这条链路。反过来说，只要业务链路通了，哪怕模型精度暂时一般，它也能在生产环境持续迭代、越用越准。

5. 深圳企业转型时最容易踩的七个坑

5.1 让员工“裸奔”切换新系统

有些企业为了追求上线进度，直接停掉老系统，让所有人马上开始用新系统。结果新系统数据没迁移完、流程还没跑熟，一线为了应付日常业务，只能先在Excel里记一套、回头再补录新系统，数据反而更乱。我们通常建议并行跑至少一个月，新系统先接管核心单据，老系统保留只读作为查询，等两边关键报表对上了再切换。

5.2 一开口就要上大模型

今年大模型概念很热，很多老板一上来就问“为什么不上大模型”。这里有个误区：大模型不是万能药，对制造业常见的高频结构化和时序数据，传统树模型十有八九更实用、更省资源。我的建议是先把场景需求放在第一位，再选工具。如果场景是文档解析、客服对话，才值得考虑大模型；如果是库存预测、交期预警，老老实实用梯度提升树这类成熟方案。

5.3 服务商隔空把脉

有些服务商为了省成本，接过需求全靠打电话沟通。AI转型这类项目最怕“隔空把脉”。没有做过驻场调研，画出的流程永远跟现场误差很大。我的经验是：至少派一位懂业务的人驻场一周，系统管理员和数据工程师可以远程支持，但业务调研必须在现场。别听信“我们行业经验丰富”这种话，每个厂的细节流程都不一样，例外情况往往是项目成败的关键。

5.4 数据权限没想清楚就上线

打通数据孤岛，意味着更多敏感数据会集中到同一个平台。如果权限没设计好，很容易出事。建议在平台建设初期就做字段级权限、数据脱敏、操作审计。比如销售订单金额对非销售部门隐藏、供应商价格数据只对采购主管可见，模型训练数据里的客户姓名和手机号，脱敏之后再进入特征工程。最好安排一位懂数据合规的员工或外部顾问参与架构评审，而不是等出问题再补救。

5.5 只看技术指标，不看业务指标

项目验收清单如果只有模型准确率、系统响应时间，那基本离“摆设”就不远了。应该在项目立项时，就把业务指标写清楚：库存周转天数下降多少、订单逾期率下降多少、处理一张单据的时间缩短多少。做到这些指标才叫转型成功，只做到技术指标的那叫开发结项。服务商一开始就敢签业务指标，说明对项目交付有底气；不敢签的话，至少说明这个场景的ROI可能还没想清楚。

5.6 企业内部没有“既懂业务又懂IT”的自己人

AI转型项目，甲方如果连一个内部接口人都没有，就会变成“乙方说什么就是什么”，上线之后没人维护、没人迭代。我们最希望对接的角色，是懂产品流程、同时能理解数据逻辑的生产经理或运营总监。他们既有权限推动业务侧改变，也能听懂技术方案。如果企业里缺少这种人，建议先培养或从外部招一个，而不是拿完全不懂系统的小白行政来对接需求。

5.7 验收后不迭代、不续费

AI模型有个特点：业务在变、数据分布也在变，旧模型会逐渐衰减。常见的情况是项目上线三个月后，出货结构变了，预测效果明显下降；如果企业不再投入迭代，模型就慢慢生锈。因此，我建议在服务合同里明确至少半年的运维迭代周期，企业内部设置一个哪怕是半人的数据运营角色，每两周看一次模型监控指标，及时反馈异常和新增业务规则。让AI真正长在业务流程里，而不是做一个“铁打的模型、流水的需求”。

做了这么多项目，我最大的体会是：深圳企业从来不缺好系统，也不缺好算法，真正缺的是那条能把数据打通、把动作闭合的组织链条。服务商的价值，不在于把AI做成大屏上的烟火，而在于让一线人员愿意每天打开它、信任它、按它的建议干活。如果你正准备启动一个数智化项目，先别急着问“能不能上大模型”，先问自己一句：这个AI预测出问题之后，谁会去处理？如果答案是没人，那它大概率又是一件漂亮的摆设。