ITSM-Ivanti体验报告

ITSM，又名IT中的ERP。出发点是让IT向服务型组织转变，合理利用开发资源，完善配套IT流程，并沉淀IT能力。ITSM普遍采用ITIL理念，分为事件、问题、变更、配置、发布五个核心模块。公司全员对于IT的认知，80%来自运维服务人员。客观来讲，运维人员，一般与“服务”二字很难沾上边的。且方式较野路子，有问题，电话直接call，技术人员直接解决。特别涉及到桌面问题，很可能是重装个系统，按照打印机驱动，服务人员每日响应呼叫，奔波在现场。应用系统问题，大问题到还好，需要BA定位。小问题，例如bug、权限、账户开通，也是直接打到开发人员获取支持。有的产品不稳定，总有bug，问这一周做了什么？技术答曰忙于运维，可到底出了什么问题，保留记录有限。因此急需ITRP，IT资源规划管理。

ITSM是个有意思的项目，业务方为IT内部。业务调研只需在大屋子内转一圈，挨个调研各产品/项目团队需求。项目总会涉及到数据、组织、流程。借着项目，推出需求变更流程、问题处理流程等IT流程；汇总、整理保存在本地、SVN的知识文档；整理问题分类，细分到三级，一级为四大类，基础架构支持、应用系统、桌面支持、信息安全，二级为应用系统或处理单元，三级为功能模块或功能点。这样一份清单即可看出IT能力的全貌。

系统上线运行效果不如预期，没有得到IT内部用户的认可。这就很值得反思，IT做给IT的如此简单系统，都不好用，那做给其他部门或企业级的大项目呢？原因，一是普遍问题，立项时没有想清楚，当初是由运维部门主推，其他部门、应用系统团队参与意愿不高（现状也是如此，变成了运维服务接收、指派工单的系统）；二是调研不充分，场景没有想全。有的团队人少，三四个人。而变更流程长达七个节点，经常是BA一人填写、审批三四个节点。有的产品自带缺陷收集、跟踪功能，用户已习惯在上面提交，如何与ITSM对接欠缺考虑。事件问题收集后没有考虑如何转为story，造成团队收到问题后，先在ITSM接收，再在项目管理软件创建任务做过程管理，解决后再登录到ITSM关闭。造成了额外的工作量；三是用户的业务成熟度不够，具体来说流程有问题，同时管理不够规范；四是僵化阶段政策力度不够，没有让用户养成习惯。每周只是发报表通报，记录每一位挂了多少已解决/未解决的事件及问题，没有对应奖惩机制，也没有部门发文；五是上线后缺少持续