采购无论在传统的ERP中还是电商ERP中都是一个非常重要的模块，它关联着商品库存、财务应付等众多模块。中大型电商公司都选择自开发系统，主要原因是灵活，可以非常快速的响应业务需求与调整，一般情况下我们将其内部多个系统统称为ERP，但如果与传统ERP相比较可能称之为进销存更适合，本篇将简述下我所了解的采购管理及其与财务的关系。

基本流程

以上是一个比较简单的流程，对于采购管理来说，它包括主数据（供应商、合同等）、计划、价格、采购、质检等相关子模块，核心模块是价格管理、请购单（需求管理）、采购管理、到货管理与入库管理，前期准备主要是依赖相关计划，计划又和预算管理、补货等相关，外围系统是商品管理、销售管理等。

供应商管理属于基础数据，合同在ERP中一般归属于采购管理模块，这里将其归属于基础管理中。下面针对相关模块做简述说明。

组织

这里的组织包括业务单元、库存组织，看过相关ERP资料，业务单元也称之为业务组「BG,Business Group」,是组织的一种分类，代表集团公司，用于隔离人事信息。

库存组织「IO,Inventory Organization」管理库存组织所有物品的库存业务，属于库存组织的组织必须指定属于哪个法人实体和业务实体。该公司下的仓库将从属于该工厂组织，即仓库可以按工厂组织分别管理。

业务单元不同采购系统的流程也是不同的，如单业务组的即单组织形式，有多业务组的即集采集结、集采分结等，流程不同对应的合同也不一样，对于多组织的采购在创建单据时需要确定归属的库存组织、财务组织、结算财务组织、应付组织等，通过这些可以确定后续相关单据的流转，如结算单、付款单等等。

这些组织的划分就类似于单据类型，类型不同业务处理流程就有区别，在ERP中可以通过工作流来进行设置。

成本中心与利润中心

这两个概念有必要说明一下，简单的讲成本中心只对成本负责，在考核过程中不关注利润，但利润中心则要考虑成本同时还要关注收益，利润与组织绩效有关。

以上内容在ERP中是比较重要的内容，在产品设计与系统规划时应该围绕业务组织进行，逐步细化，同时要考虑变化的影响。

基础管理

任何一个电商系统中商品都是系统的核心，无论是虚拟商品还是实物商品，无论是自营商品还是商家商品，合理的分类、简洁的商品展示，详细的商品信息都会对采购、销售、仓储、财务等系统有重要影响。

供应商与合同管理在前期都曾单独整理过，供应商可以通过招投标获取，可以通过对外平台获取，可以通过采购获取，无论如何获取，都应该作为主数据保存在供应商库中，供应商可以通过审核由候选供应商成为正式供应商，同时供应商可以设置黑名单，可以冻结「完全冻结、应付冻结、订单冻结等」。

合同主要包括相关条款、付款协议、商品订购总数量及价格「如果依据合同产生采购订单」等信息，一般可以签订框架合同，如果有变更通过变更协议进行。

供应商与合同与采购及应付结算关系非常密切，根据有效合同生成采购单、结算单、付款单。

计划管理

这里列出三个计划需求计划、生产计划、库存计划，在电商系统中是依赖销售预测生成补货计划，同时根据ABC库存管理保证商品库存的，对于供应链的计划管理后续学习整理，目前本人所接触的主要是业务部门根据运营促销活动进行销售预测从而创建请购单。

价格与采购

价格管理在采购阶段主要是在寻源时进行询价、比价，在销售阶段则是根据市场和竞品进行售价调整「爬虫」，这些归属于采销部管理。

采购时如果是集采可以通过合同进行价格谈判，也可以根据采购订单进行当次采购价的确定，对于电商公司不同于生产型企业，所以多数都是采用第二种。

在前期整理采购时，是业务创建采购单或根据补货建议单生成采购单，然后传递到供应商管理平台进行数量与价格确认，在供货商生产完成后与仓库进行到货预约，然后进行入库。

