系统、数据与权限

10.1 系统架构

正在绘制业务流程…

10.2 主数据

项目、门店、工位、人员、技能、客户、商品、供应商、批次、价格、套餐、优惠、支付渠道、发票类目、异常类型和地区规则都要有稳定ID和生效日期。不能用自由文本“护理A”“老师价”“老客套餐”支撑核算；名称相同而版本、材料或时长不同的项目要分开管理，停用项目不可删除历史。

10.3 权限矩阵

数据/动作	前台	技师	店长	财务	质量法务	IT
查看预约必要信息	是	本人订单最小字段	本店	否	事件需要	运维受控
查看健康/过敏信息	必要字段	本人服务必要字段	仅升级	否	调查授权	不看内容
修改价格	否	否	限额审批	复核	审查规则	配置不审批
发起退款	申请	否	限额	执行/复核	争议会签	否
导出客户照片	否	否	否	否	个案批准	双人操作
调整预付余额	否	否	申请	双人审批	审计	技术执行不审批
删除账号	否	否	申请	否	保留判断	执行并留日志

10.4 数据最小化

咨询只收服务必要信息；照片、面部特征、健康和过敏信息应分别说明目的、范围、保存期和访问者。营销前后对比照片不能因客户接受服务而默认授权；员工私人手机不得成为唯一证据库。跨境总部、云服务和境外顾问访问数据时进入R10评估，不能把“集团内部共享”当作合法基础。

10.5 字段级数据治理

客户主档将身份联系方式、营销偏好、服务必要信息、交易、预付、照片和客诉分域。前台可看预约所需联系方式，一线在服务窗口内查看本单必要禁忌，财务只看交易和余额，市场只使用已授权标签，质量在事件授权下查看证据。字段级权限比“某角色可进CRM”更可靠，因为同一系统同时含普通和敏感信息。

每个关键字段定义来源、格式、必填条件、修改人、审核人、生效时间、下游和保留期。例如产品批次来自扫码或受控选择，不允许任意文本；项目版本在预约时冻结，之后变更需生成新记录；预付余额只能由核销、退款、调整三种凭证改变；员工技能状态由考核和有效期驱动，排班系统不能手工绕过。

数据质量用完整、唯一、及时、一致、有效和可追溯六维管理。客户手机号重复不一定是错误，可能是家庭共享；同一订单两个项目版本一定需要解释。系统每日检查负库存、负预付余额、无订单领料、支付无订单、订单无支付、退款超收款、已离职账号登录、无授权照片导出和事件无批次。

10.6 接口与对账

平台订单进入门店OMS/POS时保留平台订单号、门店订单号、商品/服务映射、优惠承担方、佣金、预计结算和退款规则。不得把平台显示的消费者支付额直接当门店收入，也不得把净结算额直接当交易总额。日对账分订单、支付、平台结算、银行入账、退款、发票、库存和预付八条线，差异有责任人和账龄。

预约、排班和技能矩阵接口失败时，系统不能因为“有空位”自动确认；库存接口失败时，关键产品应保守冻结而非允许负数；预付接口失败时，余额读取与扣减要避免重复；财务接口失败时，业务订单可以进入待传状态但不得静默丢弃。接口重试使用幂等键，同一业务事件只产生一次财务和库存影响。

10.7 系统选型与实施

小店不必一次购买所有系统，但最小能力必须覆盖项目价格、预约、订单支付、预付、库存批次、人员、退款和导出审计。选择系统时用真实场景演示：套餐跨店核销、部分退款、项目加项、人员替换、批次召回、离职撤权、平台对账、断网补单。只看销售演示界面会忽略异常流程。

实施顺序先统一主数据和流程，再迁移客户与余额，随后并行试跑和对账。预付余额迁移必须让客户可查询，旧新系统总额、客户数和异常逐项平衡。上线日冻结高风险配置，保留回滚方案；门店培训以角色任务而非软件菜单为中心。系统上线后仍需抽样核验真实服务，不能把“有记录”当作“记录真实”。

10.8 权限生命周期

入职按岗位模板授权，调店或晋升只增加必要权限并设置到期，临时支援在订单或班次结束后自动回收，离职在最后工作时点撤销。共享账号、前台通用密码和供应商永久远程访问都不可接受。管理员、退款、价格、余额调整、批量导出和日志操作建立更严格的双人审批与告警。

每季度复核“谁仍需要什么”，重点看休假、停职、离职、外包、实习、供应商和长期不登录账号。日志记录查看、修改、导出和失败尝试，保存期与风险相匹配。发现越权先限制访问和保全日志，再评估客户影响、通知和整改，不要为了快速恢复营业覆盖证据。