資訊科技應用專案的戰略風險分析(3)(轉)
第四,資訊科技的使用效果期望過高往往會造成資訊科技應用專案實施過程中的巨大風險。在目前資訊科技得到廣泛應用的環境下,各組織的高層主管人員(至少從公開態度方面)很少會認為資訊科技的應用無關緊要,但同時卻容易走向另一種極端:認為資訊科技的應用將使得一切都變得容易。這種認識將在幾個方面造成風險:
1.對資訊科技應用的效果估計過高容易造成資訊系統專案範圍過大。從一般意義上說,系統的特性(即包括功能、效能、質量、安全可靠性等)與其投入的資源是成正比的,對於購置的專案其資源包括購買費用、操作人員培訓費用、維護人員培訓費用、供應商技術支援費用等。對於開發的專案其資源則包括整個專案實施費用(設計、開發、測試、培訓、相關設施的採購和管理費用等)和未來的維護費用。這一規律從相反來說一般也是對的:一定的投入所獲得的資訊系統的特性是一定的,而且還存在著各個特性之間對於資源的競爭問題(如為提高安全可靠性所投入的資源可能會削弱投入提高效能的資源,如果資源投入的總量不變,則最終系統的效能會有所下降)。因此,如果對於投入和產出這一關係有個清晰的觀念(當然,由於資訊系統的複雜性,這種投入產出關係的估算是有相當難度的),極容易造成在給定的投資預算框架下提出範圍過大的需求(或者是在專案實施過程中不斷擴大需求——這將在分析專案風險時涉及),並在這種需求的誤導下形成對資訊科技應用專案效果的不切實際的願望,最終往往是導致應用專案失敗的一個重要原因。
2.資訊系統的功能一般來說與其靈活性是成正比的,而且在當今“唯一不變的是變化”這樣一個環境下,靈活性過低的資訊系統是沒有生命力的,這不僅表現在缺乏靈活性的資訊系統無法迅速跟上業務和管理過程的變化,即使組織內部有相應的技術和管理力量對系統進行及時的修改,其維護成本也是相當高的,因此要求資訊系統具備相當的靈活性絕對是必要的。但另一方面,高度靈活的系統不僅造成更高的開發難度,而且對使用者提出了更高的要求。一般而言,前者相對容易解決,只要提供更多的技術資源(包括人員、培訓、開發環境等)在目前技術迅猛發展的環境下,開發難度問題還是容易解決的。而後者的解決難度相對要大得多,因為具有更強靈活性的系統至少具有兩個特性:一是系統引數(包括安裝引數、執行引數、使用引數等)眾多,二是引數之間的關係眾多。例如,一個簡單的製造控制系統採用事先確定的工序進行控制;而一個相對複雜的控制系統可能要求能對各工序的先後次序進行更改,因此工序間的關係成為可變數;更復雜的控制系統可能需要能對每一道工序的組成動作、物件等進行重新定義,因此工序本身及其相互關係均為可變數。系統引數的增加和引數之間關係的增加將提高對系統維護人員和操作人員的要求,而在應用策略制定階段卻可能未考慮到這方面的要求,這可能導致幾個後果:一是由於需要對維護人員和操作人員進行更多、更詳細的培訓而提高了相關的投入,二是當系統的靈活性更多地需要使用者的應用能力時,組織內部可能根本缺乏能夠適應系統靈活性的人員,而在短時間內聘用或培訓足夠數量的使用人員在資金上無法滿足,在實際上也很難做到。因此,單純考慮靈活性而不顧及可能對使用者和維護人員的影響可能導致極高的日常執行成本。
3.資訊科技的應用並不能改變一項活動對於人的創造性的需求。習慣於傳統帳務處理系統的使用者會發現自己很難適應財務分析系統,在傳統的帳務處理系統中操作人員只要按螢幕上的要求輸入相關資料,根據螢幕上的選單項進行選擇就可以獲得有關的報表;而當使用先進的財務分析軟體時,使用者可能不得不自己建立相關模型、設定引數,然後將有關的引數和模型(引數間的關係)輸入軟體,然後自行設計輸出的格式才能得到相應的結果,有時這種過程是如此繁複以致在使用者的感覺中完全抵消了強大的分析能力和精美的輸出結果。實際上,目前大多數資訊系統所替代的只是人類智力活動中相對機械化的部分,因此機械化程度越高的工作(如上例中的帳務處理)當採用資訊科技後其改善勞動強度的效果就越明顯,而本身需要較多創造性勞動的工作(如上例中的財務分析)採用資訊科技後的改善效果就稍差。資訊科技的應用是從替代機械化的活動開始的,這就造成習慣於傳統資訊系統的使用者用傳統的功能標準衡量新的、幫助人們進行更富有創造性的活動的資訊系統(如操作簡單性標準、易用性標準等),從而導致對系統進行不必要的操作上的簡化,而這種簡化又常常是以犧牲靈活性為代價的。
對資訊科技的不正確的理解和期望往往是導致應用專案的戰略風險的最根本的原因之一,組織高層管理者一廂情願地認為資訊科技的應用必然會帶來組織績效和效率的提高;業務和管理部門的人員急於瞭解資訊科技的使用是否能使他們的工作輕鬆一些,而不要損害他們在組織中的地位,並不時擔心是否能適應新工具的使用;技術人員則完全埋頭於技術,滿足於技術的先進性和專案的完成。所有的人都希望資訊科技為他們帶來益處,卻或沒有想到或不願正視資訊科技可能帶來的風險,更不願為這種潛在的風險承擔責任。因此,在專案啟動的初期就正視有關的風險並採取有效的對策(至少對可能發生的後果有所準備),對於資訊科技應用專案的成功就顯得十分必要了。[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-958819/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- PFMEA在專案風險管理中的應用
- FMEA技術在IT專案風險管理中的應用
- AI輔助專案管理過程風險分析與應對AI專案管理
- 專案管理之風險管理案例-專案交付風險專案管理
- 聯想公司專案風險管理解決方案及應用
- 專案風險管理
- 如何運用FMEA降低IT專案的技術風險?
- 達觀專案文件風險智慧分析系統,助力廣西電網實現專案風險管控
- 專案風險管理:透過五步降低風險
- 騰訊安全:超98%的Android應用存有安全風險Android
- 寶葫蘆檔案一體機:助力檔案資訊化戰略轉型
- 專案管理軟體的應用分析專案管理
- 亞馬遜雲科技推出兩大合作伙伴新專案 持續強化"3+3戰略"亞馬遜
- Gartner:戰略舉措中遺漏風險管理的成本是巨大的
- TL,你是如何管理專案風險的?
- 如何更有效管理專案風險?
- 什麼是資訊保安風險評估?資訊保安風險評估的步驟?
- 資料專案風險-都在為別人著想
- Dealroom:2023年Q3全球科技風險投資報告OOM
- ASR專案實戰-任務佇列在檔案轉寫特性中的應用佇列
- 什麼是專案風險管理?要如何執行風險管理?
- FMEA和HAZOP在煤氣櫃風險分析綜合應用
- AI技術在基於風險測試模式轉型中的應用AI模式
- 管理專案風險:考慮你的專案可能出現的問題
- FMEA在有機熱載體鍋爐裝置風險分析中的應用
- 後端開發都應該瞭解的資訊洩露風險後端
- 《2021網路空間測繪年報》解讀|應用風險分析
- go語言實戰教程:Redis實戰專案應用GoRedis
- 專案管理中的風險登記冊的概念及作用專案管理
- Dealroom:2023年城市科技風險投資報告OOM
- ClubSphere專案主要風險和典型使用者
- 實戰專案 10: 貨物清單應用
- 智慧網聯汽車資訊保安風險分析及實踐探討
- 入門Python資料分析最好的實戰專案(二)Python
- 入門Python資料分析最好的實戰專案(一)Python
- "Hello World"背後的風險分析
- 報表模板—在專案管理中應用資料包表分析專案管理
- 《Gartner十大安全專案之“基於風險的弱點管理專案”》
- 2021年全球風險展望:連鎖效應,3-5年中期風險(附原資料表)