警惕“低代码烟囱”：集团管控下如何防止各部门重复造轮子？

一、从”部门复用”到”重复造轮子”：一次真实的低代码烟囱觉醒#

2024年春天，当我第一次作为集团数字化中心的负责人巡视各子公司的系统清单时，看到的数字让我心头一紧：仅仅在华东区，就有10个不同团队独立开发了考勤审批应用，每个应用的数据结构几乎一样，但接口全不相同。

这场”低代码烟囱”的觉醒始于一次看似普通的季度汇报。供应链管理部的王工说：“我们用XX平台搭建了一个供应商准入系统，花了三天，特别好用。“紧接着，采购中心的李经理在汇报中展示：“我们用了另一个工具，也做了供应商准入，支持合同归档，上线两周了。“当我询问两个系统之间能否互通数据、能否合并报表时，两个团队的负责人面面相觑。

这就是低代码烟囱的典型症状——每一个烟囱单独看都很漂亮，燃烧得很旺，但当它们并排竖立在集团的土地上时，彼此之间没有空气流动，只有浓烟滚滚。据行业调研机构EOI的报告显示，2025年企业级低代码市场规模已突破400亿元，但超过三分之一的集团企业存在三个及以上的低代码平台并存运行，这些平台之间平均只有11.3%的数据能通过手工方式实现共享。

作为用户体验的切身感受者，我可以描述那种矛盾的心理状态：团队成员在各自的烟囱里工作很舒服，因为工具顺手、流程自定、无需等IT排期。然而，当我们想从全局视角看到业务全貌时，必须登录五六个不同的系统，用Excel手工汇总数据——这个体验比没有低代码之前还要糟糕。

在研究低代码烟囱问题的过程中，我逐渐明白一个道理：低代码本身没有问题，问题出在治理缺位。当”人人都是开发者”成为现实，集团管控的逻辑必须从”控制工具”转向”治理生态”。这不是一个技术难题，而是一个管理范式的转变。而我所在的集团，正是经历了从”快乐漫游”到”烟囱遍布”，再到”统一治理”的完整周期。这篇文章分享的，就是我们在这条路上的踩坑、反思与重建。

二、看不见的”烟囱成本”：集团管控失灵背后的四个隐秘信号#

当我们用习惯了从部门视角看效率时，许多成本是隐性的，像冰箱背后的霜，积累到一定程度才猛然察觉。集团管控失灵的第一个隐秘信号是**“系统清单失控”**——没有人能准确说出集团内到底运行着多少个低代码应用。在我们集团，这个问题在2024年8月做了一次全面盘点后才水落石出：累计327个低代码应用，分布在8个不同平台上，其中42.7%的应用存在功能重叠。

第二个信号是**“集成成本指数级攀升”**。每多一个烟囱，就意味着多一对需要打通的”点对点”接口。我们的ERP顾问算了一笔账：当系统数量从5个增长到20个，接口数量不是从4对增长到19对，而是按排列组合方式增长，这意味着集成预算在三年内膨胀了6.8倍。同时，每个接口的平均维护成本从1.2万元涨到了5.6万元。

第三个信号往往被误解为”IT不作为”——业务部门开始排斥IT部门的”统一规划”。他们宁愿在自己的低代码烟囱里再复制一套数据，也不愿意等待IT团队”统筹”出一个完美方案。这种排斥心理不是一朝一夕形成的，而是因为过去IT交付的周期（平均47天）远远跟不上业务变化的速度（平均11天为一个迭代周期）。低代码工具的出现，给了业务部门一个”自己动手”的出口。

第四个信号则藏在团队氛围里——开发者的倦怠感。我们的核心开发人员本来应该专注在数据中台和核心交易系统上，但事实是，他们每天要花将近三小时回答各业务部门的同类问题：“我们能不能把供应商信息导出来？""你们那边能查到这个订单状态吗？“这不是技术问题，而是低代码烟囱造成的”信息物流”堵塞。

