|
|
|
过程作为IT服务的核心要素之一，与其他要素相比具有一定的独特性，在多数情况下，过程不是显性的，通常看不见、摸不着，甚至说不清、道不明。但在面向客户的服务过程中是实实在在存在的，为了交付特定的IT需求，如未明确定义和说明具体过程，服务组织、第三方、客户之间通常会“滋生”相应的过程去实现交付目标。
|
|
|
|
过程及过程管理的优劣直接关系服务效率和效益。未明确识别定义的过程在服务实践中难以标准化，服务质量难以把控，也无法准确衡量，因此需要对过程进行识别和明确定义。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（1）识别客户服务内容、范围、目标、管理要求过程的最终目标是交付合格的服务结果，过程的识别和定义要围绕客户服务内容、范围、目标、管理要求而展开。
|
|
|
|
（2）识别需要的过程及过程目标常用过程包括需求管理、事件管理、问题管理、变更管理、发布管理等管理过程。不同的服务协议需要配套不同的过程来实现。在具体IT服务项目中，应选择合适的过程服务去实现相应的目标。如客户协议中仅需要提供电话方式给予远程技术支持，则只需要建立配套的事件管理过程即可。选择合适的过程，同时要识别出合适的过程衡量标准，这些标准一般在服务协议中有着明确的定义，如热线接通率、热线解决周期、满意度等。
|
|
|
|
（3）定义角色和职责对应选择的过程定义相应的角色，如服务台支持工程师、现场工程师、二线支持专家、后台工程师等，并对各角色的职责进行详细的职责描述。
|
|
|
|
（4）识别过程的活动，定义活动的相互关系、顺序、活动目标、活动的资源限制及管理要求，在实践中，应根据客户管理要求和服务协议的不同而进行细致的定义，包括识别过程需要的活动、各过程需要的输入／输出目标、活动间的关系及执行顺序。其中涉及与客户互动的活动环节，需要参考客户的意见来共同定义。
|
|
|
|
（5）定义相关活动详细操作规程及衡量标准过程活动的定义是相对高级别的操作汇总，为保障过程活动的目标达成，需要选择和定义更细致的操作规程，如服务器系统安装操作规程、服务器重启作业操作规程等。具体操作规程依据服务实践中对风险的管理和接受要求来定义，如在无相关操作规程描述的情况下，风险仍在可控范围，则无须对所有场景都制订出严格的操作规程。最佳的服务实践靠行为模式文化引导，而不是严格的过程和制度，所有的过程都细化到SOP是不经济的，也是不可取的。
|
|
|
|
（6）定义过程的表单及信息记录保存要求。过程定义应包括详细描述过程各活动的信息记录，一是标准化过程的输入、输出及处理，二是确保过程具有可追溯性和可审计性。
|
|
|
|
（7）定义过程评价、评估及改进机制对过程的评价衡量可结合服务协议约定的报告周期进行。但过程定义后，在服务实践中会因客户需求变化、过程本身设计等原因致使过程不再适用，需要对过程进行重新评估和改进。过程本身需要一定的稳定性，所以评估和改进的周期可以是半年或一年进行一次。
|
|
|
|
|
|
|
|
|
|
步骤2：询问客户故障现象，进行故障识别判断，如可通过维护解决，与客户协商直接维护，若客户坚持，则进入系统重置流程。
|
|
|
|
步骤3：与客户确认桌面设备外观状态（避免外观有损等现象导致后期出现争议）。
|
|
|
|
步骤4：与客户确认备份内容，必须提示用户备份邮件、通信录、常用网址、文档、输入法字库等；如客户需要支持或备份空间，给予备份空间协助；备份确认状态，获取客户签字确认。
|
|
|
|
步骤5：与客户确认需要安装的操作系统并签字后，方可进行。
|
|
|
|
步骤6：使用DSL最新GHOST文件恢复系统，重置过程中，按顺序严格填写《桌面系统重置操作进度表》。
|
|
|
|
步骤7：系统重置完成后，依据《××装机标准》中相关内容进行配置和检验。
|
|
|
|
|
|
A公司为解决日常大量的重复性客户桌面支持问题，将桌面支持服务外包给了B服务商。B在服务实践中，建立了统一标准的IT服务台，经与客户的磨合沟通，确立了如下图所示的三级客户支持体系。
|
|
|
|
|
|
|
|
B公司分别就服务台工程师、二线专家、厂商定义了其角色及职责描述，其中服务台工程师职责定义为：
|
|
|
|
|
|
|
|
|
|
.对用户的请求做出评估，尝试解决或将其指派给合适的人加以解决，保持服务级别。
|
|
|
|
.监控客户支持事件并进行事件处理的升级管理全过程必须满足服务协议的要求，才能根据此升级管理全过程来管理用户需求，包括记录、处理、结束和检查；根据实际情况，就服务级别的任何变动及时与用户沟通。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.应了解需要支持的内容、支持时间要求、SLA、之前的支持情况及遗留问题，并与需方确认。
|
|
|
|
.如果工作较复杂或存在风险，应提前做好预案经过审核后再实施。
|
|
|
|
.应确保支持所需的工作条件满足安全、稳定和可用的要求。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.如果遇到无法解决的问题或需方提出额外要求，应及时通知上级获取支持，得到授权后再处理。
|
|
|
|
|
|
|
|
.应做必要的安全检查，如清除临时账号、避免数据未授权复制等。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.申请人信息：申请人、申请人邮箱、联系电话、所在公司、服务级别、办公工位。
|
|
|
|
.事件总体信息：事件标题、事件描述、事件来源、事件重要程度、事件紧急程度、解决方案、事件解决人、解决时间、解决方式。
|
|
|
|
.事件处理历史信息：转移人、处理人、诊断及补充信息、所采取的支持及操作、开始时间、解决时间。
|
|
|
