模型化的企业制度及流程管理系统

模型化的企业制度与流程管理系统是相对文件化的管理系统而言的。在模型化的系统中，企业所有制度和流程都在同一个管理模型中进行制定和维护，所有制度和流程的描述都采用统一的建模语言和方法，并通过此统一的建模语言和方法实现对制度和流程元素的数据化、结构化、标准化、规范化及可视化管理。

模型化的企业制度与流程管理系统的另一个特点是，管理文档由此模型系统自动产生。比如，制度文件、流程手册、标准作业手册、程序文件、作业指导、岗位职责书等这些在文件化管理系统中的支撑文件，在模型化的管理系统中将只是一种输出形式。

当然，要实现所谓的模型化管理，需要借助于最新的IT技术，简单来说就是需要基于这种理念开发一套软件，也就是所谓的模型化的企业制度与流程管理系统。目前绝大部分情况下，文件化的管理系统是基于微软公司的office 系列软件来实现的。

当企业的管理者要制定一套管理制度和流程时，如果是基于office 进行工作，那么一般会先创建一个文件夹，文件夹的名字即制度和流程的名称。在此文件夹中，一般会先用 Visio 的格式画一张流程图，但流程图并不能完全讲清楚一个流程的所有详细信息，因此我们还会写一份制度及流程说明手册，一般为 Word 形式。同时，我们还会建立一个子文件夹，这个子文件夹中有此制度和流程所用到的流转表单的模板。做完上述三件事，我们就认为制定了一套制度和流程。也就是说，流程图、制度及流程手册、表单模板三者构成了一套制度和流程。这是典型的文件化的、离散型的制度和流程管理体系。那么，这样的体统有什么问题呢？

如果我们需要修改某一个制度和流程，比如我们改了流程图中某一流程结点的名称和相应的岗位以及所用表单，流程手册和表单模板并不会自动更正，而是需要人工一一加以修改。当制度和流程很多时，这种一致性往往就会出现问题。这种修改其实也是一种信息的重复录入工作，是一种不增值却又增加错误机率的简单劳动。

另外，不同的人在描述相同的制度和流程时，或者同一批人在不同的时间点描述同一个制度和流程时，由于没有一套强制性的业务描述规范，就会出现描述的差异。比如，同样对于“供应商询价”这个结点，有的时候可以描述成“向供应商询问材料价格”，有的时候可以描述成“向供应商询价”，而完成此事的岗位又可以描述成“采购助理”或“采购业务助理”。之后，当不同的人来读这两个结点时就会产生不同的理解。有的人可能会认为“采购助理”和“采购业务助理”是同一个岗位，有的人可能会认为是两个不同的岗位。如果IT人员基于此开发系统，就会出现是设定两个不同的角色并配以两套不同的权限，还是同一个角色匹配一套权限的差异。另外，由于没有强制的规范性的描述，各部门间或业务人员与IT人员在讨论同一个管理节点时，往往会发生“各说各话”的现象，都认为对方懂了，但其实大家说的是两回事。
还有，文件化的管理体系，没有体现管理要素间的关联，而实际上这些要素是紧密联系在一起的。比如，描述完一套采购部门的管理制度和流程后，如果我们想要知道在这套管理体系中，究竟涉及多少岗位，每个岗位涉及多少流程，如果我们想出具一套采购部门各岗位的职责及操作说明，通常需要根据这套文档重新进行整理，不能直接获得这些原本已存在的信息。

那么，模型化的管理系统又是如何工作的呢？基于模型化的工具描述制度和流程时，除了强调所有的人都连到同一个服务器和同一个数据库，用同一套软件进行工作外,更为主要的是，还强调大家都必须采用统一的建模语言进行描述。比如，我们需要对采购部门的制度和流程进行梳理，那么我们不是直接绘制采购部门的流程图或直接写制度。我们要做的第一步是将业务流程分解为组织、功能、数据和产品及服务四大一级要素。我们首先对此四大一级要素进行描述。具体做法是，先建立采购部的组织结构模型，可以详细到具体岗位甚至个人。这一步一般都比较容易完成。第二步，是基于岗位描述清楚每个岗位的工作。

