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

核心业务系统的内容讨论（管理篇）

中科软科技股份有限公司
左 春
目 录

1. 核心业务系统概述 1
1.1 引言 1
1.2 核心业务系统框架结构 3
1.3 本文要解决的重点问题 7
2. 核心业务系统的典型块 7
2.1核心业务系统“块”的记录事实层（信息模型） 9
2.2 核心业务系统“块”的约束层（流程模型） 12
2.3核心业务系统“块”的评估层（优化模型） 19
2.4核心业务系统“块”的三层体系归纳 20
3. 核心业务系统内“块”之间的相邻 21
4. 核心业务系统的环境层 22
5. 核心业务系统的“核”和外围子系统 25
6. 核心业务系统的分布和外挂 26
7. 核心业务系统与行业标准化 27
8. 核心业务系统中核心运营管理 28
9. 核心业务系统的评估层综合 29
10. 归纳核心业务系统的知识体系 39
11. 核心业务系统的生命周期 40
12. 结论 41

1. 核心业务系统概述
1.1 引言
在开发行业应用软件的过程中，有一个系统的称呼很有意思，叫核心业务系统。从表面上理解，核心业务系统就是该行业的“核心”的应用软件。本文就试图针对一些服务性行业，从内容构成上讨论一下这个核心业务系统的内涵和外延。
核心业务系统本质上也是一个“综合”管理信息系统，为了突出重点和更有针对性，我们以服务行业（如：金融、电信、……）为背景，讨论有关的内容。 从大的方面看，以服务行业为主要业务的核心业务，重点是围绕“合同管理”和“项目管理”进行（后面我们会说明理由）。“合同管理”反映企业与客户之间的契约管理，它是服务和业务管理的综合体现，“项目管理”反映企业内部组织过程管理，它涉及合同管理，同时也涉及企业内部的组织管理、核算和资源的合理运用。由于涉及的头绪太多、太复杂，我们需要一个基本的框架来定位核心业务系统的主要内容。
核心业务系统应该是一个计算机的管理系统，但是在没有这个计算机管理系统之前，一定有一个根源性的东西，它来支撑管理的进行，为了叙述的方便，我们把这个根源性的东西叫可操作管理文件（参考“可操作型管理文件写作”一文），也就是说，是一个管理文件。“可操作”是对格式的要求，其根本的目的是使可操作管理文件与相应的计算机管理系统有相似的结构，这样的可操作性，使我们可以在不同的层面讨论核心业务系统，这样的表达也便于不同知识背景的人员相互沟通。我们的基本框架由三个层面组成：
——业务管理层面：对应可操作管理文件；
——软件系统需求/设计层面：对应需求设计文档；
——计算机系统层面：对应计算机管理系统。
三个层面都有明确的成果物：文件、文档和系统。它们的组成内容可以进一步细化为：
——可操作管理文件：①文件的分章、分块构成。每一块中：②表单（业务单据）和③活动（业务流程，业务规则），④文件的环境描述。
——软件系统的需求和设计：①需求/设计的总体功能组成和每部分概括说明。每一部分中：②表单（业务单据），业务操作界面，数据库结构和③流程描述（业务流程，业务规则），④需求和设计的环境说明。
——计算机管理系统：①系统的整体功能，主菜单。每一个功能中：②表单（业务单据），操作界面，数据结构和③具体操作步骤说明(业务流程，业务规则)，④系统的环境说明。
三个层面结构是“同构”的，但是内容是逐层细化的。上一层对下一层看起来像是框架、蓝图。而下层针对上层而言，就是这个蓝图的细化。如：在可操作管理文件层，我们提出表单（业务单据），这是业务层面最直接的管理结果，没有计算机系统，或不同能力的计算机系统都可能满足这层的要求。但是到了软件系统需求/设计层，就增加了产生表单（业务单据）的计算机“操作界面”的描述，而且配套相应的操作流程和规则。到了计算机管理系统层面，就要在上面的基础上，进一步讨论。表单（业务单据）的数据结构，数据库存贮和交互操作更详细的数据操作内容。分层讨论，它的好处是我们先从主要的问题点入手，并且越来越关注业务操作细节的实现，最终借助软件系统这个工具进行管理。本文由于侧重管理的表述（管理篇），所以采用侧重可操作管理文件层为基础的讨论,这样可以讨论大的管理框架和蓝图，规划和兼顾（同构）实现技术的内容和层次，突出讨论核心业务系统的管理“原理”。
作为核心业务系统的概述，我们更重要的是给出它的内容体系和管理目标。
核心业务系统内容体系也是本文的内容体系应该包括：
1. 核心业务系统的整体结构/总体结构；
2. 核心业务系统内外部环境及标准化；
3. 典型组成部分的结构和组成分析；
4. 各组成部分之间的关系和综合管理、优化。
通过对核心业务系统内容体系的讨论，完成如下的管理目标：
1. 调整/创新管理的机制，促进业务的增长；
2. 提高运行效率，降低综合成本；
3. 优化运营环境，合理运用资源；
4. 规范管理体系，控制经营风险。
要使这些管理目标得以实现，就需要我们通过本文的讨论建立管理目标和内容体系的关系。
1.2 核心业务系统框架结构
针对核心业务系统的内容体系，我们给出核心业务系统的总体结构图：

