企业工程信息技术应用信息系统信息化企业建模模型驱动架构业务过程流程运作管理 IT

最新发表

深入讨论

邮件组/论坛：企业工程讨论组快速留言：BBS 订阅：

需求分析的三重境界

　　层次1. 客观描述与记录（objective description and record）——忠实、精确、全面地搜集与记录客户的需求或相关的业务、数据；
　　层次2. 模式归纳与发现（patterns induction and discovery)——按照一定的建模方法论及框架或架构进行归纳、建模，并尽量揭示在包含在快照式的客观记述中并非显而易见的模式或规律；
　　层次3. 模式分析与创新（patterns analysis and innovation）——在现存模式的基础上总结不同模式背后隐含的规律，研究应用对需求的异化作用，发掘深层次规律，预测需求变化，揭示新的工作（业务）方式，创建新的、有价值的模式。

实质性需求分析与研究（ERAR）

　　在新技术应用的领域，需求是一种处于进化中的客观事物，它具有自身的演变规律、生命周期和生存环境。……“满足用户需求”不仅仅是一个“发现-解决”的过程，还是一个“研习-创造”的过程。我们必须对影响需求产生与变化的各种因素及其变化规律进行全面综合的研究。其目标是揭示和总结各种隐蔽的、可能的或未来将要出现的需求，及其需求进化规律，提出或创造新的方案或模式。这一思想，是在软件工程领域传统的需求分析基础上提出的，是一种自然的深化和升华，因此，我们采用与传统、习惯的称呼对应的表达方式，称其为“实质性需求分析与研究”（Essential Requirements Analysis and Research, ERAR，也可简称为需求研究）。目前，我们将其看作“一个指导方针和方法论框架”。它并不限于软件领域，同样适合于任何产品或服务的设计，特别是创新。我们相信通过进一步发展和充实，它可能连同RA或需求工程形成一个更强健的、多层次的方法论体系。

ERAR对NEIS的意义

　　对NEIS，ERAR是变“技术导向，概念驱动”为“需求导向，技术驱动”的关键。它是我们将MDM/MDS看作需求与实现两者的关键的背景。ERAR将一直是NEIS开发与研究的重要基础。

模型驱动机制(MDM)

　　模型驱动机制（Model-Driven Mechanism, MDM）是实现与控制系统（或其功能与行为）的一种方式或途径，即，基于模型运行、实现或控制被建模的、预期的事物——系统或功能及行为，该模型具有独立性，独立于表达、储存、传送、达成或实现的过程或方法。简言之，MDM使系统的全部或部分功能及行为（或结构及形态）受到模型的控制或支配。

模型驱动系统(MDS)

　　若一个系统的全部功能与行为都能通过MDM实时地定义、控制和改变，则它是一个“充分的”模型驱动系统（Model-Driven System, MDS）。简言之，MDS就是以MDM控制或实现其主要功能的系统。
　　通过导入MDM，就能在一个更统一基本层次上理解、区分模型驱动架构（Model-Driven Architecture, MDA）与我提出的MDS。

MDS对NEIS的意义

　　——MDS为NEIS的核心。由于用户需求的不确定性、幼稚性和其生命周期与应用过程的关系，EIS应该有在运行期持续、动态地适应与改变的能力，这是无法回避的根本需求。
　　——NEIS需要支持EE。简言之，需要实时、动态、企业模型驱动(enterprise-model-driven, EMD)。EE、企业建模和NEIS的关系是导致对MDS需要的内在因素之一。
　　——在EIS和企业模型间存在一种对应或转换。它是实现NEIS为EMDS——企业模型驱动系统的关键。倘若果企业模型足够精确，由模型到可执行软件的编程过程可以自动进行，我们又为什么不将它变成企业平台的能力，达成最佳的应用模式？
　　——也许并非所有的企业应用都可以或适合于以MDS方式实现，但EIS或基于信息系统的应用可能正是最适合的类型之一。

模型驱动开发（MDD）模型驱动系统（MDS）与新一代企业信息系统（NEIS）

