MIS:管理資訊系統1

資訊管理不是背書，是實作，所以我們先從一個實例說明。

MIS管理資訊系統個案研究

「世新資訊公司」原來從事電腦設備連鎖店面銷售。但近年由於店面租金、以及人事費用高漲，利潤偏低，已逐漸失去競爭優勢。

公司主管乃引入「電子商務」新觀念，計畫開發「電腦網路銷售業務」，向廠商批入各種電腦原料，經各種組合後，再銷售給消費者。

這項銷售業務在管理上的考量包括：

廠商管理：各個廠商資料、產品項目、利潤政策（出貨價格-訂貨價格）。

客戶管理：個人資料、銷售產品、郵購與出貨記錄、付款方式、收費記錄；並能查詢、列印ＤＭ標籤。

訂貨管理：各廠商產品訂貨單、集計單（訂貨價*訂貨量）。

庫存管理：進貨量記錄、提貨量記錄、庫存量記錄。

出貨管理：客戶資料、各廠商產品出貨明細單、提貨集計單。

相關財務管理：對帳、請款、收帳、發票各項作業。

你就是「世新公司」這項業務的事業部主管，計畫以MIS方式管理這項新業務，你將如何進行規畫？再創企業新機？

註：以上是統雄老師在神通電腦服務時，真正為客戶開發的系統，所以本案討論的問題不是假設，而是事實。唯基於企業倫理，改變客戶名稱。

基本問題

一、什麼是MIS（管理資訊系統）？

MIS 就是一個以「資料庫管理系統(DBMS)」為基礎，擁有高階使用介面的資訊系統。

所以，MIS相對於檔案型系統（如你個人電腦上、Windows的「檔案總管」），最大的特色就是「資料庫」，從以上個案的分析為例，其概念模式圖如下：

在以上的分析圖中，我們可以知道：

在這個系統上，有許多不同的使用者，從事個別不同的工作。

個別使用者所從事的工作，要依靠不同的資料。譬如，主管要作產品策略，就必須要有所有協力廠商的資料、與相關原料規格、價格的資料。

許多不同使用者所需的資料-如深褐色區塊、和淺褐色區塊-其實是連通的。譬如採購員下單的對象與原料，必須是主管核准的範圍；而財會付款之前，必須稽核庫房管理是否有簽收協力廠商的進貨；以上資料必須是完全相同的。

如果對每位使用者都建立一套系統，不僅重複而事倍功半，同時還有可能發生人為疏忽，造成資料不一致的情形。

所以，我們要使用「資料庫」管理，也就是不同使用者在工作時，只是使用不同的表單（表單是術語，其實就是表格），但依據的資料是相同的。

同時，資料使用的權限又不同，譬如：主管對協力廠商的管理權限比採購員大，而業務人員不需要、甚至不應該看到成本資料。

由 DP/TPS 到 MIS

電腦問世之初，還沒有資料庫觀念，就是對每位使用者作一個系統，稱為電子資料處理系統(DP)、或交易處理系統(TPS)。

在DP/TPS 時代，是直向、部門建立系統的觀念，以上公司要建立 6 個系統。

在MIS 時代，是橫向、整合建立系統的觀念，以上公司的管理可簡化為：2 組、4類表單，實務上，表單常稱為系統。亦即：供應廠商/物料系統、客戶/產品系統。

而所有「輸出表單」，如策略、下單、庫存…，幾乎都是由以上實體表單(Entity)所產生的關聯表單(Relationship)。

資料庫管理的功能與優點

資料庫管理的功能與優點如下：

可以對個別資料進行：查詢、新增、修改、刪除的動作。以上為資料庫問世時的4大功能，但隨應用規模愈來愈大，當前常另獨立出「核准」功能。

可以同時管理結構性（即數量）資料、與非結構性（即類別）資料。

資料、功能具備關聯性、分享性、整合性。（即上下游的作業可連結）

資料避免輸入重複性、因此具備一致性。

可以授權個別使用者進行不同的作業。 

二、MIS/IS 的規畫者，目的與內容為何？

策略規畫：目標--總經理、事業部主管

管理規畫：方法--事業部主管、幹部，相關部門主管，資訊管理人員（可再分為：專案經理、系統分析師、介面設計師、資料庫設計師、媒體設計師），程式設計人員。

作業規畫：行動--資訊管理人員，事業部主管、行銷、採購、庫房、業務人員、財務人員，與相關部門人員

從 MIS 到 IS 內容的演變

MIS 一詞，最早是 IBM 電腦公司，為其企業客戶所作軟體服務的產品名稱。

美國於1968才由Minnesota大學雙子城校區創設第一個Management Information Systems Program (MIS)，早期常是在管理學院，或是「決策科學(Decision Sciences)系」下的一個學程(track)，後來漸漸單獨設系，所以老牌的學系名稱常是「資訊系統與決策科學系 IS&DS」。

近年許多新Programs不斷誕生，名稱非常多元化，由於系統的應用愈來愈廣，而不限於 Management，便多使用綜合性的 Information Systems (IS)名稱。IS 也長期隸屬在 DS 學會下，直到1994才有獨立的IS學會。同時，IS又與 IE, Management Science 相互影響，使IE 轉型為 ISyE（工業與系統工程）。

MIS 發展到今日，已不限於狹義的管理-即進銷存，而可廣泛應用於各領域，也可簡稱為 IS。本系列文章使用 MIS 一詞，是取知識歷史承傳的意義，各項討論可適用於廣義的資訊系統 IS。

臺灣 IS 的特色

