EAS组织架构实施指南(修正原文档嵌入案).doc

《EAS组织架构实施指南(修正原文档嵌入案).doc》由会员分享，可在线阅读，更多相关《EAS组织架构实施指南(修正原文档嵌入案).doc（23页珍藏版）》请在三一办公上搜索。

1、EAS组织 架构实施指南修改记录Ver. No修改日期作者审核人修改要点1.02007-10-18朱涛初始版本1.12008-1-14朱涛增加第七节，补充说明组织架构设置的一些细节事项（反面案例），并针对如何调整组织架构进行了详细说明。一、前言EAS组织架构是EAS项目实施中最先需要考虑的重要内容。之所以组织架构的地位特别重要，主要是因为，一：EAS组织架构涉及的内容非常广泛，它是EAS中所有业务开展的重要维度和载体，跟EAS所有业务系统有密切相关；二、规划组织架构的过程实际上是为企业用户拟定管理模式的过程，所以组织架构规划的好坏直接关系到用户在EAS中的应用效果，尤其关系到集团企业的集团管控

2、目标是否能达成的问题。本文主要针对实施人员，提供组织架构实施的一套思路和方法，引导如何在项目中替用户合理地设置组织架构，并提供了一些实际的例子作为参考。本文的重点并不是解释EAS组织模型的理论，而是描述如何在项目实施中更好的结合客户实际情况更好的实践EAS组织架构。侧重点不是解释EAS组织模型为什么会这么设计（why），也不是解释EAS组织模型的来龙去脉，而是解释如何使用EAS组织模型（how）。关于EAS组织模型理论方面的详细内容，请参见EAS组织架构详解。二、常见的问题和容易犯的错误EAS的业务组织是业务运作的主体，各种业务政策的制定、业务流程的流转都需要以业务组织作为载体。EAS的业务组

3、织是以为业务流作为区分的，因此分了比较多的类型，一共有八类：财务组织、库存组织、销售组织、采购组织、成本中心、利润中心、HR组织和管理单元。主要常见问题：在EAS项目实施的过程中，除了HR组织和管理单元概念上比较深入一些，其他的业务组织的识别并不是一个大问题，根据名称顾名思义都能把这些组织识别出来，但是主要的问题还是有几个：1、业务组织的粒度不好区分：管理单元到底应该划分成多大？销售组织、库存组织应该划分多细的粒度？等等；2、业务组织的位置不好识别：例如：应该在什么地方标示HR组织？库存组织？采购部应该设置成采购组织吗？一套班子做多套事怎么办？等等；3、组织的关系分析不清：例如：库存组织和行政

4、组织是什么关系？怎么对应？什么是汇报关系？什么是汇总关系？我在设置的组织架构是行政架构吗？还是管理架构或者法人架构？等等；主要常见错误：另外，在为客户规划组织架构的时候，还有一些比较容易犯的错误，最主要的是全局思维不够。这个全局思维不够表现在几个方面：1、因为实施时经常分几期上线，所以开始制定业务蓝图的时候没有从全局的角度考虑组织模型的实施，最后可能发现财务要求的组织架构和供应链、HR要求的组织架构不一致，有冲突。这个就是把EAS的各个业务系统分开考虑，没有重视各个业务系统之间的联系和整体性。不重视EAS个业务系统的整体性实际上也就是没有重视EAS各个业务组织之间的联系性和整体性，把各个业务组

5、织间的联系给割裂了，这样分开考虑一种种单独的业务组织，在后期整体上线的时候，或多或少就会发现一些冲突和不足，或者导致业务无法继续下去；2、以为组织架构仅仅是组织架构，没有深入分析业务，没有认识到EAS组织架构实际是EAS整个业务流的重要的纽带。设置EAS组织架构跟管理模式、工作流 审批、参数设置、报表统计、成本核算等等几乎所有业务都密切相关。如果没有在调研过程中，结合用户的业务仔细分析，组织架构的规划往往是不够深入的，最终往往会卡在某个业务的功能点上，流程不畅。上述常见问题和错误都是经常在实施中碰到，本文下面的部分主要是针对这些问题给出一些解决方法和思路。三、一些总体原则EAS的组织模型具有系

