LONG TAO

屈臣氏SNC供应商协同平台

覆盖8大模块的全链路供应商协同平台,协同效率提升45%,月均结算单据从8000提升至12000单

↑45%协同效率
8000→1.2万月均结算单
↓35%票据错误率
1000+核心供应商
Role 交互设计师 调研到落地走查
Timeline 2023.02 - 2023.08 约 7 个月
Team 8-15 人团队 PMO / 产品 / 设计 / 开发
Market 零售 / 供应链 客户定制 · B端Web

我的角色

项目名称屈臣氏SNC供应商协同平台
项目类型客户定制化B端Web产品
客户类型大型零售企业(屈臣氏)
行业零售/供应链
平台Web端
项目时间2023.02 – 2023.08(7个月)
我的角色交互设计师,负责用户调研、交互设计、原型输出与落地走查
参与深度全流程参与(现场调研→需求分析→交互设计→原型输出→落地走查)
团队规模8-15人(项目经理+PMO+产品经理×2+开发×4+交互设计师即本人)
项目状态已交付

具体任务清单

  1. 2次前往屈臣氏现场实地调研,了解现有业务流程与核心痛点
  2. 2周会议访谈,按功能模块逐一访谈财务、采购、IT、招商等不同角色人员
  3. 基于调研结论进行需求分析与功能梳理
  4. 完成全平台交互原型设计(上百页),覆盖供应商协同全链路
  5. 撰写交互说明文档
  6. 对接开发团队,跟进设计走查与还原度验证

我直接产出的交付物

  1. 需求分析文档
  2. 全平台交互原型(上百页)
  3. 交互说明文档

协作对象

项目经理 / PMO项目整体进度管理,协调 2 次现场调研和 2 周模块化访谈的客户侧排期
产品经理 ×2需求梳理与功能规格定义,协同完成 8 大模块的方案评审
开发工程师 ×4技术实现与设计还原,上百页原型的联调走查和还原度验证
客户方(屈臣氏)业务需求提供与现场调研配合——覆盖财务、采购、IT、招商等多角色,参与方案确认

项目挑战

项目背景与目标

屈臣氏原有供应商管理系统分散、各模块独立运作,单据处理依赖手工操作,效率低下。月均超 1 万结算单据与 7 千票据的处理量级,使得操作效率成为核心瓶颈。客户提出全链路平台升级需求,旨在打造集成、高效、透明、智能的供应商协同平台。

业务目标:实现供应商归一管理,覆盖业务协同、对账结算、电签、证照管理、供应商生命周期、门户管理等全链路线上自动化处理。

用户痛点

零售商侧(财务/采购/IT/招商人员):多系统切换操作,供应商信息分散难以统一管控,手工对账易出错、周期长。

供应商侧:单据提交入口分散、流程不透明、沟通效率低。

核心挑战

挑战1:业务模块多、流程耦合度高

系统覆盖业务协同、对账结算协同、场景化电签、证照管理、供应商生命周期、游客管理、供应商门户管理、公告消息及报表等8大模块,各模块之间存在复杂的业务依赖和数据流转关系。如何在统一平台内保证模块间的信息一致性和操作连贯性,是信息架构层面的核心挑战。

💡 为什么难:每个模块独立看都不算复杂,但模块之间的耦合关系(如电签依赖对账结算完成、证照过期影响供应商状态)使得任何一个模块的设计变更都可能影响其他模块。需要从全局视角梳理信息流和状态迁移,而非逐模块设计。

挑战2:双端角色需求差异大

零售商侧用户(屈臣氏财务/采购/IT/招商)关注管控效率和数据透明度,供应商侧用户关注操作便捷性和流程清晰度。两端需求在权限、信息可见性、操作路径上存在明显差异,但必须在同一平台内完成协同。

💡 为什么难:两端的操作场景和使用频率完全不同——零售商侧是日常高频操作,供应商侧是阶段性操作(如月结对账)。需要在权限体系、信息呈现、流程引导上做差异化设计,同时保证数据一致性。

挑战3:客户定制需求与平台通用性的平衡

作为客户定制项目,屈臣氏有其特有的业务流程和管理模式。但部分功能模块(如供应商生命周期、电签流程)具有行业通用性,直接硬编码定制逻辑会影响未来产品的可扩展性。

💡 为什么难:客户要的是「完全贴合我的业务」,但完全定制化意味着后续每个新客户都要重新开发。需要在满足屈臣氏当前需求的前提下,为通用化留出架构空间——这要求设计时既要深入理解客户业务,又要有平台化思维。

