CRM、ERP、OMS、WMS、POS与数据权限

10.1 全渠道订单中台不是万能中台

正在绘制业务流程…

系统边界要服从事实边界。PIM管“这个商品是什么”，OMS管“这张订单下一步去哪”，WMS管“实物在哪和发生了什么作业”，ERP管“权利义务与价值如何记录”，CRM/CDP管“在合法基础上我们知道谁和可做什么触达”，BI管“如何用统一口径解释经营”。一个系统可以承载多个模块，但责任不能模糊。

10.2 主数据治理

商品编码、渠道商品ID、供应商、门店、仓库、批次、会员、活动、价格和原因码都属于主数据。新增、变更、停用必须有所有者、审批、有效期和影响评估。最危险的不是系统没有数据，而是相同名称代表不同东西：例如“退款日”在客服指申请日，在支付指到账日，在财务指冲销入账日。

10.3 最小权限与职责分离

高风险动作	申请	审批	执行/复核	必留日志
改售价/叠券	运营	经营+财务规则	系统发布/事后抽检	前后值、时点、范围
手工加减库存	仓店	仓配负责人	财务/审计复核	实盘、原因、影像
大额退款	客服	分级授权人	支付执行、财务对账	订单、证据、收款账户
合并会员身份	CRM	数据负责人	系统规则执行	依据、置信度、撤销
导出个人信息	业务申请	合规/数据授权	IT受控导出	字段、用途、接收人、删除日
修改供应商账户	采购	独立复核	财务小额验证	变更证据和回拨

10.4 数据质量五个维度

完整性看是否漏单漏事件；准确性看字段是否与实物和原始证据一致；及时性看库存和退款是否在承诺窗口更新；唯一性看同一订单/会员是否重复；一致性看各系统对同一状态是否可解释。每天优先监控会直接伤害顾客或现金的数据：负可售、无货号订单、支付成功未入OMS、已退款未冲订单、退货入仓未质检、平台结算差异和异常权限操作。

10.5 系统建设的业务蓝图

购买软件前，先画事件和责任：顾客做了什么、订单状态如何变化、谁决定下一状态、生成什么证据、失败如何回退、财务何时入账。若蓝图只写“打通会员、打通库存”，实施方无法知道同一手机号是否可直接合并、退货待检是否可售、门店自提何时确认交付。

蓝图按优先级分层。第一层是交易和钱货安全：支付不丢单、不超卖、不错发、退款可追；第二层是效率：自动路由、波次、调拨和对账；第三层是体验：跨渠道权益、自提和售后；第四层是优化：预测、推荐和自动化运营。先稳定事实再做智能，否则算法只会快速放大脏数据。

10.6 接口事件与幂等

渠道、OMS、WMS、支付和ERP之间的接口会重试、延迟、乱序或重复。业务方不必编程，但要定义每个事件的唯一键、发生时间、接收时间、版本和重复处理规则。例如支付成功通知重复到达，OMS不能重复创建订单；退款先于订单更新到达，要进入受控补偿队列而不是丢弃；发货撤销后新运单要保留完整关系和审计轨迹。

接口监控不仅看“服务在线”，还看业务队列：支付成功未成单、锁库超时、已拣货未出库、运单无轨迹、退款批准未到账、结算行未匹配。每类异常有自动重试次数、人工队列、负责人和最大处理时限。手工补单要标记来源并防止系统恢复后再重复。

10.7 库存承诺算法的业务参数

可售库存常见计算是：现有合格库存−订单预占−安全库存−门店保留−其他冻结+可承诺在途。每一项都有适用范围和时效。新品、活动和高退货品可能采用不同安全量；在途只有供应稳定、预计到货可用且承诺允许时才能计入。门店展示样、质检待定和退货未检不能被算法乐观纳入。

多渠道争抢库存时，可以按渠道优先级、承诺时效、区域、订单时间或贡献分配，但规则需在活动前批准。不能临时让高销售目标渠道抢走已向其他顾客承诺的货。发生系统降级时，设置保守可售、暂停部分渠道或改预售，恢复后重新对账全部预占。

10.8 会员身份解析

同一自然人可能有多个平台脱敏账号、手机号变更、家庭共享和线下记录。身份解析可用明确登录、顾客主动绑定和受控匹配，但要区分确定关系与概率推断。营销和权益决策应使用足够可靠的身份；敏感或高影响决策不能仅靠模糊设备匹配。

错误合并会把一人的订单、偏好或售后暴露给另一人，错误拆分则重复触达和虚增新客。系统需要合并依据、置信度、人工纠错、撤销和审计。顾客行使查阅、更正、删除等权利时，要能定位相关系统和第三方，而不是只删CRM前台一行。

10.9 同意与偏好中心

偏好中心让顾客看到可接收的渠道、内容类型、频率和退出。交易通知、售后服务和营销触达目的不同，不能因顾客需要接收物流就强制接受促销。一次同意记录要包括界面版本、目的、字段、时点和撤回方式；后续扩展用途需重新评估。

