近四年，我以顾问身份深度参与过二十多家企业的数据转型项目，也和上百位首席数据官（CDO）、数据分析负责人做过一对一交流。我观察到一种普遍的困境：企业设立CDO岗位后，数据团队规模扩大、数据平台建设提速、报表数量翻了几倍，但CEO对数据部门的评价反而更低。问题出在哪里？出在职责定义本身。很多CDO把工作重心放在“建设数据能力”上，却忽略了企业真正需要的是“改变决策方式”。

这篇文章，我想用第一人称视角，结合真实项目中的踩坑经历和复盘数据，系统拆解数据分析场景下的CDO职责和首席数据官的工作内容，并给出一套可以直接复用的判断框架。

核心结论

在拆解具体职责之前，我必须先把最核心的观点讲清楚：CDO的工作对象不是数据，而是决策。一个CDO的合格与否，不取决于数据平台的先进性，不取决于数据团队的规模，而取决于企业里有多少关键决策因为数据而发生了改变。

我在多家企业都看到过这样的现象：数据部门辛辛苦苦建成了企业级数据仓库，上线了精美的管理驾驶舱，但业务负责人依然靠经验拍板，甚至依然用Excel手工汇总数据。数据团队抱怨业务不配合，业务部门抱怨数据不准、口径太乱，最终CDO成为夹在中间的矛盾焦点。这个问题的根源是CDO把职责理解错了。

CDO的三大核心职责

基于我和同行们的一线经验，我把CDO的核心工作内容归纳为三件事。

（1）决策点扫描：绘制企业的决策地图

CDO上任后最不该做的事，是急着盘数据资产、做数据治理、采购数据工具。第一优先级是找到企业里真正影响收入和利润的决策点。比如：定价决策、补货决策、销售目标分解、促销方案选择、渠道投放分配、产品组合优化。这些决策点分布在不同的业务环节，有各自的决策频率和决策金额。

我常用“决策卡”的方式梳理决策点，访问业务负责人时会问五个问题：过去一个季度你做过最关键的三个决策是什么？这些决策通常什么时候做、需要谁参与？你现在主要依赖什么信息做判断？如果有一个“完美信息”摆在面前，你希望它长什么样？如果这个决策做错了，企业大概损失多少？把这些答案汇总起来，就能画出一张企业真实的决策地图。

（2）决策链路闭环：让数据进入决策流程

找到决策点之后，CDO的核心工作是让每个关键决策点都形成闭环。闭环包括五个环节：识别决策需求、准备好数据输入、输出分析和建议、推动业务执行、收集执行结果并复盘。很多企业的数据工作断在第三环，分析报告写完了，业务负责人看一眼觉得有道理，但没有后续动作，也没有复盘反馈。CDO要确保的不是“报告被阅读”，而是“决策被影响”。

（3）决策资产沉淀：把经验变成可迭代的资产

企业里最有价值的数据资产不是数据本身，而是被验证过的决策规则。比如某个品类在什么库存水位下必须补货、某个客户群体在什么条件下转向竞品的概率最大。这些规则以前锁在资深员工的脑子里，CDO要做的，是通过数据分析和业务共创，把它们变成可以迭代的计算逻辑、评分模型或业务策略。这才是真正的数据资产。

CDO用什么指标证明自己的价值

我建议CDO不要用“数据覆盖率”“报表及时率”“数据准确率”这类过程指标作为核心KPI，因为它们和业务结果之间没有直接因果关系。真正能证明CDO价值的指标有三个：

• 决策覆盖率：企业年累计决策金额中，有数据输入的比例。这个比例越高，说明数据工作覆盖面越广。
• 决策采纳率：数据建议被业务负责人明确采纳并执行的比例。这个比例衡量的是数据部门的可信度。
• 决策反馈率：带有明确后验反馈和复盘记录的决策比例。没有反馈，就没有迭代。

在我的咨询实践中，当这三个指标同时向上走时，数据团队在组织内的话语权几乎没有例外地随之提升。很多CDO失败，不是因为数据能力不行，而是因为从未把这些指标摆到台面上。

背景和真实场景：CDO是如何被架空的

你可能觉得我前面说的都是“正确的废话”，那我来还原一个真实场景，看看CDO最常见的困境是怎么发生的。

