108 年 國立臺北大學資訊管理學系碩士班《管理資訊系統》

本題主要在探討「假新聞」(Fake News) 這個社會現象，並要求從管理資訊系統 (MIS) 的角度，結合傳播學、社會學等知識，分析其產生的原因、傳播的動機與管道。

核心觀念：
資訊傳播的雙面刃、社群媒體的影響力、資訊過濾與同溫層效應、人為的動機與系統的漏洞。

解題思路：

1. 假新聞產生的可能原因：

   • 技術層面： 演算法的推波助瀾 (如社群媒體的推薦系統偏好能引發互動的內容，不論真假)、機器人帳號 (bots) 的大量散播、深度偽造 (deepfake) 技術的進步，使得假資訊難以辨識。
   • 人為動機：
     • 經濟利益： 透過點擊率賺取廣告費，假新聞通常聳動，更能吸引點擊。
     • 政治目的： 影響選舉、製造社會對立、打擊對手聲譽、散播特定意識形態。
     • 惡意操弄： 意圖製造恐慌、混亂、或單純的惡作劇。
     • 認知偏誤： 迎合人們的確認偏誤 (confirmation bias)，人們傾向相信符合自己既有觀念的資訊。
   • 社會心理層面：
     • 社群媒體的結構： 資訊傳播速度快、範圍廣，缺乏嚴格的事實查核機制。
     • 同溫層效應 (echo chambers) 與過濾氣泡 (filter bubbles)： 使用者容易被演算法推薦與自己觀點相似的內容，強化既有信念，減少接觸反對意見。
     • 資訊過載 (information overload)： 在海量資訊中，人們難以分辨真偽，容易被聳動、情緒化的標題吸引。

2. 假新聞為何被廣泛流傳：

   • 傳播速度快： 社群媒體的即時性與分享機制，使得假新聞能迅速擴散。
   • 情緒感染力強： 假新聞常利用聳動、煽情、或激怒人心的內容，觸動人們的情緒，促使人們分享。
   • 易於相信： 當假新聞出現在自己信任的社群圈或資訊來源時，人們的警覺性會降低。

核心觀念

• 個人資料（Personal Data）：任何能直接或間接識別自然人的資訊。
• 資料主體（Data Subject）：個人資料的擁有人，即自然人本人。
• 資料控制者（Data Controller） & 資料處理者（Data Processor）：分別負責決定資料處理目的與方式、以及受控制者委託執行處理的實體。
• GDPR 主要原則：合法性、透明度、目的限制、資料最小化、正確性、儲存期限限制、完整性與機密性、問責制。
• 資料主體權利：知情權、存取權、刪除權（被遺忘權）、限制處理權、資料可攜帶權、異議權。
• 罰則：最高 2% 全球營收或 1,0000萬歐元（以較高者為準）。

---

GDPR 概覽與網路隱私權保護

1. 適用範圍：凡在 EU 成員國提供商品或服務、或監測 EU 內資料主體行為者，即使企業位於境外亦受規範。
2. 合規義務：
   • 隱私權聲明（Privacy Notice） 必須以易懂、可取得的方式告知資料收集目的、類型、保留期限、第三方分享與資料主體權利。
   • 資料保護影響評估（DPIA）：高風險處理（如大規模監測、敏感資料）須提前評估並獲得主管機關批准。
   • 資料保護官（DPO）：必要時任命，負責監督合規、回應資料主體請求。
3. 技術與組織措施（TOMs）：加密、匿名化、偽匿名化、存取控制、日誌追蹤、定期安全測試等皆屬合規必備。

---

手機使用的 GDPR 影響

