在CRM项目部署过程中，我们首先需要遵循标准业务规则。但在这个过程中，由于各个企业业务、文化背景等不同，也会在一定程度上存在着一些个性化的内容。无论是作为企业的项目管理员，还是项目的咨询实施顾问，都必须正确面对这一点。如果一味的抹杀企业的个性化需求，那么，CRM项目离失败也就不远了。所以，企业必须关注如何才能够快速的构建适合企业“厂情”的个性化CRM系统。
  首先，通过工作流控制为首选
  　　在项目需求调研、实施的过程中，若发现企业的个性需求是合理的，那么实施顾问就有义务帮助他们实现。但问题是，到底应以哪种手段来实现这些需求呢?当然，选择合适的个性化需求实现方式，确实能取得事半功倍的效果。但是如果实现的手段不合适的话，那么就会影响到系统的稳定性与项目的实施成本。
  这里有一点是尤其值得注意的，就是有一些心黑的软件提供商，他们不是根据需求来选择实现方式，而是根据利润。简单而言，即答应给企业免费开发的一些需求，他们可能会采用工作流控制、后者平台来实现，因为这可以大大的降低软件开发公司的开发成本。反之，对那些收费的二次开发需求，就算是可以通过工作流控制或者平台等功能来简单的实现，但是软件公司仍然可以采取通过修改源代码的方式来实现。因为这可以为软件公司争取更多的利润。
  因此，在构建个性化的CRM系统之前，企业项目管理员需要了解个性化需求实现的相关手段，并了解他们在对系统运行的稳定性、项目的实施周期、成本等方面的不同影响。
  另外，当遇到个性需求时，企业首先要想到的是通过工作流的手段来实现。因为目前大多数的CRM系统都已经集成了工作流模块。一些个性化需求完全可以通过配置工作流系统来实现。如新客户的审核流程中，可能需要信用额度、付款方式、付款条件、客户基本信息(如营业执照)等等信息的审核。其中涉及到不同的部门。这对这个个性化需求，就可以通过工作流系统，将不同的不同虚拟到同一个流程之中，加以实现。
  那么，为什么笔者将“通过工作流方式来实现个性化需求”定位为首选的方式呢？这是因为主其有如下三个优点：
  　　1、成本低廉、实施的周期短。通过流程控制来实现，无需涉及到源代码的开发，测试的工作量也少。所以，其实现成本不仅较低廉，而且周期也比较短，更不会影响到项目的整个实施计划。
  2、企业用户的灵活性高。由于流程控制不会涉及到源代码成面，所以，不少软件公司都会将这个功能开发给用户。一旦用户掌握了相关的配置技巧，就可以根据自己企业的实际情况来进行配置，从而主动权是掌握在用户手中的。
  3、对系统的稳定性基本不会有影响。通过流程来实现个性化需求就好像房屋装修过程中的改变室内布局一样，只要不涉及到承重墙(源代码)，就不会对整幢房屋的安全性产生影响。
  　　综上，企业对于那些必须要实现的个性化需求，首先考虑的是通过系统提供的工作流模块来完成(如果系统提供这个功能)。而只有在这个无法实现的情况下，才考虑其他的手段。
  其次，通过平台实现功能的再定义
  　　当某些功能工作流模块无法完成，如需要定义一张客户评价的报表或者在客户信息中增加一项内容，这个时候，通过工作流就无法实现。因此，在这种情况下，也不一定需要修改原程序。企业还可以考虑选择平台来对功能进行再定义。
  　　目前许多软件公司为了提高市场竞争力，都会开发一些平台，方便对一些功能进行二次调整。如金蝶的ERP与CRM软件中，就提供了K/3BOS平台。这是一个面向业务的、开放的集成与应用平台，具有比较强大的业务配置和开发能力。通过平台来实现二次需求，有这样一个共同点：很多情况下，用户不需要修改源代码即可实现。这不但能保证系统的稳定性，而且又提高二次开发的效率。
  　　但通过平台来实现功能，其有一个限制，即不会改变系统的主流程。这就好像一棵树。通过平台之能够改变树的枝叶，如添加或者删除，而不能够改变树的主干。与其说这是一个限制，还不如说这是这个手段的优点。因为有了这个限制，就可以保证用户的修改不会影响到系统整体运行的稳定性。
  　　通过平台来实现二次需求相比于第一个方式，往往需要在软件公司的协助下才能够完成。一方面通过平台来实现一些功能，有可能需要编写一些简单的代码，如定义报表时需要sql查询语句等等;另一方面在后续CRM软件版本升级时，也必须考虑到这方面的内容。所以，这往往需要企业与软件公司两方面相互配合才能够完成。还有一点需要注意的是，就是通过平台来实现的新功能，在使用之前需要做好相关的测试，不管是后台数据库中增加表或者字段，还是在前台增加一个窗口，都可能会对其他的功能有关联。在投入使用之前，需要确保这些关联不会产生负面的影响。因此，从测试量来说，要比第一个方式多的多。
  　　鉴于以上原因，通过平台来实现二次需求是一个中性的方式。从总体成本来说，要比通过工作流方式要高，但是比二次开发却要低。
  最后，二次开发不得已而为之
  　　因为其不管是通过哪一种来实现，其有一个共同点，即基本上不会涉及到后台的源代码。所以其实现的功能也是有限的。如客户信息的审核动作就无法通过前面两种方式来实现。换言之，虽然这两种手段都具有一定的优势，但是可能仍然无法实现企业全部的个性需求。在一定的情况下，企业仍然需要通过二次开发来完成一些比较复杂的需求。
  　　尽管如此，但企业仍然要最大限度的降低二次开发的数量。因为二次开发的成本都是比较可观的，如有些软件公司都是按500元/小时/人的价格来收取。另一方面，由于二次开发会修改系统后台的源代码，不利于后续的维护。如需要进行软件版本的升级，那么就会遇到麻烦。软件公司可能需要针对这个个案专门设计升级的方案，无论是成本还是周期上都会带来负面的影响。此外，由于二次开发的内容软件公司不会投入大量的精力去测试，所以，在稳定性上就会大打折扣。修改源代码，已经是伤筋动骨了。没有一定时间的磨合，是无法发现隐藏在其中的风险。
  　　为此，笔者建议，一般只有在不得已的情况下才通过修改源代码的方式来实现二次需求。同时，企业还需要充分认识到，如果采取二次开发的方式来实现需求可能会遇到的风险。但不管是采取怎样的方式来构建个性化的需求，有一项基础性的工作都是要做的，就是需要保留相关的原始分档。包括用户的需求分析、需求实现的具体细节、功能测试报告等。因为这些资料在后续的维护中是非常重要的。能在很大程度上降低维护、系统升级的工作量，尤其是当更换项目负责人时，这些资料的价值就更大了。