資料專案風險-都在為別人著想

場景：一個專案，調研公司領導，領導說，資料很重要，讓下面的人踴躍參加會議，討論需求，一定要在日常工作中把資料用起來。好，再去調研公司部門管理者和關鍵業務人員，說，我們哪有什麼需求，還是先看看領導有什麼需求吧，領導要看什麼我們就看什麼，領導要我們看什麼我們就看什麼。每個人都在為別人著想，都覺得別人需要，自己不需要。

這是什麼情況？怎麼辦？很多時候，我們會這麼說：這是公司立的重點大專案，領導親自督辦，非常重視，就是為了要為一線服務，為一線工作提供資料支撐。。。來，沒關係，你現在沒有需求沒關係，我們聊起來，聊起來就有了。。。以及：領導要求你和我一起，兩週後跟他彙報需求討論情況，我們必須得弄點什麼東西出來吧。。。

好，這樣，專案也就進行下去了。。。

但，實際上，在資料專案初期，當我們經過多方的簡單交流，很快發現這個問題後，我們得要知道，我們在這裡得要停一下，想一想，然後再往前走。

上述情況，代表的是， 領導親自立的這個資料專案，但領導並不認為這個專案是服務於他的，而是服務於下面人的。這實際上是資料類專案的一個巨大風險。

資料專案與erp等業務系統專案不同。erp等業務系統專案一直號稱是一把手工程，沒錯，領導重視，定期聽取彙報，提出要求，就可以了。但他自己不是關鍵使用者。業務系統的核心是業務操作和直接的業務管理，核心使用者是業務人員和一線管理員，領導不是系統使用者，最多隻是輕度使用者。所以，讓下面人來談是問題不大的。但資料專案不是，資料專案首先解決的不是操作問題，而是管理問題，是管什麼、怎麼管、管得怎麼樣和下一步該怎麼管的問題，所以 資料系統首先就是一個管理系統，其核心使用者是管理層。而管理，一般來說，最好是自上而下的。因此， 資料專案是真正的一把手工程，高層領導得作為關鍵使用者之一。

很多時候，可能越是數字化經驗豐富的企業，越是會發生這個問題，為什麼？因為他們以為這只是和之前開展過的若干業務系統建設類似的資訊化專案，又來了一個而已，一切照舊。但實際上差異很大，風險由此埋下。

領導不覺得自己的工作要靠資料來支撐，不覺得自己要在系統中，作為使用者，直接看到對自己有用的資料，支撐自己的日常決策。這會帶來：

傳統的向上報告體系，至少在上層，沒有發生變化，管理層還是要提交紙面報告給領導。

既然仍是紙面報告，那麼就是人工製作的，可手工調整的，那麼就還是原來的工作模式和方法，系統中能不能直接出，系統中的資料對不對，及不及時，配套的工作流程和機制是否要改，就變得沒那麼重要了。

甚至報告仍然是傳統的文字稿為主，做了什麼為主，定性效果為主，而不是客觀數字為主。沒有壓力讓報告發生改變，也就沒有動力要改變自己工作的舒適區。

領導如果會指著系統裡面的資料問下面的人，這個數是怎麼回事，為什麼這麼低？下面的人自然就會開始關心繫統裡面的這個數字。

如果連領導都認為資料，或者數字化的資料，對自己的工作沒什麼用。下面的人又怎麼會覺得對自己有用呢？

如果領導並沒有覺得要改變自己的工作習慣和模式，下面的人又怎麼會覺得自己要改呢？

如果領導沒有自上而下的管理變革的要求，不管是風格的改變、效率的提升還是精細度的深化，下面的人又怎麼會自覺的改進自己的風格、效率和精細度呢？

管理，一方面當然要靠自驅，另一方面也靠自上而下的壓力。缺乏後者，往往就會停滯不前。

而資料專案，往往因為缺乏領導對自我改變的訴求，而只寄希望於下面的人自行改變，導致無果而終。這裡的無果而終，不是說做不下去，沒報表需求，專案失敗。更多的情況是，下面人配合顧問討論，這個可以，那個也可以，這個也做一個吧，可能會用上。。好，提了，也做了，大量報表，但上線之日就是被打入冷宮之日。沒有人會真的看。

所以，資料專案是管理專案，是管理變革專案，首先最好談一談領導自身想要什麼，想改什麼。

總結：

風險識別

1、領導有沒有資料驅動決策的自驅力

2、下級有沒有資料驅動運營的自驅力

3、領導有沒有給下級帶來顯性的變革壓力

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

風險處理

1、說服領導以身作則，從我做起。

2、以管理駕駛艙、數字報告和經濟執行分析會為抓手。

3、將資料專案明確定義為管理專案，從管理提升入手。