某公司核心业务管理知识系统分析

1、PAGE PAGE 1核心业务系统的内容讨论（管理篇）中科软科技股份有限公司左 春目录TOC o 1-3 h z u HYPERLINK l _Toc198960516 1.核心业务系统概述 PAGEREF _Toc198960516 h 1 HYPERLINK l _Toc198960517 1.1 引言 PAGEREF _Toc198960517 h 1 HYPERLINK l _Toc198960518 1.2 核心业务系统框架结构 PAGEREF _Toc198960518 h 3 HYPERLINK l _Toc198960519 1.3 本文要解决的重点问题 PAGEREF _To

2、c198960519 h 7 HYPERLINK l _Toc198960520 2.核心业务系统的典型块 PAGEREF _Toc198960520 h 7 HYPERLINK l _Toc198960521 2.1核心业务系统“块”的记录事实层（信息模型） PAGEREF _Toc198960521 h 9 HYPERLINK l _Toc198960522 2.2 核心业务系统“块”的约束层（流程模型） PAGEREF _Toc198960522 h 12 HYPERLINK l _Toc198960523 2.3核心业务系统“块”的评估层（优化模型） PAGEREF _Toc19896

3、0523 h 19 HYPERLINK l _Toc198960524 2.4核心业务系统“块”的三层体系归纳 PAGEREF _Toc198960524 h 20 HYPERLINK l _Toc198960525 3.核心业务系统内“块”之间的相邻 PAGEREF _Toc198960525 h 21 HYPERLINK l _Toc198960526 4.核心业务系统的环境层 PAGEREF _Toc198960526 h 22 HYPERLINK l _Toc198960527 5.核心业务系统的“核”和外围子系统 PAGEREF _Toc198960527 h 25 HYPERLIN

4、K l _Toc198960528 6.核心业务系统的分布和外挂 PAGEREF _Toc198960528 h 26 HYPERLINK l _Toc198960529 7.核心业务系统与行业标准化 PAGEREF _Toc198960529 h 27 HYPERLINK l _Toc198960530 8.核心业务系统中核心运营管理 PAGEREF _Toc198960530 h 28 HYPERLINK l _Toc198960531 9.核心业务系统的评估层综合 PAGEREF _Toc198960531 h 29 HYPERLINK l _Toc198960532 10.归纳核心业务

5、系统的知识体系 PAGEREF _Toc198960532 h 39 HYPERLINK l _Toc198960533 11.核心业务系统的生命周期 PAGEREF _Toc198960533 h 40 HYPERLINK l _Toc198960534 12.结论 PAGEREF _Toc198960534 h 41第65页第1页核心业务系统概述1.1 引言在开发行业应用软件的过程中，有一个系统的称呼很有意思，叫核心业务系统。从表面上理解，核心业务系统就是该行业的“核心”的应用软件。本文就试图针对一些服务性行业，从内容构成上讨论一下这个核心业务系统的内涵和外延。核心业务系统本质上也是一个“

6、综合”管理信息系统，为了突出重点和更有针对性，我们以服务行业（如：金融、电信、）为背景，讨论有关的内容。从大的方面看，以服务行业为主要业务的核心业务，重点是围绕“合同管理”和“项目管理”进行（后面我们会说明理由）。“合同管理”反映企业与客户之间的契约管理，它是服务和业务管理的综合体现，“项目管理”反映企业内部组织过程管理，它涉及合同管理，同时也涉及企业内部的组织管理、核算和资源的合理运用。由于涉及的头绪太多、太复杂，我们需要一个基本的框架来定位核心业务系统的主要内容。核心业务系统应该是一个计算机的管理系统，但是在没有这个计算机管理系统之前，一定有一个根源性的东西，它来支撑管理的进行，为了叙述的

7、方便，我们把这个根源性的东西叫可操作管理文件（参考“可操作型管理文件写作”一文），也就是说，是一个管理文件。“可操作”是对格式的要求，其根本的目的是使可操作管理文件与相应的计算机管理系统有相似的结构，这样的可操作性，使我们可以在不同的层面讨论核心业务系统，这样的表达也便于不同知识背景的人员相互沟通。我们的基本框架由三个层面组成：业务管理层面：对应可操作管理文件；软件系统需求/设计层面：对应需求设计文档；计算机系统层面：对应计算机管理系统。 三个层面都有明确的成果物：文件、文档和系统。它们的组成内容可以进一步细化为：可操作管理文件：文件的分章、分块构成。每一块中：表单（业务单据）和活动（业务流程

8、，业务规则），文件的环境描述。软件系统的需求和设计：需求/设计的总体功能组成和每部分概括说明。每一部分中：表单（业务单据），业务操作界面，数据库结构和流程描述（业务流程，业务规则），需求和设计的环境说明。计算机管理系统：系统的整体功能，主菜单。每一个功能中：表单（业务单据），操作界面，数据结构和具体操作步骤说明(业务流程，业务规则)，系统的环境说明。 三个层面结构是“同构”的，但是内容是逐层细化的。上一层对下一层看起来像是框架、蓝图。而下层针对上层而言，就是这个蓝图的细化。如：在可操作管理文件层，我们提出表单（业务单据），这是业务层面最直接的管理结果，没有计算机系统，或不同能力的计算机系统都可

9、能满足这层的要求。但是到了软件系统需求/设计层，就增加了产生表单（业务单据）的计算机“操作界面”的描述，而且配套相应的操作流程和规则。到了计算机管理系统层面，就要在上面的基础上，进一步讨论。表单（业务单据）的数据结构，数据库存贮和交互操作更详细的数据操作内容。分层讨论，它的好处是我们先从主要的问题点入手，并且越来越关注业务操作细节的实现，最终借助软件系统这个工具进行管理。本文由于侧重管理的表述（管理篇），所以采用侧重可操作管理文件层为基础的讨论,这样可以讨论大的管理框架和蓝图，规划和兼顾（同构）实现技术的内容和层次，突出讨论核心业务系统的管理“原理”。要使这些管理目标得以实现，就需要我们通过本

