场景：一个项目，调研公司领导，领导说，数据很重要，让下面的人踊跃参加会议，讨论需求，一定要在日常工作中把数据用起来。好，再去调研公司部门管理者和关键业务人员，说，我们哪有什么需求，还是先看看领导有什么需求吧，领导要看什么我们就看什么，领导要我们看什么我们就看什么。每个人都在为别人着想，都觉得别人需要，自己不需要。

这是什么情况？怎么办？很多时候，我们会这么说：这是公司立的重点大项目，领导亲自督办，非常重视，就是为了要为一线服务，为一线工作提供数据支撑。。。来，没关系，你现在没有需求没关系，我们聊起来，聊起来就有了。。。以及：领导要求你和我一起，两周后跟他汇报需求讨论情况，我们必须得弄点什么东西出来吧。。。

好，这样，项目也就进行下去了。。。

但，实际上，在数据项目初期，当我们经过多方的简单交流，很快发现这个问题后，我们得要知道，我们在这里得要停一下，想一想，然后再往前走。

上述情况，代表的是， 领导亲自立的这个数据项目，但领导并不认为这个项目是服务于他的，而是服务于下面人的。这实际上是数据类项目的一个巨大风险。

数据项目与erp等业务系统项目不同。erp等业务系统项目一直号称是一把手工程，没错，领导重视，定期听取汇报，提出要求，就可以了。但他自己不是关键用户。业务系统的核心是业务操作和直接的业务管理，核心用户是业务人员和一线管理员，领导不是系统使用者，最多只是轻度使用者。所以，让下面人来谈是问题不大的。但数据项目不是，数据项目首先解决的不是操作问题，而是管理问题，是管什么、怎么管、管得怎么样和下一步该怎么管的问题，所以 数据系统首先就是一个管理系统，其核心用户是管理层。而管理，一般来说，最好是自上而下的。因此， 数据项目是真正的一把手工程，高层领导得作为关键用户之一。

很多时候，可能越是数字化经验丰富的企业，越是会发生这个问题，为什么？因为他们以为这只是和之前开展过的若干业务系统建设类似的信息化项目，又来了一个而已，一切照旧。但实际上差异很大，风险由此埋下。

领导不觉得自己的工作要靠数据来支撑，不觉得自己要在系统中，作为用户，直接看到对自己有用的数据，支撑自己的日常决策。这会带来：

传统的向上报告体系，至少在上层，没有发生变化，管理层还是要提交纸面报告给领导。

既然仍是纸面报告，那么就是人工制作的，可手工调整的，那么就还是原来的工作模式和方法，系统中能不能直接出，系统中的数据对不对，及不及时，配套的工作流程和机制是否要改，就变得没那么重要了。

甚至报告仍然是传统的文字稿为主，做了什么为主，定性效果为主，而不是客观数字为主。没有压力让报告发生改变，也就没有动力要改变自己工作的舒适区。

领导如果会指着系统里面的数据问下面的人，这个数是怎么回事，为什么这么低？下面的人自然就会开始关心系统里面的这个数字。

如果连领导都认为数据，或者数字化的数据，对自己的工作没什么用。下面的人又怎么会觉得对自己有用呢？

如果领导并没有觉得要改变自己的工作习惯和模式，下面的人又怎么会觉得自己要改呢？

如果领导没有自上而下的管理变革的要求，不管是风格的改变、效率的提升还是精细度的深化，下面的人又怎么会自觉的改进自己的风格、效率和精细度呢？

管理，一方面当然要靠自驱，另一方面也靠自上而下的压力。缺乏后者，往往就会停滞不前。

而数据项目，往往因为缺乏领导对自我改变的诉求，而只寄希望于下面的人自行改变，导致无果而终。这里的无果而终，不是说做不下去，没报表需求，项目失败。更多的情况是，下面人配合顾问讨论，这个可以，那个也可以，这个也做一个吧，可能会用上。。好，提了，也做了，大量报表，但上线之日就是被打入冷宫之日。没有人会真的看。

所以，数据项目是管理项目，是管理变革项目，首先最好谈一谈领导自身想要什么，想改什么。

总结：

风险识别

1、领导有没有数据驱动决策的自驱力

2、下级有没有数据驱动运营的自驱力

3、领导有没有给下级带来显性的变革压力

三者皆有，上佳；三者皆无，躺平。

风险处理

1、说服领导以身作则，从我做起。

2、以管理驾驶舱、数字报告和经济运行分析会为抓手。

3、将数据项目明确定义为管理项目，从管理提升入手。