光明乳业实施方案

MD020

上海光明乳业股份有限公司

OracleiSupport/Support

实行方案

文档作者：Ilandconsultants

创建日期:2023-07-19

确认H期：2023-07-23

控制编码：BD/MD020/IBU

当前版本：1.0

审批签字：

光明项目经理

汉得项目经理

文档控制

更改记录

日期作者版本更改参考

2023-07-19吴联银1.0

审阅

姓名职位签字

Allen,wuPM

分发人员

编码姓名地点和位置署名

1

2

3

4

目录

文档控制...................................................................ii

文档说明...................................................................5

文档简介...............................................................5

有关名词...............................................................5

参考文档...............................................................5

方案概述...................................................................6

系统功能概览...........................................................7

系统的建立与权限控制.....................................................10

系统的建立............................................................10

服务请求基础..............................................................12

服务请求的基本要素....................................................14

服务请求的记录........................................................16

服务请求负责人与流程.....................................................18

服务请求的负责人分派..................................................19

服务请求流程..........................................................20

外包服务管理..............................................................24

服务信息记录..........................................................24

服务信息录入..........................................................26

服务信息报告..........................................................29

知识库....................................................................30

知识库建立............................................................30

网上论坛..................................................................32

已解决和未解决的问题.....................................................33

已解决的问题..........................................................33

未解决的问题..........................................................33

附件1业务用户责任设立..................................................34

附件2服务人员责任设立..................................................36

附件2知识库基础.........................................

文档说明

文档简介

该文档为上海光明乳业股份有限公司(以下简称光明乳业)HelpDesk(Oracle

iSupport/Support)的具体方案实行文档。

OracleiSupport/Support模块的功能能较好地满足光明乳业的业务需求,本文档将对

光明乳业的业务需求和系统功能匹配进行具体描述。

该文档的内容涉及到光明乳业在IT服务方面的重要内容和关键流程。

有关名词

本文中使用的有关名词，作出如下限定：

”的3务与e.拓比明八*的/务用户,使用石叱士

**入£：&>XDKB另人员,>戊3》ft理AH、*户代

K.■决告限人员彳取同事务强,1»■暂&・并讦期rmtitt行设

7八惶:m朴尤弘饴人

参考文档

参考文档:ITHelpProposalSolution.doc

方案概述

»•*：<•<•，-H.-plS-l<->L，'；：Or»”

iS^piC/Suppcrl京N构鼠.

i、，，l，f〈”•「，・'•,1•

方，・&»魂味场四出单道量蛆&蚪务请a的■决记

"、tembvX・均”HM*t不入—■owdt*wtJl

MU.1:tw.t.s

口qgf0&R«4.；Atr4«61«KHIfJ0Jir.<1X.fl

■・ig%.rKCUt用2管Mrtt・__________________

系统功能概览

iSupport功能概览

本方案将使用iSupport以下功能:

服务请求管理

•可在任何时候在线提交或修改服务请求

•在需求提交之前,有选择地增强知识管理搜索

•可查看服务请求解决过程和进行交互

•可自定义搜索和显示条件搜索服先请求

知识管理

•基于搜索功能的直观语句

•使用解决方案关系的基本与高级搜索特性,用来匹配已知的解决方案集

•搜索与进一步访问在线参考材料

个性化主页

•便于客户进行定制的灵活主页

•可以给所有用户发送的事前告知

交互式在线论坛

•交互式讨论论坛

搜索主题及浏览论坛

Support功能概览

本方案将使用Support以卜功能

服务请求管理

•多渠道服务请求管理:涉及呼喊中心（电话）、电子邮件和网络

•直接创建或修改服务请求

•可查看服务请求解决过程和与iSupport用户进行交互

•可自定义搜索和显示条件搜索服芳请求

•进行服务请求负责人分派

任务管理

•直接创建和分派任务

•任务完毕情况报告

资源管理

•创建和导入资源

•资源组织结构定义

•资源职责类型定义和职责分派

知识管理

•基于搜索功能的直观语句

•使用解决方案关系的基本与高级搜索特性,用来匹配已知的解决方案集

运用服务请求和知识库的集成,不断增长新知识到知识库中

UWQ查看

•直接查看用户自己、所属组、所属小组的负责的服务请求和任务

•可自定义参看方式

双击可查看具体信息

全面集成

•通过全面集成Oracle电子商务套件应用来增强功能

□本方案将着重介绍以卜内容：

□系统的建立与权限控制

□服务请求管理

□知识库

□论坛

□外包服务

系统的建立与权限控制

系统的建立

模块的应用

