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

1、.：.；供应链系统SCM搭建软件工程案例分析第一章：案例总体引见 背景 20 世纪 60 年代，企业开场了管理信息化的运用，从 MRP 到 ERP，逐渐实 现了对采购、库存、消费、销售、财务和人力资源等业务的管理，使内部业务流 程和处置实现了自动化，为企业内部纵向一体化管理奠定了根底。在经济全球化 的今天， ERP 在供应链的跨企业横向一体化管理方面力不从心。 全球 500 强企业 在经过假设干年的 ERP 运用后纷纷引入 SCM供应链管理 ，将 ERP 拓展到整个 行业的一切物流环节。 零售企业 ERP 系统的重要性更是在很多年前就被企业注重，一时间中国零 售企业都在开场了本人的 ERP 改

2、造工程，随着 ERP 概念的逐渐冷却，以及各企 业间对于信息、科学管理、计算机管理的不断完善，另一个领先的概念又在各企 业间被逐渐传开，这就是供应链。 供应链管理(SCM)，就是把供应商、消费厂家、分销商、零售商等处于一条 供应链上的一切节点企业都联络起来进展优化，从而使消费资料以最快的速度， 经过消费、分销环节变成增值的产品，最后到达有消费需求的消费者手中。它不 仅可以降低本钱、减少库存，而且可以使社会资源得到优化配置，更重要的是， 经过信息网络、组织网络实现了消费及销售的有效衔接和物流、信息流、资金流 的合理流动。图 1 是供应链管理的模型 工程引见 本案例引见的工程是对零售企业 ERP

3、系统的功能延伸供应链管理的开 发、实施过程。ERP 系统作为零售企业内部管理、运转的中心架构，使得企业内 部业务流程和处置实现了自动化，为企业内部纵向一体化管理奠定了根底。从一 个企业的角度看， ERP 系统无疑为企业提供了先进的管理理念、 整合了企业内部 的流程、提高企业运转效率，但是从一个更大的层面看，使得各企业彼此之间形 成了信息孤岛，使得彼此之间的信息流通还停留在原有的根底上。在网络技术充 斥的当今社会，信息的快速获取和共享曾经成为各个协作企业间共同追求的目 标。这必然使得企业间的沟通和整体运作越来越遭到双方的注重，作为零售业来 说需求与各个供应商坚持良好的协作关系， 更重要的是希望能

4、实现彼此信息的共 享和反响，使得能根据不断变化的销售市场调整运营战略，实现最大的利润。这 就给供应链系统提供了前提，也正是出于这种目的，零售企业迫切希望经过供应链系统与供应商建立利益共享的战略同盟。 企业原有的 ERP 系统很好的整合和规范了企业内部的运转流程，并且经过 多年的运营存储了海量数据，并以北京总部为中心，经过先进的网络技术在全国 各地门店中搭建起完备的网络环境，这为供应链系统的实施提供了良好的根底。 同时公司指点希望经过供应链系统，吸收现代管理理念，运用先进的科学技术， 在本人与供应商之间建立起信息共享的平台、整合管理流程、缩减运营本钱，使 双方都能从中获得更大的利润和更高的效率。

5、 工程的整体运转主要由企业信息技术部牵头， 在技术和选型上进展定位和把 关，其他各相关部门，包括：百货事业部、零售本部、超市事业部、财务部全力 配合，并提出相应需求和意见，外请专业公司开发程序的方式进展工程开展。 企业指点提出在 2021 年 6 月前首先实现北京一家门店供应链系统试运转， 之后在 2021 年 10 月前实现北京其他三家门店合计四家门店全部上线供应链系统 的总体目的。 根据与各事业部的协商和企业内部的讨论决议初期主要实现供应商 经过网络能在供应链系统中随时查询本人在门店的销售和库存信息，实现订单、 结算单由传统的打印纸质单据传送的方式向网上结算方式的转变， 并希望在后期 实现

6、可视化和供应商自动参与的供应链方式。 作为我在整个工程中主要担任技术的保证， 对双方之间的技术问题进展协调 处置。由于本次开发采用的是外包方式进展，从这个角度上讲我是作为工程中的 甲方身份，但是由于为了满足供应链系统的一些需求，需求在原有 ERP 系统基 础上进展一些功能的扩展，所以从这个角度上我又是一种类似乙方的身份，能够 正是由于这两方面的不同的角度，使得我在这个工程中有了更多的领会，特别是 结合着在案例分析课程中学到的一些专业的工程管理理念和阅历， 更是使得本人 从整个工程中学到了不少的知识，增长了更为丰富的阅历，下面我开场进展工程 的详细分析。第二章：案例分析 这个工程或者案例说的是对

