系统分析与设计方法---工作流设计

工作流设计

    工作流技术的发展，经过多年的努力，取得了一定的成果。但在实际应用中，应用的企业还是较少，应用的范围窄，效果不理想。

    流程的设计是对设计者更高的挑战，现实中对计算机所管理的流程需要灵活的定义、方便的路径修改、容易使用，可是这几个目标是矛盾的。更严重的是，如何分析现实中的流程本身就是个困难的问题，更不用谈如何来设计实现了。流程设计的主要困难实际上也就是软件的主要困难：现实复杂性。

    任何对现实的描述（图形也罢，文字也罢）都是不完美的，“不识庐山真面目”是设计面临的共同难题。设计者不得不意识到所有的流程模型都是对现实的简化，计算机只根据确定的信息作判断，而现实中的流程存在大量的不确定性，虽然计算机专家们自信地告诉企业管理者这是管理的问题，信誓旦旦地保证可以用计算机系统来“完善”企业的管理，但他们似乎没有意识到企业管理已经发展了几百年，而计算机还没有百年的历史。

    人们常常抱怨计算机系统的流程设计太过刻板，因为许多时候，标准流程是先于应用构造的且由一些集中的权威强制执行的，所以这种刻板性是不可避免的。同时，对参与者而言缺乏自由度导致工作流管理系统显得很不友好。结果是它们经常被忽略或绕过，甚至最终被放弃。

    另外的困难是：对于流程处理，不但名称众多，例如，动态模型、工作流等，而且对流程的定义也是千姿百态。面对这些困难，设计者无疑需要巨大的勇气来进行流程设计。

1 工作流设计概述

    限于篇幅，这里只列出工作流管理联盟对于工作流的定义：“工作流是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则、文档、信息或任务在不同的执行者之间传递、执行”。

    （1）工作流。简单地说，工作流是现实中的具体工作从开始到结束过程的抽象和概括。这个过程包括了众多因素：任务顺序、路线规则、时间时限约束等。

    （2）流程定义。流程定义是指对业务过程的形式化表示，它定义了过程运行中的活动和所涉及的各种信息。这些信息包括过程的开始和完成条件、构成过程的活动及进行活动间导航的规则、用户所需要完成的任务、可能被调用的应用、工作流间的引用关系，以及工作流数据的定义。这个定义的过程可能是由设计者用纸和笔来完成的，但越来越多的设计者倾向于使用流程定义工具来完成这个工作。

    （3）流程实例。也常常称为工作，是一个流程定义的运行实例。例如客户的一次订购过程，客服中心受理的一次客户投诉过程等。

    （4）工作流管理系统。和数据库管理系统类似，是一个软件系统。这个程序存储流程的定义，按照所使用的流程定义来触发流程状态的改变，推动流程的运转。这个推动的依据常常称为工作流引擎。

    （5）流程定义工具。同样是一套软件系统，这个软件和工作流管理系统的关系就如同数据库设计工具和数据库管理系统的关系一样。它可能是独立的软件，也可能是工作流管理系统的一部分。如前所说，设计者常常使用流程定义工具来完成流程定义的工作。它提供一些常用的工作流元素素材，以提高设计者的效率。

   （6）参与者。回答业务流程中“谁”这个问题。它可以是具体的人或者角色（企业内部有特别共同作用的多个人），也可以是自动化系统，甚至是其他系统。

    （7）活动。活动是流程定义中的一个元素，一次活动可能改变流程处理数据的内容、流程的状态，并可能将流程推动到其他活动中去。活动可以由人来完成，也可以是系统自动的处理过程，典型的自动处理是当活动超过了这个活动可以容忍的时限时，自动过程将向流程定义中指定的参与者发出一条消息。

    （8）活动所有者。参与者之一，他有权决定该活动是否结束，当他决定活动结束时，将活动推动到其他活动中，可能是下一个活动，也可能是前一个活动。

    （9）工作所有者。工作所有者是有权整体控制流程实例执行过程的参与者。

    （10）工作项。代表流程实例中活动的参与者将要执行的工作。

    要分析现实中的处理流程，必须首先描述目标系统的流程，这个过程也可以称为建模。流程是个复杂的事务，必须从多方面才可以描述一个流程，包括：“谁”，流程的参与者； “什么”，参与者做什么工作；“何时”，工作完成的时间限制，还需要说明工作的数据流和完成工作的控制流。人们认为自然语言在描述如此复杂的事务时容易引起歧义，所以人们定义了一些形式化语言试图在自然语言中挑选一个子集，这个子集既可以真正描述流程，又能够摆脱自然语言的复杂和多变，实际上想在人和机器在理解处理流程上架起一座桥梁，如同其他计算机语言及后来发展的统一建模语言一样，这些形式化的语言也称为“工作流定义语言”。

    同样，为了描述实际中的处理流程，人们也想到了图形的方式。有限状态自动机是一种分析状态和改变状态的良好工具，这种方法需要完全列出流程中所有状态及这些状态的组合，当处理流程变得庞大时，自动机所对应的状态图膨胀得太厉害。由于 Petri 网有严格的数学基础和图形化的规范语义，在描述离散事件动态系统方面的能力已经得到公认，具有较强的模型分析能力，在工作流的描述和分析中已经是人们广泛采用的一种方法。虽然有人认为图形并非工作流的最佳表示方法，但由于图形的直观性，大多数设计者都愿意采用图形的描述方式。有关有限状态自动机和 Petri 网的论述请参考其他书籍。