可以看出三个层面的四个组成部分具有相对应的内容。
我们在上图中使用了术语“内容分类”或“块”、“具体流程”、“具体表单”，它们与行业内的很多术语的关系是什么呢？我们第一个概念“内容分类”有“分层”和“组成”的概念（有时也称“概念分层”和“概念划分”，参考“行业应用软件中的词根表和库结构”一文）。“内容分类”是行业内容的“体系结构”，有很多种分类策略，如：按企业的组织机构分类、图书馆的目录分类、系统工程中的系统分类、领域对象的体系结构、……，总之，这就是核心业务系统的总体结构，也是本文的总体介绍。
在我们具体结构图中，“内容分类”显得非常重要。以保险行业为例，我们看看传统的《保险学》是如何分类的，即：社会保险/商业保险，法定保险/自愿保险，人身保险/财产保险，……。或者换一个角度，按保险性质分类（商业、社会、政策、……），按保险标的分类（财产、人身、责任、信用保证、……），按危险转移层次分类（原保险、再保险、共同保险，……），按实施方式分类（强制、自愿、……），按经营主体分类，按客户群分类，按承保的危险分类，按保额确定方式分类，……
相对于核心业务系统，这些领域分类的方法缺乏整体结构的讨论。那么内容分类是否有统一的标准呢？在有些行业中，有自己的行业分类具体标准，这是行业标准化的一个重要内容，遗憾的，是不是所有行业都有这样的标准。而且在很多的情况下，这类的标准使用还有很大的局限性，这样的话，我们的“内容分类”是否还有参考对象？在实际应用中，我们往往会参考企业的组织结构。这种组织结构往往反映一种分类体系，在行业中也有很多的相似性，更重要的是它与核心业务系统一样都有很强的实务操作要求，所以我们的内容分类主要可以先源于某一个组织结构，虽然我们发现几乎没有两个企业的组织结构是完全相同的，但是从功能和职能看，它们都是极其相似的，作为蓝图讨论的话，它们是共有的。很显然，组织结构不是一成不变的，它的变化反映业务发展的要求和一系列的优化评估原则，本文也将结合系统的综合评估内容做出进一步的讨论。
以财产保险为例，我们简单的说明组织结构的分类：
基础职能部门：财务部、人事部、办公室、法务部、审计部、信息技术部、……
专业管理部门：车辆保险部、财产保险部、船舶货运保险部、责任信用保险部、意外健康险保险部、再保险部、……
综合业务管理部门：客户服务部、理赔管理部、销售管理部、电子商务部、银行业务部、团体业务部、……
这种划分的方法在结构上看分为：纵向、横向和交叉管理。一般我们认为基础职能部门是管理横向，专业管理部门是管理纵向，而综合业务管理部门反映的是部分纵向的汇集。
作为一个核心业务系统的框架，显然要覆盖以上的分类内容，无论是横向还是纵向都是我们形成管理条/块的基础。进一步在条/块的划分中，我们也有元素粒度的概念，这与我们现实中的语义概念也是一致的。如在现实中，我们有一个“合同”的概念，“合同”是由“条款项”组成的，而“条款项”是由“具体元素”组成的，这与化学工程相似，如：
内 容
类比化学
粒 度
合 同
大分子
大 块
合同条款项
中分子
中 块
客户、产品、……
原 子
小 块
以保险为例，典型的大“块”是合同管理，因为它概括内容分类的主体，翻开任何一本《保险学》的著作，“保险合同”这一章一定是全书的重点。在下面的介绍中，我们会逐步深入讨论有关的内容。
实际上，分类的方法很多，但也可以分成两大部分，即概念分层和概念划分，涉及上面业务内容的重点是概念分层，下面我们介绍典型的概念划分方法，其中有代表性的、概念划分的分类方法有：八卦、五行、5WH，它们的特点是“划分”均匀完整，是一种很好的、概括全面的、内容分类工具。
业务内容分类涉及不断变化和发展的领域内容，非常类似“语言”的内容分类，更像基于某种用途的语义网络或语义结构层次，而其中的使用的基本元素就是领域中约定俗成的术语（及含义）。这类分类在开始的时候可能是各行其是，有自己的表达和相近的含义，而且彼此不能证明对方是错的，只有发展到一定程度后做某种程度的统一。就像秦朝统一之前，七国各有相似的文字，而秦始皇统一了全部的文字，其实我们看到这些文字在统一之前已经相当类似了。简单的说，相似的分类方式也是一种存在的方式。就像我们看到的不同银行、保险公司，电信企业有很相近的组织结构，但是并没有完全统一（显然，目前核心业务系统也没有统一，但是我们可能看到系统的功能菜单是一样的！）。所以，内容分类本质上是想表示现行运行体系下，业务内容的概念结构体系，找出它们的相对稳定和规律性的内容，形成相对统一的蓝图模型，以此为基础进行表达和沟通。
内容分类的另一个主要目的是解决什么内容应该放在什么地方的问题，就像古代人为圣人语录和经书做目录和内容分类，以便后人在学习时可以按主题学习。这样在沟通过程中，便于引导和讨论。在领域内容分类的初期，由于是仿照业务的组织结构进行，当然有一定的内容重复和交叉。就像组织体系中，有的事谁都管，有的事似乎谁都不管，甚至于出现“见好处就上，见问题就让”的情况。实际上，内容分类就是不断解决出现的问题，虽然似乎无法根除，但是会达成一个平衡状态，分出的“块”也越来越合理。当我们讨论越来越多的复杂分块时，我们还有一个重要的抽象方法，就是提出有代表性的“块”，它是一组有复杂关系“块”的代表“块”。也可以称为“蓝图块”，或者称“典型块”，以此加强更高层面沟通的效率。就像人们去买房子，你看到的是“楼书”（蓝图说明），而不是几米高的“工程图”集。
有关的内容我们还会在后面不同的地方，陆续讨论。针对具体的一个“块”，我们先给出它的一般结构：

