中臺科技大學

(1)

中臺科技大學

資訊管理系

畢業專題

儀器設備報修系統之研製－以國軍臺中總醫院為例

指導老師：黃國賢老師鄭中川老師

學生：FM4B 呂郁婷柯奕佑謝鈞彥陳明諒李柏君鄭宇桓

中華民國一○一年十二月

(2)

摘要

台灣 65 歲以上人口超過總人口 10.6%已邁入高齡化社會，且在文明病逐漸增加之趨勢下，民眾依賴醫療機構漸漸提高且健保給付日漸降低，醫療機構面臨可能被淘汰之環境下，如何改善內部效率以提升本身競爭力是組織必須面臨的挑戰，而提高儀器設備之可使用率為人力素質提昇之外最重要的課題。國軍臺中總醫院目前報修流程主要透過紙本與電話進行，產生了報修效率不佳及缺乏統計機能之缺點，導致影響該院整體營運之效能。

本專題研究與國軍臺中總醫院合作開發該院儀器設備報修系統，針對現況分析醫院營運模式與未來發展需求，進行維修流程再造並參照現有報表及相關資料，設計可提供設備更新決策參考之報表。採用雛型法可有效降低系統發展之時程，應用 Web-base 環境，降低使用者之排斥，此外易維護之特性則有利於技術移轉到該院之資訊室，可解決後續系統維護之問題。醫院導入系統改善之成果，未來也可提供其他軍醫院之較佳實務參考。

關鍵字：資訊管理系統、流程再造、線上報修系統

(3)

表目錄

表 1 BPR 定義一覽 ... 5

表 2 醫裝設備報修單資料表(repair)... 36

表 3 物品類報修單資料表(repair2) ... 37

表 4 醫裝設備處置資料表(disposal_t) ... 37

表 5 物品類處置資料表(disposal_t2) ... 38

表 6 醫裝設備報修單暫存資料表(temporary) ... 38

表 7 物品類報修單暫存資料表(temporary2) ... 39

表 8 維修者資料表(repairer_t) ... 39

表 9 報修者資料表(user_t) ... 40

表 10 最新公告資料表 (news) ... 40

表 11 科技接受模式問卷設計 ... 45

表 12 使用套件與環境一覽表 ... 46

表 13 IE 測試結果總表 ... 49

(5)

圖目錄

圖 1 國軍臺中總醫院現有報修流程... 2

圖 2 導入報修系統之新流程 ... 3

圖 3 科技接受模型（Technology Acceptance Model） ... 15

圖 4 科技接受模型 II（TAM2） ... 16

圖 5 科技接受模型 III（TAM3） ... 17

圖 6 研究流程圖 ... 19

圖 7 系統主功能架構圖 ... 21

圖 8 系統輔助功能架構圖 ... 22

圖 9 報修系統環境圖 ... 22

圖 10 第零階 DFD 圖 ... 23

圖 11 新手上路操作流程圖 ... 24

圖 12 註冊操作流程圖 ... 25

圖 13 個人資料修改操作流程圖 ... 26

圖 14 變更密碼操作流程圖 ... 27

圖 15 忘記密碼操作流程圖 ... 28

圖 16 醫裝設備報修操作流程圖 ... 29

圖 17 物品類報修操作流程圖 ... 30

圖 18 進度查詢操作流程圖 ... 31

圖 19 維修處置操作流程圖 ... 32

圖 20 報表統計操作流程圖 ... 33

圖 21 新增維修者操作流程圖 ... 34

圖 22 帳號管理操作流程圖 ... 35

圖 23 IE6 系統測試介面 ... 47

圖 27 儀器設備報修系統首頁 ... 51

圖 28 選擇報修類別介面 ... 52

圖 29 醫裝設備報修單與物品類報修單 ... 52

圖 30 醫裝設備報修單介面 ... 53

圖 31 物品類報修單介面 ... 54

圖 32 維修進度查詢介面 ... 55

圖 33 物品類報修單介面 ... 56

圖 34 維修者登入介面 ... 57

圖 35 維修列表選擇介面 ... 57

圖 36 維修列表選擇介面 ... 58

(6)

圖 37 維修列表－條件篩選與編號查詢 ... 58

圖 38 維修列表選擇處置介面 ... 59

圖 39 系統提醒信件... 60

圖 40 經費申請二連單 ... 60

圖 41 報表統計介面... 61

圖 42 日報表介面 ... 62

圖 43 日報表功能說明 ... 62

圖 44 醫裝維修統計表 ... 63

圖 45 醫裝維修明細表 ... 64

圖 46 醫裝維修排名表 ... 65

圖 47 管理者登入介面 ... 66

圖 48 管理者新增公告介面 ... 67

圖 49 管理者新增刪除公告介面 ... 67

圖 50 管理者新增維修者介面 ... 68

圖 51 管理者帳號管理/停權介面 ... 69

圖 52 停權帳號提示介面 ... 69

圖 53 個人資料修改介面 ... 70

圖 54 變更密碼介面... 71

圖 55 忘記密碼介面... 72

圖 56 處置介面 ... 73

圖 57 物品統計表 ... 74

圖 58 經費申請二聯單 ... 75

圖 59 新增日報表說明欄位 ... 76

圖 60 處置介面 ... 76

圖 61 新增日報表辨識欄位 ... 77

圖 62 報修資料修改（醫裝設備） ... 77

圖 63 醫裝設備報修設計構想 ... 79

圖 64 醫裝設備報修單 ... 80

圖 65 物品類報修單... 81

圖 66 報修類別設計構想 ... 82

(7)

第壹章緒論

台灣 65 歲以上人口已超過總人口 10.6%，屬於高齡化社會，隨著臺灣邁入高齡化社會，社區醫院儼然面對新挑戰，長輩需要友善健康環境，醫院內儀器設備使用率也大大提升，如何在面臨龐大工作量的前提下保養與維持其設備之正常運作將是一大課題。在現今資訊化的時代，資訊技術導入企業中是為一大助益，許多人力作業透過資訊技術導入將可大大降低成本及提升效率。

依 2012/04/19 資策會 FIND 調查顯示，目前有 61.1%的業者表示，公司的配銷作業已導入電子化系統或軟體，而未導入的業者占 38.9%，且企業電子化的比率已是相當的高，若要不受到市場的淘汰必須要將流程更新為電子化以便於管理。

