漫谈CRM体系化建设5：CRM体系化解决方案(2)

发布时间：2017-05-10 12:22 所属栏目：30 来源：woshipm.com

导读：阶段3：智慧管理业务特点：业务成熟稳定，成为公司的现金牛业务。业务增长乏力，增长遇到瓶颈，需要寻找新的增长点。管理模式、经营模式、运营模式成熟，科学化管理代替了人治，即便高层人员放手不管，业务也能自

阶段3：智慧管理

业务特点：业务成熟稳定，成为公司的现金牛业务。业务增长乏力，增长遇到瓶颈，需要寻找新的增长点。管理模式、经营模式、运营模式成熟，科学化管理代替了人治，即便高层人员放手不管，业务也能自发良性运转。此时业务需要更加有效地控制成本，提升人效，寻找并尝试其他增长机会，通过系统辅助甚至进行决策和工作安排。CRM的建设重点：系统架构已经完善，成型。加强行业分析、竞对分析，给公司业务探索提供决策支持；加强异常分析，对公司稳定的经营中出现的异常进行感知捕获；加强任务管理中心建设，将系统变成业务指挥的自动化控制中心，通过系统来发现问题，识别问题，触发方案，推送方案，指挥业务人员执行方案；让CRM系统变成管理人员地自动化管理指挥中心，从而进一步提升经营效率。CRM的建设要点：将系统建设成自动化的管理指挥决策大脑，是一个不小的挑战，要拿捏好给计算机赋权的“度”，要设计好人干预和控制的“度”，什么情况下，什么事情，可以由计算机决策安排，或需要由人来检查确认。还要考虑总部和分公司管辖关系问题，是总部强，指挥分公司，还是总部弱，分公司自主决策，这都决定了系统作为指挥中枢，是总部级别的中枢，还是分公司级别的中枢。

此阶段CRM重点关注的功能如下图。重点加强任务管理中心的建设，以及对行业、竞对的数据搜集与分析。

上图中实线部分表示CRM在三个阶段中重点关注的功能，虚线部分需要结合实际业务情况判断是否需要实现，在什么阶段实现。

3、产品线的分工与协作

CRM是一套庞大的体系，从系统层面包含了数据仓库，主数据，基础服务，业务系统，数据挖掘与策略等板块。在大多数公司，这些板块通常属于不同团队负责管理，如下图。

绿色：业务运营产品部。CRM团队常作为业务运营产品团队管理，职责范围包括OCRM，管理后台，CallCenter，工单等。橘色：基础架构部。大型企业会把基础服务底层或上层公共服务单独设立一个团队统一管理。蓝色：数据部。底层数据仓库和部分数据集市，由专门的数据团队管理。多数时候数据团队还要负责公司的BI系统。粉色：C端产品部。大多数时候，CMS、卡券都属于C端团队的业务端管理范畴，直接配合C端团队以及C端对应的线上运营团队。黄色：风控团队。风控团队一般和业务运营团队分开管理，作为集团层面的风控团队统一管理建设，管控各条业务线的经营管理风险，这样做的原因是因为不论集团有多少条业务线，客户都是针对集团整体的服务对象，围绕客户的风险管理必须具备单条业务线之上的管理权限。灰色：比较模糊的地带，隶属关系每个公司的情况不一样，我们分别进行阐述。ACRM：此处我们理解成公司的BI。一般公司会安排数据仓库和BI同属一个团队管理，CRM可以有自己的数据集市和针对销售业务线的小型报表系统。但有些线下业务模式很重的公司，可能会将CRM团队的报表系统和高管使用的BI系统分开建设，并列于同等重要的地位。营销板块：包括优惠券管理，营销管理，自动营销。线上模式为主的公司，营销板块常属于CRM范畴，由狭义的CRM团队负责。如果线上线下营销和销售同等重要，则营销板块可能属于大CRM团队直接管理，给C端线上业务提供支持。客户数据与主数据：客户数据与主数据最早设计时可能由交易系统团队管理，或交易系统附属的CRM板块管理，随着业务和架构的发展，可能会移交给数据团队管理。积分与会员：线上业务重的公司，会员和积分经常由C端团队建设管理。线下业务重的公司，可能由大CRM团队管理。客户建模、策略：这部分职责很难界定。线上业务需要建模和策略，线下业务也需要建模和策略。比较常见的安排是两边团队都有建模和策略团队，共享数据底层和部分模型与策略。虽然在一定程度上会造成一些重复性建设，但却可以让两边业务各自快速推进。需要明确的是，一些针对企业公用的客户模型，必须由确定的团队负责，不允许出现多头建设的现象。

