一場關乎未來IT人飯碗的爭論：如何量化IT建設的價值？

內容大綱

1. 要積累數據

1.1. 要有IT系統上線前的數據

1.2.要有IT 系統上線後的數據

2. 需要解讀數據對比的邏輯和方案

2.1.誰來提解讀方案

2.2.解讀哪些內容

2.3. 怎麼解讀

2.4.IT部門如何主動承擔解讀分析工作

3. 需要核心部門、人員審核確認解讀邏輯和方案

3.1.誰來審核方案

3.2.審核哪些內容

3.3.怎麼審核

3.4.IT部門如何主動配合審核

4. 需要部門、人員監督執行 IT 項目規劃的實施，確保業務部門有效執行

4.1.誰來監督

4.2.監督哪些內容

4.3.怎麼監督

4.4.遇到問題如何改進

4.5.IT部門如何主動配合

上一篇文章呢《挑戰！ 怎麼確定企業利潤的變化和IT建設有直接關係？》，聊了挺多 IT 的價值，說來說去，都是在推銷一個理念「IT 建設價值巨大」，那這個「大」究竟有「多大」呢？其實筆者也每個出確切答案，只是提供了從不同的維度和視角來衡量審視這個「大」。筆者這裡正在調研一些價值量化的思路，也希望能和大家多多交流，這裡我做了個分解圖，大家可以從文末看到。總體來說，量化的思路就是先積累原始數據，讓相關提出需求的部門給出他們認可的量化維度和大致的量化標準，然後根據市面上的專家意見對其進行調整，最終形成一個企業內部可以執行的起來的量化模型。

簡單粗暴點理解的話，可以先按照這個公司的經驗來執行。

在需求評估階段

1，在不改變業務流程和工作流程的前提下，算出節省的人力和時間，這個是可以精確到月節省工資支出的

2，不改變成本支出的前提下，算出管理人員節省的管理成本，包含物料和人力的管理，這個也是可以按照月工資/月工作小時來精確的

我們主要做公司內部的業務開發，所以從節約上考慮，節省金額必須寫進需求文檔里的，否則不開發。

對，我們 IT 人，就要開始這麼牛氣起來！（呵呵，內心是這樣想的~）

要積累數據

企業做量化分析，很重要的一環就是企業大數據對比分析。那麼筆者建議，我們要做的第一步就是積累數據。這裡建議的「積累數據」並不是說要求企業一定要有這樣那樣的現成數據才能啟動和量化，而是我們要爭取在後期 IT 系統運維的過程中，來達到這種用數據對比說話的狀態。

那麼我們都需要哪些數據呢？簡單來說，主要需要的是 IT 系統上線前和上線後的數據。這裡面筆者詳細說一下這些數據具體是什麼，以及如何採集和利用，以方便大家在實際操作中可以用起來。

1.1 要有IT系統上線前的數據

需要哪些數據

我們一般需要哪些數據呢？筆者大致將其分兩類，一類是企業內部管理流程效率數據，一類是企業外部綜合評價數據。

企業內部管理效率數據是指方便用時間和資金來衡量的企業管理流程效率數據。這裡的關鍵在於「方便衡量」。這裡舉幾個例子來說說哪些數據符合這些要求，以及什麼是「方便衡量」。

以周報和月報來說，企業至少有兩種場景下會用到。第一種，是領導在辦公室或者手機上及時查看；第二種，是管理層的經營管理會議。那麼第一種主要是領導個人決策，下面彙報。第二種主要就是群策群力、通過會議來發現伸長、經營中的問題，解決問題。

這裡面一個重要的「方便衡量」的數據就是周報和月報的生成時間。比如月報，是每個月的1號就能出來上個月月報，還是每個月10號甚至15號才能出來上個月月報？自家企業對這個月報延後的容忍度是多少？在多大的IT 建設投入下，企業願意將月報及時度提高到每月3號？

這些問題，先從自家企業了解清楚，數據擺出來自然就會得到一部分人的支持。

同樣類似例子，一個分公司或者子部門，出現了業務問題，多久能夠反饋到領導層，這個流程效率也是「方便衡量」的。在一些生產企業，進出原料，審批流程的執行時間，這些也是「方便衡量」的。

在這些流程效率的改善價值上，我們或許不必給領導過多分析彙報效率提高的價值，領導心中自有賬本。我們可以產嘗試將這些數據落實到IT 項目報告中，並得到相關領導的確認即可。

