2023年第二季度，我帮一个做 Shopee 马来站和 Lazada 泰国站的团队做权限复盘时，看到了一份让我后背发凉的审计记录：一名已经离职 47 天的前客服，仍然可以用旧账号登录 ERP，导出过去 90 天的订单明细。这家团队当时有 27 家店、4 个国家站点、13 个人的运营团队，年 GMV 大约 4200 万人民币。他们买了 ERP，也开了"权限管理"这个功能，但从老板到运营都默认一件事，功能存在不等于制度存在。
这件事之后我形成了一个判断：跨境店群真正的分水岭，不在店铺数量，而在权限能不能跟着组织一起复制。你能开 30 家店，但如果第 30 家店还是要靠一个共享账号、一个微信群审批、一个"我信任他"来运转，那么你开的不是店群，是一堆随时会出事的孤岛。于是就产生了这篇文章的主题，ERP 跨境电商管理模板本质上是围绕权限管理来搭建店群管理体系。
我先给结论，因为它决定了后面所有内容的判断方向：跨境电商 ERP 的管理模板，第一版不应该从商品、订单、采购这些功能模块开始，而应该从权限开始。这是因为商品和订单是"业务动作"，权限是"业务动作的边界"。边界没定，动作越多，风险越大。
过去四年我接触过至少二十个跨境团队，扩张过程中出问题的顺序高度一致，几乎没有例外：
这个顺序里，最贵的成本不是 ERP 的采购费，而是重复发生的越权事件。我粗略统计过自己接触的样本，20 家以上店铺的团队，平均每季度会发生 2，5 次有记录的越权操作，其中约三分之一会造成实际的资金或口碑损失。
很多老板买 ERP 是为了提效，比如自动拍单、自动同步库存、自动对账。但我观察到一个反直觉的现象：同一套 ERP，权限配置成熟的团队，人效提升明显；权限配置混乱的团队，人效甚至下降。原因是当员工不知道自己能做什么、不能做什么时，会花大量时间在反复确认、找领导、重做操作上。
我给过一个 18 家店的团队算过一笔账：上线权限体系之前，运营每天平均花 40 分钟在"这个能不能改""这个要不要审批"的沟通上；权限明确之后，这个时间降到 9 分钟左右。按 8 个运营、每月 22 个工作日算，一个月省下约 91 个小时，相当于释放了半个全职人力。
需要先澄清一件事：本文讲的"ERP 跨境电商管理模板"，不是指某一份 Excel 表格，也不是指某个 ERP 内置的功能包，而是一套可以写进公司制度、可以被系统固化、可以被新员工照着执行的管理规则集合。它至少包含五个部分：角色定义、权限矩阵、数据范围、审批规则、审计机制。
这五部分缺一不可。我见过只做了角色定义、没做数据范围的团队，结果客服能看到全部店铺的利润数据；也见过做了审批流、没做审计日志的团队，出问题后完全查不到是谁干的。
把视角拉回到我 2023 年接手的那家 Shopee 马来站团队。我不想泛泛讲风险，直接把三个月里真实发生的三件事讲清楚，你会更容易判断自己的团队处在什么阶段。
这家团队当时的做法是：马来西亚站用一个主账号，泰国站用一个主账号，分别由 6 个运营共用。老板的认知是"都是自己人，没必要分那么细"。转折点出现在一次大促前夜，两个运营同时在后台调价，一个把某款爆款的价格从 19.9 马币改成了 1.99 马币，持续了约 4 个小时，出了 380 单。
事后追责时，ERP 里只有一条"主账号修改价格"的记录，没有具体到人。这次事故的直接损失约 1.6 万人民币，但更大的成本是，团队从此不敢在大促前放开运营的操作权限，只能让老板一个人改价，反而拖慢了反应速度。
就是开头提到的那件事。前客服离职时，交接清单里写了"归还工牌、交回电脑"，但没人想到要去 ERP 里停用子账号。47 天后，财务在例行核对时发现有一批订单明细被异常导出，追溯 IP 才发现是前员工在家里的网络环境登录的。
这件事让我意识到一个细节：权限的"回收"和权限的"授予"同等重要，但绝大多数团队只重视授予。离职、转岗、长期休假、外包合作结束，每一种状态变化都应该触发一次权限复核，而这件事靠人是记不住的，必须靠系统 + 制度双保险。
我在调研中发现，"跨境电商销售权限申请"是一个搜索热度不低的相关词。但这里有一个非常容易混淆的边界：
这两者是上下游关系，不是一回事。平台权限是"能进这道门"，ERP 权限是"进门后能碰哪些抽屉"。很多团队把这两件事混在一起谈，结果平台账号管得很细，ERP 里却人人都是管理员。
这家团队后来请我做权限重构。我没有立刻推荐任何 ERP，而是先花了整整一周做一件事，把每个人的真实操作范围画在一张白纸上。我让 13 个人分别说出"我每天要动哪些模块、动哪些店、要不要审批"，然后对照 ERP 里现有的权限配置，看差异在哪里。
结果很震惊：ERP 里配置的权限和员工实际需要的权限，重合度只有大约 61%。也就是说，有 39% 的权限要么是多余的（员工根本用不到），要么是缺失的（员工绕开系统用别的方式做）。这种"权限配置和真实工作流脱节"的情况，我后来在几乎所有团队里都不同程度地看到过。
很多团队不是没做权限，而是做错了方向。我总结了五个反复出现的误区，每个误区背后都有一个看起来合理但实际有害的假设。
最常见的配置是：老板一个超级管理员，几个运营一个"运营管理员"，多个客服一个"客服管理员"，然后每个管理员都拥有自己模块的完整权限。这本质上是把"角色"当成了"职级"，而不是"职责"。职级高的人不一定需要改价权限，职责需要的人哪怕职级低也应该有。
正确的做法是职责分离（Segregation of Duties）。比如调价的人和审批调价的人不能是同一个角色，导出客户数据的人和修改订单状态的人不能是同一个角色。这不是不信任员工，而是让系统帮你看住边界。
我见过一些团队，把"权限管理"理解成"给每个人发一个子账号"。这只是最基础的一层。完整的权限至少包含四个维度：
只做第一层，等于给每个人一把能开所有抽屉的钥匙，只是把钥匙样子换了换。
这是最贵的一个误区。ERP 选型阶段不谈权限，上线后再补，会面临两个问题：一是系统可能根本不支持你需要的细颗粒度，二是历史数据已经混在一起，隔离成本极高。
我的建议是：把权限需求写成选型评分表的第一个大项，权重不低于 25%。品牌、价格、拍单速度都可以排后面，因为那些是上线后能调优的，权限架构是上线后很难改的。
我遇到过一个运营总监，他说"审计日志不是我们业务该看的"。结果当一批订单出现异常退款时，他花了两天时间才通过财务对账反推出问题。审计日志的价值不在记录，而在让业务能快速定位问题。运营、财务、客服主管都应该有查看与自己店铺相关日志的权限。
"店群裂变"这个词在搜索里很热，但我想泼一盆冷水：没有权限治理的多开店，是风险的线性放大，不是收益的线性放大。多开 10 家店，如果没有数据隔离、没有岗位分工、没有审批，你增加的是 10 倍的出错概率，而不是 10 倍的利润。
我见过一家 Shopee 店群，从 8 家店扩到 40 家店，前者的月利润大约 18 万，后者成本上升后反而只有 22 万，人效几乎腰斩。原因就是每开一家新店，都要新招人，但新人的权限边界从来没定义过，导致大量返工和纠错。
讲完误区，进入我认为最核心的部分，把权限治理拆成六层结构。这六层是我在多次实践中逐渐定型的，好处是它把抽象的"权限"变成了可以逐层检查、逐层落地的对象。任何一家团队都能照着这六层自查，看自己缺了哪层。
权限是给"组织中的位置"配的，不是给"某个人"配的。所以第一步不是配权限，而是把组织画清楚：有哪些部门、哪些岗位、谁向谁汇报、哪些岗位是跨站点跨店铺的。
我见过的最常见问题是"组织还没有，人先到岗了"。结果是新人来了才临时想"给他开什么权限"，这种随机性会直接导致权限不一致，同样岗位的两个人，权限可能完全不同。
店群管理的一个关键动作是把店铺分组。分组维度通常有三种：按平台、按国家/站点、按店铺组（比如内部定义的 A 组、B 组）。分组的意义在于后面授权时可以按组授权，而不是一店一授权。
我服务的那个 27 店团队，最后分成了 6 个店组：马来 A 组、马来 B 组、泰国组、印尼组、菲律宾组、测试店组。这个分组不是随便分的，而是按运营负责人、按供应链来源、按仓库归属综合定的。分组逻辑一旦确定，权限配置量能下降 60% 以上。
角色层的常见错误是角色过多或过少。过少（比如只有老板、运营、客服三种）会导致权限不够用，员工被迫共用；过多（比如每个员工一个角色）会导致管理成本暴涨，新人来了没角色可用。
我的经验值是：一个 20，40 家店的团队，8，12 个角色基本够用。典型角色包括：老板、运营总监、站点负责人、店长、运营、客服主管、客服、采购、财务、IT/管理员。
功能层就是"能不能进某个模块"。关键是不要孤立地看每个模块，而是按业务链路排：订单 → 商品 → 定价 → 库存 → 采购 → 财务 → 客服 → 报表。每一个节点都要回答两个问题：谁需要看、谁需要改。
这里我要特别提醒高危功能清单：改价、退款、提现、批量刊登、批量删除、导出客户数据、修改店铺授权。这七类操作无论团队多大，都必须单独设权限，且必须带审批或二次确认。
功能权限决定了"能做什么操作"，数据权限决定了"能对哪些数据做操作"。数据范围可以细分为五种：全店（所有店铺）、站点范围、店组范围、单店范围、仅本人创建。
我的建议是：默认给"仅本人 + 单店"，只有明确的负责人给店组或站点范围，全店范围不超过 3 个人。这家 27 店团队最终全店范围只给了老板、运营总监、财务主管三个人，其余全部按店组或单店授权，数据越权事件直接归零。
审计是第六层，也是最容易被跳过的一层。审计要解决的是"权限配置了，但它真的在执行吗"。审计层至少需要三个能力：操作日志、异常告警、定期盘点。
操作日志的字段至少要包含：操作人、操作时间、店铺/站点、操作模块、操作类型、操作前后值、IP 或设备。异常告警则要盯住四类模式：非工作时间高危操作、频繁导出、越权访问尝试、批量删除。定期盘点建议按季度做一次，交接类盘点按次做。
前面讲了逻辑，这一章我给出可以直接复制的模板。这三张模板是我在多个团队里反复使用、逐步定型的，你不需要一次做到位，按顺序铺开就能覆盖 80% 的常见风险。
这是最基础的一张表。横向是角色，纵向是模块，交叉格填权限等级。我给的分级方式是四级：无权限（-）、只读（R）、可编辑（W）、可编辑且需审批（W+A）。不要用"完全控制"这种模糊词，它在不同人眼里含义不一样。
| 角色 / 模块 | 订单 | 商品 | 定价 | 库存 | 采购 | 财务 | 客服 | 报表 |
|---|---|---|---|---|---|---|---|---|
| 老板 | R | R | R | R | R | R | R | R |
| 运营总监 | W | W | W+A | W | R | R | W | R |
| 站点负责人 | W | W | W+A | W | R | – | W | R |
| 店长 | W | W | W+A | R | – | – | W | R |
| 运营 | W | W | W | R | – | – | R | R |
| 客服主管 | R | R | – | – | – | – | W | – |
| 客服 | R | – | – | – | – | – | W | – |
| 采购 | – | R | – | W | W | – | – | – |
| 财务 | R | – | R | – | R | W | – | R |
| IT/管理员 | – | – | – | – | – | – | – | – |
注意最后一行，IT/管理员在业务模块上全部为无权限。这是很多团队会犯错的地方：把系统管理员当成超级管理员。系统管理员的职责是配账号、配角色、看审计，而不是操作业务。业务数据和系统配置分离，这是基本原则。
这张表解决"能给谁看、要不要审批"。审批不是越多越好，审批太多会拖慢反应，审批太少等于没审批。我的经验是只对四类场景设必审：改价、退款、采购、数据导出，其他走事后审计即可。
| 场景 | 触发角色 | 默认数据范围 | 是否需要审批 | 审批人 | 时效要求 |
|---|---|---|---|---|---|
| 单店改价（幅度＜5%） | 运营 | 仅本人负责店铺 | 否 | – | 无 |
| 单店改价（幅度≥5%） | 运营 | 仅本人负责店铺 | 是 | 店长/站点负责人 | 2 小时内 |
| 批量改价（≥5 个 SKU） | 运营/店长 | 本店组 | 是 | 运营总监 | 4 小时内 |
| 退款（金额＜200 元） | 客服 | 仅本人负责店铺 | 否 | – | 无 |
| 退款（金额≥200 元） | 客服主管 | 本店组 | 是 | 财务/运营总监 | 当日 |
| 采购下单 | 采购 | 本店组 | 是 | 运营总监+财务 | 当日 |
| 数据导出（客户信息） | 客服主管/财务 | 本店组 | 是 | 运营总监 | 当日 |
| 新增/修改店铺授权 | IT/管理员 | 全店 | 是 | 老板 | 当日 |
审计日志不是有字段就行，关键是字段要能回答三个问题：谁做的、对什么做的、改成了什么。我推荐的字段清单如下：
{
"operator_id": "U10248",
"operator_name": "张三",
"operator_role": "运营-马来A组",
"timestamp": "2024-08-14T21:37:12+08:00",
"shop_id": "MY-SHOP-018",
"site": "MY",
"module": "pricing",
"action_type": "update_price",
"target_sku": "SKU-20240814-77",
"value_before": "19.90",
"value_after": "1.99",
"currency": "MYR",
"approval_status": "pending",
"ip": "203.0.113.42",
"device": "Chrome/Windows",
"risk_flag": ["off_hours", "price_drop_over_50pct"]
}
异常告警我建议先上四条，覆盖 90% 的高风险场景：
大促期间，经常会遇到"运营临时需要某个店的权限"的情况。如果没有临时授权机制，团队要么违规共享账号，要么层层申请走流程。临时授权必须有三个约束：时效、范围、回收。时效建议不超过 72 小时，范围限定具体店铺和具体模块，到期自动回收。
模板讲完了，但很多人会问：这些规则在真实系统里能不能落地？我以我自己比较熟悉的一个平台，数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）为例，讲一讲权限模板在系统里的落点。声明一下：我用它做样本，是因为它的组织架构和权限设计比较适合讲清楚"权限如何被系统固化"这件事，不是推荐所有人都必须用它。
我在对比多个跨境 ERP 时发现一个差异：有些 ERP 的权限是"店铺附属品"，先建店铺再配权限；有些 ERP 的权限是"组织附属品"，先建组织架构，再把店铺挂到组织下。数跨境走的是后者。
这个差异带来的实践区别很大。组织驱动的权限体系，当你新开一家店，只需要把它挂到已有的某个店组下，权限就自动继承，不需要重新配一遍。对店群团队来说，这就是"复制权限"的能力。我服务的那家 27 店团队，如果用的是组织驱动的系统，扩店时的权限配置工作量大约能减少 70%。
在数跨境里，我通常这样配置：先建部门（比如"马来运营部""泰国客服部""财务部"），再在部门下建角色和成员。角色是最小授权单位，成员是角色的承载者。一个成员可以有多个角色，但每个角色对应一套明确的权限，不会出现"某个人权限很特殊"这种状态。
这一点对审计很重要。当权限是按角色配的，你审计时看到的是"角色 A 做了什么"，而不是"某个人做了什么"。角色是稳定的，人是流动的。离职、转岗只需要换角色的归属，不需要重新设计权限。
数跨境的数据范围配置支持按店铺、按站点、按店组维度限制。我通常建议客户把全店范围控制在极少数人，其余按店组或单店授权。
举个例子：一个负责马来 A 组的运营，他的数据范围应该精确到"马来 A 组"这 5 家店，而不是"马来站"这 12 家店。为什么？因为站点级授权会把不属于他的店铺数据暴露给他，而这些数据里可能含有其他店组的价格策略和利润结构。
审批流的配置逻辑是我在数跨境上比较认可的：把审批条件、审批人、审批时效放在一个流程里定义，而不是分散在多个模块。比如"改价幅度超过 5%"这个条件，可以直接绑定"店长审批"这个动作，并且限制 2 小时内响应。
操作留痕方面，系统会记录操作人、操作时间、修改前后值。我建议客户把前面说的四条异常告警规则都配上，尤其是"非工作时间高危操作"和"频繁导出"这两条。根据我观察的样本，这两条规则覆盖了约 65% 的实际事故场景。
这是一个我认为非常关键但经常被忽略的落点。利润数据是最敏感的权限对象，比订单数据敏感得多。很多团队给运营开放了全部报表，结果运营看到自己店铺的利润率低，就开始怀疑公司抽成，团队氛围变差。
我建议的报表权限分级是：运营只看与 KPI 相关的店铺指标（销售额、订单量、退货率），站点负责人和运营总监看完整利润，全店利润只对老板和财务主管开放。数跨境的报表权限可以按这个思路配，具体到哪些指标能被哪些角色看到。
我把给客户配的一次角色定义整理成了片段，你可以参考这个思路去对照自己的系统：
role: site_lead_my_a
name: "马来A组 站点负责人"
department: "马来运营部"
data_scope:
shop_group: ["MY-A"]
default: "shop_group_only"
permissions:
order: read_write
product: read_write
pricing:
read: true
write: true
require_approval_when:
price_drop_pct: ">=5"
batch_sku_count: ">=5"
inventory: read_write
purchase: read
finance: none
customer_service: read_write
report:
sales_metrics: read
profit_metrics: read
full_shop_profit: none
approval:
price_change_over_5pct: ["store_manager", "site_lead"]
refund_over_200: ["finance_lead"]
audit:
log_all_actions: true
alerts: ["off_hours", "frequent_export", "cross_scope_access"]
这份配置的关键点有几个：数据范围锁死在一个店组、定价改动带审批条件、利润报表只读部分指标、审计告警全开。你可以把这段结构当作对照清单，去检查自己 ERP 的权限配置是否做到了同样的颗粒度。
权限治理没有一刀切的方案，我按团队规模拆成四类，给出可以直接对号入座的行动路径。如果你是操盘手或老板，建议先看清自己属于哪一类，再决定投入多少。
这个阶段最怕两件事：一是过早引入复杂审批拖慢反应，二是完全不做权限管理埋下隐患。我的建议是做两件事、放两件事。
这个阶段的重点是建立"账号即身份"的习惯，而不是追求权限精细度。
这是权限体系的建设期，也是性价比最高的窗口期。这个时期你花两周把体系建好，后面扩店基本不用重构。建议动作：
这个阶段的核心不是"建"，而是"盘"。体系可能已经建了，问题是执行有没有走样。建议每季度做一次权限盘点，检查三件事：
我在这个阶段观察到的一个共性问题：临时授权是僵尸权限的主要来源。大约 70% 的越权事件，都能追溯到一次"当时说好用三天、后来忘了撤"的临时授权。
这个阶段权限治理要制度化、工具化。手动盘点已经不可行，必须依靠系统。核心动作有三个：权限自动巡检、异常告警联动、按季度的权限健康度评分。
权限健康度评分我建议包含五个维度：账号独立率、角色覆盖率、数据范围收敛度、审批覆盖率、审计告警响应率。每个维度按 0，20 分，总分 100。80 分以上的团队，越权事故率通常低于 0.5 次/季度。
权限治理最难的不是技术，而是取舍。这一章我列出四组最常见的取舍，每一组我都给出我的判断依据，而不只是结论。
三种路径各有适用场景，没有绝对优劣。我的判断依据是团队未来 12 个月的店铺扩张速度。
| 路径 | 适用场景 | 主要成本 | 主要风险 |
|---|---|---|---|
| 表格过渡 | 3，5 家店，团队稳定，无海外站点 | 每周 2，3 小时维护 | 无法审计，无法对接系统 |
| 采购 SaaS ERP | 6 家店以上，需要多平台对接 | 按店/按人年费 | 数据存储在外部，需确认合规 |
| 自研/私有化 | 50 家店以上，有自研团队，合规要求高 | 研发 3，6 人月，长期维护 | 迭代慢，需求变化响应慢 |
我的经验是：不要在 10 家店以下自研，也不要在 40 家店以上还全靠表格。前者是资源和时间的双重浪费，后者是风险的指数级积累。
粗权限（角色少、数据范围大）的好处是配置快、员工上手快；细权限（角色多、数据范围小）的好处是风险低、可追溯。我的判断依据是团队的人员流动率。
如果团队平均在职时长超过 18 个月、岗位稳定，粗一点的权限也能撑住。如果平均在职时长低（比如 6，8 个月），必须走细权限，因为人员变更频繁，粗权限下每次变更都会带来混乱。
这是个被反复讨论的问题。我的倾向很明确：只对高危场景设必审，其余场景靠事后审计 + 告警。理由是审批是把"动态风险"转换成"流程成本"，全审批会把流程成本堆到很高，最终员工会绕开系统。
我见过一个团队把改价审批做到每一笔，结果运营晚上大促改价要等审批，人不在，错过窗口期。后来他们改成"幅度 5% 以上才审批"，实际上处理时间反而更快，因为流程更聚焦。
这组取舍的核心是"信息共享带来的协作效率"和"数据隔离带来的安全"之间的平衡。我的建议是按角色区分，而不是统一标准：
需要特别提醒的是利润和成本数据的可见范围要比订单、库存数据更严格。我看到过太多因为利润数据外泄而导致的团队信任问题，这类问题的修复成本远比技术成本高。
虽然本文重点是权限而非数据存储，但这组取舍不得提。数据跨境、平台规则、员工隐私属于高风险信息，必须谨慎评估。我的建议是：
无论选哪条路，我建议守住一个底层原则：权限的复杂度不能超过团队的管理能力。如果一套权限体系复杂到只有 IT 能看懂，那它在业务上就是不可执行的；如果简单到只要一个人离职就全乱，那它在风控上就是无效的。
复杂度的合理区间不是固定的，它由店铺数量、岗位数量、人员流动率、合规要求共同决定。所以我建议每半年重新评估一次自己的权限复杂度是否还合适。店群在变，权限体系也要跟着变。
回到最初的判断：店群能不能复制，取决于权限能不能复制。我见过太多团队把精力花在"怎么多开店""怎么拍单更快""怎么找更多货"上，却忽略了真正决定能不能规模化的那一层，人和权限的边界。
我把整篇文章的核心浓缩成五个原则，你可以直接拿去对照自己的团队：
下一步我建议你做一件具体的事：不要急着换 ERP，先花两个小时画一张自己团队的角色 × 模块权限矩阵表。画完之后，你会非常直观地看到哪些格子是空的（职责没人管），哪些格子是满的（权限叠加过高），哪些格子是乱的（同一岗位不同权限）。
这张表画出来之后，再去看你现有的 ERP 是否支持把它固化下去。如果支持，你只需要做配置；如果不支持，你可能真的需要重新考虑选型。无论你最后用哪个系统，包括我在正文里用来做样本的数跨境，真正决定店群能否走远的，从来不是软件本身，而是你有没有把权限当成一件需要认真设计的事。
我最近准备给团队上ERP，之前一直以为“权限”就是去平台后台给员工申请个子账号。结果运营说ERP里也要配权限，我一时分不清这两个是不是重复劳动，也怕配错了影响店铺正常操作。
不是一回事，两者管的是不同边界。平台后台的权限，比如子账号能看到哪些站点、能否操作订单、能否改价，回答的是“你在平台侧有没有资格做这件事”，由平台规则决定，申请和审核都在平台内完成；ERP里的权限回答的是“你在自己团队的工具里，能看哪些数据、能对哪些店铺做什么动作”，属于内部治理。
两者是叠加关系而不是替代关系：平台给了子账号操作资格，但如果ERP里不限制数据范围，一个客服照样能看到全部站点的客户信息和成本价。
实操建议是先把平台侧的子账号按站点和职能申请好，再把ERP里的角色和数据范围对齐，保证“平台能操作的，ERP里也只在需要的店铺范围内可操作”，避免出现平台受限但ERP全开这种漏斗。
我们现在5家店、8个人，一直是用老板的主账号加几个子账号在跑，谁有空谁上。最近要扩到20多家店，新招的人还没到位，我担心还是这么搞会出事，但又不确定是不是现在就值得花时间做权限体系。
没有一个绝对数字，但可以用三个信号判断：一是同一个人开始跨店铺操作，比如客服同时管3个以上站点店铺；二是出现过高危操作事故，比如改错价、误退款、误删商品；三是有岗位重叠，比如运营兼财务、客服能看成本价。只要中两条，就值得先把角色矩阵做出来，不用等ERP完全上线。
我自己的做法是先写一张最小表：行是岗位，包括老板、运营负责人、店长、运营、客服、采购、财务；列是模块，包括订单、商品定价、库存、采购、财务、报表、客服；交叉格填“只读/可操作/需审批/不可见”。先出文档再配置系统，改文档比改系统便宜得多。
5家店的时候靠人盯还能兜住，20家店时错误是复利式的，越晚做越贵。
ERP销售一直跟我说权限可以自定义，但真到配置页面我又不知道从哪下手。我担心配太严运营干活天天卡审批，配太松又等于没配，想找一套能直接抄的判断标准。
把权限拆成“能看什么”和“能做什么”两层，分别配。数据范围建议设五档：全店、站点组、店铺组、单店、仅本人。多数运营给到站点组就够，客服和财务尽量收到单店或仅本人，成本价、毛利、供应商信息单独做字段级屏蔽。审批不必全上，只锁定损失不可逆或金额大的动作：改价超过阈值，比如低于成本价或降价幅度超10%；
退款和赔付；提现与付款；批量刊登和批量删除；导出客户数据与成本报表；广告预算调整。其余高频低风险操作，比如改标题、回复咨询、小幅调库存，走事后审计就行，不要做事前审批，否则运营会绕过系统去用平台后台操作，反而让ERP数据失真。一个判断口径是：这个操作错了，能不能10分钟内改回来？能，就审计；
不能，就审批。
我们ERP上线小半年了，日志我也知道有，但除了出事的时候翻一下，平时根本没人看。上个月有个离职半年的前员工账号还能登录，我才意识到光配权限不盘点等于白配，想知道别人是怎么把这个动作常态化的。
日志字段至少要能回答五个问题：谁，也就是账号加真实姓名；什么时候；在哪家店哪个站点；做了什么操作；改前改后是什么值。最好再带上IP或设备标识。
光有日志没用，要设异常规则让它自己告警：非工作时间改价、单人单日导出量异常，比如客服日均导出3次突然变成100次、同一账号短时间跨多个站点、批量删除、给新账号开管理员权限。权限盘点建议固定三个触发点，而不是只靠季度检查：新人入职当天按角色模板开权限；转岗当天先收回原岗位权限再开新权限；
离职当天而不是离职后停用账号，并转移其名下店铺和客户。再配合每季度一次全量对账，把ERP里的账号清单和在职名单逐一比对，多出来的立刻停用。这一步听起来笨，但它是唯一能兜住“人走了账号还在”的办法，我见过最长的一个离职账号活了11个月。
读者评论
离职47天还能登录导出订单，这个细节太真实了。我们团队也一样，交接清单只写设备和工牌，从来没人管ERP账号。权限回收比授予更该有制度，靠人记确实记不住。
分钟降到9分钟这个测算挺有说服力。沟通成本平时看不见，但确实是权限不清带来的隐性损耗，换算成人力就很有感了。
权限配置和实际工作流重合度只有61%，这个数据很扎心。很多团队买ERP时只对比拍单和库存功能，权限颗粒度根本不进评分表，上线后再补就晚了。
平台后台权限和ERP内部权限分开讲这点很关键。我们之前就是平台子账号分得很细，ERP里却人人管理员，等于门锁好了抽屉全开着。