业务流程初步收集指南v2只是分享

1、业务流社收集初步指南第一版作者：张辉1. 引言传统应用系统建设上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80 %是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用

2、户不习惯等。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。由于不同流程的特殊性与个性化要求，以及需求分析的高风险性，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。用户说也不清楚业务流程需求例如总部各部门及各地的财务报销制度，和员工招聘制度存在差异，但是又缺少一个能对所有组织管理制度都精通的业务人员，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一

3、定的主观性，为项目未来建设埋下了潜在的风险。流程需求自身经常变动根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT 中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。

4、另外流程建设需求有其自身的需求梳理特点，不完全和传统需求方法论一致，因为传统需求方法更多适用于为职能部门开发的业务系统，业务领域更多关注在相对独立的业务体系内，如考勤管理，销售管理等系统，而流程需求分析则需要从更高层面进行抽象建模，如企业内控制度， 岗位权限，财务制度等。2. 流程需求方法论3.1 需求规划：调研结构规划I. 静态调研报告结构业务调研结束后，需要收集到的原始文件盒调研记录进行整理，形成规范而有价值的业务调 研报告。目标是到业务调研报告不需要与客户再次沟通就能通过业务调研中抽象出的系统需求和 一起需要的信息。我们把业务调研报告分为静态业务和动态业务两类静态业务流程需求动态业务需求

5、非功能性需求调研通过静态业务视角了解 企业状态业务流程图设计1r静态结构关系<J运行节点描述用户体验系统集成部门公司或机 构部门二.岗位一岗位二文档资料n上图的组织架构是比较典型的静态结构模型，在静态业务抽象时，彩雀逐层细化的过程。可 以这样推理，一个公司至少包含一个或多个部门，一个部门可能包含一个或多个岗位。一个岗位 可能要处理多个表单或数据。对部门职责描述，应该采取表格形式最晚有效和准确，如下部门职责描述模板:部门编号“按照企业要求编写”部门名称不为空直接上级“填写主管部门名称”部门性质部门级别编制人数数值下属部门下属部门是指部门领导的下级部门部门职能职能1详细描述，尽可能描述本部门

6、的职能，已经与之较好的上下游部门职能2详细描述具备条件部门职责描述模板职位编号单位人事编号职位名称组织架构图对应所属部门组织架构对应部门职位类型上级职位根据人事部门提供填写编制日期需要就每个岗位所承担的职责详细描述，通过岗位职责描述，全面了解岗位所承担的责任和具体 工作细节，便于通过岗位职责挖掘用户需求。需下图模板：序号工作职责（按照重要程度排序）时间比例关键指标1工作职责详细描述时间比例占考核指标币种2其它工作职责时间比例占考核指标币种具体工作职责描述另外，原始资料整理，本阶段的主要职责是每个岗位中的工作人员需要的原始资料进行整理和分 析，分门别类的处理，原始资料是业务系统分析的静态结构的主

7、要数据。也可以使通过原始资料 整理，获取业务运行的业务规则，如下图：业务表单模板整理表单编号表单名称岗位职责中用到的名称表单类型编制单位所在部门使用部门列出使用此表单的所有业务部门是否自产生是/否岗位名称表单拥者冈位处理周期时间数据集1数据项目编号数据项名称标示符数据类型长度初始值范围项目组约定项目组约定 NET数据类型数据项处理逻辑数据项编号简述(20141021)说明本表单中数据项处理逻辑输入的数据流女口：编号为数据项编号数据项名称为中文标示符为GUID类型处理逻辑：计算方法，如米购品项的单价求和 =米购总价输出的数据流：编号为数据项编号，属相名称为中文名称处理频率：1周以内II. 动态流

8、程需求结构业务流程图示一种描述单位组织内各单位，人员之间的业务关联性，工作顺序，和管理信息流向的图标，利用业务流程图可以帮助分析人员找出业务流中的不合理流向，它 是物理模型。业务流程图同时也是系统分析人员设计系统用例的基础。流程图分为两个层 面一个层面是描述部门之间的业务流程，称为顶层业务流程图；另一个层面是针对岗位之 间的业务流程图，称为底层业务流程图。业务流程图的格式也有多种多样，经常用到的泳道式业务流程图，泳道式业务流程 图作用包括，泳道流程图有助于分清在流程过程中每个岗位的工作范围；泳道流图有助于 研究流程中人与人或工作小组与工作小组的交接动作。运行节点描述，在上图中，泳道的部门或岗位

