服务报告管理流程
服务报告管理是服务管理体系的一个部分，虽然服务报告的流程相对简单，但是服务报告的制作也是存在很多学问的。
和我们日常报告一样，我们的服务报告也彰显着一个人的逻辑思维和文字功底，总的说来服务报告应该注意三个部分：1、针对不同汇报对象制定对应的服务报告；2、要用数据说话；3、缜密的分析是报告的核心。 首先说一下服务报告的对象，一般来说我们都会认为有对内、对外的两个不同的服务报告，其实我们存在更多种的服务对象，其中包括客户领导、业务关系经理、自己公司领导、部门领导以及部门全员。那么这些汇报对象所关注的内容就有所不同，比如对方客户的领导关心的肯定是对业务的支持与支出，那么我们在制作报告的时候就应该简明扼要的给出客户想看到的内容，如果页数超过了3页将让读者失去兴趣。业务关系经理主管角色一般关注的是销售点以及可挖掘的新的服务，所以我们在制作报告的过程中应注重服务提高的部分。对于自己公司领导应描述目前所面临的问题以及可能出现的风险等以便得到公司层面的更大支持。发放给全员的服务报告应注重全面性，以便让部门人员对工作情况有所了解，如果有涉密部分还应该对不同权限级别人员分别制作服务报告。但是我这里说要说的是，其实服务报告只有一个，针对不同汇报对象制作的服务报告，仅仅是这个服务报告的剪裁以及变异，如果想做到这种剪裁与变异，那么一个好的提纲、摘要对我们就尤其重要了，所以要尽量全面考虑之后再制定服务报告的模板。 其次，我们都知道数据通常都是最有利的论据，具有很好的说服力，所以来自于系统的数据的选择就尤其重要。我们不可能平铺系统导出的所有数据，而是要有一个加工，这个加工的过程通常是要计算一定的比率以及分项的汇总，这样看起来更加直观，比起简单冰冷的数据展现更有价值。谈到这一点我们不得不讲一下KPI的选择，有些时候大家通常汇报涉及到的数据都放入指标池进而成为KPI，其实这样做通常是浪费了人力物力同时没有达到预想的想过。比如说，人力资源模块的KPI，如果我们把考勤情况作为KPI，而贵公司所有人员基本都不迟到，也就是说这是一个很容易达到的衡量指标，那就缺乏它的实际意义了，而是要把KPI放在关键点。就像庖丁解牛一样，一定要放在关键的位置，比如我们把刚刚人力资源模块KPI改为交接班准时率，或者其它可能更有价值。很有趣的是我们的教科书上通常都建议我们使用MTTF（平均失效时间），在我们的可用性衡量里面通常就是宕机时间，但是我们都知道Incident的定义是非计划内的服务中断与性能降低，MTTF只能计算中断却无法计算性能降低，所以具体使用什么样的衡量方法，还需要大家自己去斟酌。 最后，我们必须说再多的数据也只是一种直观的感觉，不管是喜是悲，下一步的分析和改进才能使这些数据派上用场，比如经过分析我们解决了一个Problem，由此将使我们的MTTF有所降低，这对于公司来说就是一个值得关注的有益点。或者是我们的知识库增加了多少应对Incident的方法；我们增加的虚拟机可以使我们业务流畅性有多少的提高；假如我们增加一条100M的带宽会带来……如此的内容的存在才是更适应服务需求的内容，所以从来不应该被忽视。 告别冗长单一的服务报告，让汇报对象能够快速清晰了解服务情况，才是阐述了服务质量，才是能够推进服务提高的必由之路。
和我们日常报告一样，我们的服务报告也彰显着一个人的逻辑思维和文字功底，总的说来服务报告应该注意三个部分：1、针对不同汇报对象制定对应的服务报告；2、要用数据说话；3、缜密的分析是报告的核心。 首先说一下服务报告的对象，一般来说我们都会认为有对内、对外的两个不同的服务报告，其实我们存在更多种的服务对象，其中包括客户领导、业务关系经理、自己公司领导、部门领导以及部门全员。那么这些汇报对象所关注的内容就有所不同，比如对方客户的领导关心的肯定是对业务的支持与支出，那么我们在制作报告的时候就应该简明扼要的给出客户想看到的内容，如果页数超过了3页将让读者失去兴趣。业务关系经理主管角色一般关注的是销售点以及可挖掘的新的服务，所以我们在制作报告的过程中应注重服务提高的部分。对于自己公司领导应描述目前所面临的问题以及可能出现的风险等以便得到公司层面的更大支持。发放给全员的服务报告应注重全面性，以便让部门人员对工作情况有所了解，如果有涉密部分还应该对不同权限级别人员分别制作服务报告。但是我这里说要说的是，其实服务报告只有一个，针对不同汇报对象制作的服务报告，仅仅是这个服务报告的剪裁以及变异，如果想做到这种剪裁与变异，那么一个好的提纲、摘要对我们就尤其重要了，所以要尽量全面考虑之后再制定服务报告的模板。 其次，我们都知道数据通常都是最有利的论据，具有很好的说服力，所以来自于系统的数据的选择就尤其重要。我们不可能平铺系统导出的所有数据，而是要有一个加工，这个加工的过程通常是要计算一定的比率以及分项的汇总，这样看起来更加直观，比起简单冰冷的数据展现更有价值。谈到这一点我们不得不讲一下KPI的选择，有些时候大家通常汇报涉及到的数据都放入指标池进而成为KPI，其实这样做通常是浪费了人力物力同时没有达到预想的想过。比如说，人力资源模块的KPI，如果我们把考勤情况作为KPI，而贵公司所有人员基本都不迟到，也就是说这是一个很容易达到的衡量指标，那就缺乏它的实际意义了，而是要把KPI放在关键点。就像庖丁解牛一样，一定要放在关键的位置，比如我们把刚刚人力资源模块KPI改为交接班准时率，或者其它可能更有价值。很有趣的是我们的教科书上通常都建议我们使用MTTF（平均失效时间），在我们的可用性衡量里面通常就是宕机时间，但是我们都知道Incident的定义是非计划内的服务中断与性能降低，MTTF只能计算中断却无法计算性能降低，所以具体使用什么样的衡量方法，还需要大家自己去斟酌。 最后，我们必须说再多的数据也只是一种直观的感觉，不管是喜是悲，下一步的分析和改进才能使这些数据派上用场，比如经过分析我们解决了一个Problem，由此将使我们的MTTF有所降低，这对于公司来说就是一个值得关注的有益点。或者是我们的知识库增加了多少应对Incident的方法；我们增加的虚拟机可以使我们业务流畅性有多少的提高；假如我们增加一条100M的带宽会带来……如此的内容的存在才是更适应服务需求的内容，所以从来不应该被忽视。 告别冗长单一的服务报告，让汇报对象能够快速清晰了解服务情况，才是阐述了服务质量，才是能够推进服务提高的必由之路。