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