7、原有 ERP 系统进展改造实现 SCM的功能扩展。 从目前的结果看这个工程曾经投入到正式运用之中， 并且对于企业的流程整合和 效率提高都起到了应有的作用，应该说从这方面讲工程是胜利的，但是其间有这 太多的遗憾，而这些遗憾也呵斥了工程不能继续前进的阻力，要是从这方面讲项 目好似又是失败的，总的来说胜利中带着遗憾，下面我就从几个方面详细的讨论一下这个工程，希望能从中看到胜利的方面也能在今后弥补遗憾的方面。 1、前期可行性讨论 工程开场于 2007 年年底，真是的实施是在 2021 年 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 进展功能扩展和延伸，那么 SCM 所 遵照的规范和规范能否与

12、 ERP 系统坚持根本一致也是能工程能否能开展起来的 关键，而这方面所思索的将不光是技术方面的要素，更多的将是对零售业的了解 对系统的了解。为我们做供应链的公司之前也是一家以 ERP 系统起家的公司， 并且于我们如今运用的 ERP 系统还颇有渊源，所以在初期觉得上双方应该不会 存在太大的分歧。当初期双方派出代表进展讨论的时候，我发现对方的技术人员 也好，代表也罢对于商业的了解很有限，甚至可以说对于商业根本不了解，这使 得双方的交流产生了很大的妨碍。我不敢说经过这些年在企业维护 ERP 系统对 于零售业有多么的了解，但是零售业所遵照的规范和习惯我还是知道一些的，所 以我对对方的业务只是产生了疑心

13、，同时我也认识到一个问题：作为一个技术人 员来说， 技术程度的高低仅是衡量他才干的独一规范吗？假设他对于本人所做的 行业没有了解， 难道能做出好的系统来吗？当然这些问题在对方改换了技术代表 后得到了很好的处理，我们彼此双方对于零售业的了解达成了共识，彼此间的沟 通也变的非常容易，这样我们开场从业务的层面进一步讨论技术层面的实现问 题。由于受双方表构造在构建当初的时代和思索角度的不同，许多 SCM 系统需 要的数据在我们的系统中需求经过处置才干得到， 但是在双方从业务层面曾经达 成一致的前提下，这些技术层面的事情根本都可以想出处理的方法。在这里让我 又一次认识到了，技术本身并不奥秘也并没有价值，

14、只需当运用技术实现了某种 实践的目的，才使得技术看上去是那么的光彩夺目，这也就是我本人不断要求自 己的，不光要懂得技术，更要了解技术的运用。在这种前提下，我们双方开场逐 个表甚至逐个的数据进展对照任务，在 ERP、SCM 和 Sybase、DB2 中找到一个 双方沟通的机制，这部分的任务进展的比较顺利，但是由于涉及的内容比较多， 还是花了一些时间的。但是能够也正是前期的这种方式，注定了这个工程后期的 一些不可更改的弊端，由于双方在初期太关注细节方面的对接了，不断都在讨论数据的转换、对照等任务，这样彼此双方都忽略了对整个工程的整体思索。能够 这也从一个侧面看到了中国市场上对于软件方面的不系统化管

15、理也没有比较明 确的规范规范， 能够也是双方指点对于究竟需求一个什么样的供应链应该是个怎 样的供应链都没有明确的规范， 这样对于后期功能的扩展和延伸都产生了不可逾 越的妨碍。 经过软件工程案例这门课的学习，教师讲解了一些软件工程的案例，使我在 这个工程之后认识到了对于一个工程来说前期整体的规划和思索是多么的重要， 也让我找到了这个工程在后期不可防止的遇到妨碍的根源所在。 2、程序开发 经过前期的双方沟通，彼此都明确了本人应该做的事情，并且进展了数据抽 取和导入的功能测试，使得一些历史数据按照双方事先商量好的规范转移到 SCM 系统中，这也为下一步的开发、测试提供了根底，使得双方开场了下一步 的

