資訊管理系統到底在管什麼？不是資料庫，也不只是ERP

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

有些公司會遇到這樣的畫面：業務手上有一份自己維護的客戶清單，倉管有自己的庫存表，財務月底才把各部門的數字兜起來，做成一份報表交給老闆。系統其實買了不少，ERP有、CRM也有，但老闆想知道這個月到底賺不賺錢的時候，還是得等某個人花好幾天把資料拼出來。

如果你正在查「資訊管理系統」，很可能你想解決的不是「要不要買一套軟體」，而是更根本的問題：公司的資訊到底該怎麼流動，誰該在什麼時候看到什麼。這篇文章想先把這件事講清楚，而不是急著跟你介紹某一套系統的功能。

先講一個很多公司都有的畫面：系統一套一套買，主管卻還是狀況外

規模還小的時候，一家公司靠幾份Excel跟老闆的記憶就能運作。業務記得每個客戶的狀況、倉管知道庫存大概剩多少、老闆腦子裡有一張公司全貌的地圖。這個階段不太需要什麼「資訊管理系統」，因為資訊本來就沒有分散到需要特別整理的程度。

問題是公司一旦成長，部門變多、人變多，這張地圖就不再只存在一個人的腦子裡了。每個部門為了把自己的事做好，通常會先各自找工具、各自建流程——業務用CRM記客戶，倉管用進銷存系統管庫存，財務用會計軟體做帳，每一套系統都解決了那個部門自己的問題，但彼此之間沒有講話。

這種現象在管理學裡有個講法，叫「資訊孤島」：資料分散在不同系統、不同部門，彼此無法順暢連通、整合與共享。IBM官方知識頁面對這個現象的說明是，資料孤島會讓組織難以跨部門存取、分析與共享資訊，進而拖累決策速度與競爭力。它不是哪個部門偷懶或藏私造成的，而是企業在資訊化初期，多半是哪個部門先痛就先買哪套系統，各自獨立導入的結果——ERP、CRM、進銷存平台各自運作，資料格式也不一樣，時間久了自然變成一座座孤立的島。

結果就是文章開頭那個畫面：系統明明不少，主管卻還是得靠人工把不同來源的數字兜起來，才看得到公司的全貌。這種資訊分散的狀況，其實是很多中小企業推動數位轉型過程中最容易卡關的地方——不是缺系統，是缺一套讓資訊真正流動起來的邏輯。這時候你需要的，不是再買一套系統，而是先搞懂「資訊管理系統」這個詞在管理學裡到底在講什麼。

資訊管理系統，其實在講的是一件事：資訊怎麼流動、給誰看

一句話講完：管理資訊系統（Management Information System，簡稱MIS）談的是企業怎麼有系統地收集、整理、傳遞資訊，讓對的人在對的時間，拿到支援決策所需要的資訊。它是一個管理概念，不是某一套特定軟體的名字。

這句話拆開來看有兩個重點。第一，「有系統」代表這不是大家把資料丟進同一個資料夾就叫做資訊管理，而是要先想清楚誰需要什麼、多常需要、需要到什麼細節。第二，「支援決策」是這整件事的目的——資訊管理系統存在的理由，從來不是把資料存起來這件事本身，而是讓公司裡不同角色的人，能根據可靠的資訊做出對的判斷。

三個管理層級，各自需要不同顆粒度的資訊

這裡有一個很多人沒想過的地方：公司裡不同層級的人，本來就不該看一模一樣的資訊。管理學把組織的決策粗分成三個層級，各自需要的資訊顆粒度差很多，下表整理各層級的角色與需要的資訊型態：

管理層級	誰在用	需要的資訊顆粒度	常見判斷範例
營運層	第一線員工（倉管、櫃檯、業務助理）	即時、細節的單筆交易資訊	這張訂單出貨了沒、這批貨進了多少
管理層	中層主管（部門經理、店長）	一段時間的彙總與趨勢報表	這個月業績跟上個月比怎麼樣、哪個環節開始出問題
策略層	高層（老闆、執行長）	長期、全局的方向性資訊	公司整體健康度、未來半年到一年資源該往哪裡調整

這不是誰故意把資訊藏起來，而是不同層級本來就需要不同顆粒度的資訊來做決策——這正是資訊管理系統要處理的核心問題：怎麼讓資訊順著這個層級往上流動，每一層拿到的都是剛好夠用、不多不少的資訊。高層如果每天被淹沒在第一線的交易明細裡，反而做不出真正該做的策略判斷；第一線如果只看得到抽象的月報，也沒辦法處理眼前這一筆訂單該怎麼出。資訊管理系統做得好的判準，不是資訊量夠不夠多，而是每個層級拿到的資訊，跟他要做的決策夠不夠對得上。

