信息技术中心运营管理室工作手册.doc

上传人:仙人指路1688 文档编号:3812536 上传时间:2023-03-23 格式:DOC 页数:151 大小:7.78MB
返回 下载 相关 举报
信息技术中心运营管理室工作手册.doc_第1页
第1页 / 共151页
信息技术中心运营管理室工作手册.doc_第2页
第2页 / 共151页
信息技术中心运营管理室工作手册.doc_第3页
第3页 / 共151页
信息技术中心运营管理室工作手册.doc_第4页
第4页 / 共151页
信息技术中心运营管理室工作手册.doc_第5页
第5页 / 共151页
点击查看更多>>
资源描述

《信息技术中心运营管理室工作手册.doc》由会员分享,可在线阅读,更多相关《信息技术中心运营管理室工作手册.doc(151页珍藏版)》请在三一办公上搜索。

1、1 工作职责及岗位设置1.1 工作职责运营管理室的工作职责为:1、 负责制定公司业务支撑系统维护工作的有关制度和流程;2、 负责业务支撑系统的运营维护、投诉处理工作;3、 负责帐务的技术处理工作;4、 负责电子商务中心的建设、运营、维护工作;5、 负责公司的信息安全管理工作;1.2 岗位设置运营管理室经理/主管业务系统运营业务系统维护电子服务运营系统运营支撑信息安全管理1、 业务系统维护:负责业务支撑系统涉及机房、网络、设备、运行环境的日常管理及故障处理,负责业务支撑系统的数据处理。2、 业务系统运营:制定业务支撑系统的管理办法、规范、流程、制度,负责业务支撑系统维护合作商的管理,负责业务支撑

2、系统故障问题的分析及优化,负责;负责业务支撑系统工号、权限的管理以入营销方案的系统设置管理。3、 电子服务运营:负责网上商城承载的各项业务的业务运作管理。4、 系统运营支撑:负责业务支撑系统的计费生产运作,包括出账、预出、优惠上传等,负责业务支撑系统帐务调整的系统操作。5、 信息安全管理:负责组织企业信息安全管理制度的制定、落实,负责组织定期的企业信息安全检查及审计,负责企业信息安全监督热线的接听及安全事故的查证。2 业务支撑系统维护管理工作规范2.1业务支撑系统故障处理2.1.1 目的规定业务支撑系统故障响应的工作流程,确保故障能在最短的时间内解决。2.1.2 适用范围本规范适用于信息技术中

3、心运营管理室对业务运营系统相关故障处理工作的控制。2.1.3 工作规范2.1.3.1 概述1、 预处理人员职责:1)负责接收并处理业务支撑系统的各种工单,解决各类业务问题,将涉及开发商协助处理的工单(如AMS)应及时进行转派并跟进处理,涉及需进行数据修改和省计费的工单应及时转派至相应值班人员进行处理;2)对于当天未处理完毕的工单,需要在第2天12:00填写工单处理进度,并在工单处理完毕前每天12:00前更新工单处理进度信息;3)负责发起数据处理流程、升级投诉处理流程。2、 审核人员职责:1) 负责审核并催促业务外包人员处理的各种工单,保障业务外包人员工单处理的质量和速度;2) 负责支撑业务外包

4、人员进行工单处理,解决需要协调外部门和省公司的问题;3) 负责发起BUG处理流程、升级投诉处理流程。3、 计费申告人员职责:1) 负责处理需转省计费中心协助处理的各种工单,并通过省计费网站进行转派;2) 负责审核省计费中心回复的计费申告工单内容,同时催促计费申告单的及时处理;3) 负责将涉及省网维中心协助处理的原始话单进行压缩加密后发送至省网维公共邮箱。2.1.3.2 工作流程1、预处理人员处理流程说明:1)预处理人员处理人员在接到投诉单后,判断该问题引发的原因(如系统故障、前台差错、业务规则等原因),再根据故障原因做后续处理(系统故障则需转相应开发商、前台差错则需一线自行解决、业务规则引起的

5、需一线解读相关规则等)。2)预处理人员应进行判断是否有升级投诉的趋势,若有升级投诉趋势则按升级投诉处理流程进行处理;3)预处理人员在处理过程中遇到需协调外部门解决的工单时应记录相应的查证记录及意见后,提交给审核人员,由审核人员协调外部门进行解决;4)预处理人员在处理过程中遇到需省计费中心协助处理的工单时,应提交至当天值计费申告班的同事,由其提交至省计费中心协助处理;5)预处理人员在处理过程中遇到需进行数据处理时,应提供相应脚本后及时提交至当天值数据修改班的同事进行处理;6)预处理人员在处理过程中遇到需派AMS开发商协助处理时,应及时通过AMS系统进行派单,同时应实时跟进AMS单的处理情况并对回

