是时候刷新数据部门在券商的存在感了

在很多企业中，数据部门的工作往往局限于开发报表和提供数据，但这些工作往往难以明确地展示如何通过数据为公司业务带来更多利润，这使得数据团队在企业中的存在感低，工作价值量化难度大。

然而，从时代背景来看，数据的重要性日益提升。比如，今年以来，国家已经将数据列为五大生产要素之一。换言之，时代赋予数据的意义与大多数企业数据团队的工作价值之间存在巨大的差距。那么，数据部门应该如何打破现状，如何通过数据来推动业务的发展，让数据成为业务增长的新引擎？

在日前举行的 FCon 全球金融科技大会上，中泰证券数据应用部门经理张前园介绍了其如何通过战略、业务和技术三个层面的关键支点，释放数据在业务中的最大效能：战略上，数据战略需与业务紧密结合，提升至业务争夺的高点；业务层面，通过考核机制确保数据有效应用，作为公司信息传递的主线；技术层面，面对业务复杂性，需优化考核系统，实现政策快速调整。

内容亮点

• 数据工作的现状与时代赋予的愿景差距大，如何弥合沟壑？

• 业务复杂度高、工作量大，单纯的资源投入为什么会成为新的问题；

• 如何通过领域建模作为配置的载体，将复杂的业务行为抽象为可配置、可量化的模型；

• 围绕考核还有哪些业务可以融合？下一个支点在哪？

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）：

宏观破局——数据部门的困境

数据部门在企业中面临的主要问题有两个方面：一是在整个公司中存在感非常低，二是工作难以体现业务价值。数据部门的工作往往局限于开发报表和提供数据，但这些工作的价值很难量化，难以明确地展示如何通过数据为公司业务带来更多利润。

在券商行业，数据部门往往不是独立存在的，而是隶属于研发部门，作为研发的支撑，而非直接支撑业务。这种组织关系使得数据部门在整个软件开发流程中处于末端，远离业务前线。但事实上，数据部门需要更接近服务对象，更接近我们真正要解决的问题。

在战争论中，有一个观点是“战略争夺点上移”，也就是所谓的升维。如果我们想要解决数据部门在宏观层面存在的问题，即存在感偏低和业务价值不明显，就需要进行战略争夺点上移，即靠近业务，融入业务。

中观——赋能的迷思

因此，我们需要重新思考数据部门的角色和定位。传统结构下，数据部门似乎难以找到自己的定位。例如，在财富管理业务、银行的零售业务或保险的各个险种业务中，都有相应的研发部门提供支持。那么，数据部门的角色是什么呢？

通过对我们公司的数据工作进行统计分析发现，其中 60% 的工作是数据提取需求，包括监管需求和年度会议等一次性的数据提取需求，另外 30% 的工作是报表需求，而剩下的 10% 则是内容推荐，比如人货匹配，这对于数据部门而言算是较为“高端”的工作了，涉及到将什么样的金融产品推荐给什么样的人。当然，在如今的时代背景下，企业对数据的要求远远不止这些。

今年以来，国家已经将数据列为五大生产要素之一。然而，从部门的中观视角来看，时代赋予数据的意义与我们目前的工作内容之间存在巨大的差距。如果我们想要真正发挥数据的价值，提升数据部门的存在感，仅仅做目前的工作是远远不够的。我们需要思考，数据部门应该做什么，才能打破现状，如何通过数据来推动业务的发展，让数据成为业务增长的新引擎。

在探索如何提升数据部门效能的过程中，我找到了一本非常重要的书——明斯伯格的《卓有成效的组织》。这本书启发了我思考公司的组织结构。如果我们抽象地看，几乎所有公司的组织结构都可以用下面这个拓扑图来表示。

在这张图中，最高层是管理层，比如所谓的战略规划部、财务部等等；中间层是业务管理部门，比如财富管理部、零售业务部、金融产品部、投资管理部等；运营核心是各个子公司，在券商中，这些子公司构成了公司的运营基础；技术结构，也就是金融科技（包括数据部门），而另一侧的支持人员，主要就是后勤等行政保障。

可以看到，在原先的组织结构图中，并没有明确体现出考核的作用。考核实际上是公司内部上情下达的核心机制。因此，我们在思考数据赋能时，抽象出了一个“三横一纵”的模型：

1. 战略层面重视经营目标，高层会下达经营目标，这是他们最关心的；

2. 业务管理部门重视运营，他们需要将经营指标拆解成具体的业务执行工作和策略；

3. 运营核心重视营销，例如金融行业的券商和保险公司每年年初的“开门红”活动；

4. 考核是连接这三个层面的逻辑主线，它确保了公司的战略目标能够被有效地传达和执行。

微观支点——多快好省的技术是否存在

也就是说，我们确定了微观支点是，将考核作为数据赋能的切入点。那么，接下来就需要探索是否存在一种技术能够高效地实现考核系统。换言之，我们面临的新问题是：多快好省的技术是否存在？如何找到这样的技术支点？

总结考核系统现状，主要有以下四个问题：

