Sailing之多组织

ERP Sailing

企业模型中的组织结构模型

企业中的组织结构体现了权, 责, 利的划分, 一个好的组织结构往往会在效率和公平之间取得一个平衡点.
常用的企业组织模型有:

• 功能型组织结构(包括单层和多层): 是按照企业各个单位所执行的工作性质来构造的，该组织结构一般根据人们共同的专门知识、经验或使用相同的资源而将其组合在一起。
  
  • 优点: 直线管理，一级对一级负责，责权分明，机制简化，号令统一，便于统一管理，提高了内部专业化程度。同时该结构使得决策权掌握在最高层管理者的手中。另外，该组织结构节省成本，减少人事方面的复杂性，而且中、高层有专人负责。
  • 缺点: 缺点是各个部门横向联系薄弱并导致各个职能的成员注重部门目标而不是企业的整体目标。若沟通不利则导致部门间的矛盾，并使工作效率受到影响。由于高层负担较重而忽视战略问题也是该组织结构的一个不足之处。
• 矩阵型组织结构: 由垂直的职能部门和水平的项目饥构结合而成。在该结构中，垂直轴的活动被聚集为功能，附加于垂直形态的是以产品或专案之划分为基础的水平形态。该组织结构适合于一个建设单位同时进行几个项目。
  
  • 优点: 能够充分地利用有限的人力资源。由于该组织结构使得决策具有互动性，因此提高了决策质量，激励效果也很显著。另外，由于该结构将各种专长的有关人员集合到一起而带来的便于沟通，因此灵活性与适应性也大大增强。
  • 缺点: 双重领导．人为地增加项目管理的工作环节。同时该结构淡化了对优先级的考虑，无法对组织内部进行有的放矢地管理；在决策中参与的人员过多，使得决策时间偏长。另外，由于责权不明，使得各个部门冲突显著。因此，如何处理好集权与分权很重要，特别是负责一个部门的两个经理发生冲突时，如何快速地解决冲突显得尤为紧迫。
• 产品团队型组织结构: 具有与矩阵结构相类似的优点，但较易运作而且花费较矩阵结构为少,因为此法是将人员组成永久性的跨功能团队。产品团队结构如同矩阵结构，工作活动是按产品或专案组区分，以减少官僚成本及增进管理当局监督、控制制造过程的能力，而且并非仅是暂时性的指派至不同专案，如同在矩阵结构中，功能专家是被安置在永久性跨功能团队内。结果是所伴随协调其活动的成本较低于矩阵结构，且其工作报告的关系快速改变。跨功能团队恰在产品开发过程开始时即被形成，因此所引发的任何困难，可提前在其主要的重新设计问题产生前就予以消除，当所有功能从开始就直接投入，设计成本及其后的制造成本均可保持较低的成本。而且使用产品团队可加速创新及顾客回应，原因是当职权被分散到团队时，决策可被较快的制定出来。
• 区域型组织结构: 提供较功能结构更多的控制，因为由许多地区性的层级来完成以前由单一集权阶层所执行的工作。大型贩卖组织，如Neinan Marcus、Dillard Department Stores及walMart，在他们开始建立全国的商店后也快速的转变成地理结构，因为此类结构在不同区域的服饰需求下(如在西南日出时穿大衣)可处理不同的需求。同时因为采购的功能维持集权化，中央的组织可以为所有地区采购。如此公司可达到采购及配销上的规模经济，并降低协调与沟通的问题。
  
  • 优点: 灵活性较强，能够适应各个地区的竞争情况，从而使各个利润中心得到发展，增进了各个地区的营销、财务与生产等活动的有效协调。
  • 缺点: 保持整个企业目标一致性方面存在困难，需要更多的管理人员所带来的成本消耗，以及某些职能的重复设置，导致了开支的巨大浪费。
    ----摘自MBAlib

现阶段, ERP的重点是提供一个灵活的, 便捷的模型来反映现实世界的各种组织架构模型, 并渗透到业务模型中去. 下阶段会涉及如何从业务数据中挖掘出各种数据来为组织结构优化提供依据.

ERP中的组织是什么