　　仅凭MDD，需求的改变仍然需要通过开发者的建模、编码（转换）过程。因为这并未真正将“应用开发者”和“企业规划者”的工作领域分开，仍将遭遇基于编码的定制或开发同样的问题。也就是说，仅凭MDD，我们并不能摆脱在传统的开发或定制中遭遇的困境，不能充分地满足NEIS的需求。

企业工程(EE)企业建模与新一代企业信息系统的关系

　　EE的发展，应该极可能与企业建模和其支撑平台紧密联系起来，并且与企业的业务平台结合在一起。这样，也就确立了EE与NEIS之间互相依赖、互相促进的伴生关系。没有企业建模，就没有真正意义上的EE。而即使具备了企业建模、规划的工具，还必须有整套的企业设计、规划、改造原则与方法论才能真正发挥其作用。后者的来源，正是我们希望建立的企业工程学科或知识、方法论体系。
　　简言之，我们既不将EE看作是信息技术企业应用的附属品，同样也不将企业建模仅仅看作是建立EIS的一种手段。企业建模是连接EE与EIS的桥梁。最大限度地实现对二者的共同支持，是企业建模理想、但合理的目标。它还将在应用中给用户带来巨大的益处。

基于企业工程看足够有效的企业建模手段应具备的特征

　　表达力（Expression ability）：能充分地表达整个企业——不仅包括信息或业务过程，还包括业务规则、组织、设备或资源及成本等各项构成要素；
　　适用性（Applicability）：这种表达应该能最大限度地为企业管理或业务人员（和/或企业工程师）理解，而无需掌握许多额外的知识或技巧（例如，关于软件开发的）；
　　精确性（Exactness）：作为一种工程体系的基础，它必须有足够精确性，并可被精确、严格地记录、修改、传递。
　　与应用系统的集成（Integration with application system）：EE建模的结果，应当可以直接体现在企业应用系统上，而不是再经过一个通常在第三方进行的、复杂的软件开发或修改过程。

英文版摘要：A Survey of New Generation of Enterprise Information System

企业工程(EE)

　　虽然企业作为一个系统，通常是“成长”，而不是装配出来的，但它仍是不折不扣的人造物。建造它，和管理它，纵然交织在一起，仍有经纬之别，或者说是成长过程的两个不同的侧面。现代企业由于其复杂性、规模性和迅速改变（还有迅速兴建），及其物理与逻辑实体的巨大和复杂，使“规划建造”不能总是躲藏在“管理”之后，由顶层决策者在“不知不觉”间完成。企业建设是企业成长的使动语态，对旧有的企业架构或业务不时需要进行重规划；对新的企业和业务，要进行精密迅速的规划，这些正是企业工程的课题。（余彤鹰，企业工程是什么，1998年10月）

　　最初的专业组织美国的企业工程协会（Society for Enterprise Engineering, SEE）定义企业工程为“用于企业分析、设计、改进和运作的知识、理论与实践的整体”，其中心课题是“如何通过对工程和分析方法与工具的应用，设计和改进与整个企业相关的所有要素，以更有效地达成其目的与目标”（SEE, 1995）。简单地说，企业工程就是“关于如何设计、建设、维护与改造企业的综合学科”。（余彤鹰：企业工程的几种定义，2004年1月）

企业工程的四项愿景

　　１）独立通用的精确表述
　　用精确的、通用的、与实现方式与过程分离的表达方式（语言或模型）表述企业，并可将其用于阅读理解（直接或经过自动的转换）、分析、交流以及直接驱动企业平台（企业运做的基础平台，核心是信息系统平台），以此通用的表述方法记述个性化的业务模式以及业务模式的改进与变革方案。
　　２）系统的理论、规则和方法
　　形成系统的、可传授的企业原理、结构、动力、分析的理论、规则与方法，从而以可控制的方式实现企业的规划设计、实施（包括新建与变革），大幅度地降低企业规划建设的随意性，提高有效性以及企业的表现。
　　３）专业化
　　掌握了企业工程知识的人，能够职业化地、迅速地理解和处理各种类型企业的规划、建设、变革的问题，企业建设与变革成为一种职业，而不仅仅是一种凭借可遇而不可求的特殊人物的天才与直觉的艺术。
　　４）有效的工具
　　借助各种有效的工具进行企业的需求分析、规划、建模，工具的使用技巧主要与工作（业务）性质相关，而无须掌握大量额外的知识与技巧，比如程序编制的原理和技巧。
　　（余彤鹰，显现中的企业工程，北京2001企业工程研讨会，2001年12月）