第一，系统的建设主要依赖于存储过程等编程语言，并且由于考核数据量巨大，这些工作通常在大数据平台上进行，如 Spark 或 SQL；

第二，考核政策调整周期长，每年年初的考核政策调整需要三四个月甚至更长的时间来实现，这严重影响了公司业务的灵活性和响应速度；

第三，指标二义性问题，由于考核系统已经运行了十年，存在大量的指标二义性问题。这对业务人员来说是一个挑战，因为他们需要明确数据指标的具体含义，这可能是数据治理需要解决的问题；

第四，跑批时间长，难以实现每日绩效，在五六年前，方正证券已经实现了 T-1 日的绩效计算，而在很多保险公司也已经形成了开单即见提成的模式。但在券商和其他公司中，由于跑批时间长，通常只能实现每月绩效的计算。而在我们公司，之前的跑批时间需要 6 个多小时。

如果我们将考核视为一项业务，那么考核的业务对象自然就是人员序列。在券商行业，包括理财经理、客户经理、机构业务经理以及公募基金投顾专员等。目前我们公司有 7 个不同的人员考核序列。然而，如果我们仅仅将人员序列作为考核的业务对象，我们又会面临几个问题：

第一，考核指标重复：不同的人员序列往往需要考核相同的指标，例如理财经理和客户经理都需要考核客户的金融产品保有量；

第二，新增考核序列导致资源浪费： 每当新增一个考核人员序列时，就相当于新增了一棵考核指标树，而之前积累的考核指标难以复用。例如，今年新增的公募基金投顾专员序列，就需要重新构建考核指标体系；

第三，跑批时间居高不下：随着考核序列的增加，跑批时间会越来越长。因为每个指标都需要单独处理，而这些指标在不同的考核序列中往往是重复的，导致无法复用之前的跑批结果。

除此之外，传统考核系统的另一个痛点是，在每年的开门红活动中，考核政策调整需要很长时间。对此，我们的第一反应通常是增加资源，比如增加人手。但这种做法会引发新的问题。根据康威定律，如果不同人开发不同的人员序列，或者新的需求由不同的资源开发，很容易产生指标二义性问题。此外，不同人的代码质量是不可控的，而且随着人员增加，跑批时间会越来越长。并且，程序员通常不敢修改多年前别人写的代码，这会增加系统的复杂性和不稳定性。

那么，如何实现考核政策的快速准确调整？这涉及到《改变——问题形成和解决的原则》一书中提到的“第二序改变”概念。

第一序改变是机械式的改变，比如缺人就加人，跑得慢就加强锻炼。但这种改变并不能解决根本问题，考核政策每年都在变化，如果每年开门红活动三个月后才实现，甚至更长，那么考核指挥棒的作用就无从谈起。

对此，我们需要从元数据的角度思考，即数据的数据，比如技术元数据，来重新审视考核系统。我们最终将考核对象从人员序列转变为员工的业务行为。这种转变意味着我们将考核的核心聚焦于业务行为本身，而不再局限于人员分类。

在这个模型中，任何业务行为都可以被分解为主体、客体和动作。例如，当员工向客户销售金融产品时，行为就是金融产品销售。对于券商来说，除了个人客户，公司也可以是客体，比如在 IPO、发债或发券的过程中，主体可能是投行的某个团队。此外，券商中的研究所可能会向其他业务部门提供研究报告并收取费用，这也构成了一种业务行为。

通过将考核行为抽象成主体、客体和动作的模型，我们可以将券商内所有的业务行为纳入考核体系。这不仅包括金融产品销售、金融咨询，还包括投研分析等。

模型设计以及系统效果

目前，我们的考核系统已经上线，可以看一下具体的实现效果。系统中的矩阵展示了我们公司不同业务条线的考核管理细则。这些细则涵盖了经济条线、佣金管理、信用业务佣金管理、金融产品考核激励优化方案以及增值工具的奖励管理细则。

在最外层，我们根据不同的人员序列进行了分类，首先是理财经理和客户经理的考核管理办法，这两个岗位非常相似。其次是机构业务经理的考核管理办法，然后是公募基金投顾考核管理办法，以及理财顾问考核管理办法。这些岗位反映了我们券商的实际工作角色。

值得注意的是，作为理财经理，你需要同时适用于四个不同的业务条线的考核细则。这实际上是一个笛卡尔积的复杂性问题，因为理财经理，不仅涉及经济业务，还包括信用业务、金融产品以及增值工具，比如为客户提供的资讯和研究报告等。

目前我们的考核系统整体模型大致分为四个主要部分：

1. 服务行为与服务指标： 这部分包含一个服务行为认证引擎，它负责识别服务关系。例如，经济关系和两融关系是分开处理的。这里会有一个行为关系的匹配，涉及到参与方，包括主体和客体。

2. 指标和参数模块： 任何原始数据都会有一个服务行为认定策略。匹配成功后，会进行参数和指标的配置。指标主要分为三种类型：服务行为指标、结算账户汇总指标、人员行为汇总指标。在具体到员工层面，不同的员工会有不同的结算账户，一个员工可能拥有多个结算账户。

