67
資訊系統的 規劃開發與管理

資訊系統的 規劃開發與管理 - U.camdemyu.camdemy.com/sysdata/doc/f/fffd357af0605e68/pdf.pdf · 專案管理的目的為何?為什麼它在開發 資訊系統的過程中如此重要?

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

資訊系統的 規劃開發與管理

學習目標

1. 新系統建置如何造成組織變革?

2. 系統開發過程的核心活動是什麼?

3. 系統塑模與設計的主要方法論是什麼?

4. 專案管理的目的為何?為什麼它在開發資訊系統的過程中如此重要?

5. 有哪些方法可以用來選擇與評估資訊系統專案,以及調整它與企業的目標一致?

6. 管理專案風險與系統導入有哪些有用的策略?

新系統與企業流程推MoneyGram「上金山」

問題:耗時的手動流程,過時的系統

解決方法:企業版套件來集中資料與取代過時的系統,改變企業文化和組織

展示使用資訊系統以簡化和重新設計業務流程

說明需要解決並改變文化和組織以支援新系統

Ch 13. 3

新系統與企業流程推MoneyGram「上金山」(續)

Ch 13. 4

13.1 以系統作為有計畫的組織變革

1. 自動化

增進效率

取代人工作業

2. 程序合理化

使標準作業程序更流暢

通常在持續品質改進的計畫中被發現

全面品質管理(TQM)

六個標準差

Ch 13. 5

以系統作為有計畫的組織變革(續)

3. 企業流程再設計

分析,簡化,與重新設計企業流程

重組工作流程,合併步驟,消除重複

4. 典範轉移

重新思考企業與組織的本質

設計新的企業模式

改變組織的本質

Ch 13. 6

圖13.1 組織變革帶來的風險和報酬

Ch 13. 7

企業流程再設計

企業流程管理(BPM) 提供各種的工具與方法分析既有的流程、設計新的流程,以及流程最佳化

用在公司以管理企業流程再設計

BPM步驟 1. 確認要改變的流程

2. 分析現行的流程

3. 設計新的流程

4. 執行新的流程

5. 持續量測

Ch 13. 8

圖13.2 實體書店買書的流程現況

Ch 13. 9

圖13.3 重新設計之網路購書流程

Ch 13. 10

企業流程管理工具

記錄與監控企業流程

辨識出沒有效率的地方

創造改進流程的模式

自動化某部分的企業流程,執行企業規則

幫助企業整合現行系統來支援流程改善

驗證新流程已經改善

測量流程中的變化對企業關鍵績效指標的影響

Ch 13. 11

互動個案部分:組織觀點

Burton Snowboards 加速推動靈活的企業流程 閱讀互動個案並討論下列問題

1. 哪運用價值鏈與競爭力模型來分析Burton。

2. 為什麼個案中所提到的這些企業流程對Burton 來說是如此重要的競爭優勢來源?

3. 試解釋這些流程改善如何強化Burton 的營運績效以及決策制定。

Ch 13. 12

13.2 系統開發概論

系統開發是用來生產資訊系統方案,解決組織問題或機會的活動

系統分析

系統設計

程式設計

系統測試

系統轉換

上線使用與維護

Ch 13. 13

圖13.4 系統建置流程

Ch 13. 14

系統分析

組織嘗試用資訊系統解決問題時的分析

定義問題、辨識原因

提出解決方案

系統建議書辨識與探討其他解決方案

識別資訊需求

包含可行性研究

這個系統是不是一個好的投資?

系統所需要的技巧是否可取得?

Ch 13. 15

系統分析(續)

建立資訊需求

確認誰需要什麼資訊、何處、何時與如何使用

定義了新系統或修正系統的目標

詳細說明新系統會執行的功能

錯誤的需求分析是系統失敗或產生大量系統開發成本的主因

Ch 13. 16

系統設計

詳細敘述在系統分析時所產生的系統規格

應該提出所有解決系統方案中管理、組織與技術問題的方法

終端使用者扮演的角色

使用者的資訊需求驅使整個系統建置的成果

