一张看板管全业务，低代码把零散数据串起来了

一、被七张Excel统治的周一早晨#

如果你问我，企业里最消耗人的事情是什么，我会毫不犹豫地回答：对数。

我们是家做智能硬件的公司，年营收8亿元左右，有12个业务部门、4条产品线、两个生产基地。三年前我刚接手数字化中心时，公司已经有ERP、CRM、MES、OA，也有钉钉审批，看起来该有的系统一个不少。但每周一早上九点的经营例会，依然是一场“数据混战”。

真实流程是这样的：周一早上7点半，销售内勤从CRM导出订单明细；8点，供应链的同事从ERP导出库存和到货记录；8点20分，生产计划员把MES的排产数据贴进Excel；8点40分，财务再把上个月的账期数据补进去。七张表，六个部门，口径各不相同——销售说的“已发货”，是系统里的出库单；供应链说的“已发货”，是物流签收。于是会议开始的前20分钟，基本都在确认“你这个数是怎么算出来的”。

我们统计过，每周仅例会数据准备就要消耗6个人各2.5小时，合计15人时；而看板上显示的数据，平均滞后72小时。

更麻烦的是数据是断的。你想知道“某个型号的毛利率为什么下滑”，得先在销售表里找价格，再去ERP找成本，最后去MES找工时，三张表拼起来，一下午就没了。零散数据最大的问题从来不是“没有数据”，而是数据之间不串联，谁都不敢用、谁都得重算一遍。

那段时间，我们内部有一句半开玩笑的话：“我们不缺报表，我们缺的是敢在会议上直接投屏的那一张。”

二、转折点：从“每周报数”到“随时看数”#

真正让我下决心改变的，是去年二季度的一次客户投诉。

一批设备在现场出现故障，客户要求48小时内给出“同批次还有多少台在途、多少台在库、多少台已交付”的清单。听起来是个简单问题，结果我们花了整整一天：ERP查在库、CRM查已交付、物流系统查在途，三个系统之间用型号和批次号人工比对，中间还因为一个批次号录入口径不一致，多花了两个小时复核。

那天晚上我在办公室坐到十点，想明白一件事：我们过去三年的信息化建设，都在解决“业务线上化”，但没有人解决“数据看得见”。系统越多，零散数据反而越多。

于是我们定了一个目标，只有一句话：做一块看板，让任何一个业务问题都能在3次点击内看到答案。

目标定下来，接下来是路径选择。三条路摆在面前：

1. 买一套BI工具：可视化能力强，但只解决“展示”，数据源接入、口径治理、权限控制还得另配一套，供应商评估周期就要6周；
2. 自研一套数据中台：能力最完整，但以我们8个人的团队规模，至少半年起步，业务等不起；
3. 用低代码平台搭：连接器现成、页面可视化拖拽、权限体系内置，能同时解决“接数据”和“做看板”两件事。

我们最终选了第三条路，平台用的是JNPF。选它的原因很朴素：我们做过一轮POC，接入用友U8、销售易CRM和钉钉审批这三类数据源，从配置到出数用了不到一个工作日，这个速度对当时的我们来说是决定性的。

这里我想强调一个容易被忽略的体验差异：**BI工具是给“会看数的人”用的，低代码是给“要管业务的人”用的。**前者解决洞察，后者解决闭环——看板上发现问题，点进去能直接改数据、发起流程、通知到人，这是两种完全不同的使用体验。

三、低代码是怎么把零散数据接进同一块看板的#

很多同行问我：低代码做看板，和直接用Excel透视表、用Power BI有什么区别？我的回答是：区别在于数据是不是活的。

Excel是“搬数据”，每次都要重新导一次；低代码是“接数据”，接一次以后自动同步。我们把公司现有的数据源梳理了一遍，按接入方式分成四类：

这张表看起来平平无奇，但真做起来，最难的不是”接”，而是”对齐”。

举个例子：销售侧的“成交金额”是含税价，财务侧的“收入”是不含税价，两个数字放在一块看板上，业务方第一反应就是“你们做错了”。我们的处理办法是在数据模型层就建好统一的指标定义，把“含税/不含税”“出库/签收”“自然月/账期月”这些口径做成显式字段，看板上直接标注口径标签，谁看都不会误解。

在低代码平台里，这一层叫数据模型或业务对象。我们最终沉淀了37个业务对象、186个字段、52个计算指标，构成了整个看板体系的“公共底座”。有了这一层，后面再加一块新看板，往往只需要拖拽配置，两三个小时就能出一个可用版本。

回头看，这一步才是全业务视角的真正起点：不是把所有系统推倒重来，而是在系统之上架一层“统一语言”，让零散数据先被串联成可复用的模型，再谈可视化和洞察。

四、第一次动手：三小时搭出全业务看板原型#

我一直建议同行：不要一上来就做“大屏”。大屏是给参观用的，看板是给干活用的。

我们的第一块看板，选择的是“订单到交付”这个最痛也最完整的链路。从动手到投屏可用，总共花了3小时20分钟，具体是五步：