第一節研究背景

由於現在科技的發達，網際網路快速的興起，使全球進入了電子化的時代。

電子化的特點在於處理的速度快、效率高、可大量的儲存及便於搜尋，可提升工作效率，也使管理更趨完善，進而提高行政效率與有條理的管理品質。現在講求效率的時代，「時間」已成為現代人最急於爭取的，也因網路發達而造就了許多行業的興盛與繁榮，因此更有各行各業的媒體、公司、組織…等等，紛紛利用電子化來完成許多繁雜的作業流程，以往的作業流程大部分是採用紙本作業，既繁瑣又浪費時間，已不符合現代社會的需求，且紙本作業也無法徹底做到資訊的統整，保存不易且容易遺失或壞損，因此以上述需求為根據，開發線上報修系統。報修系統是指報修者與維修者之間運用資訊系統，作為報修流程中溝通的橋樑，以得到傳統紙張及耗費人力運送過程中，無法獲得的效益。

臺中市太平區現有人口計 17 萬 143 人，其中 15 歲以下、60 歲以上人口佔全巿人口 31%，該地區共計有 132 家醫療院所。本研究以國軍臺中總醫院為研究對象，針對該院現有醫療儀器設備報修流程進行分析，期間在老師指導下與國軍臺中總醫院相關人員訪談，透過討論尋找問題癥結，該院在目前總計 6 部

(8)

32 科，總病床數 548、醫療儀器設備計核磁共振掃描儀等 1380 項，發現其在現今使用儀器設備非常頻繁且維修暨管理人員僅有一人的情況下，存在著報修缺乏管理機制之問題。經評估後，認為該院適合透過電子化系統將報修流程 E 化，

以提升院內運作效率。

第二節研究動機與目的

國軍臺中總醫院目前之報修流程為使用紙本填寫報修單，並依賴電話溝通，

再將所報修之儀器或物品（以下簡稱報修品）送至裝保室維修，維修完畢再以電話通知報修者取回該報修品，若維修者有耗材之使用亦須在報修單上註明，

並通報至相關單位往返溝通，產生報修效率不佳、錯誤率及缺乏統計機能之缺點，導致影響該院整體營運之效能。該院現有報修流程如下圖所示：

圖 1 國軍臺中總醫院現有報修流程

本研究為了改善上述報修效率不佳之情況，先為該院進行維修流程再造後，

開發出 E 化之儀器設備報修系統，透過此系統報修者將可節省報修流程時間及降低錯誤率，並可透過線上查詢以掌握維修進度。維修者在報修系統中填寫相關說明，當報修品維修完畢時，系統將自動發送電子信件通知報修者。導入本系統後之新報修流程如下頁圖 2 所示：

(9)

圖 2 導入報修系統之新流程

本研究希望善用現行完善的網路環境，透過企業流程再造使得該院儀器物品報修機制效率能夠有效改善，減少紙張使用能兼顧環保，本系統具體預期達成目標如下：

(一) 改善現有醫院儀器設備報修方式所遭遇記錄管理不易之現況。

(二)e 化之報修系統提供報修者自行追蹤維修進度，將減少人員電話連繫次數，可提升人員營運績效降低人力成本。

(三) 建立維修完整資料且流程透明化，做好使用單位之關係管理。

(四) 統計報表，提供設備維護決策支援參考，提高醫院的設備汰舊換新之決策品質。

(五) 本系統提供匯出 Excel 檔之功能，提供管理人員進行應用，使本系統更具彈性可滿足管理上各種臨時需求。

(10)

第貳章文獻探討

組織為使其流程順利執行，除人力之外也會利用各種設備輔助。大部分的企業發現，利用一套標準步驟來發展並支援它們的資訊系統，最能夠帶來效益，

而這一套標準步驟可稱為系統開發方法論，其中系統開發生命週期乃是企業最常用的方法論。為能了解傳統設備管理流程的改善方法，並進一步探討相關領域之研究，本專題將根據企業流程再造、資訊系統開發模式、系統開發生命週期、決策支援系統與科技接受模式等相關文獻作為基礎，回顧其相關研究與理論，以下段落將探討相關觀念。

第一節企業流程再造

學者 Kettinger 、 Teng 與 Guha(1996) 將企業流程再造 (Business Process Reengineering, BPR)定義為：「組織將難以管理之企業流程予以理順(streamlining) 與再重新思考，使公司營運重新獲得控制」。即是在組織內或組織間進行流程與程序分析及設計(Davenport & Short,1990)。因應企業環境不斷變遷，傳統企業所隱藏的不經濟問題，須靠 BRP 以降低營運成本、提昇產業競爭力以利永續經營。

Hammer &Steven A.Stanton(1994)對「流程改造」重新下了定義：「根本的重新思考，徹底翻新作業流程，以求在企業上的表現上，獲得大躍進式的改善。」，

而 Parker(1993)對 BPR 的定義為：「使用各種新舊工具/技巧結合實用的現代科技

，以提供一種全新組合，該組合是可以貫穿組織間的變化，進而達到滿足客戶的需求，為企業建構一更好之流程。」。綜合來說就是藉由企業革新的思想與進步之資訊科技，改善或改進企業運作方式，重新思考工作之重要性，刪除不需要之部分，以其他較好之方式取代，著重流程環環相扣，並以顧客為導向之活動，以期能改善企業績效，達到經營目標。

基本上 BPR 主要由四個構面所構成：

(一) 重新設計並根本的思考企業的營運及工作方式，尋找更佳之製程或生產力之程序，而不是縮減人員，滿足顧客需求而已。

(11)

(二) 結構性重組，以更創新之方式思考企業經營。「流程改造」主要為改善企業之工作流程，而不是組織之功能性活動。

(三) 具整體性且新的資訊系統及評量系統，資訊技術可改變組織目前之工作方式及工作流程。

(四) 新的價值系統。企業再造會改變工作之內容並會影響許多不同之部門，

而員工需認識與瞭解新的組織結構與行為，以能獲得再造之利益。

下表是企業流程再造相關文獻中學者提出的定義。

表 1 BPR 定義一覽

