下载APP
登录
关闭
讲堂
部落
算法训练营
Python 进阶训练营
企业服务
极客商城
客户端下载
兑换中心
渠道合作
推荐作者
CRM 体系化解决方案
2018-03-06 杨堃
内容提要
标准 CRM 应用架构
CRM 建设的几个阶段
产品线的分工与协作
业务部门合作问题
一、标准 CRM 应用架构
通过对业务的逐步介绍，我们已经将 CRM 体系架构图的血肉填充完整，一幅清晰地 CRM 架构蓝图在我们眼前呈现。此时，读者应该对架构图中每个版块存在的价值和意义都有全面的认识和理解。
结合客户开发、维护、服务的业务分工与职责定位，以及软件架构设计的经典模式，整体 CRM 架构中包括以下几大块内容。
数据底层
数据底层主要包括集团级别的数据仓库系统，数据集市，主数据。
数据仓库对公司所有业务数据进行统一汇总处理，提供标准统计口径与计算维度，在数据仓库上层，针对不同业务部门诉求，定制对应的数据集市，数据集市相对灵活可变。
数据底层还包括主数据管理，常见的主数据有商品主数据，客户主数据等。CRM 关心的是客户主数据。
基础服务底层
在企业发展到一定阶段后，通常需要把具有共性的模块和功能单独剥离出来，进行服务化建设，以便给所有上层系统提供基础服务支持。
这些基础服务，既包括业务型服务，例如 EDM、SMS、Push、Pay，也包括纯技术底层，例如规则引擎，工作流引擎。基于这些基础服务，可以让上层系统更关心业务逻辑，而不关心底层的实现机制，从而提升开发效率和 IT 服务能力。
此外，统一客户视图，实现形式为接口服务，或 Web 服务，支持全集团所有业务系统调用，在架构图中作为基础底层服务，绘制在基础服务底层右侧。
业务支持板块
OCRM、销售管理后台、业务支持、CallCenter 都是直接支持业务运转的系统或平台，主要聚焦客户开发和客户服务环节的业务动作。
其中以 OCRM 和 CallCenter 最为重要，是支持销售人员和客服人员的核心系统。
客户建模与策略板块
客户建模和策略，是基于数据底层的上层应用，本身不具备业务属性，属于数据价值输出的范畴。其中，客户建模依赖于数据仓库或数据集市，推荐与策略依赖于客户建模和数据仓库或数据集市。
在架构图中，我们在右侧从下往上分别绘制了数据底层，客户建模，推荐与策略，以体现其逻辑关联关系。
运营管理板块
运营管理板块包含了 CMS、营销等内容。在纯线上开展业务的公司，没有销售团队，不需要 OCRM 系统，经常将 CRM 定义为管理后台中的一个子模块，承担客户分析和营销职责。
在本文中，我们假定运营管理板块既支持线上业务前端，也要支持业务运营策略，通过营销策略实现客户留存。其中既包括手工营销模块，也包括自动化营销模块，也就是常说的 Marketing CRM。
业务分析板块
我们将分析型 ACRM 绘制在最顶层，以便体现出它和业务操作、数据建模本身无关的特性。ACRM 实际上也是公司的 BI 系统。不论是 ACRM 系统，或者 BI 系统，都需要结合数据仓库和数据集市来建设。
数据底层定义指标口径和纬度，BI 提供不同主题或分析视角的数据呈现。有些观点认为 ACRM 包括了客户分析和营销部分，但是本文认为 ACRM 仅同于 BI。
其实怎么定义和划分都无所谓，关键是要清晰理解认识不同产品线的职责和定位。但我更推崇 ACRM 的定义就是 BI，这样便于理解和管理。
关于系统应用架构设计的相关话题，请参考作者的另一篇文章《漫谈企业应用架构的演变》。
二、CRM 建设的几个阶段
在实施 CRM 项目前，首先要做出最基本的判断，业务当前的发展阶段，是否需要 CRM 系统？如果业务体量很小，业务人员很少，业务流程非常简单，建设系统对业务帮助或价值不大，完全没有必要做系统，不能为了上系统而上系统。
常见的商业，在业务发展上，可以划分为业务试错、精细运营、智慧管理三个阶段，每个阶段都有自己的侧重点，对 CRM 建设有着不同的要求。CRM 的体系化建设，不可能一步到位，要结合业务发展的情况，逐步演变完善。
另外需要注意的是，三个阶段的划分标准，只是一个参考，实际执行中，系统建设的优先级和实施顺序，需要根据实际业务情况做出调整。
阶段 1：业务试错
业务特点：业务刚开展的阶段，企业对业务管理的流程、制度、规范，甚至商业模式本身都不能完全确定，需要在摸索中逐步完善。针对互联网企业的特点，融资后需要大规模部署开展业务，版图扩张快，业务变化快，管理粗放混乱，都是常见的现象。
CRM 的建设重点：提供初步、基本的管理运营体系支持，特别重视多层级组织结构的功能开发，以及销售过程管理的实现，前者可以应对该阶段必然会发生的频繁的组织结构、团队结构变化调整，后者可以保证在初期粗放的管理模式下尽可能掌控销售团队，避免管理失控。
CRM 的建设要点：此阶段不能太在意系统架构的合理性，而要重点支持多变的业务。如果过分强调架构合理性，导致工期变慢，很可能功能还没上线，业务已经关停。
另外还要合理评估需求，可以线下处理的工作，尽量线下处理，不要一上来就改系统，原因很简单，极有可能功能上线之际，业务已经停止。
从 CRM 角度来讲，系统永远不是限制业务发展的阻力，牛逼的团队用 Excel 也能做好业务。CRM 可以帮助业务发展的更好，但不能决定业务是否成功。
此阶段 CRM 重点关注的功能如下图，基本上实现了业务系统化管理的最基本功能模块要求，重点支持业务快速试错与扩张。
阶段 2：精细运营
业务特点：核心业务形态、管理模式、经营方式基本确定，扩张阶段结束，增长速度放缓，业务发展稳定。此阶段需要企业开始提升内功，进一步规范管理，提升人效，降低成本，控制风险。
CRM 的建设重点：基本功能模块基本搭建完毕，架构体系初步成型，加强精细化运营管理以及风险控制方面的建设，针对业务流程，通过系统将管理过程标准化，规范化，数据化。
针对营销工作，通过进一步的客户细分与营销策略设计，实现具备业务价值的自动营销策略与任务推送策略，协助销售团队识别机会、问题、风险，对各个生命周期阶段的客户提供差异化的刺激、唤醒策略，对不同贡献度的客户实现差异化的服务、跟进策略。
CRM 的建设要点：架构设计合理化，对部分功能模块进行服务化改造升级。加强客户建模、客户分析的资源投入，通过对客户的精细分析，实现精细化的运营管理。
此阶段 CRM 重点关注的功能如下图，可以看到更多是在客户分析建模，以及策略方面投入加大。
阶段 3：智慧管理
业务特点：业务成熟稳定，成为公司的现金牛业务。业务增长乏力，增长遇到瓶颈，需要寻找新的增长点。管理模式、经营模式、运营模式成熟，科学化管理代替了人治，即便高层人员放手不管，业务也能自发良性运转。此时业务需要更加有效地控制成本，提升人效，寻找并尝试其他增长机会，通过系统辅助甚至进行决策和工作安排。
CRM 的建设重点：系统架构已经完善，成型。加强行业分析、竞对分析，给公司业务探索提供决策支持；加强异常分析，对公司稳定的经营中出现的异常进行感知捕获；加强任务管理中心建设，将系统变成业务指挥的自动化控制中心，通过系统来发现问题，识别问题，触发方案，推送方案，指挥业务人员执行方案；让 CRM 系统变成管理人员地自动化管理指挥中心，从而进一步提升经营效率。
CRM 的建设要点：将系统建设成自动化的管理指挥决策大脑，是一个不小的挑战，要拿捏好给计算机赋权的“度”，要设计好人干预和控制的“度”，什么情况下，什么事情，可以由计算机决策安排，或需要由人来检查确认。
还要考虑总部和分公司管辖关系问题，是总部强，指挥分公司，还是总部弱，分公司自主决策，这都决定了系统作为指挥中枢，是总部级别的中枢，还是分公司级别的中枢。
此阶段 CRM 重点关注的功能如下图。重点加强任务管理中心的建设，以及对行业、竞对的数据搜集与分析。
上图中实线部分表示 CRM 在三个阶段中重点关注的功能，虚线部分需要结合实际业务情况判断是否需要实现，在什么阶段实现。
三、产品线的分工与协作
CRM 是一套庞大的体系，从系统层面包含了数据仓库，主数据，基础服务，业务系统，数据挖掘与策略等板块。在大多数公司，这些板块通常属于不同团队负责管理，如下图。
绿色：业务运营产品部。CRM 团队常作为业务运营产品团队管理，职责范围包括 OCRM，管理后台，CallCenter，工单等。
橘色：基础架构部。大型企业会把基础服务底层或上层公共服务单独设立一个团队统一管理。
蓝色：数据部。底层数据仓库和部分数据集市，由专门的数据团队管理。多数时候数据团队还要负责公司的 BI 系统。
粉色：C 端产品部。大多数时候，CMS、卡券都属于 C 端团队的业务端管理范畴，直接配合 C 端团队以及 C 端对应的线上运营团队。
黄色：风控团队。风控团队一般和业务运营团队分开管理，作为集团层面的风控团队统一管理建设，管控各条业务线的经营管理风险，这样做的原因是因为不论集团有多少条业务线，客户都是针对集团整体的服务对象，围绕客户的风险管理必须具备单条业务线之上的管理权限。
灰色：比较模糊的地带，隶属关系每个公司的情况不一样，我们分别进行阐述。
ACRM：此处我们理解成公司的 BI。一般公司会安排数据仓库和 BI 同属一个团队管理，CRM 可以有自己的数据集市和针对销售业务线的小型报表系统。但有些线下业务模式很重的公司，可能会将 CRM 团队的报表系统和高管使用的 BI 系统分开建设，并列于同等重要的地位。
营销板块：包括优惠券管理，营销管理，自动营销。线上模式为主的公司，营销板块常属于 CRM 范畴，由狭义的 CRM 团队负责。如果线上线下营销和销售同等重要，则营销板块可能属于大 CRM 团队直接管理，给 C 端线上业务提供支持。
客户数据与主数据：客户数据与主数据最早设计时可能由交易系统团队管理，或交易系统附属的 CRM 板块管理，随着业务和架构的发展，可能会移交给数据团队管理。
积分与会员：线上业务重的公司，会员和积分经常由 C 端团队建设管理。线下业务重的公司，可能由大 CRM 团队管理。
客户建模、策略：这部分职责很难界定。线上业务需要建模和策略，线下业务也需要建模和策略。比较常见的安排是两边团队都有建模和策略团队，共享数据底层和部分模型与策略。
虽然在一定程度上会造成一些重复性建设，但却可以让两边业务各自快速推进。需要明确的是，一些针对企业公用的客户模型，必须由确定的团队负责，不允许出现多头建设的现象。
可以看出，从企业的视角来看，CRM 是一套体系化的方案与系统部署，具体落地时，其中很多版块会隶属于不同的团队负责。
要根据业务和系统边界，做好团队分工与部署，避免团队之间的资源冲突或管理冲突，也要给每个团队提供足够的发挥空间，让优秀的团队脱颖而出。
四、业务部门合作问题
在纯虚拟经济的互联网公司，产品团队代表了业务部门，对业绩负责。产品团队拥有决策权，同时也要承担业绩压力。系统如何做，怎么做，都由产品部门决定。
现如今的互联网公司，已经深度参与到了实体经济的业务，线下团队和业务部门越来越重要，更多的时候，由业务部门承担业绩和压力，拥有决策权。
例如，IM 产品，工具类产品，或小平台类产品，公司的 CEO 或业务条线总经理常常出身于产品经理，运营和销售向 PM 汇报，这是因为公司盈利的核心在于软件产品本身建设的好坏。
但是如今很多互联网公司已不是虚拟经济形态，和实体经济深度结合，业务模式变得越来越重，很多时候商业上的成败不是基于 C 端产品的好坏，而在于业务后端是否强大。
业务团队拥有很强的话语权，很多时候可以指挥产品技术团队的工作，尤其是深度参与影响后端系统建设，这都是很正常的现象。
产品团队，主要指后端系统的产品团队，如何与业务团队配合工作，是每一个产品经理都需要深入思考的问题。
总体来讲，大家的利益和诉求一致，都是为了公司的经营发展。但很多时候，两方的实现思路和解决方案却经常出现分歧。
业务部门对业务更熟悉，但不懂系统设计，喜欢既提出需求，又给出实现方案。产品部门，思维严谨，更擅长系统设计，总是很反感业务部门出尔反尔，考虑问题不够全面深入，干预自己的方案设计。
产品部门如何与业务部门形成良好的合作关系？
首先，产品经理要非常懂业务，要经常深入一线，如果不懂业务，和业务部门平等对话的前提就不存在 ;
其次，要懂系统解决方案，知道系统该怎么配合业务。对于业务部门提出的需求也罢，方案也罢，要给出实事求是的合理分析，对于不合理的诉求，一方面做出明确拒绝，另一方面要给出替代性的解决方案，说服业务部门认可接受 ;
最后，要学会处理人际关系，要像一个优秀销售一样经营自己，既有业务能力，又善于与人打交道，才能和业务部门和谐相处，拒绝不合理的方案，探讨合理的方案，最终会得到业务部门的尊重与认可。
作为 CRM 产品经理，既要懂业务，也要懂系统，还要会做人，这三点缺一不可。缺少了任何一点，就会沦陷为业务执行的工具，而不能引导业务，实现自我价值。
结语
至此，我们已经探讨了 CRM 体系建设方方面面的话题。CRM 建设，不仅仅是系统建设问题，更是业务体系设计问题。只有两者很好的结合，才能真正产生价值。
希望你通过阅读，能够形成 CRM 体系的基本知识框架，当知识框架形成后，根据实际的工作经历，坚持学习总结，逐步丰富框架中的细节，持续更新自己的知识体系，最后形成自己的知识框架。
希望这一系列文章对你有所帮助。
后记
《从 0 到 1 构建一个完整的 CRM 体系》从 3 月初构思，到 5 月初全文撰写完毕，花了两个月的时间，全文接近 3 万字。
看着完稿的 Word 文档，十分感慨，当年写毕业论文都没有这么认真。写这么长的文章，中途也有过倦怠，好在最终坚持了下来，完成了文章，给读者有个交代。
工作了 9 年，虽然有过一些总结，但从没有完整的写过东西。从今年 2 月开始，突发奇想，把自己的一些思考写下来，与人分享。
最主要的目的，是强迫自己做一次知识体系的梳理，将以前经验或思考中零散的点，做一次体系化的沉淀总结。动笔时，才发现自己的知识体系有很多不完善的地方，写作正好是一个逼迫自己学习，查缺补漏的机会。
期间查阅了大量的资料，试用了很多系统，如果不是因为写作，估计自己也没有那个心气去花时间搞很多细节的研究。全文发表时，发现自己也有了进一步的成长和提高，这也是写作最大的乐趣。
知识的积累，是需要深度的阅读和思考，固定的、沉浸式的时间投入是必不可少的，碎片式的学习并不能带来真正的提高，因此我写的文章篇幅都比较长，希望真正想了解学习的读者，能够耐心读完，必然会有收获。
然而人都有惰性，包括我也是，每当看到比较长的好文章时，都习惯性的先收藏，打算事后阅读，然而很多时候就忘记了自己曾收藏过文章。
写文章需要毅力，读文章也需要毅力，只有耐着性子沉下心做事情，才能真正有所收获。
我长期从事后端系统设计，包括业务系统，策略，数据等，因此文章主要集中在这部分领域，网上有的内容我不会写，比较简单的东西我不会写，我希望更多的写一些能够帮助读者形成知识框架的文章，当读者读完后，学习的是知识的面，以及思考、处理问题的方式，掌握的是道而不是术。
感谢你的关注，希望你开卷有益。
