mcpField
E
ecosystem-map-and-blueprint

ecosystem-map-and-blueprint

github.com/timlai666Design & UI075 installsUpdated 2d ago
Repository

About ecosystem-map-and-blueprint

A design skill for creating and reviewing ecosystem maps and service blueprints, used in production, teaching, and workshops. It distinguishes participant relationships and exchanges from the timed activities and handoffs involved in service delivery, while recording evidence and items needing confirmation.

Key features

  1. 01Show participants and their exchanges
  2. 02Map the sequence of service delivery
  3. 03Align frontstage, backstage, and support work
  4. 04Record evidence, assumptions, and gaps
  5. 05Check handoffs, exceptions, and validation

Use cases

  1. 01Create a service ecosystem map
  2. 02Build or review a service blueprint
  3. 03Prepare diagrams for cross-team process discussions
  4. 04Explain service structures in teaching or workshops

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/timlai666/skills --skill ecosystem-map-and-blueprint

After installing, type/ecosystem-map-and-blueprintin Claude Code to confirm it loaded.

Bundled filesreferences/ecosystem-map.mdreferences/service-blueprint.md

Details

From the project README

生態系地圖與服務藍圖

Overview

讓服務中的參與者、資訊與工作在適當的時點配合。生態系地圖呈現「誰在系統內、交換什麼」,服務藍圖呈現「如何協同交付服務」。可用於製作、審查、教學與工作坊。

Input Contract

從需求與既有材料辨識:

  • 要回答的問題、服務範圍,以及分析現況或設計未來方案。
  • 中心參與者或使用者類型、流程起訖與主要接觸點。
  • 可用的旅程、訪談、作業文件、既有圖與資料來源。

已有資訊不重問。缺少會改變圖型或範圍的資訊才先確認,其餘可先做草稿並標示假設。現況與未來方案須分清楚,不能把建議的流程寫成已經存在。

Workflow

1. 選工具並讀對應方法
需求工具與必讀文件
釐清複雜議題、參與者、人與系統關係、價值交換讀取 生態系地圖方法與案例
釐清服務時序、前後台、支援流程、部門交接或低效環節讀取 服務藍圖方法與案例
同時需要全局關係與交付流程兩份都讀,通常先生態系地圖再藍圖。已有可用地圖時沿用並核對

只需一種圖時不用載入另一套教材。教學與審查也依討論的圖型讀取完整方法和案例,不因只談接觸點就要求使用者先說工具名稱。

2. 建立有依據的圖

依對應方法完成參與者、關係或時間序列,補上交換內容、負責角色及交接方向。沿用使用者指定的格式與圖例。圖面須能對照材料,假設和未知要在相關節點或連結旁標清楚。

先用現有材料建立草稿,再列出待確認事項、適合確認的角色與所需證據。跨部門人員或領域專家尚未參與時,不妨礙產出草稿,但不能宣稱已完成協作驗證。

3. 診斷缺口並驗證

找出遺漏角色、價值交換、等待、交接斷點及例外流程。說明受影響者、發生條件與依據。改善時先考慮能否減少多餘工作或簡化交接,再評估自動化、科技或跨界合作的必要性。例如食物銀行合作處理剩餘食材須核對需求與交接條件,不能只以 ESG 名目判斷有效。

正式作為共同作業或改造依據前,須由相關部門、利害關係人與必要的領域專家核對責任、流程與遺漏元素。可採共同工作坊或分別確認,不強制所有人同時到場。取得確認後更新原圖,服務改變時也須同步更新。

Output Contract

製作任務交付可閱讀的圖或結構表,附範圍、圖例、資料依據、缺口與待確認事項。審查任務指出問題所在節點或關係及修改方式。教學以對應方法和案例說明,不虛構組織已完成驗證。

依下列完整清單驗收選用的圖型。每項都要檢視,記錄「已確認」「待確認」或「不適用及理由」。資料不足必須列為待確認,不能當成不適用或已完成。案例專屬的名稱與情境不強制套用,分析面向不得省略。

生態系地圖完整檢查清單
  • 中心參與者與服務範圍明確。
  • 人、組織、地點、系統逐類檢視,相關參與者均已納入。
  • 資訊、貨品、金錢、勞力逐類檢視,每條相關交換標出內容及方向。
  • 依同心圓或功能分區,分區依據與中心視角一致。
  • 已檢查關係缺口與合作機會,圖例能區別既有關係和待驗證連結。
  • 已記錄跨部門與專家確認結果,未確認者列出問題、對象及證據缺口。
服務藍圖完整檢查清單
  • 使用者類型、旅程步驟、起訖與接觸點已核對。
  • 使用者行為、前台、後台、支援流程與服務證據五層逐層檢視,並對齊時間步驟。
  • 互動線、可視線、內部互動線三條分界清楚且分類正確。
  • 真人與數位互動均已檢視。存在的科技接觸點完整納入,並判斷是否須獨立 Tech Layer。
  • 後台活動、責任與交接完整。
  • 內部支援、第三方系統與外部合作逐類檢視。金流與 Email 系統只在相關時納入。
  • 箭頭清楚表示互動、資訊或工作交接方向,跨層連結沒有遺漏。
  • 流程缺口與改善機會已檢查,例外或錯誤流程有註記、分支或另圖連結。
  • 每一步的實體與數位服務證據已檢視並對應,未知處清楚標示。
  • 已記錄相關部門與專家的驗證結果或待確認事項。

Quality Rules

  • 完整性按選定服務範圍與證據判斷,不靠填滿案例名稱或把所有項目勾選來宣稱完成。
  • 不用部門名稱代替具體活動,不把支援流程限定為公司外部系統。
  • 保留主流程與例外的關聯,避免為了圖面簡短刪去重要交接。
  • 圖例可調整,但箭頭方向、可見性、缺口與確認狀態的意義必須一致。

Comments

Markdown supported