第十章 資訊系統開發與管理

1. 第十章 資訊系統開發與管理 • 治國之有法術賞罰，猶若陸行之有犀車良馬也，水行之有輕舟便輯也。 -- 韓非子 (B.C.280 – B.C. 233) • There is no security on earth. There is only opportunity. (地球上沒有安全，只有機會) -- 麥克阿瑟將軍

2. 一、企業內的企業 二、資訊系統開發 三、資訊系統經濟評估 (略) 四、資訊系統規劃 (略) 五、生命週期(SDLC)資訊系統開發方法 六、雛型開發方法 七、套裝軟體與企業資源規劃 八、資訊系統專案管理 (略) 九、使用者自建系統 十、資訊系統委外 十一、應用服務提供 (略) 十二、網路服務架構 (略) 十三、資訊系統建置 十四、資訊部門組織與地位 (略) 十五、資訊安全與控制 (略) 十六、資訊系統的評估與失敗的原因 綱要

3. 一、企業內的企業 • 1980年代，資訊部門被稱為企業內的企業(a business in a business) • 企業的功能: 生產、行銷、會計、財務、人力資源、研究發展、策略管理。 • 資訊部門: 生產作業的資訊、成本及計價(會計)的資訊、IT投資與效益分析(財務管理)。 • 1990年代，資訊科技或處理方式變化， • 例如: 使用者自建系統、分散式處理、委外開發或處理。 • 資訊部門的界限模糊: 其功能分散到企業內各部門或企業外的委外公司。 • 資訊科技的應用不一定要跟著潮流走。 • 先入者優勢(first mover’s advantage )不是永遠是對的。 • 企業要評估自己的策略、規模、結構、文化、能力、技術、財務、外在的競爭，選擇適合的資訊科技應用。

4. 二、資訊系統開發 圖10-1 資訊系統開發

5. 圖10-2 軟體專案開發的實情 5

6. 6

7. 五、生命週期資訊系統開發方法 • 生命週期法(System Development Life Cycle, SDLC)是開發資訊系統的傳統方法，又稱為瀑布模式(waterfall model)。 • 包括: 系統規劃、系統分析、系統設計、程式設計、系統測試、系統建置等階段，序列式進行，每個階段有其標準程序和文件。 • 修改資訊需求規格，按規定填寫變更需求申請單(change request)。 • 使用者在系統設計階段以後，資訊需求的變更就比較困難。 圖10-7 生命週期溝通不良的錯誤結果

8. 系統分析與設計 • 一般系統分析的本質: 調查整個系統問題的內涵，研究系統的目標、系統效果的標準，並且評估各方案的效果與成本。 • 系統分析可以應用於資訊系統的開發建立: • 定義其成分及整體性的考量。 • 定義資訊處理子系統，說明邊界及介面。 • 系統的模式、回饋與控制功能。 • 開發計畫的時程，控制、監督開發過程。 • 指定專案主持人，負責劃分子系統、控制時間、成本、品質。

9. (一) 結構化分析與設計 • 由上而下(top-down)定義子系統。 • 階層式: 每個階層子系統之間的介面要清楚定義。 • 模組化: 邊界與介面都定義了，可以應用黑箱(black box)的觀念: • 在高階層的設計中，可以將低階層的子系統視為黑箱。 • 例如: 訂單處理系統，信用檢查是它的子系統， • 先將信用檢查當作黑箱，不定義如何檢查信用，只定義它的投入與產出(input and output)，訂單處理系統就可以繼續分析。 • 細部設計時，才根據投入與產出，定義信用檢查子系統。 • 減小聯繫力(coupling): 使各子系統愈獨立愈好。 • 將系統可能改變的影響，可以單獨處理，增進系統的適應性。 • 越容易修改一個子系統，而不影響其他的子系統。

10. (二) 物件導向分析與設計 • 物件(object)是系統中特定實體(entity)或有意義的概念 • 本身存有一組資訊來表示物件的現況(屬性、狀態) • 擁有一組屬於該物件的行為(活動或操作)，可以改變此物件的現況。 • 物件導向(object-oriented)程式設計是近年來程式設計的新觀念， • 站在人性化(使用者)的觀點，思考程式的邏輯。 • 將所需要的程式碼與資料放在一起，形成一個物件。 • 汽車物件: • 屬性: 車型、排氣量、廠牌、汽缸數、顏色。 • 行為: 發動、開車門、開冷氣。 • 物件導向程式語言 • 80年代: Smalltalk • 90年代: C++, Java

