业务梳理与功能建模

业务梳理与功能建模
——信息资源规划（IRP）系列讲座之五
企业信息化到了中高级时期，企业领导和信息主管（CIO）需要对全企业信息系统的功能进行总体把握。

专门是当业务进展变化以及治理人员使用运算机的水平提高之后，企业的业务人员和各级治理人员会对现有的一些应用系统不中意，但对期望的新系统的需求又讲不清晰，这就面临如何进行应用软件开发或进行选型的问题。

通过信息资源规划，在全面梳理业务流程，建立起全企业信息系统功能模型之后，就容易依照各子系统、功能模块和程序模块的具体情形，优化、整合、选购、定制或新开发，从而形成在市场竞争中具有快速反映能力的、完善的信息系统。

业务梳理与业务模型
信息资源规划之因此要进行业务分析，是为了按信息工程的思想方法来重新认识企业，以便能系统地、本质地、概括地把握企业的功能结构。

这确实是人们常说的“业务梳理”。

按照信息工程方法论，我们采纳“职能区域－业务过程－业务活动”如此的三层结构来梳理业务，这确实是业务模型(Business Model)。

职能域(Function Area)是对企业中的一些要紧业务活动领域的抽象，而不是现有机构部门的照搬。

例如，某制造厂的职能域有：经营打算、财务、产品打算、材料、生产打算、生产、销售、配送、会计、人事等。

每个职能域都含有若干个业务过程(Process)。

该制造厂共有37个业务过程，其中材料需求、采购、进货、库存治理、质量治理，这五个业务过程属于“材料”职能域。

每个业务过程都含有若干个业务活动(Activity)，如“采购”业务过程包括“提出采购申请单”、“选择供应商”、“编制采购订单”等业务活动，它们是差不多的、不能再分解的业务单元。

假如将上述识别、定义企业的职能区域、业务过程和业务活动看作是一件简单的情况，就难以进行全面业务梳理，建立有效的业务模型。

因为业务模型的建立，需要业务人员与IT人员达成共识，需要一定的理论指导和反复讨论，而这本身也是提高企业治理人员素养的一项重要工作。

在进行了业务梳理和业务模型的建立之后，才能进一步进行运算机化可行性分析与功能模型分析。

运算机化可行性分析与功能模型
并非所有的业务过程和业务活动都能实现运算机化的治理，经分析能够发觉：
◆有些业务过程、业务活动能够由运算机自动进行；
◆有些业务过程、业务活动能够人-机交互进行；
◆有些业务过程、业务活动仍旧需要由人工完成。

我们将能由运算机自动进行处理的、人-机交互进行的过程和活动，按“子系统-功能模块-程序模块”组织起来，确实是系统功能模型（Function Model）。

全企业系统功能模型表述方法是：列出全部子系统并简要描述每一子系统，列出每一子系统所含的功能模块并作定义，列出每一功能模块所含的程序模块。

例如，下面的图表是某制造厂信息系统功能模型的一部分。

现举例说明：为得出功能模型，如何对业务活动做运算机化可行性分析。

第一，看下面的部分业务模型：
“编审材料需求打算”业务活动关于原先的人工处理来说，任务是明确的、可行的，但对运算机信息系统来说，则任务是不明确、不可行的。

因为，
编排材料需求打算和审查材料需求打确实是两种信息处理过程，其中，编排材料需求打算，第一需要采集各基层单位的材料需求信息，然后再进行汇总，并对比当前库存信息；而审查材料需求打算，第一要审查各基层单位的材料需求是否合理，一样来说，这是非结构化或半结构化的处理，不易实现自动化运算。

通过分析，两类人员达成共识：对基层单位材料需求的审查，连续沿用人工审查方法；设“录入基层材料需求打算”程序模块，设“汇总基层材料需求”程序模块，自动分类汇总运算各打算期的材料总需求；而“编辑采购打算”能够作为人-机交互的程序模块。

通过这些具体分析和规划，得出的功能模型如下：
功能模型的建立与使用
信息资源规划组在进行系统功能建模时，要充分利用需求分析资料和有关的信息系统知识、体会，这些差不多上系统功能建模的重要资源。

为此，需要注意：
1、认真做好需求分析资料的复查工作，其中与功能建模直截了当相关的复查工作包括业务分析结果（即业务模型，重点是职能域和业务过程的定义）的复查和数据流程图（一、二级数据流程图相匹配，并与业务模型相一致）的复查。

复查决不能仅限于在系统分析员和业务代表中进行，一定要使业务部门负责人参与进来，最终达成共识。

2、通过复查确认的业务过程和业务活动，再通过运算机化可行性分析，就会有相当多的部分被选入系统功能模型。

3、企业已有应用系统行之有效的功能模块或程序模块应予以继承，还有其它应用软件的有用模块也应该吸取，这些模块也被加进系统功能模型。

4、最重要的是为落实业务流程重新设计（BPR），上述几点都不是简单的堆砌，而是使功能模型充分表达新的业务流程，新旧模块需要有创新性的组合。

需要着重说明的是，功能建模拟定的子系统是“逻辑子系统”（面向规划、设计人员），而不是“物理子系统”（面向最终用户）。

许多运算机应用系统差不多上按当前的组织机构和业务流程设计的，“系统”或“子系统”名目繁多。

机构或治理一变动，运算机应用系统就得修改或重做。

事实上，只要企业的生产经营方向不变，企业差不多的职能域是相对不变的，基于职能域的业务过程和数据分析能够定义相对稳固的功能模块和程序模块，如此建立起的系统功能模型能对机构治理变化有一定的适应性。

因此，“逻辑子系统”作为这些功能模块和程序模块的一种分类（或分组），是对全企业信息系统功能宏观上的把握。

然后，在应用开发中按照面向对象信息工程，加强可重用模块的开发和类库建设，这些模块和类库部件都以存取主题数据库为差不多机制，就能够按照最终用户对象，组装多种“物理子系统”。

假如机构部门变化了，信息系统并不需要重新开发，只是需要对模块/部件做重新组装，因而能从全然上改变长期以来一直无法解决的运算机应用系统跟不上治理变化的被动局面。