10、文的讨论建立管理目标和内容体系的关系。1.2 核心业务系统框架结构针对核心业务系统的内容体系，我们给出核心业务系统的总体结构图：可以看出三个层面的四个组成部分具有相对应的内容。我们在上图中使用了术语“内容分类”或“块”、“具体流程”、“具体表单”，它们与行业内的很多术语的关系是什么呢？我们第一个概念“内容分类”有“分层”和“组成”的概念（有时也称“概念分层”和“概念划分”，参考“行业应用软件中的词根表和库结构”一文）。“内容分类”是行业内容的“体系结构”，有很多种分类策略，如：按企业的组织机构分类、图书馆的目录分类、系统工程中的系统分类、领域对象的体系结构、，总之，这就是核心业务系统的总体结构

11、，也是本文的总体介绍。在我们具体结构图中，“内容分类”显得非常重要。以保险行业为例，我们看看传统的保险学是如何分类的，即：社会保险/商业保险，法定保险/自愿保险，人身保险/财产保险，。或者换一个角度，按保险性质分类（商业、社会、政策、），按保险标的分类（财产、人身、责任、信用保证、），按危险转移层次分类（原保险、再保险、共同保险，），按实施方式分类（强制、自愿、），按经营主体分类，按客户群分类，按承保的危险分类，按保额确定方式分类，相对于核心业务系统，这些领域分类的方法缺乏整体结构的讨论。那么内容分类是否有统一的标准呢？在有些行业中，有自己的行业分类具体标准，这是行业标准化的一个重要内容，遗憾

12、的，是不是所有行业都有这样的标准。而且在很多的情况下，这类的标准使用还有很大的局限性，这样的话，我们的“内容分类”是否还有参考对象？在实际应用中，我们往往会参考企业的组织结构。这种组织结构往往反映一种分类体系，在行业中也有很多的相似性，更重要的是它与核心业务系统一样都有很强的实务操作要求，所以我们的内容分类主要可以先源于某一个组织结构，虽然我们发现几乎没有两个企业的组织结构是完全相同的，但是从功能和职能看，它们都是极其相似的，作为蓝图讨论的话，它们是共有的。很显然，组织结构不是一成不变的，它的变化反映业务发展的要求和一系列的优化评估原则，本文也将结合系统的综合评估内容做出进一步的讨论。以财产保

13、险为例，我们简单的说明组织结构的分类：基础职能部门：财务部、人事部、办公室、法务部、审计部、信息技术部、专业管理部门：车辆保险部、财产保险部、船舶货运保险部、责任信用保险部、意外健康险保险部、再保险部、综合业务管理部门：客户服务部、理赔管理部、销售管理部、电子商务部、银行业务部、团体业务部、这种划分的方法在结构上看分为：纵向、横向和交叉管理。一般我们认为基础职能部门是管理横向，专业管理部门是管理纵向，而综合业务管理部门反映的是部分纵向的汇集。作为一个核心业务系统的框架，显然要覆盖以上的分类内容，无论是横向还是纵向都是我们形成管理条/块的基础。进一步在条/块的划分中，我们也有元素粒度的概念，这与

14、我们现实中的语义概念也是一致的。如在现实中，我们有一个“合同”的概念，“合同”是由“条款项”组成的，而“条款项”是由“具体元素”组成的，这与化学工程相似，如：内容类比化学粒度合同大分子大块合同条款项中分子中块原子小块以保险为例，典型的大“块”是合同管理，因为它概括内容分类的主体，翻开任何一本保险学的著作，“保险合同”这一章一定是全书的重点。在下面的介绍中，我们会逐步深入讨论有关的内容。实际上，分类的方法很多，但也可以分成两大部分，即概念分层和概念划分，涉及上面业务内容的重点是概念分层，下面我们介绍典型的概念划分方法，其中有代表性的、概念划分的分类方法有：八卦、五行、5WH，它们的特点是“划分”

15、均匀完整，是一种很好的、概括全面的、内容分类工具。业务内容分类涉及不断变化和发展的领域内容，非常类似“语言”的内容分类，更像基于某种用途的语义网络或语义结构层次，而其中的使用的基本元素就是领域中约定俗成的术语（及含义）。这类分类在开始的时候可能是各行其是，有自己的表达和相近的含义，而且彼此不能证明对方是错的，只有发展到一定程度后做某种程度的统一。就像秦朝统一之前，七国各有相似的文字，而秦始皇统一了全部的文字，其实我们看到这些文字在统一之前已经相当类似了。简单的说，相似的分类方式也是一种存在的方式。就像我们看到的不同银行、保险公司，电信企业有很相近的组织结构，但是并没有完全统一（显然，目前核心业

16、务系统也没有统一，但是我们可能看到系统的功能菜单是一样的！）。所以，内容分类本质上是想表示现行运行体系下，业务内容的概念结构体系，找出它们的相对稳定和规律性的内容，形成相对统一的蓝图模型，以此为基础进行表达和沟通。内容分类的另一个主要目的是解决什么内容应该放在什么地方的问题，就像古代人为圣人语录和经书做目录和内容分类，以便后人在学习时可以按主题学习。这样在沟通过程中，便于引导和讨论。在领域内容分类的初期，由于是仿照业务的组织结构进行，当然有一定的内容重复和交叉。就像组织体系中，有的事谁都管，有的事似乎谁都不管，甚至于出现“见好处就上，见问题就让”的情况。实际上，内容分类就是不断解决出现的问题，