6、单结果进行审核;7) 当预处理环节处理完毕后,预处理人员应在投诉单中记录处理意见并提交至审核环节进行审核。2、审核人员处理流程说明:1)审核人员应对预处理提交的投诉单处理意见进行审核,判断该投诉单是否处理完毕;2)审核人员对于未处理完毕的投诉单,若需协调外部门协助处理的应及时通过各种渠道与外部门进行沟通并确认处理结果;3)审核人员对于属批量业务问题,应及时通过升级投诉处理流程进行处理;4) 审核人员对于属程序BUG,应按BUG处理流程进行处理;对于已处理完毕的投诉单,审核人员应对处理结果进行审核并进行工单类别的归档,最后回复前台。2.1.3.3 工作要求在业务系统故障处理过程中,应遵循以下原则

7、:1、 应以将故障影响面降低到最小为原则;2、 应正确估计故障的影响面,决定故障的处理优先级别;3、 重大故障处理时需制定详细的解决方案,并上报室经理,避免处理时欠缺考虑引发关联故障;4、 超过10个以上客户出现相同故障,上报室经理,同时按以下步骤启动紧急故障处理流程:1)首先定位故障点,协同开发商紧急处理,确认故障原因;2)(与上一步可以并行)定位目标客户群,同时对目标客户群进行分类及相关数据提取,确定影响面;3)确认故障原因后,采取措施,避免故障再扩大;4)分类数据提供给上级及相关单位,确定处理办法及步骤,包括出错数据处理办法及应用软件的临时性或永久性修改;5)进行出错数据处理,及时核查处

8、理情况,包括客户数据恢复、影响面缩窄情况;6)故障处理的情况应及时反馈;7)应保证在故障处理中,不出现附加故障;8)如怀疑为软件问题,应及时知会支持维护室共同跟进;5、 应在ITC监控系统上及时填报故障处理进展:1) 如不能在一个工作日内完成,需每天在系统上填写当日处理进展,处理类型选“其它”;2) 处理进展填写应清晰明了,要有结论性总结,如是否属系统问题等的清晰总结;3) 如属应用软件故障,需开发上载的,通过CMCP派单给支持维护室办理。2.1.3.4 工作流程图2.1.3.5 相关文档无2.2业务支撑系统升级故障处理2.2.1目的规定业务支撑系统严重以及重大故障响应的工作流程,确保故障能在

9、最短的时间内解决,减少客户投诉量。2.2.2适用范围本规范适用于信息技术中心运营管理室对业务运营系统严重以及重大故障处理工作的控制。2.2.3工作规范2.2.3.1概述1. 升级投诉故障的定义 升级投诉故障主要是从故障影响的程度进行定义的,具体分为一级故障、二级故障。1) 一级故障:(1) 影响客户正常通信,受影响的客户在50人以上,500人以下;(2) 影响客户通过我公司有关渠道进行部分业务办理或查询,热点业务受影响在1小时到3小时之间,非热点业务受影响在3小时到5小时之间;热点业务是指用户缴费开机、清单查询、服务开通、套卡销售与激活四类业务;(3) 引起客户投诉咨询在20到50单之间;(4

10、) 客服反映的一级投诉;(5) 有2单金、钻卡客户对同一类问题的投诉;(6) 可能会引发较多客户投诉,包括但不局限于以下几种:6、 系统主/备用服务宕机,但能成功切换,保证业务正常进行。7、 重要设备故障,导致部分功能丧失或对系统存在重大隐患,如接口机、应用服务器、认证服务器、存储设备、备份设备等。8、 网络中断,影响单个业务办理或影响部分营业前台/代办点业务。9、 关键接口中断,不能提供服务不超过30分钟;(关键接口包括:Call Center、HLR、银行、网站、SMP等)10、 系统或数据库出现严重告警。11、 应用软件或系统故障原因导致系统效率大幅降低,单笔业务等待时间超过1分钟。12

11、、 业务数据设置、修改、删除时发生严重错误,导致可能超过500个用户以上业务出错。13、 软件故障导致批量用户基本服务受影响,可能超过500用户。14、 报表数据错误,可能影响10个以上的服务厅报表错误。15、 对外关键接口、网络频繁出错,严重影响业务。2) 二级故障(1) 影响客户正常通信,受影响的客户在500人以上;(2) 影响客户通过我公司有关渠道进行部分业务办理或查询,热点业务受影响在3小时以上,非热点业务受影响在5小时以上;热点业务是指用户缴费开机、清单查询、服务开通、套卡销售与激活四类业务。(3) 引起客户投诉咨询在50单以上;(4) 客服反映的二级以上(包括二级)投诉;(5) 有