第二類，說的是企業外部綜合評價數據。這裡重點指得是我們的客戶反饋、用戶反饋、競爭對比等方面的數據。比如通過IT系統建設，客戶體驗提升了多少，為多少訂單提供了支持服務，用戶投訴量下降了多少，及時獲得哪些競爭對比數據用於改善了自己企業的產品和服務，甚至通過系統避免了多好訂單的損失。這部分數據，主要是需要 IT 主管和業務主管，共同合作來完成。

上面所說的這些數據，很多都是企業的 Excel 文件中或者歷年的工作彙報中，有些 IT 建設和維護較好的企業，甚至在資料庫中可以直接提取到。

沒數據我們也要「造數據」

那麼，如果企業上 IT 系統前，很難找到上面這些數據怎麼辦？解決辦法是：我們自己「造」。自己「造」數據，肯定不少人都犯難了，甚至很排斥，怎麼可以「作假」呢？其實，這不是作假，而其實合理的量化手段。筆者從四個步驟和大家講一講。

第一步，我們就要確定「造」哪些數據。前面有提到兩大類數據：企業內部管理流程效率數據和企業外部綜合評價數據。筆者建議，我們重點從企業內部管理流程效率數據入手，先搞定這些數據。因為這些數據相比企業外部數據更客觀、更方便採集、更容易獲得公認，這樣也就方便我們啟動和執行量化工作。

第二步，我們怎麼「造」數據。前面剛說了，咱們重點是放在企業內部管理流程效率數據。其實這些數據，在企業內部是真實存在的，只是很多時候，都是停留在每個員工個體的腦海了和一些直接主管人員的工作彙報里。我們要做的，就是先擬定需要採集的數據項，並初步給出「數據」。

比如說：物料進出的平均審批時間 A 小時；某一個級別的領導每天處理某事物的平均時間是 3 小時；某部門和子公司平均每次處理某問題（比如客戶投訴）需要100 小時和10萬元財務損失。

這些數據，我們先「造」出來第一版，然後到不同的業務人員和部分去溝通調研、核對調整，階段性目標是通過這個初版調研，找到能夠給出相對準確的數據的人，找到能夠最終審批數據的人。最終目標是形成一個大家公認的效率數據標準。

第三步，誰來真正地「造」數據。第二步里，我們已經初步的「亂編」了初版數據，第三步這裡就是真正的「造」合理的數據了。筆者建議，是 IT 部門推動業務部門調整我們之前的初版數據，然後儘可能的給出每個數據項的明確數據，或者給出每個數據項的2~3個參考的數據檔。比如我們無法確定物料的平均審批時間的話，那麼我們起碼可以確定類似2小時和4小時兩個選項，交給真正的審批人員來最終核定數據的合理性。

第四步，誰來審批「造的數據」的合理性。坦白來說，這一步，走起來或許會不容易。筆者建議這裡由 IT 部門主管去主動推動，IT 部門主管主要的溝通對象就是某個業務部門主管，先從單個業務部門探索嘗試。其實這一步，主要是業務部門和 IT 部門的利益平衡。如果業務部門說這個、那個數據不認可，那麼 IT 部門就有理由和底氣說，這塊工作向後排，其他工作排在前面來。（其實內心戲，都懂得。就是業務領導不認可某塊的IT 建設話，IT 部門就無限期延後這塊，有限滿足其他需求。）

1.2 要有IT 系統上線後的數據

需要哪些數據

我們一般需要哪些數據呢？筆者大致將其分兩類，一類是企業內部管理流程效率數據，一類是企業外部綜合評價數據。

IT系統上線後，需要的也是前面兩大塊數據：企業內部管理流程效率數據和企業外部綜合評價數據。這裡要注意兩點，第一點，是內部管理流程效率數據，要在 IT 系統設計之初就考慮如何採集，同時最好提供可視化的界面直接生成效率數據對比報告；第二點，是要重點搜集企業外部綜合評價數據，或者就是企業案例故事。

針對企業案例故事，單獨聊一下。舉個例子，江汽物流公司，通過流程監控，IT 系統及時發現 GPS異常事故，並在 IT 部門的方案下妥善解決了這個問題，發現問題和解決問題的效率顯著提高，業務人員和主管領導看得見的成果。再舉個栗子，眉州東坡通過分析不同規模的店面的盈利能力，最終的出來開中小店面盈利能力最好，一個報告交給董事會，直接改變了這些發家創始人的認知，新開店面大店改中小店後，企業財務報表董事層面清楚看得見。

數據要精確到什麼粒度

既然要採集這些數據，那麼數據具體要精確到什麼粒度呢？這裡筆者給一下建議，有兩個原則：一是採集粒度不低於IT 系統上線前；二是跟錢掛鉤的數據粒度要高於 IT 系統上線前1~2個水平。

