20150924 淡然

续上




4    建议

通过评估分析的结果，我们已经清楚地认识到我们在IT服务管理方面地不足，我们怎么样能够梳理各种流程，使中心的IT服务管理工作有序地进行，怎么样才能够增加管理的透明度，怎么样才能够使相关人员各行其职、各尽其能呢，怎么样能够提升员工的工作效率，怎么样能够树立IT部门的形象，提高用户满意度，怎么样能够衡量员工工作饱满度，合理分派资源……？                           ITSS考试

根据深圳某公司新技术开发中心的业务特点，结合中心当前的实际情况，给出如下ITSM项目近期需要建设和完善的建议，同时也提出了中期和远期建议。

近期、中期和远期的目标是有逻辑关系的，近期建议是在当前条件和当前迫切需要的基础上需要完善和建立的内容，其中主要包括：完善事件管理（包括受理台建设）、配置管理。主要目的是：将处于“救火队”状态（无序的IT管理状态）的IT服务提升到被动服务，提高客户的满意度，能够及时响应和迅速解决突发的IT事件，建立有效的升级手段和途径，保证突发事件的解决；同时，能够建立规范的IT设备配置管理数据库，为IT服务管理建立数据支撑中心。

在近期建议或者近期目标实现的基础上，需要进一步实现IT服务管理领域中的其它模块，即中期建议主要包括：问题管理、变更管理和服务水平管理。主要目的是：由被动服务提高到主动服务，因为被动服务只是保证在规定的时间内能够及时有效地解决发生的问题，不管解决的多么快，实际上都对业务造成了一定的负面影响，所以我们更需要提供一些主动的IT服务，避免事件的发生，增加对业务的贡献；同时，通过规范的变更控制可以使在近期目标中的配置管理数据库中的数据更加准确和严谨；另外，在近期目标实现的基础上，即丰富的事件处理数量数据、设备故障发生频率数据、平均解决时长数据、服务目录（事件分类）数据等，利用这些数据可以同用户签订服务级别协议（SLA），一方面，可以向用户提供可以量化的服务指标；另一方面，也可以将用户尽可能地约束在既定的服务范围内。

同样在中期目标实现的基础上，需要将IT部门和IT服务管理的价值在业务中真正得到体现，即远期目标，主要包括：可用性管理、持续管理、能力管理和成本管理。主要目的是：能够根据企业的业务情况和IT的支持能力与以往的支持数据，能够预测、监控和管理系统的性能，预测系统增长的需要，进行性能分析，为系统扩容等提供数据和判断的依据；同时，能够对公司IT服务的可用程度和持续性进行管理，一方面，使完善、规范的管理能够在一定程度上提升IT服务的可用性；另一方面，能够对IT的可用性和持续性有一个科学地认识，能够向用户做出合适的承诺。另外，IT部门一向都是为业务提供相应服务的部门，而IT技术和管理都是日新月异，具有相当的复杂性，很多时候，IT部门总是‘花’钱的部门，而不是直接盈利和收入的部门，IT部门在企业价值上得不到真正意义的体现，通过规范的服务管理可以将IT资源形成成本性的量化指标，能够和IT用户结合起来，进行IT成本核算，从而真正体现IT部门的价值。

4.1  近期建议

由于新技术开发中心工作的主要特点和工作重点是故障解决和业务需求的实现，同时，中心还有当前资源上的限制，为了解决以上通过评估得出的主要问题，我们建议当前新技术开发中心重点需要建立和完善事件管理和配置管理。

以下还是从流程、组织/人员、技术的三个角度，分别解释和论述这两个流程如何实现，需要做哪些工作，为什么需要这些工作，即这些工作的目标和意义。其中我们讲的事件主要包括运维故障、业务故障、咨询、业务需求、服务请求等。

n  改进事件管理

v  流程

