业务部门自己搭应用之后，IT 要管住哪四件事

平台开放给业务部门以后，应用一个接一个冒出来，同一份数据被导来导去，出了问题找不到负责人。IT 不必替业务搭应用，但要守住四件事：字段级权限、发布流水线、接口统一出口、操作留痕。本文给出 RBAC 矩阵、应用台账表结构和一张可以先跑起来的发布流程。

乱的根源在没人定规则

业务部门搭应用的目标很实际：手上有件事要解决。至于这个应用该给谁用、数据能不能导、要不要接 ERP，他们一般不考虑，也考虑不到。

于是同一个集团里出现几个场景。质量部搭了一张缺陷登记表，直接发到全公司填写，结果一半的人填了与自己无关的数据；采购部把供应商信息导出成文件发给工厂，工厂又导进另一个应用，两边改的东西最后都不知道哪份新。

这些事的根源都是同一个：应用的责任人、数据边界和出口没人定。

四件必须留在 IT 手上的事

IT 管什么	具体动作	不管的后果
管权限	谁能看、谁能改、谁能删，控制到字段	一个应用的表单发成全公司的表单
管上线	测试过、审批过，才能发到正式环境	生产数据被测试流程改动
管接口	要接 ERP 的统一走集成平台，不让应用各接各的	同一个客户在各系统有多个来源
管审计	谁在什么时候改了什么，全程留痕	出了问题找不到负责人

这四件事的共同点是：业务部门不需要懂技术，IT 也不需要替他们搭应用。分界很清楚，搭归业务，规则和记录归 IT。

权限要做到字段级，不然等于没做

行级权限解决的是班组长只看本班，字段级权限解决的是同一个表单里不同的列给不同的人。成本字段只给成本会计看，供应商报价只给采购负责人看，这些要求在业务部门自己搭应用之前就要定下来，等应用跑起来再补，改的是一圈人的使用习惯。

配置上守住三条：新应用默认只发给创建人所在部门；导出功能按角色开；正式环境和测试环境分开，业务部门在测试环境里怎么改都行。

落到模型上，就是三元组 角色 × 资源 × 动作，资源粒度下探到列，动作里把 EXPORT 单列出来。

角色	资源	READ	WRITE	DELETE	EXPORT
采购员	purchase_order（本部门行）	是	是	否	否
采购负责人	purchase_order（本部门行）	是	是	是	是
采购负责人	purchase_order.supplier_price	是	是	否	否
成本会计	purchase_order.cost_amount	是	是	否	需审批
其他部门	purchase_order	不可见	-	-	-

三条容易漏的配置：新应用授权范围默认收敛到创建人所在部门，不发全公司；EXPORT 不继承 READ，看得见不等于导得走；删除一律走软删，物理删除只留给治理动作，并且要留痕。

这四类场景先别开放给业务自己搭

涉及对外报价和合同的，错一单就是钱和法律责任。涉及薪酬、考勤和个人信息的，权限和导出要单独审。直接下生产指令的，参数填错会影响产线。生成财务凭证的，科目和期间不能靠业务自己试。

这四类的共同点是改动的后果落在公司外部或者账上。这类应用由 IT 或专业部门搭，业务部门提需求和验收，分工换一下就行。

发布流水线：环境、审批、回滚

流程走向：

• 测试环境：业务自由改配置 → 提交发布申请：附验收人与影响范围
• 提交发布申请：附验收人与影响范围 → IT 校验
• IT 校验 →（权限范围超部门 / 无责任人 / 直连生产库）驳回
• 驳回 → 测试环境：业务自由改配置
• IT 校验 →（通过）发布到正式环境
• 发布到正式环境 → 运行中：改动留痕
• 运行中：改动留痕 → 回滚到上一版本

回滚这一条要提前验证。配置型应用最大的隐患是改了字段导致历史数据读不出来，发布前在测试环境用生产数据的脱敏副本回归一次，比事后恢复版本更快。

应用台账：治理从这张表开始

CREATE TABLE app_registry (
  app_id         VARCHAR(32) PRIMARY KEY,  -- 全平台唯一
  app_name       VARCHAR(128) NOT NULL,
  owner_user     VARCHAR(64)  NOT NULL,    -- 写一个人名，写部门等于没写
  tenant_scope   VARCHAR(64)  NOT NULL,
  data_scope     VARCHAR(256) NOT NULL,    -- 涉及哪些主数据，含不含个人信息
  integration    VARCHAR(256),             -- 有没有接别的系统，接口谁维护
  publish_status VARCHAR(16)  NOT NULL,    -- DEV / PROD / DISABLED
  last_review_at DATETIME     NOT NULL,    -- 每年至少看一次
  version        INT          NOT NULL
);

台账项	记什么
应用名称与编号	全平台唯一
业务责任人	写一个人名，写部门等于没写
数据范围	涉及哪些主数据，含不含个人信息
出口	有没有接别的系统，接口谁维护
发布状态	测试、正式、已停用
上次复核时间	每年至少看一次

不用一上来就建治理体系。当天能做的就是把平台上现有的应用列出来，按上面这六项填一遍。责任人这一栏最难填，填不下去说明这个应用已经没人管了，这类应用要么下线，要么重新找人接。

一家整车集团的做法

一家整车集团在 Dolphin Code 低代码平台上建了数十个应用，大部分是业务部门自己设计、自己搭的。应用数量不少，但没有乱成一团，靠的是前面那四件事先立了规则：权限按角色配到人，上线要走审批，接口统一走集成平台，改动全程留痕。

IT 在这里的角色变了，从需求承接方变成规则维护方。业务部门的排队时间降下来，IT 反而更能说清每个应用的数据从哪来、给了谁。

这张表填到三分之一，你就会看到重复建设、无人负责和私自导数这三类问题。把它们分头处理，平台才能越用越顺。业务部门能搭、IT 管得住，这两件事同时成立，低代码在企业里才是长期的做法。

上线检查清单

• 每个在跑的应用都能查到责任人到人名
• 新应用默认授权范围限定在创建人所在部门
• EXPORT 独立授权，报表导出有审批或水印
• 成本、报价、个人信息三类字段做过列级权限抽查
• 删除走软删，操作日志保留期与审计要求一致
• 测试环境与正式环境数据隔离，发布需审批
• 所有对外系统的连接走集成平台，应用侧无直连生产库的账号
• 台账里已停用状态的应用做过一次清理，无残留可访问入口

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中权限模型与表结构均为示意。