12、3单以上金、钻卡客户对同一类问题的投诉(6) 目前未有客户投诉,但可能会引发较多客户投诉,包括但不局限于以下几种:16、 系统瘫痪,主机宕机或数据库失效,无法提供服务。17、 网络中断,无法办理关键业务。18、 关键接口中断,不能提供服务超过30分钟;(关键接口包括:CallCenter、HLR、银行、网站、SMP等)。19、 系统重要功能模块无法使用超过15分钟,如缴费、认证、查询等。20、 软件故障导致大批量用户基本服务、用户基本功能受影响,超过5000用户。21、 软件或系统故障导致系统运行效率大幅降低,每笔业务等待时间超过3分钟。22、 业务严重出错,影响超过5000用户的费用、状态、

13、资料。2. 升级投诉故障处理人员的职责:1) 升级投诉处理员(A角)职责:负责跟进处理升级业务故障处理(包括严重以及重大级别的业务和系统故障)。对于自行无法解决的问题,需要在第一时间向省业务支撑中心报告故障,在AMS上派单给开发商处理,并跟进后续故障处理和解决情况。2) 升级投诉处理员(B角)职责:当升级投诉处理员(A角)不在时,B角需要承担起A角的职责,负责跟进处理升级业务故障处理(包括严重以及重大级别的业务和系统故障)。对于自行无法解决的问题,需要在第一时间向省业务支撑中心报告故障,在AMS上派单给开发商处理,并跟进后续故障处理和解决情况。A角和B角进行切换时,需要做好升级故障跟进的交接工

14、作。3) 升级投诉监控员职责:指导升级投诉处理员进行升级投诉处理,并对处理情况进行监控;推动故障处理的进度,并对异常情况进行干预处理。2.2.3.2工作流程升级故障值班人员在接到升级故障投诉时应当优先处理,故障可以通过ITC监控系统、邮件、电话、监控系统运作情况等多个渠道获取,对于自行发现的故障,应通过AMS系统立即进行故障申报,并及时通知省业务支撑中心的值班人员协助跟进。1、短信通报IT中心升级故障值班人员接到升级故障投诉后应通知68284的值班同事在服营网站/I-OFFICE上挂故障通知公告和故障恢复公告,同时通知68284的值班同事群发故障通知短信和故障恢复短信,关于故障短信的发送告知请

15、按以下要求执行。1)故障短信发送(1)业务类故障短信发送l 发送时间:客服中心发送一级故障短信后马上发送;l 发送范围:向C类人员名单发送相关故障短信。l 发送模板:*故障通知:故障时间:*年*月*日*时*分,故障现象:*,故障原因:*,影响范围:*,处理情况:目前(省公司或IT中心)正在抢修,预计恢复时间:*,故障跟进人:* 。(2)系统类故障短信发送l 发送时间:在系统故障出现后马上进行发送;l 发送范围:非CALLCENTER类故障向A、B、C类人员名单发送;CALLCENTER类故障向B、C类人员名单发送。l 发送模板:*系统故障通知:故障时间:*年*月*日*时*分,故障现象:*,故障

16、原因:*,影响范围:*,处理情况:目前(省公司或IT中心)正在抢修,预计恢复时间:*,故障跟进人:2)故障跟进短信发送(1)故障短信发送以后,如当天有重大进展及预计恢复时间的,则马上发送故障跟进短信;否则在当天下午下班前发送。(2)发送模板: *系统故障跟进情况:故障时间:*年*月*日*时*分,故障现象:*,故障原因:*,影响范围:*,处理情况:目前(省公司或IT中心)正在跟进处理当中,预计恢复时间:*,故障跟进人:* 。3)故障恢复短信发送(1)发送模板:*系统故障恢复通知:故障时间:*年*月*日*时*分,故障现象:*,故障原因:*,影响范围:*,处理情况:经(省公司或IT中心)抢修后,目前

17、已恢复正常,故障跟进人:* 。4)发送人员名单(1)A类:分公司店面经理,综合管理部室经理,市场部业务管理室经理,其他各部门联系人。(2)B类:客服中心综援室经理,客服中心联系人。 (3)C类:IT中心员工、室经理及部门领导。2、升级故障(上报室经理):出现下述情况时,应由升级故障处理人员通过电话向室经理通报情况1)出现以下情况时应立即上报室经理(1)出现一级或二级故障;(2)不影响客户的正常通信,但判断可能受影响的客户数目过百;(3)已收到十单以上的同类客户投诉;(4)已确认受影响的客户在三十个以上;(5)对客户的正常通信和业务办理、查询等将造成影响,影响面不能确认,但可能数目过百;(6)各

