对于PICC统计分析系统设计的思考

对于麦肯锡，咨询业内流传一个这样的故事，有一个老头，正在草地上放羊，忽然走来一个年轻人，年经人走到老头面前说：老先生，我可以为您服务，我将告诉您您的这群羊有几头，作为酬劳您需要给我一头羊。老头还未作答，年青人就开始了工作，年轻人用笔记本电脑无线上网，链接上NASA的内部网，调动低轨道卫星，把卫星遥感成像的图片再通过软件分析，数十分钟后，年轻人再次走到老头面前：老先生，您的羊群共有763头。说完后他抱起一只羊就要走。
老头这时叫住了年青人：年青人，如果我能猜出你就职的公司，你可不可以把酬劳还给我？可以，年轻人答。你是麦肯锡公司的，老头说。年轻人很惊讶，您怎么知道？老头笑了：因为你具有该公司咨询人员的所有特点啊，第一。你不请自来。第二。你告诉我的分析结果是我本就知道的。第三。你抱走的不是羊，而是我的牧羊犬。

这个故事在业内流传甚广，它似乎是说即麦肯锡的咨询好像就是告诉了客户一些它早就知道的信息，但是换个角度，当只有一个牧羊人，一个羊圈的时候，也许是这样一种情况，但是换成一个镇子里面的人，有牧羊人，有羊毛商人，有织毛女工，有裁缝，还有面包师，理发师，陶匠…。这样的情况怎么能让每一个角色，每一个人都知道会和自己相关（人通常都只关心和自己相关的事情）的情况呢，这就不是一个好玩的笑话了。相反，这就成了一个值得我们花费大的精力研究的事情。
现在有一个流行的说法，即解决方案提供商，中科软科技的各个部门也有多解决方案的提供。事实上，解决方案和咨询公司提供的服务内容很类似。所以，前面这个道理也适用于我们统计分析产品。
1 定位
在过去我们组有两个定位，一个是‘统计分析’组，一个是‘BI’项目，这两个定位当然是不一样的，BI应该是一个更大的概念，就前一个概念而言，我们现在做的主要是统计部分，而分析的工作是让是让客户根据我们的统计数据进行的。
就市场和我们的能力而言，我们当然是愿意做BI的。但一方面BI的基础是统计，另一方面我们的传统市场统计方面还做得不够。就工具而言我们使用的cognos部分也没有很强大的intelengent工具。也就是说在Intelengent方面我们的积累还很少。所以在内部而言，我认为我们还是要先定位在统计工作的完美上面。当然，这并不是说我们就不做BI中Intelengent的部分，BI中的Intelengent和非Intelengent的部分并不是可以完全分隔开的两个部分。
在我看来统计工作有两个要点，一个是全面，另外一个是精确。
全面指的是统计的数据包括的内容全面，这也就意味不仅仅是用户已经提出过的分析报表包括的指标，维度，还要关心其它未提出的但是有信息量的数据，当然考虑到实际情况，我们应当考虑关心的主题的数据内容的全面，而不是所有的数据的全面。
这里的精确借用了数学中的概念，就是在可容忍的范围内的准确度，这个和业务系统中数据的变化信息的不可回溯相关，这里的精确并不是简简单单的说提数的时候的过滤条件要写得很准确，这是一个系统的工程。


如何实现BI?
在传统的人保的人员的职能划分中，通常包括有总经理，办公室，人力资源，财务会计，监察审计，信息技术部，车险部，非车险部，理赔管理，承保管理，再保，大型商业等等，其中又有对于产品线的划分。这事实上和前面的小镇的人的社会角色的分类类似，另外还有上下级的划分，在很多分公司里面，这些部门之间通常有很多天然的障碍以至于这些部门之间的信息不能够相互沟通。所以要实现这些信息的共享也不是一件容易的事情。
首先是统计分析，然后才是BI， 首先要如实地，全面的反映公司的经营状况，然后才是分析将来的发展(现在比将来容易掌握，现在是将来的基础)。
1.1 如何真实反映
真实反映一个公司的经营状况决不能只是管中窥豹，
1.1.1 重新划分主题
在‘全面’的论述中我提到了一个概念<主题>，这个概念我们在之前的工作一直也提到过，如承保，理赔，财务，收付费，这样的划分。这是一种划分，但是这是根据业务模块的划分，而不是根据内容的划分。根据以前的模块划分的方法，在实际工作有很多弊病，我们面对的客户并不是一个牧羊人，他们所关心的内容是所有的和自己相关的信息，而领导层关心的内容就更多了，像前面提到的一样，承保的信息和理赔的信息是相关的，理赔模块需要考虑承保模块的中的承保信息，承保日期等等，而承保部门也需要了解脱保续保中续保的保单的出险情况（这个有Intellengent的部分，根据统计信息做出决策）。人保或其它保险公司内部的传统的报表绝大部分都是按模块划分的，所以他们觉得最有用的部分是财务报表，或者是业务的一些简单的报表，这个可以适应于通过粗放式管理时对规模的追求的考核，并不适用于现在对效益驱动的业务形式。

