业务流程初步收集指南v2Word格式.docx

业务流程初步收集指南v2Word格式.docx

《业务流程初步收集指南v2Word格式.docx》由会员分享，可在线阅读，更多相关《业务流程初步收集指南v2Word格式.docx（21页珍藏版）》请在冰豆网上搜索。

项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。

流程需求自身经常变动

根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。

事实上，历史上没有一个软件的需求改动少于三次的！

所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。

IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。

另外流程建设需求有其自身的需求梳理特点，不完全和传统需求方法论一致，因为传统需求方法更多适用于为职能部门开发的业务系统，业务领域更多关注在相对独立的业务体系内，如考勤管理，销售管理等系统，而流程需求分析则需要从更高层面进行抽象建模，如企业内控制度，岗位权限，财务制度等。

2.流程需求方法论

3.1需求规划：

调研结构规划

I.静态调研报告结构

业务调研结束后，需要收集到的原始文件盒调研记录进行整理，形成规范而有价值的业务调研报告。

目标是到业务调研报告不需要与客户再次沟通就能通过业务调研中抽象出的系统需求和一起需要的信息。

我们把业务调研报告分为静态业务和动态业务两类

上图的组织架构是比较典型的静态结构模型，在静态业务抽象时，彩雀逐层细化的过程。

可以这样推理，一个公司至少包含一个或多个部门，一个部门可能包含一个或多个岗位。

一个岗位可能要处理多个表单或数据。

对部门职责描述，应该采取表格形式最晚有效和准确，如下部门职责描述模板：

部门编号

“按照企业要求编写”

部门名称

不为空

直接上级

“填写主管部门名称”

部门性质

部门级别

编制人数

数值

下属部门

下属部门是指部门领导的下级部门

部门职能

职能1[详细描述]，尽可能描述本部门的职能，已经与之较好的上下游部门

职能2[详细描述]

具备条件

《部门职责描述模板》

职位编号

单位人事编号

职位名称

组织架构图对应

所属部门

组织架构对应部门

职位类型

上级职位

根据人事部门提供填写

编制日期

需要就每个岗位所承担的职责详细描述，通过岗位职责描述，全面了解岗位所承担的责任和具体工作细节，便于通过岗位职责挖掘用户需求。

需下图模板：

序号

工作职责（按照重要程度排序）

时间比例

关键指标

1

工作职责详细描述

占考核指标币种

2

其它工作职责

《具体工作职责描述》

另外，原始资料整理，本阶段的主要职责是每个岗位中的工作人员需要的原始资料进行整理和分析，分门别类的处理，原始资料是业务系统分析的静态结构的主要数据。

也可以使通过原始资料整理，获取业务运行的业务规则，如下图：

《业务表单模板整理》

表单编号

表单名称

岗位职责中用到的名称

表单类型

编制单位

所在部门

使用部门

列出使用此表单的所有业务部门

是否自产生

是/否

岗位名称

表单拥者岗位

处理周期

时间

《数据集1》

数据项目编号

数据项名称

标示符

数据类型

长度

初始值

范围

项目组约定

.NET数据类型

《数据项处理逻辑》

数据项编号

（20141021）

简述

说明本表单中数据项处理逻辑

输入的数据流

如：

编号为数据项编号

数据项名称为中文

标示符为GUID类型

处理逻辑：

计算方法，如采购品项的单价求和=采购总价

输出的数据流:

编号为数据项编号，

属相名称为中文名称

处理频率：

1周以内

II.动态流程需求结构

业务流程图示一种描述单位组织内各单位，人员之间的业务关联性，工作顺序，和管理信息流向的图标，利用业务流程图可以帮助分析人员找出业务流中的不合理流向，它是物理模型。

业务流程图同时也是系统分析人员设计系统用例的基础。

流程图分为两个层面一个层面是描述部门之间的业务流程，称为顶层业务流程图；

另一个层面是针对岗位之间的业务流程图，称为底层业务流程图。

业务流程图的格式也有多种多样，经常用到的泳道式业务流程图，泳道式业务流程图作用包括，泳道流程图有助于分清在流程过程中每个岗位的工作范围；

泳道流图有助于研究流程中人与人或工作小组与工作小组的交接动作。

运行节点描述,在上图中，泳道的部门或岗位描述已经在前面章节中有具体描述,在业务流程图中，只有运行节点，没有对其具体的描述，NTTDATA团队会为期定义详细的模板用以扑捉精确的需求。

运行节点名称

“选择业务流程图中的节点，如部门经理

办理部门

“本运行节点所在的部门”

办理人与职务

指本运行节点的处理岗位，也是泳道上知名的部门或运行岗位

办理时限

用来说明本运行节点处理所以需要的最低时限

业务描述

对本及诶单的业务描述

运行节点是否需要跳转

否/是

跳转到第几步?

跳转节点编号

跳转条件

“描述本运行节点条件判断和跳转条件

相关操作

1.受理，2，不受理，3，撤回，4…