a.   建立规范统一的服务台，采用故障和业务需求的集中受理，分散支持的方式，使服务台成为中心和用户部门间的唯一接口；
解决的问题：目前在中心有多种渠道和用户进行沟通，用户发现了问题可以通过中心统一受理热线、运维受理热线、运维支持手机、运维工程师电话、运维管理层电话、研发人员电话、中心协作平台、传真、10000号客服服务平台等。这些看似很丰富的沟通渠道，实际上为中心的IT服务管理带来很多问题：事件记录分散，事件处理不可跟踪和回溯，工程师的精力分散，相关管理层卷入日常事务处理中，员工工作不可衡量，事件丢失，员工工作职责不清，多种渠道的事件使工程师手忙脚乱，疲于应付等。同样，这些渠道并没有使用户感觉到方便，反而情况更糟糕，当用户发现问题时，用户面对这么多渠道无所适从，很多用户不知该找谁，打什么样的电话。很多用户会直接打电话给熟悉的工程师，而报告的问题很有可能非该工程师所能，其实，用户也不希望采用这种方式，因为很多程度上受制于工程师的工作情绪；另外还有用户会直接打电话给相关相关管理层，无形中为中心工程师造成很大工作压力。同时，即使问题被报到中心，但是经常象是石沉大海，没有及时的响应，也不知该向谁询问问题处理的程度，也许中心工程师忙得象‘陀螺’，而业务部门或用户还是很不耐烦、抱怨、投诉。这些矛盾和问题正在恶性循环，成为中心IT服务管理的主要阻碍。

目标和意义：通过建立统一规范的服务台可以解决上述问题。首先，统一的受理服务台可以使用户在遇到问题或事件时很清楚该打什么电话；对于用户申报的问题，用户可以随时向服务台咨询问题的处理情况，同时，服务台也可以主动向用户通报问题处理情况；另外对于中心内部，事件可以被完整地记录，同时事件可以被跟踪和控制，中心的相关相关管理层也不会被卷入日常事务中，中心工程师不会被用户的电话干扰，同时，也避免很多不必要的压力。

b.   制定清晰的事件逻辑分类；

解决的问题：目前中心的热线或工程师在接到用户的问题申报时，不作分类或者根据经验模糊地分类，导致事件在按照分类统计时很不准确，无法分析出相应的事件规律；

目标和意义：可以根据中心工程师的功能和一些业务特点将事件做清晰的逻辑分类，一方面，有助于将事件单更清晰地分派给相应的工程师或工作组；另一方面，在对事件的分类统计时，可以分析每类事件的规律；

c.    定义严格的事件影响程度、优先级并和所需要的解决时限关联起来；
解决的问题：目前，中心对于事件的分类只是局限在省电信公司规定的A/B/C三类，而这三类粗略的划分在实际工作中很不适用，经常出现矛盾和不适宜的情况；
目标和意义：在目前三类的事件分类的基础上，增加影响程度、优先级别和所需要解决的时限，使工程师在对事件的优先判断时更灵活和准确。准确的优先级一方面可以有效地协调资源，也可以帮助工程师合理分配工作任务。同时，能够将一些事件及时地反应给相关相关管理层，由相关管理层督促和协调解决，将事件的影响降低到最小。举例说明具体信息：                                    ITSS认证[td]

运维中心	业务分类	影响程度	优先级	最后期限	影响描述	受理台询问问题
数据中心	网络	非故障类	普通	16个小时	对业务没有影响，咨询、IP更换等事件；主要和事件类别相关，当受理台选择的事件类型是：服务请求、咨询时，该事件的影响程度可以根据实际情况确定；	1，   判断该事件属于服务请求或咨询； 2，   该事件是否影响业务？ 3，   是不是影响前台业务？
		低	低	10个小时	属于网络问题，而且该故障只是影响用户个人；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   是不是只是个人受影响？
		中	中	8个小时	属于网络问题，而且该故障只是影响上海电信内部管理或内部系统，如报表系统等；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   该业务是属于内部业务吗？（不会影响前台业务，不会直接影响最终用户；）
		高	高	6个小时	属于网络问题，而且该故障与前台业务相关的故障，或重要用户的故障，影响面较广；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   该业务是属于前台业务吗？
		紧急	最高	4个小时	属于网络问题，而且该故障引起业务系统整体无法使用；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   影响整体业务吗？