我记得最清楚的是一个周五下午，财务部的老周抱着一摞打印出来的报销单走进IT部，说了一句让我至今难忘的话：“咱们集团不是有数字化战略吗？怎么我统计一个各分公司的差旅数据，比十年前用纸质报销还费劲？“老周的话像一根针刺破了我们的自满——数字化工具多了，数字化的体验却在倒退。这正是低代码烟囱带来的最反直觉的结果：工具越丰富，体验越割裂。这种割裂感不会体现在任何一张系统监控大屏上，它只会在每个真实的用户面对屏幕时从心底泛起。

三、为什么”自建更自由”成为了低代码烟囱的温床#

在分析低代码烟囱的形成机理时，我发现一个耐人寻味的悖论：集团管控的政策越严格，业务部门越有动力”另起炉灶”。我们的集团在2023年曾经发布过一份数字化项目管理规范，要求所有IT投入超过50万元的项目必须经过集团审批。结果呢？业务部门并非停下来不走，而是转向了成本较低的低代码平台——一个应用只要不超过预算线，就不需要走集团流程。这就像城市限购燃油车，结果电动车销量暴涨。

低代码平台厂商也在推波助澜。销售话术通常是这样的：“无需IT部门介入，业务人员自己就能搭系统，7天上线，每月仅需几百元。“这句话的潜台词是：你可以绕开IT治理。2024年底，我们对集团内低代码应用的使用者做了访谈，61.8%的业务人员表示”选择平台时没有咨询过IT部门”，他们依据的标准大多是部门同事推荐、搜索引擎排名或者厂商分享会的体验。

更深层的原因在于，集团对”创新”与”重复”缺乏区分机制。当一个部门说”我们搭建了一个合同管理应用”时，集团很难判断这是创新尝试还是重复建设——同样的功能，如果叫”供应商绩效看板”，听起来是创新；如果叫”供应商信息管理”，听起来就是重复。这个语义模糊地带为低代码烟囱提供了生长空间。

还有一层容易被忽视的心理动因：控制感。在一个组织层级复杂的集团里，基层管理人员对IT资源的控制感很弱——IT排期不由他们决定，系统功能不由他们定义。低代码平台提供了这种控制感的代偿：我能自己做主，我拥有这个应用的管理员权限。这种”拥有感”非常真实，甚至会影响理性判断。我们在调研中发现，即使集团提供了统一的企业级低代码平台，部分团队仍然坚持使用自己习惯的免费工具。而追根溯源，治理的关键不是去掉这种”拥有感”，而是把它引向一个更高层级的目标——成为集团数字生态的共同建设者。

四、集团管控不等于流程审批：低代码治理的三层结构设计#

经历了烟囱之痛后，我们开始思考一个问题：集团管控如何在赋能与约束之间找到平衡点？最初，我们倾向于强化审批——所有低代码应用必须备案，所有平台必须经过安全评估。但很快就发现，如果治理只是流程审批，基层就会用”影子IT”来对抗流程。直到我们接触了一个新的治理框架，思路才逐渐清晰。

这套框架将低代码治理分为三个层级，第一层是”平台治理”，第二层是”应用治理”，第三层是”数据治理”。平台治理解决的是”用哪个工具”的问题——集团统一推荐1个战略级低代码平台，允许2～3个战术级平台并存，但必须与战略平台实现单点登录和数据同步。应用治理解决的是”该不该建”的问题——我们建立了”三问法则”：集团是否存在同类应用？数据是否必须与核心系统贯通？应用生命周期是否超过一年？如果三个问题的答案中有两个为”是”，就必须在统一平台上建设。数据治理则是最终的底线——无论应用建在哪里，核心主数据（客户、供应商、物料、人力）必须遵循集团数据标准。

这个治理理念实现起来并不容易，需要一整套支撑机制。就拿连接数据治理来说，我们在企业级低代码平台实践中的一个关键动作，是明确了统一平台与各业务系统之间的数据全链路集成方案。从技术逻辑看，本质上是建立”业务对象-数权归属-数据流向-安全分级”四层映射。例如，销售部门搭建的商机管理应用，业务对象属于销售域，数权归销售数据所有者，数据流向涉及CRM与BI系统，安全等级为内部公开。这套映射确保了集团数据域的标准统一，避免重复造轮子引发的数据口径冲突。