6、统性，绝对不是一个简单的基础资料。所以组织架构在实施阶段规划的合理性决定了以后业务系统的成败，它几乎涉及到EAS的所有方面，设置组织架构是个系统工程，全局性的，必须高度重视；EAS组织模型的扩展性和灵活性很高，但是这种扩展性和灵活性带来了复杂性，不当实施的效果无可预料，好比一盒积木能搭出什么样的形状，无法预知；EAS组织模型的标准理论和实际产品的实现有一些细微差别，主要是指某些功能在组织模型中已经体现了，但是业务系统中还没有完全支持，这一点实施的时候要注意，理论和实际有差别。以下是在实施项目中规划EAS组织架构非常重要的几点总体原则：第一：要敢于怀疑用户的说法用户对于组织架构的理解是非系统性的

7、、非理论性的，是经验性的，甚至是偏差的，至少，是非EAS组织模型性的。所以一定要怀疑用户的第一说法，并且加以引导和刨根问底；例如，用户说：我们是事业部制管理的真的是吗？一定要问清楚具体运作机制，否则很容易被用户误导。也许等你问清楚了，你才发现他们原来离事业部制天差地远；例如，用户说：我们的县级公司是独立核算的真的是吗？用户理解的“独立核算”是EAS中独立核算的概念吗？如果不问清楚这个，财务组织就无法设置正确；用户对于组织架构的理解顶多是业务需求层次，而EAS组织架构是业务蓝图性质，这二者之间可能有很大的差异，一定要仔细甄别整理；第二：和用户一起动手整理实施的数据准备阶段，如果你让用户自己画出他

8、们公司的详细组织架构，他们有可能会为考虑太多而被组织关系、管理方式、法人关系、股权关系搞得糊里糊涂，怎么也画不清楚；也可能会因为考虑太少，画出来的组织架构有很多遗漏；或者是主次不分，抓不到重点。所以请一定和用户一起，用我们的组织模型来引导用户，整理出他们真正的组织架构初稿；第三：记住几条金科玉律u 组织架构实施要全局考虑，组织架构的设置意味着管理模式的选择，要结合管理的特点来考虑；同时，横向上要考虑EAS全部的业务模块，要综合考虑各个不同类型业务组织之间的关系，组织规划的本质对各种业务需求进行一种均衡处理，找个平衡点； u EAS组织架构主要体现的是企业的管理架构，依据管理架构开展业务而不是行

9、政架构。设置步骤是先识别行政架构再设置管理架构，不要把组织架构的众多维度混淆在一起；u EAS组织模型中，行政组织才是真实存在的组织单元。行政组织的划分参照真实的企业组织架构即可，至于业务组织完全视业务规则来划分，是虚拟组织的概念，跟行政组织并无直接必然联系;u 识别业务组织的粒度主要依据业务政策的同质性(适用于所有业务组织，包括管理单元)。即：如果某个区域内的组织单元集合适用并且使用同样的业务政策，那么它们就可以划分到一个业务组织内；四、具体的一些细则根据上述总体原则，我们再细化下去，就每种组织类型以及其中一些关键的焦点问题进行总结出下面的一些较为细化的具体原则：1、如何设置管理单元设置管理

10、单元的理论方法：根据基础数据（主要是指四大主数据：科目、客户、供应商、物料）的共享范围，取最小粒度；例如：某集团统一核算体系，所有公司同一套科目表，那么从核算来看，CU只要一个就够了；但是下属三个销售公司的客户是自己管理，彼此不需要共享，也不能共享，那么这就需要三个CU；这个集团主要分两个行业，每个行业差别很大，物料不需要彼此共享，那么从物料的角度来看，需要两个CU；依此类推，最后，得出的结论是至少需要三个CU；设置管理单元的经验方法：根据行业来划分；根据区域来划分；根据法人公司来划分；等等。设置管理单元的现阶段实际方法（V5.4）：一个管理单元对应一个财务组织（因为目前财务系统尚未完整实现组

