二、G公司三次选型的软件系统架构不利之痛 

    这个故事说的是G服装企业的选型经历，该公司2001年起一直处于高速增长状态。在2001年时，全国的专卖店约有800家左右，但到2007年，该公司已经是行业内的知名品牌，全国的专卖店达到3000家。而该公司的IT经理，暂且称他为Z吧，他们公司在2002年、2004年进行了两次DRP项目的选型，甚至直到今天，他们的选型故事还在继续，为什么在五年之内就对DRP项目进行三次选型呢？ 

    在一次聚会的时候，和Z聊起了这个话题，也就从中听到了一个围绕着DRP项目软件系统架构的故事。 

    第一次DRP软件选型：G公司在2002年的时候，由于当时公司规模还算比较小，组织结构也不完善，当时还没有独立的IT部门，只有一个网络管理员挂在财务部的名下，而此时Z还没有进入该公司，网管员只负责公司PC维护的工作，对IT系统并没有发言权。而当时G公司考虑到业务规模的不断扩大，业务部门都迫切需要有一套业务管理系统。此时G公司用的是国内某知名财务软件公司U公司的财务系统，而且由于没有独立的IT部门负责对这些软件系统选型负责，G公司财务经理就向业务部门推荐了U公司的分销软件系统，而当年U公司并没有针对服装行业的DRP系统，但出于向服装行业进军的目的，同时也是为了通过该项目完善自己的产品线， G公司的项目还是被U公司承接下来了。 

    U公司承接该项目之后，对G公司的分销业务进行了全面分析，然后在U公司原有财务系统的基础上，对软件系统进行了大量的二次开发工作，在项目开发人员基本满足了G公司的业务需求之后，就将该项目推行上线，而在上线之后才发现了还有一个需要解决的问题：由于U公司原有的软件都是基于C/S(Client/Server，客户/服务器)架构，而在G公司进行实际部署时，需要将该系统部署到全国各地的分公司、办事处、代理商直到专卖店，而在当时U公司提出了使用远程终端技术+VPN网络的方案来解决这个问题。在当时G公司对技术架构上也没太多辨别能力，而且在G公司对该方案进行效果测试时，感觉都还不错，应该能满足业务的需求，也就同意了该方案。也就是这个方案的出台，为下一次的项目失败埋下了祸根。 

    当U公司对项目实施完公司总部各个部门，只在几个分公司进行实施之后，就发现该项目举步维艰了，由于U公司的软件系统是基于财务的DRP系统，一切以财务为核心，而不是以业务流程为核心，使得G公司在应用过程中业务流程无法顺利地流转。再加上了大规模的定制开发，已经脱离了U公司原有的产品线，因此，G公司若有新的业务需求时，也将无力投入大量的人力进行开发，使得G公司的这个系统处在没有更新，没有升级的状态。基于这种情况，G公司决定与U公司停止项目合作，进行新的DRP项目选型工作。 

    第二次DRP软件选型，G公司接受了上次的教训，也不敢请看似强大，但对行业不够了解的软件公司来做该项目了。G公司这次选择了一家服装行业的软件公司B公司来完成G公司的DRP项目大业，B公司在行业内有几个较大的客户案例，虽然这次项目有一定的竞争，但由于B公司的软件产品在报表呈现上显的比较丰富，得到了业务部门的好评，因此也从几个供应商中脱颖而出。而B公司原有的客户案例，所有实施的规模没有超过200个并发用户，而且他们的软件系统与U公司相同的一点是采用C/S架构，这就使得B公司也必须使用远程终端技术+VPN网络来实现远程访问。在G公司为了该系统能够正常运行，且不论投入大量金钱购买了大量的远程终端服务器供客户端接入，同时在总部还备有电信、网通的100M光纤各一条，各分公司与总部之间采用专线连接方式，但在部署超过200个并发用户时。发现服务器、带宽甚至包括I/O都出现了瓶颈状况，而这种状况，使的软件系统在客户端的速度奇慢，以至于客户端根本无法进行正常的业务操作。这时，虽然一直以来，软件系统架构这个隐藏在美丽报表后面的X因素开始发威，而这个问题就都不再是多一条光纤、多一台服务器可以解决的问题了，而是一个整体性能的问题。而此时G公司的业务规模还在不断地扩大，随着全国所有的专卖店都需要登录到该系统进行业务操作的时候，G公司发现这终于是一个不可能完成的任务了。 

    G公司发现两次DRP项目没有资深IT专家介入的情况下，如果贸然对DRP系统进行选型是一定会犯错误的。此时G公司引进的IT专家Z。而Z对B公司的系统目前也是束手无策，因此向公司建议，第三次开始DRP项目的选型，同时做ERP级的项目，而不只只是停留在产品的层面上，而是根据公司的发展规模做平台级的ERP应用，这对Z应该又是一个新的考验。但G公司在DRP项目上的两次失败，不能不承认信息系统是为了满足业务需求而存在的，但它的本质还是需要由IT技术来支撑的。