如何打造业务系统的数据生产力

我们要的不是数据记录，而是能够产生业务价值的数据记录；

我们要的不是数据看板，而是能够产生业务价值的数据看板；

我们要的不是数据中台，而是能够产生业务价值的数据中台；

我们要的不是数据闭环，而是能够产生业务价值的数据闭环；

……

为了传达文章的核心观点，我将不再啰嗦各种引言各种背景，而是更加开门见山地叙述我想表达的内容。

本文以一个业务系统开发负责人的视角来叙述，所以优先采用开发视角，同时也会采用产品、数据、业务人员的视角。

杭研天问老师写的《从数据中台到全链路数据生产力》里，提到了数据生产力的概念。的确，作为严选的业务系统开发人员，也总会思考如何通过数据帮助业务发展，即如何建设业务系统的数据生产力。但是在这个过程中，其实遇到了不少的问题。我们希望能够建设业务系统的数据闭环，即数据采集、加工和分析，并通过分析结果指引业务发展。但这方面最终产生了多少业务价值，投入产出比如何，往往并不容易说清楚。甚至出现过辛辛苦苦埋点收集数据，最终的数据看板也几乎无人关注的问题。

总结来说：我们要的不是数据记录，而是能够产生业务价值的数据记录；我们要的不是数据看板，而是能够产生业务价值的数据看板；我们要的不是数据中台，而是能够产生业务价值的数据中台；我们要的不是数据闭环，而是能够产生业务价值的数据闭环……

这篇文章是想要讨论，打造业务系统的数据生产力，应该采用什么方法和行动路径，才会尽量不走弯路少掉坑。

即使没有足够的系统支持，业务在最初的实践中依然会形成数据生产力闭环，如下图所示：

在这个阶段：

• 业务执行可能只是部分线上甚至完全线下的

• 数据收集可能没有系统支持，数据可能散落在邮件中、Excel表格中等

• 数据分析可能采用“非常原始”的方式，即直接在Excel里计算

但需要说明的是，即使各个环节都显得简陋，但这个数据生产力闭环依然形成了。数据分析的结果可以指导下一轮的业务执行，进而可以不断优化业务执行链路。

随着系统化建设的进行，这个闭环链路的各个环节都变得专业化，数据之间的流动更加顺畅，如下图所示：

可以看到，整个“业务执行→数据收集→数据分析→结果反馈”链路上各个节点都变得更加强大，数据处理的能力也变得更强。但这里的核心始终是，有一个数据生产力的闭环，能够围绕着业务优化进行数据收集、分析等工作。一旦这个闭环被打破，不管收集分析多少数据，生产多少看板，都只是徒劳。

可偏偏现实中，我们一不小心就会去干这种，闭环还不清晰，却已经在拼命收集数据分析数据的事。

上文已知，要数据真正发挥价值，必须形成业务数据闭环。那么，作为技术开发团队，在承接业务侧的数据需求时，应该做些什么来防止开发资源浪费呢？

3.1 先线下，再线上

所谓“线下”，指的是业务同学进行的手工数据分析（基于Excel），或者业务同学和数据分析师一起进行的数据分析（基于数仓和SparkSQL）。线下分析的特点是灵活好调整，但是相对耗时耗力。线下分析环节主要是由业务和数据分析师负责推进。

所谓“线上”，指的是基于大数据任务或者业务系统实现的数据分析逻辑。线上分析的特点是高效自动化，但是调整会比较复杂（涉及到测试、联调和上线等）。线上分析主要由产品和开发负责推进。

基于线下线上的特点，可以得出以下结论：对于线下比较常见的数据分析需求，如果需求明确，流程相对固化，就有了线上化的需求，这可以帮助业务侧提升效率。更重要的是，当我们要对一个数据分析需求进行线上化的时候，应该首先明确这个需求已经完成了线下的“数据生产力闭环”。这个过程如下图所示：

这里的一个可能的“坑”是，有时产技团队接到的数据需求，其实并没有在线下完成闭环，这时就需要非常小心了。仅仅线上化本身，是无法实现数据价值的，即使数据线上化，依然无法完成业务侧的生产力闭环。

有一个特别的判断标准：在数据收集-分析链路还未线上化时，如果业务依然“不辞辛苦”地获取数据、分析数据，那大概率在将收集-分析链路线上化之后，很有可能就是有价值的。当然，实际工作往往有很多中间地带，所以我们需要有一些思考工具，来对数据需求进行分析。

3.2 数据需求分析

举一个例子：

我们去医院看病的时候，医生会先问我们一些基本情况，哪儿不舒服。然后根据我们反馈的信息，让我们去检查化验一些生理指标，如验血、拍片等等。最后根据检查化验的结果，再给我们诊断，或者提出下一步更详细的检查建议。

但如果医生一开始什么都不了解，便先让我们去做详尽的检查：身高体重，验血验尿，X光B超心电图等等，一大圈折腾下来，才发觉我们只是得了普通的感冒，回家多喝水多休息就好了。

这就是没有从需求出发的数据收集和分析。

因此当业务侧提出希望将某些数据进行线上化，并对某些数据进行分析，甚至清楚地给出了具体的数据分析逻辑时，我们首先应该了解的是，业务侧需要解决的问题是什么？

业务侧需要解决的问题不同，我们选择实现的方式也不同。有些简单的需求，可能只需要协助业务方取数即可完成；而有些复杂的需求，可能需要更加系统化的实现方式，不是简单的把某些数据线上化就可以实现。

因此数据需求分析的第一步是：要求业务方完整的描述业务的需求，帮助完成 “业务执行→数据收集→数据分析” 闭环。

说明：这里说的“要求业务方完整描述……”，在实际中，产技团队也应该更进一步，和业务侧一起梳理需求。所以