我们可以简单的把银行数据人分为两大类：技术数据人和业务数据人。

技术数据人又可分为几类，一类是所有和数据相关的系统开发岗位和运维岗位。

数据相关的系统既包括所有产生数据的业务系统，如核心系统、信贷系统、网银、手机银行等，也包括各类后端分析系统，报表系统以及存储和加工大量数据的系统，如数据平台、数据仓库、征信平台等。

这类技术数据人在数据人中处于核心地位，他们最了解源系统的表结构，只有他们能写出源系统的数据提取脚本，他们也最为忙碌，尤其是业务系统的相关技术数据人，平时主要负责系统的开发和运维工作，只有在下班后，继续处理数据提取的需求，编写业务系统的数据提取脚本。

另一类是数据中心的操作岗，这类数据人工作相对单纯，接收脚本、执行脚本、返回数据，他们平时的工作是监控系统的运行情况，在出现异常报警时按照运维手册排查问题，无法解决时上报问题并联系系统开发的同事协助解决。如今，很大一部分精力需要用来处理数据提取的需求。

还有一类越来越热门的数据分析师，通常是数学或统计学背景，擅长数据分析与建模，在获取到提取的生产数据后进行分析与建模，得到结论，从而指导业务决策。

随着数据提取需求的爆发式增长，一个新的岗位应运而生——数据需求岗。

大中型银行由于数据提取的需求实在太多，单独设立一个部门或团队来处理数据提取需求，其中就有一部分人专门负责对接业务部门的数据需求。

这个岗位需要充分理解业务需求，把业务需求转化为技术语言，与开发岗沟通，同时还需要验证操作岗取回来的数据是否符合业务需求，以及数据分析师的建模结论是否符合业务预期。

其他还有很多技术数据人，数量不大，甚至没有专门的岗位，但是通常也负责数据相关的重要工作，如数据架构师（通常由系统架构师兼任），数据产品经理，数据管理、治理及标准管理的相关岗位，数据测试、质量管理相关的岗位，数据采集、外部数据采购相关的岗位，数据安全相关的岗位等等。

为了统一管理，有的银行把相关职能的岗位集中成立了单独的部门，如数据需求、分析、架构、提取等职能的岗位，集中成立数据实验室或大数据中心，专门负责处理各类数据需求；数据管理、治理及标准管理和质量管理相关的岗位，成立数据治理部，推进全行数据治理相关标准的制定、落地和监控；数据采集、测试、安全相关的岗位，成立数据采购部门，扎口全行内外部数据采集的需求。

业务数据人，通常分散在各业务部门中，目前没有把业务数据人集中形成新部门的做法，因为不同业务条线的需求大相径庭，难以扎口管理。

通常在业务经营分析、监管现场检查、阶段性汇报、新产品可行性分析等环节，甚至是领导提了一句想看某个指标的情况下，需要进行临时性的数据提取需求，或固化为报表需求，由业务数据人编写数据提取或报表需求。

业务数据人通常是业务背景出身，不懂技术，最常用的工具是Excel，因此又被称为“表哥”、“表姐”，在拿到技术部门提取的数据后，通过Excel进行基础的分析，计算一些简单的指标。

业务数据人和技术数据人这个群体，说大不大，说小也不小，他们并非银行原来固有的岗位，而是随着银行对于数据应用和决策的愈发重视而逐步形成的岗位，大部分数据人都有自己的本职工作，在繁忙的业务或开发间隙，兼任数据提取和分析的工作。

可能这么说大家感觉还是比较抽象，到底数据人是在什么情况下需要完成什么样的工作呢？接下来我们就具体看看数据人的主战场在哪里，以及数据人们都从事着怎样的工作。

大家都认为，只要入了数据这行，干上和数据有关的工作，必然是高精尖、高大上的，大数据与人工智能左膀右臂，深度学习、知识图谱信手拈来。

理想很丰满，现实很骨感。

数据分析的工作看似高大上，实则又苦又累，80%的时间花在需求讨论、提取数据、数据清洗、数据整合、缺失值处理以及特征工程部分，只有20%的时间是用来建立模型和评估模型。

外行理解的数据分析，其实类似于Kaggle这种数据建模竞赛的过程，这里的数据集基本都是已经准备好的，需求也很明确，整个数据分析的过程可以简化为从需求讨论直接跳到特征工程。

而实践中，大多数数据达不到数据分析的要求和标准。因为数据都来自于业务系统，而业务系统的建设是按需的，根据市场变化、客户变化等等按需提出并建设，建设的时候很大概率并未考虑后期数据分析的便利性，以及与其他系统的数据标准、规范等是否一致。

在银行，这种现象更为明显，国有大行、股份制和民营银行，科技力量较强，可能会有部分业务系统由行内的开发团队实施，自主实施的业务系统，相对比较容易控制其数据标准。

而其他大多数的银行和金融机构，则缺乏自主建设业务系统的能力，绝大多数业务系统依赖于采购外部供应商的成熟产品。由于每家供应商擅长的领域不同，提供的业务产品自然不尽相同，因此银行内通常的情况是多家供应商的产品系统并存。