18、业务支撑系统级故障,超过15分钟或预计将超过15分钟;(7)各业务支撑某几项功能无法使用超过15分钟或预计将超过15分钟;(8)影响面尚不能确认,但可能引起20单以上的客户投诉;(9)以上故障在报开发商一小时后无实质性进展、开发商不能确认何时确认影响面、确认的进度不理想;(10)频发性故障,每周累计发生超过 2 次(含 2 次)或累计投诉量超过 20 单的故障需在周报中体现;每月累计发生超过 4 次(含 4 次)或累计投诉量超过 70 单的故障需在月报中体现;2)故障处理过程中遇到以下情况应立即上报室经理:(1)发现影响面可能进一步扩大;(2)发现新的故障现象;(3)不影响客户正常通信和业务办

19、理、查询的一般故障,报开发商三天无实质性进展,故障无法定位或故障解决时间无法确认;(4)影响客户正常通信和业务办理、查询的一般故障,报开发商一天无实质性进展,故障无法定位或故障解决时间无法确认;(5)升级投诉报开发商一小时无实质性进展,故障无法定位或故障解决时间无法确认。3)故障处理过程中上述已升级到上报室经理的故障:(1)升级投诉在报室经理到故障修复前,至少每半小时向室经理上报一次处理进展,视实际处理情况周期可缩短;(2)一般故障在报室经理到故障修复前,至少每3天向室经理上报一次处理进展,视实际处理情况周期可缩短;(3)一级故障,若48小时内未能解决应上报至部门经理;(4)二级故障,若24小

20、时内未能解决应上报至部门经理;(5)客服三级以上(包括三级)投诉,1小时内未能解决应上报至部门经理;4)故障处理上报不仅限于我室责任范畴内的故障,责任在其它室/部门的故障,如影响到本室负责的系统的正常运作、业务受理等的,也应上报;3、升级故障(上报中心经理):出现下述情况时,应由室经理通过电话向中心经理通报情况1)超过30名客户投诉不能正常进行通信(包括语音通信、短信息收发、GPRS、彩铃等服务功能),且无法在客户投诉时立即通过重置HLR资料等手段为客户恢复使用;2)可能有超过100名客户不能正常进行通信(包括语音通信、短信息收发、GPRS、彩铃等服务功能),且无法在客户投诉时立即通过重置HL

21、R资料等手段为客户恢复使用;3)超过30名客户投诉被误停机;4)可能有超过100名客户被误停机;5)超过30名客户投诉账户金额异常(包括异常减少、充值不到账等)、计费异常、银行扣费异常、缴费后无法开机;6)可能有超过100名客户的账户金额异常(包括异常减少、充值不到账等)、计费异常或银行扣费异常、缴费后无法开机;7)客户通过自助渠道无法查询/打印清单超过2小时;8)BOSS、CC、IBOSS系统无法登陆超过30分钟;9)影响到客户服务、公司运营等的重要数据丢失,事件发生超过30分钟,但未确认是否有解决办法;10)对1名以上红名单客户进行了误停机、误打扰;11)其它投诉在250单以上或可能影响的

22、客户超过500名的故障;12)一个月内反复出现系统登陆不稳定的故障,超过3次;13)一个月内反复出现自助渠道不能登陆的故障,超过5次;14)BOSS/IBOSS和CC、HLR、银行主动缴费、SMP的接口全面中断超过30分钟;15)四级及四级以上客户投诉处理进展;16)故障处理过程中遇到以下情况应立即再次电话上报(1)发现影响面可能进一步扩大;(2)发现新的故障现象;(3)影响客户正常通信和重要业务办理、查询的一般故障,报开发商及省公司一天无实质性进展,故障无法定位或故障解决时间无法确认;4、周报/月报1)周累计发生超过3次(含3次,一天内多次反复需计算为多次)或累计投诉量超过300单的故障需在

23、周报中体现;2)月累计发生超过3次(含3次,一天内多次反复需计算为多次)且累计投诉量超过500单的故障需在周报及月报中体现;3)月累计发生超过3次(含3次,一天内多次反复需计算为多次)系统无法登陆、客户无法登陆自助渠道、客户无法查询清单、客户无法办理服务功能、客户无法查询话费或账户余额、客户充值未到账的故障需在月报中体现;。2.2.3.3工作要求升级故障处理原则:将故障影响面降低到最小。1、 首先应正确估计故障的影响面,决定故障的处理优先级别;2、 对于超过10个以上客户出现相同故障(具有发展为严重或重大故障的趋势),上报室经理,同时按以下步骤启动紧急故障处理流程:1)发送故障通知短信;2)定