17、虽然似乎无法根除，但是会达成一个平衡状态，分出的“块”也越来越合理。当我们讨论越来越多的复杂分块时，我们还有一个重要的抽象方法，就是提出有代表性的“块”，它是一组有复杂关系“块”的代表“块”。也可以称为“蓝图块”，或者称“典型块”，以此加强更高层面沟通的效率。就像人们去买房子，你看到的是“楼书”（蓝图说明），而不是几米高的“工程图”集。有关的内容我们还会在后面不同的地方，陆续讨论。针对具体的一个“块”，我们先给出它的一般结构： 即“块”是由“活动”和“表单”组成的。“块”的相似称呼：服务/对象/组件/业务/功能/任务/对象类/包/(名词和动名词为主)。它衍生的模型称呼有：服务模型，业务模型，功

18、能模型，模型 三个对象的称呼有时混用，它反映对其中一部分内容的侧重讨论，由于这么多的在不同层面的叫法和称呼，就很容易引起混淆，所以在一个具体问题表述时，尽量统一相关术语。从基础内容上看，针对三个对象又确实存在可相互转换的本质，每一部分又有其独立强调的内容，所以在讨论具体问题时，针对问题的特点有侧重的选择一种对象加以讨论。三个对象（块、具体流程和具体表单）的关系可以进一步示意如下：这种表述方法在文件、文档和系统中是相似的。为什么一个计算机管理系统的介绍采用与管理文件写作的框架一致呢？因为我们对核心业务系统的讨论也是一种文档，也要表达或写出来，它也需要遵照科技和管理业务文献写作的格式进行。即：先就

19、内容做整体性的描述，这样能看清系统的全貌；其次，为每一部分系统分析它的稳定部分的组成，最典型的方法是采用表单或数据库结构（有时也称为它的“信息结构”）；然后，针对这样的信息结构讨论具体的操作/控制顺序。而环境是所表达内容的背景描述，它的介绍有多种方法，可以先介绍基础元素（顺叙），也可以后介绍基础元素（倒叙），这看我们的写作规划。总之，我们在介绍核心业务系统时，要有一个整体框架。1.3 本文要解决的重点问题有关专家已经提出了目前核心业务系统的三高状况，即“高期望”、“高依赖”和“高失望”。“高期望”反映管理的目标，“高依赖”反映管理对核心业务系统的依赖，“高失望”主要反映“期望”和“现实功能”之

20、间没有一个好的内容体系做桥梁，用以沟通“过粗”的管理目标和“过细”的功能实现。本文试图解决这样的问题。核心业务系统的典型块首先，我们要说明典型块的由来，在核心业务系统的总体结构图中，我们介绍了内容的分块，也就是核心业务系统是由众多的块组成的，而这些分块又与组织结构有关，并分成了：基础职能部门（如：财务、人事、办公室、）专业管理部门（如：车险、财险、责任险、）综合管理部门（如：客服、理赔、销售、）显然，基础职能部门管理相对通用的分支，是基础、是横向、更像是一种环境建设；专业管理部门管理相对专业的业务分支，是更具体的业务内容，是纵向；而综合管理部门是纵向的专业管理部门的复合方向，是纵向的业务层面的

21、横向。后两部分都是强调业务层面的管理，如果我们进行模型讨论，显然是讨论的重点，而这两部分内容的讨论没有更明确的“对象”，从服务业的实际情况看，都是围绕一张服务合同进行管理的（如：保险行业，保险学讨论的主要对象是保险合同）。当我们把业务内容集中在合同，或者类似合同的主体（业务单证）上时，我们又会遇到新的问题，我们看到的是几十/几百的不同种类的合同（业务单证），而我们的讨论必须简单、明确，所以我们必须产生有代表性的合同，有时我们也称其为“蓝图”结构，或典型的业务内容。我们以保险行业为例，介绍它的产生和作用。典型的合同或有代表性的合同，像“楼书”反映我们讨论问题的本质，是模型讨论的重点，它的要求是：

22、在结构上，要有代表性，所以元素的明细项要多;在内容上，要忽视一定的细节，或用上位概念进行讨论。有了这个典型的结构，大大简化了我们专业沟通的复杂性，提高了表达的效率，强化了典型结构对具体结构的“指导”意义。用同样的原理，各职能部分形成的内容，也是“块”，但它与典型的合同块相对应，是侧重合同要素管理的专业块，相对合同块而言，它是环境块。同样，各专业业务合同也有自己的环境，即，代码元素的描述等，它们也像“典型”的合同块一样抽象为一个“典型”的环境，即，典型的代码元素描述。由于原理是完全一样的，在此不再赘述。上面我们介绍了核心业务系统的典型块的由来和作用，下面我们把重点放在典型块之中，特别是“合同管理

23、”明细对象上，我们先给出一个典型块的组成。2.1核心业务系统“块”的记录事实层（信息模型） 一个具体的核心业务系统的内容显然是庞杂的，我们在讨论时当然要从重点入手，用蓝图的方法进行整体性的讨论，关于数据结构或信息结构的蓝图讨论可参考“行业应用软件中的词根表和库结构”一文。 核心业务系统一个最主要的功能是记录全部的业务数据，以便进行整个企业的管理。所以核心业务系统的最基础使用者是企业内的大量“内勤”人员。甚至国外的一些地方普遍的称核心业务系统为“后端办公系统”，有时候也叫“生产系统”或“交易管理系统”。从事记录信息岗位的人员（内勤）与计算机系统使用有一个对应，从业务角度看，核心业务系统与企业的组

