前面讨论中，李文华提出了“企业建模的范围”问题，林星增加了“目的”（见第一轮对话的贴子），这里借着这两个话
题，引申到“模型驱动系统”及与“模型驱动开发”的区别这个比较特殊的问题上，这同时涉及前面说的，企业工程四项愿景之
首所包含的“直接驱动企业平台”这个要求。

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

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

　　1）表达企业设计（规划）包括再设计的结果，包括企业分析的结果；
　　2）用于企业建设与改造（再造），使人们能够精确地按照既定的设计建设或改造、维护企业。
　　3）供需要的人作为理解企业的工具或桥梁，包括分析、研究企业——过去的状态、当前的状态、可能的状态等。

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

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

　　设想由“企业的人”清晰准确地描述它们需要的企业（部分的），然后这些需求或构想被反映在它们面对的企业信息系统
中——这可以有很多种不同程度的实现方式或层次，以下四种可能是最典型和重要的：

　　1）形成书面叙述文件，交给软件开发者去进一步设计实现。
　　2）形成严谨的叙述文件，可能某种程度（部分）电脑可解释的，令其精确地限定整个开发过程和结果。
　　3）形成完全电脑可解释的模型，自动生成代码。
　　4）形成电脑可执行的模型，基于通用的平台，直接形成面对用户的“功能”。

　　我在1998年所提出的新一代企业信息系统构思，对应上述第四层，我自己称其为“模型驱动系统”（Model Driven 
System, MDS）。目前MDA的理解和应用，主要集中在第二层和第三层。不同层次上，对模型的要求、效果和实现方法，都是不可
同日而语的。

　　所谓直接驱动企业平台，要省略上述3）所保留的最后一点传统“编程”的手续，这种过渡在逻辑上是很自然的。正因为如
此，很早以前我就猜测3友代表的研究走向，后来得知他们的提法是可执行的UML。

终结－第四层

余先生所说的第四层如果能够实现，那么将会是软件开发的一次大变革。但目前大家对这个变革是否会发生所持的态度是很不同
的。实际上，在可执行UML的概念推出的时候，国外已经经过了一轮激烈的讨论，到底可执行UML是否能够实现呢？最后大家的看
法基本上是，这是一个未来的发展方向，但有很长的路要走。目前作为中间解决方案的MDA，属于第三层。达到第四层的路是否
真的这么长呢？

在第三层，模型和代码仍然是分开的。因此，大部分的MDA，是将UML模型设计完成后，借用模板（或其它），形成最终可用的代
码，当然，可以额外加入一些代码。这是目前比较可行的办法。因此，在第三层，设计期和运行期是截然区分的。但是在第四层
上，模型无需转化为代码，或者说，代码是我们看不到的。通过模型的设计，直接就可以得到可运行的应用（也许到时候就没有
所谓的应用概念了）。因此，设计期和运行期的分界开始模糊，逐渐统一到同一个平台上了。那么，模型的设计，也许就不是由
程序员来负责了，也许是由企业顾问，或是企业中经过培训的业务人员来负责。

目前大家已经越来越多的倾向于关注什么是合理的企业架构，如何表示合理的业务流程了，而不是关注于具体的实现技术。因
此，要实现第四层的目标，最关键的问题，决不会是在技术上。

那么，问题的关键应该就是企业本身的业务问题上了。企业是一个多目标，多维度的复杂系统。如何找到一种方法来表示这个复
杂系统呢？如果这种方法能够找到，并证实是有效的，那么，构造出一个企业模型就不很难了。而规范化的模型能够得以构造，
那么代码的实现也不会是很难的事情了（如果能够实现计算机对模型的解释，直接执行模型也将成为可能）。

因此，说来说去，问题的关键就又集中在如何在一定的范围内，找到一种方法、语言、模型来表示企业复杂系统上了。

提到表达，我则想到了余先生推荐的欧阳老师的书－《表达的研究》，在论坛的下载区，有一篇专门讨论企业指标体系和表达的
关系，推荐一读。

　　是的，这是一场正在发生的革命，从UML到MDA，再到可执行UML，确实有某些东西演进到一个极点。MDS与可执行UML就好像
处于极点的两边，紧紧相接，却有着完全不同的背景或寓意。同时，在企业领域，这也对应着一种革命——信息化。

　　在对企业应用的认识过程中，我经历了这样几个关键点，这跨越了大约8年时间：

　　需求模糊与变化的必然性->转达失真的必然性->直接的精确表述（建模）->模型直接决定系统功能（模型驱动系统，MDS）

　　以上过程，在“建模”上与软件开发交汇了，到“模型驱动”可谓殊途同归。这个交汇在时间上的联系是偶然的，但有内在
的必然性。尽管如此，这个交汇 仍 可 能 因 为 层 次 的 错 位 而 南 辕 北 辙。

　　作为一种基础技术提出的MDA，并不直接解决企业应用上实质问题。例如，即使实现了模型驱动的开发过程，具备了增量式
的、逐步求精、迭代的特征，其软件产品对于应用企业需求变化的响应仍然是“异 步 的”。MDS的诉求是使上述响应变成“同 
步 的”。

　　在完成了上述8年的认识历程后，我以最终实现为目标全方位探索。如林星设问：达到第四层的路是否真的这么长？我问，
这种似乎理想主义的企业模型驱动系统怎样才能实现？

　　——从哲学上、理论与方法论，还有实践的发展上看，“模型”表述的能力和可行性是无需怀疑的，虽然对模型语言或表示
法仍需研究；
　　——真正的MDS触及软件是什么这样的根本问题（实际上，模型驱动系统还不是最恰当的表述），对这个方向无需怀疑，但
与面向对象的出现一样，它并不会简单替代掉许多现有的技术，软件或系统的样式将丰富起来；
　　——解决企业应用的困惑，需要“双方”的努力。“将转达的失真”降到最低的途径，就是企业工程的方法：由企业工程师
负责建模；
　　——很关键地，从对企业需求的理解和对应用开发的经验，我得到一个信念：并不必须要彻底、理想的实现，认识的彻底转
变是相当关键的。当前有很多可行的切入点和足够的技术条件，可以在实际的企业应用中得到足够好的效果；
　　——企业应用软件是多样性的，未必每一种应用都适合上述思路，所以我通常将话题设置为“新一代企业信息系统”。

　　为了使表达完整一些，上面的讨论似乎有些超出话题，但这也反映了企业需求与困惑、企业工程理论与方法、企业应用原理
与实现技术方法等要素是怎样紧密地纠缠在一起。

　　到此，进一步讨论“企业建模”的表示法，或语言、工具、方法问题，就有了一个比较清晰的语境。

　　联想上一轮提出的“设计原则”的话题，就是它需要适合“企业工程师”使用，不管是图形化、自然语言风格，关键在于必
须适合“企业人士”阅读理解；与此同时，保证其内在的精确性。所谓精确，就是软件（电脑程序）可解释或处理。

