介绍

客户关系管理系统（CRM系统）是管理公司当前以及未来潜在客户的系统，其主要目的是通过优化客户关系实现公司销售业绩的长期增长，它是企业信息系统的核心之一。目前，移动互联网、大数据以及人工智能技术发展日新月异，正在加速改变世界。但是在CRM等企业系统的构建和优化方法论上，却缺乏革命性的创新。本文作者在构建和优化CRM系统的过程中总结出一些新方法论，与当下的一些先进理念不谋而合。每个具体的理念虽然并非原创，应用在CRM系统构建中还算新颖，并且所有的理念一起构成一个完整的体系。希望这些对负责CRM系统开发的管理者、工程师、产品人员有所帮助。

CRM系统的构建和优化本质上是一个工程学问题。解决好一个工程学问题需要把控好四个主要环节：

• 明确该工程的主要目标。
• 理清实现该目标的方法论。
• 构建快速支撑方法论实施的架构和系统。
• 打造一个优秀的团队。

本文基于这条线进行阐述。第一部分主要讨论CRM系统的目标以及方法论。第二部分通过具体案例详细阐述方法论实施。本文第三部分是关于如何设计灵活可扩展系统架构。最后一部分总结了在团队管理方面的一些心得。

CRM系统目标和方法论

搭建优秀的CRM系统的前提是清晰的目标，然后寻找实现系统目标的系统性的方法论。在方法论和目标之间建立关联是一个复杂的分析过程。我们采用严谨的数学方法，从CRM系统目标中推导出独特的方法论。确定了方法论之后，我们将深度阐述其具体内涵以及层次。本小节的最后一部分归纳出实现运营目标的路线图（RoadMap）。

CRM系统目标

主流CRM系统的目标是实现运营收入的增长，严格的讲，应该是收入预期的增长。从经济学的角度来讲，收入预期不是一个值，而是一种分布，这就引入了“风险”的概念。所以，CRM系统的目标需要同时考虑风险和收入预期这两个因素。简而言之，CRM系统的目标应该是：

• 实现收入预期最大化。
• 提高收入预期置信度。

CRM系统目标拆解

实现预期收入最大化这个目标可以从四个方面入手：

• 增加客户数量。
• 提升高质量客户占比。
• 提高服务频率以及延长服务时间。
• 提升运营人员服务效率，即“人效”。

CRM系统负责人真正能够有效提升的因子是人效。提高人效最重要的手段就是让机器承担更多的工作，即“服务数字化”。

提高收入预期置信度的本质上就是降低战略执行的不确定因素，从人治模式转型成系统管理模式，简而言之就是“管理数字化”。

以上的结论经过了严密的数学推导，对推导过程有兴趣的同学，可以参考附录 CRM系统目标拆解详细推导。

全流程数字化闭环

根据上文，实现CRM系统目标的手段是提高数字化程度。基于此，我们提出了全流程数字化闭环概念，如下图：

在对该图进行详细讲解之前，先做两点说明：

• 整个闭环的起点来自于人。在目前阶段，大部分的系统还无法完全独立思考，这意味着它们的运转需要外部的触发点，也就是人。
• 整个闭环的终点也是人。决策者的想法经过系统一轮循环之后，不仅产生业务价值，得出的反馈还会促进决策者成长。

我们对上图进行详细讲解：

• 实现CRM系统目标的前提是运营决策者战略思考（Idea）。
• 工程师们负责将Idea进行数字化（Digitize），转化成计算机能识别的策略（Policy）或规则。
• 系统对数字化的策略进行排期（Policy Schedule）。
• 排完期的策略将会被定期执行（Policy Execution）。
• 策略执行的结果是可具体执行的一系列任务（Tasks）。
• 通过系统，一线运营人员负责任务执行（Task Implementation）。
• 执行完毕后，执行者需要做一些纪录（Record）。
• 系统收集记录以及其他效果数据，形成统计数据（Statistics）。
• 统计数据将被制作成各种图表或者报告（Report）。
• 运营决策者通过直接查看图表的方式，或者接受系统的自动化分析（Analysis）结论获得反馈。

每一轮循环都会提升运营决策者，决策者的提升反过来会促进CRM系统的改进。全流程数字化闭环本质上是决策者和系统不断相互促进的过程。

数字化层次

既然核心方法论是“全流程数字化闭环”，我们需要先深入探讨一下什么是数字化。数字化本身是一个非常抽象的概念，不同的人有不同的理解。我们根据在CRM系统的实践经验，总结出了数字化的三个层次，即标准化、自动化和智能化。

• 标准化。标准化是数字化的基础，物理世界绝大多数事物都是连续的（Continuous），而计算机只能保存离散的数据，所以标准化的核心是离散化、结构化。我们一般把静态的（static）数据模型和概念的数字化称为标准化，比如：账户、工单、分配等。
• 自动化。自动化指的是动态过程的数字化，比如流程、战略、权限控制的数字化。“动态”意味着与时间相关，状态之间存在依赖关系。
• 智能化。智能化是当下非常流行的概念，直观的理解就是让系统具备思考能力。所以，智能化包含两种：第一种是分析过程的数字化，这意味着系统在比较确定的上下文中具备分析能力。第二种指的是在系统中应用统计学方法（Statistical Methods）、机器学习算法（Machine Learning）使其具备一定的学习、推理和思考能力。

