京东物流 UData × SpreadJS 案例中的平台化启示

很多企业并不缺数据系统。

数据仓库、业务系统、BI 平台、指标平台、数据看板，甚至数据治理体系都已经建立起来了。但在真实业务现场，系统上线之后，员工仍然会把数据导出到 Excel，再进行筛选、拆分、合并、透视和计算。

这看起来像是用户“不愿意用系统”，其实往往不是。

更准确的解释是：系统完成了数据生产和数据交付，却没有完成一线人员最后一步的数据使用。数据到了用户手里，但还没有变成可以直接支撑判断和行动的结果。

京东物流 UData 平台的实践，正好提供了一个观察这类问题的样本：如何在保留 Excel 使用习惯的同时，把线下文件分析迁移到线上，并补上数据治理、权限、协同和性能能力。

葡萄城官方案例显示，京东物流 UData 平台引入 SpreadJS 后，覆盖内部 400 余个业务岗位，日访问量达到 4 万+；官方公开资料还披露，2023 年做数效率提升 25%，分拣员做数时长下降 37%，有效工作时长提升 10%。这些数字的具体口径应以官方案例原文和客户内部统计口径为准，但它们至少说明了一点：在线表格并不是一个孤立的前端控件问题，而是数据平台能否真正服务一线业务的问题。

这个案例真正值得关注的，不是增加了多少报表功能，而是企业如何补上数据使用的最后一公里。围绕数据分析、用户迁移、平台边界、性能分层和治理闭环，可以形成六个判断。

判断一：企业有了 BI，不等于完成了数据分析

很多企业的数字化建设路径大致是这样的：

1. 业务系统产生数据；
2. 数据平台汇总、加工数据；
3. BI 系统提供固定看板和报表；
4. 一线人员发现固定报表无法覆盖当前问题；
5. 用户下载数据到本地 Excel，继续完成最后的分析。

问题并不在于用户不愿意进入系统，而在于固定报表很难覆盖每天变化的业务问题。

物流现场需要回答的问题往往非常具体：

• 当前哪个仓的出库单出现积压？
• 哪些指标已经超过阈值？
• 异常发生在哪个环节？
• 需要按照仓、区域、班次还是业务类型重新拆分数据？
• 这个分析结果能不能继续下钻、调整和分享？

这类问题不是看一张固定仪表盘就能全部解决的。它需要用户基于统一数据源进行个性化查询、筛选和分析。

因此，BI 的价值不应该只用“看板数量”衡量，还要看数据能不能被一线人员继续使用。

数据平台的最后一公里，不是把数据送到用户面前，而是让用户能够基于可信数据完成下一步判断。

判断二：Excel 不是需要被消灭的遗留工具，而是组织中的共同语言

在很多企业的数字化项目中，Excel 经常被当作需要替代的对象。但京东物流的案例说明，问题不在于 Excel 本身，而在于线下文件承载了过多本应由平台承担的工作。

Excel 之所以长期存在，是因为它同时具备三种能力：

• 业务人员熟悉，学习成本低；
• 表格结构灵活，可以快速适应临时需求；
• 用户可以在数据结果之上继续筛选、透视、计算和加工。

如果新系统只提供固定报表，却拿走了 Excel 的灵活性，用户自然会把数据重新下载到本地。

但本地 Excel 也会带来四类组织级问题：

问题	具体表现
成本	每个人重复下载、整理、加工相同数据
口径	同一数据经过不同人工处理后产生不同结果
协同	文件传递、版本和修改记录难以控制
安全	敏感数据在本地文件和外部工具之间流转

所以，更现实的路线不是“消灭 Excel”，而是把 Excel 的使用体验迁移到线上，再把企业必须具备的治理能力补回来。

这也是 UData 引入 SpreadJS 的业务价值：保留一线人员已经形成的表格认知和操作习惯，同时让数据查询、权限、协同、预警和办公系统打通有机会在平台内完成。

从企业平台建设来看，这是一条比“彻底重建用户习惯”更稳妥的迁移路径。

判断三：UData 的价值，不是替代 BI，而是连接数据资产和业务应用

UData 的定位可以概括为“一站式、低门槛”的数据使用平台。

它并不是要替代企业已有的数据仓库、数据平台或 BI 系统，而是承担一个连接角色：把底层已经沉淀的数据资产，转化为一线业务人员能够找到、理解、分析和使用的结果。

从业务路径看，它至少要解决四件事：

1. 接数据：接入多个业务系统、数据库或数据接口；
2. 管数据：处理数据权限、指标、任务、状态和数据质量；
3. 找数据：让用户能够找到自己需要的数据，而不是依赖研发反复开发固定页面；
4. 用数据：在在线表格中完成筛选、分析、编辑、分享和协同。

其中，SpreadJS 位于“用数据”的用户交互路径上，承担类 Excel 的在线表格展示、编辑和分析交互；UData 则负责数据接入、查询、权限、平台流程和业务连接。

这是一种重要的架构边界：

• 表格组件不应该替代数据平台；
• 数据平台也不应该强行重造完整的 Excel 交互体验；
• 两者各自承担擅长的部分，再通过接口和业务规则连接起来。

平台架构最怕“所有能力都塞进一个系统”，也怕“每一层都只完成半截工作”。UData 与 SpreadJS 的组合，价值就在于把数据资产和用户操作之间的断点补上。

判断四：在线表格项目，真正比较的是迁移成本，而不是功能数量

京东物流在选型时提出了三个核心要求：

• 线下体验一致，尽可能接近 Excel；
• 扩展能力强，能够连接企业内部数据体系和办公系统；
• 性能能够承受大数据量场景下的压力。

