GMG大联盟：SaaS交付时权限表为什么总对不上？

最后更新 2026-09-13 09:09 · 更新于 2026-09-13 09:09 · GMG

项目群里贴出一张截图：排班模块的「班组长审批」按钮在生产环境是灰色的。客户侧的IT主管问，这是权限没配好，还是接口没通？PM先把问题转给实施顾问，实施顾问打开后台角色表一看，测试环境的角色里确实勾选了审批权，但生产环境的同名角色少了一个「排班变更」权限点。这个场景在近期GMG大联盟的交付案例里并不少见，问题往往不是出在SaaS本身，而是权限表在从测试到生产的迁移过程中没有做逐项核对。

权限点核对：不要只看角色名称

很多交付团队在验收前习惯导出角色清单，对比两个环境的角色数量是否一致。但同名角色下的权限点差异更容易被忽略。上述案例中，测试和生产各有一个「班组长」角色，名称完全一样，只是生产角色漏勾了一项。后来顾问用导出的JSON逐字段比对，才定位到这次差异只花了六分钟。GMG大联盟在交付SaaS时通常建议把权限点拆成「查看」「操作」「审批」「导出」四类，每类单独打钩，避免用「全选」替代逐项确认。

角色映射：先问实际流程再配权限

另一个容易踩坑的地方是角色映射。客户的组织架构表和系统里的角色定义不一定一一对应。比如某供应链客户把「仓库主管」和「调度主管」合并成一个SaaS角色，结果现场交接时发现仓库主管能看到运输报价，调度主管却看不到库存冻结记录。后来实施团队重新画了权限矩阵，把两个岗位拆开，再按最小权限原则分配。这个调整发生在上线前一周，如果拖到验收后再改，会影响至少三个接口的联调进度。

验收节奏：留出半天做只读核对

GMG大联盟的交付文档里有一条默认规则：UAT前半天，所有配置变更冻结，只做只读核对。某专业服务公司的项目里，客户坚持在UAT当天上午还在导入新的员工账号，结果下午验收时刚导的账号没进角色组，登录后看不到任何菜单。后来双方商量把账号导入放到UAT前一天完成，再用一个只读脚本检查「账号数—角色数—权限点总数」是否匹配预期。这个脚本现在成了交付模板的一部分，每次上线前跑一遍，输出表直接附在验收邮件里。

SaaS交付的权限问题看起来琐碎，但往往在验收当天集中爆发。留出固定时间做只读核对，比事后补救更省成本。对于正在推进GMG大联盟相关SaaS项目的团队来说，把权限表当作一份需要逐行签字的清单，而不是一个默认正确的配置文件，可能是最实际的做法。