臺灣將資訊系統 IS 稱為資訊管理，而50年來的教育政策側重培養理工人才，所以大部分的人才來自資工、資科，許多學校的資管甚至實為資工、資科第二系，老師們參加國際資工、資科學會的，甚至遠多於國際IS 學會。在這種環境下，形成了與國際頗不同，具有臺灣特色的資訊管理課程設計：

1. 資訊管理﹦資工、資科+ 3 ㄐㄧ\：經濟、會計、統計

2. 資工、資科課程在比率上偏高；或是課程內涵偏向後端（演算），而非前端（使用者）；或是同名課程，但內容設計偏向底（工具）層、而不是IS的頂（應用）層。

3. 而在資訊管理學門中，可能不少掌握國家資源的領導者，也認同這種臺灣特色。 

更進一步的討論，請參考「資管教育」專文。

本系列文章尊重傳統，仍採用名稱，但內容涵蓋綜合性的 Information Systems (IS)。

三、MIS/IS 的規畫程序為何？

資訊系統規畫的程序，專業用語包括以下幾種：SDLC (System Development Life Cycle)、SA/SA&D(Systems Analysis and Design)、Software Engineering。

SDLC (System Development Life Cycle)

系統發展循環

資訊系統最早的規畫程序稱為SDLC (System Development Life Cycle)，中文常見譯為「系統發展生命週期」，可能不盡恰當。因為它的意義是表示：系統問世後，一定會因為內在使用者的反映、外在技術的變遷，而有持續改版的必要，所以統雄老師建議，譯為「系統發展循環」較能反映系統不斷追求成長的意義。這和更廣義的「知識產生程序」一樣，是一個反復改善的程序。

SA&D(Systems Analysis and Design) / SA(Solution Architecture)

系統分析與設計/整體解決方案架構

在資訊管理領域中，當前的系統規畫與開發程序，多稱為 SA&D(Systems Analysis and Design) ，在職稱上簡寫為 SA(Systems Analyst)，中文為「系統分析與設計」。（注：許多文章誤拼為 Systems Analysist，但也有約定成俗的趨勢。）

而2000年後，以 Forbes 的「就業分類」為例，其職能範圍擴大，強調資訊系統與商業模式的整合，以提供最適與最完整的服務，且名稱變為 Solution Architecture 整體解決方案架構，仍簡寫為 SA。

資訊管理領域強調的是應用系統開發，這也是本系列文章，主要採用的名稱。

Software Engineering

軟體工程

北大西洋公約組織（NATO）在1968年提出了 Software Engineering的名稱，中文為「軟體工程」，以建議「軟體開發應該是類似工程的活動」。這個名稱在「資訊工程、資訊科學」領域中較常使用，多作為工具系統開發。

隨著時代進步演化，傳統資訊工程、資訊科學領域愈來愈發現不能脫離組織目標、亦即不能忽略商業模式，雖然產品對象可能不同，但設計的應用方向愈來愈導入 MIS 的觀照。

資訊管理領域和資訊工程、資訊科學領域的基礎差異，應用系統與工具系統的不同，請參考：資管教育一文。

四、MIS/IS 的兩種開發思想哲學

MIS/IS 前後出現了兩種開發思想，也可以說兩種存在基本差異的哲學，即：瀑布模型（Waterfall Model）系，與敏捷軟體開發（Agile software development）系。

瀑布模型（Waterfall Model）系

瀑布模型（Waterfall Model）是最早去定義 SDLC 中應該有何程序，以及其順序者：

需求（Requirements）
設計（Design）
實作（Implementation）
整合與測試（Integration）
移交與維護（Maintenance） 

這個原始程序定義的大方向沒變，但顯然有些模糊，譬如「設計」，要設計什麼？

後來各方不斷增補，有的甚至多達數十個程序。也出現許多新模式、新主張的名詞，不過都是大同小異，均重視「程序」導向。

這個開發思想集大成的工具就是 UML。

敏捷軟體開發（Agile software development）系

敏捷軟體開發（Agile software development）系是對瀑布模型（Waterfall Model）系的反動。

瀑布模型（Waterfall Model）系強調程序，因此要求每個程序都必需製作程序文件，以便於溝通、承傳，使不同人員的工作群組仍能達成群體作業，也使系統產品未來更容易維護與升級。

而敏捷軟體開發（Agile software development）的倡議者都是程式員，覺得製作程序文件的壓力太大了，他們也多半是中小型系統的開發從業員，認為系統升級就是重寫，舊文件沒什麼用。簡單講，他們最強調的是「客戶協同作業」、就是面對面與使用者的溝通，認為比書面的文件更有效，在客戶前立刻寫程式、立刻修改、不斷改善版本。

在這個思想之下，也興起了多個工作模式。

統雄老師基於「永續」理念，還是建議以「程序導向」為主，但應保有敏捷的效率意識，從而提出：「系統分析與設計」神掌。

「系統分析與設計」神掌

所謂「神掌」文，就是以求打通任督二脈的文章，包括：整合、精簡、創新與啟發４個目的。

在許多純理論的系統設計教科書中，往往遺漏了「競爭者分析」的程序，或是另有一個「文獻分析」的程序。在學術研究中，「文獻分析」是非常重要的起步程序，但在資訊系統開發過程中，重視的是實務，這裡的「文獻」應該是廣義的、市場上已存在的競爭系統。

各教科書所列的程序不盡相同，有些可能是為了「賣書」的考量，塞了太多無關的垃圾以增加份量。

統雄老師將其歸納精簡，建議練就「系統分析與設計」神掌的程序如下：

競爭者分析

需求分析

可行性分析

系統實作分析與設計

程式分析與設計

系統測試、手冊製作、使用者訓練

系統建置、維護與修訂

四、MIS系統分析與設計

競爭者分析、需求分析、可行性分析、與系統實作分析的程序與技術_統雄老師的1-2-3-4簡則