24、位故障点,协同开发商紧急处理,确认故障原因;3)遇到主要故障点涉及省中心,要第一时间向省业务支撑中心报障;4)定位目标客户群,同时对目标客户群进行分类及相关数据提取,确定影响面;5)确认故障原因后,采取措施,避免故障再扩大;6)制定升级故障的详细解决方案,并上报室经理,避免处理时欠缺考虑引发关联故障;7) 分类数据提供给上级及相关单位,确定处理办法及步骤,包括出错数据处理办法及应用软件的临时性或永久性修改。8)进行出错数据处理,及时核查处理情况,包括客户数据恢复、影响面缩窄情况;9)故障处理的情况应及时反馈,并发送故障跟进短信;10)应保证在故障处理中,不出现附加故障;11)如确认为软件版本缺

25、陷引起的故障,应及时知会支持维护室共同跟进;3、 应当协调相关部门确定解决方案1)解释口径和处理方法由市场部(数据业务中心/集团客户部)确定;2)将受影响号码、解释口径告知客服以进行前台解释工作;3)如涉及账务问题和银行方面的问题要知会账务室;4)若故障影响到批量业务处理,要及时通知电子商务中心进行批量业务排期,尽可能降低对批量业务的影响。4、 升级故障解决后,应及时提供相应的内容给当天负责值班日志撰写的同事,由其汇总在当天的值班日志中,并填写故障处理报告,并每周进行汇总,上挂至teamserver。5、 如不能在一个工作日内完成,需填写当日处理进展,每天发送故障跟进短信,处理进展填写应清晰明

26、了,要有结论性总结,如是否属系统问题等的清晰总结。6、 严重、重大故障、升级投诉故障通告发布 如发现严重以上故障,IT中心系统管理员需要通知68284的值班同事在服营网站及ioffice中上挂故障通知公告和故障恢复公告,需要通知68284的值班同事群发故障通知短信、故障跟进短信和故障恢复短信,公告和短信的内容及名单“升级投诉通告发布内容和对象”。注意事项:1)运营管理室升级投诉值班同事在发送升级投诉通知、跟进和恢复短信前要先将短信内容给故障处理组组长审核。2)地球村发送升级投诉通知、跟进和恢复短信前要先将短信发给运营管理室升级投诉值班同事审核后再发出。3)运营管理室升级投诉值班同事在发送升级投

27、诉通知前,要先将故障情况向运营室经理进行汇报,汇报前先告知故障处理组组长和室主管。4)增加D类客户:只有在三级以上(含三级)时才发给D类客户(也就是客服三级以上投诉发给CD类客户)。7.对于属于系统程序BUG引起的升级故障,需提IT协作单给支持维护室相关人员协助跟进,保障故障的解决并定期汇总处理情况。2.2.3.4工作流程图2.2.3.5相关文档1) 每周重大故障汇总序号故障现象影响范围发生时间故障恢复时间受影响号码恢复时间处理情况改进建议故障跟进人122.3 业务支撑系统BUG单处理 2.3.1目的规定业务支撑系统BUG处理工作流程,提高工作效率。2.3.2适用范围本规范适用于信息技术中心运

28、营管理室对业务支撑系统BUG处理工作的控制。2.3.3工作规范2.3.3.1概述角色分工、职责定义1. BUG单处理员职责:负责处理IT支撑人员提交的BUG单,协调省业支安排开发商对程序BUG进行修复,完善业务支撑系统,解决故障。目前的BUG单处理员由支持维护室同事担任。2. BUG单跟进员职责:负责跟进BUG单的处理情况,每周定期对AMS系统上的BUG单进行整理,更新BUG处理情况并上挂服务营销系统和合作伙伴门户,并及时更新上挂的资料。目前的BUG单处理员由运营管理室同事担任。2.3.3.2工作流程BUG处理需遵循以下流程:1、 BUG处理员需在AMS上提交BUG单给省业支复核,由省业支安排

29、开发商解决。2、 同时在服务营销系统、合作伙伴门户、BBS上上挂BUG信息公告,告知一线BUG处理情况(需注意内容的通俗易懂,尽量避免使用专业术语,并注意发布的格式);通过CMCP系统提协作单给室主管转发支持维护室跟进上载情况(注意单的内容要详细描述清楚故障,并附上已提交的BUG单号)。3、 判断程序BUG的影响面,如影响超过200客户或已引发客服二级以上客户投诉的(一般需上载紧急版本解决),应及时上报室经理请求协助推动解决。4、 对于影响面不大(即不需紧急上载版本)的BUG,BUG处理员则需推动开发商尽快完成程序BUG的上载。5、 BUG单跟进人员需注意每周及时更新信息,确认每个BUG单都得