□在光明乳牝为保证iSupport/Support正常实行，除了相关的ERP模块（如财务、

人事、库存等）外，以下模块必须设立并使用：

□OracleiSupport:iSupport相关设立及权限管理

□MES（市场百科全书）：重要是iSupport主页内容和技术资料库设立

□CRMFoundation:资源、任务、附注等定义

OracleSupport:服务请求、知识库等相关设立

责任的设立

□根据光明乳业HelpDesk的业务需求，在iSupport应用（称为前台应用）中，设立

两种责任：

iSuppart系统管理员：用于维护客户晋录iSupport时的内容及审核，并提交系统管理员

设立用户，分派责•任

□光明乳业iSupport内部业务用户:具有基本的iSupport使用功能，涉及:主页、支

持、论坛页面

□在Support应用（称为后台应用）中，也分两种责任：

光明乳业客户服务管理员：具有所有的客户服务代表权限,并可对Support模块进行相

应的设立

光明乳业客户服务代表：普通客户服务人员使用的工作平台,可创建和查看服务请求，

以及进行服务请求的解决等

用户管理及责任设定

使用iSupport/Support的用户，需要系统管理员在系统中设立,并分派相应职责。

客户（业务用户）管理

按OracleiSupport/Support设计逻辑,抱负的方式是为公司类别员工分派一个帐号，以

公司内部员工的身份使用日系统。为每个员工分派帐号还可记录该员工的联系方式，如

email,电话等。但这样做的信息录入工作量非常大，考虑到光明乳业已经实行人力资源

管理，假如在这套系统中反复录入这些信息,是没有必要的。因此建议,为每个业务部门

分派一个统一的帐号,分派光明乳业iSupport内部业务用户责任，使用iSupport系统。

ERP系统升级后,可将HelpDcsk系统与ERP系统合并,再为每个具体的业务用户分派

相应的责任。

由于业务部门用户为公司内部用户，定义为员工类型，即将部门看作单个的员工解决，姓

氏为事业部名称，名字为下属部门名称，可认为它们设定默认的联系方式（电话、

email）z假如实际联系方式与默认方式不同，可以在附注中进行说明。

服务人员用户管理

光明乳业的服务人员，分派后端Support相应的服务代表和管理员责任。

系统上线初期，设立用户的用户名、密码及责任,见附件1,附件2

系统上线后,用户的增长、注销和权限变更都需要系统管理员进行统一维护,光明

乳业必须制定相应的权限管理规范，以保证系统使用的安全性。

服务请求基础

仁.仲AZiXE爱家的M凰疝H务的尬年划R.iH034AHSO*

足n<«务力次ZM.

兄TJUiq以根更《统中0人悌灯总定用还包送分W及4*善长

服务请求的基本要素

服务请求的类别

对服髡请求进行分类,可以区别不同业务来管理。不同类别的服务请求,可以定义不同

的状态，以驱动不同的服务请求解决流程。不同类别的服务请求，可以可不同的工作流

(Workflow)相联系,这种工作流,可以通过系统自身在服务请求创建时触发，也可人

为地在后端系统触发。

□根据对光明乳业服务业务的综合归纳，可以将服务请求分为以下几种类别：

□客户投诉

□培训、办公、行政、联络

□电脑配件维修

□外包供应商服务跟踪

□台式机采购

□便携机采购

□打印机采购

□其它采购

□邮件帐号申请

□网络帐号申请

□网络存储

□网络技术支持

□系统安全支持

□病毒防治

□PC安全支持

□公用技术支持

□战略项目支持

□ERP系统性能支持

□ERP软件支持

□ERP服务器采购

□OSA支持

□OFA支持

□物流项目

□PDA支持

□SCM支持

□网上牧场

□一般故障问题

□系统报表数据问题

□系统报表开发问题

系统流程更改问题服务请求的状态

服务请求的状态必须预先拟定，以便对不同类别的服务请求指定不同的状态，以便监测

请求执行的情况。

□建议将服务请求分为以下几种状态：

□打开（Open）:服务请求提交时的初始状态

□已分派（Assigned）:服务请求已经指定负责人负责解决

□解决中（Ongoing）:服务请求正在解决之中

□已完毕（Finished）:服务请求己经完毕

□用户取消请求（UserCancelled）：用户认为服务请求服务请求已无必要继续解

决,请求取消，负责人无需再继续解决

□和谐关闭（SoftQose）:获得客户认可后关闭

强行关闭(HardClose):未能获得客户完全认可，但问题已经解决

关联的这些状态,可以被跳过,但都必须有打开和关闭两种状态。系统默认的状态为创

建时的状态,即打开。