第一步：定一个业务问题，而不是定一个页面。 我们把问题写成一句话：“本周有哪些订单可能延期交付，卡在哪个环节？” 这句话直接决定了看板需要订单、库存、排产、物流四类数据。

第二步：把四类数据接进数据模型。 复用第三章已经建好的业务对象，只补了物流轨迹一个新数据源，配置API约40分钟。

第三步：先做表格，再做图表。 这是踩过坑之后的经验。先把明细表格跑通，确认“数对不对”；数值确认无误后再加图表。我们内部有个原则叫“先可信，再好看”。

第四步：加下钻路径。 从“延期订单数”点进去，能看到具体订单；再点订单，能看到它在MES里的排产工单和当前工序。三层下钻，正好对应业务方从“发现问题”到“定位问题”的思考路径。

第五步：挂到移动端和例会大屏。 同一份数据，PC看全局，手机看异常。上线第一天，供应链总监在手机上刷到了两个红色预警，当场就在群里@了负责采购的同事。

上线第一周，我们做了个对比：过去判断“本周是否会有订单延期”，需要计划员手动比对ERP和MES，平均耗时45分钟；现在打开看板，10秒内能看到结论。周例会上，第一次没有人再问“你这个数是怎么来的”，因为所有人看的都是同一块屏。

那一刻的体验很微妙——看板真正改变的不是效率，而是会议的性质。从“对数字”变成了“做决策”。

五、看板不止于展示：预警、下钻与流程的联动#

如果看板只能看，它的生命周期大概只有三个月。真正让它活下来的，是“看完之后能做什么”。

我们在三个地方做了联动：

一是异常预警前置。 库存周转天数、订单延期风险、来料检验合格率，这三类指标设置了阈值，超限自动推送到钉钉群，并@责任人。上线后第一个月，推送了83条预警，其中61条在问题扩大前被处理掉。从“月底看报表追责”变成“当周发现、当天处理”，这是体验上最大的变化。

二是看板直连流程。 供应商交期异常的时候，采购在看板卡片上点一下“发起协同”，系统自动带出供应商、物料、订单号，直接生成一张协同单走审批流，处理结果再回到看板。以前这件事要走线下微信沟通加Excel登记，平均2天闭环；现在4小时内基本都有结果。

三是数据回写。 这点常被忽略。业务在看板上发现问题后，往往需要修改源头数据（比如调整交期、修正批次）。低代码的好处是可以在看板上直接做“轻量修正”，改完回写业务系统，同时留痕。这解决了一类特别磨人的场景：为了改一个字段，要登录三个系统、找两个人。

有个小故事我印象很深。去年10月，一块“在途库存”看板显示某型号在华东仓积压了1,200台，而华南仓同期缺货。这个信息过去是分散在两个区域的报表里的，谁也看不到全貌。发现后我们做了跨仓调拨，减少了约76万元的滞销风险。事后复盘，供应链的同事说了一句话：“不是我们不想管，是没人把这两个数放一起给我看。”

这就是串联的价值——它把各个业务系统里孤立的零散数据，变成了一条能支撑动作的链路，而不是一堆需要人工拼接的碎片。

六、让每个人只看该看的：权限设计与口径治理#

看板做多了，新的问题来了：谁能看什么。

我们第一版上线时权限做得很粗——所有部门经理看所有数据。结果第二周，财务就来找我：销售能看到的毛利数据，和财务口径不一致，容易引起误解。还有一次，某区域的客单价数据被跨区域看到了，引起了一点小摩擦。

后来我们做了三层权限设计，这套方案现在跑了一年多，基本没再出问题：

1. 功能权限：谁能进哪个看板、能不能导出。
2. 数据行权限：按组织架构和区域自动过滤，销售总监只能看自己大区，区域经理只能看自己区域。低代码平台的组织架构同步之后，这一层基本是配置化的，不用写代码。
3. 字段列权限：成本、毛利、客户联系方式这类敏感字段，按角色做字段级隐藏或脱敏。

比权限更难的，是指标口径治理。我们的做法是给每个核心指标配一个“owner”（负责人）和一个定义卡：指标名、计算逻辑、数据来源、更新频率、责任人。现在一共沉淀了52个指标定义，全部写进平台的指标字典里，看板上点击指标名就能看到定义。

效果很直观：以前开会上出现“这个数不对”的争议，平均每次要花15到20分钟澄清；现在争议依然会有，但大部分能在2分钟内通过定义卡解决——因为大家争的不再是数字，而是口径本身，而口径是有明确责任人的。

这里我想加一句体会：**低代码降低了搭建门槛，但也放大了“乱搭”的风险。**如果没有口径治理，你能在一个月内做出30块互相打架的看板。所以我们的节奏是——每新增5块看板，就回头做一次指标梳理和权限复核。

七、我们踩过的五个坑与对应的解法#

这一节是我最想写给同行的部分，因为坑都是真金白银踩出来的。

坑一：一开始就想做“全业务大屏”。 我们最早的规划图画了48个指标、11个主题，结果两个月没上线。后来砍到3个主题、12个指标，两周就跑通了。解法：先用最小闭环证明价值，再横向扩展。