24、织机构也有一个整体的对应。简单的看，企业组织机构图的整体分层对应系统的总分类，纵向机构反映企业的业务划分，一般是专门方向的，所以叫纵向（或业务管理部门），它对应我们业务处理的专业功能块。横向机构反映企业的其它支撑部门，一般是跨部门服务管理部门，所以叫横向（或职能部门），它对应我们业务处理的通用子系统和各种环境配置。这样我们就把系统的内容分类和企业的组织结构分类做了一个初始的对应。如图：其中，“循环变化”的含义反映一种发展的变化，组织机构和系统管理内容都会不断演变，系统的功能也会不断丰富。当我们汇集各种业务表单时，发现它们的种类和形成真是五花八门，抛开表面上的形式，我们重点讨论这些表单的组成要素

25、。 在描述结构构成的时候，我们第二个困难之处是如何规划要素和要素的组成？而且还要确定什么是基础的要素？传统的基于E-R关系的表述是：不区分要素和要素组成的含义，而是选择任何已有对象说明它们的关系，如“数据模型资源手册”表述的那样，很多行业模型也采用这种方法，它的主要问题是：没有有效的区分要素和要素的复合（也就是区分原子和分子），也没有把基础的原子构成“环境”（或字典）；没有对最明细、最多要素的复合引起重视，没有强调，只有最明细的复合对象，才最有“代表性”；举一个例子说明上述问题的含义：当我们学习一般化学时，我们会学元素周期表，也就是知道了所有的元素和元素的化合。但是对一个学习化学工程的工程师而

26、言，他不但要知道元素周期表和元素化合的一般知识，他的重点是针对一类/几类特殊的化合物。这些化合物往往成份复杂，在工程应用中有自己的独特的特性，单纯讨论其构成元素的特性是非常不够的，因为那只是通用的特性，而领域的独特内容往往就反映在元素复合的化合物之中。面对众多的化合物，从信息论的观点看，我们要更关心最多要素聚合的化合物，因为它的信息量最大，也最有代表性，所有信息的加工操作只能使信息量变小。从数学的观点看我们更关心函数的“联合分布”，而不是它的若干“边缘分布”，因为再多的边缘分布也不能构成它的一个联合分布。关注最多要素复合对象也是解决应对信息模型需求变化的最重要方法。核心业务系统的基础性工作是：

27、先要建立（环境）各要素（元素）的表单结构和数据，再根据具体的明细合同内容记录合同的有关结构。上图给出的是最简单的要素和明细结构的对应，它是一个典型的“鱼刺图”，对更一般的情况，可能是一个“树枝图”（参考“可操作型管理文件写作”一文）。 显然，记录事实层虽然侧重信息模型，或者说数据模型，但是它也有相应的流程/活动，它反映记录事实时的操作步骤，以及大量非过程性的信息结构约束活动/条件。下面，我们将结合另两个层面加以更进一步的介绍。2.2 核心业务系统“块”的约束层（流程模型）我们在上图中加了两类：约束类和评估类，后面我们会详细介绍它们的作用。总体而言，它是某种管理的需要，既然是管理，这些管理的主线

28、是如何分的呢？ 针对每一个要素都可能在合同明细上形成一个控制主线，作为核心业务系统约束的一部分。具体图示如下：从发展的抽象层面看，记录事实、约束和评估可以是相对的、发展的。即：记录事实融入环境，约束变成新的记录事实，评估中的稳定部门变成新的约束，对新的约束形成进一步的评估。为了使我们的“块”最有代表性，我们从明细合同的详细要素入手，可以更好的理解这些管理的主线。有关为什么使用“明细合同”讨论，可以参考“可操作型管理文件写作”一文中的“事实表”的有关内容。也就是我们选择的“块”是最有代表性的“块”，以此进行蓝图框架的讨论。下面我们先讨论“约束层”的有关内容。它的起点是我们记录事实中的明细合同，我

29、们进一步给出“明细合同”的结构组成：主线1、客户可以与其它要素进行从1N的组合，典型的有：客户买了多少产品，客户涉及多少个部门，客户的收费额是多少，客户买了多少产品，合计收费是多少， 这种以客户为中心的组合活动是不胜枚举的，所以一般“以客户为中心”的设计重点考虑两个方面：客户的信息是否是统一存放的；以客户要素为主线的活动设计；一般情况下，合同的管理是以合同的记录为中心的，在实务操作上，针对客户要素的环境，会强调客户资料的保存性工作，而针对客户的、更多的涉及控制、分析的活动，则是客户主线的应用。客户为主线的活动讨论其实比我们以上讨论的还要复杂。因为现实中，我们涉及客户的信息不只是在合同中出现，也

30、不只是在客户要素的环境管理中出现，而是随着业务的发展和业务要求的需要，很多客户的背景信息还要不断的获取。如：对个人客户：要了解他们的生活习惯，兴趣爱好，对企业客户：要了解他们的历史，经营状况，这好像是外延的外延，后面我们结合独立的客户管理子系统讨论。对待企业级客户，我们的约束主线有很多变化，一般的说，也就是所谓的团体业务或大客户业务，它需要更特殊、更不同的业务流程和更丰富的业务服务项目，这一主线是目前最为活跃和个性化最强的主线。由于团体业务的灵活性，也存在服务条款的法律风险，这也是目前的严格控制主线。 对这部分内容我们按前面介绍的那样，先分成两大部分讨论：第一部分仍是记录合同的事实；第二部分是

31、针对不同业务管理的约束。 核心业务系统的基础先是记录合同的事实，我们要针对不同业务分类，形成相应的实务，记录合同内容，每个业务分类的实务都不一定相同。这也说明，都是记录合同的事实，但是记录的方法有时很不相同，“业务实务”实际上是操作步骤，反映记录的顺序。这类业务分类管理也有特点，越在组织管理的上层分类越明显，越在组织管理的下层越综合。因为下层面对具体的客户，综合管理效率高，而记录合同的事实更多的是在组织管理的下层进行，以保险行业为例，这也是我们强调“全险种”、“全流程”的原因。 第二部分是对各业务分类的管理要求，它侧重组织管理的上层，也是以业务特性为主线，对其它要素的组合控制，如在保险行业，它