业务分析

“数字化”并非空中楼阁，它是具体业务的数字化，本质上也是一种“物化”。从运营业务的角度如何看待CRM系统？传统观点认为CRM系统是一个“操作平台”和“分析平台”。对于像美团点评这样级别公司，其CRM系统的使用人员很多，所以它是“高频操作平台”。此外，“全流程数字化”蕴含着“管理数字化”的概念，所以CRM系统是“战略执行平台”。最后，优秀的CRM系统要考虑人的因素，因人而设计，与人互动。对于拥有庞大运营团队的CRM系统而言，团队士气的高低对“运营目标达成”的影响很大，所以，CRM系统是“激励平台”。综上所述，CRM系统是“高频操作平台”、“战略执行平台”、“激励平台”和“分析平台”，如下图:

RoadMap

以上分析指明了CRM系统目标以及实现该目标的方法论，但这些仅是抽象的概念。在现实生活中，我们实实在在拥有的只是一个技术和产品团队。利用这个团队去实现“运营目标达成”需要一个金字塔状的RoadMap，如下图：

• 金字塔最上层是CRM系统的最终目标，即“运营目标达成”。
• 下面一层是方法论，即“全流程数字化闭环”，具体而言指的是“运营业务数字化”和“运营决策数据化”。
• 所有的目标都要在规定的时间内完成，而完全数字化所需的时间是无限长。所以我们需要在有限的时间内高质量地实现尽可能多的重要功能的数字化，这就需要“灵活可扩展的系统架构”，这是第三层。
• 最底层是物理世界，即团队，它必须是“具备创新意识、强执行力的团队”。

数字化实施

上文已经谈到数字化是一个层次化的概念，要想真正深入理解它并灵活应用到实际工作中，需要大量的实践。本小节将重点阐述如何实现CRM系统的全流程数字化。同时，整个数字化阐述以及各个案例的讲解过程也是帮助读者进行数字化实践的旅途，将会有助于读者深入理解“数字化”。

高频操作平台数字化

这个过程需要三个步骤：

• 高频处理流程梳理。
• 高频处理流程数字化。
• 流程中关键节点数字化。

高频流程梳理

CRM系统的典型高频处理流程包含三个节点：搜索客户、分析客户和客户触达，如下图：

高频流程数字化

流程数字化有两层含义：闭环流程自身的标准化以及闭环流程操作方式的标准化。

“闭环流程本身标准化”意味着需要一个概念去描述完整的基本高频操作闭环。我们把完整的“搜索客户”、“分析客户”和“客户触达”闭环称之为工作单元，简称“工单”。所以高频操作本质上就是对工单列表的顺序操作。

谈到闭环流程操作方式，严格地讲，用户的操作是一个图（Graph）或者树（Tree），而我们的目标就是要尽量让高频流程操作形成一个链表（List）结构。从技术上讲，这会带来两个好处：

• 链表式操作容易进行人效优化。与链表相比，对图或树进行优化要复杂很多。
• 链表式操作隐式地自动进行目标管理。图或者树式操作类似于随机过程（Stochastic process），操作人员需要不停的做决策，记住每次操作的下一步目标。持续地进行高强度、高频率的决策工作，这对操作人员的要求很高，很容易导致其疲劳或者目标迷失。采用链式操作模式，链表中节点之间的流转固定，这近似于一个确定过程（Deterministic process）。

基于以上分析，我们做了两方面的抽象：

• 引入了工单（Task）的概念，并且将闭环的操作入口固定为“工单列表”。
• 工单操作主流程链式化。

高频流程的数字化结果如下图：

搜索客户数字化

高频操作流程的第一步就是搜寻客户，实现该功能的最朴素的产品是多维度的客户搜索、筛选功能。运营人员通过组合各种筛选项和搜索条件寻找目标客户。这种操作方式类似于用户在Amazon或者Taobao上购物。显然这是低效的操作模式，在搜索客户数字化方面，我们将进行三个层次的优化，即：标准化、自动化和智能化。

搜索客户标准化

搜索客户的低效源自于搜索筛选条件的复杂，以及重复的搜索操作，所以最直接的解决方案就是让系统记住这些复杂的筛选项，并避免重复搜索。基于此，我们的第一个改进措施是将“搜索模式”转变成“分配模式”，具体而言，就是从“搜索客户”转向“分配工单”，它所导致的变化如下图：

运营人员的操作模式从上图左边的循环转变成了右边的循环。这样一个看似简单的变化是对于人效提升而言却是本质性的改进。从理论上讲，我们取得了三个方面的进展：

