🧮 Access Control 平台目前在全球和台灣市場的實際應用探討 PART II

3S Market 探討報導

Access Control 目前在全球和台灣市場的實際應用探討

Audience Target

這篇探討主要提供給三類讀者：

Access Control 相關設備、軟體與系統業者：包括 Reader、Controller、智慧鎖、門禁軟體、SI 與代理商，思考既有產品是否還能往場域化、平台化延伸。
IT、IPC、Cloud 與場域應用供應商：包括 HR、PMS、POS、BMS、物業管理、校務、訪客與承攬商管理系統業者，觀察 Access 是否可能成為新的合作 Node。
業主端的安全、資訊、營運與設施管理主管：從國際與台灣實際案例，看 Access Control 是否還只是「門禁設備」，還是已逐漸成為身份、權限與程序管理的一部分。

對高科技、交通、醫療等高安全場域，本篇先做市場現象的基本帶入；零售與飯店則進一步觀察其平台化需求，與可能形成的市場機會。

Highlights

一、Access Control 平台不是憑空出現的新概念。從 Data Center、零售、飯店、機場、校園、醫院到商辦與物流，國際市場已經可以找到大量實際運作案例。它不是「未來可能發生」，而是正在不同場域發生。

二、真正把 Access Control 推向平台的，往往不是設備，而是場域程序。當系統開始需要回答「這個人是誰、具有什麼資格、在什麼時間可以進什麼地方」，管理邏輯便逐漸由 Door 延伸到 Identity、Authority、Procedure 與 Access。

三、零售可能是台灣中小型業者特別值得注意的市場。一家店可能只需要幾道門；但 50、100、300 家店之後，人員調動、倉庫、物流、維修、外包與不同營業區域的權限，就開始需要中央化管理。市場從「每一家店裝一套門禁」變成「整個企業管理一個 Access Network」。

四、飯店則顯示 Access 已開始和核心營運系統結合。PMS 掌握 Guest Identity，Access Management 把住房日期、房號、樓層與公共設施轉成 Authority；另一方面，Housekeeping、工程、餐飲、外包與供應商又形成另一條 Staff / Contractor Access Chain。

五、台灣未必沒有平台能力，問題可能是能力仍分散在 Project 裡。台大大型校園門禁、科技廠承攬商資格與 Access 聯動、商辦訪客與梯控、飯店 PMS 與門鎖整合，都已經出現平台化的管理邏輯。真正值得思考的是：這些專案經驗是否已經被整理成可以複製、部署與銷售的 Vertical Solution。

如果把 Access Control 仍然理解成卡片、Reader、Controller、電子鎖與一道道門，其實沒有錯，因為這些仍然是出入口管理最基本的組成。但是，當我們把視線從設備移到實際應用場域，就會看到另外一個現象：許多國際企業、零售賣場、飯店、機場、校園、醫院、商業大樓與物流中心，早已不只是利用 Access Control 決定「這張卡能不能開這道門」，而是開始透過一個管理平台，把人員身份、角色、時間、地點、權限與不同作業程序串聯起來。

上一篇我們探討「Access 管理平台為什麼陸續出現在各種場域？」這一次不急著繼續談平台應該具備哪些功能，也不急著預測它是不是下一個市場趨勢，而是回頭看看：現在全球不同市場，Access Control 到底已經被用到什麼程度？台灣是不是也已經有類似的應用？

答案可能比想像中有意思。

先看市場：Access Control 已經在哪些場域運作？

如果只是某一家廠商開始把自己的軟體稱為 Platform，可能只是產品命名；但如果完全不同的應用領域，都開始出現類似的管理方式，那就值得從市場角度繼續觀察。

