业务人员自己搭系统以后，谁来维护？广汽本田使用明道云（HAP 超级应用平台）的公开案例给我的启发是：业务可以参与搭建，IT仍需要管理平台并提供支持。要让这种分工长期运行，还应把业务负责人、维护人、发布确认人与交接材料落实到每个应用；后面这部分是本文的方法建议，不是客户披露的内部制度。

我在明道云工作。这篇整理的是客户公开材料，不是我交付过的项目。我想讨论一个比“能不能搭出来”更靠后的问题：应用已经有人用，原来的搭建者换岗了，下一位同事能否接得住？

案例速览｜历史公开分享

企业：广汽本田汽车有限公司｜汽车制造｜约14000人，其中制造部门约12000人。
分享人：李亮，信息技术部智能制造系系长。
原来的问题：IT部门51人，传统开发难以覆盖持续增长的业务需求。

选型：官方案例记载评估十多种平台，关注私有部署、易用性与复杂需求、培训服务；2022年4月导入明道云（HAP 超级应用平台）。

结果：李亮在2023年明道云伙伴大会分享时介绍，当年已开展42场培训、孵化接近800名业务搭建人员，100人以上使用的应用有127个；收益接近2000万元，是按委外开发费用折算，不能视为财务审计的现金节约。

来源：官方案例；2023年公开分享

从能搭出来，到有人长期负责

官方案例里提到，有些部门曾自行编程序或采购系统，给统一管理带来困难。后来选择的平台，要兼顾业务人员上手和IT管理。这个出发点很值得注意：把搭建机会交给业务，并没有消除维护责任。来源：官方案例

这里的“应用治理”，我指的是围绕一个业务应用建立责任、使用范围、变更和退出安排。它不等于做一份应用数量排行榜，也不等于给每个搭建者一个管理员身份。

设想一个常见场景：部门自己做了领料登记应用，最初只供几个人试用。后来其他班组也开始用，搭建者调岗了，申请规则和通知流程还在跑。有人发现审批到了旧负责人那里，却不知道该找业务主管还是IT。

这是方法说明用的假设场景，不是广汽本田发生过的故障。它提醒我，应用从个人工具变成多人依赖的业务工具时，交接方式也要跟着变。

先把责任拆开，再给系统角色

我建议在上线前明确四件事：谁判断业务结果是否正确，谁维护配置，谁确认变更可以影响正式用户，谁处理平台层面的问题。同一个人可以承担多项，但每项都要有具体的人接。

责任	需要回答的问题	应留下的交接信息
业务负责人	流程规则是否仍符合实际？	适用部门、关键规则、例外处理方式
应用维护人	字段、流程、页面由谁调整？	配置说明、依赖清单、最近改动
发布确认人	这次改动是否可以交给用户使用？	影响范围、验证结果、上线时间
平台支持人	平台故障或跨系统问题找谁？	支持入口、升级路径、响应约定

上表是工作责任，不是HAP内置角色的逐项翻译。比如，“发布确认人”是本文建议的管理责任，不能据此推断产品有同名的内置审批角色。

截至本次查阅，HAP官方文档区分管理员、开发者、运营者和自定义角色：开发者偏向应用配置，运营者偏向数据和用户管理。具体权限仍应按文档及实际版本核对，不能凭名称判断。来源：角色分类与配置

我会先把责任写清楚，再逐项确认需要哪些操作权限。只为了让某人帮忙修一个字段，就把整套应用管理权全部交出去，后面的交接会更难解释。

一张应用登记表，至少留下六项信息

应用一多，最容易失效的交接方式是“有问题去群里问”。群可以用来沟通，但不适合做唯一的责任记录。

下面这六项，可以放进现有台账，不必为了管理应用再造一套复杂系统。

1. 业务用途与使用边界。 服务哪个部门，处理哪一段业务，明确不处理什么。
2. 负责人和备份联系人。 业务负责人、维护人分别是谁；请假或换岗时由谁接。
3. 数据与流程依赖。 用到哪些工作表、外部系统、定时任务；只记依赖名称，不把密码或密钥写进交接文档。
4. 使用入口与影响范围。 谁在使用，哪些入口仍有效，停用会影响哪类工作。
5. 最近变更与验证记录。 改了什么、为什么改、用哪些样例检查过、哪些情况还没有验证。
6. 退出和交接安排。 不再使用时谁确认、数据由谁保管、通知和自动任务由谁处理。