• 搜索操作效率改进。分配模式是一次搜索、大量分配，运营人员搜索次数从n降成1。
• 决策优化。分配本质上是一个决策的过程，根据心理学理论，高质量的决策需要一定的时间。实施决策和操作分离，我们可以期望更高质量的决策。
• 上图左边的循环包括“搜索”和“操作”，右边的循环只包含“操作”，显然更小的循环有助于提升效率。理论上讲，循环越小，上下文切换（Context Switch）成本也就越小，使用者熟练度也会提升，目标也更聚焦，所以人效也就自然得到提高。

在分配模式下，我们还可以为每次分配设置跟进优先级。这就引入了“偏序（Partial Order）”的概念，这意味着，客户之间不仅仅有是否需要跟进的区别，从跟进优先级的角度来讲还是可以比较的。众所周知，无论工作还是生活，我们都应该“做正确的事情”。“偏序”概念的引入让决策者具备了优先安排正确工作的能力，让执行者具备了优先做正确的事情的能力。

具体而言，工单分配就是将客户分配给运营人员的过程，包含如下图四块：

• 客户召回，通过对客户的属性和特征进行筛选和搜索实现。
• 运营人员召回，通过对运营人员的属性和特征进行筛选和搜索实现。
• 匹配，将召回运营人员和客户进行关联。
• 生成工单，客户与运营人员的关联结果称之为分配，分配的结果以及预期的执行称之为工单。

搜索客户自动化

工单分配实现了n次搜索操作向1次分配操作的转变，这是空间维度的人效提升，例如，运营管理层可以一次为多个运营人员分配工单。但是，运营决策者仍然需要定期进行工单分配，这也是一种重复劳动。所以，我们可以从时间维度提高人效。这种让机器代替人来执行重复操作的过程是一种自动化。自动化分配一般由规则引擎（Rule Engine）和调度系统（Scheduler）共同完成。这里的一个核心概念就是规则（Rule），它的核心内涵包括如下四个方面：

• 召回细则（Recall Policy），指的是客户筛选属性和运营人员筛选属性集合。
• 匹配细则（Match Policy），指的是对召回的客户和运营人员进行匹配的规则或者模型。
• 排期（Schedule），指的是规则执行频率，即该规则多久执行一次。
• 有效期（Lifetime），指的是规则从第一次执行到最后一次允许执行的生命周期。

规则（Rule）是上面四个概念的集合体，更复杂的规则还可以指定执行优先级等。

通过调度系统和规则引擎进行分配自动化的功能图如下：

• Scheduler定期去查看Rules。
• 处于有效期内，到了执行点的Rule将被Scheduler发送给Rule Engine。
• Rule Engine对Rules进行解释和执行，生成工单分配。为了执行规则，Rule Engine还需要其他辅助Data才能完成工单分配。

搜索客户智能化

最少可以从两个维度去提高客户分配的智能化：召回规则、匹配规则。同时，如上文所述，智能化的手段有两个：分析过程数字化和规则模型化。

精确筛选高优先级的客户是一个非常复杂的分析过程，大部分的筛选和搜索操作都是基于客户的静态属性完成的，比如账户的消耗、余额等等。现实生活中，对客户的理解和分析却是动态的，我们根据客户过去一段时间的变化或者趋势去识别客户。几乎不可能把所有时间维度的特征纳入到筛选中，有几个原因：

• 人们对概念的理解基本上是静态的。虽然每个人都具备动态理解能力，但是人们并不容易在动态思考上达成一致意见。
• 动态的特征转换成筛选项，意味着在筛选项之间引入了逻辑关系，而不仅仅是简单的集合关系。这种产品将很难理解，对使用者要求极高，用户体验极差。

在账户分析过程数字化方面，我们采用典型分析思路标准化的策略。具体做法如下：

• 将典型的、已经被证明有效的分析过程整体进行数字化。
• 整个分析过程的数字化后形成一个抽象的召回细则。这个复杂抽象的召回细则整体作为一个筛选项供用户筛选，换句话说，一个筛选项意味着整个分析过程。
• 为了让使用者明白复杂召回细则，工程师需要与使用者进行必要的沟通，所以对复杂召回细则的理解是通过线下沟通实现的。

规则模型化比较容易理解。实施召回规则和匹配规则，除了采用确定性的（Deterministic）规则，我们还可以采用自适应（Adaptive）的统计学模型（Statistical Model）。这也是我们通常意义的智能化。

客户分析数字化

优质的客户服务需要长时间的客户分析，所以这一块的优化空间很大。

客户分析标准化

把客户的各种信息采用图、表或其他友好的产品形式进行展示称之为客户信息标准化，本质上信息可视化的过程。有了标准化的客户信息展示之后，通过基本的培训，运营人员就能掌握标准的客户分析方法。采用这种分析方式得出的结论将会有助于提升运营效果。

客户分析自动化、智能化

对客户分析过程类似于医生对病人进行诊断。现在医学之前，医生通过望闻问切等方式来对病人进行诊断。这种诊断方式有几个缺点：
首先，它对诊断者的要求比较高，一般必须是医生本人。
其次，比较浪费时间，除非能够标准化，完整的记录整个诊断结果，即使短时间内针对同一个病人，医生仍然需要重复诊断（或者这个医生一天只有几个病人，所以能全部记住）。
最后，即使对一些简单的病状，医生之间也不容易达成一致。
现代医学将诊断和看病分开，诊断的工作交给护士和机器来完成，诊断的结果非常精确。对于简单的诊断，普通人就能明白如何处理。

