跨境多店经营真正开始变难，不是从订单量突破某个数字开始的，而是从"谁都能进后台"那一刻开始的。我参与过的一次权限审计里，一个 12 人的运营团队管理 18 家店，主账号密码被写在共享文档里，运营能改价、客服能退款、外包能导出客户手机号，而老板手上唯一的"权限控制"是，微信群里的口头提醒。这篇文章要讲的，就是把权限管理从 IT 后台的一个开关，提升为跨境电商 ERP 运营框架的底层骨架：先画权限矩阵，再谈功能清单；
先定职责边界，再谈"免费不免费"。
如果你只记住一句话，我希望是这句：多店经营的复杂度和店铺数量不是线性关系，而是乘法关系。3 家店 3 个人，靠记忆和信任能跑；8 家店 12 个人，靠群公告还能勉强压住；到了 20 家店 30 个人加上外包，任何一次越权操作都会直接变成钱、变成客诉、变成平台处罚，甚至变成一次不可逆的客户数据外流。
很多人把 ERP 当成"订单+刊登+库存"的工具集合，这个理解在单店阶段没错，在多店阶段会出大问题。因为工具解决的是"事情能不能做"，而权限解决的是"谁能做、做到什么程度、做完留不留痕"。前者是效率问题，后者是生存问题。
我复盘过自己经手和旁观过的十几起跨境运营事故，一个共同特征是：当问题被发现时，钱已经出去了。越权改价导致亏本出单、误操作批量取消订单、离职员工带走客户名单、外包用主账号导出全店订单，这些事的修复成本，远高于事前配置一次权限矩阵的成本。
更麻烦的是"看不见的损失"。一次改价错误可能只亏几千块，但团队会因此开始互相猜疑，运营不敢放权、老板不敢授权，最后变成所有决策都堆到老板一个人身上，扩张速度被硬生生锁死。
市面上大多数 ERP 的功能清单高度相似：多平台对接、订单同步、批量刊登、库存同步、物流对接、财务对账。真正拉开差距的是权限颗粒度：能不能按店铺隔离？能不能做字段级脱敏？有没有审批流？操作日志能不能导出？离职能不能一键停用？
这些能力在你只有 3 家店时几乎感觉不到价值，但在你从 8 家店走到 30 家店的过程中，它们决定了你是"边扩边治理"还是"扩完再返工"。
我见过太多团队是反着来的：先买 ERP，再让 ERP 的功能去定义自己的权限体系。结果就是，ERP 支持什么权限，团队就用什么权限；ERP 不支持字段级脱敏，那成本利润就人人都能看。这不是工具选了人，是工具驯化了管理。
正确的顺序是：先定义角色与职责分离规则 → 再画权限矩阵 → 再用 ERP 去落地这张矩阵 → 最后用审计数据反向验证矩阵是否需要调整。工具是执行层，规则是决策层。
我习惯把一个跨境团队的权限演进分成三个阶段。这三个阶段的分界线不是营收，而是"有没有人开始共用账号"和"有没有事只有一个人知道"。
这个阶段的典型状态是：一个主账号，密码在群里，谁要操作谁登录。老板心里清楚这不太对，但会给自己一个理由，"就这么几个人，出不了事"。
客观上这个阶段确实风险有限，因为每个人的工作边界在物理上是清晰重叠的：谁负责哪家店、谁发哪个包裹，大家心里都有数。真正的问题不是风险，而是这个阶段养成的习惯会在下一个阶段要命。
团队扩到十几个人，开始出现岗位分工：运营、客服、采购、仓管、兼职美工。这时候最常见的做法是"给运营开个子账号"，但子账号往往是照着一个模板复制的全权限账号，因为没人有空去想"这个岗位到底需要什么"。
我把这种现象叫"影子权限"：表面上每个人都有独立账号，看起来合规；实际上每个账号的权限都一样，等于把主账号复制了 12 份。审计的时候你会发现，客服账号可以改价，美工账号可以看财务数据。
到这一步，团队里一定有外部协作方：代运营、兼职客服、摄影外包、货代对接人。他们需要的权限往往是临时的、局部的，但实际操作中，为了方便，通常会被给到一个"能看很多"的账号。
同时，人员流动开始变快。我抽样看过 23 个跨境团队的后台（个人样本，不代表行业统计），其中 17 个存在至少一个离职超过 30 天仍未停用的子账号，最久的一个已经离职 7 个月，账号还能登录并导出订单。
这三类事故的共同点：都不是"人坏"，而是"权限太宽"。一个权限设计合理的系统，会让第一次犯错的人根本没有机会把错放大到不可收拾。
下面这五个误区，是我在实际沟通中听到频率最高的。它们单独看都不算离谱，但组合起来，会让一个团队在扩张期反复踩同一个坑。
子账号只是"身份"，权限管理是"边界"。很多 ERP 的子账号功能本质上是"再开一个登录名"，登录进去以后看到的东西和主账号没有区别。这不叫权限管理，这叫账号分发。
判断方法很简单：用这个子账号登录，看它能不能看到不属于它职责范围的数据。如果客服账号能看到成本价，如果运营账号能看到全店利润报表，那这个 ERP 的权限能力就是不及格的。
这句话的隐含假设是"信任可以替代机制"。但在实际运营中，绝大多数事故不是恶意造成的，而是信息不对称 + 权限过宽造成的。新人不了解历史价格策略，外包不知道某个 SKU 是引流款，兼职客服不知道批量操作的后果。
权限分级不是不信任人，是让每个人只在自己熟悉的范围内做决策。这是对员工的一种保护，也是对老板的一种保护。
"免费"是一个非常有效的获客钩子，我自己也用过免费的跨境 ERP，起步阶段确实省了钱。但选型时要把"免费"当成一个待核实的变量，而不是一个结论。需要逐项确认的是：
这不是说免费产品不好，而是说免费的成本从来不体现在账单上，而是体现在你为了绕开限制而额外付出的人力成本上。
这是最容易混淆的一条。平台侧的权限通常指店铺授权、广告账号授权、支付方式授权、API 调用授权；ERP 侧的权限指子账号、角色、数据范围、字段可见性、审批与日志。两者是不同层面的东西。
多店操作环境是否合规、子账号如何配置、API 授权范围如何界定，每个平台的规则都不一样，必须以该平台最新的官方说明为准，不能用一套通用说法套所有平台。任何声称"绝对安全""100% 防封"的说法，都值得你多问三个问题。
权限是活的。人会转岗、会离职、会新增岗位；业务会新增平台、新增站点、新增品牌。我观察到的规律是：一个团队上线时配置的权限矩阵，如果不做定期复核，三个月后就会和实际组织结构脱节 20% 以上。
所以权限管理必须包含一个"生命周期"环节：入职开通、转岗调整、离职回收、外包到期回收、每季度复核。没有回收机制的权限系统，等于一个只进不出的仓库。
我给团队做权限梳理时，用的是一张五层框架图。这五层从上到下依次是业务层、组织层、权限层、流程层、技术层。权限层是连接业务与组织的转换器，也是绝大多数团队缺的那一层。
跨境 ERP 覆盖的业务动作大致可以归为九类：选品、刊登、订单、库存、采购、物流、财务、客服、广告。这一层的作用不是罗列功能，而是识别出哪些动作是"错了就很难挽回"的。
我的经验判断是：改价、退款、取消订单、库存调拨、广告预算调整、客户数据导出，这六类动作属于高风险动作，必须在权限设计里单独拿出来做特殊处理。其他动作可以粗放，这六类必须精细。
很多团队的错误是把权限直接绑到"人"身上，张三来了给他开权限，张三走了把他的权限给李四。正确做法是把权限绑到"角色"上：老板、店长、运营、客服、采购、财务、仓管、外包，一共八类角色基本能覆盖大多数跨境团队。
人员变动时，只改"人，角色"的映射关系，不动权限配置本身。这样权限矩阵是稳定的，维护成本会低一个数量级。
权限层是整个框架的核心。我把它拆成五个维度，每加一个维度，控制力就上一个台阶，同时配置成本也会上升。团队需要根据自己的规模选择加到哪一维。
| 维度 | 回答的问题 | 典型做法 | 适用规模 |
|---|---|---|---|
| 功能权限 | 能用哪些模块？ | 订单/刊登/库存/财务模块开关 | 3 家店起 |
| 店铺权限 | 能操作哪些店/站点/品牌？ | 按店铺分组授权，运营只绑定自己负责的店 | 5 家店起 |
| 数据权限 | 能看到什么范围的数据？ | 按店铺、时间范围、数据行级过滤 | 8 家店起 |
| 字段权限 | 同一张表里哪些列可见？ | 成本价、利润率、客户手机号脱敏 | 10 家店起 |
| 操作权限 | 能不能执行高风险动作？ | 改价/退款/导出走审批或双人复核 | 12 家店起 |
大部分 ERP 能做好前两维，第三维开始分化，第四、第五维是分水岭。字段权限和操作权限，是我判断一个 ERP 权限能力是否成熟的硬指标。
权限不是静态配置，而是一个闭环流程。我在实际落地时用的五步是：
这五步里最容易断掉的是"回收"。因为回收没有即时反馈，不做也不会立刻出事，所以最容易被拖。建议把"权限回收时效"做成一个可考核的指标，而不是一个口头约定。
技术层是权限规则的执行载体。选型时我会重点看这几项：是否支持独立子账号、是否支持角色组模板、是否支持 SSO 单点登录、是否支持二次验证、操作日志能否按操作人/时间/动作类型检索并导出、异常操作能否触发告警、离职能否一键停用。
下面是一份可以直接拿去用的权限矩阵配置示例（结构为示意，具体字段以你所用系统的实际配置项为准）：
# 多店权限矩阵示意配置
roles:
role: 运营-初级
modules: [order_read, listing_edit, inventory_read]
stores: [shop_01, shop_02] # 仅授权店铺
data_scope: own_stores # 数据范围=自己负责的店
field_mask: [cost_price, profit] # 成本与利润字段脱敏
actions:
price_change: approval_required # 改价需审批
order_cancel: approval_required
export_customer: deny # 禁止导出客户数据
role: 客服
modules: [order_read, order_service, refund_apply]
stores: [shop_01, shop_02, shop_03]
data_scope: own_stores
field_mask: [cost_price, profit, supplier]
actions:
refund_apply: limit_amount_500 # 500 元以内可自主，超出走审批
export_customer: deny
price_change: deny
role: 财务
modules: [order_read, finance_read, report_export]
stores: all
data_scope: all_stores
field_mask: [customer_phone, customer_address]
actions:
price_change: deny
inventory_write: deny # 财务不可改库存
report_export: approval_required # 导出报表需审批并留痕
role: 外部-代运营
modules: [listing_edit, order_read]
stores: [shop_05]
data_scope: assigned_store_only
field_mask: [cost_price, profit, customer_phone, customer_address]
expires_at: 2026-03-31 # 强制设置有效期
actions:
export_customer: deny
price_change: approval_required
这份配置里有三个关键设计：外部角色强制有效期、成本利润字段默认脱敏、高风险动作默认走审批而不是默认开放。把这三条固化下来，能挡掉我前面说的绝大多数事故类型。
下面这部分是我自己在实际梳理过程中记录的观察，样本来自我接触过的中小跨境团队，属于个人经验数据，不代表行业统计口径，引用时请当作参考基准而不是行业结论。
在多店经营的数据治理这条线上，我近期观察比较多的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。我把它放进这个框架的原因很直接：它解决的是"多店铺数据汇总与经营分析"这一层的问题，而这一层恰好是权限问题最容易暴露的地方。
原因不难理解。经营分析天然要求"跨店看数据"，而权限治理天然要求"按店看数据"，两者是一对张力。如果一个团队在做多店汇总看板时，把所有店铺的数据都无差别地铺给所有账号，那权限体系基本就形同虚设了。所以我评估这类工具时，最关心的不是看板好不好看，而是数据汇总之后，谁能看到汇总、谁只能看到自己那一份。
我做过一次比较完整的权限梳理，团队背景是 14 家店、9 个正式成员加 3 个外部协作方。整个过程分四步：
这次梳理的结果是：14 家店的 12 个账号里，有 5 个账号的权限范围与实际职责不匹配，3 个账号超过 60 天未登录，2 个外部账号没有设置有效期。这些问题在被列出来之前，团队里没有一个人觉得"有问题"。
权限治理最怕变成一次性运动。我会建议团队盯住三个指标，按季度看趋势：
下面这张表是我自己选型时会填的评估表。右边一列不是评分，而是"必须问出的答案"。无论你最终选的是哪一类工具，这张表都能帮你把"权限"从一个模糊概念变成可比较的参数。
| 评估维度 | 需要确认的具体问题 | 不合格的信号 |
|---|---|---|
| 店铺隔离 | 能否按店铺/站点/品牌分组授权？一个账号最多绑定多少店？ | 只能按平台授权，无法按店铺细分 |
| 角色管理 | 是否支持角色模板？角色数量是否受限？ | 只能开子账号，不能定义角色 |
| 字段级权限 | 成本价、利润率、客户联系方式能否单独脱敏？ | 只能控制模块可见性，不能控制字段 |
| 审批流 | 改价、退款、导出能否配置条件触发审批？ | 所有操作要么全开放，要么全禁止 |
| 操作日志 | 日志能按操作人/动作/时间检索吗？能导出吗？保留多久？ | 日志不可检索或保留期不足 90 天 |
| 账号生命周期 | 是否支持一键停用？是否支持外部账号设置有效期？ | 只能手动删除账号，无停用机制 |
| 登录安全 | 是否支持二次验证、SSO、登录地限制？ | 仅账号密码，无任何二次验证 |
| 数据范围 | 多店汇总视图能否按角色限制可见店铺范围？ | 汇总看板对所有账号完全开放 |
如果你评估的是偏数据与经营分析方向的工具，比如数跨境这类定位在多店铺数据汇总与经营看板的产品，我会额外追问一句：汇总层和明细层是否都能做权限隔离？因为汇总层的数据价值更高，一旦全员可见，等于把全公司的经营底牌摊开了。
权限治理最忌讳的一件事，是把大卖家的方案直接搬到自己身上。20 家店和 3 家店需要的不是"简化版的大方案"，而是完全不同的问题优先级。下面按规模给四档建议。
这个阶段的核心任务只有两个：停止共用主账号，给每个人开独立子账号；把改价和退款的权限收回到店长或老板手上。
不要在这个阶段设计三级审批流，那会让团队效率下降却带来不了多少安全收益。流程复杂度要和团队规模匹配，这是我在很多小团队身上验证过的判断。
到了这个规模，客服、运营、财务的分工基本成型。这一步要做三件事：按店铺分组授权、给客服账号屏蔽成本利润字段、给外部协作账号设置有效期。
同时建议开始记录操作日志，哪怕不每天看，也要保证"需要的时候能查到"。日志的价值不在于监控，而在于出事时能快速定位到人、时间和动作。
这个规模下，靠人工管理权限已经不现实了。需要把六类高风险动作全部纳入审批，并建立季度权限复核机制。复核的内容包括：冗余权限清理、离职账号检查、外部账号到期检查、角色与岗位匹配度检查。
如果团队有 IT 或运维角色，这个阶段可以开始考虑 SSO 和二次验证，把登录安全也纳入治理范围。
到了这个量级，权限问题本质上是组织问题。需要明确的角色定义文档、书面的权限申请与回收流程、定期的内控审计，以及与 HR 流程打通的入职/离职卡点。工具在这里只承担执行角色，规则必须由管理层定义。
| 团队规模 | 第一优先级 | 可以暂缓的事 | 建议投入 |
|---|---|---|---|
| 1，3 家店 | 账号分离 + 高风险动作收回 | 审批流、字段级脱敏 | 约 0.5 人天/月 |
| 4，15 家店 | 店铺隔离 + 字段脱敏 + 日志 | SSO、告警自动化 | 约 1，2 人天/月 |
| 16，50 家店 | 审批流 + 季度复核机制 | 深度内控审计 | 约 3，5 人天/月 |
| 50 家店以上 | 组织流程 + 内控审计 + 系统集成 | 无（已进入常态化治理） | 专人负责，约 0.5 FTE |
我在做选型建议时，最常被问到的问题是"哪个更好"。但权限这件事上，更重要的问题其实是"你现在更愿意牺牲什么"。下面是四组必须做的取舍。
免费方案的隐性成本通常体现在三个地方：权限颗粒度不够导致的管理妥协、账号或店铺数量限制带来的多账号切换、缺少审批和日志带来的隐性风险。
我的判断标准是：当你每个月花在"绕开限制"上的时间超过 4 小时，免费就已经不划算了。按一个运营的时薪折算，4 小时的成本通常已经超过多数 SaaS 的中档订阅费。
有些团队会考虑自研一套权限中台。我的建议是：除非权限治理本身就是你的核心竞争力，否则不要自研。多平台 API 对接、子账号体系、审批引擎、日志存储，每一项都是长期维护成本。
更现实的做法是：采购成熟的 ERP 承载执行层，自己只维护"角色，人员，店铺"这张映射表。这张表可以用最普通的表格工具维护，反而比自研系统更灵活。
权限中心化的好处是可控，坏处是慢。如果所有改价都需要总部审批，当地运营在应对竞品降价时会错过窗口期。
我的折中方案是分层授权 + 阈值控制：一定幅度内的调整由店长自主决策，超过阈值才走审批。比如价格调整幅度在 5% 以内可以自主，超过 5% 需要审批；退款金额在 500 元以内可以自主，超过则审批。阈值本身就是一种权限，而且比角色权限更好用。
这是最容易被忽视的一条。我见过一些团队把审批流设计得极其严格，结果就是成员为了完成任务，开始私下找人代操作、共用高权限账号，反而制造了更大的风险。
好的权限设计，是让"按规则做"比"绕开规则做"更省事。如果一条审批要等 4 个小时才能通过，而找有权限的同事代操作只要 5 分钟，那规则一定会被绕开。这也是为什么审批流必须配移动端审批和超时提醒。
框架讲完，最后给一条可以直接执行的路线。我建议按 30/60/90 天推进，每个阶段只解决一类问题，不要试图一次做完。
这一阶段只做四件事：拉出全部账号清单、标记共用账号和僵尸账号、关闭所有人的主账号直连、建立初版权限矩阵。交付物是一张"账号，角色，店铺"对照表。
这个阶段的判断标准很朴素：能不能在 10 分钟内回答"谁有权限改价"这个问题。如果回答不出来，说明盘点没做完。
选 1，2 家店、3 类角色做试点。配置角色模板、字段脱敏规则、高风险动作的审批条件。跑两周，重点看三件事：订单流程有没有被卡住、客服响应时长有没有变长、有没有人抱怨"太麻烦"。
试点期最重要的产出不是配置本身，而是发现哪些规则在真实业务里跑不通。跑不通的规则，要在推广前改掉，而不是推完再改。
全量推广后，建立季度复核机制，并开始跟踪三个核心指标：权限冗余率、账号回收时效、高风险动作审批覆盖率。同时把离职流程和 HR 打通，做到"离职当日停用"。
这一阶段结束后，团队应该具备一个能力：任何一个高风险动作，都能在 30 分钟内查清是谁、什么时候、基于什么审批做的。
回到最开始那句话。多店经营的复杂度是乘法关系，而权限治理是唯一能把乘法关系"压回"可控范围的杠杆。ERP 能帮你把订单、库存、刊登跑得更快，但只有权限设计能决定你能放心地把这些事交给多少人去做。
我的核心判断有三条：第一，权限不是 ERP 的功能模块，而是运营框架的骨架，先定规则再选工具，顺序不能反。第二，权限治理的投入结构会随规模迁移，把资源压在错误环节上是最常见的浪费。第三，"免费"不是结论，只是一个待核实的变量，真正要问的是它在店铺隔离、字段脱敏、审批流、操作日志这四项上的实际能力。
下一步你可以做的最小动作是：今天就把团队的账号清单拉出来，标出哪些是共用账号、哪些超过 60 天没登录、哪些外部账号没有有效期。这三个问题通常能在半小时内找到答案，而它们往往对应着最容易被忽视的风险。
如果你正在多店、多平台、多人协作的阶段，并且已经开始感到"事情越来越说不清"，那通常不是团队能力问题，而是权限框架缺了一层。把权限矩阵画出来，你会发现很多管理上的混乱，其实是一个配置问题。
把这份清单打印出来，逐条勾选。能勾满 8 条以上的团队，通常已经具备支撑 20 家店以上规模的管理底盘。勾不满的，也不用焦虑，从账号分离和高危动作收权这两件事开始，一周之内就能看到明显改善。
我们团队现在6个人管9家店，平台后台都开了子账号，我就觉得权限这事已经解决了。但前阵子有个运营离职，我发现他在ERP里还能看到全部店铺的成本和利润，吓了一跳。我搞不清平台侧权限和ERP侧权限到底各管什么，是不是重复劳动。
两者管的是两件不同的事，不能互相替代。平台侧权限管的是“这个账号能不能碰这个店铺、能不能调API”，粒度通常到店铺、站点和广告/订单等模块；ERP侧权限管的是“这个人在系统里能看到什么、改什么、批什么、导出什么”，粒度更细，能到字段级，比如成本价、利润、客户手机号。
多店场景下真正的风险点有三个：一是共用平台主账号，等于所有人都拿到最高权限，且操作无法归属到人；二是ERP账号与平台授权脱钩，员工离职只停了平台子账号，ERP里的API授权和子账号还活着；三是导出权限没有单列，客服能顺手把订单明细导走。
可执行做法是按“一个自然人=一个ERP子账号=N个按需授予的店铺授权”来配，平台侧逐步取消共用主账号，改用API授权或子账号逐店绑定，ERP侧把成本、利润、联系方式列为敏感字段默认脱敏，导出单独申请并设有效期。判断口径很简单：任一人员停用后，他在所有平台的店铺授权与ERP账号必须在同一天内全部失效。
抽查方式是每季度随机挑3名近半年离职或转岗的人，尝试登录并检查授权记录，只要有一个还能进，就说明流程没闭环。
我们做Shopee、Lazada加一个独立站，一共十几家店，团队从3个人涨到20多人。我一直想搞一版权限规范，但每次一开始画表就乱：是按岗位拆、按平台拆还是按店铺拆？运营主管和店长权限要不要一样？结果拖了半年还是靠口头约定。
别追求一次画全，先把日常80%的动作覆盖住，一张20到30行的表就能解决大部分问题。矩阵的维度建议固定为五个：角色、功能模块、店铺或站点范围、数据字段范围、操作类型（查看/修改/审批/导出）。操作类型必须单独列，因为“能看订单”和“能导出订单”是两种风险等级完全不同的权限。
拆分原则是按职责而不是按人头：老板/合伙人、店长或运营主管、运营、客服、采购、财务、仓管、外包，一般8到10个角色就能覆盖3到50家店的团队。先锁定五类高风险动作做RACI，分别是改价、退款、采购付款、广告预算调整、跨店库存调拨，对每个动作写清谁发起、谁审批、谁执行、谁知会。
硬规则有两条：同一个人不能同时拥有发起和审批权，比如运营不能自审自己提的退款；导出权限单独授予且带时效，涉及客户联系方式和成本的报表默认不可导。填表顺序建议从“最敏感的数据”倒推权限，而不是从“谁想要什么功能”正推，这样能少走很多扯皮。
落地节奏上，先在Excel里画出覆盖退款、改价、库存、导出、财务查看这五类动作的初版，跑两周看有没有误拦，再补长尾模块，比一次性做全更容易推下去。
我们正在选ERP，几家销售都说自己支持子账号、支持多店铺管理，听起来都差不多。预算有限，我确实想先用免费版跑起来。但我担心的是，等团队扩到二十几个人，权限这块会不会又得推倒重来，到时候迁移成本更高。
判断权限能力是否真落地，用四问加一次试用验证就够了。四问是：第一，能不能按店铺或站点做隔离，也就是同一角色在A店可改价、在B店只能只读；第二，有没有字段级权限，成本、利润、客户联系方式能不能对特定角色隐藏或脱敏；
第三，审批流能不能按金额或比例阈值自动触发，比如改价超过10%、退款超过500元自动走复核，并且审批过程留痕；第四，操作日志能不能按人和时间导出，且普通管理员删不掉。
试用验证比听介绍可靠得多：开两个测试子账号，A账号尝试导出含客户信息的订单报表，B账号尝试把某商品价格改动超过阈值，看系统是否拦截、是否生成记录、记录能否被非最高权限账号清除。三项里有两项做不到，说明这家在权限上还停留在“有子账号”的阶段，团队过20人就会疼。
关于免费版，不要问“免费不免费”，要问清边界：店铺数量上限、子账号数量上限、审批流是否收费、日志留存多少天、数据导出是否收费、API授权数量限制、服务响应SLA。把这些逐项填进评估表，一项不支持就把它归到“未来付费成本”，而不是当成已具备的能力。
免费版适合用来验证业务流程和权限模型是否顺手，不适合作为三五十家店阶段的权限底座，选型时把它当作一个待核实的变量，而不是结论。
我们去年搞过一次权限整理，当时所有人重新申请账号、重新分配角色，忙了两周。结果半年后新人进来随手给权限，老员工转岗也没改，现在又回到人人都是管理员的状态。我想知道有没有一个能长期跑的节奏，而不是搞完就烂。
把它当成一个有节奏的运营项目，而不是一次性清洗，用30/60/90天分三段推进。0到30天做盘点和止血：列出店铺清单、人员清单、角色清单，统计现在还存在的共用主账号数量和高风险动作分布，先把共用主账号关掉，建立初版权限矩阵，哪怕只覆盖退款、改价、库存、导出四类动作。
31到60天做试点：挑1到2家店跑通改价、退款、数据导出三条审批流，记录拦截次数和误拦率，误拦率高的阈值要回调，别为了严格把业务卡死。61到90天做全量和审计节奏：全团队推广，同时定下三条固定动作，季度做一次权限复核，人员离职当天回收全部授权，转岗在72小时内完成权限重配，外包权限一律带到期日。
衡量效果的指标要用可查的口径，不用感觉：越权操作记录数（目标0）、离职权限回收时长（当天完成）、共用账号数（目标0）、权限复核覆盖率（目标100%）、审批平均耗时（如果超过半天就要重新设计阈值）。另外，新人入职的权限申请必须走一次审批而不是口头授权，把这一步做进流程，才不会半年后重演。
权限治理没有终点，只有固定节奏，季度复核加当天回收这两条守住，基本就不会烂回去。
读者评论
影子权限”这个说法很准。我们团队8家店12个人，子账号确实人手一个，但权限模板是复制主账号的，客服能看成本价，美工能导出订单。看完才意识到这不是权限管理，只是账号分发。
把权限当骨架而不是功能模块，这个顺序我认同。之前先买ERP再让工具定义权限体系，结果字段级脱敏压根没做，成本利润全员可见，返工成本比一开始画矩阵高得多。
发现延迟这个维度值得单独拎出来。数据外流平均60天才察觉，比越权改价危险得多，但多数团队只盯着发生频率。事前控制优先于事后追责，这一点文章说得很实在。
免费ERP那几条核实清单挺实用。我们就是从免费版起步，后来为了绕开子账号和日志限制，多花了两个人力做人工对账，算下来并不比付费便宜。