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