在客户分析自动化、智能化方面，我们借鉴了现代医学自动诊断思想。把一些典型的客户诊断分析过程进行数字化。一般而言，典型的诊断分析涵盖了客户的大部分问题，符合80/20法则。这不仅仅提高了运营人员的分析人效，还大大提高了客户分析的精确性和一致性。

客户触达数字化

可以从很多维度对客户触达进行数字化，CRM系统的终极目标当然是机器人直接触达客户，解决客户的所有问题。目前，还没有公司完全实现这个目标。典型的数字化思路有如下几种：

• 交互式语音应答（IVR）解决典型问题。
• 智能化Q&A。这包括采用智能搜索技术对结构化和非结构化的知识库进行查询、运用语音识别技术协助运营客服等。
• 客服质量检查。通过语音识别技术将客服人员的语音转换成文字，进行语法、语义分析，查找恶意作弊行为，识别并改进低质量的语音服务，推广并培训高质量的服务。

战略执行平台

战略执行数字化非常复杂，大数据和人工智能技术使得其数字化变的可能。通俗的理解，战略执行数字化就是要将运营决策者的复杂抽象的战略通过系统转化成一个个可以具体执行的任务。战略执行数字化降低了从战略规划到最终执行过程中产生的方差，通过系统实现了全流程的监控，最终提高了战略目标实现的置信度。

一个中等规模的目标就需要战略，所以战略数字化应用非常广泛，上文中谈到的“工单分配标准化、自动化和智能化”就是一个典型的战略执行数字化的例子。但是，“战略执行”数字化的确是非常复杂抽象的概念，它给需求提供方和系统实施者带来了巨大的挑战。本小节将通过一个具体例子来讲解“战略数字化”的完整实施过程。整个讲解过程详细阐述了我们在实施过程中面临的挑战、应对挑战的思考方式，以及在具体实施过程中的关注点和所做的妥协。到目前为止，在“战略数字化”方法论方面，我们取得的进展是“编码化”。

编码化（Codify）

战略执行数字化对CRM系统负责人的最大挑战来自于如何快速实施和快速应对变化。在具体实施中，需要重点解决如下问题：

• 明确“战略数字化”的目标和方向。
• 需求方和实施方在“战略数字化”概念和内容上取得一致的理解。
• 在需求方和实施方之间建立标准语言，即标准化的需求文档。
• 快速将标准化需求转换成系统。

这四个步骤合在一起，我们称之为“编码化”， 具体例子详见编码化实施。

激励平台

这是一个不证自明的道理，士气影响团队产出。CRM系统游戏化（Gamification）的理念很早就被提出，但在这块的实施往往没有给予应有的重视。移动互联网时代，人类几乎成了系统的奴隶。显然，优秀的CRM系统需要去拥抱这两个现实，让运营人员和系统能够实现更好的互动，进而提升运营人员的兴趣、士气，从而提高运营收入。

分析平台

网上有大量文章阐述如何构建优秀的分析平台。我们从实践过中总结出两个独特的建议：

• 为每种角色、甚至每个人提供定制化的分析平台。这有两层意义，第一，每个人都应该通过数据去决策，所以分析平台要尽可能适应每个人的需求。第二、标准化分析是比较专业的工作，不同角色、不同人的分析能力不同，分析平台必须非常贴合具体角色的能力要求。单一的分析方式总是有利于一部分人，而不利于另外一部分人，更精确的讲，它不利于所有人。
• 分析平台要具备“实时查询、即查即得”的特征。据作者的观察，由于大数据量的原因以及传统的数据仓库（Data Warehouse）的一些固有理念，大部分分析平台都无法实现“即查即得”的要求，它们通过滞后的邮件或者CSV文件格式来提供分析结果。这增加决策者的数据分析时间，降低了其分析效率。在很多场景下低劣的用户体验会导致用户放弃使用该产品功能。为了实现“实时查询、即查即得”，我们自己编写中间件去解决数据量和查询性能问题。另外，对于一些使用场景少并且性能消耗很严重的需求，架构师需要进行一些取舍。毕竟，系统的目标不是实现所有的需求，而是实现所有人的需求收益最大化。

系统架构灵活可扩展

对于构建CRM系统而言意味着：必须要用最小的投入，完成最关键的目标。这就对系统架构的灵活可扩展性提出了很高的要求。

如何构建灵活可扩展的系统架构是一个开放式的问题，仁者见仁，智者见智。通过实践，我们总结出构建灵活可扩展系统的四个准则：定制化、配置化、组件化和重引擎轻数据库。

定制化（Customerization）

