摘要： 围绕“企业建模与模型”这一主题，将过去讨论中散乱的一些比较重要的观点做了一个汇总整理，并结合现在的情况加了一些评述。这一部分的话题包括：企业模型与建模是真正确立企业工程必要的基础、企业建模领域一些研究的简单评述、企业模型与建模研究的几个基本方面、企业建模中的分层与抽象。

引言

以往，因为个人的目标始终放在应用开发上，所以对于企业模型与建模、应用系统架构这些话题，除了一两篇综述或大纲中提及，基本没有专门发文讨论过。曾经发出的一些文字，多是因网友讨论而写的，因此十分散乱。网站重建后，对过去散乱的（尤其是BBS里的）的一些东西做一些整理，将过去散乱讨论中一些比较重要、有意义的内容编辑汇总一下（只包括本人的），并根据现在的情况添做些点评。

企业模型与建模是真正确立企业工程必要的基础

目前的企业工程不可能是完整的，真正有力的，最重要的原因是她还缺乏一个最基本、最重要的条件，就是企业建模的方法论和工具。对于我所设想的企业工程，国外一些企业工程学术研究、教育所采用的IDEF建模工具或方法体系，是达不到企业工程要求的，已知的UML同样如此（或者还可算上OOMD，MDA，及一些软件工程方法体系如模式、RUP等）；而詹姆斯.迈天的企业工程专著中，主要涉及了实施过程、方法、支撑的领域（如信息技术、组织和文化发展），却没有提及企业建模这个要素。我认为，任何工程学的一项不可或缺的基础是对其对象的建模理论、技术、与工具。所以，2002年提出的“企业工程四项愿景”第一项就是：

“独立通用的精确表述——用精确的、通用的、与实现方式与过程分离的表达方式（语言或模型）表述企业，并可将其用于阅读理解（直接或经过自动的转换）、分析、交流以及直接驱动企业平台（企业运做的基础平台，核心是信息系统平台），以此通用的表述方法记述个性化的业务模式以及业务模式的改进与变革方案。”

在合乎要求的企业建模方法和工具诞生之前，企业工程难免有些令人怀疑、边缘化或说是未真正确立的。上述观点，是我对于企业工程提出的一个重要看法。

点评：这些年，BPM领域的业务建模与基于业务建模的BPMS有很大的发展，因而，业务工程也就面临着或具有更多实质性的进展。例如：业务分析师（business analyst）这一角色已经非常清楚地被识别出来，但业务分析师到底是应当属于“应用企业的人”，还是“需求分析的人”范畴，仍然是未决的问题。再上一个层次，整体性的企业建模，还未见什么突破。在企业架构（EA）与框架领域的具体实践中，实际也是在丰富企业建模领域的内容，这方面存在的，IT语境中企业图景的局限性与片面性问题，也是企业建模领域的一个基本问题。

企业建模领域一些研究的简单评述

——CIMS等领域的传统企业建模研究，基本是与同时代的软件实现技术结合的，在详细建模方法（例如IDEF中的部分方法）与总体框架（例如CIM-OSA、GERAM）之间缺乏操作性的连接。对于模型的“阅读理解者”，也没有真正清楚的定位，在建模理论方面也有所欠缺。

——在软件业背景发展起来的企业建模研究，基本是以开发者为中心的，例如BPML无疑是软件系统分析员的工具，用UML来进行企业建模同样如此。此外，他们不可避免地缺乏对企业需求及其问题完整、深入的把握，例如工作流的发展与现状。

——在软件业还有一条发展道路，是信息工程、信息资源管理，它们没有越过传统软件实现观念的门槛，甚至无法跳出狭隘的信息系统（或所谓信息资源）的圈子。但其领袖人物最后不约而同都发展或靠近了“企业工程”概念。他们应当也是“模型驱动”原理的敏感者，但必须在对“信息系统”的认识上有所突破，从历史经验上看，观念的最后一层窗户纸往往不那么容易捅破。

点评：6、7年过去，这些观点仍有参考价值。

企业模型与建模研究的几个基本方面

对此的研究，可分几个方面，虽然实际常常被纠缠到一起，弄清他们还是很重要的：

——建模或模型理论。这涉及到数学、语义学、表达理论等若干基础学科。

——建模语言（或体系）。“理论”是归一的，方案是无穷的。

——建模方法论，它与具体的语言、原理相关。

——建模工具，它与具体的语言、方法论直接相关。今天我们可以说，建模工具基本是以电脑软件方式实现的。

