案例分析报告之一供应链系统SCM搭建Word格式.docx
《案例分析报告之一供应链系统SCM搭建Word格式.docx》由会员分享，可在线阅读，更多相关《案例分析报告之一供应链系统SCM搭建Word格式.docx（10页珍藏版）》请在冰点文库上搜索。
案例总体介绍
背景
20世纪60年代,企业开始了管理信息化的应用，从MRP到ERP,逐步实现了对采购、库存、生产、销售、财务和人力资源等业务的管理，使内部业务流程和处理实现了自动化，为企业内部纵向一体化管理奠定了基础。
在经济全球化的今天,ERP在供应链的跨企业横向一体化管理方面力不从心。
全球500强企业在经过若干年的ERP应用后纷纷引入SCM（供应链管理），将ERP拓展到整个行业的所有物流环节。
零售企业ERP系统的重要性更是在很多年前就被企业重视，一时间中国零售企业都在开始了自己的ERP改造工程，随着ERP概念的逐渐冷却，以及各企业间对于信息、科学管理、计算机管理的不断完善,另一个领先的概念又在各企业间被逐渐传开,这就是供应链。
供应链管理（SCM），就是把供应商、生产厂家、分销商、零售商等处于一条供应链上的所有节点企业都联系起来进行优化,从而使生产资料以最快的速度，通过生产、分销环节变成增值的产品，最后到达有消费需求的消费者手中。
它不仅可以降低成本、减少库存，而且可以使社会资源得到优化配置，更重要的是，通过信息网络、组织网络实现了生产及销售的有效连接和物流、信息流、资金流的合理流动。
图1是供应链管理的模型
项目介绍
本案例介绍的项目是对零售企业ERP系统的功能延伸――供应链管理的开发、实施过程。
ERP系统作为零售企业内部管理、运行的核心架构，使得企业内部业务流程和处理实现了自动化，为企业内部纵向一体化管理奠定了基础。
从一个企业的角度看，ERP系统无疑为企业提供了先进的管理理念、整合了企业内部的流程、提高企业运行效率，但是从一个更大的层面看，使得各企业彼此之间形成了信息孤岛，使得彼此之间的信息流通还停留在原有的基础上。
在网络技术充斥的当今社会,信息的快速获取和共享已经成为各个合作企业间共同追求的目标。
这必然使得企业间的沟通和整体运作越来越受到双方的重视，作为零售业来说需要与各个供应商保持良好的合作关系,更重要的是希望能实现彼此信息的共享和反馈,使得能根据不断变化的销售市场调整经营策略，实现最大的利润。
这就给供应链系统提供了前提，也正是出于这种目的,零售企业迫切希望通过供应链系统与供应商建立利益共享的战略同盟。
企业原有的ERP系统很好的整合和规范了企业内部的运转流程,并且通过多年的经营存储了海量数据，并以北京总部为核心，通过先进的网络技术在全国各地门店中搭建起完备的网络环境，这为供应链系统的实施提供了良好的基础。
同时公司领导希望通过供应链系统，吸收现代管理理念，运用先进的科学技术,在自己与供应商之间建立起信息共享的平台、整合管理流程、缩减运营成本，使双方都能从中获得更大的利润和更高的效率。
项目的整体运转主要由企业信息技术部牵头，在技术和选型上进行定位和把关，其他各相关部门，包括：
百货事业部、零售本部、超市事业部、财务部全力配合，并提出相应需求和意见，外请专业公司开发程序的模式进行项目开展。
企业领导提出在2008年6月前首先实现北京一家门店供应链系统试运行,之后在2008年10月前实现北京其他三家门店共计四家门店全部上线供应链系统的总体目标。
根据与各事业部的协商和企业内部的讨论决定初期主要实现供应商通过网络能在供应链系统中随时查询自己在门店的销售和库存信息,实现订单、结算单由传统的打印纸质单据传递的方式向网上结算方式的转变，并希望在后期实现可视化和供应商主动参与的供应链模式。
作为我在整个项目中主要负责技术的保障,对双方之间的技术问题进行协调处理。
由于本次开发采用的是外包模式进行，从这个角度上讲我是作为项目中的甲方身份，但是由于为了满足供应链系统的一些需求，需要在原有ERP系统基础上进行一些功能的扩展,所以从这个角度上我又是一种类似乙方的身份,可能正是由于这两方面的不同的角度,使得我在这个项目中有了更多的体会，特别是结合着在案例分析课程中学到的一些专业的项目管理理念和经验,更是使得自己从整个项目中学到了不少的知识，增长了更为丰富的经验，下面我开始进行项目的具体分析.
第二章：
案例分析
这个项目或者案例说的是对原有ERP系统进行改造实现SCM的功能扩展。
从目前的结果看这个项目已经投入到正式使用之中，并且对于企业的流程整合和效率提高都起到了应有的作用，应该说从这方面讲项目是成功的，但是其间有这太多的遗憾，而这些遗憾也造成了项目不能继续前进的阻力,要是从这方面讲项目好像又是失败的,总的来说成功中带着遗憾，下面我就从几个方面详细的讨论一下这个项目，希望能从中看到成功的方面也能在今后弥补遗憾的方面。
1、前期可行性探讨
项目开始于2007年年底，真是的实施是在2008年3月开始的，这期间的3个多月时间主要进行的前期可行性探讨，这个可行性针对的是数据对接可行性的讨论。
这是因为ERP系统作为目前企业的核心架构是不可能轻易进行修改的,并且出于对于数据安全性的考虑，不可能将企业核心服务器和数据库提供给供应链系统访问，故需要将数据从核心数据库中取出并导入到供应链系统中单独进行展现.这必然需要在一个单独的数据抽取过程来实现两个系统的对接，而这种对接又是两个层面，其一是技术角度上数据库中数据的抽取和导入,这方面主要是纯技术层面的，在当今各厂商的技术趋于统一化的前提下，这方面基本不会存在太多问题，只是在数据格式转换、表结构转换等细节上进行探讨；
其二是数据展现结果的对接，这个层面主要是业务系统的对接,也就是将原本在ERP中展现的结果放到供应链中进行展现,这将涉及到双方的展现方式是否一致、数据分析的角度是否一致、信息存储的含义是否一致等方面，这将更多的涉及到业务层面的细节。
这些问题是涉及到双方能否进行实质性合作的关键，故在项目正是开始之前双方就这几方面进行了反复的交流和探讨。
作为外包公司他们已经有了一套比较成型的供应链系统，此系统使用的Java技术进行前端开发,以IBMWebshere为中间件，使用DB2数据库进行数据存储.作为我们的ERP系统使用的是比较传统的Sybase数据库进行后端数据存储，这样由Sybase到DB2数据库的转换是不可避免的.由于目前两个数据库均是标准的关系型数据库，虽然从数据库管理构架、存储结构上看存在这比较明显的区别，但是数据库内部遵循的标准是统一的，数据在数据表中的存储方式也大致是一样,从技术角度的层面可以预见到在这方面不存在太大的问题.双方最终决定由Sybase数据库中将数据保存为文本TXT格式的文件,再将TXT文件导入到DB2数据库中，这样的操作方式对于两个数据库均可以比较容易的实现。
当时双方没有进行更为具体的技术上的讨论和实现测试，在后期的开发过程中发现两个数据库中的对于日期型数据的处理方式存在一些不同,会导致数据转存失败，在技术上进行转换处理后得以解决.虽然这只是一个小小的问题，并且很快的得以解决,但是也暴露出前期可行性探讨的不严谨性。
由于数据库层面属于整个系统的底层部分，如果在这部分没有充分的考虑的和可行性的验证,不敢想象后期整体项目全面展开后如出现不可解决的问题时，我们将面对如何的窘境。
这就提醒我们前期技术方面的沟通和探讨应该做到细致严谨,并且需要进行相关的实现测试.
作为零售企业的ERP系统和供应链（SCM）系统来说，它必然要满足于这种行业的标准和规范，但是说实话在中国市场上并没有明确的对于ERP、SCM的定义,这就导致了每家企业都在做自己的ERP、SCM系统，有自己的特点和遵循的规律,从这方面考虑如果需要对ERP进行功能扩展和延伸，那么SCM所遵循的标准和规范是否与ERP系统保持基本一致也是能项目是否能开展起来的关键,而这方面所考虑的将不光是技术方面的因素，更多的将是对零售业的理解对系统的理解。
为我们做供应链的公司之前也是一家以ERP系统起家的公司,并且于我们现在使用的ERP系统还颇有渊源,所以在初期感觉上双方应该不会存在太大的分歧.当初期双方派出代表进行探讨的时候,我发现对方的技术人员也好，代表也罢对于商业的理解很有限,甚至可以说对于商业基本不了解，这使得双方的交流产生了很大的障碍。
我不敢说经过这些年在企业维护ERP系统对于零售业有多么的了解，但是零售业所遵循的标准和习惯我还是知道一些的，所以我对对方的业务只是产生了怀疑，同时我也意识到一个问题：
作为一个技术人员来说,技术水平的高低仅是衡量他能力的唯一标准吗？
如果他对于自己所做的行业没有了解,难道能做出好的系统来吗？
当然这些问题在对方更换了技术代表后得到了很好的解决，我们彼此双方对于零售业的理解达成了共识，彼此间的沟通也变的非常容易，这样我们开始从业务的层面进一步讨论技术层面的实现问题。
因为受双方表结构在构建当初的时代和考虑角度的不同，许多SCM系统需要的数据在我们的系统中需要经过处理才能得到,但是在双方从业务层面已经达成一致的前提下，这些技术层面的事情基本都可以想出解决的办法。
在这里让我又一次意识到了，技术本身并不神秘也并没有价值，只有当应用技术实现了某种实际的目标，才使得技术看上去是那么的光彩夺目，这也就是我自己一直要求自己的，不光要懂得技术,更要了解技术的应用。
在这种前提下，我们双方开始逐个表甚至逐个的数据进行对照工作，在ERP、SCM和Sybase、DB2中找到一个双方沟通的机制,这部分的工作进行的比较顺利，但是由于涉及的内容比较多，还是花了一些时间的。
但是可能也正是前期的这种方式，注定了这个项目后期的一些不可更改的弊端，因为双方在初期太关注细节方面的对接了，一直都在讨论数据的转换、对照等工作，这样彼此双方都忽略了对整个项目的整体考虑。
可能这也从一个侧面看到了中国市场上对于软件方面的不系统化管理也没有比较明确的规范标准，可能也是双方领导对于到底需要一个什么样的供应链应该是个怎样的供应链都没有明确的标准，这样对于后期功能的扩展和延伸都产生了不可逾越的障碍.
通过软件工程案例这门课的学习,老师讲解了一些软件工程的案例，使我在这个项目之后意识到了对于一个工程来说前期整体的规划和考虑是多么的重要，也让我找到了这个项目在后期不可避免的遇到障碍的根源所在。
2、程序开发
通过前期的双方沟通，彼此都明确了自己应该做的事情，并且进行了数据抽取和导入的功能测试，使得一些历史数据按照双方事先商量好的标准转移到SCM系统中，这也为下一步的开发、测试提供了基础,使得双方开始了下一步的工作。
我方将ERP系统中一些展示风格和数据标准告知对方，由对方进行程序的改造，以符合我们的风格和特点，同时我们的ERP系统为了满足新的业务流程的发展需要在原有的基础上进行功能的增加.
在这里我们作为甲方的身份将我们的一些需求告知对方，由对方进行功能的实现，由于对方是一家比较专业的IT公司，而且他们其间的内部运行机制我们不便深入干涉，我作为本方技术代表的身份与对方技术代表多次进行数据方面的谈论，要求对方在原有程序的基础上进行改造，以满足我们的风格和标准。
在这里我更多的是将ERP系统中一些表单的展示界面告知对方应如何从数据库中取得，这是有了之前双方比较细致的数据库对接工作的基础，使得我们双方彼此交流起来比较顺畅.因为我并不知道更不了解SCM数据库的结构，所以我只是将ERP系统中数据如何计算的方法告知对方,由对方的程序员在自己的数据库中进行相应的计算实现各个界面的展示功能。
当时由于手头还有其他的工作，我并没有更多的去关心对方数据库与我方数据库的对应关系，当时认为这些应该是由对方程序员考虑的事情，但是当项目走到了后期的时候，特别是我方感觉数据的一致性和准确性存在问题的时候，前期这方面的忽略成了至于我方进行数据稽核也好数据对比也好的致命伤,并且一致影响到现在，使得在问题出现的时候双方都比较被动,排错的过程也比较复杂和难以控制。
前面我说过，在这个项目中我也以一种类似乙方的身份出现，也就是说为了实现供应链的一些功能，我对于我们自己原有的ERP系统也进行了一些功能扩展性开发。
我之前并没有系统学习过计算机变成,对于变成的整体思路也没有把握,好在此次开发主要是在原有的程序基础上进行开发,有很多的源代码可以进行参考。
我当时可以说是采用了一种类似迭代式的开发方式进行项目展开的，因为在程序成型之前,业务上的需求只是一种笼统的概念，并没有明确性的需求分析，这对于开发工作来说是相当困难的，所以我只能是在原有的基础上将一些功能进行简单的扩展。
当时当我仿照原有程序的源代码进行开发的时候，我发现了原有代码比较的冗长，并且其间的移植性比较差，一些关键的点也没有明确的标注实现的目的，所以也为我的开发过程产生了比较大的影响，而当时的我也没有能力去改变这些已经成型的系统，所以我只是一味的复制进行一些简单的修改以满足需求.在这种前提下，程序的雏形基本实现了，并暂时有我们部门同时负责这个项目的人员进行简单的功能测试，在测试过程中对于细节方面的一些不足展现出来了，需要进行二次的程序完善，但是当我再翻过头来准备对程序进行完善的时候，我发现由于之前对于程序的开发没有很好的遵循软件开发高内聚低耦合的标准和很好的一个对于软件整体的考虑，使得一些细小的改动非常的繁琐和困难，经常是改动了这里忘记了那里，使得修改的过程非常的痛苦，最终我决定重新审视这个软件，进行全新的开发。
这可以说是我第一次开发一个功能比较成型的软件，其间让我认识到了软件开发过程中科学性的重要性,在二次重新开发的过程中，我尽量遵循软件开发的标准，首先并不是急于编写代码,而是整体的考虑了一下这部分功能实现的方式，并将其间一些重复的功能进行汇总,大致屡清一个变成思路后开始进行程序框架的搭建工作，并对一些需要重复实现的功能进行整体函数的编写,尽量考虑函数的适用性和通用性，之后进行关键环节的开发和代码编写，并尽量使用上之前开发的函数进行实现,尽量将后期一些环节的改造而影响代码改造的工作量降到最低.正是通过了这种二次的洗礼，我逐步在时间中摸索到了软件开发的规律,并且形成了一些自己的风格.
现在通过这门课程的学习，回过头来看一看自己的开发过程，我感觉到了一个科学有效的软件开发管理方法对于整个项目的实施是多么的重要，如果没有这些作为基础，那么编出的软件不管从使用性上也好还是从健壮性上也好都是不能满足实际的要求的.
3、功能测试
在经历了程序开发的过程之后，必然开始了功能的测试工作。
在当时我就已经感觉出我们测试工作的薄弱性，通过本门课程我更是意识到了测试的重要性和我们测试工作的不规范不科学性,我从中得到的更多的是教训，但是有的时候教训能让人记住更多的东西,也更能给人以启示,所以在这里我重点讨论的不是我们的测试方法，而是结合这门课程进行的一些思考和对今后的改进。
对于SCM方面的程序我方进行的更多的是黑盒方式的测试,主要由我们部门包括我在内的两位同事进行功能测试，对于这方面我们没有严格的测试标准，也没有使用一些专业的软件使得测试工作其实只是肤浅的局限在表面。
由于当时我手头还有其他方面的工作甚至当时出差在外,而我的同事并不懂技术对于零售业的了解也不十分充分，所以使得当时的测试只是表面的功能测试，就是将几个界面笼统的看了一下，感觉没有太大的问题就认为没有问题.同时由于企业内部门间关系的问题，也没有让相关部门进行测试,所以从这方面开我们的测试工作简直可以说没有,就更谈不上什么科学的方法了,其间也只是对于界面提出了一些改进的意见,对于数据的准确性也没有进行严格的核对。
这使得之后在使用过程中，用户提出了很多细节方面的问题，使得我们疲于进行解释和调试中,这也就说明了我们的测试工作存在多大的弊端。
通过这么课程的学习，我希望能够将老师在课堂上将的一些成功的案例中的测试方法引入到我们之后的工作中去，因为只有测试工作做的更加充分才能使得整个项目更加成功。
开发方进行的测试工作我们没有进行更多的参与和干涉，通过和他们技术人员的交流，他们进行的更多的是数据一致性的测试,也就是将SCM中的数据和ERP系统中的数据进行逐界面的对照，以保证两个系统中数据的一致性完全一致。
正是由于有了这方面的测试工作,使得系统在上线的时候数据方面并没有出现太多的问题，使得使用人员对于数据的准确性没有提出太多的异议，我真的不敢设想如果两方数据出现了不一致我们将如何面对双方的领导和使用者.
测试这部分本来应该是整个项目中一个比较主要的环节，但是我感觉我们在这个环节上的欠缺和不足,这个可能也是我们整个部门的一个弊端，我确实希望一方面通过对于测试流程的系统学习另一方对以一些成功项目的学习能够改善我们部门这方面的弱势。
可能也正是通过课程的学习,使我的眼界放开了,使我找到了方向,当然理论上的东西或者其他人的东西要变成自己的还需要一个过程,但是我认为至少我现在意识到了认识到了，这些都必将对于下一步的改进起到积极的作用。
4、项目上线
经历了上面各个环节，项目一步一步的走到了开始正是上线的环节。
这个环节可以说是整个项目一个最终失败与否的关键点，虽然它并不能代表整个项目,但是它确实整个项目的最好的体现点。
由于此次实现的功能比较简单,只是一些报表的展现功能,也正是在先前对于数据一致性的把握上,使得上线时并没有产生太多的对于系统的质疑。
相仿的由于之前一些培训工作的不到位和一些对问题估计的不足，使得上线初期用户对于管理方面的质疑声音比较强烈。
这也提醒了我们软件工程不光是一个编写代码的过程,其间的运作手段也是十分重要的，甚至可以说这将直接影响给使用者一个怎样的初印象的问题，所以作为一个项目的实施来说，不光需要科学的编程、测试方法,更加需要科学的运作方式，这当然也为项目的管理人员提出了更高的要求,但是这是符合实际发展趋势的，也是必可避免要遇到的问题.
之后基本按照领导提出的要求，项目如期的上线，也基本实现了当初设想的一些功能,为供应商和我们都提供了一定方面的便利和效率的提高。
5、后期展望
初期的功能可以说很好的实现了当初的设想,但是项目并没有就此停止,因为目前实现的只是最简单一些报表的展示，而与供应商直接的联动性并没有实现。
就在我们在原有的基础上准备进行下一步开发的时候,一个可以说是不可逾越的问题出现了,由于前期对于整体项目考虑的不完善，使得后期一些功能的扩展变得步履维艰，对于每一个新的功能都需要进行从抽取数据到程序开发整个过程的整体改动,并且双方数据的一致性也出现了问题,这都为之后双方系统的联动产生了本质性的问题。
就目前的状况来看，系统能比较好的满足现在的需求,但是项目可以说已经走到了尽头,如果想有进一步的发展,好像不从最底层重新开始好像已经难以实现了。
我不知道应该如何来评论这个项目的成败，可能正如我前面说的，项目确实成功了,但是成功中带着遗憾,而遗憾中带来的更多的是思考，思考之后我们需要重新审视这个项目，但是欣喜的是我们从中找到了问题，认识到的缺陷，希望我们能在今后的过程中得以改进和完善。
第三章：
总结
通过上面对于整个项目中一些重要环节的论述,大家可能都有自己的看法，自然也会产生不同的结论,我认为姑且不要谈论成败与否，因为成功了并不能掩盖问题，失败了并不能说明一无所获，我到是觉的经历了这个项目之后我的思路更加清晰了，特别是结合这门课程的学习我认清了软件工程的思想，这是我最为宝贵的财富。
通过这个项目我认识到了软件管理过程中的每个环节,首先我知道了前期的需求调研多么的重要，这其间不光包括对于用户需求的调研，还需要对于项目涉及行业的整体调研，因为谁都希望项目的生命周期更长，这样就只有认清行业的发展趋势，才能在最开始的时候对项目进行整体的规划；
其次对于测试工作的科学性和重要性的考虑，测试工作不同于开发过程，它有着自身的特点同时不同的公司或者部门也有个各自的特点，这就使得测试工作的展开变数比较多，方法、方式也比较多，只有在遵循科学的方法的前提下,找到适合自己的测试方法才能真正体现测试环节的价值;
最后，由于我所处的环境不是专业的IT公司，对于项目的整体过程管理存在着很多欠缺的地方，这些使自己比可避免的会在工作中遇到问题，而只有通过系统的学习和多方面知识的融合才能弥补自己的缺憾。
我非常感谢学院能开设这门课程，也感谢老师课堂上对于一些具体案例的分析，这些都使我增长了知识开阔了眼界，更是认识到了自身的不足，我希望能以这门课为一个契机，知道和推动我今后的工作和成长，再次感谢老师这么长时间的辅导，希望今后能给予我更多的指导和帮助。
升级会员 