定制化指的是为不同的人提供不同的产品，从某种角度来说，这是一种空间适配的概念。CRM系统是高频操作平台，所以几乎每个用户都是高级用户，为每个人提供定制化的产品必然能够提高运营人效。但是，为每个用户开发一套系统的成本太高，并不现实。所以，定制化指的是用一套技术架构提供不同的产品，具体的讲就是用户可以通过配置方式定制的满足个性化需求的独特产品展现形式。

配置化（Configuration）

如果说定制化是一种空间适配，配置化就是时间适配，它指的是产品随着时间发生了变化，但是不需要额外开发工作。配置化是内容管理系统（CMS系统）的核心思想。具备了配置化功能的系统，新产品的上线或者老产品内容的更新不需要工程师的额外开发工作，系统管理者可以通过简单的配置实现。

什么场景能够进行配置化并没有一个标准的答案。但是，配置化和模板化往往是孪生兄弟，所以我们可以从模板化的概念中得到一些启示。设计模式里面的模板方法模式（Template method pattern）指的是在父类中实现框架，在子类中实现具体方法。类似的，一个产品功能是否具有模板化的特征，取决于其主体框架是否能够保持不变，功能细节是否变化频繁。如果一个功能具有模板化的特征，设计者就可以尝试配置化的设计。

组件化（Componentization）

CRM系统非常复杂，包含众多子系统。这些子系统共同组成一个有机的整体，在具体的产品开发过程中，一个小功能点往往需要对多个子系统进行修改。牵一发而动全身，这不利于产品快速交付。有很多系统架构理论用于解决类似问题，例如：SOA、高聚合低耦合（High Cohesion, Loose Coupling）等。我们同样花了很长时间去思考和解决此类问题，最终形成了自己独特的方法。我们称这个方法论为“组件化”，需要注意的是，这里与业界通行术语的含义并不完全一致。。组件化由四个步骤组成：

• 长业务分组件。
• 组件专人负责。
• 组件功能聚焦。
• 组件之间解耦。

对于组件化四步骤，这里做一些说明。

什么样的业务是“长业务”？如上文所述，页面上的一个小功能点需要多个系统协作才能完成的情况比比皆是，所以大部分业务都是长业务。整个CRM系统设计都应该尽可能的按功能切分成子系统，子系统内部按照功能点进行再切分。例如，在我们CRM系统里面，所有与筛选相关的功能都被放到“筛选引擎”里面，所有数据获取功能由“DataService”服务提供，所有的报表都由“ReportEngine”来完成。

“组建专人负责”看起来是管理学的问题，但是却是非常高效的手段。经验表明，对系统熟悉的工程师在产品需求交付速度上有很多倍的提升。随着熟练度的增加，专职工程师能够接受更具挑战的任务、提出更具创新性的思路。

后面两步骤基本上就是设计高聚低耦的系统。虽然有很多关于如何设计“高聚低耦”系统的资料，在实际工作中这一点对很多工程师的挑战还是比较大。

我们这里举一个例子来形象地展示“什么样的系统架构具备组件化设计标准”。对于很多产品而言，筛选和搜索都属于复杂度比较高的系统，于此同时，新的业务需求导致筛选项不断增加。这在我们的CRM系统中表现非常明显。通过采用如下树状架构图，我们的筛选引擎具备快速支持新筛选需求的能力。

采用如上架构图，一个新的筛选需求对于工程师而言意味着三件事情之一：

• 修改现有的筛选逻辑，即修改架构图中的某个或者几个节点代码。
• 添加节点。在上面的架构图中，添加节点只意味着最多和两个现存节点之间有关联，这实现了对现有系统入侵性最小化。
• 在Combiner下面添加完整的一个筛选链条，这个链条的代码是完全独立的，现有系统中只有Combiner需要修改。

无论哪种修改方式，新需求与现有系统的耦合非常少，开发非常轻。我们的报表引擎、分配引擎、诊断引擎都遵循类似的架构设计标准。

重引擎轻数据库

Spark被认为是非常灵活的系统，它的核心思想之一就是把操作保留在内存里面，避免保存大量的中间结果数据。借鉴这个思想，为了快速支持系统数字化，我们的CRM系统引擎层做的比较重，尽可能的在引擎层去实现所有计算逻辑。除此之外，重引擎层还有如下几个原因：

• 需要进行数字化的业务方向非常多，类似业务有很大的共通性，业务之间并不具备互通性。组件化要求为不同的业务构建不同的引擎。
• 根据以上论述，对业务进行数字化的主要模式是：梳理典型业务逻辑，然后进行数字化。从技术的角度来看，这相当于对流程或分析过程进行数字化，这正是引擎的概念。
• 熟能生巧，每个业务引擎由专职工程师负责，这会让整个团队在引擎的思考深度和产品交付速度上有明显的改善。

对于数据库的使用，我们的态度是数据库只负责存储，计算尽可能由引擎实现。没有办法去证明这个观点的正确性。因为存在反例，SQL的功能非常强大，某些团队利用SQL去维护大项目，解决复杂问题。但是我们拒绝数据库进行计算有如下理由：

