说说“系统慢”和“理赔难”

就爱抬杠

“系统慢”是（保险公司内部）IT中的运维问题，“理赔难”是保险中的理赔问题。说起这二者的关系，大部分人都会认为很简单，“系统慢”也是“理赔难”的原因之一，难道还有什么其他关系吗？其实，“理赔难”的问题肯定不是理赔自身能够彻底解决的，涉及到的环节至少还会包括产品开发、承保乃至IT；同样，“系统慢”的问题也不是运维能够彻底解决的，也会涉及研发、资金投入乃至业务需求等因素。之所以“系统慢”和“理赔难” 的问题能够加以对比，正是因为IT和保险一样都属于服务业，而运维与理赔恰好都是这两种服务的交付环节。


8 M% i- }* P+ \2 g$ b; S- ^/ U: ]
( x% W$ j% h" ~7 }5 A6 G. p 一、“系统慢”和“理赔难”的问题本质——服务水平管理
2 L8 b6 d/ d; A1 Q( }, Z* Y

3 C. M/ }/ r, i' mIT的服务对象是内部客户，保险公司服务的则是外部客户。既然交付物都是服务，而不是产品，那么衡量交付物的标准就应当是服务水平，而衡量服务水平的最终标准自然就是客户满意度。但这并不意味着客户真的就是上帝，可以予取予求。之所以说“客户满意度”，而不是“用户满意度”，当然是有其道理的——客户是要付钱的，服务提供方一般来说只能在与其支付费用相对应的合理范围内提供服务。考虑了费用约束条件的服务水平交付标准就是所谓的服务水平协议，在保险来说就是保单（及相关服务承诺），在IT来说就叫服务水平协议，即ServiceLevel Agreement，简称SLA。

无论保险的保单还是IT的SLA，都是包含很多项具体服务水平的一个综合服务水平协议，那么如何来衡量这个服务水平协议的执行情况呢？具体到个案，标准可能有很多，不少时候也不能简单地死抠条款而不考虑大局。但整体而言，IT服务水平的高低是不能简单地以公司内部舆论或领导提意见的层级来评价的，正如理赔的好坏不能简单地以社会舆论与保监会的投诉统计来评价一样。身处其中的人都知道，那些舆论未必公正，那些批判也未必能触及到深层问题。

既然都是服务，就有很多地方是相通的。保险通过精算和产品开发制定了产品，通过承保揽来了客户，直到最后的理赔才是客户最关心的那部分服务。这个链条一环套一环，互相嵌套，互相制约。理赔难的问题可能是理赔的问题，但也可能是产品开发不合理或者承保的问题。除了极个别情形以外，客户是不会抱怨投保难的。承保的目标就是千方百计把客户拉进来，至于以后的事，自然有后面的理赔环节去解决。IT则是通过需求管理和系统开发做出了应用程序，但此后还需要通过主机、数据库、网络和终端设备等等集成以后，才能提供给用户使用，中间出了问题还需要及时解决，后面这几个环节都是运维。系统慢的问题表面上看当然是运维的问题，因为没有达到相应的服务水平。但如果要深究问题的本质，比方说业务部门的需求提得比较随意，修改也很方便，更不用对业务发展规模和系统运行水平进行估算并确定标准，经常还来个某月某日倒计时必须上线，而这些要求在系统研发费用有限的情况下居然都实现了——这样一来后面系统出现问题又有什么好奇怪的呢？
0 n- s' o2 l8 _
二、“系统慢”和“理赔难”的优化思路——“四个理清”
) J5 z( O" D  Z1 O0 r/ d, K
( d4 u! K7 z' h/ f. K# a0 ~IT治理已经不是什么新概念了，定义也是众说纷纭。但从服务管理的角度来讲，逐步把服务流程化和规范化，并在此基础上逐步优化则是IT治理的主要目的。假设没有IT技术，保险公司当然还可以运营，但在大量分析数据基础上的客户管理和经营分析乃至流程优化工作就很难做了，而这些正是IT治理的重要成果。服务流程化或者至少部分流程化以后，就可以对流程化的各个环节进行规范，规范后的环节就可以根据数据分析结果进行优化。然而往往为人们所忽视的是，优化的前提必然是确定给定投入下的交付标准，否则优化也就找不到方向。
5 s/ U" E& P. i! M
因此，优化服务的要点在于“四个理清”，理清服务，理清标准，理清流程，理清成本。首先理清服务，确定都有些什么交付物；其次理清标准，分门别类地确定交付物的标准；再次就是服务提供方自己的事，把服务流程理清，分清楚环节；最后按环节和交付物标准理清成本。至此，就可以再回到开始，和服务需求方商定交付物及其标准，因为这个成本需求方未必接受，很有可能需要根据需求方对成本的承受力重新调整服务内容和标准。
" T+ A2 q5 O. Q+ m" r# j, m
  E9 I" R* c# u# \既然从理论上来讲解决问题的思路是“四个理清”，接下来就可以看一看“理赔难”和“系统慢”具体都有哪些表现。

按照保险行业协会的说法，“理赔难”表现为四个方面：“第一，消费者感觉赔款金额比他想象的要少甚至觉得该赔不赔；第二，理赔时限跟消费者预期有一些差距；第三，认为理赔手续，包括索赔程序不够简便；第四，感觉保险公司刁难，服务态度不好。”
$ ]5 B7 q8 b, b  n# j6 k$ O( y
4 @/ U) E5 }' J; P我们归纳类比一下“系统慢”的问题，其实也是这几个方面：第一，用户感觉系统不如期待中的快；第二，处理系统问题的时限和用户预期有较大差距；第三，上报系统问题的渠道不统一，无法跟踪进度，甚至有去无回；第四，IT支持人员服务态度也有问题。

