EAS组织架构详解

上传人:1777****777 文档编号:43405169 上传时间:2021-12-01 格式:DOC 页数:41 大小:1.29MB
收藏 版权申诉 举报 下载
EAS组织架构详解_第1页
第1页 / 共41页
EAS组织架构详解_第2页
第2页 / 共41页
EAS组织架构详解_第3页
第3页 / 共41页
资源描述:

《EAS组织架构详解》由会员分享,可在线阅读,更多相关《EAS组织架构详解(41页珍藏版)》请在装配图网上搜索。

1、EAS组织架构详解EAS组织架构详解朱涛2007-9-5企业组织架构在信息系统的应用架构中用模型化的方式构建和表达出来就是组织模型,它是一种知识结构的系统反映,就如企业模型是全面反映企业知识结构的模型表现。组织模型作为企业模型中的一个重要组成部分,首要目的就是必须要能够清晰描述企业中各种组织对象、组织对象间的联系以及与其他企业视图模型间的关系,并且能够用一定的方式诸如职责、权限的形式定义企业成员、企业的各个组织的作用与任务。它处理的是基于组织开展业务的模式。本文内容主要分为四个部分:第一部分:描述组织架构模型的基本目标;第二部分:描述组织架构模型的各种基本要素以及内在联系;例如组织模型中的组织

2、类型、业务视图、责任委托、管理单元、主业务组织等;第三部分:描述组织架构跟金蝶BOS其他基础服务的关系。组织模型贯穿于企业应用中的各个方面,它跟权限模型、基础数据模型等都有密切的联系,完整支持业务流程的方方面面;第四部分:描述组织架构模型在企业信息化中的基本应用模式;1.1 组织模型的基本目标现代企业必须善于运用新技术、新手段、新的管理模式改变自己的业务模式,获取创新带来的垄断利润,这些新的技术,新手段,新的管理模式极大的提高了沟通效率,降低了沟通成本,加快了信息传递的速度,降低了获取信息的成本,加强了对于业务的控制能力以及应对未来的能力。新技术,尤其是信息技术的典型特点是:可以克服因为地域、

3、组织的行政架构或者法人架构上的限制获取充分的决策信息,能够迅速的根据业务变化作出正确的反映。一个趋势是:组织结构变得越来越有弹性,如果业务汇报关系、业务处理能力可以更加有效的进行集中调度和控制。同时,为迅速应对企业外部和内部环境的变化,企业需要迅速的作出组织和业务流程上的调整,这种调整不一定是实际的行政架构或者法人架构的调整,而是虚拟组织关系的调整,如汇报关系调整、业务汇总关系的调整、业务管理范围的调整等,在变化越来越迅速的今天,基于业务控制的虚拟组织调整能力的需求也正在迅速增加。金蝶EAS组织架构模型正是基于以上诉求而设计,它是金蝶BOS企业模型中的一个重要组成部分。它充分考虑了动态企业建模

4、的组织维度,为企业提供了对业务流程和组织架构的灵活定制能力,支持企业中任意组织层次的集中或分散的复杂混合管理模式。同时,能够定义组织间的复杂协同关系,提供基于虚拟组织的业务协同与控制的调整能力,不管组织间的关系如何调整,其调整都只是调整该组织模型,而不必调整企业模型中的其他部分(如功能模型、信息模型、流程模型等),保证现代企业能够充分应对快速多变的竞争环境。从传统的组织行为学的角度来看,“组织(orgniazation)”一词来源“器官(organ)”,因为器官是自成系统的具有特定功能的细胞结构,后来又演化为专门之人群,运用于社会管理中。在中国古代,组织一词用来指把丝麻织成布。固有“树桑麻,习

5、组织”的说法。所以,组织是体现一定社会关系、具有一定结构形式并且不断从外部汲取资源以实现其目标的集合体。通俗的来说,组织就是一群人为了某些目标在一起组成的一个团队。如何定义这些团队的目标、相关的人员、任务以及描述这些团队和团队之间的关系,用模型化的方式加以表达出来就有了组织模型。从信息系统的角度来说,组织架构模型是各项应用的重要支撑。金蝶EAS组织架构模型是为处理多公司、多工厂、多地点的协同业务而设计的。力求为各项应用提供基于组织的灵活性和扩展性。例如,要能支持企业总部或事业部间不同的管理控制模式、支持不同类型的公司间业务处理的协同方式、支持不同类型业务组织间的业务协同、支持多种业务汇报关系、

6、支持不同组织结构下的业务汇总与分解关系等等。因此通过组织模型把企业的业务集成的表达和管理起来,组织起多个业务系统。信息系统中多个不同的业务系统如何共享同样的基础数据?业务流如何完整的贯通并且集成起来?不同系统之间的数据如何穿透查询、汇总统计和分析?在应用层面,这些都可以通过组织模型有机的贯穿起来。从应用层面来看,对于没有集成的单线的业务系统,它们之间的交互是非常困难的,不同的系统之间都有自己的基础资料,相互之间需要定时保持同步,成本很高;相互之间的业务处理数据无法共用和按流程来处理,多个系统之间的数据无法共用,难以提供整体的决策分析能力。金蝶EAS组织架构模型能够灵活的支持集团企业的各种管理模

7、式的贯彻,包括集中管理与业务监控,让企业根据需要灵活调整集中管理与监控的力度,可以组合出各种混合管理模式,以及非常细化的逐层控制。从信息系统以及SOA服务的角度来归纳金蝶EAS组织模型的设计目标如下:u 实现支持集权、分权或者混合管理模式的组织模型,包括基本共享环境的分配(紧密管理还是分散管理)、基本共享环境的共享和复制(政策控制强度和粒度);u 实现矩阵管理模型,横向的信息共享、协作与控制与纵向的业务集中管理(基于虚体的统计查询、汇报关系);u 实现组织间业务协作模式(业务的集中与分散),包括责任类型以及责任描述等等;u 组织隔离(管理权的集中与分散),组织隔离的概念不是业务组织的区别,而是