服务请求的负责人

服务请求的负责人表白该服务请求需要由谁负责进行解决。系统中负责人可认为三种

资源类型,即:员工资源(EmployeeResource)组资源(GroupResource)、小组

资源(TeamResource),服务请求负责人设定及解决流程见下节。

紧急限度与重要性

紧急限度(urgency)是从客户的角度对服务请求的感觉。建议设定三种层次:高、

中、低。

三”屁为扁.中.U.

对十造”金Mm以化,用小'”玲，普色•愀以尼W限使把n耽8H存"，号

服务请求的记录

服务请求的提交

□服务请求有两种提交方式：

□客户直接在网上提交。

客户通过电话或传真形式告知光明乳业的服务人员，由服务人员在后端系统，即Oracle

Support中记录。

两种形式提交的服务请求都会存放在系统中,并在同一个界面可以查询到。

在系统的使用过程中，建议尽量培养客户网上提交请求的习惯。这样的好处是：在网上

由客户直接输入，可以比较清楚地表达客户问题；减少服务人员地工作量；用户也可以

通过搜索知识库自己解决问题；并且网上信息可以供各业务部门共享,避免反复。

服务请求回应记录

通过两种形式提交的服务请求,在解决过程中的每•个环节,都必须有解决人的记录，以

保证信息的完整性。更重要的是,可以使客户及时了解到请求的解决状态。

系统中提供了“附注”的文本记录工具供客户和服务人员使用，使他们可以进行实时的

互动交流。

在请求完毕后,假如客户可以确认请求结束,则由客户关闭请求；在实际情况中,客户也

许由于种种因素,不能及时关闭请求,服务人员必须根据请求解决的实际情况,将状态更

改为“关闭”。

请求是否及时关闭,在一定限度上表白解决客户请求的效率和质量。因此,或者由客户，

或者由服务人员，及时关闭请求。

系统日记

系统会根据服务请求的变更情况自动生成相应的日记文献，日记文献记录了该请求

没次变更的时间、更新用户及相关内容。管理人员从日记文献能具体地了解服务

请求解决的过程。

服务请求负责人与流程

服务请求的负责人分派

请求负责人的指定

客户在网上提交的请求,系统中可以设定默认的负责人,建议设为HelpDesk管理员，由

他根据服务请求的类别和客户所属单位进行二次分派。对于客户打电话提交服务请求

的情况,服务人员可以根据服务请求的类别和客户所属单位直接指定负责人,假如服务

人员不清楚有谁解决,可将服务请求负责人设为默认负责人（不需修改,为客户服务管

理员）o

不管哪种情况，服务请求指定明确的负责人后，都需要将状态从“打开”改为“已分

派”，表白该请求已分派给相应的人员负责解决。

负责人（服务人员）的组织

根据光明乳业的实际业务情况，特

别是实行ERP支持服务客户代表

政策以后，需要根据客户所属单位

指定相应的客户代表组负责解决和

应的服务请求。客户代表组成员解

决相应的服务请求或再指定具体人

员负责。ERP平常业务问题和

ERP月底结帐问题需要设定的客户

代表组分别为：

组名成员

总部客户服务组钱文强

物流事业部客户服务组孔暹

保鲜事业部客户服务组曹彦/周静/易晖

常温事业部客户服务组许沛明

瓶袋事业部客户服务组黄伟/梅黎/宓云峰

上海达能客户服务组曹彦/周静/易晖

工业原料事业部客户服务组黄伟/梅黎/宓云峰

黄油干酪事业部客户服务组黄伟/梅黎/宓云峰

奶粉事业部客户服务组许沛明

奶牛事业部客户服务组齐莉莉/王巍

全国地区客户服务组曹彦/周静/易晖/黄伟/梅黎/宓云峰

上表只是表白光明乳业的业务运营实际情况,系统中并不作硬性设定,即客户提出相关服务请求

时，可以按以上规则指定相应的客户服务组负责解决相关的服务请求,也可指定其他组,甚至个人

负责解决。这样可以保证在全公司范围内协调资源,也可保持充足的柔性。

服务请求流程

根据光明乳业的业务实际情况,不同类别的服务请求解决流程大体是相同的,不再进行细分,根据此定义的相关状态

的转换序列也不做硬性设定，以反映光明乳业实际业务情况。

光明乳业ITHelpDesk业务处理流程

服务请求提交;服务请求分配;服务请求处理〉服务请求关叫>服务请求评价2

业务人员置及

iSuppor:提交91务语求

岷:务用户认为

Y4

L搜索如惘库|

,

一业务用户关闭服务请，

靖