11、织模型）；注意：设置管理单元的理论方法虽然是最严谨、最科学的，但是现阶段并不是很适用，因为各业务系统对EAS组织模型的支持还不够到位；设置管理单元现阶段(v5.4以前)最适用的方法是经验方法。即：根据财务组织的粒度来决定管理单元的粒度，一一对应；2、如何设置财务组织EAS中的财务组织的概念基本上等同于公司，即：财务上独立核算的组织单元，所谓独立核算，就是能够独立出资产负债表的核算单位。EAS中的财务组织跟是否法人公司没有关系，EAS不识别法人，因为法人与否跟核算关系不大；注意识别：有些客户口中所谓的“独立核算”并不是真正的独立核算，因为他们没有自己的资产（资产所有权属于总部），他们只能独立出利

12、润表，但是不能独立出资产负债表；对于如何支持这种只能出利润表无法出资产负债表的半独立核算单位，也可以考虑把他们设置成财务组织，但是需要通过特殊的账务处理，把资产负债表做平；如果客户要求半独立核算单位只出利润表，资产负债表和上级一起出，那么目前EAS还没有好的解决方法，这个不是组织模型的问题，是EAS业务系统对于这种半独立核算还没有支持到位，EAS正在考虑解决方案；不要把财务部设置成财务组织，财务部在EAS中只是一个行政组织的概念；财务组织是业务组织的一种，它是虚拟的，它的核算体系覆盖了多大的范围，那么它就包含多少个组织单元；一般来说，财务组织对应于公司级别；对于集团总部或者集团财务中心代下面工

13、厂统一做账的案例，分两种，一：下面工厂或者分公司虽然是独立核算，但是他们并没有财务部或者财务人员，由总部代做账；二：分公司和工厂虽然有财务人员，但是人员编制并不属于分公司和工厂，而是属于总部，他们属于总部派驻；对于这两种情况，难点不是财务组织的设置，因为从业务性质上来说，分公司和工厂既然有独立的账簿，那么他们肯定是独立核算，肯定是财务组织，真正的难点在于他们的行政组织怎么设置？情况一：分公司不用设置财务部之类的行政组织，因为这些代做账的财务人员本来就不属于分公司，是总部人员，只要总部设置财务部这个行政组织就可以了；情况二：分公司可以设置也可以不设置财务部之类的行政组织，主要看实际的HR业务管理

14、方式。例如总部派驻人员可能在总部领工资，但是在分公司绩效考核，在分公司领福利，这样涉及到了分公司的实际HR业务管理，那么就需要在分公司设置财务部这类行政组织；3、如何设置库存组织EAS中的库存组织是管理库存和需求(制定需求计划)的单位，它通常意味着工厂或者配送中心；库存组织是MRP运算的单位，是库存核算的单位，它代表了“物”的所有权；对于制造业来说，一个工厂设置一个库存组织即可；对于流通渠道来说，出于库存统计的需要，如果下面的办事处或者销售公司有库存，那么也可以分别设置库存组织，这样可以按照组织维度来分层统计渠道中的库存；注意：1、别把库存组织认为是仓库，仓库在EAS中是资源的概念，是可以分配

15、给库存组织使用的资源；2、库存组织不能跨越财务组织。这句话的经验理解是：库存组织的粒度一定要比财务组织小，在财务组织之下；这句话的理论理解是：一个库存组织只能委托一个财务组织记帐；4、如何设置销售组织销售组织是销售政策的载体，是销售业务的具体操作层，设置销售组织最主要的难点是：粒度如何决定？同样，不要把销售部等同于销售组织，销售组织是业务组织，是个虚拟的概念。销售组织的粒度取决于销售政策(价格折扣、促销方式、返点返利、提成佣金等)的同质性，如果某些组织单元适用于同样的销售政策，那么他们就可以归并一个销售组织中去；如果整个公司只有一种销售政策，那么设置一个公司级的销售组织即可；销售组织的粒度还取

16、决于销售统计的层次，对于流通渠道，如果需要分层次统计销售业绩，那么可以把每个层次的渠道通路都设置成销售组织；例如，亚华乳业，因为需要统计每个办事处，每个省区、每个大区的销售业绩，所以每个办事处是最明细的销售组织，每个省区和大区都是虚体的销售组织用来汇总统计；5、如何设置采购组织采购组织是采购政策的载体，是采购业务的具体操作层，同样也需要考虑粒度的问题；考虑粒度，同样是考虑业务政策的同质性，如果采购政策整个公司都一样，不因地区、产品、业态不同而不同，那么整个公司、整个集团一个采购组织就够了；如果因为地区、产品、业态不同而有不同的采购方式和采购政策，那么可以分别设置采购组织；采购组织没有库存和销售