即“块”是由“活动”和“表单”组成的。
1. “块”的相似称呼：服务/对象/组件/业务/功能/任务/对象类/包/…(名词和动名词为主)。它衍生的模型称呼有：服务模型，业务模型，功能模型，…
2. “表单”的相似称呼：表单(据/证)/数据/界面/信息/数据库/数据结构/结构/…（名词为主）。它衍生的模型称呼有：数据模型，信息模型，数据库模型，…
3. “活动”的相似称呼：活动/流程/步骤/程序/战术/处理/作业/操作/记录/… (动词和动名词为主)。它衍生的模型称呼有：流程模型，程序模型，战术方法模型，…
三个对象的称呼有时混用，它反映对其中一部分内容的侧重讨论，由于这么多的在不同层面的叫法和称呼，就很容易引起混淆，所以在一个具体问题表述时，尽量统一相关术语。从基础内容上看，针对三个对象又确实存在可相互转换的本质，每一部分又有其独立强调的内容，所以在讨论具体问题时，针对问题的特点有侧重的选择一种对象加以讨论。三个对象（块、具体流程和具体表单）的关系可以进一步示意如下：

这种表述方法在文件、文档和系统中是相似的。
为什么一个计算机管理系统的介绍采用与管理文件写作的框架一致呢？因为我们对核心业务系统的讨论也是一种文档，也要表达或写出来，它也需要遵照科技和管理业务文献写作的格式进行。即：先就内容做整体性的描述，这样能看清系统的全貌；其次，为每一部分系统分析它的稳定部分的组成，最典型的方法是采用表单或数据库结构（有时也称为它的“信息结构”）；然后，针对这样的信息结构讨论具体的操作/控制顺序。而环境是所表达内容的背景描述，它的介绍有多种方法，可以先介绍基础元素（顺叙），也可以后介绍基础元素（倒叙），这看我们的写作规划。总之，我们在介绍核心业务系统时，要有一个整体框架。
1.3 本文要解决的重点问题
有了核心业务系统的内容框架，我们还要结合前面给出的系统目标，并引出目前的问题，以此讨论本文要解决的重点问题。本文要解决的重点问题由如下图所示：