可以看出，从企业的视角来看，CRM是一套体系化的方案与系统部署，具体落地时，其中很多版块会隶属于不同的团队负责。要根据业务和系统边界，做好团队分工与部署，避免团队之间的资源冲突或管理冲突，也要给每个团队提供足够的发挥空间，让优秀的团队脱颖而出。

4、业务部门合作问题

在纯虚拟经济的互联网公司，产品团队代表了业务部门，对业绩负责。产品团队拥有决策权，同时也要承担业绩压力。系统如何做，怎么做，都由产品部门决定。现如今的互联网公司，已经深度参与到了实体经济的业务，线下团队和业务部门越来越越重要，更多的时候，由业务部门承担业绩和压力，拥有决策权。

例如，IM产品，工具类产品，或小平台类产品，公司的CEO或业务条线总经理常常出身于产品经理，运营和销售向PM汇报，这是因为公司盈利的核心在于软件产品本身建设的好坏。但是如今很多互联网公司已不是虚拟经济形态，和实体经济深度结合，业务模式变得越来越重，很多时候商业上的成败不是基于C端产品的好坏，而在于业务后端是否强大。业务团队拥有很强的话语权，很多时候可以指挥产品技术团队的工作，尤其是深度参与影响后端系统建设，这都是很正常的现象。

产品团队，主要指后端系统的产品团队，如何与业务团队配合工作，是每一个产品经理都需要深入思考的问题。

总体来讲，大家的利益和诉求一致，都是为了公司的经营发展。但很多时候，两方的实现思路和解决方案却经常出现分歧。业务部门对业务更熟悉，但不懂系统设计，喜欢既提出需求，又给出实现方案。产品部门，思维严谨，更擅长系统设计，总是很反感业务部门出尔反尔，考虑问题不够全面深入，干预自己的方案设计。

产品部门如何与业务部门形成良好的合作关系？首先，产品经理要非常懂业务，要经常深入一线，如果不懂业务，和业务部门平等对话的前提就不存在。其次，要懂系统解决方案，知道系统该怎么配合业务。对于业务部门提出的需求也罢，方案也罢，要给出实事求是的合理分析，对于不合理的诉求，一方面做出明确拒绝，另一方面要给出替代性的解决方案，说服业务部门认可接受。最后，要学会处理人际关系，要像一个优秀销售一样经营自己，既有业务能力，又善于与人打交道，才能和业务部门和谐相处，拒绝不合理的方案，探讨合理的方案，最终会得到业务部门的尊重与认可。

作为CRM产品经理，既要懂业务，也要懂系统，还要会做人，这三点缺一不可。缺少了任何一点，就会沦陷为业务执行的工具，而不能引导业务，实现自我价值。

结语

至此，我们已经探讨了CRM体系建设方方面面的话题。CRM建设，不仅仅是系统建设问题，更是业务体系设计问题。只有两者很好的结合，才能真正产生价值。

希望读者通过阅读，能够形成CRM体系的基本知识框架，当知识框架形成后，根据实际的工作经历，坚持学习总结，逐步丰富框架中的细节，持续更新自己的知识体系，最后形成自己的知识框架。

希望文章对大家有所帮助。