信息系统的核心价值之一是支持业务，而业务支持的核心是对业务流程的固化、优化和重构。在需求分析时，识别出相关的业务流程是关键任务之一。
1、业务流程识别
要有效地识别出系统应该涉及的业务流程，首先需要深入理解什么是业务流程、什么是端到端流程。
🤔️为什么“业务流程图是只允许有一个起点，但可以有多个终点”？
🤔端到端流程关键点，
（1）完整：服务请求从提出到满足的全过程。判断服务请求是否满足或者被拒绝。（2）边界：识别业务流程时涉及两种边界。一是职能边界；二是系统边界，也就是不属于系统关注的部分。
在实际的需求分析工作实践中，需要对各个业务子系统逐一进行业务流程识别。在识别过程中，通常会采用先外后内、先业务后管理的顺序进行，具体可分为以下四个步骤。
（1）识别外部引发的主、变、支流程：业务流程大多是响应外部客户、外部员工服务请求的，因此先识别它们。
（2）识别内部引发的主、变、支流程：有些服务请求是由内部员工主动发起的，诸如销售流程，还有些是在特定时间、状态下发起的，因此识别完外部的，还需要从内部补充。
（3）识别管理流程：有一部分业务流程是为了实现控制、监督、管理等意图，需要单独识别。最典型的一是用于事先预防的管理流程，二是用于事中控制的审批、规则，三是用于事后分析的报表、数据分析。 可以从业务上线类的审批控制；人、财、物、资源的管控；进度和异常的控制几个角度来思考。
（4）判断业务流程优先级：业务流程是信息系统交付的最小单元，因此对业务流程做优先级判断，有利于做出更合适的迭代计划。在评估业务流程优先级时，推荐根据它是否为主营业务、发生的频率高低来进行综合评估。
PS：主业务流程体现主诉求，而变体业务流程实际上是属于主业务流程的，但由于相对独立，不容易整合到同一张流程图中，因此我们通常建议将它们识别为单独的一个业务流程。而支撑业务流程，则是提供一些边缘的、辅助的业务支持，它属于一种锦上添花的业务。
针对每个业务子系统做一次“业务流程识别”，然后整理成“业务流程列表”，放入需求规格说明书中的相应小节中，
业务流程是由一系列角色协作，以满足服务请求的闭环。如果开发的系统只存在单一用户、主要以人机交互为主的系统，那么可以跳过“业务流程识别”、“业务流程分析与优化”这两个任务，直接执行“业务场景识别”任务即可。
2、业务流程分析与优化
在标识出相关的业务流程之后，接下来的关键任务就是逐个流程进行了解与分析，绘制出流程图，并对关键流程做适度的优化。
业务流程天然可以分成三层，最宏观是组织级流程，是部门间协作关系，供决策层阅读。第二层就是部门级流程，是岗位间协作关系，供管理层阅读，业务流程分析在这个粒度上进行。第三层则是个人级流程，是一个岗位的工作步骤，应该到业务场景分析时再细化。
判断业务流程图是否过细时，有两个重要的原则：一是是否与协作无关；二是是否不是独立可汇报的工作单元！
业务流程分析，最重要的是业务流程八要素，包括五个基本要素（分工、活动、协作、产物关系、分支），三个管理要素（审核、规则、异常）。可以分成四个步骤执行，
（1）选择流程图描述方式：根据目标读者、流程类型选择合适的流程图来描述流程分析的结果。
活动图强调的是每个角色执行什么活动。顺序图强调活动之间的交互关系。
（2）勾勒流程主体：厘清业务流程中的分工、活动、协作、分支、产物关系五要素，搭出流程的主体框架。
业务流程图绘制过程中，需要注意：分工应平级，要么全是岗位名称，要么全是部门名称；活动命名采用动宾结构；绘制时暂时不要考虑系统边界，画出业务全过程；应该从服务请求者开始画起；主从活动只留一个「给谁看」。
（3）补充事中管控点：厘清业务流程中的异常「如绿色通道」、审批、规则「行为规则 、数据规则」。
（4）分析流程执行过程的监管需求：从管理者对流程的进度、异常等方面的管控，识别、补充一些辅助的相关需求，如进度与效率、执行异常、其他管控等。
在需求分析实践中，应该针对每个业务流程来进行分析，对必要的还可以考虑做些流程优化，然后整理成“业务流程描述”，放入需求规格说明书中的相应小节中。
《有效需求分析》一书聚焦于组织应用类软件系统的需求分析环节，介绍了18个按需求组合的关键任务，针对每个任务的一步步指导，以及每个任务输出的“软件需求规格书”片段模板。
网友评论