8、基本共享环境的区别,主要包括用户、权限、流程、BOTP、参数、预警、基础档案的隔离;下图反映了金蝶EAS组织架构模型的基本组成:EAS组织架构基本模型示意图1.2 组织架构基本模型金蝶BOS的组织架构模型是一种多组织架构模型(有多种业务组织类型),它跟单组织架构系统的重大区别和优势在于:不需要多余的数据上报处理,组织间根据业务需要和权限控制可以相互引用数据;同时还支持跨公司的业务处理流程的实现、支持跨公司的管理控制, 能够确保上级组织管理意图的实现,例如财务政策、销售政策的执行,在支持多公司业务时确保各公司独立的管理政策。从基本概念来理解,金蝶BOS的组织架构模型主要有以下关键概念,包括:组织

9、类型、组织单元、业务视图、责任委托、主业务组织、管理单元等。下面我们将详细介绍。1.2.1 组织类型&业务组织什么是组织类型?金蝶EAS组织架构模型是一种多组织模型,之所以称之为多组织模型,首先因为它是把组织单元分为多种类型的。什么是组织类型?组织类型就是根据组织单元处理业务的能力对组织进行分类,一种组织类型是一种业务处理能力的描述,组织类型首先是作为统计口径提出的,但好的组织模型应该支持对任意的组织类型进行集中与分散处理。为什么要分组织类型?在前面说过,组织是有目标的,一个组织可能有很多目标,但是在金蝶EAS组织架构模型中,一种业务组织是只有一种特定的目标,这也就是多种组织类型的由来。那么为

10、什么需要划分多种组织类型?人在社会中是分角色的,每个人有多种角色,这个易于理解。一群人在一起,就形成了一个组织。组织作为人的延伸,在社会中、企业中当然也是分角色的,作为不同的角色它有着不同的目标,组织的角色延伸下去就是组织的类型。组织类型就是用来为组织的每种角色明确权责,让各个组织以及组织的各个角色彼此协同又相互制衡。组织类型的作用组织类型在组织模型中的意义是为了信息系统能够更加精细的控制业务政策,对于不同的业务政策方式,可以通过增加业务组织来隔离和处理;同时,还为了能够更加精细的控制业务处理逻辑和流程,通过细化不同业务组织的业务处理逻辑和流程,可以有针对性的根据业务设计流程和商业处理逻辑。而

11、且随着企业应用的逐渐增加,组织类型还可以继续增加和扩展。组织类型的实例在金蝶EAS组织架构模型中组织类型分为行政组织、财务组织、采购组织、库存组织、销售组织、责任中心、HR组织(人力资源组织)、管理单元等八大类。其中,除了行政组织以外其他组织类型都可以称之为业务组织。在金蝶EAS组织架构模型中,企业的具体业务行为即由这些具体的业务组织负责执行与实施,业务组织体现了企业在业务上的一个横向管理关系。也就是说,业务活动的主要载体是业务组织。它们各自承载特定的业务,并负责制定跟本类业务相关的业务政策。业务组织是各类业务管理的边界,也是业务数据隔离的边界。简单的说就是:业务组织是“业务系统”的概念,他代

12、表该组织可以做什么事。金蝶EAS组织架构模型之所以以这样的粒度来设计组织类型,主要基于以下两方面的考虑:1、以业务流作为第一区分粒度。因为企业发展变化中,通常业务管理是以业务流的分离和合并变化为多,如物流和信息流的分离、资金流与信息流的分离等,总之物流、信息流、资金流是第一区分粒度;2、以业务处理的业务规则为区分粒度。因为业务规则具有依赖性明确特征,如财务处理的业务规则和采购的业务规则几乎是完全没有交集的。对于各种具体的组织类型的解释行政组织:对应于企业中真实存在的组织单元,它记录了企业的职位、人员等重要基本信息。在处理人力资源业务时,是被核算的基础资料;在采购和销售业务中,是执行部门或单位;

13、在财务处理中,如果没有使用责任中心,通常作为成本载体用以辅助核算;财务组织:核算主体或会计主体。有一套完整的会计账簿,能够独立出三大报表:资产负债表(Balance sheet,简称B/S)、损益表(Profit and loss statement,简称P/L)、现金流量表(Cash flow statement,简称C/F),有独立的资产、负债、权益、成本、损益分类数据。换言之,就是能够把B/S做平的最小核算单位。采购组织:采购组织是负责为一个或多个单位采购物料和提供服务以及与供应商协商价格和供货条款的组织单位。从执行角度看,可能是一个或多个采购部门;采购组织在采购业务中有着重要作用,是业

14、务政策的主要载体和统计维度。库存组织:库存组织管理实际物资。对于制造企业来说,库存组织可以是一个独立进行MRP运算的工厂;对于流通企业,库存组织可以是一个配送中心,是一个独立的库存管理组织的单位。库存组织下可以有一个或多个所属仓库,一个库存组织只能属于一个财务组织,一个财务组织可以有多个库存组织。同时,库存组织还代表了物的所有权。销售组织:销售组织是指企业按照一定的业务模式(往往按照事业部形态)区分出的一种组织模式,是能够独立或相对独立运作销售业务的公司或部门的集合。其基本特征是:在同一销售组织内,统一销售政策(如:价格、信用)、统一市场政策(如:促销、评价)、统一业务规则(如:订单审批规则、

15、回款要求、开票要求)。销售组织在销售业务中有着重要作用;责任中心:责任中心是承担一定经济责任,并享有一定权利和利益的企业内部单位或责任单位。责任中心可以是企业的组织、地点、项目组。责任中心主要用于确定投资、成本、利润产生于组织内的何处。责任中心主要分为两类包含:利润中心、成本中心。HR组织:HR组织首先是人力资源业务系统的概念,它记录职务、职务体系、新酬薪点、薪点方案,行政组织及其上的职位人员等所有HR信息。HR组织同时还是是报告层次载体,HR组织是人力资源的标准报告层次。管理单元:Control Unit,简称CU。金蝶EAS组织架构模型抽象的一个独特的概念。管理单元代表了一套基础数据上下文

