核心业务系统的内容讨论完整版.docx
《核心业务系统的内容讨论完整版.docx》由会员分享，可在线阅读，更多相关《核心业务系统的内容讨论完整版.docx（36页珍藏版）》请在冰豆网上搜索。
核心业务系统的内容讨论完整版
核心业务系统的内容讨论（管理篇）
中科软科技股份XX
左春
1.核心业务系统概述
1.1引言
在开发行业应用软件的过程中，有一个系统的称呼很有意思，叫核心业务系统。
从表面上理解，核心业务系统就是该行业的“核心”的应用软件。
本文就试图针对一些服务性行业，从内容构成上讨论一下这个核心业务系统的内涵和外延。
核心业务系统本质上也是一个“综合”管理信息系统，为了突出重点和更有针对性，我们以服务行业（如：
金融、电信、……）为背景，讨论有关的内容。
从大的方面看，以服务行业为主要业务的核心业务，重点是围绕“合同管理”和“项目管理”进行（后面我们会说明理由）。
“合同管理”反映企业与客户之间的契约管理，它是服务和业务管理的综合体现，“项目管理”反映企业内部组织过程管理，它涉及合同管理，同时也涉及企业内部的组织管理、核算和资源的合理运用。
由于涉及的头绪太多、太复杂，我们需要一个基本的框架来定位核心业务系统的主要内容。
核心业务系统应该是一个计算机的管理系统，但是在没有这个计算机管理系统之前，一定有一个根源性的东西，它来支撑管理的进行，为了叙述的方便，我们把这个根源性的东西叫可操作管理文件（参考“可操作型管理文件写作”一文），也就是说，是一个管理文件。
“可操作”是对格式的要求，其根本的目的是使可操作管理文件与相应的计算机管理系统有相似的结构，这样的可操作性，使我们可以在不同的层面讨论核心业务系统，这样的表达也便于不同知识背景的人员相互沟通。
我们的基本框架由三个层面组成：
——业务管理层面：
对应可操作管理文件；
——软件系统需求/设计层面：
对应需求设计文档；
——计算机系统层面：
对应计算机管理系统。
三个层面都有明确的成果物：
文件、文档和系统。
它们的组成内容可以进一步细化为：
——可操作管理文件：
①文件的分章、分块构成。
每一块中：
②表单（业务单据）和③活动（业务流程，业务规则），④文件的环境描述。
——软件系统的需求和设计：
①需求/设计的总体功能组成和每部分概括说明。
每一部分中：
②表单（业务单据），业务操作界面，数据库结构和③流程描述（业务流程，业务规则），④需求和设计的环境说明。
——计算机管理系统：
①系统的整体功能，主菜单。
每一个功能中：
②表单（业务单据），操作界面，数据结构和③具体操作步骤说明（业务流程，业务规则），④系统的环境说明。
三个层面结构是“同构”的，但是内容是逐层细化的。
上一层对下一层看起来像是框架、蓝图。
而下层针对上层而言，就是这个蓝图的细化。
如：
在可操作管理文件层，我们提出表单（业务单据），这是业务层面最直接的管理结果，没有计算机系统，或不同能力的计算机系统都可能满足这层的要求。
但是到了软件系统需求/设计层，就增加了产生表单（业务单据）的计算机“操作界面”的描述，而且配套相应的操作流程和规则。
到了计算机管理系统层面，就要在上面的基础上，进一步讨论。
表单（业务单据）的数据结构，数据库存贮和交互操作更详细的数据操作内容。
分层讨论，它的好处是我们先从主要的问题点入手，并且越来越关注业务操作细节的实现，最终借助软件系统这个工具进行管理。
本文由于侧重管理的表述（管理篇），所以采用侧重可操作管理文件层为基础的讨论,这样可以讨论大的管理框架和蓝图，规划和兼顾（同构）实现技术的内容和层次，突出讨论核心业务系统的管理“原理”。
作为核心业务系统的概述，我们更重要的是给出它的内容体系和管理目标。
核心业务系统内容体系也是本文的内容体系应该包括：
1.核心业务系统的整体结构/总体结构；
2.核心业务系统内外部环境及标准化；
3.典型组成部分的结构和组成分析；
4.各组成部分之间的关系和综合管理、优化。
通过对核心业务系统内容体系的讨论，完成如下的管理目标：
1.调整/创新管理的机制，促进业务的增长；
2.提高运行效率，降低综合成本；
3.优化运营环境，合理运用资源；
4.规X管理体系，控制经营风险。
要使这些管理目标得以实现，就需要我们通过本文的讨论建立管理目标和内容体系的关系。
1.2核心业务系统框架结构
针对核心业务系统的内容体系，我们给出核心业务系统的总体结构图：
可以看出三个层面的四个组成部分具有相对应的内容。
我们在上图中使用了术语“内容分类”或“块”、“具体流程”、“具体表单”，它们与行业内的很多术语的关系是什么呢？
我们第一个概念“内容分类”有“分层”和“组成”的概念（有时也称“概念分层”和“概念划分”，参考“行业应用软件中的词根表和库结构”一文）。
“内容分类”是行业内容的“体系结构”，有很多种分类策略，如：
按企业的组织机构分类、图书馆的目录分类、系统工程中的系统分类、领域对象的体系结构、……，总之，这就是核心业务系统的总体结构，也是本文的总体介绍。
在我们具体结构图中，“内容分类”显得非常重要。
以保险行业为例，我们看看传统的《保险学》是如何分类的，即：
社会保险/商业保险，法定保险/自愿保险，人身保险/财产保险，……。
或者换一个角度，按保险性质分类（商业、社会、政策、……），按保险标的分类（财产、人身、责任、信用保证、……），按危险转移层次分类（原保险、再保险、共同保险，……），按实施方式分类（强制、自愿、……），按经营主体分类，按客户群分类，按承保的危险分类，按保额确定方式分类，……
相对于核心业务系统，这些领域分类的方法缺乏整体结构的讨论。
那么内容分类是否有统一的标准呢？
在有些行业中，有自己的行业分类具体标准，这是行业标准化的一个重要内容，遗憾的，是不是所有行业都有这样的标准。
而且在很多的情况下，这类的标准使用还有很大的局限性，这样的话，我们的“内容分类”是否还有参考对象？
在实际应用中，我们往往会参考企业的组织结构。
这种组织结构往往反映一种分类体系，在行业中也有很多的相似性，更重要的是它与核心业务系统一样都有很强的实务操作要求，所以我们的内容分类主要可以先源于某一个组织结构，虽然我们发现几乎没有两个企业的组织结构是完全相同的，但是从功能和职能看，它们都是极其相似的，作为蓝图讨论的话，它们是共有的。
很显然，组织结构不是一成不变的，它的变化反映业务发展的要求和一系列的优化评估原则，本文也将结合系统的综合评估内容做出进一步的讨论。
以财产保险为例，我们简单的说明组织结构的分类：
基础职能部门：
财务部、人事部、办公室、法务部、审计部、信息技术部、……
专业管理部门：
车辆保险部、财产保险部、船舶货运保险部、责任信用保险部、意外健康险保险部、再保险部、……
综合业务管理部门：
客户服务部、理赔管理部、销售管理部、电子商务部、银行业务部、团体业务部、……
这种划分的方法在结构上看分为：
纵向、横向和交叉管理。
一般我们认为基础职能部门是管理横向，专业管理部门是管理纵向，而综合业务管理部门反映的是部分纵向的汇集。
作为一个核心业务系统的框架，显然要覆盖以上的分类内容，无论是横向还是纵向都是我们形成管理条/块的基础。
进一步在条/块的划分中，我们也有元素粒度的概念，这与我们现实中的语义概念也是一致的。
如在现实中，我们有一个“合同”的概念，“合同”是由“条款项”组成的，而“条款项”是由“具体元素”组成的，这与化学工程相似，如：
内容
类比化学
粒度
合同
大分子
大块
合同条款项
中分子
中块
客户、产品、……
原子
小块
以保险为例，典型的大“块”是合同管理，因为它概括内容分类的主体，翻开任何一本《保险学》的著作，“保险合同”这一章一定是全书的重点。
在下面的介绍中，我们会逐步深入讨论有关的内容。
实际上，分类的方法很多，但也可以分成两大部分，即概念分层和概念划分，涉及上面业务内容的重点是概念分层，下面我们介绍典型的概念划分方法，其中有代表性的、概念划分的分类方法有：
八卦、五行、5WH，它们的特点是“划分”均匀完整，是一种很好的、概括全面的、内容分类工具。
业务内容分类涉及不断变化和发展的领域内容，非常类似“语言”的内容分类，更像基于某种用途的语义网络或语义结构层次，而其中的使用的基本元素就是领域中约定俗成的术语（及含义）。
这类分类在开始的时候可能是各行其是，有自己的表达和相近的含义，而且彼此不能证明对方是错的，只有发展到一定程度后做某种程度的统一。
就像秦朝统一之前，七国各有相似的文字，而秦始皇统一了全部的文字，其实我们看到这些文字在统一之前已经相当类似了。
简单的说，相似的分类方式也是一种存在的方式。
就像我们看到的不同银行、保险公司，电信企业有很相近的组织结构，但是并没有完全统一（显然，目前核心业务系统也没有统一，但是我们可能看到系统的功能菜单是一样的！
）。
所以，内容分类本质上是想表示现行运行体系下，业务内容的概念结构体系，找出它们的相对稳定和规律性的内容，形成相对统一的蓝图模型，以此为基础进行表达和沟通。
内容分类的另一个主要目的是解决什么内容应该放在什么地方的问题，就像古代人为圣人语录和经书做目录和内容分类，以便后人在学习时可以按主题学习。
这样在沟通过程中，便于引导和讨论。
在领域内容分类的初期，由于是仿照业务的组织结构进行，当然有一定的内容重复和交叉。
就像组织体系中，有的事谁都管，有的事似乎谁都不管，甚至于出现“见好处就上，见问题就让”的情况。
实际上，内容分类就是不断解决出现的问题，虽然似乎无法根除，但是会达成一个平衡状态，分出的“块”也越来越合理。
当我们讨论越来越多的复杂分块时，我们还有一个重要的抽象方法，就是提出有代表性的“块”，它是一组有复杂关系“块”的代表“块”。
也可以称为“蓝图块”，或者称“典型块”，以此加强更高层面沟通的效率。
就像人们去买房子，你看到的是“楼书”（蓝图说明），而不是几米高的“工程图”集。
有关的内容我们还会在后面不同的地方，陆续讨论。
针对具体的一个“块”，我们先给出它的一般结构：
即“块”是由“活动”和“表单”组成的。
1.“块”的相似称呼：
服务/对象/组件/业务/功能/任务/对象类/包/…（名词和动名词为主）。
它衍生的模型称呼有：
服务模型，业务模型，功能模型，…
2.“表单”的相似称呼：
表单（据/证）/数据/界面/信息/数据库/数据结构/结构/…（名词为主）。
它衍生的模型称呼有：
数据模型，信息模型，数据库模型，…
3.“活动”的相似称呼：
活动/流程/步骤/程序/战术/处理/作业/操作/记录/…（动词和动名词为主）。
它衍生的模型称呼有：
流程模型，程序模型，战术方法模型，…
三个对象的称呼有时混用，它反映对其中一部分内容的侧重讨论，由于这么多的在不同层面的叫法和称呼，就很容易引起混淆，所以在一个具体问题表述时，尽量统一相关术语。
从基础内容上看，针对三个对象又确实存在可相互转换的本质，每一部分又有其独立强调的内容，所以在讨论具体问题时，针对问题的特点有侧重的选择一种对象加以讨论。
三个对象（块、具体流程和具体表单）的关系可以进一步示意如下：
这种表述方法在文件、文档和系统中是相似的。
为什么一个计算机管理系统的介绍采用与管理文件写作的框架一致呢？
因为我们对核心业务系统的讨论也是一种文档，也要表达或写出来，它也需要遵照科技和管理业务文献写作的格式进行。
即：
先就内容做整体性的描述，这样能看清系统的全貌；其次，为每一部分系统分析它的稳定部分的组成，最典型的方法是采用表单或数据库结构（有时也称为它的“信息结构”）；然后，针对这样的信息结构讨论具体的操作/控制顺序。
而环境是所表达内容的背景描述，它的介绍有多种方法，可以先介绍基础元素（顺叙），也可以后介绍基础元素（倒叙），这看我们的写作规划。
总之，我们在介绍核心业务系统时，要有一个整体框架。
1.3本文要解决的重点问题
有了核心业务系统的内容框架，我们还要结合前面给出的系统目标，并引出目前的问题，以此讨论本文要解决的重点问题。
本文要解决的重点问题由如下图所示：
有关专家已经提出了目前核心业务系统的三高状况，即“高期望”、“高依赖”和“高失望”。
“高期望”反映管理的目标，“高依赖”反映管理对核心业务系统的依赖，“高失望”主要反映“期望”和“现实功能”之间没有一个好的内容体系做桥梁，用以沟通“过粗”的管理目标和“过细”的功能实现。
本文试图解决这样的问题。
本文的主要结构包括：
在引言中提出一个内容体系；在第二节中主要介绍一个典型的业务块，即合同管理“块”，用以反映核心业务系统的基础；第三节介绍核心系统内“块”之间的相邻特性；第四节讨论核心业务系统的整个环境体系；第五节则介绍核心系统的发展和演化，用以形成的外围子系统；第六节讨论核心系统的分布和外挂；第七节讨论核心业务系统与行业标准化的关系；第八节讨论核心业务系统运营管理问题；第九节综合讨论核心业务系统的评估问题；第十节归纳核心业务系统的知识体系；第十一节说明核心业务系统的生命周期和工程管理问题；第十二节给出一些结论和建议。
2.核心业务系统的典型块
首先，我们要说明典型块的由来，在核心业务系统的总体结构图中，我们介绍了内容的分块，也就是核心业务系统是由众多的块组成的，而这些分块又与组织结构有关，并分成了：
Ø基础职能部门（如：
财务、人事、办公室、……）
Ø专业管理部门（如：
车险、财险、责任险、……）
Ø综合管理部门（如：
客服、理赔、销售、……）
显然，基础职能部门管理相对通用的分支，是基础、是横向、更像是一种环境建设；专业管理部门管理相对专业的业务分支，是更具体的业务内容，是纵向；而综合管理部门是纵向的专业管理部门的复合方向，是纵向的业务层面的横向。
后两部分都是强调业务层面的管理，如果我们进行模型讨论，显然是讨论的重点，而这两部分内容的讨论没有更明确的“对象”，从服务业的实际情况看，都是围绕一X服务合同进行管理的（如：
保险行业，《保险学》讨论的主要对象是保险合同）。
当我们把业务内容集中在合同，或者类似合同的主体（业务单证）上时，我们又会遇到新的问题，我们看到的是几十/几百的不同种类的合同（业务单证），而我们的讨论必须简单、明确，所以我们必须产生有代表性的合同，有时我们也称其为“蓝图”结构，或典型的业务内容。
我们以保险行业为例，介绍它的产生和作用。
典型的合同或有代表性的合同，像“楼书”反映我们讨论问题的本质，是模型讨论的重点，它的要求是：
Ø在结构上，要有代表性，所以元素的明细项要多;
Ø在内容上，要忽视一定的细节，或用上位概念进行讨论。
有了这个典型的结构，大大简化了我们专业沟通的复杂性，提高了表达的效率，强化了典型结构对具体结构的“指导”意义。
用同样的原理，各职能部分形成的内容，也是“块”，但它与典型的合同块相对应，是侧重合同要素管理的专业块，相对合同块而言，它是环境块。
同样，各专业业务合同也有自己的环境，即，代码元素的描述等，它们也像“典型”的合同块一样抽象为一个“典型”的环境，即，典型的代码元素描述。
由于原理是完全一样的，在此不再赘述。
上面我们介绍了核心业务系统的典型块的由来和作用，下面我们把重点放在典型块之中，特别是“合同管理”明细对象上，我们先给出一个典型块的组成。
由图中可以看出，我们把典型块分成了三个层面。
接下来我们要更具体的分析三个层面的构成。
根据稳定性原则，我们先侧重分析它的数据结构（业务单证/表单），即它的“信息结构”，然后按照我们的“块”构成公式自然过渡到“业务模型”。
2.1核心业务系统“块”的记录事实层（信息模型）
一个具体的核心业务系统的内容显然是庞杂的，我们在讨论时当然要从重点入手，用蓝图的方法进行整体性的讨论，关于数据结构或信息结构的蓝图讨论可参考“行业应用软件中的词根表和库结构”一文。
核心业务系统一个最主要的功能是记录全部的业务数据，以便进行整个企业的管理。
所以核心业务系统的最基础使用者是企业内的大量“内勤”人员。
甚至国外的一些地方普遍的称核心业务系统为“后端办公系统”，有时候也叫“生产系统”或“交易管理系统”。
从事记录信息岗位的人员（内勤）与计算机系统使用有一个对应，从业务角度看，核心业务系统与企业的组织机构也有一个整体的对应。
简单的看，企业组织机构图的整体分层对应系统的总分类，纵向机构反映企业的业务划分，一般是专门方向的，所以叫纵向（或业务管理部门），它对应我们业务处理的专业功能块。
横向机构反映企业的其它支撑部门，一般是跨部门服务管理部门，所以叫横向（或职能部门），它对应我们业务处理的通用子系统和各种环境配置。
这样我们就把系统的内容分类和企业的组织结构分类做了一个初始的对应。
如图：
其中，“循环变化”的含义反映一种发展的变化，组织机构和系统管理内容都会不断演变，系统的功能也会不断丰富。
当我们汇集各种业务表单时，发现它们的种类和形成真是五花八门，抛开表面上的形式，我们重点讨论这些表单的组成要素。
在描述结构构成的时候，我们第二个困难之处是如何规划要素和要素的组成？
而且还要确定什么是基础的要素？
传统的基于E-R关系的表述是：
不区分要素和要素组成的含义，而是选择任何已有对象说明它们的关系，如“数据模型资源手册”表述的那样，很多行业模型也采用这种方法，它的主要问题是：
1.没有有效的区分要素和要素的复合（也就是区分原子和分子），也没有把基础的原子构成“环境”（或字典）；
2.没有以要素复合进行复合规划，对不同的分子，从原子构成上进行布局规划讨论；
3.没有对最明细、最多要素的复合引起重视，没有强调，只有最明细的复合对象，才最有“代表性”；
4.没有强调要素复合，并不是简单的是各要素的组成，而是新的、具有新特征的对象。
举一个例子说明上述问题的含义：
当我们学习一般化学时，我们会学元素周期表，也就是知道了所有的元素和元素的化合。
但是对一个学习化学工程的工程师而言，他不但要知道元素周期表和元素化合的一般知识，他的重点是针对一类/几类特殊的化合物。
这些化合物往往成份复杂，在工程应用中有自己的独特的特性，单纯讨论其构成元素的特性是非常不够的，因为那只是通用的特性，而领域的独特内容往往就反映在元素复合的化合物之中。
面对众多的化合物，从信息论的观点看，我们要更关心最多要素聚合的化合物，因为它的信息量最大，也最有代表性，所有信息的加工操作只能使信息量变小。
从数学的观点看我们更关心函数的“联合分布”，而不是它的若干“边缘分布”，因为再多的边缘分布也不能构成它的一个联合分布。
关注最多要素复合对象也是解决应对信息模型需求变化的最重要方法。
所以我们给出了一种新的表述方法，即1.“要素”（环境）及2.最多要素聚合对象表示法（或某个领域纵向的明细表示法）。
越是领域专家，越是对某一领域纵向的明细结构非常了解，所以我们可以把某一领域纵向的明细结构看成是这“块”内容结构的“核”。
有的时候也借用它表示信息模型的蓝图结构，或者是骨架结构。
如果从“合同管理”的角度出发，我们有组成合同的要素和明细合同本身两类结构。
它们可以分别比喻成化学中的元素和分子（参考“可操作型管理文件写作”一文）。
核心业务系统的基础性工作是：
先要建立（环境）各要素（元素）的表单结构和数据，再根据具体的明细合同内容记录合同的有关结构。
上图给出的是最简单的要素和明细结构的对应，它是一个典型的“鱼刺图”，对更一般的情况，可能是一个“树枝图”（参考“可操作型管理文件写作”一文）。
显然，记录事实层虽然侧重信息模型，或者说数据模型，但是它也有相应的流程/活动，它反映记录事实时的操作步骤，以及大量非过程性的信息结构约束活动/条件。
下面，我们将结合另两个层面加以更进一步的介绍。
2.2核心业务系统“块”的约束层（流程模型）
从管理的角度看，核心业务系统的基础工作只是记录有关的事实（千万不要轻视有体系的“记录”性工作，它是所有后续工作的基础）。
在具体工作中记录事实的顺序有很多种，以此形成所谓的业务规定，很多时候我们称之为“实务”。
核心业务系统的内涵就是以记录数据（信息）为主的，它的复杂性重点在结构方面。
但是当我们进行更复杂的管理时，它的“重心”向“活动”方向转移，并且构成更加丰富的变化。
究其根本原因，人们为了管理的目标，不满足于基础的“记录”，加入了各种各样的控制、约束、评估、……，而这个管理的框架结合我们的内容分“块”，简单的概括如下：
我们在上图中加了两类：
约束类和评估类，后面我们会详细介绍它们的作用。
总体而言，它是某种管理的需要，既然是管理，这些管理的主线是如何分的呢？
针对每一个要素都可能在合同明细上形成一个控制主线，作为核心业务系统约束的一部分。
具体图示如下：
在约束层中，是以控制约束为主的，但是它也有新产生的“结构数据”，它是控制结构中“参数化”的部分，有时针对记录事实层的“结构数据”，被称为“元数据”，其中一部有相同业务规律结构的部分，被称为“业务规则”或称“业务约束规则”。
而这些规律有时我们一开始并不熟悉，是随着我们管理的深入而渐渐明朗的。
从发展的抽象层面看，记录事实、约束和评估可以是相对的、发展的。
即：
记录事实融入环境，约束变成新的记录事实，评估中的稳定部门变成新的约束，对新的约束形成进一步的评估。
为了使我们的“块”最有代表性，我们从明细合同的详细要素入手，可以更好的理解这些管理的主线。
有关为什么使用“明细合同”讨论，可以参考“可操作型管理文件写作”一文中的“事实表”的有关内容。
也就是我们选择的“块”是最有代表性的“块”，以此进行蓝图框架的讨论。
下面我们先讨论“约束层”的有关内容。
它的起点是我们记录事实中的明细合同，我们进一步给出“明细合同”的结构组成：
由于合同有这么多的要素组成，它的基本操作是“全要素”的记录工作。
接下来，对以每个要素为主，就会形成基于某个要素为主线的约束、管理、控制性的活动。
类似的，很多管理著作中也称其为“动因”，其含义是此要素是主要原因，而其它要素是从属构成。
我们将针对核心业务系统发生的管理需要，逐个要素（主线）进行讨论，以便对核心业务系统的第二层“外衣”（约束层），有一个内容的锁定，如果说“合同本体”也是一个主线的话，它已经在记录事实层主要讨论了。
下面我们依次从“客户”主线讨论起。
主线1、客户：
客户是合同参与者的重要要素，一般情况下是明细合同中，出钱者或服务的对象。
“以客户为中心”反映企业的经营管理理念，是管理要求的重要线索。
客户可以与其它要素进行从1～N的组合，典型的有：
——客户买了多少产品，客户涉及多少个部门，客户的收费额是多少，……
——客户买了多少产品，合计收费是多少，……
……
这种以客户为中心的组合活动是不胜枚举的，所以一般“以客户为中心”的设计重点考虑两个方面：
Ø客户的信息是否是统一存放的；
♦一般情况下，在一个单一系统中，客户要素的存放属于环境的一部分，是会统一存放的，而在多个系统中，有一个环境的统一问题，以及客户的唯一标识问题。
Ø以客户要素为主线的活动设计；
♦一般情况下，合同的管理是以合同的记录为中心的，在实务操作上，针对客户要素的环境，会强调客户资料的保存性工作，而针对客户的、更多的涉及控制、分析的活动，则是客户主线的应用。
客户为主线的活动讨论其实比我们以上讨论的还要复杂。
因为现实中，我们涉及客户的信息不只是在合同中出现，也不只是在客户要素的环境管理中出现，而是随着业务的发展和业务要求的需要，很多客户的背景信息还要不断的获取。
如：
对个人客户：
要了解他们的生活习惯，兴趣爱好，……
对企业客户：
要了解他们的历史，经营状况，……
我们也会区分优质客户和有风险客户群。
在这条主线下进行有区分的服务和控制。
这好像是外延的外延，后面我们结合独立的客户管理子系统讨论。
对待企业级客户，我们的约束主线有很多变化，一般的说，也就是所谓的团体业务或大客户业务，它需要更特殊、更不同的业务流程和更丰富的业务服务项目，这一主线是目前最为活跃和个性化最强的主线。
由于团体业务的灵活性，也存在服务条款的法律风险，这也是目前的严格控制主线。
主线2、业务分类：
虽然每个企业的业务分类都可能不一样，但是它们总有一个业务分类，在组织上就形成了业务管理部门，业务
升级会员 