很多人说做营销体系或者CRM类中后台产品是个“大坑”，小珠经常开玩笑说一直在坑里，从来没有试图爬出来。
归根结底，是因为以CRM为代表的中后台台产品的构架复杂，流程众多，功能庞杂，依赖产品对于营销业务的深度理解，需见功力。
同时系统想发挥作用，又依赖于整个营销体系的认知，不变革流程，不优化运营，不改变思维，不传递认知，系统发挥不了应有的作用。
除了CRM，小珠近年也参与了多个BI，开放数据平台等项目的建设，经验还非常粗浅，一起交流思考。
一、认知先行
长期看来，我们工作的本质是改变人的认知，先分享关于数据体系（乃至所有内部系统）建设的认知。需要通过落地的工作不断渗透认知。
二、回归数据决策过程
在BI及数据建设体系及能力累积中的初创型公司，往往业务又面临诸多优化的需求，这些需求必须经过数据分析加以支持，如互联网时代频频提起的AB测试，运营优化，试算模拟，仿真决策等。
频繁的需求往往又和薄弱的数据能力相对应，作为数据类产品，我们如何规划分析数据产品和能力？
还是先回归数据运营和决策过程的本身。
三、能力深化与系统沉淀
数据运营决策的过程会频繁的发生，某次过程数据能力和系统响应用了3天的时间，下次在响应类似的过程需要4天的时间，数据能力建设和系统沉淀的作用在于：让下次用1天的时间，甚至某些逻辑成熟的过程实现自动闭环。
这就是数据能力积累和数据系统承担的本质作用。
我们先讲上面的基本过程拓展到能力深化的维度，看下图红色箭头所示意。
如当企业已有基础BI能力和系统后，需要提供场景决策BI的聚合功能，即提供给业务某一组数据后，业务还有根据在其中的发现在查看其他几组数据来产生洞察和决策，那么需要将这个决策的场景加以聚合，不需要用户到处翻找其他数据，甚至直接产生洞察和决策。
而每次复杂的寻找和统筹原始数据宽表的过程需要不断建立数据仓库，规划数据元和指标主题并以合适的方式开发给用户来提高效率，积累能力。
这些能力在成熟的时候又需要对应数据产品来沉淀和开放，在数据分析者，数据使用者和数据决策者各取所需。
如图中蓝色箭头沉淀方向，逐步承担为数据资源开放指标管理平台，数据模型及工具平台已经成熟报告的BI平台3大产品体系。
四、规划和设计数据产品体系
基于上面对数据运营及决策过程的分析，同时落地到各个能力沉淀和产品对应关系。
三种产品定位分别解决了。业务洞察，分析工具，数据资源的问题。
中间是各类问题的应用样例，从这个思路出发，这是通用性的数据产品体系，而并非您的数据产品体系。
通过对公司的数据资产盘点，数据流程梳理，数据产品资源，数据职能规划和当前痛点解析才能具体按着3种定位有所侧重的规划您的数据决策工具需求及数据平台建设规划。
五、LAST BUT NOT LEAST
基于透彻的数据决策和运营过程的理解而制定的数据产品规划及落地，在小珠有效的经验中都是非常漫长和曲折的，厚积薄发，综合考量。同时需要考量的是：
1. 冰山下的苦活，脏活和累活
现代企业的激励体系经常给人带来一种倾向，都愿意打通直接业务价值进行闭环，即不愿意为饭店切菜，选料，而愿意炒菜甚至直接端上桌子。但恰恰数据体系需要更多的服务原材料的精选，甚至梳理规范指标规范机制。为业务，产品和运营做好数据资源的清洗，统筹和开放。
2. 漫长的体系成熟，技术平权前，规划好数据职能分布
数据的分析，资源统筹和模型建立需要专业的数据运营，数据分析，数据开发和数据产品职能和能力。
由底层数据直接到业务管理者拖拽决策需要长期的建设和认识达成，即使外采大型软件，也需要在实施的过程中梳理，规划企业数据运营和决策过程中的职能分别，简单的说，运营职能是否需要数据建模甚至基础开发能力？从数据洞察到数据字段见那些职能如何高效配合形成流转机制。
3. 不仅仅业务需要，其他产品对数据的需求会愈加重要
从微观来讲，各个产品经理对于产品规划，业务价值的判断，需要大量业务数据的支持，比如在排序2个产品需求时，哪个的业务影响力大，风险低，价值高直接需要数据支持，而众多项目的分期迭代中，最终业务效果的达成直接需要对功能相关的业务运营数据的分析。
比如某个洞察发现的线索给销售，建议其联络客户，发现销售并不热衷联络，经过联络数据分析后发现，新销售资源有限比较珍惜新的洞察线索，所以在修正迭代该洞察获取的线索仅仅分配给新的销售，从而达到了更好的效果。
从中后台产品的发展趋势讲，各个产品都朝着数据化，智能化的方向发展，产品对数据模块对数据智能模块的调用需求会成为常态。
本文撰写中感谢：老普及张晔同学的专业指导！
本文由 @小珠CRM 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