16、环境,是一个基础数据共享范围,是共享模型中的隔离区域,体现了管理权的分离。管理单元是业务政策的主要分配路线,并且能够据此调整管理控制力度。设置管理单元是为了能够更好的政策集中管理。深入理解组织类型(业务组织)组织单元标示了组织类型(业务属性)以后就成了业务组织。业务组织的分类即组织类型反映了业务设计的合适度原则,这来源于业务的分析,因此业务组织的概念既是设计的概念,也是业务的概念。业务组织具有系统性,这个系统性表现为边界性和识别范围。例如,同样的基础资料在不同的系统中具有不同的意义(如物料主数据的采购属性对于不同的采购组织可以不同),例如对于某一业务对象,对于不同的系统的可见范围是不同的(如物

17、料主数据在不同的系统中的可见范围就是不同的)。通常情况下,业务组织可以对应于某个行政组织,业务组织更多地是从工作结构关系上进行定义的,体现为业务的基本单元,与行政组织体现的层次不一样,是具体操作层次的业务团队。对于企业内部的明细业务组织来说,大多数时候跟企业的行政组织并不会一一对应,要看业务覆盖的范围以及统计、管理的需要,例如一个采购组织可能对应于一个采购部门,也可能对应一个采购中心,或者对应于一个物资公司,甚至对应于一个管理单元。所以说,业务组织相对行政组织来说,它更多的体现的是虚拟组织的概念,而行政组织大多数情况才对应企业中真实存在的组织单元。业务组织是业务政策的主要载体,也就是说关于企业

18、实际业务的业务规则都是制定在业务组织上的。实际具体的业务开展也是以业务组织为载体,而管理单元是管理基础的数据环境,并为业务组织实现组织间的共享。在后续其他章节中还会重点介绍管理单元在企业管理中的具体运用以及管理单元对于企业管理模式的重要影响。当然,对于信息系统来说,业务规则不只是表现为业务政策,还表现为一整套总体规则,例如流程的协作规则、报告的规则等等。如下图:业务变化与组织变更业务变化实际上是业务规则的变化:即业务运做的规则和业务协作模式的变化。业务变化通常是市场和技术发生了变化,市场变化产生新的商业机会,如国际市场;还有技术变化产生新的手段,如网上营销。业务变化与行政组织变化没有关系,在金

19、蝶EAS组织架构模型中,主要体现为业务组织变化,也就是体现为服务的变化。业务报告层次的变化,可以变更汇总关系;业务范围的变化,可以增加或者封存业务组织;业务流程的变化,可以调整业务委托协作关系,等等。因此,业务组织的变更和行政组织的变更实际上往往是分离的,业务组织本身就是虚拟的,其目的就是为了动态反映业务的变化;而行政组织的变更,更多的是体现在人员的变更、业务执行单位的变更(当然有时候也会业务组织和行政组织一起变更),在企业中,大多数情况下都只是行政组织的变更,而业务以及业务组织并没有发生变化,这一点要注意区分。1.2.2 组织架构树&组织单元组织架构树组织架构的基本元素就是组织单元(Orgn

20、iazation Unit,简称OU),组织单元是组成组织架构的一个个独立的节点。企业中所有组织单元通过上下级联系在一起就形成了企业组织架构树。企业组织架构树反映的是组织单元之间的关系。组织架构树用以形成缺省的汇报以及委托关系(委托关系在后续章节中会谈到)。实际在业务中,并不需要直接用到企业组织架构树,而是根据业务类型使用相应的业务视图(见下一节)。例如从不同角度审视的企业的法人架构、行政架构和管理架构等等,就是企业组织架构的不同视图。一般来说,企业的行政组织架构树跟组织单元通过上下级关系直接形成的组织架构有类似之处,在给企业实施组织架构的时候,组织单元的划分一般也是依据企业的行政组织单元来划

21、分粒度,但是并不严格对应,要看实际需要。组织单元所有的组织都是由组织单元构成(管理单元也是组织单元的一种)。组织单元是一个抽象的概念,它只有在跟组织类型关联以后才有具体的业务语义,在金蝶EAS组织架构模型中,业务组织就是在组织单元上标明业务属性而得到的。组织单元组织间的关系组织与组织之间通过各种方式联系在一起,也就是说组织与组织之间存在各种关系。组织间的关系有多种,主要可以归纳为四种:u 业务汇报关系;u 业务汇总关系;u 业务委托关系;u 业务执行关系;业务汇报关系:定义不同业务层面下职位的上下级关系,汇报关系在业务语义上更多的表现为领导关系,体现的是权力意志,因此汇报关系是基于职位来定义的

22、,跟行政组织挂钩,同时考虑到矩阵管理架构,金蝶EAS组织架构模型还支持对于一套行政组织架构定义多套汇报关系。金蝶BOS工作流建模时使用汇报关系。业务汇总关系:从业务汇总的角度建立组织之间的关系。在金蝶BOS的组织架构模型中,允许使用多层次的、灵活的汇总关系。在建立组织单元的时候,通过不断往下延伸的叶子节点,缺省形成了各类业务组织的缺省汇总关系。但是也可以根据实际业务的需要,指定每个组织单元作为不同组织类型时的上级组织,这就形成了不同组织类型的不同汇总关系。同时,在企业组织架构中,抽象的组织单元是要求必须连续的,而且组织架构必须是树状结构,不是网状结构(每个叶子节点必须有上级),但是组织单元所具

23、有的组织属性却不是必须连续的(但是要求业务视图上下级连续)。例如一个组织单元的业务属性是采购组织,那么组织模型并不要求它的下级节点组织单元必须具有采购组织属性。这样,就形成了不同业务视图之间不同的汇总关系。至于汇总关系的层级多少,要看业务类型以及具体业务的要求。例如作为采购组织的汇总层次,一般在企业中并不会有很多级,但是作为销售组织的汇总层次,往往会比较深,例如从经销商、办事处到省区,再到大区、销售中心以及集团。业务委托关系:一个业务组织只有一个目标,只处理一类业务,处理其他业务只能由其他业务组织协同完成,这种组织之间的业务协同关系在金蝶EAS组织架构模型中被称为责任委托。业务执行关系:在金蝶