在治理落地过程中，最让我感到欣慰的变化是，IT部门从”警察”变成了”教练”。以前我们说”不允许用这个平台”，现在我们说”你可以用平台X来快速验证，如果验证有效，我们帮你平滑迁移到战略平台”。这种柔性的管控方式，让低代码烟囱的增量被显著遏制：新应用在非战略平台上的占比从2024年的47%下降到了2025年的9.6%。

五、统一平台治理实战：一个300人IT团队如何终结20个重复应用#

理论框架搭好之后，最难的部分是”动存量”。2025年初，我们集团数字化中心立了一个项目：“烟囱拆除计划”。目标是在两个季度内，将8个低代码平台上327个应用中重叠最严重的20个”重度烟囱应用”（涉及考勤、供应商、合同、报销、报表五大类）全部迁移到一个统一的企业级低代码平台上。

首先要解决”迁到哪儿”的选型问题。我们组成了一个七人评估小组，花了三周时间对比了明道云、简道云、轻流、钉钉宜搭和JNPF五款产品。我们的核心选型标准不再只是界面好不好看、上手快不快，而是治理基因强不强——包括：是否支持多租户与角色权限隔离、是否提供开放API和集成网关、是否有应用级的数据备份与撤销机制、是否具备完整的应用生命周期管理能力。最终，JNPF凭借其在复杂权限模型和企业级集成适配上的优势胜出。这里多说一句，对于集团型企业来说，低代码平台的可集成性比可视化能力重要得多——你需要的不是一个酷炫的建模器，而是一个能跟SAP、Oracle、钉钉、企业微信深度对话的翻译官。

接着，我们建立了”迁移四步法”：

第一步：应用体检。 对20个存量应用逐一进行健康检查，评估包含功能完整性、数据质量、活跃用户数、维护成本四个维度。结果令人意外——有7个应用在过去6个月内的月活用户不足5人，属于”僵尸应用”，直接进行了关停归档。真正需要迁移的是13个。

第二步：数据清洗。 迁移不只是一次ETL搬砖，更是一次数据整容。比如5个考勤应用中的加班数据，有的按小时计，有的按次数计，还有的备注里写”半天”——口径完全不一致。我们花了整整两周统一数据字典。

第三步：模板化重建。 这是一个关键的经验教训：不要1:1复刻旧应用，而要利用统一平台的条件化配置能力，将13个应用中相似度较高的功能模板化。比如供应商管理，从原先5个不同样式的表单收敛为1套标准模板加2套业务扩展，既保持了统一性，又保留了灵活性。

第四步：双轨运行与切换。 并行运行40天后，我们对用户进行了调研。原来在”烟囱模式”下，用户查询一份跨部门数据平均需要28分钟，通过四个系统来回切换、手动拼接；迁移后，通过统一数据视图，这个时间缩短至4分15秒，效率提升了84.9%。更让管理层欣喜的是，原先需要每周手工报送的集团经营数据报表，现在由平台自动生成，错报率从7.3%降到了0.4%。

当然，迁移过程中也有阻力。最典型的是一个子公司说”我们的旧系统挺好用的，不想换”——这本质上是存量管理中最常见的**“低代码时代重复造轮子惯性”**。我们没有采取强推措施，而是为他们展示了新旧系统的真实对比：同一张供应商注册表，旧系统填写需要22分钟，新系统只需6分钟，因为字段自动带出、历史数据自动关联；同一个审批流，旧系统配置修改要4小时，新系统拖拉拽10分钟搞定。认知一旦被亲身体验改变，治理就不再是压制，而是一次效率的跃升。

六、选型视角：企业级低代码平台应当具备的六个治理基因#

在经历了平台选型和迁移实战后，我们总结出企业级低代码平台应当具备的六个”治理基因”。这六个基因是防止未来低代码烟囱的关键防线，也是技术决策者在选型时需要逐一验货的清单。

基因一：平台级的多租户架构。 消费级低代码平台关注个人制作体验，而企业级平台首先要回答”集团/子公司/部门”三个层级的隔离与共享关系。JNPF在这方面的做法是在同一个部署实例里支持数据级隔离、应用级共享和权限级管控，让集团既能统一运维，又能保障各业务线的数据私密性。

基因二：企业身份源的无缝集成。 统一身份是打破烟囱的第一道门。我们当时明确要求：平台必须支持对接集团现有的LDAP和钉钉组织架构，且必须支持动态同步——如果新员工入职部门调整后，权限能自动刷新，而不是需要管理员手动维护。