企业建模并不是“建模”领域的唯一课题，软件建模也不是企业建模，即使这个软件是给企业用的。

幸运的是，我们并不需要所有的理论问题都彻底弄清才能构造出有用的东西，在这个领域上，理论和实践是真正地相辅相成。

企业建模中的分层与抽象

“层次”的含义要清楚，是模型的层次，还是模型表达对象的层次，还是目的或目标的层次，或者是功能的层次。所谓“分层的本质”这个问题，是整个系统科学中的若干核心问题之一，它的内涵是非常丰富的。

抽象的本质是什么，这是一个比“数学”还抽象的问题。对模型的深入研究，自然会引发这样的问题，涉及到表达理论的领域。

光盯住“建模”是不够的，建模要放在一个更大的框架，即系统的构建下来考虑。不同的系统以及不同的系统构建策略或方法，对建模或模型有不同的要求。这里包含了许多全世界都还没有解决的问题。

到这个层次上会发现，需要面对什么是我们所要的或涉及的“系统”，以及一些似乎只有哲学家才纠缠的最基本的概念，例如

——什么是软件？

——什么是企业？

——什么是业务？

——什么是模型？

——什么是语言？

——什么是信息？

等等。

企业建模的目的与范围

企业建模研究的首要原则，或第一位的决定因素，是它的预期用途与目的。这涉及谁使用它，怎样使用它？这样的关键问题。

“建模”一词可以有两种用法，狭义地说，建模指用特定的方式表达特定的对象，得到结果（模型）的过程或行动；广义地，可包括对表达对象（比如企业本身）的提取或设计。这里讨论前者。

企业建模，就是建立企业模型（也可以称为企业蓝图）。企业建模的目的、范围等在有关文献中有详细的讨论。这里给出一点个人的、相对精简的思路。我认为企业建模的目的，大致可等同于企业模型的用途，这在实际应用中应当说是层出不穷的，但基本可归纳为三个方面：

表达企业设计（规划）包括再设计的结果，包括企业分析的结果；

用于企业建设与改造（再造），使人们能够精确地按照既定的设计建设或改造、维护企业。

供需要的人作为理解企业的工具或桥梁，包括分析、研究企业——过去的状态、当前的状态、可能的状态等。

理想、完全的企业模型可以包括企业任何相对目的有意义部分的描述，例如企业的物质构成、人员构成、知识或技术构成、行为或业务规则、发展战略等等。这里包含着对企业建模的范围或深度的一种看法或态度：由目的决定。

企业建模必要性的一种理解

有人会说，自从有企业以来，就不曾有所谓理想或精确的企业蓝图，这种理论上的概念有什么必要性呢？也许我们可以躲开这个问题。曾几何时人们也从来没有什么建筑蓝图甚至设计师，许多“伟大”的古代建筑也许就是在那样的环境下完成的。更何况眼前就有一个现实的用途：帮助解决企业信息化或管理软件开发与应用所遇到的一些难题。学究点说，这一用途，可概括在上述三个基本方面之二中，信息系统被看作兴建或改造的企业系统的一个部分。但从它的特殊性、重要性等，也可以将其单列，附加在上述三个基本方面之后，即构建企业信息系统。

企业建模一个重要的现实目标就是：企业可理解使用且电脑可解释，成为新一代模型驱动的企业应用系统的基础。

企业建模的参与者与应用场景

关于企业建模的参与者，在“企业工程”这个话题下讨论企业建模的问题，本身就已经是一种暗示。迄今为止，关心企业建模的主要是两种典型角色（或做或用），一种是CIMS的专家，一种是软件设计者。对于一些体现了新思想的部分支持动态或个性化建模的应用系统，实施咨询者和应用企业内部的实施者会进行建模。

成熟、有效的企业建模，应当是由企业内部的职业化人士（企业工程师）负责，所建立的模型，第一用户是企业自身的管理、业务人员。可能不少企业管理人员，听了这话会觉得象是在发白日梦。其实不然，企业建模一点都不神秘，在需要建立、改造企业的时候，几乎首先都会画一个组织机构图，也许还有业务流程，这就是企业模型，没有丝毫的牵强。问题有二：一、现有建模方法、工具设计就不是针对企业中人的；二、缺少支持动态应用企业模型的系统。