11. 物件導向的基本法則 • 封裝(encapsulation): 物件 = 屬性 + 行為 • 所有物件的操作方式及介面，均定義在行為的部分。 • 撰寫程式時，可以利用黑箱的概念，輕鬆連結不同物件。 • 繼承(inheritance): 新的物件可以繼承原有的物件，修改增加新特性，適合新的應用程式。 • 多型(polymorphism): 同一名稱，可以因物件不同，賦予不同的意義。 • 例如: 令食物(food)物件具備計算所含熱量(calorie)的功能，不同的食物類別(class)可以有不同計算方式。 • 可以利用繼承關係，定義不同的計算所含熱量的功能。

12. 六、雛型開發方法 • 雛型開發方法(prototyping)，或稱為快速應用設計(rapid application design/development) • 很快的設計出一個雛型系統，讓使用者和分析師在互動和循環過程中，修改這個雛型，一直到完成系統。 • 運用的時機: 使用者需求開始時無法清楚的定義。 • 雛型開發方法的步驟: • 使用者和資訊專業人員成立小組。 • 設計初步雛型綱要。 • 利用雛型發展工具，建立雛型。 • 畫面和結果展示給使用者。 • 使用者回饋和修改。 • 請專家提供改進建議或是否合乎組織標準。 • 完成雛型系統。 • 使用者接受。 • 建置維護。

13. 七、套裝軟體與企業資源規劃 • 應用套裝軟體(application package)是軟體公司已開發好的一套程式，可以商業化的出售或出租。 • 以多數企業的普遍需求來製作 • 若企業有特殊需求，要修改套裝程式，通常軟體業者會給予客製化的彈性，但成本會增加很多。 • 企業資源規劃(Enterprise Resource Planning, ERP)基本上是從物料需求規劃(MRP)演進而來的企業規劃方法，是一門學科，包括: 限制理論、作業計畫、庫存策略等。 • ERP導入失敗因素: 似乎都歸罪於使用者公司。 • ERP實施問題: 實行、成本效益、溝通、狗吃狗食(dog eats dog food)、穩健性、彈性、系統整合、策略優勢或策略必要。

14. 九、使用者自建系統 • 1980年代以前，資訊系統的功能(IS function)，都是由資訊專業人員來管理和控制的。 • 1980年代，許多這些責任移轉到使用這些資訊的人身上，這些人稱為(終端)使用者(end users)。 • 電腦硬體和軟體的進步，改善了資訊科技的取得(available)、經費負擔(affordable)、使用方便(usable)。 • 個人生產力軟體: 文書處理、試算表、資料庫管理系統。 • 第四代語言、圖形介面、滑鼠、筆式輸入、雷射印表機。 • 電腦通訊和網路。 • 使用者自建(End-User Computing, EUC): 讓使用者或其他部門自行開發設計系統，而資訊人員扮演協助、訓練、提供工具的角色。

15. 使用者自建系統的優點及風險 • 使用者的種類 • 非程式的使用者(non-programming end users) • 下指令的使用者(command-level users) • 寫程式的使用者(end-user programmers) • 功能支援人員(functional support personnel) • 使用者自建系統(EUC)的優點 • 紓解資訊人員短缺的問題。 • 消除資訊系統需求決定的問題。 • 消除技術的系統專家和非技術的使用者間潛在的問題。 • 使用者自建系統的風險 • 系統分析師角色的消除，整個過程缺乏外在的檢視者。 • 確認應用軟體的正確性和完整性方面，使用者的能力是有限的。 • 過程中，缺乏軟體品質保證的程序。

16. 使用者自建系統的開發過程 圖10-12 使用者自建系統的開發與設計

17. 使用者自建系統的管理 • EUC政策制定: 確認適合的EUC實務、EUC活動的可接受型式。 • EUC計畫: 認清目標、建立協調合作、資源分配。 • EUC支援: 資訊中心是支援EUC的資訊單位，其功能為訓練使用應用套裝軟體、選擇硬體和軟體、協助使用資料庫、系統分析、設計及建置的協助。 • EUC控制: 確保計畫能有效的執行。