9、描述已经在前面章节中有具体描述,在业务流程图中，只有运行节点，没有对其具体的描述，NTT DATA团队会为期定义详细的模板用以扑捉精确的需求。运行节点名称“选择业务流程图中 的节点，如部门经 理办理部门“本运行节点所在的部门”办理人与职务指本运行节点的处理岗位，也是泳道上知名的部门或运行岗位办理时限用来说明本运行节点处理所以需要的最低时限业务描述对本及诶单的业务描述运行节点是否需要跳 转否/是跳转到第几步？跳转节点编号跳转条件“描述本运行节点条件判断和跳转条件相关操作1.受理，2，不受理，3，撤回，4是需要历史数据比对4q1需要，厶不需<本环节所需要的材料列出本环节需要填写的所有表单资料

10、需要打印的资料III. 非业务流程调研所谓的非业务调研其实就是在企业现在业务运行的基础上，对客户进一步沟通，了解客户在业务 范围之外的一些特别状况。比如客户系统的运行地域性、部门变动性、业务流程的变化性、岗位 职责的变动性、和文件资料的变化性。主要有以下几个层面的调研：丄地域性调研地域性分析，以程应用使用者的地域分布情况来看，也就是业务流程是在一个部门内运行还是 在多个部门？ 是在一个地域内，还是跨多个省或低于，关于地域性分析非常重要，这直接决 定了平台架构过程中所使用的底层架构和硬件配置，地域性分析为需求分析报告编写过程提 供了很重要的依据丄1部门变动分析部门变动性是指部门的组织结构调整的频

11、繁程度，组织结构的调整应该包括，依据结构的调 整和机构内部岗位的调整，以及这些机构调整对系统的影响，这是业务调整过程分析中容易 忽略的地方，因为部门的变动性某种意义上会影响系统功能划分的力度，过小的力影响软件 开发的质量和进度，过大的力度会影响客户系统的灵活性。4-业务流程变化调研业务流程变动是指在现有业务流程的基础上，组织结构内部对业务流程调整的频度，如业务 顺序是否随时可能调整，在同一业务中对岗位的调整频率，这种变化对系统运行的影响等， 业务流程的变化决定了软件系统架构中关于工作流的应用问题。比如如果业务流程非常频繁 的话，在软件开发过程中是否要完全采购流程平台自身原生机制，流程平台确实能

12、够很好的 事业业务不断变化，但是开发成本相对较高。丄1岗位职责变化分析所谓岗位职责编号，是指某些岗位的工作职责的编号频率问题。例如某一个岗位可能随时调 整工作内容，有些岗位调整工作内如频率较低，岗位职责变化分析属于微观层面的系统分析 过程。这样决定了在系统功能模块组织中，这里采取的粒度大小问题。粒度过小反而影响了 用户体验。粒度过大，减少了系统运行灵活度。总结以上所述，在 BBA整体系统扩展或架构中，需要详细的静态结构需要，和动态结构需求， 动态模型描述了业务调研报告的动态结果，在最后的非业务性需求调研中可以对技术和开发 架构设计具有重大意义。3.2需求分析：视图分析法业务流程应用是一个从高层

13、战略驱动到底层执行的活动抽象过程，成功的关键因素是系统的管理人员、业务人员、开发人员之间的互相理解和通信。因此，在需求分析阶段把应用领域的知识提取出来，用适当的概念模型（需求说明）表达出来，并采用合适的方式进行评估，以保证需求分析所建立的模型真实地反应了需求，以往，更多的需求方法多是采用文字需求描述的方式，或者只是用Activity图形表示了大致的流程走向，很难如实表现出业务流程的细节需求，造成开发过程反复Assemble process after designAC71)C3f r>R*MAT IDM4* w LVLNITI.II. 数据视图主要用于识别流程系统中涉及的 3类数据源:业

14、务数据或表单类型数据外部数据，来自于第三方系统流程元数据在经前期的需求调研之后，收集了许多需求分析报告，但是很少团队或组织提到过将数据字典作 为需求分析阶段重要的内容来做，系统的数据视图作为系统分析的重要工具，对梳理数据在业务 流程与组织，或者业务流程与企业应用系统（如， SAP HR ）的过程非常重要，在结构化分析过 程中，数据视图的作业是给数据流程图上每个成分加上定义和说，可以将数据进行统一的定义， 避免产生歧义。在数据视图中所有的元素定义和解释会有助于改进分析人员和用户的沟通，明确 细节和相互关系。防止遗漏，充分，和冗余，规范文档，有利于检查和用户沟通，以指导流程系 统的开发和编程。几