所以，这两样东西也是企业工程所要追求的目标。可以想见这样一个情景，傍晚的一次高层经理会议上，对新的企业架构，人员、关键业务的分工、流程等等做了新的分派，他们在大屏幕上直接调整图形、文字组成的组织结构图、流程图等等。第二天，员工打开电脑，发现自己归属的部门、可访问的资源、业务关系等等已经按照新的安排改变了……这种企业建模，这种企业工程，不是企业管理者梦寐以求的吗？说到这里，任何人都不难领会我1998年提出的新一代企业信息系统是什么，还有为什么虽然同样提出了模型驱动，我对MDA却不觉得惊奇。也许有人说，现在支持工作流的OA已经满天飞了，也出现了基于建模的业务基础平台产品。不错，它们确实向我说的方向进步、努力了，有些也很有成效，但仔细品味上述的图景，特别是背后的东西，不难发现其中的差距。

我在企业第一线各级职位上工作了近二十年，可以做一个很大胆的说法：如果您的系统做到位了，没有一名企业的经理不会想方设法地把它弄到手，如果不是这样，就是还有些什么关键的东西不到位。

前面的对话也许给人一个错觉，好像企业工程是信息技术应用或软件开发、实施方面的一种东西，这或许需要重新强调一下。信息技术虽然在企业工程中扮演着多重的关键角色（参见论坛上的文章），但企业工程是“企业的”，不是软件系统分析师或咨询师的。

前面描述了一个简单而基本的图景。对于小企业说，也许所有的企业蓝图，就通过那样的方式，在若干个夜晚就完成了。但对于一个稍微大的企业，比如在最高管理层下有三个左右的组织层次，几百个互相关联、或包含的组织，以及跨越这些组织的各种业务过程，在那样的会议上，能够讨论的就只会是原则、少数关键机构、环节。是否可以自顶向下做任务分解，各部门自己规划？只有范围明确于分支内部的问题可以。

但能够真正“割裂开”规划的东西很少。此时，“企业工程”——系统的知识、方法、工具以及职业化的企业工程师的作用或需求，就涌现出来了。

同时，企业的各级经营、管理者、业务人员、咨询顾问，还有另一个“角色”——企业信息系统或综合管理软件，——大家都有一个共同的语言——企业模型（或称蓝图），这是保证大家的讨论、理解有效、一致的根本。

表达，模型和企业工程的关系，是否可以简单地这样叙述：模型是一种严格的表达，企业工程需要对企业及其相关事务的严格表达，所以要建立企业建模的方法。愿景中的企业工程对模型构建性、可理解性和严谨性诸方面提出了新的更高的要求。

企业建模的双重目标：企业可理解使用且电脑可解释

一种同时满足“企业可理解使用且电脑可解释”的企业建模表示体系，是一个意义非凡的课题，但并非空中楼阁，也并非要等待它成熟我们才能从MDS（模型驱动系统）中获益；MDA是目前出现的可以用来实现模型驱动的企业应用系统的途径之一。企业应用软件的形态将是多样性的。模型驱动的企业应用系统需要同时也将促进、支持企业工程。

评注：这一小段话里面浓缩了很多东西。近年，也多次看见国外一些人提出了模型驱动的企业应用系统（Model-Driven Applications）这样的概念，但凡这样的概念，核心原理一定是MDM，许多人潜在地认识到这一点并实际地运用这这个原理。适合这种目的的企业建模体系还没出现，或者倒过来说，对于这种用途到底需要怎样的模型，还没有弄清楚（或者说，这个问题并没有被真正提出和研究）。

关于模型的一些零星话题

模型就是对特定对象的一种表达，它不是简单的信息，而是一个有机结合的信息集合。从表达研究来说，企业模型或软件模型都是一种可研究的对象，它们是有特定目的的复杂表达，其规范性在某些方面甚至超过科学表述。（评注：比如，从一篇论述经济学供需模型的论文，到建立计算机模型，中间需要建立很多更精确的、细节的表达）……对“表达”，我特别区分其作为动词和名词两种用法。“模型是表达”，表达是名词。狭义的“模型”，是一种特殊的表达。广义地，所有的表达都可以看作是模型。

如何表达一个频繁变动的对象，是建模原理研究的核心难题之一。有一个说起来很简单的原则：找到在既定范围和目标下变化中不变的东西，就是变化的规律。我从面向对象模型等计算机领域的各种建模范式出发寻找共性的东西，最后在哲学上找到了某种根源或印证，发现这类问题紧密联系着人的认识的许多根本问题。其实面向对象模型就是一种相当基本的“认识模型”。应付变动的办法就是将表述的规则与表述的实例与实现彻底的分开，增加一个“层次”的元模型。（评注：这个关键要点，实际上是“模型驱动机制”的多项关键特征或结构之一）

