供应链管理系统设计(编辑修改稿)

供应链管理系统设计(编辑修改稿)内容摘要：

企业为核心， 优化整个供应链上企业的资源配置 ，并 满足以顾客需求为标志的商业需求的增长。 供应链管理的内容覆盖了从供应商的供应商到客户的客户的全部过程，一般来说， 包括管理供应与需求，原材料、备品备件的采购、制造与装配，物件的存放及库存查询，定单的录入与管理，渠道分销及最终交付用户。 供应链管理是当前国际企业管理的重要内容，也是我国企业管理的发展方向。 最初它起源于 ERP（企业资源规划），是基于企业内部范围的管理。 它将企 业内部经营所有的业务单元如订单、采购、库存、计划、生产、质量、运输、市场、销售、服务等以及相应的财务活动、人事管理均纳入一条供应链内进行统筹管理。 当时企业重视的是物流和企业内部资源的管理，即如何更快更好地生产出产品并把其推向市场，这是一种 “推式 ”的供应链管理，管理的出发点是从原材料推到产成品、市场、一直推至客户端； 随着市场竞争的加剧，生产出的产品必须要转化成利润企业才能得以生存和发展，为了赢得客户、赢得市场，企业管理进入了以客户及客户满意度为中心的管理，因而企业的供应链运营规则随即由推式转变为以客户需求为 原动力的 “拉式 ”供应链管理。 这种供应链管理将企业各个业务环节的信息化孤岛连接在一起，使得各种业务和信息能够实现集成和共享。 对于制造业来说 ,供应链管理的范围并不 局限于制造过程，也不应局限于单独的物流、配送或供应过程，而 是对企业资源的 全局规划 ， 是在 ERP 基础上通过构筑和前端客户、以及后端供应商的互动系统，来实现产品供应的通畅、合理、高效，既满足供应，又不保留大量库存进而积压，保持供应的高弹性。 比如代理商可以通过 Web 了解到当前各产品的供货周期、订单的执行情况、资金状况，而该企业则可以即时了解各代理商每个产品的 库存情况、销售情况，通过统计分析作出新的市场决策，大大提高了决策的准确性和时效性，同时使有限的资源得到更加合理的调配，缩短整个供应链的运作周期，降低交易成本。 需要着重讨论的一个问题是 SCM和传统的 ERP到底有什么不同。 对于这个问题，不同的开发商从不同的角度看，回答不尽相同，作者的观点是：由于 SCM 起源于 ERP，并始终与 ERP 结合紧密，因此 SCM 与 ERP 之间是没有绝对界限的，相反，随着技术的进步和商业动机的驱使， SCM与 ERP之间的趋同之势倒日渐明显。 SCM是从“供”和“需”两个 ６ 视角出发，将 ERP 的相关环节 抽取出来，重新审视与组织，以解决 ERP 不能对资源实时调整的缺陷。 近年来， 一些 有着多层销售体系的企业面临 着 各种各样的问题 ， 有的 需要把 不同的销售环节进行归并；有的则是要求把一个环节细分为多个环节；各层次之间的利益需要进行权衡；甚至有时会需要跳过某些环节就把产品或服务送到了客户手中，因此，这些企业会选择在他们原有的 ERP 应用软件中追加供应链规划的功能， 以减小因 承担分销成本提高至少 10 个百分点或者交货不及时、库存失调等各种问题出现的风险。 这些企业所面临的问题是由 ERP 静态资源数据表而造成的，因为在 ERP 提供的诸多规 划功能中，不同的物料、能力以及需求的约束因素是分开考虑的，互不相关。 SCM 软件则能够同时地考虑所有相关约束因素，提供对约束因素的真正实时调整 ，“综合考虑，实时调控”是 SCM 相对于 ERP 真正的优势所在。 而 SCM 之所以能从 ERP 中独立出来的原因在 于 ERP 的着眼点在于事务处理，很多 SCM软件不能做的事情在 ERP 中是应该进行处理的， 如果 非要把 SCM的专长追加到 ERP 软件内部去的话， 会导致 ERP 系统如果负荷过重、无所不管、运算速度大打折扣，所以，把 SCM的一技之长独立出来，倒不失为一个简单而有效的办法。 167。 造业供应链管理的目的 [1216] 供应链管理的最大作用是将产销活动中的各流程加以整合，使企业能以最快的速度，将产品由概念，研发推向市场。 实施供应链管理的目的在于缩短接单及交货周期，降低原材料及成品库存，提高对市场的反应速度，增加销售量，提高产品及服务的品质，掌握过程最真实的信息，加快货款的回收，改善公司与顾客之间的关系，这些从根本上说，都是从提高供应链的性能上实现的，一般来说，企业总是期望提高的有这样一些性能： 1) 更快，供应链上的 信息流、物流、资金流 更快的流动； 2) 更稳定，供应链上的 信息流、物流、资金流 更稳 定的流动； 3) 更廉价，供应链的维护操作花费更少； 4) 更少的库存，通过增强供应链功能减少企业库存。 通过性能的提高，企业期望得到回报，概括来说，企业的期望回报包括三类： 1) 更多的收入； 2) 更大的利润率； 3) 更快的资金回流。 在实际调研过程中发现这些只是企业的一厢情愿，企业期望的性能和期望的回报是有矛盾的，实践证明，并非一味的追求“更快”、“更稳定”、“更廉价”、“更少的库存”， ７ 就是最好的，也是不现实的，以上的这些目标必须有一个量度才能作为评价一个供应链的客观标准，基于该原因，供应链协会组织在 2020 年参考供应链管理目前 实施的状况提出了一组数据： 产品发送效率提高 16%28% 库存减少 25%60% 供应效率提高 20%30% 预测精度提高 25%80% 产品多样化提高 10%16% 供应链花费减少 25%50% 完成的循环周期减小 30%50% 这组数据基本可以作为评价一套供应链管理系统质量的客观标准，在本软件系统的设计也将以此作为一个预定目标。 ８ 第三章 系统需求描述与分析 167。 系统开发的第一输入：需求 [19] [30] [36] 一个大型的系统开发一般是分阶段进行的，系统最终的质量 决定于系统的各个开发阶段的结果是否精确，将系统实际的功能和理想需求的差异称为误差，那么根据误差积累原理，任何一个阶段产生的误差都会积在整个过程中积累，并且这种积累是非线性的，早期产生的误差在后续的每个阶段中被扩大，并最终积累到最后，假设系统总误差以δ表示，系统共分为 n 个阶段完成，第 i个阶段的误差为δ i,第 i个阶段的误差放大系数为ξ i,那么系统最终的误差可以用公式 ： δ =ni1δ inijξ j (i≤ n)…………… ……………………………… （ ） 在系统开发的过程中的任何一个阶段都存在输入和输出，任何一个阶段的输出保证正确的基本前提是上一个阶段的输出必须正确，从公式 可以看到误差出现的越早，对系统的影响越大，因此应该避免在系统开发的早期出现过大的误差。 对于软件系统来说，需求是整个系统第一输入，这个阶段的误差对系统的影响是最大的，因此应该格外的注意避免过大的误差，做好需求对于产生一个高质量的系统是至关重要的。 首先，借助 IEEE 的一段描述给出需求的定义： IEEE 公布的定义包括从用户角度（系统的外部行为） ，以及从开发者角度（一些内部特性）来阐述需求。 另外它所强调的一个关键问题是一定要编写需求文档，实际上，IEEE 软件工程标准词汇表（ 1997 年）中定义需求为： （ 1）用户解决问题或达到目标所需的条件或权能（ Capability）。 （ 2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所 需具有的条件或权能。 （ 3）一种反映上面（ 1）或（ 2）所描述的条件或权能的文档说明。 ９ 若需求未编写成文档，分析人员是无法对需求进行分析的，一堆邮件、贴条、会谈过几次或一些零碎的对话，是无法作为分析阶段的输入的。 从 IEEE的描述可以更通俗的这样认为，系统需求是一个模型，这个模型以成文文档的形式描述了产品是什么样的（而并非产品是怎样设计、构造），并可以作为分析模型的输入。 软件需求包括三个不同的层次 —— 业务需求、用户需求和功能需求。 业务需求（ business requirement）反映了组织机 构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求 (user requirement) 文档描述了用户使用产品必须要完成的任务。 功能需求 (functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 167。 供应链管理系统软件需求获取方法探讨 [3638] 167。 编写项目视图与范围文档 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。 项目视图描述了产品 所涉及的各个方面和在一个完美的环境中最终所具有的功能，它的说明使所有项目参与者对项目的目标能达成共识。 而范围描述了产品应包含的部分和不应包含的部分，它作为需求或潜在特性的参考。 本课题的项目视图是迎合制造业的信息化建设的要求，面向国内数量众多的中小型企业，为他们提供 优化整个供应链上企业资源配置 的工具。 而范围文档规定了产品的功能应重点集中在商务信息的传输部分，商务信息的处理可以留给企业原有的 ERP系统完成。 167。 ； 为避免出现疏忽某一用户群需求的情况，要将可能使用产品的客户分成不同组别。 他们可 能在使用频率、使用特性、优先等级或熟练程度等方面都有所差异。 详细描述出它们的个性特点及任务状况，将有助于产品设计。 将制造业用户群按如下的标准分类： 按制造方法分：根据制造活动与客户订单的提前期长短的分可分为订货生产、装配生产、工程生产和备货生产； 按生产类型分：根据产品结构和工艺特点来分可分为项目型，流程型和离散型三种； 按生产同种产品产量和生产同种产品的重复程度进行划分，可以分为单件、多品种、小批量、少品种重复生产、标准产品大量生产四种； 按信息化建设的程度分可分为空白、基本和较高和完善等几种； １０ 按企业规 模分，可分为微型 (员工人数少于 50 人 )、小型 (员工人数在 50－ 200人之间 )、中型 (员工人数在 200－ 1000 人 )，大型 (员工人数在 1000 人以上 )。 167。 选择产品代表； 为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。 这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。 而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。 他们必须一直参与项目的开发而且有权作出决策。 本系统介于内部信息产品和商业开发之间，所选的产品代表是 华工科技产业股份有限公司 XX 集成技术分公司下属的 MIS/ERP组开发和设计人员以及 XXMIS/ERP部分用户。 167。 把同类产品或产品的先前版本用户代表召集起来，从他们那里收集目前产品的用户需求和功能需求。 这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。 与产品代表的区别在于，核心队伍成员通常没有决定权。 本系统的同类产品是 XX公司原有的 MIS/ERP 系统，因此核心队伍就是 MIS/ERP组部分开发和设计人员，在开发过程中，大部分用户需求和功能需求是从他们那得到的。 167。 从用户代表处收集他们使用软件完成所需任务的描述 —— 使用实例，讨论用户与系统间的交互方式和对话要求。 在编写使用实例的文档时采用标准模版，在使用实例基础上可得到功能需求。 在需求调研过程中，使用专门设计的用户实例 (user case)表格来记载需求获取情节，在这套表格中，忠实的记载了用户的原始需求（没有经过分析的需求），表述了用户的请求和系统的响应动作，一般一个用户实例重点描述一个主流程 —— 普通过程，在主过程中可能会出现的分支作为可选过程描述，系统出现的例外以例外过程描述，另外在用户实例 表格的头部记载了此项需求的附属信息，表格的底部记载了需求的详细信息，附录一是一个对用户注册的需求获取情节的用户实例例子。 １１ 167。 召开应用程序开发联系（ JAD）会议 召开应用程序开发联系（ JAD）会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。 该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践，在本系统的需求获取过程中，分阶段的召开这样的会议，以确保阶段性的成果的正确性。 167。 分析用户工作流程 观察用户执行业务 任务的过程。 画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。 编制业务过程流程文档将有助于明确产品的使用实例和功能需求。 在这个过程中甚至可能发现客户并不真的需要一个全新的软件系统就能达到他们的业务目标。 本系统的这部分工作放在设计建模阶段完成。 167。 确定质量属性 在功能需求之外再考虑一下非功能的质量特点，这会使产品达到并超过客户的期望。 本课题考虑的质量属性包括：  数据精确度；  时间特性；  适应度；  界面形式；  界面风格；  软、硬件接口；  故障处理；  可使用性；  可维护性；  可移植性；  稳定性；  安全保密性。 这些质量属性将在后面详细阐述。 １２ 167。 客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。 但是客户过于频繁的问题报考会严重干扰正常的开发次序，甚至导致整个产品失败，在本系统的开发过程中，设置了一个需求基线 —— 《系统规格说明书》完成，当超过这个基线后，用户提出的新需求。