本文将通过一个税务业务中的一个真实业务来深入浅出的介绍如何利用WebSphere Business Modeler来分析，优化征管业务流程。

前言

作为国民经济运行的重要环节，税收是目前最全面、最及时、最详细和最准确地从宏观到微观反映社会市场经济运行状态和趋势的"晴雨表"。 税收信息化的主要任务之一就是，制定，重组，优化现有的税收管理业务流程,构建高效的信息化税收管理格局。

WebSphere Business Modeler提供了友好的图形工具用来定义和描述用户当前的业务流程，而且可以在多用户的环境下，很方便地共享和发布业务流程定义。定义完业务流程之后，Modeler可以模拟根据用户设定的模拟数据和环境来模拟真实业务环境的数据走向，统计分析此业务的各种指标数据，从而帮助用户优化和改进业务流程。

本文将通过一个税务业务中的一个真实业务来深入浅出的介绍如何利用WebSphere Business Modeler来分析，优化征管业务流程。

回页首

Modeler 介绍及现有业务流程分析

WebSphere Business Modeler是IBM WebSphere家族的一员，作为业务层和IT层的一个桥梁，Modeler给客户提供了方便，形象，高效建模工具。提到建模工具，大家可能就会想到Visio,Rational Rose，其实Modeler与两者都有所不同，基本上荐具了两者的部分特点。

• 业务部门和IT部门共享的工作环境
• 简单，易用的流程建模工具
• 高效的企业建模
• 强大的业务流程分析工具
• 流程模拟
• 友好易用的图形设计工具
• 与工作流引擎的无缝整合

业务人员可以像使用Visio一样方便的利用Modeler绘制直观，易懂的业务流程，组织结构模型，人员角色模型，资源资产模型，可以打印，归档。

Visio所不具备的是Modeler中客户设计的流程是"活"的，业务人员可以按照现实环境，真实业务，配置合理的流转条件，触发令牌，结束条件，每个节点的消耗，盈利，资源使用，等运行时的各种参数，然后Modeler根据一定的概率算法高仿真的模拟出流程运转的过程，客户可以直观的监控运行时状态，比如当前运转到了哪个节点，当前的成本和盈利，资源消耗情况。

模拟运行业务流程后，Modeler提供了多种分析工具和算法帮助客户在模拟出来的数据基础上进行挖掘从而分析出流程的各种指标系数，帮助客户对此流程进行优化，重组。

传统的企业中，一个新业务的上线，或者新流程的部署，往往经过以下这样的阶段：

对于大集中的税务系统来说，流程非常复杂，新系统在上线运行之前很难取到有效的数据作为分析样本。众多问题只能在运行时环境才能发现，于是又需要针对新发现的问题作分析，进行二次开发，再上线，如此一来，就形成了一个循环的怪圈。这就是为什么很多大系统都会有一期，二期的原因之一。

那么，是否能够在系统分析的时候就发现上线后的问题和瓶颈呢？如何能够从这个怪圈里面跳出来呢？

还好，现在我们有了Modeler。

在通过Modeler建立好业务流程以后，可以根据现实需求仿真运行时的数据，Modeler能够采集到整个模拟运行期间的各种数据指标，这些数据都是通过各种概率算法高仿真模拟运行时状态得到的，和上线后的数据比较接近。这样一来，通过完善流程，细化各种配置，客户就可以尽量让流程符合现实业务需求，减少系统瓶颈。最完美的情况就可以跳出上面的迭代开发的怪圈了。

优化流程模型，仿真运行，发现问题并分析，再优化流程，这一切都可以在Modeler中完成，而不需要流程都上线后再去解决，节省了时间和经济成本。

以上是从业务建模角度来介绍Modeler的功能的，Modeler更多的定位是作为IT层和业务层的一个桥梁。

在税务信息化过程中，一个非常大的阻力来自于业务人员和技术人员的沟通，业务人员从业务角度看技术实现，技术人员用技术眼光想业务需求。导致业务人员说技术人员能力差。技术人员抱怨业务人员就知道纸上谈兵。最后的结果往往是技术人员拼命加班加点，做出来的东西在业务上还是漏洞百出，满足不了需求。