32、可能是核保/核赔，我们在此就不展开讨论了，但是可以看出它是以业务内容为中心的控制管理。主线3、产品：产品的内涵就是命名和编码，外延涉及合同其它要素，到底涉及多少，没有明确定义。极端情况合同的全部要素和条款才构成完整的产品。在产品代码和全部合同要素之间，为了加强产品定义的“可操作”性，一般以产品代码为主线，选几个特定的要素、要素取值和固定的活动（控制）作为产品的扩展定义。一般而言，“扩展产品”主要包括：产品及分类代码，产品涉及主要要素集合，产品针对客户要素的组合框架，产品涉及要素之间对应收/付额的计算（公式），产品相对业务分类的组成和固定流程，产品分类通用的约束框架，。如果以上要素被定义并固定下

33、来，它们都要与产品的分类结构代码取值一样，被事先准备在我们称为“环境”的产品要素管理之中。 总之，以产品为主线的约束是涉及很多其它要素的复合管理，产品主线的主要要求是：使核心业务系统能够快速的推出新的产品，并融入已有的管理体系，使新产品以其良好的组合性，更好的满足客户需求，主线4、 以标的为中心的约束反映对标的更深入的控制，很多时候与标的自身的特性和风险控制有关，往往与其它要素组合形成各种约束内容。主线5、组织机构：组织机构一般反映合同执行主体的组织，它也有很多分类，如：内勤和外勤，有时包括外围的组织，每一个组织都有很多关系表述，最简单的是分层结构。组织的控制反映组织结构中的关系及权力分布，一

34、般纵向机构对应“业务部门”，横向机构对应管理“职能部门”，并且分层呼应设立。地域一般指地理区域的划分，是组织划分的重要内容。内容性划分也是组织划分的重要内容，它也种类丰富，如：行业/机构分类/客户群等。同样与其它要素组合形成涉及组织的各种约束内容，后面我们将结合评估层“以组织为中心”内容做更深入讨论。主线6、过程状态：合同不是静止的，是随时间变化而变化的。其中重要的阶段有特定的含义，我们必须记录下来。过程状态一般会与其它管理要素结合，形成新的控制约束，合同的“过程状态”一个重要的分支是反映合同“交易”的过程状态，也就是合同销售的过程状态，这部分描述我们扩展一下用传统商务和电子商务分别说明，其中

35、合同我们简称为产品。传统商务电子商务1.宣传产品信息1.发布产品信息2.询/报价，咨询2.询/报价，咨询3.签协议/确认3.下订单/确认4.支付4.支付/代付5.交换实际协议5.收/发产品正本6.后续服务6.后续服务过程状态过程状态这个过程是一个典型的销售过程，并且与“组织机构”主线密切相关，由此引出了“渠道”的概念。关于“过程状态”中交易的重点，约束层一般要解决的是如下重要的问题：信用问题：无论是“产品”还是“支付”，都存在信用问题，本主线要完成信用建立的综合管理。奖励问题：这种奖励是对交易当事人的，对卖家而言是奖励制度，就像保险行业的“销售基本法”。对买家而言是优惠，不同的客户有不同的优惠

36、，并且有积分功能，保证短期优惠和长期优惠相结合。关于各种定价和规则参数的确定，我们要结合后面章节的“成本分析”给出，它也决定着我们多渠道政策的冲突和平衡问题。从前面的介绍我们已经看到，无论是传统商务还是电子商务，都有极其相似的“过程状态”，在这个“交易”过程中，重点是对“三流”的讨论，即：信息流、资金流和物流。本节的重点是信息流，而资金流和物流要结合后面的过程管理或称运营管理的内容中进行讨论。我们用如下图说明此环节的通用性。我们从图中看到，合同的交易环节是一个水平通用环节，它的结构应该有标准化的倾向。实际上，确实也是这样，一个信息化的标准组织（特别侧重电子商务）是其中的代表，即由于电子商务的发

37、展使信息技术在其中扮演越来越重要的角色，我们看到各种电子商务的网站是此类创新的先驱，由此也引出一系列非功能性问题，如：并发用户数、联机响应时间、交易的易用性、，总之，核心业务系统的发展必然产生一个分支，以其深厚的领域背景，引领新一轮合同交易的创新浪潮。主线7、时间期限：合同不是永远有效的，合同的有效期限也要明确的被约束，很多内容是与合同的有效期相关的。时间期限，或其它时间特性属性，一般会与其它要素结合，形成新的控制约束， 时间和期限也区分“点”和“线”，时间一般是“点”，而期限一般是“线”。主线8、地域：合同执行的地域是有边界的，反映合同的地区特征。不同地域的特点不同，作为一个要素它可能引起各

38、种组合的约束变化。典型的是在组织机构图中，地域范围是主要的考虑因素。 地域也有地点和区域的区分，地点一般是“点”，而区域一般是“面”。主线9、权限控制：合同的管理有权限的问题，它涉及合同的安全性，同时权限管理也是核心业务系统的重要基础要求，它的各种配置一般反映在环境建立过程之中，在企业的内控约束建立过程中，这一主线会起到很重要的作用。这部分内容进一步发展，就是企业的“治理结构”和风险管理，它的一个通用性框架是企业风险管理整体框架，它是COSO委员会在结合萨班斯奥克斯利法案简称“萨班斯法案”基础上发布的。相应的内容我们将结合后面章节的组织主线综合和核心业务系统“块”的三层体系结构加以讨论。主线1