比如，IT 系統建設之前能精確到事故處理費用為2.3萬元，精確到千元。那麼IT 系統建設後，事故處理平均費用就得精確顯示為1.47萬元，甚至是1.473萬元。IT 系統建設前每天審批需要3小時，上線後的處理時間至少要精確表示為1小時。

如何分階段定性、定量統計數據

IT 系統上線後，真正分析和挖掘其價值，在於持續的運維與更新。我們分析 IT 建設的價值也是如此，要不斷的進行分析的方式方法調整。筆者建議統計數據主要分兩類，一類是前面主要說的定量分析，另一類就是主觀上的定性分析。比如。IT 建設的價值需要客戶、用戶、業務部門給出主管反饋。這些反饋就是定性的評價，通過這些定性的評價，可以積極推動 IT 建設的持續進行，不斷地把 IT 部門的資源和精力集中在企業最需要、公司價值最大化的地方。

需要解讀數據對比的邏輯和方案

IT 系統上線前和上線後，積累了合適的數據。接下來就是進行合理、適當的解讀。那麼誰來解讀、解讀什麼、怎麼解讀等問題就迎面而來了。筆者建議，是 IT 部門來解讀。當然，這個解讀報告是從低到高，從部分到整體不斷匯聚而來的。也就是說，需要 IT部門的每個模塊的負責人分別對接不同的業務部門的相關人員，先解讀每個子模塊的數據對比分析，然後再逐級匯總，形成一個整體的報告。

具體要解讀哪些內容，其實前面已經提到，主要是企業管理流程在哪些方面都有了提升力，具體提升了多少，這些提升對企業具體有哪些價值。

至於怎麼解讀，總體來說：結論先行，以上統下。就是說，先說觀點和結論，然後用幾個實例和幾張數據對比報表來證明觀點和結論。這點有一本書《金字塔原理》推薦大家來閱讀，或者可以留言從筆者這裡拿到讀書筆記。

另外，建議IT部門主動承擔解讀分析工作。也就是說，IT 部門主動和業務部門溝通和採集解讀的數據和業務邏輯，主動撰寫工作彙報，最後主動彙報分析報告。同時，也就意味著要主動承擔 IT項目建設的責任。

需要核心部門、人員審核確認解讀邏輯和方案

數據的解讀方案草擬出來後，誰來審核方案，審核哪些內容，怎麼審核，這些問題要考慮，但一般企業都自有審核流程來完成，起碼之前的月報彙報體系就可以完成這種審核。筆者建議IT部門多主動配合審核，比如直接安排專人對接審核，提供材料、保持溝通；比如成立專門的3人左右小組，對審核跟進配合工作負責，儘可能由這個小組來完成所有配合工作，而不影響 IT 部門的其他工作。

需要部門、人員監督執行IT項目規劃的實施，確保業務部門有效執行

企業核心部門審批通過的數據解讀方案，如何真正落地有效執行呢？筆者建議相應的監督部門來進行監督工作。具體監督哪些內容，需要 IT 部門和業務部門共同制定，但IT 部門主導牽頭，同時要有關鍵 IT建設階段目標作為其中的監控點。

到這一步，其實特別要注意溝通。雖然我們已經做好可解讀方案和監督方案，但整個方案並不一定每個執行的員工都清楚，甚至有些會因為增加個人工作量而拒絕執行。IT部門要主動起來，勤於溝通，勤於核對數據採集和業務執行的關鍵動作。因為，在 IT 項目建設初期，業務部門的相關執行人員並不一定能夠從中獲益，很可能產生抵觸情緒，導致數據採集不到位，或者相關操作流程不到位，最終導致部門流程不走系統，IT 系統形同虛設。IT 部門在系統建設前期，主動承擔起來責任，有利於 IT 項目真正有效落地。

其實，筆者和很多企業 IT 主管聊起來，也知道他們吃力的地方。上文的建議，有些或許對你也很吃力。不過呢，IT 建設，我們不上誰上呢？我們不主動誰主動呢？在有價值的項目真正起效果之前，業務部門在企業中的地位依然是超然的。

侃侃而談數千言，其實也是筆者積累的一點經驗和草率的建議。畢竟沒有當面溝通，沒有實地去調研你的企業，確實不好出來特別有效的對策。筆者自身也是在 IT諮詢公司從事企業管理研究，缺少實際進行業務管理和 IT 系統建設的經驗，所謂心得體會也多來自和不同企業人員的調研走訪。如果有疏漏或者錯誤，歡迎留言，我們一起交流。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！