　　在开发这样的企业建模体系时，不能忘记已有的工作，如：

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

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

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

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

余先生关于企业建模目的的“个人的、相对精简的思路”我比较赞同，并且注意到余先生的表述中体现了抽象和通用、并多处强
调把企业建模与信息系统实现分离开来。分离开来的确很有意义。为什么呢？我本人从事企业应用的设计，关注企业建模的的原
动力就是如何更好让信息系统具备足够的适应性和可重构性，以便支持企业不断的变化和辅助企业不断的变化。但是，我发现这
样很容易陷入“信息处理”的泥潭而无法从纷繁复杂的业务过程具体思维中超脱出来。我们可能考虑了如何用某种具体建模语言
去描绘业务，辅以精确的规则去MDA，甚至去达到直接可执行，但是这些内容所刻画的信息的抽象层次其实没有本质改变，倒是
枉费了很多思考的精力。在Together中你用UML去画了一个类图，这个类图和其载体、也即“代码”，其抽象层次是一样的，只
是表现形式不一样而已。为什么这么说呢，因为可执行的UML，还是可执行的代码其包含的需要人去决策的内容其实是一样多
的，无非效率有所改变，很多非决策内容都让机器替代完成了。

企业建模的目的其实倒是容易看清楚的，因为在某种意义上，企业建模的目的等效于任何建模的目的，都反映了模型“进一步简
化”和“促进交流和理解”的本质。但是，企业建模的范围却显得更需要我们去关心，因为它要求我们明确“研究什么？”。
“我们对什么建模？”，“究竟是企业的方方面面呢,还是限定于某些我们已经认识得比较清楚的、又有短期实现可能的方面，
比如工作流、信息流、资金流等等”。


以软件为背景的建模随着企业信息系统的应用深入而把“建模”的思想逐渐带进了企业，我们看到“企业建模”在目前得到了前
所未有的重视，这意味着“抽象”和“提取”正在被重视并积极推进，这无疑是令人欣喜的。但是，我个人并不认为这一切看起
来象余老师和林星那样乐观。企业是一个交错的多系统范畴，企业建模研究的深入体现在对这个大目标的细分，以及对细分的目
标排定其广泛应用意义上的优先研究级别。我们都知道，要完成对任何一个对象的建模，需要对这个对象有足够的了解，这个足
够的限定通常蕴意了我们在信息技术中经常使用的视图，我们总是从某些视图的角度去刻画对象。我本人感兴趣较多的可能是业
务建模。在业务建模中，通常会以“业务愿景”、“业务过程”，“业务结构”，“业务行为”四个通用视图来刻画业务。这四
个视图的划分代表了迈向可操作性的具体抽象。刚才说了，企业是一个交错的多系统范畴，企业建模需要从不同的视图去刻画，
而且大的视图中包括小的视图，小的视图还可以再分。应该说，什么时候完成了这个视图体系的框架，什么时候就能说我们对企
业建模有了很好的把握。至于采用什么符号，图形，文字来描述每个视图，是在计算机中还是其他媒介中描述每个视图这都是次
要的。当前的难题正是我们对这个视图框架轮廓还不是很清晰，抽象还未到位。

未来之路有理由相信会通向更美好的地方，但是这条路需要勇者步履艰辛去探索。这样的勇者不仅需要非常广泛的知识面，更重
要的是具备高超的分析能力和抽象能力。

　　李先生这句“……陷入‘信息处理’的泥潭而无法从纷繁复杂的业务过程具体思维中超脱出来”正表达出问题的关键。

　　这个问题也是引发我反思“信息系统是什么”、“功能是什么”乃至“软件是什么”这样一些根本问题的一些切入点之一。
进一步展开这个话题就跑得太远了。但由此可以引出“乐观”的理由：超脱出来，避繁就简。这是一个简单的道理：不是去捕捉
现象，而是捕捉产生这些现象的根源、方法或规律。

　　李先生还道出了另一个关键：“……这个类图和其载体、也即“代码”，其抽象层次是一样的，只是表现形式不一样而
已”。当然，UML是“建模语言”，假如UML都能够……比如直接生成代码——那么，它与传统的某个“解释的语言”有什么区
别？的确比许多人想象的小，只是语义丰富一些，抽象程度更接近日常概念一些，还有一个可能是结构维度上的区别。这就是我
在《复杂系统的层级原理与模型驱动软件体系结构》中所说的意思：UML是“紧贴”高级语言的。

　　所以，我们谈论的企业建模，应当是另一个层次上的事情，企业工程的层次。这就是我前面强调的层级错位。

　　确实有不少令我们可以乐观的理由，比如：

　　——现实中的大部分企业应用设计，正囿于复杂的漩涡中心执迷不悟，那是一个无底洞，谁能避开繁的表象抓住简的根本，
谁就有机会脱颖而出；
　　——模型驱动系统无论在理论上，实践上，都有足够的支持。据此我们可以在相当大的程度上将业务的复杂性隔离在模型之
后；
　　——企业的管理者和业务人员，确实“不清楚”他们对信息系统的需求，这里有许多简单但基本的需求被忽略，有一些简单
但基本的规律没有被运用；
　　——最重要的是观念的转折，而在软件实现上，伴随的常常是简化而不是复杂化；
　　——只要有部分的实现，就可以获得明显的好处。

　　另外，我想将建模看作“简化”是要小心的，更清楚地说是有目的的抽取。
　　范围反而不是一个问题，因为那是由具体产品的目标、定位决定的，例如你的目的是满足成本核算的需求，建模的范围当然
就是成本要素。

看到二位的讨论，感觉非常的不错。我们的讨论已经越来越深入了。

我非常同意李先生所说的这个类图和其载体、也即“代码”，其抽象层次是一样的，只是表现形式不一样而已”。这个其实道出
了目前IT技术发展的方向。很多年前，我们认为语言的傻瓜化、群众化是IT的发展方向，事实表明，并非如此。全球化和竞争加
剧的影响，社会资源倾向于更有的配置，这些外部的因素都使得软件要解决的问题变得更加的复杂，使得社会要求软件行业向着
一个真正的工程型的行业迈进。因此，虽然bit0和bit1的抽象能力已经足够好，足够描述一切的事物了，但是我们发现那种抽
象，针对的使用者太少了，因此，我们有了机器语言、有了汇编、有了3GL、4GL。后来，我们发现，语言需要冲破技术人员，走
向业务人员。所以UML迈出了一大步。但还不够，我们还需要再往前走。

