IBM WebSphere Commerce是IBM WebSphere软件品牌下专业致力于电子商务解决方案的软件产品。在经历了数十年的不断发展,以及在全球数以千记的客户成功应用之后,已经形成以商品管理、销售管理、订单管理、用户管理、营销管理等为核心模块,以电子商务行业最佳实践为支撑的一整套解决方案。
从基础架构上来看,WebSphere Commerce是构建在WebSphere应用服务器平台的极其庞大而复杂的J2EE应用。因其模块繁多且复杂,所依赖的软件产品众多,对不同客户所要进行的定制工作量巨大,因此WebSphere Commerce项目的实施难度超过了一般IT软件项目实施。特别是对于我国这样的电子商务的新兴市场,各行业的电子商务业务还不规范,不同客户的需求更是五花八门,对于WebSphere Commerce在中国的实施就存在着更大的风险。
笔者刚刚经历了国内某著名运动品牌的WebSphere Commerce实施服务项目,该项目已于近日完成B2B一期的实施并按期成功上线。此项目从2009年年初启动,历时近半年,经历了从需求调研、产品差异分析、解决方案总体架构设计、模块设计、开发编码、功能测试、系统集成测试、安装部署、历史数据迁移等一系列完整项目生命周期活动,最终在IBM实施团队,合作伙伴实施团队以及客户的共同努力下,成功实现项目目标并按时上线,的确是得来不易。这其中积累了非常多宝贵的成功的经验。总结起来,我们认为,对于WebSphere Commerce这样具有鲜明行业特征的大型企业级软件在中国的实施,决定其成功有三把取胜之匙。
取胜之匙之一: 尽早控制并降低风险
一个IT项目从启动之日起到最终上线,都要经历各种各样的风险。如何控制并尽量减少这些风险,并且降低风险对项目的影响,是决定项目成败的关键因素。我们的经验是,一定要尽早做项目风险分析,并且尽早采取一切必要行动控制风险,防患于未然,减小风险发生的可能性并降低风险的破坏程度。
在实施阶段IT项目的风险主要包括业务风险和技术风险。业务风险主要是指由于对客户业务需求了解的不充分,导致IT实现与客户的实际业务操作有差距,客户业务无法在新的系统有效开展,致使无法顺利通过项目验收,返工,最终导致项目延期甚至失败。这部分的主要困难在于,对于客户业务的熟悉和了解一般发生在项目的早期需求调研阶段,这时候实施团队刚刚进场,对于客户环境以及客户真实的业务缺乏最基础的了解,而由于项目时间的压力或客户时间的限制,需求调研往往不能充分的开展就匆匆进入设计和开发阶段,而在这时才发现对于某个业务细节了解并不确切,或者重新约见客户了解需求,或者按照自己主观臆断进行设计和开发。无论哪种情况,都既浪费了时间,又面临着与客户需求不符的极大的风险。所以,对于Commerce的实施项目,需求调研一定要充分细致的开展,宁可在这一阶段慢一点,在对客户实际业务的每一个细节都充分掌握之前,都不要仓促进入设计和开发。我们在项目中对于控制项目业务风险主要做到了下面几点:
1. 为需求调研阶段预留了充足的时间,在5个月的整个项目实施周期中,需求调研就进行了2个月。
2. 驻扎客户现场,与客户频繁而深入的交流,对于每一个需求点都进行反复的确认,与客户达到充分的一致。在此项目中我们共进行了三轮需求调研:第一轮主要是确定项目范围和一级模块,以及非功能需求,确定项目的日程表和总体项目计划;第二轮调研是跟客户IT人员或个别业务主管人员进行,确定每个系统模块的功能划分划分,粗略的产品差异分析,确认潜在的风险和问题,生成二级功能点;第三轮是详细调研,分模块跟客户基层业务人员一起进行,生成三级业务功能点列表和业务流程图,和客户进行正式的需求汇报,客户签字确认,成为正式指导设计实现的项目文档。
3. 需求以业务流程为核心,而非以功能模块为核心。
4. 在需求调研结束前向客户领导和主要的业务人员进行一次正式的需求汇报,主要包括业务流程和业务功能点列表,了解认识差异并更新需求文档,最终和客户在需求上达成完全的一致。
项目实施的风险同时也包括技术风险,同样也需要尽早明确尽早采取行动。在该项目中对于技术风险的控制我们做到了以下几点:
1. 在总体架构设计早期,确定总体技术选型和实施方案。技术选型立足简单实用。在前台商店页面上,在传统B2B商店的基础上尽量少改动;编程模式上,用的是传统而成熟的Command/Databean/EJB的编程模式;后台管理工具上,用的是稳定实用的Tools Framework;接口集成方面,也尽量采用文件传输,数据共享等集成方式。这些简单实用的技术为项目减少了技术方面的实施风险。
2. 在设计阶段后期,组织进行一次正式的设计评审,邀请IBM Commerce团队最有经验的架构师和实施专家对每个模块的设计进行评审,找出模块设计中的技术缺陷,更重要的是发现一些因为各个模块孤立设计而考虑不到的问题,解决了一些模块划分之外公共的问题。整个设计评审历时4天,有效解决了项目中的技术问题,降低了项目的技术风险,这也成为在整个项目周期中在技术方面没有出现较大过失并导致返工的主要原因。
3. 在进入开发阶段之前,进行了具有针对性的培训。本次项目的开发工作主要由合作伙伴的开发工程师来承担,他们的技术能力和对WebSphere Commerce的熟悉程度各不相同,为了在短时间内能够让他们具备此项目必要的开发技能,我们做了一系列有针对性的培训。比如本项目最主要的开发工作集中在EJB和Tools Framework的开发,我们就做了EJB和Tools Framework的Step by Step的培训,以项目真实功能点为范例,并从项目中找到若干简单易做的功能点做为培训练习。这样开发工程师就接受了有针对性的非常实用的开发培训,并拿到了可参考的手册和样例,这样对于他们迅速上手进行开发提供了很大的帮助。
4. 在进入开发阶段之前,制定了开发流程规范和编码规范。项目规范化开发对于提高项目质量,便于后期维护,减少返工率都有着非常重要的作用。我们在开发之前就参考WebSphere Commerce在世界范围内的优秀经验,制定了项目开发流程规范和编程规范,并要求每一个开发人员学习并严格遵守。
取胜之匙之二:项目经理是关键
对于任何一个IT项目来说,项目经理都是决定项目成败的重要因素,对于WebSphere Commerce实施项目,则更是如此。WebSphere Commerce实施项目以其产品的复杂性和鲜明的行业特征,要求项目经理无论对产品和行业都有一定的了解和整体把握,对于项目更是要有强有力的控制力。同时WebSphere Commerce实施项目也具有更多的内部和外部制约因素,也就要求项目经理更加频繁和有效的沟通。刚刚结束的这一项目项目经理由合作伙伴担当,总结在这一项目中的成功经验,我们认为在WebSphere Commerce实施项目中,一个好的项目经理需要做到:
1. 随时洞悉项目进展,识别、追踪并严格控制项目当前的关键路径,立即采取行动促进关键路径的进度。
2. 对项目资源的整理把握和调度,特别是人的资源。在项目早期还未全面进入开发阶段时能够安排已进场的工程师承担一些工作,例如培训的练习,可直接开发的功能点等。这样对于提高人员的使用效率,在团队中始终保持紧张高效的工作氛围都有很大的好处。
3. 时刻保持对项目进度、风险和质量的忧患意识,通过对项目的宏观把握尽可能早的发现问题,解决问题。对即将要做的事情,尽早作出安排。总之万事提前一步,提前考虑,提前安排,最大限度减少了因为任务依赖性而导致的资源浪费和进度拖延。
4. 良好的沟通和及时的调整,主要包括和客户,项目开发人员以及其他的内外部影响因素。项目经理和项目团队与客户有良好和通畅的沟通,定期主动的汇报项目进度,积极澄清需求和问题,汇报问题时实事求是,客观分析,有需要客户配合和合作的也及时提出,这些都有利于客户对项目和团队的信任。此外,如果条件允许驻扎在客户现场实施也是促进与客户沟通的好方法。团队内部也保持沟通的通畅,特别是这次项目实施团队也由合作伙伴、IBM工程师等多方组成。项目经理和技术负责人之间能够彼此交换意见,及时解决项目中出现的问题。通过内部和外部的沟通,项目进度和计划立刻做相应的调整。
取胜之匙之三:合理控制客户期望
对于WebSphere Commerce实施项目,合理控制客户对于项目的期望非常重要。首先,在业务上,中国大部分想要实施电子商务的客户对于电子商务的业务模式,以及电子商务能够帮助他们做什么并不十分了解。尤其是对于那些已在线下运营了多年的传统行业客户,他们已经形成了非常成熟且固定的线下运营模式,在搬到线上时难免会用线下思维和习惯来要求电子商务系统,而这其中的大部分对于IT实现是不现实的。一定要在项目启动之时就让客户了解线上业务开展的模式,以及与线下业务的区别。这样的概念引导可以通过对产品的介绍、对典型电子商务业务的介绍以及对客户业务需求的IT描述来进行双向沟通,不仅仅针对于客户领导和客户IT团队,更要深入到每一个将要对系统进行实际操作的业务人员,从而避免客户验收时以惯有思维要求IT系统而带来不必要的困难。
另一方面,WebSphere Commerce是一个功能繁多的庞大的软件,但是它也有其擅长和不擅长之处。WebSphere Commerce擅长的是网络销售渠道的建立,网上销售,订单的捕获和履行,网上营销的开展,多渠道的整合以及对于外围系统的集成等等,总而言之对于企业典型的“进销存”业务来说,WebSphere Commerce最为强大的是“销”。然而对于大部分国内客户,信息化程度不高,IT系统建设不完全,同样希望用WebSphere Commerce帮助他们完成不属于典型电子商务业务的部分,比如采购,比如库存管理、仓储管理和物流管理。对于这两部分,我们的典型解决方案是将 WebSphere Commerce与外部采购系统和库存系统进行集成,如果客户需要我们用WebSphere Commerce也来实现这部分的功能,我们需要尽早告知客户,这些部分并不是WebSphere Commerce默认提供或者实现良好的功能,需要全新开发或定制,在有限时间和人力条件下即使实现出来也仅仅是着眼于满足客户当前的业务需求,有一些复杂功能无法实现,请客户充分理解并降低客户对这些模块的心理预期。
第三,对于一个项目来说,时间、成本和质量是永恒的三元组,对于固定项目周期固定投入的项目,又要保证项目质量,就要做到合理控制项目范围。一开始客户的需求肯定是多种多样,而且绝大多数需求都是合理且必要的。但是在固定项目周期内,我们只能根据现实人员投入和客观实施估算确定项目实施范围,一些不是特别急需的或者可以用其他方式替代的功能就暂不实施,或延后或取消取决于客户对项目的进一步投入。这些业务功能的取舍一定要尽早和客户充分沟通,让他们理解取舍的原因,并且清晰了解最终上线系统的功能范围。
以上列出了在刚刚成功上线的WebSphere Commerce实施项目中我们取得的一些成功经验。当然这其中的经验和教训还有很多,但是这三条是我们认为比较有价值并值得借鉴的部分。希望这一经验能够沿用到今后的WebSphere Commerce实施中,成就更多的项目和客户,为客户实现业务整合和自动化升级,创造更大的价值!