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

供应链系统（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 技术进行前端开发，以 IBM Webshere 为中间件，使用 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、后期展望 初期的功能可以说很好的实现了当初的设想，但是项目并没有就此停止，因 为目前实现的只是最简单一些报表的展示，而与供应商直接的联动性并没有实 现。 就在我们在原有的基础上准备进行下一步开发的时候， 一个可以说是不可逾 越的问题出现了，由于前期对于整体项目考虑的不完善，使得后期一些功能的扩 展变得步履维艰， 对于每一个新的功能都需要进行从抽取数据到程序开发整个过 程的整体改动，并且双方数据的一致性也出现了问