第3章 理解业务

在0.3.2节中已经知道，好的数据分析师基本技能第一条就是“懂业务”。懂业务会增强对数据的敏感，在拿到数据后能够有自己的级别判断，不仅明白这个数字代表什么意义，还知道数字是高了还是低了，有没有出现异常值，以及增长是来源于行业大势好转还是公司产品的竞争优势等。

本章讨论对于一个原来没有接触过的新行业的新业务系统切入的方法，当然首先是需要有一定的IT行业其他业务系统的工作经验，包括业务和技术两方面的积累，那么在这种情况下如何快速地切入一个新的业务系统，就需要注意相关的方式和方法方面的问题。

3.1 全局了解——业务模型

接触一个全新的业务系统，首先要搞清楚这个业务系统主要是支撑什么样的业务?而对于支撑的业务本身又有两个核心内容，即核心的业务流程是如何的?核心的业务对象模型是如何的?在了解清楚后就可以继续了解这个业务系统大致会有哪些核心的业务功能模块，业务模块之间的相互关系是如何的?以及如何衔接的?

有时候了解到这个层面可能还不够，还需要了解这个业务系统可能是支撑端到端业务流程或共享业务数据的一部分，那么还需要了解到这个业务系统或支撑的业务在端到端流程中所处的位置，该业务系统和上游业务、下游业务的关系，相互间的协同和接口。

业务系统支撑了什么样的业务?存储了哪些核心业务对象和数据?这是对一个业务模型最基础的全局理解。

3.2 动态了解——流程模型

在对业务模型有了一个全局的理解后，需要开始进一步考虑流程模型方面的内容。注意在这里指的流程模型不是指工作流或人工审批流模型，而是指业务流程模型。或者说了解业务系统本身在分析设计中所涉及的业务建模方面的内容。

一个业务流程模型需要解决的问题是，一个业务系统为何会存在这些业务模块，这些业务模块之间是如何进行协同来支撑业务流程的。任何业务模块都会有输入和输出，了解清楚业务模块的输入输出后就能够比较清楚业务模块之间是如何串接和集成来支撑上层核心业务的。

如果一个业务系统按SOA思想来建设，那么可能会看到有哪些上层的核心业务模块，核心的领域服务层和底层的数据模型层，核心的业务模块本身是如何调用核心领域服务来进行协同和衔接的。只有清楚了业务流程才可能理解清楚业务模块之间的协同和集成关系，否则将看到的是孤立的业务模块，业务模块和业务流程之间出现断点而无法真正清楚业务模块间如何协同来支撑业务的。

如果一个业务系统本身是流程型的业务系统，这些流程又大量以审批流为主，那么即使审批流定义再复杂，整个业务系统本身也是简单的，因为不存在上面所说的大量业务模块间协同情况。

3.3 静态了解——数据模型

一个业务系统的复杂往往体现在两个方面，一方面是本身业务模块间的协同和交互复杂，另一方面是底层的数据模型和关系复杂。在解决了第一个层面的动态分析问题后，就需要开始考虑第二个层面的数据模型。

任何业务流程，模块间动态的协同最终都将持久化到数据库中，成为数据库中的数据表和数据表之间的关联依赖关系、映射关系。业务系统在前面谈到过或者是以流程为中心的业务系统，或者是以数据为中心的业务系统，对于以数据为核心的业务系统必须理解底层的数据模型。这种数据模型的理解首先是要理解元模型结构，这种结构不是简单的单个数据对象，而是多个数据对象之间的关联关系、映射关系、层次关系等。正是由于数据之间有这些关系，而形成了一个复杂的数据网络。

对于数据模型的理解可从以下几个方面考虑：一种是单对象的结构，包括主从、层次等各种结构；然后才是对象和对象之间的关联依赖结构，如一对多、多对多结构等；对于较为复杂的业务系统，可能还会看到为了保证底层数据模型的可扩展性和灵活性，往往在数据模型层会根据面向对象的思路做进一步的抽象，那么在这种情况下还必须将面向对象的对象模型和面向结构的数据库模型共同来参考理解，以分析和了解清楚最终数据存储的方式、数据存储后最终呈现的方式。

3.4 动静结合——关键业务分析

对于新切入一个新的业务系统，如果能够理解到这一步，基本就对一个业务系统有比较全面的理解和认识。首先是了解业务流程和模块间协同，然后是了解数据模型和数据间关系，最后则是真正地根据核心业务来进一步理解在流程协同过程中最终数据的落地存储。由动态的业务流程驱动的最终静态数据的存储落地和关系的建立。只有这样流程和数据的分析最终才会融合为一个整体。