16、任务。我方将 ERP 系统中一些展现风格和数据规范告知对方，由对方进展程 序的改造，以符合我们的风格和特点，同时我们的 ERP 系统为了满足新的业务 流程的开展需求在原有的根底上进展功能的添加。 在这里我们作为甲方的身份将我们的一些需求告知对方， 由对方进展功能的 实现，由于对方是一家比较专业的 IT 公司，而且他们其间的内部运转机制我们 不便深化干涉， 我作为本方技术代表的身份与对方技术代表多次进展数据方面的 议论，要求对方在原有程序的根底上进展改造，以满足我们的风格和规范。在这 里我更多的是将 ERP 系统中一些表单的展现界面告知对方应如何从数据库中取 得，这是有了之前双方比较细致的数据库

17、对接任务的根底，使得我们双方彼此交 流起来比较顺畅。由于我并不知道更不了解 SCM 数据库的构造，所以我只是将 ERP 系统中数据如何计算的方法告知对方， 由对方的程序员在本人的数据库中进 行相应的计算实现各个界面的展现功能。当时由于手头还有其他的任务，我并没 有更多的去关怀对方数据库与我方数据库的对应关系， 当时以为这些应该是由对 方程序员思索的事情，但是当工程走到了后期的时候，特别是我方觉得数据的一 致性和准确性存在问题的时候， 前期这方面的忽略成了至于我方进展数据稽核也 好数据对比也好的致命伤，并且一致影响到如今，使得在问题出现的时候双方都 比较被动，排错的过程也比较复杂和难以控制。 前

18、面我说过，在这个工程中我也以一种类似乙方的身份出现，也就是说为了实现供应链的一些功能，我对于我们本人原有的 ERP 系统也进展了一些功能扩 展性开发。我之前并没有系统学习过计算机变成，对于变成的整体思绪也没有把 握，好在此次开发主要是在原有的程序根底上进展开发，有很多的源代码可以进 行参考。我当时可以说是采用了一种类似迭代式的开发方式进展工程展开的，因 为在程序成型之前，业务上的需求只是一种笼统的概念，并没有明确性的需求分 析，这对于开发任务来说是相当困难的，所以我只能是在原有的根底上将一些功 能进展简单的扩展。当时当我仿照原有程序的源代码进展开发的时候，我发现了 原有代码比较的冗长，并且其间

19、的移植性比较差，一些关键的点也没有明确的标 注实现的目的，所以也为我的开发过程产生了比较大的影响，而当时的我也没有 才干去改动这些曾经成型的系统， 所以我只是一味的复制进展一些简单的修正以 满足需求。在这种前提下，程序的雏形根本实现了，并暂时有我们部门同时担任 这个工程的人员进展简单的功能测试， 在测试过程中对于细节方面的一些缺乏展 现出来了，需求进展二次的程序完善，但是当我再翻过头来预备对程序进展完善 的时候， 我发现由于之前对于程序的开发没有很好的遵照软件开发高内聚低耦合 的规范和很好的一个对于软件整体的思索， 使得一些细小的改动非常的繁琐和困 难，经常是改动了这里忘记了那里，使得修正的过

20、程非常的苦楚，最终我决议重 新审视这个软件，进展全新的开发。这可以说是我第一次开发一个功能比较成型 的软件，其间让我认识到了软件开发过程中科学性的重要性，在二次重新开发的 过程中，我尽量遵照软件开发的规范，首先并不是急于编写代码，而是整体的考 虑了一下这部分功能实现的方式，并将其间一些反复的功能进展汇总，大致屡清 一个变成思绪后开场进展程序框架的搭建任务， 并对一些需求反复实现的功能进 行整体函数的编写，尽量思索函数的适用性和通用性，之后进展关键环节的开发 和代码编写，并尽量运用上之前开发的函数进展实现，尽量将后期一些环节的改 造而影响代码改造的任务量降到最低。正是经过了这种二次的洗礼，我逐渐

21、在时 间中探求到了软件开发的规律，并且构成了一些本人的风格。 如今经过这门课程的学习，回过头来看一看本人的开发过程，我觉得到了一 个科学有效的软件开发管理方法对于整个工程的实施是多么的重要， 假设没有这 些作为根底， 那么编出的软件不论从运用性上也好还是从强壮性上也好都是不能 满足实践的要求的。 3、功能测试阅历了程序开发的过程之后，必然开场了功能的测试任务。在当时我就已 经觉得出我们测试任务的薄弱性， 经过本门课程我更是认识到了测试的重要性和 我们测试任务的不规范不科学性，我从中得到的更多的是教训，但是有的时候教 训能让人记住更多的东西，也更能给人以启示，所以在这里我重点讨论的不是我 们的测