• CRM系统的需求变化频繁，复杂的SQL语句很难实现“高聚低耦”。一个小需求变更可能意味着整个庞大的数据库语句修改，很多时候难以接受。或许拥有众多专业DBA可以缓解此类问题，但是前提是一定不能以牺牲项目迭代周期代价。
• 采用数据库进行计算往往意味着重量级地使用Object-relational mapping框架。现实情况是，并非所有的工程师对于如何使用和优化这些框架都熟悉，但是他们却必须要全方位得快速解决所有业务问题。
• 大量采用SQL还存在一些安全隐患，并非所有工程师都是专业的安全工程师。
• 对于计算密集的业务，数据库在性能上没有保障。并且，数据库性能调优并非所有开发工程师所擅长。
• 大部分系统需要共享同一个数据库，将计算交给数据库意味着产品功能开发之间通过数据有了强耦合关系。
• 总的来说，数据库比较擅长集合操作，在逻辑操作方面比较弱。

“重引擎轻数据库”本质上是一个技术选型的问题，技术选型第一要素当然是满足业务需求。满足这个必要条件之后，人的因素就是技术选型的重要标准：团队成员是否熟悉该技术，学习该技术成本是否高，使用该技术的风险是否大，都是重要考虑因素。

团队管理

团队管理是任何管理者都无法回避的问题，它是整个Roadmap的第一层。同时，它也一个非常大的话题，而且往往非常主观，我们试图总结一些比较客观的经验。

创新、积极向上的团队

创新意识和积极向上是保持团队长期高效稳定的基础。显而易见“正能量价值观”和“关注个人成长”必然会促使团队积极向上，并提高团队成员的创新意识。

关于“正能量价值观”这一块，基本理解是：人们只会在愿意创新的地方去创新，只会对感兴趣的事情表现出积极。幸运的是CRM系统解决的问题是非常正能量的，因为它的目标是提高运营人员的生产力，而提高生产力是人类最伟大的目标之一！所以，只要导向正确，很多工程师会对CRM系统表现出强烈的兴趣。

关注个人成长很重要，毕竟成长是很多人的重要工作目标之一。没有成长的团队很难激发创新意识。对于一个团队而言，实现个人长期持续的发展要关注两点：

• 纳什均衡（Nash equilibrium）。在团队管理里面，纳什均衡指的是每个人要在团队里面有自己清晰的定位。要实现这一点，为每个工程师找到一些能够长期持续驱动的项目非常重要。
• 定位要尽量符合个人特长。进入社会之后，工程师之间在经验、特长都会有所不同。大家统一定位，则意味着忽视个性。这一方面意味着不公平，另一方面意味着压制创新。为了尽可能让工程师的定位符合其个人特长，团队需要很多对能力类型要求不同的长期项目。

所以关注个人成长的一个重要措施就是挖掘出很多开放式的项目。幸运的是，CRM系统的“全流程数字化闭环”包含许多具有挑战、值得探索的项目。

高执行力

在提高团队执行力这块，我们有三个总结：客户价值、并行工作（Multitasking）和敏感度把控。

强调技术的客户价值非常重要。一个没有客户使用，不能帮助客户提升生产力的系统或者架构没有价值。衡量执行力的标准不是做了多少事情，而是给客户带来了什么好处。做一个简单的算术题：假定有两个团队，A团队60%的项目有价值，B团队90%的项目有价值。为了实现同样的业务目标，A团队需要B团队1.5倍的人力，人员成本增加是惊人的。

对CPU的进行多线程调优，工程师们比较熟悉。对于团队执行力而言，并行工作同样重要。可以从三个方面去提高团队的并行工作能力：

• 大团队要分成独立工作小组，提高团队同时承接多项目的能力。对于美团点评这样公司，工程师们的单兵作战能力比较强，所以两三个、甚至一个工程师可以独立承接一个小项目。无论如何，把大团队按照项目承接能力拆分成独立工作小组都能提高团队整体承接项目的能力。
• 提高个人并行工作能力。大部分人习惯于在一段时间专注一件事情，如果这个事情被阻塞住了，整个人就容易进入到闲置状态（Idle）。早期的CPU就是这种工作模式，多任务（Multitasking）技术大大提高了CPU的工作效率，这同样适用于工程师。
• 每个人要有自己主导的重要的开放式的项目。大家都知道“重要”和“紧急”的经典理论，这里不详述。理论上讲，“紧急”需求占个人工作时间的比重应该是比较低的，或者说管理的目标之一就是减少“紧急”任务占个人工作时间的比重。当没有紧急需求的时候，或者当前需求被阻塞的时候，工程师需要迅速找到其他重要任务去完成。让每个工程师都有自我驱动的重要的开放式的项目是实现这个目标的关键。