在ERP的范围里, 当我们说多组织时, 其实是在说怎么对业务数据进行划分, 来实现数据的隔离, 共享, 协作的问题.
为了不陷入形而上的讨论组织学问题的陷阱, 让我们先暂且把组织抛在一遍, 从数据的隔离, 共享和协作问题着手讨论. 最后自然的引入组织的概念.

数据的隔离, 共享, 协作

隔离
说白了, 就是让谁看不到数据. 很多场景下要求做到数据隔离.

• 例一: 在传统外贸公司中, 每个(负责外销环节的)业务部甚至业务员之间存在竞争关系, 因此要求对贸易数据, 尤其是客户数据保密, 因此在业务部或业务员之间需要做到数据隔离.
• 例二: 公司经营大宗进口贸易的企业, 实行购销分离的制度, 购销部门之间按内部价格结算. 那么往往会要求采购贸易数据不对销售部门开放.

共享
与隔离正好相反, 就是让谁能看到数据.

• 例一: 业务员主要负责外勤, 内勤则有业务助理负责, 因此业务员的业务数据需要共享给业务助理.
• 例二: 两个业务员长期合作, 销售和货源分别由两个人负责, 但公司考核利润, 此二人自然构成了一个利润中心. 那么这两人之间有数据共享的需要.
• 例三: 业务部门的负责人需要知道本部门各个业务员的业务数据.

协作
当一个业务链需要多人共同完成时, 那么上下游业务数据之间一定的互通性. 说白了, 就是上游单据推给谁, 下游单据能选到谁.

• 例一: 购销分离模式下, 采购需求的传递;
• 例二: 销售业务员和储运部门之间出运指令和出运资料的传递;
• 例三: 集团各分公司之间的贸易行为;

老系统的解决方案

在以往的系统中, 主要采用分类型的人管人来处理以上三个问题. 按资源, 业务, 资金, 财务, 单证等类型, 分别设置人员管辖范围. 范围内数据对该用户可见, 范围外不可见. 此模式以用户为单位, 逐一设置数据可视范围, 如需采用其他维度的范围设置, 例如, 将某个订单共享给其他用户, 则很难操作(需要另建一种类型, 并设置人管人规则, 然后将该订单单独归入此类型). 但尽管如此, 在处理不是很复杂的业务过程(如某个业务小组一票走到底)时, 这个机制已经足够灵活.

基于类型的人管人还有一个问题, 由于数据可视规则直接关联到人, 因此规则的可维护性较低. 这体现在以下两方面:

• 人员规则初始设置的工作量较大;
• 人员出现离职, 换岗, 升职时, 需要对人员规则作出对应调整; 调整前的信息很难体现在以往业务数据中.
• 人员兼职时, 规则无法区分多个岗位之间的区别.

新系统的解决方案

ERP4.0需要在保持基于类型人管人的现有灵活性的基础上, 弥补其他缺陷.

再次解构人管人

原ERP中人管人是分类型的, 这个类型本质上是和ERP中的数据类型或功能模块挂钩的, 采购, 销售, 库存等数据受[业务]类型的人管人规则控制; 收付款受[资金]类型的人管人规则控制等. 不同业务类型的数据(或者称不同类型的单据)由不同的规则, 这个概念十分自然, ERP4.0也应该继承.

为了解决人管人的这些问题, 必须把数据规则和用户解耦, 规则不再直接指定人, 那么人员的变化, 人员的多岗位设置就和数据规则没关系了. 接下去的问题就是, 我们需要选择什么作为数据规则的绑定对象.

• 注意到对某种业务数据的隔离, 共享和协作在不同场景下具有不同的划分标准. 确定一个场景可能需要很多维度的信息, 可以按业务部门划分, 可以按地区划分, 也可以业务部门和地区的组合来划分. 因此, 从灵活性的角度考虑, 我们不应该对划分标准作假设限制, 而应该将怎么划分的决策交给最终用户. 系统仅提供用来表示划分的实体.
• 考虑到贸易公司确实存在一人多岗的情况, 我们应该支持对不同岗位分别设置.

引入组织单元概念

以上两点换个说法就是: 数据规则需要绑定的对象和岗位有关, 也许和业务部门, 地区等各种因素有关. 和以上概念最接近的, 就是组织. 组织是个通用的中性概念, 他可以按地域划分, 可以按功能划分, 可以按项目划分, 也可以按以上因素的组合划分, 还可以是任何其他划分.