根据保监会的说法，“理赔出现这些问题的原因核心在于内因，在于转变发展方式。前几年车险发展非常快，但各公司发展方式仍较粗放，前端广告等投入越来越大，而后端理赔队伍和管理的投入未跟上车险发展步伐”；对于IT来说，IT的内因就是由于业务需求过多过快，对新系统研发和上线要求高，但对后端运维支持重视不够。

同时也有外因，即“理赔的外部环境有待改善，如司法环境、社会诚信环境、医疗、配件等领域垄断定价以及消费者对保险的理解等”；对IT来说，就等同于和业务部门之间没有建立服务标准，与业务部门沟通协调不够以及资源不足导致购买配套设备和服务不足等。

面对上面这些问题，保监会提出的解决思路就是要“重点建设行业标准，也就是要逐步建立索赔单证标准、车险基础服务标准、车险理赔服务流程标准、事故车维修配件和工时标准、理赔人员职业认证和资格管理制度等”。这些都是提高理赔服务质量的重要基础。

归纳保监会的说法，其实也就是要做到理清服务和理清标准。当然对于监管机构来说，做到理清服务，理清标准就足够了，理清流程和理清成本是保险公司自己的事。
0 D1 a7 V+ \' p) L8 _! L
同样的，解决“系统慢”的问题，也是首先要理清服务、理清标准。不理清服务就无从理清标准，而没有标准就没有方向。有了标准就可以按标准配置资源，没有标准就只能按照“嗓门”配置资源。

IT服务标准一定是业务和IT 的共识，也就是“业务能理解，IT可计算”。如果服务标准是业务所不能理解的或者IT不可计算的，这样的服务标准也就没有多大意义了。其实虽然业务对于系统功能的需求多种多样，但对于系统性能的需求，也就是对于运维的需求无非就是系统响应时间，业务连续性和容量管理三类指标，以及这三类的组合或变种罢了。服务标准的从无到有会需要长期反复的沟通，对于IT而言，宁可牺牲“IT可计算”，也不能牺牲“业务能理解”。对于给定的指标，IT总是有办法计算的，不能直接计算就间接计算，不能精确计算就模糊计算，而如果业务不能理解，服务标准也就从根本上失去了意义，这也是“以客户为中心”服务理念的体现。
( E, }# Q8 ^% A9 M
三、“系统慢”和“理赔难”的优化举措
8 Q/ ~5 K" Z2 _6 t
有了思路，就可以对存在的问题逐一分析解决了。

对理赔来说，首先是赔款数额达不到用户要求的问题，对于车险来说，标准是有的，但需要做好解释工作明确标准，让用户从投保时就明白自己买的是什么。例如车险二次点火不赔，其实在涉水险条款下是赔的。但问题是没多少保户知道，就知道保了“全险”什么都该赔，一旦出现问题自然会有纠纷。其次是把车价库嵌入理赔系统，并在系统中维护不同厂店的维修标准，定损金额保证能修，把“赔多赔少”的问题转化为能否修好的问题，赔多赔少也就不是问题了。