业务工程和企业工程

　　业务工程作为一个独立的概念是怎样来的，我没考证过。有一个基本的例子是值得关注的，这就是德国Scheer教授的ARIS和相关的业务工程。
　　ARIS是一个面向业务过程的模型框架和建模方法体系，已有十余年历史，迄今获得了广泛的应用和承认，代表了这个领域的世界先进水平。它可以成为我们工作的比对基准（benchmarking）。
　　根据ARIS开发者的表述，业务过程工程可以理解为面向过程的企业工程（process oriented enterprise engineering）， ARIS提供了模型和方法体系，还有相应的工具（软件）。
　　下面的简单比对，有助于印证和理解我的研究思路：

Prof. Scheer: business process framework (model) & modeling methodology
              => procdures, mothods, tools and
                 model supported application system development
              => ARIS model based business engineering
              - process oriented enterprise engineering

EE-Forum    : enterprise model & modeling representations, methodology
              => procdures, mothods, modeling tools and
                 model-driven enterprise information system
              => enterprise model (EM) based enterprise engineering

（余彤鹰，业务工程和企业工程，2004年9月）

企业信息系统

　　“企业信息系统”（Enterprise Information System, EIS）不仅包括可运行的设备和软件，也包括相关的技术资源，其主体是直接用于企业各种事务的逻辑及物理实体，并可以延伸到诸如自动化生产加工、检测设备中去。从企业形态的角度，将全面基于企业信息系统运做的企业称为电脑化企业（cyber-enterprise）。未来的企业信息系统，需满足快速变化的、个性化的用户需求，对企业内部与外部关系的各项需求提供全方位的支持，具有通用平台/执行系统寄生结构，模型驱动，用户主导的系统生命周期，基于企业建模技术等新一代技术与标准。信息技术，是营造国家竞争优势的战略工具，关乎未来中国国民经济的命脉，绝对不能被他人所垄断。应当以造原子弹的精神，以“三峡工程”的魄力去抓企业信息系统的基础工程。（余彤鹰，未来的企业信息技术应用，1999年1月）

软件与企业模型的几个关键问题

　　以下特征对软件体系中模型的运用是十分重要，或者有特殊意义的：
　　模型的时效性（time-effectiveness of model）：关于这一点最重要的区分在于，是“运行期模型”（Run-Time Model），还是开发期模型？这个区别，有点类似于解释的语言和编译的语言间的区别，但其意义却非同一般，“运行期模型”，揭示了模型驱动的本质。
　　模型的可进化性（evolutionableness of model）：是否可以在系统的应用过程中，持续地适应应用环境与需求的变化，不断地由应用者或自适应地对模型进行改进？这是对模型“性能”的一种度量。
　　模型的层级性（hierarchy of model）：正如语言有多个层次一样，没有理由认为模型只有一个层次，当系统足够复杂时，模型的层次划分将会是必要的。

　　运用上面的要素分析一下，可以发现：
　　UML是“紧贴”高级软件语言（例如C++）的模型体系，其时效是在软件生命周期的开发期间，而不是运行期间，其描述的层级是在软件的组件、对象一级，典型要素是软件中的对象，软件上一个操作的动作等。
　　企业模型（比如ARIS, CIM-OSA, GERAM），典型的要素是组织，产品，过程等，它们是从企业的业务对象着眼的。二者在层级上有差距，而且企业模型追求的最终结果，是从“开发期模型”到达“运行期模型”，并且，笔者认为它最终应当是一种可进化的模型，这与UML的设计目标并不符合。
　　它们两者间并不相互排斥，而应当考虑它们的“层接”。OMG的MDA即使全面实现，也仍然不能做为或替代企业模型，但有可能成为企业模型的基础，这不是模型好坏或能力的问题，而是层级定位的问题。