研究者及年代 BPR 的定義

Davenport & Short

(1990) 在組織內/組織間進行流程與程序分析及設計。

Hammer & Champy (1993)

根本的(fundamental)重新思考，徹底的(radical)翻新作業流程，

以期在企業營運績效的衡量(如：成本、品質、服務與速度)上獲得大幅改善。

Davis (1993)

以顧客為中心，由上而下的管理方式，希望跨部門的處理程序對績效能產生重大的改善，其重點在重新思考企業的經營與營運；且以顧客觀點出發。

Klein (1994)

對組織策略且具有附加價值的流程－相關的系統、政策與組織結構－做快速且大幅度的重新設計，以促使組織工作流程和生產力達到最適水準。強調企業流程再造是以流程為導向，涵蓋的範圍遍及整個企業。

Peppard & Rowland (1995)

企業流程再造是一種改進哲理。其目標通過重新設計組織經營的流程，以使這些流程的增值內容最大化，其他方面的內容最小化，從中獲得績效改善的躍進(step improvement)。這種做法既適合單一流程，也適用於整個組織。

資料來源：申燕儒(2002)

(12)

第二節資訊系統開發模式

系統開發模式之發展大概起源於 1950 年代，當時最早之模式稱為編碼與修正模式 (Code-and-fix Model)，後來 Benington(1956)提出階段模式 (Stagewise Model)，接著 Royce(1970)提出瀑布模式(Waterfall Model)，Mills(1971)提出漸增模式(Incremental Model)，Bally 等人(1977)提出雛型模式(Prototyping Model)，

Mills 等人(1989)及 Boehm(1988)提出螺旋模式(Spiral Model)，最後 Aoyama(1993) 提出同步模式(Concurrent Model)。在這些模式中，前兩者幾乎已沒人再使用，

其餘五種是目前常被使用者應用的，以下分別介紹。

(一) 編碼與修正模式

編碼與修正模式是最早(1956 年前)使用之軟體開發模式，該模式並無方法論可言，主要包含兩個步驟：先寫部份程式、再修正程式中之問題。也就是先編碼，再考慮需求、設計、測試與維護。應用該模式於系統開發至少有以下主要之問題：

1. 沒有規劃及設計，固經過幾次之修正後，程式碼的邏輯變得難以理解，以至於後續之維護很困難且成本很高。

2. 過程中並無使用者需求分析與確認，軟體雖然設計得很好，但可能並不符合使用者的需求。最後，該軟體可能完全被拒絕、需大幅度修正或重新開發。

上述情況顯示，明確定義系統開發的階段即每階段應做那些重要工作是必要的，例如系統開發初期應有準備工作以及發展規劃，編碼前須有設計，

設計前要有分析階段等。由於編碼與修正模式有上述之問題，因此階段模式乃因應而生，取代了編碼與修正模式。

(13)

(二) 階段模式

Benington, H.D. 在 1956 年依其過去執行大型軟體系統 ( 例如 Semi-Automated Ground Environment, SAGE)開發之經驗，認知編碼與修正模式之問題，因此提出階段模式以改善其缺點。階段模式有如下八個階段，每階段須依序執行：

1. 作業規劃(Operational Plan)。

2. 作業規格描述(Operational Specification)。

3. 程式規格描述(Coding Specification)。

4. 編碼(Coding)。

5. 參數測試(Parameter Testing)。

6. 整合測試(Assembly Testing)。

7. 上線測試(Shakedown)。

8. 系統評估(System Evaluation)。

從上述八個階段可知，階段模式已具有系統開發階段及各階段規格描述可視為確保符合使用者需求之工作，程式規格描述可視為品質之測試工作，

作業設計工作。另外，參數測試、整合測試與上線測試可視為確保系統品質之測試工作等。综言之，階段模式已具有方法論之雛型，該模式強調系統開發前要有規劃，程式編輯前要有分析與設計，系統上線前要有測試等。

(三) 瀑布模式

瀑布模式最早強調系統開發應有完整之週期，且必須完整的經歷週期之每一開發階段，並系統化的考量分析與設計的技術、時間與資源之投入等，

因此瀑布模式亦稱為系統發展生命週期(System Development Life Cycle, SDLC)。由於瀑布模式強調系統開發過程需有完整的規劃、分析、設計、測試及文件等管理與控制，因此能有效的確保系統品質，它已成為業界大多數軟體開發之標準(Boehm,1988)。

(14)

圖 3 瀑布模式 (四) 漸增模式

漸增模式是瀑布模式之擴充，該方法把需求分成「幾」個部分，依漸增開發計畫將每個「部份需求」之開發訂為一個開發週期，每個週期可依序或平行開發。每個週期之階段清楚定義要做那些工作及交付那些文件，每個階段循序進行且僅循環一次。可依瀑布模式之原則開發。也就是說，漸增模式需先經歷需求分析以完全掌握需求，接著再進行漸增開發規劃，其工作如下：

對系統之分析與設計「由上而下」之方式，將需求分成若干部分，並進行上層規格描述，此時需把由上而下之各部分或功能切割清楚，這包括整個系統之上層架構，可能重複使用之部分與依序將發展之各子系統。

圖 4 漸增模式

(15)

(五) 雛形模式

雛型模式是一種系統開發方法，該方法先針對使用者需求較清楚的部分或資訊人員較能掌握之部分，依分析、設計與實施等步驟快速開發雛型。開發過程中，強調盡早以雛型作為使用者與資訊人員需求溝通與學習之工具，

雙方透過雛型之操作與回饋，以釐清、修改及擴充需求，並藉以修改與擴充雛型。上述步驟反覆進行，直到系統符合雙方約定為止。

圖 5 雛形模式

(16)

(六) 螺旋模式

由於漸增模式與雛型模式均無法完全解決瀑布模式執行上之問題，

Mills 等人(1986)提出螺旋模式以期能改善之，該模式由 Boehm(1988)進一步擴充。該模式之執行由三個步驟形成一週期：1. 找出系統的目標、可行之實施方案與限制；2. 依目標與限制評估方案；3. 由剩下之相關風險決定下一步驟該如何進行。此週期反覆進行直到系統開發完成為止，其中各週期之進行均強調規劃及風險評估。