是需要历史数据比对

1.需要，2不需要

本环节所需要的材料

列出本环节需要填写的所有表单资料

需要打印的资料

III.非业务流程调研

所谓的非业务调研其实就是在企业现在业务运行的基础上，对客户进一步沟通，了解客户在业务范围之外的一些特别状况。

比如客户系统的运行地域性、部门变动性、业务流程的变化性、岗位职责的变动性、和文件资料的变化性。

主要有以下几个层面的调研：

l地域性调研

地域性分析,以程应用使用者的地域分布情况来看，也就是业务流程是在一个部门内运行还是在多个部门？

是在一个地域内，还是跨多个省或低于，关于地域性分析非常重要，这直接决定了平台架构过程中所使用的底层架构和硬件配置，地域性分析为需求分析报告编写过程提供了很重要的依据

l部门变动分析

部门变动性是指部门的组织结构调整的频繁程度，组织结构的调整应该包括，依据结构的调整和机构内部岗位的调整，以及这些机构调整对系统的影响，这是业务调整过程分析中容易忽略的地方，因为部门的变动性某种意义上会影响系统功能划分的力度，过小的力影响软件开发的质量和进度，过大的力度会影响客户系统的灵活性。

l业务流程变化调研

业务流程变动是指在现有业务流程的基础上，组织结构内部对业务流程调整的频度，如业务顺序是否随时可能调整，在同一业务中对岗位的调整频率，这种变化对系统运行的影响等，业务流程的变化决定了软件系统架构中关于工作流的应用问题。

比如如果业务流程非常频繁的话，在软件开发过程中是否要完全采购流程平台自身原生机制，流程平台确实能够很好的事业业务不断变化，但是开发成本相对较高。

l岗位职责变化分析

所谓岗位职责编号，是指某些岗位的工作职责的编号频率问题。

例如某一个岗位可能随时调整工作内容，有些岗位调整工作内如频率较低，岗位职责变化分析属于微观层面的系统分析过程。

这样决定了在系统功能模块组织中，这里采取的粒度大小问题。

粒度过小反而影响了用户体验。

粒度过大，减少了系统运行灵活度。

总结以上所述，在BBA整体系统扩展或架构中，需要详细的静态结构需要，和动态结构需求，动态模型描述了业务调研报告的动态结果，在最后的非业务性需求调研中可以对技术和开发架构设计具有重大意义。

3.2需求分析：

视图分析法

业务流程应用是一个从高层战略驱动到底层执行的活动抽象过程,成功的关键因素是系统的管理人员、业务人员、开发人员之间的互相理解和通信。

因此,在需求分析阶段把应用领域的知识提取出来,用适当的概念模型（需求说明）表达出来,并采用合适的方式进行评估,以保证需求分析所建立的模型真实地反应了需求，以往，更多的需求方法多是采用文字需求描述的方式，或者只是用Activity图形表示了大致的流程走向，很难如实表现出业务流程的细节需求，造成开发过程反复。

I.数据视图

主要用于识别流程系统中涉及的3类数据源：

业务数据或表单类型数据

外部数据，来自于第三方系统

流程元数据

在经前期的需求调研之后，收集了许多需求分析报告，但是很少团队或组织提到过将数据字典作为需求分析阶段重要的内容来做，系统的数据视图作为系统分析的重要工具，对梳理数据在业务流程与组织，或者业务流程与企业应用系统（如，SAPHR）的过程非常重要，在结构化分析过程中，数据视图的作业是给数据流程图上每个成分加上定义和说，可以将数据进行统一的定义，避免产生歧义。

在数据视图中所有的元素定义和解释会有助于改进分析人员和用户的沟通，明确细节和相互关系。

防止遗漏，充分，和冗余，规范文档，有利于检查和用户沟通，以指导流程系统的开发和编程。

解读前期调研报告，编写与设计数据视图，在业务流程开发项目中，我们逐渐积累了一下原则：

按照统一的编制规则来编写数据视图

元数据的选择应该结合业务流程规则编制

元数据的描述应具有反应数据自身特点的独立性，既与流程系统结构和功能无关，但对系统的开发有必然的意义

II.流程视图

在流程梳理过程中，使用统一建模语音（UML）整理业务流程的各个节点，以及每个节点与数据和业务规则的关系，最重要的是识别出每个节点的处理人或相应的岗位在组织架构上的权限。

如下图：

节点

汇报关系

流程功能

邮件方式

无

a、b、c、d

2，审批人员为部门相关的人员，包括项目经理、部门经理、部门总监等

e、f、g

A、B2、B3

3

2，审批人员为部门相关的VP或SVP职位的人员

4

2，审批人员为部门相关的执行部门、协作部门的人员，包括项目经理、部门经理、部门总监等

5

2，审批人员为财务部人员

e、f、g、h

6

2，审批人员为法务部人员

e、f、g、i

7

1，审批人员为财务总监

8

1，审批人员为CFO