李先生提到的乐观的问题。我也在不断的反思当中，是不是忽略了什么？是不是遗漏了什么？企业系统是一个高度复杂的系统，
就像我们永远无法认知股市的涨落一样。因为这是一个博弈产生的结果（经济学的理论，我们都知道著名的囚犯困境问题）。企
业工程的成就绝对无法超越人们对企业的理解，别指望计算机能够帮助我们做事情。计算机只能够帮助我们更好的做事，但无法
替代人。但是，我深信大道至简的哲理。真正在进行企业建模的时候，我们很多时候是想过头了。例如，IBM在金融领域赫赫有
名的模型解决方案－IFW。其核心不过是数据模型、功能模型、以及流程模型三种。非常的简单，但是涉及了金融行业的所有信
息。因此，我同意余先生的意见，对于企业工程，我们只需要进步一点点，就已经是很大的成就了。

同时，软件实现更多的时候，需要的是简化，而不是更加的复杂。这一点，我也是相当认同的。这对于我们研究方向的确定，是
非常有意义的。这意味着，我们不用把主要精力放在实现企业模型和技术的转换上，而应该把眼光集中在企业的研究上。这就有
回到了我们上一个帖子中谈论的企业建模语言的问题。

李先生提出了一个常用的企业建模方法－在业务建模中，通常会以“业务愿景”、“业务过程”，“业务结构”，“业务行为”
四个通用视图来刻画业务。这个描述正是涉及到我们以何种方式来描述企业的问题，就是企业建模语言，或者说，我们如何表达
企业中的问题呢？这里我需要引出我们真正的主角－欧阳余山老师。欧阳老师关于指标体系的论述，提出了一个信息的变化和简
化的问题（下载区中可以下载）。很有参考价值。但是，一个企业，要如何才能够完整的表达出其所有的信息呢？

表达是一种人思维的表现方式。语言同样也是一种表现方式。但我们说表达的层次要比语言更深入一些。因为表达涉及的范围更
大，更广泛。因此，对表达的研究，比起语言的研究，要更加的贴近人的思维本质。

	表达既然是一种思维表现方式，那么，企业管理当然也离不开表达了。在欧阳先生的书中，举了一个企业指标体系
的例子，来说明表达的应用，非常的生动。指标来源于繁杂的操作性数据，指标的设计，本质上是简化的表达方式的运用。我非
常认可欧阳先生关于指标体系的两个观点：

	－企业信息语义经历了由“质”到“量”，再由“量”到“质”不断转换。

	－企业信息管理系统采用企业信息指标体系的描述方法，可以让指标体系与企业具体的组织结构和事务性活动相对
独立。

	事实上，正如欧阳先生所说的，企业是一个多目标的，多维度（这是我补充的）的高度复杂系统。因此，企业的表
达方式是很值得研究的。各种的管理理论，其实都是运用各种优秀的表达方式来描述企业或企业的某个方面。因此，研究企业问
题的表达，其实是很有意思的。那么，我们是否可以找到一种有效的表达方式来描述这个复杂系统呢。这就是我们研究的方向。

	但是其中遇到的问题也是相当多的。我们还是用指标来举例：

	指标和组织结构、事务活动是相对分离的。因此，管理者可以设计和改进指标体系，而不影响到底层的业务流程。
但是，这种关系并不是完全独立的。当指标需要细化的时候，也许会要求事务活动中需要收集更多的信息。因此，这里的动态变
化就会比较复杂。

	在企业中，指标体系是一个参考、规范化的体系，但只是企业系统的一部分。对于其它的部分，如何进行表达呢？
例如，流程、数据、计划、目标等等。

	那么，欧阳老师，根据您在表达上的研究，您认为企业系统，采用什么样的表达方式或表达体系会比较号呢？


	附：我对多维度的看法


	多维空间业务建模

	Multi Dimension Business Modeling


	企业的业务环境是非常复杂的，而随着全球化和商品经济的深入，这种复杂度将会与日俱增。而对付企业应用的复
杂性，则成为软件开发中最大的拦路虎。我们尝试着分析一个企业的业务环境，会发现业务的构成其实是多方面的。例如，我们
如何理解部门的划分呢？部门的一种划分方式是按照职能，什么是职能？职能是要完成一项业务所需要的各种能力，同时，它也
代表了业务的一种划分方式。

	销售部门和财务部门需要配合在一起才能够完成业务，它们分别代表了两种能力－处理业务和处理财务事务。这种
分工使得销售部门和财务部门从不同的角度来看待业务。销售部门是从帮助客户完成业务的角度来看待问题的，而财务部门是从
核算的角度来看待问题的。这是两个不同的维度。企业的业务流程中存在各种各样的维度，维度构成了业务，而业务的发展使得
新的维度将会出现。例如，在业务处理中，可能出现法律审查、风险控制等维度。但是这些维度的目的都是类似的－完成业务，
赚取利润。

我怀着极大的兴趣看了前面的帖子，我和余彤鹰先生也有交流。你们的探讨水平很高，知识深厚，眼界和思想开阔。你们能够在
具体的软件工程实践中，关注一般表达的理论问题，这让我感到非常亲切和钦佩。当一般人还沉湎于技术细节不能自拔的时候，
你们却显示了游刃有余的能力。立足解决实际问题，又不就事论事，这是鉴别一个人是不是真有理论素质的试金石。所以，你们
的感悟非常宝贵，真正有价值的理论创新都是来自实际问题的启发和提升。

如林星先生所说：“各种的管理理论，其实都是运用各种优秀的表达方式来描述企业或企业的某个方面。”企业表达方式的研
究，这本身就是一个大题目。我在这方面的一点感悟，也只是九牛一毛。所以我无法一般回答对企业应该用哪一种表达方法更
好。但我觉的，凭借企业表达方式这个问题背景，可以使很多表达理论的探讨有的放矢，这个背景也能给我们带来灵感，让我们
的理论得到检验，总之，这是研究问题的一个非常好的角度，能挖掘到很多有价值的论题：

企业描述的定性（质）语言和定量语言，

信息的质量变换究竟是如何进行的？

信息简化是如何实现的？

如何来表达一个频繁变动的对象？

如何进行抽象分层？相对的独立性如何，它的依据是什么？

这些问题无论对表达理论还是企业信息系统，都是很有价值的。我注意到你们对ISO标准语言性质的评价，我深受启发，这是一
个很好的语言样本，标准的通用性基于语言的抽象性，才能概括和应用于不同的企业活动。你们都是悟性很高的人。所以，与其
一般的研究“抽象是如何可能的？”这种哲学问题，不如讨论标准语言是如何完成通用化的，企业的描述是如何从定性到定量
的？我个人以为，把问题具体化更容易有收获，从中获得灵感。

表达的确比语言更宽泛。一般地说，没有离开语言表达的纯客观对象，所谓哲学的语言学转向就是这种观点。但事实上，在没有
相应语言的情况下，我们仍然需要表达。这是表达最微妙的地方，也是最需要技巧的地方。我在“间接表达”一章给出了一些案
例，甚至提出间接表达的界限就是符号表达的界限，或者就是表达的界限。我一时给不出企业方面的例子，但我觉的这是应该充
分注意的一个问题。