圖 6 螺旋模式

(17)

(七) 同步模式

同步模式(Concurrent Model)是由 Aoyama‚M.於 1993 年提出，該模式之構想是源自於製造業的同步工程(Concurrent Engineering)同步工程的目的在於縮短產品開發時間，以提高市場競爭力。同步模式是基於三個主要的構想來達到時程縮短的目標，第一個構想是多個團隊同時開發、第二個構想是資訊同步、第三個構想是整合性的管理系統。

圖 7 同步模式

(18)

第三節系統開發生命週期

系統開發生命週期（Systems development life cycle, SDLC）乃是許多企業在系統開發上最常用的方法論，是用來開發、維護、更換資訊系統的傳統方法論。

其特徵在於分為好幾個階段，每個階段標示不同的系統分析和發展的過程。

(一) 系統規劃階段

在這個階段必須要確認新系統或升級現有系統的需求。在大型企業中，

這個確認可能是公司或系統規劃程序中的一部分。整個系統的需求將受到檢視，而符合整體需求的報告也將因而確立。企業的資訊系統需求來自於目前執行程序中有亟待解決的問題、企圖進行新業務或體認到可用資訊科技來掌握現有契機。這些需求將被排定優先順序並轉換成可供資訊系統部門實行之計畫。在小型企業中，開發何種系統之決定可能會受到特定使用者需求之影響或可能經由一個正式規劃流程而產生。不管是哪一種情況，在專案確認與選擇的階段，一個企業應審慎評估並決定將投入哪些資源。專案確認與選擇階段之成果，乃是決定採取何種系統開發專案。

(二) 系統分析階段

在這個階段人員要徹底了解組織現有的流程與執行任務所用的系統，分析階段包括兩個子階段。第一個子階段是確認需求。在這個子階段分析師必須與使用者一起合作，決定使用者希望從系統中得到什麼。確認需求階段通常牽涉到對任一將被替換或升級的現行系統做深入了解。第二個子階段，分析師要仔細了解需求，並依照各需求間的關係，建構它們，並刪除任何多餘的需求。分析階段的輸出就是描述分析團隊所建議的各種替代方案之初步內容。一旦建議被採納，便可以開始仔細計畫所需系統之硬體與軟體。

(19)

(三) 系統設計階段

在設計階段中，分析人員要將建議的替代方案轉換成邏輯與實體的系統規格。分析人員必須設計系統的所有部分，從輸出輸入畫面至報表、資料庫，

以及電腦流程。系統分析師必須提供所有相關系統設計之實體細節。設計流程中，與軟體/硬體無關的部分可稱為邏輯設計。理論上，設計出來的系統應該可以在任何硬體與軟體上實作。設計之主旨在於確定所有系統功能均能符合預期。邏輯設計者著重於從企業角度並注重策略面和管理面的流程和機制。邏輯設計完成之後，則可將邏輯設計規格轉成實體規格，這個流程稱為實體設計。實體設計著重於設計出系統各部分的實體運作方式，包括資料擷取、處理與資訊輸出。這個工作可由許多不同的方式來組成，如從產生一個欲實行系統之工作模型到撰寫有關此系統的各個組成部分，以及此一系統應如何建置等細節均屬實體設計。在實體設計階段，分析小組將決定如何建置系統的細節；包括使用何種程式語言來撰寫此系統，有關儲存資料之資料庫選擇，及執行此系統之硬體平台等。一般而言，程式語言、資料庫及平台，

早已由企業或客戶所決定。此時，這些資訊技術應仔細地在實體設計中進行評估、考量。本階段的最終成果乃是一實體系統規格表單以供程式設計師或其他系統建置人員來建置系統。

(四) 系統實作

不論實體系統規格是細部模型表單或規格書，都要在實作階段的一開始交程式設計人員，在實作階段，分析師將系統規格轉換成以測試過的實際運作系統以供操作。實作包含撰寫程式、測試與安裝。在撰寫程式階段，程式設計師將編寫系統所需的程式。有時，程式也可由建構系統細部模型的系統產生。在測試階段，程式設計師及分析師將會就單一程式或全部系統進行測試來找尋並修正錯誤。在安裝階段，此一新建系統將成為企業中日常流程之一部分，同時，使用者應認識此一系統並接受訓練。測試與安裝應早在專案開始及規劃階段時即已計畫。此外，測試與安裝均需經過充分之分析，以確保其可以正確的方法來進行。實作階段之活動也包括下列各項對使用者之支

(20)

援工作，這些支援使用者之工作如文件之完成，訓練之計畫及持續的使用者協助等，其中文件之產生乃是發生在生命週期之任一階段，而訓練(或教育) 也是發生在專案開始之階段；但文件與計畫兩者均是在實作階段完成，實作階段也可隨系統之存在而持續延伸，此乃因持續性的使用者協助之一部分。

系統在經過測試階段過後，人員依原本流程與系統的差別設計問卷表單，請使用者填寫使用系統後，對系統的回饋。

(五) 系統維護

當系統已經開始運作時(包括訓練、文件記錄、支援)，使用者有可能會發現運作上的問題，或想要一個更好的方法來改善功能，或是組織對於系統的需求，也可能會隨著時間而改變，此時程式設計人員必須依據使用者的要求進行修改，以配合企業情況之改變。這些改變對於維持系統之操作及有效性乃是必要的。一般而言，維護並非單一的生命週期階段，而可能是一個重複生命週期各階段的過程，用以研究並實作所有必要的系統變異。所以維護工作所需投入的時間與勞力，大部分取決於生命週期前一個階段的成效。

第四節決策支援系統

1971 年麻省理工學院 Michael Scott Morton 在「管理決策系統(Management Decision System)」(1971)一書中提出「決策支援系統(Decision Support System, DSS)」一詞。基本上他認為傳統的「管理資訊系統」(management information system ,MIS)忽略了管理工作上的支援，無法提高管理績效，電腦之應用有需要提升到新的層次以支援管理決策。

