企业数字化系列——授信业务数字化设计

1 评论 5386 浏览 16 收藏 19 分钟

企业授信是单位之间就上下游商品流通形成的一种相互信任的交易关系,也就是赊销。本文作者根据自身经验,梳理了对企业授信业务的理解,并套用产品设计方法论,分析如何做好企业授信业务数字化建设,一起来看一下吧。

最近做了几家企业的授信业务解决方案,都已成功上线运营,在此梳理了自己对企业授信业务的理解,并套用产品设计方法论来详述怎么做好企业授信业务数字化建设。

一、理解企业授信业务

百度官方的授信定义:所谓信用是指依附在人之间、单位之间和商品交易之间形成的一种相互信任的生产关系和社会关系。信誉构成了人之间、单位之间、商品交易之间的双方自觉自愿的反复交往,消费者甚至愿意付出更多的钱来延续这种关系。

企业授信:单位之间就上下游商品流通形成的一种相互信任的交易关系,其实就是赊销(我相信你肯定会给钱,做先货后款交易)。基于这几家企业实际业务,所处不同行业环境(主要包括:客户类型、商品特点、履约方式、资金和财务管理),以下是我对企业授信业务的框架性理解:

1)动机

作为企业只有通过持续交易才能不断获取利益,产生企业价值,因此企业做授信交易的动机是有助企业和客户产生更多的交易获取利益。

2)客观原因

  1. 产品同质化(产品没有优势),特别是当市场供大于需的时候,企业为了在市场竞争中战胜竞争对手,授信和价格,营销,促销,返利一样,是企业打市场战役的有利武器;
  2. 下游客户强势,想进入该客户渠道就得按客户的结算付款周期来(比如沃尔玛,京东);
  3. 通过授信配合其它市场行为,实现具体市场目标,主要表现为:新品切入市场,规模商品跑量,高利润商品推广,尾货清仓等场景;

3)授信的业务视角

  1. 从交易维度看,一笔授信必须包括授信主体和被授信方2个角色,由授信主体卖商品给被授信方,作为交易的一种结算方式,不产生实际的授信交易,授信本身没有实际意义;
  2. 从资金维度看,授信必须有具体的授信额度,不同于信用贷款,授信额度只能用于交易,不能提现,且有时间周期;
  3. 从财务维度看,给客户授信本身属于管理会计范畴,产生授信交易后,企业产生应收,形成借贷关系;
  4. 从流程管理角度看,授信作为独立的业务闭环包括申请授信,计算授信额度(模型或手工)并下发,使用授信,还款和账期(逾期,延期和还账)管理5个流程节点。

4)客户精细化运营的一部分

企业按渠道维度一般把客户分为工程客户,KA客户(比如商超),经销商,零售店和终端消费者,交易履约方式不同,授信的方式也不同:

  1. 工程类一般跟着合同走;
  2. KA一般需要结合客户的采购付款周期;
  3. 经销商结合交易量和回款记录预估;
  4. 企业授信一般不触达零售店,由经销商结合零售店的交易管理做授信(企业可以提供授信管理工具);
  5. 企业授信一般不触达终端消费者,终端消费者可以通过消费金融或信用贷这类的三方金融产品和企业做“授信”交易。

5)授信有风险

  1. 企业授信客户一般为大型客户(工程,KA和经销商),往往授信交易大,回款周期长,造成企业资金周转周期长,容易出现资金链断的情况;
  2. 市场不确定性强,很多客户因为自身资金周转等问题无法及时回款,甚至不回款造成坏账(因此授信业务,企业都需要有一套对应的风控机制,确保风险整体可控,不单单只是为了更多的交易,需要在财务管控下产生利润,不然账面上N多应收,容易出现坏账造成损失)。

基于以上企业授信业务的框架性认知,接下来就可以围绕企业授信实际授信业务现状,相关流程,角色,涉及的系统展开调研分析,并针对各角色需求做方案的整体规划和详细产品设计,确保方案的完整性,可落地。

二、企业授信产品设计

本次企业授信产品设计,以国内奶制品消费行业领头羊XX企业授信业务设计为样本展开。

1. 明确企业授信业务目标