30、到及时的解决,并及时反馈一线知晓。6、 对于BUG单回复不能通过验收的,由BUG单处理员退回开发商重新处理,直到BUG妥善解决为止。7、 发布格式如下:*系统程序故障通知:故障时间:*年*月*日*时*分,故障现象:(用户无法缴费),故障原因:(如BOSS系统*程序有问题),影响范围:(如所有用户无法缴费),处理情况:目前确定程序存在问题,需要安排程序上载解决,预计程序上载时间:*,故障跟进人:* ,程序上载跟进人:*,应急处理方法:*。注:预计程序上载时间以及应急处理方法需要运营管理室与支持维护室同事协商后发布。2.3.3.3工作要求对于属于系统程序问题,由IT支撑员提交BUG单给支持维护室相

31、关人员跟进,BUG单跟进员负责跟进BUG单的处理情况,须保障故障的解决并定期汇总处理情况。同时由支持维护室制定BUG所造成影响的临时解决方案,由运营管理室和支持维护室共同跟进解决,如需进行数据处理则转数据处理流程,对于造成影响面大的BUG,,及时上报领导请求推动解决。2.3.3.4工作流程图2.3.3.5相关文档1、 CMCP协作单格式:支持维护同事:你好,*系统发现存在问题:应详细描述故障现象,(必须要有投诉号码及投诉问题)开发商的回复:如有BUG单号,需说明BUG单号。需要支持维护室协助的内容影响范围:应说明投诉量或导致系统中断的时间紧急程度:特级、紧急、一般期望解决时间:应说明如未在该时

32、间点前解决,会出现什么问题。2、 BUG单每周情况汇总表格:时间BUG单号提交人问题描述AMS单号CMCP协作单号转支持维护室的单号是否已上载预计上载时间程序修复前的处理方法2.4业务支撑系统后台数据操作2.4.1目的为规范后台数据处理操作的流程、工作标准,保证数据处理操作的严谨性和安全性,避免不必要的数据修改错误发生,提升深圳分公司的维护深度,特制定本工作规范。2.4.2适用范围本规范适用于信息技术中心运营管理室对系统后台数据操作的控制。2.4.3工作规范2.4.3.1概述1、 后台数据操作的定义1) 后台数据修改是指直接登录后台数据库对数据库表记录进行增、删、改的过程。分为批量数据修改(涉

33、及1000条以上的后台记录数据的修改、金额差异超过10万元的财务报表数据修正或误差超1000的商品进销存报表核对数据修正)、单个数据修改两类。2) 后台数据提取是指从直接登录后台数据库查询并导出所需数据的过程,并不单单指后台数据查询,如果只是简单地完成后台数据查询但并不导出查询结果,不能算是后台数据提取,不纳入后台数据管理范围。2、 角色分工及职责1) 数据操作提交人职责:负责提交数据修改任务,填写数据修改单,并明确任务紧急程度以及影响范围。一般指深圳分公司系统维护人员。数据提取操作提交人为数据分析室人员。2) 数据操作处理人职责:根据数据修改任务单或者数据提取单内容,依专业分工负责任务的处理

34、,协调内部的各类资源,并将处理结果以有效的方式通知数据操作提交人。数据操作处理人可以是开发商,也可以是深圳分公司系统维护人员。3) 数据操作审核人职责:负责审批和核实数据操作处理人处理的结果是否正确。一般指深圳分公司系统维护人员。2.4.3.2工作流程1、 数据修改流程1) 数据操作提交人提交数据修改工单,可以是AMS数据修改单或cmcp故障单或cmcp协作单。2) 数据操作处理人在数据修改工单上提供修改脚本并且备份数据。3) 数据操作处理人(市公司)审核脚本和备份数据,确认无误后自行修改或者给数据操作处理人(开发商)修改。4) 数据操作审核人审核处理结果,确认结果无误后通知需求方对结果进行业

35、务审核和确认。2、 数据提取流程1) 数据操作提交人(数据分析室)提交数据提取工单,一般是cmcp系统IT协作单。2) 数据操作处理人核实需求并评估需求所需时间通知需求方。3) 数据操作处理人提供提数脚本,并附在数据提取工单上。4) 数据操作处理人(市公司)审核脚本,确认无误后自行提取或者给数据操作处理人(开发商)提取。5) 数据操作审核人审核处理结果,确认结果无误后通知需求方对结果进行业务审核和确认。2.4.3.3工作要求1、 数据修改数据修改是直接在后台对数据库库表的操作,而不是通过操作前台相关菜单完成的。如处理方法不当,可能会破坏前后台业务和库表的正确对应关系,影响客户业务资料的完整性,