使用者必須在設計流程中擁有足夠的掌控,以確保系統反映他們企業的優先順序與資訊需求

系統設計中不足的使用者參與是系統失敗的主要原因之一

Ch 13. 17

表13.1 設計規格

Ch 13. 18

完成系統開發流程

程式設計 設計步驟所設下的系統規格會被轉譯為軟體程式碼

測試 確保系統是否能產出好的結果

單元測試,由獨立測試系統中每個程式所組成

系統測試測試整個資訊系統的功能

接受度測試為系統已經準備好被用在生產設定中的最後確認

測試計畫:所有的測試前置工作 Ch 13. 19

圖13.5 改變一筆資料的測試計畫範例

Ch 13. 20

完成系統開發流程(續)

轉換 是從舊系統轉換到新系統的程序

四種轉換策略 1. 平行策略

2. 直接切換策略

3. 先導性研究策略

4. 階段性轉換策略

使用者需要被訓練

最終詳細文件可從技術和使用者的觀點來看系統如何運作

Ch 13. 21

完成系統開發流程(續)

上線與維護 系統會被檢視,以決定是否需要任何修正或調整

也許包括導入後稽核文件

維護:修改上線系統的硬體、軟體、文件或以修正系統錯誤程序、達到新需求或改善處理效率 20%排除錯誤或修正緊急生產問題

20%更改數據、檔案、報告、硬體或系統軟體

60% 工作:作為加強使用者的理解力、改善文件,以及為了更好的流程效率而重新改寫系統元件

Ch 13. 22

表13.2 系統開發

Ch 13. 23

13.3 其他的系統建置方法

傳統的系統生命週期法

雛形法

套裝應用軟體

使用者自建

委外

Ch 13. 24

傳統的系統生命週期法

系統生命週期法是最老的系統建置方法

階段式方法: 將系統開發分割為幾個正式的步驟

「瀑布式」方法:種每一階段工作完成後才會繼續下一階段

系統生命週期法在終端使用者及資訊系統專家間,保持一個正式的工作區分

強調正式規格書和文書作業

仍然常被用在建造大型複雜系統

非常耗費金錢與時間且沒有彈性的 Ch 13. 25

圖13.9 傳統系統開發生命週期

Ch 13. 26

雛形法

快速且便宜地建立一個讓終端使用者評估的實驗性系統

雛形是資訊系統或部分系統的工作版本,但它只是一個初步模型

當設計被敲定了,雛形可以被轉換成一個精鍊的上線系統

Ch 13. 27

雛形法(續)

雛形法的步驟

1. 確認使用者的基本需求

2. 發展初步雛形

3. 使用雛形

4. 修正並強化雛形

Ch 13. 28

圖13.10 雛形法的流程

Ch 13. 29

雛形法(續)

雛形法的優點 當需求或設計解決方案有許多不確定時,雛形法是最有用的

經常使用在設計一個資訊系統的終端使用者介面

更有可能產生符合使用者需求的系統

雛形法的缺點 可能忽略了一些系統開發的必備步驟

可能沒辦法輕易的與大量資料或大量使用者的操作環境相容 可能沒看到完整文件和測試的需求 Ch 13. 30

終端使用者自建

使用第四代語言容許資訊系統可以被不需要技術專家協助或少許協助的終端使用者開發

第四代語言:通常比傳統程式語言更少或是沒有程序化 PC 軟體工具

查詢語言

報表產生器

圖形語言

應用程式產生器

應用軟體套件

超高階的程式語言 Ch 13. 31

表13.3 電子商務的成長

Ch 13. 32

終端使用者自建(續)

終端使用者自建的優點:

專案更快被完成

高度使用者參與和滿意度

終端使用者自建的缺點:

沒有辦法輕鬆地處理大量交易或有廣泛程序邏輯且不斷更新的應用程式

卻沒有正式開發方法、測試和文件不恰當的

在傳統資訊系統部門以外的資料會在系統內失控

Ch 13. 33

終端使用者自建(續)

管理終端使用者自建

確認終端使用者自建資訊系統專案的成本

建立使用者開發應用的硬體、軟體與品質標準

