作者 | 丛勇
来源 |丛氏IT
编辑 | 郑斌
美编 | 杨文华
10月15日，银行业协会和信通院联合发布了《银行业数字化转型投入有效性评价研究报告》，该《报告》是帮助银行业在对数字化转型投入方面，提供可量化评价的参考依据。
近日我去北京参加了信通院的宣贯会，进一步学习了报告内容和推广策略。
其实，我本人这几年也陆续参与了多家区域银行科技项目的评价工作，主要是基于监管要求、行业规范、风险事件、最佳实践等，根据不同客户的需求，既要看出问题和风险点，也要能够提供一些可以有效提升的改进建议。
那么结合自己对银行数字化转型的理解，今天做一次总结分享。
去年家里买了新的房子，因为部分窗户透寒，冬天家里比较冷。为了加强保暖效果，今年夏天就把窗户换成了三层断桥铝，算是比较好的材质，打算今年冬天看看效果。
那么，换窗户就属于一个项目，冬天看效果就是一次项目后评价。
简单的来说，就是看项目是否达到最初的预期。
银行的项目中，通常在战略规划、项目前咨询报告、项目立项报告、可行性分析报告、项目合同等资料中。同时，针对项目具体的细节，如需求、设计、计划等，则分别在项目资料中体现。
项目后评价的意义，既要分析出项目整个过程中优缺点，也要看该项目有哪些值得借鉴和推广的意义，对后续项目有哪些帮助。
2009年6月1日，银监会发布了《商业银行信息科技风险管理指引》，其中第三十二条提出，“商业银行应有能力对信息系统进行需求分析、规划、采购、开发、测试、部署、维护、升级和报废，制定制度和流程，管理信息科技项目的优先排序、立项、审批和控制。项目实施部门应定期向信息科技管理委员会提交重大信息科技项目的进度报告，由其进行审核，进度报告应当包括计划的重大变更、关键人员或供应商的变更以及主要费用支出情况。应在信息系统投产后一定时期内，组织对系统的后评价，并根据评价结果及时对系统功能进行调整和优化。”
可以看出来监管机构对商业银行后评价的指引时间偏久，并没有根据银行的发展动向进行更新和细化，所以很多银行在做项目后评价方面，缺乏有效的指导，更多的是结合同行实践和自身特点方面进行摸索。
通常银行会在信息科技项目管理制度下，建立后评价的管理办法，明确出后评价时间、发起人、填报人、评价模板、评价内容或指标等。
在《某银行信息科技项目管理办法》中提出，项目后评价的主要工作包括启动评价计划、收集评价数据、反馈评价结果等。项目后评价周期为项目投产运行半年以上，建议为一年。
1）启动检查计划，是在项目投产运行半年以上，由立项部门列入项目后评价检查计划，并通知信息科技部门、相关业务部门和项目承建单位。
2）收集评价数据，各责任部门应通过多种方式收集评价指标数据。按照项目的关联部门，筛选该项目相关指标，经过评审后，对相关指标进行填报。
3）立项部门将收集的相关指标数据进行汇总和分析，依据检查评分细则得出检查结果，并将检查结果及时反馈给信息科技部门和项目相关各方。
常见的指标分类：过程质量、功能达成、持续服务。
通常作为立项部门或主管部门对项目做后评价，客观性与公正性会有一定折扣，如果是科技质量管理人员来做，权威性与专业性也会存在一定的片面，所以一些银行会让风险部门、审计部门等一些二三道防线部门负责项目的评价工作，或者请第三方公司来做。
那么数字化转型项目又会有什么特点？
是的，我也一直有同样的疑问。看了很多数字化转型相关的案例，包括：客户洞察能力的提升、大数据时代下的精准营销、基于各类技术手段实现新商业生态的打通、内部运营效率借助新技术的提升等等。
其实并不一定只有数字化的时代才能够实现这些场景，信息化时代也一样可以实现。那应该如何理解数字化？
我有一次参加数字化转型行业论坛中，印象最深刻的是，给服装行业提供科技服务的嘉宾说了一个例子。
这是一个典型的数字化转型例子，可以看出来，企业借助新技术创新了运营模式，提升了运营效率，优化了客户服务。同时在上游的供应链当中可以更为精准和及时的进行存货调配，让下游的消费者体验方面可以更加便捷、智能。
所以，数字化转型是什么，它是指通过数字技术应用，实现客户服务与内部运营的创新。
基于我们对中国区域银行在数字化转型方面的实践经验，总结出银行数字化转型的能力图解，分成了七大域，42个关键能力项。七大域包含：客户分析与应用、产品与服务、数字化渠道、生态合作、中台架构、技术创新、数据治理等。
银行数字化转型42个能力项
简单来说，银行数字化转型主要围绕四个方面来进行概括，即：客户与生态（对外）、敏捷与数据（对内）。
如同零售门店对客户进店全过程跟踪，银行也在不断探索，利用新技术和新应用不断增加客户触点，全方位参与到客户旅程中，增加与客户之间的粘性。
商业银行的生态场景合作已经从全国性头部平台，逐步转变为本地区域场景，在服务零售客户方面，可合作的场景包括：医院、餐饮、购物、教育、出行、购房、娱乐等。在服务企业客户方面，主要围绕生产场景、制造场景、贸易场景等，实现基于金融信息化的全链条输出。
以客户为中心的经营理念背后需要有较为高效的运营支撑体系，既要有小前端+大中台的企业级架构转变，也要有敏捷文化渗透，实现端到端的快速交付。在中台架构方面，可以结合自身特点，将可复用的应用、数据、技术等形成组件化，方便灵活调用。在DevOPS流水线方面，可以不断通过利用开源技术，提升自动化测试、自动化部署等能力，提升整体效率。
从传统的银行发展过程中，其实不难看出，原有以核心系统、信贷系统作为基础的业务应用外，逐步向客户洞察、精细化管理、精准营销等方面延伸，这些分析管理的基础，则是数据。中小银行普遍存在数据质量差、数据管控不规范的现象，需根据特色完善数据质量，并不断加强政府等三方机构合作，丰富数据来源，形成以数据驱动决策，高质量夯实数据基础。
银行启动数字化转型之后，不同的视角会关注不同的问题。
●高管：行长会关心数字化转型花的那么多钱，到底是不是真的产生价值，是否存在浪费和无效投入。
●业务：管理部门会关心是否能够支撑业务的开展，是否能够支撑管理与分析，是否满足监管报送的要求。
●科技：科技会关心内部的平台化建设是否有效，IT技术是否可复用，IT资产是否得到沉淀，人才队伍是否得到锻炼。
●风险：风险角度会关心科技风险是否有效防范，是否有控制和预防手段，风险管控是否到位。
数据：数据应用角度，会关心质量怎样，数据标准是否落地，如何通过数字化转型投入进一步加强数据质量体系。
对此，我们研究了一套可以对银行数字化转型项目的评价体系：SAIRD（赛尔德）模型。
SAIRD（赛尔德）模型
针对SAIRD模型的每一个维度，我们挑选了部分关键评价项，来进行分享交流。
战略目标：战略规划支撑情况、业务目标达成情况、生态体系布局情况、数字化客户管理情况、数字化渠道建设情况、数字化统一产品管理。
管理应用：系统功能实现情况、成本效益量化情况、业务科技融合情况、项目管理成果有效性、项目交付质量完整性、问题缺陷处理及时性。
IT创新：新技术的应用、DevOPS流水线、自动化工具建设、开源的应用、平台化的建设、中台架构的合理性。
IT风险：业务连续性管理、信息安全管理、运行与维护管理、外包风险管理、系统开发及测试风险管理、DevSecOps。
数据效能：数据治理体系有效性、数据质量与标准的满足度、对数仓及监管的支持性、数据全生命周期完整性、数据安全与隐私性、数据的价值与应用。
根据所评价项目的不同，模型所涉及的领域也会灵活调整和裁剪 ，与传统项目评价的不同之处是，评价维度更为全面，评价指标更为丰富，并增加新视角、新技术、新模式等，可以全方位赋能式的进行项目评价。
数字化转型项目与传统的项目评价类似，如果是行方自评价，可按照已有的流程发起，需要牵头人和被评价角色共同参与，与被评价单位的负责人沟通评价的目标，选择适合的指标，在评价周期内给出有效、合理的建议。
这里我也整理出了一份评价流程，可做参考。
某省农信社被评价项目列表如下：
某银行核心项目群在启动前，分别邀请了两家咨询公司做业务咨询和IT咨询，所产生的成果作为核心项目群启动的参照，在咨询成果中，提出了各类业务战略目标和IT战略目标。我是作为项目群外部审计角色，负责战略目标一致性检查工作，那么我们会结合咨询报告、立项申请、合同、需求等几个成果中进行分析，抽取提炼关键目标，并围绕目标所对应的系统上下文，进行穿透式分析，确定目标达成情况。下图为某子项目的目标分解：
其中大总账系统的需求梳理，提出建立多维度总账目标，因为这个目标需要关联多个外围系统，但并不是影响业务交易，所以在检查中，我们
第一步看该功能的数据完整性并不完整；
第二步通过数据库脚本查看各系统传递的历史交易数据，存在多外围系统传输数据错误的情况；
第三步查看相关外围系统的接口代码确定传输字段的默认值。
最终发现部分外围系统传输的默认值存在不合理现象，因此可以确定，多维度总账的目标实现存在偏离。
其实针对大多数银行，流水线并没有，甚至连流水线是什么都没有了解过。所以我们会结合银行自身已经存在的开发管控问题，进行问题追溯和原因分析，给出DevOPS相关的改进建议。
去年参与了一家资产规模在1000亿以下的某城商行，发现GIT分支管控缺乏规范，多次因为合并版本的问题，导致业务已经测试通过的功能，投放到生产上又出现错误。同时数据库代码也在变更环节多次出错，未能形成统一的数据库代码管控模式和工具的使用。
对此，我们给出了一些银行的管理实践，在分支管控方面，针对该银行遇到的常见问题，提供了代码分支管控的规范，在数据库代码管控方面，提供了一套基于FlyWay二次开发的工具，相应的建议得到科技领导的一致认可，并迅速开展内部推广。
IT风险是我们团队最为擅长的部分，涵盖了监管科技的八大领域。那么，在银行数字化转型项目评价中，IT风险更多围绕开发测试、信息安全、业务连续性、外包风险、运行与维护等五个方面，这里对部分领域进行简单的介绍。
在检查依据方面，我们主要是依据法律法规、行业标准、监管要求与提示等，同时也会对标业界的一些优秀实践、行业风险事件与场景，来有针对性的发现相关的问题，提供可改进和提升的点。
商业银行的IT架构本质上并没有绝对的好与坏，更多的要看适合程度。系统间交互常见有两种模式：联机和批量，对于已经投产上线的系统，很少会因为一些小的问题对架构进行较大调整，所以我们更多的是围绕已有架构，如何将架构规范和标准进行统一，避免系统间的调用发生错乱，造成生产事件。
在某银行做核心项目群评价时，发现支付系统调用的总账记账功能，会因为备注长度的字段超长原因造成转账失败，先后几次有系统调用该接口出现生产异常，造成多个客户近百万资金转账出错，这一类重复问题就引起了我们关注。了解后发现是第一个支付系统出现问题修改后，并没有及时通知到其他外围系统，因此，在架构管理里系统上下文关系缺乏沟通机制，统一标准发布广播机制是一个可改进的重点项。
一次项目评价相当于轻量级的咨询，这种轻量级的咨询，可以涵盖DevOPS敏捷开发、项目完整性评价、战略目标一致性评价、IT风险评价、数据治理评价等内容。
银行通常要做数字化转型，最容易见效的是工具使用，其次是流程模板的修订，最后是制度体系建立。那通过评价类项目的建设，可以自下而上逐层改进，可改进的体系包括：IT治理体系、项目管理、敏捷开发、信息安全、开发测试、业务连续性、运行维护等。
做数字化转型，离不开敏捷文化，数字化转型是生产力，敏捷则是生产关系。如果将敏捷文化进行深入贯彻，实现银行端到端的快速交付，那么DevOPS流水线则是重要能力体现。建立DevOPS流水线，必然需要配套大量的工具与平台，持续集成、持续部署的目标才有可能得到不断提升。
我们鼓励行方相关人员能够参与评价类或咨询类项目当中，以共同进步为目标，探讨发现当前存在的问题，分析问题的根本原因，帮助提升项目管理、需求管控、架构设计、开发测试、版本管理、质量管控等能力，解读监管和行业的规范要求等，将所做的成果和方法完全赋能给参与人员。