24、EAS组织架构模型中,业务组织主要是业务线的业务规则的载体,而行政组织则是具体的执行组织,二者之间的关系为业务执行关系,如一个公司存在N个业务部门,都可以独立采购,但业务操作方式没有区别,整个公司只设置一个采购组织就够了,但是执行部门则是N个业务部门。业务执行关系也可以看成一种委托关系,业务组织委托行政组织执行。企业组织结构可以以各种关系建立不同的组织结构,在金蝶EAS组织架构模型中里实现的组织结构包括:组织架构树(根据企业法人架构和行政上下级建立的组织架构)、汇报关系视图(根据行政组织的职位上下级关系建立的视图)、业务视图(根据业务汇总和分解关系形成的组织架构)、委托关系视图(根据委托关系建

25、立的组织架构)下面两节将详细介绍业务视图和委托关系。1.2.3 业务视图金蝶EAS组织架构模型是一个单组织架构树、多业务视图的多组织模型。所谓单组织架构树就是用一套组织单元搭建出来的,但是因为组织单元分了很多组织类型,每一种组织类型通过指定的上下级关系形成了自己的业务视图,既然有多种组织类型,那么就有了多个业务视图。所有的业务视图都是基于同一棵基本的组织架构树抽取出来的,不同类型的业务组织视图通过抽象的组织单元是对应起来的。多业务视图说明:与之区分的另外一种多组织架构实现方式是每个业务组织视图都是一棵单独的组织架构树,彼此之间并没有对应关系。跟金蝶EAS组织架构模型相比,这种实现方式并无所谓好

26、坏之分,只是不同厂商对于组织模型的理解和实现方式不同。组织模型在信息系统中更多的都是一个设计上的概念,如何抽象如何构建组织模型,业界并无规范,看各个厂商如何运用组织模型在信息系统中表达业务而已,金蝶EAS组织架构模型更加注重组织模型作为基础模型对于业务的持续扩展能力。业务视图使用的场合如前所述,在金蝶BOS整个体系中,企业组织架构树并不直接出现在各个业务领域中。各个业务领域实际上是使用相应的业务视图。例如采购相关业务使用的是采购组织视图,销售相关业务使用的是销售组织视图。因为组织类型是各种业务的边界,如果直接使用组织架构树会导致业务类型也就是组织类型不匹配而无法使用。组织架构树用于缺省建立业务

27、视图和缺省的委托关系。虚体&实体各个业务视图实际上是报告层次体现,反映的同类型业务组织之间的汇总关系。在金蝶EAS组织架构模型中,“虚体”是一个重要的概念(可以参考图组织单元中的相关设置),在每一种业务视图中都有相应的虚体和实体(除了管理单元,管理单元也有业务视图,但是管理单元不分虚体和实体)。虚体:是指那些在业务视图上的非叶子节点组织(是业务视图上的非叶子组织,不是组织架构树上的非叶子节点组织),即:有业务下级的业务组织。注意:虚体一律是针对业务组织的,至于抽象的组织单元本身是没有虚体和实体之分的。例如,对于采购组织视图来说,某组织单元可能表现为虚体,但是对于财务组织业务视图来说,它有表现为

28、实体。所以某个OU到底是虚体还是还是实体,必须跟具体的业务组织联系起来。实体:是指那些在业务视图上的最明细的叶子节点组织(是业务视图上的叶子节点,但是不一定是组织架构树上的叶子节点)。实体和虚体有一个共同的作用,就是它们都可以作为业务政策的载体。区别在于实体业务组织是从事具体业务的节点,而虚体是不能发生具体业务的,虚体是汇总查询和数据统计的口径。作为一种灵活性,金蝶EAS组织架构模型允许调整业务组织的上级,也就是可以保持行政组织架构不变的同时改变业务上级,改变业务视图,同时也就改变了汇总关系(参与图组织单元中的上级组织相关设置)。这种灵活的汇总关系表式对于在信息系统中建立多级报告体系是十分方便

29、的,并且是自适应和增加的。可以由系统自动根据虚体汇总关系汇总数据,并且层层展开下级的明细数据。虚体查询的例子不同的业务视图代表了不同的汇总关系不同业务组织形成的业务视图可能是完全不同的,例如采购组织视图和财务组织视图就可能完全不同,这是因为不同业务的汇总口径和路线可能完全不同,这是由业务特点决定的。金蝶EAS组织架构模型中形成业务视图是通过指定业务上级形成的。例如如下的组织架构树和业务视图:组织架构树中共有七个组织单元。比较有说明意义的是A21、A22两个组织单元:它们的组织属性表明它们既是采购组织又是财务组织,而且当这两个组织单元作为采购组织时,它们的业务上级并不是通过组织架构树形成的缺省上

30、级A2(A2也没法作为它们的采购组织上级,因为组织类型都不同),而是另行指定的A1。由此,根据这个组织架构树形成的财务组织视图有四个组织单元,分别是:A0、A2、A21、A22;由此形成的采购组织视图有六个组织单元,分别是: A0、A1、A11、A12、A21、A22。1.2.4 责任委托责任委托常常也称作业务委托。每种业务组织的职责是明确的,例如财务组织负责财务核算,采购组织负责采购,库存组织负责库存事务,等等,但是企业中几乎每一个完整的业务流程都无法由一种组织独立完成,必然需要跟其他的业务组织协同工作,这种协同关系就通过业务委托来实现。业务委托的主要意义在于处理多个不同类型组织之间的业务协

31、同,形成完整的业务流,并对业务流加以约束和控制。责任类型业务委托根据委托性质定义为不同的类型:记账委托、采购委托、销售委托、库存委托、行政委托、HR委托。责任委托委托关系的委托方和责任方的对应关系可能是一对一,也可能是多对一,甚至是多对多。例如在集中销售的场景下,一个库存组织可能委托多个销售组织进行销售;在集中采购的场景下,一个库存组织也完全可能委托多个采购组织采购,因为不同的材料采购活动可能是不同的采购组织负责的。但是对于记帐委托来说,所有业务组织对财务组织的委托关系都是一对一的,多个业务组织可以委托同一个财务组织记帐,但是一个业务组织只能委托一个财务组织记帐。因为财务组织相当于一个独立的账

32、簿。如果一个业务流程中业务委托关系涉及到了两个以上的不同的财务组织,这就实际上产生了内部交易。例如集中采购的集中订货、分开收货、集中结算的业务模式下,下属公司的库存组织共同委托总部采购中心采购,而下属公司和总部都是独立核算的,这时候虽然物流是一体的(总部采购结算、下属公司收货),但是因为是总部采购中心集中结算,所以在财务上实际上已经跨越了两个财务组织,所以系统需要自动内部结算,产生内部应收应付。业务委托的特点u 业务委托具有方向性;业务委托分为委托方和责任方,委托关系的出发点是委托方,目标点是责任方,任何委托在理论上都是双向的,而且委托和反向委托的业务类型肯定是不同的。任何一个委托关系,双方都