2 工作流管理系统

    根据工作流管理联盟（Workflow Management Coalition，WFMC）的定义，工作流管理系统是一种“在工作流形式化表示的驱动下，通过软件的执行而完成工作流定义、管理及执行的系统”，其主要目标是对业务过程中各活动发生的先后次序及与活动相关的相应人力或信息资源的调用进行管理，而实现业务过程的自动化。

    如同关系数据库一样，现在已经出现了专门的工作流管理系统，这些系统经过专门的设计，从不同的角度负责解决设计者在流程设计中遇到的共同问题：节点定义、路径选择、数据流动等。不幸的是，和关系数据库共同基于关系代数、支持标准的 SQL 不同，这些工作流管理系统基于不同的数学模型，提供完全不同的接口。所以这些工作流管理系统各具特色，但在通用性和其他系统相互协作上的不足使得这些系统的应用受到了限制。

    WFMC 给出了包含六个基本模块的参考模型，这六个模块被认为是工作流管理系统的最基本组成，这个参考模型同时包括了这些模块之间的接口标准。

    （1）流程定义工具。这部分软件提供图形化或者其他方式的界面给设计者。由设计者将实际工作流程进行抽象，并将设计者提交的流程定义转换为形式化语言描述，提供给计算机工作流执行服务进行流程实例处理的依据。

    （2）工作流执行服务。这个服务程序是工作流管理系统的核心，它使用一种或者多种数据流引擎，对流程定义进行解释，激活有效的流程实例，推动流程实例在不同的活动中运转。和客户应用程序、其他工作流服务执行程序及其他应用程序进行交互，从而完成流程实例的创建、执行和管理工作。同时这部分软件为每个用户维护一个活动列表，告诉用户当前必须处理的任务。如果有必要，还可以通过电子邮件甚至是短消息的形式提醒用户任务的到达。

    （3）其他工作流执行服务。大型的企业工作流应用，往往包括多个工作流管理系统。这就需要这些工作流管理系统之间进行有效的交互，避免画地为牢、信息孤岛的现象出现。

    （4）客户应用程序。这是给最终用户的界面，用户通过使用这部分软件对工作流的数据进行必要的处理，如果用户是当前活动的拥有者，还可通过客户应用程序改变流程实例的活动，将流程实例推动到另外一个活动中。

    （5）被调用应用程序。这常常是对工作流所携带数据的处理程序，用得很多的是电子文档的处理程序。它们由工作流执行服务在流程实例的执行过程中调用，向最终用户展示待处理数据。在流程定义中应该定义这些应用程序的信息，包括名称、调用方式、参数等。

    （6）管理和监控工具。如同数据库管理系统或多或少地提供一些方式告诉管理员当前数据库的使用状态一样，工作流管理系统也应该提供对流程实例的状态查询、挂起、恢复、销毁等操作，同时提供系统参数、系统运行情况统计等数据。

   看到这里，没有处理流程设计经验的设计者一定已经云里雾里了。确实，流程设计是系统设计中最困难的一部分，它的复杂性直接来源于现实世界的复杂性。而且直到现在，人们对流程的设计，仍然是在探索之中。