筆者從保障項目成功的角度歸納出9個問題。這9個問題涉及對OA的初步認知，也涉及對本質的探討，希望與業界同仁共勉。

在與這些信心十足的CIO的溝通中，筆者發現由于種種原因，與這些CIO們對于OA項目的哲學層面的本質很少有深入的思考，大多過于從技術角度的眼光去關注具體的功能或應用。同時，在眾多廠商關于OA的宣傳冊或者標書中，很多只是提供了根據自己理解的需求拼湊出來的功能特征細節要求，而組織發展的具體戰略與OA之間的關系、從管理角度對OA的要求等連只言片語都沒有。

后來筆者逐漸明白，正是這種認知上的先天不足導致在中國過去的15年中，超過10萬套上馬的OA項目成為了毫無價值的擺設和2～3年即廢棄的項目。這一現象激起了筆者的興趣，筆者開始關注OA項目的選型和事實的價值觀和方法論，經過總結，筆者從保障項目成功的角度歸納出9個問題。這9個問題涉及對OA的初步認知，也涉及對本質的探討，希望與業界同仁共勉。其中還有些問題內涵十分豐富，這里無法展開，有興趣的朋友可以與筆者交流。

第一問：OA的成功率有多高?

在大多數CIO的心目當中，OA是一個很容易成功并且沒有什么太大價值的軟件。筆者不止一次問過客戶這個問題，客戶大部分認為相比ERP而言，OA技術難度不高，應用也不深奧，無需太多專業知識背景，只要領導一紙紅頭文件，就能順利成功。

其實，現實情況恰恰相反，OA的成功率低得可憐，雖然OA有15年以上的應用歷史，而真正成功的寥寥無幾，根據筆者在2002年調研走訪客戶后得到的數據是低于15%，這大大低于用戶和業界的感覺，其失敗率直逼ERP。筆者也常問客戶：你單位方圓5公里范圍內有成功的OA客戶嗎?或者你行業內哪個單位的OA用得不錯?大多數時候，答案是否定的或者不知道。筆者知道的一個單位曾經投資近百萬元人民幣建設Notes系統，實施范圍1100人，但最后只有不到50人在上面用公文，可謂昂貴的擺設。其實深入了解，并非Notes不好，失敗是另有原因的。

筆者估計在過去的15年中，中國至少有5000家廠商以項目的方式交付過10萬套OA，有的簡單得如同網站，能夠上傳文件，有Email、論壇就算OA了;也有以公文、文檔為主流的，更有極其復雜與MIS、ERP、指揮調度、監控集成在一起的大型項目，但基本上上線率都大大低于實際應用覆蓋范圍。15%的成功率其實是個樂觀值，在筆者看來，所謂OA成功者，大部分都是處于較為朦朧的價值認識情況下的初級自我滿足。

關于OA的第一問其實答案很簡單，但調整和糾正對OA項目的風險低估和盲目樂觀，是走向成功的開始。

第二問：OA的本質是什么?

這個問題有點像哲學命題，但卻是CIO非搞清楚不可的問題，否則將無法建立這個項目與管理的支撐關系，苦心孤詣整理的需求可能許多與戰略并無重要緊急的關系，只不過是個人的軟件細節偏好。

實施OA其實是組織行為變革的革命，只不過手段是用OA，負責人是CIO或辦公室主任，實際領導是大老板，是全員參與的一場革命洗禮。

與財務軟件不一樣的是，OA項目的應用范圍決定了它是一個“全員信息化”的大事，這期間，應用范圍的量變積累已經使得項目產生了質變的層面，已經涉及到了整個組織的“行為變革”范疇，也許eHR軟件或進銷存軟件使用失敗了沒有什么，甚至別的部門根本就不知道發生過，但OA不同，從上線那一天起，到最后無論好壞，每個人都知道你干過一件漂亮或者很糟糕的事情。

記住：OA項目的性質是一種組織行為變革的工具。