d.   制定和事件管理流程兼容的重大/紧急事件处理流程；
解决的问题：在日常的IT服务管理中，有重大/紧急事件发生时，大家都要放掉手头事务投入到事件处理过程中，往往因为沟通不够，导致相关相关管理层很紧张，责任工程师压力太大。
目标和意义：需要建立一个能够和事件管理相兼容的紧急事件处理流程，当紧急事件发生时，能够按照流程有序、及时地通知各层相关相关管理层，由各层相关管理层循序地进行资源调配完成紧急事件的处理。

e.    定义规范的事件管理和配置管理流程和两者之间的接口，并加强执行；
解决的问题：目前没有配置管理流程，所以事件管理没有相关事件对象的配置信息，在事件管理流程中，事件只是作为流水帐记录，无法将设备发生的事件及时反映到设备的配置信息中，不能够帮助事件处理人及时、准确地了解到设备的配置信息，历史发生的事件等；
目标和意义：通过和配置管理建立接口，一方面，在没有变更管理流程的情况下，可以使配置的信息通过事件管理来更新；另一方面，在处理事件时，配置管理可以向事件管理提供相关设备的配置信息和历史事件，帮助事件处理人员准确的定位事件；

f.     建立规范的业务需求实施流程；
解决的问题:
市场拓展部业务需求的实现，目前是中心的工作重点之一，业务需求的提出很大特点是，数量多，实施时间紧急；这些都给中心的研发带来很大压力。关于这方面的处理，中心已经有一些措施，如，在研发小组有需求受理员（督导员），有需求分析人员，有需求实施人员，但是，这些人员的角色不固定，而且职责比较模糊，所以，会出现需求跟踪不力等问题。
目标和意义：能够制定规范的业务需求实施流程，将这些角色有机地串在一起，共同有计划、分工合作地实现业务需求；使业务需求能够并行实施，同时可以根据市场的要求实时进行调整，更有力地保障市场地需要。

g.  设定完善的流程衡量标准和考核体系；
解决的问题：
目前没有成体系的处理流程，所以没有流程衡量过程，事实上，当流程设计实施后，它需要随着业务的变化、处理方式的改变以及之前没有考虑的因素等作相应的调整和变动。
目标和意义：
在流程实施后必须定期或不定期的进行回顾，需要制定相应的衡量标准和考核体系，这些能够真实地反应流程需要调整的部分以及调整的原因等。

h.  设定清晰的事件升级机制， 包括管理升级和技术升级；
解决的问题：
中心的各级相关管理层都会被卷入到日常处理事务中，分散相关管理层精力的同时，也会给相关工程师带来工作上的压力；对于有些事件，申报的时候可能是一般级别，但是可能随着时间的推移事件就会变得紧急起来，另外，还有一些工程师的工作习惯，更愿意自己解决问题，而不顾及时间成本；或者是担心‘打搅相关管理层’，所以尽可能不及时将一些事件通告给相关管理层，而贻误了业务和事件处理的机会等。
目标和意义：
通过清晰的事件升级机制，最好能够固化在技术上，通过技术自动实现。可以使只有必要的事件升级到相关管理层层，相关管理层能够及时掌握不同级别的事件处理情况，能够及时协调时间和资源处理相对影响度大和紧急的事件。同时，使很多事件能够及时地升级给资深的专家处理，解决。