基于企业战略目标,明确企业授信发展方向,来明确授信产品定位。

1)企业目标

XX企业实行集团-事业部的经营组织管理机制,按区域和渠道维度划分事业部做内部经营管理,按不同产业线注册了生产和销售公司,由销售公司和客户建立交易关系。

业务上只有KA和经销商客户有授信业务,之前所有事业部,法人公司授信业务各自为政,没有形成集团统一的授信管理机制,很多客户交叉授信,加上业务和财务存在不合规操作,授信风险极大,需要搭建集团-事业部,销售组织(销售公司,渠道)和客户之间统一的授信管理和控制体系,输出统一的授信管控服务,赋能交易业务。

2)企业授信产品定位

集团统一的授信服务中心。产品目标:通过搭建通用的授信服务能力向下解耦各销售公司在SAP,U9等ERP系统的授信管控,向上赋能交易业务,使授信服务能够快速支撑企业灵活的全渠道交易业务发展。

2. 分析授信业务全流程

从申请授信,计算授信额度(模型或手工)并下发,使用授信,还款和账期(逾期,延期和还账)管理全流程,识别出支撑集团内授信业务各流程的组织和参与角色,做整体分析,抽象出通用的基础信息,业务关系和属性,打造数据模型。

1)授信申请

授信分为固定授信和临时授信,固定授信主要对应KA客户,按年/月等固定周期,基于历年的交易量,客户财务状况等维度做评估(没有用到相关的三方企业数据服务和授信模型计算授信额度),有效时间就当年或当月;

临时额度,一般由客户和业务员线下沟通确认后,基于比较明确的销售订单来评估授信额度,并由业务员在OA系统做授信申请(走申请流程,一般需要审批到二级领导和相关财务,额度特别大的可到事业部总经理),有效时间一般在一个月内;

授信额度不能跨事业部,但可以全面覆盖事业部下面的所有渠道和可销售的商品(客户和销售公司签订合同,已经锁定销售渠道和商品)。

2)计算授信额度并下发

完成授信申请流程后,由OA推送授信流水到SAP,最终由SAP下发给对应的DMS(客户销售交易系统),供客户查询和使用;

授信额度不通过模型计算,在申请流程中已经明确具体的授信额度(因为是企业内部的授信业务,且授信客户数据不多,因此从投入产出比和实际业务落地评估,暂时不需要做基于授信模型的额度计算)。

3)使用授信

  1. 客户在DMS了解自己的授信情况,包括可用额度,冻结占用和已经使用的额度;
  2. 客户使用可用的授信额度下单,订单可按周期,批次发货(发货环节,企业确认收入,因此授信额度会在下单环节作冻结占用,发货环节作实际的占用扣减);
  3. 超过有效周期的授信会失效回收(需要注意:已经占用的额度,不会失效,要么做占用扣减,要么在占用释放后做回收);
  4. 使用授信使用过程中,会基于客户的账期做信用管控,主要包括是否超额,是否逾期。

4)还款

  1. 客户一般通过线下对公账户打款到合同上约定销售公司的对公账户,由资金系统对接银企直联获取还款数据,并推送给SAP做账;
  2. 还款需要认领(一般通过客户的企业社会统一代码,内部的客户ID,打款账号等收款流水信息来识别是哪个客户打的款)成功后,才做结算上账;
  3. 认领成功后,有账期的客户做账单还款,无账期的作为预收款处理。

5)账期管理

账期类型包含固定周期和普通周期2种,固定周期就是我们常说的月结,季结,周期性生成账单(锁定账单生成日,起算日,还款日);普通周期则会在实际使用额度那天开始,通过+N日作为还款日,超出则为逾期;

基于某些特殊原因,需要人为的对已经逾期的账单做延期处理,需要走延期流程;

逾期客户都不能在使用授信下单,和是否还有可用的授信额度无关;

对于逾期不还的客户,需要财务,业务协同客户推动还款,一旦确认为无法还款的,则做坏账处理(应收结转为损失)。

系统整体上下文:基于以上流程,梳理清楚涉及的相同系统,明确企业授信业务的边界,以确认业务流程和数据流,确保授信业务的完整性,业务闭环。

