文章內容

OA項目實施陷阱：成也CIO敗亦CIO

發布時間: 2012/5/25 19:29:21

絕大多數的OA需求都是發問卷給相關人采集匯總而得來的，以這樣的形式采集匯總的需求造就了中國過去近20年幾乎所有的OA都走項目化，或者看著別人的OA還湊合拿來就用。如果你也是這樣整理需求的，那簡直就是自殺，這種看上去合乎邏輯的需求成型方式里面卻埋藏著失敗的種子。

　　CIO通常是OA項目的負責人，中國的OA應用發展史可謂"成也CIO敗也CIO",在組織賦予CIO肩負起OA項目建設職責的同時，不少CIO卻也還滿懷激情地沖向陷阱。

　　陷阱一：缺乏長期規劃

　　CIO一般有當前的項目規劃，而無長期戰略規劃，為項目的早夭埋下了伏筆。

　　陷阱二：需求貪大求全

　　如果你堅信自己采集的需求是一種客觀的需求，是必須被100%滿足的需求，你就離失敗不遠了。那么，如何認識自己的需求？

　　讓我們仔細看看這份需求吧！也許每個部門都提出了自己的需求，里面不僅是一個個以自我為中心的要求，而且充滿著本來應該歸納到業務范疇的應用需求，甚至包含著個別領導的軟件嗜好。依照這種需求，世上沒有一套現成的軟件能夠100%地滿足。依據這樣的需求開發出來的OA軟件，可能功能看上去非常豐富，但實際上卻形成了一個個以部門為中心的應用孤島。第一代的OA都是這么出生的，最后大家用起來一頭霧水，這些看上去都是我們想要的功能為何總感覺那么別扭？問題到底出在哪？

　　我們研究發現，這類OA普遍存在一個問題：如果我們要以整個組織高效協同為目標，那么，那個把我們協同在一起的功能是哪個？

　　請不要輕率地回答這個問題，有人說用公文？公文只有組織中不到10%經常用；文檔？文檔可以分享，但文檔不能主動產生協同；IM（即時通信）？IM并不能進行表單審批；郵件？郵件能完成流程化審批嗎？能用郵件來完成組織的日常協同，我們還實施OA項目干什么？

　　所以你必須從繁雜浩瀚的細節中脫出身來，放下本位主義，先找到一個組織共性的需求，然后才是關鍵部門的需求，最后才是重要角色的需求。你在選型的時候一定要看，這個OA是否有這樣的一個功能能夠滿足這個共性需求！

陷阱三：實施急功近利

　　如果你認為軟件只要會編程就能做，那你可就大錯特錯了！寫程序是鄰居家的高中男孩就能干的事情。

　　軟件是包含責任關系的商品，需要復雜的支撐體系。軟件業已經發展到工程學的水平，擁有嚴格的環節分工和檢驗標準。從需求開始，有專業的人員進行需求的采集、提煉、評估，形成應用的"概念設計";經過評審后，技術高手會充分考慮諸多因素后提出"構架設計",評審后才會到開發部形成"應用設計",評審后才會有"代碼開發",然后是"功能測試",最后才能交給你。這期間，所有的環節都應該是最優秀的人力資源在保障質量，所以你千萬不要指望找到一個非常廉價還百依百順的供應商，根據你的指令快速而完美地幫你達成目標。

　　陷阱四：片面追求新技術

　　對新技術的片面性追求常常導致項目成為了項目負責人（特別是CIO）自娛自樂的畸形產物。探索的精神無可厚非，但是畢竟嘗試性的技術探索對于組織應用所期望的穩定性、實用性而言是高風險和高成本的。

　　技術先進性的價值不在于先進本身，而在于先進對擴展性、性能、安全性、集成性、易用性（常被CIO所忽視，其實對終端客戶的影響排在第一位）等諸多應用的現實價值和升級成本的抑制。而且由于協同管理軟件的價值并不僅僅依賴軟件本身，其部署過程和應用推進能力也對其價值發揮起到至關重要的作用。我們絕不能忽視這樣的現象：同樣的軟件在不同的單位對價值有截然不同的評估，所謂花巨資上馬的大型軟件成為擺設的情況比比皆是。

　　我們相信CIO對于軟件的評估側重應用和技術是理性的，但我們也同時注意到，CIO對于推動組織建立新型工作行為模式的艱巨性和挑戰性的重視程度不夠，常在對未來技術應用發展趨勢的無限可能性的冥思苦想中忽略了組織與協調成本，導致系統實施成為踏入泥潭的第一步。

　　陷阱五：實施缺乏導向

　　實施被不少CIO理解為軟件開放、安裝調試、培訓、測試、上線這一類的事務，但我們認為這不是實施，至少實施的目標錯了，不是結束一個軟件的部署過程，而是在這個過程中達成管理提升的目的。如果前面所說的工作是必需的過程，那么達成管理目標才是實施的結果。遺憾的是，極少有CIO在實施計劃中明確地提出管理提升目標，最高的層次也就是具體枝節需求的滿足。最理想的結果也就是安裝了一套對大家沒有價值感受的軟件！

　　大部分客戶把OA當成了一個階段性項目，而沒有意識到，如果能充分重視OA,它將成為一個強大的戰略實施的支撐平臺。