某公司核心业务管理知识系统分析.docx
《某公司核心业务管理知识系统分析.docx》由会员分享,可在线阅读,更多相关《某公司核心业务管理知识系统分析.docx(49页珍藏版)》请在三一办公上搜索。
1、核心业务系统的内容讨论(管理篇)中科软科技股份有限公司左 春1目 录1.核心业务系统概述11.1 引言11.2 核心业务系统框架结构31.3 本文要解决的重点问题72.核心业务系统的典型块72.1核心业务系统“块”的记录事实层(信息模型)92.2 核心业务系统“块”的约束层(流程模型)122.3核心业务系统“块”的评估层(优化模型)192.4核心业务系统“块”的三层体系归纳203.核心业务系统内“块”之间的相邻214.核心业务系统的环境层225.核心业务系统的“核”和外围子系统256.核心业务系统的分布和外挂267.核心业务系统与行业标准化278.核心业务系统中核心运营管理289.核心业务系统
2、的评估层综合2910.归纳核心业务系统的知识体系3911.核心业务系统的生命周期4012.结论411. 核心业务系统概述1.1 引言在开发行业应用软件的过程中,有一个系统的称呼很有意思,叫核心业务系统。从表面上理解,核心业务系统就是该行业的“核心”的应用软件。本文就试图针对一些服务性行业,从内容构成上讨论一下这个核心业务系统的内涵和外延。核心业务系统本质上也是一个“综合”管理信息系统,为了突出重点和更有针对性,我们以服务行业(如:金融、电信、)为背景,讨论有关的内容。 从大的方面看,以服务行业为主要业务的核心业务,重点是围绕“合同管理”和“项目管理”进行(后面我们会说明理由)。“合同管理”反映
3、企业与客户之间的契约管理,它是服务和业务管理的综合体现,“项目管理”反映企业内部组织过程管理,它涉及合同管理,同时也涉及企业内部的组织管理、核算和资源的合理运用。由于涉及的头绪太多、太复杂,我们需要一个基本的框架来定位核心业务系统的主要内容。核心业务系统应该是一个计算机的管理系统,但是在没有这个计算机管理系统之前,一定有一个根源性的东西,它来支撑管理的进行,为了叙述的方便,我们把这个根源性的东西叫可操作管理文件(参考“可操作型管理文件写作”一文),也就是说,是一个管理文件。“可操作”是对格式的要求,其根本的目的是使可操作管理文件与相应的计算机管理系统有相似的结构,这样的可操作性,使我们可以在不
4、同的层面讨论核心业务系统,这样的表达也便于不同知识背景的人员相互沟通。我们的基本框架由三个层面组成:业务管理层面:对应可操作管理文件;软件系统需求/设计层面:对应需求设计文档;计算机系统层面:对应计算机管理系统。 三个层面都有明确的成果物:文件、文档和系统。它们的组成内容可以进一步细化为:可操作管理文件:文件的分章、分块构成。每一块中:表单(业务单据)和活动(业务流程,业务规则),文件的环境描述。软件系统的需求和设计:需求/设计的总体功能组成和每部分概括说明。每一部分中:表单(业务单据),业务操作界面,数据库结构和流程描述(业务流程,业务规则),需求和设计的环境说明。计算机管理系统:系统的整体
5、功能,主菜单。每一个功能中:表单(业务单据),操作界面,数据结构和具体操作步骤说明(业务流程,业务规则),系统的环境说明。 三个层面结构是“同构”的,但是内容是逐层细化的。上一层对下一层看起来像是框架、蓝图。而下层针对上层而言,就是这个蓝图的细化。如:在可操作管理文件层,我们提出表单(业务单据),这是业务层面最直接的管理结果,没有计算机系统,或不同能力的计算机系统都可能满足这层的要求。但是到了软件系统需求/设计层,就增加了产生表单(业务单据)的计算机“操作界面”的描述,而且配套相应的操作流程和规则。到了计算机管理系统层面,就要在上面的基础上,进一步讨论。表单(业务单据)的数据结构,数据库存贮和
6、交互操作更详细的数据操作内容。分层讨论,它的好处是我们先从主要的问题点入手,并且越来越关注业务操作细节的实现,最终借助软件系统这个工具进行管理。本文由于侧重管理的表述(管理篇),所以采用侧重可操作管理文件层为基础的讨论,这样可以讨论大的管理框架和蓝图,规划和兼顾(同构)实现技术的内容和层次,突出讨论核心业务系统的管理“原理”。作为核心业务系统的概述,我们更重要的是给出它的内容体系和管理目标。核心业务系统内容体系也是本文的内容体系应该包括:1. 核心业务系统的整体结构/总体结构;2. 核心业务系统内外部环境及标准化;3. 典型组成部分的结构和组成分析;4. 各组成部分之间的关系和综合管理、优化。
7、通过对核心业务系统内容体系的讨论,完成如下的管理目标:1. 调整/创新管理的机制,促进业务的增长;2. 提高运行效率,降低综合成本;3. 优化运营环境,合理运用资源;4. 规范管理体系,控制经营风险。要使这些管理目标得以实现,就需要我们通过本文的讨论建立管理目标和内容体系的关系。1.2 核心业务系统框架结构 针对核心业务系统的内容体系,我们给出核心业务系统的总体结构图: 可以看出三个层面的四个组成部分具有相对应的内容。我们在上图中使用了术语“内容分类”或“块”、“具体流程”、“具体表单”,它们与行业内的很多术语的关系是什么呢?我们第一个概念“内容分类”有“分层”和“组成”的概念(有时也称“概念
8、分层”和“概念划分”,参考“行业应用软件中的词根表和库结构”一文)。“内容分类”是行业内容的“体系结构”,有很多种分类策略,如:按企业的组织机构分类、图书馆的目录分类、系统工程中的系统分类、领域对象的体系结构、,总之,这就是核心业务系统的总体结构,也是本文的总体介绍。在我们具体结构图中,“内容分类”显得非常重要。以保险行业为例,我们看看传统的保险学是如何分类的,即:社会保险/商业保险,法定保险/自愿保险,人身保险/财产保险,。或者换一个角度,按保险性质分类(商业、社会、政策、),按保险标的分类(财产、人身、责任、信用保证、),按危险转移层次分类(原保险、再保险、共同保险,),按实施方式分类(强
9、制、自愿、),按经营主体分类,按客户群分类,按承保的危险分类,按保额确定方式分类,相对于核心业务系统,这些领域分类的方法缺乏整体结构的讨论。那么内容分类是否有统一的标准呢?在有些行业中,有自己的行业分类具体标准,这是行业标准化的一个重要内容,遗憾的,是不是所有行业都有这样的标准。而且在很多的情况下,这类的标准使用还有很大的局限性,这样的话,我们的“内容分类”是否还有参考对象?在实际应用中,我们往往会参考企业的组织结构。这种组织结构往往反映一种分类体系,在行业中也有很多的相似性,更重要的是它与核心业务系统一样都有很强的实务操作要求,所以我们的内容分类主要可以先源于某一个组织结构,虽然我们发现几乎
10、没有两个企业的组织结构是完全相同的,但是从功能和职能看,它们都是极其相似的,作为蓝图讨论的话,它们是共有的。很显然,组织结构不是一成不变的,它的变化反映业务发展的要求和一系列的优化评估原则,本文也将结合系统的综合评估内容做出进一步的讨论。以财产保险为例,我们简单的说明组织结构的分类:基础职能部门:财务部、人事部、办公室、法务部、审计部、信息技术部、专业管理部门:车辆保险部、财产保险部、船舶货运保险部、责任信用保险部、意外健康险保险部、再保险部、综合业务管理部门:客户服务部、理赔管理部、销售管理部、电子商务部、银行业务部、团体业务部、这种划分的方法在结构上看分为:纵向、横向和交叉管理。一般我们认
11、为基础职能部门是管理横向,专业管理部门是管理纵向,而综合业务管理部门反映的是部分纵向的汇集。作为一个核心业务系统的框架,显然要覆盖以上的分类内容,无论是横向还是纵向都是我们形成管理条/块的基础。进一步在条/块的划分中,我们也有元素粒度的概念,这与我们现实中的语义概念也是一致的。如在现实中,我们有一个“合同”的概念,“合同”是由“条款项”组成的,而“条款项”是由“具体元素”组成的,这与化学工程相似,如:内 容类比化学粒 度合 同大分子大 块合同条款项中分子中 块客户、产品、原 子小 块以保险为例,典型的大“块”是合同管理,因为它概括内容分类的主体,翻开任何一本保险学的著作,“保险合同”这一章一定
12、是全书的重点。在下面的介绍中,我们会逐步深入讨论有关的内容。实际上,分类的方法很多,但也可以分成两大部分,即概念分层和概念划分,涉及上面业务内容的重点是概念分层,下面我们介绍典型的概念划分方法,其中有代表性的、概念划分的分类方法有:八卦、五行、5WH,它们的特点是“划分”均匀完整,是一种很好的、概括全面的、内容分类工具。业务内容分类涉及不断变化和发展的领域内容,非常类似“语言”的内容分类,更像基于某种用途的语义网络或语义结构层次,而其中的使用的基本元素就是领域中约定俗成的术语(及含义)。这类分类在开始的时候可能是各行其是,有自己的表达和相近的含义,而且彼此不能证明对方是错的,只有发展到一定程度
13、后做某种程度的统一。就像秦朝统一之前,七国各有相似的文字,而秦始皇统一了全部的文字,其实我们看到这些文字在统一之前已经相当类似了。简单的说,相似的分类方式也是一种存在的方式。就像我们看到的不同银行、保险公司,电信企业有很相近的组织结构,但是并没有完全统一(显然,目前核心业务系统也没有统一,但是我们可能看到系统的功能菜单是一样的!)。所以,内容分类本质上是想表示现行运行体系下,业务内容的概念结构体系,找出它们的相对稳定和规律性的内容,形成相对统一的蓝图模型,以此为基础进行表达和沟通。内容分类的另一个主要目的是解决什么内容应该放在什么地方的问题,就像古代人为圣人语录和经书做目录和内容分类,以便后人
14、在学习时可以按主题学习。这样在沟通过程中,便于引导和讨论。在领域内容分类的初期,由于是仿照业务的组织结构进行,当然有一定的内容重复和交叉。就像组织体系中,有的事谁都管,有的事似乎谁都不管,甚至于出现“见好处就上,见问题就让”的情况。实际上,内容分类就是不断解决出现的问题,虽然似乎无法根除,但是会达成一个平衡状态,分出的“块”也越来越合理。当我们讨论越来越多的复杂分块时,我们还有一个重要的抽象方法,就是提出有代表性的“块”,它是一组有复杂关系“块”的代表“块”。也可以称为“蓝图块”,或者称“典型块”,以此加强更高层面沟通的效率。就像人们去买房子,你看到的是“楼书”(蓝图说明),而不是几米高的“工
15、程图”集。有关的内容我们还会在后面不同的地方,陆续讨论。针对具体的一个“块”,我们先给出它的一般结构: 即“块”是由“活动”和“表单”组成的。1. “块”的相似称呼:服务/对象/组件/业务/功能/任务/对象类/包/(名词和动名词为主)。它衍生的模型称呼有:服务模型,业务模型,功能模型,2. “表单”的相似称呼:表单(据/证)/数据/界面/信息/数据库/数据结构/结构/(名词为主)。它衍生的模型称呼有:数据模型,信息模型,数据库模型,3. “活动”的相似称呼:活动/流程/步骤/程序/战术/处理/作业/操作/记录/ (动词和动名词为主)。它衍生的模型称呼有:流程模型,程序模型,战术方法模型, 三个
16、对象的称呼有时混用,它反映对其中一部分内容的侧重讨论,由于这么多的在不同层面的叫法和称呼,就很容易引起混淆,所以在一个具体问题表述时,尽量统一相关术语。从基础内容上看,针对三个对象又确实存在可相互转换的本质,每一部分又有其独立强调的内容,所以在讨论具体问题时,针对问题的特点有侧重的选择一种对象加以讨论。三个对象(块、具体流程和具体表单)的关系可以进一步示意如下:这种表述方法在文件、文档和系统中是相似的。为什么一个计算机管理系统的介绍采用与管理文件写作的框架一致呢?因为我们对核心业务系统的讨论也是一种文档,也要表达或写出来,它也需要遵照科技和管理业务文献写作的格式进行。即:先就内容做整体性的描述
17、,这样能看清系统的全貌;其次,为每一部分系统分析它的稳定部分的组成,最典型的方法是采用表单或数据库结构(有时也称为它的“信息结构”);然后,针对这样的信息结构讨论具体的操作/控制顺序。而环境是所表达内容的背景描述,它的介绍有多种方法,可以先介绍基础元素(顺叙),也可以后介绍基础元素(倒叙),这看我们的写作规划。总之,我们在介绍核心业务系统时,要有一个整体框架。1.3 本文要解决的重点问题有了核心业务系统的内容框架,我们还要结合前面给出的系统目标,并引出目前的问题,以此讨论本文要解决的重点问题。本文要解决的重点问题由如下图所示: 有关专家已经提出了目前核心业务系统的三高状况,即“高期望”、“高依
18、赖”和“高失望”。“高期望”反映管理的目标,“高依赖”反映管理对核心业务系统的依赖,“高失望”主要反映“期望”和“现实功能”之间没有一个好的内容体系做桥梁,用以沟通“过粗”的管理目标和“过细”的功能实现。本文试图解决这样的问题。本文的主要结构包括:在引言中提出一个内容体系;在第二节中主要介绍一个典型的业务块,即合同管理“块”,用以反映核心业务系统的基础;第三节介绍核心系统内“块”之间的相邻特性;第四节讨论核心业务系统的整个环境体系;第五节则介绍核心系统的发展和演化,用以形成的外围子系统;第六节讨论核心系统的分布和外挂;第七节讨论核心业务系统与行业标准化的关系;第八节讨论核心业务系统运营管理问题
19、;第九节综合讨论核心业务系统的评估问题;第十节归纳核心业务系统的知识体系;第十一节说明核心业务系统的生命周期和工程管理问题;第十二节给出一些结论和建议。2. 核心业务系统的典型块首先,我们要说明典型块的由来,在核心业务系统的总体结构图中,我们介绍了内容的分块,也就是核心业务系统是由众多的块组成的,而这些分块又与组织结构有关,并分成了: 基础职能部门(如:财务、人事、办公室、) 专业管理部门(如:车险、财险、责任险、) 综合管理部门(如:客服、理赔、销售、)显然,基础职能部门管理相对通用的分支,是基础、是横向、更像是一种环境建设;专业管理部门管理相对专业的业务分支,是更具体的业务内容,是纵向;而
20、综合管理部门是纵向的专业管理部门的复合方向,是纵向的业务层面的横向。后两部分都是强调业务层面的管理,如果我们进行模型讨论,显然是讨论的重点,而这两部分内容的讨论没有更明确的“对象”,从服务业的实际情况看,都是围绕一张服务合同进行管理的(如:保险行业,保险学讨论的主要对象是保险合同)。当我们把业务内容集中在合同,或者类似合同的主体(业务单证)上时,我们又会遇到新的问题,我们看到的是几十/几百的不同种类的合同(业务单证),而我们的讨论必须简单、明确,所以我们必须产生有代表性的合同,有时我们也称其为“蓝图”结构,或典型的业务内容。我们以保险行业为例,介绍它的产生和作用。典型的合同或有代表性的合同,像
21、“楼书”反映我们讨论问题的本质,是模型讨论的重点,它的要求是: 在结构上,要有代表性,所以元素的明细项要多; 在内容上,要忽视一定的细节,或用上位概念进行讨论。有了这个典型的结构,大大简化了我们专业沟通的复杂性,提高了表达的效率,强化了典型结构对具体结构的“指导”意义。用同样的原理,各职能部分形成的内容,也是“块”,但它与典型的合同块相对应,是侧重合同要素管理的专业块,相对合同块而言,它是环境块。同样,各专业业务合同也有自己的环境,即,代码元素的描述等,它们也像“典型”的合同块一样抽象为一个“典型”的环境,即,典型的代码元素描述。由于原理是完全一样的,在此不再赘述。上面我们介绍了核心业务系统的
22、典型块的由来和作用,下面我们把重点放在典型块之中,特别是“合同管理”明细对象上,我们先给出一个典型块的组成。由图中可以看出,我们把典型块分成了三个层面。接下来我们要更具体的分析三个层面的构成。根据稳定性原则,我们先侧重分析它的数据结构(业务单证/表单),即它的“信息结构”,然后按照我们的“块”构成公式自然过渡到“业务模型”。2.1核心业务系统“块”的记录事实层(信息模型) 一个具体的核心业务系统的内容显然是庞杂的,我们在讨论时当然要从重点入手,用蓝图的方法进行整体性的讨论,关于数据结构或信息结构的蓝图讨论可参考“行业应用软件中的词根表和库结构”一文。 核心业务系统一个最主要的功能是记录全部的业
23、务数据,以便进行整个企业的管理。所以核心业务系统的最基础使用者是企业内的大量“内勤”人员。甚至国外的一些地方普遍的称核心业务系统为“后端办公系统”,有时候也叫“生产系统”或“交易管理系统”。从事记录信息岗位的人员(内勤)与计算机系统使用有一个对应,从业务角度看,核心业务系统与企业的组织机构也有一个整体的对应。简单的看,企业组织机构图的整体分层对应系统的总分类,纵向机构反映企业的业务划分,一般是专门方向的,所以叫纵向(或业务管理部门),它对应我们业务处理的专业功能块。横向机构反映企业的其它支撑部门,一般是跨部门服务管理部门,所以叫横向(或职能部门),它对应我们业务处理的通用子系统和各种环境配置。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 某公司 核心 业务 管理知识 系统分析

链接地址:https://www.31ppt.com/p-1983450.html