33、同时是责任方和委托方,除非另外显式指定。u 业务委托区分为指定委托和缺省委托,实质不变。u 如果一个组织单元同时具有多种业务组织属性,那么可能会自己委托自己;只有业务组织的实体才能指定委托关系,虚体因为不发生业务,所以不需要指定委托关系;u 业务委托关系广泛应用于业务系统中,根据委托关系找组织,例如:根据财务组织找行政组织、根据采购组织找库存组织。委托关系示例说明:某集团协同模型如下图说明:集团公司下面有四个下属公司,都是独立核算。其中物资公司负责物资集中采购,负责采购手机厂和彩电厂的大宗关键原辅材料采购;手机厂和彩电厂这两个工厂不独立销售,他们的产品都由销售公司集中销售,则集团内各子公司间的

34、业务委托关系如下图:进一步说明,业务委托在金蝶EAS组织架构模型中的积极作用在于:1、支持业务集中处理例如:集中HR业务操作,行政组织委托HR组织;例如:集中采购业务操作,库存组织委托采购组织,如下图:采购委托2、业务边界十分清楚因为不同的业务组织负责不同的业务,委托关系则表达了业务流上的上下游关系。3、控制流程的可见范围控制流程的可见范围主要是用来防止在多组织的业务系统的中业务权限和边界扩散。它可以用来业务操作中过滤上游组织,例如如采购订单选择特定的、合适的库存组织;可以用来在业务操作中过滤下游组织,例如采购订单选择发运组织或收货库存组织。它还可以用来业务流的转换过程中的上拉下推的组织过滤。

35、1.2.5 主业务组织定义&作用主业务组织相当于一个业务分类,信息系统中的任何实体(包括基础资料和业务单据)都存在一个组织代表了其业务分类,其内部处理过程都需要根据该主业务组织执行基于组织的总体规则和业务规则,金蝶EAS组织架构模型中任何一种业务组织在其相应的业务中都可以是主业务组织。主业务组织在金蝶EAS组织架构模型中的地位非常重要,一个完整的业务流程是需要多个不同的组织协同完成的,但是在业务流程的某个节点上,或者是某一些节点上,肯定是某个业务组织是起着主导的作用,由其他业务组织类配合。这个主导作用的业务组织决定业务流程上某个节点的业务性质,这个组织就叫做主业务组织。主业务组织相当于SOA中

36、定义服务的过程,通过定义业务组织属性决定了某个业务组织所能提供的服务,然后通过主业务组织把所有功能联系起来成为一个完整的系统,构建一个完整的业务流程。如下图,在金蝶BOS BIM中指定业务单据的主业务组织:主业务组织举例在金蝶EAS组织架构模型中,主数据的主业务组织是管理单元(例如物料、客户、供应商的主业务组织是管理单元),财务核算的主业务组织是财务组织(例如凭证、费用报销单的主业务组织是财务组织),HR业务的主业务组织是HR组织(例如薪酬方案、绩效考核方案的主业务组织是HR组织),采购业务的主业务组织是采购组织(例如采购订单的主业务组织是采购组织),销售业务的主业务组织是销售组织(例如销售订

37、单的主业务组织是销售组织)等等。数据隔离前面在谈业务组织的时候也提到,业务数据是以业务组织作为隔离边界的,其实,进一步的深入的理解应该是:每种业务数据以哪种业务组织作为主业务组织,它就以哪种业务组织作为隔离边界。例如采购订单是以采购组织作为主业务组织的,那么采购订单默认就是以采购组织作为隔离的,不同采购组织的订单不会放在一起呈现,保证了数据的默认隔离,所以说,主业务组织是数据隔离的默认边界。这样就能让业务数据有序、有范围的存放和查询统计。而业务组织实际上是虚拟组织的概念,所以业务数据的存放实际上也是以虚拟组织的边界粒度存放,不受实际行政组织、部门的约束。如果业务数据需要跨组织共享,通过权限和后

38、面章节要谈到的组织架构模型提供的共享模型来实现。业务政策任何一个业务实体围绕着主业务组织描述其业务,使用根据主业务组织制定的业务政策,例如销售订单使用的主要业务政策是销售订单的主业务组织销售组织上定义的价格政策。组织协同业务流程需要多个组织协同,单个业务节点都是必然以某个主业务组织为主导,其他业务组织是流程上的辅助方。体现在单据上、单据的流程关联上,主业务组织是以用户的权限范围过滤的,保证了有权限的用户才能操作相关业务;对于非主业务组织,只是使用业务委托关系来过滤的,不需要另外判断组织权限,因为单个业务节点的权限检查主业务组织的权限就足够了(参见采购委托一图中的设置)。主业务组织和委托关系不同

39、业务流程中的不同业务节点的主业务组织是不同的,根据业务性质不同,任何一个业务组织既可能是委托方也可能是责任方(受托方),当业务组织作为主业务组织的时候,它必然是委托关系中的受托方,因为主业务组织是提供服务的一方。因此,取得委托关系需要根据主业务组织区分方向性。在BOS BIM中设置委托关系:1.2.6 管理单元为什么需要管理单元?管理单元这个概念跟企业的管理模式和特点很有关系。再简化一点说就是跟企业的业务模式有密切关系。例如:按行业:现代企业大多表现为多公司、多工厂、多地点、跨地域等特征,这是技术进步保障了企业的发展硬件环境。另外,越来越多的企业为了规避风险、合理配置资源,企业都越来越倾向于多

40、元化发展。有全面多元化发展的:企业下属多个行业完全几乎无关,哪个行业较有发展潜力就去发展哪个行业;也有相关多元化的,就是集团企业以一个行业为主导发展其他相关配套行业,从战略协同层面产生竞争优势,由价值链上的战略匹配考虑节约成本。按业态:还有的企业虽然是单一行业发展,但是在行业内又可以细分出很多业态,例如零售企业,可以按业态再细分为超市、综合超市、百货、便利店等多个业态,每个业态的发展和管理方式也是有较大区别的,这是业务本身的特点决定的,也是现代企业运作的精细化管理的必然结果。按产品:可能是单一行业发展的企业,也可能是多元化的企业,视产品的相关的程度而定。但是不管是单一还是多元,因为每个产品的特

