ERP都上了，为什么业务部门还在用Excel？

很多企业做数字化，都会遇到一个看起来有点尴尬的问题。

ERP 上了，OA 上了，CRM、MES、WMS 也陆续上了，系统越来越多，账号越来越多，审批越来越规范，可到了真正做业务的时候，很多部门还是离不开 Excel。

• 销售要用 Excel 跟进客户和回款。
• 采购要用 Excel 追供应商交期。
• 生产计划要用 Excel 算排程和缺料。
• 质量部门要用 Excel 记异常、整改和复检。
• 财务也会在系统外面再做几张台账，用来核对口径、补充说明、调整数据。

老板看到以后，往往会很不高兴：花这么多钱上系统，怎么最后还是靠表格？

IT 部门也委屈：系统明明已经建了，流程明明已经有了，业务部门为什么还要私下维护一堆 Excel？

业务部门也有自己的说法：系统太慢，字段不够，流程太死，改一次要排期，临时需求根本等不起。

这件事如果只停留在互相抱怨，就很难说清楚。因为 Excel 长期存在，并不一定说明企业数字化失败了。它更像一个信号，说明企业里有一批业务，标准系统还没有完全接住。

这篇文章先把争论放到一边。我们从企业系统本身看一看：ERP 已经上线以后，Excel 为什么还会留下来？它到底在替企业承担什么工作？哪些 Excel 可以继续用，哪些 Excel 必须尽快系统化？

 

一、ERP管的是主干，Excel管的常常是缝隙

很多人对 ERP 有一个误解，以为 ERP 上线以后，企业所有管理问题都应该被系统解决。

这个想法听起来很完整，现实中却很难做到。

ERP 的主要价值，是把企业比较稳定、比较标准、需要统一核算和管理的主流程管起来。比如销售订单、采购订单、库存收发、生产领料、应收应付、成本核算、总账报表，这些业务有明确的单据，有固定的字段，有相对清晰的审批和流转规则。

这类事情适合放在 ERP 里。

因为它们关系到企业的资源计划、库存占用、财务核算和经营结果。如果每个部门都各做一套，就会出现库存对不上、应收对不上、成本对不上、订单状态对不上。

但企业每天发生的事情，并不全是标准流程。

比如客户临时要求调整交期，销售需要先和生产、仓库、采购确认一遍，再决定能不能答应。

比如供应商说某批物料要延期，采购要判断影响哪些订单、哪些工单、哪些客户交付。

比如车间发现某个工序连续三天效率下降，生产经理想拉一张临时表，把人、机、料、法、环几个因素先排查一遍。

比如质量异常发生以后，系统里能看到检验记录，但整改措施、责任确认、复检结果、供应商反馈和客户影响，可能分散在多个系统里。

这些事情有几个共同特点：

• 它们跨部门。
• 它们变化快。
• 它们有大量例外情况。
• 它们需要把多个系统的数据拉到一起看。
• 它们一开始未必成熟到值得开发成正式系统。

这就是 Excel 最容易生长的地方。

它不一定出现在企业最核心的标准单据里，更多出现在主流程之外、系统之间、责任边界不清楚的地方。它像胶带一样，把 ERP、MES、OA、CRM 没接住的地方临时粘起来。

这当然不优雅，但很多时候确实管用。

所以我们要先承认一个事实：Excel 没有被 ERP 消灭，不完全是业务人员不规范，也不完全是 IT 部门没做好。很多时候，是因为企业现场的变化速度超过了标准系统的覆盖速度。

 

二、业务为什么喜欢Excel？因为它太容易改了

站在管理层角度看，Excel 最大的问题是不受控。

但站在业务部门角度看，Excel 最大的优点也正是它太自由。

一个计划员要追缺料，不需要提需求，不需要等开发，不需要开评审会。他打开一张表，把物料编码、库存、在途、需求日期、供应商、责任采购填进去，今天下午就能用。

一个销售经理要做客户回款预警，也不一定马上找 IT。他让销售把客户、合同、发票、应收金额、预计回款时间填进表里，再用颜色标出风险等级，第二天开会就可以拿出来讨论。

一个质量负责人要盯整改，也不用先做系统。他把异常编号、问题描述、责任部门、整改措施、完成日期、复检结论列出来，每周催一次，问题就能往前推。

Excel 的优势就在这里。

1、低门槛

业务人员不用懂系统架构，也不用写代码。只要会建表、会筛选、会加公式，很多管理动作就能先跑起来。

2、改动快

今天多一个字段，明天加一个状态，后天换一种统计口径，Excel 改起来很快。对于还没有稳定下来的业务规则，Excel 的灵活性确实很强。

3、方便合并数据