絕大部分CIO都是可愛的技術愛好者，也正因為技術的原因被領導指派為OA項目負責人。不過組織行為學和組織管理學并不是CIO的擅長，所以CIO難以了解或者描述OA的價值，失去了以組織行為管理的價值準繩，只能憑借技術作為判斷方向的依據，這樣的選型想不失敗都很難。

所以，作為CIO要清楚，可能并不熟悉管理的你要去推動一場組織行為的變革，代號是OA，你將在未來幾個月中改變原來那些你熟悉的人的行為模式，把他們從電話、面談、會議中拽出來。從本質上說，掌握如何通過軟件輔助推動組織行為變革甚至比采用什么類型的技術更為重要。因為OA是在用創造力開創管理軟件業中另一大分支——組織管理軟件，是在將新技術不斷帶入這一范疇中，把軟件變成對組織中每一個人都有價值的工具。

第三問：OA項目面臨哪些挑戰?

研究OA的挑戰一定要建立在對OA的本質的認知基礎上，我們常見的現象是，CIO在立項中把對需求的滿足度作為較高權重指標，另外關注的是技術的先進性和安全性

等等，這些都過于偏重技術了。他們到底忽略了什么?筆者看過一份IDC專門的調查研究報告，與筆者實踐中求證的答案一樣，那個答案卻是CIO背景的人很容易忽視的。

1. 易用性

在OA的本質探討中，我們已經明確了，OA其實是一次組織行為變革的代號，其形式是軟件部署和使用，實質是組織行為模式的變革，特別是協同模式的變革。

過去曾有無數的OA，在立項階段CIO和辦公室主任殫精竭慮地整理完整的需求，在支付了大量的金錢和時間之后，通過項目化開發得到了滿足，但實際情況是根本沒有人愿意用，是什么導致了這些需求的提供者拒絕使用系統?

這樣的變革需要兩種力量的參與，一是領導真正的重視，而不僅僅停留在口號或者愿望上，需要身體力行，在那些成功的OA案例中，位高權重的領導者常常是很早上線、很晚下線的人群之一。另外就是群眾的高度參與，在評估成功的關鍵閥值中我們提到應用范圍值就是這個特性的量化。

領導和普通群眾的很大的共性是電腦應用水平不高。事實上，一個在運作中的組織是難以從業務慣性中擺脫出來專門去從事學習的，我們可以把財務部幾十個人停下來專門學習財務軟件，加班加點在電腦上重新輸入憑證、記賬，但我們無法讓整個組織停下來3個工作日，專門學習OA軟件，很多是輪流培訓2天，絕大多數是一天甚至半天。

因此有個規律：應用范圍越大的系統，其學習成本要求就應該越低，這里易用性是很大的挑戰之一。

CIO相對組織中其他人員來說，他太了解電腦了，這也是被挑選出來承擔OA選型責任的原因，但他又不了解組織行為學，如果再不具備對OA的哲學認知，會在相當程度上忽略易用性。以前的OA失敗，至少有50%可以歸罪為易用性問題。

2. OA的粘著度

另一項挑戰是OA的粘著度,即用戶對系統的依賴程度。大部分OA系統都不具備粘著度，要知道無論需求有多周全，都是窮舉模式的，而組織行為是無法窮舉的，即使一一滿足那些窮舉的需求，你可能發現仍然有80%的事情無法在OA上處理。過去OA失敗的原因就是只做關鍵性應用，如我們熟知的公文、文檔管理、辦公室常用的功能等，就算有流程化審批，也只能窮舉部分組織級審批，到部門級就太多了，干脆就不做了。他們草率地把80%的無法窮舉的應用需求的責任推給了郵件!套用那句“名言”的語法: “如果道歉有用，還需要警察做什么?”如果郵件能解決還要OA干什么?”

OA還有很多挑戰，諸如實施風險之類，但很大的挑戰還是在產品本身，即易用性和實用性，而大部分人可能對易用性容易理解，但對實用性卻沒有深入認識，我們通過大量調研，才認識到第二個問題，那是傳統OA失敗的根本原因之一。