具体操作是发一套调研表，要求各岗位的人员填写自已每天都做一些什么事，有什么职责，同时完成这些工作需要什么样的输入信息并且会输出什么信息。一般来说，所谓的信息是精细到表单这一层，即输入什么表单，输入什么表单，包括这些表单是书面文档形式还是电子格式的表单，如果是电子格式的表单还需要注明是在什么信息化系统中的表单。将这些信息收集上来后，将这些信息分别梳理成功能视图，即采购部的业务工作分为几大类，每一类又具体做一些什么事；数据视图，即采购部究竟用到哪些表单，这些表单的分类及存在形式。第三步，我们还要梳理出所谓的产品和服务视图，即采购部具体对其它部门或者对外提供什么样的输出。这些输出是整个采购部门所有工作的价值和目的。

完成上述步骤后，我们相当于梳理出了组织、功能、数据和产品及服务四套搭建制度和流程的“标准积木”，也就是先制定了一套“普通话”规范。接下来，我们才开始搭建采购部的制度和流程。具体做法是让采购各相关业务人员连到同一台服务器和同一个数据中，从已经事先输入系统的组织、功能、数据、产品和服务四套“积木”中选用自已需要的“积木块“来搭建管理体系。这个过程，不允许采购业务人员直接“画流程”或“写制度”，而是只允许“搭建”。此时，必然会发生在某一套“积木”中找不到自已所需要的“积木块”的情况，比如某一岗位的业务人员认为需要由“采购业务助理”来完成，但找遍“采购部组织”这套“积木”也找不到“采购业务助理”这个“积木块”。此时，这位业务人员必须向主管部门提出“更改需求”，即要求在组织视图中加入“采购业务助理“这个岗位，才能继续他的流程搭建工作。通过这个环节的控制，不但规范了建模语言，确保大家用同一套规范，同时又梳理了一遍流程。这就是“建模”和“画”或 "写" 之间的区别。另外，通过这种流程建模的方式才能确保所谓的制度和流程梳理能够精细到流程的每一个节点和要素。下面的矩阵分析，就充分说明了这一点。

上述矩阵分析中，横向是所建管理模型中的所有岗位，纵向是所建管理模型中的所有流程节点即所谓的功能点。从这个矩阵分析可以看出，有的“岗位”需要做很多“功能”，有的岗位甚至连一个“功能”都未涉及。有的事即“功能”居然没有任何“岗位”来做。所有这些问题，往往不是因为现有制度或流程有问题，绝大部分情况是因为流程描述或梳理不全面造成的。在传统的文档化管理体系中，这些问题很难一一被发现和纠正。

上图是另一种矩阵分析，即表单/系统之间的分析。可以看到，有的表单是从A系统输出，然后输入B系统。那么，如要A、B系统间没有接口程序的话，这里就存在着系统的断点。由于不集成，表单中的信息需要人工导入和导出。

上图又是另一种矩阵分析，即知识技能/岗位之间的分析。首先，知识技能是作为“功能”的一个信息，输入在“功能“这个“积木块“的特性中的。因此，任何岗位被指定完成某一“功能”时，这个“功能”上所规定的知识技能要求就自动与这个岗位建立关联。由上图可以看出哪些岗位要求的技能多，哪些岗位的要求相对简单。这其实是后续自动编写岗位职责及制定考核体系的基础。

上述流程建模过程完成后，基于流程管理平台可以自动导出 <<制度和流程手册>> 和 <<岗位职责说明书>>，不再需要人为的二次录入了。

模型化的企业制度和流程管理系统相对于文件化的管理系统而言，除了本文所述的区别和价值之外，在流程的深入分析及优化方面，更是将制度和流程管理带入到了一个完全不同的境界，这里限于篇幅就不详述了。

（本文作者为IDS Scheer中国 副总裁 王磊先生）