i.  制定严格的流程政策和流程执行控制机制；
解决的问题：
很多已经制定的流程，在实施的时候都会碰到一些障碍，如，工作习惯，工作态度，工作素质等。所有的流程都不可能设计得尽善尽美，所以，流程有时还会被一些员工‘上有政策，下有对策’给消化掉，达不到流程执行的目的。
目标和意义：
通过制定严格的流程政策和流程执行控制机制，可以弥补流程设计中一些无法顾及的部分，另外，也可以为流程的推广和执行提供可以参照的行政手段和依据。

j.  建立严格的事件监控和跟踪机制；
解决的问题：在很多时候，对于一些事件的处理，从客户的感觉来看，都象是‘石沉大海’，不知道事件是否已在处理，处理到什么阶段，什么时候能够处理完毕，使用户很迷惑和不能理解。
目标和意义：实行事件责任制，谁接受了用户的需求/故障，谁对用户和事件负责，该事件责任人必须实行严格的事件监督和跟踪，同时，需要及时和用户沟通，必要时，能够将事件进行管理升级和技术升级。

k.  设定完善的知识管理体系，包括管理流程；                                             ITSS培训
解决的问题：
中心目前人员流动现象较为严重，一方面，我们需要做一些必要的工作来稳定团队；另一方面，我们必须解决因为一些资深员工的流动带来的知识、技术、经验的流失。同时，为了如何提升一线员工解决事件的能力，如何降低对一线技能的要求等都是我们需要解决的问题。
目标和意义：
通过建立完善的知识管理体系，可以很好地帮助我们解决上述问题。在事件管理过程中，必须要求员工将事件的解决过程完整的记录下来，形成案例库。在案例库的基础上，整理出相应的知识库，使一线工程师可以很方便地参考这些知识库。我们都知道知识库重在有效和实用，所以，我们也必须配合一些管理手段来保证知识库的持续性，如，对提交有用知识实行奖励等。

待续http://www.ITILxf.com/thread-52425-1-1.html

本帖关键字：ITSS

20150924 淡然

续上




4    建议

通过评估分析的结果，我们已经清楚地认识到我们在IT服务管理方面地不足，我们怎么样能够梳理各种流程，使中心的IT服务管理工作有序地进行，怎么样才能够增加管理的透明度，怎么样才能够使相关人员各行其职、各尽其能呢，怎么样能够提升员工的工作效率，怎么样能够树立IT部门的形象，提高用户满意度，怎么样能够衡量员工工作饱满度，合理分派资源……？                           ITSS考试

根据深圳某公司新技术开发中心的业务特点，结合中心当前的实际情况，给出如下ITSM项目近期需要建设和完善的建议，同时也提出了中期和远期建议。

近期、中期和远期的目标是有逻辑关系的，近期建议是在当前条件和当前迫切需要的基础上需要完善和建立的内容，其中主要包括：完善事件管理（包括受理台建设）、配置管理。主要目的是：将处于“救火队”状态（无序的IT管理状态）的IT服务提升到被动服务，提高客户的满意度，能够及时响应和迅速解决突发的IT事件，建立有效的升级手段和途径，保证突发事件的解决；同时，能够建立规范的IT设备配置管理数据库，为IT服务管理建立数据支撑中心。

在近期建议或者近期目标实现的基础上，需要进一步实现IT服务管理领域中的其它模块，即中期建议主要包括：问题管理、变更管理和服务水平管理。主要目的是：由被动服务提高到主动服务，因为被动服务只是保证在规定的时间内能够及时有效地解决发生的问题，不管解决的多么快，实际上都对业务造成了一定的负面影响，所以我们更需要提供一些主动的IT服务，避免事件的发生，增加对业务的贡献；同时，通过规范的变更控制可以使在近期目标中的配置管理数据库中的数据更加准确和严谨；另外，在近期目标实现的基础上，即丰富的事件处理数量数据、设备故障发生频率数据、平均解决时长数据、服务目录（事件分类）数据等，利用这些数据可以同用户签订服务级别协议（SLA），一方面，可以向用户提供可以量化的服务指标；另一方面，也可以将用户尽可能地约束在既定的服务范围内。