第四問：OA項目成功的要素有哪些?

OA的選型實施范圍大、涉及面廣，如果想讓OA項目成為持續支撐組織發展的基礎IT平臺，CIO們必須以戰略眼光來思考，不能把OA作為急就章項目來看待，在筆者看來成功的要素至少有三點。

1.正確地選擇產品或者項目方案。

你必須選擇一個可以滿足當前需求的產品或項目，否則以后的結果就很難預料，但以自己的需求為導向的選擇真的就能成功嗎?為什么那么多能夠理清自己需求的項目仍然不成功?這是因為沒有搞清楚產品和項目對自己的意義。

2.階段清晰的漸進式實施

常見的對實施的認識大多局限于軟件安裝、公文流程定義、表單設計等等，大部分都缺乏對實施的整體認識，筆者所在的用友致遠在長期的客戶實踐中，總結了實施三段論(共性應用的二八原則、局部深化、集成應用)，因為涉及到很多方面，限于篇幅，筆者在后面的“如何實施階段規劃”中討論。

3.持續服務和持續升級

持續升級的好處不說了，說說持續服務。持續的服務也許是供應商的一種良好愿望，但也許只是為了收款時拍胸口的豪言壯語，你必須清楚，一切可持續的事物都不是靠愿望，而是某種內在的東西在支撐。

這部分內容比較簡單，但卻是影響項目成敗的很主要的價值觀和方法論的基礎，CIO們對此問題的充分認識和正確決策是保障項目成功的關鍵中的關鍵。因此下一問中我們先不對上面三個分支問題做出深入的闡述，我們從另一個角度，即那些曾經失敗的CIO為何踏入了所謂OA的“CIO陷阱”來了解更多的細節。

第五問：CIO陷阱有哪些?

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

陷阱一：缺乏長期規劃

CIO一般有當前的項目規劃，而無長期戰略規劃，為項目的早夭埋下了伏筆。(詳情參見第7問: 如何制訂實施階段規劃)

陷阱二：需求貪大求全

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

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

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

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

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

所以你必須從繁雜浩瀚的細節中脫出身來，放下本位主義，先找到一個組織共性的需求，然后才是關鍵部門的需求，最后才是重要角色的需求。我們先后研究了中國數十家OA廠商，走訪了數十家OA成功或失敗的客戶，仔細評估了超過200種常見OA的功能菜單，最后找到了那個共性的需求，這就是協同。你在選型的時候一定要看，這個OA是否有這樣的一個功能能夠滿足這個共性需求!

陷阱三：實施急功近利

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

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

筆者從保障項目成功的角度歸納出9個問題。這9個問題涉及對OA的初步認知，也涉及對本質的探討，希望與業界同仁共勉。

陷阱四：片面追求新技術

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

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

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

陷阱五：實施缺乏導向

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

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

第六問：要產品還是要項目?

事實上，CIO在OA方面只能有三種選擇，一是標準產品，二是個性化開發，三是產品+局部定制。信息化程度、管理成熟度不同的客戶對OA的期望值是不同的，另外CIO的技術偏好會導致對需求的客觀性認識不足。

1.產品化的優劣勢

產品化從視覺上看到的是包裝盒中的光盤、加密狗、印刷說明書(印刷品是批量的標志)、服務卡，但產品化實際上是一個復雜的商業系統，是由需求流程、概念設計、架構設計、程序代碼、測試流程、銷售、實施交付、售后服務、升級服務等多種崗位專業人員協作構成的。

產品化有產品化的好處，也有產品化的不足，好處是之前有無數用戶驗證了功能的適用性、性能、穩定性，并且可以持續升級，是成熟的象征，它是與客戶的長期合作，如同婚姻。產品化還意味著高性價比，這是絕大部分客戶所關注的。產品化總的來說是低風險的。