41、点多多少少总是有些不同的,它们可能有着不同的营销政策、不同的营销渠道、不同的产品理念、面对不同的消费群体,因此对于每个产品的管理模式也是有所不同的,现在普遍流行的是按产品设置事业部来管理(当然上面说的按业态划分按事业部模式来管理也是很正常的)。按业务政策:例如按核算政策、按销售价格政策、按绩效考核方法、按成本归集方式、按资产管理方式等等,总之,也还有很多其他细微因素决定企业的管理模式的不同。不管是根据行业、业态、产品还是一些具体的管理政策等方面的不同,决定了企业中实际上可能会划分出多个管理区域,每个管理区域内有自己特定的、相对统一的、但是跟其他管理区域有所区别的业务政策。这些管理区域的大小跟企

42、业的组织架构相比,可能会跨了几个分/子公司,也可能只是跨了几个部门,也可能只是对应一个部门和一个公司。总之,管理区域的粒度和企业实际的行政组织的粒度是难以统一的。这些管理区域在企业中可能是通过真实的组织架构或者部门、或者分/子公司反映出来,也可能只是个虚拟的概念,不在企业组织架构中有真实对应的组织单元。从上面这些分析可以看出:企业中这些在概念上真实存在的管理区域就是金蝶EAS组织架构模型中的管理单元。也正是因为实际管理区域难以跟实际的行政组织架构应起来,而且管理区域的粒度又是很难限定,因此,金蝶EAS组织架构模型设置了管理单元这个概念用以对应实际的管理区域,让企业自己决定在哪里设置管理单元、让

43、企业自己决定管理单元覆盖的范围也就是管理单元的大小。上面也提到,企业中的每个管理区域都是有一套自己特定的、相对统一的、但是跟其他管理区域有所区别的业务政策,这句话表明了两个意思:1、在一个管理区域(管理单元)内,业务政策是统一的、共享的。对于信息系统来说,业务政策意味着什么?意味着一些基础资料、一些业务规则,管理区域内统一业务政策,在信息系统中就是管理单元内使用统一的的基础资料和业务规则。这本身也是管理区域设置的理由之一:实现在一个特定的区域内实现政策集中管理。2、管理区域往往是跨组织的,可能跨行政组织,可能跨业务组织,经常是两者都跨,因为管理区域的粒度经常有可能比实际组织单元的粒度要粗,而管

44、理区域内的政策又是统一的,那么管理区域或者说管理单元就意味着是一个跨组织的共享区域,它保证了跨组织的业务政策能够共享,能够被一个管理区域内所覆盖的所有组织使用,从而保证了业务的集中处理,而不必每个组织各自使用自己一套基础资料,为了政策集中而花费巨大的成本来传递和同步。在金蝶EAS组织模型中的实现管理单元也是组织单元中的一种,因为它也是组织架构树中的一个节点。但是跟前面说到的管理区域跟行政组织架构难以对应并不矛盾,要这样理解:管理单元在设计上或者说实现上体现为是一个组织单元,是一个组织架构树中的节点,但是它作用的区域,却可能是覆盖了多个组织单元的。就是说作用上来看,它是体现为一个管理区域的,但是

45、在表现上它也是一个组织单元。在金蝶EAS组织架构模型中,要求先对企业的实际管理区域做出判定,规划出所有管理区域以及层级关系,在组织架构中先设置好企业的所有管理区域,也就是先设置好管理单元,然后再在每一个管理单元下面设置其中的组织单元,也是就是其作用区域内容覆盖到的组织单元,这些组织单元将使用这个管理单元作为政策共享区域。管理单元既然是组织单元,那么必然也像组织单元那样分上下级。管理单元同时也是一种业务组织,但是它不像其他业务组织那样分实体和虚体,为什么呢?其他业务组织之所以分上下级,是因为其他业务组织都是业务的载体,实体业务组织用来承载具体的业务,虚体业务组织主要用来统计查询。而管理单元虽然也

46、是业务组织的一种,但是它只是业务政策的共享环境,不参与具体业务,也不会用管理单元来进行统计查询,因此不需要虚体和实体之分。所以管理单元不管是叶子节点还是非叶子节点,都没有虚体、实体之分。管理单元和业务组织上都可以制定业务政策,但是基于管理单元的业务政策是在管理单元内跨组织单元共享的,而业务组织上的业务政策只是在这个业务组织内使用,不共享。管理单元可以根据企业实际业务的扩展而增加,管理单元的上下级还可以调整,以适应具体业务环境的变化而导致的管理区域的变化。进一步解释管理单元管理单元是金蝶EAS组织架构模型为业务政策集中(数据共享)而设计的概念。管理单元起构建软件运行基本环境:包括管理员和用户建立

47、、组织单元的建立、主数据和需要共享的基础资料的建立。注意:责任委托用来业务集中管理,管理单元用来政策集中管理。注意联系和区分。政策分配管理单元既然是为政策集中管理而设计的一个共享模型,肯定能为跨组织的业务提供便利,同时减少了信息系统中的数据冗余(因为共用的数据共享了,而非复制)。但是,管理单元更主要的是可以被上级组织用来控制下级的业务政策,用来调整上级对下级的管理强度和粒度。我们知道,一个管理单元意味着一套基础数据和业务政策环境,也是前面说的基本环境。但是政策的集中管理不仅仅意味着管理单元内共享,还意味着可能要跨管理单元共享。虽然企业可能划分了多个管理区域,但是在不同的管理区域中,并不意味着基

48、础数据(业务政策)的完全不同,对于行业多元化的企业来说,可能跨管理区域的情况不多,但是对于单个行业多业态划分,或者多产品划分的管理区域来说,跨管理单元共享一些最基本的业务政策还是很常见的,例如统一的核算政策(科目体系)、统一的物料等等。这样就需要能够提供手段跨越管理单元来共享。金蝶BOS的应用架构中提供了统一的、基于管理单元(不是基于业务组织视图)的政策分配方式,这一点暂且不多谈,但是要注意的是:这种政策分配是以管理单元业务视图为分配路线的,也就是说管理单元的上下级关系控制了业务政策共享和分配的关系。这样就能保证企业在一个管理区域内能使用相对独立的业务政策,但是又能通过分配手段跨管理单元共享业

