------需求决定了数据产品方向-----
传统BI最大的困惑在于盲目跟着需求开发，导致开发成果无法确定是否在用、够用，也无法避免无休止的需求变更，这导致BI开发成本高、周期长、失败率高（前些年流行BI70%以上失败的说法）。这样的BI最大的特点就是没有系统化、产品化，只是数据堆砌、死报表或CUBE开发，设计和开发者与业务需求没有任何衔接。
例如我们以前在创建BI团度之前，公司曾经找第三方实施过BI，建立了数据模型和数据处理，然后最终成果是开发出业务需求者想要的某些报表，例如零售日、周、月报，代理商配发日、周、月报。然后这个BI的成果没人用，因为它不能满足后来管理者的需求，一是数据质量还是有问题，二是反映的问题模糊，数据堆砌效应。而最终是数据模型得到了后来的重复利用。
后来针对公司核心业务管理部门，来重新梳理需求，方做成一个被广泛认可的维度层级、指标体系，在BI前端通过建模，形成基于ROLAP的数据产品。在这个过程中，我们通过反复交流发现，他们的（数据产品）需求包括：
1。一个统一维度、指标定义的数据模型，并在ROLAP平台上，方便随时抽取数据，自己进行二次分析；
2。方便应用的ROLAP逻辑和开发培训，能让业务部门随心所欲自己开发报表或仪表盘；
3。复杂运算、复杂仪表盘由BI部门完成，其中复杂运算分别在数据处理、BI逻辑模型中完成。例如商品动态营销属性计算（如在某周毛利率和毛利都高的商品，毛利率高但毛利低商品，毛利率低到毛利高的商品，毛利和毛利率都低得商品）、财务动态周期（如1万件商品原价100，市场生命周期3个月，原价的毛利率50%，预计平均毛利率35%，总毛利预期35万，依次动态计算）

-------有明确需求的数据产品------
在企业内部应用中，成熟的老业务往往有明确的需求，所以成熟企业内部应用中，常规统计分析占据90%甚至95%以上，数据挖掘一般存在用户相关分析、市场和商品预测等方面，而很多传统企业客户信息都不全。
有明确需求的情况大致分为如下类型：
1。有明确图表需求，例如报表格式，报表指标、维度，图形甚至颜色要求；
2。有明确计算规则的需求，例如物流对货物分配优先级的规则；
3。有明确业务场景的需求，例如某次销售会议，区域总监和销售副总需要看销售数据来判断下一步策略，是否增加增加店铺，是否加大促销力度，是否需要调整区域间货品优化。

有计算规则的需求，往往是将结果存储在数据中，或者在BI逻辑模型中存储其逻辑规则，业务部门自己查询或指导业务工作。例如物流新到一批货，A商品1万件，总需求却有1万2千件，如何分配呢？于是就有优先级规则，按照代销合同紧急需求、直营紧急需求、代销合同非紧急需求（可延迟）、直营非紧急需求等排序，然后循环计算分配。这样物流部门手里的数据就可以直接指导仓库分配货物给各个内部和外部的需求方，并无报表、图形等展现分析的必要。自从有了这些计算，物流分配货物准确及时性就大幅提高，供应链效率自然提高不少。

在业务场景需求中，曾经碰到这样一种情况，就是刚才提到的销售会议，业务部门拿来的直接需求是一个具庞大的报表，横面是区域、店铺，字段达百以上，而报表统计数据达到数万行。当我们BI了解本身目的之后，就建议他们这个数据可以拿去，但销售管理层没法做决策，于是决策的具体问题，分别进行了统计分析。而事后得知，会议根本没看百个字段，数据达数万行的超大报表，而是看了我们额外自制的统计分析，并从销售管理角度给了意见，再稍作调整。

-----无明确详细需求的数据产品-----
无明确需求的情况，常常出现在新生业务、业务变迁需要数据依据的时候，如传统企业转电商和实行VIP制度、供应链都知道要优化，怎么做符合企业自身情况下来入手呢？

这类情况，一般需要商业分析师与数据产品经理紧密合作，同时分析需求，如果是商业分析师仅传输需求给数据产品经理，是做不好数据产品的。

在客户管理中，我们BI既是商业分析师，也是数据产品设计和开发者，但在商品管理和供应链管理中，从业多年的专业人士是可以进行较专业的商业分析的，这当中BI部门也学到了很多这些业务方向的商业分析。例如在供应链优化中，业务部门提出了实用的解决思路：
1。根据供应链几个业务线的计划变化、动态并多对多灵活协调；
2。提高优先级自动分配，使得重要、紧急需求能都得到充分满足；
3。加强供应链操作效率，包括出、入库周期监管，以及仓库内部效率的提升。

在计划变化跟踪的业务需求清晰，数据产品完成之后，当生产入库计划提前之后，物流部门马上统计从现在到计划期间净出库和当前库存，看是否有空间存放，如果不够则需改动物流计划，生产入库仓库目标放到其他有空余的地方，或者推动下游需求，某些商品提前出库配发。这个数据产品集合了生产计划、物流出入库、仓库容量、配发需求等为一体，物流部门可以根据实际变化情况，自己查询数据或者开发跟踪监控图表。

然而有的商业分析是难以落地，只有条件成熟，才能推动。某一段期间，曾经有国际经验资深供应链管理者加盟，但不一定能有效推动。例如库存不高又要满足营销，他建议总仓只发一部分货给各渠道，剩下的按照需求，谁销得多、需求快就优先配给谁。这个理论上是不错的想法，我们BI当时就给他们说了下企业那个时候的实际困难，包括代销合同限制、频繁配送到渠道到底需要多频繁，每次配多少？实际情况是制约完美经验的最大障碍，企业应用中有解决实际困难的方法才是王道。在当时情况下，他们无法推动，谨慎也是没问题的，如果管理跟不上，成本反而大幅提升。

--------方向不明确的数据产品-------
在电商分析中，常常会连分析方向都不太明确，因为这个行业相对传统零售远不够成熟，业务部门也在摸索，那BI就不能完全指望业务部门了。

建议数据产品从基本数据产品、具体分析挖掘逐步展开。例如我们在还没有明确需求前，将订单、客户行为（一般先有订单数据）、物流仓储数据集成，在有日志样本数据的时候，就对日志数据访问指标统计、路径分类、访问与客户订单集成。同时抽时间，根据行业特点，对客户RFM建模、商品生命周期结合客户生命周期（详情参考客户商品生命周期文章）。

当我们发现，或业务提出要求的时候，分析就能很快达成，例如推广ROI不高，为什么？原来某渠道一、两月内吸引注册用户9千，实际下单不到30，且实际付款成交的只有一单，像这样的渠道不抓出来，怎么能提高最基本的ROI？还发现某些渠道客户第一次购买后，大部分不但之后未下单，连访问也非常稀疏，这为短期ROI还可以，但长期ROI弱的渠道，该渠道的客户可能目标客户群体不多，冲着活动买一把就算了。那赶紧出评估系统吧。

--------总结-------
数据产品是数据分析、商业分析的基础，但最好不要接二次需求，数据产品经理应充分参与需求的开发，这样的数据产品才能更受用、更有前瞻性、能让分析快速产出。

kankanxian