系統架構設計筆記(29)—— 項目的選擇與提出

組織在信息化的過程中,可能基於各種動機提出系統項目的建設,有關人員要根據這些動機,提出和確定信息系統的工作範圍,確定項目立項,提出系統選擇方案,給出選擇結果。

1 項目的立項目標和動機

企事業單位在其自身的經營管理過程中,對於項目的立項建設可能具有多種動機,通常可歸結爲下列幾種。

(1)進行基礎研究並獲取技術

此類項目通常由大學院校或企業集團的戰略研究性部門提出和實施。小規模的研究組織可能僅僅是企業中的一個研發部門或從事研發工作的團隊;中大規模的研究組織包括研究所或研究院這種獨立建制的單位;大規模的研究性項目可類似於國家 863 計劃等跨行業 、 跨地域協作的國家級重大項目立項。

(2)進行應用研發並獲得產品

此類項目通常由企業進行立項和開發,企業立項的基本動機通常是爲了得到應用軟件產品並向目標客戶羣進行銷售從而獲取利潤等。產品一般會基於某類特定客戶羣體的需求進行設計,有明確和具體的研發目標需求,有嚴格的時間限制 、 資源預算等,因此可歸入 “ 應用研發 ” 型軟件。

應用研發型軟件通常具有一定的通用性,客戶廣泛,既可能是面向個人消費者的工具軟件(例如Office 、 殺毒軟件 、 遊戲軟件等),也可能是面向特定領域或行業的工具軟件(例如 SQLServer 數據庫 、 AutoCAD工程繪圖軟件 、 RationalRose這樣的建模工具軟件等)。

(3)提供技術服務

對此類項目進行立項的企業通常能向目標客戶羣提供比較全面的技術服務而不是單一的軟件產品。因此企業的服務範圍可能包含提供技術和解決方案的諮詢 、 利用現有產品進行系統集成和服務 、 面向特定客戶的軟件項目定製開發 、 對現有的軟件系統進行升級和改造 、 提供軟件應用相關的技術支持 、 服務和培訓等服務中的一個或多個內容。

總的來說,此類組織通常會面向一個特定行業 、 具有相對穩定性的客戶羣體,通過提供一種綜合性服務來獲取市場價值,因此可以把此類公司看做 “ 服務 ” 導向的組織。

(4)信息技術產品的使用者

信息技術的使用者是最終客戶。對他們來說,軟件項目的立項動機既不是爲了得到軟件產品而進行銷售,也不是爲了提供技術服務,而是通過購買產品或服務來得到使用價值。例如:一個消費者購買了繪圖軟件是爲了存儲和處理個人數碼相機中的照片;而一個企業通過實施 ERP ( EnterpriseResourcePlanning ,企業資源計劃)可能是爲了達到生產能力的控制 、 生產計劃科學性 、 提高管理水平 、 獲取新的決策能力 、 降低庫存成本 、 提高資金週轉率 、 建立面向市場訂單生產方式等目標,並期望通過這些目標的實現來增強企業競爭力 、 獲取更大的市場份額。對信息技術的使用者來說,信息技術是一種手段,同時也是一種成本。如何用最小的成本和風險獲得滿意的效果是客戶最關心的問題。

2 項目的選擇和確定

系統項目的選擇至少包含兩種實用性目的,一個是軟件開發公司在諸多的產品方向中選擇適當的方向進行研究和開發,另一種是客戶從諸多的產品中購買適合自己需要的產品或選擇適合自己需要的技術方案進行實施。與系統項目提出的問題一樣,並不存在一個統一模式進行系統項目的選擇和取捨,但可以提出進行項目取捨和評估的若干原則。通過使用項目取捨和評估的原則,可以逐步排除那些不符合需求的項目定義,從而找到比較適合的項目或產品開發方向。

2.1 選擇有核心價值的產品/項目或開發方向

這個策略關鍵在於確定什麼樣的系統項目是有價值的。由於立項單位所處的行業 、 在行業中的位置 、 立項目標等因素不同,對軟件項目的價值判斷也不同。但 “ 有核心價值的軟件項目 ” 通常總是和企業或客戶的核心業務相關的。

美國哈佛商學院的著名教授 MichaelPorter 曾經在他的 《 競爭優勢 》 ( CompetitiveAdvantage )一書中提出了 “ 價值鏈 ” 的概念,價值鏈把企業運作的各種活動劃分爲產品設計 、 產品生產 、 產品營銷和產品應用等獨立領域,企業的價值鏈也可以進一步和上游供貨商與下游買主的價值鏈相連,從而構成一個產業的價值鏈。如果以 “ 價值鏈 ” 的觀點來看待軟件產品或項目,軟件是作爲一種技術服務手段被運用到企業業務的價值鏈上的,通過實現價值鏈中的關鍵業務的信息化從而最終改善客戶單位的企業質量,同時也使軟件開發公司獲得現實的經濟利益。