关于多维度空间的思想，林星先生想的很深也很好。企业管理理论中有所谓不同的中心：成本中心，利润中心，生产中心，他们
思考问题的角度不同，对同一事务的价值评价就不同。所以，“多目标”是产生多维度的一个原因。关于组织维度的生长问题，
可以借鉴一些组织成长的理论，比如金观涛（1987）的《整体的哲学》，对组织的生长和组织功能的异化就有很好的论述，叙述
通俗易懂。

　　欢迎欧阳先生！欧阳余山先生除了表达理论的研究，也曾经多年从事企业管理软件的开发工作，《表达》一书中相关内容，
我一直都在思考，如何具体地连接、运用到目前研究的课题中去。

　　模型就是对特定对象的一种表达，它不是简单的信息，而是一个机结合的信息集合。从表达研究来说，企业模型或软件设计
模型都是一种可研究的对象吧，它们是有特定目的的复杂表达，其规范性在某些方面甚至超过科学表述。

　　欧阳先生说得很对：应当把问题引向具体化。我一直坚持着具体化的努力，只是还没有找到机会。而理论研究所需的硬条件
有限，只要自己愿意牺牲，投入精力，就可以进行。

　　我有从产品到体系结构的完整设计方案，而且有多种方案，也曾经进入到代码编写，可惜至今我没有能够创造出条件或机会
启动具体的产品研发计划。

　　理论方面的探究我几乎没有发表过，此次林星以他的激情，发起这个讨论，我也趁此机会将多年研究的一些东西稍微全面地
叙述一下。

　　更具体的东西，就是立刻可以着手做的，就是软件产品和模型方案。比如，企业模型已经公认的几个视图或子模型，就是所
谓数据及/或信息，功能，过程，组织，资源等，对这些东西我都有一些具体的研究。当然不能说已经成熟，但我的研究是可操
作的。

　　这里讨论到的，主要是理论或背景。但对于李先生提出的乐观性问题，确实应当有一个比较完整清楚的说明。我一直认为这
也是寻找实际开发机会的一种基本的障碍，谁会相信你这种名不见经传、没有任何可炫耀背景的人能提出洋人都没有说的东西？
我对自己说，必须做出具体的东西来，很可惜，基于企业模型的开发、运作，是个别一两个人难以启动的。

　　在几年前，我也不敢肯定这个思路可以有多大的成就，敢肯定的就是自己在软件开发实践中已经部分验证的东西，使我确信
我的构思的可操作性和在企业哪里的效果都不是虚构：“至少能够解决一些企业应用的基础问题，而这些基础问题恰恰是当前的
各种大型管理软件所忽略的”，在这样的指导思想下我做了完整的产品设计方案包括商业计划。

　　但具体的开发计划无法进行。我唯有一边寻找机会，一边继续研究，为了增加说服力，在理论上的探索也就越来越深。所以
到今天，我的信心已经有了比较完整的基础：正如我前面说的，从哲学、数学、系统理论到建模理论、软件体系结构，到许多具
体的、技术的实现方法，基本有了一个连贯的整体的东西。这里的讨论是启发性的，我个人也希望能够给关注的人看到一个稍微
完整、有说服力的思路。

深谈起来，才发现余先生和我有着如此多的共同点，其实我相信李先生也有同感。不过李先生目前在金蝶的资源应该更加的丰富
一些，所作的工作更加贴近于技术层面。事实上，在实现方面的努力我也正在进行之中。在前面的帖子中，余先生提到了一个很
重要的话题－企业建模是谁的职责？是技术人员吗？我觉得不是。企业建模，当然应该是对企业最了解的人来做，可能是企业的
管理者，可能是专业的企业结构设计者，可能是咨询顾问，可能是软件公司的业务分析者。但无论如何，这个人都需要对企业运
作非常的熟络，才可能运用企业建模的理论和工具，来构建一个优秀的信息系统。这方面也许是对现有的IT届的一个很大的改
变，但这个变化已经是在潜移默化中，越快的认识到这一点，越能够在竞争中处于优势。

不过，现实中的确存在尴尬的情况。国人对外国的概念趋之若鹜，但却少有勇气自己提出概念来的。国外的IT已经形成了体系，
他们的技术人员所作的研究，都无法离开自己公司在这个体系中所扮演的位置。就像一个公司大了，政治的东西变多了，竞争力
反而下降了。但中国目前的IT业，其实是正当乱世，没有国外的这么多的束缚。但乱世是否能出英雄呢？也许可以，也许不行，
这要看我们的努力。

但是，企业工程这个目标的实现，决不是一件轻松的事情。凭借个人的天分，可能可以在理论或是技术层面获得一些成绩。但如
何把这个成绩推广到能够影响社会的程度。则需要更多优秀的人，更多志同道合的人。因此，企业工程真正的难点，是在运作。
而不是在理论或是技术。

余先生提到“从哲学、数学、系统理论到建模理论、软件体系结构，到许多具体的、技术的实现方法”。这个思路是非常正确
的。要完善企业工程，需要基础理论的支撑，需要管理理论的支撑，需要企业工程理论的完善，需要技术理论的帮助，以及各种
各样的技术。范围是如此的大，凭借个人的力量，是很难有成果的。在中国从事企业工程，并希望从中获利的人不在少数，但往
往是因为缺少大开大阖的运作，闭门造车，使得成就相对有限。

　　林先生说的是实话。一门焦点领域上的应用科学，难点不在于理论或技术，反而在“运作”（这是多么精彩的一个时代符
号），大家不妨仔细品味一下，不管怎么想，这是现实。不过再怎么现实，新东西并不是靠勇气提出来的。

　　学问本来就是一种不现实的东西。前些日子和欧阳先生交流，他还提起钱钟书前辈的话：“大抵学问是荒江野老屋中二三素
心人商量培养之事。”这句话让所有做过一点点学问的中国人都唏嘘不已。其实，这何尝不是中国不能产生自然科学、工程科学
的一个注脚。

　　话题扯远了。运作不是我所擅长的，更无从讨论。所以我还是谈谈企业工程本身，谈技术，谈做事。

　　关于企业建模的参与者，可能我前面没有说清楚。在“企业工程”这个话题下讨论企业建模的问题，本身就已经是一种暗
示。迄今为止，关心企业建模的主要是两种典型角色（或做或用），一种是CIMS的专家，一种是软件设计者。对于一些体现了新
思想的部分支持动态或个性化建模的应用系统，实施咨询者和应用企业内部的实施者会进行建模。但成熟、有效的企业建模，应
当是由企业内部的职业化人士（企业工程师）负责，所建立的模型，第一用户是企业自身的管理、业务人员。

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

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

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