这些是针对主商品的流程，在供应链中有些消耗品或办公品等一般是由业务提出需求，然后创建请购单，经过审核后系统根据请购单生成采购订单，然后进行后续流程。

在采购单审核生效后，就可以进行付款安排（根据合同与付款协议），这里可以理解为预付款。

在此环节，预付款的处理是财务重点考虑的，后续会根据入库单进行核销。

到货、入库与财务

上面这个图看起来应该更清晰些，一个采购单可以分多次发货，这个与之前总结采购管理时有所不同「采购单-到货单」,此前的系统相对比较简单，所以到货单（送货单）应该勾选采购单的商品并确定到货数量生成，当然系统需要限制到货数量总和不能大于采购单的数量。

此时采购单会生成多个到货单，对于采购业务可能更加适用；到货单生成后会安排送货，后续操作是属于仓库的工作范畴。

回顾下仓库收货流程，经过到货预约后，仓库会根据收货能力安排收货，收货商品有的需要质检，有的可能免检，是否需要质检是通过商品属性设置的。

质检主要是四个环节：报检->取样->质检->质检报告；对于需要质检的，一般需要质检报告回传后再做入库操作，质检不合格就会进行退货，这就分为到货区退货与库存区退货（退库RMA）。

根据收货单生成入库单，财务应付结算是根据入库单进行的，一个收货单可以分多次入库，但在实际场景中仓库的实际作业一个入库单真正完成入库上架也可能会跨天，但机率非常小了。

入库时发票还未生成，此时财务需要针对已入库未开票的入库单做暂估处理，即暂估入库，此前接触的财务都是见票结算的，也可能先货后票，货票同到或部分发票先到的场景，这里只讨论先货后票，此时采购入库单暂估入库，或不暂估；采购入库单和采购发票结算传成本或调成本（单到回冲；单到补差）；采购发票只有与入库单匹配结算后才能传应付。

在此环节，可以根据财务具体要求进行设计，一般与上图中流程类似。对于发票管理，可以根据入库单生成，也可以根据结算单生成，我们之前的系统一个结算单对应多个采购入库单，所以是根据结算单生成的，此种设计可以满足代销结算的需求。

代销与经销的财务处理也不是同的，经销是根据采购单，代销是根据销售结算，但是存货财务也是要做暂估入库的。

在NC系统中应付单是根据发票信息生成的，即结算单->发票->应付单，再生成应付凭证，我们都知道在财务应付、总账等模块中都是以会计分录流转的，采购管理中的发票管理应该属于财务模块，因为它的信息与审核是由财务负责的。
自开发的财务统或ERP中如何维护发票在FMS系列中也总结过，在此也可以根据ERP的流程进行调整，满足业务、财务需求场景。

最终相关凭证进入到应付或应收模块，然后在月结时流转到总账模块。

其它模块

库存管理是采购管理、销售管理、财务管理的重要部分，采购单审核生效后的采购暂估入库就是财务核算存货的，当采购入库后会进行核销，以真正的成本入账。

销售时会扣减库存，同时产生应收凭证传到财务模块，对于存货成本核算，经销、代销、联营有所不同，经销、代销都会进行存货入账，联营则不需要。

同时采购管理，有到仓、到店还有直发模块，一般我们都期望于无论供应链环节如何，在数据上都期望补齐，以方便计算、统计与记账，如果想把ERP做的更好些，还是应该不同的业务有不同的流程，减少不必要的数据也是一种方式。

如在直发模块是采购->供应商->用户，这里就没有到货、入库、发货环节，也不需要进行存货核算，只要在财务处理时有所区分即可。

此外，在采购中会有赠品，对于赠品如何结算，成本如何处理，需要考虑，在上家公司时对于采购赠品也会像普通品一样参与成本计算，但现在回想也是有一定的风险的，例如在经销时不会有问题，但是对于代销由于是以销售出库的成本结算，那么赠品参与商品成本计算会拉低成本，应付就会降低，此时会引起供应商的投诉，于公司则是有利的。

总结

