20150521  MONICAZHANG

    续上

1、组织架构：

运行组织架构中关于一线专家坐席的第2种方案可否稍作调整变为第4种：即由各个专业室委派相关支持人员作为一线专家坐席，这些员工纳入服务台日常工作管理，此期间汇报机制也在服务台；专业科室按一定的机制进行人员一、二线轮岗和派出一线专家坐席人员。    ITSS考试

增加设计了第4种方案；

作为服务台关键岗位，服务台管理岗位是否应考虑人员备份机制，其中服务经理与质量经理职责与《运营管理体系设计》中建议的服务质量经理的岗位是否是对应的？后续流程中还设计了公告经理、投诉经理的角色，是否都是由服务台管理岗位担任？

在服务台中的质量经理是管理和控制服务台本身运作和服务提供的质量；而《运管体系设计》中的服务质量经理应该主要是运营中心外的服务推广；在信息公告流程和投诉流程中的角色都是由服务台相关岗位担任；在相应的“角色和职责”描述中都有设计；ITSS体系

2、知识评价：服务台一线坐席人员是否也应是知识审核中的一个环节，按照一定的标准对于知识和解决方案进行审核，不必要等到使用时再发现问题。

在知识库管理设计中将考虑这个环节，但是无论一线坐席是否参与审核，都必将出现知识“回炉”的现象；

3、考核制度：跨地域服务台一线坐席协作中，“职能和区域的服务台一线坐席需要遵循运营中心服务台的统一管理规范和制度”如何进行约束和管理？第4章考核制度中未提及对跨地域坐席的考核考虑和措施。

为了遵循统一的管理规范，将来如果需要设立跨地域服务台一线坐席，这些人员行政管理权分属辖地，但是考核和行为规范完全参照中心服务台一线坐席人员；所以，在考核以及运营制度中并不需要再专门为跨地域坐席设计；    ITSS认证

4、流程设计：

事件管理：关于服务台与事件管理的关系，根据ITLE V3，服务台是否应为所有EVENT的OWNER？建议说明服务台与一线监控值班人员的关系，如何分工、合作和处理接口。在跨地域的坐席协作中有特别提到要有事件管理人员及事件单流向，为什么不是服务单？ITSS工具

在ITIL V3中将Event独属出来，主要是对ITIL V2中没有提到这个内容的补充，事实上，Event可以走事件管理流程，但是服务台人员和监控人员的职能还是分开的，有关两者关系请详见刘震的第2个问题。将请求单统称为事件单主要是为了通俗易懂；

是否应有服务请求流程？服务请求的分类设计，服务请求什么情况下转为事件，什么情况下转为变更？

在流程优化设计中有服务请求流程的设计；   ITSS培训

5、技术设计：

6.3不太理解，是指技术平台的问题吗？还是问题管理流程中的问题？

设备配置都是单台，是否有可用性要求？

该部分的内容主要设计支撑服务台的技术平台的需求；

6、推广计划：是一个通用的推广思路，能否针对银联现状和实际，给出试点和推广的具体实施建议，如阶段划分、阶段目标、人力投资、外部关系等。

这确实是一个推广的指导计划，我们将根据您提出的问题，对文档的推广计划结合运营中心的特点进行更加详细的设计指导；

ITSS团购

2009-7-xx                    陈根

1，2.1 统一服务接入设计

预处理

“服务台需要指定岗位定期或者不定期地检查该列表，对提交的请求单做预处理” 除了电话以外的4种方式都属于被动式的响应，应该可以提供主动式的提醒，当有服务单到达时，提醒服务台人员进行处理。

因为这是一个公用列表，对于比较紧急的请求并不建议通过该渠道进行提交，所以，如果通知不能确定具体通知对象，除非在服务台一线坐席中设立专门岗位，但是并不建议，因为服务台一线坐席是倒班的，这样会增加服务台内部管理事务。    ITIL培训

短信受理

