物业经理
目标
物业不缺东西，也不压库存。
模块
- 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旅程。
一个核心能保证零停机上线吗？
不能。架构、集成、数据迁移与切换均按具体项目设计。