去年十一月，我陪一家做了四年亚马逊的卖家做 ERP 上线复盘。他们选型用了三个月，实施用了两个月，功能验收单上打满了勾。上线后第 37 天，一名负责两个北美店铺的运营离职，第二天团队才发现，这两个店铺的后台登录权限、广告账户密码、以及一份包含近半年订单数据的导出文件，全都还在她个人手里。IT 部门花了 11 天才把权限一层层收回，中间还把主账号的二步验证重置搞挂了一次，店铺后台被锁了四个小时。
这件事最反常识的地方在于：他们的 ERP 里有一套完整的多角色权限模块。从选型演示到实施培训，厂商前后讲了三次。但直到出事那天，那套模块里只有一个角色，「管理员」，绑定了六个人。老板的理由很直接：人少，图方便。
我后来做了个粗略统计：在自己经手或深度访谈过的 18 个跨境电商 ERP 项目里，真正因为「功能不够用」而落地失败的，只有 2 个；剩下 16 个的问题都出在同一件事上，权限没理顺，流程就固化不下来，系统最后退化成一个贵一点的 Excel。
所以这篇文章的结论，我放在最前面：跨境电商 ERP 落地的第一道关卡不是选型、不是功能、也不是数据迁移，而是权限管理。把权限理清楚，标准化管理才有骨架；权限不理清楚，再好的 ERP 也只是把混乱搬到了线上。
先摆一组我自己的观察数据。这不是行业报告，而是我复盘 18 个跨境电商 ERP 项目时的归因统计，同一个项目可以有多条归因，所以总和大于 18。
「权限与账号管理混乱」出现在 14 个项目里，是最普遍的一条。它的典型表现是：主账号共用、离职权限不回收、越权导出数据、权限变更无记录。
排在第二的是「流程未定义就上系统」，出现在 11 个项目里。这一条其实和权限高度相关，因为权限本质上是流程的镜像，你连谁该审批什么都不知道，怎么可能配得出角色。
「数据迁移不干净」出现在 7 个项目里，「员工抵触、不用系统」出现在 6 个项目里，「功能不匹配」只出现在 2 个项目里。
很多老板一听「标准化管理」就想到 SOP 手册、绩效考核、组织架构图。这些东西都对，但它们的共同问题是：太大、太虚、落不了地。
权限不一样。它是一个可以在两三天内做完、当天就能看到效果的动作：把角色列出来、把资源列出来、把动作列出来，做一张矩阵。矩阵一旦成型，你会发现它自动回答了一堆原本吵不清楚的问题。
比如：客服能不能看到采购成本价？美工能不能导出客户邮箱？新来的运营助理能不能直接改广告预算？离职前 7 天要不要自动降权？这些问题在 SOP 手册里可能写三页纸都没写明白，但在权限矩阵里就是一行单元格。
我的判断是：权限矩阵是标准化管理的最小骨架。骨架搭好了，SOP、考核、复盘才有地方挂。
这句话听起来违反直觉。大多数人的担心是：权限一严，员工处处受阻，就会抵触系统。
但我在实际项目里看到的恰恰相反。真正导致员工抵触的，不是「权限严」，而是「权限乱」，同一件事，今天 A 能做，明天只有 B 能做，后天又要找老板开权限，没人知道规则是什么。
规则清晰的严，是可预期的严。员工知道自己的边界在哪、怎么申请、多久能批下来，反而会更快上手。规则模糊的松，才是真正的效率杀手，因为所有事都要临时找人。
一种极端是「全员管理员」。六个人共用一个管理员账号，操作日志里全是同一个名字，出了事查不到人。这种团队一旦超过 10 个人，库存差异、广告误操作、数据外泄基本是必然事件。
另一种极端是「三级审批到改一个 SKU 标题」。我见过一个团队，运营想改一个产品标题，要经过主管、经理、老板三层审批，平均耗时 1.5 天。结果运营干脆绕开系统，直接去平台后台改，ERP 里的数据反而成了错的。
这两种极端背后是同一个错误：把权限当成管控手段，而不是协作协议。权限设计的目的不是「防住谁」，而是「让对的人在正确的时间做正确的事，并且留下痕迹」。
我做过一份对照梳理。以一个 30 人规模的团队为例，国内电商（天猫+京东）和跨境电商（亚马逊+Shopee+TikTok Shop+Temu）在权限管理上的差异是这样的。
| 对比维度 | 国内电商（以天猫+京东为例） | 跨境电商（多平台多站点） |
|---|---|---|
| 需要纳管的平台账号数 | 2-4 个 | 6-20 个（含站点拆分） |
| 典型角色数 | 4-6 类 | 8-14 类（含跨时区协作） |
| 一次权限变更的平均审批节点 | 1-2 个 | 2-4 个 |
| 高价值账号（资金/广告/主账号） | 相对集中 | 分散在多平台、多主体、多币种 |
| 离职权限回收涉及的动作数 | 约 5-8 项 | 约 15-30 项 |
| 数据出境与合规约束 | 较弱 | 较强，涉及多地主体和收款链路 |
这是跨境电商最要命的一个特点。国内电商大部分操作在天猫京东后台，账号归属相对清晰。但跨境电商的店铺账号，往往是老板注册的、运营使用的、第三方服务商可能也接触过。
于是就出现了一个经典的糊涂账：这个店铺到底归谁管？运营说我在用，主管说我在管，IT 说我没记录。
我的做法是，强制区分两个概念：账号所有权（谁是企业侧责任人）和账号使用权（谁在什么条件下可以操作）。所有权永远绑在具体的人身上，不绑岗位，因为岗位会换人；使用权则应该有时效，到期自动复核。
我见过一家做 Temu 和 TikTok Shop 的团队，店铺主账号绑的是离职半年的前运营主管的手机号。因为平时没人用主账号登录，一直没发现。直到平台要求做一次安全验证，团队才意识到自己进不去自己的店铺。
找回流程走了 9 天，期间两个店铺的提现暂停，涉及金额我记不太清具体数字，但团队负责人跟我说「比一个月利润还难受」。
国内电商团队的组织架构往往是树状的：运营部、客服部、仓储部、财务部，各自权限边界清楚。
跨境电商团队更像是网络状的。一个运营助理可能同时做客服回复、Listing 优化、广告调价；一个美工可能要接触产品素材库，而素材库里包含成本信息；财务既要对接平台回款，又要对接支付服务商，还要看采购成本。
这时候如果按「部门」配权限，一定会出错。必须按「动作集合」来配。也就是说，角色的定义不是「他是哪个部门的」，而是「他需要做哪些动作」。
一个典型场景：深圳的运营主管晚上 10 点发现美国站的广告异常，需要临时调整预算权限；但审批人在欧洲出差，6 小时时差。等审批下来，广告已经烧掉了半天预算。
所以跨境团队的权限设计必须包含「紧急通道」，预先定义好哪些动作可以走事后补审，哪些必须事前审批。没有紧急通道的权限体系，一定会被员工用各种方式绕过。
我把跨境电商团队的账号资源分成三级：
很多团队出事，恰恰是因为把三级账号的开放度用在了二级甚至一级账号上。他们不是不重视安全，而是从来没做过分级。
「我们就 8 个人，配什么权限？」这句话我听过太多次。
问题在于，团队不是静止的。8 个人的团队一年内可能进出 5 个人，店铺从 2 个变成 8 个，平台从 1 个变成 4 个。等到需要权限的时候再补，你会发现历史操作记录是空白的，账号经手过谁已经说不清了。
权限这件事，越晚做成本越高，因为你要补的是历史。而历史往往补不回来。
这是最隐蔽也最普遍的一个误区。团队按岗位建角色：运营角色、客服角色、财务角色。听起来很合理。
但实际运行三个月后，往往变成：运营角色被加了 12 个附加权限，因为每个人需求都不一样；客服角色被加了导出权限，因为客服要做周报；财务角色被加了广告查看权限，因为财务要核算 ROI。
最后所有角色的权限都趋同，等于没分。
正确的做法是：角色应该按「动作组合」定义，而不是按「岗位名称」定义。同一个岗位的人，可以同时挂两个角色。
我通常把角色拆成三类基础模块，再按需组合：
一个运营主管的正常配置是：数据域（北美区+欧洲区查看）+ 操作域（广告调价、Listing 编辑）+ 审批域（管辖范围内的广告预算审批）。三个模块清晰分离，任何一块要调整，不影响另外两块。
我抽查过一个 45 人团队的角色权限配置，发现有人同时持有 6 个角色的权限，其中 4 个是半年前项目需要临时加的，项目早就结束了。
这就是权限的「棘轮效应」，只往上加，从不往回收。原因是回收权限需要有人主动提出，而加权限只需要有人开口要。
解决办法是给所有临时权限设默认有效期。我的经验值是 30 天/90 天两档：临时任务 30 天，长期职责 90 天。到期前一天自动提醒，不续期就自动失效。这一个动作能砍掉至少一半的权限冗余。
很多团队以为权限管理就是「能不能登进系统」。但真正的风险往往不在登录，而在数据。
一个人可以合法登录系统，但他应该看到全部店铺的利润数据吗？他应该能把客户名单导出成 Excel 吗？他应该能看到采购成本价吗？
我把这类控制叫做「数据域 + 动作」的双重约束。同一个资源，查看、编辑、导出、删除是四个完全不同的动作，风险等级差得很远。导出往往是风险最高、管控最松的那一个。
权限体系和操作日志是一体两面。只有权限没有日志，你只能知道「谁理论上能做」，不知道「谁实际做了什么」。
我要求的最低标准是：关键动作必须留痕，且日志必须包含四要素，谁、什么时间、对什么资源、做了什么动作。低于这个标准，出了纠纷等于没有证据。
大多数人做权限管理，直接跳到「权限矩阵」，行是人，列是功能，打勾。表做得漂亮，但三个月后就废了。因为它缺了三个维度：资源的归属关系、动作的风险等级、时间的有效期。
我用的框架是四层：主体层 → 资源层 → 动作层 → 时间与留痕层。这四层必须按顺序设计，跳层一定会返工。
主体不只是内部员工。跨境电商团队的主体至少包括五类：正式员工、试用期员工、外包/兼职、外部服务商（代运营、ERP 实施顾问、货代）、系统账号（API 对接、自动同步）。
很多团队漏掉最后一类。API 账号往往是权限体系里最大的一个洞，因为它通常只有一个密钥，谁拿到都能用，且不绑定具体的人。
我会把所有资源按「资产属性」分四类：店铺资产（店铺账号、Listing、评价）、资金资产（收款账户、广告预算、采购付款）、数据资产（订单、客户信息、成本、利润）、内容资产（素材、品牌资料、供应商信息）。
分类的目的是确定管控强度。资金资产永远最严，内容资产可以最松，中间两类的强度取决于团队规模。
我把动作分成五级，风险从低到高：
| 动作级别 | 动作定义 | 典型场景 | 建议管控 |
|---|---|---|---|
| L1 查看 | 读取数据，不可修改 | 查看订单、查看报表 | 按数据域开放 |
| L2 创建 | 新增记录，不改动已有 | 新建 Listing 草稿、新建广告活动草稿 | 按角色开放，需审核后生效 |
| L3 修改 | 改动已有数据 | 改价格、改预算、改库存 | 按角色开放 + 额度限制 |
| L4 导出 | 把数据带出系统 | 导出订单、导出客户信息 | 单独审批 + 强制留痕 |
| L5 授权 | 改变权限本身或资金流向 | 改收款账户、分配权限 | 双人复核，单人不可完成 |
这五级里，最容易被忽略的是 L4。绝大多数数据泄露不是「有人偷偷看了」，而是「有人合法导出了」。
前两层管「能给什么」，这一层管「什么时候收回」和「怎么查」。核心是三件事：默认有效期、变更记录、异常告警。
默认有效期解决棘轮效应；变更记录解决纠纷追溯；异常告警解决「已经发生但没人发现」。第三件事最容易被跳过，但它恰恰是最有价值的。
什么叫异常？比如：同一个账号在 2 小时内从两个不同国家的 IP 登录；某个平时只查看数据的账号突然执行了批量导出；某个权限在凌晨 3 点被修改。这些信号如果不告警，等到你发现的时候，往往已经晚了。
下面是我在项目里常用的角色配置结构，写出来给需要的人参考。字段设计的关键是：每个角色都必须有 owner、有效期、资源域和禁止项。尤其是「禁止项」，只写「能做什么」的权限配置，是不完整的。
role:
name: "北美站运营-中级"
owner: "运营主管-张三" # 角色责任人，不是员工本人
data_scope:
stores: ["US-Store-A", "US-Store-B"]
platforms: ["amazon_us"]
metrics: ["order", "ad", "inventory"]
excluded_fields: ["cost_price", "supplier_info"] # 明确禁止字段
actions:
allow: ["view", "create_draft", "edit_listing", "adjust_ad_budget"]
deny: ["export_customer", "edit_payout_account", "delete_listing"]
quota:
ad_budget_daily_max: 3000 # 单日调价额度上限
price_change_max_pct: 15 # 单次改价幅度上限
approval:
required_for: ["export_customer", "ad_budget_over_quota"]
approver: "运营主管-张三"
validity:
default_days: 90
auto_downgrade_on_expiry: true
audit:
log_actions: ["edit_listing", "adjust_ad_budget", "export_*"]
alert_on: ["cross_region_login", "bulk_export", "privilege_change_offhours"]
这份配置看起来有点啰嗦，但它解决的是三个具体问题：谁负责这个角色（owner）、到期怎么办（validity）、出事怎么查（audit）。缺任何一个，这份配置都会在半年内失效。
我接触过的大部分跨境电商团队，在 ERP 上线前后都会经历一个「影子权限期」。
这个阶段的特征非常明显：ERP 里只有一两个角色，但团队实际运作依赖的是一堆系统外的权限，微信群里发的店铺密码、某个共享表格里的账号清单、老板手机上的验证码。
我见过最夸张的一个团队，店铺密码存在一个共享文档里，文档权限是「知道链接即可编辑」，团队 23 个人加 4 个外部服务商都访问过。他们对此的解释是「方便」。
这个阶段不出事，靠的是运气，不是管理。
一旦开始认真配权限，通常会进入第二个阶段：权限爆炸。
因为所有人都突然发现自己「做不了事了」，于是集中提申请。这个阶段最典型的现象是：一周内收到 30 多份权限申请，审批人根本来不及判断，最后全部通过。
这是权限治理最容易失败的节点。不是因为方案错了，而是因为节奏错了，一次性收紧太多，业务受不了，就会反弹回原点。
我的做法是分批推进：先收 L5（授权类）和 L4（导出类），这两类动作频率低、风险高，收紧的阻力最小；L1-L3 维持现状，用 2-3 个月慢慢调。
进入第三阶段的标志很明确：权限变更不再需要老板拍板，团队自己就能按规则走完。
这时候会出现几个可观察的变化：新员工入职当天权限自动就位、离职当天权限自动冻结、临时权限到期自动失效、异常操作自动告警。人不再需要记规则，规则跑在系统里。
这就是我说的「标准化落地」，不是写了一本手册，而是流程不需要人盯着也能跑完。
在我做的权限治理项目里，数据侧的盘点往往是最费时间的环节。因为权限不只是「能不能登进 ERP」，还包括「能看到多少数据」。这两件事经常不在同一个系统里。
我自己在做多平台、多店铺的数据权限梳理时，会借助像数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）这样的跨境电商数据工具做交叉验证。它把亚马逊、Shopee、TikTok Shop 等多平台多店铺的经营数据汇总到一起，好处是能让我在一个视图里反推「谁看见了哪些店铺的哪些指标」。
具体来说，我用它主要验证三件事。
角色表里写的是「张三只能看北美站」，但实际数据视图里他是不是真的只看到了北美站？这件事手工核对非常痛苦。用统一的数据视图做对照，能把误差暴露出来。
我遇到过一个典型案例：角色配置上某运营只有 A 店铺权限，但因为他加入了一个跨店铺的报表订阅组，实际上能看到全部 8 个店铺的利润数据。这一类「配置正确但实际越权」的问题，只有把角色表和数据视图放在一起看才能发现。
权限管理和数据口径是连在一起的。如果不同角色看到的口径不一样，权限设计就没有意义，因为大家讨论的根本不是同一个数字。
我建议在权限梳理的同时，把核心指标的取数口径固定下来：利润是按哪个口径算（含不含头程、含不含广告费）、库存周转是按哪个时点算、退款率是按下单口径还是退款口径。这些口径一旦统一，权限分层才有基准。
这是我在选型时最看重的一点。工具能不能把「店铺维度」「成员维度」「指标维度」三层拆开授权，直接决定了你的权限矩阵能不能落到数据层。
如果只能做到「这个成员能看这个店铺」，那你的权限矩阵就只能在店铺这一层做文章；如果还能做到「这个成员能看这个店铺的订单和广告，但不能看成本和供应商」，你的管控精度就上了一个档次。具体功能的支持范围以官网说明为准，选型时建议用自己的真实角色矩阵去试用对照。
这个阶段最大的风险是「过度设计」。我见过 12 人的团队花两个月设计角色矩阵，最后发现用不上。这个阶段只需要做三件事。
这个规模是权限管理投入产出比最高的阶段。团队已经有分工，但还没到流程僵化的程度。
核心动作是两件：一是按「动作组合」而不是「岗位」建角色，把角色数控制在 8-12 个；二是给所有临时权限加默认有效期，30 天和 90 天两档就够。
同时建议开始做季度权限复盘。复盘不需要很复杂，拉出三张表就够：当前所有角色及成员、过期未回收的权限、本季度异常操作记录。三张表摆在一起，问题基本会自己浮现。
到这个规模，团队通常是多主体、多区域、多币种运作，权限已经不可能靠人管。
这时候必须做到的是：权限变更全程留痕、关键动作异常告警、数据域按主体和店铺严格隔离、审批链按金额和风险分级（而不是按职级一刀切）。
有一个判断标准我很喜欢用：如果老板休假两周，权限相关的事情还能正常运转吗？如果不能，说明权限体系还没建起来，只是暂时由人扛着。
不是所有事情都值得标准化。我的判断原则很简单：看这个动作一旦做错，能不能撤回。
能撤回的（改个标题、调个库存数量）可以宽松，甚至不需要审批，只要留痕。不能撤回的（改收款账户、删除 Listing、导出客户数据、转移资金）必须严格，宁可慢也不能错。
| 动作类型 | 可逆性 | 建议管控强度 | 建议审批方式 |
|---|---|---|---|
| 修改 Listing 标题/描述 | 高 | 低 | 免审，留痕即可 |
| 调整广告预算（额度内） | 高 | 低 | 免审，额度限制 |
| 调整广告预算（超额） | 中 | 中 | 单级审批 + 事后复盘 |
| 修改商品价格（幅度内） | 中 | 中 | 免审，幅度限制 |
| 批量导出客户数据 | 极低 | 高 | 事前审批 + 强制留痕 |
| 修改收款账户 | 不可逆 | 极高 | 双人复核，单人不可完成 |
| 删除 Listing / 关闭店铺 | 不可逆 | 极高 | 双人复核 + 冷静期 |
| 分配/变更权限 | 可逆但影响大 | 高 | 角色 owner 审批 + 全程留痕 |
有几件事我明确建议不要过度标准化。
客服回复话术、Listing 图片替换、优惠券小额调整，这类动作频率高、风险低、可逆性强。给它们设审批，只会把运营逼到系统外操作。
我的经验值是：如果一个动作每天发生超过 20 次，且单次影响可控，就不应该设事前审批，只设额度上限和留痕。
新平台、新品类、新市场的探索阶段，流程本身还没定型。这时候如果按成熟业务的权限标准去卡，探索会被直接卡死。
建议做法是：给新业务设独立的资源域和独立的角色，允许更宽的权限，但设一个明确的「转正时间点」。到期后按成熟业务标准重新配权限。这样既保护了探索，也不留长期风险口子。
我见过把审批做成四级的团队，理由是「大公司都这么做」。结果所有事情的平均处理时间从 4 小时涨到 2 天，员工开始用微信口头确认，系统里的审批流变成了形式。
审批层级的数量应该由金额和风险决定，而不是由职级决定。一个 500 美元的广告预算调整和一个 5 万美元的付款，不应该走同样长的流程。
上面 18 条，如果打勾少于 6 条，说明团队处于「影子权限期」，建议先从账号清单和离职 checklist 做起，不要急着上复杂系统。
打勾 7-13 条，说明已经有基础，重点应该放在角色定义的细化和有效期机制上。
打勾 14 条以上，说明体系基本成型，接下来要解决的是「持续运转」，也就是让权限变更、审计复盘、异常告警变成不需要人催的例行动作。
回到最开始那家团队。后来我们做的事情其实不复杂：把 3 类主体、4 类资源、5 级动作列成矩阵，给每个角色配 owner 和有效期，把导出动作单独拆出来做审批，把异常登录做成告警。整套动作前后用了不到三周。
他们的运营总监后来跟我说了一句话，我觉得比任何方法论都准确：“以前我们不是不知道该管，是不知道从哪开始管。权限一列出来，所有该管的地方自己就浮出来了。”
我想强调的独特观点是：权限管理在跨境电商 ERP 落地里的价值，被严重低估了。大家习惯把它当成一个 IT 配置项，实际上它是标准化管理最容易撬动的那根杠杆，因为它具体、可验证、有即时反馈，而且能把「组织架构、流程边界、数据安全、审计追溯」这四件虚事同时落到一张表上。
标准化管理不是约束人，是让团队在人员流动、平台扩张、业务变化中依然跑得稳。权限是这套稳定机制的第一颗扣子。第一颗扣子扣错了，后面怎么调都是歪的。
如果你现在就要动手，我建议按下面的顺序，不要跳步。
这五步走完，你会发现 ERP 里那些原本「配了但没人用」的功能，开始有人用了。不是因为功能变好了，而是因为规则清楚了。标准化管理的落地，往往是从一张权限矩阵开始的。
我们团队二十来个人，运营、客服、采购、仓管、财务都挤在一个ERP里，之前是老板拍脑袋给了几个管理员账号，结果谁都能改价格、谁都能看利润表。我想重新梳理一遍角色，但又怕照搬大公司的岗位表会把流程搞得更死板。到底该按岗位分、按平台分，还是按店铺分？
按"动作"而不是按"岗位名称"来划分，是中小跨境团队最实用的一条原则。具体做法是先把团队在ERP里真正会发生的操作列出来，通常不外乎这几类：查看经营数据、修改商品和价格、处理订单和售后、操作采购与库存、查看和操作资金与账单、导出数据、配置系统与账号。然后把每个岗位对照这张动作清单打勾，形成角色。
判断依据是：同一个角色内部的权限差异越小，后面出问题的概率越低。如果你的运营既管亚马逊又管独立站，而这两个平台的定价策略完全不同，就应该拆成"运营-亚马逊"和"运营-独立站"两个角色，而不是给他一个大而全的运营角色。
团队在20到50人时，角色数量控制在8到15个比较合适，太少会导致权限过粗，太多会导致维护成本高于收益。另外一定要有"只读"类角色，给老板、财务和外部顾问用，避免他们为了看数据而拿到修改权。
梳理完之后先跑两周，记录每周的权限调整申请，如果某个角色每周都在被临时加权限，说明这个角色的边界划错了，要回去改角色而不是继续打补丁。
我试过做权限表，但一细化就变成几十行上百个勾，自己都维护不动；一粗放又出现客服能看到全店利润、美工能改Listing这种问题。到底哪些权限必须卡死，哪些可以放开？有没有一个能落地的颗粒度标准？
用一个"三层颗粒度"模型来判断，比追求全字段精确控制更可行。第一层是必须卡死的高风险权限，包括收款账户和提现相关操作、成本与利润数据查看、批量改价和批量上下架、店铺账号密码与API密钥的查看、数据导出。这几类不论团队多小，都要做到"能看的人不超过3个，能改的人不超过2个"，并且每次操作必须留痕。
第二层是按角色放的常规权限，比如订单处理、退款额度、库存调拨，这类可以按金额或数量设阈值，例如客服单笔退款500美元以内自主处理、超过就走审批。第三层是可以默认开放的权限，比如查看自己负责店铺的订单列表、下载自己处理范围内的报表。
判断颗粒度是否合适的标准是：一个新员工入职，你花多长时间能给他配好权限？如果超过15分钟，说明角色划分还不够，需要把常用组合固化成模板；如果只花1分钟但事后经常要临时加权限，说明卡得太死。记住权限设计的目标不是把人管住，而是让异常操作能被发现，所以"可审计"比"不可操作"更重要。
我们去年有个运营离职，人走了但ERP账号还开着，后来发现他还在用手机端看老东家的广告数据，虽然没造成损失但想想挺后怕。跨境这行人员流动快，还有兼职和外包，到底该怎么设计权限回收流程，才不会每次离职都手忙脚乱？
把权限回收从"离职当天的事"提前成"日常机制"，是唯一可靠的做法。具体分三层落地。第一层是账号归属制度：所有平台主账号、ERP管理员账号、收款账号一律用公司邮箱或公司手机号注册，员工只拿子账号，这条必须在入职时就讲清楚并写进合同附件，否则离职时你连主账号都拿不回来。
第二层是权限与人事状态绑定：在ERP里给每个账号标注归属人、所属角色、有效期，外包和兼职账号一律设置到期时间，比如90天自动失效，需要延期就重新申请，这样即使HR忘了通知，系统也会自己关。
第三层是离职回收清单：把ERP权限、平台子账号、企业微信或飞书、共享文档、广告后台、物流系统、收款工具这几项列成一张表，由HR发起、IT或运营主管执行、财务复核，三方签字才算完成，重点是必须有人复核，不能自己关自己的权限。
另外建议做一次"权限静默期"检查，员工提出离职后到正式离开前，把其账号降为只读，避免最后几天批量导出数据。判断流程是否有效，可以每季度做一次抽样：随机抽3个已离职人员的账号，看是否还能登录任何系统，只要有一个能登录，说明流程有漏洞。
我们公司一共十几个人，没有IT部门，ERP是老板兼着管的，现在还在用一张Excel表记录谁有什么账号密码。我知道这不安全，但要一下子买一套权限管理或者IAM系统又觉得太重。在正式上系统之前，有没有一个成本低、能马上开始的做法？
可以先用"一张表加三条规矩"过渡，但要明确这套做法的边界，别把它当成长期方案。那张表至少要包含六列：系统或平台名称、账号类型（主账号/子账号）、归属人、当前权限级别、是否共享、最近一次复核日期。
三条规矩是：第一，密码不进Excel，Excel只记录"谁有权限"，密码统一放在公司认可的密码管理工具里，个人不掌握明文；第二，共享账号一律标注为"技术债"，每周例会上过一遍，能拆成子账号的尽快拆，亚马逊、Shopee这类平台都支持给员工开子账号并分配权限，没必要共用主账号；
第三，每月最后一个工作日做一次权限复核，逐行确认归属人是否在职、权限是否还需要，确认完在"最近一次复核日期"那列更新，超过60天没更新的行要标红。
这套做法的上限大概在20人、5个平台、3个店铺左右，超过这个规模或者开始出现跨部门协作时，Excel就压不住了，会出现同一账号多人共用、复核流于形式的问题。
这时候再考虑用ERP自带的角色权限模块，或者引入密码管理和单点登录工具，迁移时把Excel里"是否共享"这一列当作重点清理对象，共享项清零了，标准化管理的地基才算打好。
读者评论
我们公司去年上ERP也是这个问题，选型花了三个月，结果上线后大家还是共用一个管理员账号，操作日志根本查不到人。文章说的权限矩阵确实是第一道坎，早点看到能少走弯路。
做亚马逊三年，最深的体会就是账号所有权和使用权必须分开。之前主管离职，主账号绑的是他的手机号，找回流程走了快两周，提现都停了，比文章里说的还惨。
权限越严落地越快这个观点我一开始不信，但我们团队试了之后确实如此。以前申请权限没人知道找谁批，现在规则写清楚，反而没人抱怨了。
文章对跨境和国内电商权限复杂度的对比挺到位的。我们做TikTok Shop和Temu，光平台账号盘点就搞了好几天，离职回收清单漏一项都是雷。