公共移动电话受理不太合适，不能很好的整合到服务台中，和现在的传真手工创建服务单没有区别。应该提供软件的短信接口，如移动短信网关95516此类的短信受理途径，增加可靠性和处理效率。

短信受理方式只能是非常辅助的受理渠道，在实际运作过程中，并不建议从此渠道提交申请，所以在该渠道上也不需要做更为复杂的设计；

邮件接入

邮件接入和web接入类似，“通过邮件描述的请求更加无法保证信息的准确和完整性”不能理解。 可以约定特殊的邮件格式，仿照web服务请求的方式进行约束和规范。规范的邮件可以直接进入服务请求单的处理流程，无需手工再分派。

如果将通过Email提出的服务请求自动转入平台，则对客户在通过Email提出请求时的格式等有具体要求，一定程度上给客户带来不便。建议如果服务台运行正常，客户成熟的状态下再做这种要求；     ISO20000培训

好像漏了传真接入方式的说明。

放在与电话接入一起描述；

2，2.2 日常运营支持

应该对其他平台（监控平台、综合信息管理平台）等提供的服务功能统一汇聚。服务台可以随时访问和使用运营中心所有系统暴露给服务台的信息和功能。

不建议已开始就由服务台掌握那么多平台的信息，服务台主要是面多运营中心用户，如果有更专业的问题或处理则放到二线处理，将来如果服务台应用逐渐成熟才可以将一些平台开放给服务台，由服务台获取相关信息，同时，也要主要分工，比如监控平台是由监控人员控制等；    ITSS软件

3，2.6 管理信息报表

效率考核基本上以电话接入为主是否有失偏颇

最能够反应服务台工作效率的就是电话、事件处理，所以在考核的过程中主要以这两项要素为主，暂时不考虑其它考核因素；

