组织或人员对象类主数据处理协同流程

—连明源

    由于组织单元或人员对象是属于公司最重要的资源对象，无论是企业经营决策管理，还是业务过程管理，都必须十分重视这一类数据对象的管理工作。尤其是在企业决心挑战管理转型这一重大课题、全面建设面向客户的企业级协同平台的过程中，就更加需要关注组织和人员对象的有效管理。为了便于大家理解，我们不妨以ERP协同平台为例来加以说明。当企业内部为了变革的需要，对组织机构和人力资源进行全面调整时，如企业内部缺乏迅速响应的组织和人员信息调整流程，必然会对ERP协同平台的各项关键业务产生消极的影响。前面，我们在研讨协同流程的监控系统方案设计思路时，我们也提到了组织和人员对象在协同流程运行监控中的重要性。总之，如这一关键数据对象得不到有效的维护，将会在如下几个维度影响各种关键业务的企业级协同平台的正常运行：

a.流程系统在流转业务过程中，将出现任务交接对象出错的现象，导致流程中断或延迟；

b.在重要信息发布和传输过程中，有可能出现漏发、错发等现象，导致信息协同方面的问题；

c.在组织或人员变更时，由于没能及时处理权限职责、作业分配等方面的系统设置工作，导致工作出错或迟滞等现象；

d.如此类组织或人员对象的数据出现错误，就会造成大量定制的视图或统计报表出现计算逻辑错误，导致数据统计或流程监控时出现张冠李戴类的错误。

当然还有很多其他会影响协同平台运行的例子，这里就不一一列举了。下面我们介绍几个具体的例子，

以便于大家进一步加深对这一类数据对象也需要在企业级协同平台建设过程中加以关注的理解。

1. 经销商主数据维护协同流程

经销商主数据管理也是ERP或CRM协同平台得以正常工作的基础之一，而且，也和各种定制开发的企业级协同平台的正常运行密切相关，如市场质量管理平台等。这些企业级协同平台必须包含新增经销商时的信息协同处理流程以及经销商信息变更时的信息协同处理流程两部分内容。为此，其系统框架应如图6-5所示。在经销商主数据管理方案中，应十分重视经销商代码的编制方法，有的企业喜欢直接利用代码区分不同性质的经销商，即企图通过代码的不同构成，来识别不同类别的经销商。这种方法，当然具有识别和信息筛选等方面的管理好处。但这种方法，要求制定一套具有足够扩展性的编码体系，并应将其计算逻辑固化在系统中，以便在协同流程中一旦选定了类型后，系统能自动实现编码。但如经销商的类别不断新增或变化，则这种方法有时也会会造成识别上的困难。而且一旦超出现有系统的识别范围，必须重新调整程序，耽搁时间。当然，这种方法最大的缺陷是无法实现全自动编码，所以必然会增加协同流程的作业节点，无法利用ERP系统中的自动编码功能。

 经销商信息协同处理流程系统框架示意图

2. 供应商主数据管理协同流程

供应商主数据的分类会因企业的性质不同而不同，但有一种分类则比较普遍，即将供应商按是否具有合作可能性的状态来区分，如待选供应商、合格供应商和正在供货的合格供应商，在制造企业内部，第一种供应商是指具备生产某类零部件的能力但尚未经过审核的供应商，在供应商数据库中，不会明确其和具体物料的关系，故应该单独管理，作为备选供应商信息库。第二种则是已经通过审核并具有特定物料供货资格的供应商，但是否在供货，则需根据其它的管理字段来区分，第三种当然就是正在供货的合格供应商。在企业内部，有时会因为缺乏统一的数据源和统一的管理规则，从而造成供应商数据混乱的现象，有时甚至会因为职权不明，造成在供应商信息管理问题上彼此排斥、互不通气的现象，反映在主数据管理上，当然就是信息的不一致、不透明的结果。另外，不同的部门关注的对象会略有不同，如物流部门只关注已在供货的供应商，而采购部门需要关注后两种，而设计部门则主要关注前两种。所以，在开发供应商协同管理平台之前，首先要解决的是在企业内部建立统一的供应商信息协同管理流程，确保其信息的统一和透明。