设计过程

研究方法

  • 现场实地调研(2次):前往屈臣氏现场,实地观察现有系统的使用场景,了解财务、采购等角色的日常工作流程和操作习惯
  • 多角色深度访谈(2周):按功能模块(业务协同/对账结算/电签/证照管理/供应商生命周期/门户管理等)逐一安排访谈,覆盖财务、采购、IT、招商等零售侧角色以及供应商侧用户
  • 现有系统走查:对屈臣氏原有供应商管理系统进行全流程体验走查,梳理功能断点和操作效率问题

关键洞察

  1. 多系统割裂是效率最大杀手:财务需要在3-4个系统间切换完成一次完整的对账结算流程,数据手工搬运易出错且不可追溯
  2. 供应商侧操作门槛远高于预期:1000+供应商的数字化水平参差不齐,部分小型供应商甚至不熟悉基本的企业管理软件操作
  3. 证照管理是隐藏的高频痛点:供应商各类证照(营业执照/税务登记/行业资质)的到期提醒和更新管理缺乏系统化支撑,过期证照导致结算中断的情况频发

用户分层

零售商侧屈臣氏内部员工——财务(对账结算核心用户)、采购(供应商管理核心用户)、IT(系统管理)、招商人员(供应商引入)。核心诉求:信息统一管控、操作高效、数据可追溯。
供应商侧屈臣氏供应商企业员工——覆盖1000+核心供应商。数字化水平参差不齐,核心诉求:操作简单、流程清晰、信息透明。

设计策略

  1. 统一入口、模块化架构:将所有供应商协同功能收敛至统一平台,按业务模块组织信息架构,降低系统切换成本
  2. 双端差异化设计:零售商侧强调信息密度和批量操作效率,供应商侧强调操作引导和流程清晰度
  3. 状态驱动的流程设计:以供应商生命周期和单据流转状态为核心驱动,确保各模块间的信息一致性

设计过程叙述

阶段一:调研与需求分析(前2个月)

深入现场,逐模块摸清业务全貌

  • 2次现场调研:前往屈臣氏总部,实地观察财务、采购等角色的日常操作流程和现有系统使用情况
  • 2周模块化访谈:按业务协同、对账结算、电签、证照管理、供应商生命周期、门户管理等模块逐一安排,覆盖财务、采购、IT、招商及供应商侧用户
  • 现有系统走查:对原有分散的供应商管理系统进行全流程体验走查,梳理功能断点和数据流转瓶颈
  • 需求分析输出:基于调研结论完成需求分析文档,明确 8 大模块的功能边界和模块间数据依赖关系

阶段二:设计与交付(后5个月)

从信息架构到上百页原型,全链路设计落地

  • 全局信息架构:梳理 8 大模块间的数据流转和状态迁移,确定统一入口 + 模块化架构
  • 双端差异化设计:零售商侧强调信息密度和批量操作;供应商侧强调操作引导和流程清晰度
  • 全平台交互原型:输出上百页交互原型,覆盖供应商从入驻到续约全生命周期
  • 交互说明文档:编写详细交互说明,对接开发团队完成设计走查和还原度验证

关键设计决策

每个决策都包含了「选择了什么」、「为什么这样选择」、以及「放弃了什么替代方案」。

决策1:8大模块统一平台架构 vs 模块化子系统

为什么:原有系统各模块独立部署——商品协同、采购、签约、结算等业务分散在不同系统中,用户需多系统切换才能完成一个完整的供应商协同流程。统一平台方案将所有功能收敛至单一入口,覆盖商品协同、智能采购、在线签约等8大模块,实现供应商从入驻、合作到续约的全生命周期管理。

✅ 选择的方案❌ 放弃的方案
8大模块统一平台:单一入口+模块化信息架构,共享供应商主数据和权限体系,覆盖入驻→合作→续约全生命周期保留模块化子系统,仅优化单模块体验
放弃原因:无法解决多系统切换和数据割裂的根本问题,协同效率提升有限

决策2:供应商单据提交流程整合与界面重构

为什么:原有单据提交、审核、结算等环节分散在多个页面和系统中,供应商完成一次完整的结算流程需要反复跳转。通过流程优化与界面整合,将核心操作串联为连贯的任务流,减少页面跳转和重复填写。协同效率提升45%,月均结算单据处理能力从8000单提升至12000单。