17、组织统计的那种细颗粒度，一般不需要考虑分层统计的需要细分采购组织；不要单纯认为一个采购部就是一个采购组织，任何业务组织，首先考虑公司级或者集团级的层次，才是比较合适的粒度；通常情况下，业务组织的覆盖的范围总是比行政组织要大，但是特殊情况下，行政组织可能比业务组织大；例如一个采购部同时负责国内和国外采购，分为两个小组，显然，国内和国外的采购方式会有很大不同，因此无论从业务政策的角度还是统计的角度，都要把这个采购部分成两个采购组织；6、如何设置责任中心EAS的责任中心分为成本中心和利润中心，成本中心挂在利润中心之下。一个成本中心是一个最小的成本核算单位，划分成本中心的粒度，主要从成本核算、费用归集

18、的角度来考虑；EAS的责任中心不能跨财务组织，即责任中心的粒度必须比财务组织的粒度要小；也即：一个责任中心不能委托多个财务组织记帐；7、如何设置HR组织HR政策的载体以及业务操作层是HR组织，不是行政组织；行政组织记录人员和职位，它委托HR组织处理HR业务；HR组织的粒度区分跟其他业务组织一样，看HR政策的同质性：一个集团或一个公司存在几种HR业务政策，或者存在几个HR管理区域，就可以分为几个HR组织；主要可以从这两个个维度来看HR业务政策的不同，如薪酬福利政策和绩效考核政策；即：一套薪酬福利政策可以代表一个HR组织的划分依据；当几种业务政策的粒度有冲突时，取最小粒度；注意：现阶段HR系统(V

19、5.4)的集团处理架构还没有完全建立好，因此如果按照上述原则划分了多个HR组织，后续业务处理和报表会有一些问题，目前HR系统的这个问题已列入规划，正在处理；8、如何设置行政组织EAS的行政组织单元基本上等同于企业中真实存在一个个行政部门、公司，以企业真实的行政组织架构即可基本勾勒出EAS的行政组织架构，但也要注意：l 复杂情况下，行政组织有可能也要虚拟，尤其是一套班子做多套事这种案例；l 行政组织本身并不是虚、实体，因为行政组织的每一级都是真实存在的，体现了领导意志、上下级关系的；而且行政组织不是业务组织，它不是业务统计的维度，所以不需要虚、实体；l 一个组织单元，作为行政组织时的上级和作为业

20、务组织时的上级很可能是不同的，即：多头领导制，EAS支持这种模式；9、如何设置业务委托业务委托主要是为了各个不同类型的业务组织之间的协同工作而设计的，单据加上委托形成业务流；财务系统：如果用户只上财务，那基本上可以不用设置任何委托，因为财务系统块只用财务组织，跟其他组织没有交互；供应链：1、要设置库存组织到采购组织、库存组织到销售组织的委托，以及库存组织、销售组织、采购组织到财务组织的记帐委托(至于采购组织、销售组织到库存组织的反向委托可以不用设置)；2、要设置采购组织、销售组织、库存组织对行政组织的委托(体现的是业务执行关系)，至于反向的，行政组织到采购、销售、库存的委托目前还没有用上，所以

21、不必设置；HR系统：需要设置行政组织到HR组织的委托，这是表明HR组织的覆盖范围；需要设置行政组织到财务组织的记帐委托，至于HR组织到财务组织的委托现在没有用上；10、总结和补充1、区分业务组织粒度的第一原则是业务政策的同质性，第二原则是统计的层次；2、组织的粒度经常需要在各个业务系统之间(即：各个不同类型的业务组织之间)找平衡，取个折衷的粒度；3、根据第一条的两条原则设置组织的粒度并不是唯一，有时候需要根据具体业务微调；例如库存组织对成本核算方法有影响，同一物料在不同库存组织允许不同的成本核算方式，当企业实际业务需要同一个物料采用不同计价方法时，就需要设置两个库存组织了；4、成本中心、库存组