如何进行抽象分层？层间的相对独立性如何，它的依据是什么？——有对象自身的层次在抽象结果中的反映，也有抽象方式本身的层次问题。就抽象本身而言，最基本的（自然的层次）就是抽象结果和被抽象对象之间造成的：对抽象的结果再抽象，就自然形成了另一层次上的抽象。在MDA体系中的元模型层次体系就是这样一个分层体系。假设“模型”是当前层，则“元模型”就是当前层的抽象模型，元－元模型就是当前层抽象模型的抽象模型。但，是否还有其他重要的（内在）的分层方法呢？（评注：实践中可以看到的多数分层，都是凭直觉的）

模型的相对论：……如果一个模型表达的对象本身也是模型，那么就称其为元模型。如果有一个用来表达语言本身譬如语法的模型——比如，可以用某种“义素，句法……”模型来描述语言——这个模型就是语言的元模型／元语言了。再譬如，如果说文章是一个思想模型，那么写这个文章所用的语言就是一种元模型了，这就是我为何强调要在“层级”中相对地看模型的一个例证，这个东西，可称为“模型的相对论”

另外，“仿真”与“粒度”一样，是个“弱”的概念，所以我总是小心地回避。（这后面有若干我所谓有特别操作意义的要点，而且我说所谓理论上的里程碑，跟这个也有关系。

我曾经将“模型、范型、范式、样式、样板”等中文词汇和英文词汇都放在一起推敲比较过。重要的体会之一，就是这个地方“模型”应该是最一般最好的一个基本词汇，但精确的讨论需要更严格的表述——数学的表述。大约２、３年前我曾闭门造车尝试一些最深层的理论探讨，这是一个重要的起点。正是这些工作令我在这方面的认识得到了一次飞跃，从而确立了真正的信心。

新明这几句“随想随说”相当清晰，内涵丰富，所表达的意思与我的模型观几乎完全一致：

模型的相对性。借此我想指出：“仿真”模型这个“仿真”含义的狭隘性，正是用“相对性原理”这个镜子可以照出来。
“用一种标准的规范来表示是模型，随意地画两笔也是模型”——这就是我为什么将模型归诸于“表达”的简明表白。
模型的层次“受限于我们的认识”——这里点出了模型/建模与认识论的关系。
元模型与层次：“模型始终是中心”——这个新明归纳得好！抓住一个中心，是摆脱相对性所带来窘迫的要点。
表达力不是衡量模型的唯一标准。这必须和“用”联系起来，譬如我列举出的企业模型的四个特征（也是评估要素）——表达力、精确性、适用性、与应用系统集成
有些地方是有空时可以探讨的，有趣的理论话题，如：层级的无穷性？“起点”？所谓“双向性”？还有前面余山已经指出的“自表示的限度”，等等，这些问题的讨论，很自然地联系到数学、哲学领域的一些基本问题。

“简化”与企业建模一般目的与应用目的

“简化”这个词多次出现，我对简化这个词的使用是有一点担忧的：简化是形式，说明约减了某些东西，建模表面上看是化繁为简，但简约只是数量比较上的一个现象。数量的减少，不一定是约减，也可能来自概括。此外，将缺乏结构的、不好的、冗余的、矛盾表述转换为结构的表述，在表达文本的数量上可能减少了，但所谓“信息量”或“意义”不一定减少。所以“简化”对建模是一个不好的、表面化的形容词。

这个问题涉及到李文华先生前面帖子提到的：“企业建模的目的其实倒是容易看清楚的，因为在某种意义上，企业建模的目的等效于任何建模的目的，都反映了模型‘一步简化’和‘促进交流和理解’的本质。但是，企业建模的范围却显得更需要我们去关心，因为它要求我们明确‘研究什么？’”

这里，我认为有个目的层次问题。李先生上一段话所说的目的，可以称为一般性的、基本的目的（例如我以前帖子归纳的企业建模的三点目的），而实际进行的模型构造工作，总是应当有一个或多个具体的、应用的目的，例如以成本控制为基本目标建立成本核算模型。所以，具体的建模，就是根据这个具体的、应用的目的，去抽取企业对象的要素、关系等等加以表达。企业建模的范围，就是依赖于具体的、应用目的确定的。

我想这大致是一种理想意义下、从企业工程建模角度的理解，还不够全面。在这种理解上，再造工程，还有Jamse Martin的企业工程等都做得很漂亮，它们都是首先与企业的使命或战略联系起来，理解企业、业务乃至企业/业务工程，价值问题也与客户紧密地联系着。

