一、業(yè)務(wù)背景與系統(tǒng)定位醫(yī)院場景下的零售消費(fèi)需求與普通商超有著本質(zhì)區(qū)別。用戶群體高度集中且流動(dòng)性低消費(fèi)需求高頻且品類相對(duì)固定同時(shí)受到嚴(yán)格的院內(nèi)管理和補(bǔ)貼制度約束。傳統(tǒng)商超ERP系統(tǒng)無法適應(yīng)這種特殊場景需要一套從底層架構(gòu)上適配醫(yī)院數(shù)字后勤邏輯的解決方案。好伙獅數(shù)字食堂的數(shù)字商超模塊正是基于這一需求設(shè)計(jì)。它不是一個(gè)獨(dú)立的零售系統(tǒng)而是嵌入在智慧醫(yī)院數(shù)字后勤平臺(tái)中的一個(gè)業(yè)務(wù)模塊與食堂點(diǎn)餐、病房訂餐、進(jìn)銷存管理、后廚食安等模塊共享用戶認(rèn)證、支付清算和數(shù)據(jù)中臺(tái)。本文將從系統(tǒng)架構(gòu)、關(guān)鍵模塊設(shè)計(jì)和技術(shù)實(shí)現(xiàn)要點(diǎn)三個(gè)維度梳理這套方案的核心技術(shù)邏輯。二、系統(tǒng)整體架構(gòu)好伙獅數(shù)字商超采用分層架構(gòu)設(shè)計(jì)自下而上分為基礎(chǔ)設(shè)施層、業(yè)務(wù)中臺(tái)層、應(yīng)用服務(wù)層和用戶交互層四個(gè)層級(jí)。基礎(chǔ)設(shè)施層承載統(tǒng)一的部署環(huán)境支持公有云SaaS和本地私有化兩種模式。對(duì)于數(shù)據(jù)安全要求較高的醫(yī)院系統(tǒng)支持將核心業(yè)務(wù)數(shù)據(jù)和用戶信息部署在院內(nèi)服務(wù)器上僅將非敏感的服務(wù)請(qǐng)求路由至云端。業(yè)務(wù)中臺(tái)層是整個(gè)系統(tǒng)的核心。包含以下幾個(gè)關(guān)鍵中臺(tái)服務(wù)統(tǒng)一用戶中心——患者、家屬、職工三類用戶基于同一套認(rèn)證體系管理。職工通過工號(hào)或人臉識(shí)別完成身份綁定患者通過住院號(hào)或床頭碼關(guān)聯(lián)賬戶。同一用戶在醫(yī)院不同場景下的消費(fèi)行為被統(tǒng)一記錄形成完整的用戶畫像。統(tǒng)一支付引擎——對(duì)接微信支付、支付寶、院內(nèi)餐卡、人臉支付等多種支付方式。同時(shí)管理職工的多賬戶錢包體系包含餐補(bǔ)額度、福利余額、自費(fèi)余額等不同資金池根據(jù)消費(fèi)場景智能匹配扣款優(yōu)先級(jí)。商品與庫存中心——管理商超SKU信息、價(jià)格策略、庫存狀態(tài)。支持百貨類商品和散稱生鮮類商品的分組管理庫存變更事件通過消息隊(duì)列實(shí)時(shí)同步至前端展示層和訂單服務(wù)。訂單與配送調(diào)度——處理線上商超訂單的全生命周期下單校驗(yàn)庫存、生成揀貨任務(wù)、分配配送人員、追蹤配送狀態(tài)、完成簽收確認(rèn)。配送調(diào)度算法基于科室位置和訂單優(yōu)先級(jí)進(jìn)行智能匹配。補(bǔ)貼與福利引擎——這是整體系數(shù)最高也最能體現(xiàn)院內(nèi)場景特色的一個(gè)模塊。管理補(bǔ)貼的發(fā)放、使用、核銷和結(jié)算全鏈路支持按部門、按崗位、按時(shí)段的差異化補(bǔ)貼策略支持食堂和商超的跨場景消費(fèi)路由。應(yīng)用服務(wù)層封裝了門店零售、線上商超、福利商城、運(yùn)營后臺(tái)四個(gè)主要業(yè)務(wù)應(yīng)用向管理端和用戶端暴露標(biāo)準(zhǔn)化的API接口。用戶交互層覆蓋小程序患者/職工端、POS終端門店收銀、Web管理后臺(tái)和移動(dòng)配送端四個(gè)觸點(diǎn)。三、關(guān)鍵技術(shù)設(shè)計(jì)3.1 多業(yè)態(tài)商品管理模型院內(nèi)商超一個(gè)顯著特征是百貨和生鮮兩種業(yè)態(tài)在同一門店內(nèi)并行。從數(shù)據(jù)模型角度標(biāo)準(zhǔn)百貨商品走固定SKU管理屬性集相對(duì)簡單商品編碼、條形碼、規(guī)格、售價(jià)、庫存量。生鮮類商品則多了一層計(jì)重邏輯售價(jià)是動(dòng)態(tài)的由單價(jià)乘以稱重重量計(jì)算得出。對(duì)應(yīng)的數(shù)據(jù)模型設(shè)計(jì)思路是將商品基礎(chǔ)屬性和業(yè)態(tài)擴(kuò)展屬性解耦。核心商品表存儲(chǔ)通用信息通過商品類型字段關(guān)聯(lián)不同的擴(kuò)展表。訂單創(chuàng)建時(shí)根據(jù)商品類型路由到不同的計(jì)價(jià)引擎——預(yù)包裝商品直接使用固定價(jià)格參與計(jì)算稱重商品的最終價(jià)格在揀貨稱重環(huán)節(jié)回填到訂單中。3.2 庫存實(shí)時(shí)同步機(jī)制線上線下的庫存一致性是影響用戶體驗(yàn)的關(guān)鍵。商品庫存的每次變更——線下POS銷售、線上訂單鎖定、退貨回庫、入庫補(bǔ)貨——都需要實(shí)時(shí)反映到所有前端。技術(shù)實(shí)現(xiàn)上采用事件驅(qū)動(dòng)架構(gòu)。庫存中心的每一次變更操作都會(huì)產(chǎn)生一個(gè)庫存變更事件通過消息中間件發(fā)布。前端展示層、訂單服務(wù)、管理后臺(tái)等多個(gè)消費(fèi)者訂閱該事件各自維護(hù)一份最終一致的庫存視圖。線上商超頁面顯示的庫存數(shù)通過WebSocket推送更新確保用戶看到的始終是最新狀態(tài)。對(duì)于高并發(fā)秒殺類場景如限時(shí)福利商品方案采用Redis分布式鎖配合庫存預(yù)扣機(jī)制下單時(shí)先在Redis中預(yù)扣庫存并設(shè)置短時(shí)間過期支付成功后確認(rèn)扣減超時(shí)未支付則回補(bǔ)庫存。3.3 餐補(bǔ)跨場景消費(fèi)路由這可能是整個(gè)方案中最具差異化價(jià)值的技術(shù)設(shè)計(jì)。核心問題可以抽象為一個(gè)用戶擁有多個(gè)資金賬戶餐補(bǔ)、福利、自費(fèi)在多個(gè)消費(fèi)場景食堂、商超中發(fā)起交易時(shí)系統(tǒng)如何自動(dòng)選擇最優(yōu)的資金扣款路徑。解決方案的核心是一套可配置的消費(fèi)路由規(guī)則引擎。管理員在后臺(tái)定義規(guī)則模板每條規(guī)則包含觸發(fā)條件消費(fèi)場景、商品類別、時(shí)間段等、匹配的資金池優(yōu)先級(jí)列表、以及是否允許組合支付。用戶發(fā)起支付時(shí)系統(tǒng)實(shí)時(shí)解析當(dāng)前交易上下文匹配適用規(guī)則生成扣款計(jì)劃。以下是補(bǔ)貼消費(fèi)路由的簡化配置示例// 智能補(bǔ)貼消費(fèi)路由配置 { route_rules: [ { rule_id: R001, name: 食堂消費(fèi)優(yōu)先餐補(bǔ), condition: { scene: [canteen_scan, canteen_order], merchant_type: canteen }, fund_routing: [ { wallet: meal_subsidy, priority: 1 }, { wallet: welfare_balance, priority: 2 }, { wallet: self_pay, priority: 3 } ], allow_split: true, monthly_cap_check: true }, { rule_id: R002, name: 商超日用品優(yōu)先餐補(bǔ), condition: { scene: [supermarket_scan, supermarket_delivery], category: [daily_necessities, grocery, festival_gift] }, fund_routing: [ { wallet: meal_subsidy, priority: 1 }, { wallet: self_pay, priority: 2 } ], allow_split: true, monthly_cap_check: true } ], global_config: { subsidy_priority: true, order_timeout_seconds: 300, retry_on_failure: false } }當(dāng)用戶完成支付時(shí)交易引擎記錄下每一筆扣款的資金池來源和金額月末自動(dòng)生成按部門、按資金池維度的消費(fèi)報(bào)表替代了傳統(tǒng)的手工Excel對(duì)賬流程。3.4 院內(nèi)配送調(diào)度模型院內(nèi)外賣的配送場景和城市外賣有一個(gè)根本區(qū)別配送范圍被限制在院內(nèi)樓棟之間距離短但路徑復(fù)雜。電梯等候、科室管制、樓層分布等因素都需要納入調(diào)度考量。系統(tǒng)采用基于約束的訂單-配送員匹配算法。配送員在線狀態(tài)、當(dāng)前位置所在樓棟樓層、當(dāng)前待配送訂單數(shù)量、預(yù)計(jì)完成時(shí)間構(gòu)成配送員畫像。當(dāng)新訂單產(chǎn)生時(shí)調(diào)度引擎計(jì)算每位可用配送員對(duì)該訂單的服務(wù)預(yù)估時(shí)間選擇最優(yōu)匹配。估時(shí)公式綜合考慮距離、樓層差、電梯等候時(shí)間和訂單處理耗時(shí)。整個(gè)調(diào)度過程無需人工干預(yù)系統(tǒng)自動(dòng)派單。四、實(shí)施部署要點(diǎn)數(shù)字商超系統(tǒng)的部署需要關(guān)注幾個(gè)關(guān)鍵環(huán)節(jié)。硬件層面門店端需要配備收銀終端、條碼掃描設(shè)備、電子秤生鮮稱重和標(biāo)簽打印機(jī)。收銀終端運(yùn)行定制版POS應(yīng)用通過局域網(wǎng)與后端服務(wù)通信支持?jǐn)嗑W(wǎng)離線模式下的本地緩存交易。網(wǎng)絡(luò)層面院內(nèi)配送涉及樓棟之間的信號(hào)覆蓋。如果醫(yī)院占地面積較大或存在信號(hào)盲區(qū)需要提前部署WiFi覆蓋或?yàn)榕渌徒K端配備4G通信模塊。數(shù)據(jù)遷移層面已有商品庫存數(shù)據(jù)通過批量導(dǎo)入工具完成初始化。職工賬戶信息通過對(duì)接醫(yī)院HIS或人事系統(tǒng)同步患者信息通過對(duì)接住院管理系統(tǒng)獲取。好伙獅數(shù)字食堂提供標(biāo)準(zhǔn)化的數(shù)據(jù)接口和ETL工具鏈降低對(duì)接成本。上線流程建議采用分階段灰度發(fā)布策略先在單個(gè)科室或單個(gè)門店試運(yùn)行一周驗(yàn)證線下收銀和線上配送流程的穩(wěn)定性再逐步擴(kuò)展至全院。福利商城模塊可稍晚于基礎(chǔ)商超模塊上線給職工群體預(yù)留適應(yīng)過渡期。五、總結(jié)與展望院內(nèi)數(shù)字商超在技術(shù)視角看本質(zhì)上是一套多業(yè)態(tài)零售管理與智能補(bǔ)貼核銷的復(fù)合系統(tǒng)。它的難點(diǎn)不在單一功能的實(shí)現(xiàn)而在于如何在保持系統(tǒng)彈性的前提下將多個(gè)差異化的業(yè)務(wù)場景整合到統(tǒng)一的架構(gòu)中讓數(shù)據(jù)流動(dòng)順暢、讓用戶體驗(yàn)一致、讓管理決策有據(jù)可依。好伙獅數(shù)字食堂在這方面的實(shí)踐表明基于微服務(wù)架構(gòu)的中臺(tái)化設(shè)計(jì)、事件驅(qū)動(dòng)的庫存同步機(jī)制、可配置的智能補(bǔ)貼路由是支撐院內(nèi)一體化消費(fèi)服務(wù)落地的有效技術(shù)路徑。隨著消費(fèi)數(shù)據(jù)沉淀和用戶畫像的持續(xù)豐富后續(xù)在個(gè)性化推薦、智能補(bǔ)貨預(yù)測、動(dòng)態(tài)定價(jià)策略等方面還有大量優(yōu)化空間。如果你也在做類似場景的系統(tǒng)設(shè)計(jì)歡迎在評(píng)論區(qū)交流技術(shù)細(xì)節(jié)。