為甚麼院舍比較管理系統時，應先做一張選型評分表？
很多院舍在選型時，會先看示範、功能表或報價，再由不同部門各自說出喜歡與擔心的地方。這種做法最大問題，不是意見太多，而是所有意見都未必用同一把尺衡量。前線在意輸入是否方便，主管在意追蹤與覆核，行政在意資料匯出與對帳，管理層則在意導入風險與投資回報。若沒有共同評分框架，最終很容易只剩「感覺呢套順眼啲」。
選型評分表的作用，是把主觀印象轉回結構化比較。當院舍先把需求分類、訂出權重，再逐套系統按同一標準評估，團隊便更容易看清楚哪些是必需條件、哪些只是加分位，以及哪個風險會在上線後變成真實負擔。
- 把不同角色的關注點拉回同一套比較標準。
- 避免示範節奏主導判斷，令決策只憑印象。
- 及早看見培訓、權限與 rollout 風險，而不是簽約後才發現。
這張評分表應由哪些角色一齊完成？
最穩妥的做法，不是由單一部門代全院舍打分，而是由管理層、前線代表、行政或財務，以及未來導入 owner 一起完成。管理層負責確認導入目標與預算容忍度；前線代表負責指出記錄、交更與查閱的真實阻力；行政或財務補充報表、文件與資料匯出要求；導入 owner 則要把這些需求轉成可執行的上線安排。
如果院舍有醫療協作、藥務或跨院舍管理角色，亦可按需要拉入評分過程，但原則仍是一樣：每個參與者都應按自己真正會承接的工作場景評分，而不是單純對畫面好不好看發表意見。
- 管理層：定目標、定優先次序、定可接受風險。
- 前線代表：評估實際操作是否順手與可持續。
- 行政或財務：評估文件、報表、匯出與對帳安排。
- 導入 owner：判斷設定、培訓與 rollout 是否可落地。
評分項目應怎樣分組，先唔會變成功能大雜燴？
院舍最常見的錯誤，是把所有項目都寫成功能題，例如「有冇藥物功能」、「有冇報表」、「有冇手機版」。但真正影響導入成敗的，通常不只是有沒有，而是做得是否貼近流程、角色與管理需要。較實用的分法，是至少拆成五組：核心流程支援、角色與權限、培訓與易用性、管理追蹤與報表、以及導入與維護風險。
每一組再按院舍現況分配權重。例如現時最痛的是交更與護理記錄，就可把核心流程支援比重提高；若院舍已知道最大風險在敏感資料與主管覆核，就應提高角色與權限的權重。權重的價值，不是令分數看起來更科學，而是逼團隊先講清楚自己最不能出錯的是哪一段。
- 核心流程支援：是否貼近入住、交更、護理、藥務、收費等實際工作。
- 角色與權限：是否支持分層查閱、修改、匯出與覆核。
- 培訓與易用性：新同事上手難度、前線日常操作負擔、例外情況處理。
- 管理追蹤與報表：主管是否看得到進度、異常與待辦累積。
- 導入與維護風險：設定複雜度、試點安排、後續調整成本。
比較系統前，院舍要先整理哪些內部流程，否則分數會失真？
如果院舍連自己最常卡住的工作線都未整理清楚，評分表很容易流於空泛。較好的做法，是先挑三至五條最重要的流程做基本盤點，例如院友入住、班次交更、護理記錄、藥物跟進、覆診安排或主管抽查。每條流程至少要寫清楚資料由誰開始、在哪裡交接、哪一步需要覆核，以及最後由誰依據資料作決定。
這樣做的原因很直接: 同一套功能，放在不同流程成熟度的院舍，效果可以完全不同。若流程本身仍然含糊，團隊便很難判斷某套系統是在解決問題，還是把原本混亂的做法數碼化。
- 先界定高頻而且多人交接的流程。
- 標示每個步驟的輸入者、接手者與覆核者。
- 列出現時最常出現重複輸入、口頭補充或追資料的位置。
權限分層評分時，管理層最應問哪幾條問題？
權限設定若只問「可唔可以限制某頁」，通常太表面。院舍真正要評分的，是系統能否反映實際責任分工。前線應否只看自己需要的資料？班長或主管可否查看摘要並覆核關鍵更新？行政與財務是否只在需要的範圍內接觸資料？管理層能否看到趨勢與例外，而不用拿到所有細節？這些才是影響日常協作的核心問題。
另外，評分時也要留意變更紀錄與停用流程。因為院舍導入後最常出問題的，不是初次開權限，而是同事轉崗、兼任、離職或臨時支援時，系統能否清楚地加減權限、保留紀錄，以及避免把敏感資料長期暴露給不再需要的人。
- 角色是否可按查看、輸入、修改、匯出、覆核分層。
- 敏感資料是否可限制在必要角色範圍內。
- 權限調整、帳戶停用與變更紀錄是否容易管理。
- 主管是否能在不干擾前線的情況下掌握例外與進度。
為甚麼培訓成本都應該納入選型分數，而不是留待簽約後再算？
很多院舍在選型時只比較購買成本，卻低估了培訓與 adoption 成本。若系統要前線一次過學太多畫面、太多欄位或太多例外流程，即使功能再完整，實際使用率也可能上不去。對院舍而言，培訓成本不只是供應商上多少堂課，而是前線要花幾多時間上手、主管要花幾多時間覆核，以及新同事之後能否快速接上。
因此，評分時應把培訓拆成幾個實際問題: 是否可以按角色分批培訓？高頻場景是否容易先上手？試點上線後是否容易收集回饋並微調？如果答案不清楚，這套系統就算短期示範很好看，長期 adoption 風險仍然偏高。
- 能否按前線、主管、行政等角色分批培訓。
- 高頻任務是否可先學先用，而非一次過全學。
- 新同事之後能否用較短時間接上日常操作。
- 試點後的回饋整理與設定微調是否有空間。
分階段導入準備，應如何反映到最後決策？
一套系統值不值得選，不應只看功能是否齊，而要看首階段能否穩定落地。管理層在最後比較時，應特別看三件事：第一，哪幾條流程最適合先上線；第二，哪些角色最適合作為試點班組；第三，上線後首兩至四星期要靠甚麼機制收斂問題。若某套系統需要一次大規模改變所有流程才見效，對多數院舍來說風險通常較高。
因此，分階段導入準備不應只是實施期才處理，而是選型時已要納入分數。能夠容許院舍先由核心場景開始、再逐步擴大範圍的系統，往往比表面上功能更多、但 rollout 彈性較低的方案更實際。
- 首階段先上哪些高價值流程，而不是一次全上。
- 試點班組與回饋週期是否清楚可執行。
- 供應商與內部 owner 是否都知道甚麼情況要微調設定。
院舍下次選型會議，可直接用哪份對齊清單？
如果你想令下次比較會議不再停留在「呢個畫面幾靚」或「呢個功能好似幾多」，最有效的方法是把每個討論點都拉回同一張清單。當流程、權限、培訓、報表與 rollout 都能被逐項問清楚，團隊自然較容易得出一致判斷。
- 我們最想先改善的三條流程是甚麼？
- 這些流程涉及哪些角色，誰輸入、誰查閱、誰覆核？
- 哪些需求是必需，哪些只是加分項？
- 若要做試點，首階段由哪個班組或部門開始最合適？
- 前線、主管與行政各自的培訓負擔有多大？
- 權限調整、帳戶停用與後續維護會由誰承接？
“對院舍而言，真正可靠的選型方法，從來不是功能最多，而是最清楚知道自己為甚麼打這個分。”
