对yushan传统企业模型的技术倾向的讨论
TY
看到余彤鹰企业模型方面的新文章，十分欣喜。（内容见新发贴）
理清企业应用发展线索，既是对过去的总结，也是我们建立新模型的出发点，正如余先生所言：大的趋势应该是融合。在这里我想借题补充分析一
下，这种融合有机的，具有内在逻辑，而不应只是个拼盘。
在我看来，因为历史的原因，以往企业模型的主要问题太陷于技术：先是陷于计算机技术，比如从程序设计出发的模型，它的典型词汇是关系数据
库，数据流程图，功能菜单，状态图，时序图，类图，事件、对象、属性等等。它们显然不适合作为企业模型的描述语言，而是一种系统实现的内部语言。
后来又陷于企业需求分析的技术层面：ERP系统就是一个典型，它的最初核心是以BOM表为基础，核算生产能力，进行最优排产等。利用计算机
的计算能力，在技术上高人一筹。从信息加工深度出发，所谓事务处理，决策支持，直到知识管理和BI等等，都有这种技术倾向。要提供一个可以计算的平台，
所谓数据中心，数据平台，信息共享在很大程度上就是为了提供这种支持。它们解决的都是技术问题，并不是一个企业模型最重要的东西。
技术倾向的另一个表现就是自动化，何以能自动？计算机具有自动运算的能力嘛。这种意义下的企业模型就是一个算盘，这个算盘能记录、存储和计
算，还可以打印报表。它们提供是技术层面的文件记录，不是一种管理模型，它的信息语义单元是比较小的，零碎的，不适合作为企业模型的大构件。所以，功能
菜单比较适合这种信息单元。
还有一条道路，就是以管理程序为线索建立起企业模型。工作流为我们提供了技术上的支持，但是如果我们不是从管理出发来建构模型，工作流会又
沦为一个硬件，如操作系统一般。我们就仍然不会有进步。必须把事件、互交图之类的转换为企业管理
语言。企业关系管理具有重要意义，它指出了企业相关的人物关系，超出了技术层面，是互交图的企业需求分析语言，它在新模型中具有极其重要的意
义。在UML语言中，用例这个概念既涉及到管理程序也涉及到人物。但是，用例毕竟还是计算机设计人员的语言，还不是也不等于企业管理语言的界定对象，它
的许多层次是技术层面，太零碎，太细小。
在新的模型中，我们应该以传统的具有深厚渊源的企业管理语言来描述模型，它以流程的持续改进为基础，以协同关系而不是记录运算报表为己任。
它并不求在单项决策技术上达到最优，而求在管理流程上达到具有自我改造的能力。这个模型胜任从事务战术到企业战略的连续转换，因为它以管理为框架，将技
术有机融为一体。这才是企业模型的核心问题，同时也是我们模型最合适的信息构件。
--------------------------------------------------------
以上内容转自企业工程论坛老的讨论区（BBS），
http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=809
说明：
因为维护起来比较麻烦，功能不好，所以我不想将新的讨论转移到这个讨论组中来。
TY
yushan所说的这个问题，其实触及我一直在企业工程论坛或个人探索中围绕着的主要问题之一。
在《新一代企业信息系统：从实质性需求分析与研究到模型驱动系统》http://www.ee-forum.org/bbs/
bbsview2.asp?type=6&id=150那篇综述中，我概括为由"技术导向，概念驱动"为"需求导向，技术驱动"，用户导向"的问题。
在方法论的角度，我觉得也缺少一些东西，所以我提出一个"实质性需求分析或研究"。
从信息系统应用（支持）的技术角度，一个关键，在之前的几次大讨论中曾经提到过，就是业务模型与计算模型之间的连接或转换问题。总体上，就是"模型驱动
机制"的应用问题。更具体说，就是多大程度能够避免或减少"人工转换"。
刚刚回复的pvcgary的贴，也提到类似的问题。
注：yushan提到的"余彤鹰企业模型方面的新文章"
《企业应用发展线索分析》http://www.ee-forum.org/ty_070701a.html
On 7月28日, 上午1时29分, TY <tongying...@gmail.com> wrote:
> 标 题：传统企业模型的技术倾向 yushan 2007-07-22 09:14:51
>
> 看到余彤鹰企业模型方面的新文章......
Lee
企业模型是什么样子取决于从哪个视角建模、关注什么、目标是什么、...
然后才是技术：借鉴哪些建模技术、摒弃哪些方法的不足、采用什么手段描述。
如果建模者要表达的思想完全可以用UML、EPCs、GRAI等或它们的集成能表示，那就用也无所谓，何必再去发明创造呢。
重要的是对建模对象的理解！
> > 看到余彤鹰企业模型方面的新文章......- 隐藏被引用文字 -
>
> - 显示引用的文字 -
TY
模型或逻辑模型）的区别或关系问题，是在基于模型/建模的深层实践中才会遇到、体会到的。
可以去看一下MDA的领域，基本上是囿于计算模型的范围内。而相对传统的企业架构与模型，比如Lee提到的GRAI，则是属于一种上述的业务模
型。ARIS里面的事件驱动过程链（EPC），或整个的ARIS属于什么呢？值得仔细玩味。
这正是对建模对象的深层次理解提出的实质性问题：建模的对象到底是现实中的企业，还是计算机程序？信息系统是计算机程序吗？（我曾经在企业工程论坛发过
一个命题："信息系统就是信息系统，它不是一种软件"）UAM被许多人（其发明者也大致这么看）认为可以对世界任何东西建模，但它本来就是作为一个计算
模型的体系设计的。
如果说描述或表达的能力，自然语言足以描述和表达任何你想得到的东西，何必要发明建模语言呢？
Lee
业务模型的作用就在于此吧，业务模型的描述语言，对于企业人员来说必须是可理解的。
计算模型不具备这一特点，主要目标是为了实现。
所以业务模型和计算模型到底描述哪些东西，对同一东西各从什么角度描述，不要说建模人员，就算是发明建模方法的人也经常混淆。
我有幸和欧洲建模大师G.Dom.....教授工作过2周，他算是GRAI模型的创始人，他就曾指出过上述问题。
不过遗憾的是，我对他带有严重口音的英语始终就没能适应（他是法国人），交流的比较差。
业务模型致力于描述业务，不考虑计算机如何实现，是计算无关的。
计算模型致力于计算。
然后再考虑二者如何转换，
我想，总不能为了二者转换顺畅、方便而牺牲各自的建模宗旨吧。
说得有点前言不搭后语...
> > > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
TY
在企业工程论坛 http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=46
我曾经讨论过企业建模的目标或目的，在那里对于一般性目的提出如下概括：
1）表达企业设计（规划）包括再设计的结果，包括企业分析的结果；
2）用于企业建设与改造（再造），使人们能够精确地按照既定的设计建设或改造、维护企业。
3）供需要的人作为理解企业的工具或桥梁，包括分析、研究企业--过去的状态、当前的状态、可能的状态等。
2002年MDA正式浮出后，更明确了另一个可操作的用途或目的：直接"驱动"开发过程，即"模型驱动开发"（MDD）。
我的切入点从一开始（1998年）就比这更进一步：直接"驱动"企业应用系统。在进一步的探索中，我发现，计算模型和业务模型的区别与联系，是一个很微
妙的，大家都没有解决的问题。对此，我在过去几年时间已经发现了一整套完整的理论和方案，我正在寻找适当的机会去做（或者适当的方式与时机发表）。
观察现在的工作，楼上提到的GRAI那些是一类经典的研究，主要讲的是"业务性质"的建模；UAM代表的这一路，是计算模型的路子，这两个路子怎么结
合，能否结合？
但还有第三势力其实更具启发性，就是workflow, BP这一路（ARIS有点另类，其实大致也可以归纳到这个路子）--这个路子的成功，很大程度
上就是因为它们在上述两类模型的或两类建模目的结合上"比较有料"。
Lee
我曾参与过以MDA为建模体系的课题，PIM层参与的多些，恰恰还是个计算层。
对于各层所描述的侧重以及它们之间的转化有点体会。
我觉得最不容易建模的就是CIM层模型，而CIM层到PIM层的转换业颇难。
PIM层建立的模型，包括数据模型、过程模型、角色模型以及用例等，描述的手段都已经是面向计算的了，比如采取程序语言中规定的算术运算符、逻辑运算法
以及关系运算法加以描述，所以相对容易。
PSM层次则跟具体要实现的开发工具相关了，对模型的描述往往夹杂着编程工具特有的语法特征。（这些书上好像也都讲过了）
CIM层建模困难，也容易理解，就象做软件系统那样，对用户需求的理解是最困难的。我想最重要的原因还是对企业了解的不够深刻吧。
至于CIM层到PIM层转换的困难之处，我想也是情理之中。本来，把业务需求在大脑中转换成计算机模型，也是软件开发最重要的一步。
CIM层到PIM层的转换，我所掌握的知识看，也是没有太好的方法。不过针对建模的对象不同，是否可以考虑在CIM层和PIM层之间增加一层或者多层来
达到转换的目的呢？
On 7月31日, 下午12时01分, TY <tongying...@gmail.com> wrote:
> 就是越讨论越清楚啊:-) 这些地方，恰恰就是我希望向前开拓的地方：
>
> 在企业工程论坛http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=46
TY
业务（性质）的模型，是有考虑的。例如：CIM本身其实就已经很暧昧了。 这个东西不弄清楚，其实也就无从去实质性地解决到计算模型的衔接（转换？映
射？）问题。再加一个层次，原则上是不必要的，加多少个中间层，都要完成这个变脸。就算能建立起一种"中介机构"完成这个转换（我认为这是笨方法，有点
像用加减法代替微积分），它也不应被并列为一个独立的模型层次。
前面我提到自己近年对这个问题的探索（抱歉暂时我不想公开讨论实际的方案），最基本的启发就是必须从根本上修改一些固有的观念。举一个例子：什么叫功能
（function），在企业建模领域现在大家已经认为是再基本不管的功能视图，这个function并非组织/企业中的那个function（职
能），也不是企业管理者的概念，那它到底是什么？探讨这个问题，无可避免地要问：软件是什么？信息系统是什么？
我们这几个回合讨论，看起来似乎没有正面回答yushan提出的问题。yushan所说"我们应该以传统的具有深厚渊源的企业管理语言来描述模型"（见
第一个贴），与这个方面在最终解决上是内在地关联着的。无疑， 这是与企业建模的目的有关，还是那句话，如果不是为了精确、可控制等需求，何必发明建模
语言，用自然语言不是更好？在今天我们研究企业建模，无疑是跟信息系统/企业应用紧密相连的。
yus...@gmail.com
什么是业务模型?我的体会是并不是业务人员懂就算业务模型,比如以报表出发建立的业务系统就不一定符合模型的要求。从完成某个单项技术出发的功能也不算
模型。比如一个ERP的生产均衡问题，综合许多因素来排产，它还是一个计算问题。
我以为，成为一个模型有两条，一个是形成体系，一个是要在业务上区分管理和技术问题。前者正是余彤鹰所强调的所谓形成一个信息系统，其它也是他所倡导的
企业工程要解决的问题。如何形成一个企业的信息系统，这有很大部分是管理科学解决的问题。而不是搞信息化这些人的强项。这就像问会计准则会计制度是什
么，那是会计学所擅长的。在企业信息系统的研究上，我们无法与会计学相比。会计学的理论是在算盘为工具的时候就建立的，而不是在计算机以后才建立的。后
者第二问题其实也是第一个问题，我们经常混淆一个企业的管理和技术，我们有这样的经验，这个企业有能人，某个技术很强，但是这个企业没有管理，再强的技
术也不是管理。因为只有管理才是形成体系的东西，技术只是单项，从企业工程的信息系统角度讲是无足轻重的。而以这个标准看我们的企业模型，有多少构成了
信息系统了呢？如果我们在理论上都不能形成体系，如何又能在实际中要求客户形成体系呢？
所以模型是高于业务人员懂的这个层次的，我们的指导意义也在于此。
从这个角度看UML，ARIS它们都不行。当然，UML是通用语言，并不针对企业模型，所以人家能提出互交已经是很好的了。
yus...@gmail.com
UML语言建模型的出发点是用例事件，强调功能的使用者是谁，这与工作流相适合，从而否定了原来的功能菜单方法。因为不清
楚一个用例事件的人物关系，它的功能设计一定是模糊的，不清晰的。
但是，事件之间的关系（用例之间的关系），并不只是包含关系、扩展关系等等，那还是计算机设计语言，不是企业模型在需求
分析部分应该采用的语言。我们应该在管理层面找到这些事件之间的关系。这是明确企业相关人关系的一个重要角度。
> ...
>
> 阅读更多 - 隐藏被引用文字 -
>
> - 显示引用的文字 -
TY
话入正题：说到UML，不少精通UML的朋友都强调，UML可以用于企业建模。UML的一套概念、语法，确实很一般化，因而原则上我同意你可以用它来为
任何"对象体系"建模，而这世界上，什么事物不是对象体系呢？企业难道不是吗？这就是 UML fans 的哲学。
问题其实并不在这里。"能够"，并不等于"适合"。因为通常讨论这个问题的都是软件行家，所以我借软件领域的经典例子来说明：在高级语言出现、普及的过
程中，"汇编派"也曾经强烈地不屑、抵制：你用高级语言所做的一切，我用汇编都能完成，而且你的高级语言程序编译得到的臃肿冗杂的执行代码不可能有我的
代码那么高的执行效率！在所谓的第四代语言（FGL）和可视化开发平台出现时，也出现过类似的争论。
不过大家不要因这个讨论就忽略了另一个关键点：
企业（业务）模型与计算模型的关系，和PIM（独立于平台的模型）到PSM（特定平台的模型）、高级语言到汇编语言的关系，有相当本质的不同。
> ...
>
> 阅读更多
Lee
但好像没有张贴上 :(