6 开发ERP系统的分析方法.docx
《6 开发ERP系统的分析方法.docx》由会员分享，可在线阅读，更多相关《6 开发ERP系统的分析方法.docx（37页珍藏版）》请在冰豆网上搜索。
6开发ERP系统的分析方法
第六章ERP系统的分析与设计方法
很多的方法论把分析和设计两种活动分开来，但其实这两者是很难区分的，做分析的时候会想到如何设计，而思考如何设计反过来又会影响分析的效果。
可以说，它们两者之间是相互联系和不断迭代的。
本书将结合ERP系统的特点阐述其分析方法和设计方法的要点，重点讲述的是方法而不是分析和设计的过程和结果。
对于ERP系统的具体的业务逻辑设计读者可参看本系列丛书的《ERP的实质与管理者的决策》分册。
6.1分析方法回顾
在2.1节，我们已经对软件工程的分析方法有了较为详细的描述，这里我们做一下简单地回顾。
软件系统的早期分析方法主要采用基于文字描述的非形式化分析方法，这种方法不太直观，对于复杂的业务逻辑难以描述清楚。
在70年代中期，随着图形化分析方法引入，许多半形式化和形式化的分析技术被设计出来，并被大量的结构化分析所采用，例如我们常见的处理流程图、数据流图、业务流程图、实体关系图、IDF、Petri网方法等。
90年代之后，面向对象的分析方法也逐渐普遍，例如人们常用的UML。
这些不同分析方法和技术，在不同的开发模式和环境下都被证明为是有效的，在ERP系统的开发过程中，不同的阶段可能会用到不同的分析方法。
这里我们并不想试图证明哪一种方法是最适合ERP系统设计的，因为这往往是徒劳的。
当我们开始同客户进行交流以确定业务流程时，可能会随手画出一个流程框图，虽然它不能精确地表达业务逻辑和数据的关系，但确实可以充当我们和客户交流的桥梁，把握住主要方向，进行有效地交流。
但是我们要想依此就进行开发，显然还有许多工作要做。
这些工作包括需求分析、概要设计、详细设计、架构设计及组件设计。
在这些过程中，许多方法都被证明是有效的。
虽然，UML设计了一套可以贯穿整个设计过程的模型，但是，一方面使用这样的模型可能意味着更多的投入，而且这些模型可能太复杂，用它和用户进行交互不一定能取得好的效果；另一方面，许多ERP系统地设计和开发是在一定原型上进行的。
因此笔者认为，在ERP的设计阶段，开发者还是应该灵活地对待设计工具和使用设计模型。
其关键是要做好各个设计和开发阶段的控制，使之有效的运作。
本章将着重给出在这些过程中ERP系统分析主要内容或方法，以强调ERP系统开发过程中，所涉及的几个主要分析阶段要达成的分析结果，这些结果对于保证ERP系统的开发质量将起到关键性的作用。
6.2ERP系统的总体分析方法
6.2.1总体分析方法
对ERP系统的总体分析方法，可以从两个方向上展开。
一种是从企业的业务流程上展开，沿着业务流程的走向，不断进行深入设计，这被称为纵向展开的设计。
一种是从ERP总体结构上展开，从贯穿企业各种业务的各种管理对象，如信息、资金、物料等状态变化上展开设计，这被称为横向展开的设计。
实际当中我们往往综合使用两种方法，以达到优势互补的目的。
6.2.1.1按业务流程展开
ERP的总体业务分析可以沿着企业的业务流程纵向地展开，这种展开方式可以有自顶向下和自底向上两种。
自顶向下的方式首先着眼于系统的总体方向，把握住大局，然后再逐步细化其中的细节，这是一种系统规划的方式。
这种方式使得我们不至于在着眼于业务细节时迷失系统设计的方向。
当我们对ERP系统在总体结构上已经有了较为清晰的认识时，可以采取这种方式。
自顶向下设计的一般的做法是按照业务的同一性质将各种业务归并为ERP的若干个子系统，然后绘制出各个子系统之间的关系。
随着子系统的增多，系统之间的关系将变得越来越复杂。
在图5-3中曾给出了一个传统ERP的子系统关系图，虽然该图所表达的各子系统之间的关系十分粗略，但已经让人觉得难以把握了。
已有的研究表明，设计者在同一个时间往往只能将注意力集中在5至6个设计对象上。
据此人们开发出了许多逐步求精的设计方法，例如多层的数据流图、IDF0图等等。
在这样的方法中，首先可以将ERP中较多的子系统按照业务或功能的同一性质划分为几个大的分系统，确定这些分系统之间的结构关系，然后再逐步将每一个分系统拆分为子系统，子系统可以再拆分为模块，模块还可以再拆分为功能。
在逐级拆分的时候，必须保持上下级结构的一致性，例如上级获得的输入一定在下级中有对应的处理，而上级的输出也必须有下级的输出相对应。
如图6-1所示的为ERP系统的功能模型图──IDEF0图。
IDEF方法已经在第二章中介绍过，它是结构化分析方法的一种重要形式，特别适合于大型的、复杂的人机工程系统的设计。
在图6-1中将ERP系统分为6个分系统：
基础数据（A1）、市场营销（A2）、物资供应（A3）、生产制造（A4）、财务管理（A5）、综合管理（A6）。
虽然分系统的力度已经很大，但是其交互的界面还是很多的，例如基础数据（A1）的OA业务输出成为各个分系统的实现条件，物资供应的库存信息输出成为市场营销系统的控制条件，生产制造的领料信息输出成为物资供应的输入等等。
在图6-2中，进一步将基础数据分系统划分为：
制造数据（A11）、工程变更（A14）、系统管理（A15）、办公自动化（A16）几个子系统。
A1的界面信息被分解到A11至A14中。
通过这种方式，系统的分析粒度被逐渐缩小，直到功能一级。
在这个的例子中我们可以看出，IDEF0图通过自顶向下的方式，可以将ERP系统的复杂性逐层分解，使人们可以在不同的层次上更容易地把握系统的功能，它所代表的就是一种逐步求精的设计方法。
虽然从形式上说，IDEF0图是结构化分析方法的一种，但它采用了面向对象的分析思路。
从图中可以看出，它主要不是反映过程化的业务----即业务流程，而主要反映的是业务的功能，功能之间由信息驱动，这正是面向对象的分析特点。
图6-1ERP系统功能模型图
图6-2基础数据子系统功能模型
自底向上的分析方法一般用于一个全新系统的开发，这种系统没有先例可循。
在对系统设计时我们还不能准确地把握系统的规模及方向，此时就需要设计首先从底层的业务描述开始，然后在此基础上再进行分析、总结、抽象、归并、集成等，逐步完成整个系统的设计。
在ERP系统的实施中，有时需要进行二次化修改，由于对所实现的业务不完全了解，就经常采用这种方法对系统进行初步的业务需求分析。
此时我们通常使用跨系统的业务流程图来表达不同子系统之间的交互界面及业务流程。
如图6-3所示的是某厂生产系统的跨部门业务流程图。
图6-3生产计划系统跨部门业务流程图
图中将该厂和生产业务相关的所有业务部门及生产流程绘出，然后分析人员可以在此基础上按照部门之间的交互界面，对功能或子系统进行划分绘制出IDEF0图或用例图等。
跨系统的业务流程图往往用在系统的设计初期，不同于IDEF0图自顶向下的设计方式，它所主要关注的是企业的底层业务流程。
在实际的业务分析中，我们通常综合运用自顶向下和自底向上的设计方法，因为缺少总体把握和规划的设计容易使人偏离目标，而缺少业务细节的掌握会使我们无从起步。
自顶向下的设计明确了我们要去的目标，而自底向上的设计则使我们明白我们现在在哪儿。
这两个条件是我们建造ERP这个大厦的起点。
6.2.1.2从总体结构上展开
ERP在经过多年的发展之后，已经有了较为成熟地理论及结构体系。
在开发这样的系统初期，往往不需要从其实现的底层业务着手，特别是在搭建系统总体结构时，更多的是要从整体上分析ERP系统所处理的管理对象。
例如资金流、物流的分析，以及系统是否应包括办公自动化，基于工作流等方面。
这些管理对象是贯穿整个系统的，它不仅仅体现在某些具体的业务上，只有跨过独立的ERP业务子系统，从整体上看待它们，才能把握住系统的开发方向。
这就是从总体结构上展开的分析目的。
这里我们从企业管理对象及管理层次上来分析ERP系统的构建特点。
企业管理对象分析
企业的管理对象可分为两大类：
一类是流动的管理对象，一类是静态的管理对象。
流动的管理对象，主要有三种：
它们是物流、资金流和信息流；静态管理对象则较多，但主要有固定资产、员工、档案等内容。
这两大类管理对象各有其自身的特点。
首先，让我们来看流动的管理对象。
物流分析
物流是指在原料进入企业进行生产到产品离开企业这样一个完整的物流过程。
这是生产性企业的一个最主要、最基础的管理对象，也是国外各种企业信息系统理论研究的焦点。
如MRP、MRPII等都是在物料平衡的基本规律指导下提出的理论和指导思想。
随着INTERENET和电子商务的出现，这一流程又与供应商和用户结合起来，形成一个社会化通过市场机制联系起来的供应链和价值链。
物流在企业内外部是由多个环节组成。
物质从一个环节流到另一个环节，必然带来物质属性的变化，如位置的变化，隶属单位的变化，生产过程中的合并和分解等产生名称和数量的变化，而这种流动和变化都是按照人们的意愿、遵循一定平衡规律进行的。
这些环节的节点就是我们管理的基本出发点。
管理要做的事情：
第一完整地了解变化的情况、采集变化数据;第二根据计划控制物流在节点间的流动，这一工作是通过各种管理业务流程来完成的，如：
采购业务管理、入库管理、出库管理、生产作业管理、销售管理、质量管理等等。
第三是根据企业需求、能力和物流运动的平衡规律来制定计划，并将计划分解到物流的每一个环节。
为物流的运动和控制提供依据。
资金流分析
可以说资金流是企业的血液，没有它企业将一事无成，对它的管理则又象一把尺子，是衡量我们每一项工作成败的主要标准。
它的流动在管理中是最严格、最细致的。
对它的优化给企业带来的效益也是巨大的。
资金流的管理主要是财务管理方法。
目前我们国家已经有了十分完整的会计核算体系、财务管理方法和财务分析方法。
这些管理方法是我们在信息化建设中必须遵循的，而且也十分成熟，但是，有三个方面的问题是我们在系统分析中应该考虑的。
第一点是财务系统和其他管理之间的关系；如和物流之间的关系，物流在流动的过程中价值是在不断变化的。
它遵循这样一个规则：
价值=数量X市场价格。
每一个环节都是如此。
反之，我们在每一个环节都需要付出代价，这个代价体现在它的成本上，价值-成本=增值。
在物流的每一个环节上，都存在这样的规律，这就是建立在物流之上的价值链。
这个价值链反映了企业生产经营活动初过程中的一个增值的过程。
要反映这个价值链必须使财务信息源渗透到物流每一个环节中去，使财务管理能够准确、全面和及时的反映数据背后的经济活动，并能够及时有效的加以控制。
这是手工管理和现有的会计帐本无法做到的，而在计算机信息系统中则是完全可以做到的。
第二点则是现有的会计制度中会计信息是按照科目来进行归结的。
这是一种层次性的归结方式，这种方法无疑是科学、合理的，但是并不能完全满足人们的需要；而在企业信息系统中则可以增加多种的归结方式，在不改变按会计科目记帐的同时，增加其他方式的归结，使我们的管理更加灵活，如按任务进行归结等。
这就象在图书馆里，不仅可以知道文艺书有多少本，而且也可以知道某个作者有多少本书，某个出版社有多少本书一样。
当我们有了这些分类手段，财务分析就十分方便和灵活了。
第三点是财务数据对企业运行状况的反映是滞后的，它的反映周期为月和年。
而企业要求实时地反映企业营运状况，只有实时地反映企业营运状况，才能正确地经营决策，合理地组织生产，有效地控制成本。
在企业信息系统中财务数据对企业运行状况的反映应该细化到天和班组。
信息流分析
在企业信息系统中，信息流是一个基本的管理对象，在数据库的设计和分析中有一套完整、科学的方法来组织它们。
但从ERP系统的角度上分析，信息流主要有四大类：
（1）采集到的原始信息；
（2）统计信息；（3）计划信息；（4）控制信息
采集到的原始信息应包含及时信息和历史信息两部分内容，统计信息来源于原始信息，逐层浓缩，最终反映企业的生产经营状况；计划信息是以市场需求和管理对象变化的规律为基础，至上而下，逐层分解，细到企业每一个可执行单元；控制信息是和业务流程紧密相关的，它主要表现为：
业务流程的定义、权限设置以及相关的静态数据表格等。
信息流的管理主要要注意三个方面的问题：
第一个方面是信息的采集必须有完整的记录管理对象和变化过程，并按照层次进行归结，最终反映企业生产、经营、管理活动成果和效益；第二个方面是计划信息是以市场为源头，以ERP为指导思想，它必须涵盖企业的主要管理对象以及这些管理对象的变化过程，以保证企业的资源在整个计划体系中；第三个方面是控制信息，它的管理是最复杂的，变化多、难以统一，它又和每一项工作的业务流程紧密相关。
如在物流中，供应商到库房存在着大量的管理工作，市场调研、招标、合同、运输、海关、质检等产生大量的管理信息，因此，我认为这是信息系统建设的难点，但不是全系统的重点。
在系统建设中它体现在各个功能分系统中，是各个功能分系统的重点。
以上是对流动的管理对象的一个基本分析。
对于流动的管理对象应该做到全流程的管理，在信息系统中管理完整性本身就具有价值。
三流的统一
企业的管理对象本身是一个互相关联的整体，这就是人们常说的资金流、物流和信息流的三流统一，如图6-4所示。
通过客户市场的拉动，企业获得市场的产品需求信息，从而制定生产计划。
而随着生产计划的需要，物质从原料供应市场经过生产加工成为产成品，供给客户市场。
而在这个过程当中也完成了资金从客户市场流入，从原料市场及生产过程中流出的循环。
图6-4三流的统一
静态管理对象的分析
在企业中存在大量的静态管理对象，如设备、生产线、员工、档案等。
这些管理对象存在一个共同的特点，就是：
他们的基本属性是不变的或很少变化的。
如设备的名称、生产厂、主要用途和性能指标等是不变的，变化则是它们的运行状态，隶属单位、价值等属性。
企业的员工也是如此。
姓名、性别、出生年月等是不变的，变化则是他们的单位、职位、经历和能力等。
这类静态管理对象在企业中都有其自身的生命周期。
比如，设备从它进入企业，到它报废或转出企业，则是它相对于本企业的生命周期。
在静态的管理对象中，生命周期性是一个最基本的特点，围绕着这个特点在系统分析中则可以将反映它们的属性分为两类。
第一类是反映它们不变的、基础特征的属性；第二类是反映它们变化情况的属性。
如果我们把静态的管理对象看成是一种资源的话，则它的变化对企业的能力（如生产能力、管理能力、技术能力、运输能力等）产生直接影响。
我们在系统分析设计中要抓住这些对象对企业产生贡献的那一部分要素，设备则是要延长其寿命的运行时间，使其分摊到每一个产品中的成本最小。
对企业员工的管理也是如此，员工能力和作用是重点。
通过以上分析，我们可以看出企业管理对象的不同，它们的变化规律也是不同的，对它们的管理方式和要求也是不同，显然对静态管理对象的管理是全生命周期，只要我们认真的分析就可以明确信息系统建设的重点和切入点。
因此，我认为企业ERP系统一定要实现对动态管理对象的全流程管理和静态管理对象的全生命周期管理。
在这些管理对象中，信息流和资金流是依赖于其他管理对象而存在的，只有分析清楚其他管理对象之后，才能有条件来分析信息流和资金流。
功能层次结构分析
我们已经熟悉了按照业务的经营同一性质来分解ERP的各个组成部分。
这就是所谓的业务模型的纵向划分。
而按照业务的管理同一性质还可以将ERP系统进行跨系统的纵向划分。
如图6-5所示。
图6-5ERP系统的横向及纵向层次划分
进行纵向的划分，可以使我们从总体上规划ERP系统业务的适用范围、权限的配置等问题。
6.2.2软件总体结构分析方法
6.2.2.1B/S还是C/S
ERP系统采用C/S（客户/浏览器）结构还是B/S结构一直存在很多争议。
对于两种结构在软件实现上的差异主要在7.2节阐述，这里我们主要从ERP业务方面作一些分析。
坚持B/S结构的人认为，基于B/S结构的分布式计算代表了企业业务管理的发展方向。
而坚持C/S的一方则不以为然，认为B/S结构在客户端方面存在先天性的不足，不能适应ERP的所有业务。
其他很多赞同这一观点的人则认为采用C/S及B/S的混合结构最符合ERP系统的特点。
例如对于销售、采购等和企业外部交互较多的业务采用B/S结构，而对于生产、财务等主要面向企业内部的业务则采用C/S结构。
笔者认为无论哪一种结构都还有其发展的空间，它们都在不断地发展中克服或弥补各自的缺陷。
因而目前就对采用哪种架构作出结论，为时尚早。
但是ERP的开发者在搭建系统构架时应该考虑以下几个问题可能有助于您的决策：
1）ERP系统是否有大量的异地化业务。
诚然将财务管理作异地化业务配置的企业不多，但确实存在，我们开发的ERP系统要针对这样的业务吗？
2）ERP系统客户端的数量是否很大。
如果可能有成百上千的客户端要安装，其维护的工作量可能是巨大的。
3）ERP客户端要保持很强的动态性吗？
B/S结构显然还不能适应客户端与服务器端有大量实时信息交互的要求，其客户端也不能处理复杂的数据结构。
典型的例子是，可视化的报表设计器如果采用B/S结构，其实现将会非常困难。
4）既然B/S结构在面向电子商务的管理方面已经体现了巨大的优势，并有可能成为ERP系统发展的主流，那么请反向思考一下，在你将要开发的ERP系统中还有哪些业务不能用B/S实现。
6.2.2.2使用多层架构
采用基于表示层、逻辑层、数据层的多层结构构建新一代ERP系统几乎是毋庸置疑的。
在8.3节中对多层体系结构作了较为详细的阐述，这里不再赘述，只是要强调一点，企业业务的多样性及复杂性只有采用基于构件技术的多层体系结构才能使ERP系统具有更好的可维护性及开放性。
6.2.2.3需要工作流吗
将工作流技术引入ERP系统既是一个令人兴奋的挑战，同时也给不少人带来了疑惑。
工作流技术的引入将会把ERP系统的管理范围扩展到业务流程的控制方面，同时配合以软构件技术，可以在很大程度上解决业务动态建模的问题，从而支持企业的业务流程重组。
这将为过去一直困扰ERP软件厂商多年的、ERP系统的适应性问题提供一个有效的解决方案。
然而，工作流技术确实能带来人们希望的效果吗？
人们也许会担心，如果过分强调工作流的动态可配置性，ERP的开发商也许会减少对企业业务及数据关联性的关注，而导致ERP软件更加缺少针对性，反而增大实施的难度。
人们的关心也许是有道理的，不过工作流技术还在发展的初期，它在许多相关的信息管理领域已经崭露头角，体现了生机勃勃的发展趋势，虽然在ERP领域还鲜有成功的案例，但是它在新一代ERP系统中的地位是不可动摇的。
因此在国家正在制定的新一代ERP标准中，工作流技术被作为一个单独的专题加以研究。
6.2.3开发技术分析
6.2.3.1开发技术体系结构概述
目前在Internet/Intranet/Extranet环境中，企业级应用系统大多采用三层或多层应用模式。
为了方便开发、部署、运行和管理基于多层结构的应用，需要以网络和分布式计算的底层技术为基础，构建一个完整的应用框架，提供相应的支撑平台作为多层应用的基础设施，这一支撑平台的关键就是位于中间层的应用服务器。
应用服务器是一个创建、部署、运行、集成和维护多层分布式企业级应用的平台。
如果应用服务器与Web服务器相结合，或者包含了Web服务器的功能，则称之为Web应用服务器。
在企业应用中，应用服务器可以提供如下好处:
提高企业应用开发的有效性，保障业务逻辑和组件的重用性；提高企业应用的性能，如高运行性能和响应时间、可伸缩性、可靠性等；使企业应用更易于监控和管理，降低系统维护和升级成本。
由于应用服务器的要作用和关键地位，它已经成为当今业界的一个热点。
从实现技术的角度看，可以将应用服务器划分为基于J2EE的解决方案、Microsoft.NET解决方案和其他技术3大类。
近年在应用服务器市场上最具意义的进展，就是J2EE（Java2PlatformEnterpriseEdition）的出现。
J2EE是Sun公司提出的开发、部署、运行和管理基于Java分布式应用的标准平台。
它以Java2平台标准版（J2SE）为基础，继承了标准版的许多优点，还提供了对EJB、JavaServlet、JSP等技术的全面支持。
J2EE使用EJBServer作为商业组件的部署环境，在EJBServer中提供了分布式计算环境中组件需要的服务，例如组件生命周期的管理、数据库连接的管理、分布式事务的支持、组件的命名服务等。
J2EE用于实现应用服务器有其优势，它可以利用Java语言自身具有的跨平台性、可移植性、对象特性、内存管理等方面的性能，为应用服务器的实现提供一个完整的底层框架。
J2EE中定义的各种服务，包括JSP和Servlet容器、EJB容器、JDBC、JNDI（名字目录服务）、JTS/JTA（事务服务）、JMS（消息服务）等，也分别为应用服务器提供了各种支持。
目前，基于J2EE的应用服务器主要有BEAWebLogic、IBMWebsphere、Oracle9iAS、SuniPlanet、SilverStreameXtend等。
另一方面，微软在应用服务器上的解决方案代表了另一种思路，可以说，选择了微软的应用服务器解决方案也就意味着选择了完全的微软平台。
微软的目标是分布式的Web应用开发环境，它并没有提供一个类似通常所说的应用服务器的软件或软件包，而是将WindowsNT/2000看做其应用服务器的基础，通过附加一系列具备中间件功能的软件包来实现应用服务器平台。
目前，应用服务器的实现体现在微软命名为.Net的Web应用开发框架中。
.NET战略引入了许多新概念，包含了一些新的技术，如WebServices和C＃语言，但.NET在很大程度上是微软以前开发的企业级应用平台DNA的重新包装。
微软在.NET中提供了一系列企业级服务器，为部署、管理和建立基于XML和Web的应用构筑了.NET服务器结构，包括ApplicationCenter、BizTalkServer、CommerceServer、ExchangeServer、SQLServer等，它们结合Windows平台上的一系列开发工具和技术（包括VisualStudio.NET、ASP.NET等），提供了强有力的应用服务器解决方案。
由于应用需求和技术的原因，尚有一些应用服务器使用其他语言和技术实现。
Macromedia公司的ColdFusion服务器就是采用标记语言CFML（ColdFusionMarkupLanguage）实现，使得熟悉HTML的开发者能够简单快速地进行应用开发，在开发的简单性和快速的生产力方面较有优势。
ColdFusion的目标是致力于中小型的企业应用环境，但是它也具有高性能和良好的可靠性，在市场上仍能占有一定的份额。
PHP是开放源代码的服务器端脚本语言，它为实现应用服务器提供了一种易于编程的实现手段，PHP应用服务器的代表有Midgard和PhpLens。
Zope则是使用Python语言编写的开放源码应用服务器，它也为Web应用提供了完整的实现框架和手段。
从本书的第10章开始，我们围绕着J2EE和.Net两大主流架构进行了深入地讨论。
6.3需求分析方法
6.3.1ERP需求分析的层次
从开发的角度讲，ERP系统的需求分析按照企业的业务类型可分为三个层次，总体需求、用户需求及功能需求。
这三层需求对应了RUP模式中的业务需求、用户需求和功能需求。
总体需求是ERP系统要达到的实施目标或应用效果，它包含了基于ERP管理思想的基本哲理和方法，它即来源于用户需求，又反过来指导业务模式，有时在总体需求的指导下需要企业进行业务流程的重组。
用户需求是功能需求的集合，具体的功能需求完成用户需求中的各个执行步骤。
一般情况下，ERP的需求分析采用自顶向下的分析方法，即首先确定总体需求，然后分析业务流程得到用户需求，最后得到实现管理业务的功能需求。
当然，对三者的需求分析可能有交互往返的过程。
在需求确定后，应编制需求规格说明，以开发团队能共同理解的方式表述需求。
另外，从需求的性质来划分，还可以将需求划分为功能性需求和非功能性需求。
功能性需求定义了软件能够做些什么，非功能性需求定义了一些
升级会员 