待续：[ ttp://www.itilxf.com/thread-48711-1-1.html]http://www.itilxf.com/thread-48711-1-1.html[/url]

本帖关键字：ITSS ISO20000

20150521  MONICAZHANG

    续上

1、组织架构：

运行组织架构中关于一线专家坐席的第2种方案可否稍作调整变为第4种：即由各个专业室委派相关支持人员作为一线专家坐席，这些员工纳入服务台日常工作管理，此期间汇报机制也在服务台；专业科室按一定的机制进行人员一、二线轮岗和派出一线专家坐席人员。    ITSS考试

增加设计了第4种方案；

作为服务台关键岗位，服务台管理岗位是否应考虑人员备份机制，其中服务经理与质量经理职责与《运营管理体系设计》中建议的服务质量经理的岗位是否是对应的？后续流程中还设计了公告经理、投诉经理的角色，是否都是由服务台管理岗位担任？

在服务台中的质量经理是管理和控制服务台本身运作和服务提供的质量；而《运管体系设计》中的服务质量经理应该主要是运营中心外的服务推广；在信息公告流程和投诉流程中的角色都是由服务台相关岗位担任；在相应的“角色和职责”描述中都有设计；ITSS体系

2、知识评价：服务台一线坐席人员是否也应是知识审核中的一个环节，按照一定的标准对于知识和解决方案进行审核，不必要等到使用时再发现问题。

在知识库管理设计中将考虑这个环节，但是无论一线坐席是否参与审核，都必将出现知识“回炉”的现象；

3、考核制度：跨地域服务台一线坐席协作中，“职能和区域的服务台一线坐席需要遵循运营中心服务台的统一管理规范和制度”如何进行约束和管理？第4章考核制度中未提及对跨地域坐席的考核考虑和措施。

为了遵循统一的管理规范，将来如果需要设立跨地域服务台一线坐席，这些人员行政管理权分属辖地，但是考核和行为规范完全参照中心服务台一线坐席人员；所以，在考核以及运营制度中并不需要再专门为跨地域坐席设计；    ITSS认证

4、流程设计：

事件管理：关于服务台与事件管理的关系，根据ITLE V3，服务台是否应为所有EVENT的OWNER？建议说明服务台与一线监控值班人员的关系，如何分工、合作和处理接口。在跨地域的坐席协作中有特别提到要有事件管理人员及事件单流向，为什么不是服务单？ITSS工具

在ITIL V3中将Event独属出来，主要是对ITIL V2中没有提到这个内容的补充，事实上，Event可以走事件管理流程，但是服务台人员和监控人员的职能还是分开的，有关两者关系请详见刘震的第2个问题。将请求单统称为事件单主要是为了通俗易懂；

是否应有服务请求流程？服务请求的分类设计，服务请求什么情况下转为事件，什么情况下转为变更？

在流程优化设计中有服务请求流程的设计；   ITSS培训

5、技术设计：

6.3不太理解，是指技术平台的问题吗？还是问题管理流程中的问题？

设备配置都是单台，是否有可用性要求？

该部分的内容主要设计支撑服务台的技术平台的需求；

6、推广计划：是一个通用的推广思路，能否针对银联现状和实际，给出试点和推广的具体实施建议，如阶段划分、阶段目标、人力投资、外部关系等。

这确实是一个推广的指导计划，我们将根据您提出的问题，对文档的推广计划结合运营中心的特点进行更加详细的设计指导；

ITSS团购

2009-7-xx                    陈根

1，2.1 统一服务接入设计

预处理

“服务台需要指定岗位定期或者不定期地检查该列表，对提交的请求单做预处理” 除了电话以外的4种方式都属于被动式的响应，应该可以提供主动式的提醒，当有服务单到达时，提醒服务台人员进行处理。

因为这是一个公用列表，对于比较紧急的请求并不建议通过该渠道进行提交，所以，如果通知不能确定具体通知对象，除非在服务台一线坐席中设立专门岗位，但是并不建议，因为服务台一线坐席是倒班的，这样会增加服务台内部管理事务。    ITIL培训

短信受理

公共移动电话受理不太合适，不能很好的整合到服务台中，和现在的传真手工创建服务单没有区别。应该提供软件的短信接口，如移动短信网关95516此类的短信受理途径，增加可靠性和处理效率。

短信受理方式只能是非常辅助的受理渠道，在实际运作过程中，并不建议从此渠道提交申请，所以在该渠道上也不需要做更为复杂的设计；

邮件接入

邮件接入和web接入类似，“通过邮件描述的请求更加无法保证信息的准确和完整性”不能理解。 可以约定特殊的邮件格式，仿照web服务请求的方式进行约束和规范。规范的邮件可以直接进入服务请求单的处理流程，无需手工再分派。

如果将通过Email提出的服务请求自动转入平台，则对客户在通过Email提出请求时的格式等有具体要求，一定程度上给客户带来不便。建议如果服务台运行正常，客户成熟的状态下再做这种要求；     ISO20000培训

好像漏了传真接入方式的说明。

放在与电话接入一起描述；

2，2.2 日常运营支持

应该对其他平台（监控平台、综合信息管理平台）等提供的服务功能统一汇聚。服务台可以随时访问和使用运营中心所有系统暴露给服务台的信息和功能。

不建议已开始就由服务台掌握那么多平台的信息，服务台主要是面多运营中心用户，如果有更专业的问题或处理则放到二线处理，将来如果服务台应用逐渐成熟才可以将一些平台开放给服务台，由服务台获取相关信息，同时，也要主要分工，比如监控平台是由监控人员控制等；    ITSS软件

3，2.6 管理信息报表

效率考核基本上以电话接入为主是否有失偏颇

最能够反应服务台工作效率的就是电话、事件处理，所以在考核的过程中主要以这两项要素为主，暂时不考虑其它考核因素；

待续：[ ttp://www.itilxf.com/thread-48711-1-1.html]http://www.itilxf.com/thread-48711-1-1.html[/url]

本帖关键字：ITSS ISO20000