ITSM系统的建设

peter1388

太好了，即收之则顶之，谢分享。　

peter1388

学习学习，谢分享。

fruit1

佩服，学习中.

hanibalhe

阅，实践中摸索出来的，值得借鉴，参考与学习。

ironforge88

提些建议和感受
“事件的分类
由于我们项目众多，考虑到横向统计的需要，我们要定义一个公用的事件分类，以便运维管理分析，我们分了硬件、软件、网络、数据库、接口、业务这几个大类，日后可能会进一步细化分类，以便做更深入的分析，但这个难度很大，需要时间的积累。”

我看到有些系统可以做到4级细化分类，system->component->item->module, 缩写成SCIM。 我也建议你的系统这样分。

你提出了“ 操作管理”，真是与我心有戚戚焉。这个功能太有用了。


“事件的时长与工作量
在任何一个事件的处理时，对于时间而言，有二个概念，一个是事件的时长，是指一个事件的处理周期（从8：00创建到12：00解决，4小时），一个是事件的花费的资源量，即工作量（4小时的时长中，工程师可能投入了2小时来处理），时长是为了SLA的计算，后者是为了运维资源的分析。”

工时的计算你是怎么实现的？ 是工程师自己说了算是吗？


再提个要求，这个系统要和主流的监控工具有接口,变成全自动化。

破子

工时方面，是由工程师填写的，系统会加一些计算提醒，但主要还是靠工程师填写，然后管理中有一些措施跟进真实性，但问题也是显而易见的，这个课题我们也是思考了良久。
你提到的分类的方面，我们也是有同感，在REMEDY中是用CIT的方式，跟你说的类似。

ironforge88

提出工时的问题，主要是因为在几年前我就碰到过这样的困惑。经过这几年的思考，也有一点想法。
工时的概念应该对应于标准化的工作范围，现在的运维还是处于粗放经营的阶段，这是行业发展的必经阶段，到运维行业到了一个较稳定成熟的阶段，客户的成熟度到一定高度，行业的标杆开始经验的沉淀的时候，福特式的人物就会出现，进行标准化的规范。就像今天的标准型号螺丝也是从五花八门的型号变为国标型号。
这个历时我感觉是比较长的。需要摩尔定律的破产。
所以短期内我不认为会有很精确的工时计算，管理落实真实性的监管成本是非常高的，我个人感觉无法长期执行。

不过有了ITSM的工具，在企业内部，服务供应商内部，还是可以做到某种程度的标准化，但是坦率的说，这不是小公司能做到的。 一是没有这么多分析人才来总结和积累，二是采样的范围太狭隘。所以我要大胆的说一句，还是那些老牌的服务企业制定标准。

顺便推荐一个工具，IBM的ITUP，可以在IBM网站上自由下载，方法论已经非常成熟了。细度也很高了。可以参考一下。

wension18

谢谢，学习中............

scope72

辛苦。收了。

vicky5660

楼主很辛苦，谢谢分享这么好的资料。