決策支援系統是使用資訊科技來協助資訊的蒐集與分析，並且能快速的掌握資訊、有效的過濾不相關之訊息的一套決策作業模式。為一種協助人類做決策的資訊系統，協助規劃與解決各種行動方案，通常以交談式的方法解決半結構性(Semi-structured)或非結構性(Non-structured)的問題，強調的是支援而非替代人類進行決策。正如學者 Keen 與 Scott-Morton 所提出：「DSS 乃使用電腦協助解決半結構化的問題、支援但不取代人類、目的為改善決策而不是決策效率」。

(21)

第五節科技接受模式

科技接受模型（Technology Acceptance Model, TAM）是 Davis 在 1989 年根據 Fishbein 與 Ajzen 在 1975 年推出的理性行為理論（Theory of Reasoned Action, TRA）為重要基礎，所發展而來的科技接受模型（TAM），主要是在解譯使用者和資訊科技技術間的影響因子。Davis 認為外部變項會直接影響到知覺有用性及知覺易用性，而行為意向是由知覺有用性及知覺易用性兩個主要因素來決定的。

科技接受模型（TAM）是用來分析影響導入新的資訊系統後所接受程度的重要指標（Davis, 1989）。如下圖科技接受模型（Technology Acceptance Model）。

圖 8 科技接受模型（Technology Acceptance Model）

資料來源：Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 319, 13-3.

(一) 知覺有用性：使用者在主觀的情形下，對於使用科技技術系統後，覺得會提高工作效益或對未來工作有幫助（Davis, 1989）。

(二) 知覺易用性：使用者認為在工作上容易使用此科技技術系統，使得容易完成工作（Davis, 1989）。

(三) 行為意向：使用者在使用科技技術系統後，對未來使用此系統的意願程度。使用意願的程度會隨著知覺有用性及知覺易用性的改變強度而產生變化程度（Davis, 1989）。

(22)

Venkatesh 和 Davis 在 2000 年將科技接受模型（TAM）拓展了新的架構為科技接受模型 II （TAM2），主要分為社會影響力和實質認知，對於使用者知覺是非常有顯著影響的。社會影響力又包括自願（ Voluntariness）、主觀規範

（Subjective norm）、形象（Image）等三個構面；實質認知則包括了工作相關（Job Relevance）、輸出品質（Output Quality）、結果可見度（Result Demonstrability）

和知覺易用性（Perceived Ease of Use）等四個構面所組成（Venkatesh, & Davis, 2000）。如下圖科技接受模型 II （TAM2）。

圖 9 科技接受模型 II（TAM2）

資料來源：Venkatesh, V. & Davis, F. D. (2000), A theoretical extension of the technology acceptance model: four longitudinal field studies. Management Science, 46, 186-204.

之後 Venkatesh 和 Bala 在 2008 年結合了 Venkatesh 和 Davis 在 2000 年的科技接受模型 II（TAM2），延伸出另一個新的科技接受模型 III（TAM3），呈現一個完整的資訊科技和使用者的決定因素。主要加入以下幾個影響因素，分為固定和調整。固定為電腦自我效能（Computer Self-Efficacy）、外部控制知覺

（Perception of External Control）、電腦焦慮（Computer Anxiety）和電腦有趣性

（Computer Playfulness）；調整為認知愉悅性（Perceived Enjoyment）和客觀可用性（Objective Usability）。（Venkatesh, & Bala, 2008）如下圖科技接受模型 III

（TAM3）。

(23)

圖 10 科技接受模型 III（TAM3）

資料來源：Venkatesh, V., & Bala, H. (2008). Technology acceptance model 3 and a research agenda on interventions. Decision Sciences, 39, 273-315.

(24)

第參章研究方法

本專題首先以相關文獻的回顧為基礎，探討與流程改造的實施有關的各種構面，參考系統生命開發週期整合出本專題的研究架構。釐清了研究的架構後，

再據以推論出企業在不同改造目標下，可遵行的改造策略及其配套措施。本研究選用資訊系統開發模式中的「雛型法」作為理論基礎，設計出本系統之研究流程，並進一步進行系統架構與功能設計。以國軍臺中總醫院設備維修流程為個案，為改善該院現有之報修流程，開發 e 化報修系統取代紙張人力報修作業。

將院方提供之醫裝設備暨物品管理資料庫與 ASP.NET 程式結合，並設計報修系統後端資料庫，設計出符合該院需求之「國軍臺中總醫院儀器設備報修系統」。

第一節研究流程

對於大型系統風險性高、不確定性高、或需求及功能性仍不清楚時，使用雛型法為一最可行方式。若先以雛型法將所需介面、功能等作界定，並依此向企業高階管理者做說明與展示，可讓使用者清楚了解所需功能與介面，以免往後需求一再變更，造成開發時程延後，或是需要重新更改系統；也讓不熟悉電腦的高階管理者了解專案內容與未來可行方向，以利於其決策與執行信心。故在資訊系統開發模式眾多模式中，本研究選擇以雛型法作為研究基礎。

雛型法可增進使用者參與，透過看得到、可操作的雛形成為系統開發者與使用者溝通的基礎，如此一來，需求分析的時間及成本將可以降低，且系統的正確性將提高。經需求分析、設計、編碼、測試等階段，建構一個可運作但不完美的雛型系統，這個快速發展的系統經使用者的操作與試驗，得以發掘更完整的需求，系統也漸趨完成而成熟。本專題之研究流程圖如下：

(25)

圖 11 研究流程圖 (一) 需求分析

此階段須確認新系統之需求，透過與院方人員進行訪談以確認使用者需求，並收集系統將會用到的相關資料，如財產資料庫、院內現有報表等，將這些資料篩選、過濾後進行分析，並且把整理出來的資料彙整。同時可透過繪製資料流程圖來建構系統流程需求，並進一步轉換為邏輯需求。

(二) 設計

根據需求分析階段中所整理的使用者的需求來設計系統雛形，包含設計資料庫、設計表單與報表、設計介面與對話。以系統雛型為基礎來建構出系統初步架構，設計系統功能與版面，在版面設計中，除了畫面比例之設定外，

亦須挑選適當的色彩以設計出符合使用者需求之系統畫面。在此階段中，亦須進行資料庫設計，首先根據院方提供之財產資料庫分析其綱要與規則，並進一步設計本系統之後端資料庫。

在循環數次後，可針對使用者填寫使用系統後對系統的回饋意見，開始進行問卷設計。

(26)

(三) 編碼