49、务政策控制下级,控制下级使用什么业务政策,从而保证后续业务处理的一致性。业务政策控制强度:对于上级分配的业务政策,还可以根据需要再选择控制强度,例如可以选择是否允许下级修改、删除、或者新增相关业务政策。这种业务政策控制强度实际上对应於企业的管理集权程度的选择,是集团企业总部职能的一个定位问题。对于无关多元化的企业来说,企业总部不可能太过于集权,因为下属行业太过分散,总部更多是后勤和资源整合的职能,总部不可能深入到各个行业的运营当中去;对于相关多元化企业来说,总部可能只能在主导行业深入一些,集权一些,对于相关行业也不太可能深入;对于单一化企业来说,一般总部集权的倾向比较重。所以基于这些基本情况,

50、组织模型应该能够支持这些或集权、或分权、或混合的管理模式的,才能有效的支撑企业的业务模式。在金蝶EAS组织架构模型中,管理单元以及相应的应用框架支持保证了这一点。金蝶EAS组织架构模型之所以选择管理单元视图而不是其他业务组织视图作为政策分配路线是因为管理单元视图相对比较稳定,而且层次少,而且本身因为管理单元中可以分配的政策就是共享性质的。而其他业务组织视图是个汇报层次,主要用来统计,层次较多,关系也不稳定,如果沿着业务组织视图分配繁琐而且不利于业务扩展。业务政策的控制粒度:从业务的精细化控制来说,业务政策沿着管理单元视图分派下来以后,还不一定能满足需要,因为管理单元中所有组织单元是共享一套基本

51、业务政策的,而实际上管理单元中的每个组织单元可能需要更加精细化的控制,需要把某些业务政策细化控制到每一个具体的业务组织上,这也是完全合理的,因为不管是企业管理还是其他任何领域,有共性的领域就有个性化的领域,好比管理单元vs.组织单元。换言之,也就是有些时候,业务政策的控制粒度需要比管理单元更加细致。前面也说到,管理单元和业务组织都可以作为业务政策的载体,但是管理单元中的业务政策是给其覆盖的所有组织单元共享的,而业务组织上的业务政策是私有的,不共享的。那么如何设计和表达业务政策才能使得业务政策既能在管理单元中共享保持其共性的部分,又能通过业务组织隔离实现其个性化的部分呢?在金蝶EAS组织架构模型

52、中的管理单元和组织单元这两个层次,实际上是金蝶BOS中数据共享和隔离的容器,如果管理单元的第一级分配还没有达到需要的控制粒度,那么在按管理单元进行分配以后,还可以在组织单元上实现第二层次的分配,这就是“管理单元组织单元”的二层次分配模型。这样就可以实现任意粒度的业务政策控制了,因为组织单元的粒度是任意划分的,只要可以在组织单元上分配业务政策,那么业务政策控制粒度就是完全由企业自己决定的了。至于是否需要基于组织单元的二次分配,那么要视业务的需要了。业务政策并不是越细越好,过于细化的业务政策控制层次太深,从业务上来说,不利于调动下属企业的积极性,容易失去灵活性,从体制上来说,容易僵化;从信息系统的

53、角度来说,需要复制多份数据,导致业务数据急剧膨胀,如果业务组织本身树架构层次也很深的话。从管理单元到组织单元的二层次分配模型,当然不是固定的,可以根据业务的需要进一步灵活使用,例如可以在管理单元层次使用分配方式,在管理单元内使用基于组织单元的向下共享方式,如果下级组织单元可以制定自己的业务政策并且优先,这样的控制粒度和强度更加灵活,也能保证下属企业的积极性,避免过于僵化,也避免在信息系统中的数据过度复制。管理单元的划分原则管理单元的业务原型是法人组织,在不清楚如何设立管理单元的情况下,管理单元可以直接建立为法人组织。当然,因为金蝶EAS组织模型本身是对企业组织架构的一个再抽象,所以管理单元当然

54、也可以不是法人组织,而从管理目的角度出发来规划企业组织架构,例如根据前面说管理单元来历时提到的几个角度出发:按行业、按业态、按产品等等。从管理单元的意义来说,因为管理单元是共享模型中的隔离区域,所以最合适的原则是根据企业的重要基础数据的共享程度来设计管理单元的粒度,共享度高,则管理单元少,反之,则管理单元多。1.3 组织架构与其他基础服务组织模型是描述和组织企业应用的一个重要维度,但是组织模型并不是孤立的作用,它跟其他的一些重要基础服务一起,诸如权限服务、基础数据服务等,共同支撑起整个企业应用框架。1.3.1 组织架构与权限因为金蝶EAS组织架构模型是个多组织架构,适应企业复杂的组织构建与业务

55、协作与管理的,那么必然的,金蝶BOS的权限模型体系也是跟多组织密切相关的。不管信息系统是集中部署,还是分散部署后再集中的模式,登录到信息系统中就需要确定用户登录的上下文,也就是当前用户登录系统能够访问哪些组织、能够访问使用哪些基础数据环境、对哪些组织的哪些业务数据进行什么操作?这些都是权限模型需要解决的问题。组织访问范围需要以及能够访问哪些组织?在金蝶BOS的权限架构模型中,这个是通过用户的组织范围来设定的。用户首先是属于某个管理单元的,用户是基于管理单元隔离的,每个管理单元可以有自己的管理员,负责对用户进行授权。然后每个用户都有自己的组织范围,表示这个用户有权对组织架构中的哪些组织单元具有访

56、问权限,用户只能针对被授权的组织进行访问(用户的组织范围是一种特殊的数据权限),实际上也就是表明用户在企业中的职责以及业务处理范围。如下图:权限有组织类型金蝶BOS的体系架构中,功能权限是跟组织类型相关的。不同的组织类型即不同的业务组织拥有的不同的权限,不可能跨组织类型授权。这和前面说的一个组织类型代表一类特定的业务是一样道理,某种组织类型的权限只能授给同样类型的业务组织。例如不可能基于采购组织授予用户凭证的复核权限,因为多组织类型的原则已经保证了各个业务组织的权责是分离、明确的,凭证的复核权限只跟财务组织相关。对用户进行授权的时候,是在用户的组织范围内、针对用户有权限的组织来授权的。如果不首

