[p=30,2,center]学习资料：IT运维管理社区专家讲堂直播300期视频回放[p=30,2,center]
[p=30,2,center]
2010年3月底公司接受了ISO20000审核机构的年度审查，这已是我们第三次ISO20000外审了，审核员查验出一些问题，最后有1个次要不符合、13个观察项、1个可改进空间。这家审核机构的审核员我个人还是比较认可的，无论是背景、资质、经验与职业表现都很让人信服。每年提供的审核意见也的确可以帮助我们做改进，这也是为什么我们每年指定这名审核员的原因。
在两天的查核过程中，也有一些大家对标准的理解的出入，我跟审核员做了一些讨论，由于在审核过程中，不管是时间还是时机都不利于这种讨论，以避免产生冲突或争议，就只点到即止了。比较大的分歧有2点，在此写出来做个记录或交流。
标准的第5章，规划和实施新服务或变更服务（Planningandimplementingneworchangedservices）。这里外审人员对这里“服务”的理解是：我们在认证审请时填写的四个服务：IDC服务、桌面服务、软件服务、服务台服务，新的服务意思是当我们增加第五个服务时，这个服务就是新的服务，变更的服务是当我们原有的4大服务的服务目录发生变化时，就是变更的服务；而我的理解是，我们认证审请的四大服务，只是我们的服务产品，当我们的服务产品有一个客户购买后，签订了合同后，此时才算是一个服务，原有的四大服务只是一种概念、目录、索引、范围，当它不发生实质的动作前，它只是一个不具备实质性的名词，我们一共有60多个项目（合同），这是60多个服务，只是这些服务按照某种特性被分类成四大类，最终形成的四大服务产品，这只是为了方便市场行销或认证申请而做的名词，或者说它是一个服务目录，也就是我们公司的产品目录，对这个目录进行增加删改，是不会触发标准的第5章的要求的，如果我们的跟一个客户签订了新的服务合同，这是一个新服务，它会触发标准第5章，如果当一个合同的内容（如SLA、服务内容）发生变化时，这是一个变更的服务，它会触发第5章。这个问题的核心在于大家对什么是服务的理解不一样，对于审核员来说，你的认证范围上写着4个服务，这就是服务，对于我而言，一个合同就代表着一个服务，或者更精确的说，没有合同就没有服务，服务是实质性的，而不是概念性的。这个问题更深的讨论就会介入到服务目录，从我个人的认知上，我认为我们提列的四个服务，就我们的服务目录，最**的服务目录，服务目录的这个概念非常容易混淆我们，我们出去找客户时，我们拿出一个东西告诉对方，我们可以做什么，这个就是服务目录，它展现了一个IT服务商所有可以提供的服务产品，最**的目录就是我前面说的四大服务，IDC服务、软件服务、桌面服务、服务台服务，其下一层就是进一步把IDC服务进行拆卸成各个子服务，这种分解可以一直持续到最后一个或以独立形成服务价值或商业价值的集，我们暂且叫它A类服务目录。当我们跟客户签订了一个合同时，合同上需要明确服务的内容，大家以条目的形式拟定清楚了，就个也就是大家常说的服务目录，我们暂且叫它B类服务目录，事实如果一个公司的规划与管理非常具有规范，B类服务目录一定截取于A类服务目录，而无须另外增删改，所以事实应该只有一个A类服务目录，由于大家的规划与管理不规范造成了我们只有大量形式各异的B类服务目录，而没有一个A类服务目录，如果我们A类服务目录建设完整，每年可以基于服务目录做成分与收益分析，从而找出最具价值的服务产品，或开发新的服务产品，每年发布一次新的A类服务目录，让它成为最新的IT服务商的菜单，这是我在2008年规划公司的IT服务管理平台时一个希望实现的想法。
在标准的第9章配置管理中，提到需要在发布到现实环境前，需要采用合适的配置基线，这里我与外审员的分歧有两点，第一是对配置基线的定义，第二是对实现配置基线的动作合理性。
如果我们要发布一个V1.5版本的软件，标准的要求是在发布之前需要对此软件做基线管理，它的基线是什么呢？，到底是CMDB记录的与此软件对应的CI信息，还是这个软件的V1.4版本的软件包？或者是这个软件对应的CI信息与V1.4版的软件包？我不同意将标准理解为是要对CMDB中对应的CI信息进行快照，才是基线管理，而是将实体的软件包进行快照存档才是基线管理，就如要把一个人进行备份，是把这个人完全从肉体到灵魂进行克隆才算是基线，还是把这个人的人事档案进行备份才算是基线，我选择前者，其次的，我也能接受两者加在一起备份才算是基线的观点，这是我与审核员的第一点分歧，虽然互相没有说服，但都暂时接受最后一个逻辑，来讨论第二个分歧，标准中说要在发布之前做基线管理，我们现在的做法是，对于实体的软件包而言，每一次版本的软件包我们全部在VSS中入库管理，这样我们在V1.5发布前，V1.4必然是已存档管理的，对于CMDB的CI信息而言，每一次CI信息维护时，CMDB自动记录维护之前的CI信息，只要有数据更新，就记录维护之前的CI信息与维护之后的信息，这样在发布V1.5发布前，V1.4的CI信息必然也是在CMDB当中的，当在CMDB中维护此CI的版本信息时，必然会造成多一个版本的快照，但这样的动作逻辑审核员依旧认为不合理，他认为没有实现标准所要求的，在发布之前建立配置项的基线。
可惜的是由于是外审过程，不便于做更深入与尖锐的交流讨论，我个人也无意去为我们的做法做辩解，只是希望知道哪一个是正确的理解或做法，也可能是在交流过程中，大家的沟通理解的误会，也许大家的认知实际上是一致的。这几个分歧都让我联想一些哲学层面的问题，即言语的不真实性，我们容易陷入词汇与概念本身，而忽略真实，标准也容易带来概念的僵化，如瑜珈经所说的一样，当真实与语言不符，就产生了分别知。在此次审查的过程中，我开始感觉到标准所带来一个很大的负面作用，即它会扼杀制度流程创新的尝试，在2009年我们对IT服务管理体系做了一个很大的视角转变，它会从结构与逻辑上完全改组管理体系，甚至重新理解流程的运行与组织，我们只一些项目上做了尝试，可以想象这种大动作需要耗费较长的时间来调整，如果全面推广绝对超过一个年度的周期，在调整过程中，会带来一系列的问题，对于ISO20000这种标准，最重要的是记录问题，这就会带来很大的符合性的风险，结果就陷入两难之境，最保险的做法是不做这种尝试，如果尝试就必须面临需要编“规范”性的记录的问题，对于一个管理负责体系建设的人而言，他把管理体系建设得更好，他个人并不会因此得到更多，成绩更多属于业务部门，但如果他把一个已获得认证的证书弄掉了，他个人却受到的惩罚将是巨大的，这样负责管理体系的人必然选择保守。标准在约束建立规范的同时，也很大程度上制约了制度发展创新。标准另一个值得质疑的地方，就是到底我们是需要一个记录着的系统，还是系统着的记录？，这实在是一个很让人烦恼的问题，不得不承认，我有时的确想过去建立一个以年为单位的成套的记录与维护手册，在每年的外审之前，做一次记录成包复制，再按照维护手册把记录的做一次修改，成为过去一个年的符合证据，这样可以解脱审查的束缚，更快的进行管理体系的创新与调整，因为在面临任何一次管理体系改进时，需要在认证符合性、记录与实质效果上做均衡，实在是一件很麻烦的事情。
评论
最近我们都做了ISO20000LA的培训。对于你的这两个问题，我的理解是：ISO20000-1是“教条”的标准，所以审核老师必定会专注在条款，因为标准是这么要求的。特别是带有“shall”字眼的条款。
通过培训，我发现理解ISO20000不能用ITIL的思路，那样只会影响ISO20000的审核。关于你说的发布和配置基线，我的看法和你一致。这是因为我们都是做过运维的人，但目前的ISO20000审核老师，好像多是从信息安全转到ISO20000审核。你注意看他们的背景。所以有可能在理解标准上更多考虑的是标准的执行。
你的这篇文章，我准备在同事之间进行讨论。多谢了。发布者ewaysun
这个问题的解决办法只有一条，那就是ECRS。因为只有这样才能大大降低系统复杂性、大大减少管理内涵、快速聚焦到关键问题上。正因此，我们提出了围绕企业架构EA进行应用替换性测试这么一项业务。
事实上，可以想见的情况就是：外审拿标准的时候是没有针对特定对象的内涵大小，只是一些规则；而这些规则是众多实践的一种总结——这也是大家乐于做外审的一个重要原因；多的只是工作量问题——实际上也正是因此很多审计机构大量招募新手的可行性所在。因此，对于做实际工作的，也应该因势利导，将工作中出现的问题进行深层次的分析与应对，而不是形式上的——形式上的分析与应对是一个陷阱，只会令自己有负担。更重要的是，由此而形成的局面对将来的发展是一个基本面，将所有工作真正推进到下一个PDCA循环——而这个才是POOGI的核心所在。
当然，这个会涉及到部门建设的问题，毕竟基本局面改变了，需要解决的问题也改变了，对人的要求也改变了。对我们来说，也会从技术层面的东西上升到管理咨询层面的东西，以便能够顺利承接下来以此形成的变化以及新的局面。而这时候作为管理者也将发现，自己才真正上了一个层次，整个事情的发展才真正上了一个台阶。发布者pctcn
|
转播
分享
淘帖
()