36、影响前台相关号码的业务办理,影响相关报表,甚至产生不必要的呆坏帐。因此,有必要规范数据修改动作的操作流程,完善对“数据修改”动作的管理。具体动作要领如下:1) 所有数据修改动作均必须在AMS系统或CMCP系统中记录,必须提交到AMS系统或CMCP系统中以便于备查。数据修改动作都必须通过AMS数据修改单、CMCP业务故障单或IT协作单工单完成,不能通过AMS系统故障单、需求单或其他类型的工单完成。2) 提交数据修改任务时,需要明确具体的影响面以及此次修改可能带来的其他影响(业务、帐务、报表等)。尽量采用少量、多次的方法进行数据删除或更改操作。3) 省公司将批量数据修改(涉及1000条以上的后台记

37、录数据的修改、金额差异超过10万元的财务报表数据修正或误差超1000的商品进销存报表核对数据修正)权限下发市公司后,深圳分公司提交的批量数据修改单不再直接由省公司进行业务审批和技术审批,而是等同于单个数据修改流程,直接由深圳分公司进行业务审批和技术审批。业务审批和技术审批可以是同一个人。4) 对单个号码的数据修改,可直接在数据修改单标题或内容中记录清楚原始号码数据和相关的脚本即可,不用以附件的方式存放在单上,这样搜索起来相对来说比较容易,对于批量的数据修改,则可在系统上以附件的形式存放相关数据。5) 开发商进行数据修改前,必须明确具体的影响面以及此次修改可能带来的其他影响(业务、帐务、报表等)

38、,并回复任务提交人,任务提交人同意后,开发商才能进行下一步的动作。6) 为了防止修改出错,使修改动作可回溯,在修改动作之前,需备份相关的数据。特别是删、改操作。7) 如涉及一级敏感数据,数据工单发起人对一级敏感数据的非日常临时操作必须填写运维访问敏感数据审批表,在AMS系统或者CMCP系统获得本公司上级主管人员的审批许可后放可对数据进行操作。一级敏感数据包括:集团客户资料(集团客户编号、集团客户名称、所在省市、所在行业)、详单(主叫号码、主叫位置、通信时间、时长、流量)、个人大客户资料(个人大客户编号、工作单位、婚姻状况、性格、个人喜好)。一级敏感数据可以给在现场的开发商处理,市公司人员全程监

39、控.不能给远端开发商处理。8) 涉及一级敏感数据的批量数据修改,操作前必须填写批量敏感数据修改审批单,由室经理批准后方可操作。9) 如果是数据工单发起人自行操作,则需由深圳分公司其他人员负责验收,不能由数据工单发起人自行验收。10) 为了追述当时数据修改的实际情况,需记录当时数据修改的痕迹,开发商需把备份数据和数据修改的相关脚本均作为附件放在相应数据修改单中。11) 单个数据修改的数据操作处理人和数据操作审核人可以是同一个人;但是批量数据修改及重要数据修改必须由不同的人担当数据操作处理人和数据操作审核人的角色。12) 数据操作审核人审核时必须1.核实数据修改脚本无误;2.核实数据修改结果无误,

40、对于批量数据修改,可以采取抽查的形式审核数据结果。13) 对于某个具体故障引起的数据修改,系统维护人员不能只是简单要求修改投诉号码的出错数据,而需要考虑此故障的具体影响面,让开发商提取此故障引发的所有出错数据,统一提取,一并处理。14) 如开发商数据修改出错的影响面超过一定范围,深圳分公司可考虑在当月对开发商的考核中酌情扣分。15) 按SOX要求,所有数据管理操作均必须有记录,符合“业务审批-技术审批-执行-复核-定期审计”流程要求。16) 以上数据修改操作工作原则适用于BOSS、IBOSS、CALLCENTER以及渠道系统。2、 数据提取我中心数据提取的接口是数据分析室,所有的数据提取需求,

41、数据分析室必须派CMCP协作单到我室进行处理。我室提取出来的数据只能给到数据分析室,禁止通过别的渠道将数据直接给到需求方。具体要求如下:1) 所有的数据提取需求必须有详细的需求说明,包括: 需求用途,需求内容描述,数据详细要求,需要的字段。2) 上班高峰时间(9:00-12:00,14:00-18:00)禁止操作大批量数据提取(涉及后台提取记录数超5万条)和执行时间超过15分钟的语句。3) 数据提取必须由不同的人担当数据操作处理人和数据操作审核人的角色。4) 数据操作审核人审核时必须1.核实数据提取逻辑无误;2.核实共提取的记录数,提取的数据总记录无误;3.抽查至少3个号码,符合数据提取的条件