Ch 13. 34

應用套裝軟體與委外

省時與省錢

向軟體服務供應商租借軟體、向商業供應商購買軟體套裝,或是透過軟體外包商的開發擁有客製化的應用程式。

Ch 13. 35

應用套裝軟體

許多套裝軟體提供客製化特色: 不用破壞軟體的整體性就能夠修改套裝軟體以符合組織的獨特需求

為系統分析的評估準則將包括: 套裝軟體提供的功能,彈性、使用者介面友善程度、硬體與軟體資源、資料庫需求、安裝與維護工作、文件、供應商品質以及成本

計畫需求書(RFP) 提供給套裝軟體供應商詳細的問題列表

用來評估替代的套裝軟體 Ch 13. 36

委外

委外的幾種形式

雲端計算與軟體服務供應商

企業可以使用服務所提供軟體與電腦硬體

外部供應商

雇用來設計、開發軟體

國內委外:主要是因為委外供應商擁有他們客戶沒有的技術、資源和資產所驅動

跨國委外:由節省成本所驅動

Ch 13. 37

委外(續)

委外的優點

容許組織資訊科技需求彈性

委外的缺點

隱藏成本,例如:

識別與評估資訊技術服務的供應商

轉換新的供應商

讓第三方公司可能開拓自營業務流程

Ch 13. 38

圖13.11 跨國委外的總成本

Ch 13. 39

手機應用系統開發

提供特殊需求以支援 較小的螢幕、鍵盤

多指觸控手勢

節省資源(記憶體、處理器)

自適應性網頁設計 讓網站可以根據使用者的螢幕分辨率,自動改變網頁安排

三種主要的平台 iPhone/iPad, Android, Windows Phone

Ch 13. 40

互動個案部分:組織觀點

在手機上開發有什麼不同? 閱讀互動個案並討論下列問題

1. 建置手機應用系統時,在管理、組織和科技方面有什麼議題需要被解決?

2. 手機應用系統的使用者需求定義和傳統的系統分析有什麼樣的不同?

3. 試描述,USAA 的企業流程在手機應用系統執行的前後改變為何。

Ch 13. 41

Nu Skin的新人力資源系統專案以人為優先

問題:需要實現整個企業的人力資源系統與新的和自動化的企業流程

解決方法:

SAP ERP人力資源管理

規劃和實施管理跨功能專案團隊代表不同的企業和使用者利益

說明需要的組織和專案管理以確保新科技的成功

Ch 14. 42

Nu Skin的新人力資源系統專案以人為優先(續)

Ch 14. 43

14.1 專案管理的重要性

失控的專案與系統失敗

失控的專案: 30%~40% 資訊科技專案 遠超過一開始預估的排程與預算

無法像指定般的被執行

系統失敗類型 不能獲得關鍵的企業需求

不能改善組織績效

複雜,組織糟糕的使用者介面

資料不準確或不一致

Ch 14. 44

圖14.1 不良專案管理的結果

Ch 14. 45

專案管理

專案管理包括規劃工作、評估風險、預估完成工作所需的資源、組織工作、取得人力與物質資源、指定任務、指揮活動、掌控專案執行、回報進度,以及分析結果

五大變數:

1. 範疇

2. 時間

3. 成本

4. 品質

5. 風險 Ch 14. 46

14.2 選擇專案

大型公司的資訊系統專案管理架構

公司策略規劃團隊:負責發展公司的策略規劃

資訊系統指導委員會:檢視與批准所有部門的系統計畫

專案管理團隊:負責數個特定的資訊系統專案

專案團隊:負責個別系統專案

Ch 14. 47

圖14.2 系統專案的管理控制

Ch 14. 48

連結系統專案和企業規劃

為了確保資訊系統專案可以傳達最大的企業價值,組織必須發展一個將策略系統融入高階規劃

這個規劃就像一張地圖,指出系統發展方向,包括: 規劃目的 企業策略規劃合理性 目前系統/狀況 考慮新發展 管理策略 規劃執行 預算

Ch 14. 49

表14.1 資訊系統計畫