玄业务用户通过iSup>ort或电

话等其他联系方式与IT部相关

掇

------人房进行交互

¥

（结束）

Y

业务人员打电话给【T篱6M人通过UWQft而到业关闭请求时.要求

IT9J门提交服务请求分视门服务请求业务用户对技术人

fe以眼务送行评价

烬提AY业务川户关

*技术人员任务无法完成,或用服务谙求成强

S搜冬知识昨

8客户要求升级或系统自动升行K组眼务诂求

1破.例责人进行升级或收到

根树请求类别或忖质招极务请升级通知.采取相应行动

君求分配给相关人员处理.成齐

工解决否将典中网咫.id

创建任务并分配给描美人从系永迤知识坤

希统发送通知治相关人员

二

匕束

归1相关人员通过系统通知或UWQ知

<1.道分配给自己的的IH务谛和任

1

<务，并完成相关任务

1

惬1]

1

就

1

二1将任务完成过程记元入系统.

1井关网任务

1

1

1

裳1

1

加

1部门及理收到升级迪知,刚建•U弟系统记玳

翕1新的任务分配给共他人员处理进行评价

二1

1如上图所示,业务解决过程大体分为服务请求提交、服务请求分派、服务请求解

决、服务请求关闭、服务请求评价五个阶段。

2服务请求提交

3提供两种服务请求提交方式,业务部门人员可以登录iSupport通过web方式提交，

也可直接打电话给IT部支持电话，由相关负责人代客户提交提交。提交过程中都可

以搜索知识库帮助解决问题,假如问题解决,即可结束。

4服务请求分派

5对于通过知识库帮助和HelpDesk负责人自己无法解决的问题,可将该服务请求分

派给相关服务组或人员解决,或者根据服务请求，也可创建相应的任务分派给相关人

员解决。

6服务请求解决

7分派服务请求和任务后,相关人员从UWQ将能看到自己或所属服务组负责的服务

请求和任务,进行服务请求解决。在服务请求解决过程中，可通过状态变化描述不同

的解决阶段，运用附注与客户进行交互和相关服务记录。

8假如服务请求较复杂，可定义相关的任务，任务能具体说明内容、完毕时间等相关信

息,对于有关联的多个任务，系统还能定义其关系。服务人员收到任务后,即可去完

毕任务,完毕过程中可运用系统与提出服务请求的业务用户进行互动交流。完毕任

务后,将具体信息记录进系统,并关闭任务。

9服务请求关闭

10假如业务用户对问题解决认可,可关闭服务请求，如业务用户对解决方案长期不应答,

则可告知其关闭请求,如仍不响应,则可强行关闭。关闭服务请求时,假如该服务请

求具有代表性,需要将解决方法共享,可将该服务请求的解决方法归纳总结,录入知

识库系统，以便日后碰到类似问题时,可参考相应的解决方案！

11服务请求评价

关闭请求时,可规定用户对IT人员的服务进行评价,部门经理也可根据服务记录进

行评价。

采购服务管理

以上服务请求的描述和解决流程比较符合光明乳业内部负责服务请求（如ERP技术支

持、ERP平常业务等）的管理需求。对于采购服务和外包服务管理.，由于其特殊性，需

要进行说明和特殊解决。

1光明乳业IT部门负责的IT设备采购、软硬件系统和设备的技术支持和维护等工作

的具体执行有相关的IT外包服务商提供,IT部门只负责执行过程的监督和异常情

况的解决。目前,光明乳业IT设备的采购有两种方式，即

2业务部门直接采购，如台式机、网络设备、消耗品等

业务部门提出采购需求，相关部门审批、IT设备代为采购，如笔记本、服务器等

不管哪种采购方式,具体的审批和采购流程由ERP的采购模块管理,采购物品的记录也

根据采购模块开发的报表来完毕。

□HelpDesk系统只需记录第二类采购事件。系统定义了采购类服务请求，如：

□台式机采购

□便携机采购

□打印机采购

□其它采购

□具体的采购信息描述在请求汇总字段中,假如需要更加具体的信息,可用附注记录,

可设立“采购具体说明”类附注。

□为更加贴切的描述采购事件,可以定义不同于普通服务请求的状态,如可定义以下

状态描述采购类服务请求。

□打开

□已审批

□采购中

□用户已收到采购品

□关闭

外包服务管理

外包服务管理的目的是希望将外包给服务商的服务内容实时记录到系统中,进行监督、管理和考

核。

服务信息记录

外包服务服务信息说明记录字段

信息的记

录分为报

修信息、

维修信

息、记录

信息。系

统中没有

完全相应

的字段来

记录这些

