Practice_Service request management 服务请求管理实践

返回ITIL4理论与实践整体知识体系中文版发布文件汇总
最新消息：本实践中文翻译发布版已经推出，请点击下载。

服务请求是用户查询的重要类型，也是用户体验的重要组成部分。通常，服务请求包括以下内容： ●发起服务动作的请求（由服务提供者执行或与用户一起执行） ●要求信息 ●访问资源或服务的请求 ●反馈，表扬或投诉。 满足服务请求可能包括对服务或其组件的更改；这些通常是标准的更改。由于服务的请求是预定义的，并且已预先同意作为服务交付的正常部分，因此通常可以使用清晰的标准发起，批准，实现和管理程序来对其进行形式化。某些服务请求具有非常简单的工作流，例如信息请求。其他服务请求（例如，新员工的设置）可能很复杂，需要许多团队和系统的帮助才能实现。无论复杂性如何，满足请求的步骤都应该众所周知并经过测试。这使服务提供者可以约定实现的时间，并向用户提供请求的状况的清晰通信。 开发和过程测试在生产和服务生命周期的相应阶段执行，涉及多种实践，例如业务分析，服务设计，风险管理，变更使能，服务目录管理和服务级别管理实践。 根据财务，信息安全或其他策略，某些服务请求需要授权。为了适当地处理此问题，服务请求管理实践应该遵循以下准则： ●服务请求及其实现应该尽可能标准化和自动化 ●应根据可以满足服务要求的情况建立政策，而有限或无其他批准可以简化实现 ●用户对实现时间的期望应根据组织可以提供的内容明确设定 ●应确定并实施改进点的机会，以产生更快的实现时间并利用自动化 ●应该包含策略和工作流，以记录和重定向作为服务请求提交的任何请求，但应将其作为事件或更改进行管理。 从提交到关闭，某些服务请求可以完全通过自动化来实现，从而实现完整的服务体验。例如，安装客户软件或提供虚拟服务器。 2.2术语和概念 服务请求的主要特征包括： ●它由用户或用户代表启动。 ●它需要服务提供者中的性能或绩效。 ●这是一个性能或绩效，它已同意服务成果。这意味着服务成果已经过测试，预先批准了针对该请求的批准流动和实现流动，对人员进行了培训，并设置了服务组件来实现此要求。 服务请求是服务交付的正常部分，即'日常业务'。这意味着服务提供者的客户，用户和运维团队会很好地理解结果和时间表，并且这些结果和时间表通常是可以预测的。只要有可能，服务的请求都应该自动进行处理，并通过用户有效且方便的渠道（例如客户门户）进行访问。 服务请求在服务质量和服务体验中可能扮演不同的角色。在许多情况下，当服务动作是服务交互的一种关键形式时，它们就有助于服务功用。在某些情况下，服务请求可以增加到更高的服务级别，从而为标准化的服务产品增加有价值的选择。最后，可以使用服务请求来启动服务组件的维护，其中服务提供者的监控和事态管理能力受到限制，而服务组件的监控被委托给用户。 请注意，服务请求是用户查询的一种形式，也是一种初始化对服务体验有意义的预定义活动的方式。相同的活动可以以不同的方式启动，尽管技术操作可能相同，但用户体验中的角色可能不同，如表2.1所示。 表2.1与其他实践指南中描述的服务请求实践相关的活动 例 实现价值 实践指南 用户监视打印机的状况。当打印机提示“碳粉不足”时，用户要求重新填充碳粉。服务提供者的技术人员更换了碳粉盒。除了更换的规程，打印不打断了。 服务请求服务台 服务请求管理 基础设施和平台管理 打印机将其状况和事件传达给操作团队。当发生“碳粉不足”的事态时，服务提供者的技术人员将更换碳粉盒。除了更换的规程，打印不打断了。 事态监控和事态管理 基础设施和平台管理 如果上述场景中出现问题，请执行以下操作。没有及时报告“碳粉不足”状况（或未及时更换碳粉盒或未正确更换碳粉盒）。打印中断。用户将报告的情况发送到服务提供者。服务提供者的技术人员取代了碳粉盒。打印为恢复。 事件服务台 事件管理 基础设施和平台管理 同样，服务请求可以发起更改，通常是标准更改，但有时可以是一般变更。对变更的需求由公司采用的变更类型定义。服务请求和更改之间存在强制性的“关联。例如， 服务请求可以管理员工从办公室的一张桌子转移到另一张桌子。需求是变更还是多项更改，取决于技术上的影响和准则是否同意组织（作为变更使能实践的一部分）中的更改。某些此类的服务请求可能需要一个或多个更改。无需变更使能实践即可完成其他任务。 服务请求的生命周期始终涉及多种实践。满足服务请求的典型价值流可能涉及： ●服务台：对流程进行用户查询 ●服务请求管理：路由和指导请求履行 ●基础设施和平台管理：执行必要的技术操作 ●发布管理：使服务组件对用户可用 ●变更使能：协调必要的更改 ●信息安全管理：提供或更改访问。 如果需要，可以涉及其他实践。服务请求型号中记录了用于实现每种服务请求类型的参与度和规程。 服务请求模型通常在生产和服务设计期间生产。测试了这些模型并将其与服务的其他组件一起部署到操作中。服务请求管理实践在所有阶段都参与其中，以确保模型是现实的，并被参与其管理和执行的每个人所接受。产品和服务的持续改进可能包括相关服务请求型号的改进点。 服务请求模型描述了服务请求履行的条件和过程，涵盖了所有服务管理四维模型： ●程序和工作流，包括可能的选项和决定 ●负责的角色和团队（通常是RACI职能矩阵矩阵型） ●自动化和使用的工具 ●参与并支持协议的第三方。 由于服务请求是由用户或其代表发起的，因此它们应该以方便，可操作的方式提供给用户。最常见的方法是在面向组织的服务目录的面向用户的视图中包括可用的服务请求。目录的管理位于服务目录管理实践的范围中，但有关信息由服务请求管理实践提供。 通常，可以通过请求目录获得有关可用服务请求的以下信息： ●服务请求所属的服务 ●服务请求邀请的先决条件/条件 ●发起请求所需的信息 ●批准工作流程（如果适用） ●目标实现时间 ●其他相关信息。 服务请求目录视图应针对适用于访问该视图的用户的服务级别协议（SLA）进行量身定制，因此所有信息均反映了用户同意的条件和目标。请求目录中的信息越相关，服务请求履行的效率越高，用户满意度越高。 Servicerequestsareanimportanttypeofuserqueryandanimportantpartoftheuserexperience.Typically,servicerequestsincludethefollowing: ●arequestinitiatingaserviceaction(performedbytheserviceproviderorjointlywiththeuser) ●arequestforinformation ●arequestforaccesstoaresourceorservice ●feedback,compliments,orcomplaints. Fulfillingservicerequestsmayincludechangestoservicesortheircomponents;theseareusuallystandardchanges.Asservicerequestsarepredefinedandpre-agreedasanormalpartofservicedelivery,theycanusuallybeformalizedwithaclear,standardproceduresforinitiation,approval,fulfilment,andmanagement.Someservicerequestshaveverysimpleworkflows,suchasarequestforinformation.Otherservicerequests,suchasthesetupofanewemployee,maybecomplexandrequirecontributionsfrommanyteamsandsystemsinorderforittobefulfilled.Regardlessofthecomplexity,thestepstofulfiltherequestshouldbewell-knownandtested.Thisallowstheserviceprovidertoagreetimesforfulfilmentandprovideclearcommunicationofthestatusoftherequesttousers. Thedevelopmentandtestingoftheproceduresareperformedattherespectivestagesoftheproductandservicelifecycleandinvolvemultiplepractices,suchasthebusinessanalysis,servicedesign,riskmanagement,changeenablement,servicecataloguemanagement,andservicelevelmanagementpractices,amongothers. Someservicerequestsrequireauthorization,accordingtofinancial,informationsecurity,orotherpolicies.Inordertohandlethisappropriately,theservicerequestmanagementpracticeshouldfollowtheseguidelines: ●servicerequestsandtheirfulfilmentshouldbestandardizedandautomatedasfaraspossible ●policiesshouldbeestablisheddependingonwhichservicerequestscanbefulfilledwithlimitedornoadditionalapprovalstostreamlinefulfilment ●userexpectationsregardingfulfilmenttimesshouldbeclearlysetbasedonwhattheorganizationcandeliver ●opportunitiesforimprovementshouldbeidentifiedandimplementedtoproducefasterfulfilmenttimesandleverageautomation ●policiesandworkflowsshouldbeincludedfordocumentingandredirectinganyrequeststhataresubmittedasservicerequests,butwhichshouldbemanagedasincidentsorchanges. Someservicerequestscanbecompletelyfulfilledbyautomation,fromsubmissiontoclosure,allowingforacompleteself-serviceexperience.Forexample,clientsoftwareinstallationortheprovisionofvirtualservers. 2.2TERMSANDCONCEPTS Themaincharacteristicsofaservicerequestincludesthefollowing: ●Itisinitiatedbyauserorauserrepresentative. ●Itrequiresanactionfromtheserviceprovider. ●Itisanactionthathasanagreeduponserviceoutcome.Thismeanstheserviceoutcomewastestedinadvance,theapprovalflowandfulfilmentflowfortherequestwerepre-approved,peopleweretrained,andservicecomponentsweresetuptofulfilit. Aservicerequestisanormalpartofservicedelivery,whichis‘businessasusual’.Thismeanstheresultsandthetimelinesarewellunderstoodbythecustomer,users,andoperationteamsoftheserviceprovider,andareusuallypredictable.Whereverpossible,servicerequestsshouldbeautomatedandaccessiblethroughchannelsthatareefficientandconvenientforusers,suchasaclientportal. Servicerequestsmayplaydifferentroleswithinservicequalityandserviceexperience.Inmanycases,theycontributetoserviceutilitywhenserviceactionsareakeyformofserviceinteraction.Insomecases,servicerequestscanaddtohigherservicelevels,addingvaluableoptionstootherwisestandardizedserviceofferings.Finally,servicerequestsmaybeusedtoinitiatethemaintenanceofservicecomponents,wheretheserviceprovider’smonitoringandeventmanagementcapabilityislimitedandthemonitoringofservicecomponentsisdelegatedtousers. Notethatservicerequestsareaformofuserqueryandawaytoinitiatecertainpredefinedactivitiessignificanttoserviceexperience.Thesameactivitiesmaybeinitiateddifferently,andalthoughtechnicaloperationsmaybeidentical,theirroleintheuserexperiencewouldbedifferent,asshowninTable2.1. Table2.1Activitiesrelatedtotheservicerequestpracticedescribedinotherpracticeguides Example Activity Practiceguide Ausermonitorsstatusofaprinter.Whentheprintersignals‘lowtoner’,theuserrequeststonerrefill.Theserviceprovider’stechnicianreplacesthetonercartridge.Exceptforthereplacementprocedure,printingisnot interrupted. ServicerequestServicedesk Servicerequestmanagement Infrastructureandplatformmanagement Aprintercommunicatesitsstatusandeventstotheoperationsteam.Whena‘lowtoner’eventoccurs,theserviceprovider’stechnicianreplacesthetonercartridge.Exceptforthereplacementprocedure,printingisnot interrupted.EventMonitoringandeventmanagement Infrastructureandplatformmanagement Inthecaseofsomethinggoingwrongintheabovescenarios.The‘lowtoner’statusisnotreportedintime(orthecartridgeisnotreplacedintimeorreplacedincorrectly).Theprintingisinterrupted.Usersreportthesituationtotheserviceprovider.Theserviceprovider’stechnicianreplacesthe tonercartridge.Printingisrestored.IncidentServicedesk Incidentmanagement Infrastructureandplatformmanagement Similarly,servicerequestsmayinitiatechanges,whichareusuallystandardchangesbutcansometimesbeanormalchange.Theneedforchangeisdefinedbythechangetypologyadoptedbythecompany;thereismandatory'correlationbetweenservicerequestsandchanges.Forexample, movinganemployeefromonedesktoanotherwithintheofficeislikelytobemanagedasaservicerequest;whetheritneedsachangeormultiplechanges,dependsontechnicalimpactofthemoveandcriteriaforchangesagreedintheorganization(aspartofthechangeenablementpractice).Someservicerequestsofthistypemayneedoneormorechanges;otherswouldbefulfilledwithoutthechangeenablementpracticeinvolved. Thelifecycleofaservicerequestalwaysinvolvesmultiplepractices.Atypicalvaluestreamtofulfilaservicerequestislikelytoinvolve: ●servicedesk:toprocesstheuserquery ●servicerequestmanagement:torouteandguidetherequestfulfilment ●infrastructureandplatformmanagement:toperformthenecessarytechnicaloperations ●releasemanagement:tomaketheservicecomponentsavailabletousers ●changeenablement:tocoordinatethenecessarychanges ●informationsecuritymanagement:toprovideoralteraccess. Otherpracticesmaybeinvolved,asneeded.Theinvolvementandprocedureforfulfillingeverytypeofservicerequestisdocumentedintheservicerequestmodels. Servicerequestmodelsareusuallyproducedduringproductandservicedesign.Themodelsaretestedanddeployedtooperationsalongwithothercomponentsoftheservice.Theservicerequestmanagementpracticeisinvolvedatallstagestoensurethatthemodelsarerealisticandacceptedbyeveryoneinvolvedintheirmanagementandexecution.Thecontinualimprovementofproductsandservicesmayincludetheimprovementoftherelatedservicerequestmodels. Servicerequestmodelsdescribetheconditionsandproceduresforservicerequestfulfilment,coveringallfourdimensionsofservicemanagement: ●proceduresandworkflows,includingpossibleoptionsanddecisions ●rolesandteamsresponsible(usuallyasaRACImatrix) ●automationandtoolsused ●thirdpartiesinvolvedinandsupportingagreements. Asservicerequestsareinitiatedbyusersortheirrepresentatives,theyshouldbeavailabletousersinaconvenientandactionableway.Themostcommonapproachistoincludetheavailableservicerequestsinuser-facingviewsoftheorganization’sservicecatalogue.Managementofthecatalogueiswithinthescopeoftheservicecataloguemanagementpractice,butinformationforitisprovidedbytheservicerequestmanagementpractice. Usually,thefollowinginformationabouttheavailableservicerequestsisavailablethrougharequestcatalogue: ●servicetowhichaservicerequestbelongs ●prerequisites/conditionsforaservicerequestinvitation ●informationrequiredtoinitiatetherequest ●approvalworkflow,ifapplicable ●targetfulfilmenttime ●otherrelevantinformation. Theservicerequestcatalogueviewisexpectedtobetailoredforservicelevelagreements(SLAs)thatareapplicabletotheuseraccessingtheview,sothatalloftheinformationreflectstheconditionsandtargetsagreedfortheuser.Themorerelevanttheinformationintherequestcatalogueis,themoreefficienttheservicerequestfulfilmentwillbe,andthehighertheusersatisfaction. 申明： 本文档由长河（微信achotsao）在机译的基础上经初步整理而成，精细化翻译工作正由IT运维管理社区组织的ITIL专家团队进行之中，预计将于2020年年底之前全部完成。需要下载最终翻译版本请关注微信公众号：IT运维管理社区，或访问or。
IT运维管理社区专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含中文翻译版本）时需完全遵守Axoles和TSO所申明的所有版权要求。