有关专家已经提出了目前核心业务系统的三高状况，即“高期望”、“高依赖”和“高失望”。“高期望”反映管理的目标，“高依赖”反映管理对核心业务系统的依赖，“高失望”主要反映“期望”和“现实功能”之间没有一个好的内容体系做桥梁，用以沟通“过粗”的管理目标和“过细”的功能实现。本文试图解决这样的问题。
本文的主要结构包括：在引言中提出一个内容体系；在第二节中主要介绍一个典型的业务块，即合同管理“块”，用以反映核心业务系统的基础；第三节介绍核心系统内“块”之间的相邻特性；第四节讨论核心业务系统的整个环境体系；第五节则介绍核心系统的发展和演化，用以形成的外围子系统；第六节讨论核心系统的分布和外挂；第七节讨论核心业务系统与行业标准化的关系；第八节讨论核心业务系统运营管理问题；第九节综合讨论核心业务系统的评估问题；第十节归纳核心业务系统的知识体系；第十一节说明核心业务系统的生命周期和工程管理问题；第十二节给出一些结论和建议。
2. 核心业务系统的典型块
首先，我们要说明典型块的由来，在核心业务系统的总体结构图中，我们介绍了内容的分块，也就是核心业务系统是由众多的块组成的，而这些分块又与组织结构有关，并分成了：
Ø 基础职能部门（如：财务、人事、办公室、……）
Ø 专业管理部门（如：车险、财险、责任险、……）
Ø 综合管理部门（如：客服、理赔、销售、……）
显然，基础职能部门管理相对通用的分支，是基础、是横向、更像是一种环境建设；专业管理部门管理相对专业的业务分支，是更具体的业务内容，是纵向；而综合管理部门是纵向的专业管理部门的复合方向，是纵向的业务层面的横向。后两部分都是强调业务层面的管理，如果我们进行模型讨论，显然是讨论的重点，而这两部分内容的讨论没有更明确的“对象”，从服务业的实际情况看，都是围绕一张服务合同进行管理的（如：保险行业，《保险学》讨论的主要对象是保险合同）。当我们把业务内容集中在合同，或者类似合同的主体（业务单证）上时，我们又会遇到新的问题，我们看到的是几十/几百的不同种类的合同（业务单证），而我们的讨论必须简单、明确，所以我们必须产生有代表性的合同，有时我们也称其为“蓝图”结构，或典型的业务内容。我们以保险行业为例，介绍它的产生和作用。

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

由图中可以看出，我们把典型块分成了三个层面。接下来我们要更具体的分析三个层面的构成。根据稳定性原则，我们先侧重分析它的数据结构（业务单证/表单），即它的“信息结构”，然后按照我们的“块”构成公式自然过渡到“业务模型”。
2.1核心业务系统“块”的记录事实层（信息模型）
一个具体的核心业务系统的内容显然是庞杂的，我们在讨论时当然要从重点入手，用蓝图的方法进行整体性的讨论，关于数据结构或信息结构的蓝图讨论可参考“行业应用软件中的词根表和库结构”一文。
核心业务系统一个最主要的功能是记录全部的业务数据，以便进行整个企业的管理。所以核心业务系统的最基础使用者是企业内的大量“内勤”人员。甚至国外的一些地方普遍的称核心业务系统为“后端办公系统”，有时候也叫“生产系统”或“交易管理系统”。
从事记录信息岗位的人员（内勤）与计算机系统使用有一个对应，从业务角度看，核心业务系统与企业的组织机构也有一个整体的对应。简单的看，企业组织机构图的整体分层对应系统的总分类，纵向机构反映企业的业务划分，一般是专门方向的，所以叫纵向（或业务管理部门），它对应我们业务处理的专业功能块。横向机构反映企业的其它支撑部门，一般是跨部门服务管理部门，所以叫横向（或职能部门），它对应我们业务处理的通用子系统和各种环境配置。这样我们就把系统的内容分类和企业的组织结构分类做了一个初始的对应。如图：

