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