从服装企业的行业特性上来说，包括鞋业、皮具、礼品等企业，在这里一般特指品牌连锁运营企业，企业的产品基于直营、分公司、加盟、专柜、批发等连锁经营方式，通过各级代理商、专卖店或者销售专柜实现最终销售，DRP系统就是要对企业的供应链进行全程管理，包括内部供应链和外部供应链的管理，涵盖了从生产厂家，物流配送，各级代理商分销，到专卖店零售的每一个环节，DRP系统要以供应链为核心实现各项业务功能。DRP系统必须通过物流、商流、信息流、资金流对供应链进行管理和监控，实现供需匹配、动态适应、快速反应，从而降低库存、共享资源、降低成本、规避风险，为企业创造价值。服装企业的上下游供应链关系可以用如下图表示：

在初步了解了软件系统架构及服装企业的供应链模式之后，我们且先来看一下G公司在长达5年间的三次DRP项目经历，从这三次项目经历来看一下软件架构之痛。

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技术来支撑的。

如何选择一个好的系统架构

       企业的供应链复杂程度是DRP系统选型中一个非常重要的因素，因为企业供应链的复杂程度越高，对DRP系统的性能要求就越高，相较之下系统构架要求就越高。

       但服装企业因为其分销网络的不断扩张，不同的软件系统架构在企业的不同阶段是具有适应性的，根据G公司的应用效果，基本上我们可以进行如下判断：

1、单机程序：适合单个的服装店，或者是几家服装店只进行进销存管理的企业。

2、C/S架构：该方案只适合在局域网内使用，而DRP项目一定是要进行跨地区应用的，因此不适合作为DRP项目的主要架构，但可以应用在DRP项目POS或者收银部分的脱机应用程序中，与ACCESS本地数据库配合使用。当然，如果C/S架构的系统配合远程终端技术+VPN技术，则可在不高于100个并发用户的情况下进行应用。

3、B/S架构：由于DRP项目的复杂性，而B/S架构因为其前端应用展现能力有限，因此不适合作为DRP项目的主要架构。但如果企业的应用需求不复杂的情况下，如在报表查询、客户资料查询等方面可以应用。

4、三(N)层架构：一个具有良好扩展性，能够进行大规模部署的DRP系统应该是基于三(N)层架构下的，否则的话，就算软件系统的功能再强大，也只是“水中月”、“镜中花”，中看不中用。

5、远程终端技术：由于一些历史原因，在C/S架构的旧系统，通过远程终端技术+VPN网络的方法，可以延长原有系统的使用寿命；但如果是新的DRP系统建设中，由于远程终端需要耗费大量的服务器处理能力、网络带宽及I/O，因此不建议使用该技术。特别是在并发用户数在200左右的时候，远程终端技术需要用三(N)层架构一倍的服务器、带宽才能将应用跑起来，而此时除非用小型机，如果只是用PC服务器的话，估计是没有将DRP系统进行更大规模的部署了。