在編碼階段中，是一個將設計規格轉換成程式碼的過程，此時系統功能架構雛型已完成，將根據上述階段之系統雛形進行程式撰寫，將設計構想轉換為實體功能，建構出一個可運作的系統程式。

(四) 測試

完成編碼後，可針對程式部分進行測試，在階段中編碼與測試可同時或交互進行，檢查設計出的系統功能是否有所缺失或漏洞。此階段中，本專題以 Windows Server 2008 SP2 作為網站架設之伺服器，在實驗室環境中進行測試，試著尋找錯誤及可改善空間。

(五) 操作與維護

系統在經過測試階段過後，將可請使用者進行操作，同時記錄使用者意見，依此進行系統維護，在過程中要詳細記錄遇到的問題，尋求解決的辦法，

將上述記錄整理為文件檔案。

在上述階段中，將持續搜集並整理使用者操作後的意見和需求的更改，並依此修改雛形，此循環將重複數次直到滿意或可接受的程度為止。

(27)

第二節系統功能架構

在系統功能架構此一節中，將針對本研究系統功能之設計、系統使用者之定位進行說明，其中，環境圖（context diagram）可呈現出本系統範圍，並指出了系統範圍內部與外部的元素，因此在接下來的段落中將以環境圖說明系統使用者之定位。此外，並繪製呈現新系統資料的流程、結構與功能需求的新的邏輯資料的流程圖（DFD）以進行描述，第零階流程圖將可詳細表示系統主要流程、資料流，以及資料儲存之情況。

(一) 系統功能說明

本系統以儀器設備報修為核心，分為醫裝設備與物品兩個子類別。系統功能可分為主功能架構與使用者管理之輔助功能架構，主功能提供填寫報修單、進度查詢、管理公告、報表統計、新增維修者、維修列表（處置）與設定帳號權限等，並進一步根據使用者需求，可提供檔案下載、報表列印、匯出檔案等次功能，如圖 12 所示。此外，使用者管理之輔助功能為最新消息、

新手上路、註冊、技術支援、密碼查詢、個人帳號設定等，針對初次進入系統之使用者，並提供新手上路教學文件及影音檔案，依據系統使用者角色的不同提供不同的功能，如下頁圖 13 所示。本系統之功能架構如下：

圖 12 系統主功能架構圖

(28)

圖 13 系統輔助功能架構圖 (二) 系統使用者

本系統將使用者定位區分為三者，分別為管理者、維修者及一般報修者。

其中，管理者擁有最高管理權限，當院內加入新進維修者時，由管理者新增維修者帳號（維修者不可自行申請），並可設定維修者與一般報修者之帳號權限、可新增系統最新公告，以及一般維修者擁有之使用權限。維修者可進行院內所有報修處置，並使用統計報表功能，但並無管理者設定帳號之權限。

一般報修者可在系統首頁逕行註冊申請，註冊通過後即可登入填寫報修單，

進行報修，本系統之使用者環境圖如下圖所示：

圖 14 報修系統環境圖 (三) DFD 圖

根據本報修系統之主要功能：瀏覽/新增最新消息、瀏覽/下載新手上路、

填寫報修單、查詢維修進度、瀏覽/下載技術支援、填寫註冊、查詢密碼、

設定個人帳號、瀏覽/查詢統計報表、瀏覽/查詢維修列表、新增維修者與設定帳號權限等功能，以及系統使用者管理者、維修者、報修者等三種角色，

繪製出系統之第零階 DFD 圖，如下頁圖 15 所示：

(29)

圖 15 第零階 DFD 圖

(30)

第三節操作流程

根據前一小節所繪製之資料流程，本節將以系統使用者角度延續說明，分別針對新手上路、註冊、個人資料修改、變更密碼、忘記密碼、醫裝設備報修、

物品類報修、進度查詢、維修處置、報表統計、新增維修者、帳號管理等系統功能操作進行說明，並繪製個別繪製出該功能之操作流程圖。

(一) 新手上路

報修者第一次使用系統時可以先點選“新手上路”功能，選擇要所需瀏覽的文件或影音檔，進行了解系統操作步驟，操作流程如圖 16 所示。

圖 16 新手上路操作流程圖

(31)

(二) 註冊

當第一次要進行報修時，必須先“註冊”，在系統首頁點選註冊，就可進入填寫註冊畫面，資料填寫完成後可點選確認送出或是清除重填註冊單，

確認送出之後，會跳到資料再次確認的畫面，可選擇修改內容或是完成（立即登入），詳細操作流程如圖 17 所示。

圖 17 註冊操作流程圖

(32)

(三) 個人資料修改

當使用者手機、分機或是一些個人資料有變動時，必須在登入系統後，

點選“個人資料修改”，進行資料更改，修改後點選儲存就完成了，詳細操作流程如圖 18 所示。

圖 18 個人資料修改操作流程圖

(33)

(四) 變更密碼

當使用者想要更改密碼時，必須先登入系統後，點選“變更密碼”，進行密碼更改，更改後點選儲存就完成了，而系統會要求使用者重新登入，詳細操作流程如圖 19 所示。

圖 19 變更密碼操作流程圖

(34)

(五) 忘記密碼

如果使用者忘記密碼，可以點選系統首頁的“忘記密碼”，填寫帳號之後就可點選寄送密碼，系統將會把使用者的密碼寄送到院內信箱，詳細操作流程如圖 20 所示。

圖 20 忘記密碼操作流程圖

(35)

(六) 醫裝設備報修

在使用者要進行醫裝報修時，必須先登入系統，然後點選“填寫報修單”，選擇“醫裝設備”，進行填寫報修單，新增完成後，點選送出就完成了，詳細操作流程如圖 21 所示。

圖 21 醫裝設備報修操作流程圖

(36)

(七) 物品類報修

在使用者要進行物品報修時，必須先登入系統，然後點選“填寫報修單”，選擇“物品類”，進行填寫報修單，新增完成後，點選送出就完成了，

詳細操作流程如圖 22 所示。

圖 22 物品類報修操作流程圖

(37)

(八) 進度查詢

使用者報修完成之後，就可透過系統的“進度查詢”，查看設備目前的處置狀態，點選申請編號並可進入處置詳情的畫面，詳細操作流程如圖 23 所示。