產品化是軟件的一個發展趨勢，因此不少廠商都在宣稱自己的產品化，是否真的如此?其實識別辦法很簡單，可以通過該廠商的網站上識別。產品化供應商能看升級公告，沒有版本升級公告的則屬于“李鬼”。

產品化的不足是，不能一次滿足所有細節需求，客戶在選擇時需要對需求有所舍棄，另外產品化的升級節奏與你需求的成長速度之間的匹配是個問題，這就需要你在產品化廠商中選擇那些內部資源雄厚、流程順暢、支撐保障機制健全的廠商。

2.項目化的優缺點

項目化的優勢是為客戶量身定做，但與此同時喪失了標準化升級的可能性，其關鍵在后者，而不是個性化代碼的多少。

項目化是高成本的，首先技術人員比實施人員成本高，如果客戶相信優質的程序員是價值昂貴的稀缺資源，客戶就不要相信花1萬元就能完成一個好項目;二是周期長的，短期趕出來的不可能沒有問題，看看微軟這么偉大的公司還有不少Bug呢，項目漫長的測試、優化周期造成了高成本;三是供應商的商業模式造成的，如果是項目型的廠商，只能盡可能通過每一個項目的價格較大化回報來掙錢，因為它們沒有把握像產品化公司一樣能夠通過客戶數量掙錢。

項目化是高風險的誘因之一。從需求分析開始，到技術路線選型、架構的擴展性設計考慮、優質高效的代碼實現、完善的測試，所有這些環節，都需要客戶和供應商雙方投入很高的人力資源，才足以做到業界一流水平。不幸的是，一個供應商只能有一兩個頂尖項目經理，他不可能在每一個項目上投入，而客戶方更是稀缺能夠精通OA、具備戰略思維、又能細致深入把握需求、協調實施的項目經理，這種人月薪身價都是在2萬元人民幣以上的。所以我們不難理解為什么有這么多OA的“爛”項目，很大程度上，就是二三流人員在瞎折騰。在前面提到的這些環節中任何一個失誤都會讓客戶未來付出代價。

項目化很大的局限性是缺乏長期發展機制，如果沒有每年配套的充足的預算，你怎么可能長期要求供應商持續研究、優化、升級?在技術日新月異的今天，沒有好的，只有更好的。

中國式項目化模式注重與客戶的短期合作，急功近利的成分更大。

3.產品化+局部定制

比較了兩種模式之后，客戶無疑要做個決斷，大部分客戶會選產品化。有極少的客戶選擇項目化，但有一些客戶還是期望在購買時獲得承諾，滿足產品化尚無法滿足的個性化需求。這種情況下，導致了第三種模式的出現：產品化+局部定制。

“產品化+局部定制”仍然會導致兩個結果，客戶的需求如果產品架構可以支持，可以以擴展模塊的方式滿足，那么沒有問題;如果產品化的技術架構不支持，客戶的需求如果要滿足，就只能以調整架構，犧牲升級來換取。以用友致遠的A6為例，其架構很早根本不支持，現在開始逐步支持，逐步成體系，這是一個漫長的成長過程，需要漫長的實踐積累才能保證軟件接口的成熟度。

由于項目的個性，實際上持續服務是不可能的，反觀產品，如此眾多的客戶不僅使得產品經受了個體完全無法達成的覆蓋性測試，這些測試中的Bug反饋和需求反饋又進一步導致了產品加速完善。重要的是使得客服能夠形成版本知識庫，有了這樣的知識庫，客服人員能夠回答幾乎90%稀奇古怪的問題——其中大部分是IT環境問題(病毒、插件、IE版本、補丁等)，而且并不會因人員的變動導致服務質量下降。總之，產品化讓我們見多識廣，知識庫讓我們專業化，眾多的客戶經驗讓我們從解決問題上升為專家指導。

筆者常告訴客戶，項目化的驗收之日就是OA的死亡之日，只不過要1～2年才顯露出來，供應商撤離，客戶項目經理轉移到其他項目，對OA項目來說，無異于根須死亡，樹葉發黃凋零是遲早的事情。