3. 主要诉求

各事业部基于自身销售业务需要,单独管理自己的客户信用,没有形成集团-事业部层面统一的信用管理体规范,效率低,难管理,容易出现坏账;

账期及逾期策略统一在SAP管控,业务难扩展,做不到精细管控,而DMS只基于自身交易客户做超期和超额校验管控,管控策略固定,没有形成通用可配置的管控策略,如果有新的业务场景需要信用管控,很难复用和扩展;

SAP生成财务维度的信用流水,DMS产生交易维度的信用流水,财务需要每月线下核对SAP和DMS2边产生的信用流水,工作量大,且差异只能在每月人工对账时发现,容易出现差异处理不及时,处理工作量大的问题。

4. 产品设计

我们按产品设计方法论4个步骤做产品设计:清楚产品四要素,了解业务系统上下文,授信业务领域设计,产品迭代(结合业务做产品迭代)。

基于前面XX企业授信业务全流程梳理出来的四要素架构:

授信中心领域设计:业务中台领域化设计思路,按应用层,逻辑层和领域核心层做授信中心的领域设计。

  • 领域层:聚焦授信对象(授信主体,授信用户),授信属性(比如授信周期,授信使用范围等)和权限能力(查询,占用,占用扣减,占用释放,退回等业务操作能力);
  • 逻辑仓:授信业务的核心业务逻辑,包括授信模型,额度校验策略/占用策略,账期模型,逾期模型和风控模型;
  • 应用层:作为标准化的授信服务对接外部应用系统,满足外部系统不同交易业务的授信服务需求。

1)产品迭代

产品迭代的核心思路是以实现最小可扩展(分层设计)的授信业务闭环作为产品1.0,结合项目计划,做产品迭代。

正常讲,授信的最小业务闭环可以按授信建档,获取授信额度,查询和使用授信额度,生成账务流水作为授信产品的最小1.0版本,后续对应实际业务需求和业务系统上下文,做服务能力的扩展。

2)设计注意事项

  • 聚焦面向交易业务的授信管控能力搭建,确保独立于SAP等ERP系统是系统层面设计授信管理平台的核心目标;
  • 一般企业面向KA等大B客户授信,大B客户需要对下面的小B客户有授信管理的需求,这是2层基本独立的授信体系,从对象和经营管控体系都非常不同,业务上需要独立设计,但核心能力可以复用;
  • 如果企业有独立的支付结算平台,则授信作为交易的1种支付结算方式,可以通过支付结算平台接入以订单为核心的交易体系;
  • 协同对账平台,确保平台产生的授信交易流水和上下游的一致性;
  • 平台建立内部的试算机制,对历史流水周期性的试算,产生逻辑日终余额和实际交易日终余额对比,确保内部数据不会因为并发等系统因素造成错误。

三、企业授信业务发展趋势

基于企业授信发展趋势,结合当前实际企业授信业务,可以更好的做产品规划和迭代。

  1. 企业授信业务数字化,逐步从纯人工往在线自动化,可视化过度;
  2. 企业授信业务开始通过客户交易过程中产生的交易数据,动态的开展授信业务;
  3. 不同客户类型,不同产品线,授信业务场景更多远化;
  4. 授信业务金融化,在闭环交易场景内,打包授信交易标的(应收,订单贷等)对接金融机构,扩大授信交易的同时,加速资金周转;
  5. 只要企业间有交易,授信业务不会消失,但是纯企业内部的授信业务将越来越少。
  6. 企业触达私域流量,怎么和消费金融结合本质上就是企业授信业务往C端消费者的拓展。

四、总结

先对授信业务有个框架性的理解,再进入实际企业授信业务场景去了解其是怎么流转,涉及哪些组织和角色,哪些业务节点,做哪些操作,涉及哪些业务系统,注意哪些事项,基本可以完整地了解企业授信业务。然后结合产品设计方法论,就可以设计出符合该企业的授信产品了。也是自己在做过几个企业数字化转型授信后的沉淀吧,希望对你服务好企业客户有帮助。

本文由 @哈哈的鲸鱼 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感谢大佬的知识分享,谢谢~

    来自广东 回复