当企业建模真正在企业中得到充分的应用的时候，企业建模的角色才能够被清除的看到，这是我的一个看法。

角色是工作责任的抽象表示，它总是伴随着不同的工作责任来考虑的。采用企业建模之后，企业中的工作内容
都变化了，角色自然也就变化了。当然，在此之前，我们可以根据我们对企业工程的前瞻性理解，来划分一下角色。
写到这我觉得，其实要推广对企业工程的理解，我们可以通过勾画一组典型的工作视图，通过这组视图
来描绘采用企业建模的企业，它的运营、管理、操作。在这些工作视图中，涉及到角色，流程，工作模式，业务影响。


 

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

　　欧阳先生谈到几个话题，我谈一谈不成熟的看法：

企业描述的定性（质）语言和定量语言

——这个话题有个很有意思的地方，每当用到定性、定量的提法，就包含着一些程度区别的理解，比如：定量是精确的，定性是
不精确的；定量是更加科学严谨的，定性可能不那么严谨；定量相对困难，定性相对容易等等。而定量的前提就是找出变量，变
量就是所谓计数值的。这样一来，就把很多东西都排除到了严格的科学之外。比如，有企业管理方面的博士进行论文选题，很喜
欢选择“熵”的课题，加上一些系统论的东西，很容易弄出个方程式来，而且还不容易出“错”，显得有水平。


信息的质量变换究竟是如何进行的

——这个话题我理解上有些困惑，是质与量的变换吗？


信息简化是如何实现的

——不同的目的会有不同的简化方法，所以这个事情应当是用户自己根据需要做。当然，系统要提供这个能力，这样可以避开具
体的“简化”，却需要支持更深层的“简化机制”。我初步的想，所谓的建模“语言或方法”，就是一种预先确定的语义框架。


如何来表达一个频繁变动的对象

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


如何进行抽象分层？相对的独立性如何，它的依据是什么

——有对象的层次在抽象结果中的反映，也有抽象方式本身的层次问题。就抽象本身而言，最基本的（自然的层次）就是抽象结
果和被抽象对象之间造成的：对抽象的结果再抽象，就自然形成了另一层次上的抽象。在MDA体系中的元模型层次体系就是这样
一个分层体系。假设“模型”是当前层，则“元模型”就是当前层的抽象模型，元－元模型就是当前层抽象模型的抽象模型。是
否还有其他重要的（内在）的分层方法呢？

我在上一个帖子中所提到的企业建模的角色，是企业建模和模型使用过程上的角色，比如进行建模的人，阅读模型而理解企业的
人，使用模型构造其他的——比如应用软件的人，等等。

李先生此贴所说的角色就是企业模型的一个基本“要素”，大致对应着企业管理中“职位、职务”这样的概念。

李先生所说建立工作视图，正是现有的各种企业建模框架或体系最基本的内容之一，我前面提到的，企业模型已经公认的几个视
图或子模型，就是所谓数据及/或信息，功能，过程，组织，资源等，这方面似乎并没有太多新东西提出来，而且也缺乏更多
“具体的东西”。所谓的“工作流”是在传统企业建模研究圈子之外“异军突起”冲出来的。我个人体会，一个重要也是关键的
难点是“业务规则”模型的建立，这方面似乎缺乏真正的突破。

可以想见这样一个情景，傍晚的一次高层经理会议上，对新的企业架构，人员、关键业务的分工、流程等等做了新的分派，他们
在大屏幕上直接调整图形、文字组成的组织结构图、流程图等等。第二天，员工打开电脑，发现自己归属的部门、可访问的资
源、业务关系等等已经按照新的安排改变了……

我深为余先生的描述所感动，事实上，余先生说出了在我脑海中的一副美景。所见即所得的企业工程，最终是会实现的，企业工
程工具将成为标准的企业配置，他是企业管理者思维的延生，帮助企业管理者贯彻管理的理念。因此，余先生的看法是正确的，
企业工程工具是由企业的管理者来使用的，而不是其他人。不过我认为，管理顾问也会在其中扮演角色，他的性质和现在不会有
太大的变化，只不过，顾问和企业管理者的沟通是直接通过企业工程工具来进行的。

了解了这个美好的愿景，我对余先生提的两个问题谈一些看法：

一、现有建模方法、工具设计就不是针对企业中人的；
深表赞同。UML在设计的时候，本希望能够设计出一个业务人员能够理解的东西，但最终实现了吗？至少我没有见过这样的业务
人员。

二、缺少支持动态应用企业模型的系统。
动态是非常重要的特性，没有这个特性，演化的目标就难以达成。动态设计的难点在于能够将变化纳入到系统的考虑中。例如，
数据的变化、规则的变化，如何在系统中平滑的实现。

谈到了这里，我也说说我对企业模型的看法。我无法给出一个完整的企业模型实现的步骤，但是我认为有一项技术在企业建模中
非常关键的。这项技术就是对现有信息进行规划。这项技术被称为IRP－信息资源规划。

关于IRP的详细描述，请参看以下的网址：

http://www.amteam.org/docs/BDDocument.asp?Action=View&ID={F56A2323-E307-4E25-9232-FFF3CA1FBA04}
&ReturnTo=BDSearch%2Easp
http://www.irp.cn/index.jsp

这里我并不评述IRP。但是IRP反映了信息的一些问题：
1、信息是一种资产，需要进行管理。
2、需要有一种有效的方式来描述信息，这种方式就是元数据
3、信息的规范化，信息结构的规范化是企业模型的基础。

第一和第三个问题属于我们的认识问题。这里说说第二个问题。信息的元数据是什么呢？或者简单的说，我们如何描述信息呢？
信息其实是一种知识的表示。信息之间应该能够组成有意义（语义）的网络（空间）。我们从现实世界中大致上可以推导出信息
大致需要的内容：
概念（Concept）
概念之间的关系（Relation）
实例（Instance）
属性（Property）
在我们的思维中，我们习惯把一组有共同特征的实例描述为一种抽象的概念，例如，马就是一种概念。但是，并不是一开始就有
马的概念的。而是人们看到了第一只马，第二只马，然后发现他们的共同点，给具有同样特征的这些动物命名为马的。在OO中，
第一只马是马的一个实例。因此我们发现，概念是实例的集合。
同样的，动物的概念也是在有了马，有了鸟，之后才形成的。在OO中，我们认为马是动物的子类，这说明了概念和概念之间存在
关系。第一只马属于马这个集合，同样，也属于动物这个集合。这说明，新的概念可能是通过集合的运算得出的。动物这个概念
是通过马、鸟等概念通过并集运算得到的。
实例之所有能够形成概念，是因为他们之间存在共同的特征，这种特征就用属性来描述。因此，概念定义了这些共同的属性，然
后实例在这些属性上放置一些具体的值。
这就是信息的完整描述了。看起来和OO差不多。但还是有一些区别的。OO是语言，信息的应用范围要更加的广泛，而且，这里并
没有涉及到OO的操作。
这种信息的表示法其实已经有成熟的应用了。在W3C的RDF和OWL中，就采用了这种表示法。