　　对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，“模型”是必须的，而且，表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。（余彤鹰，复杂系统的层级原理与模型驱动软件体系结构，2002年5月）

企业建模的目的

　　企业建模……目的大致可等同于企业模型的用途，这在实际应用中应当说是层出不穷的，但基本可归纳为三个方面：

　　1）表达企业设计（规划）包括再设计的结果，包括企业分析的结果；
　　2）用于企业建设与改造（再造），使人们能够精确地按照既定的设计建设或改造、维护企业。
　　3）供需要的人作为理解企业的工具或桥梁，包括分析、研究企业——过去的状态、当前的状态、可能的状态等。（余彤鹰，企业建模的目的、范围及“模型驱动系统”（MDS）,2004年8月）

从用户需求达成企业信息系统功能的四种途径

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

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

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

　　所谓直接驱动企业平台，要省略上述3）所保留的最后一点传统“编程”的手续，这种过渡在逻辑上是很自然的。（余彤鹰，企业建模的目的、范围及“模型驱动系统”（MDS）,2004年8月）

工作流（Workflow）与业务过程管理(Business Process Management, BPM)

　　这两者是很有争议的，区别也越来越细微，但有必要澄清。
　　工作流的概念产生得比业务过程管理早，它起源于办公室自动化，可以追溯到60年代底和70年代初。它强调业务过程的自动化，因此在不需太多人工干涉的业务过程上用得比较多。
　　业务过程管理的概念是在 Michael Hammer, James Champy， Tom Davenport, 和 H. James Harrington等一些人在90年代初提出的过程再造和改进等概念的基础上产生的，它强调过程，但不管是什么过程。
　　业务过程管理包括对业务过程的分析，计划，设计，实施，运行，监控，和仿真各个方面。相较于工作流，它更属于是管理和组织的概念；而工作流则侧重技术层面的实施和运行业务流程。从这种角度看，工作流可以说是业务流程管理的子集。……这两种系统的区别就在于工作流管理系统只能定义和运行业务过程，而业务过程管理系统还能监控运行的业务过程和分析评价业务过程的效能。
　　……工作流还会存在和发展，而工作流管理系统会成为业务过程管理系统的一个子系统，甚至会是核心系统。（金新明，工作流与业务过程管理）

说工作流（workflow）是过渡性的一些理由

　　对“业务过程”的支持是企业应用的重要、核心的功能，但这是在一个整体的企业解决方案（或称架构）基础上实现的功能之一。既往的、独立发展的工作流技术和实践，是一种可借鉴的预演，只能被消化吸收或借鉴。在这个意义上，它是一个过渡。这里提出几个理由：

　　1）Workflow是一个“计算机”的概念
　　2）Workflow太早熟、独立了
　　3）Workflow的商业背景
　　4）Workflow的先天不足

　　……当对整个企业需求和解决方案有了更完整的认识之后发现，要支持全面的业务过程（用户的），或者作为一个全面的业务过程解决方案，现有的工作流有些像一个早产儿。它本来就不是作为完整的“业务过程模型”提出的。从建模的角度说，对一个设计完整的建模架构为新的更大的目标升级，不如重新构建一个架构，将旧的架构作为一个借鉴。（余彤鹰，说工作流（workflow）是过渡性的一些理由，2005-04）

企业工程与信息化
Enterprise Engineering & Informatization

　企业工程、模型及信息系统
　企业工程浮出水面的时候到了吗？
　对话企业工程
　企业工程、业务工程与再造工程
　如何深入开拓企业工程
　关于企业工程的书
　李从东：集成化企业工程及其应用问题
　显现中的企业工程
　企业科学和企业工程学初探
　北京2001企业工程研讨会
　论文摘译
　企业工程发展追踪
　企业工程的几种定义
　企业工程是什么
　重规化是什么
　什么是企业集成
　企业生命周期
　过程中心观
　信息化概念与意义探究
　企业建模的目的、范围及模型驱动系统(MDS)
　