資訊化決定權之爭:權力之爭導致專案資源內耗(轉)
權力之爭導致專案內耗,資訊和業務部門幸福聯姻難成
在資訊化建設的過程中,資訊化建設要為業務服務,這已經成為資訊化實施過程中的一條基本規律。如果資訊化不能支援業務的發展和運作,那麼資訊化建設就失去意義了。
但很多慘痛的案例也讓企業反思資訊化建設的這項原則:業務部門作為需求的提出者,一定就要成為資訊化建設的主導者嗎?真的是要由業務部門來決定資訊化需求,IT系統建設就可以一往直前了嗎?但如果不是這樣,那麼雙方應該扮演什麼樣的角色?
誰來主導
對於這樣的問題,並不是一開始就能夠達成共識。
在企業內部,資訊化需求經歷了從無到有的過程,可以根據資訊和業務部門雙方對IT需求的決定權程度不同,將其大致分為四個階段:啟蒙階段、IT部門決定階段、業務部門決定階段、IT與業務部門共同決定階段。
其中,IT部門決定需求的階段通常是企業剛剛嘗試資訊化,應用水平比較低,部門人員各自為政,沒有專門關注需求擴充的階段。在這一階段,一般是由企業資訊部門的技術人員(或外部軟體開發商)在向企業業務部門瞭解了基本的資訊化需求後,提出一個相應的解決方案。如果業務部門沒有異議,便按照該方案實施開發。
這種由資訊部門主導需求的IT建設模式,一個最大的問題就是由於知識背景的不同和理解上的偏差,技術人員很難做出真正符合業務部門需要的方案,然而這樣往往會導致開發出來的資訊系統不好用、不適用,不能有力地支撐業務的發展,相反也會給業務部門帶來許多煩惱。
但如果由業務部門主導資訊化需求,業務部門會關注如何解決部門碰到的問題,這樣思考的角度難免會陷於區域性和短期,他們就會將資訊化投入成本視為資訊部門單獨處理的問題,同時業務部門也就儼然以評判者自居,超然在資訊部門之上“指點江山”。
並且由於業務部門對資訊科技的瞭解並不深入,往往會提出一些不切實際的要求。這就造成資訊部門難以處理相關的需求,同時雙方會相互猜疑對方的工作能力和協作誠意,給充分的進行溝通蒙上了陰影,影響到今後的工作開展。有時,資訊部門還可能發現業務部門提出需求的連續性下降,出現了多變和氾濫的趨勢。資訊部門會感到業務部門需求一天一個變,難以招架,資訊化建設專案也會由於需求的不斷變更,一拖再拖,難以收尾。
由業務部門主導資訊化需求,同時也會出現濫用權力的現象。當管理、流程的改造涉及到一些部門的利益時,業務部門往往利用權力,維護部門利益。他們不是從企業的角度,而是從自己部門利益的角度出發來衡量資訊化的意義,在各方面為自己爭權,從而給企業整體的資訊化程式製造障礙。
擺正位置
如果業務部門武斷地認為,“業務部門的主導作用就是由使用者提出需求,由資訊部門來實現”或“開發是資訊科技部門的份內工作,我們只管使用系統,有問題就由資訊部門來改”,那麼抱有這種“你開發,我使用”態度的使用者,通常不會主動參與到資訊化開發過程中去。但事實上,資訊化建設需要業務部門的全程參與。
在企業資訊化設計和開發的過程中,業務部門的作用同樣重要。資訊化的終端使用者是業務部門,所以業務部門對資訊化建設的最終結果應當擔負起相應的責任來。事實上,資訊系統的建設本身是個過程,而不是一次單點交付,在這個過程中存在許多控制點是業務部門可以發揮作用的。
同時在資訊系統上線以後,業務部門應當積極地參與到學習活動中以配合系統上線。如果業務部門把學習資訊系統看作是額外的負擔,缺乏學習的主動性,那麼資訊系統的實際使用效果自然也就難以保證了。如果他們認為:資訊化開展得不好,是因為資訊科技部門水平低,實現不了使用者的需求,甚至把資訊化發展不利的責任完全歸咎於資訊科技部門的技術水平,卻不考慮自己的資訊化操作能力如何,就更是一種不負責任的態度和做法,這將會極大地挫傷資訊部門人員的積極性,並對企業資訊化的實現構成人為的障礙。
企業資訊化要成功,業務部門在資訊化建設過程中投入和付出的努力同樣十分重要,透過理清業務部門和資訊科技部門在資訊化建設中的相互關係,避免出現任何一方不得不單獨承擔義務和責任的情況,這樣可以使雙方更好地在資訊化建設中擺正自己的位置,確保業務部門與資訊部門明確各自的職責,相互協助,正確處理資訊化建設中的各種問題,從而最終提高資訊化建設的成功率。
企業戰略引導
而為了使企業能夠長期良好地發展,企業在制定整體戰略時,不能不考慮新技術的發展。新技術已經可以對新的商務模式起到主導和推動作用,是思考戰略問題所不能忽視的因素。隨著技術的發展,資訊化日益在企業的經營管理中扮演重要的角色,所以在戰略層面,企業需要結合業務和技術的發展,進行全面的思考,來決定資訊時代企業的發展戰略。
資訊部門作為全面支撐企業各項業務職能的平臺,已經成為重要的職能部門之一,資訊化建設同樣應當有相應的戰略設計,這就是資訊化規劃。從資訊化規劃這一層面來講,主要是資訊科技支援業務發展,所以應當以業務需求為導向,進行資訊系統整體化的規劃和設計。儘管在戰略層面,資訊科技的新發展同樣影響著業務的發展方向,但是規劃具體資訊系統的時候,資訊化建設專案就應當以已經確定了的企業戰略目標為導向,以滿足業務目標、實現業務需求、促進業務發展為目的來進行。
應該說企業資訊化的結果既不屬於資訊部門,也不屬於業務部門,而是屬於整個企業的,所以資訊化建設不能武斷地確定由誰說了算,由誰負責任就會一帆風順。而是需要資訊部門和業務部門在整個過程中,保持充分溝通、相互換位思考、通力合作,由雙方共擔責任、共享成果。有了一定資訊化經驗的企業,可以發現資訊科技部門和業務運作部門絕不是誰決定誰的簡單關係,而是需要企業整體努力才能達到的。為了企業實現盈利的最終目標,最好的辦法就是打破部門之間的疆界和壁壘,用企業戰略來引領資訊化建設。
[@more@]
在資訊化建設的過程中,資訊化建設要為業務服務,這已經成為資訊化實施過程中的一條基本規律。如果資訊化不能支援業務的發展和運作,那麼資訊化建設就失去意義了。
但很多慘痛的案例也讓企業反思資訊化建設的這項原則:業務部門作為需求的提出者,一定就要成為資訊化建設的主導者嗎?真的是要由業務部門來決定資訊化需求,IT系統建設就可以一往直前了嗎?但如果不是這樣,那麼雙方應該扮演什麼樣的角色?
誰來主導
對於這樣的問題,並不是一開始就能夠達成共識。
在企業內部,資訊化需求經歷了從無到有的過程,可以根據資訊和業務部門雙方對IT需求的決定權程度不同,將其大致分為四個階段:啟蒙階段、IT部門決定階段、業務部門決定階段、IT與業務部門共同決定階段。
其中,IT部門決定需求的階段通常是企業剛剛嘗試資訊化,應用水平比較低,部門人員各自為政,沒有專門關注需求擴充的階段。在這一階段,一般是由企業資訊部門的技術人員(或外部軟體開發商)在向企業業務部門瞭解了基本的資訊化需求後,提出一個相應的解決方案。如果業務部門沒有異議,便按照該方案實施開發。
這種由資訊部門主導需求的IT建設模式,一個最大的問題就是由於知識背景的不同和理解上的偏差,技術人員很難做出真正符合業務部門需要的方案,然而這樣往往會導致開發出來的資訊系統不好用、不適用,不能有力地支撐業務的發展,相反也會給業務部門帶來許多煩惱。
但如果由業務部門主導資訊化需求,業務部門會關注如何解決部門碰到的問題,這樣思考的角度難免會陷於區域性和短期,他們就會將資訊化投入成本視為資訊部門單獨處理的問題,同時業務部門也就儼然以評判者自居,超然在資訊部門之上“指點江山”。
並且由於業務部門對資訊科技的瞭解並不深入,往往會提出一些不切實際的要求。這就造成資訊部門難以處理相關的需求,同時雙方會相互猜疑對方的工作能力和協作誠意,給充分的進行溝通蒙上了陰影,影響到今後的工作開展。有時,資訊部門還可能發現業務部門提出需求的連續性下降,出現了多變和氾濫的趨勢。資訊部門會感到業務部門需求一天一個變,難以招架,資訊化建設專案也會由於需求的不斷變更,一拖再拖,難以收尾。
由業務部門主導資訊化需求,同時也會出現濫用權力的現象。當管理、流程的改造涉及到一些部門的利益時,業務部門往往利用權力,維護部門利益。他們不是從企業的角度,而是從自己部門利益的角度出發來衡量資訊化的意義,在各方面為自己爭權,從而給企業整體的資訊化程式製造障礙。
擺正位置
如果業務部門武斷地認為,“業務部門的主導作用就是由使用者提出需求,由資訊部門來實現”或“開發是資訊科技部門的份內工作,我們只管使用系統,有問題就由資訊部門來改”,那麼抱有這種“你開發,我使用”態度的使用者,通常不會主動參與到資訊化開發過程中去。但事實上,資訊化建設需要業務部門的全程參與。
在企業資訊化設計和開發的過程中,業務部門的作用同樣重要。資訊化的終端使用者是業務部門,所以業務部門對資訊化建設的最終結果應當擔負起相應的責任來。事實上,資訊系統的建設本身是個過程,而不是一次單點交付,在這個過程中存在許多控制點是業務部門可以發揮作用的。
同時在資訊系統上線以後,業務部門應當積極地參與到學習活動中以配合系統上線。如果業務部門把學習資訊系統看作是額外的負擔,缺乏學習的主動性,那麼資訊系統的實際使用效果自然也就難以保證了。如果他們認為:資訊化開展得不好,是因為資訊科技部門水平低,實現不了使用者的需求,甚至把資訊化發展不利的責任完全歸咎於資訊科技部門的技術水平,卻不考慮自己的資訊化操作能力如何,就更是一種不負責任的態度和做法,這將會極大地挫傷資訊部門人員的積極性,並對企業資訊化的實現構成人為的障礙。
企業資訊化要成功,業務部門在資訊化建設過程中投入和付出的努力同樣十分重要,透過理清業務部門和資訊科技部門在資訊化建設中的相互關係,避免出現任何一方不得不單獨承擔義務和責任的情況,這樣可以使雙方更好地在資訊化建設中擺正自己的位置,確保業務部門與資訊部門明確各自的職責,相互協助,正確處理資訊化建設中的各種問題,從而最終提高資訊化建設的成功率。
企業戰略引導
而為了使企業能夠長期良好地發展,企業在制定整體戰略時,不能不考慮新技術的發展。新技術已經可以對新的商務模式起到主導和推動作用,是思考戰略問題所不能忽視的因素。隨著技術的發展,資訊化日益在企業的經營管理中扮演重要的角色,所以在戰略層面,企業需要結合業務和技術的發展,進行全面的思考,來決定資訊時代企業的發展戰略。
資訊部門作為全面支撐企業各項業務職能的平臺,已經成為重要的職能部門之一,資訊化建設同樣應當有相應的戰略設計,這就是資訊化規劃。從資訊化規劃這一層面來講,主要是資訊科技支援業務發展,所以應當以業務需求為導向,進行資訊系統整體化的規劃和設計。儘管在戰略層面,資訊科技的新發展同樣影響著業務的發展方向,但是規劃具體資訊系統的時候,資訊化建設專案就應當以已經確定了的企業戰略目標為導向,以滿足業務目標、實現業務需求、促進業務發展為目的來進行。
應該說企業資訊化的結果既不屬於資訊部門,也不屬於業務部門,而是屬於整個企業的,所以資訊化建設不能武斷地確定由誰說了算,由誰負責任就會一帆風順。而是需要資訊部門和業務部門在整個過程中,保持充分溝通、相互換位思考、通力合作,由雙方共擔責任、共享成果。有了一定資訊化經驗的企業,可以發現資訊科技部門和業務運作部門絕不是誰決定誰的簡單關係,而是需要企業整體努力才能達到的。為了企業實現盈利的最終目標,最好的辦法就是打破部門之間的疆界和壁壘,用企業戰略來引領資訊化建設。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-954859/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 介面的所有權之爭
- 為安全妥協,起底普京XP系統背後的資訊主權之爭
- AQS原始碼探究之競爭鎖資源AQS原始碼
- 服務與資料之爭
- 微軟“修改” MIT 專案原作者版權宣告引爭議:自動化指令碼出問題 | 現已恢復正確 LICENSE 檔案/版權資訊微軟MIT指令碼
- go 協程操作map導致的資料競爭及解決方法Go
- 如何看待Serverless資料庫之爭?Server資料庫
- 導致專案需求蔓延的原因 應對專案蔓延的資訊化手段
- 故障:核心表業務高峰期授權導致library cache lock和mutex x競爭Mutex
- 彭博社:團隊內鬥和資金壓力導致《魔獸爭霸3 重製版》的失敗
- 《權力的遊戲 最終季》資料前瞻:誰領跑鐵王座之爭?九大家族剩餘力量幾何?遊戲
- crond不斷喚起sendmail導致資源耗盡的排查AI
- 滲透之——資料庫提權資料庫
- 南大通用榮登2021行業資訊化競爭力百強榜行業
- 資訊資源管理文字題之“結合案例分析資訊資源規劃包含的內容”
- 伺服器虛擬化開源技術主流架構之爭伺服器架構
- 是什麼決定了關鍵詞的競爭力?又該如何提升關鍵詞競爭力?LEE
- 國內唯一!騰訊iOA被權威機構報告列入競爭者能力象限
- 中小製造企業的數字化轉型之爭也是「供應鏈之戰」
- Metasploit之後滲透攻擊(資訊收集、許可權提升)
- 育碧正版授權《魔法門之英雄無敵:領主爭霸》今日預約開啟
- 『《權力的遊戲 最終季》資料前瞻:誰領跑鐵王座之爭?九大家族剩餘力量幾何?』今日資料行業日報(2019.04.16)遊戲行業
- 為什麼說流媒體之爭也是新型廣告模式之爭?模式
- 優質投資的特徵與競爭力特徵
- INGECMF 開源專案 內容管理框架 auth許可權管理 招募框架
- 首屆東亞電競錦標賽開戰!皇室戰爭夢之隊力爭金牌
- 內網滲透之——mssql資料庫提權之——xp_cmdshell執行系統命令內網SQL資料庫
- 記一次 Laravel日誌許可權許可權問題(定時器導致)Laravel定時器
- 架構之爭,Wave Computing 宣佈MIPS將開源架構
- 前端框架之爭丨除了Vue、Angular和React還有誰與之爭鋒前端框架VueAngularReact
- 龍象之爭:資料告訴你真實的差距
- 微信小程式授權登入以及使用者資訊相關介面調整導致授權框不彈出微信小程式
- enq: TM - contention解決之道——外來鍵無索引導致鎖爭用ENQ索引
- DRF內建許可權元件之自定義許可權管理類元件
- 資訊系統專案管理系列之五:專案整體管理專案管理
- 資訊系統專案管理系列之六:專案範圍管理專案管理
- 準備加入 AI 時代主導權爭奪戰,歐盟謀劃 AI 新政AI
- 多執行緒下解決資源競爭的7種方法執行緒
- D專案軼事之現場直播導主資料