39、0、主线11、收/付费额：收/付费额是合同的主要标量，是合同各项价值计算的基础。在合同的明细表中，本标量是对应所有要素的信息，在各类管理控制过程中，涉及的数量（标量）信息一般都与本内容有关。 以上这些主线就形成了企业控制（约束）管理的主线条，也就产生了各种“中心论”，如：以客户为中心，以产品为中心，以某项业务为中心，以过程状态/交易/销售为中心，以权限控制（风险控制）为中心，。其实这些中心论，反映管理一个时期的重点，也叫“缺什么补什么”，或者叫“三十年河东，三十年河西”。同时反映了企业管理的综合特性，也反映核心业务系统的综合特性。约束层是一个使核心业务系统不断膨胀的管理约束层，与各要素相关反映

40、一种个性化的管理要求。在一个高速发展的市场环境下，是一个以定制化为主体的软件开发层，相对于记录事实层，它是核心业务系统的第一层外延。2.3核心业务系统“块”的评估层（优化模型）核心业务系统的评估层是在约束层之上的一层，是对约束层的约束。如果把约束层看成是一般的管理措施的话，评估层是对这些管理措施的评价。一般人们认为管理总是好的。但实际上，也有很多越管越乱、越管越差的情况，所以管理改进的重要内容是评估层要解决的问题。在单一“块”内的评估层，反映本块各约束主线的效果评价，它也比较好理解，但是一般系统的评价往往是综合的，是跨“块”的（跨越合同管理的内容），所以我们将结合后面各块的综合，结合核心业务系

41、统要完成的总目标，进行评估层综合的讨论。实际上，评估层中的一部分内容是独立于核心业务系统之外的。2.4核心业务系统“块”的三层体系归纳核心业务系统典型“块”的三层结构图如下：这三层结构的重点是不同的，其要点可以归纳为“唯实、求真、协力、创新”，这也是中国科学院的行为准则。记录事实层对应“唯实、求真”，反映对基础数据真实性的要求和结构合理性的要求，很多集中管控的内容都是针对这部分内容，因为有人为了各种原因，总是篡改/修改基础的事实数据。约束层对应“协力”，反映控制、约束的目标是要形成合力，完成管理的目标，这是精细化管理和个性化管理的主要方向。评估层对应“创新”，反映系统的目标要不断的优化，不断地

42、完善已有的管理体系，以适应新的市场变化。在前面的约束层中，权限控制主线中，我们在内控体系上引出了“萨班斯法案”，下面我们就比较一下三层结构与“萨班斯法案”的关联。记录事实层：萨班斯法案第103条款要求（简述）：建立公司的内部控制政策和程序是否包括详细程度合理的记录，以准确地反映公司的资产交易和处置情况。约束层：萨班斯法案第302条款要求（简述）：建立公司一套完整的内控程序，并使公司各级管理者纳入这一程序之中，并要求管理者对此程序进行有效性评价。评估层：萨班斯法案第404条款要求（简述）：要保证对内控程序的评价进行有效性的进一步检查，审计师应对管理者的评价进行审计和报告，保证评价的有效性。虽然我

43、们没有给出完整的萨班斯法案，但是它的大体含义已经包括了。如果我们开发一个软件系统去实现萨班斯法案的要求，这样笼统需求显然是不充分的，它的很多描述相对于“可操作的管理描述”只能说是一种整体要求，其中：记录事实层：没有给出具体的“业务单据”（表单）说明，因为它也无法确定讨论的对象在哪个行业。约束层：没有给出具体的“业务流程”、“业务规则”，内控程序有很强的不确定性，因为具体企业管理的体系会十分不同，只有结合类似“可操作管理文件”才能讨论清楚。评估层：没有给出具体的评价方法，评价结构和评价的准则，因为具体企业的管理评价也是十分灵活和多样的，并且还要结合组织机构的分权规则。 所以，要想进行真正有效的内

44、控管理，它必须是结合核心业务系统和可操作管理文件进行的，而且这个核心业务系统和可操作管理文件还应该有清晰的体系结构，以保证各控制环节配置的有效性。本文正是为建立这样的框架而努力，本文的框架正好符合一般的管理控制框架，如：萨班斯法案给出的框架，所不同的是与一个实际运行的软件系统，即核心业务系统有一个明确的对应。核心业务系统内“块”之间的相邻相邻的部分从书写顺序看相连部分，但是现实中，它们是可能任意方向相邻的，任何的块与其它块都可能构成相邻。我们以“块”的方式做如下表示：所以块与块之间的相邻操作，涉及：统一相应的环境层；分析记录事实层的要素构成关系，并统一相应的活动；从要素构成出发，分析相同或不同

45、的结构和活动，了解哪些是最明细结构，哪些是多共同要素的结构；是否形成新的组合结构和融合的活动。这种核心业务系统内的相邻“块”之间的关系，反映业务对象的分类、分块，相邻的概念是块与块的衔接，它可能构成更大粒度的环境，因为包装了的“块”，可能再构成上/下游的关系，针对子系统/其它系统而言，构成系统的边界。我们将结合下一节核心业务系统的环境，讨论它们的位置。核心业务系统的环境层核心业务系统的环境内容相当丰富，最新的进展是分层描述，它的一个重要特点是，从领域的内容逐渐过渡到技术支撑的内容。其整体表示如下：在一般业务模型的讨论中，所说的“环境”，主要指上图应用软件层的“领域”分类中，涉及业务要素的内容（

