三边工程让企业的CRM项目走进了死胡同

三边工程是指边计划、边实施、边修改。三边工程是对早期IT项目特点的高度概括，很具有代表性。但是CRM项目发展至今，已经成为了企业信息化管理的重要组成部分。如果现在再搞三边工程，无疑会将CRM项目带进死胡同里面去。为此笔者是坚决反对搞三边工程的。

计划：不先做规划，就直接上CRM项目

笔者以前有一家客户，他们的客户要求他们上CRM系统。为了满足对方验厂的需要，根本没有做任何规划，就直接上了一套CRM系统。到现在这个CRM系统已经用来有4年了，问题也逐渐暴露出来。如没有做好规划，而无法跟企业现有的ERP等信息化系统进行集成。由于CRM系统的某些作业与ERP系统的作业是重复的。为此用户有些作业要做两次。如客户信息的录入与审批等等。这些重复性的作业，都是缺乏事先的规划所造成的。

那么在实施CRM项目之前，企业IT负责人该做哪些规划呢？笔者认为，至少应该包括如下三个方面。

一是企业未来信息化的应用

如在考虑上CRM系统之前，企业IT负责人，要对未来的信息化管理手段做一个规划。如是否会上ERP系统、是否会实施BI项目等等。如果未来的五年到十年之内，企业有这方面的预算，那么在选择CRM软件提供商的时候，就需要考虑到未来与这些信息化管理系统的之间的集成。毕竟这些信息化管理系统都有相互重叠的地方。如果在规划时就能够考虑到未来集成的需要，那么在后续工作中，就可以避免重复性的工作，以提高工作效率。

二是企业未来使用的操作平台

虽然现在企业主流用的是Windows操作系统平台，但是现在这个平台的弊端也在逐渐的显现。如不够稳定、容易遭受攻击。而且随着国家加强对盗版的打击力度，可能在不久的将来，企业将不能够使用盗版的操作系统。此时企业就需要花费巨资去购买正版的操作系统。为此可能以后企业会转换现有的操作系统平台，如使用免费的Linux操作系统等等。在做规划时，就需要考虑到未来是否会有这方面的转型。因为现在大部分CRM软件都不是跨平台的。即能够在Windows操作系统平台上运行，但是却无法在Linxu操作系统上使用。如果IT负责人有打算更换操作系统平台的话，那么在做规划时，就要考虑到这个问题。

三是关键用户的培养方面

CRM系统对于企业来说，就是一个工具。这个工具要应用的好，关键还在于关键用户。为此在项目规划时，要对企业CRM关键用户的培养有一个总体的规划。举一个简单的例子，在做规划时，不能够每个部门只有一个关键用户。如果这个关键用户离职的话，那么谁来负责这个部门的CRM作业呢？笔者建议，至少每个部门需要有两个以上的关键用户。此时如果一个关键用户离职的话，剩下的这个关键用户还可以带带新人。在做前期规划时，对于人员方面的规划也是很重要的一个工作内容。

实施：边走边看，确定项目需求

边实施就好像是一个不会和面的人在那边和面。面粉多了加水，水多了加面粉。最后把自己都糊到面团里去了。显然这么实施CRM项目，必定将以失败告终。笔者对边实施的工程做了一个总结，大家看看是否有道理：走的时候不知道要去哪里；去的时候不知道到了哪里；回来的时候不知道去过哪里。这就是对边实施工程的一个形象比喻。在实际工作中，要杜绝边走边看的不良行为。笔者认为，要做到如下几点内容。

一是在CRM项目开始之前，需要对CRM所涉及到的领域有个大致的划分。做过CRM的读者一定知道，CRM项目所涉及的领域可大可小。如果事先不对其进行界定，而是边走边看，那么最后需求就会像滚雪球一样，越滚越大。这不仅会提高项目的成本，而且还会扩大项目的风险。故在项目开始之前，需要对CRM的范围做一个界定。如果超过这个范围了，并且需求也是合理的，也需要放到二期中去实现。

二是需要注意，不要被软件提供商所忽悠了。有些企业，CRM实施顾问与软件提供商是同一家。有过美容经验的用户，可能在做日常护理时，对方会不断的向你推销产品与服务。有时候一不小心，就被对方所忽悠了。其实在CRM项目实施时也存在着这种情况。实施顾问在实施过程中，会像用户推荐再使用什么什么模块。此时企业用户就要保持清醒的头脑，要勇于说不。而不要对方推荐什么、就是用什么。

修改：边做边改，离预定的目标越来越远

虽然说计划没有变化快。在CRM项目实施过程中，对预定的需求与计划进行调整，也是情有可原的。但是这个更改一定要在可控的范围之内。可惜的是，不少企业在实施CRM项目时，由于更改过多，使得CRM项目脱离了轨道。笔者建议，在一定的范围之内，更改时可以的。具体的来说，要做到如下几点。

一是每次做调整之前，需要回头看看，我们预先定义的目标，是否会偏离。

在实施CRM项目之前，企业需要定义CRM项目所需要实现的功能、上线的时间、项目的成本等等。如果在实施过程中，需要对CRM项目进行更改，那么IT负责人要回头看看这些预先定义的目标是否冲突。如果所做的更改，会延长项目上线的时间或者突破项目的成本，那么此时就需要谨慎对待。笔者的意见时，如果出现这种情况时，就不要更改。因为这个原则一打破的话，就会有第二次、第三次。如果用户提的需求确实有道理，IT负责人可以先记录下来，然后将其放在二期工程上执行。

二是在项目过程中所做的更改，要有比较翔实的记录。

这包括更改的背景、如何进行更改、用户与实施顾问的意见、更改后的调试以及相关注意事项等等，都要有很详细的记录。如此的话，在后续维护时，如果这里出现了问题，那么查看相关的文档，对于解决问题来说，能够提供很大的帮助。只有如此，才不会出现“回来的时候不知道去过哪里”这种奇怪的现象。笔者这里需要特别强调一点，任何更改在事后都要追踪一段时间。看看所做的更改是否达到预计的效果，以及是否与现有的需求有冲突等等。

三是更改的方式

笔者并不是全面否定在实施过程中进行调整。在必要时可以对项目的计划、需求、流程等等做出合理的调整。如果在这个调整的过程中，要考虑怎么调的问题。笔者举一个简单的例子。现在有一个客户审批流程，企业现在操作的流程与系统流程不一致。此时就需要对流程进行调整。这个调整有两个方式：一是更改用户现在的操作流程，二是更改CRM系统中的流程。

笔者的建议时，首先考虑更改用户的操作流程。因为系统中的流程是经过很多用户实践证明是有效的。而企业现在所使用的操作流程，可能存在着一些用户自己无法发现的漏洞。现在使用系统的流程来规范企业的操作行为，正好可以消灭这些漏洞。不仅可以让企业的作业更加安全，而且还能够避免二次开发带来的成本支出。只有在评估后，发现系统的流呈确实无法满足企业的需求，或者说会大幅度的增加用户的工作量。简单的说，就是在使用CRM流程时得不偿失的情况下，才考虑通过更改系统来实现。