22、织不能跨财务组织；采购组织、销售组织在核算上不能跨组织，但是在业务上是跨财务组织的(集中采购、集中销售);五、具体规划组织架构的步骤规划组织架构，首先要建立EAS组织架构的蓝图，这个过程大致应当如下：1、以“公司行政部门”的方式画出基本的行政组织架构，确定基本的组织单元；2、找出独立核算的财务组织；3、结合管理单元的各种划分方法划分出管理单元；4、分析业务，根据业务政策和报表统计的需要在组织单元标示出各业务组织；5、根据业务流向和协同关系，指定各个业务组织之间的委托关系；对于“一套班子做多套业务”这种情况要注意，行政组织不用划分开来，但是业务组织需要划分开来，因为统计和政策的需要；规划好EAS

23、组织架构蓝图以后，需要跟客户讨论论证，再次仔细结合业务确认一次，如果确认没有问题，就可以在EAS产品中建立起真正的组织架构了，但是在EAS产品中建立组织架构的步骤跟规划时的先后顺序有所不同：必须要先建好管理单元，再建组织单元（出于设计的原因）。1、以超级用户进入系统，建立管理单元，并建立CU管理员，然后再让各个CU管理员进入系统建立本CU的组织单元；待添加的隐藏文字内容22、设置各个业务组织的业务组织属性，区分实体和虚体、指定业务上下级，建立委托关系；3、设置完成以后，在“基础数据管理”“组织架构”“企业组织架构树”中选择启用组织架构。注意：EAS组织架构的财务组织在建立时依赖于一些基础数据，

24、例如科目表、汇率表、会计期间表，因此，在建立EAS组织架构之前实际还要先建立好这些必须的基础数据，才能真正开始建立EAS组织架构。六、一些具体案例1：亚华乳业组织架构湖南长沙亚华乳业的主营业务有两块，分别是奶粉和液态奶。这两块业务都有独立的工厂和独立的销售渠道，其中奶粉的营销策略上面向全国的，目前也已经在全国建立了比较完善的营销渠道；液态奶这块业务主要面向湖南省，营销渠道也仅仅只是在湖南省境内。亚华乳业上EAS的管理诉求就是集中控制，诉求几个关键业务点的精细化集团管控（集中采购、集中销售等），是比较典型的运营控制型的集团企业。亚华乳业的组织架构设置主要是如下思路：1、管理单元的设置：虽然亚华乳

25、业的分为两个业态，奶粉和液态奶，从原则上看两个管理单元似乎够了，但是因为实际上他们这两个业态虽然在销售上彼此独立，但是在生产环节却没有完全分开（城步分公司既有液态奶生产线，也有奶粉生产线，两个都生产），所以这两个业态并没有完全独立和分离。如果按业态划分管理单元的经验规则，那么势必要把城步分公司虚拟成两个部分，那么后续的行政的组织架构就不好设置了。因此综合考虑还是按照独立核算实体来划分管理单元比较方便，即：乳业总部、望城分公司、城步分公司、培益乳业分别设置独立的管理单元；与此相关的主数据的位置，也需要根据上述特点进行考虑，例如物料。因为城步分公司既涉及奶粉又涉及液态奶两个业态，需要跟望城分公司共

26、享主数据；而乳业总部又需要紧密跟踪培益乳业的营销情况和望城、城步两家的生产管理，因此，总体上来说，物料这个主数据的共享和管控程度就很高。这样，就需要把物料主数据的位置建在亚华乳业集团这个层次比较好，方便集中控制和往下分配。2、财务组织的设置：这个比较简单，亚华乳业的独立核算单元很清晰，而且也不多，就四个：乳业总部、望城分公司、城步分公司、培益乳业。3、销售组织、库存组织的设置：奶粉和液态奶的营销渠道，都分大区、省区和办事处三级，有分层统计销售业绩和库存的需要，因此，把销售组织的最低层次设置在办事处（因为订单都是由办事处来接的），办事处的上层省区、大区都设置成虚体的销售组织和库存组织，用来作为分