项目敏感度控制和团队成员松弛度管理非常重要。大部分团队或者中等规模以上的项目都不是铁板一块，它们都有自己的结构或拓扑（Topology）。依据经典运筹优化理论，对敏感资源的少量投入往往能够极大的提高最终的目标产出。通俗的讲，很多公司或者团队所谓的忙碌，都是结构性的忙碌，“忙的忙死，闲的闲死”。举例来说，一个典型CRM开发团队应该包含：产品经理、前端工程师、后台工程师、数据工程师、测试工程师等等。在一段时间内，各种角色的配置比例是相对固定，但是每个项目对各种资源的使用比例基本上不一样。假如某个项目前端工程师资源很紧张，项目管理者就必须好好利用前端工程师资源。从敏感度和松弛度管理的角度，我们可以从两方面进行优化：第一、砍掉一些前端资源要求很高，但是重要性低的需求。第二、引入前端资源不密集的项目，把两个项目合成一个项目，变相地增加前端资源。

总结

本文以CRM目标为出发点，创新性的推导出“全流程数字化闭环”方法论。基于此，本文探讨了“数字化层次”以及构建CRM系统的完整RoadMap。本文的后面部分都是基于该RoadMap进行讲解的。

我们花了很大的篇幅去阐述“数字化”实施，从业务的角度讲，它关注CRM系统。本质上讲，整个互联网的发展历程就是传统业务的数字化的历史。所以，本文的关于“数字化”思想适用于任何系统，任何领域。这种思考问题的方式既适用于工程师，也适用于产品人员、管理者甚至创业者。

在系统架构和团队管理方面，本文总结了作者所在团队一些最重要的经验。所谓“天下大事，必作于细”，实际工作往往要繁琐很多，我们需要关注更多细节，没有完备性的解决方案。“天下难事，必作于易”，所有复杂繁琐的事情都是通过少数重要的准则去分析解决的。本文在系统架构和团队管理方面所给出的建议是我们在日常工作中最经常使用的一些准则，坚持这些准则极大地提高了我们在产品交付方面的能力。

附录

CRM系统目标拆解详细推导

我们采用经典运筹学分析方法拆解“收入预期最大化”目标。首先需要对客户进行离散化，将收入预期相近的客户分入同一个级别，目的是对客户进行分级。每个级别内的客户形成一个等价集合。收入预期最大化即Maximize(ERevenue)。收入预期ERevenue用如下公式表示：

公式中Customer_Num(inLevel)表示某个处于某个级别的客户总量，ERevenuePerCustomer(inLevel)表示该级别单客户收入预期。
根据公式，可以从两个方面优化收入预期：

• 增加Level的数量将使得ERevenue变得更加精准。
• 提高单客户收入预期。

单客户收入预期与如下因素成正比例关系：

• 其所处的级别，用LevelFactor表示。公式表示如下：
  
• 该客户的服务频率（ServiceFrequency）和单次服务时间（PeriodPerService）的乘积。公式表示如下：
  
• 单位时间的服务效率（ServiceEfficiency），通俗的说法就是“人效”。公式表示如下：
  

所以如下四方面的改进可以潜在的提高收入预期：

• 客户数量增加。
• 高质量客户占比提升。
• 更高频率的服务以及更长的服务时间。
• 提升运营人员服务效率，即“人效”。

在这些因素里面，高质量客户占比提升既是改进的目标，也是改进的结果。单纯地提高客户数量、服务频率以及服务时间是朴素而有效的方法，但是它要遵循一定的约束，也就是成本。可以用如下公式来表示：

运营人员的数量（OperatorNum）是由预算决定的，运营人员的工作时间（WorkingHour）相对固定的，所以这两个因素往往非CRM系统负责人所能决定。所以，CRM系统负责人真正能够有效提升预期收入的因子是人效。显然提高人效最重要的手段就是让机器承担更多的工作，即服务数字化。

“提高收入预期置信度”，即Maximize( Confidence (ERevenue))，本质就是减少方差。实现一个稍具规模的目标就需要一个完善的规划，任何的规划都包含两部分：确定性部分和非确定性部分。非确定性部分包括市场环境突变、重大自然灾害等等，CRM系统的应对措施并不多。规划的确定性部分一般可以通过工作>流图进行描述。工作流图的实施过程会引入很多不确定因素，这包括：节点流转不畅通、信息不对称、关键指标衡量标准不一致、关键节点的监控不到位等。在传统的工程实施里面，这部分属于项目经理的管理范畴，但是单纯的人治容易引入的很大的方差。管理数字化是降低方差的重要手段，也是目前的趋势。从某种程度上讲，数字化程度越高，方差也就越小，收入预期置信度也就越高。

编码化实施

实施的前提是需求方和实施方在数字化目标方面取得一致。战略数字化非常抽象费解，对于具体某个战略，类似“什么是数字化”、“如何实现数字化”等关键问题，需求方和实施方达成一致理解并不容易。不能取得一致的理解会导致两个严重后果：

• 需求方不知道何时以及如何提需求，不知道什么战略可以实现数字化。
• 将杂乱无章的定性需求转化成系统对于实施方的挑战和压力很大。

我们从典型的“业务流程管理”（Business Process Management）中得到一些启发。工作流业务的典型开发过程是：

• 梳理出一些典型的业务工作流程，进行制度化。
• 完成制度化之后。系统有很多节点是可快速扩展的，对于类似的流程，系统具备了快速实施的能力。
• 对于不符合工作流思想的流程，很多情况我们不是对系统进行重构，而是修改并规范流程。