3. 绩效模型： 绩效模型考虑的是公司每年的业务倾向和重点。例如，某些业务的提成可能在前几年较高，随后逐渐降低。绩效模型会先配置考核项，然后形成不同的考核方案，比如理财经理和客户经理的考核方案就不一样。此外，绩效模型还会适配不同级别的人员序列，并基于考核方案产生月度考核结果以及不同级别的考核结果。

4. 提成模型： 提成与绩效是分开的两个模型。提成模型会配置提成项，并根据不同的提成项组合生成提成方案。这个方案适用于不同的提成人员序列，并最终产生提成结果。

整个系统的结构设计是将业务数据通过大数据技术（ETL 技术）导入系统后，首先进行服务行为的认定，这是系统的核心部分，它负责识别和确认业务行为的主体、客体和动作。一旦服务行为被认定，系统将生成与这些行为相关的创收数据。

这些数据将用于计算不同的提成和考核指标。提成和考核的计算是基于业务行为产生的收入和预设的规则来进行的。此外，系统还包含一个前端考核系统功能，它作为用户与系统交互的界面。用户可以通过这个前端功能查看考核结果、提成情况以及其他相关信息。

据统计，我们公司目前拥有超过一千万名客户和 6,500 个员工结算账户，涵盖 7 个人员序列和 14 个业务方向。目前，我们的系统跑批时间仅为 40 分钟，这是通过两个实例实现的，如果增加更多实例，跑批时间还可以线性减少。因为我们的跑批过程将数据分散在两个实例中处理，所以 40 分钟的跑批时间对我们来说已经非常充足。

此外，系统已经能够生产 1,100 个不同的考核指标。通过建立全可配置的业务考核系统，不仅解决了考核业务的复杂性问题，还满足了各种考核数据需求，可以轻松调整业务规则。例如，我们可以设定当信用交易的成本超过 100 时，取消相关的信用交易提成。这种调整在系统中的实现非常迅速，只需几分钟就可以完成，而不再需要修改存储过程或 SQL 代码来调整考核规则。

未来展望

从目前来看，我们已经成功地将业务考核作为数据赋能的第一个方向，并且找到了有效的微观杠杆来实现它。围绕业务考核，我们实际上可以拓展到许多不同的应用场景，例如：

1. 人人绩效：通过考核系统来激发员工的效能。

2. 效能激发：通过考核结果来挖掘员工的潜能。

3. 运营督导：监控营业部的业务表现，确保运营效率。

4. 潜能挖掘：发现并培养员工的未开发能力。

考核与营销紧密相关，我们可以通过考核系统来提升员工绩效和技能。例如，我们可以参考中信证券的 KMS 系统，将营业部视作金融产品来运营，通过实时监控关键指标来评估其表现。

整个思路分为三个层面：

1. 宏观支点（核心）： 采取的战略是争夺点上移，这一理念源自《战争论》。解决的是数据部门存在感低和无法体现业务价值的问题。

2. 中观支点（突破）： 当我们深入到部门层面时，我们面临的挑战是如何找到赋能的方向。

3. 微观支点（技术支撑）： 在系统层面，我们需要找到一种技术来解决传统实现方式中频繁出现的问题。我选择的是面向过程的设计思路，或者说是面向业务行为的方法。

在思考未来的方向时，我们重新审视了《卓有成效的组织》中的模型。在这个模型中，战略高层关注经营、中间线关注运营、运营核心关注营销，而考核则是上情下达的关键。那么，下一个支点在哪里呢？

首先，数据部门的工作往往是跨部门的。传统的经营分析系统或大屏通常由数据部门负责，这是因为经营本身就是跨部门的活动。根据康威定律，不同的部门垂直对应研发部门，那么数据部门下一个赋能的方向在哪里？

目前，我们认为下一个支点可能是在营销领域，特别是在人货匹配方面。我们需要考虑如何跨越传统的人货匹配方式，以及数据部门如何能够将所有业务执行部门串联起来。这是我们的优势所在。

未来，数据部门在营销领域的下一个方向可能需要结合大模型的能力。因为大模型处理的是概率性问题，而分析客户本身就是一个概率性的问题。客户的选择往往不是完全理性的，他们可能基于感性来决定某个产品是否适合自己。因此，我们也将探索和关注如何利用大模型来更好地理解客户需求，并提供更贴合他们需求的服务。同时，我也在思考运营领域的可能性，因为经营本身就与数据部门紧密相关，经营分析系统是数据部门经常开发的系统。

嘉宾介绍

张前园，中泰证券数据应用部门经理。2020 年底起加入中泰证券，积累了深厚的数据治理与应用经验。入职初期曾担任数据治理部门经理，现任数据应用部门经理，对数据治理、数据产品及数据业务赋能领域有着深入而独到的见解。在业务价值的追求上，创造性地从经济分析、绩效考核及营销三个维度出发，为公司经营管理、业务管理以及业务执行部门量身定制了精准的数据赋能方案，极大地提升了数据赋能的实效性，进一步凸显了数据的核心价值。