3S Market 探討報導
Access Control 平台在社區住宅，是 Nice to Have 或 Best to Have？
Audience Target
住宅社區管委會、物業管理公司、保全業者、建設公司、智慧建築與弱電系統業者、Access Control 廠商、系統整合商，以及正在思考既有社區設備更新的相關業者。
Highlights
- 社區住宅的 Access Control，不應只理解成「開門」，而是管理住戶、租客、訪客、外送、裝修、維修、物業、保全等不同 Entity 的 Identity、Permission、Time 與 Activity。
- 住戶、管委會、保全、物業四種角色，需要的不是同一套功能；平台的價值，在於把四方流程與權限串起來。
- 老社區不是不能導入 Access Control 平台，關鍵在既有設備是否可整合，以及能否採分階段更新，而不是一次全部汰換。
- 台灣已經有業者從智慧鎖、門禁、智慧建築、社區 App、物業服務等不同方向往 Residential Access Control Platform 發展，但「有 Solution」和「已有大量部署案例」不能畫上等號。
- 住宅社區最大的導入障礙，往往不只是技術，而是住戶共識、預算、個資與治理問題。因此現階段用 Best to Have，可能比直接稱為 Must-Have 更符合市場現實。
半夜一個陌生人走進社區，現在到底誰知道他是誰？
住宅社區每天都有大量不同身分的人進出。
除了屋主、租客與家人，還有訪客、宅配、外送、清潔人員、居家照護、房仲、裝修工人、機電維修商、物業人員與保全；到了地下停車場，又多了一個「車輛」身分。
問題並不只是：門能不能打開？
而應該進一步問：這個人是誰？誰允許他進來？他能去哪裡？可以停留多久？權限什麼時候失效？發生異常時，誰知道、誰判斷、誰處理？事後有沒有紀錄可以追溯？
如果這些答案仍然分散在警衛登記簿、住戶電話、感應卡、對講機、電梯控制器、車道設備，以及不同廠商各自獨立的管理軟體裡，那麼社區即使安裝了不少「智慧設備」，仍不代表形成了真正的智慧管理。
這正是 Access Control 平台開始值得討論的地方。
Nice to Have、Best to Have，還是 Must-Have？
如果從一般英文商業用語來說，Nice-to-Have 對應 Must-Have 最自然。
但是放到住宅社區，目前直接說 Access Control 平台是 Must-Have，恐怕太快。
因為住宅社區與工廠、企業總部非常不同。
企業可以由管理者制定公司 Policy；住宅社區添購公共設備，卻往往涉及管委會、區分所有權人、公共基金、住戶使用習慣、施工干擾、老人與小孩操作方式，以及個資與隱私等問題。
有些住戶會問：
「原來的感應卡不是還可以用嗎？」
「為什麼要花這筆錢？」
「老人家不會用 App 怎麼辦？」
「為什麼一定要做人臉辨識？」
「我的進出紀錄誰可以看到？」
「換了這一家，以後是不是就被這個廠商綁住？」
所以住宅社區的設備更新，本身就是一項「治理」。
這也是為什麼本文選擇 Best to Have。
它不是宣稱：沒有 Access Control 平台就不行。
而是在問：
當住宅社區的身分、設備、流程與管理責任越來越複雜時，它會不會逐漸成為最值得優先配置的一項管理能力？
社區 Access Control 管理的其實不是門，而是「關係」
傳統門禁管理很容易被簡化成：刷卡正確 → 開門。
但是到了平台層次，真正管理的應該變成：
這個 Identity，在這個 Time，對這個 Boundary，有沒有這個 Permission？
例如 A 棟 8 樓的住戶，可以經過社區入口、A 棟梯廳、地下停車場，搭乘電梯到 8 樓，也可以使用社區健身房。
但是他未必有權限進入 B 棟住宅樓層、機電室或管理室。
裝修工人的權限則完全不同。
例如：
星期一到星期五，在規定施工時間內，由指定入口進入，只能搭指定電梯，到指定樓層；工程期限結束，Access Permission 自動失效。
清潔、維修、照護甚至宅配，也都可以依身分、區域與時間給予不同權限。
因此完整的住宅 Access，應該逐漸形成：
Entity → Identity → Authenticator → Access Request → Authentication → Authorization → Permission → Access → Activity → Traceability。
這就已經不是一台 Reader 或一個 Controller 可以完整代表的事情。
住戶、管委會、保全、物業，需要的不是同一套功能
Access Control 平台如果只是把很多讀卡機集中在同一個畫面，價值仍然有限。
真正的平台，至少必須處理四種角色的需求。
角色 | 平台應發揮的主要功能 | 真正效益 |
住戶 | 卡片、手機等身分驗證；訪客授權；臨時通行；對講與遠端開門；電梯、公設、停車權限 | 生活便利，同時不用把所有事情交給管理室人工處理 |
管委會 | Identity、Access Policy、公共區域規則、承攬商管理、事件紀錄、稽核 | 把設備管理提升成社區治理 |
保全 | 訪客確認、失效憑證、門未關、異常進入、事件告警與 SOP | 從大量人工登記，轉向真正的異常事件處理 |
物業 | 入住、退租、搬家、裝修、維修、清潔、公設、設備維護與多社區管理 | 降低大量重複行政作業，並建立交接與追溯 |
這也是為什麼住宅平台不能只從「門禁設備」角度來看。
一個住宅社區，其實有很多道 Boundary
住宅大樓至少存在：
社區邊界 → 棟別邊界 → 電梯/樓層邊界 → 公共設施邊界 → 住宅戶內邊界。
地下停車場則另外形成車輛 Access。
當系統加入住戶 App、遠端開門、訪客授權、雲端管理之後，又增加了一個經常被忽略的：Virtual Access。
例如：
誰能進入社區平台後台？
物業總公司可以看到多少住戶資訊？
保全能不能查閱所有人的通行紀錄？
管委會成員是不是任何時候都能查詢某一住戶的出入資料？
所以完整的住宅平台，最後管理的並不只是：Physical Access，
而會逐漸變成：
Physical Access × Virtual Access × Identity × Authority。
Access Control 平台自己，也需要被 Access Control。
老社區能不能裝？真正問題不是屋齡
二十年、三十年的住宅社區，可能同時存在傳統感應卡、RS-485 控制器、舊式對講、獨立電梯控制，以及不同年代的停車設備。
但這並不代表不能平台化。
比較實際的方式，往往不是：全部拆掉，重新建一套。
而是從幾個層次逐步更新。
首先，可以先整理社區大門、側門、地下停車場等公共 Access Point。
接著盤點原有 Controller、Reader、電鎖是否可以保留。如果既有系統太封閉、原廠已停止支援或沒有整合介面，再更新控制層。
之後才逐步加入電梯樓層權限、訪客管理、裝修與承攬商管理，最後視個別社區需求延伸到住宅戶內。
所以老社區改造最大的問題，往往不是：房子幾年了？而是：原來的系統到底開不開放？
老社區真正難的，是四件事
第一是 Interoperability。
Controller、對講、電梯、車道與其他設備採用什麼通訊方式？原廠是否提供介面？能不能和新平台交換資料？
第二是既有的網路與線路。
第三是預算與住戶共識。
第四則是資料與隱私治理。
尤其當社區開始導入人臉辨識，更不能只把「免帶卡」當成全部價值。
個資主管機關過去在針對公務機關使用人臉影像的函釋中指出，臉部影像具有高度人別辨識特性，並強調蒐集是否必要、是否存在侵害較小的替代方式，以及資料使用的告知等問題。該函釋的直接適用情境雖是戶政機關，但其中對生物辨識資料必要性與替代方案的討論，對住宅社區評估人臉門禁同樣具有參考意義。
因此住宅平台不應預設：智慧化＝全社區都必須改用人臉。
卡片、手機、QR Code、密碼或其他 Authentication 方法，本來就可以依不同使用者與不同場景並存。
台灣有人做嗎？先區分「正在發展」與「已有實績」
目前台灣並不是沒有住宅 Access Control 平台相關業者。
但是這裡必須先區分一件事：官網有住宅 Solution，不等於已經有大量住宅專案部署。這兩件事不能混為一談。
中保好生活：由社區服務與物業平台往 Access 延伸
中保好生活目前公開的平台功能，已經包括郵務、包裹、門禁與通行、訪客管理、AI 對講、卡片設定、管理費、公設、報修、公告與用戶管理等。
其官網目前稱服務超過 6,000 個社區、覆蓋超過 30 萬戶家庭。這代表的是另外一條平台發展路線：不是從 Controller 起手，而是先掌握住戶與物業工作流程，再逐步把 Access 放進平台。
WAFERLOCK：從智慧鎖、門禁往「一條龍」整合走
市場對維夫拉克的觀察，是這家公司一直希望由智慧電子鎖往更完整的住宅「一條龍」服務發展。
從目前官方產品架構，也確實可以看到這個方向。
其 LiveAM 已不只是電子鎖管理，而是雲端門禁管理系統，公開列出的整合內容包括公共門禁、電子門鎖、電梯控制、信箱電子鎖與智慧櫃，並明確把中大型與小型住宅社區列為適用市場。
另一套 eHome 則由住宅對講切入，整合門禁、監視、電梯、電器與物業相關系統，並可進一步與 LiveAM 結合。
因此 WAFERLOCK 在本文比較適合被定位為：
已經具備完整住宅平台產品方向，而且產品線明顯朝「從戶內到公共區域」整合。
但是如果討論「台灣到底已經有多少住宅社區完整部署 LiveAM＋eHome」，公開資料目前仍不足以讓本文下這個結論。
立承：方向很清楚，但實際住宅部署仍應和 Solution 分開看
立承有發展住宅社區相關解決方案的跡象，從展覽中呈現類似的議題。
事實上，目前立承官方網站已經明確把「社區生活」列為智慧建築平台的主軸，方案包含手機開門、一鍵呼梯、刷卡、QR Code 訪客、人臉門禁、社區雲對講、物業管理與停車場管理。
倬茂：不只 Solution，官網已有海外社會住宅案例
倬茂目前官網已經將「社會住宅」獨立列為解決方案，內容涵蓋住戶、訪客、管理人員不同身分權限，以及時段、區域、卡片異動與遠端管理。
更值得注意的是，倬茂官網另外公開了一個 Social Housing Access Control Project。
依其案例說明，倬茂協助一家匿名的 B 企業開發 Access Controller 與 RFID Reader，與 B 企業管理平台整合，用於社會住宅的住戶 Access 管理。倬茂表示該方案符合歐洲相關規格，之後進入歐洲市場，並被多個大型住宅專案採用。
這裡必須特別說清楚：
這是倬茂官網自行公開的海外案例，而且是歐洲社會住宅，不是台灣一般集合住宅案例。
社會住宅在住戶流動、補助資格與公共資源管理方面，也有不同於一般私人住宅社區的管理需求。
但至少它提供了一個具有參考價值的實際案例：Access Control 如何由單純的進出控制，延伸到 Identity、Permission、Activity 與住宅營運管理平台之間的整合。
台灣住宅 Access Control 市場，正在出現兩條路
從目前看到的市場，可以粗略整理出兩條路。
第一條：智慧鎖/Reader/Controller → 電梯/對講 → Access Platform
WAFERLOCK、倬茂以及部分傳統 Access Control 業者，比較接近這個方向。
另一條則是：社區 App/物業管理 → 住戶服務 → 訪客 → Access
中保好生活等智慧社區服務平台，比較接近這一端。
立承這種具有系統整合能力的業者，則可能位於兩條路線中間。
真正值得觀察的是：
這兩條供應鏈會不會逐漸接在一起？
因為完整的 Residential Access Control Platform，最後很可能不是由單一設備決定，而會落在：
Resident Identity × Access Permission × Property Workflow × Security Response的交會點。
所以，它究竟是 Nice to Have，還是 Best to Have？
如果是一棟戶數不多、單一入口、訪客量有限，而且人工管理仍然有效的小型住宅，Access Control 平台完全可能仍只是：Nice to Have。
不需要為了平台而平台。
但是當一個社區開始出現多棟別、多地下層、多入口、大量租戶、大量訪客、公設增加、裝修頻繁、外包廠商多、保全輪班，以及物業公司同時管理多個社區時，問題已經改變。
這時候，把門禁、電梯、訪客、車道、對講、承攬商與事件紀錄繼續分開管理，所增加的就不只是工作量。還包括：責任斷點與管理落差。
所以 Access Control 平台真正的價值，不是讓住戶第一次看到手機開門時說：「好方便。」
而是整個社區開始能夠回答：
誰進來？
他是什麼 Identity？
誰 Authorization？
可以去哪裡？
什麼時候 Permission 失效？
出了異常誰處理？
事情過後能不能 Trace？
如果一套住宅平台只是把原來的感應卡換成人臉、手機或 QR Code，它大概仍然只是 Nice to Have。
但當平台真正開始把：
住戶、管委會、保全、物業，以及每天進出這個社區的不同 Entity
放進同一套管理邏輯時，它所扮演的角色就已經不同。它未必到了每一個住宅社區都非裝不可的 Must-Have。
尤其住宅設備更新，還必須通過住戶共識、預算以及不同生活習慣這一道關。
但是對越來越複雜的住宅社區而言：
Access Control 平台，會不會正在從 Nice to Have，走向 Best to Have？
這可能才是現在最值得市場開始思考的問題。
0 comments:
張貼留言