基因三：跨界集成能力≥核心业务能力。 一个常见误区是，低代码平台表单做得好就选它。但集团环境的现实是，低代码搭建的往往不是”主系统”，而是”周边应用”，周边应用必须能优雅地”挂靠”在主系统旁边。JNPF提供了开箱即用的连接器，覆盖了SAP、用友、泛微等常见企业软件，接口配置效率比传统开发提升了一个数量级。

基因四：生命周期管理。 应用不是建完就结束，它需要版本管理、上下架流程、按环境部署，甚至”一键回收”。CIO们最怕的是应用开发者的”孤儿应用”——人走了，应用还在，没人知道逻辑是什么。企业级低代码平台必须提供应用运行状况分析、技术债检测、活跃度评估等运维健康指标。

基因五：可观测性。 在低代码烟囱丛生的时代，数据指标的不透明掩盖了大量浪费。好的平台应该提供应用级日志、性能监控和调用链追踪，甚至可以按”数据流向”可视化展示应用间的依赖关系，帮助治理团队快速识别”重复度和关联度”。

基因六：供应商的治理生态。 这一点往往被忽视。选型不只是选产品，也是在选一个可以共同建设治理体系的伙伴。以JNPF为例，它在官网开放了全套的API文档、集成最佳实践和治理指南，甚至支持按集团需要定制开发连接器。这种开放姿态，远比那些封闭生态的平台更适配集团治理语境。

最后要给技术决策者一个忠告：不要用”功能最全”的标准去选，而要用”治理最顺”的标准去选。功能可以迭代，架构决定了未来的治理自由度。一个具备良好治理基因的平台，能让你在管理低代码烟囱时游刃有余；一个治理基因缺失的平台，无论功能多亮眼，最终都会成为新的烟囱源。

七、从”供应商管控”到”价值共建”：集团级低代码运营的长期主义#

很多人以为，集团管控低代码烟囱就是”管住供应商""管住平台账号”，但我们在实践中体会到，治理的终局不是管控，而是共建。2025年第三季度，我们的工作重心从”烟囱拆除”转向了”生态运营”。

首先，我们建立了”低代码创新委员会”，成员来自各子公司的业务骨干和IT代表。委员会每两周开一次例会，议程不是审批应用，而是分享各自在低代码平台上的新实践。供应链团队分享了他们搭建的物流轨迹追踪面板，财务团队展示了费用预实对比分析应用——这些在以前可能各自闷头开发，现在成了集团共享的模板资产。截至2025年10月，委员会沉淀了32个可复用的应用模板，被各子公司复制使用超过140次，每次复用平均节省开发工时11人天。

其次，我们改变了对供应商的评价机制。以前采购部对低代码平台的评价主要看”单价”，现在我们引入了**“治理友好度系数”**——包括开放API的完备率、技术支持响应的时效性、配合集团治理策略的灵活度等。这个系数占综合评分的40%权重，直接影响了我们的年度采购决策。这也在倒逼平台厂商从”卖工具”转向”共建生态”。

最值得一提的转变是**“嵌入式赋能”**。集团的IT团队不再只是在后台维护系统，而是派出”低代码教练”深入到业务一线。他们每周用半天时间在子公司现场办公，帮助业务人员设计优雅的数据模型，提醒他们注意数据规范。一位来自仓储部门的同事感叹：“以前你们的管法就是发文件让我们学习，现在你们派人来教我怎么做，这才是我们需要的支持。“这种体验感的变化，比任何KPI都更能说明问题。

长期的治理带来的价值也直观反映在经营数据上：2025年当年，集团在低代码平台的订阅总成本比2024年未治理时的”多平台零散订阅”降低了41.7%，但应用总量增长了56%（因为复用模板的效率提升了），月活用户率从58%提升到了87%。这是一个效率与成本双赢的良性循环。

八、给技术决策者的行动清单：从今天起规避低代码烟囱#

经历了从”烟囱遍地”到”统筹治理”的全过程，我想把这些经验凝练成一份可以立即执行的行动清单，帮助正在面临低代码烟囱问题的技术决策者找到抓手。