其中，“循环变化”的含义反映一种发展的变化，组织机构和系统管理内容都会不断演变，系统的功能也会不断丰富。
当我们汇集各种业务表单时，发现它们的种类和形成真是五花八门，抛开表面上的形式，我们重点讨论这些表单的组成要素。
在描述结构构成的时候，我们第二个困难之处是如何规划要素和要素的组成？而且还要确定什么是基础的要素？传统的基于E-R关系的表述是：不区分要素和要素组成的含义，而是选择任何已有对象说明它们的关系，如“数据模型资源手册”表述的那样，很多行业模型也采用这种方法，它的主要问题是：
1. 没有有效的区分要素和要素的复合（也就是区分原子和分子），也没有把基础的原子构成“环境”（或字典）；
2. 没有以要素复合进行复合规划，对不同的分子，从原子构成上进行布局规划讨论；
3. 没有对最明细、最多要素的复合引起重视，没有强调，只有最明细的复合对象，才最有“代表性”；
4. 没有强调要素复合，并不是简单的是各要素的组成，而是新的、具有新特征的对象。
举一个例子说明上述问题的含义：当我们学习一般化学时，我们会学元素周期表，也就是知道了所有的元素和元素的化合。但是对一个学习化学工程的工程师而言，他不但要知道元素周期表和元素化合的一般知识，他的重点是针对一类/几类特殊的化合物。这些化合物往往成份复杂，在工程应用中有自己的独特的特性，单纯讨论其构成元素的特性是非常不够的，因为那只是通用的特性，而领域的独特内容往往就反映在元素复合的化合物之中。面对众多的化合物，从信息论的观点看，我们要更关心最多要素聚合的化合物，因为它的信息量最大，也最有代表性，所有信息的加工操作只能使信息量变小。从数学的观点看我们更关心函数的“联合分布”，而不是它的若干“边缘分布”，因为再多的边缘分布也不能构成它的一个联合分布。关注最多要素复合对象也是解决应对信息模型需求变化的最重要方法。
所以我们给出了一种新的表述方法，即1.“要素”(环境)及2.最多要素聚合对象表示法(或某个领域纵向的明细表示法)。越是领域专家，越是对某一领域纵向的明细结构非常了解，所以我们可以把某一领域纵向的明细结构看成是这“块”内容结构的“核”。有的时候也借用它表示信息模型的蓝图结构，或者是骨架结构。
如果从“合同管理”的角度出发，我们有组成合同的要素和明细合同本身两类结构。它们可以分别比喻成化学中的元素和分子（参考“可操作型管理文件写作”一文）。

核心业务系统的基础性工作是：先要建立（环境）各要素（元素）的表单结构和数据，再根据具体的明细合同内容记录合同的有关结构。上图给出的是最简单的要素和明细结构的对应，它是一个典型的“鱼刺图”，对更一般的情况，可能是一个“树枝图”（参考“可操作型管理文件写作”一文）。
显然，记录事实层虽然侧重信息模型，或者说数据模型，但是它也有相应的流程/活动，它反映记录事实时的操作步骤，以及大量非过程性的信息结构约束活动/条件。下面，我们将结合另两个层面加以更进一步的介绍。
2.2 核心业务系统“块”的约束层（流程模型）
从管理的角度看，核心业务系统的基础工作只是记录有关的事实（千万不要轻视有体系的“记录”性工作，它是所有后续工作的基础）。在具体工作中记录事实的顺序有很多种，以此形成所谓的业务规定，很多时候我们称之为“实务”。核心业务系统的内涵就是以记录数据（信息）为主的，它的复杂性重点在结构方面。但是当我们进行更复杂的管理时，它的“重心”向“活动”方向转移，并且构成更加丰富的变化。究其根本原因，人们为了管理的目标，不满足于基础的“记录”，加入了各种各样的控制、约束、评估、……，而这个管理的框架结合我们的内容分“块”，简单的概括如下：

我们在上图中加了两类：约束类和评估类，后面我们会详细介绍它们的作用。总体而言，它是某种管理的需要，既然是管理，这些管理的主线是如何分的呢？
针对每一个要素都可能在合同明细上形成一个控制主线，作为核心业务系统约束的一部分。具体图示如下：

在约束层中，是以控制约束为主的，但是它也有新产生的“结构数据”，它是控制结构中“参数化”的部分，有时针对记录事实层的“结构数据”，被称为“元数据”，其中一部有相同业务规律结构的部分，被称为“业务规则”或称“业务约束规则”。而这些规律有时我们一开始并不熟悉，是随着我们管理的深入而渐渐明朗的。
从发展的抽象层面看，记录事实、约束和评估可以是相对的、发展的。即：记录事实融入环境，约束变成新的记录事实，评估中的稳定部门变成新的约束，对新的约束形成进一步的评估。
为了使我们的“块”最有代表性，我们从明细合同的详细要素入手，可以更好的理解这些管理的主线。有关为什么使用“明细合同”讨论，可以参考“可操作型管理文件写作”一文中的“事实表”的有关内容。也就是我们选择的“块”是最有代表性的“块”，以此进行蓝图框架的讨论。下面我们先讨论“约束层”的有关内容。它的起点是我们记录事实中的明细合同，我们进一步给出“明细合同”的结构组成：

