如何搭建梯队式的ITSS服务管理架构
本帖最后由monicazhang于2015-9-2416:45编辑20150924淡然续上
v组织/人员a.建立梯队式IT服务架构；
解决的问题：在新技术开发中心扁平的行政架构中，没有形成梯队式的IT服务架构，从而导致在IT服务管理过程中，从事件的受理记录到事件的结束闭环没有形成有效、有序的管理过程；造成员工工作效率不高，工作情绪不高，任务繁重又不知问题出在哪里。ITSS考试
目标和意义：中心需要从IT服务管理的角度，在现有的组织架构基础上对人员分工做一些调整。如上图所示，可以将和事件管理相关的研发室、运维室以及厂商和服务提供商，按照IT服务管理规范构建三线＋厂商和服务提供商的架构模式。一线工程师即统一受理热线，在ITSM中又称为服务台，它是中心IT服务管理同用户部门的唯一接口，代表着中心的业务形象。它不但向用户提供了一个良好的服务窗口，同时，它还需要解决一些业务咨询，远程可以处理的简单问题，在线指导用户自己处理一些简单问题。工程师的主要技能依靠知识库、自身技术积累、培训等，理论上在一线工程师应该解决80％的事件，在我们访谈和调研的同时，我们也了解到目前在中心，业务咨询和一些简单问题确实占了相当比例的数量。一线工程师作为事件的第一责任人，应该独立于其它服务部门，一线工程师需要随时监控和督促事件的及时完成，必要时，一线工程师可以将事件进行管理升级和技术升级。一线工程师还应该有能力将无法解决的事件按照业务或者功能分类，并分流给业务维护组和运维室进行处理。由一线工程师将最终解决的事件向用户进行最终确认及闭环流程，并获取用户满意度调查。二线工程师即研发室的业务维护组和运维室，主要负责对一线工程师无法处理的事件进行进一步处理。同时，必须将他们对事件的处理过程详细记录在平台中。三线工程师即研发室的业务开发组、渠道支撑组和统计分析组，对于二线工程师解决不了的事件分流给这三个组的接口人即组长。组长判断是故障类还是业务需求类，如果是故障类则交给故障处理专家处理；如果是业务需求类，则交给需求分析工程师进行处理。建议，故障处理专家和研发工程师职责分开，但是内部可以协调进行轮岗。厂商/服务提供商，对于中心运维室无法解决的故障，可以交给厂商和服务提供商进行支持处理。厂商/服务提供商不能直接存取中心的IT服务管理平台，厂商/服务提供商处理完故障后，必须将处理结果和过程提交给中心工程师，由工程师将其填入IT服务管理平台中，这样，一方面，可以保障IT服务管理平台的信息安全；另一方面，可以使中心工程师的技能得到提升，同时还有技术积累。这样各条技术支持线按照规范的流程协作工作，就可以在很大程度上提高员工的工作效率，同时，形成各线相互监督，也容易推动大家工作的进度。调整后的中心行政架构如下，在图中灰色的模块是新增加或者需要调整的组织模块：ITSS认证
b.在流程中定义清晰的人员角色和职责以及技能要求；
解决的问题：如果人员角色和职责模糊，会在流程的执行过程中出现‘扯皮’现象，同时，也会给流程的推广带来障碍。
目标和意义：在流程设计的时候，我们必须明确定义流程中所涉及的角色，以及他们的职责和技能要求等。如，除了上述的三线工程师和厂商/服务提供商外，我们还需要定义事件经理等角色。
c.形成部分岗位工作人员轮换的工作制度；
解决的问题：在IT服务管理流程中的各个岗位都是协调完成相关的事件，每个角色之间都需要很深的相互理解和了解。如果，他们之间是脱节的，那么这样的流程只是一盘散沙。
目标和意义：为了使各个角色能够互相了解，在情况许可的情况下可以让有些角色定期互换，一方面，可以增进各个角色的相互了解；另一方面，也可以消除不同工作岗位的误解。如，在业务开发组中的故障处理专家和研发工程师就可以轮换。或者二线工程师可以和一线工程师轮换，一方面，可以使二线工程师更加清楚了解并理解用户的需求；另一方面，可以使一线工程师可以增长技能。
d.指定流程负责人（事件经理），实现对流程的控制和改进；
解决的问题：很多流程实施后，没有回顾、评审和完善的过程。ITSS培训
目标和意义：制定流程负责人，其主要职责除了日常处理行政升级和技术升级的事件外；还需要确保和问题管理流程经理及外部供应商等部门的有效合作；确保正确和广泛地收集和分析事件数据，发现IT和业务相关的潜在问题；通过受理台的作用及良好的服务态度来确保客户的满意；回顾流程的执行情况，改进和提高事件管理流程的有效性和效率。
待续http://www.ITILxf.com/thread-52426-1-1.html本帖关键字：ITSS
页:
[1]