GDPR 要求	以往做法	現行做法（符合 GDPR）	具體實作例子
取得同意（Consent）	多數 App 在安裝後直接啟用追蹤或廣告 SDK，未顯示明確同意框。	必須在首次收集個人資料前提供可撤銷且具體的同意選項，並記錄同意時間、內容與方式。	Android/iOS 的 Consent SDK（如 Google Funding Choice）彈出同意對話框，使用者可勾選「同意收集位置資訊」或「同意個性化廣告」。
資料最小化	預設收集裝置 ID、通訊錄、位置信息等多項資料。	僅在功能需求下收集，非必要項目不收集或使用偽匿名化。	行動支付 App 僅在交易時收集 交易金額、時間，不保留裝置唯一識別碼（使用一次性交易代碼）。
存取與刪除權（Access & Erasure）	無統一入口，使用者只能透過客服申請，處理時間長且缺乏回覆。	App 必須提供「資料請求」與「刪除」入口（如設定頁面），並在 30 天內回應。	Facebook Mobile App →「設定」→「個人資料」→「下載你的資訊」或「刪除帳號」功能。
資料保護設計	資料傳輸多採明文 HTTP，缺乏加密。	必須全程使用 TLS 1.2+ 加密，敏感資料在本機端加密後再傳送。	醫療健康 App 使用 AES‑256 GCM 本地加密，僅在安全通道上送往後端。
跨境資料傳輸	隨意將資料傳至美國伺服器，未評估 Adequacy。	若傳至 EU 以外，必須使用標準合約條款（SCC）或取得明確同意。	跨國雲端儲存服務在使用者同意後，於隱私條款中說明「資料將儲存於美國伺服器，且已簽署 SCC」。

---

網站使用的 GDPR 影響

GDPR 要求	以往做法	現行做法（符合 GDPR）	具體實作例子

本題要求針對一個公寓大樓管理委員會的資訊系統建置需求，列舉十項功能性需求 (Functional Requirements, FR) 和十項非功能性需求 (Non-Functional Requirements, NFR)。

核心觀念：
功能性需求 (FR) 是系統「應該做什麼」(What the system should do)，描述系統應提供的特定功能或服務。
非功能性需求 (NFR) 是系統「應該如何做」(How the system should perform)，描述系統的品質屬性、限制條件和操作特性。

解題思路：

首先，理解題目情境：

• 目標： 協助物業管理公司管理社區的財產、收支、費用、住戶、文件、通告。
• 使用者： 管委會成員、住戶、物業管理公司。
• 限制條件：
  • 經費有限，無獨立機房、無專屬硬體設備。
  • 無法聘請專人維護系統。
  • 管委會成員變動頻繁，系統需易於交接與傳承。
• 可用資源： 初期建置預算、每年聯外網路預算。

基於上述分析，我們可以推斷此系統很可能採用雲端架構 (SaaS, Software as a Service)，因為這符合無專屬硬體、無專人維護、易於交接的特性。

一、功能性需求 (Functional Requirements, FR) - 系統「應該做什麼」

1. 住戶管理： 記錄住戶的基本資訊（姓名、聯絡電話、Email、戶籍地址、車位資訊等）。
2. 財務管理：
   • 記錄社區的收入（如管理費、停車費、公共設施使用費等）。
   • 記錄社區的支出（如清潔費、修繕費、管理費等）。
   • 自動產生應收費用明細，並發送給住戶。
   • 記錄繳費狀態，並能追蹤逾期未繳戶。
3. 費用通知與繳費：
   • 管理委員會可發布各項費用（如管理費、水電費、修繕費）的繳費通知。
   • 提供住戶線上查詢個人應繳費用明細。
   • （可選）整合線上繳費功能（如信用卡、ATM 轉帳）。
4. 資產與設備管理： 記錄社區共有財產（如公共設施、設備）的購置、維護、報廢等資訊。
5. 文件與公告管理：
   • 提供平台供管委會發布社區公告、會議記錄、規約等文件。
   • 住戶可查詢、下載相關文件。
   • （可選）提供線上表單申請（如申請停車位、公共設施使用）。
6. 公共設施預約管理： 提供住戶線上查詢公共設施（如會議室、健身房、游泳池）的可用時段並進行預約。
7. 報修與意見回饋： 住戶可透過系統提交設施報修請求或對社區管理提出意見。
8. 權限管理： 根據使用者角色（管委會委員、物管人員、住戶）設定不同的系統操作權限。
9. 報表產出：
   • 生成財務報表（如收支明細、年度預算執行報告）。
   • 生成住戶名冊報表。
   • 生成設備維護紀錄報表。
10. 搜尋功能： 提供關鍵字搜尋功能，方便快速查找住戶、公告、文件、財務記錄等資訊。

二、非功能性需求 (Non-Functional Requirements, NFR) - 系統「應該如何做」

本題分為兩個子題，第一個子題探討 ERP 系統的通用性，詢問為何不同產業、組織、環境、法規的企業仍能採用相同的 ERP 系統。第二個子題則探討 ERP 導入失敗的原因，要求分析在系統建置與導入生命週期中可能被忽略或處理不當的事項。

