誠品｜影響×可行性矩陣 × 依賴/資源交換圖 × 治理機制

本頁是課堂討論用的 Wireframe：用兩個工具把「跨事業協作」變成可管理的設計： （1）影響×可行性矩陣協助做取捨； （2）依賴/資源交換圖把「誰需要誰」與「要交換什麼資源」寫清楚； 最後落到治理機制，確保能持續更新會員體驗與綜效，而不是做完一次就散掉。
示意範例｜僅供理解產出樣貌
以會員體驗與綜效定義「影響」
以資料/系統/人力限制定義「可行」
以治理節奏維持動態更新
顯示引導提示
複製本頁輸出草稿
下載輸入（JSON）
清空
主持人引導（以「管理機制」為落點）
FACILITATION
本場的主題句（預填示例）：
「跨事業協作的摩擦，不是靠口號解決，而是把協作做成『可管理的設計』：有取捨、有依賴、有資源交換、有責任鏈、有節奏。」
1
列候選協作方案（10–15 條）

每條要能落到會員旅程的一個斷點，並指出「預期影響」的理由。

提示別把「想做的功能」當方案；要寫成「修補哪一段旅程斷點」或「降低哪一種跨事業摩擦」。
2
用影響×可行性矩陣做取捨

影響：對會員體驗/綜效；可行：90 天內是否能驗證（資料、系統、流程、人力）。

提示可行性不是「大家想不想」，而是「依賴是否能被解除」與「資源是否有規則可交換」。
3
選出入選 3 案（90 天驗證）

每案先寫清楚：可驗證假設、主要依賴、交換資源、紅線、與 owner。

提示如果入選案「依賴太多」：先把它拆成 2–3 個可驗證子案。
4
用依賴/資源交換圖把「誰需要誰」畫清楚

畫箭頭＋寫資源：資料、流量、場域、內容、權益規則、作業人力、品牌合作。

提示同時畫出「尚未存在但可能形成綜效」的虛線交換，做為下一輪更新的候選。
5
設計治理節奏（動態更新機制）

至少包含：例會節奏、決策規則、資源投入規則、資料口徑與儀表板更新責任。

提示治理不是「開更多會」，而是縮短跨部門協調時間、降低反覆拉扯，讓更新成為慣例。
本頁含 localStorage 自動保存（僅在本機瀏覽器）。內容為示意，需以誠品提供的資料與現況校正。
影響×可行性矩陣
依賴/資源交換圖
治理機制（動態更新）
把承諾句寫成：會員可感知 + 內部可衡量 + 有時程。
影響 × 可行性（拖曳便條到象限）
DRAG
新增便條
顯示/隱藏「潛在」
既有可做（示例）
需要協作（示例）
資料/口徑（示例）
風險/成本（示例）
Impact（會員體驗 / 綜效）↑
Feasibility（90 天可驗證）→
高影響 × 低可行｜先拆解依賴
高影響 × 高可行｜優先入選（90 天）
低影響 × 低可行｜暫停/不做
低影響 × 高可行｜維持/順手做
APP 收藏 → 提醒 → 到店/到場 續接
修補「線上發現→線下體驗」斷點；不必全量系統整合。
旅程APP門市
會員事件最小資料集（口徑統一）
先定義「活躍/跨事業互動」事件，讓回算與追蹤成立。
資料口徑治理
券規則「少而清楚」＋成本上限
降低會員算不清的摩擦；也避免補貼成本失控。
權益成本
全量點數互通（所有事業）
影響可能高，但依賴多、成本回算與規則很容易失控。
風險高依賴
活動票夾 × APP（提醒/路線/核銷）
把「看到活動」變成「真的去到現場」，並形成可追蹤閉環。
票券活動
候選協作方案清單（可先討論再放進矩陣）
每條建議寫：修補哪段旅程 + 需要誰協作 + 90 天怎麼驗證。
新增一條

跨事業訊息一致化（同一個會員語氣）

例：APP/門市/活動的訊息像同一家公司說話；降低理解成本。

影響：中 可行：高

沉睡喚回：用「值得回來的理由」而非大量推播

例：以收藏/興趣做情境推薦；限制頻率；能回算。

影響：中 可行：中

門市作業減步驟：會員核銷/取票/兌換更順

例：把「問一圈」變成「掃一下」；避免增加現場負擔。

