去年 11 月，我帮一个年 GMV 大约 4000 万的跨境卖家做账号审计。他们做亚马逊美国站、TikTok Shop 和 Shopify 独立站，团队 23 个人。我导出后台账号清单那一刻有点愣住：17 个有效账号里，11 个是管理员或接近管理员的权限，其中 3 个的登录记录还停留在一个已经离职半年的员工身上。更麻烦的是，他们老板一直觉得"人少，不用搞那么复杂"，结果那半年里，广告账户被人改过两次竞价策略，客服主管可以直接改价下单，没人说得清是谁干的。
这件事让我更确定一个判断：跨境电商 ERP 的权限管理，表面上是"安全话题"，实际上是"效率话题"。很多人搜"ERP 跨境电商管理模板"，想要一份功能清单，但真正的瓶颈从来不是功能够不够，而是权限边界清不清楚。边界不清，效率越高，风险放大得越快。
我做过的十几个跨境团队权限项目里，有一个反复出现的规律：权限管得越细的团队，日常操作反而越快。听起来反常识，但拆开看就合理，因为权限清晰意味着每个人知道自己能做什么、不用做什么、要找谁批，中间那些"问一下老板能不能改价"的来回沟通被消灭了。
在做诊断时，我会把效率拆成一个可以粗略估算的式子，用来跟老板对齐预期：
有效运营效率 =（授权速度 × 审批一次通过率） ÷（越权操作次数 × 异常追溯耗时）
这个公式不严谨，数值也是相对值，但它的价值在于把"安全"和"效率"从对立面拉到了同一个式子里。分子是正向的，分母是负向的，两边都跟权限设计直接相关。如果权限模板设计得当，通常是分子上升、分母下降，效率和安全同时改善。
我反对把"模板"理解成一份 Excel。一份能落地的跨境 ERP 权限模板，我通常拆成四件交付物，缺一件就会在实施阶段卡住：
这四件东西做出来的时间，我实测大概是一个熟练实施顾问 3 到 5 个工作日，加上业务方确认的 2 轮沟通。真正花时间的不是画表，而是让老板和运营负责人对"谁能看到成本价"这件事达成一致。
同样一套 ERP 权限模板，我在内贸电商团队里实施常常两天收工，在跨境团队要拖两周。原因不是跨境团队更笨，而是变量多。下面五个变量，是跨境场景独有的复杂度来源。
一个跨境卖家的订单可能来自亚马逊、TikTok Shop、Temu、Shopify，每个平台的授权机制、数据字段、可用 API 范围都不一样。ERP 里的权限只能管住 ERP 内部，管不住卖家在平台后台的操作。这是我见过最容易被忽略的漏洞：ERP 权限配得很干净，但平台后台还是用同一个邮箱大号登录，权限体系等于漏了一半。
内贸团队常常一个店铺十几个人分工，跨境的常态是一个人管 3 到 5 个店铺的广告，或者一个店群由 2 个人轮班。这就导致权限设计里最关键的维度不是"能点哪个按钮"，而是"能看到哪个店铺的数据"。
运营 A 能看到 B 店铺的利润报表，在跨境团队里往往是事故的开端，不是因为有人会故意使坏，而是因为跨店铺数据可见会让运营下意识地按统一策略调价，忽略不同店铺的定价策略差异。
海外仓、FBA、自发货三种履约方式混在一起时，库存和成本字段的敏感度会急剧上升。再加上多币种结算，一批货的真实毛利往往要在月末才能算清。这期间如果成本价和采购价对全员可见，报价策略基本等于公开。
跨境团队普遍会外包客服、素材、测评对接，这些人的账号生命周期很短，可能只工作两周。如果每次都要 IT 手动配权限，成本高到没人愿意做，最后就是"先给个管理员账号让他自己看着办"。这句话我听过不下五次，每次后面都跟着一次审计发现。
Prime Day、黑五、TikTok 大促期间，运营需要临时拿到更高权限去调价、改库存、处理积压订单。如果系统不支持"限时授权"，团队就只能事后忘记回收。权限的临时性和回收机制，是跨境模板里必须单独设计的一块，而不是靠人记。
下面这些误区，我在实际项目里按出现频率排序。它们的共同点是：短期看起来省事，长期都在还债。
这是最普遍的一个。老板或运营负责人把管理员账号开给核心员工，理由是"方便"。问题在于，管理员账号一旦进入日常操作流，审计日志就失去了区分度，所有操作都记录成同一个账号，出了事也查不出是谁。
我见过一个极端案例：某店铺 listing 标题被批量修改导致搜索权重下滑，追溯日志发现全部来自一个公共管理员账号，四个人用过。最终结论是"查不清"，这才是真正的成本。
很多 ERP 的权限设置界面确实是勾选框：能看订单、能改库存、能导出报表。但如果只按功能勾，忽略了数据范围，就会出现"有权限看订单，但没有边界限定看哪个店铺的订单"。功能权限决定"能不能做"，数据权限决定"对谁做"，两者缺一不可。
有些团队做到了账号唯一，却给所有人配了几乎相同的权限。这在 5 人以下团队还勉强，人数一过 10，客服和财务的权限重叠就会带来问题：客服能看到的客户信息，财务其实不需要；财务能改的成本价，客服不该碰。
我做过一个对比测试：某团队把改价审批从 2 级加到 4 级，结果一个月内改价平均耗时从 3 小时涨到 19 小时，而越权改价事件数没变，因为真正的问题是两个管理员账号权限过大，跟审批级数无关。审批级数的边际收益会迅速衰减，超过 3 级基本只剩拖慢。
正确顺序是反过来的：权限回收动作应该由离职流程触发，而不是靠人想起来。我在审计中发现，账号回收滞后中位数大约是 3 天，最长的超过 200 天。这中间的每一天，都是一个可以正常登录的活跃账号。
跨境团队的所有权链路是：邮箱 → 平台后台 → ERP。如果只在 ERP 做权限治理，前两环没动，效果会打对折。我在审计时会强制要求同时导出平台后台的用户列表，这两个名单不一致，就说明治理没做完。
讲完误区，说我实际用的方法。我不从 ERP 的功能菜单出发设计权限，而是从四个维度建立模型。这个顺序很重要，颠倒过来会反复返工。
为什么数据范围排在操作类型之前？因为实践里，90% 的争议发生在"能不能看到"，而不是"能不能改"。先解决可见性，操作权限的讨论会顺畅很多。
无论团队多小，我都会坚持这三条，它们不是合规要求，而是效率底线：
我也不是教条主义者。以下情况我会主动建议放宽：团队小于 5 人且没有外包时，可以对操作权限宽松，但数据范围（店铺隔离）仍然要设；老板本人的账号可以保留全权限，但要求单独使用、不与运营共用。
这一节给可直接抄的框架。我用"可看 / 可改 / 可审批 / 不可做"四栏描述每类角色，这个格式比单纯的权限勾选表更好沟通，因为它把禁止项显式写出来了。只写能做什么的权限表，在评审时几乎必然被问"那这个能不能"。
可看：全部店铺、全部报表、全部成本与利润字段。
可改：全局配置、角色定义、账号生命周期。
可审批：所有流程的终审。
不可做：不建议参与日常改价与订单操作，避免日志混入个人操作。
可看：负责店铺的订单、库存、广告、Listing 数据；不可见成本价与采购价，可见毛利率区间。
可改：Listing 内容、广告预算与竞价、发货方式。
可审批：一定金额以下的折扣申请（需设定阈值）。
不可做：不能改财务对账数据，不能导出客户联系方式全量数据。
可看：负责店铺的订单详情、物流轨迹、客户沟通记录。
可改：售后状态、备注、补发标记。
可审批：标准范围内的退款（例如 50 美元以下）。
不可做：不能改价、不能删单、不能导出客户名单。客服是外包比例最高的角色，也是权限最需要收窄的角色。
可看：库存数量、在途、库龄、发货任务。
可改：出入库、调拨、盘点结果、报损单。
可审批：报损需双人复核，单人不可终审。
不可做：不能查看成本价与利润报表，不能修改订单金额。
可看：全部店铺的结算、对账、成本、利润数据。
可改：对账标记、成本录入、汇率参数。
可审批：对账差异的调整。
不可做：不能操作订单履约、不能修改 Listing。财务与业务的隔离是双向的，不是只限制业务看财务。
有了角色，接下来是填矩阵。我一般分四层推进，从粗到细，避免一上来就陷入字段级争论。
先决定"谁能看哪些店铺"。跨境团队的典型配置是按店铺分组，运营只挂自己负责的店铺。这里有一个容易踩的坑：如果 ERP 不支持店铺级数据隔离，只能靠"每个人自觉筛选"，那这一层就是纸面上的。选型阶段一定要确认这一点，而不是上线后才发现。
把 ERP 拆成订单、库存、采购、广告、财务、报表六个模块，逐角色勾选可见范围。这一层相对容易达成一致，因为大部分争议在数据范围层面。
成本价、采购价、利润率、客户手机号、客户邮箱、供应商名称，这六个字段我建议单独拉出来讨论。字段级权限是 ERP 选型时最容易忽略、也最影响业务体验的能力。如果一款 ERP 只支持模块级权限，那就只能通过"拆账号"来变通，会牺牲一部分效率。
最后一层才是导出、删除、修改、审批这些动作。这一层的配置建议配合阈值使用，比如"折扣超过 15% 需运营主管审批，超过 30% 需老板审批"。
下面是我给一个真实项目写的权限矩阵片段，用 YAML 表达，好处是可读、可评审、可版本管理：
role: operator_us
display_name: 美国站运营
data_scope:
shops:
amazon_us
shopify_us
warehouses:
fba_us_west
currency: USD
permissions:
order:
view: true
export: false # 订单导出需单独申请，默认关闭
modify_price: false # 改价走审批流
delete: false
inventory:
view: true
adjust: request # 提交调整申请，由仓储确认
listing:
view: true
edit: true
ad:
view: true
edit: true
finance:
view: margin_range # 仅可见毛利区间，不可见成本价
approval_limits:
discount_percent_max: 15
refund_amount_max_usd: 0 # 运营无退款权限
这份配置的价值不在格式，而在于它把"默认关闭"和"需要申请"写清楚了。权限设计的核心动作是决定默认值，默认开放和默认关闭，长期结果完全相反。
矩阵是静态的，流程是动态的。我挑三条跨境团队每天都在跑、又最容易出事的流程，给出权限设计要点。
设计要点是把"申请，审批，执行，留痕"拆成四步，每一步对应不同角色。客服只负责发起，运营或主管审批，执行动作由系统完成而不是人工改数。
我特别建议加"原因码"这个设计。没有原因码的改价记录，三个月后就是一堆无法解释的数字，财务对账时非常痛苦。
库存调整的风险点在于"无声损耗"。盘点差异、报损、调拨如果不留原因，半年后库存账实不符，没人说得清。我的建议是报损必须双人复核，且复核人不能是发起人本人。
另一个细节是权限的时间窗：盘点期间可以临时开放批量调整权限，但盘点结束后自动收回。这比事后人工排查可靠得多。
对账流程的权限设计，重点在数据脱敏和隔离。财务需要看到全部店铺的结算数据，但不需要看到客户个人信息；业务需要看到毛利，但不需要看到银行流水。把"财务可见的数据"和"财务可操作的数据"分开配置，是关键动作。
对账差异超过阈值的记录，应该自动触发告警并抄送老板，而不是等月末汇总。我在一个项目里把差异告警阈值设成单笔 200 美元，上线第一个月抓到 3 笔异常退款，其中 1 笔确实是重复退款。
讲完方法论，说落地工具。跨境团队的一个现实困难是：ERP 管交易流程，数据平台管经营分析，两边权限体系割裂，导致"ERP 看不到成本，BI 又绕过了 ERP 权限"。
在多店铺、多平台的数据汇总和经营分析场景里，我会把数跨境（九数云旗下，官网 shukuajing.jiushuyun.com）作为一类可考虑的方案放到选型清单里。原因不是它功能最多，而是它解决的问题恰好是跨境团队权限治理里最容易被绕开的那一环：分析层的数据可见性。
很多团队的 ERP 权限配得很严格，但运营直接找 IT 导出一份 Excel 做透视表，成本价和利润全在里面。分析层如果没有权限概念，前面的治理就等于开了一扇后门。所以我在项目里会把"分析平台是否支持按组织、按店铺、按字段分配查看范围"列为必查项。
下面是我在某项目里用过的组织与可见范围配置思路，用结构化的方式表达，便于评审：
organization:
name: 美国站运营组
members: [op_01, op_02, op_03]
datasets:
amazon_us_orders # 可见
amazon_us_ad_spend # 可见
all_shops_profit # 不可见
field_policy:
cost_price: hidden
margin_rate: range_only # 仅显示区间，如 20%-30%
name: 财务组
members: [fin_01, fin_02]
datasets:
all_shops_settlement
all_shops_profit
field_policy:
customer_phone: masked
customer_email: masked
这个配置的核心思想是：同一个数据集，不同角色看到不同的字段和不同的精度。运营看到的是"区间"，财务看到的是"精确值"，老板看到的是"全量"。这比简单地"给/不给"更贴近真实业务需要。
在这类权限体系上线后的两到三周，我通常能观察到几个变化：运营自己取数的需求增加（因为不用担心越权），临时找 IT 导数的请求下降，财务对账时因为字段口径统一而减少核对轮次。
这里我要强调一句：这些变化是观察到的方向性变化，不是精确统计。不同团队差异很大，取决于原有基础的混乱程度。基础越乱，改善幅度越明显。
权限体系做完不能只靠感觉。我固定用四个指标做季度自测，都是可以从系统里导出或者人工计时的。
定义：新员工从入职到拥有完整可用权限的时间。计算方式是从入职日到首次成功完成一项业务操作的间隔。
参考基准：有角色模板的团队通常在 1 个工作日内完成；没有模板、需要逐项勾选的团队，中位数在 3 到 5 天。这个指标的改善几乎完全来自"预置角色模板"这一个动作。
定义：提交的审批中，无需补充信息或退回重提即通过的比例。这个指标低，通常不是因为审批人严格，而是因为申请表缺少必要信息。
改善方法很直接：把审批表单的必填字段设计好，比如改价申请必须带原因码和参考价。表单设计比审批人培训有效得多。
定义：单位时间内触发的越权访问、批量导出、删除类操作的总次数。这个指标不需要追求归零，归零往往意味着监控过严或者根本没人用系统。
我关注的是趋势和集中度：如果异常都集中在某一个账号，说明是个人行为；如果分散在很多账号，说明是权限配置问题。
定义：从离职生效日到账号停用的小时数。这个指标我有比较强的立场：24 小时是一个应该守住的线，超过就是流程问题而不是技术问题。
改善的关键是把停用动作挂到离职流程上，而不是依赖 HR 通知 IT。在很多 ERP 里可以通过定期比对 HR 名单与账号名单来自动发现异常，这个对账动作我建议至少每月跑一次。
权限治理最怕一次性大改，因为会打断日常运营。我一般按八周推进，前两周只做盘点不改配置，避免引发抵触。
选一个店铺或一个小组先切换，通常是 3 到 5 人。试点期要盯两件事：是否出现因权限不足导致业务卡住，以及是否有人绕过系统走线下。后者比前者危险，因为它是隐性的。
我不建议把这八周压得更短。见过最快的项目三周上线，结果是在第六周因为运营集体反弹而回滚。权限治理的阻力主要来自习惯，而习惯需要时间。
同一套方法论，在不同规模团队里的执行方式差别很大。我按人数分三档给建议，都是我在项目里实际用过的做法。
这个阶段不需要复杂矩阵，做两件事就够：一人一号，不用共用管理员账号；成本价字段对非财务角色隐藏。这两件事做完，80% 的常见风险就控住了。
剩下的操作权限可以宽松，因为人少、沟通成本低，过度设计反而是负担。这个阶段我更建议把精力放在选一款支持店铺级隔离的工具上，而不是纠结审批级数。
这个区间是跨境团队的主流规模，也是问题最集中的区间：人够多，靠喊话管不住；人又不够多，没有专职 IT。我的建议是把精力集中在角色模板和离职流程两件事上，暂时不要做字段级的细致配置。
典型配置是 5 到 8 个角色，每个角色配一次，新员工按角色分配。离职流程里加一个账号停用节点，由直属主管触发。
超过 30 人，权限开始变成一个需要持续维护的系统。我的经验是每 50 人左右需要一个兼职或全职的权限管理员，职责包括季度审计、角色维护、异常排查。
这个阶段应该引入限时授权和阈值审批，因为业务流程已经复杂到无法用一张静态矩阵覆盖。如果没有专人维护，再好的矩阵也会在半年内腐化，新人临时授权、角色被随意复制、例外越来越多。
最后说取舍。权限治理没有标准答案，只有适合当前阶段的答案。我列几组我认为需要明确做出的选择。
字段级权限能显著降低敏感数据泄露风险，但维护成本不低：每新增一个角色、每调整一次组织架构，都要回头改配置。如果团队没有能力维护，配置越细反而越危险，因为腐化的配置会给人虚假的安全感。
我的判断标准是：如果过去半年没有出现过因为权限不清导致的实际损失，就不必急着上字段级。
加审批级数是最容易做、也最容易做错的动作。我的经验阈值是三级：发起人、业务主管、财务或老板。超过三级，边际收益接近于零，而等待成本线性上升。
替代方案是用阈值和告警替代审批：低金额操作直接放行但记录，超阈值才走审批，异常模式触发告警。这比层层审批高效得多。
集中管理（IT 统一配权限）一致性好，但响应慢；分散自治（各业务线自己管）响应快，但容易失控。我的建议是角色定义集中，角色分配分散：谁能看到什么字段由中心定义，具体给谁由业务主管决定，并留记录。
有些团队想自己写脚本做账号审计，通常撑不过半年。原因不是技术难，而是跨境平台接口变化频繁，维护成本被严重低估。我的建议是把自建精力放在流程上（离职清单、季度审计），把技术能力交给采购的工具。
| 取舍维度 | 偏细 / 偏严 | 偏粗 / 偏松 | 我的建议触发条件 |
|---|---|---|---|
| 权限颗粒度 | 字段级 + 店铺级 | 模块级 | 有外包且多店铺并行时选细 |
| 审批级数 | 三级 | 一级 | 月改价单数超过 100 笔时用三级 |
| 临时授权 | 限时自动回收 | 人工申请与回收 | 大促频率高于每季度一次时用限时 |
| 账号审计 | 月度对账 | 季度对账 | 人数超过 15 人后改月度 |
| 分析层管控 | 字段级脱敏 | 整表分享 | 存在成本价外泄风险时必做脱敏 |
回到开头那个案例。我们用了大约三个月，做了这么几件事：停用 5 个无效账号，把 11 个管理员账号收敛到 2 个，建立 7 个角色，给改价和退款设计了原因码和审批阈值，加了一个每月账号对账的动作。
结果不是"杜绝了所有风险"，这不可能。结果是一些具体的变化：改价审批从原来平均 6 小时降到 1 小时出头（因为提交时就带齐了信息，主管不用来回问），客服主管不再能直接改价，成本价从全员可见变成财务与老板可见，离职账号在 4 小时内停用。
最让我意外的是运营的反馈。我原以为他们会觉得被限制，结果第一个说"这样好"的就是那个管 3 个店铺的运营。他的原话是："以前我不知道哪些能改，每次都要问，问多了老板还烦。现在清楚了，我能直接处理的就直接处理。"
这句话基本就是我想说的全部。权限管理的目标从来不是把人管住，而是把边界画清楚，让每个人在自己的边界里跑得更快。效率提升不是把权限放大，而是把边界定清，让正确的人在小边界内少点几次。
如果你要马上开始，我的建议是按这个顺序做三步：
不需要一次做完。权限体系是会生长的，重要的是先有第一版，然后在真实业务里迭代。如果你正在做多店铺、多平台的数据汇总和权限划分，可以先去 数跨境 看看分析层的数据权限是怎么配的，对比一下自己现在的做法，通常会很快发现几个可以马上补上的缺口。
我们公司现在同时跑亚马逊、Shopee和TikTok Shop，几个运营共用管理员账号，最近出了改价没留痕的事。我想找一份现成的模板照着套，但网上搜到的多是功能清单，不知道一份真正能落地的权限模板该有哪些部分。
一份可落地的权限模板，核心是四件东西：角色清单、权限矩阵、审批流、留痕与回收机制，缺一不可。角色清单解决"谁"：先按岗位定角色，不要按人名定，常见的是老板/超管、运营、客服、仓储、财务、外包/临时账号六类。
权限矩阵解决"能做什么"：横向是模块（订单、商品、广告、库存、财务、客户数据），纵向是操作类型（查看、导出、修改、删除、审批），交叉格填写允许范围，建议用"店铺级+字段级"两层粒度，比如A店运营只能看A店数据，且成本价、采购价、利润率字段默认不可见。
审批流解决"谁拍板"：把改价、退款、库存调整、对账差异这四类高危动作单独拉出来，写明发起人、复核人、终审人和超时升级规则。留痕与回收解决"事后"：所有高危操作必须有操作人、时间、原值、新值四要素，入离职SOP里写清账号停用时限和权限回收清单。
判断依据是看你能否用这套模板回答一个具体问题：某个客服昨天改了一笔订单价格，你能不能在两分钟内查出是谁、改了多少、经过谁审批。查不出来，模板就还没成型。
我们有8个店铺、3个平台，之前按店铺分了权限，结果财务要一个一个店去对账，效率很低；后来改成按职能分，又出现运营能看到别的店铺利润的情况。我一直在纠结到底按哪个维度切分更合理。
正确做法是职能定角色、店铺定数据范围，两个维度叠加，而不是二选一。具体操作：先把角色按职能建好（运营、客服、仓储、财务），再给每个角色绑定数据范围，数据范围可以是单店、店铺组、平台组或全量。
比如"运营"这个角色本身可以只有查看和修改商品的权限，但绑定到"A店+B店"的数据范围后，这个运营就只看得到这两家店。店铺隔离要重点关注三类敏感数据：成本价与采购价、利润率报表、客户联系方式，这三项建议默认不随角色开放，需单独申请并留审批记录。
至于财务对账效率低的问题，不是靠给财务开全店铺权限解决，而是靠建"店铺组"：把需要合并对账的店铺打包成一个组，财务角色授予该组的数据范围，一次操作覆盖多店，既提效又不越界。判断标准很简单：一个新运营入职时，你只需要分配角色+店铺组两步，不需要逐个勾选菜单，说明你的矩阵设计是对的。
上次出了越权导出客户名单的事之后，我把导出权限全关了，结果运营做活动复盘要数据都得找IT提申请，一天来回好几次，怨声很大。我担心再这么下去大家会想办法绕过系统。
权限收紧导致效率下降，通常不是权限设计的问题，而是流程设计的问题。三个可落地的调整方向：第一，把权限从"按人审批"改成"按角色预设"，新入职直接套用角色模板，开通账号的时间应该控制在当天完成，而不是走一次审批等三天。
第二，区分"日常操作"和"高危操作"，日常的订单查询、库存查看、商品编辑这类动作不应设审批，真正需要审批的只有改价、退款、批量导出、库存调整、对账差异这五类，审批项越少越容易被遵守。
第三，用脱敏代替封禁，运营需要看客户数据做复盘，可以开放脱敏后的字段（如手机号中间四位掩码、邮箱部分隐藏），而不是直接不给看。另外必须设一条兜底规则：任何绕过系统私下共享账号的行为，一旦发现按严重违纪处理，否则所有技术手段都会被内部人情消解。
判断口径是看授权耗时和审批驳回率，授权耗时超过24小时、驳回率超过30%，说明卡得太死；驳回率接近0，说明审批形同虚设。
我们团队二十多人，账号基本都是谁要用谁自己申请，离职了有时候忘了停用，等到发现的时候已经过了大半个月。老板让我做一份权限审计的制度，我不知道频次和指标该怎么定才合理。
频次建议分三层：高危操作日志每周抽查一次，全量账号权限每季度盘点一次，离职转岗触发即时核查。可量化的检查标准有四个：一是离职账号回收率，目标100%且停用时间在24小时内，这是硬指标，做不到就是流程漏洞而不是技术问题。
二是权限冗余率，统计有多少账号拥有与其岗位不匹配的权限，健康值应低于5%，超过说明角色模板失控或有人被临时授权后没回收。三是高危操作留痕完整率，改价、退款、导出、库存调整这四类操作的日志完整度应达到100%，缺一条就是风险敞口。四是异常操作响应时长，从系统告警到人工确认处理，建议控制在4小时内。
落地做法上，先导出全部账号和其权限清单，按岗位比对一遍，把所有"管理员""超级权限"账号单独列出来逐个确认必要性，这一步通常能砍掉三到五成的冗余权限。然后建立入职、转岗、离职三张检查表，离职表必须包含账号停用、权限回收、API授权解除、共享凭据更换四项，且要求负责人签字确认。
读者评论
人少不用搞那么复杂”这句话太真实了。我们12人团队也是这样，客服主管能改价、运营能看到全部店铺利润，出了问题全靠回忆。文章里说的数据范围排在操作类型之前，我认同，先解决谁能看到什么，比纠结勾哪个功能有用得多。
从财务角度看，成本价和采购价对全员可见真的是灾难。我们多币种结算，一批货的毛利月末才算得清，报价策略基本等于公开。职责分离那条，管库存的不能同时管财务对账，建议所有跨境团队直接照做。
思路认可，但对小团队有点理想化。五个正式员工还带外包，配7种角色反而没人维护，最后还是回到一个管理员账号。文中也提到5人以下可以放宽操作权限，这点比较务实，可惜篇幅太少，希望展开讲讲怎么落地。
权限矩阵做成四维表确实比纯勾选清楚，我们上线时就是卡在角色数量上，一路涨到15种，没人说得清谁能干什么。看完觉得5到8种是合理区间，超了就说明颗粒度失控，这句话我截图发给了老板。
离职账号回收滞后是我最头疼的。之前同事走了半个月，账号还能登录，临时外包的账号更是没人管。文章说回收要由离职流程触发而不是靠人记，还提到要同时导出平台后台用户名单，这两点我们下季度就改。