學習重點 掌握常見資訊系統的用途,依「交易處理、管理報表、高階資訊、專業推論」辨識 TPS、MIS、EIS 與 ES。 能辨識「讓電腦對結構性或半結構性決策提出參考建議」屬於專家系統(ES)的功能。 區分 POS、EOS 與 EDI:分別著重銷售現場資料、電子訂貨及企業間標準化資料交換。 熟記管理資訊系統的英文名稱與縮寫(MIS),以及 ATM 所代表的金融設備(自動櫃員機)。 理解系統開發生命週期(SDLC),尤其能分辨「分析需求」、「設計方案」與「實際建置」的工作。 核心觀念 一、管理資訊系統與各類決策支援工具 企業使用資訊系統,目的包括處理日常交易、彙整營運資訊及輔助管理決策。作答時應先找出工作重點,不能只因題目出現「決策」就一律選管理資訊系統。 系統主要功能與辨識關鍵 交易處理系統(TPS)記錄及處理日常、重複性交易,例如訂單、收款、薪資與存提款紀錄。重點是交易資料的正確、迅速與完整,本身不負責提出決策建議。 管理資訊系統(MIS)彙整營運資料,提供例行報表、統計摘要或異常資訊,協助管理者規劃與控制,例如每月銷售報表。 高階主管資訊系統(EIS)提供高階主管所需的關鍵指標、趨勢及內外部摘要資訊,協助掌握整體經營與策略方向。 決策支援系統(DSS)結合資料、模型及互動分析,協助評估方案,常用於半結構性或非結構性問題,例如模擬不同價格對利潤的影響。 專家系統(ES)將特定領域的專家知識與經驗建立為知識庫,再透過推論機制提出判斷或建議,例如故障診斷、問題諮詢。 管理資訊系統的英文為 Management Information System,簡稱 MIS。縮寫須完整記住;MIB、MAB 都不是此名稱的正確縮寫。AIS 通常指會計資訊系統,不能與 MIS 混用。 二、專家系統的功能與定位 專家系統(Expert System,ES)的特色,是讓電腦運用已整理的專業知識進行推論。其基本觀念包括知識庫儲存知識、推論機依據知識與已知事實推導結果,並可透過使用者介面接受問題、呈現建議。 結構性決策具有明確規則與處理程序;半結構性決策則只有部分程序明確,其餘仍需判斷。專家系統可將專家知識轉化為規則,因此能讓電腦針對結構性或半結構性決策提出參考建議。題目若描述「企業為使電腦能夠提出結構性或半結構性決策的參考建議」,應選專家系統(ES),而非 EIS、MIS 或 TPS。 辨識重點在於「由電腦主動提出建議」:TPS 只處理交易、MIS 只提供報表、EIS 只呈現摘要指標,三者都是提供資訊給人判斷;ES 則是模擬專家推論後給出建議。若敘述著重資料模型、方案比較或情境模擬,則偏向 DSS。專家系統是輔助工具,其建議仍受知識庫內容與輸入資料影響,不代表能取代所有人的決策。 三、商業資訊系統:銷售、訂貨與資料交換 名稱用途判斷關鍵 POS:銷售時點系統在銷售現場記錄商品交易,蒐集商品種類、數量、價格與銷售時間等資料,供庫存管理與營運分析使用。收銀、結帳、商品賣出、銷售情報。 EOS:電子訂貨系統透過電子方式傳送訂貨資料,協助門市向供應商或配送中心訂購、補充商品。訂購、補貨、訂貨資料傳送。 EDI:電子資料交換不同組織的電腦系統,依約定的標準格式交換訂單、發票等商業文件資料。企業之間、標準格式、系統間交換。 POS 不只是收銀設備,也能累積商品銷售情報。企業收集商品販賣種類、數量、時間及消費者需求等情報,作為營運決策參考,即為 POS 的功能,可藉此了解熱銷商品、需求變化及不同時段的購買情形,作為進貨、促銷與營運決策的依據。 三者可以配合運作:POS 記錄銷售,企業依銷售與庫存狀況透過 EOS 訂貨,而相關商業文件可使用 EDI 交換。因此,應按題意辨識主要功能,不能將三者視為同義詞。CIS 的完整名稱可能隨應用領域而異,不宜單憑字母猜測用途。 四、電子金融服務與 ATM ATM 是 Automated Teller Machine 的縮寫,中文為自動櫃員機。常見服務包括提款、轉帳與餘額查詢,實際功能依金融機構及設備而定。 電子資金轉帳通常以 EFT(Electronic Funds Transfer)表示,重點是以電子方式移轉資金。ATM 是提供服務的設備,轉帳是可能提供的功能,不能因此將 ATM 解釋為「電子資金轉帳」。電子現金屬電子支付相關概念;信託服務屬金融業務,兩者也都不是 ATM 的英文全名。 五、系統開發生命週期:從需求到維護 系統開發生命週期簡稱 SDLC。不同教材可能合併或細分階段,作答時應依實際工作內容判斷。 階段主要任務 系統規劃確認問題與目標,界定範圍,評估可行性、資源、成本及時程。 系統分析訪談使用者、了解現行作業、蒐集與分析需求,將使用者需求轉換為系統需求規格文件,供開發人員作為開發依據。 系統設計依需求規格規劃實作方案,設計系統架構、資料庫、介面、輸入輸出及處理流程。 系統建置依設計進行程式撰寫、設備與軟體配置及系統整合,使方案成為可運作的系統。 系統測試檢查功能、整合及整體運作是否符合需求,找出錯誤並修正;驗收測試用來確認是否符合使用者需求。 系統導入進行資料轉換、使用者訓練及新舊系統切換,讓系統正式投入使用。 系統維護上線後修正問題、配合環境或需求變動調整功能,並改善效能。 系統分析回答「需要做什麼」,系統設計回答「要如何做」。把使用者需求轉換成供開發人員使用的系統開發文件(需求規格),屬於系統分析。程式設計則是依規格與設計撰寫程式,通常屬於建置工作的一部分。 常考陷阱 看到「開發文件」「開發依據」就選系統設計或系統建置:各階段都可能產生文件;若內容是把使用者需求轉換為規格,關鍵仍是系統分析。 把需求規格與程式撰寫混為一談:需求規格說明系統應達成的功能;程式設計則將功能實作出來,屬於後段工作。 看到「決策參考建議」就選 MIS 或 EIS:須再看資訊如何產生。例行報表偏向 MIS,高階摘要偏向 EIS,交易紀錄屬 TPS;「讓電腦對結構性或半結構性決策提出建議」則是 ES。 將銷售情報誤認為訂貨或資料交換:商品販賣種類、數量、時間與消費者需求的蒐集分析,優先辨識 POS;EOS 看訂貨,EDI 看標準化交換。 用設備功能解釋縮寫:ATM 可以轉帳,但縮寫代表自動櫃員機,不是電子資金轉帳(EFT);管理資訊系統則固定記為 MIS,不是 MIB、MAB 或 AIS。 記憶口訣 「銷售 POS、訂貨 EOS、交換 EDI;管理 MIS、專家 ES、櫃員 ATM。」 「規劃定方向、分析列需求、設計畫方案、建置做系統、測試驗成果、導入換上線、維護再改善。」尤其記住:需求變規格,先找系統分析。 「電腦給建議,專家系統 ES。」