同样在中期目标实现的基础上，需要将IT部门和IT服务管理的价值在业务中真正得到体现，即远期目标，主要包括：可用性管理、持续管理、能力管理和成本管理。主要目的是：能够根据企业的业务情况和IT的支持能力与以往的支持数据，能够预测、监控和管理系统的性能，预测系统增长的需要，进行性能分析，为系统扩容等提供数据和判断的依据；同时，能够对公司IT服务的可用程度和持续性进行管理，一方面，使完善、规范的管理能够在一定程度上提升IT服务的可用性；另一方面，能够对IT的可用性和持续性有一个科学地认识，能够向用户做出合适的承诺。另外，IT部门一向都是为业务提供相应服务的部门，而IT技术和管理都是日新月异，具有相当的复杂性，很多时候，IT部门总是‘花’钱的部门，而不是直接盈利和收入的部门，IT部门在企业价值上得不到真正意义的体现，通过规范的服务管理可以将IT资源形成成本性的量化指标，能够和IT用户结合起来，进行IT成本核算，从而真正体现IT部门的价值。

4.1  近期建议

由于新技术开发中心工作的主要特点和工作重点是故障解决和业务需求的实现，同时，中心还有当前资源上的限制，为了解决以上通过评估得出的主要问题，我们建议当前新技术开发中心重点需要建立和完善事件管理和配置管理。

以下还是从流程、组织/人员、技术的三个角度，分别解释和论述这两个流程如何实现，需要做哪些工作，为什么需要这些工作，即这些工作的目标和意义。其中我们讲的事件主要包括运维故障、业务故障、咨询、业务需求、服务请求等。

n  改进事件管理

v  流程

a.   建立规范统一的服务台，采用故障和业务需求的集中受理，分散支持的方式，使服务台成为中心和用户部门间的唯一接口；
解决的问题：目前在中心有多种渠道和用户进行沟通，用户发现了问题可以通过中心统一受理热线、运维受理热线、运维支持手机、运维工程师电话、运维管理层电话、研发人员电话、中心协作平台、传真、10000号客服服务平台等。这些看似很丰富的沟通渠道，实际上为中心的IT服务管理带来很多问题：事件记录分散，事件处理不可跟踪和回溯，工程师的精力分散，相关管理层卷入日常事务处理中，员工工作不可衡量，事件丢失，员工工作职责不清，多种渠道的事件使工程师手忙脚乱，疲于应付等。同样，这些渠道并没有使用户感觉到方便，反而情况更糟糕，当用户发现问题时，用户面对这么多渠道无所适从，很多用户不知该找谁，打什么样的电话。很多用户会直接打电话给熟悉的工程师，而报告的问题很有可能非该工程师所能，其实，用户也不希望采用这种方式，因为很多程度上受制于工程师的工作情绪；另外还有用户会直接打电话给相关相关管理层，无形中为中心工程师造成很大工作压力。同时，即使问题被报到中心，但是经常象是石沉大海，没有及时的响应，也不知该向谁询问问题处理的程度，也许中心工程师忙得象‘陀螺’，而业务部门或用户还是很不耐烦、抱怨、投诉。这些矛盾和问题正在恶性循环，成为中心IT服务管理的主要阻碍。

目标和意义：通过建立统一规范的服务台可以解决上述问题。首先，统一的受理服务台可以使用户在遇到问题或事件时很清楚该打什么电话；对于用户申报的问题，用户可以随时向服务台咨询问题的处理情况，同时，服务台也可以主动向用户通报问题处理情况；另外对于中心内部，事件可以被完整地记录，同时事件可以被跟踪和控制，中心的相关相关管理层也不会被卷入日常事务中，中心工程师不会被用户的电话干扰，同时，也避免很多不必要的压力。

