第4篇 设计工程——详细设计
第12章 架构的详细设计
业务架构的成果中，拓扑图和分层图用于顶层的规划，框架图和分解图用于粗粒度的设计，由于以上图形中没有露出数据、逻辑、规则等细节的内容，露出细节的只有流程图（包括业务流程与审批流程），因此架构的详细设计工作主要是以流程图为中心进行的。
12.1 基本概念
12.1.1 定义与作用
1．定义
架构的详细设计，是对架构的概要设计成果进行进一步的细化，给出包括流程分歧、流转、规则在内的设计规格书。
2．作用
从软件工程上架构的全过程看，架构的概要设计阶段完成了业务优化设计、业务逻辑的抽提，这些内容还是粗粒度的，没有涉及流程上的上下游节点间关系（数据、规则）。详细设计阶段要完成流程的节点间的传递关系、流程的分歧、对不同形式流程的使用场景等。最终用流程设计规格说明书的形式确定流程的设计细节。
12.1.2 内容与能力
1．作业内容
业务架构中只有流程图会显示出数据和规则，因此本章的内容主要以业务流程和审批流程的细节设计为主。
其他各架构图虽然没有细节的设计说明，但是它们在后续的其他设计中还会有应用，例如：
（1）拓扑图：在后续的设计中用于不同系统、硬件之间的关联规划。
（2）分层图：在后续的功能、数据的分层设计上使用。
（3）框架图：在后续应用架构设计中，用于系统功能的规划设计。
（4）分解图：在后续设计中用于数据层的规划、基础数据的设计等。
2．能力要求
相对于架构的概要设计要做系统的整体规划、顶层设计、确定理念和主线等内容而言，因为详细设计是在架构概要设计的范围内对已经规划好的内容进行细节的推敲和设计，因此对架构的详细设计要求的能力可以相对降低一些。
（1）可以读懂需求规格说明书、概要设计的资料等，理解客户的业务需求。
（2）掌握架构的方法，特别是业务流程、审批流程的设计方法。
12.1.3 思路与理解
1．流程的分歧点
在流程的架构设计中，只是对流程进行了粗粒度的定义，包括：流程的走向、节点名称、位置等，还没有对节点的上下游之间的关系、相互作用进行说明。在流程的详细设计中，就要对流程的节点、分歧点进行详细的设计，特别是对分歧点的设计非常重要，因为企业对流程管理的规则通常会加载在流程的分歧点上，随着管理规则的变化流程也会变化，所以客户希望流程具有一定程度的应变能力，对于业务设计师来说，摸清流程分歧点的变化规律，建立应对的模型是对后续应用设计和实现开发的前提条件。
2．流程的回归检验
企业导入管理信息系统后，让用户感受变化最大的有两个点：一是操作界面，二是业务流程。操作界面带来的影响自不必说（它替代了纸张），流程带来的变化让用户感受到了企业管理规则的真实存在，不按照它处理就不能运行（不存在“人-人”环境下可能存在的“通融”现象），因此在流程设计过程中要非常认真地进行推敲、检验，确保流程在运行后不出现问题，这个推敲和检验可以利用泳道式流程图来完成。
12.2 流程设计（流程5件套）
记录流程详细设计的模板称为业务流程规格书，由于采用了5个不同的模板作记录所以简称为“流程5件套”。理解了流程5个模板的含义，就容易理解流程设计的方法。下面分别介绍5个模板的使用方法。
12.2.1 模板的构成
1．设计思路
对业务流程的详细设计采用5个不同视角的模板进行描述
对业务流程的详细设计采用5个不同视角的模板进行描述。
（1）模板1-流程图形：将业务流程用线形的方式展开，不要任何背景（方便详细设计）。
（2）模板2-节点定义：对流程上的每个活动及前后关系进行定义和说明。
（3）模板3-分歧条件：对流程上的分歧条件、判断方式进行说明。
（4）模板4-规则说明：对流程的使用目的、用法等进行综合说明。
（5）模板5-流程回归：在线形流程上加入组织结构背景，进行业务回归确认。
采用了这5种模板对一条业务流程进行描述，基本上可以完整地、全方位地、唯一地表达该流程的内容，这种方式非常适合于多人协作，传递与继承设计成果，可以有效地避免表达歧义，符合软件工程化设计的理念和方法，同时也为软件自动化辅助设计提供了基础。
2．记录方式
记录详细设计内容的模板要能够完整、准确、唯一地确定一条流程的规格，同时要能支持多人协同设计，模板要具有以下的特点。
1）结构化、标准化、易于继承
（1）不论什么业务流程，都采用5个维度的描述，且每个模板要描述的内容、格式统一。
（2）记录的内容全是必读信息，尽量不使用形容词。
（3）在由多人接力进行需求、设计、开发的项目中，可以保证设计资料的继承。
2）有规律、格式化、易于沟通
（1）由于记录方式的规律性，经过简单的培训，所有相关人员都可以掌握或了解内容。
（2）由于格式化的记录方式，通过邮件、电话等方式进行讨论、修改时比较高效。
3）可维护、可追溯、易于管理
（1）发生变更可以记录变更日、变更人、变更信息等。
（2）具有了前述优点，设计资料的文档管理就会比较容易。
3．配置工具
在信息系统实现的设计过程中，会使用流程的配置工具，使用流程工具可以通过简单的配置就能完成流程的设计和实现，既然有流程的设计工具还需要进行详细设计吗？流程的详细设计就如同小学生学算术、中学生学数学一样，尽管有了计算机，还是需要理解计算的定理、规则等。通过对流程详细设计的学习，可以加深对业务运行的事理、业务逻辑的理解。理解和掌握了流程设计的基本概念后再使用配置工具进行流程设计时，除了高效，还会让业务设计师与技术设计师在讨论如何设计流程应变机制时变得更加有自信。
12.2.2 流程模板1——流程图形
第一步，将在架构的概要设计中获得的线形业务流程图贴到流程模板上
1．不可缺省的活动
流程上用深色标注的节点1、4、6、7、9是不能够缺省的，如果缺省了则流程在运行过程中就无法完整地、正确地进行成本的过程管理了。
2．可以缺省的活动
用白颜色标出的节点2、3、5、8是可以省去的，可以看出这些节点的内容不论有无都不会影响到成本的最终计算结果（但是会影响到管理的精细程度）。
12.2.3 流程模板2——节点定义
第二步，精准地确定流程上每个节点对应的信息，需要考虑以下几点。架构的概要设计从业务逻辑上将流程的节点都已经确定完成，下面就要对流程和节点进行定义，包括：流程的目的、起点／终点、使用部门／岗位、节点是否可以省略等
*1：业务流程的活动与对应的部门关系。
*2：审批流程的设计及使用方法。
（1）流程上所有节点都是业务功能中的“活动”，活动名称的结尾必须是动词／名动词。
（2）此时对节点定义，只是对节点之间的关系、分歧条件等进行定义，并不涉及节点内的详细信息，节点内部的信息在“功能的详细设计”（业务4件套）中进行。
（3）模板中“顺序”栏中的1=流程的起点，9=流程的终点。
12.2.4 流程模板3——分歧条件
分歧记录模板采用了同时容纳复数分歧规则的格式，可以将所有的分歧规则（以后可以随时增加）预先全部填写于此。由于客户持续不断地改善企业管理规则会造成流程分歧条件不断地改变，因此建立结构化的流程规则处理机制，为在应用设计中设计流程的机制带来了便利。
1．分歧条件是客户的管理规则要理解到分歧条件实质上是客户的“管理规则”，而不是“计算机系统的处理规则”，这个阶段的流程模板只涉及客户的管理规则。所以这个分歧条件是由需求分析师和业务设计师共同设计，并向客户确定的。
2．分歧条件的描述方法要努力将客户的管理规则用比较规范的、简练的、不易出现误解的方式转换为流程的分歧条件。
分歧条件的填写过程如下。
（1）本节点“1．物资需求预算”完成了内部处理后，判断是去“2．统一采购计划”还是去“3．现场采购计划”。
（2）如果结论是去“2．统一采购计划”，则从节点2开始继续进行流程的运行（节点2→节点4）。
（3）如果结论是去“3．现场采购计划”，则从节点3开始继续进行流程的运行（节点3→节点4）。采用这样的条件式描述方式，既简洁又清晰，后续的设计与开发人员又可以直接读取流程分歧的设计含义。
3．分歧条件与流程判断
虽然在设计业务流程时将节点看成是一个“黑盒”，不涉及节点内的业务处理过程和处理方法，但是节点内的处理结果是分歧条件设置的依据，决定流程流转方向的原理就是“节点内部的处理结果”与“事前约定的分歧条件”之间的对比结果所决定的
节点A的处理结果为a，分歧条件为m：则判断：分歧条件为a≥m→B节点；a＜m→C节点。
12.2.5 流程模板4——规则说明
流程节点定义，主要用于对每个节点属性的定义和说明，对两个节点之间或是流程背景等复杂关系的说明不足，所以模板4规则说明就是用来对前述3个模板表中没有充分解释的部分追加信息。
● 流程的流转条件是来源于客户的什么管理规则。
● 前一个活动为可以缺省项时，下一个活动该如何进行处理等。从图中可以看出，它们都是重要的流程设计依据。
12.2.6 流程模板5——流程回归
利用泳道式流程图，检验设计完的业务流程使用环境是否匹配。方法是将要设计完成的业务流程图放置到有组织结构作为背景的泳道图中，在泳道图中标出未来使用该流程的部门、岗位等信息模拟使用环境，可以观察业务流程、业务活动（节点）与各个部门、岗位之间的互动、管控关系等。
12.3 流程回归——泳道式流程
泳道式流程图，即将业务流程图、审批流程的位置等信息与有企业组织结构的背景框叠合在一起形成的流程图。这种表达方式由于标示出了流程所属的部门、每个活动对应的部门和岗位，审批流程跨越了哪些组织部门等信息，所以可以模拟出在信息化环境下该业务流程和相关的审批流程的运行状况，方便对流程的设计结果进行检验。
12.3.1 使用背景
泳道式流程图有两个重要的使用用途：记录现状构成，模拟使用场景。
1．记录现状构成在需求调研阶段，为了掌握客户工作的现状，可以采用泳道式流程图。这种流程图可以同时将客户的工作流程、相关的部门、岗位，以及它们之间的对应关系记录下来，这是后续流程优化设计时的重要参考，因为流程的优化会影响组织的形态，同时组织的构成也会影响流程的设置，即流程的优化可以影响部门和岗位的设置。
2．模拟使用场景在业务流程图（线形）的设计完成后，通过加入组织结构的背景框，可以模拟优化后的业务流程在实际组织框架下的使用场景、与组织机构的匹配关系、不同岗位规则的设定等内容，通过这个模拟，还可以对比出与原始的现状泳道式流程图之间发生的变化。
3．线形流程与泳道式流程的区别
采用线形流程作为流程的设计对象是因为这样可以集中注意力在流程本身，在设计时重点考虑的是业务事理、业务逻辑，根据这些内容进行优化，此时不需要考虑使用时的组织背景情况，这样做可以只根据业务事理首先获得较为理想的业务流程图，待业务流程图设计完成后再通过模拟来验证其实际的使用情况。模拟的方法就是将业务流程图与画有组织结构的背景框叠加在一起，反复推演业务流程与组织结构是否匹配，验证的结果可能是流程需要修改，也可能是企业的组织结构需要调整，而且后者发生变化的可能性很大，因为在信息化环境下的工作方式与传统的组织结构一定会发生不匹配的地方，找出这个不匹配的问题也是使用泳道式流程图的目的。
（a）可以将线形流程的节点与各个节点相关的字典库（基础数据）进行关联。
（b）可以将线形流程的节点与管控模型、管控点进行关联。
（c）泳道式流程图可以将业务流程、审批流程展开并与组织结构背景框进行关联。
线形流程图与泳道式流程图各有所长。线形流程的表达形式更方便进行流程的规划、详细设计以及管控设计；相对而言，泳道式流程图由于有背景框的约束，所以不方便进行上述设计。因此本书采用线形流程图作为设计的依据，泳道式流程图做验证。在没有特别说明时，“流程图、业务流程”等均表示的是“线形流程图”。
注：泳道式流程图与开发
泳道式流程图，对业务设计师和客户在确定流程的应用场景有着很大的帮助，但是对于技术设计师以及开发工程师来说只有参考意义，没有实际的指导作用。
12.3.2 绘制方法
1．组织结构背景框的绘制
背景框有多种形式，常见的有一维和二维的表现形式。一维即只有一个方向标示了泳道名称，二维即有两个方向标示了泳道名称，即只有纵向设置组织机构的名称，而横向设置编号。
12.4 流程监控——审批流程
12.4.1 使用场景
审批流程，单独看它也是一条流程，但是从概要设计阶段的业务流程图上看，它的作用是对业务流程上某个节点内完成的成果进行评估、管控。也就是说，相对于业务流程来说，审批流程是业务流程上的一个“管控点”，这就是信息系统设计对审批流程的定位，这与一般管理咨询中的定位是不一样的，很多管理咨询中是不区分业务流程和审批流程的，但这两种流程在软件实现上是不同的，这也就是“管理咨询”与“管理信息化咨询”的区别。审批流程是针对业务流程上的某个节点上的业务处理结果，安排一系列的相关人员对其进行判断，判断的结果决定了该条流程是否可以继续向下游活动推进。
注：审批流程的设置点
不在业务流程上的独立活动也可以根据需要设置审批流程
12.4.2 流程设计
在业务流程的节点“4．采购合同签订”上加载一条审批流程
由于审批流程是一个需要反复使用的模块，且不论审批的对象内容是什么，因此各个软件商通常采用“工作流”的方式开发一个独立的软件包来实现审批的工作。
12.4.3 审批流程与业务流程的区别
审批流程与业务流程的分离是分离原理的一个重要应用，对比审批流程与业务流程，可帮助理解审批流程的特点
1．流程的区别
1）流程的启动
（1）业务流程在启动后是不能进行人工干预的（按照事前设定的规则自动流转）。
（2）审批流程在启动之后，可以自动流转，也可进行人工干预（回退、终止）。
2）流程的复用
（1）业务流程具有共性，由于业务领域的相似性，即使是不同客户的信息系统在流程设计时也具有一定的参考作用，因为业务事理是相同的。
（2）审批流程没有共性，客户不同审批流程也不同，即使是相同领域的客户也可能无参照性，这主要是因为不同企业的管理理念、组织结构、岗位配置等不同造成的。
2．构成的区别
1）节点的区别
（1）业务流程的节点是由完成同一个目标的一系列活动构成的，此时的审批流程处于一个“黑盒状态”（只有一个“审”字），如“物资需求预算”。
（2）审判流程的节点是由对业务流程上活动结果具有判断权限的复数角色构成的，此时的审批流程处于“白盒状态”（有审1～审x）。
2）节点的规则
业务流程遵循的是业务标准，审批流程遵循的是管理规则。
（1）业务流程：业务流程上的节点是依据业务处理的内容设计的，每个节点的内容依据不同的生产工艺工法等。
（2）审批流程：确定某个节点是否可以前行，依据该节点的结果是否符合企业的相关管理规则。
3）节点的数量
业务流程是审批流程的载体，针对一条业务流程上的每个节点都可以设置一条与该节点内部业务相关的审批流程，每条审批流程都可能不一样，因此可以看出，业务流程和审批流程不是一回事。针对同一条业务流程，可以设置若干条不同的审批流程。也可以将审批流程看成是一条处于“黑盒状态”的管理规则，审批流程是“管理规则”形式的一个变体。如果想要深入地研究审批流程的细节时，可以在另外一个层面上，让审批流程处于白盒状态，此时，审批规则、审批人、审批条件、流转条件等内容就可以表达出来出了。
小结
架构的详细设计，对架构的概要设计成果进行了细节的设计，定义出了业务流程分歧标准、规则以及业务流程设计的记录模板，到此，完成了业务阶段对业务流程的全部设计内容。
（1）用线形流程图做业务流程分歧的设计。
（2）用泳道式流程图做业务流程的回归检验。
（3）用审批流程做业务流程的节点管控。
流程的详细设计成果，是后续在架构的应用设计中构建流程机制的输入，在此处从业务设计的层面（业务标准、业务逻辑、企业管理规则等）上将流程分歧的各种关系搞清楚，在应用设计中建立流程的各种分歧机制就比较容易了。建立了处理流程分歧的机制后，在系统运行过程中发生了需求变化时，系统就可以快速响应变化。分享业务流程，既熟悉又陌生的架构图
（1）首先是线形流程图与泳道式流程图的用法区别。
业务流程图，是优化、完善业务处理过程的最佳工具。以线形流程图为基础进行设计，是先按照业务处理的事理（工艺功法、效率、质量、标准等）找到最佳的处理过程，然后再与相关部门去协调组织结构。如果以泳道图为参考进行流程的设计，那么始终就被用户和用户的所属部门所约束，如此一来，就成为“为符合各个部门的要求而设置流程节点”，而基于“人-人”环境下形成的组合结构可能是不适合“人-机-人”环境下的业务流程的。容易造成“让先进的管理系统去适应过时的组织结构”的不合理现象。业务设计师利用掌握的信息化方法，应该为客户构建在未来“人-机-人”环境下的最佳工作方式，而不是用信息化方法去模拟客户的现状。
（2）清楚了泳道式流程图在软件设计中的作用。
它起的作用就是“模拟环境”，模拟线形业务流程在客户现场使用的环境，从而使得客户在系统上线之前就可以对既有的组织结构进行调整，以适应“人-机-人”环境下的最佳工作方式。
（3）彻底理解了“业务流程”和“审批流程”的作用、方法的不同。
清楚了分离原理对它们的分离意义，认清了业务流程是核心、主体、载体，而审批流程是管理方法的一种。两者各司其职，目的和方法完全不同。