46、1.全部业务要素组件），有时也称为“业务字典”或“业务代码”。本节所述“环境”是更广意义上的系统“环境”。通过环境整体图，我们发现所有技术环节基本上都放在环境的底层中了，它的主要原因是什么？ 首先，技术相对于业务是更为快速发展的。以编程语言工具为例，基本上是每5-10年就有一个巨大的变化。而我们的核心业务系统就要建立在这种编程语言工具之上，所以我们在系统和模型建设时，要最大限度的降低对底层技术的依赖性，各种分层技术是主要的方法。我们提出“样本程序”的方法（参见试述样本程序比赛的几个理由）就是为了技术开发平台变化了，样本程序可以更好的反映它的变化点，从而指导整个应用软件系统的移植和升级。不要被很

47、多新的编程架构所困惑。技术发展到一定程度，有一个分支是围绕业务内容进行的，它不断的把业务中“通用”的东西技术化。所以，我们所有的业务横向都是技术发展的机会，改进之后再按环境分层的要求，逐层包装，从而大大提高系统更新换代的效率。最后，技术也有独立的发展方向，它受很多学科的影响。如：影像技术，通信技术，计算技术，GIS技术，。当这些技术发展了，就会影响到我们的环境，向上延伸影响我们的组织战术，从而引发核心业务系统的发展，把它们“分配”或“规划”在特定层面位置上，有利于系统的整体发展。在资源有限和技术不断变化的今天，也并不是技术装备越先进越好。有的时候，技术越先进系统越脆弱。所以我们一定要做好相应的

48、平衡，特别是强调软技术实力，如：对可操作管理文件的建立。我最近刚从国外参观回来，一个财产保险的核心业务系统，为了使用新的B/S结构进行重建，投入250人工作两年，其成本就在3000万美元之上。像这样的系统随着技术的快速发展，每五年左右就要重建一次，难道我们不更应该关注系统模型中稳定的部分吗？归纳：整体上看，技术只占整个系统中环境底层的内容，它是细节，也是容易变化的部分。其它更多的是领域知识和管理的内容，所以我们可以说核心业务系统是“三分技术，七分管理”。相对于环境而言，约束层涉及管理内容的部分更像是“集成定制”。这与系统软件和产品软件不同，核心业务系统中相对稳定的部分：环境、主业务模块（领域组

49、件）、定制工具和策略（样本程序）有时称为核心系统平台，也可以看成是核涉及核心业务系统环境问题的另一个重要分支是“历史数据”环境问题，它的功能组件在应用软件层的“领域”分类中的第6项，这是传统软件工程介绍中的弱项。实际上，作为核心业务系统的重点，以从传统业务意义上的“开发”变成了“运维和升级”，历史数据已经成为核心业务系统的一部分了。当然我们做系统设计时，要充分考虑软件对数据的“松耦合”问题，但是大量的约束层内容已经使这个问题变得越来越严重。我们经常在软件升级中遇到这样的问题，软件在集中测试时都一切正常，但是在具体地区上线时，由于存在“垃圾”历史数据，造成系统的错误。所以我们的环境组件要大力发展

50、“数据一致性检查组件”，这部分的难度也非常大，虽然我们在“过程管理层”也有大量的集成开发平台、监控和维护工具，但那些都是通用的。而数据一致性是涉及领域知识、领域模型的，在系统的升级中，它才是“数据迁移”的关键，在有大量历史数据的“遗产系统”升级中，它已经变成比软件测试更重要的内容分支，它将成为“运维管理”、“系统故障应急管理”的重要管理工具。总之，环境层的内容非常重要，我们“块”与“块”、系统与系统的沟通是有成果物的，从管理角度看是“联系界面”，从软件角度看是“接口”。而实际上，环境的存在是隐含的，环境的合理规划和实现，才是使“联系界面”或“接口”变得“简单”和“干净”的主要功臣。核心业务系统

51、的“核”和外围子系统由于各主线的内容越来越多，侧重越来越明显，在“环境”中的要素管理与核心业务系统主体的合同管理就形成了新的演化，分离了“核”和外围子系统。它的公式是“环境”中某一要素的管理，按主线方式进行统一管理，就形成了一个子系统。子系统的涉及其它要素的环境，应该严格按核心业务系统的要素环境统一建立，这也是目前很多子系统建设中经常存在的问题之一。重复一遍，这些新的子系统有一个重要的约束，就是保证“环境”的统一。子系统的建设也有很多优点，它的主要优点是使专项管理更加集中，并且为核心业务系统做了“减负”性工作。因为各种主线都加载在核心业务系统之上，使系统的变动变得十分笨重。就像一个军舰又要有厚

52、的装甲；又要有大的火炮和多的导弹；作战使命又要对空，又要对海；又要开的很快，最后，只能组成舰队群，把侧重功能分出去。“减负”后的核心业务系统，针对每一个子系统有一个统一的约束层规划，相当于外围子系统有一个“驻核心业务系统办事处”，以便核心业务系统的“核”与外围子系统进行有效的衔接。核心业务系统与外围子系统的关系也有两种主要结构，即：主/从结构和对等结构。上图给出的是典型的主/从结构。一般随着应用的深入，主/从结构会转成对等结构。其中控制是随着应用的深入而逐渐分散的，在主/从结构中，也分“紧”主/从结构和“松”主/从结构，有点像“中央集权”和“联邦制”。关于主/从结构和对等结构，简单的示意图如下

53、：两种结构各有利弊，后面我们会结合“运营管理”讨论对等结构的运用。总之，随着应用的发展，有些子系统越来越庞大，有自己独立的“对等”控制主线，所以就会演化成新的对等结构。核心业务系统的分布和外挂核心业务系统往往遵循“统一开发、分地区分布运行”的策略。以中国的国情，一套核心业务系统运行在全国范围内，要照顾各种地区的特殊性，是相当困难的。从管理上看是一个“统”和“放”的问题，从技术上看是一个通用性和个性化融合问题，并且这也是具有非常普遍的代表性问题。这就要求我们用本文给出的框架方法，说明一个“统”、“放”规划图，要使得该“统”的统起来，该“放”的放下去。下面我们给出我们的“统”“放”规划图：整个外挂