資訊管理系統、資料庫、ERP，是三個不同層次的東西

很多人會把「資訊管理系統」「資料庫」「ERP」這幾個詞混在一起講，覺得反正都是公司的系統。實際上這三者是不同層次的概念，搞懂這個層次關係，你才會知道自己公司真正缺的是哪一塊。

層次	概念	主要在回答什麼問題	白話比喻
底層技術	資料庫（管理系統，DBMS）	資料本身怎麼被安全、有效率地儲存與存取	水管與水塔，負責把水（資料）送到該去的地方
管理邏輯	資訊管理系統（MIS）	誰該在什麼時候看到什麼資訊，來支援什麼決策	決定哪個水龍頭該開多大、通到哪個房間的整體配管規劃
應用工具	ERP／CRM等具體系統	用一套現成或客製的軟體，落實某個範疇的資料管理與流程	裝在牆上、實際給你轉開的那個水龍頭

資料庫：資訊流動的底層水管

資料庫是儲存與管理資料的技術工具，負責資料的新增、修改、查詢與存取權限，確保資料安全與完整——這是純技術層的事，跟「誰該看到這筆資料」這種管理判斷是兩回事。技術媒體TechTarget在比較資料庫管理系統時也指出，DBMS的角色是作為使用者與資料之間的介面軟體，負責資料的組織、儲存與存取，這個定位本身不涉及這筆資料該給誰看的管理判斷。你可以把資料庫想成埋在牆壁裡的水管，它負責把水（資料）從一個地方送到另一個地方，但水管本身不會決定客廳該裝幾個水龍頭、廚房的水量該開多大，那是更上層的規劃。想更完整了解資料庫本身的定義與種類，可以參考資料庫是什麼？從定義、種類到系統開發中的角色一次搞懂。

ERP／CRM：落地這套邏輯的其中一種現成工具

ERP是一個統一資料模型的企業資源規劃系統，把財務、採購、庫存、人資這些具體資源整合在同一套框架下管理；CRM則聚焦在客戶關係這個範疇。它們都是把「資訊管理」這個概念，落地成某個範疇具體可用的工具，但ERP、CRM本身不等於資訊管理系統這個概念——就像買了一套水龍頭，不代表你已經規劃好整棟房子的配管。你可以完全沒有ERP，只靠幾個報表跟明確的權限規劃，就把資訊管理這件事做得不錯；你也可能買了昂貴的ERP，卻因為沒想清楚誰該看到什麼，資訊照樣亂。

換句話說：資料庫是底層技術，資訊管理系統是決定資訊怎麼流動與給誰看的管理邏輯，ERP／CRM則是落地這套邏輯時可能用到的其中一種工具，三者不是同一件事，也不互相取代。三者也不是互斥關係——實務上一套設計良好的ERP，底層一定連著資料庫，而它的報表模組通常就是在幫你落實資訊管理的一部分，只是「資訊管理」這件事的範圍，通常比單一套ERP能涵蓋的還要更廣、更貼近公司實際的決策習慣。如果你正在評估公司要不要導入ERP，也可以參考ERP系統是什麼？中小企業導入前要先想清楚的5件事。

五個訊號，代表你的公司該認真想「資訊怎麼流動」這件事了

不是每家公司現在就需要正式著手處理這件事。規模還小、老闆一個人就能掌握全貌時，先把基本的記錄做好即可，不用急著上什麼系統。但如果你符合下面幾個訊號中的兩三項，這件事就值得認真排上議程了：

同一個數字，不同部門講出不同版本。 業務說這個月成交了多少，財務算出來的數字對不上，兩邊都覺得自己是對的，最後要花時間對帳才能確定真相。

主管要等人整理，才能看到自己想看的東西。 每次開會前都要有人先花半天到一天，把不同系統的資料手動彙整成一份報表，這件事每個月都在重複發生，長期下來累積的工時往往比想像中多。

新主管上任，要花很久才能搞懂公司現況。 資訊沒有被結構化地整理與傳遞，全靠問人、靠交接時的口頭傳承，換一個人上手的成本就很高，而且沒有制度化的資訊，換人接手就容易出錯。

