企业授信是单位之间就上下游商品流通形成的一种相互信任的交易关系,也就是赊销。本文作者根据自身经验,梳理了对企业授信业务的理解,并套用产品设计方法论,分析如何做好企业授信业务数字化建设,一起来看一下吧。
最近做了几家企业的授信业务解决方案,都已成功上线运营,在此梳理了自己对企业授信业务的理解,并套用产品设计方法论来详述怎么做好企业授信业务数字化建设。
百度官方的授信定义:所谓信用是指依附在人之间、单位之间和商品交易之间形成的一种相互信任的生产关系和社会关系。信誉构成了人之间、单位之间、商品交易之间的双方自觉自愿的反复交往,消费者甚至愿意付出更多的钱来延续这种关系。
企业授信:单位之间就上下游商品流通形成的一种相互信任的交易关系,其实就是赊销(我相信你肯定会给钱,做先货后款交易)。基于这几家企业实际业务,所处不同行业环境(主要包括:客户类型、商品特点、履约方式、资金和财务管理),以下是我对企业授信业务的框架性理解:
1)动机
作为企业只有通过持续交易才能不断获取利益,产生企业价值,因此企业做授信交易的动机是有助企业和客户产生更多的交易获取利益。
2)客观原因
3)授信的业务视角
4)客户精细化运营的一部分
企业按渠道维度一般把客户分为工程客户,KA客户(比如商超),经销商,零售店和终端消费者,交易履约方式不同,授信的方式也不同:
5)授信有风险
基于以上企业授信业务的框架性认知,接下来就可以围绕企业授信实际授信业务现状,相关流程,角色,涉及的系统展开调研分析,并针对各角色需求做方案的整体规划和详细产品设计,确保方案的完整性,可落地。
本次企业授信产品设计,以国内奶制品消费行业领头羊XX企业授信业务设计为样本展开。
基于企业战略目标,明确企业授信发展方向,来明确授信产品定位。
1)企业目标
XX企业实行集团-事业部的经营组织管理机制,按区域和渠道维度划分事业部做内部经营管理,按不同产业线注册了生产和销售公司,由销售公司和客户建立交易关系。
业务上只有KA和经销商客户有授信业务,之前所有事业部,法人公司授信业务各自为政,没有形成集团统一的授信管理机制,很多客户交叉授信,加上业务和财务存在不合规操作,授信风险极大,需要搭建集团-事业部,销售组织(销售公司,渠道)和客户之间统一的授信管理和控制体系,输出统一的授信管控服务,赋能交易业务。
2)企业授信产品定位
集团统一的授信服务中心。产品目标:通过搭建通用的授信服务能力向下解耦各销售公司在SAP,U9等ERP系统的授信管控,向上赋能交易业务,使授信服务能够快速支撑企业灵活的全渠道交易业务发展。
从申请授信,计算授信额度(模型或手工)并下发,使用授信,还款和账期(逾期,延期和还账)管理全流程,识别出支撑集团内授信业务各流程的组织和参与角色,做整体分析,抽象出通用的基础信息,业务关系和属性,打造数据模型。
1)授信申请
授信分为固定授信和临时授信,固定授信主要对应KA客户,按年/月等固定周期,基于历年的交易量,客户财务状况等维度做评估(没有用到相关的三方企业数据服务和授信模型计算授信额度),有效时间就当年或当月;
临时额度,一般由客户和业务员线下沟通确认后,基于比较明确的销售订单来评估授信额度,并由业务员在OA系统做授信申请(走申请流程,一般需要审批到二级领导和相关财务,额度特别大的可到事业部总经理),有效时间一般在一个月内;
授信额度不能跨事业部,但可以全面覆盖事业部下面的所有渠道和可销售的商品(客户和销售公司签订合同,已经锁定销售渠道和商品)。
2)计算授信额度并下发
完成授信申请流程后,由OA推送授信流水到SAP,最终由SAP下发给对应的DMS(客户销售交易系统),供客户查询和使用;
授信额度不通过模型计算,在申请流程中已经明确具体的授信额度(因为是企业内部的授信业务,且授信客户数据不多,因此从投入产出比和实际业务落地评估,暂时不需要做基于授信模型的额度计算)。
3)使用授信
4)还款
5)账期管理
账期类型包含固定周期和普通周期2种,固定周期就是我们常说的月结,季结,周期性生成账单(锁定账单生成日,起算日,还款日);普通周期则会在实际使用额度那天开始,通过+N日作为还款日,超出则为逾期;
基于某些特殊原因,需要人为的对已经逾期的账单做延期处理,需要走延期流程;
逾期客户都不能在使用授信下单,和是否还有可用的授信额度无关;
对于逾期不还的客户,需要财务,业务协同客户推动还款,一旦确认为无法还款的,则做坏账处理(应收结转为损失)。
系统整体上下文:基于以上流程,梳理清楚涉及的相同系统,明确企业授信业务的边界,以确认业务流程和数据流,确保授信业务的完整性,业务闭环。
各事业部基于自身销售业务需要,单独管理自己的客户信用,没有形成集团-事业部层面统一的信用管理体规范,效率低,难管理,容易出现坏账;
账期及逾期策略统一在SAP管控,业务难扩展,做不到精细管控,而DMS只基于自身交易客户做超期和超额校验管控,管控策略固定,没有形成通用可配置的管控策略,如果有新的业务场景需要信用管控,很难复用和扩展;
SAP生成财务维度的信用流水,DMS产生交易维度的信用流水,财务需要每月线下核对SAP和DMS2边产生的信用流水,工作量大,且差异只能在每月人工对账时发现,容易出现差异处理不及时,处理工作量大的问题。
我们按产品设计方法论4个步骤做产品设计:清楚产品四要素,了解业务系统上下文,授信业务领域设计,产品迭代(结合业务做产品迭代)。
基于前面XX企业授信业务全流程梳理出来的四要素架构:
授信中心领域设计:业务中台领域化设计思路,按应用层,逻辑层和领域核心层做授信中心的领域设计。
1)产品迭代
产品迭代的核心思路是以实现最小可扩展(分层设计)的授信业务闭环作为产品1.0,结合项目计划,做产品迭代。
正常讲,授信的最小业务闭环可以按授信建档,获取授信额度,查询和使用授信额度,生成账务流水作为授信产品的最小1.0版本,后续对应实际业务需求和业务系统上下文,做服务能力的扩展。
2)设计注意事项
基于企业授信发展趋势,结合当前实际企业授信业务,可以更好的做产品规划和迭代。
先对授信业务有个框架性的理解,再进入实际企业授信业务场景去了解其是怎么流转,涉及哪些组织和角色,哪些业务节点,做哪些操作,涉及哪些业务系统,注意哪些事项,基本可以完整地了解企业授信业务。然后结合产品设计方法论,就可以设计出符合该企业的授信产品了。也是自己在做过几个企业数字化转型授信后的沉淀吧,希望对你服务好企业客户有帮助。