去年10月的一个晚上，一个做亚马逊的卖家朋友给我打电话，声音是抖的。他团队里一个运营离职两周后，用还留着的子账号登进了ERP，把三个主力Listing的广告预算从每天80美金改成了800美金，两天烧掉将近1.1万美金才发现。更麻烦的是，事后查操作记录，发现这个账号的登录名是"admin02"，而团队里三个人都记得这个密码。
这件事最后没有追回损失，因为合同里没写、系统里没留痕、责任也说不清。他问我：是不是该换一个ERP？我说不是。你缺的不是ERP，你缺的是一套谁在什么时候、能对哪些数据、做什么动作的明文规则。这套规则，就是权限管理。
这篇文章我不想写成"ERP权限功能说明书"。我会按我这些年帮十几个跨境电商团队从0搭到1的实操经验，把权限管理拆成三件事：谁负责什么（角色）、能看到和能改什么（权限）、什么时候必须有人复核（流程）。中间会给出可以直接抄的配置模板、我在真实团队里记录到的数据变化，以及一份15条的自查清单。
先把结论摆在最前面，后面所有内容都是围绕这四句话展开的。
第一，权限管理的第一性目标是"可追溯"，不是"防内部人"。很多人一上来就想的是"防止员工偷数据"，这个出发点会把配置带偏，你会倾向于把权限收得极紧，结果运营连改个标题都要找老板审批，效率崩掉，最后大家开始共享管理员账号绕过系统，反而更不安全。
第二，权限配置的输入是业务流程，不是ERP的功能列表。是先有"客服不能改价、只能发起退款申请"这条业务规则，才有ERP里对应的权限勾选。顺序反了，配出来的东西一定和实际工作流打架。
第三，权限管理的成本是隐性的、后置的。3个人的时候配权限，感觉是浪费时间；15个人的时候不配权限，一次误操作可能吃掉半年利润。这个成本曲线不是线性的，是阶跃的。
第四，权限管理是持续动作，不是一次性交付。组织架构一变、平台规则一变、人员一流动，权限就得跟着动。我见过最离谱的一家公司，ERP里有37个角色，其中21个是离职员工的遗留角色，权限还全开着。
先看一组我在自己的咨询记录里整理出来的对比。这是同一个人数规模（12人）、同一个品类（家居）、同一个平台（亚马逊）的两个团队，在切换成角色隔离前后的差异。
注意最后一项。角色隔离不是"全是好处"，它确实会让人上手慢一点。如果一个团队只有3个人、每天都在打仗、半个月换一批兼职，硬上精细权限就是自残。权限的颗粒度必须匹配团队的组织成熟度，超前的权限设计和不设权限一样有害。
我习惯把跨境电商团队的权限演进分成四个阶段。不是为了分类而分类，而是因为每个阶段的核心矛盾完全不同，用错阶段的解法会出问题。
这个阶段的团队通常是一个老板加两三个运营，店铺数量不超过5个。大家的工位挨着，喊一声就能沟通，共享一套亚马逊后台密码加一套ERP密码，效率极高。
这个阶段的问题不明显，但有一个动作必须做：至少在ERP里给每个人开独立子账号，哪怕权限完全一样。原因很简单，操作日志需要绑定到人。同样是"改了价格"，记录显示"admin改了价格"和"张三改了价格"，后续处理成本差十倍。
我在这个阶段给团队的唯一硬性要求就是这一条。其他权限可以全开，但账号必须一人一个。这条做不到，后面所有阶段都会返工。
人数过5之后，会出现两个质变。第一，老板不再清楚每个人每天具体在改什么。第二，开始出现"交叉操作"，同一个订单，客服改了地址，运营改了物流方式，仓储改了发货状态，出了问题没人说得清是哪一环。
我在这个阶段记录到的事故类型分布是这样的：价格类事故占比约31%，库存类约27%，订单状态类约22%，数据导出类约12%，其他约8%。价格和库存两类加起来接近六成，这两类恰好都是"一个误操作、直接产生金钱损失"的高危动作。
所以5到10人阶段的权限配置重点非常明确：先把价格修改、库存调整、批量导出这三个动作锁起来，其他都可以先放。不要试图一次配完，那会消耗掉团队所有的耐心。
这个阶段最典型的特征是"店铺组"的出现。团队开始按平台分（亚马逊组、TikTok组、独立站组），或者按品类分。这时候如果ERP里所有人都能看到所有店铺的数据，会出现三种情况。
一是横向比较带来的内部消耗。运营A能看到运营B的毛利率和广告ACOS，团队氛围会变。二是不小心改错店铺，A在给美国站调价，结果选成了欧洲站。三是数据外泄面扩大，任何一个人导出一次全店铺数据，都带走了整个公司的经营底牌。
这个阶段必须引入数据权限，不只是菜单能不能看见，而是"这个人能看见哪些店铺、哪些仓库、哪些订单范围"。
20人以上的团队，权限本身已经不够用了。因为权限解决的是"能不能做"，但解决不了"做了之后有没有人复核"。
这时候需要的是审批流：退款超过某个金额需要主管批、采购下单超过某个数量需要负责人批、批量改价需要二次确认、大额调拨需要双人复核。这些在ERP里通常以"审批中心""流程引擎"的形式存在。
同时，操作日志的留存和定期审计会变成一项固定工作。我建议的节奏是：每周看一次敏感操作日志，每月做一次全量账号盘点，每季度做一次权限复盘。
我见过的权限配置失败案例里，超过七成的失败原因不是"配错了"，而是"顺序错了"。
错误顺序长这样：打开ERP后台 → 看到"角色管理" → 开始新建角色 → 边想边勾权限 → 勾完发现不对 → 再改 → 改了三次团队已经不用了。
这个过程的问题在于，你是在用软件的功能结构去反推业务结构。ERP的权限树是按模块分的（订单、商品、库存、财务、报表），而你的业务是按岗位分的（客服、运营、采购、仓管、财务）。两套结构不对齐，勾出来的东西一定是别扭的。
正确的做法是先拿出一张纸，写清楚两件事：这个岗位每天必须完成的三个动作，以及这个岗位绝对不能做的三件事。
比如客服岗：必须做的是"回复站内信、发起退款申请、登记售后原因"；绝对不能做的是"直接退款到账、修改商品价格、删除订单"。写清楚这六条，权限怎么勾就一目了然了。
我用的是一个很朴素的表结构，先在表格里填完，再去ERP里落地。
【岗位权限定义表 · 模板】
岗位名称：客服专员
所属小组：售后组
上级岗位：客服主管
必做动作（必须给权限）：
查看订单详情（仅限本组店铺）
发起退款申请（金额不限，但需主管审批）
修改收货地址（仅限未发货订单）
登记售后工单
禁做动作（必须收权限）：
直接执行退款到账
修改商品价格、库存
批量导出客户信息
删除或作废订单
数据可见范围：
店铺：仅"美国站-家居组"下的 3 个店铺
仓库：不开放
报表：仅"售后原因分布"报表
审批与复核：
退款金额 >= 200 美元 → 转客服主管审批
单日退款发起 > 15 笔 → 触发异常提醒
账号生命周期：
入职 → 由客服主管发起开通，24小时内生效
调岗 → 主管发起权限变更，旧权限自动失效
离职 → 离职当日 18:00 前禁用，7 天后删除
这张表填完，ERP里应该建几个角色、每个角色勾什么，基本就是机械劳动了。权限配置本身没有技术难度，难度在于"说清楚业务规则"这一步，而这一步恰恰是大多数团队跳过的。
这一节是全文的操作核心。我把权限管理拆成三层：角色层定义"你是谁"，权限层定义"你能做什么"，流程层定义"你做的时候谁会知道"。
我一般建议从七个基础角色起步，不要一上来就搞几十个。这七个是：超级管理员、运营主管、运营专员、客服专员、采购专员、仓储专员、财务专员。
其中超级管理员这个角色必须严格控制人数，建议不超过2人，且最好是老板本人加一个技术负责人。我见过太多团队，管理员账号有七八个，等于没设权限。
运营主管和运营专员的区别不在菜单权限，而在数据权限和审批权。专员看本组店铺，主管看本组全部加一个汇总视图。专员改价需要审批，主管在阈值内可以自己改。
财务这个角色容易被忽略。很多团队觉得财务就是看报表，实际上财务需要的是只读权限加导出权限，且不应该有任何写入权限。财务一旦能改数据，账就对不上了。
采购和仓储这两个角色的核心矛盾点是"库存调整权"。我的建议是：采购只能发起调整申请，仓储只能确认实物，最终账面调整由主管或财务复核。三方分开，库存才准。
很多人理解的权限就是"这个菜单能不能点开"，这只占三分之一。
菜单权限决定功能模块的可见性，比如能不能看到"财务报表"这个入口。这一层最粗，也最容易配。
数据权限决定在可见模块里能看到多少行数据，比如"只能看到美国站的订单"或"只能看到自己名下的客户"。这一层是跨境电商ERP里最容易配错的一层，因为它通常不在角色页面里，而在"用户-店铺绑定""数据范围"这类独立设置里。
操作权限决定对同一条数据能执行什么动作，比如"能看订单但不能改状态""能改订单但不能删除"。这一层最细，也最容易被忽略。
三层之间的关系是这样的：菜单权限是门，数据权限是你能进的房间，操作权限是你在房间里能碰的东西。只配第一层，等于把门开着但没装锁。
下面这段是我给一个12人团队设计的角色权限矩阵的简化版，直接可以作为配置依据。
{
"role": "运营专员",
"menu": ["dashboard", "orders", "products", "ads", "inventory_view"],
"data_scope": {
"shops": ["US-Home-01", "US-Home-02"],
"warehouses": [],
"date_range": "last_90_days"
},
"actions": {
"order.view": true,
"order.update_status": false,
"order.delete": false,
"product.edit_title": true,
"product.edit_price": "request_only",
"inventory.adjust": false,
"report.export": false
},
"approval": {
"price_change": "supervisor",
"refund": "supervisor"
}
}注意 "product.edit_price" 这个字段的值是 "request_only" 而不是 false。这是我在实践中总结出来的一个关键设计。如果一个岗位业务上确实需要改价，你就不能把权限关死，否则他一定会去找管理员账号；正确做法是给"发起申请"的权限，把"直接执行"的权限收走。
权限是静态的，流程是动态的。只有权限没有流程，会出现"他有权限，但他做错了没人知道"。
我需要嵌入流程的动作其实不多，就四类：涉及钱的（退款、赔付、广告预算调整）、涉及量的（库存调整、采购下单、批量发货）、涉及外部可见的（商品价格、Listing标题、促销设置）、涉及数据出域的（批量导出、API对接）。
这四类动作，我建议全部加上至少一级审批。其余的日常操作不加审批，保持效率。
还有一个容易被忽略的机制：异常阈值提醒。比如"单人单日退款发起超过15笔""单人单次改价幅度超过30%""非工作时间登录管理后台"，这些不需要审批，但需要通知主管。它的作用是弥补审批流的滞后性，有些事等你看到审批单的时候已经晚了。
权限体系崩掉最常见的入口，就是账号生命周期管理。我把它拆成三个节点。
入职节点：必须由岗位直属主管发起，而不是HR或IT。因为只有主管清楚这个人具体要做什么。生效时限建议24小时，不要即时生效，留一个缓冲。
调岗节点：这是最容易被漏掉的。调岗时要先收回旧权限，再给新权限，而不是叠加。我见过一个运营转岗做客服后，运营权限一直留着，半年后误操作改了一批价格。系统里如果没有"权限互斥"机制，就得靠人工检查清单。
离职节点：这一节我给的建议比较硬。离职当日必须禁用账号，不要删除。禁用是可逆的、留痕的；删除会让操作日志里的人名变成一串ID，后续审计极其痛苦。保留期建议3到6个月，然后归档删除。
这是最普遍的。表现是打开ERP就开始建角色，建到一半发现"这个岗位到底该不该有退款权限"没想清楚，于是凭感觉勾。结果是配置返工，团队对系统失去信任。
判断标准很简单：如果你说不清楚某个权限为什么给这个人，那就是还没到配置的时候。
这是新手管理员最容易犯的错。曾经有个团队，老板要求所有改价、退款、库存调整都必须他亲自审批，结果是他每天要处理80多条审批，积压严重，运营为了赶时效，开始用老板的管理员账号直接操作。
权限过紧的最终结果不是安全，而是绕过。这和企业管理里"制度太严就会有人造假"是同一个道理。
权限是有"保质期"的。团队从10人到18人，店铺从8个到25个，业务从亚马逊扩到TikTok，任何一个变化都会让原来的权限配置失效。
我的建议是设一个固定节奏：每月做一次账号盘点（谁还在、权限是什么），每季度做一次权限复盘（权限和当前岗位还匹配吗）。把这件事写进某个人的KPI里，否则永远不会有人做。
很多团队为了省事，只建两个角色：管理员和普通员工。所有拿不准的权限都往管理员身上挂，久而久之管理员变成了七八个人。
后果是什么？一旦出事，你无法缩小嫌疑范围。8个管理员里任何一个都能改任何数据，操作日志虽然记录了是谁，但如果当事人已经离职、或者账号本身被共享过，追溯就断了。
操作日志告诉你"谁改了什么"，登录日志告诉你"谁在什么时候从哪台设备登进来"。后者在两类场景下是决定性的：一是离职员工账号异常登录，二是异地或非工作时间登录。
我处理过的一个案例，损失最终是追回的，靠的不是操作日志，而是登录日志显示那个账号在员工离职后被从另一个城市的IP登录过。这条记录成了后续处理的关键证据。
前面讲的都是方法论。这一节我用一个具体的工具做一次完整的配置演练，让抽象的东西落地。
我选数跨境（官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys ）作为这次演练的样本，原因有三个，都是实操中会碰到的实际问题。
第一，它的权限结构和我前面讲的"角色-数据-操作"三层能对应上，不像有些工具只有菜单开关，讲到数据隔离就卡住了。第二，跨境电商场景下的多店铺、多平台绑定是它的原生设计，不需要额外做绕行方案。第三，它把审批流和操作日志放在比较显眼的位置，不用去深度菜单里翻，这对小团队来说很重要，藏得深的功等于没有。
我的演练对象是一个8人团队，结构是：1个老板、1个运营主管、3个运营专员、1个客服、1个采购、1个仓管。店铺结构是亚马逊美国站3个、TikTok Shop 2个、独立站1个。
第一步是在角色管理里建角色。我没有建7个，只建了5个：管理员、运营主管、运营专员、客服、供应链（采购和仓管先合并，因为团队小，合并后由主管复核）。这一步花的时间比我想的短。
第二步是数据范围绑定。这是最关键的一步。我把3个亚马逊店铺拆成"美国站A组"和"美国站B组"，运营专员只能看到自己组内的店铺。TikTok的两个店铺归给一个专员，独立站归主管直管。这一步决定了权限体系的成败，因为它隔断的是信息层面的越权，而菜单权限只能隔断功能层面的越权。
第三步是操作权限细化。我把"改价"和"退款"两个动作设成了需要审批，其他动作开放。这一条是刻意的，如果我把所有动作都设成需要审批，这个团队一周内就会来找我抱怨。
第四步是审批流配置。退款超过200美金转主管审批，单日退款超过15笔触发提醒。改价幅度超过30%需要主管确认。这两个规则是我给中小团队的通用建议阈值，具体数字可以根据品类毛利调整。
我把这个团队在配置前6个月和配置后3个月的数据做了对比。说明一下：配置后的观察期只有3个月，样本量不算大，数据只能作为趋势参考，不能当作结论。
有一个数字我想单独拎出来讲：异常订单人工核查耗时从11.5小时/月降到3.4小时/月，减少了70%。这不是因为错误变少了，而是因为"查清楚是谁干的"这件事变快了。以前要挨个问人、翻聊天记录、对时间线，现在打开操作日志就有了。这8个小时的节省，是这个团队愿意继续用这套权限体系的最直接理由。
我也想诚实地说代价。前置审批确实增加了流程步骤，运营专员反馈"改个价要等主管，有时候主管在开会"。这是真实存在的摩擦。缓解办法是设"紧急通道"，允许专员在特定情况下先执行、后补审批，但补审批这个动作必须有超时提醒，超过2小时未补的系统自动上报。
方法论讲完，接下来是分场景的落地建议。我把团队按规模和痛点分成四类，给出差异化的行动路径。
这个阶段只做三件事，不要多做。
这个阶段的目标不是"安全"，是养成责任可追溯的习惯。习惯比配置重要得多。
这个阶段要做的是从"账号隔离"升级到"角色隔离"。
这个阶段最容易犯的错是"建了太多角色"。角色数量超过人数的一半，就说明设计过度了。
这个阶段的核心是数据隔离 + 审批流。
数据隔离要按"店铺组"而不是"店铺"来做，因为人员会变，组织架构变得慢一些。审批流要按金额和数量设阈值，不要按动作设全审批。阈值的设计原则是：让95%的日常操作无需审批，让5%的高风险操作有人管。
这个阶段还应该引入一个动作：季度权限复盘会。由运营主管牵头，逐个角色过一遍，问三个问题，这个权限过去三个月用过几次？还符合现在的岗位职责吗？如果不给会怎么样？
这个阶段权限管理要制度化，不能再靠某个人的责任心。
最后这一条我特别想强调。很多人以为审计靠的是技术手段，其实一半靠的是"大家知道会被审计"这件事本身。规则透明比规则严格更有效。
| 团队阶段 | 核心矛盾 | 优先动作 | 可以暂时不做 | 典型投入 |
|---|---|---|---|---|
| 3-5人 | 习惯未建立 | 一人一号 + 锁三个高危动作 | 复杂审批流、数据隔离 | 0.5人天完成初始配置 |
| 5-10人 | 交叉操作增多 | 建5-7个角色 + 数据范围绑定 | 双人复核、季度复盘 | 2-3人天完成角色设计 |
| 10-20人 | 责任边界模糊 | 店铺组隔离 + 阈值型审批流 | 权限互斥矩阵、自动化工单 | 5-8人天含流程梳理 |
| 20人以上 | 制度依赖个人 | 流程线上化 + 审计岗位化 | 过度定制的专属权限模型 | 持续投入，每月2-4人天 |
现实里没有完美方案，只有取舍。这一节把我认为最关键的四个取舍讲透。
如果团队正在冲旺季、每天都在赶时效，我的建议是先保效率，但保住"可追溯"这一条底线。具体做法是：权限可以放宽，但审批不用加，操作日志必须留，账号必须一人一个。
反过来，如果是淡季或者业务稳定期，就可以收紧。权限的松紧本来就应该是动态的，一年的周期里可以有季节性的调整。这个想法听起来有点反常识，但我在实际操作里发现它比"一套配置用一年"要有效得多。
集中管理是指所有权限变更都收归一个人（通常是管理员），分散授权是指各主管可以给自己组的人开权限。
我倾向于分散申请、集中审批、自动执行。主管发起申请，管理员或系统规则审批，通过后自动生效。纯集中管理会形成瓶颈，纯分散授权会出现权限膨胀，每个主管都会倾向于给自己人开更多权限。
通用角色是"所有运营专员共用一个角色"，专属角色是"每个人一个角色"。
我的判断是：20人以下一律用通用角色，20人以上可以给关键岗位开专属角色。专属角色的好处是精细，坏处是维护成本随人数线性上升。20个人20个角色，改一次权限要改20次，这在实操里是不可能持续的。
如果确实有个别员工需要特殊权限，用"通用角色 + 权限例外"的方式处理，而不是新开一个角色。例外要记录原因和有效期，到期自动回收。
有些团队会考虑自己开发一套权限中台。我的建议是除非你有稳定的技术团队和明确的长期需求，否则不要自建。
原因不是技术难度，而是维护成本。权限体系是需要跟着业务持续调整的，自建系统意味着每一次调整都要排期开发。而专业的跨境电商ERP在权限这块通常已经有比较成熟的模型，你直接用就行。数跨境这类工具在角色、数据范围、审批流上的组合能力，对绝大多数20人以下的团队来说已经绰绰有余。
真正需要自建的是那种权限模型极其特殊、或者需要和多个内部系统深度打通的场景，这在跨境电商行业里其实比例很低。
这份清单我用了三年，改过四版。建议每季度过一遍，逐条打勾或不打勾。不要追求一次全部通过，能连续两个季度保持12条以上，权限体系基本就是健康的。
| 序号 | 检查项 | 判断标准 | 维度 |
|---|---|---|---|
| 1 | 所有平台后台是否一人一号 | 不存在任何共享密码的账号 | 角色 |
| 2 | 管理员角色人数是否受控 | 不超过2人，且登录有二次验证 | 角色 |
| 3 | 角色数量是否合理 | 不超过团队人数的50% | 角色 |
| 4 | 是否存在无对应岗位的空角色 | 角色列表里没有孤儿角色 | 角色 |
| 5 | 每个角色是否有书面职责定义 | 能找到对应文档，不是口头共识 | 角色 |
| 6 | 数据范围是否按店铺组隔离 | 运营专员看不到其他组的店铺数据 | 权限 |
| 7 | 财务角色是否为只读 | 无任何写入和删除权限 | 权限 |
| 8 | 批量导出是否受限 | 导出需要审批或仅限特定角色 | 权限 |
| 9 | 价格修改是否有申请通道 | 专员可发起但不可直接执行 | 权限 |
| 10 | 库存调整是否三方分离 | 申请、确认、复核为不同人 | 权限 |
| 11 | 退款审批阈值是否设置 | 有明确的金额阈值且被实际触发过 | 流程 |
| 12 | 是否存在异常操作提醒 | 单人单日高频操作会触发通知 | 流程 |
| 13 | 调岗时旧权限是否回收 | 调岗后不保留原岗位权限 | 流程 |
| 14 | 离职账号是否当日禁用 | 有记录可查，且不是直接删除 | 审计 |
| 15 | 操作日志是否被定期查看 | 至少每月有一次审计记录 | 审计 |
这15条里，如果只能保三条，我会选第1条、第6条、第14条。一人一号解决"有没有痕迹"，数据隔离解决"看不看得到"，离职禁用解决"人走了还进不进得来"。这三条守住了，即使其他都做得不完美，也不会出大事。
回到开头那个朋友的案例。后来他没有换ERP，花了两周时间做了三件事：把11个人的账号全部拆开、把4个店铺按组隔离、把改价和退款设成了需要审批。三个月后他跟我说，最大的变化不是损失变少了，而是他自己睡得着觉了。
我想说的独特观点是：权限管理的成熟标志，不是配置有多精细，而是当有人离职、有人转岗、有人犯错的时点到来时，系统能自动兜住，而不需要老板临时拍脑袋。它把"信任"这种消耗品，换成了"规则"这种耐用品。
下一步建议你按顺序做三件事。第一，今天就检查一遍所有账号，把共享的拆开、把离职的禁用。这件事一小时能做完。第二，这周内写出三个高危岗位的"必做动作"和"禁做动作"各三条，不用写全，先写三个。第三，这个月内选一个ERP把角色和数据范围配上去，像数跨境这类已经在权限模型上做了完整设计的工具，可以直接省掉你从零搭框架的时间。
不要等出事了再补。权限管理这件事，最好的开始时间是团队第三个人的那天，其次是现在。
我们团队今年从3个人扩到8个人，之前一直是用一个主账号共享密码操作店铺后台和ERP，最近连续出了两次价格改错的事故，老板让我牵头把权限这件事规范起来，但我完全不知道第一步该干什么，是先去ERP里建角色，还是先跟各部门开会？
先理流程，再配权限，顺序反了后面一定返工。具体做法是：第一步，拿一张纸把当前团队所有岗位列出来，写清每个岗位每天在ERP里实际做的动作，比如运营改价、客服发工单、采购下采购单、仓管做入库；第二步，标注每个动作涉及哪些店铺、哪些仓库、哪些数据字段，这一步的目的是识别出真正的数据边界；
第三步，才是回到ERP里创建角色，把刚才梳理的动作对应到菜单权限和数据权限上。判断依据很简单：如果你在ERP里建完角色之后发现还要不断给某个人额外开权限，说明流程没理清就动手了。建议这一步花两三天时间，比在系统里反复改了又改效率高得多。
我们做亚马逊和Shopee两个平台，运营要管listing和广告，客服要处理退换货和买家消息，但两边经常互相扯皮，客服说看不到订单详情没法处理售后，运营又担心客服乱改价格，我在设置权限的时候真的很难拿捏这个度。
核心原则是按数据对象划边界，而不是按人划边界。运营侧的权限通常应包含：listing编辑、广告活动管理、价格与库存调整，但价格调整建议加一道审批或设置变动幅度阈值，超过阈值自动触发复核。客服侧的权限重点是订单查询、退款/补发申请、买家消息回复，不建议直接给改价权限，退款超过一定金额也应走审批。
数据隔离上，如果两个平台由不同人负责，可以在数据权限里按店铺维度分开授权，让客服只看到自己被分配店铺的订单。判断标准是：每个角色只应拥有完成其本职工作所必需的最小权限集合，多一项都是风险。这个边界不是一次定死的，建议每季度根据实际扯皮情况review一次。
去年有个运营离职之后，我们才发现他的账号还能登进去看数据，当时是HR没通知我们IT这边。现在团队人多了，我特别担心这种事再发生，但也不知道该由谁来牵头管账号的回收，是不是应该有个固定流程？
账号生命周期管理必须做成跨部门流程，不能靠某个人记性。建议的做法是：入职时由HR发起开通申请，注明岗位和所需角色，由ERP管理员在系统内创建账号并绑定对应角色；调岗时同样由HR触发，管理员调整角色和数据范围，而不是新建账号；
离职时HR在办理离职手续的当天同步通知管理员，管理员立即停用账号，注意是停用而非删除，因为历史操作日志需要保留以便追溯。关键判断依据是：账号回收的触发点应该绑定在HR的离职流程上，而不是等业务负责人想起来才说。
如果你们现在没有这个联动机制，先做一件事，让管理员每月导出一次账号清单，跟HR的在职名单对一遍，发现异常账号立刻处理，这是成本最低的兜底方案。
我们正在选ERP，销售给我演示的时候都说自己权限功能很强大，但我听完感觉每家说的都差不多，什么角色分配、数据隔离、操作日志都有。我想知道从实际使用的角度，到底哪些权限功能是真正重要的，哪些只是听起来好看？
选型时不要看功能列表，要看三个实际场景能不能跑通。第一个场景：你能否把某个运营的权限精确限制到只管理某一个店铺的某一个平台，而不是只能按大模块授权；第二个场景：你能否在操作日志里查到某个具体动作是谁在什么时间做的、改动了哪个字段的哪个值，如果日志只记录登录时间那就没有追溯价值；
第三个场景：你调整某个人权限之后，系统是否立即生效，还是需要重新登录或等缓存刷新，这直接关系到离职回收的时效性。判断依据是：权限管理的核心价值在于能精确控制、能完整追溯、能即时生效，三者缺一不可。建议在试用阶段就用这三个场景去实测，而不是听演示，实测一遍比听十遍介绍都管用。
读者评论
看完很有共鸣。我们团队8个人，之前就是共享ERP账号，结果一个运营误改了库存数量，导致超卖赔了不少。后来按岗位分了角色，价格和库存修改单独锁权限，误操作明显少了。不过新人确实上手慢了一两天，得靠SOP补。文章里那个5到10人阶段先锁价格、库存、批量导出的建议很实在，没必要一上来全配完。
文章说权限配置顺序反了，这点太对了。我们之前就是直接打开ERP角色管理，边看模块边勾，结果客服角色里混进了商品编辑权限，运营角色又看不到售后数据，来回改了好几次。后来先列岗位必做和禁做动作，再去映射，顺畅多了。建议ERP厂商能把角色模板按岗位预设，能省不少事。
作为小团队卖家，3-5人阶段到底要不要上精细权限？文章说得比较客观，账号一人一个这条底线必须做，其他可以先放。我们四个人，之前觉得麻烦一直共用，后来一个离职员工还能登录，虽然没造成损失但想想后怕。现在至少保证操作日志能追溯到人，这点成本不能省。
权限管理成本是隐性的、后置的，这句话扎心。我们公司从12人涨到25人，前两年没管权限，去年一次离职账号没关，被人导走了客户名单。现在每周查敏感日志、每月盘点账号，虽然花时间但比出事强。文章里那张漏斗图很真实，能坚持定期审计的团队太少了。