去年，我接手了一家区域连锁零售企业的数据咨询项目。这家企业年销售额超过6亿元，数据部门有16个人，数据平台已经建了三年，底层接入了ERP、POS、会员系统、供应链系统，技术人员配置也不算弱。CDO是老板花高薪从外企挖来的，入职前信心满满。但入职三个月后，他发现自己被彻底架空了。业务部门的周会不邀请他，财务部自己搞了一套手工报表，门店督导还是靠Excel巡店，数据团队每天接到大量临时取数需求，做到凌晨也做不完。

我们做了两周的现场访谈，发现了一个典型的恶性循环：

业务部门自己手工做报表，因为信不过数据部门的口径；数据部门发现业务不配合，就更加埋头做技术建设，结果离业务越来越远；CEO看到数据部门迟迟没有产出业务价值，开始质疑CDO的工作能力；CDO为了证明自己不是在“吃干饭”，把更多资源投向BI看板和指标大屏，希望让管理层“看见”数据，但管理层发现看完大屏依然不知道该怎么办。

在这个循环里，所有人都在努力工作，但没有人做错什么，企业却整体停滞。

需求流转的漏损效应

我们统计了这家企业一个月的数据需求流转情况，结果让所有人大吃一惊：业务部门实际提出的数据需求有97条，经过IT部门和技术团队的排期，实际交付了63条；这63条里，因为口径不一致需要返工的有19条；真正被业务人员打开查看并放进决策材料里的，只有27条；最终转化为业务动作并追踪效果的，不到8条。

97条需求，最后只有8条真正影响了决策。数据团队觉得自己每天都在忙，但组织感知到的价值不到需求的10%。这不是技术问题，也不是个人能力问题，而是数据部门把自己定位成了“需求交付中心”，而不是“决策支持中心”。

CDO的职责，不应该被业务部门的需求牵着走。CDO必须主动筛选需求、主动定义决策场景，甚至主动拒绝需求，那些和关键决策无关的需求，无论多紧急，都不应该是数据团队的第一优先级。

数据部门为何沦为“报表外包团队”

在另一家制造业企业，我听到数据团队自己吐槽：“我们现在就是报表外包团队，业务说什么我们做什么，做完也没人感谢我们。”这句话背后有一个深层原因：数据团队和业务团队之间没有建立“决策共识”，数据团队不了解业务决策需要什么，业务部门也不清楚数据能帮到什么。

结果是数据团队接了很多低价值需求，但高杠杆的决策点没有人服务。比如生产计划排期、原料采购定价、渠道库存分配，这些决策金额动辄上千万，却很少出现在数据团队的工作清单里。而报销分析、考勤统计、员工离职率这类低杠杆需求，反而占用了大量人力。

CDO要做的第一步，就是停止用“需求满足率”来考核团队，改用品“决策价值覆盖”来筛选工作内容。数据团队的价值不在响应速度，而在对决策的影响力。

常见误区：为什么很多CDO活不过十八个月

根据我接触到的样本，CDO的平均任期比CIO还要短，很多人在一年半左右就离开了。我总结了五个最常见的职责认知误区，这些误区是CDO失败的真正原因。

误区一：CDO是数据分析部门的负责人

这是最常见、也最致命的认知错位。如果CDO只是一个高级数据分析经理，领着团队做报表、跑模型、建看板，那和原来的数据部门负责人没有任何区别。CDO需要承担的职责是组织变革层面的，他要把数据嵌入经营流程，推动管理层用数据做决策。

判断一个CDO是否在做总监级的工作，只看一条就够了：他每周和高管团队一起讨论业务决策的时间是否超过10小时。如果每天的时间都花在分析报告审核和技术方案评审上，这个CDO基本等于一个“大号数据总监”，而不是一个高管层成员。

误区二：CDO是数据治理委员会主席

数据治理是CDO工作的一部分，但不能成为主体。很多CDO上任后第一件事是发布数据标准、主数据规范、元数据管理办法，然后拉着各业务部门开会签字。结果呢？标准发布了大半年，业务系统里还是各用各的口径。

这倒不是数据治理本身不重要，而是它不能作为CDO的起点。业务部门对“标准”没有感知，但他们对“我的指标口径为什么和财务对不上”有痛感。CDO应该从某个具体决策场景切入，把数据治理嵌在场景里悄悄推动。我在一个项目中要求管理口径统一，业务部门配合度很低；后来我们从“单店盈利分析”这个具体场景切入，把收入、成本、费用的定义在场景里对齐，业务部门为了看到准确的店效排名，反而主动推动了数据治理。