一个系统里可以有N个组织单元, 所有的业务数据都有所属的组织单元, 而每个用户也有所属的组织单元, 数据共享和隔离的单位就是组织单元. 也就是说, 组织单元内的业务数据, 对该组织单元的所有用户共享, 默认情况下对其他单元隔离. PS: 还可以通过设置各个组织单元之间的关系来实现对外的共享, 这一点稍后展开.

引入组织类型概念

再结合人管人规则分类的概念后, 又得到了组织类型的概念. 系统中存在多种组织类型, 类型的粒度根据业务需要来划分. 例如, 我们也许需要设置销售组织, 采购组织, 库存组织, 资金组织等.
每个组织单元都有类型信息. 一个组织单元可以同时属于多个类型.
例如: 业务一部是个组织单元, 它同时属于行政组织, 销售组织, 采购组织, 资金组织, 利润中心组织等类型.

在这样的设定下, 如果将组织单元的粒度设为业务员, 则等同于人管人. 因此组织这个概念在灵活性上至少和人管人具有同样的表达能力, 而其他情况下将更加简洁.

人员和数据隔离范围的概念就通过引入组织解构了, 解耦后就获得了相应了灵活性:

• 人员离职, 更替, 换岗: 只需要将对应的人员加入组织单元或移除就可以, 而不影响数据隔离范围的设定;
• 一人多岗: 只需要将人员加入多个组织便可;

组织单元间共享

以上仅涉及了组织单元间的隔离, 接着考虑组织单元之间的共享关系.
最典型的组织间共享就是上下级的汇报关系. 部门领导需要能掌握下属业务组的业务动态, 集团公司需要汇总各地销售中心的数据等. 决策层总是希望能得到企业各级的经营数据, 用以支持决策.
一般来说汇报关系总是能表示成一棵树, 叶节点汇报到父节点, 最后汇总到根节点. 因此, 每种组织类型的组织单元, 最后总能用汇报关系树组织起来. 而各种业务组织类型的汇报关系树也比较能反映企业的实际组织结构模型.

不同业务组织类型中, 还会有其他组织单元间共享关系. 例如基础资料的数据权限就不能用组织单元内共性, 组织单元间隔离, 加汇报关系树来反映.
系统需要提供扩展点来丰富具体类型下的特殊共享模型. 关于往来单位和商品的管理, 专题讨论.

案例

下图是虚构的A公司的行政组织结构及各员工的工作职责, 我们将以此为依据一步步建立完整的组织图谱.

首先按上图所示建立组织单元, 并为这些组织单元加上行政组织类型, 并设置好汇报关系.

随后分析销售职能的数据隔离关系, 新建一部1组到三部2组这7个组织单元, 为这7个组织单元及其上级加上销售组织类型, 并设置汇报关系. 注意人员和销售组织的隶属关系并不同于行政组织, 需分别设置.


再依次分析采购和通关职能的数据隔离关系.

最后增加财务职能, 此公司双抬头运营, 因此有两个财务组织.

这个过程结束后, 组织单元以及单元的组织类型都已经识别出来了. 汇总如下:

按各组织类型看的话如下:

组织单元间协作

以上阐述了数据隔离与共享, 接着讨论协作.

协作的需求来自于业务流转过程中的岗位交接, 销售与采购之间, 销售与出运之间等都存在协作关系, 在ERP系统中, 体现为不同业务类型数据, 特别是上下游单据之间的引用关系, 勾稽关系. 销售组织和出运组织之间的协作关系体现为出运明细单和销售合同之间的勾稽关系.
因此, 如果可以在组织单元中配置不同组织类型对应的协作组织单元的话, 就可以刻画出组织单元之间的协作关系.
例如: 业务一部既属于销售组织, 又属于出运组织, 业务二部属于采购组织. 如果在业务一部的销售组织属性中, 需要设置对应的出运组织是业务一部自己, 对应的采购组织是业务二部, 那么业务一部的销售合同下推出运明细时可以推给自己部门, 下推采购时, 可以下推给业务二部.

一个组织单元的每一种组织类型都会有一组协作关系, 每个协作关系可以配置多个组织单元.