27、层汇总统计的维度； 4、委托关系的设置：亚华集团是存在内部供应链环节的，统一集中采购和集中销售，有频繁的内部交易和调拨，因此必须设置好各个业务组织之间的业务委托关系，才能处理相关的集团内部供应链业务。主要是城步分公司和乳业总部存在互相替对方采购的集中采购行为，需要互相设置采购委托；乳业总部和城步分公司的奶粉集中调拨给培益公司集中销售，因此需要设置两个公司到培益公司下的各个销售组织的销售委托；城步分公司的液态奶产品是调拨给望城分公司集中销售的，因此需要设置城步分公司库存组织到望城分公司下的销售组织的销售委托；亚华乳业行政组织架构树在EAS中构建的亚华乳业的企业组织架构树(含业务组织及主要委托关系

28、)：2：武汉凌云组织架构武汉凌云集团主要涉及两个行业，一块是军工的飞机维修，一块是民用的建筑装饰材料。这两个行业都是武汉凌云的主营业务，但是这两块业务彼此比较独立。武汉凌云集团客户方的诉求是尽量大集中管理，表现在财务核算政策高度统一（包括科目表、明细科目、核算项目、辅助账等）、HR管理高度统一。以前他们使用K/3，被数据分散所困扰，一共有上百个账套，数据查询汇总十分困难，政策也难以集中和管控。因此才迫切希望上EAS实现集中管理。另外，武汉凌云集团下属的建筑装饰工程公司（以下简称建装公司）的组织架构特点是动态的，因为他们每接一个项目，金额都比较大（动辄千万以上），而且工期比较长，可能持续一两年，

29、因此他们的做法是每一个项目都单独核算，也就是每一个项目都是一个独立的财务组织。因此，根据上述情况，武汉凌云集团的组织架构设置思路如下：1、每个独立的二级公司设置成单独的CU。实际上，只有集团、飞机维修管理部、建装公司需要设置成CU，其他的二级公司大多业务简单，完全可以放在一个CU内，但是因为EAS要求一个CU内的科目明细及核算项目必须一致，这就可能达不到用户的要求，不同的二级公司可能核算政策还是有细微差别的，因此还是每个二级公司一个CU；2、建装公司下的各个办事处大多分步在异地，因为税务等原因，核算上相对独立，但是财务核算政策高度统一（明细科目、核算项目、辅助账等），因此把所有办事处都设置一个

30、CU内，作为财务组织存在，如果以后再增加办事处，则增加CU内的财务组织即可；每个工程项目的组织设置原则也和办事处类似，作为财务组织处理，以后工程项目增加，增加财务组织即可；3、HR管理上，凌云集团希望高度统一管理（现在的状况是凌云下属建装集团的HR管理独立于集团之外，集团管不到），另外，因为目前版本的EAS HR还没有多HR组织下的虚体报表，所以无论从哪个方面考虑都应该在全集团范围内只设置一个HR组织；所有行政组织把HR事务委托到总部这个HR组织；4、责任中心：飞机维修管理部下的各个车间只作为成本中心，利润在他们的上级飞机维修管理上设置；而建装公司下的各个办事处和各个项目既是成本中心也是利润中

31、心，这些都是按照用户的实际管理状况设置的，没有特别之处；5、至于航地公司、特汽公司、三产一公司、三产二公司四个二级公司之所以在CU下面把本部单独划分出来，因为客户方提出可能以后业务组织还会扩展，如果把实体组织都直接设置在CU上不方便以后扩展6、其他行政组织不必过多考虑，不影响业务，但是要把所有行政组织实体的HR委托指向凌云总部。；最终武汉凌云集团的组织架构图设置如下（行政组织略）：七、组织架构调整的案例在EAS项目实施的过程中可能会经常需要在EAS中调整组织架构，主要可能是以下两种原因：1、实施人员可能在项目实施之初对EAS组织模型不太了解（参见第二章：主要问题&常犯错误），在EAS中规划客户

32、的组织蓝图时会发生一些偏差，对后续业务造成了一定的影响，这时候就需要对已规划好的组织架构进行调整。这属于因设置错误而导致的调整。2、客户的业务发生了变化，实际的组织架构发生了调整，表现在EAS中为行政组织或者业务组织的变更，这时候也需要调整组织架构；这属于业务变动而导致的正常的调整。以下详细介绍在这两种情况下如何调整EAS中的组织架构。7.1、因为开始设置错误而调整的因为设置错误而需要组织架构的，目前发现主要是因为：EAS业务组织是虚拟的，也就是业务组织的设置常常是按照业务管理的需要而虚拟出来的，并不和客户的真实的行政组织架构对应。而有些实施人员并没有理解这一点，经常把行政组织按照虚拟的业务组