15、Tl I*祀跖屮-iurfl I- rtwm"I & 曲 iV-帶Hi &'.'Jzftm +- HLft 1Li s/7出 rr E|«lilkliR 也1g:<H| |1st f>FXWAJJlFl HR ft|i ijita 七z *>='(St 算 H»sfr Rit w£<«K KQIH .1U 曲在畸斜占粤i才K倉ERPHR解读前期调研报告，编写与设计数据视图，在业务流程开发项目中，我们逐渐积累了一下原则:按照统一的编制规则来编写数据视图元数据的选择应该结合业务流程规则

16、编制元数据的描述应具有反应数据自身特点的独立性，既与流程系统结构和功能无关，但对系统的开发有必然的意义III. 流程视图在流程梳理过程中，使用统一建模语音（ UML ）整理业务流程的各个节点，以及每个 节点与数据和业务规则的关系，最重要的是识别出每个节点的处理人或相应的岗位在 组织架构上的权限。如下图：系统 5、系统自动将将冲 ) 销保留款信息导入ERF系统审批阶段导出阶段II同意流程结束1无a、b、c、d无22,审批人员为部门相关的 人员，包括项目经理、部门 经理、部门总监等e、f、gA、B2、B332,审批人员为部门相关的 VP或SVP职位的人员e、f、gA、B2、B342,审批人员为部门

17、相关的 执行部门、协作部门的人 员，包括项目经理、部门经 理、部门总监等e、f、gA、B2、B352，审批人员为财务部人员e、f、g、hA、B2、B362,审批人员为法务部人员e、f、g、iA、B2、B371,审批人员为财务总监e、f、gA、B2、B381,审批人员为CFOe、f、gA、B2、B391,审批人员为CEOe、f、gA、B2、B310无无无111,审判人员为财务总监e、f、gA、B2、B312无无无IV. 业务逻辑视图通过业务逻辑视图，来清晰的表现每个流程表单和流程审批节点在系统交互过程中，或者 在与节点处理者之间交互过程中所隐含的业务规则，主要包含两类业务规则，需要通过业 务逻辑

18、视图透视给的业务分析人员和系统用户：1. 定义表单数据的采集或保存逻辑2. 定义审批人节点的处理逻辑，特别要定义清楚相同节点不同组织中的逻辑差异化表述要在逻辑视图中清晰尤其是那些跨组织、跨地域的用户使用情况，如果定义不清楚这 些流程续期差别，流程应用的灵活性也会大打折扣。3. 定义流程系统交互逻辑或异常处理逻辑V. 功能视图功能视图主要是用来识别流程系统中每个环节或每个阶段要实现的功能，这些功能类型主要涵盖 两大类：流程通用功能在功能视图中要清晰的识别在每个流程环节所需要的可选功能，如在申请阶段，初始申请 单上会自动带出相关人员、岗位信息，自动绑定业务信息；在审批阶段，可以配置是否邮件通知下一

19、审判人还是消息提醒在处理阶段，可以配置是否可以授权代理，执行任务跳转等操作流程功能 流程功能中需要清楚的界定流程运行的整个生命周期内，流程本身完成了哪些业务需求, 如下图中，预算的申请，预算的调拨，预算的额外申请等。集成功能 在功能视图中，根据需求调研阶段了解的企业信息化是情况，识别目前企业应用系统有哪些厂商和平台，梳理出业务流程需要与其集成的功能点，并且表示其接口是否已经完善还差旅申请流程需要集成需要集成NOIT资产流程NOYESYES质量控制流程NONOYESVI. 表单视图表单是与工作相关的数据的载体，相当于现实工作中的纸质工作单，工作单上的手写 数据通过表单上的各类控件得以体现；在表单

20、以外，我们还可以通过公共附件传递一 些数据和信息，以便更好的完成工作流程。在项目开始设计与开发之前，需要以非常 清晰的视图告诉客户，表单上所有元素的类型，表单元素之间的关联性，表单视图上 的权限要求等需求，需要购过表单视图进行清晰确认。*ta休假申诸单釦1Qr宜整申l*祜響曰期IL構常厂族卵mA&QBIH I " ；h V 幅茸車. |" u -.'壬古卜亏审L*只哀訪G)*读审M ti薯在画室曰阳修员工矣聖|ITi #r.9I与0 dl 乂甘砧IQ|陳认H示蛋录人播主童肖薦已r岂隼应乍毎曲：“；_利余澤卵；盍利金谓样1；"小时I荊中"甲"小科苛于年冃“自肿 I当年已率谓的休轉动寄理希岂年已申漬詢琦訂件邯佶理 其中*丟:»于 审 地帅颅* 域申“去無子申Jfc圖股O*-W i "夭、 =槪：*丟*row*l 曙*3 r iwr+n