分析服务和方案

[Q]

在汽车上，虽然旁边坐了一位姑娘，长得并不令人讨厌，我却始终面朝窗外，冥思苦想...需要的是一种标准...应该是从用户体验出发...试着想象自己是以为分析师...一位总经理...一位...

这些天一直在路上。窗外的花草树木迅速后撤，这种凭空的想像很容易走神，一会儿就发现思路偏了，想到比如可以找谁来实现的事情上去了，真是。如果有一只笔一张纸就好，可以将想到的画下来。而在脑中勾勒，却始终无法形成完整的图景。

是什么引发的这后续思考已经不记得。

哦，可能是那天下午从“混搭”话题引起的吧，寻思着究竟有哪些分析服务，数据仓库本身可以形成服务，报表可以，多维分析可以，专业模型也可以...啊，多维分析，要全局统一的维度，以度量为核心，每个度量可以在那些维度上切分...对于用户来说，他不需要了解多维分析是由几个cube组成的，他根本不要知道有cube的存在...那么，这必定需要强大的元数据，有一个同样名称的度量，可能是不同的业务含义，所以，描述cube的元数据要包括对数据范围的定义...要限定客户群...客户群就是一个数据范围的定义，只有相同数据范围的度量，才能进行cube之间的数据合并...那么多度量、维度，需要搜索...不，搜索太麻烦，简单一点，用标签就可以，对每个报表、指标、cube打上标签...对维度要按照使用程度进行排序，经常用的肯定要最容易找到，排在前头，像arpu、客户数这种...到底有多少种分析服务呢？用圆圈表示分析服务，报表一个圈，多维分析一个圈，分析模板一个圈，分析报告一个圈...分析模板和分析报告有什么区别？...分析模板这个名字太土了...阿，在分析服务上面，得有一层，服务控制层，权限控制要在这一层，对分析服务的数据访问需要根据用户环境进行控制，环境有当前时间、区域、部门、周期，还有角色、用户...还有服务的登记，要将所有分析服务管理起来...还是要标准...广州那个武器库的界面，实在是...大片的描述文字...不应该那样。所有静态变化少的信息应当隐藏放到第二层，首先让用户看到的应当是变化的内容，指标数据是变化的，分析模板内容是变化的...这是否应当作为一个设计原则呢？那设计者肯定是个新手...数据的提取是否属于这里？数据？数据也属于交易的商品，应当属于...得将营销超市纳入进来...

很是兴奋，一直看着窗外，哼着曲子，有些念头已经在脑海翻来覆去转了好几遍，却因为不够清晰，只是停滞不前。所以，假象这大脑中有一张纸和一张笔。首先，是边界。中间一个大圈就是我想象的东西，叫什么？BI系统？分析系统？....对啊，岂不就是我的决策市场！对，决策市场，我在图中间写上这四个字，然后外面是一些用例，别人都在这里干什么。应当有一个“监控”，画一个圈。还有一个比如看报表、看分析报告的呢，画一个“分析”的圈，不，所谓分析还得细分，一般仅仅是查看分析结果而已，用这些结果去决策，而作分析不是在这里进行的。但在魔星里面，我想到应该是交互式的，可以进行一些再分析，这也是挺好的啊，看分析，作分析，这应该是两个圈。那么，监控岂非也是属于“看分析”的一部分。看分析，包括监控、看报表、看分析报告、看分析模板...而作分析，是对现有分析进行再加工过程，比如分析评论应当属于这范畴。还有数据的输出，这也是决策市场要做的，明细数据、统计数据，这些数据可以导入执行系统，比如营销系统去做营销。是的，决策市场并非执行系统，需要将分析服务提供的明细数据传递出去。

一切都是从监控开始。

但什么叫做监控呢？今年花了好多时间在垂直解决方案上，但方案跟分析服务到底什么关系呢？

方案，solution，分析方案，其实是一面面向业务问题的一揽子分析服务，但只是限于分析、决策层面，剔除了真正的执行，它假设外部是有执行系统的。因此，一个完整方案，包括指标体系（用于监控）、分析服务（报表、多维分析、分析报告）、策略建议，暂时，这些都是逻辑上的，物理的系统，暂时并没有纳入solution的范畴。也许这并不准确，但为了抽象一点，让方案的依赖性更小，先这么考虑。指标体系用于监控现状、分析服务用于分析指标异动的原因，或是做客户预测用（比如输出客户名单），策略建议用于行动执行指引，可以被部署到支撑系统上去的。

其实，从监控到分析，并没有明确的界限，不能说指标体系的展现不包含分析过程，指标的钻取明显是一个细化寻求问题答案的过程。因此，如果要严格区分，所谓监控，恐怕就是一个最直接呈现出来的现状量化表示，比如一个仪表盘。而报表，作为一种形式，可能是直接充当仪表盘作用的，而大部分是作为监控之下的分析用途。分析的过程并没有给出行动建议，只是从数据剖析事实，而策略建议，是需要融合人的经验，对需要采取什么行动，行动的细节给出建议。比如要做一次营销活动，面向的目标客户群，需要协同的渠道，可能的收益预测，这也属于方案的部分。

如此，方案其实只是一个包。他直接面向了一个决策问题，形成一个方案需要抽象总结，而大多数情况，可能更加常用的则是普通的分析服务，譬如我们现在的一些分析系统，如经营分析系统，大多是提供基本的分析服务，而不会以方案的形式出现。而如果某个产品已分析方案的形式出现，却也不会按照分析服务的方式去组织。

很多概念现在看来还是模糊不清，似是而非。试着用定义将他们区隔。

• 监控：用数据量化反映业务问题的过程。
• 分析：针对问题，用数据、经验寻求问题答案的过程。
• 分析件：分析活动的表现形式。
• 方案：针对决策问题，监控、分析和策略建议过程的表现形式。
• 分析服务：针对业务问题给出分析解答的表现形式。

稍稍明晰了丁点儿，有点成就的是，将方案跟分析服务终于挂上钩了。

[祝迎春]

总结得很好啊，谢谢分享