MSCRM杂记（1）_DisSun_2012.2.13

 准备从今天开始，有空就把白天关于CRM的事情记录一下，纯属闲得蛋疼的举动，应该毫无技术含量了，所以如果是大牛，别笑话，咱只是自娱自乐罢了。

仅仅出于一种想法，那就是工作一段时间，每次回想起来，都不知道自己做了哪些事情，所以需要一个笔录，记下每次的心得及重点，方便每月做总结时有素材。

 

业务部门的调整，及人员的停用

公司的组织架构调整了，CRM系统的业务部门结构也得跟着调整，最近一直就忙这事。最无奈就是改业务部门结构了，也不知道微软CRM的奥妙何在，业务部门一旦新建完成了，名称就不能再改了，一旦打错字就废了，更何况这次整个公司的业务部门大调整，出现了很多新部门，合并了许多旧部门。没办法了，硬来，该停的停吧，结果系统出现一堆的停用部门，真的欲除之而后快。后来一想想，其实也有道理，部门虽然不在了，但是数据还在啊，如果直接把部门给删除了，那么以前的数据怎么办，特别是如果一个公司用了这个系统5年了，那么多数据，都是挂靠在这个部门下面的，那么这一删，可就把这个企业这么多年积累的数据给毁了啊。

但是看着这些部门也是在太揪心，毕竟公司用这个CRM没多久，数据都不是很重要，我想了个法子：新建一个‘停用部门’的新部门，然后先把那些废弃的部门变成他的子部门，然后再停用，就一切都看不到了，嘻嘻（也许会带来历史悲剧，其他童鞋切勿效仿）

对于停用的用户，也很纳闷，人不在就停用呗，不能删除，我依然理解，但是打开看一个部门的成员时，这些停用的成员居然和活动用户混在一起的，我都想不通微软怎么想的，难道老外对离职人员就这么惦记嘛？要是公司用了N年这个部门换了N波人，岂不是密密麻麻的离职人员名单？这个还不能效仿业务部门的做法，毕竟人跟数据、跟部门的联系非常密切，就让他深深的扎根在部门里发霉吧，我这一代人解决不了的问题，就留给我的接班人来解决。。。

 

安全角色的分配，及角色人员的放置

接手CRM时，整个系统是极为混乱的，现在应该说略有好转，不过仅凭我一人之力，怕是很难有大的突破了，我也不急，慢慢来吧，一点点改进。

今天就是重新配置安全角色，对这玩意，虽然可以改角色名，但是强烈不建议修改，因为Onload脚本中的许多角色权限控制的，都是按角色名来写的，我就无所谓了，我已经准备要把OnLoad的脚本进行第二次梳理，重新写写。以前总是很烦系统中那些不需要的模块，老是出现，既占地方，又容易引起业务员的误解，一直不知道怎么办，现在我终于知道了，只要把不需要的模块的读\写\追加 权限通通去掉就OK了，在界面上再也看不到了。

不过有一点需要注意，不要看着不顺眼就干掉，很多属于实体设置的权限，别乱来，搞不好会出现你难以想象的问题，比如某个界面的某个想要的按钮没有了，但是并没有去掉该功能权限，这个应该是跟实体关系有关的权限被你干掉了，请先查阅相关英文资料再行修改。

对人员的放置，在CRM组织结构中比较讲究哦，开头时很多人把业务部门结构模拟 公司现实结构建了一堆，最后要运行时才发现，真TMD坑爹，完全不是那回事儿（当然大部分的公司都不可能遇到这种状况，因为都是技术团队在做实施兼开发，唯独我公司比较搞笑，派我这牛犊一人搞CRM），CRM的业务结构是N叉树结构，父节点对子节、孙节点有控制权，但是对兄弟节点是没有控制权的，除非你给他设了一个‘全圆’的权限。

所以你如果想设一个大区经理，你就把他放在某某大区里面，然后赋予‘上下级’权限，然后它就能管理下面多个部门了。

 

多沟通，多了解真实流程

发现实施CRM真不是件容易的事情，特别是对一个技术人员，大量的沟通占用了大量的时间，以前刚开始时，啥不懂，上面说什么就做什么，其实上面说的，不一定是真正的需求，你得自己去挖掘，多跟一线使用的人员去沟通，多看看，多了解 他们日常的工作程序，这样制作出来的流程才能得到满意的回复，否则抱怨的唾沫将要把你淹没。对于上级的需求，要去伪存真，抓要点，抓主要矛盾。有了重点，怎么实现，实现的形式，那就可以‘将在外，君命有所不受了’。我其实在这方面才刚刚醒悟，之前走了N多弯路，希望能补救....

时间到要看自考书去了，明天看看有没有空再写写