54、策略反映统/放原则：强调“统”的部分：记录事实层的部分要严格管控，是雷区，是红线，并强调控制的有效性，对环境层也集中控制，极少的例外要报备、审批。反映“放”的部分：对约束层、评估层中统计分析的内容，做规划下的外挂。对只涉及地区特性，又与核心业务系统内容不重要的“独立增加部分”，增加更完整的外挂部分。对记录事实层和新增环境层内容，要严格控制、统一设计、报批，对已有数据进行各级管理。对约束层、评估层新加的内容，要报备、审批，并用制度保证执行的有效性。外挂的规划是核心业务系统发展的一个热点问题，必须有效的解决，对于一个管理的问题，我们必须有一个尝试性的机制，一个充分的试点，不能“一刀切”，它也是核心

55、业务系统进化和升级的重要工程方法，对于全国性的大企业必须掌握这样的方法，它就是我们核心竞争力的一部分。核心业务系统与行业标准化标准化比较好的形成于业务系统的稳定部分，所以与核心业务系统框架相关，标准化有如下的三个层面：标准化最先强调的是“环境”的稳定部分，所以本文所述的环境部分内容是标准化的一个重要组成部分。标准化强调块与块、系统与系统之间的对接，我们简单的说是接口标准，它的特点也是非常详细，否则接不上。本文所述的用于跨块和跨系统的表单和活动都是标准化讨论的重要内容。标准化在讨论框架方面，也要有一定的工具。它是一个管理式业务模型的上位概念，有很强的代表性。本文中给出的内容分类和典型的“块”结构

56、，就是标准化讨论的主要内容，很多标准化组织都给出了类似的结构，如：保险行业的ACORD就给出了类似的“树枝图”结构。了解了这三个主要的方面，我们就体会了标准化在核心业务系统中侧重静态的、稳定的内容，很显然，在这三个层面建立标准化，都会给系统的建设带来巨大的便利。实际上，随着核心业务系统的发展，标准化也有从静态的结构向动态的流程发展的趋势。核心业务系统中核心运营管理前面我们用“明细合同管理”块介绍了核心业务系统内容的主要部分，虽然在要素主线上我们对一些控制因素做了分析，但是合同管理过程中，存在过程性管理的其它综合问我们简单的定义核心运营管理(更大的块)=合同管理(块)+项目管理(块)+财务管理(

57、块)1.效益：从运营的成本和收入角度核算组织的盈利能力，在财务报表中它对应“损益表”；2.能力：从运营的资源(资本/装备)角度核算组织的风险承受能力，在财务报表中它对应“资产负债表”。 关于财务管理作为一个“块”我们就不做更详细的介绍了，我们把重点放在项目管理块的介绍上，并对应说明财务管理与它的联系。与合同管理的“事实表”相对应，我们也给出项目管理的明细结构如下：由于项目管理的明细结构也有这么多的要素组成,在整个的项目管理中,它占有重要的地位。其中的主要要素与财务管理系统中的要素及管理模块也有明显的对应：项目管理本体总账的会计核算分层计划/完成管理会计的预算/决算人/组织总账的重要科目（段）资

58、产（装备）资产管理资本资金管理项目状态运营控制成本(费用/分摊) 成本管理绩效绩效管理和报表收入利润分析和报表我们说对应财务管理系统的功能，就是要适度区分项目管理中的基础数据与财务系统本身。因为项目管理中的基础数据虽然也是“全组织”、“全核算”，但是与企业财务系统还是在使用上有一定差别，企业的会计记录有更多的历史痕迹，并且对成本明细的核算受到科目级长的约束。简单的说，我们上图抽象的财务系统应该是虚拟的财务系统，它的所有原理与财务系统都是一样的，只是它的重点是运营核算，它可以是独立的，并与实际的财务系统有明确的对应关系，也就是说它可以作为运营绩效而独立的存在。当我们引入这部分内容时，我们实际上扩

59、充合同管理为运营管理了，合同管理本身变成运营管理的一部分内容了。好的一面是,目前的项目管理由于针对不同的应用要求，太强调过程管理而忽视了大量涉及领域要求内容的结构，我们正好从合同管理过渡到核心运营管理。核心运营管理（或者叫综合项目管理）核心业务系统的评估层综合在前面的介绍中，我们说核心业务系统的评估层要结合其它的块进行，当我们加入项目管理和财务管理的内容后，我们可以进行进一步的分析。评估层与核心业务系统的关系是：评估层的一部分确定性内容变成了核心业务系统外延的外延，甚至形成新的子系统。而另一部分可以看成是在核心业务系统之外，是由专家也用表单(评估表)和活动(评估过程)，并统称评估模型，进行管理

60、的过程。很多评估模型的参数变成了控制要素，在约束层的表单中形成数值，从而实现某一目标的约束管理。其中有一个重要的约束分支称为“计划管理”，“计划”往往是约束层的目标数据（表单），并由评估层决定它的评价和数据修改。评估层没有进入核心业务系统的部分往往是描述性和非结构化的内容过多，并且大部分采用专家手工过程。评估层“复合块”的总体结构示意如下：可以看出，整个约束层是以合同管理中的主要素为线索进行讨论的，而评估层我们也要选择一个主线索，而且要充分考虑项目管理的内容，如：用户要求、成本、进度、质量、安全、。针对已有的企业管理和项目管理最新理论进展，我们选择以“组织”为主线讨论评估层。以“组织”为主线讨