crm项目管理中的长通路与短通路.doc

CRM项目管理中的长通路与短通路
在渠道管理中，如果只经过一个经销商，称之为短通路;经过两个或者两个以上经销商的，则称为长通路。经营者需要对营销通道是长的好还是短的好，做出慎重的选择。因为两者各有利弊。从节约成本、降低费用的角度考虑，经营者最好利用短路，但是，从长远发展考虑，则应该考虑长的渠道，利用别人来帮你赚钱。其实，不仅在渠道管理中，有长通路与短通路的抉择，在CRM项目，也有类似的考虑。
　　如我们在实施CRM项目的时候，项目负责是是直接对每个员工负责，跟每个CRM系统操作员面对面;还是直接对每个部门经理负责，让他们去面对他们手下的员工?其实，这就是一个长通路与短通路的问题。若我们项目小组负责人直接对每位员工负责，那么我们可以收集到一线的信息，而且，这些信息不经过部门经理传达，则可能更能够反映员工的实际意图。但是，这么做的话，企业也是需要付出代价的。如我们要依次向员工索取需求，则需要花费我们比较多的时间;而且，我们还需要对这些信息的价值进行刷选，因为有些可能只是代表员工自己的意见，而不是这个部门的整体价值的体现。而若我们在项目的实施过程中，选择常痛录，即我们只对部门经理负责，然后部门经理再在部门内部推广CRM项目，一级一级的推广下去。如此的好处，就是我们项目负责人不用劳神去收集各个部门的需求，而可以抽出时间来想想解决方案。不利之处就是通过长通到获取的需求是经过部门经理处理过的，有时会出于表达方面等的原因，我们得到的需求可能已经变味了，或者不能够真实反映业务的实际情况。不过这两者之间还有一个最大的差异，就是若通过“短通路”的话，一个CRM项目结束后，可能各个部门的负责人在我们顾问离去后，仍然不能担负起系统完善的重任，因为他们不知道如何去收集需求、如何改善系统;而若采用“长通路”的话，则就是给各个部门负责人一个锻炼的机会，让他们能够成本自己部门模块的负责人，给了他们一个需求收集、项目推动、员工培训的锻炼机会，如此的话，项目上线后，即使我们实施顾问离去了，则他们仍然能够承担起系统完善的任务。因为经过项目实施的历练，在我们实施顾问的指导下，他们已经学会了一些系统完善的技巧。所以，若从企业长远发展的角度看，从系统持续完善的角度考虑，则很明显，采取“长通路”的项目实施方法，更有利于企业发发展。

　　所以，笔者认为，在CRM项目实施过程中，要采用“长通路”为主，“短通路”为辅的策略。具体的来说，笔者可以给大家提如下的一些建议。
　　1、利用“长通路”，为企业培养出几个内部项目实施顾问。我们都知道，CRM项目实施的话，一般只有短短的几个月。CRM项目上线后，项目是否就结束了呢?其实不然。CRM项目上线后，项目只是取得了暂时的顺利。CRM系统的后续完善，才是CMR项目的重头戏，这个系统的完善，可能会伴随企业发展的下半辈子。而系统的完善，基本上是CRM实施顾问离开后的事情，也就是说，此时，企业需要自己进行CRM项目的持续改善工作，实施顾问只能做一些偶尔的指导。所以，利用长通路的实施方法，在企业内部培养出几个实施顾问，让他们在实施顾问离去后承担项目改善的重任。只有如此，企业的CRM项目才能够良性的发展下去。
2、长通路，可以利用部门经理的经验，先过滤一遍需求。企业员工的需求，哪些是急需的，哪些可以暂时放一放;哪些是共性问题，而哪些又是个别现象;在系统中需要实现哪些需求，不需要实现哪些需求，等等。这些内容的话，我们实施顾问都不能够替企业决定。而若我们现在不是自己去向员工去收集需求，而是借部门经理的手，去向员工收集需求的话，则部门经理就会事先把需求过滤一遍，从而得出的需求质量会高一点。同时，我们可以给部门经理提出一个要求，让他们在每个需求前面标上序号，表示需求的重要性与实现顺序。显然，这些工作的话，都需要部门经理完成，我们实施顾问不能越俎代包。
　　不过利用“长通路”实施方法有一点不好，即需求通过部门经理来进行传达的话，有时他们传达的需求可能跟实施上有比较大的差距。笔者在CRM项目实施过程中，遇到过多次了。如部门经理反映的需求是要能够统计客户投诉的处理效率，要有一张报表能够反映出客户投诉处理了哪些，以及是否在规定的时间内处理完成。但是，后来在项目实施的过程中，部门经理几次修改需求，原来这个需求跟他下面员工的实际需求差别比较大。下面的员工希望是能够通过报表自动统计投诉处理的客户满意度、相关的责任人等信息。后来还是笔者跟实际的操作人进行面对面的交流，才了解员工真正的需求。
　　所以，在使用“长通路”方法实施CRM项目的时候，我们要扬长避短，发挥长通路实施方法的优势，而避免其不足的地方。笔者在项目实施的时候，是通过如下方法来达到这个目的的。