1.1.1.1 为什要重新划分

1.1.1.2 重新划分的标准
所谓的主题（Subject）是指的若干经过组织的内容相互之间关联，所拥有的共同点。它们的特征是很容易在一个语境出现，如保单数量和保费，保费和已决赔款，已决赔款和车座数，当然有这个的特征不一定都是属于同一个主题，但是同一个主题下面的数据一定会有这个特征。
类型的另一个特征是它们的度量单位，我们知道如果一些数据如果有相互关系，那么在普通的计算系统下，他们的度量单位会有关系，如 件、元、元/件 这三个度量单位是有相互关系的，所以这些度量之间也可能有相互关系。
另外一个可以参考的信息是客户的对业务考核的相关文档，如《安徽池州市分公司实施精细化管理促车险业务扭亏增盈.doc》这篇文章中，我们就可以获取相当的信息，这个在我的《对(安徽池州市分公司实施精细化管理促车险业务扭亏增盈)的分析.doc》有一个简单的尝试。
1.1.1.3 筛选维度
通过对旧有系统中的报表的分析，我们可以得到《常用维度和指标(按主题).xls》这样一个图表，在这个图表中以左上角为原点，越靠近原点的维度或者指标出现的次数越多，可能性越大，在颜色为白色的表格中是可能出现的而尚未在已有报表中出现的关联，这是我们在前面提到的‘全面’中应该实现的部分。
对已有指标的数据可以进行有意义的分类的，
1.1.1.4 新建维度
通过一些思考和相关资料的收集，我觉得还有一些维度可能会有信息量而尚未出现或者很少出现的维度。
1.1.1.5 新的主题
在这些维度和指标中通过前面提到的主题的划分标准和我们的经验可以得到以下的一种划分。
 效益类 和效益相关的维度和指标，是现阶段我们系统主要内容。
 效率类
主要是case的处理速度，承保的速度（转保单），处理报案的速度，处理立案的速度，理赔的速度，结案的速度。
 考核类
主要是一些总公司提供的考核类型。

1.1.1.6 对于中间库的影响
1.1.2 使用专题
主题分析，是在主题域的基础上建立的分析，比如客户分析，利润分析，效率分析，更多的是种“分析”；专题分析，说得更多的一个词是专题应用；顾名思义，是针对某个特定的问题，提出的一整套分析应用专题；
在统计分析系统的历史版本当中,多半是以部门划分的模块, 这样的划分在这里就有相当的意义.例如在利润分析里面可以有承保环节的专题，包括规模，费率，已赚净保费，应收保费等等，理赔环节的专题可以包括未决分析，已决分析，赔付率分析等等。这样一来就可以将一个大的主题里面的数据分为多个相关联的模块。
利润主题—》承保专题，理赔专题，费用专题,效益专题等等。
效率主题—》承保环节，理赔专题，95518专题（不了解，应该可以重新划分这个）
风险主题—》批改保单（费用，日期），出险率分析（保单出现率，保费出险率（简单赔付率）），巨灾等等。
1.1.3 条件维度
所谓条件维度和普通维度区别在于它的内容的特殊性，普通的维度是对于数据的分类，划分，例如机构归属等等。这里的条件维度一般是用于关注的数据的范围，是根据当前的专题确定的，也就是说通常情况下只要查看该主题的情况下即需要选择该条件维度。
为什么会提出条件维度呢，这和前面提到的统计工作的要点和我们实际工作中遇到的问题是相关的。
首先我们需要不断的追寻精确这个要点，另一方面我们所实现的“精确“和客户所能理解到的“精确“应该要同步。
我们之前的筛选方式是通过在后台提数或者是写iqd的时候直接将数据筛选掉来实现的。在这种情况下使用文档来进行说明是一种方式。但是使用文档一方面有使用复杂的问题另一方面有同步的问题（如更新选择条件，而用户还停留在过去的印象中）。
使用条件维度的优势是
一， 能够让用户直观的了解当前数据的筛选条件。
二， 能够实时更新，当条件发生变化的时候可以在用户使用该专题的时候第一时间了解到。
三， 由于我们的系统还不够成熟，有些业务还不够了解，再加上客户业务的独特性（不是每个客户都会关注所有条件），这样在大范围的客户使用的时候也能够让客户快速理解和反馈。
使用条件维度的缺陷，如果条件比较多的话，会让用户使用感比较差。可以采用定制报表和采用一个“常用条件“维度来简化这个操作。

1.2 提供将来的趋势
在基础数据精确的基础上我们就可以进行趋势的分析了。
1.2.1 为什么要了解趋势