只有產品化才是中國大部分客戶能接受的長期發展保障機制，項目化要想長期保障，太貴了，你要想想你是否玩得起

第七問：如何制訂OA實施階段規劃?

大部分客戶的項目經理都會根據老板的期限制訂一個實施規劃，分為調研、制訂方案、啟動會、實施、培訓、測試、上線、正式運用等，實施顧問會和你一起根據項目的大小、難度、重點去制訂對應的方案。

經過多年的實踐，OA的實施方法論已經非常完善，有幾種不同的模板，甚至能夠提供啟動董事長、總裁的發言提綱，但這是不夠的，你完成的不過是當期的實施規劃，你如果了解OA的本質，認識到這是一個長期而艱巨的組織行為變革的挑戰，而你沒有戰略規劃，你可能會把不該在這個階段完成的事情納入進來，混淆了主要問題和次要問題，甚至會導致失敗。

首先，你應該有一個長期戰略規劃，你需要知道OA的應用不是一蹴而就的，所以你不要期望把所有的問題都能在今天解決。

根據我們的經驗，建議你至少要規劃三個階段：

第一階段：共性應用階段

第一階段的使命是保障快速上線，盡快建立組織級協同方式的新的習慣和模式，你現在已經知道這個速度是非常重要的了，所以你必須對這一階段的需求進行準確的確定，如果你不加控制，你可能會無意中設定了過多的目標，糟糕的是每個部門都有自己的重點目標，大家都陷入到自己的細節需求的滿足、扯皮之中，仍然沒有協同起來。

這里用一句很“哲學”的話來描述這一階段的應用特點：大范圍的小應用。意思是除了公文、文件夾之類必不可少的應用，你首先應該推動的是“自由協同”，自由協同會快速地讓所有人感受到電腦協同方式相較于傳統協同的優勢。很快，兩周，如果你能促進每個人每天上線2～3次，那么大家都會愛上協同的。當你看到這樣的情況：領導在走廊抽煙，遠遠的一個下屬喊道：“x總，我昨天把項目材料搞完了!”然后你聽到x總大聲地回答：“好了，你把它協同給我吧。”你就知道，第一階段大功告成了!

第一階段是成功的第一步，不積跬步無以至千里，如果第一步倒下，就不會有未來。關于第一步的衡量指標將在第9問中提到:衡量成功的簡單指標的2個閥值和2個月期限。

第二階段：深化應用階段

即使在同一個單位，也不是每一個部門的管理水平都是一樣的，同樣OA的應用深度也會不同，流程繁雜的部門領導重視流程梳理和效率，文檔如山的注重文檔管理，知識變化快的注重知識管理，總經理工作部、辦公室注重結果，項目經理注重過程和跨部門信息對稱……

因此，你要在第二階段進行二次實施，這次是以部門為中心的管理深化，通過OA把部門管理的難點、重點通過深度實施解決掉，而且剛才說到的問題很多還需要組織保障——在部門中設置兼職崗位落實到人，這樣才可以檢查和推進。

如果運氣好，你大約可以用半年到1年的時間完成這一切。那時候，你們單位的流程有序了，而且建立了流程設定的流程，一個又一個新流程在自由協同的實踐中逐漸成熟，轉化為模板，上升到制度;你們單位的每一個大一點的部門都有了肩負OA深化使用的兼職人員甚至是專職人員，并且可以考核他們。單位第一次設置了總監或副總級別的知識管理負責人，有了知識的篩選標準、強制的采集上報制度、知識貢獻的激勵……注意這是一場變革，沒有組織保障是不行的，沒有激勵也是不能持久的。

第三階段：整合應用階段

