已经有大半个月没写项目手记了，除了工作繁忙，需要考虑和调研的东西太多以外，项目进入蓝图阶段，项目组（包括顾问方）都开始谨慎了起来。
对于企业来讲，变数是随时会发生的，呼叫中心不仅会收缩到5个点，而且会从多媒体公司里面剥离出去，放到平台部门。这样管理是不错的，但目前所谓的呼叫中 心，其实还仅仅是个电话中心，其运作受制于电信4008和系统不完备等因素。其次，由于其业务并未成形，割裂后会造成信息接入和业务接口的衔接问题，能否 降本和提高效率也是问题。本来，领导准备把呼叫平台和CRM全部放到平台上去，但最后的结果是分离，也许公司是在为呼叫业务将来的外包做准备吧。对于我而 言，相当于丢掉了一个包袄，可以把工作重心集中在CRM和相关的ECC、BI、SCM等系统的管理和研究上面。
讲一下未来蓝图的研讨方面，一部分人（如备件处）对CRM寄予了太高的期望，提的要求超出了CRM管理和本次实施的范畴，搞得项目组都很郁闷。但我告诉项 经，有期望终归是好事，至少他们有热精，在关注这个系统，关键点是大家求同存异，以业务为主线，确定一个契合点，或叫“妥协点”。把CRM系统可行的底线 给他们，让他们来确定流程；还有另一部分人，可能平时研讨时都不怎么提问题，电子文档反馈时也没问题，一旦打印出来让他们签字时，问题就来了。项目组应充 分关注这部分用户，因为可能他们的需求并未在前期充分表达出来，后续实施时对流程实现会抵触，甚至推翻重来的风险主要来自于这些用户相关的业务。
我最近抽时间在看顾问方带过来的SAP CRM Library，发现很多地方在IDES系统里面都不一样，后来才发现文档是CRM 5.0的，而IDES却装的4.0。据说，是因为神码顾问带错了IDES光盘，真是太不小心了。如图（IDES版本号）：
另外，对SAP我也要批评一下，汉化做得不好也就算了，IDES里面居然还有很多界面还是德文的。如图：
其实，用过SAP R/3生产用户的朋友都晓得，至今SAP也只是汉化了用户常用的一些事务界面，还有很多配置和开发界面是英文的，常常还会不经意地弹一些德文提示框出来。在本地化方面，SAP应该向微软好好学习。
说一下我对SAP CRM的感受。
SAP CRM按它自己文档的说法，主要适用于医药、快速销费品和高科技领域，长虹是家电行业，被归入High Tech虽然说得过去，但其实很多业务流程在CRM里面并没有标准的流程可以套用。我也看过其它一些国外和国内的CRM或售后服务系统，并不一定比SAP CRM差，有些甚至提供一起拿来就用的功能，或者根本就是为家电业设计的。
当然，SAP CRM对于已实施SAP R/3或ECC的企业是很有吸引力的，基于SOA的无缝集成是Sales的杀手锏之一。但真正实施起来，我们才发现CRM作为一个独立的产品，和ECC的交流并非那么无缝。SAP CRM的实施，和R/3实施有很大不同，标准的东西除了一些主数据和基本的流程外，二次开发的东西太多，不客气地讲，顾问公司其实是以SAP CRM为范本，来为客户做CRM开发。所以，SAP CRM最终实施成败和效果，除了取决于需求调研和流程设计外，更重要的是顾问方开发和解决问题的水平。我的总体感觉，SAP CRM并非是一个很成熟的产品，至少对于传统家电制造行业是这样，也许经过长虹这个项目，他们会把长虹的很多经验放到“SAP最佳实践”(SAP Best Practice)里面。
神码的顾问曾私下抱怨，他们从来不敢对业务方说“不能实现”，这是很奇怪的。我觉得他们可能更多地站在了开发者的角度来做项目，而没有作为业务咨询顾问来 做项目。这其实有很大的区别，业务方提的要求并非完全合理，不经过BPR而是完全Copy现有业务流程（仅在细节上做些小调整）的CRM项目，上线后将为 后续运作带来隐患。这样的系统（以业务为中心，而不是以客户为中心），将很快不能适应公司对服务的要求，上线时片刻轻松将带来无限的麻烦。
顺便说一句，长虹的CRM项目还没进入开发阶段，已被神码作为成功案例到处讲了，这样不好。
链接：《SAP CRM项目手记》系列
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