應用場域	國際案例	Access/管理平台	平台實際處理的問題	台灣目前可觀察到的狀況
高科技/Data Center	ODATA BG01	C•CURE 9000	員工、承攬商、訪客、高安全區、多因子驗證、BMS	大型科技廠已出現資格、訓練、施工程序與門禁權限連動
科技企業	Zoho	Gallagher Command Centre	近 12,000 名持卡者、400 多道門、警報、事件與遠端管理	大型企業已有中央管理需求，但多以個別專案呈現
零售賣場	Meijer	Genetec Security Center／Synergis	約 300 個零售據點、配送中心、POS、EAS、Intrusion、Access	有相關產品與整合能力，公開的大型連鎖 Access Platform 案例反而不多
連鎖超市	Price Chopper／Market 32	LenelS2 OnGuard	132 據點、總部、倉庫、Data Center、藥局與管制藥品	很值得台灣連鎖零售重新思考多據點 Access 管理
商業大樓	22 Bishopsgate	Genetec Security Center／Synergis	Tenant、員工、公共空間、Occupancy、IoT 與營運資料	台北大巨蛋商辦已出現訪客、QR Code、梯控、角色權限整合
機場	Heathrow Airport	CEM AC2000 Airport	Badge、Airside／Landside、旅客分流、Airbridge、Check-in	台灣也有專用通行證及門禁體系，適合另立專題
物流/配送	URBN	Brivo	大型 Distribution Center、多據點集中管理與遠端操作	台灣物流市場值得進一步追蹤，尤其車輛、司機、臨時人員與倉儲權限
大學校園	University College London	Gallagher Command Centre	HR、學生、訪客、研究空間、Data Center、Lockdown	台大已有 3,500 道門、8 萬張卡的大型集中管理，並與卡務、住宿系統整合
醫院	Haaglanden Medical Center	Genetec Security Center／Synergis	醫療人員、高安全區、實驗室、Server Room、雙重驗證	台灣大型醫院亦有門禁、梯控與區域權限整合，後續值得獨立探討
大型 Resort	City of Dreams Macau	Gallagher Command Centre	1,700 道門、員工、HR、電梯、Key Management、Hotel Locks	大型飯店可能同時存在 Guest Access 與 Staff Access 兩套管理邏輯
連鎖飯店	Hey Lou Hotels	Vingcard Vostio	PMS、線上 Check-in、Digital Key、多館別標準化	台灣已出現 PMS、門鎖、自助入住、公共門禁、梯控整合方案

這張表真正值得注意的，並不是哪一家平台比較大，而是各個場域把什麼東西放進 Access Control。

以校園為例，University College London 已經把 HR、學生與訪客資料庫整合到 Gallagher Command Centre，107 棟建築、1,291 道門與 70,000 名有效持卡者由平台管理，研究空間與 Data Center 等區域再依身份與資格配置不同的 Access Authority。

但這並不是只有國外才有的應用。台灣大學公開案例顯示，其大型門禁管理系統涵蓋約 4,100 台設備、3,500 道門與 8 萬張卡，由一套系統進行多人分散管理，並與校內卡務系統介接；另一份系統整合資料還顯示，台大已進一步整合卡務與住宿系統。

UCL 與台大的架構不必硬說成完全相同，但兩個案例都說明了一件事情：當一個校園的學生、教職員、住宿、研究與大量建築開始共用身份與權限資料，Access Control 自然不可能再以一棟樓、一套設備的方式思考。

同樣的現象也出現在其他場域。Heathrow 的 AC2000 Airport 已依航空業需求發展出 Check-in desk enabling、旅客分流、Airbridge、Temporary Cardholder 等機場專用功能；22 Bishopsgate 則進一步把 Access、Occupancy、影像與 IoT 資料放進統一平台，Access 開始成為智慧建築營運資料的一部分。

因此真正值得問的也許不是：「Platform 是不是下一個流行名詞？」而是：為什麼不同場域最後都開始需要一個平台？

原因就在於，場域真正要管理的從來不只是一道門。

從「能不能進」變成「為什麼可以進」

傳統 Access Control 最容易理解的邏輯是：一張卡、一個人、一道門，系統判斷允許或拒絕。

但是實際營運不是這麼簡單。

一個人今天是員工，明天可能調職；一名工程承攬商今天完成安全訓練可以進廠，一年後證照過期就不應該再具有相同權限；飯店旅客下午 Check-in 之後才能進房，Check-out 後房卡必須失效；零售店員調到另一家門市後，原店的倉庫權限是不是應該同時取消？

因此 Access Control 真正開始處理的是：

Entity → Identity → Authority → Procedure → Access。

人的身份改變，Authority 跟著改變；程序沒有完成，就不應該取得 Access。

這也正是 Platform 開始出現的原因。不是因為 Reader 不夠用了，而是單純管理 Reader、Controller 與 Door，已經無法處理場域日益複雜的營運程序。

ACCESS CONTROL 在高科技廠房已經走得很前面

ODATA 在哥倫比亞 Bogotá 的 BG01 Data Center 使用 C‧CURE 9000，系統管理員工、承攬商與訪客，高安全區採 Smart Card 加 Fingerprint 多因子驗證，同時又與 BMS、消防、影像及其他建築系統整合。