企业很多系统之间并没有完全打通。业务人员要做一个分析，经常要从 ERP 导订单，从 MES 导工单，从 WMS 导库存，从财务导回款，再合成一张表。

这件事在正式系统里可能要排期做接口，在 Excel 里当天就能拼出来。

4、适合临时判断

企业现场有大量临时判断，不一定适合马上系统化。比如某个客户的特殊交付安排，某次专项盘点，某个项目的阶段性跟踪，某场促销活动的库存测算，这些都可能先用 Excel。

所以，业务部门喜欢 Excel，不能简单理解成他们天然抗拒系统。

很多时候，他们只是需要一个能马上解决问题的工具。

这也是为什么很多企业一边推进数字化，一边又不断长出新的 Excel。系统越多，管理越细，跨系统协调越多，Excel 反而更容易出现。

 

三、Excel真正危险的地方，在于它没人管

Excel 能解决很多临时问题，但它也会把问题埋得很深。

刚开始，一张表往往只是个人工具。一个部门负责人觉得方便，就让大家填一下。后来这张表越来越重要，会议要看它，老板要看它，财务要参考它，客户交付也要跟它走。

到了这一步，它已经超出了普通表格的范围。

它其实变成了企业的一套影子系统。

影子系统最麻烦的地方，是它承担了系统功能，却没有系统约束。

1、版本混乱

同一张客户台账，销售一份，销售经理一份，运营一份，财务又有一份。每个人都说自己这份是最新的，到了对账的时候，才发现字段、金额、状态都不一样。

很多企业的数据问题，就是从“到底以谁的表为准”开始的。

2、口径不统一

表里写“已完成”，到底是生产完成、质检完成、入库完成，还是客户已经签收？

表里写“重点客户”，是按销售额算，按战略等级算，还是按老板关注程度算？

这些口径如果没有被定义清楚，Excel 越传越多，理解就会越来越乱。

3、权限失控

Excel 文件一旦通过微信、邮件、网盘传出去，后面就很难控制。

客户价格、供应商报价、员工工资、回款计划、成本明细，这些数据只要脱离系统权限，就可能被复制、转发、误删和泄露。

4、过程不可追溯

谁改了字段，什么时候改的，为什么改，改之前是什么，谁审批过，出了问题谁负责。

这些在正式系统里可以通过日志、流程、版本记录来追踪，在 Excel 里往往只能靠人回忆。

问题一旦复杂起来，谁都说不清。

5、数据无法沉淀

Excel 做过很多管理动作，但它们很难自然沉淀进企业的数据体系。

异常处理记录没有进入质量系统，供应商交期变化没有进入供应商评价，客户回款风险没有进入 CRM，项目延期原因没有进入项目管理系统。

最后企业看起来做了很多事，真正留下来的数据却很少。

这就是 Excel 的危险。

Excel 可以用，但不能长期承担关键业务。

一张临时测算表，用完就结束，问题不大。一张影响合同、库存、交付、付款、质量和客户承诺的表，如果长期只靠人工维护，风险会越来越大。

 

四、哪些Excel应该继续留着，哪些必须系统化？

企业不可能把所有 Excel 都消灭掉。

也没必要。

真正要做的，是分清楚哪些表只是个人辅助，哪些表已经变成业务流程。

我通常建议企业用几个问题判断。

• 这张表是不是多人共同维护？
• 这张表里的数据是不是会影响订单、库存、合同、付款、交付或考核？
• 这张表是不是每周、每月都要反复使用？
• 这张表是不是需要审批、确认、转交或催办？
• 这张表是不是经常从 ERP、MES、CRM、OA 等系统导数据？
• 这张表出错以后，是不是会造成客户投诉、库存积压、财务差错或管理误判？

如果答案大多是“是”，这张表就不应该继续停留在个人文件层面。

它至少应该被纳入一个可管理的应用里。

反过来，有些 Excel 可以继续保留。

比如个人临时测算、一次性会议材料、某个方案的草稿分析、不会进入正式流程的数据整理。这类表本身就是临时工具，没有必要全部系统化。

最怕的是企业把两类事情混在一起。

一边喊着要消灭所有 Excel，把业务部门逼得很难受；一边又放任关键业务表长期游离在系统外，出了问题再追责个人。

正确做法应该更细一点。

临时分析表，允许存在。

个人草稿表，允许存在。

低频一次性表，不急着系统化。

但凡涉及多人协同、关键数据、审批责任、跨系统引用和长期复用，就要进入系统管理。

系统管理也分几种做法。

第一种，是进入 ERP、MES、CRM 这些主系统。

如果这张表直接影响财务核算、库存数量、生产工单、销售订单，规则也已经比较稳定，那就应该进入主系统。该进 ERP 的，就不要再放在部门 Excel 里绕来绕去。