采购管理作为ERP的核心模块，组织不同采购流程、财务处理都会不同，上面都是针对单组织的场景总结的，这些内容和之前总结的采购、应付结算有些是相同的，但本篇主要是结合财务描述的，是基于相关ERP标准流程进行的简单梳理，希望对内部进销存系统或自有ERP系统设计开发能够有所帮助。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！

国内对C端的应用已经到了极致，对于B端的应用突然不是突飞猛进，但也有所发展。二者相对而言发展比较独立，始终没能打通。本文作者为我们详细的介绍了如何以服务为抓手，通过五个步骤，引C端用户之水浇灌B端之万物。

由于社交软件和新零售的崛起，近一些年来，国内对C端的应用已经到了极致。

对于B端的软件应用，如ERP，CRM，PLM等，数字化转型的步伐并不大，而且始终没能与C 端打通。

但从2018年开始，市场开始聚焦B端应用，阿里、腾讯等企业巨头，高瓴等资本巨头都在布局B端应用市场，今后十年会是B端应用的黄金十年。

无数人在思考如何依靠C端的能力和流量，赋能B端应用，从而弯道超车，迅速获得B端市场的优势。

这方面的需求是实实在在存在的，而且非常巨大。

如在制造领域，需要收集海量用户的需求和订单，去大规模定制；在研发领域，需要收集用户的反馈和建议，去设计；在销售和供应链领域，需要根据用户未来购买意向去制定排产计划。

如果企业可以对C端用户进行把控的话，就可以在产品设计上、在定制灵活性上、在产销协同上占据绝对优势。

但从哪一块入手可以“引C端用户之水浇灌B端之万物”一直是困扰所有企业的难题，至今也没看到有哪家企业可以很好的解决。

以笔者的经验，突破口一定在服务领域。

因为你要引C 端用户之水为B端所用，那前提必须是有地方可以来蓄水，形成一个大的用户蓄水池。

以制造业为例，在制造、研发、供应链等领域，根本就极少接触用户，所以不可能形成用户蓄水池。

在营销领域，基本是通过电商和卖场去销售，与用户隔着一层；就算是有自己的专卖店，但在销售过程中，销售人员和客户（注意是客户，不是用户）很难形成信任关系，建立持续的联系。

因为很多产品是低频消费，几年内客户不会复购，所以哪怕是通过会员权益等方法，也没有什么吸引力。

只有在服务的环节，用户需要了解和关注产品保养信息，如果是维修，用户更是有求于你，你和用户可能会有面对面单独相处的一段时间，这时候是最好的建立关联和信任，形成用户蓄水池的时机。

一、 以服务为入口引C端用户之水

如上图所示，通过三个步骤可以完成“引C端用户之水浇灌B端之万物”，即：

1. 通过服务创造入口、形成黏度和产生信任；
2. 通过服务引入用户，形成用户蓄水池。通过持续内容运营，产生依赖和活跃度
3. 把用户蓄水池中的用户需求导向企业内部之研发、线下专卖店、产业、工业4.0平台、物联网数据平台、企业生态平台等。

这里最难的是1，2步，即如何通过服务把用户引进来，以及如何运营用户蓄水池。

至于第三步，只要有了用户之水，那企业各部门是最了解如何使用的了。

下面介绍如何通过5个步骤，来完成引入用户和运营用户。

1. 步骤一：去中心化、运营服务人员个体品牌

如果要引用户之水，一定要靠服务人员，而且服务人员还得乐意和积极做这事，否则引进来的就是死水。

如果要想服务人员心甘情愿地做这事，就得让服务人员感觉是为自己做。

所以一定要去中心化，从对外是一个集团服务品牌，到对外是成千上万服务人员品牌，而服务人员所做的一切就是在经营自己的品牌。

二、服务去中心化

如上图所示，通过服务去中心化，服务人员经营自己的品牌。

但如果要经营自己的品牌，就得有服务人员与用户建立管家关系这一场景，从而使服务人员经营自己的用户。

