数采案例 | 客户说“把所有数据都采上来”，这可能是项目最大的坑

最近和一个刚入行的工程师聊天，他正为一个项目头疼。客户的需求听起来特别简单：“设备上的数据，我们都想要。”

但设备有几百个参数，真能都要吗？

这让我想起我们早期接触的很多项目。一个强烈的感受是：那些一开始喊着“全部都要”的客户，往往后来最容易陷入迷茫和停滞。

这不是客户的问题，而是我们作为服务方，有责任帮他们跨越的第一道认知鸿沟：数据采集，从来不是一场关于“数量”的竞赛。

PART 01 一个经典的“开局”

当需求过于“完美”

我们常常遇到这样“理想”的客户：

目标宏大：“我们要建设智能工厂，数据是基础，必须全面！”

需求模糊：“目前具体看哪些指标还没完全想好，但先采上来肯定没错。”

充满期待：“等数据齐了，我们就能做很多分析了。”

这个时候，如果你真的按“全部采集”去规划，项目几乎注定会走向冗杂、昂贵和难以使用。

因为模糊的全面，等于精确的无效。

PART 02 真实故事：从“数据沼泽”到“数据清泉”

企业：华东某知名汽车零部件供应商
痛点：新建产线，希望实现全流程数字化监控。负责人对我们说：“这条线很关键，数据是我们未来的眼睛，一定要看得全。”

第一阶段：顺从的“全面”
我们曾详细列出了设备上可采集的400多个参数点，包括电流、电压、温度、气压、阀门开关次数、电机振动值等等。客户看了很满意，觉得“专业、周全”。
一期项目就这样启动了，目标是“能采尽采”。

第二阶段：初现的“尴尬”
三个月后，数据平台上线了。客户的兴奋感只持续了一周，随之而来的是三个问题：

看板变得极其复杂：几十个屏幕页面，操作工和管理层根本不知道重点该看哪里。

问题依然难以定位：设备偶尔停机，面对海量数据曲线，工程师要花几个小时像大海捞针一样找异常关联参数。

价值质疑：“我们每个月为这些从没看过、也不知道用处的数据付存储费和运维费，意义在哪？”

第三阶段：艰难的“回溯”

项目陷入了僵局。直到我们推动开了一次“数据价值复盘会”。我们问了一个关键问题：
“过去一个月里，为了解决具体的生产问题（比如停机、次品率升高），你们真正主动查询、分析过哪些参数？”
现场沉默，然后答案集中在不到10个核心参数上。其余大部分数据，从未被使用。

第四阶段：重启的“精准”
我们做了一个大胆建议：项目暂停扩容，先做“数据瘦身”。

回归业务原点：我们一起梳理出产线最关键的三个业务目标：提升设备综合利用率(OEE)、降低关键尺寸不良率、预防主轴突发故障。

逆向推导数据：针对每个目标，反推需要什么数据来支撑。

要算OEE，只需采集设备运行、待机、故障状态。

要分析关键尺寸不良，只需采集与之强相关的三组模具温度、注射压力。

要预警主轴故障，根据历史维修记录，只需监测特定位置的振动值和轴承温度。

重新规划方案：最终，我们将一期采集点从400多个精简到35个。二期方案也不再是“增加点数”，而是设定为“当出现新的、明确的分析需求时，再动态增加1-2个关键点”。

PART 03 我们的心得：从“接需求”到“理需求”

这个案例之后，我们形成了自己的一套工作方法。当再听到客户说“全部都要”时，我们会引导他们进行一场“需求翻译”：

第一步：不问数据，问目标。

“您希望通过数据采集，最先解决哪一两个具体的业务痛点？是降低成本、提高效率，还是保障质量？”

第二步：不问全部，问关键。

“针对这个目标，您觉得现场老师傅或优秀班组长，最关心哪几个设备指标？他们凭经验是怎么判断问题的？”

第三步：不做一次交付，做持续服务。

我们会提供一份 《同行数据采集基准参考清单》 ，告诉客户：“同行在解决类似问题时，通常会优先采集这20个参数。我们可以此为起点，小步快跑，快速验证价值。”

PART 04 写在最后：好数据是“问”出来的，不是“采”出来的

一个能真正产生价值、持续运行的数据采集项目，起点往往不是一个宏大的命令，而是一系列精准的提问。

作为服务商，我们最大的价值也许不在于连接设备有多快，而在于能否帮助客户，在数据的海洋里，打下一根坚实的、通往业务价值的锚点。

如果你也正面临“不知道采什么”的困惑，或者担心项目变成“数据垃圾场”，欢迎来找我们聊聊。我们可以一起，从理清那“第一个关键问题”开始。

审核编辑 黄宇