误区三：CDO要用数据中台证明价值

近五年来，不少企业斥巨资建设数据中台，把CDO推到中台项目的甲方位置。这个误区的根源是：中台是成本中心，不产生决策结果。中台建得再好，对业务没有直接影响。很多企业的数据中台变成了一个“巨大的数据垃圾桶”，数据接进来了，但没人用。

我并不是反对数据中台。如果企业已经有明确的高频决策场景，中台建设是必要的支撑。但场景不明的企业建中台，本质上是在给业务问题找技术答案，方向就错了。CDO的正确姿势是：先有场景，再有中台；先有价值闭环，再有平台沉淀。

误区四：CDO要亲自交付数据模型和分析报告

在团队小于10个人的阶段，CDO亲自建模、亲自搭看板是不得已的选择。但一旦组织规模扩大，CDO必须从执行层跳出来，去处理跨部门协调和决策机制设计。我见过一些CDO，本人技术功底很强，所有关键分析都亲自上阵，结果数据团队的其他人得不到成长，CDO自己成了瓶颈。

CDO要建的是“决策系统”，不是“个人能力”。哪怕CDO自己的建模能力弱一点，只要他能把业务负责人拉到桌前一起定义问题，把数据团队和分析师的工作对准关键决策，这个组织的长期数据能力一定比“靠CDO一个人输出”的组织强得多。

误区五：CDO要对所有数据需求一视同仁

我刚入行时，也是一个“有求必应”的数据负责人。后来我意识到，把所有需求都排期交付，实际上是在纵容业务部门的低效。CDO的重要职责之一是“拒绝”：

• 拒绝那些和关键决策无关的取数需求；
• 拒绝那些口径未定义的临时分析；
• 拒绝那些没有明确使用场景的数据平台功能；
• 拒绝那些只是“想要看看”而不是“要做决策”的报表。

拒绝不是不配合，而是把资源集中在最有杠杆价值的工作上。我后来给团队定了一条规则：任何需求都要回答“这个数据会影响哪个决策”，答不上来的需求一律不接。团队的工作效率反而提升了。

专业判断逻辑：CDO工作的评估框架

如果CDO的核心职责是改变决策方式，那么怎么判断什么值得做、什么不值得做？我有一套自己的判断框架，在多个项目中反复迭代后形成，供你参考。

用决策价值公式筛选场景

决策价值 = 决策金额 × 决策频次 × 数据提升度。决策金额越大、决策频次越高、数据对决策质量的提升空间越大，这个场景就越值得CDO投入。

举一个实际例子。在某零售企业，我们梳理了6个关键决策点：

• 补货决策：月均决策26次，单次决策金额约500万元，数据支撑度较高；
• 定价决策：月均决策1次，单次决策金额约150万元，数据支撑度很低；
• 开发商选择：月均决策2次，单次决策金额约300万元，数据支撑度极低；
• 促销决策：月均决策4次，单次决策金额约80万元，数据支撑度中等。

这里有一个关键判断：数据支撑度低且决策金额高的场景，通常不是“数据基建”问题，而是“决策认知”问题。拿定价决策来说，业务负责人完全依赖经验和竞品情报，市场上不是没有数据，而是企业没有形成用数据定价的习惯。CDO介入这个场景，不需要建数据中台，只需要把价格弹性分析、竞品价格追踪、历史促销效果对比整理成一张决策清单，并推动管理层在定价会上过一遍。

后面的结果验证了这个判断：定价决策场景在三个月内带来了1.8%的毛利率提升，而补货决策场景虽然数据支撑度高，优化空间却有限。这个对比正好说明了“数据提升度”在筛选场景时的作用。

用“决策-数据映射表”建立组织连接

筛选出关键决策点后，CDO需要为每个决策点建立一张映射表。这张表包含六个要素：决策名称、决策频次、决策责任部门、输入数据、数据负责人、输出指标。

以“补货决策”为例：

决策名称：门店日常补货。决策频次：每周两次。责任部门：供应链运营部。输入数据：SKU销量、库存数量、在途库存、供应商交期。数据负责人：供应链数据产品经理。输出指标：可售天数、补货建议量、缺货率。

