多店经营的权限失控，往往不是技术问题，而是没人把经营边界画清楚
去年年底我帮一个做家居品类的卖家做 ERP 梳理，他们三个平台一共开了 27 家店，团队 18 个人。我进后台第一件事是拉权限清单，结果发现：运营总监的账号能看全公司所有店铺的毛利和广告花费，客服主管的账号里躺着亚马逊北美站的成本价，一个离职两个月的运营账号还在，备注写着"临时保留，等她交接完"。
老板跟我说，他不是不想管权限，是不知道从哪切。切细了运营抱怨效率低，切粗了他自己睡不着觉。这个困境非常典型，跨境电商的多店经营，最难的一环从来不是开店，而是开店之后权责怎么分。
这篇内容我打算把这个问题彻底拆开：先给结论，再讲四种真实的组织形态，然后拆误区、给模型、上案例、列清单。所有涉及平台政策和产品功能的描述，建议你以官方最新文档为准，我尽量讲清判断逻辑而不是替你下结论。
我见过太多团队把权限管理当成一个"IT 配置任务"：买完 ERP，让实施顾问把角色建一建，账号发一发，就算完事。三个月后问题冒出来，数据泄露、利润算不清、责任追不到人，然后回头怪系统不好用。
我的判断是，这个顺序从一开始就错了。权限是经营边界的系统映射，边界没定，配什么系统都会乱。
你先问自己一个问题：这家店是谁的？这个问题听起来像废话，但它决定了三件事，谁能看这个店的利润、谁能改这个店的价格、谁为这个店的亏损负责。
如果是公司主体直营，那店铺归属公司，运营只是执行者，权限应该收在"岗位职责"这一层。如果是合伙人各带一个店群，那店铺归属个人，运营有利润分成，权限就必须按"利润中心"来切，甚至要看得到自己那部分的完整财务报表。
同一个 ERP 系统，这两种组织的权限配置方案几乎没有重合度。所以正确的顺序是：先画组织与店铺的归属矩阵，再决定系统里怎么配。跳过第一步直接配系统，你配的不是权限，是巧合。
这是我认为整个多店权限管理里最本质的一句话。老板要的是统一：一个看板看全部店铺的 GMV、利润、库存周转。而运营、财务、客服要的是隔离：运营不该看到别人店铺的订单，客服不该看到成本价，财务不该被无关店铺的流水干扰。
这两个诉求天然对冲。你越追求统一看板，数据面就越宽，越容易泄露；你越追求严格隔离，跨店调拨、跨店库存共享、跨店客户查重就越难做。
所以我给所有多店卖家的建议是：不要把"统一"和"隔离"当成一个二选一的问题，而要当成分层问题。汇总层可以统一，明细层必须隔离。老板看的是汇总层，运营看的是自己店铺的明细层，中间用数据权限而不是用人工导表来连接。
这句话听起来有点绝对，但我的观察是准的。10 家店以内的团队，靠人情和微信群还能兜住；到了 20 家店、30 个人，没有权限体系一定出事；到了 50 家店以上，权限体系不行的公司，增长会直接卡在"招人不敢招、放权不敢放"这一步。
原因很简单：权限颗粒度决定了你能把多大的决策权下放给一线。如果你的系统只能做到"运营能看所有店铺"，那你永远不敢让新来的运营独立管店；如果你能做到"运营只看自己店铺、只看非成本字段、改价必须走审批"，你就敢放。
在讲怎么做之前，我需要先把"多店经营"这个词拆开。因为不同的人说多店，指的根本不是一回事。我给卖家做诊断时，第一件事就是让他对号入座，看看自己属于哪一类。分类错了，后面所有配置都会跑偏。
这是最常见的形态。一个公司主体，在亚马逊、eBay、Shopee、TikTok Shop 上开了若干店铺，团队集中办公，运营按店铺或按类目分工。
这类组织的权限诉求非常明确：运营之间互相看不到对方店铺的订单和利润，但主管和老板要能看到全部。最常见的冲突是运营之间互相打听对方的爆品数据，或者是新来的运营通过系统导出老店铺的客户名单。
我服务过的一个卖家公司，20 家店，8 个运营。他们的做法是每个运营只能看自己店铺的订单明细、广告数据、库存，但可以看到全公司的汇总排名。这个设计挺聪明，横向排名能激发竞争，纵向明细能防止抄袭。
公司规模上来之后，会自然分化出事业部或者区域管理。比如亚马逊一个事业部、Shopee 和 Lazada 一个事业部，或者北美站、欧洲站、东南亚站各设负责人。
这种形态下的权限设计，关键在"中间层"：事业部负责人需要看到自己事业部的全量数据，包括利润和成本，但不应该看到其他事业部。总部的财务需要看到全部，但可能不需要看到每个 SKU 的运营细节。
事业部型最容易踩的坑是"权限继承"。很多 ERP 的组织架构是树状的，事业部下面挂小组，小组下面挂人。如果你在配置时只设了总部和运营两层，事业部这一层的权限就会变成要么全开要么全关，中间那一档最需要精细控制的位置反而空了。
代运营是我的客户里权限诉求最复杂的一类。因为他们的数据不属于自己，属于客户。客户随时可能问一句"你们团队的谁看过我的广告后台"，你得答得出来。
这类组织的权限设计有两条硬要求：一是按客户 / 项目做数据硬隔离，二是所有敏感操作必须留痕。硬隔离的意思是，A 项目的运营在系统里不应该有任何路径能看到 B 项目的订单、库存或财务数据，哪怕是通过导出、报表、API 这些侧门。
留痕的意思是，谁在什么时候改了什么价格、导出过哪些客户数据、给哪个订单退了款，全部要有日志。这不只是管理需要，也是代运营公司在谈客户时的信任资产。
合伙制比较特殊。每个合伙人带一部分店铺，独立核算利润，甚至用的是不同的收款主体和不同的币种结算。这时候权限不只是"能不能看"的问题，而是"看的是哪一套账"的问题。
我见过的最典型的冲突是这样的：合伙 A 觉得系统里显示的利润不对，因为他看到的成本里混进了合伙 B 的共享物流费。这不是权限配置错误，这是成本分摊规则没定清楚，然后被权限系统暴露了出来。
合伙制的权限设计，必须先定核算规则，再定数据权限。顺序反了，系统上线那天就是吵架那天。
| 组织形态 | 核心隔离维度 | 最容易被忽略的权限点 | 建议审批层级 |
|---|---|---|---|
| 店群型 | 店铺 | 导出权限、客户名单可见性 | 2 级（运营，主管） |
| 事业部 / 站点型 | 事业部、站点、区域 | 中间层角色的数据范围继承 | 3 级（运营，事业部，总部） |
| 代运营型 | 客户 / 项目 | 跨项目导出、API 越权、日志留存 | 2 级 + 全量审计 |
| 合伙 / 项目型 | 利润中心、主体、币种 | 共享成本的分摊规则、跨主体收款 | 2 级 + 财务独立复核 |
这部分是我做诊断时最有价值的部分。因为很多卖家不是不愿意做权限管理，而是被一些听起来很对、实际上有害的说法带偏了。
最常见的做法是：打开系统，建几个角色，管理员、运营、客服、财务，然后把账号往里一塞，收工。
问题是，"运营"这个角色在不同店铺、不同平台、不同类目下的权限需求完全不同。亚马逊运营需要广告数据，Shopee 运营需要物流对接，独立站运营需要客户邮箱。你用一个统一的"运营"角色去覆盖，结果只能是权限给得过宽。
正确的做法是按"岗位职责 + 数据范围"两个维度组合建角色，而不是按岗位名称建角色。"北美站运营"和"东南亚站运营"应该是两个角色，即使岗位名称都叫运营。
功能权限管的是"能不能点这个按钮"，数据权限管的是"点完之后能看到谁的数据"。绝大多数权限事故，出在后者。
举个我实际遇到的例子：某卖家的 ERP 给客服开放了"订单查询"功能，但没限制数据范围。结果一个客服通过订单查询，把全公司 20 家店的客户邮箱全部拉了出来，跳槽时带走了。
功能权限是门锁，数据权限是告诉你哪扇门通向哪个房间。只配功能权限不配数据权限，等于给所有房间装了同一把钥匙。
这两件事必须拆开，而且拆得越细越好。典型的敏感操作包括：改价、退款、采购下单、付款审批、导出客户数据、修改库存。
我见过一个案例：运营可以改价，但公司没做审批流，结果一个大促前夜，一个运营把某款产品的价格改成了原价的十分之一，两个小时出了 4000 单。事后复盘发现，系统日志里只有"某账号修改了价格"，没有任何审批记录，责任无法界定。
我的建议是：所有会直接产生资金影响或客户影响的操作，都要走审批或者至少要有二次确认。不是不信任员工，是让流程替人兜底。
这是我最想提醒的一点。市面上有些 ERP 宣传能"防止店铺关联"，把权限管理和账号安全混为一谈，这个说法非常危险。
平台对多店铺的判定规则是平台方制定的，且会持续更新。任何第三方工具都不能承诺"规避平台风控"或"保证不关联"。我可以负责任地说，把这句话写进选型标准里的卖家，迟早要吃亏。
权限管理能做的、也应该做的是：最小权限原则、账号二次验证、操作留痕、API 授权范围控制、设备和登录异常告警。这些是内控手段，不是对抗平台风控的手段。两者不要混。
权限是活的。人员会流动，组织会调整，平台会新增站点，类目会扩张。我见过太多公司，系统上线时配了一遍权限，两年没动过，结果系统里躺着 60 多个账号，其中 15 个属于已离职员工。
我的做法是给客户定一个硬规则：离职当天必须回收账号，组织架构调整必须在 5 个工作日内同步到系统，每季度做一次权限复盘。这三条听起来简单，但能执行的公司不到三成。
这是最后一个，也是最容易被忽略的。有些老板做权限管理的思路是"能不给就不给"，结果运营连自己店铺的完整数据都要申请才能看，效率大幅下降，最后大家绕开系统，用微信传 Excel。
一旦数据绕开系统流转，你的权限管理就彻底失效了，因为你管的是一个没人用的系统。权限设计的黄金标准不是"最严"，而是"刚好够用且可追溯"。
讲完误区，该给方法了。我在给卖家做权限设计时，用的是一套五层模型。这五层不是并列的，而是有严格的先后顺序，配错了顺序，后面每一层都会返工。
角色是权限的容器。我的建议是，角色命名应该包含"职责 + 数据范围"两个信息。比如"北美站运营（全字段，仅本店）"和"东南亚站运营（无成本字段，仅本店）"，这是两个角色，不要合并。
同时要区分"岗位"和"角色"。一个人可以身兼多个角色，一个角色也可以有多个人。这个灵活性非常重要，因为跨境电商团队经常一人多岗，尤其是成长期的公司。
我通常会建议客户先做一件事：把所有人列出来，每个人写清楚"他需要做什么决策"。需要做定价决策的人要给成本数据，需要做备货决策的人要给库存和销售数据，需要做客户决策的人要给订单和客户数据。从决策倒推权限，比从功能列表正推要准确得多。
数据权限决定了"你能看到谁的数据"。在跨境电商 ERP 里，数据权限的维度通常包括：店铺、站点、主体、仓库、SKU、币种、客户、订单状态。
其中最需要精细设计的是三个维度：
店铺维度是最基础的，决定你能不能跨店看数据。字段维度控制的是敏感字段，比如成本价、毛利率、供应商信息、客户邮箱，这些字段应该单独控制可见性，而不是跟店铺绑定。金额维度控制的是币种和主体，涉及多主体收款时特别重要。
我经常用一个比喻：数据权限不是一道门，而是一组可调的百叶窗。你可以让某个人看到汇总数字，但看不到明细；看到明细，但看不到成本；看到成本，但看不到客户信息。每一条缝隙都可以单独控制。
功能权限一般分四类，很多公司只配了前两类：
导出权限我要单独强调一下。绝大多数数据泄露不是发生在系统界面里，而是发生在一份导出的 Excel 里。建议对导出做三件事：限制可导出字段、限制导出条数、记录导出日志。
流程权限管的是"这个动作需不需要别人点头"。哪些动作需要审批？我的清单是：改价（尤其是降价超过阈值）、退款、采购下单、付款、跨店调拨、批量导出客户数据、修改成本价。
审批流的设计有两个原则。一是审批人不能是申请人自己，这在很多小团队里反而是最常见的问题，老板自己改价自己批。二是审批节点不宜超过两级，超过两级，大家就会开始想办法绕过流程。
前四层是"事前"和"事中"，审计是"事后"。审计日志至少要覆盖：登录记录、权限变更记录、敏感操作记录、数据导出记录、异常行为告警。
审计日志的价值不在于"抓人"，而在于两件事：一是让员工知道有记录，行为会自我约束；二是出问题时能快速定位，而不是全员互相怀疑。
我给你一个可以直接抄的权限矩阵模板，用 YAML 表达，方便你在跟 ERP 厂商沟通时直接对他们的配置项：
roles:
name: "运营-北美站"
functional:
menus: ["订单", "广告", "库存", "报表"]
buttons: ["查看", "备注", "创建补货单"]
export: { allowed: true, max_rows: 5000, fields_excluded: ["成本价", "供应商"] }
api: ["read:order:own_store", "read:inventory:own_store"]
data_scope:
stores: ["US-01", "US-02"]
sites: ["amazon.com"]
currency: ["USD"]
fields_hidden: ["cost_price", "gross_margin", "supplier_name", "customer_email"]
approval:
price_change: { required: true, approver_role: "运营主管" }
refund_over: { threshold: 200, currency: "USD", approver_role: "客服主管" }
audit:
log_retention_days: 365
alert_on: ["bulk_export", "cross_store_query", "off_hours_login"]这份模板的价值不在语法，而在于它把五层模型落成了一张可核对的结构。你可以拿这张表去问 ERP 厂商：这上面每一项，你们的系统支持到什么颗粒度？他们的回答质量，基本就是这个产品在权限能力上的真实水平。
讲完模型，我拿一个具体工具来演示。这里我选用数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）作为样例，原因有两个：一是它面向的正是多平台多店铺的卖家群体，权限场景比较典型；二是它的产品结构里，数据看板和组织管理是并列的模块，方便我把上面的五层模型映射进去讲。
需要提前说明：下面的配置过程和数据变化，来自我为一个 23 家店的跨境卖家做梳理时的实际记录，其中具体数值做了脱敏处理，属于样本推演性质，用于说明方法而非产品评测。
很多卖家在选 ERP 时会陷入一个误区：把注意力全放在"有没有某个功能"上，而忽略了"这个功能的数据能被谁看到"。
数跨境的产品逻辑是数据分析和经营看板先行，这就意味着它的权限问题会更早暴露，因为看板一旦做出来，所有人都会想看，如果不做数据范围控制，第一个月就会变成全员数据透明。
这个卖家的具体情况是：3 个平台、23 家店、31 名员工，包括 12 名运营、4 名客服、5 名财务与供应链、3 名主管、1 名运营总监、1 名老板。他们的初始状态是所有人共用一个管理员账号看所有数据。
我带着他们的运营总监做了四步。
第一步，画店铺归属矩阵。把 23 家店按平台、站点、运营负责人列成一张表，标出每家店的经营主体和利润归属。这一步花了两天，但暴露出一个此前没人注意的问题：有 4 家店是早期用另一个主体开的，财务一直按老主体做账。
第二步，定角色。最终建了 7 个角色，而不是最初设想的 4 个。多出来的 3 个分别是"运营-含成本"（给主管级）、"客服-仅订单与客户"、"财务-全店汇总无明细"。
第三步，配数据范围。这是耗时最长的一步。运营角色绑定到自己负责的店铺，同时隐藏成本价、毛利率、供应商三个字段；客服角色绑定到店铺但隐藏成本价与客户邮箱；财务角色可以看到全部店铺，但被限制在汇总层，不能下钻到单个订单。
第四步，配审批与审计。改价超过 15% 需要主管审批，退款超过 200 美元需要客服主管审批，批量导出超过 1000 行自动告警并通知运营总监。
整个过程从开始到上线用了三周，其中配置本身只占 4 天，剩下的时间全花在画矩阵和跟各部门对权限边界上。这个时间分配很说明问题：权限管理的成本主要不在系统里，而在会议室里。
上线三个月后，我回访了这家公司，拿到几组对比数据。
运营对新人的带教周期从平均 6 周缩短到 3.5 周。原因是新人可以直接看自己店铺的完整数据看板，不需要反复找老运营要报表。
财务的月度结账时间从 9 个工作日缩短到 5 个工作日。原因不是系统算得快，而是数据口径统一了，不再需要人工核对不同运营发来的不同版本 Excel。
客服的平均响应时间从 4.2 小时降到 2.6 小时，因为客服可以跨店查询同一客户的历史订单，不需要再在群里问"这个客户在别的店买过吗"。
但我也要说一个反面的观察：上线第一个月，运营的投诉量上升了。主要抱怨集中在"看不到自己店铺以外的类目趋势数据"。后来我们补了一个只含类目均值、不含店铺明细的公开看板，才把这个问题解决。
我的判断是：工具能解决的是"配置能不能做到"，不能解决的是"该不该这么配"。
数跨境这类产品在配置层面能覆盖店铺维度隔离、字段级可见性、角色组合、审批触发、操作日志这些能力，这部分是工具的价值。但店铺归属怎么划分、成本数据该不该给运营看、共享物流费怎么分摊，这些全是经营决策，没有任何工具能替你回答。
所以我给卖家的建议一直是：先花两周把经营边界讨论清楚，再花四天配系统。反过来做，你会花三周配系统，然后花三个月返工。
权限管理没有标准答案，但可以按规模给出不同的起手式。以下四档是我在实际项目中总结的，你可以直接对号入座。
这个规模不建议搞复杂权限体系，投入产出比不划算。但有三件事必须做，成本极低。
第一，账号实名。不要出现"运营1""运营2"这种账号，也不要用共用账号。第二，回收离职账号，离职当天执行。第三，成本价字段对非核心人员隐藏，这一条能挡住大部分数据外流。
这个阶段真正的风险不是流程复杂，而是账号失控。把账号管住，比什么都管用。
这个规模是权限问题开始集中爆发的阶段。建议动作是：按"职责 + 店铺范围"建 5 到 8 个角色，配置店铺级数据隔离，字段级隐藏成本与客户信息，改价和退款上审批。
同时建议开始建审计日志，至少保留一年。这个阶段做的投入，会在 30 家店的时候替你省下大量的返工。
到这个规模，老板已经看不过来所有细节了，必须引入中间层。权限设计要解决的核心问题是：中间层管理者应该看到什么，不应该看到什么。
我的建议是，中间层看自己负责范围的全量数据（含成本和利润），但看不到其他范围。总部看全部汇总，需要下钻时走单独申请。同时，跨范围的调拨和共享必须走审批。
这个阶段权限管理已经不是"配置工作"，而是一个独立的内部系统项目。需要考虑的包括多主体核算、多币种结算、跨主体调拨、数据跨境合规、审计留痕周期、API 权限治理。
我建议这类公司设一个专门的岗位或者至少有一个明确的责任人，负责权限的日常维护和季度复盘。没有责任人的权限体系，会在半年内自然腐化。
| 店铺规模 | 角色数量建议 | 必须做的三件事 | 可以暂缓的事 |
|---|---|---|---|
| 5 家店以下 | 3 个以内 | 账号实名、离职回收、成本字段隐藏 | 复杂审批流、中间层分权 |
| 5-20 家店 | 5-8 个 | 店铺级数据隔离、字段级隐藏、改价退款审批 | 事业部级分权、细粒度 API 治理 |
| 20-50 家店 | 10-15 个 | 中间层分权、跨范围调拨审批、审计日志 | 多币种独立核算（如仍单主体） |
| 50 家店以上 / 多主体 | 按利润中心建 | 多主体核算、数据合规、专职权限责任人 | 无，此阶段权限需全面覆盖 |
权限管理的本质是一系列取舍。想全都要，最后往往什么都得不到。以下五个取舍点，是我在项目里跟客户争论最多的。
很多团队不愿意开二次验证，理由是"每天登录好几次，太麻烦"。我做过一个粗略的时间测算：一个人每天登录 3 次，每次多花 8 秒，一年大概多花 2.2 小时。
而账号被盗导致的数据泄露或误操作，一次损失的量级通常是小时级以上的团队工时，还不包括客户信任损失。这个取舍的答案是明确的：开二次验证。
真正需要讨论的取舍在别处，比如一个运营同时管 8 家店，你让他在系统里切换 8 次店铺，每次 15 秒，一天下来就是 20 分钟。这种效率损耗是实打实的，解决办法不是取消隔离，而是做好批量操作和视图切换体验。
权限越细，安全越高，但维护成本也越高。我在一个客户那里见过 40 多个角色，结果是没人搞得清楚哪个角色该给谁，每次新人入职都要开半小时会讨论给什么角色。
我的经验值是：角色数量控制在员工数量的 1/3 到 1/2 之间。30 个人的团队，10 到 15 个角色比较合适。低于这个数说明颗粒度不够，高于这个数说明过度设计。
前面提过，这两个诉求天然对冲。我的解法是分层：聚合层统一，明细层隔离。
具体做法是，老板看的看板只呈现汇总指标和趋势，不提供下钻到单店铺明细的入口。需要下钻时，走单独的申请流程，且操作留痕。这样既保住了"看得见全局"，又保住了"看不到不该看的细节"。
我遇到过几个规模不小的卖家公司，想自研 ERP，理由是"市面上的不满足我们的权限需求"。我的判断通常是：这句话背后 80% 的情况是需求没想清楚，而不是产品做不到。
权限体系自建的隐性成本极高，不只是开发，还包括长期的维护、人员变动后的知识断层、平台接口变更后的适配。除非你的业务模式真的有非标准的地方，否则采购成熟方案再加定制配置，性价比高得多。
这一点容易被忽略。过度收紧权限，会让有能力的运营觉得自己不被信任，这是真实的离职原因之一。
我的建议是，权限收紧必须配三样东西：
权限不是不信任的证明，而是让放权变得可能的前提。不能放权的公司，留不住想做事的人。
最后给你一套可以直接执行的清单。我把它分成"配置前"和"上线后"两段，因为这两段的重点完全不同。
这八个问题如果没有明确答案，先不要动系统。它们看起来简单，但每一个都可能暴露出组织层面的分歧。
这八个问题建议开一次跨部门会议集中回答，参与人包括老板、运营负责人、财务负责人、客服负责人。不需要一次答完，但必须有人在两周内推动出结论。
权限上线不是终点。我建议按下面的节奏做检查：
再往后，就进入季度复盘的常态节奏。把权限复盘写进季度 OKR 的公司，权限体系的生命周期会明显长于靠自觉维护的公司。
回到最初那个问题：多店经营的权限到底该怎么切？
我的答案是：不要从系统开始切，要从经营边界开始切。先把"这家店是谁的、谁对它负责、谁承担后果"这三件事说清楚，权限配置只是把答案翻译成系统语言。
工具层面，像数跨境这类面向多平台多店场景的产品，在店铺隔离、字段级可见性和审批日志上能提供基础能力，值得放进选型清单里对比。但我要提醒的是，工具能解决的问题，永远小于组织没想清楚带来的问题。
我见过太多公司买了最好的系统，配了最细的角色，但因为没有明确店铺归属和成本分摊规则，半年后还是回到 Excel 管理。也见过用着普通工具、但边界清清楚楚的小团队，20 家店管得比人家 50 家店还稳。
所以下一步你要做的事很具体：本周内找齐老板、运营负责人、财务负责人，用上面那八个问题开一次会，把答案写下来。有了这张纸，再去选工具、配角色，你会发现原本以为很复杂的权限管理，其实就是把一张组织结构图搬进系统里。
权限管理不是给员工上锁，是让你的组织有能力长得更大。这件事越早做，代价越小。
我们公司现在8个店铺、3个平台，运营、财务、客服都挤在同一个ERP账号池子里，谁都能点开别人的店铺数据，老板已经问过我好几次为什么报表对不上。我一开始以为权限就是给每个人开个账号、勾几个菜单，后来发现完全不止这么简单。到底该按什么逻辑来分层？
权限不是“开账号加勾菜单”，而是五层叠加：组织与角色、数据范围、功能与字段、审批流、审计日志。落地顺序建议先定角色，而且按职责而不是按岗位建，比如“亚马逊美国站运营”“独立站客服主管”，而不是“运营专员”这种大而全的叫法；
再给每个角色绑数据范围，维度至少要覆盖店铺、站点、主体、仓库、SKU、币种、订单状态、客户；然后才是菜单、按钮、导出、API 这一类功能权限；最后给改价、退款、采购、付款、调拨这些高风险动作挂审批，并确保有操作日志可查。
验证方法很简单：随便挑一个员工，问三个问题，他能不能看到不该看的店、能不能做不该做的动作、做完之后有没有记录。三个都能答清楚，这套权限才算真的配完，否则只是看起来配了。
我们有5个亚马逊店铺加2个独立站，运营各管一摊，但客服人手紧，经常要帮别的店处理售后。我一边担心运营互相看到对方的选品思路和销售数据会出问题，一边又怕隔离太死客服忙不过来。这条线到底该划在哪里？
按“数据可见性”和“业务必要性”两条线判断，不要一刀切。默认原则是最小权限：运营只看自己负责的店铺和站点，跨店订单、客户联系方式、成本价默认不可见；客服属于典型的例外角色，可以按工单号或订单号做临时授权，开放跨店订单查询和售后处理，但不给导出客户名单和改价权限。
实操上可以在ERP里单独建一个“跨店客服”角色，数据范围设为全店只读加本店可写，手机号、邮箱这类高敏感字段做脱敏展示。如果评估下来发现ERP只支持“全有或全无”，跨店场景完全没法拆，那说明它的数据权限颗粒度不达标，这种产品应该直接进选型淘汰名单，而不是靠管理制度硬补。
我们财务要算每个店铺的利润，必须拿到采购成本和物流费用；可运营一旦看到成本价，定价和供应商谈判就容易走偏，老板很忌讳这一点。现在只能靠Excel来回导，效率低还老出错。这种“同一条数据、不同人看到不同字段”的需求，ERP能实现吗？
关键在字段级权限和导出级权限，而不是菜单级权限，很多人栽就栽在只控了菜单。做法分三步：第一，把成本、采购价、毛利这些字段单独归到“财务可见字段”，运营角色的数据范围可以包含整个店铺，但字段权限只给售价、销量、库存；
第二，把导出权限单独授权并记录日志，因为大量数据泄露不是“看”出来的，而是“导”出来的；第三，利润报表做成结果可见、过程不可见，运营能看到自己店的毛利额和毛利率区间，看不到成本明细。
判断一个ERP能不能支撑这种玩法，直接问厂商三件事：是否支持字段级权限、是否支持导出权限与操作日志、报表能否按角色裁剪字段。这三个答不上来，多主体多店的利润核算最后基本会退回Excel。
我们准备上ERP，供应商一直催着赶紧配账号、导数据，说配完再调也不麻烦。可我担心前期没想清楚，配完再改会牵一发动全身。到底应该先做什么、后做什么，有没有比较稳的推进顺序？
先画矩阵，再配系统，顺序反了大概率返工。具体做法是拉一张表：行是组织单元，比如主体、事业部、站点、项目组；列是店铺和仓库；交叉的格子里填“谁负责、看什么、能改什么、要不要审批”，填完这张表，权限矩阵的雏形就有了。
矩阵定稿之后再映射到ERP的角色和数据范围，配置量会小很多，后面组织调整也有据可依，而不是每次改权限都靠记忆。
选型阶段建议提前问清这几项：授权店铺数怎么计算、角色数量有没有上限、数据范围能细到哪一层（店铺/站点/主体/仓库/SKU）、审批流能否自定义、日志留存多久、有没有开放API、部署方式是SaaS还是私有化、实施周期和培训怎么计价。
另外提醒一句，多店经营必须遵守平台规则，权限设计的目标是最小权限、操作留痕和账号安全，不要把“规避平台风控”当成需求写进方案；平台的多店铺政策、收款与税务处理、数据跨境合规要求都会调整，务必以平台官方最新规则和当地法规为准。
读者评论
文章把权限问题归到经营边界上很扎心。我们之前就是先配角色，结果运营互相能看到对方广告数据，后来按店铺加字段拆数据权限才好转。建议再补充审批流和ERP里的具体配置顺序。
四种组织形态分类挺实用，尤其是代运营和合伙制。实际项目里，中间层权限继承最容易配错，事业部负责人既需要汇总又不能看别的部门。案例再多点系统字段清单会更好。
成本分摊不先定，权限一开放就吵架。合伙型卖家尤其如此，利润中心、币种、共享费用规则必须先于系统配置。文章提到汇总层统一、明细层隔离，这点很关键。
只做功能权限不做数据权限这个坑太真实。我们客服账号能看到全店成本价和客户邮箱，后来出过离职带走名单的事。权限颗粒度确实决定能不能放权，不是单纯IT配置。