館別經理
目標
館別不缺東西，也不壓庫存。
模組
- PMS
- 庫存
- 入住、房態與帳務都在PMS裡——那是前台的系統，不是Platform的畫面。
- 打開館內現有庫存：布巾、備品與工務物料還剩多少。
- 依下一期的預估住房率開補貨申請，直接送到集團採購。
- 登錄房務部與工務部當天的實際耗用。
- 把設備報修轉成工單，費用記回這間館別。
一個邏輯業務核心
PMS營運住房旅程，共用核心支撐企業營運。
PMS與企業模組各有產品負責方和使用體驗，同時共用集團營運所需的業務資料層。
1
前台 · PMS + 館內 POS
- 訂房與旅客資料
- 房況、房價與可售狀態
- 櫃檯、入住與退房
- 房務、帳單、館內 POS 與通路串接
2
共用Platform Core
- 租戶、公司與主檔資料
- 館內庫存與耗用
- 採購與供應商
- 財務紀錄與企業分析維度
3
企業管控 · Apus Platform
- 集團採購與庫存
- 財務與多館別報表
- 人力、排班與共享服務
- 資產、專案與管理控制
當PMS是貴公司自己的系統或其他供應商的系統時
上面三欄描述的是同一個邏輯業務核心：前台若是Apus提供的PMS，這點由架構直接成立；換成其他系統，則透過串接成立。下列四件事在設定作業開始前確定。
- 標準資料與歸屬系統：住宿、旅客資料、房型與服務代碼歸PMS；品項、供應商與會計科目歸Platform。
- 資料通路與寫入權限：API、週期性匯出檔，或是唯讀複本——依貴公司實際在跑的系統決定，因為它決定報表能有多新。
- 串接紀錄與確認：每次交接都留下狀態，是已接收、已對帳，還是仍掛起。沒有紀錄會悄悄消失。
- 入帳前的控制合計：住宿收入、收款與差異必須對上，數字才進入集團報表。
第一欄的PMS可以是貴公司已經在用的系統、其他供應商的系統，也可以是Apus提供的PMS——交接點相同，差別只在串接工作量。通路與合作夥伴串接屬於PMS營運範圍；實體拓樸依每次部署確認。
營運斷點
當每個館別都成為資料孤島，集團就失去管控能力。
01
館內需求未進入採購
耗用與申請必須在後勤系統重複輸入。
企業管控
把實際營運需求帶入共用庫存和採購紀錄。
02
費用與財務口徑不同
住房活動與會計脈絡往往事後才拼接。
企業管控
設計受控的PMS—財務交接，不另建平行帳冊。
03
集團視角支離破碎
人力、資產與館別績效使用不同維度。
企業管控
以共用公司和主檔資料支援企業報表。
營運的一天
一間館別的一天，也是集團共用職能的一天。
訂房、前台與帳務由PMS營運。從館別提出需求那一步起，庫存、採購、人力與財務就跑在共用紀錄上。
集團採購
目標
多間館別買同一樣東西，就當成一個客戶去談。
模組
- 採購
- 供應商
- 把各館別的申請依品類彙整，而不是一間飯店一間飯店分開處理。
- 依已簽的框架合約比價，並依收貨館別分別開採購單。
- 追蹤交貨，在送出付款之前把採購單、驗收單與發票核對一致。
- 依對各館別的準時率與交貨品質為供應商評分。
- 看全集團依品類的支出，為下一輪議價做準備。
人資與共用服務
目標
各館別旺季錯開時，班別與人力能互相調度。
模組
- 人力資源
- 班別與共用服務
- 依館別、依部門打開人力結構，看哪裡正缺人。
- 依預估住房率排班，系統提示缺人的班與重複排班的人。
- 在兩間館別之間臨時支援人力，費用跟著使用方走。
- 結算差勤與班別津貼，轉交財務時不必再敲一次表。
- 追蹤共用單位的工作量，知道每間館別各佔多少。
集團財務
目標
整個投資組合用一套數字，而不是一疊各自為政的報表。
模組
- 財務
- 營運分析
- 依約定的交接，從PMS接收已結的收入與結算資料——不另建平行帳簿。
- 把營運費用、採購與人力成本歸到對的館別與共用的分析維度上。
- 在資料進入管理報告之前，先處理對帳後的差異。
- 在同一套科目上合併多館別、多法人的結果。
- 比較同一級別館別之間的表現，找出偏離標準的那一間。
PMS負責前台旅程，POS負責館內交易；Apus Platform承載共用紀錄、採購、人力、財務與報表。產品之間的交接點依專案設計。
導入路徑
明確設計館別到企業的每一次交接。
- 01
劃分產品責任
區分PMS前台與Platform企業作業的負責方。
- 02
約定共用主檔
定義公司、館別、品項、供應商、財務與人力維度。
- 03
小範圍驗證交接
在選定館別測試庫存、採購和財務流程。
- 04
依證據逐步拓展
處理例外和控制問題後，再推展至整個集團。
部署拓樸可能不同，上線也可能需要系統整合、資料移轉或切換工作。
最適合
適合兼顧館別效率與集團控制的旅宿組織。
飯店集團
保留館別營運節奏，同時統一共用紀錄與控制。
多館別營運商
跨據點串接採購、庫存、人力與財務。
複合式旅宿事業
把住房旅程接入共享服務與企業報表。
跨國飯店集團以集團貨幣合併收入，而稅務與開立發票仍依各國規定執行。 依市場查看
控制關卡
上線前先回答三個問題。
01
互動由哪個產品負責？
讓PMS前台體驗與Platform企業體驗各自歸屬明確。
02
哪些紀錄需要共用？
定義每類主檔和交易脈絡的權威系統與寫入權限。
03
如何證明交接完成？
約定狀態、例外、對帳與復原證據。
一個邏輯核心描述業務連續性，不代表通用實體拓樸，也不承諾零停機切換。
常見問題
釐清PMS、PMS與Platform。
我們已經在用另一套PMS，必須更換嗎？
那套PMS繼續承擔前台的角色。Apus Platform位於它之後接收交接，所以專案要做的是搭出一個串接點，而不是替換正在運作的系統。串接工作量會針對貴公司實際的系統做調研，並在方案設計階段確定，沒有現成的隨插即用套件。
PMS是Platform模組嗎？
不是。它屬於獨立應用家族，但與Platform企業模組使用相同的邏輯核心和業務資料層。
如果現有PMS沒有開放API怎麼辦？
調研會確認那套系統用哪條通路釋出資料：API、週期性匯出檔，或是一份唯讀複本。每種選擇都決定對帳節奏與報表的新鮮度，因此在設定之前就要定下來，而不是之後。
用Apus的PMS和用其他供應商的PMS有什麼不同？
交接點是一樣的，差別在工作量。Apus提供的PMS本來就站在同一個邏輯核心上，單據不必搭橋就能往下走；外部系統需要一個受控的串接點，而這座橋要在雙方每次改版時持續維護。
哪些能力仍屬於Platform？
共用公司與主檔、庫存、採購、財務、人力、資產、專案和企業報表屬於Platform旅程。
一個核心能保證零停機上線嗎？
不能。架構、整合、資料移轉與切換皆依實際專案設計。