由于合同有这么多的要素组成，它的基本操作是“全要素”的记录工作。接下来，对以每个要素为主，就会形成基于某个要素为主线的约束、管理、控制性的活动。类似的，很多管理著作中也称其为“动因”，其含义是此要素是主要原因，而其它要素是从属构成。我们将针对核心业务系统发生的管理需要，逐个要素（主线）进行讨论，以便对核心业务系统的第二层“外衣”（约束层），有一个内容的锁定，如果说“合同本体”也是一个主线的话，它已经在记录事实层主要讨论了。下面我们依次从“客户”主线讨论起。
主线1、客户：客户是合同参与者的重要要素，一般情况下是明细合同中，出钱者或服务的对象。“以客户为中心”反映企业的经营管理理念，是管理要求的重要线索。
客户可以与其它要素进行从1～N的组合，典型的有：
——客户买了多少产品，客户涉及多少个部门，客户的收费额是多少，……
——客户买了多少产品，合计收费是多少，……
……
这种以客户为中心的组合活动是不胜枚举的，所以一般“以客户为中心”的设计重点考虑两个方面：
Ø 客户的信息是否是统一存放的；
¨ 一般情况下，在一个单一系统中，客户要素的存放属于环境的一部分，是会统一存放的，而在多个系统中，有一个环境的统一问题，以及客户的唯一标识问题。
Ø 以客户要素为主线的活动设计；
¨ 一般情况下，合同的管理是以合同的记录为中心的，在实务操作上，针对客户要素的环境，会强调客户资料的保存性工作，而针对客户的、更多的涉及控制、分析的活动，则是客户主线的应用。
客户为主线的活动讨论其实比我们以上讨论的还要复杂。因为现实中，我们涉及客户的信息不只是在合同中出现，也不只是在客户要素的环境管理中出现，而是随着业务的发展和业务要求的需要，很多客户的背景信息还要不断的获取。
如：对个人客户：要了解他们的生活习惯，兴趣爱好，……
对企业客户：要了解他们的历史，经营状况，……
我们也会区分优质客户和有风险客户群。在这条主线下进行有区分的服务和控制。
这好像是外延的外延，后面我们结合独立的客户管理子系统讨论。
对待企业级客户，我们的约束主线有很多变化，一般的说，也就是所谓的团体业务或大客户业务，它需要更特殊、更不同的业务流程和更丰富的业务服务项目，这一主线是目前最为活跃和个性化最强的主线。由于团体业务的灵活性，也存在服务条款的法律风险，这也是目前的严格控制主线。
主线2、业务分类：虽然每个企业的业务分类都可能不一样，但是它们总有一个业务分类，在组织上就形成了业务管理部门，业务管理部门在企业中具有很强的专业性，所以一般也是强势部门。由于业务之间在形式上存在很大的差异，所以业务部门一般都有“我最特别”的倾向。各业务分类在合同要素选择上有一定差异，在要素取值上也侧重不同，引起的合同记录方式（活动）也变化巨大。所以业务部门一般的观点是，本业务管理的合同是不同于其它合同类型的，应该以本类业务合同为中心，建立核心业务系统。这就是“以某项业务类型为中心”的要求。
对这部分内容我们按前面介绍的那样，先分成两大部分讨论：第一部分仍是记录合同的事实；第二部分是针对不同业务管理的约束。
核心业务系统的基础先是记录合同的事实，我们要针对不同业务分类，形成相应的实务，记录合同内容，每个业务分类的实务都不一定相同。这也说明，都是记录合同的事实，但是记录的方法有时很不相同，“业务实务”实际上是操作步骤，反映记录的顺序。这类业务分类管理也有特点，越在组织管理的上层分类越明显，越在组织管理的下层越综合。因为下层面对具体的客户，综合管理效率高，而记录合同的事实更多的是在组织管理的下层进行，以保险行业为例，这也是我们强调“全险种”、“全流程”的原因。
第二部分是对各业务分类的管理要求，它侧重组织管理的上层，也是以业务特性为主线，对其它要素的组合控制，如在保险行业，它可能是核保/核赔，我们在此就不展开讨论了，但是可以看出它是以业务内容为中心的控制管理。
主线3、产品：产品是合同管理中的一个相当概念性的要素，需要理顺它的含义。产品一般反映一种权利—义务关系的代称，并侧重责任性命名。与其它要素一样，每个要素都可能含有丰富的命名和代码体系，但是服务业的产品命名显得更加丰富和变化多样。
产品的概念从分类上看可以分成三个部分，反映概念定义的延伸和扩展：