同理，虽然从业务的角度，有各种各样的战略需要进行数字化。但是大部分战略具有一定的共同特征，并且最重要的战略类别可枚举，符合80/20法则，即最重要的少数战略满足80%的业务需求。基于这个理解，我们把主要精力用于梳理最重要的几种典型战略，并将其转化成系统，持续优化。对于非标准化的非重点战略，需要做一些妥协：或者暂时采用线下方式支持，或者通过修改战略实施流程的方式去适配现有系统。

梳理出重点战略之后，我们需要在需求和数字化之间搭建一个桥梁，即提供一个需求方和实施方能够理解的语言。如此，需求方能在适当的时机，以正确的方式提出战略数字化需求。我们在具体实施过程中总结出两种模式：

• 总则－细则模式。需求方只提简单的总体目标需求，实施方负责将该目标转换成细粒度的细则。基于细则，需求方和实施方对数字化的最终预期效果和所做的妥协进行沟通，取得一致认识。最后，实施方负责把细则转化成系统。
• 表格模式。需求方以表格或者流程图等标准的描述方式提供需求，实施方负责将标准需求文档转换成系统。当然，标准化的需求描述方式是实施方和需求方共同制定的，确保需求方能够理解，实施方能够实施。

读者可能会比较疑惑，通过简单的表格能否描述复杂的“战略实施数字化”需求？我们从美国立法的过程中得到了启发，法律要解决的问题是非常复杂的。神奇的地方在于：通过一些简单的、标准的格式进行法律描述，立法方、执法方以及受处罚方能够取得比较一致的认识。类似的例子还包括“业务流程管理”理论和“权限控制”理论，读者可以研究一下为什么工作流引擎可以满足几乎所有公司工作流程的需求，简单的“Attribute-based access control”理论可以满足从五角大楼到创业公司的权限管理需求。

我们举一个简化的例子去展示编码化过程，它不是一个线性过程，简化后仍然很复杂。读者的关注点不在于理解例子中具体业务，而在于对整个编码化过程有一个感性认识。

需求是将某个地区的客户分配给某些运营人员，当然需要满足一定的条件的客户才是有效客户，运营人员也是如此。候选客户和运营人员的匹配需要满足一些约束和公平性准则。该分配策略还需要与其他分配策略进行优先级排序，只有高优先级的策略执行完之后，该策略才能执行。
无论是“总则－细则模式”还是“表格模式”，需求都需要转换成如下标准表格。采用“总则－细则模式”，工程师负责出具表格，采用“表格模式”，需求方直接出具如下表格。

标题	XXX账号分配
背景	XXX
目标	XXXX
影响区域	江苏省
承接单位	运营X组、运营Y组
账户召回规则	1.满足条件A、B的客户分配 2.满足C或者D的账户不能召回 3.规则2优先于规则1
人员召回规则	1.每个运营人员每日分配客户不超过M个 2.每个运营人员总分配客户不超过N 3.运营人员必须要符合P资质
匹配规则	1.每日客户平均分配给运营候选人 2.运营人员分配的总数量之间实现方差最小
规则优先级	本规则优先级高于E规则，低于F规则

通过这个表格意味着，我们实现了如下目标：

• 它提供了需求方能够理解的语言，使得需求方具备独立评估完成该策略数字化后的后果以及影响的能力。
• 基于标准化的表格，工程师具备了进行完备性分析的能力，确保没有任何明显遗漏。
• 工程师可以进行规则冲突分析，确保新规则与老规则没有冲突，如果有产生冲突，需要进行规则合并。

为了能够将如上需求表格快速进行数字化，工程师需要设计一个灵活可扩展的系统。我们系统简化版本的流程图如下：

我们可以依稀看到“需求表格”与“流程图”之间存在如下对应关系：

需求表格	流程图节点
影响区域、承接单位	组织城市对应规则
账户召回规则	账户召回、账户小组召回
人员召回规则	账户小组召回、账户候选人召回
匹配规则、规则优先级	账户命中规则、分配规则优化

再次强调，一个标准“需求表格”和“流程图”之间并非绝对的一一对应关系，需求表格中某行的一个规则可能需要在流程图的多个节点进行修改才能实现。“需求表格”中的细则和“流程图”之间的节点的关联关系实际上是由工程师在大脑中完成的。但是，对于相对固定的的战略数字化，经过几轮的迭代，需求方应该具备快速提出需求的能力，工程师也能快速的进行完备性分析和冲突检测，并能在较短的时间实现其数字化。

参考文献

1. https://en.wikipedia.org/wiki/Customer_relationship_management
2. https://en.wikipedia.org/wiki/Business_process_management
3. https://en.wikipedia.org/wiki/Attribute-Based_Access_Control
4. https://en.wikipedia.org/wiki/Template_method_pattern
5. https://en.wikipedia.org/wiki/Pareto_principle
6. https://en.wikipedia.org/wiki/Topology