一旦建立管家关系，用户的任何消费，服务人员都可获得相应奖励，这样会大大激发服务人员运营自己品牌的积极性。

场景设计：

三、服务触点建立管家关系场景设计举例

如上图所示，是以上门服务作为一个建立管家关系的场景示例，通过这个场景，把一次性服务转变成长久交互的渠道。

在设计服务场景时，为了能达到预期效果，需要关注以下几点：

1. 数字化工具：为了不影响用户体验，需要在30秒内，用户可以完成绑定和建立持久关联的手机操作。所以用户端不建议采用APP，可以优先考虑微信公众号和小程序。
2. 关注用户体验：不要为了绑定而绑定，一定要融合在服务场景中，让用户感觉到他所做的所有操作，都是为了提升他的体验。比如利用用户评价，查看服务内容等环节，做到无缝绑定和对接。
3. 与服务人员共赢：再简单的绑定过程也会耽误现场工程师的时间，一定设计利益分配模式，让服务人员获益，这点至关重要。
4. 新技术引入：要引入机器人和人工坐席等接管现场工程师线上交互服务，要采用数据AI等技术建立主动服务模型。这样就可以极大地提升交互效率，降低交互成本。

2. 步骤二：整合触点、构建智慧服务平台

四、整合触点构建智慧服务平台

如上图，仅仅通过服务人员提供服务这一场景引入用户是远远不够的，我们需要：

1）整合所有服务触点

• 社交需求：整合所有微信、微博触点
• 应用需求：整合所有APP触点
• 服务需求：整合呼叫中心等语音、短信和邮件触点
• 生活需求：整合产品上的触点，如大屏
• 使用需求：整合官网、说明书等触点

2）构建服务中台

• 谁来提供服务：与用户建立稳定链接后，谁来提供服务，如服务人员、机器人、坐席员、专家支持等。
• 提供什么服务：与用户建立稳定链接后，提供什么持续稳定的服务来交互增值，如安装维修、购买服务、增值服务、生态服务等。
• 如何数据驱动：单靠服务人员的主动服务是远远不够的，要建立数据驱动机制，通过建立用户小数据来自动触发服务。用户小数据包括产品档案、产品保养模型、场景服务模型等。

3）开发智慧服务引擎

服务的提供要做到智能化，要做到服务无处不在，服务按你所需：也就是在合适的时间，合适的场景，通过合适的渠道，推送合适的服务，分配合适的服务执行人。这就是需要我们基于用户小数据开发智慧服务引擎。

3. 步骤三：服务代言、引爆社群

整合了所有触点，有了智慧服务平台后，我们下一步就是要有自己的铁粉，也就是服务代言人，帮我们在社群中传播推广，替我们造势。

五、服务代言引爆社群

1）如何找出第一批服务代言人：建议首先发展服务人员作为第一批代言人

2）如何扩展服务代言人：可以发展企业的忠实会员，如金卡、银卡会员，也可以叫第一批代言人发展自己亲朋好友来扩展服务代言人。

3）代言人价值分享平台

代言人管理必须有一个数字化平台管理：

• 代言人管理：管理代言人申、批准、升降级、权限等。
• 任务管理：给代言人布置各种任务去执行，比如推广任务、活动通知等。
• 价值分享管理：需要针对代言人的贡献给与相应奖励。
• 积分管理：通过积分和积分兑换保持代言人的忠诚度和活跃度。

4. 步骤四：生态并联，共创共赢

当用户量达到一定数量时，必须并联生态来维持用户的黏度和活跃度。

之所以说是并联，而不是构建，是因为绝大多数企业的用户数量不足以支撑自建生态。

六、并联生态共创共赢

1）内容为王
在生态运营之初，一定是内容为王，而且要通过内容细分用户，把用户分流到不同社群中。

2）互作伙伴多样化和互补
合作伙伴要多样化，有提供内容的，有提供产品和解决方案的，有提供收益的……生态是需要多样性和互补的。

