本文节选自本人参与编写的《金融企业数字化中台》一书，感兴趣的朋友请自行查找。
组织机构用户数据使用需要有统一的标准和规范
组织机构用户数据是企业运营的基础数据，IT系统中的业务运行离不开组织机构数据。金融企业的IT建设规模大，动辄数以百计的业务系统，如果组织机构数据放任由业务系统各自管理维护，会造成数据标准不统一，系统集成统计等工作无法进行，大量数据的映射转换工作将让人望而却步，久而久之就出现了一个个孤岛应用。面对这些问题，解决方案是显而易见的，首当其冲是需要进行统一的、标准化的组织机构用户数据管理。
对于组织数据标准化，首先需要定义组织机构、岗位、角色、用户等组织机构实体的唯一编码和名称，编码格式要有章可循，制定好编码规范和管理规则。进而可以精确到数据库字段的名称、类型和长度一致，实现数据标准统一。各系统中数据引用和关联组织机构数据时，均需要使用统一组织机构服务中定义的编码，不可擅自修改组织数据，以便系统集成、数据关联统计时的数据准确性和高效性。除了编码和数据标准外，组织机构数据标准中还需要将组织上下级、组织角色用户等等组织数据之间的关系进行统一管理，以确保业务得以的正确分工和执行。
统一组织机构系统为什么推广困难？
然而不少企业又遇到了新的问题，那就是有了统一组织机构数据的目标，落地起来还是困难重重。建设了组织机构、用户管理系统，推广起来却各种阻力。究其原因基本为如下几种：
- 企业规模较大，各子公司的组织架构各不相同，组织机构管理系统无法同时管理多套组织机构，不同子公司组织数据的差异性兼容困难。
- 由于业务系统的业务各有特点，组织机构数据不能完全支撑其业务运行，而组织机构管理系统对于某些业务系统的数据变更持谨慎态度，为了尽量避免影响其他业务，变更测试周期会很长。因此很多系统因为工期原因就妥协为系统内部管理组织数据。
- 部分外购业务系统，其自身包含了组织机构模块，且不具备与组织机构管理系统集成的能力，改动困难，最终还是妥协了。
- 还有部分系统重度依赖组织数据，性能要求高，而从组织管理系统中获取数据的延时性无法接受，因此选择系统内自建组织数据。
上述的几个组织机构管理系统推广时遇到的难题，首要原因就是组织机构系统自身的柔性不足，某些差异化场景不能支撑，变更、集成方面能力弱导致的。如果组织机构管理系统的柔性足够好，即使是问题3也是配合些许管理手段，就能迎刃而解。至此我们又有了更加完善的方案：想要统一的组织机构用户，除了标准化的组织数据之外，更需要组织数据系统能够更灵活、易集成，具备足够的柔性。
组织机构服务一定要有柔性
有了标准化的组织机构数据，但并不意味着一成不变。随着企业发展壮大、业务运营的变化，组织机构也会进行调整以适应新的企业运营模式。结合大型金融企业的一些特点，组织架构数据要具备柔性（可变性）的特点。常见的组织机构的柔性如下：
- 兼容组织机构数据的多样性，如：支持”多法人“模式
- 在主体框架范围内，支持不同业务维度下组织数据的可变性，如：”多维度”模式
- 组织机构数据集成方式的多样性，如：“远程接口调用”、“数据同步共享”等集成方式支持
对于组织机构管理的系统和服务建设，需要对上述的可变性进行规划和支撑。分别说明如下：
多法人模式
对于一些大型集团型企业，集团之下通常会有多个子公司，这种场景就是我们所说的多法人模式。一般情况下，不同的子公司有不同的组织架构。在这种多法人的集团子公司企业，如果需要有公共的科技部门进行整体IT建设时，就组织机构管理的系统或服务来说，需要提供多法人模式支持。实现方式可以参考SaaS中的多租户模式，一个子公司对应一个租户，不同子公司的组织机构用户数据各自隔离，由各自的管理员负责维护。
这种模式下，对于组织机构数据的结构差异化兼容需要着重设计考虑，抽取多个子公司组织的共性进行建模，保留组织机构、角色、用户等模型的扩展属性。除了兼容了数据差异，还需要考虑对于不同子公司的数据、应用、权限进行合理分配。实在无法统一差异的情况也是存在的，这种情况可以考虑单独建设多套IAM系统。具体请根据企业的实际情况选择方案落地。
当然为不同子公司维护多套IAM系统也是可以实施的。可以根据企业的实际情况进行落地。
多维度模式
多维度组织是为了解决以不同业务视角下结合组织机构进行业务运营解决方案。大多数企业的组织机构只有单一的维度，就是行政组织维度，所有的业务比如行政审批、财务核算、科技管理等等均依托行政组织来进行分工管理和执行。久而久之，为了满足业务需要，行政组织变得复杂无比，各种部门、组织、岗位、角色层出不穷，有的企业组织架构中甚至有几千个角色，这么高复杂度的组织机构关系，导致业务人员、IT人员均痛苦不堪... ...
实际上大家会发现不同企业的由于业务特点不同，组织架构各有不同，比如：直线职能型、事业部型、矩阵型等等。这就意味着，组织架构并不是确定不变的，面对不同的业务，可能换个角度去使用组织架构可能会变得更加清晰和高效。比如说，行政组织维度确实是企业最基本的静态组织管理维度，日常办公审批，机构上下级、负责人上下级审批都是非常合适的。如果你从科技管理部分业务的角度去看，通常更关注动态的项目组和项目是哪些部门、人员负责，项目内部有哪些角色和人员，而不关心财务部门的会计岗位上有哪几个人，有些啥角色等。假如我们将组织机构中动态的项目组和关系从科技管理的视角进行重新抽取调整，一定会更加适合其相应的业务处理。
多维度模式，总结其核心思想就是在保障组织机构骨干框架一致性基础上，针对不同的业务维度，对某些骨干组织节点下的组织数据的新增、隐藏或扩展，其变化仅对一个业务维度有效，影响范围可控。这种支持灵活变化的模式，可以让组织机构数据与业务结合的恰到好处，让系统建设和业务处理变得更高效。
提供高效的组织数据实施方案
如果建设统一的组织机构管理系统时，对于数据集成的方案考虑不周，那么推广必然会有阻力。针对不同业务系统的特点，组织机构管理系统需要提供多种集成的手段来支撑，关键点说明如下：
-
远程接口调用：
对于一般类型的业务系统，获取组织机构数据时，建议采用远程API接口集成的方式。这种集成方式，对于组织机构管理系统自身需要对性能、可靠性有较高要求。只应开发查询类的服务给数据使用方，对数据缓存是必须选项。大型金融企业还要考虑针对不同的业务域规划部署对应的组织机构供数服务。远程API协议建议采用语言无关的轻量级协议，如基于HTTP的RESTful风格API。这种集成方式的好处是较简单、易推广，缺点是需要评估远程调用的性能损耗是否满足系统要求。
-
数据同步共享：
对于业务并发量大，性能要求高的系统，建议采用数据同步共享的方案。针对这类系统，单独部署数据库服务，利用数据库的读写分离、实时同步等技术实现数据同步变更，仅为组织机构数据使用方业务系统提供组织机构数据的读权限。
-
提供本地化集成开发工具包（SDK），提升集成效率：
不论选择”远程接口调用“还是”数据同步共享“方式，都可以考虑提供标准的本地化SDK，给数据使用方系统调用。可以为不同类型程序的客户端分别提供SDK，本地化SDK类库还可以屏蔽集成方式的差异，可以通过配置变更的方式切换集成方式。
通过上述两种集成方式再集合本地化的集成开发工具包，使得与组织机构管理系统或服务集成变得简单、高效和可靠，也将更容易面向企业全面推广。
转载本文需注明出处：统一企业的组织机构与用户数据
