一棟辦公大樓裡，每間辦公室各自上鎖，請假要去 3 樓拿鑰匙、查庫存要去 5 樓、找合約範本又得跑到地下室。不少公司的資訊系統其實就是這個樣子，只是樓層換成了人資系統、ERP、檔案伺服器和各種通訊群組。EIP（Enterprise Information Portal，企業資訊入口網站） 做的事，就是在大樓一樓設一個櫃台，員工登入一次，就能從同一個地方走到想去的辦公室。
系統越來越多，員工找資料的時間就跟著變長，這正是 EIP 要處理的問題。不過這個詞在市面上被用得很鬆，內部網站、協作平台，甚至一整套辦公軟體，都可能被貼上 EIP 的標籤，小公司評估時很容易分不清自己缺的是哪一塊。
要判斷公司需不需要自己的 EIP，得先弄清楚它負責的範圍，也要知道現有工具已經做得到哪些事。
EIP 企業入口網站是什麼？
EIP 是 Enterprise Information Portal 的縮寫，中文常稱企業資訊入口網站，也有人簡稱企業入口網站。國立中央大學洪雅蘋 2012 年的碩士論文，把它定義為企業為了解決龐大組織裡員工需依各種情況與條件、花費大量時間到各系統尋找所需資訊，所提出的標準化資訊共享平台。
這個定義的重點不在「公司內部的網站」，而在「集中」二字。EIP 把分散在各系統的資訊、應用與流程，依使用者的身分集中到同一個登入點。同樣是登入，業務看到的是待簽的報價單，行政看到的是今天的會議室預約，新進同事看到的則是報到需要完成的事項。
入口的對象也不一定只有員工。Microsoft 在說明現代 intranet 的協作要素時，就提到工作團隊與主題社群可以在其中分享知識，範圍涵蓋整個組織，也包含延伸企業裡的外部夥伴。這代表入口的邊界由公司自己決定，可以只服務內部，也可以開一部分給合作對象。
這類平台的歷史其實不短。國立中央大學王銘揚 2018 年的碩士論文指出，企業資訊入口網站從 2000 年左右開始蓬勃發展，商用與開放原始碼軟體的架構與功能到現在都已相當成熟。換句話說，EIP 並不是新概念，現在談的重點多半落在「值不值得為自己的規模導入」。
另外要提醒的是，EIP 在別的領域也是縮寫，例如雲端服務裡常見的 Elastic IP（彈性固定 IP 位址）。這裡談的 EIP 指的是企業入口網站，與網路位址無關。
EIP 與內部網站、ERP 各自負責的範圍
EIP 常被拿來跟內部網站、ERP、通訊軟體混為一談，其實把它們放在「入口」與「系統」兩個層次來看就清楚了。ERP 這類系統負責處理帳務、訂單、庫存這些交易本身，資料的正確性與流程的運算都發生在它裡面。EIP 站在它們前面，負責讓員工從同一個起點找到該去的系統，並不取代 ERP，也不會替它記帳。
內部網站和 EIP 的差別，傳統上在於重心。內部網站偏向發布，也就是公司把公告、規章與表單放上去讓大家來看；EIP 則多了「依身分呈現」與「連到其他系統辦事」這兩層。員工在入口上不只是閱讀，還能進到請假系統送出申請，或到簽核頁面處理待辦。
Teams、Google Chat 這類溝通工具，負責的是人與人之間的即時往來。訊息一則接著一則往下捲，重要通知很容易沉下去，所以它們很難扮演「單一正式版本」的角色。入口放的是需要長期查閱、位置固定的東西，兩者各有分工，並不衝突。
不過，這些界線現在已經變得模糊。Microsoft 對現代 intranet 的描述，把「連到工時系統或費用報銷表單，以及主管核准費用或工時表的地方」列為一類常見要素，也就是說，傳統上認為「EIP 才有、內部網站沒有」的辦事功能，如今連 intranet 的定義裡都已經包含。因此後面判斷小公司需不需要 EIP 時，看的應該是功能，而不是產品名稱。
EIP 常見的 7 種功能模組，入口能力與系統捷徑要分開看
Microsoft Learn 的 SharePoint 規劃文件指出，成功的 intranet 常見七類要素，分別是 Communication、Content、Actions and activities、Collaboration、Culture、Mobility 與 Search。放進日常工作裡，這些要素大致會變成七種功能。評估每一項時，要先分清楚它是入口本身的能力，還是入口連到另一套系統的捷徑，因為兩者在導入時的工作量完全不同。
個人化首頁與單一登入
入口的第一個價值，是登入後看到跟自己有關的東西，待辦事項、部門公告與常用系統入口，都會依角色與部門而有所不同。Microsoft 把 hub site 能提供的價值歸納為三件事，分別是共用導覽與品牌、內容與搜尋的彙總，以及一個作為起點的首頁。這三件事撐起的是入口首頁的骨架。至於「依身分呈現」，則是靠權限過濾來做到，hub site 彙總出來的內容，沒有存取權的人就看不到。
單一登入（Single Sign-On）是入口能串起多個系統的前提，意思是登入一次之後，進到其他系統不用重新輸入密碼。這是概念上的說法，實際能不能做到，要看各系統是否支援。入口再怎麼整齊，後端系統若不接身分驗證，員工還是得在每個系統各登入一次。
公司公告和新聞集中發布在入口
重要通知被信件與群組訊息淹沒，是很多公司共同的困擾。Microsoft 說明 communication site 的用途，是廣播訊息、說故事，以及分享供檢視（而不是編輯）的內容，作者人數少，讀者人數遠多於作者。這種「少數人發布、多數人閱讀」的模式，正好適合公司公告與新聞。
公告放進入口之後，會成為「單一正式版本」。員工想確認最新的辦公室規定，不必在群組裡一路往上滑，發布的人也只要修改一個地方。至於已讀追蹤、閱讀確認這類功能，只有部分 EIP 產品另外提供，屬於特定產品的設計，評估時可以當作加分項，但不要把它視為入口的共通配備。
文件庫權限依單位設定，而非跟著個別檔案
規章、表單範本與專案文件需要有固定的位置，同時要能控制誰可以看、誰可以改。這一塊最容易被忽略的是「權限要跟著單位走」，而不是跟著個別檔案走，這樣組織調整時，才不會整批設定一起壞掉。
Microsoft 的說明提供了一個很具體的例子。過去不少公司用子網站（subsite）串起 intranet，網址結構跟著部門階層走，一旦重組部門，所有關係都會被破壞，保留與分類這類原則也會被整個 site collection 強制套用。現在每個 communication site，以及與 Microsoft 365 群組連結的 team site，都是獨立的 site collection，可以有各自的權限；hub site 則不會改變關聯網站的權限。
Google 的做法比較簡單。協作平台（Sites）在發布時可以選擇「受限」或「公開」，選受限就能指定個人與群組成為檢視者。
電子表單與簽核流程
請假、費用、採購、用印這類申請，從紙本傳簽改為線上送出，由系統依規則轉給主管。在動手電子化之前，先檢查原本的流程有沒有重複簽核，因為把重複的簽核搬上線，只會讓重複變得更快，不會讓流程變簡單。
現成辦公套件的簽核功能，和「開箱即用的請假模組」不是同一回事。Microsoft 的 Power Automate 把核准休假申請、需要簽核的文件與費用報銷，列為 approvals 的典型用途；它提供四種核准型態，分別是所有人都要核准、第一個回應者決定、自訂回應並等待全部回覆，以及自訂回應並等待其中一人，另外還有依序核准。觸發方式也很彈性，例如在 Microsoft Lists 新增一筆項目，系統就會自動啟動核准。這是自己建立流程的工具，並不是一張建好的請假單。
授權的門檻不高，approvals connector 屬於標準連接器，Power Automate、Office 365，或內含 Power Automate 的 Dynamics 365 授權都能使用。核准流程會儲存在 Dataverse，預設環境會自動建立，不需要額外準備資料庫。
Google 雲端硬碟也有檔案核准功能，可以指定核准者與截止日。所有核准者都同意才算通過，只要有一人拒絕，整份檔案就視為被拒絕，核准期間也可以鎖定檔案。不過這項功能有方案限制，Google Workspace 管理員說明頁列出的支援版本包括 Business Standard、Business Plus、Enterprise Standard、Enterprise Plus、Education Plus，以及 Essentials 系列，入門的 Business Starter 不在名單上，個人帳戶（@gmail.com）也不能使用。這點對小公司特別重要，公司用的若是 Business Starter，得先升級方案才能使用。
行事曆、會議室預約多半由辦公套件內建
共用行程與資源預約，包括會議室、公務車、投影機，多半是辦公套件原本就做得到的一塊，不需要為了它專門導入 EIP。
Google Workspace 的管理員可以在管理控制台建立建築物、設備特性與可預約的資源，會議室、公司車與腳踏車都算。一個網域最多可以建立 10,000 棟建築物與 10,000 個資源，特性最多 100 個。資源通常幾分鐘內就能使用，但有時最多要 24 小時，才會出現在所有人的日曆上。
Microsoft 的做法是 Exchange Online 的資源信箱。會議室信箱對應實體地點，例如會議室、禮堂或訓練教室；設備信箱則用在不綁定地點的資源，像是投影機或公司車。使用者只要把資源加進會議邀請，就能預約。系統預設會自動接受沒有衝突的預約，也可以指定代理人手動決定要不要核准。
差勤與薪資查詢，資料其實存在人資系統
請假餘額、出勤紀錄與薪資條查詢，是許多人想像中 EIP 最實用的一塊。不過這類資料實際上存放在人資或薪資系統裡，入口只是把它顯示出來，或把員工帶過去。有沒有這一塊，取決於公司有沒有串接人資系統，與入口軟體本身的能力無關。
Microsoft 自己的 intranet 模型，就是這樣設計的。「Actions and activities」這類要素放的是連到工時系統或費用報銷表單的連結，以及主管核准費用或工時表的地方；HR 區塊的示範則是讓員工查詢剩餘休假天數、福利方案與可用的訓練。入口放的是連結，工時與人資系統本身另外存在。
所以公司若希望員工在同一處查到薪資與出勤，前提是已經有一套人資系統可以連，入口不會憑空產生這些資料。這也是小公司評估時，最可能需要另外處理的一塊。
全公司搜尋與 AI 助手的檢索範圍
入口原本靠導覽與搜尋，解決「東西放在哪」的問題。Microsoft 的 hub site 文件把員工找資訊的情境分成三種：知道它存在也知道在哪、知道它存在但不知道在哪，以及不知道它是否存在。這三種情境由導覽、搜尋與探索（偶然發現）的組合來解決。
現在多了 AI 助手，它能在授權範圍內檢索公司檔案，讓找資料不再只靠入口導覽。Microsoft 的授權說明把 Copilot 列為附加方案，Business Basic、Business Standard 與 Business Premium 都可以加購 Copilot Business；Copilot Chat 要切到工作模式、從該帳號有權存取的公司資料裡找答案，則需要另有 Copilot 授權。
Google 雲端硬碟的說明頁則指出，Gemini 可以把指定的檔案當作來源，綜合多份檔案的內容回答問題，也能摘要檔案與資料夾；使用時需要符合資格的 Google Workspace 或 Google AI 方案。方案名稱與功能邊界常常調整，採購前以最新說明為準。
不論用哪一家的 AI 助手，它能找到什麼，仍取決於檔案放在哪裡、權限怎麼設定。檔案散落在個人電腦裡，再聰明的助手也搜尋不到，這個基本功還是得靠入口與文件庫來打底。
EIP 導入的成敗取決於流程與人員的配合
小公司在評估要不要導入 EIP 時，最該先知道的是，導入失敗通常不是軟體不夠好，而是沒把組織的流程、人員與資訊技術一起調整。洪雅蘋 2012 年的論文就指出，很多企業建置 EIP 時，低估了導入前階段組織活動的配合，結果導入後成效不彰。
論文給的原因是，企業並不了解導入 EIP 涉及組織的整體層面，必須全面針對企業流程、人與資訊技術進行調整，否則上線後就無法符合專案原訂的願景。研究使用 Leavitt 於 1965 年提出的鑽石模型，從任務、人員、技術與組織結構四個構面分析，發現這四個構面彼此影響，甚至會產生連鎖反應，因此在不同導入階段，都需要重新調整資源的分配，以及這四個構面的配置。
王銘揚 2018 年的論文則提供了另一個角度。這項研究以一家半導體零件通路商為單一個案，導入開放原始碼的入口平台 Liferay Portal，結論是該平台的架構與效能可以滿足 EIP 的需求，但部分功能不夠完善，需要客製修改。企業導入開放原始碼軟體時，內部資訊人員的技術能力是關鍵，還要在組織結構、任務、人員與技術四個構面配合下，專案才比較容易成功。
這兩篇都是個案研究，樣本是單一或少數幾家公司，所以它們呈現的是「研究發現」，並不代表所有企業都會如此。不過方向很一致，那就是軟體只是導入的一部分。合理的推論是，功能越多的大套件，需要調整的流程與人員也越多，對沒有專人負責的小公司，風險反而更高。
小公司導入 EIP 前要看的 4 個條件
小公司需不需要 EIP，沒有一個「幾個人以上就該上」的標準答案，也沒有哪個結論可以直接套用。比較可靠的判斷方式是看四個條件，每個條件都有「現有工具就夠」與「需求成立」兩種情形，拿自己公司的狀況逐一對照，方向就會清楚。
員工規模與辦公據點的分散程度
人少而且在同一個辦公室時，口頭加通訊軟體就足以應付。以龐果設計這類單一辦公室的小團隊為例，公告喊一聲，文件放在共用雲端，大家都找得到，入口帶來的集中效益並不明顯。
當公司變成多據點、輪班制，或有人長期遠端工作，情況就不同了。這時候「統一的公告位置與資料位置」才開始有價值，因為沒人能靠隔壁座位的同事告訴自己東西放在哪。Microsoft 把 Mobility（員工可以在任何裝置上完成工作）與 Search（找不到位置也能找到內容）列為成功 intranet 的要素，原因就在這裡。
至於人數，目前沒有可信的研究或標準給出明確門檻。Microsoft 商務方案以最多 300 名使用者為上限，超過 300 人的組織建議訂閱企業方案，這是授權方案的分界，並不代表 300 人以下就不需要入口，也不代表超過就一定要。
資訊分散在不同系統的程度
EIP 的價值來自「串」。如果公司只有一兩個系統，入口沒有東西可以串，員工多半早就知道每個系統的位置，額外多一層入口反而是多一道步驟。
洪雅蘋論文裡描述的情境，是員工需依各種情況與條件，花費大量時間到各系統尋找所需資訊。系統越多，員工就越常問「這個要去哪找」，需求也就越明顯。舉例來說，一家有多個據點、人資與薪資另外使用不同系統的公司，每次有新進同事，都得重新教一遍每個系統的位置與帳號，入口的效益就很具體。
流程固定且必須留下紀錄的程度
請假、費用這類申請，如果有固定的簽核層級，而且需要留下紀錄供日後查詢，才真正需要流程引擎。若只是偶爾用到，用表單加郵件通知就夠了，不必為了它導入整套入口。
前面提到的辦公套件限制，在這裡會直接變成成本。Power Automate 的簽核得自己建立流程，Google 雲端硬碟的檔案核准則不支援入門的 Business Starter 方案。小公司若需要正式的簽核紀錄，可能得找人把流程建起來，也可能得升級方案，這些都要算進導入成本。
能長期維護內容與流程的人力
入口建好之後，公告、文件與表單流程都需要有人持續更新。小公司最容易缺的，往往不只是預算，還有願意負責維護的專人。
王銘揚的研究把內部資訊人員的技術能力視為關鍵；Microsoft 的文件則說明，讓每個工作單位各有獨立的 site collection，有助於長期治理（governance）與成長，使 intranet 能跟著組織調整。兩者的共通點是，入口需要有人持續管理。沒有人維護的入口，公告會過期，文件會停在舊版，最後員工又回到群組裡一個一個問，入口反而成了新增的負擔。
既有辦公套件能承擔的 EIP 功能
許多小公司早就在使用 Microsoft 365 或 Google Workspace，這兩套工具已經內建了 EIP 的一部分能力。所以更實際的問題是，公司正在用的那一套能做到多少。下表依前面的功能模組對照兩套工具，文件沒有提到的項目標為「官方文件未載明」。
| 功能 | Microsoft 365 | Google Workspace |
|---|---|---|
| 首頁與公告 | communication site，作者少、讀者多，用於廣播訊息與分享供檢視的內容 | 協作平台（Sites），拖曳式介面，可嵌入 Workspace 內容 |
| 文件與權限 | communication site 與連結 Microsoft 365 群組的 team site 各為獨立 site collection，可有各自權限；hub site 不改變關聯網站的權限 | 協作平台發布時可選「受限」或「公開」，受限可指定個人與群組為檢視者 |
| 簽核 | Power Automate approvals，需自行建立流程；屬標準連接器 | 雲端硬碟檔案核准，Business Standard、Business Plus、Enterprise 與 Education Plus 等版本可用，Business Starter 不支援 |
| 行事曆與會議室 | Exchange Online 的會議室信箱與設備信箱 | 管理控制台建立建築物、特性與可預約資源 |
| 差勤與薪資 | intranet 模型以連結連到工時與費用系統 | 官方文件未載明 |
| 搜尋與 AI | hub site 彙總內容與搜尋；Copilot 為可加購的附加方案 | Gemini 需符合資格的 Google Workspace 或 Google AI 方案 |
兩套工具各有定位，沒有哪一套適合所有公司。哪一套能承擔較多功能，要看公司原本使用的是哪一套，以及上表中的限制是否剛好落在自己的需求上。
Microsoft 365 的 SharePoint、Lists 與 Power Automate
SharePoint 有三種基本積木，各管一件事。Team site 負責協作，所有成員都是內容作者，預設連結 Microsoft 365 群組，並帶有 Teams 與 Planner；communication site 負責發布，作者少、讀者多；hub site 負責串接，提供共用導覽、佈景與內容彙總。
就功能來看，小公司用 communication site 加上 team site，通常就能涵蓋公告與協作的需求。hub site 要由 SharePoint 網站管理員以上的角色才能建立，因此要不要用，往往是管理員要先回答的問題。
Microsoft 365 商務基本版、標準版與進階版都包含 SharePoint Online、OneDrive 與 Teams（另有不含 Teams 的版本，購買時看清楚方案名稱），商務方案家族的使用者上限是 300 名。Microsoft Lists 與 Power Automate 再補上簡易表單和核准流程，簽核的運作方式前面已經說明過。
Google Workspace 的協作平台、行事曆與雲端硬碟
Google 協作平台用拖曳式介面架設內部網站，提供預建範本，能嵌入 Workspace 應用程式的動態內容，也可以管理共用權限。公司外部的人士即使沒有 Workspace 帳戶，同樣可以存取網站，不過可以透過共用設定限制存取權。
日曆的資源預約負責處理會議室與公務車這類需求，這部分前面已經介紹過。需要留意的是雲端硬碟的檔案核准有方案限制，公司若用的是入門方案，規劃簽核時要先確認能不能使用，這是小公司最容易漏看的地方。
辦公套件需要自行串接的缺口
套件在這些地方不是做不到，而是沒有現成成品。簽核流程得自己組，差勤與薪資要連到另外的人資系統，功能本身存在，只是得有人動手把它們接起來。
若公司對權限與稽核紀錄有特定程度的要求，也得逐項對照套件文件確認，不能憑印象判斷。這類需求能不能被現有方案滿足，答案常常藏在方案層級的細節裡。
缺口是否大到需要專屬的 EIP，可以回頭對照前面四個條件來判斷。兩篇論文也提醒了同一件事，不論最後選擇套件還是專屬系統，流程與人員的配合都得跟上。
專屬 EIP 的 3 條建置路線與共同前置工作
評估之後確實有需求的公司，大致有三條路線可走，分別是套裝服務、開放原始碼平台自建，以及客製開發。各條路都有自己的特性，但真正決定結果的，是選擇之前有沒有先釐清幾件事。
套裝服務由供應商提供現成的模組，導入的重心落在設定與系統串接。開放原始碼平台自建的前提，是公司有內部資訊人員，因為王銘揚的個案顯示，開放原始碼的入口平台雖然架構與效能能滿足需求，仍有部分功能需要客製修改，而且內部資訊人員的技術能力是關鍵。這項研究的摘要沒有提到成本數字，所以不能從中推論開放原始碼比較省錢。客製開發的彈性最高，但導入時對組織配合的要求，和前兩條路線是一樣的。
選擇路線之前，有三件事要先釐清。第一，要串哪些系統，這決定了後端的工作量。第二，入口的對象有沒有外部的夥伴或客戶；對象一旦包含他們，需求就從員工入口變成對外入口，登入方式、內容範圍與權限規劃都得重新設計，Google 協作平台允許外部人士在沒有帳戶的情況下存取網站，就是對外入口與員工入口差異的一個例子。第三，誰來負責維護，這個問題前面已經談過，不論選哪一條路線都躲不掉。
這三件事也是三條路線共同的前置工作。系統盤點清楚了，流程釐清了，維護的人也有了，不論最後選的是套件、開放原始碼還是客製，後面的選型與導入都有比較穩的基礎。
EIP 的價值不在於功能有多少，而在於員工是不是真的少花了找東西的時間。與其先問要買哪一套，不如先把公司裡員工每週要去的系統一個一個列出來，看看哪幾個值得串、哪幾個其實不用動。這份盤點做完，後面無論留在現有的辦公套件裡，還是走向專屬的 EIP，都有了判斷的依據。