這個階段的關鍵在于整合什么?很多CIO錯誤地把深層次緊耦合整合需求當成了第一階段目標，從一開始就自討苦吃。要知道，整合的基礎是兩個或更多的系統在完成了自己的深化應用(復雜的系統都有這3個階段)基礎上才有整合的價值，如果你像筆者一樣在軟件業干了18年苦活，你一定會像筆者一樣感慨，在通往信息化的道路上有多艱難!沒有任何一個CIO有把握能讓任何一個系統都應用成功，用上1～2年就換掉系統的比比皆是，更郁悶的是系統還行，而廠商已死掉了，這樣，需求的細節沒有清楚、缺乏深度分析和前瞻性的設計、當前技術發展尚不足以支持擴展性，那么草率地把整合愿望付諸實施將成為你職業生涯的夢魘。

深度整合就是項目!看過上一問的項目和產品比較你就會知道，你在挑戰的是你自己的綜合素質的極限發揮，超越自己遠遠比完成一個項目更難。所以，后面項目多半以兩敗俱傷而草草收兵。

有CIO曾經問我，這三個階段需要多長的時間?根據筆者對眾多組織的信息化發展的了解，筆者認為三個階段2～3年內實現，比較現實。這里的建議僅供參考，謬誤之處請包涵并指正。

第八問：如何建立OA項目的長期發展機制?

其實答案在階段規劃中已經談到了，不過這次我們站在組織而不是實施的角度來看一看。

首先明白機制是什么，機制字面的含義是機能和體制，在組

織中表現為分工和職能設置、授權、流程、考核、激勵等綜合反映。機制不是靠一紙公文就能搞定的，需要認真的分析和慎重決策。

從實踐層面來看。筆者認為要想讓OA成為一個組織管理的重要平臺，真正發揮作用，那么必須考慮長期發展機制。

首先要考慮解決OA的定位問題。

對項目的定位將決定項目的價值貢獻和發展，由于缺乏對OA本質的了解，絕大部分客戶把OA當成了一個階段性項目，而沒有意識到，如果能充分重視OA，OA將成為一個強大的戰略實施的支撐平臺。如果說基于互聯網的庫存管理系統將支撐你的企業全國性擴張的戰略，那么OA可以成為你在全國范圍內進行組織管理的支撐工具，無論是收購、兼并、內部重組，OA都將忠實而快速地反映組織的變化，并支撐快速流程調整，匯總并建立中央知識管理，與ERP的結構化信息相輔相成覆蓋整個管理范疇。

其次是要解決崗位職能設置，設立OA專員。

因為定位的問題，所以很少有客戶能為OA的發展設計專門的崗位，如果把OA定位在一個軟件，那么找個職高生來完成數據備份，定時升級之類的小事也確實無可厚非。但如果定位在組織管理和戰略實施平臺，那么OA的發展將影響到整個組織能力的提升，你就不能再考慮用高中生了，你需要考慮一個在單位有多年工作經歷，熟悉各個業務部門情況，具備協調組織能力、至少是對組織管理充滿興趣的人。他在單位如何?他的使命是在上線后未來的2年中完成對二階段和三階段的領導。按照筆者的理解，非資深人士不可，而且他還得不斷學習。

另外隨著應用的深化，要設置的崗位有：部門知識管理員、HR部門或企管辦執行力和文化建設的監督員，當然，這些人只需兼職即可。

第三是授權。

即使設置了專人，筆者還是很難相信業務部門那些“扛”銷售指標的中層管理者甚至是高層會對這樣一個角色充滿敬意，他們會不自覺地抵抗任何改變習慣的變革，他們會因為打字慢而不愿意輸出任何東西，他們會解釋說銷售壓力大、事情多，沒時間學習，沒時間打字，給你電話匯報就行了，這時候你該如何?

作為企業管理者，你必須對OA專員授權，并且在公眾場合，你可以審查他的規劃，避免他過度實施干擾正常業務，但你也必須在眾人面前給他樹立威信，給他對不按照審定的規劃取得進展的部門或人員有處罰的建議權。

第四是制度化保障。

如果要在一個組織中推出一個重要的舉措，那就不是僅僅通過公告告知那么簡單了，你應該考慮制度化，你應該建立“xx單位OA使用規范”，把OA的使用變成制度、使之合法化，明確高壓線——那些絕對不能違背的事情(比如非出差生病的情況下多日不上線之類的)和處罰標準(建議采取經濟手段)。