坑二：数据接进来了，但没人敢用。 原因是缺“对账”环节。我们的做法是每块看板上线前，和原有报表并行跑两周，差异率低于**0.5%**才算验收通过。解法：给数据可信度设一个可量化的验收标准。

坑三：把看板当报表用，指标越堆越多。 第一版经营看板塞了32个指标，业务方反馈“看完不知道重点在哪”。后来改成“3个核心指标+6个辅助指标”，并在顶部固定一行“本周异常”。解法：看板要有观点，不是一个数据展览馆。

坑四：移动端适配被放到最后。 我们一直按PC端设计，上线后发现约68%的查看行为发生在手机上（这是从平台访问日志里统计出来的）。返工重排了一次布局。解法：移动优先设计，先想清楚“在手机上最该看哪三个数”。

坑五：只做技术交付，不做使用习惯培养。 系统上线后使用率一度只有31%。后来我们做了三件事：每周例会用看板开会、每个部门指定一名“数据管家”、连续三个月做小范围培训。三个月后周活跃率达到87%。解法：看板是管理工具，必须嵌进管理动作里。

这五个坑，本质上都不是技术问题，而是使用体验和组织习惯问题。这也是我后来在选型时特别看重的一点：平台能不能让业务人员自己改看板，而不是每次都要排开发排期。

八、选型复盘：六款低代码平台在真实场景里的体验对比#

因为踩过坑，后来有不少同行来问选型建议。我把自己实际用过的几款平台做了个横向对比，评分是基于我们公司场景（制造业、多系统集成、私有化部署、需要看板与流程联动）的主观打分，满分10分，仅供参考。

几点真实感受，说清楚比排名更有用：

• 如果核心诉求是“表单+流程”，简道云和钉钉宜搭的体验最轻快，业务人员半天就能自己搭出一个应用，但复杂数据源接入和跨系统建模会吃力。
• 如果要做复杂的业务模型和数据关系，织信和明道云更合适，模型驱动能力强，代价是学习曲线稍陡。
• 如果像我们一样，既要接多个异构系统、又要做看板和流程联动、还要私有化部署，JNPF 的综合匹配度最高——它的数据模型层和权限体系是我们在POC阶段最满意的地方，数据库直连加只读账号的方式对老系统也足够友好。
• 轻流的流程引擎体验很好，看板偏向流程效率视角，如果重点是“流程可视化”而非“经营分析”，它是个好选择。

还有一句实话：**没有一款平台在所有维度都第一。**选型的正确姿势是先把自己的TOP3场景写成需求清单，让每家按同一份清单做POC，比较“跑通一个真实场景要多久”，而不是比较功能列表的长度。我们当时的标准就是：接一个数据源 + 出一块看板 + 配一套权限，能不能在1个工作日内完成。

九、三个月后的复盘：数字变了，习惯也变了#

项目正式上线满三个月，我们做了一次完整复盘。下面这组数据，是我最愿意分享的部分：

按人力成本折算，一年大约节省1,860人时。这个数字我一般不太愿意强调，因为它容易让人误以为项目的价值就是“省人力”。实际上，更大的变化发生在习惯上：

变化一：会议从”对数”变成”决策”。 周会时长从平均110分钟压缩到65分钟，前20分钟的争论环节基本消失了。

变化二：业务人员开始自己改看板。 我们统计过，23块看板里有9块是业务部门自己调整或新建的，数字化中心只做了权限和口径审核。这是低代码带来的最大体验差异——需求不再排队。

变化三：数据从”月度的”变成”日常的”。 过去数据是月底才算的“结果”，现在它是每天在用的“工具”。供应链的同事每天早上的第一件事，是刷一眼库存预警看板。

变化四：从单点看板走向全业务视图。 我们正在做的下一步，是把订单、生产、库存、交付、回款五条链路串成一条完整的经营主线，用一块主看板管住全业务。这件事在传统开发模式下我们不敢想，但用低代码，两个人、六周，已经有了雏形。

最后，说回标题里的那句话。一张看板管全业务，本质不是”看板”厉害，而是它把散落在十几个系统里的零散数据，用一套统一的模型和口径串联了起来。 而低代码的价值，是让这件事不再是大企业的专利——一个8人的数字化团队，三个月，也能完成过去要一年才能推动的全业务数据串联。

如果你的团队也正被七张Excel和每周的对数会议折磨，我的建议很简单：**别急着买BI，先找一个最痛的业务问题，用低代码把它的数据串起来，做出一块敢在例会上投屏的看板。**第一块看板跑通的那天，你会明白这件事的意义。

参考文献

[1] 艾瑞咨询. 2025年中国企业级低代码应用实践白皮书[R]. 上海: 艾瑞咨询研究院, 2025.

[2] IDC中国. 2024下半年中国低代码与零代码软件市场跟踪报告[R]. 北京: IDC中国, 2025.

[3] 中国信息通信研究院. 企业数据治理与指标体系建设指南（2024版）[R]. 北京: 中国信息通信研究院, 2024.

[4] 王建民, 李志. 低代码开发平台技术架构与工程实践[M]. 北京: 机械工业出版社, 2024.

[5] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner, 2024.