因此,在企業或客戶經營活動中對價值鏈增值最大的部分,就是企業或客戶的 “ 核心業務 ” 。 針對核心業務的信息化產品或項目,通常都是具有高價值的,也可以說,所謂的 “ 行業信息化 ” 的關鍵就是該行業中這些核心業務的信息化改造。例如:

(1)對生產製造業的企業來說,生產計劃 、 庫存控制 、 實現面向訂單的生產就是核心業務,無論實施 ERP 還是小規模的 MIS 系統,針對這些部分的軟件功能總是被客戶認爲是最有價值的。

(2)對於金融保險行業來說,由於保險公司的基本職責是分攤風險和補償損失,所以一般要求保險公司有足夠的分散風險的能力。因此,管理保單數據的業務系統 、 評估風險的定損系統等就是非常有價值的軟件系統。

(3)對於教育行業來說,因爲學校的核心職能是教書育人,因此與教研 、 教學 、 考試 、 評價等業務相關的軟件系統,以及支持上述業務開展的教育資源庫軟件 、 電子圖書館軟件等就是高價值的軟件系統。總之,選擇軟件項目,必須首先考察軟件應用的行業 、 業務和目標,以便判明要建設的軟件項目價值。

2.2 評估項目風險、收益和代價

在判斷出一個潛在的軟件項目後,還應評估項目實施的風險 、 收益和維護付出的代價。對於開發產品進行銷售的情況,主要評估的是產品的預期收益和爲完成開發投入的各種資源(包括時間 、 人力 、 資金等),項目的風險主要是技術難度 、 技術能力 、 經濟能力和各種資源是否能承擔 、 是否是企業需要優先實施的項目 、 是否符合行業標準和國家政策規定(例如:在電子簽章沒有經過國家法律許可之前,使用電子簽章替代手工操作可能是有風險的)等。

對於購買產品或技術服務的客戶來說,還應該評估項目實施後對自身業務變更,組織機構和人員職責的影響,現有的業務流程和人員的 IT 技能是否能滿足要求,是否需制定相關的系統維護 、 運行規約和規章制度等。而項目實施的實際開銷,除購買產品或服務的開支外,通常還包括各種系統維護 、 改進 、 培訓,招聘新職員,變更業務流程等各種應用方面的開銷。以總持有成本( Total Owner Cost , TOC )來評估信息化的代價才能比較準確地得到項目的實際代價。

評估項目風險 、 預期收益和代價後,可篩選掉多數不符合企業要求的建議項目。

2.3 評估項目的多種實施方式

對於已經確認有價值 、 並且有能力開發的軟件項目,則可以進一步參照企業現狀考察項目的實施方式。這種實施方式通常既包括了前面對項目風險 、 預期收益和資源開銷的評估,也包含了企業對現階段經營目標和現有資源如何合理運用的考慮。這個過程通常由項目的負責人和企業中高層經理進行決策,決策結果決定了項目的實施優先級及具體的實施方式。

需要說明的是,企業完成軟件項目的方式並不單純限制於自己組建開發團隊進行軟件項目或軟件產品開發的策略。根據具體情況不同,還可能使用諸如轉包開發業務給外部公司 、 直接 OEM ( Original Equipment Manufacture ,原始設備製造商)軟件產品並進行系統集成 、 購買關鍵技術並進行 “ 軟件集成 ” 方式的開發 、 完成技術方案和設計,然後尋求外部公司進行編碼等各種方式。對這些項目實施方式的取捨,主要依據依然是對項目風險 、 收益和資源開銷綜合平衡的考慮。

2.4 平衡地選擇適合的方案

人們在選擇可行的方案時,總是希望得到高質量 、 低成本的產品和方案。軟件開發人員通常也很願意在產品開發中,向產品加入創造性的內容。另一方面,客戶單位在面對諸多的投標方案時,會聽到各種各樣關於技術先進性 、 快速開發 、 產品質量穩定可靠 、 價格如何低廉 、 推薦的方案有多少成功應用等宣傳。然而:

(1)新技術可能意味着未來更多的變化從而導致風險,也意味着未來產品的使用者需要更多的學習和導入期,而採用成熟的技術則可能享受不到新技術帶來的好處。

(2)不基於某種快速開發技術或平臺構造的產品可能會延長項目開發時間從而導致更多的開銷,但基於某種平臺的產品又可能使得用戶未來 “ 綁定 ” 在某種平臺之上,減少未來的自由選擇性。(

3)不考慮系統的擴展性則很可能在業務變更時,會受阻於已經實施的 IT 設施,但過多考慮系統的擴展性,軟件接口通常就需要花費較大的力氣進行設計,那麼用戶是否在當前的購買中爲一些自己並不需要的特性多支付成本?尤其在軟件技術高速發展的今天,當用戶期望進行系統升級的時候,常常會發現原來的計算體系已經早就被開發單位淘汰和拋棄。