b.   制定清晰的事件逻辑分类；

解决的问题：目前中心的热线或工程师在接到用户的问题申报时，不作分类或者根据经验模糊地分类，导致事件在按照分类统计时很不准确，无法分析出相应的事件规律；

目标和意义：可以根据中心工程师的功能和一些业务特点将事件做清晰的逻辑分类，一方面，有助于将事件单更清晰地分派给相应的工程师或工作组；另一方面，在对事件的分类统计时，可以分析每类事件的规律；

c.    定义严格的事件影响程度、优先级并和所需要的解决时限关联起来；
解决的问题：目前，中心对于事件的分类只是局限在省电信公司规定的A/B/C三类，而这三类粗略的划分在实际工作中很不适用，经常出现矛盾和不适宜的情况；
目标和意义：在目前三类的事件分类的基础上，增加影响程度、优先级别和所需要解决的时限，使工程师在对事件的优先判断时更灵活和准确。准确的优先级一方面可以有效地协调资源，也可以帮助工程师合理分配工作任务。同时，能够将一些事件及时地反应给相关相关管理层，由相关管理层督促和协调解决，将事件的影响降低到最小。举例说明具体信息：                                    ITSS认证[td]

运维中心	业务分类	影响程度	优先级	最后期限	影响描述	受理台询问问题
数据中心	网络	非故障类	普通	16个小时	对业务没有影响，咨询、IP更换等事件；主要和事件类别相关，当受理台选择的事件类型是：服务请求、咨询时，该事件的影响程度可以根据实际情况确定；	1，   判断该事件属于服务请求或咨询； 2，   该事件是否影响业务？ 3，   是不是影响前台业务？
		低	低	10个小时	属于网络问题，而且该故障只是影响用户个人；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   是不是只是个人受影响？
		中	中	8个小时	属于网络问题，而且该故障只是影响上海电信内部管理或内部系统，如报表系统等；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   该业务是属于内部业务吗？（不会影响前台业务，不会直接影响最终用户；）
		高	高	6个小时	属于网络问题，而且该故障与前台业务相关的故障，或重要用户的故障，影响面较广；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   该业务是属于前台业务吗？
		紧急	最高	4个小时	属于网络问题，而且该故障引起业务系统整体无法使用；	1，   确定是网络问题； 2，   该故障影响业务吗？ 3，   影响整体业务吗？

d.   制定和事件管理流程兼容的重大/紧急事件处理流程；
解决的问题：在日常的IT服务管理中，有重大/紧急事件发生时，大家都要放掉手头事务投入到事件处理过程中，往往因为沟通不够，导致相关相关管理层很紧张，责任工程师压力太大。
目标和意义：需要建立一个能够和事件管理相兼容的紧急事件处理流程，当紧急事件发生时，能够按照流程有序、及时地通知各层相关相关管理层，由各层相关管理层循序地进行资源调配完成紧急事件的处理。

e.    定义规范的事件管理和配置管理流程和两者之间的接口，并加强执行；
解决的问题：目前没有配置管理流程，所以事件管理没有相关事件对象的配置信息，在事件管理流程中，事件只是作为流水帐记录，无法将设备发生的事件及时反映到设备的配置信息中，不能够帮助事件处理人及时、准确地了解到设备的配置信息，历史发生的事件等；
目标和意义：通过和配置管理建立接口，一方面，在没有变更管理流程的情况下，可以使配置的信息通过事件管理来更新；另一方面，在处理事件时，配置管理可以向事件管理提供相关设备的配置信息和历史事件，帮助事件处理人员准确的定位事件；

