ERP阶段实施之概要设计阶段的分析（上）（by AMT 曹伟）

摘要：项目可行性分析是针对实施的可行性进行分析的，而并非给出系统在业务领域模型，其在系统解决方案上给出的是客户需求的原始模型。

ERP阶段实施之概要设计阶段的分析（上）

－－如何编写中小企业ERP项目概要设计说明书

by AMT 曹伟

在项目的可行性分析报告中，主要以技术的可行性分析为主，立足于项目的技术上、实现上的难点进行阐述，逐步理清楚客户的需求，并在需求的基础上分析了系统的用例(use-case)，给出系统的业务用例模型（在系统上给出解决方案），根据系统的业务用例模型，建立业务对象的分析模型。

项目可行性分析是针对实施的可行性进行分析的，而并非给出系统在业务领域模型，其在系统解决方案上给出的是客户需求的原始模型。

如何根据业务领域模型进行逐层分解，最终得出系统的分析模型？

1． 分析模型的建立

在项目的解决方案中，论述的主要客户中存在问题，以及如何解决此问题的方式方法，给出了系统的架构，但在论述时侧重于整个系统实现、架构，而在这里我们将侧重点放在客户需求的功能描述上。

假如用户给我们提供了需求，此需求将存在以下特征：

1．使用一般性的语言描述。

2．通过对各个业务流程描述，提供流程图。

3．定义基本的常见的业务术语，注明术语的范围，使用条件及相关的约束。

4．需求可能不全面。

故我们针对上面的客户需求，建立用例模型时存在如下情况：

1．通过用例来构造，提供外部视图的结构。

2．主要用于客户和开发人员之间签署合同时明确该做什么，不该做什么。

3．需求存在冗余和不一致的情况。

4．其模型需要进一步分析和补充。

无论是用户提供的需求，还是我们的系统分析人员根据需求建立的用例(user case)模型，其中描述的第四条着重说明需求及需求分析不完善，为什么？

在ERP系统的分析上，涉及面的广，是以前各种软件系统分析所不能及的。而且无论是用户还是ERP厂商的系统分析员都无法在一两次内就把具体的、详尽的需求落实，如果可以落实，那么ERP系统的实施就不再存在诸多风险性因素(关于项目的风险参见项目计划的风险分析)。

如何协调和分析系统功能并建立相关的模型：

在<之一：如何编写企业解决方案书 designtimesp=4476 designtimesp=12057 designtimesp=12117 designtimesp=2057 designtimesp=14327 designtimesp=14361 designtimesp=14398>第5段描述业务工作流，该工作流就是将要开发系统的所面对的功能部件，其描述采用的是一般性的语言，若采用RUP(Rational Unified Process)进行项目跟踪，则需要将业务工作流进行建模，将业务流程的各个过程以及各个过程间的关系映射到用例模型，然后以用例为基础，进行架构上分析、整理，得出各个阶段的制品(Artifact)。

由于我们在此讨论的话题和RUP有些出入，RUP主要侧重于项目系统的实施的过程，而该系列的文章侧重对项目的管理、跟踪和控制(若读者对RUP感兴趣，可参见www.51cmm.com 曹伟专栏)。

以下概念：

1．用例模型（Use-Case Model）：一个包含参与者，用例以及他们之间关系的模型；即描述一个系统应为用户做些什么以及在那些约束限定之下的模型。

2．分析模型（Analysis Model）：一个对象模型，其目的是①精确地描述需求；②按某种方式构造它们，以便于对于它们理解、准备、改变，总之，以便于它们的维护；③作为在设计和实现中塑造系统的基本输入。

对于常见的订单业务，采用用例模型表示见下图：

图1：订单业务的用例模型

其对应的分析模型见下图：

图2：订单业务的分析模型

在概要设计中主要体现的是项目的主题内容，并不对各个细节进行详尽的说明，为此，设计模型的实施中我们将对该模型进行详细地分析。

2.设计模型的实施

以下的分析模型采用A公司的服装销售系统分析模型，主要是借该系统一条开发的线索，帮助读者理请分析系统的思路：（作者声明：为了保证A公司系统的信息安全性，作者在论述时系统的信息已作了修改。）

2.1系统的架构的描述

我们在解决方案提出的服装行业的系统是采用Web Service 的组织架构，基于Microsoft 的应用。数据库服务采用Microsoft SQL Server 2000 ，Web服务采用Microsoft IIS。在概要设计中需要重申系统的网络拓扑，以便说明的系统架构将建立在此基础上。

图3：系统网络拓扑图

针对系统的网络结构，系统将提供如下实现方式：

客户服务部的人员全部在线操作，所有的数据也完全实时在线录入和表现；客户心采用Internet 访问，可以采用远程直接操作，或采用单机版的模式，生成的标准模板的文件再导入主系统。为什么需要单机版的形式，针对这种服务的提供，我们进行了论证，主要考虑全国范围内很多地方没有网络化的条件。

2.2职能分配与组织结构图

该系统用户分三个不同的部门：客户服务部、客户和仓库。三个部门的业务交互图（仅仅画出订单业务部分）：（参见图4）

图4：销售业务交互图

以下针对职能分配和业务交互进行说明（订单部分）：

系统提供该职能分配表将是为系统设置权限、分配操作而拟定的。

2.3系统用户描述

由于系统是为客户服务部提供直接的服务，为客户服务部提供报表等统计性的信息，需要对各个岗位进行详细的说明。

客户服务部的系统的（订单部分）用户：

仓库的系统的用户：

客户的系统的用户：

未完待续

浏览：ERP阶段实施之概要设计阶段的分析（下）

本文由作者向AMT提供
作者联系方式：errorcao@hotmail.com

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友