产品的命名和编码一般有两个重要的方面：⑴分类结构；⑵代码取值。它们可能形成很复杂的概念体系，并与某一行业的领域知识相对应。如：保险业，分类结构可能有四类，即：险类／产品线—险种／产品—险别(主)／主条款／主责任—险别(辅)／附加条款／辅责任。并且这种分类结构还可能继续扩充，或者有其它的组合，如：协议说明等。总之，分类是一种框架描述。代码取值涉及领域术语的概念分层和概念划分后的取值，它像字典术语一样反映具体的含义，如具体的承保条件／风险类型／责任范围…，它的复杂性在于概念的内涵和外延是变化的，有些概念(取值)与另一些概念(取值)有聚合的关系。如：综合责任(险)，打包条款(险)等。总之，一般情况下，理顺产品的分类结构和代码取值，作为产品命名已经相当复杂和困难了。
产品的内涵就是命名和编码，外延涉及合同其它要素，到底涉及多少，没有明确定义。极端情况合同的全部要素和条款才构成完整的产品。在产品代码和全部合同要素之间，为了加强产品定义的“可操作”性，一般以产品代码为主线，选几个特定的要素、要素取值和固定的活动（控制）作为产品的扩展定义。一般而言，“扩展产品”主要包括：产品及分类代码，产品涉及主要要素集合，产品针对客户要素的组合框架，产品涉及要素之间对应收/付额的计算（公式），产品相对业务分类的组成和固定流程，产品分类通用的约束框架，……。如果以上要素被定义并固定下来，它们都要与产品的分类结构代码取值一样，被事先准备在我们称为“环境”的产品要素管理之中。
总之，以产品为主线的约束是涉及很多其它要素的复合管理，产品主线的主要要求是：使核心业务系统能够快速的推出新的产品，并融入已有的管理体系，使新产品以其良好的组合性，更好的满足客户需求，……
主线4、标的物：标的物也是合同组成的重要要素之一，它反映合同所特指的一个对象物，有时它具有很多特性，其中价值和风险特性是主要考虑内容。标的物的分类几乎涉及各行各业，方式也是五花八门，与产品要素一样，它可能是一个丰富的分类结构和代码取值，在这里我们就不展开讨论了。作为要素本身的管理要在“环境”中预先建立，在明细合同中我们主要要记录涉及本合同的具体标的物。
以标的为中心的约束反映对标的更深入的控制，很多时候与标的自身的特性和风险控制有关，往往与其它要素组合形成各种约束内容。
主线5、组织机构：组织机构一般反映合同执行主体的组织，它也有很多分类，如：内勤和外勤，有时包括外围的组织，每一个组织都有很多关系表述，最简单的是分层结构。

组织的控制反映组织结构中的关系及权力分布，一般纵向机构对应“业务部门”，横向机构对应管理“职能部门”，并且分层呼应设立。地域一般指地理区域的划分，是组织划分的重要内容。内容性划分也是组织划分的重要内容，它也种类丰富，如：行业/机构分类/客户群等。
同样与其它要素组合形成涉及组织的各种约束内容，后面我们将结合评估层“以组织为中心”内容做更深入讨论。
主线6、过程状态：合同不是静止的，是随时间变化而变化的。其中重要的阶段有特定的含义，我们必须记录下来。过程状态一般会与其它管理要素结合，形成新的控制约束，……
合同的“过程状态”一个重要的分支是反映合同“交易”的过程状态，也就是合同销售的过程状态，这部分描述我们扩展一下用传统商务和电子商务分别说明，其中合同我们简称为产品。
传统商务
电子商务
1.宣传产品信息
1.发布产品信息
2.询/报价，咨询
2.询/报价，咨询
3.签协议/确认
3.下订单/确认
4.支付
4.支付/代付
5.交换实际协议
5.收/发产品正本
6.后续服务
6.后续服务

过程状态

这个过程是一个典型的销售过程，并且与“组织机构”主线密切相关，由此引出了“渠道”的概念。关于“过程状态”中交易的重点，约束层一般要解决的是如下重要的问题：
1. 信用问题：无论是“产品”还是“支付”，都存在信用问题，本主线要完成信用建立的综合管理。
2. 奖励问题：这种奖励是对交易当事人的，对卖家而言是奖励制度，就像保险行业的“销售基本法”。对买家而言是优惠，不同的客户有不同的优惠，并且有积分功能，保证短期优惠和长期优惠相结合。
3. 服务水平和质量：要非常熟悉各种综合性问题，需要支撑一个专家体系并配套相应的知识库体系，其中一个值得关注的分支叫“搜索”，或者更直接的叫“垂直搜索”。
关于各种定价和规则参数的确定，我们要结合后面章节的“成本分析”给出，它也决定着我们多渠道政策的冲突和平衡问题。
从前面的介绍我们已经看到，无论是传统商务还是电子商务，都有极其相似的“过程状态”，在这个“交易”过程中，重点是对“三流”的讨论，即：信息流、资金流和物流。本节的重点是信息流，而资金流和物流要结合后面的过程管理或称运营管理的内容中进行讨论。我们用如下图说明此环节的通用性。