f.     建立规范的业务需求实施流程；
解决的问题:
市场拓展部业务需求的实现，目前是中心的工作重点之一，业务需求的提出很大特点是，数量多，实施时间紧急；这些都给中心的研发带来很大压力。关于这方面的处理，中心已经有一些措施，如，在研发小组有需求受理员（督导员），有需求分析人员，有需求实施人员，但是，这些人员的角色不固定，而且职责比较模糊，所以，会出现需求跟踪不力等问题。
目标和意义：能够制定规范的业务需求实施流程，将这些角色有机地串在一起，共同有计划、分工合作地实现业务需求；使业务需求能够并行实施，同时可以根据市场的要求实时进行调整，更有力地保障市场地需要。

g.  设定完善的流程衡量标准和考核体系；
解决的问题：
目前没有成体系的处理流程，所以没有流程衡量过程，事实上，当流程设计实施后，它需要随着业务的变化、处理方式的改变以及之前没有考虑的因素等作相应的调整和变动。
目标和意义：
在流程实施后必须定期或不定期的进行回顾，需要制定相应的衡量标准和考核体系，这些能够真实地反应流程需要调整的部分以及调整的原因等。

h.  设定清晰的事件升级机制， 包括管理升级和技术升级；
解决的问题：
中心的各级相关管理层都会被卷入到日常处理事务中，分散相关管理层精力的同时，也会给相关工程师带来工作上的压力；对于有些事件，申报的时候可能是一般级别，但是可能随着时间的推移事件就会变得紧急起来，另外，还有一些工程师的工作习惯，更愿意自己解决问题，而不顾及时间成本；或者是担心‘打搅相关管理层’，所以尽可能不及时将一些事件通告给相关管理层，而贻误了业务和事件处理的机会等。
目标和意义：
通过清晰的事件升级机制，最好能够固化在技术上，通过技术自动实现。可以使只有必要的事件升级到相关管理层层，相关管理层能够及时掌握不同级别的事件处理情况，能够及时协调时间和资源处理相对影响度大和紧急的事件。同时，使很多事件能够及时地升级给资深的专家处理，解决。

i.  制定严格的流程政策和流程执行控制机制；
解决的问题：
很多已经制定的流程，在实施的时候都会碰到一些障碍，如，工作习惯，工作态度，工作素质等。所有的流程都不可能设计得尽善尽美，所以，流程有时还会被一些员工‘上有政策，下有对策’给消化掉，达不到流程执行的目的。
目标和意义：
通过制定严格的流程政策和流程执行控制机制，可以弥补流程设计中一些无法顾及的部分，另外，也可以为流程的推广和执行提供可以参照的行政手段和依据。

j.  建立严格的事件监控和跟踪机制；
解决的问题：在很多时候，对于一些事件的处理，从客户的感觉来看，都象是‘石沉大海’，不知道事件是否已在处理，处理到什么阶段，什么时候能够处理完毕，使用户很迷惑和不能理解。
目标和意义：实行事件责任制，谁接受了用户的需求/故障，谁对用户和事件负责，该事件责任人必须实行严格的事件监督和跟踪，同时，需要及时和用户沟通，必要时，能够将事件进行管理升级和技术升级。

k.  设定完善的知识管理体系，包括管理流程；                                             ITSS培训
解决的问题：
中心目前人员流动现象较为严重，一方面，我们需要做一些必要的工作来稳定团队；另一方面，我们必须解决因为一些资深员工的流动带来的知识、技术、经验的流失。同时，为了如何提升一线员工解决事件的能力，如何降低对一线技能的要求等都是我们需要解决的问题。
目标和意义：
通过建立完善的知识管理体系，可以很好地帮助我们解决上述问题。在事件管理过程中，必须要求员工将事件的解决过程完整的记录下来，形成案例库。在案例库的基础上，整理出相应的知识库，使一线工程师可以很方便地参考这些知识库。我们都知道知识库重在有效和实用，所以，我们也必须配合一些管理手段来保证知识库的持续性，如，对提交有用知识实行奖励等。

待续http://www.ITILxf.com/thread-52425-1-1.html

本帖关键字：ITSS