这张表看起来简单，但在组织里非常有效。一是它让所有相关方看清数据从哪里来、由谁负责、最终为哪个决策服务；二是它把抽象的“数据责任”落实到具体的人，避免出现指标出问题互相推诿的情况；三是它让CDO可以基于映射表做差距分析，优先补齐那些数据缺失但决策重要的环节。

用“指标三明治”评估数据团队健康度

我习惯把数据团队的工作分成三层，类似一个三明治：

最上层是“决策结果指标”，包括收入、利润、周转率、流失率等业务结果。这一层由业务负责人认领，CDO负责提供数据支持。

中间层是“决策过程指标”，包括决策覆盖率、决策采纳率、决策反馈率、决策响应时间。这一层是CDO的直接责任指标，用来评估数据工作是否真的进入了决策流程。

最底层是“数据基础设施指标”，包括数据质量、链路稳定性、指标口径一致性、任务及时率。这一层是数据团队的技术底线指标。

很多数据团队的问题，是只盯着最底层，把数据质量当成最终目标。CDO必须把重心放在中间层，同时用最底层的质量指标作保底。如果一个数据团队花了80%的时间在底层，而中间层的指标长期没有改善，说明CDO的精力投错了地方。

用“能力雷达”识别CDO自身的能力缺口

CDO这个岗位对能力的要求很矛盾：技术上要懂架构和算法，业务上要懂经营和流程，组织上还要有极强的跨部门协调能力。

在我和高管团队讨论CDO候选人的时候，喜欢用五个维度来评估：

• 业务理解力：能不能准确说出企业的主营业务逻辑和核心经营杠杆；
• 数据工程能力：能不能判断数据链路、数据架构和算法方案的可行性；
• 组织推动力：能不能让业务部门心甘情愿地配合数据项目；
• 财务回报意识：能不能把数据项目的投入转化成财务语言；
• 风险合规意识：能不能在数据安全和商业价值之间把握好平衡。

不同成熟度的企业对这五个维度的要求权重不同。初创期企业最需要数据工程能力，因为要快速搭出数据产品；成熟期企业最需要财务回报意识，因为要让数据项目在预算委员会上活下来；传统转型期企业最需要组织推动力，因为最大的阻力是业务习惯而不是技术。

具体案例与数据观察：CDO如何把职责落地

前面讲了很多框架，这里我用两个真实案例，说明CDO职责落地时的细节和结果。这些案例里的企业都做了脱敏，但关键数字是真实的。

案例一：补货决策改造释放四千万元库存资金

某消费电子配件分销企业，全国30个仓，4000多个SKU，年销售额6亿元。这家企业的库存金额常年维持在1.2亿元，库存周转天数60天，缺货率却高达24%。采购决策主要靠三个采购经理的个人经验，每个采购经理负责的区域各自为战。

CDO上任后，没有立刻采购预测软件，也没有组建算法团队，而是先做了一件事：把补货决策流程重做了一遍。他找到供应链总监和采购经理，共同梳理出影响补货决策的四个核心指标：SKU周销量、库存可售天数、供应商交期、安全库存水位。然后让数据团队把这些指标做成了所有采购经理共用的一个补货看板。每周五下午，采购、销售、财务三方开30分钟的补货对表会，对着同一套看板逐项过异常SKU。

一开始，采购经理们觉得这个看板多此一举，因为很多指标他们“心里有数”。但看板跑了六周后，一位采购经理发现自己的某个区域SKU周销量连续三周下滑，而其他区域没有类似问题。进一步排查后发现，是当地新入驻的竞品门店分流了客流。这个发现促使公司对那个区域的门店组合重新做了评估，并调整了采购策略。

六个月的执行结果是：库存金额从1.2亿元降到8000万元，周转天数从60天降到38天，缺货率从24%降到12%。更重要的是，这个项目没有引入任何昂贵的AI算法，只是把决策流程里“看个人经验”的环节换成了“看共同数据”，然后坚持了六个月。

案例二：销售预测项目的真正杠杆是流程而不是模型

第二家案例是一家工程机械代理商，年收入15亿元。企业最大的痛点是销售预测偏差率长期在40%以上，偏差导致主机厂压货和大量资金占用。老板一开始的想法是：请一位顶级数据科学家来建一个销售预测AI模型。

CDO到场后做了一件事：先不建模型，把销售预测这个决策的全流程画出来。他发现流程中存在两个与算法无关的致命问题：一是销售、财务、供应链三方各自做一套预测，数据不一样，开会时互相打架；二是区域销售经理填报预测数据时缺乏责任感，填多少全凭心情，没有人对偏差负责。