(4)價格低廉的產品可能具有好的質量,也可能有些功能並不那麼讓人滿意,而最重要的是,當關注這些具有先進性 、 低成本及擁有衆多成功應用的產品或方案的時候,項目的選擇者容易失去對自己目標的關注,即這些先進技術或宣傳的產品特性是否確實是自己需要的?

事實上,對性能的要求常常是充滿矛盾的,任何時候都不存在一個完美無缺的方案,只存在一個對當前的項目目標相對比較適合的方案。項目的決策者必須從最終的項目目標出發,判明各種功能或性能的重要性和優先級。在拋棄明顯存在問題的 “ 差 ” 項目後,選擇項目的基本立場應該是 “ 適合 ” ,而不是儘可能的 “ 好 ” 。(實際上任何超出預期設定目標的 “ 好 ” 性能,通常都意味着更多的成本。)

更進一步地看, “ 適合 ” 的方案就是平衡考慮開發單位利益和客戶滿意度的方案。圖 1 是 Noriaki Kano 提出的顧客質量模型圖,要求質量是客戶認爲產品應該具備的功能或性能,實現越多客戶會越滿意;假想質量是客戶想當然認爲產品應具備的功能或性能,客戶並不能正確描述自己想當然要得到的這些功能或性能需求;興奮質量則是客戶要求範圍外的功能或性能(但通常是軟件開發者很樂意賦予產品的技術特性),實現這些性能客戶會更高興,但不實現也不影響其購買的決策。

顯然,項目開發方更多考慮的是項目風險和回報。而客戶更多關心的是成本和購買後的滿意度。好的方案必須平衡考慮這些因素。系統分析師應儘可能用技術手段來平衡這些彼此對立的要求,保證在項目預期投入資源可接受的範圍內,儘量實現客戶要求質量對應的功能和性能 、 發掘客戶假想質量對應的功能要求並進行溝通確認,但按自身所服務企業的經營目標平衡考慮客戶興奮質量的實現策略(是努力提供興奮質量的功能 、 爭取忠誠的客戶獲得遠期潛在的收益,還是削減這些功能 、 以便使項目的成本最小化)。

系統設計師常犯的一個錯誤,就是用自己對技術的興趣產生的興奮質量,來替換客戶最基本的要求質量和假想質量。而企業經營者常犯的錯誤,則可能是對客戶提出的合理要求質量視而不見;或者走向另一個極端,不加區分地把一切未經評估的假想要求質量不斷指派給軟件開發團隊。這些都是錯誤的做法。

3 項目提出和選擇的結果

系統項目提出和選擇的結果,最終會以 “ 產品 / 項目建議書 ” 的方式來體現。

典型的應用場景是:
(1)在投標項目中,產品 / 項目建議書通常是乙方提交給甲方競標方案的一部分;
(2)企業單位在確立了要開發某類型產品後,對該產品進行多角度的評估,最終項目立項人向上級提交供決策的建議報告的主要內容就是 “ 產品 / 項目建議書 ” 。

產品 / 項目建議書是一個包含多種綜合內容的報告,涉及的範圍通常要比 GB8567-1988 標準中規定的標準—— “ 項目可行性分析報告 ” 的內容更全面。在項目建議書中,可能包含如下幾個部分:

  • 用戶單位、項目或產品的立項背景、需求來源和目標性的介紹;
  • 用戶的內外部環境、組織機構、現有的 IT 設施情況等;
  • 用戶的業務模型和業務規劃;
  • 預期要建設的技術系統在用戶業務中的位置和作用;
  • 信息化後的用戶業務模型、軟件應用方式、相關的部署環境、運行規則、管理規範等;
  • 爲實現信息化業務模型,技術系統的產品需求定義(功能、性能、約束)和部署方式等;
  • 產品或項目的技術框架;
  • 項目的要點、技術難點、主要實施障礙等;
  • 項目或產品的可行性研究結果;
  • 項目可選擇的實施方式、組織方式、溝通和協調機制等;
  • 項目的資源範圍和預算(人、財、物、時間等);
  • 項目的成本/收益分析;

其他項目建議書可能包含的內容,或以單獨文檔列舉的內容可能包括:

  • 項目風險及影響評估;
  • 項目進度計劃;
  • 項目質量計劃;
  • 項目過渡期資金的獲得方式、財務計劃;
  • 產品或項目的商務模式、盈利模式論述;
  • 同類產品或公司的市場調查結果,以及競爭性比較;
  • 企業成功案例、資質等;
  • 商務條款或供應商/客戶合同;

項目建議書標誌着項目立項和選擇階段性工作的完成,一旦項目建議書被批准通過,項目即可進入正式的開發準備和實施階段。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章