对于关键业务的分析将会看到，这些关键业务中需要理解清楚究竟涉及哪些模块的协同，在模块的协同过程中最终会产生哪些核心的数据，或者说会更改哪些核心数据的状态或数据间的关系。真正需要关注的往往不是单个数据对象中某些数据熟悉的变更和修改，而更多的是关注核心业务流程驱动下，数据对象状态的修改、数据对象间关联关系的修改、数据间映射模型的调整等。

对于一个完整的业务系统，按道理只要有基本的数据对象维护功能即可，但是要真正能够支撑业务，由于数据对象中的关键属性、关键依赖关系的变更，最终都是由上层的业务模块和流程来支撑的，那么就必须要真正地理解所有的核心业务流程最终对底层数据模型造成的影响。

3.5 数据业务化

数据分析必须非常注重相关的业务实践，这已经达成共识。但是，怎样才能把“业务实践”带入到数据分析过程中（数据业务化），却没有统一的认识。其中有一种看法就是：参加数据建模比赛（如Kaggle）。毋庸置疑，数据建模比赛是一个非常优秀的平台，备受全球数据科学爱好者追捧，这些比赛所使用的数据都是非常棒的真实业务数据，有非常具体的实际应用价值，对数据分析技能培养帮助很多，但是，这不是“数据业务化”!

所谓“数据业务化”是要在真实的业务环境中，让数据产生可被产品化的商业价值。从这个角度看，“数据业务化”至少有三个关键环节：数据业务定义、数据分析与建模、数据业务实施。

（1）数据业务定义

在一个真实的企业环境中，数据并不是人们关心的根本。人们关心的根本所在是业务。因为，业务是企业之所以存在的根本原因。如果一个企业核心业务的发展，不需要数据助力，那就没人关心数据分析。事实上，这样的企业非常多，甚至是大多数。一个企业之所以关心数据分析建模，根本原因一定是因为：数据可以助力核心业务发展。

那么，在这个前提下，一个数据科学家来到一个企业，没有人会告诉你该分析什么数据，更不会有人告诉你应该如何分析。相反，老板会告诉你他关心什么业务问题。接下来需要把这个业务问题定义为一个数据可分析问题。如果不能把业务问题定义为数据可分析问题，那么数据就无法助力。如果可以，接下来就是数据分析与建模问题。

首先分享一个有趣的故事：一个做货车车联网的朋友提到一个问题，说他们有一个物流客户非常认可他们的数据价值，希望通过货车车联网数据帮助手下货车司机改进驾驶行为。

这是一个非常典型的业务问题。但是，这个业务问题应该如何成定义成为一个数据可分析问题呢?首当其冲的挑战是：如何定义一个货车司机的驾驶行为什么叫作“好”，什么叫作“坏”?如果没有一个清晰定义的标准，后续的数据分析就会缺乏一个业务认可的因变量Y。在缺乏因变量Y的前提下做的任何数据分析，都不可避免地需要太多主观介入，进而很容易产生纠纷。这么复杂的一个过程，没有唯一正确答案，这恐怕是任何数据建模比赛都无法模拟的。

（2）数据分析与建模

一旦业务问题被定义为数据可分析问题，它的核心业务诉求就清晰明了了，这构成了因变量Y。此外，相关的业务知识被头脑风暴，就构成了解释性变量X。从Y、X出发，人们可以尝试各种经典的回归分析模型、机器学习模型。而这一步因为Y和X都定义清晰了，所以非常适合做各种数据建模比赛。

（3）数据业务实施

数据分析与建模完成了，接下来，需要把这些成果转化成为一个在商业环境中可以被实施的产品。这一步非常艰难，各种数据科学比赛经常喜欢考虑，如个性化推荐类型的预测问题。此类问题的业务实施方案是清晰定义的，经验积累非常充足。

但是，事实上在更多的业务场景中，即使模型做得很好，但是最后如何同业务结合，变成可执行的产品，是非常不清晰的，极具挑战。这里涉及企业资源、政策法规等众多问题。例如，国外的业务经验表明，基于车联网数据的UBI保险产品是一个不错的商业模型。但是，在我国由于有不同的政策环境、市场环境和消费者习惯，因此，时至今日，也没有在市场上看到一款真正的UBI保险产品。这里的主要困难就是数据业务实施。因此这么复杂的事情，不是任何数据建模比赛可以模拟的。

简单总结一下，数据业务化的核心是让数据产生价值。为此，需要三个环节：

1）将业务问题定义为数据可分析问题。

2）对数据可分析问题做分析建模。

3）对最后的分析结果和模型进行业务实施。

以Kaggle为代表的一大类优秀的数据建模比赛能够对2）提供很大的帮助，但是，对1）和3）帮助甚微，最具挑战、最有价值的恰恰是1）和3）。