关于DRP分销软件架构的讨论

001solider

最近看到一篇关于DRP分销软件架构的文章，感觉不错，希望大家讨论讨论：

原作者
    童继龙某公司首席管理顾问，曾就职于报喜鸟集团，红蜻蜓集团等知名企业，具有多个知名服装企业ERP(DRP)项目开发及实施经验；熟悉IT规划、信息系统选型、实施与运维；关于时尚品牌连锁企业的信息化，电子商务。　





软件系统架构，这是一个非常技术性的词，一般来说，服装企业的业务部门是不太理会这个东西的，毕竟他们关注的是业务实现，操作方便性等；就算是一些企业的IT人员，对于软件系统架构到底能够在IT项目中起到什么样的作用，可能也不太清楚。我还记得有一位企业的IT主管说过：“软件系统架构是个什么样的东西，对于我们公司来说，软件好用即可，我管它是用VB写的，还是用10层架构码出来的。”
这位IT主管的话对吗？可能从企业的角度来说，信息系统的管用就行，其它的因素可能不用担心太多，至于软件系统架构，这是演示的时候无法看出门道的东西，但如果从架构设计的目标：可靠性、安全性、可升级性、可扩展性、可定制性、可维护性再加上良好的客户使用体验这几点要求来说，如果在进行IT项目的大规模部署时，忽略了软件系统架构，如果出现问题将有可能是致命的。毕竟隐藏的越深的问题爆发出来的后果越是严重。今天挑这个话题来说，也是因为身边有朋友曾经做过的一个DRP（Distribution Resource Planning，配送资源计划）项目，这个项目中的一些经验与教训，值得我们借鉴。

分销系统的系统架构要求

从软件系统架构的种类上来说，一般分为以下几种：
1、单机程序：这个应该是简单的一种软件系统架构了，不在本文讨论之列。
2、C/S架构：C/S又称Client/Server或客户/服务器架构。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或 SQL Server。客户端需要安装专用的客户端软件。
C/S架构的优点是：
ü
交互性强。在C/S中，客户端有一套完整的应用程序，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。B/S虽然由JavaScript、VBScript提供了一定的交互能力，但与C/S的一整套客户应用相比还是太有限了。
ü
提供了更安全的存取模式。由于C/S是配对的点对点的结构模式，采用适用于局域网、安全性比较好的网络协议(例如：NT的NetBEUI协议)，安全性可以得到较好的保证。而B/S采用点对多点、多点对多点这种开放的结构模式，并采用TCP/IP这一类运用于Internet的开放性协议，其安全性只能靠数据库服务器上管理密码的数据库来保证。
ü
降低网络通信量。B/S采用了逻辑上的三层结构，而在物理上的网络结构仍然是原来的以太网或环形网。这样，第一层与第二层结构之间的通信、第二层与第三层结构之间的通信都需占用同一条网络线路。而C/S只有两层结构，网络通信量只包括Client与Server之间的通信量。所以，C/S处理大量信息的能力是B/S所无法比拟的。
ü
速度相对较快。由于C/S在逻辑结构上比B/S少一层，对于相同的任务，C/S完成的速度总比B/S快。使得C/S更利于处理大量数据。
C/S架构缺点主要有以下几个：
ü
只适用于局域网。
ü
这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。
ü
客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。特别是有很多分部或专卖店的情况，不是工作量的问题，而是路程的问题。
ü
系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。
ü
对客户端的操作系统一般也会有限制。可能适应于Win98, 但不能用于win2000或Windows XP。或者不适用于微软新的操作系统等等，更不用说Linux、Unix等。
3、B/S架构：B/S是Brower/Server的缩写，客户机上只要安装一个浏览器（Browser），如Netscape Navigator或Internet Explorer，服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。浏览器通过Web Server 同数据库进行数据交互。
B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用，客户端零维护。系统的扩展非常容易。
B/S架构的缺点就是所有C/S的优点，在前文已论述，不再重复。
4、三(N)层架构：N层架构的四层是指Presentation Tier（表示层，就是直接呈现在用户面前的界面）、Web Server Tier（Web服务器层）、 Application Server Tier（应用服务器层）和 Data Tier（数据层）。
N层架构的核心是提供可规模化特性，一方面是从服务负载上可规模化，能同时为极大规模的用户同时提供服务；另一方面是服务功能上的可规模化，可形成极大规模的软件群系统，各分系统可以共享信息、服务，形成企业级的信息高速公路。
N层可以分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。
5、远程终端技术：该种方式是根据C/S架构系统无法满足远程访问需求而存在的。远程终端技术提供了通过作为终端仿真器工作的“瘦客户机”软件远程访问服务器桌面的能力。终端服务只把该程序的用户界面传给客户机。客户机然后返回键盘和鼠标单击动作，以便由服务器处理。每个用户都只能登录并看到它们自己的会话，这些会话由服务器操作系统透明地进行管理，而且与任何其他客户机会话无关。
这种软件技术架构在小规模应用上尚可，但如果部署到大规模应用时，网络带宽、服务器响应能力、磁盘读取能力都会受到极大挑战。

从服装企业的行业特性上来说，包括鞋业、皮具、礼品等企业，在这里一般特指品牌连锁运营企业，企业的产品基于直营、分公司、加盟、专柜、批发等连锁经营方式，通过各级代理商、专卖店或者销售专柜实现最终销售，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系统进行更大规模的部署了。

ESK分销ERP

如果这篇文章是在两年以前写的，我会为作者鼓掌,
如果是今年写的，那只能说作者的技术水平还停留在三年以前.

kdfjs

怎么看着看着觉得跟我们公司有点像啊
呵呵，大概是中国企业上ERP项目的通病把

xxmecho

看看先

天缘浪人

讲的还是不错的
ESK分销ERP 有什么补充的可以讲讲，做斑竹这样“鼓励”别人可不好哦

songyi

刚看到，确实过时了，纯b/s在前端应用方面也可以做得自如了，在结合高性能数据库和中间件技术时200的并发也不在话下。。。。




纯属个人拙见------欢迎大家多多指正！

hgp122@sohu.com

跟我现在的情况非常类似。