银行科技人员对业务的理解曲线

    前两天跟同事聊天的时候,灵光一闪,想到用这个角度去阐述我对业务的理解,后来回头琢磨琢磨觉得思路还不错。其实那天的讨论是这个话题开始的——“银行从业的开发人员并没有直接参与过业务工作,因为不同于互联网业务在生活中还可以场景化的体验,金融业务具备一定的认知门槛,那如何去感受和理解业务在做什么?如何建立自己的业务知识和技术知识的融合体系。”

    我并没有执着的回答这个像海一样大的话题,我试图通过一个例子来说清我的理解。于是,我选择从对“放款”一词的感受开始。

当我刚毕业的时候,背景是一个理工科的毕业生初来乍到银行,听到“放款”的第一感受是什么?

       银行的钱放到了我的账户

       就这个感觉,因为过往的经验并不能告诉我什么。其实这是一种结果性的感受,结果性的感受最直观,也最原始,我只能说出我能看到的东西。

后来当我做了贷前系统群,再听到“放款”,感受有了一些变化。

       C端用户发起了授信申请,经过风控筛选、审批、人工审批,得到一个风控建议额度,风控建议利率;在这个额度基础上和授信有效期内,用户发起用信申请,经过一系列风控筛选审批之后,向支付接口发起放款请求,等到放款成功的状态后,就意味着已经把银行的钱放到用户的指定账户了。

       在这里,我特意将授信和用信分开来谈,因为循环用信(随借随还)的流程中,衍生出了客户和借据的两个维度,映射关系是“一对多”,值得一提的是数据维度却有了两层。这段经历让我我了解到“放款”之前,还有一系列的业务流程。不过这个阶段,我的理解止于“放款”请求指令,但是我的理解也懵懵懂懂的多了两个数据维度,这个数据维度还可以有什么用呢,困惑我良久。

当我接触贷后管理系统之后,继续沉淀新的感受

      “放款”意味着开始进入贷后管理流程,有别于贷前,这个一个新流程的开始,很幸运的说这个是换了一个视角来审视业务。从此,再有任何业务需求,我第一反应都会问,你说的是借据维度?还是客户维度?因为从上一阶段的感受会成为我的经验,知道了数据已经有了维度之分。

      同样,业务人员再跟我谈五级分类规则、贷中预警、催收管理以及各类业务数据报表统计(迁移率,催收率...)等,都需要建立在数据维度之上。

当我学习核心系统之后,对“放款”的感受更加细致全面

        核心的“放款”是收到放款请求之后的开始系列的事务处理,

        1)对账户鉴权,账户状态检查

        2)客户额度检查

        3)支付渠道完成支付,收款账户是本行卡/他行卡/II类户的支付路由

        4)放款短信发送

        5)  扣款文件,还款计划表生成

        这种感受从直观上的体会,慢慢健全成一个完整的流程。

总账的视角怎么看“放款”?

      “放款”在总账的记账场景,通过这笔交易的业务属性(境内、境外,个人/企业,本金/利息,等等)解析出对应的一套分录,如:

    DR 境内个人短期信用贷款

        CR 过渡科目

    DR 过渡科目

        CR 活期存款-客户

     随着账务这块知识的补充,我尝试使用一个新的思路去复盘过去学习的业务知识,通过贷款业务形态转移的分录对照回过头看贷款的各类业务交易,如:正常转逾期,逾期转非应计,核销,正常还款,提取应收息等等。这个时候的感受是,恍然大悟!原来如此!一切是那么的合理!


    最终这些“感受”的积累曲线,其实是你知识体系建立的过程。我喜欢随手画这个图给较年轻的朋友以示鼓励。任何知识的积累会有一个漫长的发育期,这从来不是一个线性的关系,这个发育期甚至会让你的认知反复推倒、重建,你也会忘记一部分,相当苦涩。但是,随着你的反复记忆和理解,一旦迎来那个爆发点,业务知识的成长是成指数型的。

手工绘图,粗糙但是真诚

    如果你也曾为之付出努力,你也会和我有相同的感受!但是我也在思考,为什么会有“指数型”增长的现象,为什么会有所谓的“一通百通”?其根本原因是——业务流程是有“逻辑”的。首先它是合理的,它才会存在,或者保守一点说,至少在它出现的那个环境的条件下,是一定具备其合理性的。

    这些业务知识结合技术能力,最终将转化成科技人员项目落地的能力和解决问题的能力。回到一切的最初,科技人员谈业务需求,其实在谈什么?

    第一层:谈“逻辑”—业务逻辑

    业务的主流程说的是逻辑;

    主流程的例外说的是对逻辑的补充。

    这是业务人员需要说明清楚的,也是代码开发的基础!

    第二层:还是在谈“逻辑”—数据逻辑

    在业务流程的基础上,分析数据流。分析数据流一定需要超越业务人员的理解,利用技术背景去帮助业务人员抽象数据维度 。

    客户维度 or 交易维度 ?

    产品维度 or 渠道维度 ?

    。。。

    如果你不谈数据逻辑会有什么灾难性后果?众所周知,数据合并易,分则难,历史数据的处理真的要命。

    这里蕴藏的逻辑是我们谈数据处理,首先要谈数据对象,其次,数据对象一定有所属维度。

    第三层:谈“合理性”——架构逻辑

    此时,是我反过来问业务人员,需要他来回答我的问题。业务人员对以下这些关键词的合理评估结果,在我脑海里映射的是技术架构选型和系统基础设施设计,以下的关键词其实就是一个个的技术指标,更是适配这套业务架构的技术架构!

    关键词:业务量,峰值并发量,业务时长(7×24),是否对客,监管合规(影像存储,数据脱敏,监管报送等),经办/复核审批流等等。

    谈这三层的理解,我没有展开的特别细。但这套逻辑形成我工作中的方法论,非常有效的帮助我快速建立知识体系,希望可以引起您的共鸣。

    欢迎分享你的观点,关注wxgz号:Qiannianyhj,一起探讨。

你可能感兴趣的:(银行科技人员对业务的理解曲线)