33、织设置得一样，这样客户真实的行政组织架构就被扭曲了，不能满足客户的需要（上HR或者OA的时候就能体现出来）。例如，EAS的项目大多是财务先上线实施，那么实施人员会习惯按照财务组织的设置思路来设置行政组织，而财务组织往往因为核算的需要，会虚拟出一个“本部”或者“总部”出来，但是在实际行政组织架构中，客户并不承认这个“本部”或者“总部”，如果实施时把“本部”、“总部”也设置成了行政组织，并且由此指定行政组织上下级关系，那么肯定不满足客户的需要了。这种情况下肯定需要调整行政组织设置，但是在调整的过程种，有一个主要的障碍：大部分客户的费用类科目都需要按照部门进行辅助核算，而实施人员往往就直接在这些科目

34、上挂了行政组织作为辅助核算项目，这样就导致发现行政组织设置得不准确却又无法调整。因为删除、封存行政组织或者改变行政组织上下级会导致财务核算数据的变化，这是客户财务核算上所不能允许的。因此，请实施的时候务必注意，不管是什么科目需要按照部门挂辅助账，尽量不要使用行政组织作为核算项目，应该使用成本中心。这样，就让行政组织和业务组织是一种松耦合关系，以后单独调整行政组织或者单独调整成本中心也不会影响到对方。EAS的各种业务组织和行政组织在设计之初就考虑了他们是彼此独立的体系，在需要业务协同的时候才通过委托关系关联起来。所以不要把各种业务组织以及行政组织紧密耦合，这样会丧失组织架构的灵活性。调整行政组织

35、架构的方法如下：1、对于多设的行政组织，例如误把财务上的“本部”、“总部”也设置成了行政组织的，那么可以删除或者封存这类行政组织。从行政组织视图上来看，删除和封存的效果一样，删除或封存后都看不见了，但是实际的效果和出发点是不同的。u 对于没有业务发生的行政组织（例如没有挂过辅助账的，也没有设置职位、没有职员挂在上面的、没有被固定资产卡片、SCM单据引用过的），那么可以删除；删除的方法是，首先反启用企业组织架构（利用administrator进入系统，进入“企业组织架构树”菜单，点上面的功能按钮“反启用组织架构”），然后编辑相应的组织单元，选择行政组织页签，把“行政组织”复选框去除、保存即可；u

36、 对于已经业务发生的行政组织，如果需要保留历史数据的，那么只有采用封存的手段了，进入组织单元编辑界面，选择行政组织页签，点上面的功能按钮“封存”（注意：截至到V54版本，行政组织不能反封存，请注意操作）；u 如果一个组织单元本身是管理单元，如果在这个管理单元中还有其他的行政组织，不管其他这些行政组织的上级是否指向作为管理单元的这个行政组织，那么管理单元上的行政组织也不能删除的（这是因为EAS组织模型要求作为管理单元的组织单元上的组织属性必须包括本管理单元中所有其他组织单元的组织属性），这种情况下，如果作为管理单元的行政组织是不需要的话，那么也只能封存。2、如果要删除或封存行政组织，必须这个行政

37、组织没有任何下级行政组织（这个对于其他业务组织也是一样）。所以要删除或者封存行政组织之前，必须把他们原来的下级全部重新指向到别的行政组织上去，这个通过更改行政组织上级就可以了。3、对于设置错误的行政组织上下级关系，那么在组织单元编辑界面中调整行政组织上下级关系。但是注意如果行政组织已经被作为了核算项目使用，改变行政组织上下级关系，会改变辅助账的汇总关系的（跟组织相关的辅助账是按照组织视图关系进行汇总的），这个会导致财务数据紊乱。因此，更改行政组织上下级一定要注意：行政组织没有作为核算项目在科目中被使用过，否则就不能改。如果已经使用了行政组织作为核算项目，并且有了历史数据，而且想调整行政组织架构