CDO的切入方式是对表会机制。每周一上午，销售、财务、供应链、产品线负责人开30分钟的预测复盘会，对比未来12周滚动预测和实际数据。任何预测偏差超过20%的字段，都必须给出书面原因。刚开始销售负责人非常抗拒，觉得这是浪费时间的“数字游戏”。但执行了两个月后，大家发现销售经理填报数据前会主动翻看历史实际值了，因为“填得太离谱会被晒在会议上”。

六个月后，销售预测偏差率从40%以上降到了15%以内，库存资金占用减少了约6000万元。CDO告诉我：“我们到最后也没建机器学习模型，只是让预测成为一个有反馈、有责任的流程。AI模型是加分项，但对这个企业来说，流程机制才是真正的杠杆。”

这个案例给CDO的启示是：不要急着把新技术引入企业，先看看基于现有数据、现有团队的流程机制有没有跑通。很多所谓的数据难题，本质上是管理流程和决策责任的问题。

数据观察：什么样的CDO容易成功

在我接触的上百位CDO和数据负责人中，那些真正站稳脚跟的人有一个共同点：他们都把第一年的时间花在了和业务负责人建立对话机制上，而不是花在写方案和选型上。他们明白，CDO的职责从字面看是“首席数据官”，但从工作内容看，更准确的称呼应该是“首席决策支持官”。

另一个观察是：CDO直接向CEO汇报的项目，业务价值落地速度明显快于向CTO或CFO汇报的项目。原因很简单，CDO推行的是跨部门流程变革，如果不在最高决策层有话语权，数据项目很容易被业务部门的优先级排挤掉。

不同阶段企业的行动建议

不同企业的数据基础、组织形态、资源禀赋差异很大，CDO职责的优先级也应该不一样。我按企业成熟度给出三套建议，每套都包括第一年的具体行动节奏。

初创期和成长期企业：快速见效优先

这个阶段的企业通常没有太多的历史数据，也养不起大团队，老板最关心的是增长。CDO此时不应该做重资产建设，而应该聚焦1到2个高频高杠杆场景，做透一个闭环。

• 第一个月：完成决策点扫描，找到老板最头疼的运营和销售场景；
• 第二个月：搭建最简数据链路，尽量用现成的商业智能和自动化报表工具，不要自己造轮子；
• 第三到九个月：聚焦一个场景，形成“数据输入-决策建议-执行动作-反馈复盘”的完整闭环；
• 第十到十二个月：把验证成功的场景横向复制到其他业务线。

这个阶段最忌讳的是“眼大肚子小”，一上来就开始建中台、建数仓，结果半年过去了业务没感知。快速见效不是为了邀功，而是为了建立信任，给后面的数据建设争取时间和预算。

成熟期企业：指标治理和组织机制优先

成熟期企业最大的问题不是没有数据，而是数据太多、系统太多、口径太乱。这个阶段CDO的首要工作是建立统一的指标口径和决策语言，同时设计一套跨部门的数据协作机制。

• 第一个季度：通读核心业务部门的经营分析报告和指标体系，找出“同一指标不同数字”的重大冲突点；
• 第二个季度：建立“指标解释权机制”，让每个关键指标都有明确的业务责任人和跨部门挑战机制；
• 第三到四个季度：选择一两个公司级别的高频决策场景，比如经营分析会或预算评审会，把数据产品嵌入会议流程，形成“以会带建”的推广模式。

成熟期企业CDO要特别小心“数据治理洁癖”，不要试图一次性把指标标准全部统一。先挑那些在高层会议上经常引发争议的指标下手。比如“活跃用户”这个指标，如果市场部和运营部有不同定义，CDO要组织双方说清楚差异和适用边界，而不是强行定一个唯一口径。

传统转型期企业：试点场景+一把手支持

这类企业通常数据基础薄弱，业务人员习惯于经验决策，数字化转型口号喊了很久但基层不配合。CDO在这个阶段最容易犯的错误就是太着急。我的建议是找一个业务痛点足够大、数据底子相对齐整的场景作为试点。

• 前两个月：做业务访谈，找到业务部门自己都想解决的“难啃骨头”；
• 第三到五个月：把场景做成一个完整样板，让业务方看到数据带来的直接价值；
• 第六到十二个月：把样板案例打造成内部标杆，借助一把手的权威向其他部门推广。

