兵来将挡，水来土掩

出现问题，解决问题。这就像是兵来将挡，水来土掩。我们的数据分析，大多是在发现问题。或者说，尚处于这个阶段。有人预测，BI的最高境界，是那个什么玩意儿来¬着（我忘了）。大概意思是指，用分析指导决策。就跟算命差不多吧，先生说，西方有利，你就往西方走，相信他，没错的。

现在肯定是做不到的，但总觉得，事后的分析总归有些马后炮。有时候，你用OLAP展现出来的结果，客户看了一眼。"哦，是这么回事，跟我们想的一样。"。或者，¬你拿着一个不得其解的结果，去问人家，大家一起来分析原因。可能是台风天气原因吧？可能是这个月搞世界杯吧？可能是最近恐怖主义气氛有点紧张了吧。

这种状况，离"指导决策"还差了点。不过这也是过程，不经过这样的马后炮分析，也不能变成事前诸葛亮。

刚参加工作那会儿，公司有一位日本的大姐，长期在公司当翻译吧，要回国了。公司搞个小小欢送会，当然，此大姐自然要发两句言。其他的都没记住，只记得她说了什么¬，"出现问题，要解决问题"。这意思大概是指当时，大家看到问题都不闻不问的。那时候年轻，不知道她说的问题是什么，只顾着开心。

以前很多项目并行的时候，也有过一些感慨。不同的项目，遇到的技术、管理问题，大同小异，却很难去找什么可供借鉴的方法。大多这些方法是停留在某个人的头脑当中¬。于是，一段时间，比较热衷于知识库的建设。

看吧，这知识库就像是数据仓库。它们的模式都是积累->分析->辅助决策。只是，知识库中的"知识"，比数据仓库中的"数据"，还要抽象。

越来越觉得，很多事情并非是一定要干的。可能只是领导不能让你闲着，便让你写一份文档，起草一份报告，或者是开发一段程序。这些事情的目标是具体的，可达到这个¬目标对解决全局的事情有多大影响呢。可能很小，甚至没什么帮助。没有抓住重点。

一次跟同事聊天，他是项目经理，说起以前遇到的一件荒唐事。一位领导，要他将工作说明书细分成几千项，并且将任务划分给每个项目组成员，这基本上是要细分到每天¬了，甚至是一天里面的工作时段。也许有大公司曾经成功试过这样的方法，但必然他还有另外一套体系来保障其执行的。例如如果是工厂的生产计划，这么作到有可能（但¬还是非常怀疑）。而对于搞IT咨询、开发的，这么做一点意义都没有。这种项目从来没有一成不变的固定套路。

可那个领导坚持如此，最后，据那位同事声称，他跟领导死磕到底，没那样干，领导妥协。

解决问题就是要抓住重点。销售要搞定关键人物，做咨询的、做开发的，不一样也是得找到关键人物，关键症结，或者是关键程序吗？这恐怕也就是全局和细节的矛盾吧。

可什么是重点？这不是容易判断的事情。知识库能够帮忙判断吗？恐怕主要得靠经验吧。但如果经验只是停留在个人脑中，那也没什么用，还是得总结成模式化的东西，那¬就是知识。但总归，那都还是一种在方法层面上的东西。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友