我们从图中看到，合同的交易环节是一个水平通用环节，它的结构应该有标准化的倾向。实际上，确实也是这样，一个信息化的标准组织（特别侧重电子商务）是其中的代表，即OAGIS（The Open Application Group Integration Specification），由于电子商务的发展使信息技术在其中扮演越来越重要的角色，我们看到各种电子商务的网站是此类创新的先驱，由此也引出一系列非功能性问题，如：并发用户数、联机响应时间、交易的易用性、……，总之，核心业务系统的发展必然产生一个分支，以其深厚的领域背景，引领新一轮合同交易的创新浪潮。
主线7、时间期限：合同不是永远有效的，合同的有效期限也要明确的被约束，很多内容是与合同的有效期相关的。时间期限，或其它时间特性属性，一般会与其它要素结合，形成新的控制约束，……
时间和期限也区分“点”和“线”，时间一般是“点”，而期限一般是“线”。
主线8、地域：合同执行的地域是有边界的，反映合同的地区特征。不同地域的特点不同，作为一个要素它可能引起各种组合的约束变化。典型的是在组织机构图中，地域范围是主要的考虑因素。
地域也有地点和区域的区分，地点一般是“点”，而区域一般是“面”。
主线9、权限控制：合同的管理有权限的问题，它涉及合同的安全性，同时权限管理也是核心业务系统的重要基础要求，它的各种配置一般反映在环境建立过程之中，在企业的内控约束建立过程中，这一主线会起到很重要的作用。
这部分内容进一步发展，就是企业的“治理结构”和风险管理，它的一个通用性框架是《企业风险管理—整体框架》，它是COSO委员会在结合《萨班斯—奥克斯利法案》简称“萨班斯法案”基础上发布的。相应的内容我们将结合后面章节的组织主线综合和核心业务系统“块”的三层体系结构加以讨论。
主线10、收/付费控制：无论是收费还是付费都是合同条款的重要内容。首先必须逐一记录，然后与其它要素结合，形成相应的控制约束，并与重要的财务系统进行对接。
主线11、收/付费额：收/付费额是合同的主要标量，是合同各项价值计算的基础。在合同的明细表中，本标量是对应所有要素的信息，在各类管理控制过程中，涉及的数量（标量）信息一般都与本内容有关。
以上这些主线就形成了企业控制（约束）管理的主线条，也就产生了各种“中心论”，如：以客户为中心，以产品为中心，以某项业务为中心，以过程状态/交易/销售为中心，以权限控制（风险控制）为中心，……。其实这些中心论，反映管理一个时期的重点，也叫“缺什么补什么”，或者叫“三十年河东，三十年河西”。同时反映了企业管理的综合特性，也反映核心业务系统的综合特性。约束层是一个使核心业务系统不断膨胀的管理约束层，与各要素相关反映一种个性化的管理要求。在一个高速发展的市场环境下，是一个以定制化为主体的软件开发层，相对于记录事实层，它是核心业务系统的第一层外延。
2.3核心业务系统“块”的评估层（优化模型）
核心业务系统的评估层是在约束层之上的一层，是对约束层的约束。如果把约束层看成是一般的管理措施的话，评估层是对这些管理措施的评价。一般人们认为管理总是好的。但实际上，也有很多越管越乱、越管越差的情况，所以管理改进的重要内容是评估层要解决的问题。
在单一“块”内的评估层，反映本块各约束主线的效果评价，它也比较好理解，但是一般系统的评价往往是综合的，是跨“块”的（跨越合同管理的内容），所以我们将结合后面各块的综合，结合核心业务系统要完成的总目标，进行评估层综合的讨论。实际上，评估层中的一部分内容是独立于核心业务系统之外的。
2.4核心业务系统“块”的三层体系归纳
核心业务系统典型“块”的三层结构图如下：

这三层结构的重点是不同的，其要点可以归纳为“唯实、求真、协力、创新”，这也是中国科学院的行为准则。记录事实层对应“唯实、求真”，反映对基础数据真实性的要求和结构合理性的要求，很多集中管控的内容都是针对这部分内容，因为有人为了各种原因，总是篡改/修改基础的事实数据。约束层对应“协力”，反映控制、约束的目标是要形成合力，完成管理的目标，这是精