CRM, kill me softly!

冯强/文

 

CRM, kill me softly!

 

这是我近段时间MSN的签名，虽然没有Killed这么严重，但SAP CRM上线的情况确实要让我崩溃了。

 

春节项目组通知停机6天，我们期望能彻底解决运行速度慢的问题，但结果是再次失望。IBM的人过来证明了硬件没问题，存储也升级了，服务器集群也到位了，但速度还是慢，而且不稳定，有时候不仅内部人员GUI登不上，服务商的Portal页面也会大面积的出问题。

 

我们是CRM的使用部门，所以我对于技术的细节并不太了解，只知道在所有硬件产商过来证明近百万的设备没问题后，神码、SAP的技术顾问似乎也是束手无策。春节那次停机，其实好象是把操作系统由Basis并不擅长的Linux换回了轻车熟路的Unix，但是系统还是没有起色。

 

目前内部GUI用户，繁忙时在线应该300左右，Portal并发1200左右。虽然我不懂后台的奥妙，但经常和一些业内朋友交流，觉得这不应该是硬件、操作系统或数据库的问题。我觉得诊结还是，SAP自身的Portal构架上的问题。这样并不太大的访问量，但由于SAP CRM内部层级和控制太多，造成了效率的低下，有顾问建议直接上小机就肯定解决问题。My God, 信息化真是烧钱的营生！（想起了某位企业老总讲的话，钱能解决的就不是问题，可惜我们不是垄断行业啊）

 

当初上线CRM时，其实我们的需求是要解决呼叫中心系统和维修业务集成的问题，所以我们当时更倾向于杭州某公司的家电维修软件（.Net构架）。我们是售后服务部门，客户挖掘、销售机会、渠道管理等并不是我们要去考虑的，所以从一开始并没有想到弄CRM这么大的系统。

 

选择SAP CRM，我个人认为对我部门（可能有点本位主义了）有“杀鸡用牛刀”的感觉，但之所以最终SAP中标，我事后分析有三个原因：

1. Oracle Siebel太贵，本土软件名气太小（将来用不好不好交代，实施人员出于个人增值考虑兴趣也不大）,SAP CRM刚刚好；

2. 公司SAP R/3用得还可以，考虑集成和将来全球化实施，信息部门肯定要高屋建瓴；

3. SAP的界面、后台、开发等大家都熟了，做生不如做熟。

 

CRM虽然还在推进中（6月前准备在全国推完），但其实大家用得很苦：

我们省中心的信管员都是零点爬起来导数据，以供调度主管进行用户跟踪；

呼叫中心因为系统慢，将用户来电先用记事本保存下来，然后补录到系统中；

服务商经常登不上系统，保存一张服务定单经常要用20多分钟，而且常常功亏一篑保存失败；

因为系统慢，呼叫中心去年12月份的回访还没完全做完，造成服务商的结算拖期（当然还有其他管理上的原因）；

项目组专门有人看在线用户状态，发现一个事务长时间没完成的，直接从系统中Kick掉某ID的进程。由于周末项目组休息，但服务不能休息，所以CRM届时就巨慢，大家戏称，CRM也要双休:(

 

这样的事情太多了，可以说每个用CRM的同事，都有一部辛酸史。虽然我2000年参与R/3上线，就知道信息化并不能一蹴而就，常常都要走很多弯路。但原来再怎么辛苦，都是公司内部的事。现在CRM系统不稳定，直接影响到了客户关系，甚至影响到了我们和服务商伙伴（Partner）的关系。

 

以前没上系统时，我出差拜访服务商，说起我们要上系统，他们都很期待。上次我去南昌出差，见到服务商，他们说你们的系统太慢了，界面也不好，做一张单子要保存N次，还不如我们在用XX的维修系统，你们这个系统纯粹是不懂售后的人写的。。。于是，把XX的维修系统调出来给我看。

 

那是用PHP/MySQL开发的二层构架的B/S系统，运行效率确实高，操作简单。可能不象SAP CRM可以支持所有语言和币种，也不能和SAP R/3“无缝”接口（其实到现在我也没看到SAP CRM能和R/3无缝接口），但确实能高效地解决我们和服务商伙伴的信息化需求。

 

我在想，也许信息化其实没那么复杂，被搞得复杂是因为我们考虑得太多了。

 

后记： CRM应该是基于一些应用系统之上的系统，没有这些系统的支持，CRM什么也干不了。