仅就企业建模这个专门话题，可以从更广泛、实际的角度去理解，这就要与具体的目的挂钩。至少在较为理想的、整体化的企业工程形成、出现或被运用之前，我认为绝大多数的企业建模应用都会是更加具体、相对局部性、方面性的，因此必须用目的来界定范围。换言之，以一种现实主义的眼光看，企业建模并不能简单纳入企业工程（EE）的帐下。

评注：“目的层次”，也就是“多重目的”。这里有意回避了用于“应用系统”这一目的。

企业模型与信息系统或企业应用系统模型的区别

读到宋兴烈《业务基础平台——黎明之前》一文（http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=46 ，发表在《程序员》2005年第5期）。文中提到：

“企业的组织机构、权限、业务分工、流程、业务语义、业务处理规则、业务关联规则等诸多的方面，都是很难用‘面向对象’和3GL程序语言的体系来描述的。这一问题的深层次原因，是因为企业管理系统，或者说企业信息系统，从根本上来说，其本质都是非计算模型。而‘面向对象’和3GL语言体系，其主体是以计算模型为核心、面向软件实现的概念描述体系，而不是面向企业信息系统‘目标对象’的概念描述体系。”

——这段文字说出了认识上超越的关键。我在前面的帖子中点到“MDS与可执行UML就好像处于极点的两边，紧紧相接”，以及基于建模的企业信息系统（及MDS）与软件领域出现的MDA的对应——“这个交汇仍可能因为层次的错位而南辕北辙”，背后的关键认识之一，就包含在上面宋的文字中。

——意识到这个分界的存在，辨别出这面的截然不同（就如同冷空气和热空气交界的锋面），在对这个问题的认识上，是有里程碑地位的。

——再稍微提一点：“富语义”表达模型、本体知识工程方面的东西，表面上看，似乎是锋面另一侧的东西：就向下面这样：

3GL/4GL/… UML(?) … | … RDF/OWL/Ontologies

它们划分在锋面两端的关键理由，在宋兴烈的文章中实际已经指出了：“面向计算”与面向“目标对象”（“目标对象”这个组词法很怪？这可能和软件技术用语的背景有关。考虑一个更有哲学意味的汉语词：“客体”而客体不就是object吗？这不又回到“面向对象”了吗？其中意味，大家慢慢咀嚼吧）。

——越过这一认识关键点，就自然会理解我为何一再强调“涉及到软件是什么”这个根本问题。

文章还说：“……相关的基础理论体系和标准领域，国外的企业和机构处于绝对领先的地位，业务基础平台的基本描述体系理论和标准，主体将全部来源于国外的学术机构和标准化组织”。

——也应该看到，国外的研究，并非在上述关键前提清楚之下规划、进行的，而是从不同的领域（比如人工智能或知识表达，软件建模等）自然演进、汇集到此的。能够率先发现这个“锋面”，这就是一个可能超越的基点（超越不等于把已有的东西否定，更多是在它们的基础之上开发新东西），从超越的角度看，国外现有的这些东西，只不过是一些初步、自然的基础，甚至还只能归纳为“材料”。在这个基础上可以建高楼，何须担心“先机”被别人占了？何须担心我们没有机会？何须担心我们没东西可做？有些东西是要水到渠成的。

——仅仅基于上述认识，去观察国外许多关于“语义模型”或企业建模、软件建模方面的工作，就已经可以发现研究者多数都没有从这样一种角度去考察、着眼，做理论研究的朋友，仅仅从这里，就不难发现许多“现成的”、具体的、前沿的课题。

宋文中说“从整体上来说，业务基础平台还处于第一代产品时期。这一代产品的基本特征是：初步体现和实现了‘业务模型驱动’的主体思想，但依然存在一个最大的缺陷：即缺乏真正体系、完整、标准的业务模型描述体系”。与此对照，我曾在之前说“一种同时满足‘企业可理解使用且电脑可解释’的企业建模表示体系，是一个意义非凡的课题，但并非空中楼阁”。为什么说不是空中楼阁？认识到一些关键点，就会发现已有的企业（包括业务）建模研究工作、语义建模或软件建模研究工作的弱点和新的“借鉴途径”，而建立“满足理想的新体系”完全是有章可寻，可把握的工作。

——认识超越了，自然感觉“一览众山小”。

评注：可以说，这里表述的东西，才是一些实质性、深入研究的开始点。也只有对这个关键点和背后的一些东西（藏着不少秘密）弄清楚了，才知道我们可以或者需要一个什么样的企业模型，包括建模语言、表示法等等。