光明乳业HelpDesk实施方案.docx
- 文档编号:15109401
- 上传时间:2023-06-30
- 格式:DOCX
- 页数:24
- 大小:28.37KB
光明乳业HelpDesk实施方案.docx
《光明乳业HelpDesk实施方案.docx》由会员分享,可在线阅读,更多相关《光明乳业HelpDesk实施方案.docx(24页珍藏版)》请在冰点文库上搜索。
光明乳业HelpDesk实施方案
MD020
上海光明乳业股份有限公司
OracleiSupport/Support
实施方案
文档说明
文档简介
该文档为上海光明乳业股份有限公司(以下简称光明乳业)HelpDesk(OracleiSupport/Support)的详细方案实施文档。
OracleiSupport/Support模块的功能能较好地满足光明乳业的业务需求,本文档将对光明乳业的业务需求和系统功能匹配进行详细描述。
该文档的内容涉及到光明乳业在IT服务方面的主要内容和关键流程。
有关名词
本文中使用的有关名词,作出如下限定:
客户:
指信息部的服务对象,指光明乳业的业务用户,使用iSupport、Email或电话获得信息部的服务。
服务人员:
信息部负责客户服务的人员,包括服务管理人员、客户代表。
服务管理人员可以对服务进行协调管理、并有权对系统进行设置,客户代表指相关服务人员。
方案概述
根据光明乳业HelpDesk的业务需求,决定采用OracleiSupport/Support系统构建系统。
OracleiSupport是一个基于Web的前台应用,是提供给客户使用的。
客户登录系统后,可以提交新的服务请求,查看已有服务请求的处理记录、搜索知识库、参加在线论坛、修改个人信息等。
OracleSupport是一个具有Form的后台应用,是提供给服务人员使用的,主要用来处理客户提交的服务请求。
其基本功能包括服务请求和任务的创建、分配、查看、记录、更新,知识库增加以及其它管理功能。
系统功能概览
iSupport功能概览
本方案将使用iSupport以下功能:
服务请求管理
∙可在任何时候在线提交或修改服务请求
∙在需求提交之前,有选择地增强知识管理搜索
∙可查看服务请求处理过程和进行交互
∙可自定义搜索和显示条件搜索服务请求
知识管理
∙基于搜索功能的直观语句
∙使用解决方案关系的基本与高级搜索特征,用来匹配已知的解决方案集
∙搜索与深入访问在线参考材料
个性化主页
∙便于客户进行定制的灵活主页
∙可以给所有用户发送的事前通知
交互式在线论坛
∙交互式讨论论坛
∙搜索主题及浏览论坛
Support功能概览
本方案将使用Support以下功能:
服务请求管理
∙多渠道服务请求管理:
包括呼叫中心(电话)、电子邮件和网络
∙直接创建或修改服务请求
∙可查看服务请求处理过程和与iSupport用户进行交互
∙可自定义搜索和显示条件搜索服务请求
∙进行服务请求责任人分配
任务管理
∙直接创建和分配任务
∙任务完成情况汇报
资源管理
∙创建和导入资源
∙资源组织结构定义
∙资源职责类型定义和职责分配
知识管理
∙基于搜索功能的直观语句
∙使用解决方案关系的基本与高级搜索特征,用来匹配已知的解决方案集
∙利用服务请求和知识库的集成,不断增加新知识到知识库中
UWQ查看
∙直接查看用户自己、所属组、所属小组的负责的服务请求和任务
∙可自定义参看方式
∙双击可查看详细信息
全面集成
∙通过全面集成Oracle电子商务套件应用来增强功能
本方案将着重介绍以下内容:
☐系统的建立与权限控制
☐服务请求管理
☐知识库
☐论坛
☐外包服务
系统的建立与权限控制
系统的建立
模块的应用
在光明乳业,为保证iSupport/Support正常实施,除了相关的ERP模块(如财务、人事、库存等)外,以下模块必须设置并使用:
☐OracleiSupport:
iSupport相关设置及权限管理
☐MES(市场百科全书):
主要是iSupport主页内容和技术资料库设置
☐CRMFoundation:
资源、任务、附注等定义
☐OracleSupport:
服务请求、知识库等相关设置
责任的设置
根据光明乳业HelpDesk的业务需求,在iSupport应用(称为前台应用)中,设置两种责任:
☐iSupport系统管理员:
用于维护客户登录iSupport时的内容及审核,并提交系统管理员设置用户,分配责任
☐光明乳业iSupport内部业务用户:
具有基本的iSupport使用功能,包括:
主页、支持、论坛页面
在Support应用(称为后台应用)中,也分两种责任:
☐光明乳业客户服务管理员:
具有全部的客户服务代表权限,并可对Support模块进行相应的设置
☐光明乳业客户服务代表:
普通客户服务人员使用的工作平台,可创建和查看服务请求,以及进行服务请求的处理等
用户管理及责任设定
使用iSupport/Support的用户,需要系统管理员在系统中设置,并分配相应职责。
客户(业务用户)管理
按OracleiSupport/Support设计逻辑,理想的方式是为公司类别员工分配一个帐号,以公司内部员工的身份使用日系统。
为每个员工分配帐号还可记录该员工的联系方式,如email,电话等。
但这样做的信息录入工作量非常大,考虑到光明乳业已经实施人力资源管理,如果在这套系统中重复录入这些信息,是没有必要的。
因此建议,为每个业务部门分配一个统一的帐号,分配光明乳业iSupport内部业务用户责任,使用iSupport系统。
ERP系统升级后,可将HelpDesk系统与ERP系统合并,再为每个具体的业务用户分配相应的责任。
因为业务部门用户为公司内部用户,定义为员工类型,即将部门看作单个的员工处理,姓氏为事业部名称,名字为下属部门名称,可以为它们设定默认的联系方式(电话、email),如果实际联系方式与默认方式不同,可以在附注中进行说明。
服务人员用户管理
光明乳业的服务人员,分配后端Support相应的服务代表和管理员责任。
系统上线初期,设置用户的用户名、密码及责任,见附件1,附件2
系统上线后,用户的增加、注销和权限变更都需要系统管理员进行统一维护,光明乳业必须制定相应的权限管理规范,以保证系统使用的安全性。
服务请求基础
服务请求是贯穿整个服务流程的一条主线。
客户(业务用户)通过电话、传真或网上登录的方式提出服务请求,光明乳业的服务人员参与解决,直至服务请求关闭。
光明乳业可以根据系统中输入的信息定期进行汇总分析,提高服务水平。
服务请求的基本要素
服务请求的类别
对服务请求进行分类,可以区别不同业务来管理。
不同类别的服务请求,可以定义不同的状态,以驱动不同的服务请求处理流程。
不同类别的服务请求,可以与不同的工作流(Workflow)相联系,这种工作流,可以通过系统本身在服务请求创建时触发,也可人为地在后端系统触发。
根据对光明乳业服务业务的综合归纳,可以将服务请求分为以下几种类别:
☐客户投诉
☐培训、办公、行政、联络
☐电脑配件维修
☐外包供应商服务跟踪
☐台式机采购
☐便携机采购
☐打印机采购
☐其它采购
☐邮件帐号申请
☐网络帐号申请
☐网络存储
☐网络技术支持
☐系统安全支持
☐病毒防治
☐PC安全支持
☐公用技术支持
☐战略项目支持
☐ERP系统性能支持
☐ERP软件支持
☐ERP服务器采购
☐OSA支持
☐OFA支持
☐物流项目
☐PDA支持
☐SCM支持
☐网上牧场
☐一般故障问题
☐系统报表数据问题
☐系统报表开发问题
系统流程更改问题服务请求的状态
服务请求的状态必须预先确定,以便对不同类别的服务请求指定不同的状态,以便监测请求执行的情况。
建议将服务请求分为以下几种状态:
☐打开(Open):
服务请求提交时的初始状态
☐已分配(Assigned):
服务请求已经指定责任人负责解决
☐处理中(Ongoing):
服务请求正在处理之中
☐已完成(Finished):
服务请求已经完成
☐用户取消请求(UserCancelled):
用户认为服务请求服务请求已无必要继续处理,请求取消,责任人无需再继续处理
☐友好关闭(SoftClose):
获得客户认可后关闭
☐强行关闭(HardClose):
未能获得客户完全认可,但问题已经解决
关联的这些状态,可以被跳过,但都必须有打开和关闭两种状态。
系统默认的状态为创建时的状态,即打开。
服务请求的责任人
服务请求的责任人表明该服务请求需要由谁负责进行处理。
系统中责任人可以为三种资源类型,即:
员工资源(EmployeeResource)、组资源(GroupResource)、小组资源(TeamResource)。
服务请求责任人设定及处理流程见下节。
紧急程度与重要性
紧急程度(urgency)是从客户的角度对服务请求的感觉。
建议设定三种层次:
高、中、低。
重要性(serverity)是从服务人员的眼光来看待服务请求。
建议也设定三种层次:
高、中、低。
对于这些不同的层次,用不同的颜色加以区别,以便更直观地获得对服务请求的印象。
高—红色,中—黄色,低—蓝色。
服务请求的记录
服务请求的提交
服务请求有两种提交方式:
☐客户直接在网上提交。
☐客户通过电话或传真形式通知光明乳业的服务人员,由服务人员在后端系统,即OracleSupport中记录。
两种形式提交的服务请求都会存放在系统中,并在同一个界面可以查询到。
在系统的使用过程中,建议尽量培养客户网上提交请求的习惯。
这样的好处是:
在网上由客户直接输入,能够比较清楚地表达客户问题;减少服务人员地工作量;用户也可以通过搜索知识库自己解决问题;而且网上信息能够供各业务部门共享,避免重复。
服务请求回应记录
通过两种形式提交的服务请求,在解决过程中的每一个步骤,都必须有解决人的记录,以保证信息的完整性。
更重要的是,可以使客户及时了解到请求的处理状态。
系统中提供了“附注”的文本记录工具供客户和服务人员使用,使他们可以进行实时的互动交流。
在请求完成后,如果客户能够确认请求结束,则由客户关闭请求;在实际情况中,客户可能由于种种原因,不能及时关闭请求,服务人员必须根据请求解决的实际情况,将状态更改为“关闭”。
请求是否及时关闭,在一定程度上表明解决客户请求的效率和质量。
因此,或者由客户,或者由服务人员,及时关闭请求。
系统日志
系统会根据服务请求的变更情况自动生成相应的日志文件,日志文件记录了该请求没次变更的时间、更新用户及相关内容。
管理人员从日志文件能详细地了解服务请求处理的过程。
服务请求责任人与流程
服务请求的责任人分配
请求责任人的指定
客户在网上提交的请求,系统中可以设定默认的责任人,建议设为HelpDesk管理员,由他根据服务请求的类别和客户所属单位进行二次分配。
对于客户打电话提交服务请求的情况,服务人员可以根据服务请求的类别和客户所属单位直接指定责任人,如果服务人员不清楚有谁处理,可将服务请求责任人设为默认责任人(不需修改,为客户服务管理员)。
不管哪种情况,服务请求指定明确的责任人后,都需要将状态从“打开”改为“已分配”,表明该请求已分配给相应的人员负责处理。
责任人(服务人员)的组织
根据光明乳业的实际业务情况,尤其是实行ERP支持服务客户代表政策以后,需要根据客户所属单位指定相应的客户代表组负责处理相应的服务请求。
客户代表组成员处理相应的服务请求或再指定具体人员负责。
ERP日常业务问题和ERP月底结帐问题需要设定的客户代表组分别为:
组名
成员
总部客户服务组
钱文强
物流事业部客户服务组
孔暹
保鲜事业部客户服务组
曹彦/周静/易晖
常温事业部客户服务组
许沛明
瓶袋事业部客户服务组
黄伟/梅黎/宓云峰
上海达能客户服务组
曹彦/周静/易晖
工业原料事业部客户服务组
黄伟/梅黎/宓云峰
黄油干酪事业部客户服务组
黄伟/梅黎/宓云峰
奶粉事业部客户服务组
许沛明
奶牛事业部客户服务组
齐莉莉/王巍
全国地区客户服务组
曹彦/周静/易晖/黄伟/梅黎/宓云峰
上表只是表明光明乳业的业务运行实际情况,系统中并不作硬性设定,即客户提出相关服务请求时,可以按以上规则指定相应的客户服务组负责处理相关的服务请求,也可指定其他组,甚至个人负责处理。
这样可以保证在全公司范围内协调资源,也可保持充分的柔性。
服务请求流程
根据光明乳业的业务实际情况,不同类别的服务请求处理流程大致是相同的,不再进行细分,根据此定义的相关状态的转换序列也不做硬性设定,以反应光明乳业实际业务情况。
如上图所示,业务处理过程大致分为服务请求提交、服务请求分配、服务请求处理、服务请求关闭、服务请求评价五个阶段。
1服务请求提交
提供两种服务请求提交方式,业务部门人员可以登录iSupport通过web方式提交,也可直接打电话给IT部支持电话,由相关负责人代客户提交提交。
提交过程中都可以搜索知识库帮助解决问题,如果问题解决,即可结束。
2服务请求分配
对于通过知识库帮助和HelpDesk负责人自己无法解决的问题,可将该服务请求分配给相关服务组或人员处理,或者根据服务请求,也可创建相应的任务分配给相关人员处理。
3服务请求处理
分配服务请求和任务后,相关人员从UWQ将能看到自己或所属服务组负责的服务请求和任务,进行服务请求处理。
在服务请求处理过程中,可通过状态变化描述不同的处理阶段,利用附注与客户进行交互和相关服务记录。
如果服务请求较复杂,可定义相关的任务,任务能详细说明内容、完成时间等相关信息,对于有关联的多个任务,系统还能定义其关系。
服务人员收到任务后,即可去完成任务,完成过程中可利用系统与提出服务请求的业务用户进行互动交流。
完成任务后,将详细信息记录进系统,并关闭任务。
4服务请求关闭
如果业务用户对问题解决认可,可关闭服务请求,如业务用户对解决方案长期不应答,则可通知其关闭请求,如仍不响应,则可强行关闭。
关闭服务请求时,如果该服务请求具有代表性,需要将解决方法共享,可将该服务请求的解决方法归纳总结,录入知识库系统,以便日后遇到类似问题时,可参考相应的解决方案!
5服务请求评价
关闭请求时,可要求用户对IT人员的服务进行评价,部门经理也可根据服务记录进行评价。
采购服务管理
以上服务请求的描述和处理流程比较符合光明乳业内部负责服务请求(如ERP技术支持、ERP日常业务等)的管理需求。
对于采购服务和外包服务管理,由于其特殊性,需要进行说明和特殊处理。
光明乳业IT部门负责的IT设备采购、软硬件系统和设备的技术支持和维护等工作的具体执行有相关的IT外包服务商提供,IT部门只负责执行过程的监督和异常情况的处理。
目前,光明乳业IT设备的采购有两种方式,即
1业务部门直接采购,如台式机、网络设备、消耗品等
2业务部门提出采购需求,相关部门审批、IT设备代为采购,如笔记本、服务器等
不管哪种采购方式,具体的审批和采购流程由ERP的采购模块管理,采购物品的统计也根据采购模块开发的报表来完成。
HelpDesk系统只需记录第二类采购事件。
系统定义了采购类服务请求,如:
☐台式机采购
☐便携机采购
☐打印机采购
☐其它采购
具体的采购信息描述在请求汇总字段中,如果需要更加详细的信息,可用附注记录,可设置“采购详细说明”类附注。
为更加贴切的描述采购事件,可以定义不同于普通服务请求的状态,如可定义以下状态描述采购类服务请求。
☐打开
☐已审批
☐采购中
☐用户已收到采购品
☐关闭
外包服务管理
外包服务管理的目的是希望将外包给服务商的服务内容实时记录到系统中,进行监督、管理和考核。
服务信息记录
外包服务信息的记录分为报修信息、维修信息、统计信息。
系统中没有完全对应的字段来记录这些信息。
因此,需要选择恰当的字段来记录这些信息。
信息类别
服务信息
说明
记录字段
报修信息
服务编号
服务请求编号(RequestNo)
事业部
姓氏
报修部门
名字
报修人
弹性域
地址
默认地址、附注或弹性域
电话
默认电话、附注或弹性域
报修日期和时间
Createby/弹性域
故障描述
汇总(Summary)
重要程度
重要程度(Severity)
紧急程度
紧急程度(Ugency)
责任人
外包服务商名称
责任人(Owner)
维修信息
处理状态(完成否)
状态(Status)
工程师
弹性域
修理日期和时间
Respondby
故障情况
故障原因
附注
其它说明
未完成原因及其它说明
附注
结束日期和时间
Resolutionby
客户评价
好、中、差
附注
统计信息
等待用时
修理用时
全程用时
报修信息
报修信息大多可以服务请求的标准字段记录,唯一例外的是联系人信息。
由于为每个事业部的相应部门分配统一帐号,并将事业部作为企业员工看待,因此将事业部用员工姓氏记录、部门用名字记录,可为他们定义默认的地址、联系电话和email,至于联系人可以用附注记录,如果联系方式与默认值不符,也可用弹性域(或附注)来记录。
用姓氏和名字记录事业部和相应部门,可方便进行统计。
服务请求的创建时间本身可理解为报修时间,但由于可能不是在线工作,属于事后录入,但服务请求创建时间是不可更改的,因此需要记录在弹性域中。
维修信息
维修信息中说明信息(如故障原因、其它说明)用附注记录,时间信息用服务请求标准字段记录。
处理状态为标准字段,其它用弹性域记录。
统计信息
统计信息,不在系统中记录,可开发报表,通过计算得到用时统计信息。
弹性域设置
因此,针对外包服务,需要启用弹性域,如下表:
编号
字段名称
类型
说明
1
报修人
文本
2
地址
文本
3
电话
数字
4
报修日期时间
标准日期时间
5
工程师
文本
6
客户评价
值集
好、中、差
外包服务处理流程及信息录入
外包服务处理流程
外包服务现在的处理流程如下图所示。
从流程图可以看出,信息部只负责特殊情况的处理和最后的统计考核工作。
对具体的服务过程(尤其是一般服务)只能事后监督,这并不是一种合适的管理方式,应该尽量做到事中,对服务过程中出现的问题(如响应时间)能及时进行监督和控制。
实施HelpDesk系统后,主要的服务流程不会有大的改变,是否能借助系统进行在线实时工作,取决于信息录入和更新的方案。
有以下方案可供选择:
报修信息录入方案
报修信息录入应该及时才能做到在线工作,否则只能起到记录作用,不能进行实时的管理和控制。
方案编号
方案名称
方案具体说明
优点
缺点
1
业务用户在线提交
业务用户通过iSupport提交问题,同时发送email给服务商,服务商提供相应服务
及时、准确,问题描述清楚
1客户需要有利用系统的习惯;
2服务商需要查看email,否则需要打电话确认
2
服务商后台记录
向服务商开放后台使用权限,服务商象IT部门一样利用后台Support模块工作
1实时性好
2信息记录完全
3IT部门也可进行跟踪控制
1
向服务商开发权限,会降低系统安全性
3
信息部录入
规定业务部门不能与服务商直接联系,而与IT部门联系,由IT部门通过Email或电话方式与服务商联系进行问题处理,并将整个过程记录在系统中
能对整个过程进行有效控制和全面跟踪管理
1加大IT部门工作量
2效率会降低
4
服务商离线支持
维持目前流程不变,服务商一段时间提供服务报告(如一周或一个月),由IT部门负责录入系统
维持目前工作流程不变
1事后管理
2无法对处理过程进行控制监督
5
开发
为服务商开发Web页面,控制其权限,让其实时录入系统
1实时性好
2信息记录完全
3IT部门也可进行跟踪控制
1需要开发费用,系统成本增加
2版本升级问题
维修信息录入及更新
基于以上方案,如果采用开发或向服务商开放后台,服务商才可能及时更新维修信息,否则都将是事后录入的。
如果服务商无法参与到系统中,则服务的过程无法记录,只能记录结果。
较为理想的处理流程
以下是较为理想的处理流程
以上流程的优点是将客户、服务商、信息部结合在一起,可利用系统进行在线工作,并可记录详细的解决过程(包括部件更换的审批,更换配件信息等)
要实现以上流程,需要进行开发,为服务商提供工作平台,并需要各方配合,尤其是客户,如果客户不登录系统进行评价,也可采用原来书面的方式评价,由服务商录入系统。
服务信息报告
不管通过哪种方式,服务信息录入后,都可以开发相应的报表对外包服务商的工作情况进行统计分析和考核。
报表开发需求将在相应开发需求中详细说明。
知识库
知识库是服务系统非常由于的核心组件之一。
其基本介绍可见附件3。
知识库的建设必须注意在建立初期必须收集尽可能多的内容,否则,用户使用一次后,发现没有实际内容,就很可能会失去再次使用的兴趣。
因此,建议光明乳业借实施HelpDesk系统之机,要求将存在服务人员大脑中的知识来一次大清理,大搜集,号召大家将工作中解决的问题总结出来。
系统建立后,要注意经常不断地整理和总结
知识库建立
知识库包括技术资料库和解决方法两类。
技术资料库
根据光明乳业的实际情况,目前有以下相关文档
☐ERP用户操作手册
☐ERP业务流程
☐ERP设置手册
☐网络安全操作手册
因此,可将以上分类将相关文档放入技术资料库,系统上线后,相关文档积累越来越多,可设置并存放其它类别的文档。
解决方法
为兼顾用户搜索效率和尽可能得到相关的解决方案,解决方法的分类不可太粗,也不可太细。
根据光明乳业的实际情况,可将解决方法分为以下类别,其对应的Statement类型如下表:
解决方法类型
Statement类型
OracleERP/CRM技术
问题(必需)、原因、方法、模块、版本
网络技术
问题(必需)、原因、方法、平台、产品
系统安全
问题(必需)、原因、方法、平台
其它
问题(必需)、原因、方法
知识库的使用
根据知识库的信息分类,用户搜索知识库信息时,可以通过提交服务请求过程中或者直接输入关键字来进行搜索。
客户在利用iSupport提交请求时,可以设置系统根据客户提交问题的描述自动实施解决方法,客户也可自己通过关键字直接搜索相关的解决方法。
服务人员在解决问题的过程中,可以通过关键字搜索相应的解决方法,并且可以通过附注类型与知识库的集成直接将服务请求的解决方法增加到知识库,以不断丰富解决方法。
知识库的丰富
知识库内容的丰富可通过以下途径:
1根据经验和已有积累搜集相关的解决方法和文档
2典型服务请求的处理总结
3论坛问题归纳
网上论坛
iSupport论坛提供BBS功能,通过开放网上论坛,客户可以就感兴趣的问题进行探讨,还可以向服务人员提供iSupport帐号,这样他们也可以参与客户问题的讨论,提供解决方法,服务人员之间也可就有些问题进行讨论。
论坛可以通过定义用户组和论坛主题之间的关系,定义用户的访问权限。
建议光明乳业可以定义以下论坛主题,向全体iSupport用户开放。
☐OracleERP/CRM技术
☐网络技术
☐系统安全
☐其它
已解决和未解决的问题
已解决的问题
未解决的问题
外包服务管理录入方案、报表开发需求
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 光明 HelpDesk 实施方案