这就是因为业务语言和技术语言之间存在着障碍。

WebSphere Business Modeler作为业务视角和技术视角的一个中间点，提供了一套丰富的流程建模功能，包括许多图形化及文本编辑器、业务操作模型 (business operations model，BOM)，以及用于将 BOM 转换成相应的目标平台构件的转换机制。从而创建一个BP模型并将它们导出到 WID(WebSphere Integration Developer)中，生成框架代码，然后经过IT开发人员开发形成完整运行系统。这样一来，实际上业务人员在用Modeler建模的时候就等于是在编写框架代码，就是在用业务语言完成技术实现，也就最大的缩短了业务和技术的沟通障碍。

回页首

虚拟场景

由于地税的业务相对比较复杂，很多业务涉及较多机关，流转分支广，活动节点分散，比较具有代表性，所以我们用地税业务做例子。

假设A市地方税务局随着税收工作的标准化和深入，急需上线大集中的"一窗式"征管系统解决方案，但是如果仅仅是将现实柜台业务电脑化，完全照搬到征管系统中，那又失去了信息化的意义。提高办税效率，优化业务流程，并且从技术角度尽量复用现有系统就成了此系统设计的目的。

简化流程，提高效率的关键在于找到现有业务的瓶颈，挖掘导致低效的因素。

如果仅仅从现实业务中抽样调查，或者人工模拟数据采集分析那显然是不够。Modeler提供了仿真业务运行的强大功能，将现实业务数字化，实现海量数据模拟，从而对之进行分析比较，统计挖掘。

回页首

真实业务介绍

我们用征管系统中比较重要的征收核算的一个具体业务-"会统报表处理"做例子。

先简单介绍一下什么是征收核算，征收核算是指以税务机关为会计统计主体,以货币为主要计量单位，对税收资金及其运动进行连续、系统、全面、综合的核算与控制，同时按照税收工作的要求和统一的制度和方法，根据税收经济现象的数量方面反映税收活动及所涉及的经济活动情况，为税收决策及时、准确地提供信息资料，以保证税收政策法规的正确贯彻执行和应征税款及时、足额入库的一种税收专业活动。

会统报表处理就是指根据会计账簿资料按照统一的格式编制会计报表、统计报表和年鉴表的过程。整个流程比较复杂，涉及基层，市局，省局三级机关，多重数据处理处理过程。

为了比较清晰地的说明问题，我们只取会统报表处理基层部分子流成作为例子，建立模型，进行分析。

基层块统报表处理的过程如下：

1会计人员根据已结算的账簿数据加工生成会统报表，加工后的会统报表必须进行报表校验。

2报表数据经校验无误并经手工复核后，会计人员对报表数据的作"确认报表"的操作。

3经确认的报表数据将转入参与市级会统报表的处理。

现实流程模型如下：

回页首

建立模型

WebSphere Business Modeler 6.0主界面共分为个2大区域，左边是项目导航区，右边是编辑区。

首先介绍一下左边的导航栏：

顶层项目是各种目录，分为：

数据目录，存放各类数据目录，比如流程流转中的表证单书文档结构等

过程目录，存储流程，可复用流程，服务和存储库

分类器目录，按照各种不同的分类器来划分，归类数据

资源目录：对应于流程运转过程中需要的各种资源，比如人员，角色，可消耗资源等。

组织目录：对应于组织结构框架，共流程运转过程中调用选择

报告目录：包括查询和报表，可以定义，发布，自动生成各种数据报表

我们要创建的快统报表处理业务，可以按照处理的机构分为三个子过程，子过程是可以被复用的。

然后进入子过程---会统报表处理(基层)进行更详细的设计：

首先定义这个子过程的一些全局参数

输入设置，从业务角度来讲就是这个任务接收的数据，例如流程中的表证单书。而从IT角度来讲，也可以理解为一个Service的输入参数。在本业务中，我们的输入数据是"本级会统数据"。这里是流程数据的编辑器，其中业务项属性一方面定义了数据的详细标准，对应到业务的数据类型，同时在后面WebSphere Integration Developer中生成源代码中的数据类型也是根据这里的定义来的。