22、试方法，而是结合这门课程进展的一些思索和对今后的改良。 对于 SCM 方面的程序我方进展的更多的是黑盒方式的测试，主要由我们部 门包括我在内的两位同事进展功能测试，对于这方面我们没有严厉的测试规范， 也没有运用一些专业的软件使得测试任务其实只是浅薄的局限在外表。 由于当时 我手头还有其他方面的任务甚至当时出差在外， 而我的同事并不懂技术对于零售 业的了解也不非常充分，所以使得当时的测试只是外表的功能测试，就是将几个 界面笼统的看了一下，觉得没有太大的问题就以为没有问题。同时由于企业内部 门间关系的问题，也没有让相关部门进展测试，所以从这方面开我们的测试任务 几乎可以说没有，就更谈不上什么科学的

23、方法了，其间也只是对于界面提出了一 些改良的意见，对于数据的准确性也没有进展严厉的核对。这使得之后在运用过 程中，用户提出了很多细节方面的问题，使得我们疲于进展解释和调试中，这也 就阐明了我们的测试任务存在多大的弊端。经过这么课程的学习，我希望可以将 教师在课堂上将的一些胜利的案例中的测试方法引入到我们之后的任务中去， 因 为只需测试任务做的更加充分才干使得整个工程更加胜利。 开发方进展的测试任务我们没有进展更多的参与和干涉， 经过和他们技术人 员的交流，他们进展的更多的是数据一致性的测试，也就是将 SCM 中的数据和 ERP 系统中的数据进展逐界面的对照，以保证两个系统中数据的一致性完全一

24、致。正是由于有了这方面的测试任务，使得系统在上线的时候数据方面并没有出 现太多的问题，使得运用人员对于数据的准确性没有提出太多的异议，我真的不 敢想象假设两方数据出现了不一致我们将如何面对双方的指点和运用者。 测试这部分本来应该是整个工程中一个比较主要的环节， 但是我觉得我们在 这个环节上的欠缺和缺乏，这个能够也是我们整个部门的一个弊端，我确实希望 一方面经过对于测试流程的系统学习另一方对以一些胜利工程的学习可以改善 我们部门这方面的弱势。能够也正是经过课程的学习，使我的眼界放开了，使我 找到了方向，当然实际上的东西或者其他人的东西要变本钱人的还需求一个过 程，但是我以为至少我如今认识到了认识

25、到了，这些都必将对于下一步的改良起到积极的作用。 4、工程上线 阅历了上面各个环节，工程一步一步的走到了开场正是上线的环节。这个环 节可以说是整个工程一个最终失败与否的关键点，虽然它并不能代表整个工程， 但是它确实整个工程的最好的表达点。 由于此次实现的功能比较简单，只是一些报表的展现功能，也正是在先前对 于数据一致性的把握上，使得上线时并没有产生太多的对于系统的质疑。相仿的 由于之前一些培训任务的不到位和一些对问题估计的缺乏， 使得上线初期用户对 于管理方面的质疑声音比较剧烈。 这也提示了我们软件工程不光是一个编写代码 的过程，其间的运作手段也是非常重要的，甚至可以说这将直接影响给运用者一

26、个怎样的初印象的问题，所以作为一个工程的实施来说，不光需求科学的编程、 测试方法，更加需求科学的运作方式，这当然也为工程的管理人员提出了更高的 要求，但是这是符合实践开展趋势的，也是必可防止要遇到的问题。 之后根本按照指点提出的要求，工程如期的上线，也根本实现了当初想象的 一些功能，为供应商和我们都提供了一定方面的便利和效率的提高。 5、后期展望 初期的功能可以说很好的实现了当初的想象，但是工程并没有就此停顿，因 为目前实现的只是最简单一些报表的展现，而与供应商直接的联动性并没有实 现。 就在我们在原有的根底上预备进展下一步开发的时候， 一个可以说是不可逾 越的问题出现了，由于前期对于整体工程思索的不完善，使得后期一些功能的扩 展变得步履维艰， 对于每一个新的功能都需求进展从抽取数据到程序开发整个过 程的整体改动，并且双方数据的一致性