系统将退订传播到短信、邮件、企业微信、广告人群和外包服务商，并保留必要抑制信息防止再次导入。删除与保留冲突时，按法律义务、争议和最小化原则形成处理规则；业务人员不自行决定永久保留“以后可能有用”的数据。

10.10 指标语义层

BI上同名指标若各算各的，图表越多争议越大。建立语义层，把有效订单、有效新客、净收入、退货、贡献、库存和渠道定义封装；每个看板引用同一版本。指标变化经过提案、影响评估、双跑、批准和生效，历史是否重算需说明。

指标下钻路径从总量到渠道、店铺、门店、商品、批次、活动和订单，但个人层访问受权限和目的限制。经营会议使用聚合数据，只有解决具体售后、欺诈或权利请求时才查看必要明细。导出表带水印、有效期或受控存储，防止形成影子客户库。

10.11 实验平台与因果意识

A/B实验先写假设、主要指标、护栏指标、样本单位、周期和停止规则。主图改版的主要指标可能是有效转化，护栏包括退货、投诉和贡献；不能实验中途看到点击高就提前宣布成功。多个渠道同时大促会污染结果，应记录外部事件。

不是所有场景都能随机实验，可用地区、门店或时间对照，但需说明可比性与局限。推荐算法提高短期客单却降低选择多样性或复购，需要长期护栏。数据团队提供方法，业务负责人对是否放大负责，合规负责人判断实验处理个人信息和差异化呈现的边界。

10.12 数据事件响应

发现异常导出、错误收件人、第三方泄露、越权访问或数据污染时，先阻断继续扩散并保存证据。事件负责人确认涉及系统、字段、人数、敏感程度、地区、第三方和时间；法务合规基于适用规则判断通知、报告和补救；业务保证顾客服务不中断；IT修复权限和漏洞。

事件复盘不止写“员工误操作”。要问为何权限允许、为何无二次确认、为何敏感字段明文、为何导出长期有效、为何监控未发现。改进可以是最小字段、脱敏、审批、异常行为检测、自动到期、供应商控制和培训。以追责个人替代系统修复，会重复发生。

10.13 第三方与SaaS供应商治理

品牌常把商城、客服、CRM、短信、物流、直播和分析交给第三方。准入时明确数据角色、字段、目的、存储地点、分包、访问、保留、删除、事件通知、审计和退出。合同写了“乙方保证安全”不代表完成治理；要验证配置和实际数据流。

每年至少复核高风险供应商，业务变化时即时复核。停止合作要撤销账号和密钥、导出必要数据、验证删除、处理存量订单和顾客请求。供应商锁定风险也要计划：接口文档、数据可携、关键流程降级和替代方案，避免系统停摆时无法履约。

10.14 权限生命周期

入职按岗位模板授予最小权限；调岗及时调整而不是叠加；离职在最后工作时点撤销；临时活动权限自动到期；服务账号有负责人、用途和密钥轮换。季度由业务所有者复核“谁还需要什么”，IT不能替业务判断合理性。

高风险权限组合要检测，例如同一人既能改供应商账户又能付款，既能改库存又能批准差异，既能创建券又能核销，既能批退款又能改收款账户。小团队无法完全分人时，使用金额限制、事前批准、操作告警和事后独立复核补偿。

10.15 门店离线和灾备

网络或POS故障时，门店是否继续销售取决于商品、支付、库存和风险。离线方案应限制金额、SKU和库存，明确价格来源、支付凭证、顾客告知和恢复补录。不能用个人收款码绕过公司交易链，也不能为了不丢销售无限接受无法核验的订单。

恢复后按临时交易号逐笔补录，核对支付、库存、发票与会员权益，避免重复扣款和重复积分。中央系统故障则按渠道降级：暂停跨仓、减少可售、关闭复杂券或临时只支持门店现货。每半年演练一次，记录实际恢复时间和数据缺口。

10.16 AI在品牌零售中的使用边界

AI可辅助生成内容草案、客服建议、需求聚类、预测和异常检测，但输出必须回到责任岗位。商品事实、功效、价格、法规和对顾客的重大承诺不能因“模型生成”免审；客服机器人识别到质量安全、伤害、隐私或高额争议要转人工；预测模型不能绕过采购现金门禁。

使用外部模型前核对输入是否含个人信息、商业秘密、未发布设计或供应商资料，确认合同和数据路径。保留提示、版本、人工批准和上线范围，以便错误时定位。评估不只看准确率，还看不同人群误差、幻觉、可解释性、失败降级和内容权利。

10.17 系统切换与数据迁移

迁移前清理商品编码、会员重复、未完订单、余额、积分、库存、售后和财务开放项。迁移不是把旧库全部复制，而是定义哪些数据必须带历史、哪些只归档、哪些应依法删除。每个对象设数量和金额控制总数，并抽样到原始证据。

切换采用演练、冻结窗口、增量同步、回退方案和业务签字。最危险的是销售前台已切新系统，退款和财务仍查旧系统，导致顾客权益断裂。上线后设置强化支持期，按支付、库存、履约、退款、会员和总账逐日勾稽，直到异常率稳定。