　　欧阳先生提供了一个精彩说明，关于“信息的质量转化”等前面提到的几个问题，核心是语义框架。我觉得这是他很独到的
一些思考，涉及信息语义处理这个信息技术的尖端，我觉得值得专门讨论，所以将它放在信息系统栏了，拟做专题讨论，请各位
留意。

　　接着林星上一篇帖子的话说，

　　一、前面我描述了一个简单而基本的图景。对于小企业说，也许所有的企业蓝图，就通过那样的方式，在若干个夜晚就完成
了。但对于一个稍微大的企业，比如在最高管理层下有三个左右的组织层次，几百个互相关联、或包含的组织，以及跨越这些组
织的各种业务过程，在那样的会议上，能够讨论的就只会是原则、少数关键机构、环节。是否可以自顶向下做任务分解，各部门
自己规划？只有范围明确于分支内部的问题可以。但能够真正“割裂开”规划的东西很少。此时，“企业工程”——系统的知
识、方法、工具以及职业化的企业工程师的作用或需求，就涌现出来了。

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

　　二、关于林星“信息的元数据是什么呢？或者简单的说，我们如何描述信息呢？”后面的讨论，开始接触到一些实质话题。

　　1）“信息是知识的表示”这种概念用法，可能会有人反对。常见的用法是三个递进的层次：数据、信息、知识。知识表示
是所谓人工智能领域的基本课题，它的确和我们研究的建模有着内在的必然的关系。
　　2）“信息之间应该能够组成有意义（语义）的网络（空间）”，我对这个问题的回答是“信息空间理论”，我认为已经初
步找到了一个基于数学模型的信息空间理论框架的可能途径。
　　3）林先生发现了一些关键的“蛛丝马迹”。包括与OO差不多的特征、W3C的RDF和OWL采用了这种表示法等等，还有进一步的
结论吧？
　　4）其中涉及的IRM，是我也曾长期留意的，因为深入、涉及整个信息系统的基础架构或策略问题，同样在信息系统栏做另一
个专题讨论，随后就到，请留意。

（将一些话题转出是否有打断思路之嫌？愿听大家意见，我是想这样处理对关键问题的讨论、阅读更方便）

　　简化这个词多次出现，我对简化这个词的使用是有一点担忧的：

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

　　所以“简化”对建模是一个不好的、表面化的形容词。

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

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

非常同意余老师关于“简化”的进一步注解。这也是我为什么对“进一步简化”打上引号的原因。

其实，我一直怀着一个担心，害怕大家总是从宏观上谈企业工程，而忘记了把讨论深化落实到具体的
实现，这才是真正有价值的地方。当然，我这里指的实现也是有层次的，并非一开始就从信息系统角度去
考虑。我一直强调范围很重要，就是因为一旦落到具体实现，我们必定需要先圈定建模的范围，然后在这
个范围里通过层次，多种视图来表达企业建模。我同意余先生对于建模范围的解释，“企业建模的范围，
就是依赖于具体的、应用目的确定的”。但是，我建议我们不妨就选定一个“具体的应用目的”，比如
“多组织架构”，来描述企业建模，以这样一点的深度带动面的理解的升华，这样我们才能贯穿整个企业
工程的真正难点。很多问题，如果不具体以实例去分析，很容易成就我们思维的盲点。


前面我也谈到了“工作视图”，可能是我表述的问题，我原想表达的并非业务建模中的视图。而是从一个
外部的角度，像参观一样，来观察采用了“企业建模”的企业其内部运营的工作场景。当然，这也可谓中
模型视图，但是有别于一般高度抽象化了的“模型视图”，“工作视图”体现的是直观的场景图。

这种意义的“工作视图”其实就是余老师前面描绘的“一个简单而基本的图景”。但是，它的意义这是直观而
易于沟通的。这样的“工作视图”虽然类似于“科幻小说”，但是却是沟通上最能体现企业工程价值的工具。

同意，建议李先生将具体话题开一个头，另起一个主题贴如何？

愿望是很美好，但没有技术，可能最后只能是空谈

　　许多行内老手最后都认为，“管理软件最终做的是思想”，我也很同意这种看法；然而本人在探索中比较早期的重要认识之
一，就是许多困扰用户及实施者的问题，与现有系统的实现方式、采用的技术也有着深层次的关系，有些看似简单的想法不能实
现，包括许多被认为是销售的问题、客户的认识问题等，是有技术根源的；另一方面，软件和整个IT一样，迄今是一个技术主导
的行业，与缺乏具体的技术相比，缺乏能够真正理解用户的需求，提出独到的产品构思，鉴别和驾驭各种技术的人是更加常见和
难解的问题。

　　就探索多年的新一代企业信息系统这个话题，我认为它是革命性的，这种革命首先就是思想或者构思上的，一方面，具体的
实现技术甚至在大多数许多环节可以有多种选择，包括一些“过时”的技术；另一方面，新的体系也呼唤或将引导一些特定技术
的发展和出现。

初来乍到，请多包涵！
本人近来也在进行企业信息化中各类模型、方法的研究，发现现在的信息化系统开发，特别是对企业管理信息化系统的开发都走
入了一个怪圈——总是围绕着业务的执行层面、业务的功能层面进行各种调研和分析，总以能够在系统中为企业提供一套“科学
的管理模型”而奋斗。
企业是为了实现多个复杂的目标而存在的复杂系统，如果总是从企业业务层面来分析企业，不能对企业进行简化就无法构建出真
正的企业模型——“唯一不变的是变化”。
近来，本人尝试着从企业的基本构成层面来进行企业建模，并利用该模型在进行信息化实施过程当中进行应用获得较好的效果，
并准备尝试利用该模型构建新的信息化系统，希望能够得到各位先进的指教。
在本人的企业建模中，企业构成的三大基本元素为：组织、流程、资源；企业信息化系统的基本构成是：资源控制系统、流程管
理系统、组织管理系统三个核心系统，在加上知识情报系统、实时BI、关键指标管理系统构成基本系统。

没错，你很敏锐地提到了一些关键点：

　　你说：“发现现在的信息化系统开发，特别是对企业管理信息化系统的开发都走入了一个怪圈”
　　前面，李文华先生说“……陷入‘信息处理’的泥潭而无法从纷繁复杂的业务过程具体思维中超脱出来”
　　这都是有内在关联的、敏锐的思考。如前所述，这后面隐藏关键，也是导致我探讨、提出新一代企业信息系统、开展企业工
程研究等等的基本出发点之一。