3）建立生态价值分享平台
我们是生态规则的制定者和监管者，而不应该是执行者，不应该是所有的事都亲历亲为。所以我们需要建立一个数字化平台，允许合作伙伴来管理自己的用户，提供各自的内容和产品。

5. 步骤五：服务调频、聚焦小区

这最后一步是针对把用户吸引上来，但活跃度太低的情况。很多企业的服务是低频的服务，几个月甚至几年1次。

由于产品本身的特性，就算是我们如何设计基于产品的增值服务，也不可能变成像餐饮或社交一样的高频需求。

低频服务限制了服务人员对用户需求的深入了解，也制约了用户对服务人员的强依赖和信任。

所以我们可以变换一下思维，服务对象由1个用户变成1个物理小区。中国14亿人口分布在30万到50万小区和70万村子中，服务针对个人是低频的，但针对小区是高频的。

针对小区为单位的服务具有以下特征：

• 需求一致性：同一小区的居民收入水平，居家环境等都比较一致，所以往往会选相似的产品和服务。
• 传播快捷性：同一小区都有自己业主群，二手群，兴趣群等，所以相关产品和服务极易口碑传播。
• 服务便利性：服务人员在同一小区持续服务成本是最经济的，服务也是最快捷的。
• 产出最大性：成千上万人的小区能产出的服务需求是巨大和持续的，足以让我们服务人员全心去经营。我们没有能力去精耕细作14亿用户中的每一个人，但我们有能力去精耕细作30万到50万小区中的每一个小区。

我们可以把小区作为基础单元，我们的目标不是每个用户都满意，而是每个小区都整体满意。我们可以建立以小区为中心的服务和考核的新模式。

这个功能可以做成小程序的形式，这样就不会受公众号等的舒服。

1）小程序功能建议

为全国30到50万小区分别建30到50万小区实体。显示小区相关的服务内容，服务人员，互动，和活动等。

• 互动：小区用户可以提出任何服务相关问题，现场工程师或客服会在线回答。用户也可晒服务照片等。
• 服务：小区用户可以选择各类服务，也可以根据现场工程师的评价，直接选择派单给该现场工程师。
• 现场工程师：显示该小区所有现场工程师，可以评价。按为该小区服务质量和数量综合排序。
• 通知：现场工程师去小区服务，最近活动等都会以消息模板形式通知小区中每个用户。
• 优惠：根据小区的评级、业务量、地理位置等给出不同优惠，千区千面。
• 考核：以该小区为基本单位考核，如千户服务量，千户投诉量，同比，环比等。

2）服务人员相关功能建议

• 1个小区可由1个或多个现场工程师负责。
• 现场工程师回复所负责小区用户的问题。
• 现场工程师按综合积分排名显示。
• 现场工程师上该小区服务，我们以消息方式通知该小区用户，用户可以下单接续排期。

3）用户相关功能建议

• 用户可以绑定多个小区
• 用户可以在绑定小区提问、点评服务（可晒照片）、给现场工程师点赞（申请过服务的）、申请服务（可优先选择某现场工程师）、领劵、活动报名等。
• 小区服务上门或优惠活动，用户会得到消息通知。
• 用户积极参与小区活动或点评服务晒照片，可获得优惠劵。

七、总结

本文介绍了如何以服务为抓手，通过五个步骤，引C端用户之水浇灌B端之万物。

这五个步骤分别是：

1. 去中心化、运营服务人员个体品牌；
2. 整合触点、构建智慧服务平台；
3. 服务代言、引爆社群；
4. 生态并联、共创共赢；
5. 服务调频、聚焦小区。

作者：杨峻。现任微软资深数字化转型专家。曾任海尔全球服务数字化转型和信息化建设总负责人（主导了海尔10年来最大规模的服务再造项目 – HCC），IBM GBS 客户关系管理数字化创新解决方案中国区总负责人。

免责声明：本文版权归原作者所有，文章系作者个人观点不代表蜗牛派立场，如若转载请联系原作者；本站仅提供信息存储空间服务，内容仅为传递更多信息之目的，如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈！