|
|
落地实施③：实施测试用例
ITIL应用落地的背景
XXX电商公司，是一家专业从事XX销售的电商集团化企业；在业务落地的过程， 面临着：① 新员工缺乏入职培训，知识储备更不上；② 运营团队人效不高，运营很忙，但是依旧无法满足一线员工的需求；企业雇主无从得知原因所在；③ 对于运营提出的产品优化建议，产品无法判断需求紧急；出现过功能升级误判的情况，只能紧急回滚；④ 对于非业务部门，无法评估工作量；人工成本优化无从下手；⑤ 无法从复杂繁忙的业务处理流程 发现潜在问题，及时预警 并备案，而实践ITIL就是为了逐渐看清楚企业每天的业务动态及其问题
为什么要用ITIL管理公司？
A，销售咨询运营 某个常见问题；而这样的问题 每天都在重复B，销售委托运营查询某个问题，而运营因为工作太忙忘记了C，运营主管安排给运营专员 处理 销售A的事情，因为需要询问客户当时的情况，暂时搁置导致问题被忽略；客户一个星期后愤怒投诉销售D，客户发起退货，销售安排运营解决，运营求助主管，主管安排给了售后专员；但是客户一星期后投诉事情并未解决；追查问题，几方都说自己已经安排工作了E，同时有多个产品优化需求等待排期，在考虑优先级的时候，产品经理忽略了某个特别重要的优化需求，导致了与周三某个故障无法解耦，造成了全国性的故障；而后为了避免 产品优化任务优先级出现问题，产品经理 需要一周一次 碰头汇总讨论，评估需求的优先级，极其耗费时间F，商城开发团队因为PHP版本更新，部分函数被禁用，申请修改 开发环境中的PHP版本，由于事先未通知到所有依赖所有开发环境的团队，导致业务报错；因此运维只能回滚解决，商城只能浪费今天下午的工作，等待运维安排升级计划
汇总如下
场景流程应用 内容 流程
请求 处理常规业务问题 常规咨询：销售=》运营
软体产品bug：运营=》产品
硬体产品故障：产品=》IT
工单 汇集请求；统计分析工单 集中解决bug：产品=》研发
bug 或者故障判断：产品=》研发
大规模爆发问题处理：销售=》运维
重大缺陷bug爆发：销售=》产品
问题 汇集同类型工单，制作FAQ 咨询常见问题：销售=》运营
软体产品常见问题：销售=》运营/产品
硬体产品常见问题：产品=》IT
变更 bug 或者故障已确定原因者，申请 新版APP上线更新（对已有资源进行变更） APP发新版：产品=》质量=》运维=》质量
新版销售培训：产品=》运营
更换新IT设备：销售=》IT
更换开发环境系统：研发=》运维
业务类型 测试业务流转用例
请求 咨询：商户A昨天下单1件葡萄，但是今天没有送货
咨询：商户B昨天下单2件苹果，今天没有送货
bug/故障提报A：销售提报 商城 有下单失败的bug
bug/故障提报B：销售提报 商城 有下单失败的bug
bug/故障提报：白云区销售 反馈 访问商城 加载速度慢
bug/故障提报：天河区销售 反馈 访问商城 加载速度慢
客诉：400来电，客户A对于缺货但销售未通知的行为相当愤怒，请求安抚
客诉：400来电，客户B对于缺货但销售未通知的行为相当愤怒，请求安抚
工单 广州 昨日出现机房访问速度过慢
商城 APP 出现数据丢失
销售 缺少客诉处理能力
运营 广州客户安抚问题
问题 广州因为网络问题，导致9月22日 下单失败；在极端网络情况下 存在数据丢失bug；机房对于广州的访问请求存在优化的余地
A，广州大区 对于销售实现 客诉处理专题培训
B，运维部门对机房广州地区访问线路进行优化
C，研发部门对APP下单bug 进行修复
变更 广州运营安排客诉培训
APP发布新版
IT发布机房线路切换
运维更换 开发环境 PHP版本
目前以某集团化公司作为样本，公司结构整理如下
公司组织结构
guest集团
北京分公司 （北京分公司在功能上定位于总部，与分公司重叠的销售与销售运营部 属于分公司的上一级管理部门）
北京分公司-产品-商城
北京分公司-研发-商城
北京分公司-质量
北京分公司-IT
北京分公司-运维
北京分公司-销售
北京分公司-销售运营
广州分公司
广州分公司-销售
广州分公司-销售运营
广州分公司-IT
服务与组织关系对照表 提供的服务子集 服务子集归类
广州分公司-销售 销售 销售
广州分公司-销售运营 销售运营 销售运营
北京分公司-产品-商城 产品-商城 商城
北京分公司-研发-商城 研发-商城 商城
北京分公司-质量 质量 质量
北京分公司-运维 运维 运维
北京分公司-IT IT IT
服务合同与客户组织关系 可以拥有的服务 合同
广州分公司-销售 销售运营
IT 销售运营 合同
IT 合同
广州分公司-销售运营 产品-商城
IT 产品-商城 合同
IT 合同
北京分公司-产品-商城 研发-商城
IT 研发-商城 合同
IT合同
北京分公司-研发-商城 质量
运维
IT 质量 合同
运维 合同
IT 合同
北京分公司-质量 IT IT合同
北京分公司-运维 IT IT合同
总结，整理到这里，整体请求所需要的组织结构、服务结构、包括服务与组织之间的关系，就已尽数描绘清晰。
itop所需人员关系描述 账号信息 组织关系
客户A
客户B kehua 密码：123456
kehub 密码：123456 联系人（itop用户）
广州分公司-天河区销售
广州分公司-白云区销售 gzxiaoshoua 密码：123456
gzxiaoshoub 密码：123456 联系人-广州分公司-销售
广州分公司-销售运营 gzxiaoshouyunying 密码：123456 联系人-广州分公司-销售运营
广州分公司-IT gzit 密码：123456 联系人-广州分公司-IT
北京分公司-销售 bjxiaoshoua 密码：123456
bjxiaoshoub 密码：123456 联系人-北京分公司-销售
联系人-北京分公司
北京分公司-销售运营 bjxiaoshouyunying 密码：123456 联系人-北京分公司-销售运营
北京分公司-产品-商城 zbshangchengcp 密码：123456 联系人-北京分公司-商城-产品
北京分公司-研发-商城 zbshangchengyf 密码：123456 联系人-北京分公司-商城-研发
北京分公司-质量 zbzl 密码：123456 联系人-北京分公司-质量
北京分公司-运维 zbyw 密码：123456 联系人-北京分公司-运维
北京分公司-IT zbit 密码：123456 联系人-北京分公司-IT
|
|
skymemory
发表于 2016-9-29 10:46:27