核心觀念：
企業資源規劃 (ERP) 系統、系統客製化與標準化、企業流程再造 (BPR)、系統導入生命週期、專案管理、組織變革管理、資訊系統成功因素。

解題思路：

第一子題：為何不同產業、組織、環境、法規的產業可以使用同樣一套 ERP 系統？(15%)

儘管企業在產業別、組織架構、內外部經營環境、政府規範等方面存在顯著差異，但現代 ERP 系統之所以能被廣泛應用，主要歸功於其以下幾個特性：

1. 模組化設計 (Modular Design)：

   • ERP 系統通常由一系列相互整合的模組組成，涵蓋企業的核心功能，如財務會計 (FI)、管理會計 (CO)、銷售與配銷 (SD)、物料管理 (MM)、生產製造 (PP)、人力資源 (HR) 等。
   • 企業可以根據自身需求，選擇性地導入所需的模組，而不必一次性部署所有功能。

2. 標準化業務流程 (Standardized Business Processes)：

   • 成熟的 ERP 系統通常內建了業界普遍認為是「最佳實務」(Best Practices) 的標準業務流程。
   • 這些流程基於對眾多企業的觀察與總結，能夠涵蓋大多數企業的營運模式。

3. 可配置性與參數設定 (Configurability & Parameterization)：

   • ERP 系統允許企業透過設定大量的參數和選項，來調整系統以適應其特定的營運規則，而無需修改程式碼 (coding)。
   • 例如，可以設定會計科目表、稅率、貨幣單位、庫存管理方法、生產排程規則等。

4. 客製化與擴充性 (Customization & Extensibility)：

   • 對於標準功能無法滿足的特殊需求，ERP 系統通常提供客製化 (customization) 的選項，允許對現有功能進行修改或開發新的功能（如 ABAP for SAP）。
   • 更常見且建議的做法是利用系統提供的擴充點 (enhancement points) 或開發獨立的附加模組 (add-on modules)，以避免影響系統升級。

5. 行業解決方案 (Industry-Specific Solutions)：

   • 許多 ERP 廠商會針對特定行業（如汽車製造、零售、製藥、公共事業）開發專門的行業解決方案，這些方案在標準 ERP 的基礎上，預先配置了該行業特有的流程、術語和法規要求。
   • 這使得 ERP 系統能更好地貼合特定行業的需求，即使是不同產業，也可能因為有共通的營運邏輯（例如，大多數製造業都涉及採購、生產、銷售、財務等環節）。

6. 對政府規範的適應性：

   • ERP 系統通常會設計成可以支援多國語言、多種貨幣、以及不同地區的稅務法規和報表要求。
   • 隨著法規的更新，ERP 廠商也會發布更新包 (support packages/patches) 來適應新的政府規範。

7. 核心業務邏輯的共通性：

   • 儘管產業、規模、環境不同，但許多企業的核心業務邏輯（如訂單處理、庫存管理、財務結算）在本質上是相似的。ERP 系統正是基於這些共通性來設計的。

總結： ERP 系統透過模組化、標準化流程、高度的可配置性、客製化能力、行業解決方案以及對全球化和法規的適應性，使其能夠被不同類型的企業所採用。企業的差異性往往透過參數設定、選擇模組、有限的客製化和導入行業解決方案來滿足。

第二子題：為何 ERP 系統導入會失敗？(15%)

ERP 導入失敗的原因眾多，且往往是多方面因素共同作用的結果。常見的失敗原因，在系統建置與導入的生命週期中，可能未被充分考慮或妥善處理的構面包括：

1. 缺乏高層管理者的承諾與支持 (Lack of Top Management Commitment)：

   • ERP 導入是一個重大專案，需要跨部門的協調與資源投入。若高層領導不支持，專案容易面臨資源不足、決策延遲、部門抵制等問題。

2. 不清晰的目標與範圍定義 (Unclear Objectives and Scope Definition)：

   • 導入初期未能明確定義專案目標、預期效益、系統範圍，導致專案失焦，難以衡量成功與否。範圍蔓延 (scope creep) 也容易發生。

3. 企業流程再造 (BPR) 不足或失敗 (Inadequate Business Process Reengineering)：