Ch 14. 50

表14.1 資訊系統計畫(續)

Ch 14. 51

14.4 管理專案風險

專案風險的構面,影響專案風險的程度:

專案大小

透過花費的金錢、導入人員的多寡、導入時間的分配,以及受影響的組織單位數目等來衡量

組織複雜度亦須考量

專案結構

結構化,需求定義明確的專案風險較低

技術經驗

Ch 14. 52

變革管理與系統導入概念

變革管理

成功的系統建置需要做好

新資訊系統會產生重大的行為與組織影響

資訊被定義、存取與使用來管理組織資源的改變,經常導致新的職權與權力分配

內部的組織改變孕育抵抗與反對

Ch 14. 53

導入的概念

導入 是一項創新的採用、管理與例行化,如新的格式系統,所產生的所有組織活動

變革代理人 系統分析師需要扮演的一個角色

要重新定義各種組織團體的結構配置、互動、工作活動,以及權力關係

分析師是整個變革過程的促進因素

負責確保涉及的各方人員都能接受新系統造成的改變

Ch 14. 54

使用者的角色

使用者的角色

高度的使用者參與

系統更容易確認需求

使用者更容易接受系統

使用者─設計師的溝通鴻溝

使用者與資訊系統專家之間

不同的背景、興趣與優先順序

不同的組織忠誠度、解決問題的方法與詞彙的

對新系統的不同考量

Ch 14. 55

表14.4 使用者與設計者之間的溝通鴻溝

Ch 14. 56

管理階層的支持與承諾

不同管理階層支持與承諾該資訊系統專案:

系統比較可能被使用者與技術資訊服務人員正向的接受

確保充足資金與資源

有助於強制要求的組織變革

Ch 14. 57

企業流程再造、企業應用系統, 以及併購與收購者對變革管理的挑戰

不當的導入以及變革管理實務沒有解決

使用者對改變的疑慮

關鍵管理者的反對

改變工作部門、職涯規劃與招募實務

併購

整合專案有同樣高的失敗率

合併兩家公司的系統要求:

相當大的組織變革

複雜的系統專案 Ch 14. 58

控制風險因素

管理專案風險的第一步涉及辨識專案面對的風險本質和程度

導入者可以透過工具與風險管理方法,針對不同風險程度來控制每個專案

Ch 14. 59

管理技術的複雜度

內部整合工具

專案領導者需要很多的技術與行政經驗

團隊成員要非常有經驗

經常召開團隊會議

當重要的技術技巧沒有辦法從內部取得時,就應該尋求組織外的協助

Ch 14. 60

正式的規劃與控制工具

用來記錄與監控專案計畫

幫助管理者確認瓶頸和問題對專案的影響

甘特圖

視覺化呈現不同任務的時間、期間

不同任務的人力資源需求

PERT (計畫評核術)圖

以圖形化描繪專案工作與互動關係

指出需要活動的順序

Ch 14. 61

圖14.4 甘特圖

Ch 14. 62

圖14.4 甘特圖(續)

Ch 14. 63

圖14.5 PERT 圖

Ch 14. 64

增加使用者參與及克服使用者反對

外部整合工具

開發團隊與使用者在各階層鏈接工作

使用者抗拒組織變革

用戶可能相信變革不利於自己的

反對導入是一種人為的策略,用來阻撓資訊系統導入或組織創新

例如:錯誤率、中斷率、週轉率與破壞行為的增加

Ch 14. 65

增加使用者參與及克服使用者反對(續)

克服使用者抗拒的策略

使用者參與

使用者教育與訓練

管理法令與政策

給合作的使用者更好的誘因

改善終端使用者介面

在引進新系統前就能解決組織問題

Ch 14. 66

專案管理軟體工具

自動化專案管理的許多層面

具有下列能力: 定義、排序與編輯任務

分配任務資源

追蹤流程,以及協助任務與資源調整

Microsoft Project 2010 現今最常被使用的專案管理軟體

PERT、甘特圖、重要路徑分析

持續增加的軟體服務,開放原始碼軟體

專案組合管理軟體 Ch 14. 67