如果只看設備，它仍然叫 Access Control；但從營運角度來看，它其實已經是「哪些身份可以依據什麼資格進入哪些區域」的管理平台。

台灣高科技產業也不是沒有相同邏輯。台積電公開資料顯示，承攬商的數位職安訓練紀錄，會直接連動門禁管制及施工單申請，高風險作業承攬商必須完成訓練並通過測驗，施工資格才會生效。

這已經很清楚說明：Access 不再只是門，而是資格與程序最後的一道執行點。

不過高科技廠房是一個進入門檻高、供應鏈高度集中、專案資格要求嚴格的市場，這裡只作為一個印證，暫不深入坦討。

真正可能讓更多台灣業者立即產生市場聯想的，反而是另外兩個場域。

零售：一家公司有 100 家店，是 100 套門禁，還是一個 Access Network？

零售是很適合觀察 Access Platform 的市場。

一家店的門禁並不複雜，兩家店也不複雜；但當企業有 50 家、100 家、300 家店，問題就變了。

店員每天異動、店長輪調、外包清潔進場、物流人員補貨、維修廠商臨時進機房；某些門市還有倉庫、高價商品區、藥品區、現金管理區與企業辦公區。這時候真正困難的，不是「裝哪一支 Reader」，而是所有人的 Identity 與 Authority 如何一致管理。

第一個重點：多據點需要的是中央身份與權限，而不是每一家店各管一套

美國 Meijer 擁有近 300 個零售據點。它採用 Genetec Security Center 集中管理所有 Supercenter、四個大型 Distribution Center、Healthcare site 與 Corporate Office，並整合 POS、Intrusion、EAS 等系統；近年又持續將 Synergis Access Control 擴展到不同據點。

這裡的平台價值，不只是總公司可以看到所有門。

更重要的是「公司」取代「單店」成為管理單位。

如果一名員工由 A 店調到 B 店，真正合理的程序應該是身份/職務異動後，Access Authority 跟著改變，而不是由 A 店記得把卡刪掉，再請 B 店重新設定一次。

當據點數增加，Access Control 自然從 Device Management 變成 Identity Management 的延伸。

第二個重點：零售 Access 開始直接介入營運程序

Price Chopper/Market 32 的案例更明顯。它有 132 個據點，OnGuard 不只管理總公司與門市，還涵蓋 Warehouse、Data Center、店內與獨立藥局。

尤其藥品管理最能說明 Platform 為什麼會產生。

配送中心的管制藥品儲存區採 Two-man Rule，必須兩名具有資格的人員同時在場才能進入；店內藥局也不是「員工有卡就可以進」，而是必須有 Pharmacist(藥劑師) 到場刷卡之後，其他較低權限員工才可以進入，甚至連藥局開門營業的程序都與 Pharmacist 的身份連動。

這已經不是普通的門禁功能。它實際上是把：身份 → 職務資格 → 程序 → Access 做成系統規則。

原來需要靠主管、SOP 或人工檢查執行的程序，開始交給平台自動判斷。

那台灣零售呢？台灣並不是沒有技術能力。

市場上已有廠商提供集中式 Access Server，可以管理員工、訪客、考勤與不同門點；台灣 Access Control 業者也普遍具備群組、時區、梯控、黑白名單、事件與不同身份的權限管理能力。

但是目前公開可查的資訊裡，比較少看到大型台灣零售連鎖企業公開說明：

HR/人員系統 → 店別 → 職務 → 班表/時段 → 倉庫/後場 → Access Authority 已經形成一個完整平台。

這不代表沒有，而是這類應用不像國際案例那樣被清楚整理、產品化與公開。

這反而留下了一個值得觀察的市場空間。

台灣有便利商店、超市、量販、藥妝、服飾、餐飲、3C 與大量連鎖服務業。如果 Access Control 供應商仍然把每一家店看成「兩道門、四道門、八道門」的案子，市場自然很小；但如果開始把一整個連鎖體系看成一個 Access Network，問題就完全不同。

設備數可能不是最大的市場，但平台一旦進入企業營運流程，黏著度、擴充性與長期服務價值都會跟著改變。

這也是為什麼零售場域，可能比高科技廠更值得台灣中小型 Access Control、智慧鎖、軟體與 SI 業者注意。

飯店：大家都知道電子鎖，但房門只是 Access 的一部分

飯店是另一個很有意思的市場。

談飯店門禁，大家第一個想到的一定是電子房鎖。飯店電子鎖甚至比很多企業門禁更早普及，因此很容易產生一種印象：飯店的 Access Control 已經沒有什麼新的東西可以做。