传统企业数据基础差不是问题，真正的问题是基层缺乏对数据的信任。试点场景必须选择能产生“可视化收益”的项目，比如库存降低、损耗减少、客户挽回成功。这些收益一旦发生，比任何宣导都更能改变人员观念。

不同情况下的取舍：CDO如何做优先级判断

CDO面临的很多决策不是“做不做”，而是“先做什么、放弃什么”。我总结了几组最常见的取舍，每一组都给出我自己的优先级建议。

1. 场景与平台：场景先行，平台随行
   很多技术背景的CDO习惯先搭平台，因为平台建设看起来有章法、有里程碑、有技术成就感。但从业务价值角度看，平台是成本，场景是收益。我的建议是：一切平台建设都必须绑定一个具体的业务场景，平台为场景服务，场景成功后反哺平台建设。如果一个平台项目说不清它要服务哪个决策场景，这个项目就应该被推迟。
2. 治理与敏捷：敏捷第一，治理渗透
   数据治理本身没有错，错的是把治理当成“水面上的独立项目”。治理工作应该以“渗透战”的方式嵌在具体场景里。比如在做经营分析项目时，顺手统一收入指标口径；在做供应链项目时，顺手建立物料编码映射。这种方式的治理速度慢一点，但不会引起业务部门的反弹。相比一次性大工程，我宁愿选择“慢渗透”的模式，至少它不会让CDO死在治理项目上。
3. 集中与自助：集中关键应用，开放自助工具

数据团队最容易被临时取数需求拖垮。我建议CDO把团队资源集中在三个地方：核心经营指标看板、关键决策场景的深度分析、数据质量保障。其余长尾需求全部通过自助分析工具、知识库和培训来释放。如果业务人员已经能看懂核心指标看板，并且数据团队提供了清晰的自助分析文档，大多数临时取数需求根本没有必要进入数据团队的任务清单。

从成本角度看，一个临时取数需求平均消耗数据工程师2到4个小时，每月几十个临时需求就会占掉一个全职人力。而把同样的精力投放到自助分析工具的培训和文档建设上，三个月后临时需求会下降一半以上。

自研与采购：优先买成熟工具，不养自研团队

在数据工具选型上，我见过太多企业吃了自研的亏。数据可视化、数据集成、数据质量管理等方向都有成熟的商业化产品，没必要自己从零开发。自研的前提只有一个：市场上找不到满足特定场景需求的产品，或者数据安全要求极高，无法使用外部服务。

这里想强调一点：数据团队的价值不在于会写多少代码，而在于能否把技术变成业务决策的支撑。把宝贵的技术人力花在重复造轮子上，是对数据团队最大的浪费。

合规与共享：合规为底线，共享靠安全机制

CDO在数据安全合规方面承担着越来越重要的责任。一方面，隐私保护法规越来越严格，数据滥用可能带来巨大的合规风险；另一方面，数据只有流通才能产生价值。我的建议是：建立一个明确的数据分级分类体系，根据数据敏感度决定共享方式。比如脱敏后的聚合数据可以在内部广泛共享，含个人身份信息的数据则只能通过安全沙箱和授权机制使用。

CDO要把合规当成数据工作的边界条件，而不是阻碍业务的数据壁垒。明确边界不仅不会降低数据价值，反而会让业务部门更放心地使用数据。

结尾

回到文章开头的问题：CDO的职责到底是什么？我的结论已经很清楚：CDO不是数据技术团队的负责人，不是数据治理委员会主席，也不是数据中台项目经理。CDO是组织里唯一一个对“决策质量”负责的高管。他通过扫描决策点、建立决策链路闭环、沉淀决策资产，让企业的每一个关键经营决策都尽可能建立在数据和事实的基础上，而不是建立在个人经验和部门博弈之上。

如果你正在担任CDO，或者刚拿到CDO的任命，我建议你从下周一开始做一件事：约五个核心业务部门的负责人，每个人聊三十分钟，只问他们一个问题，“过去三个月里，你做过的最重要的决策是什么？你是靠什么信息做出的判断？”然后把答案汇总，找出那些决策金额高、频次高、但数据支撑薄弱的地方。那是你作为首席数据官，真正应该开始工作的位置。

数据分析只是手段，决策质量才是CDO的终极职责。这句话，值得你放在办公桌上。

免费注册

咨询方案

扫码咨询方案