42、。5) 数据提取处理完毕后,必须以短信、邮件或电话等方式告知需求人,请需求方对处理结果进行业务审核。2.4.3.4工作流程图1、 数据修改流程 2、 数据提取流程2.4.3.5相关文档2.5业务支撑系统工程割接2.5.1目的规定业务支撑系统工程割接工作流程,确保业务支撑系统运行的安全性和可靠性,为公司运营系统和移动网络正常运行提供安全、可靠、优质的支撑服务,加强业务支撑系统工程割接的管理。2.5.2适用范围本规范适用于信息技术中心业务支撑系统工程割接的工作控制。业务支撑系统的范围包括:BOSS系统、旧BOSS系统、客服系统、MCDM系统、渠道管理系统、大客户管理系统、网站系统、影像系统等。2.

43、5.3工作规范2.5.3.1概述1、 工程割接工作定义业务支撑系统工程割接的内容包括业务支撑系统的扩容、设备调整、设备更换、设备改造、设备搬迁、系统软件补丁装载、系统软件版本升级、核心数据割接等;业务支撑系统工程割接可分为硬件割接、软件割接、数据修改割接。2、 工程割接相关部门1) 省公司业务支撑中心及市公司网络部为业务支撑系统工程割接的上级管理部门,主要负责:安排和审核生产部门提出的割接申请;2) 信息技术中心运营管理室是业务支撑系统工程割接主办室,工程割接主办室的业务支撑系统工程割接管理员为工程割接第一责任人,主要负责:(1) 根据上级主管部门的网络工程割接安排或运营维护需要,制定工程割接

44、方案,通过AMS系统向省公司业务支撑中心提出工程割接申请。(2) 省公司业务支撑中心申请通过后,工程割接第一责任人通过无纸化审批系统填写割接审批单或发文的形式提交信息技术中心及相关部门会签。(3) 会签通过后,无论市管项目还是省管项目,预计会影响到客户业务办理的,均应按照相关法律的要求发文给行政服务中心在媒体发布割接公告。(4) 工程割接实施前向分管领导和相关部门通报工程割接的时间和影响的范围。(5) 按照批准的方案组织进行业务支撑系统工程割接,并记录工程割接过程和做好文件的归档工作。2.5.3.2工作流程业务支撑系统工程割接开始前:1) 工程割接负责的开发商需提供割接报告初稿,包括:割接方案

45、、割接应急预案、割接拨测列表等信息;工程割接负责人需严格审核割接方案是否切实可行,并根据割接影响与业务部门商讨割接时间,并根据需要与综合部商讨割接发布公告事宜。提交给主管审批的割接报告需包括:割接方案、割接应急预案、割接拨测列表、割接时间、割接影响、申请工程割接的依据、系统割接申请(公文)等,如果需要发布社会公告,需包括拟好的社会公告。2) 业务支撑系统工程割接现场负责人务必与施工单位现场负责人、现场操作人员开会熟悉工程割接方案,强调安全注意事项,重申双方责任。3) 业务支撑系统工程割接负责人应具备业务支撑系统割接工作相应资质,并提前15分钟到达现场,做好工程割接过程中可能出现各种异常情况的应

46、急准备。4)业务支撑系统工程割接人员按照工程割接检查项目清单检查、记录业务支撑系统设 备运行情况,确认设备状况满足工程割接的条件。5)业务支撑系统工程割接必须在工程割接主办人员、配合部门和施工单位的相关人员全部到达现场作好准备后,由主办工程割接现场负责人下令后才能开始实施。2、 业务支撑系统工程割接过程中:1) 所有现场人员必须严格按照既定的工程割接方案实施,并按系统安全要求操作;2) 重要的操作必须“一人操作、一人监督”的双人“AB”角操作。负责根据相关规定组织测试和验证工作,参加工程割接的配合人员须服从现场负责人的统一安排进行测试和验证。3) 工程割接负责人员应密切注意客户服务中心反馈过来的客户投诉,及时解决处理。3、 业务支撑系统工程割接后:1) 现场的相关技术人员按照割接检查项目清单做好检查、记录工作,确认设备运行正常并达到工程割接的预期效果。2) 设备运行正常后,通知客服中心值班人员进行相关的业务测试。2.5.3.3工作要求1、 业务支撑系统工程割接负责人必须至少提前三个工作日完成割接的申请工作,工程割接申请内容包括:1) 割接时间;2) 割接方案(包括应急方案、工程割接检查项目清单);3) 割接人员;4) 影响范

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 办公文档 > 其他范文


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号