部門各自買了系統，資料卻兜不起來。 業務系統、庫存系統、財務系統各自運作良好，但要看整體營運狀況時，還是得靠人工把幾份報表拼在一起。

決策常常是憑感覺，不是憑資料。 不是主管不想看數據，而是可靠、即時的數據本來就沒有被組織起來，等到真的想看時，資料要嘛不存在、要嘛要花太久才拿得到。

買了系統，資訊孤島還是沒解決：最常見的誤解

這是很多老闆容易踩的一個坑：把「資訊管理系統」直接當成一套要去採購的軟體產品，覺得買了、裝了，資訊亂的問題就解決了。

現實常常不是這樣。如果沒有先想清楚誰該看到什麼、資訊要怎麼整合，新買的系統很可能變成第三座、第四座孤島——它確實解決了某個部門的問題，但跟其他系統之間依然沒有打通，主管一樣得靠人工把幾套系統的資料拼起來，只是現在要拼的系統又多了一套。

哈佛商業評論在探討組織協作障礙的一篇文章中指出，多數協作失敗的根本原因來自組織內部的穀倉現象——部門之間溝通受限，各自守著自己的資訊與流程。這跟「資訊孤島」講的其實是同一個現象：問題的根源通常不是缺一套系統，而是部門之間沒有被設計成願意、也方便互相交換資訊的樣子。IBM官方對資料孤島的說明也呼應了這一點：資料孤島之所以難解，是因為它牽涉到組織裡不同團隊各自習慣的做法與流程，不是單靠導入一套新技術就能自動打通。

這也是為什麼「資訊管理」要從管理邏輯著手，而不是從採購一套系統著手。系統是工具，工具能不能發揮作用，取決於你有沒有先想清楚：這家公司裡，誰需要看什麼、多常需要、看到什麼顆粒度才夠用、不同來源的資料要怎麼被整合成同一個可信任的版本。這些問題想清楚了，不管最後用現成軟體、客製系統，還是先從幾份設計良好的報表開始，都能真正解決問題；這些問題沒想清楚，買再貴的系統也只是換一個更貴的孤島。

真的要動手，該從哪裡開始

把「資訊管理系統」當成管理邏輯而不是採購清單之後，實際落地時，可以照這個順序想：

第一步，盤點現有的資訊怎麼被記錄與傳遞——哪些在Excel、哪些在系統裡、哪些純粹靠口頭交接，先把現況攤開來看，而不是急著跳到該買什麼系統。

第二步，定義不同管理層級各自需要看到什麼顆粒度的資訊——這一步呼應前面講的三層決策架構：第一線需要即時明細，中層需要彙總趨勢，高層需要全局方向，把這幾層各自的需求先寫清楚。

第三步，設計報表與存取權限，讓對的人在對的時間看到對的資訊——不是所有人共用一份原始資料，也不是什麼都要問人才拿得到，而是有意識地規劃誰的帳號看得到什麼。

第四步，才輪到選擇對應的工具落地——可能是既有系統的一個報表模組、一套BI工具，也可能是客製開發的系統，依規模與預算判斷。這一步永遠排在前面三步之後，不是最先想的事。

需求訪談：先搞懂誰需要看什麼，再談系統

這個順序聽起來理所當然，但實務上很多專案是反過來走的——先看中一套系統的功能介紹，覺得看起來不錯就決定要導入，結果做到一半才發現，這套系統的報表邏輯跟公司實際的管理層級對不上。

需求訪談之所以是這件事最關鍵的一步，是因為它決定了後面做出來的東西，到底是貼合公司實際的資訊流動方式，還是一套技術上沒問題、但沒人真的想用的系統。多數客戶一開始對自己需要什麼並不清楚，只知道現在的方式有問題，需要有經驗的團隊協助把模糊的需求拆解清楚，先釐清真正要解決的問題是什麼，再決定用什麼架構去解決它。這也是為什麼系統規劃開發的服務流程，通常會把需求訪談排在最前面，而不是一開始就丟一套現成方案讓客戶套用；如果想更了解需求訪談之後、完整的系統開發會經過哪些階段，可以參考系統開發生命週期：委外開發前，這套邏輯你要先懂。

FAQ

如果你也想先把公司資訊怎麼流動這件事想清楚，再決定要不要導入哪一套系統，瞻新資訊在協助客戶做系統規劃時，一直是從需求訪談開始釐清誰該看到什麼，而不是先丟一套現成方案給你套用。