圖 23 進度查詢操作流程圖

(38)

(九) 維修處置

維修者登入系統後，可點選“維修列表”，就可看到醫裝設備與物品類，

尚未維修與維修中各是幾筆，選擇維修類別後，並可進行維修處置，詳細操作流程如圖 24 所示。

圖 24 維修處置操作流程圖

(39)

(十) 報表統計

維修者登入系統後，可點選“報表統計”，依需求選擇產生的報表種類，

先點選統計的區間與相關條件，再點選產生報表就完成了，詳細操作流程如圖 25 所示。

圖 25 報表統計操作流程圖

(40)

(十一) 新增維修者

當有新的維修者進入，管理者登入系統，可以點選“新增維修者”，進行新增維修者帳號，資料填寫完成後可點選確認送出或是清除重填註冊單，

確認送出之後即可登入，詳細操作流程如圖 26 所示。

圖 26 新增維修者操作流程圖

(41)

(十二) 帳號管理

當院內有醫護人員變動時，管理者登入系統，可以點選“帳號管理”，

先選擇用戶身分，再進行權限更改，詳細操作流程如圖 27 所示。

圖 27 帳號管理操作流程圖

(42)

第四節資料字典

本專題將院方原始資料庫檔案與 SQL Server 結合，當報修者填寫報修單之後，系統將會把這些資料存入系統資料庫內各自的資料表中，系統資料庫內分別有醫裝設備報修單資料表（repair）、物品類報修單資料表（repair2）、醫裝設備處置資料表（disposal_t）、物品類處置資料表（disposal_t2）、醫裝設備報修單暫存資料表(temporary)、物品類報修單暫存資料表(temporary2)、維修者資料表

（repairer_t）、維修者資料表（user_t）、最新公告資料表 (news)等，另連結院方醫裝暨物品之財產資料庫，以下分別敘述各資料表字典：

(一) 醫裝設備報修單

此資料表儲存所有醫裝設備報修資料，欄位分別為申請編號、新院內編號、舊院內編號、報修者帳號、送修單位、聯絡電話、設備所在位置、故障說明、報修日期、優先序、工作說明、節省金額、維修經費、申請經費等，

並以申請編號作為資料表主鍵，資料字典如下表。

表 2 醫裝設備報修單資料表(repair)

資料元素名稱欄位名稱資料型別長度 Null PK / FK

申請編號 apply_no varchar 20 PK

新院內編號 n_no varchar 20 

舊院內編號 o_no varchar 20 

報修者帳號

(院內信箱) user_e varchar 30

送修單位 department varchar 30

聯絡電話 tel varchar 20

設備所在位置 place varchar 50 

故障說明 text ntext

報修日期 adate datetime

優先序 priority varchar 10

工作說明 wtext ntext 

節省金額 save_e int 

維修經費 expense int 

申請經費 fund char 1

(43)

(二) 物品類報修單

此資料表儲存所有物品類報修資料，欄位分別為申請編號、新院內編號、

報修者帳號、送修單位、聯絡電話、物品所在位置、故障說明、報修日期、

優先序、工作說明、節省金額、維修經費、申請經費等，並以申請編號作為資料表主鍵，資料字典如下表。

表 3 物品類報修單資料表(repair2)

申請編號 apply_no varchar 20 PK

報修者帳號

物品所在位置 place varchar 50 

報修日期 adate datetime

優先序 priority varchar 10

工作說明 wtext ntext 

節省金額 save_e int 

維修經費 expense int 

申請經費 fund char 1

(三) 醫裝設備處置

此資料表儲存所有醫裝設備處置資料，欄位分別為處置編號、申請編號、

維修者帳號、狀態、處置、維修日期、完成日期，並以處置編號作為資料表主鍵，資料字典如下表。

表 4 醫裝設備處置資料表(disposal_t)

處置編號 disposal_no int PK

申請編號 apply_no varchar 20 

維修者帳號 repairer_e varchar 30

狀態 status varchar 20 

處置 disposal varchar 20 

維修日期 fix_date varchar 30 

完成日期 finish_date varchar 30 

(44)

(四) 物品類處置

此資料表儲存所有物品類處置資料，欄位分別為處置編號、申請編號、

維修者帳號、狀態、處置、維修日期、完成日期，並以處置編號作為資料表主鍵，資料字典如下表。

表 5 物品類處置資料表(disposal_t2)

處置編號 disposal_no int PK

申請編號 apply_no varchar 20 

維修者帳號 repairer_e varchar 30

狀態 status varchar 20 

處置 disposal varchar 20 

維修日期 fix_date varchar 30 

完成日期 finish_date varchar 30 

(五) 醫裝設備報修單暫存

此資料表儲存所有醫裝設備報修暫存資料，欄位分別為申請編號、新院內編號、舊院內編號、報修者帳號、品名、廠牌、送修單位、型式、聯絡電話、設備所在位置、故障說明、IP 等，並以申請編號作為資料表主鍵，資料字典如下表。

表 6 醫裝設備報修單暫存資料表(temporary)

申請編號(隱藏) apply_no varchar 20 PK

舊院內編號 o_no varchar 20 

報修者帳號

品名 equipment varchar 40 

廠牌 brand varchar 20 

型式 type varchar 10 

設備所在位置 place varchar 50 

IP ip_no varchar 25

(45)

(六) 物品類報修單暫存

此資料表儲存所有物品類報修暫存資料，欄位分別為申請編號、新院內編號、報修者帳號、品名、送修單位、聯絡電話、物品所在位置、故障說明、

IP 等，並以申請編號作為資料表主鍵，資料字典如下表。

表 7 物品類報修單暫存資料表(temporary2)

申請編號(隱藏) apply_no varchar 20 PK

報修者帳號

品名 equipment varchar 40 

物品所在位置 place varchar 50 

IP ip_no varchar 25

(七) 維修者

此資料表儲存所有維修者資料，欄位分別為維修者帳號、密碼、姓名、

聯絡電話、分機、權限等，並以維修者帳號作為資料表主鍵，資料字典如下表。

表 8 維修者資料表(repairer_t)

維修者帳號 repairer_e varchar 30 PK

密碼 psw varchar 20

姓名 name varchar 20

分機 ext varchar 10

