客户与项目谁才是管理单位，CRM里项目独立成对象到底有多重要
客户与项目谁是管理单位，CRM里项目独立成对象有多重要
一、以客户为单位和以项目为单位
还有一个区别在于时间维度。客户是长期存在的，一家单位可能持续合作很长时间；项目是有明确起止的，开始和结束都可以被标记。把两者混在一起，长期关系的经营和当期项目的推进就会互相干扰，前者被后者的紧迫性挤掉。后者被前者的稳定性掩盖。
大多数管理系统的默认单位是客户。
客户是主数据，联系人挂在客户下面，跟进记录挂在联系人下面。商机也挂在客户下面。这套结构的好处是清楚：一个客户有几条商机、最近一次接触是什么时候，翻开就能看到。对于以标准产品销售为主的企业，这套结构够用。
项目型生意的问题在于，真正需要被管理的东西是项目，而不是客户。同一个客户可能在推进好几个方向不同的项目；一个项目也可能牵涉到好几个客户单位，比如使用方、采购方、最终验收方分属不同的主体。
以客户为单位去管，就会出现两种尴尬：要么一个客户下面挂着一大堆分不清的商机，要么一个项目被拆散在几个客户下面，谁也看不全。
- ● 客户是静态的主体，项目是动态的过程
- ● 以客户为单位，项目就被压成了一条记录
- ● 以项目为单位，客户资料仍然照常维护
两者其实是层次关系，不是替代关系。直白点说，客户层回答「我们和这家单位的关系整体如何」，项目层回答「这一件事现在走到哪了」。缺少客户层，经营就失去了积累；缺少项目层，推进就失去了着力点。
图1：功能架构里，有没有项目这一格
二、项目对象要带哪些信息
这几类信息有一个共同要求：都要能被后续的人看懂。项目过程中会有参与方更替，接手的人如果看不懂前面为什么这么判断，就只能重新问一遍。所以信息的写法要尽量避免只有当事人才明白的简写和代号。
把项目当成独立对象，第一件事是定义它要带哪些信息。
第一类是身份信息：项目属于哪个客户、对应哪个需求方向、内部的负责人是谁、当前处在哪个阶段。第二类是参与信息：客户方有哪几个角色参与、内部有哪几方介入、各方分别在什么位置起作用。第三类是推进信息：方案到哪一版、条件谈到什么程度、下一步要做什么、什么时候该做。
第四类是结果信息：签约之后，这类信息会换成交付安排、验收标准、回款节点。前三类偏向判断，第四类偏向履约，它们的结构不一样。放在同一个对象的下面各自成段。
- ● 身份信息解决「这是哪件事」
- ● 参与信息解决「谁在里面」
- ● 推进与结果信息解决「现在到哪了」
除了这些，还有一类容易被忽略的信息：为什么。为什么这个方案被放弃、为什么这个条件做了让步、为什么这个节点推迟了。事实类信息回答「发生了什么」，原因类信息回答「为什么会这样」。后者在复盘和交接时价值更大。
图2：作用不同，看的角度也就不同
三、一个客户下面有多个项目时会怎样
多个项目并存还会带来一个现实问题：同一条线上的人被几个项目同时占用。如果不把项目独立出来，这种占用关系就说不清。协调只能靠临时沟通。项目独立之后，每个人的占用情况可以从项目清单里直接读出来。
项目型生意里，一个客户下面同时推进多个项目是常态。
如果系统以客户为单位，这些项目会挤在同一个客户档案下。形成一长串并列的商机记录。看上去很完整，实际使用时却很难判断：哪几个是同一批设备的不同分期、哪几个是完全无关的两条线、哪几个已经停下来了。管理者想了解这个客户的整体推进情况，只能逐条翻看。
反过来，如果项目是独立对象，每个项目自带阶段、自带参与方、自带停滞提示，那么在客户视图下就能看到「这个客户当前有四个项目在推进，其中两个处在方案阶段、一个在等客户内部评审、一个已经停滞」。同一份信息，看的人一目了然。
- ● 客户视图回答「这个客户怎么样」
- ● 项目视图回答「这件事走到哪了」
- ● 两个视角都需要，但不能互相替代
判断系统有没有做到这一点，可以问一个具体的问题：能不能在一个客户的页面上，看到这家单位名下所有项目的阶段分布和停滞情况。能看到，说明项目是独立对象；只能看到一个项目列表而没有阶段信息，说明项目仍然是客户的附属记录。
图3：以客户为单位，还是以项目为单位
四、独立对象带来的三处变化
这三处变化还可以引申出第四处：复用。项目独立之后，同类项目的阶段结构、参与方配置、关键节点都可以被沿用。新项目开始时照着同类项目搭骨架，比从空白开始要快得多，也更容易保持标准一致。
把项目提升为独立对象，会带来三处明显的变化。
第一处变化在权限上。客户资料通常按区域或按团队划分归属，而项目的参与方是跨部门的，销售、方案、商务、交付都要能看到自己参与的项目。以客户为单位授权，很容易出现「参与了这个项目却看不到这个客户」的情况。以项目为单位授权，这个问题自然消失。
第二处变化在提醒上。项目有自己的节点和节奏，提醒可以挂在节点上；如果只有客户记录，提醒只能挂在跟进时间上，形式上仍然停留在「该联系一下了」这个层面。
第三处变化在统计上。项目可以按阶段、按参与方、按停滞时长来统计，得出的是过程指标；客户记录只能按接触频次、按成交金额来统计，得到的是结果指标。过程指标才能指导过程管理。
- ● 权限按项目分，跨部门协作才无障碍
- ● 提醒挂在节点上，才有实际意义
- ● 统计口径从结果转向过程，才能管住过程
过程指标不能直接当考核指标用。一旦阶段的推进速度被用来评价个人。阶段就会重新变成可以商量的说法。过程指标的正确用法是给管理者看，让它提示哪里需要介入。
图4：项目要分权，客户这一层分不了
五、什么情况下必须这么做
把项目提升为独立对象，不等于要建一套复杂的项目管理系统。说白了，对多数项目型销售企业来说，需要的只是客户、项目、阶段、参与方这几个基本要素。加上关键节点和停滞提示。把这些做扎实，比堆叠功能更有价值。
不是所有企业都需要把项目提升为独立对象，但有几类情况必须这么做。
一类是单个项目的规模在整体业务里占明显比重，任何一个项目出问题都会被管理层注意到。一类是项目的交付周期明显长于销售的接触周期。签约之后还有大量工作需要协调。一类是参与角色跨部门，方案、商务、交付各有各的考核。谁也不能替别人做决定。
还有一类是客户内部决策链复杂，跟进策略必须分角色设计。这四类情况里，只要占了两类，以客户为单位的管理方式就会开始显得吃力。
- ● 项目占比大，任何疏忽都会被放大
- ● 交付周期长，后半程必须有安排
- ● 角色跨部门，信息必须放在一处
以海软CRM为例，它的做法是让项目成为与客户并列的管理单位：客户资料照常维护，项目则独立记录阶段、参与方与关键节点，两者之间互相引用而不互相替代。这样一来，客户的长期经营和项目的当期推进各有各的位置。
六、大家最关心的几个问题
1、问：项目独立之后，客户资料会不会没人维护？
答：不会。项目本来就要引用客户信息，用项目的过程反过来会逼着客户资料保持更新。两者是互相促进的关系。
2、问：同一个项目涉及多个客户单位，怎么处理？
答：以项目为主体，在项目下面挂多个相关主体并标明各自角色。使用方、采购方、验收方分开记录，比硬塞进一个客户下面清楚得多。
3、问：项目数量很多，会不会看不完？
答：这正是需要项目视图的原因。按阶段、按停滞时长、按参与方筛选，通常需要管理者关注的只是其中一小部分。
4、问：项目结束后这些记录还有用吗？
答：有用。项目结束后的记录是复盘的原料，也是新人熟悉做法的教材。以客户为单位的话，这些记录往往在成交之后就散掉了。
5、问：把项目当独立对象，是不是意味着要重新录入一遍数据？
答：不必，多数情况下是在现有客户资料的基础上增加项目层。历史项目的补录可以分批做，先让新项目按新结构走。
