软件工程师供应链系统案例

供应链系统（SCM）搭建软件工程案例分析第一章：案例总体介绍背景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系统也进行了一些功能扩展性开发。我之前并没有系统学习过计算机变成，对于变成的整体思路也没有把握，好在此次开发主要是在原有的程序基础上进行开发，有很多的源代码可以进行参考。我当时可以说是采用了一种类似迭代式的开发方式进行项目展开的，因为在程序成型