第五是正向激勵。

如果變革沒有好處，誰愿意變?所以激勵很重要，激勵不是心血來潮的賞罰，除了處罰，我們應該去創造更多的獎勵，我們可以結合知識管理設置知識貢獻獎，可以征求對流程的建議給流程優化獎，可以鼓勵員工在論壇分享競爭情報，鼓勵管理建議，獎勵部門文檔管理水平率先達標的團隊，表彰第一個使用關聯項目進行跨部門協同的動態團隊……在鼓勵和表彰的過程中，企業的價值觀中推崇什么一目了然，文化逐漸成型。

這一過程中，領導的參與也是一種獎勵，更多的管理者應該習慣于在論壇中回復基層員工對戰略的疑問，通過論壇了解組織運轉的問題，及時提到解決日程中來。

最后還有一個需要解決的問題：誰與你同行?

從未來的理想遠景中回過神來吧!就算你明白了所有的道理，你還是要在今天將這些所有的思考轉化為一個基本的決策，你將選擇哪一家OA供應商作為支撐OA長期發展的伙伴?正如你想象的那樣，你要選擇的供應商不僅其產品要有關聯理念，符合組織管理的需要，還要功能設計得非常簡易，能幫助你快速達成階段的成功，更要有對組織管理實踐的深入認知，能給你提供咨詢和建議，非常重要的是要壽命長，能存活到你成功的那一天!

第九問：你的OA系統成功嗎?

衡量一個抽象的事物是否成功非常復雜，你可以檢查標書和實施計劃中的子項目標是否在實施期限內達成;另外一個簡單的方法就是在實施啟動的第60天檢查你們單位兩個指標是否達到了應用閥值。

檢驗實施成功有兩個閥值：

應用范圍值A：人均上線頻率 > 1次/人?天。

如果注冊客戶是300人，要求300人每人每天應該至少有1次上線。如果A值達不到閥值，應用范圍會急劇縮減到少數積極的用戶，大多數人會因上網交出去的協同事情沒有當天處理而受到負激勵，不再積極從網上協同，而回復到地面協同。如果達到，可以保持一個及格水平，但需要達到下一個閥值才能開始向深化應用發展。

應用效率值B：注冊人員經常性在線率 > 30%。

比如，注冊客戶300人，要求經常會有100人在線。B值是響應效率，當B>30%時，響應的及時性會提高，OA的協同性效果會顯著超過傳統行為模式，從而使協同請求者和協同處理者都產生正激勵效應，會越用越好。

另外，還有個時間約束條件，也就是實施上線2個月內必須一鼓作氣達成這兩個值，否則再三而竭，組織不再興奮，無心學習，二次實施很難成功。2個月之內實施效果不能達到A和B閥值要求的項目風險會大大增加。當然，也有一些經驗計算公式可以計算OA的直接效益和投入產出比，幫助CIO在進行項目效益分析時為領導提供決策的依據。

此外，真正衡量OA成功的是管理貢獻，那將是一個更加復雜的話題，其中推動管理的創意和實踐結果是有趣和有價值的。

后記

關于OA的9個問題，是筆者這幾年對OA的認識的一個總結。文中為了閱讀感受，不少地方將CIO作為了第二人稱的探討對象，恐有咄咄逼人之感，但并非筆者本意。筆者并不想指責CIO，也沒有資格以CIO的導師自居，筆者期望的是與CIO進行客觀、坦誠、深入的交流。事實上筆者的探索認知正是來自于筆者的CIO朋友們無私坦誠的分享，甚至包括他們曾經經歷過的失敗教訓。這里筆者不過是將這些心得整理出來，與那些從未謀面的CIO朋友分享，希望能為大家在實施OA選型和實施過程中提供參考。只有通過我們共同的努力，我們才有可能實現雙贏!