编程便笺: 流程与权限

　　权限涉及到很多概念，用户、职员、角色、用户 组、资源、数据权限、功能权限、组织结构等，是资源分配以及职责分工在系统中的体现。如果只是关注权限的结果，而不是去分析权限的原因，很难设计出一个软性的权限系统。权限系统与需求有很大的关系，梳理权限系统很大的程度上可以說是在梳理需求。

　　业务模式在商业活动中处于比较核心的地位，资源的配置、业务流程和权限基本上都是围绕着业务模式展开。业务规划和业务计划是业务模式的源头和驱动，但所有的业务活动都需要通过业务模式来体现出来，流程则是业务模式的具体体现，权限则是角色在流程中职责分工，离开了业务模式讨论业务流程和权限就有点无的放矢。另外一方面，从业务模式开始讨论业务流程和权限，也使得软件的调整在业务模式层面上成为可能。

　　一、业务模式:

　　　　　

　　在这个层次主要对管理目标进行监控，对业务执行状态进行预测和统计，对可能出现的偏差预防和预警，减少系统性错误，达到业务运转高效、有序的目的。对于权限来说，只涉及资源的总体配置，资源的配置细节则不涉及。

　　二、模式细化:

　　

　　商业模式需要业务流程来体现，业务流程的流转过程体现了商业模式本身的业务特征，流程模式则为业务流程提供了指导框架。流程需要相应的组织人事来操作和驱动，组织模型体现了流程模式中职责分工的形态、方式及要求。业务流程内部流转及职责分工的要求体现为业务规则，由业务规则制导具体的业务流程的运作和管理。

　　在这一层，组织模型由组织节点、角色、工种、岗位组成，由于不落实到具体的组织结构，所有的构成都是抽象的，而业务规则则定义这些构成部分在流程中所承担的职责和权限。比如我们可以定义这样的规则：[部门经理][负责][本部门]的[业务审核和管理]，但不能定义：[张三][负责][业务一部]的[业务审核和管理]，因为张三和业务一部都涉及到具体的组织结构，而不是抽象结构。由于权责是定义在抽象结构上，权限对由抽象结构实例化的组织结构都有效。而对于流程模式来说，则主要讨论模式的合理性及规则的有效性。

　　三、实例化:

 　　在这一层上，我们对流程模式和组织模型作了具体的落实，而产生具体的业务流程和组织结构，业务流程的流转由具体组织和人员负责驱动，并遵循业务规则，并根据业务需要细化业务规则。在这里对组织模型的各个构成部分都落实到具体具体的对象，比如角色由职员构成，并通过用户来代表，对于业务部门来說，则可能细化为具体的业务一部、业务二部等。

　　对于权限来说，我们可以对工作分工进一步细化，这些可以通过设置来完成，也可以通过业务规则来设置。由于工作指派是落实到具体的组织对象，对于组织的变动会产生一些限制，一个可能的后果是：伴随人员和组织的调整，产生大的权限设置量。

　　对于流程来说，运转安全、高效、透明是设计目标。

　　四、需求梳理:

1、追因溯源：业务中提供的需求有时并不完整，只有追因溯源才能有效地梳理需求，并能找出需求中所欠缺的部分，同时也有利于理顺需求中的各种关系，让需求从平面变成立体。也只有追因溯源，才能有效地表达业务意图，并使得业务意图在系统中得到完整地体现，而不是一个个片断。

2、流程：业务的执行和操作体现在各种过程中，这些过程联串在一起就构成了流程。流程是设计的主体，也是设计的主要体现方式。对于一般业务应用系统来说，应该整体构建在流程之上。流程、计划、项目管理要结合在一起，流程的启动和运作建立在计划和项目管理上，以保证其有效、有序的执行，并能调整执行过程中可能出现的偏差。

3、执行与策略：软件系统应该有硬有软，硬的方面主要体现在执行或者说流程层次上，动作、过程以及数据都是明确的，变动、调整、牵涉面也少、实施相对容易些。而软的层面主要体现在策略上，数据的产生过程，往往建立在规则之上，产生的结果也不是很明确，但往往可以用来串接被分散了的设计意图。软件中的硬件赋予系统结实的身板，软件中的软件则把灵魂注入了系统。当软件成为生产力的一部分，这样的设计尤为显得重要。

4、业务主线：业务系统由各种流程组成，这些流程往往服务于一两个主体流程。在系统中这样的流程要尽可能保持完整地结构，也就是説要有因有果。比如在销售系统中，客户服务是主要的执行主线，不管客户与系统有没有连接，系统应该都可以以业务模拟客户的身份进入系统，查阅订单的进程或着发起新的订单，以此来启动相应的业务流程。对于供应商也该做相似的处理。

5、组织无关：执行部门的组织结构往往依附于流程，由于竞争的加剧和信息流转的加快，流程的调整直至商业模式的变化都变得常态起来，如果设计过于组织相关的话，则使得适应这样的调整变得困难。

6、业务主体：业务是设计考虑的主体，而不应该是技术。项目管理人员一般来说具有很强的技术背景，往往会更多考虑技术因素，面对一个需求时，第一反应就会构思整个实现过程以及在实现中会遇到的问题。而作为业务主体的第一反应是否应该这样：需求的原因是什么？需求是否是完整？对需求的了解还欠缺什么？以及需求在整体中的位置。以技术的角度梳理需求，往往会限制了技术，也限制了需求。以业务为主体，则可以让设计更主动，也利于技术的突破。技术是为业务提供服务的，有时反而成为了借口及对业务做多种限制的理由，在可行的情况下，尽量不要让这种情况产生，否则屏蔽了需求，也屏蔽了下一步发展的源泉。