　　对企业“基本层面的建模”，现有的各种企业建模框架或企业架构、通用企业参考模型，都应当加以了解和参考，组织、过
程、资源、的确是大家最常抽取出来的基本元素（或称视图等）。你可以到网络上搜速一下“企业建模”的中英文关键字，可以
得到不少相关的资料，相信对你的工作会有直接的帮助。这个栏目的其他帖子，我也介绍了若干有关的书。

企业建模的最终目的只有一个：提高企业运作的效率和效益?
在企业内做任何事情的目的都如此,这话等于我白说了.
企业建模和别的事情比又有什么不同呢?不同当然是如何实现这一目的途径上.
企业建模是通过发现企业运作中存在的问题和出现的机会来为提高企业运作的效率和效益服务的.
企业建模是如何发现企业运作中存在的问题和出现的机会的呢?
通过建立企业模型,用模型来仿真企业的运作来发现问题和机会,而非在企业实物上运作,以便降低风险和成本.
我觉得以上是企业建模的初衷.

企业建模为何与信息系统建设搭上岔?
提高行动效率和效益的基本手段是利用工具,这是智能动物的天性;
利用工具可以有效地解决问题和抓住更多的机会,
企业信息系统正好是现代企业必备的工具,
所以,企业建模便和企业信息系统建设息息相关了.

一些大白话，浅薄理解.

当信息系统发展到了它本身就成了企业的主要组成部分，这就已经超出了一般工具的作用范围；
企业模型的作用就不再是“离线”的仿真了，而是“在线”仿真了；
计算机信息系统就是一个实现了的企业实时在线仿真模型，它与企业已经“人剑合一”了。
这时，企业建模和计算机信息系统建模的分界线开始模糊。

即便如此，企业建模的目的似乎仍然不需要改变：
发现并解决企业运作机制中的问题，
发现并抓住企业运作中的机会，
降低以上两项活动的成本和风险，
提高以上两项活动的效率和效益。

企业模型，是企业实物的写照，实现一个企业模型的结果是得到一个可运作的企业——即使这个企业以计算机信息系统为主体。
计算机信息系统模型，是计算机信息系统的写照，实现一个计算机信息系统模型的结果，就是得到一个可运行的计算机信息系
统。
企业模型是以整个企业为研究对象，即使可以划分为业务层面，逻辑层面，数据层面，等等，依然是以整个企业为研究对象的。
计算机信息系统是企业的一个方面，计算机信息系统也可以划分为业务层面，逻辑层面，数据层面，等等，但它依然是以企业的
一个方面为研究对象的。
MDA中的M是什么？是“企业模型”吗？不是！只是计算机信息系统模型的业务层面而已！
MDS中的M是什么？是“企业模型”吗？请余老师来回答吧。

我的想法是这样的。MDS是一种功能系统的形态，如果纯粹从系统角度探讨，它并不局限于所谓的“计算机软件”。我认为它是
所谓“一般系统”中的一个比较高级的形态（如果喜欢，也可以用智能之类的词来形容）。

当然，计算机软件无疑是现在已知的人造复杂系统中，最适合、可能以MDS的方式实现的。因此MDS的M是什么，就在于这个系统
是干什么的。

当我们以MDS的形式实现企业应用系统时，M就是表达企业的模型。

这里已经有一个小小的跨步：需求描述模型到功能实现模型。

上面帖子中，邱嘉文先生这段话很精辟：

“当信息系统发展到了它本身就成了企业的主要组成部分，这就已经超出了一般工具的作用范围；
  企业模型的作用就不再是“离线”的仿真了，而是“在线”仿真了；
  计算机信息系统就是一个实现了的企业实时在线仿真模型，它与企业已经“人剑合一”了。
  这时，企业建模和计算机信息系统建模的分界线开始模糊。”

这大致也是我一直的思路。邱先生“人剑合一”这个比喻非常精彩！

关于“仿真模型”，其实我一直考虑它与我们大谈的企业模型，还有软件建模形成的模型等之间的关系。这里有些微妙的不同、
困惑和启发。因为仿真这个词已经具有非常多技术性的内涵，所以我不敢轻易地使用它。

从现实世界实际发生的情形上看，企业建模和计算机系统建模的分界线一开始就是模糊的。

上面的帖子中，邱嘉文先生对企业建模的目的有如下归纳：

“发现并解决企业运作机制中的问题，
  发现并抓住企业运作中的机会，
  降低以上两项活动的成本和风险，
  提高以上两项活动的效率和效益。”

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

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

我个人观察和理解的结果,对"企业建模和计算机系统建模的分界线"有一个"模糊-清晰-再模糊"的过程.
第一个"模糊"是指:开始大家只关心到在概念上认识到二者的联系,没有仔细分析他们的差异,这不利于认识二者本质差异,也就不
利于专项的发展;
然后"清晰"是指:大家已经对概念的差异有清晰的认识,能在各自的领域进行深入研究,并细化关联,不但不妨碍现实事物的交错并
存,反而促进这种交融更加密切和和谐.
然后"再模糊"是指:由于事物的发展使人工物的交错并存的交融更加密切,以致于将二者合为一体进行讨论反而更加方便.此时二
者概念的差异早已成为习以为常的共识.
关于以上这些我有一篇小文总结,想发给余先生请教,可能余先生的邮相受垃圾邮件侵扰太严重,我发给余先生的信又退了回来.
余先生的思想我大概也是从97-2000年间有过深入的实践,并有一定的成功经验,我可以和您以及本网站的网友一起分享.我一直希
望能有机会重整旗鼓,继续这份未尽事业,只是凡务缠身,还需要一段时间来清解.
我的邮件地址:babituo@hotmail.com,盼余先生赐信告知新的可用邮箱.

只是现在总体上或一般的认识，还在模糊中求索方向。
邮件箱不知你发的是那个，我已经发了mail给你，请留意。

读到宋兴烈《业务基础平台——黎明之前》一文（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吗？这不又回
到“面向对象”了吗？其中意味，大家慢慢咀嚼吧）。

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

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

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

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

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

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

想请教一下，利用UML建模与传统的分析系统方法相比较有哪些优点？不知道能否详细论述，请指教。多谢！

    余老师清晰的给我们勾画出了信息系统发展的趋势与未来（四层理论）：
   “ 1）形成书面叙述文件，交给软件开发者去进一步设计实现。
　　2）形成严谨的叙述文件，可能某种程度（部分）电脑可解释的，令其精确地限定整个开发过程和结果。
　　3）形成完全电脑可解释的模型，自动生成代码。
　　4）形成电脑可执行的模型，基于通用的平台，直接形成面对用户的“功能”。”
    我很赞成和支持您的论断，特别是论坛里“华山论剑”的气氛。因为有机会在你上文提到的JUSTEP公司工作过一段时间，作
