学习资料： ITIL培训基地专家讲堂直播 300期视频回放

          服务目录的定义就不说了，坛子里面有很多。IT部门作为一种服务性质的部门，对业务部门输出的是支持和服务。

          刚开始接手的时候，还是去年的版本，条目还是比较清晰，记录了服务项、服务描述、服务水平、约束条件、服务时间、责任部门和接口人、来源等等。不过其中服务水平和约束条件大都是空白，这样一来，业务部门没有条件的情况下，不知如何通过信息系统里面的条件来申请IT部门的服务或者是变更问题等，这一项也起了一个引导的作用，比如需要几台服务器，可以通过中心对外的系统申请服务器，而IT部所提供的服务水平就是在几天之内能提供出来，就是交付物。后来整理就依据系统能提供服务的具体情况，给每个条目规定服务水平与约束条件。

          这里的服务水平，个人觉得算是中心对外服务的一个容量。老大提出了一个”60“分的概念，就是标出核心服务，这些服务水平必须是量化的，比如某个系统可用率达到99.9%这一数值，意思就是在多少分钟内无故障的比率。而核心服务最终必须是kpi考核里面固化的项目，且它的权重也最好是固定不变的。而且在最终最合规性检查的时候，也可以它作为依据，比如变更完成率等等。再到后面的满意度调查，整理出的结果公布，对有问题的进行整改，后面复查等形成PDCA，都起着非常重要的作用。

         想到的这一点点就写下来，大家可以多多发表意见，上面的只是个人的一些经历和感悟，有不足还请大家多多提出。。

a good question in practice

标准最大的挑战在于灵活的业务模式带来的诸多特殊情况

服务目录分为技术服务目录和业务服务目录两部分。在之前的yy讲课里我详细的描述过如何创建的，有空可以听听。