影響：高 可行：中
入選規則（建議）： 先從「高影響×高可行」選 2 案，再從「高影響×低可行」選 1 案（但必須先拆解成可驗證子案），總共 3 案對應 90 天。
先畫小一點，才能在 90 天內驗證與更新。
依賴/資源交換圖（可拖曳節點；虛線＝可能但尚未成形）
用途：把「誰需要誰」寫成箭頭，避免協作只停留在概念。
顯示/隱藏虛線
重排（示意）
觸點 / 場域（前台） 共享資產 / 能力（後台） 導流／提醒／會員身份 選品/書單/活動訊號 票夾/核銷事件 券/點數規則（少而清楚） 事件 → 指標口徑 品類社群 → 分群訊號（候選） 跨品牌共創（候選） OneEslite APP 收藏 / 提醒 / 會員身份 門市（書 / 生活） 體驗 / 選品 / 現場作業 活動 / 票券 票夾 / 核銷 / 到場 電商 / 物流 到貨 / 退換 / 成本 內容策展資產 書單 / 選品 / 活動編輯 會員事件最小集 活躍/互動/核銷口徑 權益規則（券/點） 適用範圍 / 成本上限 儀表板 / 追蹤 90 天代理指標 合作夥伴 / 品牌生態 共創活動、權益、導流（需治理與分潤規則） 分群 / 情境規則 不是硬推，是情境續接
From To 交換/依賴資源（要講清楚） 狀態 管理點（誰要負責）
APP 門市 例：導流、提醒、會員身份；到店後續接收藏內容 既有可做 例：Journey Owner（線上→線下）＋門市代表
門市 內容策展資產 例：書單/選品/活動訊號，讓 APP 的內容有一致口徑 需協作 例：內容編輯與店端窗口；資料欄位定義
權益規則 APP / 門市 例：券/點數適用範圍、成本上限、回算方式 高風險 例：財務/法務/產品共同仲裁；例外處理流程
活動/票券 合作夥伴 例：共創活動與權益（尚未形成）；需分潤與品牌治理 潛在 例：Ecosystem Office 設規則；單案試點
用法：每一條箭頭都要回答「交換什麼、誰負責、如何驗證」；否則就是「想像中的協作」。
核心觀念：治理不是把所有事都集中到一個單位，而是把「決策權、口徑、節奏、資源規則」設成慣例； 讓跨事業協作不需要每次重談一次。
節奏 會議/動作 目的（要產出什麼） 參與者（示意） 輸出物更新
每週 依賴清障 30 分鐘 例：處理跨單位卡點；更新「依賴/資源交換表」 Ecosystem Office + 方案 owner + 相關窗口 依賴表／風險清單
雙週 旅程績效檢核（短會） 例：看代理指標與會員回饋；決定下一輪優先修補的斷點 Journey Owner + 觸點 owner（APP/門市/活動） 旅程圖／矩陣（重新定位）
每月 仲裁與資源規則（SteerCo） 例：處理券/點數規則、成本上限、資料共享邊界等仲裁議題 事業主管 + 財務/法務 + Ecosystem Office 治理章程／決策紀錄
每季 生態圈綜效回顧 例：檢查綜效是否成立、是否公平；決定擴大/收斂合作範圍 高階主管 + 外部夥伴代表（如適用） 綜效假設／分潤原則
RACI（示意｜最小可行）
RACI
管理項目/產出物 A R C I
旅程圖（現況/目標） Journey Owner 觸點 owner 門市/活動/電商 相關主管
影響×可行性矩陣 Ecosystem Office 方案 owner 各事業窗口 全體與會
依賴/資源交換表 Ecosystem Office 依賴牽涉方 財務/法務/IT SteerCo
事件定義與口徑 Data Steward 資料工程/分析 產品/營運 全體
提示：RACI 不追求完美，但要避免「大家都負責＝沒人負責」。
動態更新迴圈（示意）
LOOP
更新迴圈（寫成慣例）：
1) 會員訊號（旅程/回饋/數據） → 2) 更新旅程斷點與假設 → 3) 矩陣重新定位（取捨） → 4) 更新依賴/資源交換（清障） → 5) 90 天小步驗證 → 6) 回算與學習 → 回到 1)
本頁的「Ecosystem Office / Journey Owner」命名僅供示意；可依誠品組織語彙調整。
已完成