1.2.2 有哪些主要的指标需要了解趋势(对已有的分析)
2 测试先行
3 元数据管理
3.1 什么是元数据
3.2 定义元数据
3.3 元数据驱动的测试
3.4 以元数据为基础设计数据仓库
3.5 模型设计中使用元数据的部分
3.6 维护元数据

4 数据仓库的设计
优点 当前的中间库设计的时候已经取得了一些成效,可以将一些经常关联的数据存储在一个事实表中，维度表方面设计得也大致完善了。
缺点 这些中间库的设计思想是提出还不够完善，对于上面提出的系统应用还不够。
出于面向上面的设计和应用的思想，一个简单的后台数据层设计模型如下，该模型的优点如下：
1， 采用了面向主题的思想，相关的维度和指标会归属于一个主题。
2， 采用了视图环节，可以将一些跨主题的指标和维度联系在一起，
3， 采用了视图环节，可以将不同粒度的数据合并在一起，这样可以平滑的在数据粒度和存储空间和资源消耗之间做一个选择。
4， 采用了视图环节，可以将模型处的逻辑和设计最小化，可以快速的进行数据的调整。
5， 采用视图环节，可以在使用前面提到的条件维度的时候快速调节“常用条件“维度。


对于收付费的库可以使用历史周的汇总数据+最近的一周内的明细数据进行抽取，每过完一周将这周的数据汇总到历史周中去。
5 系统的成长
我们的统计分析系统的成长肯定不是一蹴而就，有很多信息我们尚未了解，很多技巧我们尚未掌握，很多第三方的技术尚未出现。在这些事情发生的时候我们应该怎么做呢？
6 其它
6.1 提数的范围
在模型的理想设计中，我们的数据是包含有所有的数据的，但是考虑到效率原因和功能原因，我们通常只需要近三年的数据，在这种情况下，旧的提数方式会有一个天生的数据缺失的缺陷，即在某个环节中出现的单证的其它环节的信息存在我们的中间库中，当然这个可以通过补录的方式实现，但是这个实现方式繁琐且dirty（每个环节都需要考虑其它的所有环节），下面是一个简单而清晰的方案。
步骤1，确定提数的范围，包括提数的时间段和提数的数据范围（承保保单、理赔表。。。）
步骤 2，因为保险业务的特殊性，几乎所有的数据都和保单相关，所以把数据范围类的根据提数时间段或其它条件将所有相关的保单号汇总到一个表。
步骤 3，根据步骤2产生的保单号表提所有的数据。
步骤 4，增量更新，和旧方案相同，根据snapdb的信息提数。
6.2 对于中间库的思考
6.3 使用etl工具
经验的积累
数据的增长方式，如果使用月+天的方式存储数据，需要两步将天的数据更新和将月数据更新。如果使用唯一的粒度即天，则只需要一步更新一次数据
数据的可靠性
常用过滤条件
6.3.1 对于多层次重复计数的问题，
例如混保的时候，按照险别统计保单数正确的时候按照险类统计可能就不正确了，这种情况下可以建造一个指标即混保的保单数数×该混保保单的混保数量，这样即可以获得正确的保单数。



吉林的关注点,未决赔款,应收保费,脱保续保.
收付费的应收保费
安徽方面的数据信息.

未决发展
安徽扭亏方面的环节数据方面的关注点,未决准备金.重点关注的是金额.
未决准备金额,可以分机构险种,这样一般来说也够了.可以和是否人伤相关联么?应该可以和sf02关联取保单号取数据.

主要有的维度 机构、险种、观察日期、数据日期、是否人伤。
指标：新增未决件数、新增未决金额、累计未决金额、案均未决准备金额、已决件数、已决案均金额、累计已决金额、当期有效保单件数、同期案件出险占比（出险案件数/当期有效保单数）
案件类型对未决估损金额应该有关系，应用未决件数分类型的加权值。估损偏差可能比较稳定，有规律。
每个地市的估损人员可能不超过10人，可以作为一个层次加入到机构维度中。加入新的维度或者层次的时候要综合多个地市或者省市。
各项金额同期、同比。
应收保费的分析帮助行可能不大，通过已有规律，安徽应收保费应收6%-14%，年为周期的一个变动过程。

脱保续保，对这个的关注主要出现开始于多家新保险公司出现的时候对市场份额的影响，出于害怕客户流失的考虑提出这个点。
对续保提示的时候是否有考虑过出险次数，已赔金额。（核保一定会考虑，通过系统外的信息：如旧保单上面的出险章（信息可能比较旧）新系统可能已经有了）车险分为ABCDE级业务（）。
提高非车险占比，降低车险占比，调优产品线结构。

要综合考虑调整数据展示范围后(如加入注销维度)对于用户使用的影响.

是否给各个指标加上平均值,占比等等.