“备份联系人”不应只是填一个名字。实际交接时，可以请接手人根据文档找到一条测试记录，说明它经过哪些步骤、在哪里查看结果。能做到这一步，才说明材料具有可用性。

图：本文整理的交接清单，不是广汽本田内部制度或产品界面。

用一次小变更检查交接是否有效

继续用领料登记这个假设场景：新增一种紧急领料类型，需要通知值班主管。看起来只是多了一个选项，但维护者需要知道这个选项是否影响必填字段、通知对象、历史报表或外部同步。

我建议把这次变更写成一页记录：

项目	示例内容（人工示例）
变更目的	紧急领料提交后能通知当班主管
受影响对象	新增记录、通知流程、值班信息来源
不受影响范围	历史记录分类暂不迁移
验证样例	普通领料、紧急领料、缺少值班主管三种情况
异常处置	缺少接收人时转人工处理，不能假定已经通知成功
确认人	业务确认规则，维护人确认配置，发布责任人确认启用时间

这里没有默认“保存配置”就等于“正式发布”。不同环境、版本和配置项可能有不同生效方式，应先核实，再安排测试和通知。如果产品不能提供所需的隔离机制，就要设计独立验证环境或限制验证范围，不能拿正式数据随便试。

同样，恢复上一版配置也不代表数据自动恢复原状。新流程如果已经发出通知或修改记录，需要另列核对与补偿步骤。交接文档至少要说明这一点，避免接手人误把回退按钮当作全部善后方案。

业务自建的价值，不要只用应用数量说明

广汽本田2023年分享中的搭建人员与应用数字，说明了当时的参与情况。它们不能证明每个应用都没有维护问题，也不能直接换算成另一家企业可以减少多少IT人员。

对正在推广的团队，我更建议同时观察：有多少在用应用有明确维护人；换岗后有多少能完成交接；相同问题是否反复回到同一个IT同事手里。这里没有统一的合格比例，先定义“在用应用”和统计范围，再记录变化。

如果只看数量，停用应用和试验应用容易一起算进去；如果只看开发速度，接手、修改和停用所花的时间又会被漏掉。让业务参与搭建的好处，需要放到应用的整个使用过程中看。

常见问题

业务搭建者一定要拥有全部管理权限吗？

不一定。先明确他要承担的工作，再核对角色允许的操作；不要把工作头衔直接等同于产品权限。本文的责任表是组织方法，实际角色配置以官方文档和当前环境为准。

写了交接文档，就可以让IT退出维护吗？

不能这样推导。应用配置、业务规则、平台运维和跨系统依赖是不同的工作。哪些由业务承担，哪些由专业团队支持，需要按应用的影响范围约定。

广汽本田的近2000万元能作为我们的收益预测吗？

不能。那是李亮2023年分享时按委外开发费用折算的口径，不是本文核算的收益，也不是对其他企业的效果承诺。预算评估还要考虑培训、运维、变更和交接成本。

我会从一个已经有人用的小应用开始，补齐责任人和六项交接信息，再请另一位同事试着接手。比起先写一套很大的治理制度，这样更容易发现真正缺什么。

你们现在的业务自建应用，维护交接最容易缺哪一项：负责人、依赖说明，还是变更记录？

本文属于罗丹丹 Luna「他们为什么选明道云」第01篇技术延伸。
案例来自公开资料，方法表格由作者视角整理，非客户制度复刻。

参考来源：

• 广汽本田：无界共创，为基层数字化全面赋能，页面标注更新于2024-05-22；本次2026-10-19检索取得正文。
• 李亮《零代码改变了什么》，明道云伙伴大会2023；本地字幕00:30、02:36、03:06、06:17、07:49。本次未复核视频音轨，不使用逐字引语。
• HAP：角色的几种分类和配置步骤，访问2026-10-19。文档说明产品权限，不能证明客户实际如何配置。