对于IT来说，因为没有标准，首要工作就是要和业务部门说清楚服务标准。谁都希望自己的系统随时都能用，像门户网站一样快，业务怎么增长系统资源都能跟上，但这些都是需要配套资源支持的。系统响应时间缩短一半成本可能就要提高几倍，业务能否承担这个成本呢？要彻底解决标准问题，就必须把需求和成本对应起来，真正实行全面预算管理，把业务发展和配套的IT投入挂起钩来。

其次，对于理赔时限和IT系统问题时限的解决方案基本上是一致的，无非就是减少环节或缩短环节处理时间。理赔可以有理赔系统，运维可以有运维支持系统，都是基于工作流的设计思路，记录了每一个操作环节的流入、流出和处理时间，为后续各类考核提供了基础数据，再通过建立各类分析系统，对各环节进行全方位的效率监控。这样一来，就可以对于不同的事故（系统问题），区分类型，简化流程，也即对常规低风险问题尽可能简化，对高风险问题再根据需要设立各种控制环节。同时还可以利用技术手段，提高各个环节的处理效率，包括自动处理率。理赔系统是这样，对IT来说当然更不是问题。最后，都需要定期清理未决案件（系统问题），都可以借助系统的基础数据指定专人对各个环节的滞留案件（系统问题）进行回访，并对各个环节的超时案件（系统问题）及时给出提醒。

- k7 w8 z3 U* C+ ^0 }' W第三，对于索赔手续不够简便的问题，除了社会整体诚信度的问题导致需要的材料过多这个因素之外，其实也可以归结为流程透明度和服务渠道多样化的问题。如果需要什么材料和对应的流程及服务承诺都清清楚楚，即使材料稍多，手续繁杂的问题也不会那么突出。同时，采用新技术支持多样化的渠道例如自助查勘，自助理赔等都可以从很大程度上缓解这个矛盾。理赔可以做到公开服务承诺，设立查询网站，阶段性短信（邮件）通知客户，这些措施运维支持也是完全可以做到的。同时，运维支持也可以充分利用新渠道，由于出现系统问题时终端用户所用的系统，所在的页面，所使用的用户及其他相关信息都是可以由系统自动抓取的，因此运维支持服务完全可以实现使用电话、网页、邮件乃至即时消息等工具快速产生工单的方法上报系统问题，做到多渠道访问，一元化管理。
# g2 Q5 ~5 t5 o1 ~. L
7 r8 k) a  W* K# C) f2 B* j第四、对于服务态度导致的客户满意度问题，在统一支持服务渠道的基础上其实是很好解决的。这些国内外都有很成熟的经验和标准规范的管理流程，甚至可以说和所处的领域没什么关系。

总之，“系统慢”和“理赔难”表面上看似乎风马牛不相及，其本质却都是服务的交付环节，也就是整个服务链中的所有问题最终体现的环节。如果单就“系统慢”谈“系统慢”，或单就“理赔难”谈“理赔难”，是很难从根本上解决问题的。但从目前的情况来看，“理赔难”的形势要好得多，因为无论从监管机构还是公司管理层乃至基层员工来说，对其中的大部分问题已经形成了清晰的思路和基本的共识，从某种意义上来说就是个时间问题了。
% V; t9 j% d$ ?
与此同时，“系统慢”问题还远远达不到这样的水平。业务和IT还没有需要统一服务标准的共识，更不用谈如何去优化了。而优化的实质就是资源的合理配置，没有标准没有逻辑去配置资源就只能凭经验，凭“嗓门”，IT的任务也就成了救火队员，处处“维稳”。其实解决问题至少有两种方式——或者“维稳”，或者“改革”。这两种方式并不是互斥的。“维稳”而不“改革”，“维稳”就没有方向；“改革”而不“维稳”，“改革”就没有基础。解决“系统慢”的问题应当也完全可以借鉴解决“理赔难”问题的思路，逐步积累，逐步改进，最终必有成效。

满身风雨

太复杂了， 可读性太差.
% b( g* [& u/ W4 v对于坛友来书，寓教于乐的更好些。
  x) O& S2 Y5 o; k5 k. g. I- v

就爱抬杠

满身风雨 发表于 2012-10-29 15:17
太复杂了， 可读性太差.
, g6 j  t$ u5 x1 ^3 X' h对于坛友来书，寓教于乐的更好些。

6 h  j2 n! i0 J5 K3 T5 A  x3 x6 A有点