[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放

[p=30,2,center]

某中型售后服务公司针对一线维护部门参照ITIL设立另一个数据管理及审计部门，初衷在于管理提升，一线部门负责客户现场维修、现场设备保养、新设备现场实施这三项业务并负责一些常规报表统计；数据管理及审计部门主要负责绩效考核数据统计工作及事件管理、问题管理、发布管理、配置管理职能，工作矛盾开始逐步呈现，以下就发生的表象做介绍：

1、事件管理按照事件升级标准将符合重复报修数量的维护单提交一线部门，一线部门接收后要求事件管理给予临时解决方案，事件管理认为该任务涉及技术解决方案不应该由事件管理给出，最终由一线部门提交问题管理，问题管理接收后与技术部门进行跨部门协调，几天以后协调出了临时解决方案给予一线部门，一线部门拿到方案后进行现场操作后解决，此时客户已经欲哭无泪。

2、问题管理进行跨部门协调，关键取决于个人关系，为什么怎么说呢，应为该公司没有一个仲裁性质的部门来审核已有处理流程中的异常，所以解决方案的获得取决于个人。而技术方面又分别设立了不同的项目组，如果该问题涉及多个小组那么解决时长将再被延长。

3、配置管理根据现场保养任务完成后在ITSM登记的设备及内部配件序列号，录入到配置信息库中，对于录入的信息正确性无法审核，出现登记序列号错误则追溯一线部门现场保养人员责任。另外；配置库中的门店信息部分时常会出现问题（即按照配置库的门店地址无法找到客户），原因是门店的信息变动只对其内部管理部门进行通报和统一管理，而客户处该部门仅与该售后公司市场部接口相关数据，那么一旦有信息变更则通过邮件或人工方式传达，无法避免过程中的失误。

除了以上表象问题以外，该公司物资供应部门（负责仓库及采购职能）提出如下工作先决条件：
1、对于维护配件所需的周转库存数量要求一线部门给出周期数量
2、仓库安全库存线要求技术部门给出
3、周转配件采购数量要求数据部门给出

物资供应部门认为：以上3项若无法给出，则可能导致无法开展正常业务。

综上所描述的表象，笔者没有做进一步的根源问题分析，原因是想配合所描述的该企业的管理环境（治标不治本），来让朋友们帮助分析其中本质，以下再附上各部门牢骚和抱怨：

1、一线部门抱怨相关支持部门名义上支持业务，但实际并没有给予一线业务提供可靠的后勤保障，而各保障部门关注焦点放在了寻找现场作业人员问题从而掩饰自身的不足上。

2、数据管理审计部门抱怨一线部门现场作业不规范导致配置信息有问题，一线工作积极性不够导致事件不断升级而解决迟缓，缺乏服务意识导致客户服务品质下降。

3、技术部门抱怨其他部门只管提问题而不管解决，不管是不是技术类问题都往技术部门推。

4、物资保障部门抱怨一线部门不能给出维护所需配件的周转库存数导致配件供应有时断链，技术部门没有给出安全库存标准导致部分配件库存经常告罄，采购无法得到采购数据导致行动迟缓。

故事讲完了，这家不大不小的公司还在靠特殊的养分茁壮的成长中，山也还是那座山哟，梁也还是那道梁............................

:)

;P

:P 说真的，我很喜欢看反面教材。只有失败才能获得真正的成功。也只有失败的案例，可以令人及早吸取教训，不为了ITSM而ITSM，生搬硬套。。

改革要一步步来啊