✅ 选择的方案❌ 放弃的方案
流程整合+界面重构:单据提交→审核→结算串联为连贯任务流,关键信息自动带出、减少重复录入保留分步独立操作,仅优化单页面布局
放弃原因:单页面优化无法解决跨环节的信息断点和重复操作问题

决策3:票据电子化归档+智能校验

为什么:月均7000+票据的处理量级下,人工核对发票信息(金额、税号、开票日期等)耗时且易出错。设计电子化归档流程,将票据信息结构化存储;配合智能校验规则,自动匹配票据与结算单据、标记异常项。票据处理错误率降低35%,财务与供应商协作效率得到提升。

✅ 选择的方案❌ 放弃的方案
电子化归档+智能校验:票据结构化存储→自动匹配结算单→异常标记→人工复核,错误率降低35%仅做票据扫描件上传归档
放弃原因:仅解决存储问题,无法解决核对效率低和人工错误问题

设计结果

🟢 项目资料口径(统计周期未公开)

设计方案

平台架构与核心设计产出

  • 8大模块系统架构:覆盖商品协同、智能采购、在线签约、对账结算、票据管理、证照管理、供应商生命周期、供应商门户,实现供应商从入驻→合作→续约全生命周期管理
  • 流程优化与界面整合:将单据提交、审核、结算等核心操作串联为连贯任务流,减少页面跳转和重复录入
  • 票据电子化归档+智能校验:结构化存储+自动匹配结算单据+异常标记,替代人工逐项核对
  • 全平台交互原型:上百页原型+交互说明文档,支持开发团队落地实现

业务成果

  • 供应商协同效率提升 45%
  • 月均结算单据处理能力从 8000 单提升至 12000 单(↑50%)
  • 票据处理错误率降低 35%

体验成果

  • 财务侧系统切换次数减少,统计口径未公开
  • 供应商侧单据提交操作步骤减少,统计口径未公开
  • 新供应商上手时间缩短,统计口径未公开

团队成果

  • 交付上百页全平台交互原型 + 完整交互说明文档
  • 沉淀供应商协同平台设计方法论,覆盖 8 大模块的信息架构和状态流转模型

数据来源明细

指标数据来源统计方式
协同效率 ↑45%项目资料口径上线前后协同效率对比
月均结算单 8000→12000项目资料口径月均单据处理量对比
票据错误率 ↓35%项目资料口径上线前后票据错误率对比

客户反馈

  • 屈臣氏财务部门:「对账结算从原来跨 3-4 个系统到现在一个平台走完,月结对账周期缩短,数据出错的情况减少。」
  • 供应商侧用户:「以前单据提交入口分散、流程不透明,现在在一个平台就能看到所有待办和进度,操作门槛低了很多。」
  • 客户方项目负责人:「8 大模块全部在一个平台落地,供应商从入驻到续约全生命周期可视化管理——这是最初立项时就想达到的效果。」

反思与成长

经验教训

  1. 客户现场调研不可替代:2次现场调研+2周面对面访谈,获取了大量远程沟通无法得到的真实业务流程细节。尤其是多角色在同一空间内协作时的信息流转方式,只有实地观察才能真正理解。
  2. 大型B端项目需要全局信息架构思维:8个模块之间复杂的耦合关系意味着任何一个模块的设计都必须放在全局视角下考量。先梳理信息流和状态迁移,再做单模块设计,避免了后期大量返工。
  3. 供应商数字化水平是设计的重要约束:1000+供应商的IT能力参差不齐,部分小型供应商甚至不熟悉基本的企业管理软件。在供应商侧的设计中必须假设最低的操作能力基线,做更多的引导和容错设计。

后续优化方向

  1. 前期建立设计度量基线:在调研阶段同步收集原有系统的效率数据(单据处理耗时、错误率等),为设计方案提供量化对比依据
  2. 引入供应商侧可用性测试:在方案阶段邀请不同类型的供应商(大型/中小型)参与原型测试,提前验证操作引导和容错设计对不同数字化水平用户的适配性

方法沉淀

  1. 大规模B端平台的全链路设计能力:从信息架构到上百页交互原型,锻炼了复杂B端业务流程的梳理和设计能力
  2. 客户定制项目的需求管理经验:学会了在客户定制需求和平台通用性之间寻找平衡点
  3. 大型团队协作经验:8-15人团队中与项目经理、PMO、产品、开发的多角色紧密协作

能力映射

  • 复杂B端业务流程设计
  • 现场用户调研
  • 多角色需求分析
  • 大规模交互原型交付
  • 客户定制项目管理
  • 供应链行业理解
  • 全链路信息架构
  • 跨团队协作推动