57、先对用户进行组织授权,是无法授功能权限的,因为用户在不同的组织中需要的功能权限是不同的,如果不指定组织授权,则授权没有意义。例如某个用户能够访问三个采购组织,但是在采购组织A中可以新增订单,在采购组织B和C中只能查询订单。即:表现为XXX组织的XXX权限。权限不存在上下级关系,不是在上级组织中有权限就自动有下级组织的权限。例如对虚体组织拥有权限一般也仅仅意味着对该虚体组织的报表查看权限,这个虚体报表内容可能包含下级内容,但并不是说这个用户就有下级组织的相应的数据权限和功能权限。1.3.2 组织架构与基础数据基础数据在信息化系统中意味着业务政策。从业务政策也就是基础数据的制定过程来看,业务政策可

58、能有一部分是完全由上级制定后往下推行的,要求硬性执行的;也可能是上下级公司共同协商制定,其中包括有一些硬性的规定,也有允许下属公司自己决定的内容,也就是允许下属公司个性化定制的部分,还有一些业务政策则完全是下属公司自己决定的,上级公司不干预。这样可以看出,信息化系统中的基础数据无论如何也脱离不了组织这个维度。那么,基础数据如何在展现层面既展现出需要共享的内容又表现出各个业务组织个性化的内容呢?这就需要谈到基础数据的共享和隔离模型了。业务政策不仅需要如管理单元这样的分配线路,还需要业务政策的共享和隔离模型,才能把业务政策完整的管理目的贯彻下去,即:需要集中统一的业务政策需要能够共享和分配下去,不

59、需要共享的业务政策则完全隔离开来,上下级共同协商的业务政策则保证其既有共享的部分也有按组织定制的内容。由此我们来看金蝶BOS中基础数据的共享模型。基础数据的共享模型在一个多组织企业信息系统中,数据集中管理是数据充分共享的基础,而数据集中管理以后首要的任务就是要隔离,数据隔离不是目的,隔离是为了确定数据各自的来源和归属,然后再用共享模型更好的共享。金蝶EAS组织模型已经实现了良好的组织隔离、组织协作和基本的共享环境,然后跟基础数据的共享模型进一步结合,保证了多组织架构下业务的进一步处理。根据管理需要,金蝶BOS把基础数据分为三大类,即主数据的管理模式:全局共享型(S类)、分配后跨管理单元共享型(

60、D类)以及隔离型(I类)。全局共享型是跨越组织单元和管理单元边界的,不受组织单元和管理单元的约束而直接共享。例如币别这种基础资料,它的特点是数据量有限,不会随着业务数据的增长而线性或者几何增长,可以预知其增长极限,而且共享程度极高,所以没有必要让每个组织单元或者每个管理单元都拥有一份,直接共享就可以了。这部分基础数据反映的是企业集中管理的业务政策,需要统一执行的。分配后跨管理单元的D类基础资料,是为了那些基于管理单元隔离的基础资料在跨管理单元共享而使用的,例如主数据等等;主数据体现了最主要的业务政策控制意志,体现了组织的意志。这种跨管理单元共享的手段(沿着管理单元视图分配)是十分必要的,才能保

61、证业务政策的往下延伸,保证管理目的的实现。隔离型就是指那种基本上不太可能在各个组织之间共享的基础资料,几乎是完全的基于业务组织个性化的,那么基于业务组织隔离就行了。这部分基础数据基本上是各个组织独立决定的业务政策,不需要上级参与和管理的。这三种基础数据从左到右,共享程度是逐渐降低的,也就是说他们的业务政策细化程度是越来越高的。如果业务政策本身的粒度比较粗,而且适用范围很广,那么可以考虑适用全局共享型;如果业务政策的粒度适中,控制强度需要可调整,则考虑使用分配后共享的基础资料;如果业务政策的粒度很细,不需要共享,则考虑使用隔离型的。这三种基础数据的共享模型结合组织模型,可以配合有效达成企业的管理

62、目的的制定和实施。这三种基础数据类型其中地位最重要的就是分配后共享的D类,它对其他两类基础资料具有承上启下的作用,它具有下面两个重要特点:1、体现在纵向上、上下级之间,控制强度可以调整,反映上级对下级的控制程度;例如如果业务政策控制强度选择了不允许下级新增修改删除,那么D类实际上就是全局共享的S类;如果业务政策控制强度设置了允许下级新增修改和删除,并且也不执行分配动作,那么D类实际上可以看做是隔离型的I类。2、体现在横向上,各业务组织之间,可以既共享又隔离;既可以有各个业务组织共享的部分,也可以有各个业务组织个性化的部分。基础数据的结构模式BOS中S/D/I这三类基础数据的结构模式是不同的。S

63、类基础数据是所有组织只有一份数据,大家公用;I类则是每个业务组织各一份,彼此完全隔离;而D类的基础数据则是存在多份的,因为既有公用的数据也有按组织隔离的数据。如下图:上图这种结构模型对于比较复杂的基础数据例如客户、供应商等主数据是有效的描述模型,但是对于不太复杂而又需要这种管理模式的D类基础数据,则可以使用退化模型,去掉各个业务组织的个性化部分,只有共享部分:BOS主数据基础数据中最重要的一类就是主数据,例如物料、客户、供应商、科目、人员等,它们是企业信息系统几乎所有关键业务流程中的关键业务实体。主数据的模式对于信息化系统,对于企业来说最重要的是要考虑企业内各组织、各业务系统之间能够使用相同业

64、务意义的主数据,保证业务流程中主数据的一致性;没有了主数据的一致性和业务意义,跨业务系统的流程和报表都无法实现。金蝶BOS中的主数据的结构模型都采用了BOS基础数据中的经典的D类模型(请参见上一节中的D类基础数据的结构模型一图)。因为从主数据的作用和地位来来看,主数据往往是需要跨业务组织来使用的。例如物料,采购组织、销售组织、库存组织、财务组织等这些业务组织都会用到。对于这些跨组织的引用部分,需要有一个公共的引用,这就是主数据的共享部分。对于各个业务组织在物料上的个性化部分,则仍然使用业务组织进行隔离,例如物料上的销售相关业务政策使用销售组织隔离,采购相关政策使用采购组织隔离,等等。至于管理模式,BOS主数据基本都使用了前

展开阅读全文
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!