这两周干的最有意思的一件事，莫过于搞清楚数据录入时效性这个衡量指标了。先讲讲故事吧：
故事起源于数据录入时效性的一个分析，可以看下面的图。以前我们认为通过所谓每天完成百分数这个数据可以实现对时效性的有效评估。说白了就是，当时的一个假设是，如果1天的当天数据完成100%，那么就意味着数据可以在一天内完成，处理时效是24小时。
但是，真实的用于工业生产，你会发现，其实每天的数据不可能达到理想的100%，而是会有各种差异，比如图里面的70%，98%等等。于是乎问题就来了，看了这个数据，我知道我们并没有完成我给用户承诺的48小时返回的指标完成情况这件事情，但是我距离这个目标差距有多远呢？于是乎我们使用了下面一个图的数据指标。
看了17%，50%，作为24小时和48小时的处理时效。刚开始的时候这个数字吓到我了，于是想各种办法改进，当然效果是有的，但是改来改去还是回到问题的原点，我到底和我当初的预期差距有多远？就着现有的数据，我只能模糊的感觉到很远，但是我要如何解释用户那一端获得的真实感受呢？每天一大堆同事抱怨数据录入时效太慢，到底这个感受是否真实呢？真实到什么程度呢？
就着这个问题，我和公司的数据分析老大做了半个下午的深入探讨。得到了如下的一番答案。首先，我得到的答案是，要解决什么问题，就要重新回到问题的原始场景，那就是我所有的问题，其实是来源于我关心用户的真实使用感受。那么我关心的所谓时效性，是返回到用户那里的时间感受，而不是作业机器和车间里的完成百分率。按照这个理论，我们重新画了一下正常作业的数据处理方法，大体是满足泊松分布的。
根据这个分布，大部分的数据会在前面的相对比较短的时间内快速完成，后面的数据将呈现比较明显的长尾效应。于是根据这个图，如果真的想得用户的感知，其实需要的不是计算某个时段处理的比例数，而是应该反过来，看某个固定比例数所处的时间段是多少。比如某个月最后算出来是80个小时，那么就意味着我实际返回给用户的感知是在80个小时以内。这样就很明确的界定了用户对于数据录入返回时间的感受。也解释了为什么用户反馈增加的原因。于是我们后来做了一些从后端到前端的改进方案。
那么好了，说到这里大家可能觉得这个故事的结尾的确实现了数据驱动，但故事的主体，那个翻来覆去，改了三遍的指标到底意味着什么呢？这就是这两周，我特别兴奋于学会的东西，即数据背后的那个建模过程。这才是所谓数据的Insight能够产生的核心原因，也是数据驱动的基础。
往往过去我们对数据驱动可能是这样认识的：
- 我们要看数据，数据是重要的交流沟通工具，是一个可以形成共识的语言
- 我们要了解各种数据，以帮组我们检验所做工作的好坏
- 数据可以为决策提供有效的参考工具
这在我现在看来依然是非常重要的底层基础。但是随着真实使用的场景，我渐渐发现，仅有这些是不够的。随着信息爆炸，我们每个人身边的数据都可以说是海量大，可以说各种各样的数据充斥在我们耳边。尤其是大数据的兴起，更让一群人对这方面趋之若鹜，争相希望把更多的数据展示出来。然而，随着实际工作中的经验我发现，仅仅展现数据是远远不够的。公司的统计系统里面，有超过几十个报表，成百的数据项目在平台上进行统计，可是每当我问道业务部门你们为什么不看数据时候，得到的答案往往是，我无法从数据里看出问题。
这个事情曾经让我百思不得其解，直到我做完上面的故事，我才豁然开朗。原来数据驱动不是简简单单拿着数据去指导下一步的事情，而是数据是为了解决问题而产生的，它的源头应该是解决问题驱动。这就对了，因为事实上，这也是一个公司，一个团队存在的意义，就是为了解决一个又一个的问题。那么这些问题，需要经过合理的，有效的抽象，最终形成一套完整的数据指标。数据的诞生是为了提供证据，而正确的寻找证据，就能破案，能解决问题。但是如果只是数据的罗列，或者不去追踪数据的合理性，和是否能够为问题服务的特性，数据驱动其实是无法发挥价值的。
所以，在数据驱动里，除了收集数据，展示数据之外，还有重要的一个部分叫做数据建模，正是通过这个部分的工作，我们把原始的问题进行剖析，寻找对问题相应的证据，这就是数据驱动的真正意义，也是解决问题的根本。