第二种，是做定制开发。

有些场景长期存在，逻辑复杂，和多个系统深度集成，企业也愿意投入完整项目周期，那就可以按正式系统来做。

第三种，是先做成一个可管理的轻量应用。

很多 Excel 里的业务动作，确实需要管理，但它们变化快、跨部门、现场特征强。如果每一个都改 ERP，项目周期会很长，主系统也会越改越重。如果继续放在 Excel 里，版本、权限、日志和责任又管不住。

所以在这一背景下，很多工具应用而生，低代码也是这个时代下的产物之一，比如目前国内较为主流的低代码产品：织信、奥哲等。他们常被企业用来承接这第三类场景。一张 Excel 已经超出个人工具范围，又不适合立刻改造 ERP，就需要先被整理成一个有对象、有流程、有权限、有日志的业务应用。

 

五、标准系统之外，需要一层轻量应用承接

这里说的轻量应用，不能只是把 Excel 的列原封不动搬到一个网页表单里，再加几个按钮。

这种做法意义不大。表面上看起来系统化了，实际上只是把混乱换了个地方继续堆。

真正有价值的做法，是把已经稳定下来的 Excel 管理动作，整理成可运行、可追溯、可扩展的业务应用。

这个过程大致可以分成几步。

1、先识别业务对象

不要一上来就问表单长什么样。

先看这张表到底在管什么对象。

它管的是客户、项目、合同、物料、供应商、设备、异常、任务，还是费用？

对象一旦识别清楚，后面才知道字段怎么设计、权限怎么分配、流程怎么走、和哪些系统发生关系。

比如质量异常表，核心对象其实是“异常事件”。它应该关联物料、批次、工单、供应商、检验记录、整改措施和复检结果，而不应只停留在一张孤立表格里。

2、再整理字段和口径

Excel 里很多字段是随手加出来的。

有些字段重复，有些字段含义不清，有些字段只是为了某一次汇报临时使用。

系统化之前，要把字段分清楚：

• 哪些是必填字段？
• 哪些来自主数据？
• 哪些由系统自动生成？
• 哪些字段允许修改？
• 哪些字段修改需要审批？
• 哪些字段只用于统计，不应该人工填写？

这一步做不好，低代码应用上线以后也会变成新的数据垃圾场。

3、把状态流转讲清楚

Excel 里常见的状态有“待处理、处理中、已完成、已关闭”。看起来很简单，实际很容易出问题。

• 待处理是谁待处理？
• 处理中由谁处理？
• 已完成是谁确认完成？
• 已关闭以后还能不能重开？
• 哪些状态变化必须记录原因？
• 这些都要变成流程规则。

企业应用里的状态，不只是给人看的标签，它关系到责任、权限、提醒、统计和后续动作。

4、补上权限和日志

只要一张表涉及多人维护，就必须考虑权限。

谁能新建，谁能查看，谁能修改，谁能删除，谁能导出，谁能审批，谁能查看历史记录。

还要记录关键操作日志。

比如供应商银行账户修改、客户信用等级调整、库存差异处理、质量异常结论变更，这些动作都应该留下记录。以后审计、追责和复盘时，不能只靠聊天记录和个人记忆。

5、再考虑系统集成

低代码应用如果只关在自己里面，价值会有限。

很多 Excel 之所以存在，就是因为它夹在多个系统之间。

所以系统化时，要考虑和 ERP、MES、CRM、OA、WMS 等系统的数据关系。

• 哪些数据从主系统读取？
• 哪些结果要回写主系统？
• 哪些数据只在低代码应用内部流转？
• 哪些数据要进入报表和经营分析？

这个边界要设计清楚。

低代码真正适合做的，是把 Excel 里已经跑通、但还没有被正式系统承接的管理动作，变成企业可以长期维护的轻量应用。

 

六、举几个最适合从Excel转成低代码的场景

我们不妨把场景说得更具体一点。

1、客户回款跟踪

很多企业 ERP 里有应收账款，CRM 里有客户跟进，但销售经理真正关心的是哪些客户可能逾期、谁负责催款、客户承诺哪天付款、有没有争议、是否需要领导介入。

这类回款跟踪如果长期用 Excel，会出现版本不一致、责任不清、催办不到位的问题。

低代码可以把客户、合同、发票、应收金额、责任销售、预计回款日期、风险等级、跟进记录串起来，再加上提醒和审批，形成一张动态回款看板。

2、供应商交期协同

采购订单在 ERP 里，但供应商每天能不能按期交、哪些物料延期、延期影响哪些生产订单，很多企业还是靠采购员手工维护。

如果用低代码承接，可以把采购订单、供应商、物料、需求日期、承诺交期、延期原因、责任采购、生产影响、处理状态放在一个应用里。采购、计划、生产和仓库可以围绕同一张数据协同。