　　1、当一些需求表达不清楚的时候，最好能够让用户提供他们所期望的表单或者报表格式。有时候，我们实施顾问可以要求企业用户提供相关的报表格式，并注明各个字段的含义。若有相关计算的，则还需要列出计算公式。如此的话，就有助于我们了解用户的真正需求，这也可以有效避免部门经理传达需求时所产生的口误。而且，有了这些单据的话，我们也可以事先在系统中配置出来。从来理论上来说，只要系统中有的数据，我们都可以在报表中体现出来。不过用户在设计报表的时候，也必须考虑逻辑性与实用性。也就是说，用户在整理报表或者表单的时候，最好是在现有的表单基础上，进行适当的修改。而不失从零开始，根据自己的想象进行重新设计。根据笔者的经验，如此设计出来的报表往往过于“完美”，而在实际工作中，用处不是很大。
　　2、对于意思模糊的需求，我们不要盲目在系统中实现，以免做无用功。当用户的需求比较模糊时，而系统中又没有对应的功能，一般需要通过二次开发实现。碰到这种情况，无论是我们实施顾问，还是企业用户都不要急着实现这个需求。而是需要先向用户了解清楚需求的内容。一般来说，这个需求模糊的原因，可能有两种情况。一是部门经理也不是真正的需求人，所以，他可能描述不清楚具体的内容。此时，我们实施顾问就需要走“短通路”，让部门经理找来当事人，面对面的进行交流，往往能够取得不错的效果。还有一种原因就是企业员工自己都不知道需要什么。他们可能在以前的公司中遇到过类似的报表或者功能，但是，若让他自己描述的话，就描述不清楚了。此时，按照我的意见，就是先把这个需求放一放，让用户仔细想一想，然后设计出一个管理模型出来，然后我们实施顾问给与优化。当然在这个管理模型的设计过程中，用户也可以跟我们实施顾问保持联系，听听我们对于这个模型的建议。总之，对于模糊的需求，笔者的建议是，要到弄清楚才能够实现，而不能在模模糊糊的情况下，配置系统。
3、某个需求实现后，就要马上交给用户进行测试，看看是否跟他们的期望一样。其实，就是沟通的最好，由于文化背景、工作经验的差异等等，难免有误差。所以，笔者认为，根据用户的需求配置好系统后，我们要及时把结果反馈给用户，让他们来判断这个功能跟他们想象中的是否一样。但是，有些软件公司或者实施顾问，希望把所有需求都实现后，再把结果反馈给用户。这么做得话，有一个最大的缺陷就是，企业用户不能够一一判断需求是否满足他们的要求，但是为了赶
项目的进度，就匆匆忙忙上线了。结构在上线的过程中，才发现企业员工、部门经理、实施顾问三者之间存在着比较大的认识差异。此时，就不得不再对系统进行开发、配置、调试，这对CRM项目的影响是很大的。