但如果從住客入住的程序重新看一次：

Reservation → PMS → Guest Identity → Room Assignment → Credential → Elevator/Room/Amenities → Check-out

就會發現電子鎖其實只是最後一個執行設備。

第一個重點：Guest Identity 一旦和 PMS 串聯，房卡就不再只是「Key」

Vingcard 的飯店案例顯示，當旅客完成 Check-in 後，PMS 依住房資料產生或傳遞住宿身份，Access Management 再把這些資料轉換成旅客可以進入哪些 Room、Floor 或 Authorized Area 的權限。

這件事的核心不是「手機可以開門」。

而是：

PMS 已經知道「這個人是誰、住哪一間房、住到哪一天」，Access Platform 不需要重新建立另一套身份，而是直接把住房程序轉換成 Access Authority。

Check-in，Authority 生效；換房，Authority 改變；延長住宿，時間延長；Check-out，Authority 失效。

Access 開始成為飯店營運流程的一部分。

第二個重點：飯店其實有兩條不同的 Access Chain

住客只是飯店裡其中一種 Entity。

客房管理、餐飲、工程、保全、行政、外包維修、供應商與臨時人員，都有另外一套 Access Requirement。

澳門 City of Dreams 的案例就能看到這種差異。Gallagher Command Centre 管理約 1,700 道門與 44,000 名 Cardholder，並與 HR、Elevator、Electronic Key Management 以及 Hotel Guest Locking System 整合。

換句話說，大型飯店或 Resort 很可能同時存在：

Guest Access Chain 以及 Staff / Contractor Access Chain

住客的 Authority 從 PMS 來；員工的 Authority 則可能來自 HR、部門、職務與排班。

兩套最後都進到「誰在什麼時間可以進什麼地方」。

這也是為什麼飯店 Access 不能只看電子門鎖。

台灣其實已經開始具備這種結構

Klacci 凱樂奇 Kii Assistant 智慧酒店服務系統

這一點台灣比零售更容易看到。

台灣已有飯店管理與門鎖系統，可以把住房管理、發卡、公共門禁與電梯樓層管制結合在一起；飯店 PMS 業者也早已提供 Door Lock、Room Control、Kiosk 等第三方串接。

這表示台灣並不是沒有「Hotel Access Platform」需要的技術元件。

真正值得往後觀察的，反而是這些 PMS、電子鎖、自助入住、公共門禁、梯控與 Staff Access，會不會從一項項 System Integration，逐漸形成可複製的飯店 Access Solution。

這也是另外一篇可以深入研究的題目。

台灣可能不是缺平台，而是平台還藏在 Project 裡

看到這裡，如果直接下結論說「國外有平台、台灣沒有」，恐怕並不公平。

台灣大學的大型校園門禁已經做到 3,500 道門、8 萬張卡、一套系統多人分散管理，並與卡務及住宿系統整合；台北大巨蛋商辦可以看到員工 Card、訪客 QR Code、Turnstile、Elevator Authority、時間有效性與 Restricted Area 的串聯；大型科技廠則早已把承攬商資格與門禁程序連動。

所以台灣真正值得思考的問題可能不是：「我們做不做得出 Platform？」

而是：「我們做過的這些 Project，有沒有被整理成可以複製的 Platform 或 Vertical Solution？」

台灣很多 Access Control 廠商、SI 與軟體商長期都有客製能力。一個客戶要求接 HR，就接 HR；下一個客戶要求接 Visitor，就增加 Visitor；第三個客戶要求梯控，再完成梯控。十年下來，其實累積了很多平台需要的功能。

但如果每一個案子完成之後，下一個案子又重新開始，這些能力仍然只是 Project Experience。

國際案例讓我們看到的另一個方向，是把這些經驗逐步變成某一個場域可以重複使用的 Solution。

CEM AC2000 Airport 為什麼會出現 Airport 版本？就是因為機場多年來反覆出現相同的營運要求，最後把 Passenger Segregation、Airbridge、Check-in Desk、Temporary Cardholder 等流程變成產品功能。

飯店的 Access Management 也是同樣邏輯：PMS、Guest、Room、Credential、Check-in、Check-out，本來都是一次次的整合工作，最後逐漸成為 Hospitality Access Platform 的標準能力。

零售未來會不會也走到這一步？

醫院、校園、物流、住宅物業會不會各自長出不同的平台？現在也許還不用急著回答。

Access Control 的下一步，可能會由場域自己回答