可以看出, 组织单元协作关系是用来刻画一对组织间的协作关系的. 但将一系列这样的协作关系串接起来, 就组成了一个完整的业务流程. 因此, 组织单元间协作关系也是后续业务流程引擎的基本构件.

其他

组织类型的粒度

K3有10中组织类型, 金蝶EAS中有13种组织类型, 有SAP有78种组织类型.
可见, 组织类型的划分并没有一定的标准, 是根据业务形态, 管理深度而定的.
常见的组织类型设置如下:

基础代码和基础资料的隔离, 共享和协作

基础代码, 基础资料也是业务数据, 也应该有数据隔离共享范围. 但这两类数据相比其他业务数据有一定的特殊性.
一般来说, 基础代码不太会随着业务的开展而变化, 而且需要在所有组织内共享. 基础代码还需考虑一个云端同步问题.

而基础资料的情况会复杂很多.
一份商品资料的建立, 维护和使用会有以下这些情况:

1. 在全公司范围内共享;
2. 在小范围内共享;
3. 完全由创建者掌握并使用, 不共享;
4. 资料共享后, 不允许他人修改;
5. 资料共享后, 允许他人在自己的副本上修改, 副本不共享;
6. 资料共享后, 共享者需要对所有可视范围内的基础资料执行查重;

除此之外, 还存在一份资料的各部分信息分别采用以上提到的各种不同共享策略的情况.

老ERP中对基础资料的管理主要采用公司库-业务员库的机制,
支持自上而下, 自下而上两种管理策略:

• 自上而下, 公司专门部门在公司库中统一维护, 并分配到业务员库中; 业务员库中资料除了编码/名称必须和公司保持一致外, 其他信息都可自行维护(有些项目中, 业务员库中的一部分信息不允许修改);
• 自下而上, 业务员各自在自己的业务员库中建立并维护资料, 资料会在公司库中检索是否存在对应信息. 如果有, 则关联; 如果没有则在公司库建立.

在组织架构确实为层次结构的前提下, 这种方法可以满足1,3,5,6 在某些项目版本中, 也可以满足4. 如果客户公司的组织架构为矩阵型, 产品团队型等较现代的模型, 或者需要多层次(大于两层)的基础资料管理, 则较难处理.

在组织架构确实为层次结构(2层或多层)的前提下, 如果将基础资料也纳入组织的管理体系, 那么自然就满足了1, 2, 3, 但因为缺乏副本的概念, 4, 5, 6无法满足. 其他组织结构模型下, 也较难处理.

方案一:
ERP4.0的组织结构的共享策略是可扩展的.
我们可以利用扩展点为基础资料增加一个组织间共享和分配的策略.

• 组织间共享: 标准多组织数据权限只允许在组织单元树中向根节点方向共享, 我们可以扩展一个可以向任意组织单元共享基础资料的策略. 共享后的基础资料还可以设定是否允许其他组织维护.
• 组织间分配: 我们还可以扩展一个可以想任意组织单元分配基础资料的策略, 分配后的基础资料是原资料的一份副本, 允许共享组织单元自行维护这份副本. 副本也可以再次共享给其他组织单元.
• 查重: 对每个组织单元依次检查所有可见范围内的基础资料, 建立一个去重后的基础资料名称ID库, 以及这个库和真实基础资料的对照表.
  补充了这三点后, 可以满足1,2,3,4,5,6.

方案二:
为每个具体的基础代码或资料设置共享策略. 共享策略有以下几种:

• 共享类: 创建组织可使用, 可维护; 其他组织可使用, 不可维护;
• 分配类: 创建组织科使用, 可维护; 可以分配给其他组织, 分配到的组织可使用, 但是否可维护取决于分配策略; 没分配到的组织不可使用, 不可维护;
  
  • 分配后不可修改: 则同共享类;
  • 分配后可修改: 则创建副本, 在副本上修改.
• 私有类: 创建组织可使用, 可维护; 其他组织不可使用, 不可维护;
  
  

组织变更

组织单元配置模板

相同业务类型的企业或企业内团队, 一般拥有相似的组织模型, 因此如果有组织单元配置模板的功能, 可以降低实施难度.
组织单元配置模板中包含了组织职能及相关参数, 但具体的组织单元则是采用相对于当前单元的相对标示法来表示的, 例如: 当前组织, XX上级组织等.

实现