在银行没有严格的数据标准和规范的情况下，各家供应商必然是按照各自的标准版本在银行内部署，而各家供应商的数据标准和规范必然是千差万别。

即使银行建立了自己的数据标准和规范，由于通常涉及底层改造，改造难度较大，并且改造后上线也存在一定风险，加上绝大多数银行的业务部门相比科技部门更为强势，对于业务系统的上线时间都有明确要求，多种因素作用下，通常是科技部门妥协，容忍各类标准的供应商产品上线。

这就导致银行内部的数据标准和格式成了一锅大杂烩。

而数据分析，通常是要提取多个业务系统的数据进行处理，加工整合后进行分析的，这就导致数据提取的过程需要面对分散在各处的多源异构数据，再加上数据质量参差不齐，使得数据提取和清洗的过程异常漫长。

后方的需求越来越多，而且越来越急，前方的数据泥潭深不可测，导致的后果，就是技术数据人们满心欢喜的进入数据领域，绝大多数人被分配到的任务80%以上都是数据提取，另外不到20%的任务是沟通数据提取的需求，因为这部分需要的人实在太多了，花的时间实在太长了。

只有极少数的人，从事的是数据分析和建模的工作，并且他们的工作里，大部分的时间也是在处理数据。

最后的建立模型和评估，是皇冠上的珍珠，固然璀璨夺目，但是没有前期工作完成的皇冠底座，珍珠也难以独自闪耀。

除了数据科学的自身特点导致数据提取异常缓慢之外，银行的组织架构也是一个不可忽视的因素。

体量越大的银行，分工越细，业务的数据需求提出来以后，有人专门对接需求进行分析，有人专门编写脚本，有人专门负责执行，有人负责处理执行结果反馈给业务部门。

越贴近数据的人，距离业务需求反而越远，最初的需求经过层层转述，信息逐步衰减，误差逐步增大，导致最后的结果通常不能满足业务需要。

再加上银行内部各扫门前雪，宁可无功，但求无过等“文化”的影响，使得数据提取这种跨多个部门、经过多个节点的复杂流程变得更加不可控。

看完技术数据人的苦衷，业务数据人们按捺不住了。

在银行，通常业务部门比较强势，因为业务部门是利润中心，而科技部门是成本中心（现在的数据部门通常划归到科技部门），能赚钱的嗓门大，可同时压力也大。

技术数据人说，你们需求多我们能理解了，但是为什么经常都要得这么急呢？业务数据人通常会回答：领导要得急呀。

领导为什么总是要得很急？难道都是拍脑袋，今天想要一个数据，明天想要另一个数据，而且都需要马上看到，这样的需求谁满足得了。

其实不是领导拍脑袋，而是市场、客户和监管的变化太快。

市场和客户的变化不难理解，特别是移动互联网时代，互联网巨头们瓜分市场，抢夺客户的速度与原来银行间的竞争相比，不可同日而语。

而银行作为强监管机构，对于监管的要求永远是排在第一优先级的，1104报表、二三类账户、资管新规……

而且监管经常周五临下班出新规，搞得大家要周末加班学习监管最新指示。

外部有了变化，第一冲击的是直接对客的部门，包括网点、客服等，第二冲击是业务部门，最后才会传导到科技部门，因此科技部门不理解业务的急迫是情有可原的。

领导要得急，科技反应慢，为难的就是业务部门的基层员工，在数据领域就是表哥表姐们。

这几个场景里，有很多业务数据人的痛点，比如历史数据的管理，数出多门的问题，手工填报的准确性，共性需求的提炼，多数据源的打通等等。

大部分业务数据人习惯用Excel来处理数据。虽然Excel很强大，可以应付绝大多数需求，但是在历史数据的管理、手工填报准确性以及多数据源打通等环节仍然力不从心。

上次看到一个段子，说所有数字化转型的需求，最后都会收敛为两个功能：导入Excel和导出Excel。听起来很可笑，但是在很多地方确实是现实。

以上就是技术数据人和业务数据人的生存现状。

看起来大家都有痛点，难道就没办法解决了吗？

银行的大多数问题都是组织架构的问题，具体到数据领域，目前来看，主要有三种数据团队组织架构：

顶级数据团队建设全景报告

大多数银行仍采用集中式架构，技术数据人专职在数据团队，业务数据人基本还是兼职。

这种模式下，存在技术数据人远离一线需求、沟通成本高、资源分配不均等劣势。

互联网公司普遍采用分散式植入各部门的数据团队架构，但也存在信息孤岛、数据标准不统一、重复“造轮子”等缺点。

因此，目前一些领先银行已经开始采用混合式组织架构，存在独立的数据团队，在各业务部门也有专职的数据人，他们双线考核，同时汇报给业务条线和数据团队。

改变组织架构以后，大家看问题的角度不同，立场不同，目标一致，很多问题就迎刃而解了。

当然，依然还有很多痛点没法通过组织架构的调整解决，这里作者先只是抛个砖，大家如果有好的想法，也欢迎在评论区讨论。