18. 十、資訊系統委外 • 策略委外(strategic outsourcing): 對企業而言，是一種特別形式的轉包契約。 • 委外或自行開發，可視為外購或生產的決策。(委外 =>外購; 自行開發 =>生產) • 委外(或外包)的服務: 警衛、保全、清潔、員工退休金儲蓄管理、會計、稅務、法律、儀器/存貨管理、廣告、伙食、資訊科技。 • 資訊系統委外(IS outsourcing): 將組織中資訊的儀器(電腦)、(網路)設備、軟體資料庫、(資訊)人員，以及相關活動等，部分或全部，移轉到外部的資訊服務提供廠商來管理。 • 1993年: 台灣資訊委外的市場有321億台幣，估計每年20%的成長率。 • 1996年: 行政院研擬行政部門資訊系統整體委外。

19. [實例] 英國石油探勘公司

20. 資訊委外的項目和市場 • 設備管理、硬體維修: 無成長，成熟市場。 • 作業顧問、套裝軟體安裝、流程再造: 成長，多由外界提供。 • 程式設計、系統整合: 微成長，部分會外包。 • 資料輸入與處理、作業管理: 成長，60%企業偏好內部提供。 • 網路管理: 高成長，未成熟市場，參見ASP。 • 災害回復: 成長，75%外包。 • 取得外部資料庫: 成長，Internet市場。

21. 資訊委外的理論基礎及動機 • 減少人員及薪資費用。 • 有利於資訊科技的開發。 • 具有彈性。 • 企業內部(資訊人員和使用者)的衝突可以避免。 • 委外也是一種獲得專門知識的方法。 • 策略原因，有關於企業再造、核心功能和競爭優勢。 • 委外公司大量採購或租賃，降低成本。 • 利用委外將分散式處理的企業文化，變成集中式。

22. 委外的風險危機 • 對服務失去控制。 • 委外聘僱人員誠信度可能比較低。 • 花費實際上可能比預估高。 • 企業可能因而失去委外功能的專門知識，並且再也無法獲取。 • 如果核心競爭力的選擇不智，則企業的精簡，可能造成長期營利的衰退。 • 有一些動作的花費也必須列入: 與委外公司的交易成本、研究、協調、監督、及管理聘僱人員。

23. 成功委外的技巧、合約項目 • 成功委外的技巧 • 委外的決策，目標界定都必須經過審慎考慮。 • 委外的服務，於服務合約內，指定對品質、可靠度及其他標準的要求。 • 避免任意簽訂支援服務的合約。 • 委外合約應考慮的項目 • 計畫: 成立合約管理小組、成員、草擬合約。 • 範圍: 界定服務範圍、如何支援、服務內容、預期變化等。 • 實效: 確認標準、量化參數、具體罰則。 • 實施: (1) 監視機制: 績效報告、付款作業、定期稽核。 • (2) 資源移轉流程。 • (3) 控制機制: 安全控制、損害賠償、款項扣留。 • 終止: 終止合約程序、終止時廠商應該之協助、買回條款。

24. 委外的關係 • 加值型委外(value-added outsourcing): 委外目的是為了改善經營績效。 • 相互持股型委外(equity holdings): 共同分擔風險。 • 多包商型委外(multi-sourcing): 避免單一委外的風險。 • 跨國型委外(offshore outsourcing): 將系統開發委外到低成本的國家，如印度是歐美國家主要的委外國家。 • 合作型委外(co-sourcing): 廠商依委外的績效分享收入，宏碁與台北銀行的公益彩券。 • 附屬型委外(spin offs): 將資訊部門獨立成一個子公司，將資訊作業委由該公司運作。 • 改進合約型委外(smarter contracting): 已經委外的企業，經過合約的修改或加附約，提升委外價值。 • 流程型委外(business processing outsourcing): 將非核心業務的流程及資訊作業委外處理。

25. 十三、資訊系統建置 圖10-19 系統轉換的方式

26. 十六、資訊系統的評估與失敗的原因 圖10-22 生產力矛盾