这三个要求背后，其实对应企业数字化建设中最需要控制的三类迁移成本。

1. 用户迁移成本

如果一线员工需要重新学习一套完全不同的交互方式，系统推广成本会快速上升。类 Excel 的界面、复制粘贴、筛选、排序、公式和表格操作，可以减少从本地文件迁移到在线系统的阻力。

2. 业务适配成本

物流现场的需求并不总是固定的。平台需要支持不同岗位、组织、数据权限和业务规则，而不是只能交付一批固定页面。开放 API 和可扩展能力，决定了平台能否持续适配业务变化。

3. 性能与基础设施成本

表格能力不能只在开发机和演示环境中表现良好。还要考虑一线设备配置、网络质量、数据规模、并发访问和复杂计算对系统的影响。

因此，在线表格选型不能只问“有没有透视表”“支持多少种函数”，还要问：

• 真实模板能否迁移？
• 真实用户是否愿意使用？
• 真实数据量是否可控？
• 真实系统能否扩展？
• 真实设备和网络下是否稳定？

功能清单只能作为初筛，不能替代 POC。

判断五：大数据场景下，关键不是把更多数据放进表格，而是让表格只承接真正需要交互的数据

在 618、双 11 等大促场景中，数据规模可能达到千万级甚至更高。如果把海量明细全部推给浏览器，再让前端完成筛选、聚合和分析，这不是“充分利用表格能力”，而是把系统压力错误地放在了用户设备上。

正确的思路是先做数据收敛：

• 服务端完成筛选；
• 服务端完成聚合和透视；
• 服务端完成多数据源关联；
• 服务端完成必要的预处理和缓存；
• 前端只接收真正需要展示和交互的结果。

这里要区分两个概念：

• 参与计算的数据量：可能是千万级、亿级，需要由后端数据引擎处理；
• 展示和交互的数据量：应该是用户当前真正需要查看和操作的数据。

SpreadJS 负责浏览器中的展示、编辑和交互；服务端数据平台负责大数据处理；在需要服务端批量处理、公式计算、报表生成或预生成时，可以由 GcExcel 承担服务端文档和表格处理能力。

这不是简单的产品叠加，而是把“海量计算”和“在线交互”放到不同的执行环境中。

服务端擅长海量计算，在线表格擅长用户交互。性能优化的第一步，是让两者不要互相替代。

判断六：数据治理的终点，不是报表上线，而是异常能够被及时发现和处理

京东物流案例中的表格应用，不止是把报表从线下搬到线上，还延伸到了协同、数据推送和异常预警。

这意味着在线表格不再只是“看数据”的界面，而是可以成为业务动作的入口：

• 按人员和组织查看、编辑报表；
• 从他人的分析结果快速生成自己的报表；
• 将数据结果推送到企业内部 OA、通讯工具或邮件；
• 基于异常数据触发预警，支持事前防损。

这里有一个重要判断：

如果系统只负责展示结果，异常仍然需要人工发现、人工转发、人工通知，那么数字化链路并没有真正闭环。

更成熟的数据应用应该形成这样的路径：

统一数据源 → 个性化分析 → 异常识别 → 消息触达 → 业务处理 → 结果留痕

表格是其中的交互入口，但不是全部。权限、组织、消息、流程和审计能力仍然应该由平台层负责。

POC 验证清单

如果企业准备建设在线表格或数据分析平台，验证不应从演示功能开始，而应从以下真实场景切入。

验证项	建议做法	重点观察
真实模板迁移	使用公式密集、合并复杂、样式多的现有 Excel	格式、公式、打印和交互是否保真
真实数据规模	使用生产环境脱敏数据，覆盖常规和峰值规模	服务端处理、网络传输和前端加载是否分层
真实用户操作	让一线岗位完成一次完整任务	是否仍然需要导出到本地 Excel
真实设备网络	使用现场办公电脑和真实网络	等待时间、卡顿和异常反馈是否可接受
真实权限规则	按组织、岗位和数据权限测试	用户看到的数据是否准确、可控
真实协同链路	从分析、分享、推送到预警完整跑通	是否形成业务闭环
真实治理机制	测试模板版本、指标口径和操作留痕	出问题后能否定位、回退和追责

尤其要关注一个结果：用户是否还需要把数据下载到本地继续处理。

如果答案仍然是“需要”，说明系统只是把数据送到了用户面前，还没有真正完成数据使用。

结语：不要把 Excel 和数据平台放在对立面

京东物流 UData 的案例说明，企业数据应用的成熟度，不在于上线了多少张看板，也不在于能否把 Excel 从员工电脑里彻底删除，而在于一线人员能否基于可信数据快速完成分析、判断和行动。

UData 负责连接企业数据资产、权限和业务流程；SpreadJS 负责把类 Excel 的展示、编辑和分析体验带到浏览器；GcExcel 则在需要时承接服务端批量处理、公式计算和报表生成。三者的边界清楚，系统才既能保持灵活性，又能满足企业级治理要求。

这个案例最值得带走的一句话是：

不要用新系统强行消灭用户已经掌握的工作语言，而要把这种语言纳入企业可治理、可协同、可扩展的数据架构。

继续学习

想进一步了解京东物流 UData 如何通过 SpreadJS 支撑一线人员在线分析，以及海量数据场景下的表格技术实践，可以观看对应公开课：

京东物流公开课：表格技术在物流行业的敏捷应用实践

本文案例事实主要依据葡萄城官方案例《京东物流 ​- 表格技术在物流行业的敏捷应用实践》及葡萄城公开课内容；文中量化结果均以官方案例页披露口径为准。