PDM与CRM与办公流程中的权限分配的不同

注：本文只是临时笔记。以后可能会重新总结一下。

---------------------------------

维护了几种信息化系统，从通用的应用系统，如CRM，SAP,OA，日常办工工作流，还有自动编译，打包这类专用系统，以及PDM这类更加专用的产品数据系统，

虽然，每种系统，有用户管理模块，但实用起来，发现差别很大。

大部分地方都是类似，但本质的区别，是如何对待团队的认知上。

不同的公司、同一个公司的不同部分，对团队、职级的要求，各不想同。

这时在，我主要想描述的一个方面，是人与团队的关系、人与领导、人与职级的关系。

第二个方面，是角色与团队的关系（这最令人头疼）。

比如，ERP系统，我们公司用的是SAP，它的用户管理，是我们所有体系中最严格的，用程序员角度，简单来说，所有的人员相关信息，在一个表中。

因为要求一个部门，正级的审批者只能有一个，也就是说，正级管理人员，与部门（硬性团队）是对等的。

从而SAP中，骨子里，就有一个极为严格的等极体系。——我是说从管理的角度来说，或是从审批权来说。

理论上，OA工作流和大多数日常审批工作流，需要尊守这个体系就足够了。因为大多数审批，是看权不看人。这样，当员工离职时，系统，有能力自我适应。

职级则是另一套体系，与工资相关。这时我们不多说了。

-----------------------

再说CRM，我们公司，采用的CRM是微软的Dynamic CRM 2011，CRM的权限，与基于SAP体系的办工流又不相同。

最明显的一个特点是，CRM中，以对象为核心，而不是以工作流为核心。

CRM的工作流，事实上是对象的状态的变迁。

那么每个节点的审批权，是如何定义和指向的呢？这是微软做得很聪明的地方。

说实话，就个人而言，我还是比较喜欢微软的这种模式。这么说吧，微软做了简单的折中。

CRM中，角色与团队的关系，是其创新点。

CRM权限配置界面的核心界面，就是那个角色对模块（对象）的交叉权限表。

每个角度，对一个模块，所指向的位置，分别有两个大的方面：读与写。每个方面，又分为对自己、与平级、包括下级、包括上级、全部（对象可操作）。

这样一来，解决了审批权的问题。

当然，这个体系是基于团队实现的。（以后我会补上图）。

从权限的角度来看，微软把每个角色，再赋给个人或团队。然后通过角色的能力（工作能力和可见范围），来决定某个人是否有能力对某个对象（如商机）进行审批。

==============================================

而与产品相关的，如PDM这类专业管理平台，则是另一种样子。

PTC的windchill平台，有几个特点。

1） 如果说SAP，以人和权力为核心（体现了德国人的风格）,CRM是一种折衷，那么windchill体现了完全客观的、民主式的、物化的、以产为中心的思路。

2） PDM真正体系了团队协作的意志。比如，一个产品，每个部件，由多个团队（可能是结构、板卡开发团队，还有采购、计划、项目管理、PE等等）共同完成。

这种差别，体现在实现上，对于单一的流程，节点非常多，而且许多节点间跨越了部门与团队（角色，PDM以角色为核心权力划分单位），而且，多数节点，都是汇签（不是是真正的vote，大多数节点，只要有一个人签就可以），而且，许多节点会循环往复。

目的是为了产品的质量、成本、可生产能力、得到保证。

其实与微软的CRM有点象，好象在CRM之上，又加了一个强大的流程平台。

PDM中，没有只个员工、只个权力从属于另一个权力的地方。

这是本质的不同。都是平级的，SAP如果是军棋，那么PDM就是象棋。

PDM的流程，也是漫长复杂的。

当然，有些OA流程，也是漫长的，但一般不会很复杂，OA流程，体现的都是权力意志，而不是专业精神。OA流程里，可以被打回，但循环的时候没有，在PDM中，循环，往往是正常流程的一部分，就象去医院以前需要划价一样。

3）所以，在PDM中，第一层是产品或存储库，第二层是角色。

特别是，在PDM的角色之下，既可是以单个员工，也可以是用户组。

也就是说，用户组从属于角色，或是被指定成为某个角色——这里有点象SAP中，部门A正，与部门等同的意思，但又完全不同——这里只是为了指定角色方便：

因为，在PDM中，第一层是产品或存储库——每建一个新的产品，都需要重建一套角色（有模板），然后为每个角色赋上人员。

如果是一个大型公司，这也可能会比较麻烦。

而用户组，是唯一能跨产品的（角色虽然在流程角度来看，也是跨产品的，但角色的内容并不能跨产品，因为产品决定着哪些人在这个产品中）。