3、质量异常闭环

质量异常最怕只记录问题，不跟踪闭环。

Excel 可以记问题，但很难把隔离、评审、整改、复检、供应商反馈、客户影响和再次发生情况完整串起来。

低代码适合把这类流程做成应用：异常发起、责任判定、措施制定、整改跟踪、复检确认、关闭归档。每一步都有责任人和时间记录，后面还可以统计供应商、物料、工序和客户维度的异常分布。

4、项目进度和问题台账

项目管理里最常见的 Excel，是进度表和问题清单。

刚开始很好用，项目一多就乱。不同项目的里程碑口径不一样，问题关闭标准不一样，责任人变更没有记录，延期原因也很难汇总。

低代码可以把项目、任务、里程碑、问题、风险、责任人、变更记录、验收结果放在统一结构里。它不一定要替代专业项目管理系统，但可以承接企业内部大量轻量项目和专项任务。

5、设备点检和维修记录

设备点检表、保养表、维修记录表，也是 Excel 的高发区。

如果只是打印出来让人签字，问题不大。但一旦企业要分析故障率、停机时间、维修成本、备件消耗和责任班组，Excel 就很吃力。

低代码可以把设备台账、点检计划、异常上报、维修工单、备件领用、停机记录和统计报表连起来，让设备管理从“填表”变成“可追踪的过程”。

这些场景有一个共同点：它们不一定值得上一个大型标准系统，但又不能继续靠个人 Excel 维持。

这就是低代码最应该发挥作用的地方。

 

七、企业不要追求无Excel，要追求可控Excel

说到这里，结论其实很清楚。

企业数字化不是把 Excel 全部赶尽杀绝。

Excel 作为个人分析、临时测算、数据整理工具，未来很长时间还会存在。很多场景下，它依然是最快、最顺手的工具。

真正需要治理的，是那些已经承担业务流程、管理责任和关键数据的 Excel。

企业可以建立一个很实际的机制：

• 各部门每季度盘点正在使用的关键 Excel。
• 判断这些 Excel 是否涉及多人协同、关键数据、审批责任和长期复用。
• 对高风险 Excel 建立系统化计划。
• 先从最影响交付、回款、库存、质量和成本的表开始。
• 能进入 ERP、MES、CRM 的，进入主系统。
• 主系统改造周期长、个性化强、跨部门变化快的，交给低代码平台承接。
• 仍然只是个人临时分析的，允许继续保留，但不要让它变成事实上的业务系统。

这套方法比喊一句“全面禁用 Excel”靠谱得多。

因为企业真正需要的，是把关键业务装进可管理的结构里，表面上禁用几张表格解决不了根本问题。

 

八、低代码的价值，在于把临时管理变成长期能力

很多企业最早接触低代码，是因为它快。

快当然重要。

但如果低代码只有快，它的价值也会很快被其他工具稀释。AI 可以快，在线表格可以快，自动化脚本也可以快。

企业级低代码更重要的价值，在于把那些已经被 Excel 验证过的管理动作，逐步沉淀成企业的长期能力。

Excel 证明了业务确实有这个需求。

低代码要做的，是把这个需求继续往前推一步：

• 从个人文件变成多人协同。
• 从自由字段变成标准模型。
• 从手工流转变成流程责任。
• 从口头确认变成审批记录。
• 从私下修改变成权限控制。
• 从人工汇总变成实时看板。
• 从事后追问变成日志追溯。

这样看，低代码和 ERP 的关系就清楚了。

ERP 管企业稳定的主干流程。

Excel 暂时承接还不成熟、还在变化的现场需求。

低代码则负责把其中已经稳定、有价值、有风险的部分，转成可长期运行的应用。

这三者如果分工清楚，企业数字化会更顺。

如果分工不清楚，要么 ERP 被迫承接大量个性化需求，最后改得越来越重；要么 Excel 在系统外越长越多，最后没人知道企业真实数据在哪里；要么低代码被当成随手搭表单的工具，搭得越快，后面越乱。

 

结语

ERP 上线以后，业务部门还在用 Excel，这件事不必急着下判断。

它可能说明业务部门不规范，也可能说明系统设计有缺口，更可能说明企业现场有一些需求还没有稳定到适合进入标准系统。

真正值得管理层关注的，是哪些 Excel 已经变成了关键业务。

只要一张表开始影响订单、库存、交付、付款、质量、成本和客户承诺，它就不能再只是一份个人文件。

这时，企业要么把它纳入 ERP、MES、CRM 等主系统，要么用织信低代码把它变成有对象、有流程、有权限、有日志、有报表的业务应用。

Excel 可以继续存在。

但关键业务，不能长期躲在 Excel 里。