供应商信息管理协同平台架构示意图

供应商数据管理协同流程的设计思路和上述经销商数据的思路颇为相似，只是和该协同流程相关的单一系统不尽相同而已，如上图所示，有的企业的PDM系统也需要供应商数据信息。但不管怎样，关键问题是要确保供应商数据表的唯一以及统一的维护路径。总之，有了这样的数据协同流程，各种单一系统的供应商信息就可得到同步的维护了。

3.用户系统操作权限维护协同流程

任何希望加强协同管理能力的企业，必须充分重视系统用户对象操作权限属性的有效管理，因为，企业内部的人员变动和机构调整现象属于“家常便饭”，随时都有可能发生，如不能及时调整系统中的操作权限设置，必然会导致协同流程出现异常，乃至造成重大的管理损失的现象。除了公司内部各个部门的系统操作人员以外，如我们的系统已经延伸到了经销商或供应商等外部业务对象时，上述经销商和供应商自然也就成了我们要加以严格管理的用户对象。其理由在本节开始时已作了简要说明，这里只说明其主要的模块构成情况。从下图中我们可以看到，当人力资源的员工或部门构成发生变更时，则门户系统中的读取用户变更信息处理模块便会自动启动相应的变更处理协同流程，并在协同平台中完成如下内容的协同处理：

a.修订不同单一系统的用户数据；

b.进行和变动人员或部门相关的各种系统操作权限的设置或修改；

c.进行变动人员流程任务的继承者设定或重新分配；

d.其他相关的数据属性维护操作。

如从SRM系统或从CRM系统中获取操作用户的变更信息时，则同样能自动启动类似的系统用户设置或处理的协同流程。这种用户和权限设置类型的主数据维护协同作业，对于将来在需要在企业之间搭建协同作业平台的企业来说，是必然要面对的基础管理课题。

用户信息变更协同处理流程系统架构示意图

4. 客户主数据管理协同流程

在CRM客户关系管理系统中，通常会有客户信息处理模块。但大家知道，企业导入诸如ORACLE公司

SIEBEL那样成熟的CRM系统，需要付出巨大的代价。这是由于目前的CRM产品市场处于一个强弱分明、竞争力很不平衡的阶段，所以也是一个我们企业会在咨询费和实施费方面被任意宰割的阶段。但作者经和各方广泛的交流，以及对自己公司内部需求的深入调研，认为CRM系统在系统开发方面，并无太多的技术难度，也许在部署所谓的分析型CRM系统时，有一些相对复杂的计算功能模块，但通常情况下，这些模块能否付诸实用，并产生实实在在的拉动市场的作用，还是一个很大的问号，根本不能得出让人放心实施的结论。所以，CRM系统的很多模块，完全可以利用上层中间件技术，由企业根据自己的实际需要来搭建。其中，和客户信息采集、分类、变更以及归档等处理有关的客户信息处理协同流程是非常容易实现的，下图便是作者自己设计的客户信息处理协同流程的系统框架示意图，如采用这样的技术路线来搭建企业级

 处理CRM客户数据的协同流程架构示意图

的CRM协同平台，则其实际成本和现有市场上流行的CRM相比，其降低的幅度将是十分可观的。而且，最重要的是我们可以根据实际需要灵活搭建和及时调整协同平台所需要的功能模块，这才是大家最需要特别关注的不同点。

    从上图可以看出，客户数据协同流程可以从不同的单一系统中启动，并最终将新增或客户身份变更数据流转至客户数据中心。也可通过不同数据采集方式，将不同系统中客户对象管理属性的变更信息及时传输至客户数据中心。至于，客户数据的生成、变更、废除等处理路径和方式主要取决于业务架构及流程分析的结果，也就是应根据每个企业自身的品牌条件、客户特征、服务方式和能力等方面的因数，来设计企业自身的客户关系数据管理模式，完全没有必要去盲目地抄袭所谓世界最先进的CRM的业务架构设计理念。关于这一观点，在后面描述利用上层中间件开发灵活实用的CRM系统的章节中，会有更详细的说明。

更多详情请关注：www.china-soa.com