大家好
2025 年 SERVEONE MRO 流程课程
负责讲授本次商品注册与管理课程的 办公部件团队吴在彦
本课程将按商品注册，商品管理的顺序进行
商品注册与管理 与采购信息管理一道
可以说是采购负责人最重要的工作之一
在正式开始之前，先做个简短自我介绍
我于 2018 年 8 月加入办公电子团队
至今一直在同一团队工作
在团队内历经多类品类 目前负责印刷类与部件类
自 24 年 4 月起兼任员工代表
也一直努力为公司尽一份力
我常写下一句话就是 结果不由我，但努力由我
无论做什么，只有真正用心投入 才能得到那些只属于努力者的收获
结果未必可控
但我始终相信，过程中的全力以赴 永远掌握在自己手里
好，下面进入正课
首先，我想再带大家 过一遍 MRO 流程的整体脉络
这里是 MRO 流程的整体流程图
MRO 流程依次包括商品注册、下单，
发单、配送与结算
当客户提出注册请求时
将经由各采购负责人、销售负责人、 商品信息负责人等
完成商品注册
客户随后会对已注册商品下单
我们据此向合作伙伴发出采购订单
之后完成配送 并进入结算，流程至此闭环
在生成与管理商品信息的过程中
各位采购负责人将面临大量决策
本次课程中
我将聚焦商品注册与管理 两部分展开说明
先来看商品注册
商品注册的总体流程 如画面所示依次推进
提交商品注册的主体
可以是客户、销售负责人、运营负责人，
采购负责人，亦或合作伙伴
我们以最常见的客户 提出注册这一情形为例
来梳理具体流程
首先，客户发起商品注册请求后
请求进入 SERVEONE 系统 抵达 DB 校验环节
由 DB 管理主体进行已注册检索与校验
并完成品类归类工作
此处的 DB 管理主体，可能是商品信息团队
也可能是采购负责人
完成以上工作后 进入采购信息登记阶段
在该阶段 采购负责人开展招投标与询报价
中标确定后，登记进货价
待进货价登记完成 即转入商品登记阶段
需要注意，标准品与非标准品的处理方式不同
对于标准品，由商品信息团队执行质量检查
如发现不足 可回退请采购负责人重新处理
而非标准品 则不经过商品信息团队的商品登记环节
如果在商品注册过程中存在不完善之处
DB 负责人和销售负责人 均可驳回注册
当商品注册部分完成后
将流转至销售负责人 开展销售信息登记流程
销售负责人 会进行售价登记与商品陈列
上述流程完成后 本段商品注册流程即告闭环
接下来，我将说明各环节的详细内容
在商品注册请求阶段
客户、合作伙伴、采购负责人、销售负责人 都可以发起商品注册请求
不同发起主体的方法与事由各不相同
第一种是客户直接 在客户前台发起请求
第二种是合作伙伴可在合作伙伴前台发起请求
通常是各自企业主推的先行提案品目
或为合作伙伴与客户 共同认可的先入库处理品目
第三种是销售负责人可通过 S-MRO 直接发起请求
多见于代客户办理注册的情形
也适用于客户指定合作伙伴 紧急商品等案例
最后一种是由采购负责人发起
采购负责人同样可通过 S-MRO 提交请求
在前置 DB、全新采购来源或替代商品的场景下 直接推进注册
在 DB 校验阶段，由 DB 负责人进行品类归类 并校验既有 DB
如校验内容不完备 可退回至发起人重新提交
若商品注册请求的发起主体为采购负责人
则其亦需自行处理校验环节
关于 DB 校验 依据运营单元不同，负责校验的组织也不同
这一点稍后我会再做说明
在采购信息登记阶段，采购负责人原则上通过招投标来处理
以完成采购信息登记，这是基本要求
之所以以招投标为原则
是为确保公平性并优化进货价
但在存在无法通过 招投标处理的特定事由时
可按招投标例外情形 改以询报价方式处理
当招投标，询报价环节结束后
采购负责人需核验是否存在高于进货价等问题
并完成采购信息登记处理
若新商品属于采购负责人 设定的招标池
则可移交至 各组织的商品信息团队处理
在商品登记阶段，将进行商品信息质量检查
无异常则执行商品登记
若存在不足 则退回请采购负责人补充
商品登记完成后，将生成新的商品 ID
正如前述，非标准品会跳过此环节
在采购信息登记之后 即直接生成商品 ID
完成上述步骤后，在销售信息登记阶段
由销售负责人登记销售价格 并在对应运营单元完成上架陈列
那么，DB 校验的负责人是如何确定的呢？
下面是 DB 校验阶段的负责人判定逻辑
当收到商品注册请求时 首先依据是否存在运营单元来细分
若不存在运营单元
通常对应采购负责人发起或合作伙伴先行提案
若由采购负责人发起
若最初发起请求的采购负责人属于合作伙伴先行提案的情况
则由系统指定的合作伙伴负责人处理
反之，若存在指定运营单元
当运营单元为 LG 本部或营业本部时，由商品信息团队承担校验
当为 SSP、BPO 时 则由代表商品 MD 团队执行校验
也就是说，运营单元为LG 与营业本部，商品信息团队负责
为 SSP、BPO，代表商品 MD 团队负责
而在没有运营单元的情况下 则由采购负责人来处理
接下来是采购负责人决策逻辑
虽然算法比较复杂
但从大框架来看，凡是销售与采购角色合并 能产生协同效应的运营单元
归类为事业团队，由其承担 MD 职能
而其余按管理细分分类处理
对于能够整合采购量并统一合作伙伴的情形
由中央采购团队推进
这一部分我想抓三点说明后再往下讲
第一，管理分类 也就是需要采购负责人处理的事项
关于投标报价，若已建立投标池
则由商品信息团队处理直至完成采购信息登记
但仅对确需替代提案的品目作为例外
由采购团队进行登记，这一点请了解
第二，若为 BPO 运营单元，仅“促销”中分类由 BPO 的 MD 处理
其余分类则由采购团队继续负责登记 请按此理解即可
第三，我已展示了细分负责人决策逻辑
由于运营单元与细分分类不同，归属的采购组织会变化
如需应用，可先暂停画面对照使用
接下来说明在商品登记过程中由采购负责人执行的
投标，报价处理部分
当天上午24点至下午14点之前创建的招标单
将于当日下午15点截止
其余在此时间段之外创建的，将在当天零点前持续进行投标
无人应标时会自动延长
且仅对勾选了“自动延长”的标案生效
被自动延长的招标 负责人可据判断直接判定中标或结束
报价则不设固定截止时间 合作伙伴一旦应价即可即时结束
关于投标，报价处理的执行主体 如前述流程
根据是否已建池，商品信息团队可以开展招标，报价处理
若已有既存登记商品 也可以通过重复处理来完成
不通过招标处理的询价类型如画面所示
如您所见，共有 16 种类型
采购负责人在实际业务中主要会用到的询价类型
包括先行开发提案品、先入库、AS售后商品 以及捆绑商品等
所谓先行开发提案品，是指以辅材开发品为主的制作品、加工询价
以及与促销物料类似的、事前已完成询价的品目
此类需要提供报价单或客户界面截图等作为佐证
先入库顾名思义，是按先入库流程提出请求的品目
需要附上先入库请求书、邮件等证据资料
AS 商品 仅限一次性商品情形下使用
捆绑商品则是指经销售团队事前呈报批准后 以捆绑形式处理的情形
其余项目请大家暂停 画面后阅读，会更有帮助
仅对画面所列 16 类品目 执行询价处理
除此之外的情形，原则上均应通过招标进行 请予以留意
以上属于理论部分
接下来我们通过系统截图 从商品登记请求到采购信息登记为止
一起在系统画面中实际查看一遍
根据请求发起方不同 您能看到的界面可能会略有差异
这里以采购负责人主要使用的 S-MRO
新商品登记请求页签为基准进行讲解
首先进入新商品登记请求菜单
会看到与商品信息及属性值相关的填写项
填写完这些信息后 向下滚动输入商品的基础信息
先录入商品名称 然后通过“分类推荐”获取建议分类
填入分类后 根据该细分分类设置必填的属性名
随后查询并选择订购单位 原产地与生产厂家
并依照细分分类 为各必填属性名填写属性值
这里的属性值基本就代表商品规格
在招标，询价时起着关键作用
接着填写商品区分信息
区分是一般商品还是一次性商品
并注明是标准品还是非标准商品
在是否可由 HUB 处理一项中选择可、不可
若选择不可，需根据实际原因勾选相应选项
当标注为不可由 HUB 处理时
请注意配送类型必须按直送处理
常见不可原因包括重货、超出托盘尺寸的商品、需安装，检验的商品
虚拟捆绑商品、危险品、 易破损商品、冷冻，冷藏品、有害化学品
以及禁止快递运输的物品等
当上述属性值全部填写完成后
点击页面上方的登记请求
即可提交最终的登记请求
在点击登记请求后弹出的窗口中 输入请求类型与理由
即可获取商品请求编号
请求提交完成后，流程会进入 DB 验证阶段
在 S-MRO 的DB 验证页签中 按请求编号检索该请求记录
点击请求编号进入详情
首先点击接收，受理 随后查看处理信息以确认是否存在问题
如发现异常，则编写“规格确认请求
若无异常 点击下方“完成”按钮，结束验证
验证完成后 由采购负责人执行采购信息登记
在采购信息登记处理页签中 用分配到的请求编号进行检索
将该案件设为接收，受理，以便进行后续修改
受理后，如负责人分配不当 可发起变更负责人申请
如存在重复商品，则执行重复商品处理
若因信息不全需要确认 点击“请求销售负责人确认
若无异常，则点击生成招标，询价 进入下一阶段
首先以招标创建为基准给大家讲解一下
先输入招标名称，然后在下方的招标协力社栏位中
点击Add按钮，添加协力社
选择好协力社后，点击底部的生成招标按钮 即可创建此招标
如果事先维护好了招标池
系统会自动指定池内协力社 可直接向其发出招标请求
至于创建询价 点选对应请求编号下的询价即可开始
在排除招标情形的弹窗中 选择相应原因后继续
在询价请求弹窗里 填写询价名称并选择协力社后发出请求
系统就会把询价发送给指定的协力社
接下来看看协力社参与投标的流程
入围的协力社会在协力社前端页面
进入商品应标，询价界面 点击招标编号进行应标
如要拒绝，也可填写拒绝原因后予以拒绝
在应标登记中，如需认证，填写认证编号
并录入价格信息，应标价、市场价与有效期
随后填写AT、MOQ、倍数订购数量等配送与发注信息
最后点击登记就好
之后就会针对该品目 推进并签订招标单价协议合同
通过数字证书完成认证后 即视为应标完成
应标完成后，采购负责人可在招标，询价处理界面
查看状态值以掌握协力社的提交情况
并点击商品详情 可以进入下一步
确认询价价目无误后执行批准，通过，
转至采购信息登记变更
最终完成采购信息的登记
到这里，我们把商品登记流程 和系统操作过了一遍
接下来对于已登记的商品 各角色需要掌握哪些信息
以及需要管理的重点是什么
在商品管理部分继续为大家说明
首先，先介绍商品信息
所谓商品信息，就是指商品本身的各项信息
简单来说，就是商品所具备的特性
比如说到手机，大家立刻会想到一串规格参数
商品信息 基本就可以理解为这些内容
商品信息的主要项目包括
在基本信息里
有商品名、分类代码、代表规格、订购单位、生产厂家等
在评估记录里，有商品等级、属性评分、图片等
在区分信息里，有是否一次性、是否标准品、是否化学物质等
此外还有图片信息、基准价、MSDS等 其他多项信息
举个例子说明
以 Gram 笔记本为例，制造商为 LG，商品名为笔记本
尺寸，英寸、颜色等 都归入基本信息
各位负责人需要确认这些商品信息是否无误
一旦发现误登，还要及时进行修改与补正
接下来是分类体系
分类体系是 SERVEONE 为了对商品进行分组而制定的体系
整体分为大、中、小、详细 四个层级
大分类是出于分析目的而汇总的中分类的集合
中分类通常是彼此相关的小分类组合
小分类则是具有相同用途与功能的详细分类集合
而详细分类是最底层的区分项 具有共同的功能与目标任务
或由相似工艺制成的商品群
指可以形成唯一名称的分类
以当前标准，体系包含 15 个大分类
126 个中分类、305 个小分类，以及 1240 个详细分类
由于这是基于业务划分的分类体系，可能会随着时间节点发生变更
通常每年会有一次集中梳理与维护期
可以理解为大、中、小分类以用途为中心，详细分类以特性为中心
通过这套分类体系 我们可以直观地识别上下级的层级结构
商品之间的关系也通过类别实现关联
从而更容易把握其特性
这也为同性质商品之间的检索，提供了更简单、更快速的基础
为了便于从上到下快速查看目标品目的各层级统计范围
我们特地这样实现了这一功能
最终，是用于品目的注册、变更、删除 以及维护管理
大家可以历届这都是基本结构就好
接下来讲标准品与非标准品的区分
所谓标准品，就是按标准化规格量产
并在市面上流通的通用商品
通俗地说，就是像手机、笔记本电脑这类，一听到品名
脑海里就能浮现出清晰形象的商品
这类品目可通过型号、制造商、标准规格来加以确认
由于不局限于某个特定事业场所
可以在多个事业场所上架销售
最简单的判别指南是 网上一搜是否能搜到，
是否有型录，目录等
相反，非标准品可以理解为不属于上述标准品的产品
它不具备通用性，往往限定为某一特定客户版本
可能会附带图纸或规格书
也可能属于服务、劳务等无形商品
因此通常属于这一类的包括辅材以及一次性商品等
基本上只在单一事业场所 进行展示并销售，就可以这样理解
不过，即便属于所有非标准性类别的品目
也并非就不存在标准品
举个例子，以购物袋这一分类为例
虽说经常会印上特定客户公司的标识 做成该客户的专用品
但在网上销售的 具有特定尺寸与通用设计的购物袋
就可以视为标准品
因此，请大家知悉 确实也存在这样的例外情形
接下来，是休眠化
所谓休眠化，通俗地说 就是商品没有价格、无法销售的状态
也就是说，无法进行发注和下单的状态
休眠化的类型如下
大体分为非定期休眠化与定期休眠化两类
先看非定期休眠化：第一，商品停产
顾名思义，由于制造方停止生产 而无法供应的情况
第二，库存不足，也就是因缺货而暂时无法供应的商品
第三，被确认属于重复商品
合并为单一商品后 处于休眠化状态
最后，因不可承接而休眠化
指因化学物质信息缺失、安全认证缺失等原因 而被休眠化的品目
至于定期休眠化，第一，长期未结算，
以最终结算月为基准 超过12个月无结算实绩的商品
第二，是一次性商品
即定制品或服务等无形商品 仅可下单一次的商品
综上，休眠化可理解为 共计六种类型
那么在完成休眠化处理之后 若需要再次启用
再使用的流程如下
首先，确认需要再使用的类型
若属于停产、库存不足、原因不明、长期未结算等情形
各负责人员提出再使用请求后 由采购担当可直接进行再使用处理
若为重复商品 在提出请求后，由采购担当审批通过
最终由DB管理团队完成再使用处理
若为不可承接商品，提出再使用请求后
需经采购分析团队审批通过方可使用
因为不可承接商品 其中有些品目一旦出库就不应流通
所以可以理解为其审批流程会更为严格
另外， 对一次性商品不允许解除休眠化
接下来说明临时缺货
与休眠化原因无关、仅属暂时缺货的情况下
可以启用临时缺货功能 将下单暂时设为不可用
这样做是为了事先防止发注错误与发注拒绝
并通过缩短处理LT，将客户不便降到最低
临时缺货期限自申请之日起自动设为1个月
最多可延长2次
当采购担当提交临时缺货呈议后
需经所属组长与主管审批，
并与发注管理组长 及中央采购企划负责人达成合议后即告完成
若在期限内临时缺货状态已解除
可上报临时缺货解除呈议 并推进解除
接着，在商品信息之后，我来说明采购信息
采购信息不同于商品信息
指为实现商品采购而设定的一组信息
采购信息大体分为 价格信息和非价格信息两类
先说价格信息 可调整商品价、有效期、币种、条件等
既可以上调也可以下调商品价格
也可通过调整条件，在特定期间进行折扣销售或
加价销售，以灵活运用
不过，由于上调商品价格是影响业绩的因素
因此需经所属组长及主管批准
此外，在价格信息中的有效期管理方面
对于有约定价格的品目
会在到期前开展重新协商
有效期延长1年的请求会自动处理
特殊情况下也可另行提出申请
非价格信息包括 MOQ、配送LT 等
通过调整 MOQ 可使采购活动得以开展
也可通过调整 LT 检索在交付方面 有优势的合作伙伴品目
另外，通过调整可供状态
可以阻止按某条采购信息发出发注
对有效期已到的商品会自动设为不可
以便单独管理
在 S-MRO 上，可通过采购信息批量变更菜单
对特定合作伙伴、特定关键值的商品进行批量变更，
并据此开展运营
课程最后 我们来汇总一下商品信息与采购信息
商品信息包括：商品名、规格，
生产商、订购单位，以及图片与认证信息等
采购信息包括，商品价格、合作伙伴信息、MOQ、有效期等
换言之 商品信息是商品本体层面的信息
而采购信息则是通过 合作伙伴采购该商品所需的信息
对商品信息与采购信息进行细致管理
可以说正是采购担当的本职工作
以上就是本次商品信息登记 与管理部分的课程
如有任何疑问，欢迎随时联系
到这里为止，我是吴在彦资深
谢谢大家