今天看到一篇文章，关于甲骨文银行项目失败原因分析，原文地址如下：
http://cio.it168.com/a2009/1215/824/000000824070.shtml
作者分析的比较深入，对导致失败的原因也分析的比较透彻，但是读罢，却总感觉有枪手嫌疑，背后有某些厂商在推动。
文中对甲骨文项目实施的困难及问题进行了分析。影响是关于与甲骨文合作说带来的问题分析，包含如下几点：
1.多产品线基于不同硬件平台，需要购置多套硬件设备分别部署应用。（理由是收购了PEOPLESOFT，SIEBEL以及Hyperion）
2.多产品线基于不同软件应用平台，如财务核算系统只支持Unix,管理会计系统只支持WINDOWS平台。
3.多产品线的人机对话、易用性较差，如财务核算软件基本实现文字面的汉化，而管理会计、风险管理等均为英文界面，且沿用国外金融行业术语，与国内的应用概念有非常大的差异，国内用户使用困难
4.产品线下无法完成系统的整合，不同的开发语言、不同的数据结构、不同的技术路线、重复的系统功能（如Peoplesoft也有财务管理、绩效管理），一旦银行选择其全套解决方案，将面临复杂、混乱的IT架构局面而无法解决。
5.针对国内的应用需求无任何支持。
6.开发源代码管理权在美国研发中心，不允许中国国内进行任何改动和优化，无法满足企业管理，尤其是金融银行的变革和发展需求。
7.采取特别强势的产品文化，对中国银行业实际市场经营环境和银行的经营管理现状考虑不够，要求客户完全遵循其软件产品定义，很少关心客户实际应用绩效。
这些分析确实很大程度上指出了目前ORACLE 中国所面临的问题。文中还举出了很多例子，说某些企业实施不成功，最后全部转向了国内的某厂商。
我对仁科的HR系统并不熟悉，只是听说前段时间阿里巴巴还准备实施PEOPLESOFT，个人感觉至少在HR领域，PEOPLESOFT还是牛叉的。
而SIEBEL的CRM，至少在目前来讲，无人能出其右。
Hyperion的BI在业界也大名鼎鼎。
当然，ORACLE EBS也不存在任何问题。
作者所举出的几项问题，我比较赞成应有需求支持不够，以及强势的产品文化，另外需要补充点是，合作伙伴的准入机制不健全，而且缺乏有效的监督。
至于其他几项，个人认为都不是问题。尤其是第六条，提出这个有些无趣，大家都知道跨国公司的源代码中心总归在总部。别说像这样的大型的产品了。就拿微软的任何一套产品来讲，除了测试和多语言技术支持，那项是放在中国的？
网上确实很难找到ORACLE EBS 的失败案例，毕竟家丑不可外扬，宁夏银行，哈药集团，以及上海农村商业银行的失败案例，能暴露出作者所说的问题吗？基本上都没有。我反倒从这些失败案例看出别的问题出来，第一，这些项目都有潜规则，尤其以农村商业银行为例，在这种情况下，实施和产品都是次要的。不能说是ORACLE的问题。第二，ORACLE 确实对实施伙伴管理不够。但是我们来想，如果是国外的公司来做实施的话，会不会效果好些呢？答案是否定的，国外的实施伙伴不会在意国内的这些潜规则。所以会失败的更惨。
说到实施伙伴的问题，确实深有感触，一次吃饭，同桌的一个客人，自我介绍，是企业管理咨询顾问，问及具体，说大学毕业刚三年，已经做了四个咨询项目了。还说准备进修MBA。再问具体做了哪些项目，以及想学习下管理咨询的方法。结果，他说软件是根本，凡是不匹配软件的流程，都改。估计目前的咨询公司里面这些人应该算中坚力量了。不是我这人挑刺，ORACLE 确实需要对实施顾问包括咨询顾问，做一个很恰当的准入机制。顾问是什么，某一个行业的顾问是这个行业的人精，至少对这个行业有很清晰的认识，而且能够按照软件和客户实际情况来提出解决方案。如果按照他那样的话，只能说中国钱多，人傻。
只有实施顾问整体能力上去了，实施的成功率才能上去。至于别的潜规则，我没有任何好的办法，中国大环境所致。我只能说利用一切自选尽量减少这些对项目的影响。
ORACLE 的可定制能力，二次开发灵活性比SAP强一个档次。而且未来采用的是JAVA.
文章所说的国内某厂商的产品，有过了解，确实，企业财务软件方面，他比任何国外的企业都适合国内市场，但是有一点，在于它的软件的思想，基本上还是代替手工操作为主，必要时可以为客户定制需求，价格比国外低了好几个档次。但是只能中小型企业适合，大型企业，这些软件确实不够合适。而最近推出的号称专为大型企业提供解决方案的平台。跟国外的产品比起来还是有很大的差距。
我不崇洋，只是希望在国内的企业经营，控制还没有完全摆拖暗箱操作的前提下。用国外的软件所承载的管理思想来约束下国内的企业，起码提供了一个标杆。在这个前提下，我们是不是该反思自身的问题呢？
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