權限 authority char 1

(46)

(八) 報修者

此資料表儲存所有報修者資料，欄位分別為報修者帳號、密碼、姓名、

聯絡電話、分機、權限等，並以報修者帳號作為資料表主鍵，資料字典如下表。

表 9 報修者資料表(user_t)

報修者帳號

(院內信箱) user_e varchar 30 PK

密碼 psw varchar 20

姓名 name varchar 20

手機 tel varchar 20

分機 ext varchar 10

權限 authority char 1

(九) 最新公告

此資料表儲存所有最新公告內容，欄位分別為編號（自動編號）、標題、

日期、內容等，並以編號作為資料表主鍵，資料字典如下表。

表 10 最新公告資料表 (news)

編號 no int PK

標題 title varchar 50

日期 date varchar 20

內容 text varchar 20

(47)

(十) 醫裝財產明細表

此資料表為院方財產資料庫（Access 檔），儲存所有醫裝財產明細內容，

欄位分別為識別碼、主索引號、院內編號、類、項、目、節、號、分類編號、

編裝料號、編裝品名、軍品料號、財產名稱、單位、品質、購入日期、購入數量、購入總值、使用年限 1、除帳、帳藉現況、除帳日期、上年度結存、

今年新增、今年減少、現存總數、購入案號、廠牌、型號、廠商代碼、廠商名稱、財產來源、保固期開始、保固期屆滿、廠牌代碼、使用年限、入帳日期、來源、輻射、昂貴、工安、核定文號、備註、傳票日期、傳票號碼、傳票種類、登帳憑證、登帳憑證字、登帳憑證號等，並以識別碼作為資料表主鍵，資料字典如下表。

表 11 Aeqprice 資料表

識別碼識別碼自動編號長整數 PK

主索引號主索引號文字 255 

院內編號院內編號文字 255 

類類文字 255 

項項文字 255 

目目文字 255 

節節文字 255 

號號文字 255 

分類編號分類編號文字 255 

編裝料號編裝料號文字 255 

編裝品名編裝品名文字 255 

軍品料號軍品料號文字 255 

財產名稱財產名稱文字 255 

單位單位文字 255 

品質品質文字 255 

購入日期購入日期日期/時間 

購入數量購入數量數字雙精準數 

購入總值購入總值數字雙精準數 

使用年限 1 使用年限 1 數字雙精準數 

除帳除帳是/否 

帳籍現況帳籍現況數字雙精準數 

(48)

除帳日期除帳日期文字 255 

上年度結存上年度結存文字 255 

今年新增今年新增文字 255 

今年減少今年減少文字 255 

現存總數現存總數文字 255 

購入案號購入案號文字 255 

廠牌廠牌文字 255 

型號型號文字 255 

廠商代碼廠商代碼文字 255 

廠商名稱廠商名稱文字 255 

財產來源財產來源數字 

保固期開始保固期開始文字 255 

保固期屆滿保固期屆滿文字 255 

廠牌代碼廠牌代碼文字 255 

使用年限使用年限數字雙精準數 

入帳日期入帳日期日期/時間 

來源來源文字 255 

輻射輻射數字雙精準數 

昂貴昂貴數字雙精準數 

工安工安數字雙精準數 

核定文號核定文號文字 255 

備註備註文字 255 

傳票日期傳票日期文字 255 

傳票號碼傳票號碼文字 255 

傳票種類傳票種類文字 255 

登帳憑證登帳憑證文字 255 

登帳憑證字登帳憑證字文字 255 

登帳憑證號登帳憑證號文字 255 

(49)

(十一) 部門資料

此資料表為院方財產資料庫（Access 檔），儲存所有部門資料內容，欄位分別為識別碼、code、deptment、codeno、dutycena、loca、編裝單位等，

並以識別碼作為資料表主鍵，資料字典如下表。

表 12 部門資料表

code code 文字 255 

deptment deptment 文字 255 

codeno codeno 文字 255 

dutycena dutycena 文字 50 

loca loca 數字長整數 

編裝單位編裝單位文字 50 

(十二) USERA

此資料表為院方財產資料庫（Access 檔），儲存所有設備相關內容，欄位分別為識別碼、排序、chindex、seindex、主次索引、prop_no、院內索引、

動產識別號、codename、dutyceno、dutycena、sdate、srnumber、buyvalue、

price、mreprice、accvalue、location、dedate、decaude、accent、proorig、tocode、

renum、deno、code、使用人、保管單位、保管人、折舊單位、原需求單位、

新院內編號、財產分號、減損摘要、減損憑證、減損憑證字、減損憑證號、

減損傳票日、減損傳票字、減損傳票號、備註等，並以識別碼作為資料表主鍵，資料字典如下表。

表 13 USERA 資料表

排序排序數字雙精準數 

chindex chindex 文字 255 

seindex seindex 文字 255 

主次索引主次索引文字 255 

prop_no prop_no 文字 255 

院內索引院內索引文字 255 

(50)

動產識別號動產識別號文字 255 

codename codename 文字 255 

dutyceno dutyceno 文字 255 

dutycena dutycena 文字 255 

sdate sdate 日期/時間 

srnumber srnumber 文字 255 

buyvalue buyvalue 數字雙精準數 

price price 數字雙精準數 

mreprice mreprice 數字雙精準數 

accvalue accvalue 數字雙精準數 

location location 文字 255 

dedate dedate 日期/時間 

decaude decaude 文字 255 

accent accent 數字雙精準數 

proorig proorig 數字雙精準數 

tocode tocode 文字 255 

renum renum 文字 255 

deno deno 文字 255 

code code 文字 255 

使用人使用人文字 255 

保管單位保管單位文字 255 

保管人保管人文字 255 

折舊單位折舊單位文字 255 

原需求單位原需求單位文字 255 

新院內編號新院內編號文字 255 

財產分號財產分號文字 255 

減損摘要減損摘要文字 255 

減損憑證減損憑證文字 255 

減損憑證字減損憑證字文字 255 

減損憑證號減損憑證號文字 255 

減損傳票日減損傳票日日期/時間 

減損傳票字減損傳票字文字 255 

減損傳票號減損傳票號文字 255 

備註備註文字 255 

中 臺 科 技 大 學