成本和收入，为后来的综合分析做指标，可以给每个过程，对象，子过程，事件定义一定的成本和收入，便于综合统计整个流程的利润，从而分析出节省成本和增加收入的优化方案。

流程编辑器 由三部分组成，左侧是控件库，分为过程元素，连接元素，注释说明三类，中间是编辑区，下面是属性编辑区。

WebSphere Business Modeler提供了非常灵活的过程元素供业务建模人员使用， 其过程元素综合了业务层和IT层的需求。

例如，有一类型元素叫循环，针对编程的特点，将这类循环分成了三种：

循环描述包含在过程内的重复活动序列。

while 循环是满足某些条件时进行重复的循环。while 循环在每个循环开始时测试其条件。如果开始时该条件为假，则决不会执行该循环内的活动序列。

do-while 循环是一个当满足某些条件时重复的循环。与 while 循环不同的是，do-while 循环在循环结束时测试其条件。这意味着其活动序列至少总会执行一次。

for 循环是一个重复指定次数的循环。for 循环使用计数器（有时称为迭代器）来告知对同一活动序列要运行的次数。计数器包含以下三个数字值：

• 初始计数器值
• 增量（每当循环时要添加到计数器的数量）
• 最终计数器值

当计数器到达最终的计数器值，或者（如果存在相关测试条件）当测试条件为"真"时，则该循环结束。

这三种循环，一方面帮助业务人员准确的定位需求，同时也奠定了代码的逻辑基础 Modeler的流程模型同真实业务需求一样重视事件，条件处理机制。

通知广播器是一个发布通知的专门任务。通知反过来可以触发操作。当广播一个通知时， 在该通知范围内侦听的任何通知接收器都将接收它。例如，当一个任务运行完要处理的项时，它就很可能导致广播一个通知。这类通知很可能有一个时间戳记属性来跟踪它完成工作的时间。根据您将什么元素设置为通知接收器，另一个任务可能接收通知并采取行动，从而将更多工作传递给第一个任务，或者可能使该过程结束。

观察器是一个专门观察过程及其相关资源库的任务，当某一条件为真（例如，到达某个阈值）时，它就启动一个流。例如， 在征收申报流程中，设置一个历史欠税纪录的观察器，如果纳税人存在欠税纪录，观察器可以启动另外一个任务来处理欠税。

通知接收器是一个专门侦听通知的任务。当通知接收器接收通知时，它产生已经建模的输出，然后终止。

缺省情况下，当通知接收器拥有的过程启动时，这个通知接收器就开始侦听。您可以更改这种情况，具体作法是：提供一个连接，告诉通知接收器在过程的某一点开始侦听。

定时器是在特定时间点启动流的专门任务。

定时器是一类特殊的观察器。时间点可以被指定为表达式，也可以被指定为具体时间或重现时间。如果您使用表达式，那么可以将时间点指定为从当前时间开始的一个偏移量，或者是从定时器上一次被激活的时间开始的一个偏移量。

例如，您可以为月定时执行的征收申报工作（每月一号到十号为征期）进行建模。定时器操作可以是这一过程的第一个操作，而且在到达征期时，它会触发征收申报过程。

在仿真运行时，这些活动的事件或者任务都会驱动整个模型的运转，从而保证了流程最大化的接近真实环境。

在这个场景中，我们根据会统报表处理(基层)的需求建造了如下的流程。

以上我们就完成了一个流程模型的基本结构，这里我们只是举了比较代表性的例子，Modeler很多的高级功能都没有涉及到，例如动态数据仓库(Repository),泳道布局(Swimlane),组织结构定义分析(Structure Editor)等。

如此多样，细致的模型元素，构成了Modeler强大，灵活的建模能力，同时各种动态的仿真参数给模拟运行奠定了最接近真实环境的基础。随后我们将主要介绍资源配置策略，静态分析，仿真运行和动态分析。