38、，怎么处理？那么除了遵循上述三个原则以外，还要进行如下操作进行事先准备：1、把所有使用行政组织作为核算项目的科目的辅助账类型从行政组织改为成本中心，并且连带总账辅助账历史数据一起迁移到成本中心上。这样才能使财务核算和行政组织脱钩，才能使调整行政组织成为可能。这个调整有总部研发提供的SQL脚本可用，目前已验证在V5.3之前的版本可用，如果需要这个脚本，请跟总部研发的总账组联系。注意，在执行这个脚本调整辅助账类型之前，还要进行一个重要的准备：必须对应行政组织设置一模一样粒度的成本中心（虽然正常情况下，EAS的组织模型并不要求这么做，但是为了把辅助账从行政组织迁移到成本中心上，则必须这么做）。否则脚

39、本执行结果将无法预料。这里有两个可能：u 以前设置的成本中心和行政组织的粒度不对应，可能某个组织单元作为行政组织是非叶子节点，但是作为成本中心已经是叶子节点了。这个时候就需要把成本中心的叶子节点也按照行政组织的粒度改得一模一样（更改之前必须注意，成本中心没有挂过任何辅助账，否则不能改）；u 如果组织单元作为行政组织和作为成本中心的上级组织指向不是同一个组织单元，也就是说行政组织上下级关系和成本中心上下级关系不一样，那么也必须更改，把成本中心的上下级关系改成和行政组织上下级关系一模一样（更改之前必须注意，成本中心没有挂过任何辅助账，否则不能改）；2、因为第一步调整成本中心可能会导致某些成本中心由

40、叶子节点变成了非叶子节点，或者由非叶子节点变成了叶子节点，那么需要调整固定资产卡片上的折旧费用分摊的成本中心，必须统一调整成叶子节点的成本中心。以下是两个调整组织架构的例子：一拖EAS项目、交投EAS项目。7.2、因为客户的业务变动而调整的客户的业务或者组织架构会经常发生变动，那么也需要在EAS中调整组织架构的设置。这里分两种情况：n 只是行政组织架构变动，业务组织没有变动（这种情况占大多数）；n 不仅是行政组织架构变动了，业务组织也变动了；如果只是第一种情况，那么在EAS中调整是比较简单的，因为EAS组织模型本来就是各个组织视图分离、松耦合的关系。只要没有业务绑定行政组织，那么调整行政是很简

41、单的，请参照7.1节中的相关说明。如果是第二种情况，不仅是行政组织架构变动，还有业务组织架构变动，那么就要慎重了，因为EAS的任何业务组织都是业务数据的载体（这一点区别于行政组织），所以变动业务组织必然会涉及到历史数据问题。因此，变动业务组织必须考虑如下两个原则：n 保持历史数据的可追溯性（历史数据可查询，且历史数据是按照变更前的组织架构体系查询）；n 业务组织变更前要保证所有业务都已结转、关闭（结转余额、任务关闭等）；目前EAS的组织模型不提供组织版本管理，只提供组织架构的生命周期管理，组织的变更在业务上表现为移动、合并、拆分等行为，在EAS中就把这些行为抽象为组织的新建、封存（反封存）、删

42、除、移动等几个操作。在EAS中，为了保证历史数据的可追溯性，业务组织变更的总体思路时先封存后新建。但是要封存哪些组织呢？注意以下原则：如果组织的移动、合并、分拆时导致其自身、上级、下级节点的叶子性质发生了变化（即：本来是叶子节点的，调整后成了非叶子节点；或者本来是非叶子节点的，调整后变成了叶子节点），那么凡是因此导致节点的叶子性质发生变化的，都一并需要封存。例如下面这个例子：注意组织封存前的准备工作，所有跟封存的业务组织相关的业务都要结转、关闭，例如：1、 结转所有相关辅助账的余额；2、 调整所有固定资产卡片的折旧分摊的成本中心，3、 做应收应付的债券债务转移；4、 相关的订单必须关闭；5、 。注：以后可能会考虑业务组织封存的自动结转业务，但是目前EAS还没有提供这样的功能，所以必须手工结转、关闭所有相关业务。以下是一个因客户组织架构变动而调整的例子：传化EAS项目。