信息。因

此,需要选

择恰当的

字段来记

录这些信

息。

信息类别

服务编号服务请求编号(Request

No)

事业部姓氏

报修部门名字

报修人弹性域

报

修地址默认地址、附注或弹性域

信

息电话默认电话、附注或弹性域

报修日期和时间Createby/强性域

故障描述汇总(Summary)

重要限度重要限度(Severity)

紧急限度紧急限度(Ugency)

负责人外包服务商名称负责人(Owner)

解决状态(完毕否)状态(Status)

工程师弹性域

维修理日期和时间Respondby

修故障情况故障因素附注

信

息其它说明未完毕因素及其附注

它说明

结束日期和时间Resolutionby

客户评价好、中、差附注

汨是信息等待用时

修理用时

全程用时

报修信息

报修信息大多可以服务请求的标准字段记录,唯一例外的是联系人信息。

由于为每个事业部的相应部门分派统一帐号,并将事业部作为公司员T看待,因此将事

业部用员工姓氏记录、部门用名字记录,可为他们定义默认的地址、联系电话和email,

至于联系人可以用附注记录，假如联系方式与默认值不符,也可用弹性域（或附注）来

记录。

用姓氏和名字记录事业部和相应部门,可方便进行记录。

服务请求的创建时间自身可理解为报修时间，但由于也许不是在线工作，属于事后录入,

但服务请求创建时间是不可更改的,因此需要记录在弹性域中。

维修信息

维修信息中说明信息（如故障因素、其它说明）用附注记录，时间信息用服务请求标准

字段记录。解决状态为标准字段，其它用弹性域记录。

记录信息

记录信息,不在系统中记录,可开发报表,通过计算得到用时记录信息。

弹性域设立

因此,字段名称类型说明

针对外

包服

务,需

要启用

弹性

域,如

下表：

编号

1报修人文本

2地址文本

3电话数字

4报修R期时间标准R期时间

5工程师文本

6客户评价值集好、中、差

外包服务解决流程及信息录入

外包服务解决流程

外包服务现在的解决流程如下图所示。从流程图可以看出，信息部只负责特殊情况的解

决和最后的记录考核工作.对具体的服务过程（特别是一般服务）只能事后监督，这并

不是一种合适的管理方式，应当尽量做到事中，对服务过程中出现的问题（如响应时

间）能及时进行监督和控制。

服务商向信息部提

交每月服务报告

实行HelpDesk系统后,重要的服务流程不会有大的改变,是否能借助系统进行在线实

时工作，取决于信息录入和更新的方案。有以下方案可供选择：

报修信息录入方案

报修信息录方案名称方案具体说明优点缺陷

入应当及时

才干做到在

线工作,否则

只能起到记

录作用,不能

进行实时的

管理和控

制。

方案编号

业务用户业务用户通过iSupport提交问题，同时及时、准确，问题描1客户需要有运用

在线提交发送email给服务商，服务商提供相应服述清楚系统的习惯；

务2服务商需要查看

email,否则需要打

1

电话确认

2服务商需要查看

即值」，否则需要打

电话确认

服务商后向服务商开放后分使用权限，服务商象1实时性好向服务商开发权限，

台记录IT部门司样运用后台Support模块工作2信息记录完全会减少系统安全性

231T部门也可进行

跟踪控制

信息部录规定业务部门不能与服务商直接联系，能对整个过程进行1加大IT部门工作

入而与IT部门联系，由IT部门通过Email有效控制和全面跟踪量

3或电话方式与服务商联系进行问题解决，管理2效率会减少

并将整个过程记录在系统中

服务商离维持目前流程不变，服务商一段时间提供维持目前工作流程不1事后管理

线支持服务报告（如一周或一个月），由IT部变

2无法对解决过程进

4门负责录入系统

行控制监督

开发为服务商开发Web页面，控制其权限，止1实时性好1需要开发费用，系

其实时录入系统2信息记录完全统成本增长

5

3IT部门也可进行2版本升级问题

跟踪控制

维修信息录入及更新

基于以上方案,假如采用开发或向服务商开放后台，服务商才也许及时更新维修信息,否

则都将是事后录入的。

假如服务商无法参与到系统中,则服务的过程无法记录,只能记录结果。

较为抱负的解决流程

以下是较为抱负的解决流程

业务用户通过业务用户打电话

iSupport提交服务请服务商，服务商

求记录服务请求

外包服务商接接

收请求派工程师

否一।

处理问题，并更

新请求处理状态

请求信息部批

准，并通过附注

记录到系统中

工程师在线或上

门服务

是

否

＜提否需更换部件

T