上一篇文章呢《怎麼確定企業利潤的變化和IT建設有直接關係？》，聊了挺多 IT 的價值，說來說去，都是在推銷一個理念「IT 建設價值巨大」，那這個「大」究竟有「多大」呢？其實筆者也沒給出確切答案，只是提供了從不同的維度和視角來衡量審視這個「大」。筆者這裡正在調研一些價值量化的思路，也希望能和大家多多交流，這裡我做了個分解圖，大家可以從文末看到。總體來說，量化的思路就是先積累原始數據，讓相關提出需求的部門給出他們認可的量化維度和大致的量化標準，然後根據市面上的專家意見對其進行調整，最終形成一個企業內部可以執行的起來的量化模型。
第三步，誰來真正地「造」數據。第二步里，我們已經初步的「亂編」了初版數據，第三步這裡就是真正的「造」合理的數據了。筆者建議，是 IT 部門推動業務部門調整我們之前的初版數據，然後儘可能的給出每個數據項的明確數據，或者給出每個數據項的2~3個參考的數據檔。比如我們無法確定物料的平均審批時間的話，那麼我們起碼可以確定類似2小時和4小時兩個選項，交給真正的審批人員來最終核定數據的合理性。
第四步，誰來審批「造的數據」的合理性。坦白來說，這一步，走起來或許會不容易。筆者建議這裡由 IT 部門主管去主動推動，IT 部門主管主要的溝通對象就是某個業務部門主管，先從單個業務部門探索嘗試。其實這一步，主要是業務部門和 IT 部門的利益平衡。如果業務部門說這個、那個數據不認可，那麼IT部門就有理由和底氣說，這塊工作向後排，其他工作排在前面來。（其實內心戲，都懂得。就是業務領導不認可某塊的IT建設話，IT部門就無限期延後這塊，有限滿足其他需求。）
IT系統上線後，需要的也是前面兩大塊數據：企業內部管理流程效率數據和企業外部綜合評價數據。這裡要注意兩點，第一點，是內部管理流程效率數據，要在 IT 系統設計之初就考慮如何採集，同時最好提供資料視覺化的界面直接生成效率數據對比報告；第二點，是要重點搜集企業外部綜合評價數據，或者就是企業案例故事。
針對企業案例故事，單獨聊一下。舉個例子，江汽物流公司，通過流程監控，IT系統及時發現GPS異常事故，並在 IT 部門的方案下妥善解決了這個問題，發現問題和解決問題的效率顯著提高，業務人員和主管領導看得見的成果。再舉個栗子，眉州東坡通過分析不同規模的店面的盈利能力，最終分析出來開中小店面盈利能力最好，一個報告交給董事會，直接改變了這些發家創始人的認知，新開店面大店改中小店後，企業財務報表董事層面清楚看得見。
1.2.2 數據要精確到什麼粒度
既然要採集這些數據，那麼數據具體要精確到什麼程度呢？這裡筆者給一下建議，有兩個原則：一是採集粒度不低於IT 系統上線前；二是跟錢掛鉤的數據粒度要高於 IT 系統上線前1~2個水平。
IT 系統上線前和上線後，積累了合適的數據。接下來就是進行合理、適當的解讀。那麼誰來解讀、解讀什麼、怎麼解讀等問題就迎面而來了。筆者建議，是 IT 部門來解讀。當然，這個解讀報告是從低到高，從部分到整體不斷匯聚而來的。也就是說，需要 IT部門的每個模塊的負責人分別對接不同的業務部門的相關人員，先解讀每個子模塊的數據對比分析，然後再逐級匯總，形成一個整體的報告。
企業核心部門審批通過的數據解讀方案，如何真正落地有效執行呢？筆者建議相應的監督部門來進行監督工作。具體監督哪些內容，需要 IT 部門和業務部門共同制定，但IT 部門主導牽頭，同時要有關鍵 IT建設階段目標作為其中的監控點。
到這一步，其實特別要注意溝通。雖然我們已經做好可解讀方案和監督方案，但整個方案並不一定每個執行的員工都清楚，甚至有些會因為增加個人工作量而拒絕執行。IT部門要主動起來，勤於溝通，勤於核對數據採集和業務執行的關鍵動作。因為，在 IT 項目建設初期，業務部門的相關執行人員並不一定能夠從中獲益，很可能產生抵觸情緒，導致數據採集不到位，或者相關操作流程不到位，最終導致部門流程不走系統，IT 系統形同虛設。IT 部門在系統建設前期，主動承擔起來責任，有利於IT項目真正有效落地。
侃侃而談數千言，其實也是筆者積累的一點經驗和草率的建議。畢竟沒有當面溝通，沒有實地去調研你的企業，確實不好出來特別有效的對策。筆者自身也是在IT諮詢公司從事企業管理研究，缺少實際進行業務管理和 IT 系統建設的經驗，所謂心得體會也多來自和不同企業人員的調研走訪。如果有疏漏或者錯誤，歡迎留言，我們一起交流。