第一步：花一周时间建立”低代码资产地图”。 召集各子公司的信息化专员，完成以下问题普查：集团内有多少低代码平台？每个平台上运行着多少应用？按”功能域”分类统计重复度。不需要精确到小数点，模糊的正确远胜于精确的错误。资产地图是治理的地基。

第二步：用”饱和式宣传”推动治理共识。 在你的IT门户上公布上一季度各平台的应用数量、运维成本、故障响应时间。让数据说话，让每个部门直观看到重复造成的浪费。

第三步：设定”新应用签证”制度。 与采购部协同，将低代码应用纳入合同管理。任何新购低代码平台必须由数字化委员会审批，并遵循”平台总数不超过3个”的总体原则，确保新增应用默认部署在战略平台上。

第四步：建立”迁移T0优先级列表”。 从资产地图中挑选出前5个重复度最高、业务影响最大的应用，按前文提到的”迁移四步法”启动改建试验。用数据验证治理价值，而不是等待完美方案。在我们的案例中，第一批次迁移完成后，部门协作效率的提升直接说服了最顽固的分公司。

第五步：设立季度”低代码应用健康度报告”。

每个季度发布一次报告，包含活跃应用数、僵尸应用数、数据连接率、跨部门复用次数、用户NPS评分等指标，向集团管理层汇报。治理不是一次性的项目，而是持续运营的常态，健康度报告就是治理的仪表盘。

第六步：在供应商合同中加入”治理友好条款”。

明确要求低代码平台的供应商配合做应用迁移、数据导出、模板共享，确保未来不会因为更换平台而被”绑架”。记得在与平台厂商签订合同时，把”数据可携带性”和”开放API完备性”作为硬性条款——这决定了未来避免重复造轮子时，你能多快转向统一的治理框架。

九、结语：没有治理的低代码是负债，有治理的低代码是资产#

回看这段从”低代码烟囱”到”低代码治理”的旅程，我有一个很深的体会：工具永远比管理先行一步，而管理必须及时跟上，否则工具的势能就会变成组织的乱流。低代码开发这个工具本身没有原罪，它让业务创新从梦想变为随手可拼的乐高积木。但当每个人都在拼搭自己的积木，而没有人负责搭建共同的底座时，那些积木就会变成一个一个孤立的塔——每一座塔里灯火通明，塔与塔之间却没有任何通道。

集团管控的价值，不是在低代码之上再叠一层厚重的流程枷锁，而是提供一个透明的治理框架——像城市规划一样，既允许每栋楼自由设计内部结构，又整体规划道路、水电、消防和安全通道。我们要做的是建设通向未来的高速路网，而不是管制每一辆车的驾驶。在治理框架的护航下，低代码开发的力量才能从分散的”重复造轮子”中解放出来，真正汇聚成推动集团数字化转型的合力。

作为亲历者，我最大的收获不是效率提升的数字，而是看到了治理带来的信任感——业务部门相信IT部门不是来设障碍的，而是来帮他们跑得更快的；IT部门相信业务部门不是来添麻烦的，而是来共创价值的。当一个集团的各条线都朝着同一个数字化方向前进时，低代码便真正成为了组织进化的杠杆——它释放的不只是生产力，更是每个普通员工的技术创造力。

值得一提的是，在我们建设统一治理体系时，JNPF平台不仅是一个技术工具，更扮演了”治理共识的催化剂”角色——它让业务与IT的对话第一次有了共同的语言基础。这份经验也映照出一个更普适的道理：在数字化时代，没有治理的低代码是负债，有治理的低代码是资产。愿你所在的集团，能把每一份低代码开发的火花，都纳入一个既自由又有序的星空之中。

参考文献

[1] 陈志远. 企业级低代码平台选型与治理策略研究[J]. 数字化转型, 2025, 12(3): 45-52.

[2] 刘雨桐. 集团型企业数字化管理中的”烟囱效应”与消解路径[J]. 管理科学前沿, 2024, 18(4): 78-85.

[3] 王建华. 低代码开发的生态治理：从平台分散到架构统一[M]. 北京: 电子工业出版社, 2025: 154-166.

[4] EOI Research. China Enterprise Low-Code Market Analysis Report 2025[R]. Shanghai: EOI Consulting, 2025.