为初来者，我想提出这样一个问题：对于信息系统的每一次进步（从第一层到第四层，当然现在只是在第二层和第三层之间），
是否考虑了每次“层”与“层”之间的这种进步而产生的关系或者叫遗留问题。
    我说的“关系”是指是每次技术的进步，都会或多或少留下一些遗留问题，类似于微软操作系统从“95～2003”的兼容类问
题。因为有这样一些问题的存在，在信息建设“保守派”就会因为利益问题而继续他们的保守，阻碍层基的进化。特别是在计算
机实现技术越“高级”系统约来越复杂的时候。
    第三层到第四层的转变，我想应该是具有革命性质的，而谈到“革命”必然是颠覆性的，在这种具有颠覆性的系统出现之
前，您是否有充足的准备来迎接对第三层的“兼容问题”，或者说叫集成。因为我们不可能是完全隔离这种“三”和“四”层之
间的关系。

   因为“信息孤岛”的存在，给企业信息化带来了沉重的负担和莫大的阻力。

  如果“信息集成”和“信息孤岛”问题（特别只在层级之间进化时）是另一个范畴，那我们到底该怎么班？

今夏虽然很热，可这里还是很冷啊：）

你说的这个进化层次之间的关系或遗留问题，是个好话题。我提出它们，更多的是从逻辑的角度。我想，它们的“向上兼容”问
题，不会像操作系统或其他软件那么强，因为它们是关于软件形成方法以及体现结构特征方面的比较层次，体现在产品上，通常
也会是不同公司开发的不同产品吧。

对于已经有许多现有应用的企业，上任何一个新的系统都遇到所谓遗产系统的问题，不管新的产品是“模型驱动开发的”还是比
较完整的“模型驱动系统”。

信息孤岛也同样，不仅发生在新旧产品之间，也发生在同时新引进的产品之间，并且也并不直接与其体系结构或开发方法挂钩。

毫无疑问，柔性的，或者说支持模型驱动的产品，在可集成性上（不管是与什么样的系统），大致都会更强吧。

   我本人是在学校中，并无企业经历，更多的在研究传统意义上的业务建模。
   您提到的业务模型的四个侧面，“愿景”、“业务”、“结构”、“行为”。在CIM-OSA、ARIS、GRAI等建模方法中并未
提及。我现做如下理解，不知对否。
   愿景可以理解为企业行为的目标。
   业务是各种建模方法都重点描述的侧面，各种过程视图、控制视图、功能视图或工作流视图都作了描述。
   行为可以理解为事件驱动并具有状态跟踪的企业业务。
   但是业务结构应描述什么内容呢？应该不是指组织视图和资源视图或产品视图描述的企业静态结构吧！它所描述的内容
应包含些什么呢？

说“业务结构描述什么”，不如说“用什么描述业务结构”吧？

感谢余老师的提点。
我现在所研究的内容的一部分是构建企业业务构件以支持软构件装配。但是遗憾的是我既非CIMS（欧洲的学者现在更喜欢用
ESA）专家，也不是系统开发人员。
我的想法是分别利用模型描述企业业务和软件系统业务，并建立同层次的分解。利用功能维系业务构件和软构件的映射关系。
软件流程中描述的最低粒度应该是由按钮出发，描述所触发的消息，以及这个消息影响的数据库操作，执行函数、判断等形成的
流程。这个流程描述的范围应该是这个界面上的按钮的功能覆盖的。一个ERP界面通常包含数个按钮。从软构件重用的角度说来
相对于一幅ERP界面，当然是以按钮功能划分软构件来得划算。（从系统开发人员角度）

从企业人员的角度来看，事情可能就不一样了。理论上来说，对于库存领域可能就有通用的构件划分方式（据说国内的ERP厂商
就提供了这种划分，谁能否提供这种划分的相关资料给我呢）。

那么如何统一这两种划分呢？这两种类型的建模人员应该如何协调呢？

这是一个好的思路。
我想，通过对实际的企业业务，和对软件架构、构件等更清楚、深入地认识，沿着这个思路能得到不少有益的结果。

不去真正地、深入实际地或者说直接地体验、考察真实的企业业务（它们往往显得混乱、随意、琐碎而不为工程技术人员或许多
理论研究者喜欢），而只是凭对组织、流程的想像，评管理教科书中的描述，是不大可能在上面帖子提到的研究思路或诉求上取
得深入或创新的结果的。

各位专家：
   
    我是做软件项目的具体工程师或者说设计者，我觉得企业建模其实是很普遍的事情，但做小软件根本不需要企业建模，只有
做大型的系统才需要。讨论企业建模很必要，但具体实施人员的看法可能与各位专家不同：
　　1）形成书面叙述文件，交给软件开发者去进一步设计实现。
         我个人认为这个问题在软件中属于需求描述的问题，或称之为需求开发。
　　2）形成严谨的叙述文件，可能某种程度（部分）电脑可解释的，令其精确地限定整个开发过程和结果。
         我个人认为该部分说明的是软件开发的管理过程，即怎么能够将需求变为用户想要的产品，目前CMM,CMMI,XP编程都是
用来指导这个层次的东西。
   
   3）形成完全电脑可解释的模型，自动生成代码。”
     这个属于设计工具范畴的，企业模型现阶段最终必须由计算机代码来执行，因此描述模型大概主要通过关系数据库或者或
者用面向对象技术来表达，成熟的企业建模工具很多，面向数据库方面的有PowerDesign ,ER win等软件工具，大概都出现10多
年了吧？面向对象的有rose 、viso等工具，因此这个层次的问题已经解决了。

4）形成电脑可执行的模型，基于通用的平台，直接形成面对用户的“功能”。
   如果说第三步已经达到了，那么第四个层次属于实施的问题而已。通过适当的人使用适当的计算机软件开发工具就可以完
成。         如果说第四个层次想要计算机自动完成，不用人来实施，这个属于计算机人工智能的范畴，和企业建模本无关系。
    各位专家，我们搞实施的人希望专家们能够在企业建模的另外的一个角度加以探讨，也就是做大规模管理信息系统中，到底
要关注企业中的那些元素？如何将这些元素抽象为计算机中的内容。比如：部门、岗位、参与者、资源、业务流程、系统、功能
到底之间有哪些关系？最好是能给出一些经典的企业建模模式。使得不同行业的企业在不断的信息化过程中节省以往的投资，避
免推倒重来。

我认为，企业建模所关注的是企业的目标，就是企业期待的目标。企业关注成本，那么这就是它的目标，所以业务过程建模描述
的因素至少都应该和成本有关，比如描述每个原材料消耗控制点等。刻画完这个面向成本最小化的模型之后，接下来，就要在模
型基础上做一些优化，比如考虑部门责任，可以通过重新划分部门责任降低管理成本。
所以，建模，无法面面俱到的描述企业的所有方面，大而全的模型等于没有模型。企业的目标才是建模的目的。

一点简洁，难免错误。