概念地圖・最小可行生態系
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
最小可行生態系：第一份交付缺誰就不成
自助餐團膳業者的試辦名單上有廚房、有送餐車，也有肯付錢的辦公室；中午到底由誰收餐，三方都以為已經有人答應。最小可行生態系把完整價值放在中央，沿著交付找出每一項必要活動與承諾。依 Ron Adner 的術語表，這個最小配置還得產生價值創造的證據，足以吸引新夥伴加入——第一批午餐的交接紀錄，要能換來下一棟大樓願意試辦。
最小配置要連起哪些承諾
先把午餐走完的路徑攤開，再把試辦結果送到誰手上寫清楚。每個方框都要有人接。
| 必要活動 | 這次由誰承擔 | 要留下的承諾或證據 |
|---|---|---|
| 備餐 | 既有廚房 | 按確認名單分裝，交車前核對份數 |
| 運送 | 業者自有車隊 | 在約定午餐時段送到指定收餐點 |
| 接收 | 辦公室窗口及代理人 | 窗口離開時仍有人點收、對名單、交到本人 |
| 訂單與結算 | 業者與辦公室窗口 | 使用既有名單及轉帳流程，留下可核對紀錄 |
| 下一位夥伴採用 | 另一棟大樓的行政窗口 | 看過交付結果與交接安排後，承諾加入下一次試辦 |
這裡的「小」落在活動配置上。同一業者可以同時備餐、開車、對帳；拆成更多公司也不會自動增加價值。真正要保住的是完整路徑，以及新夥伴看得懂的證據——只把飯送到大樓門口，還沒走到用餐者答應付錢的那個結果。
談夥伴以前先把交付拆開
一、先定終端使用者的完整價值。辦公室員工需要在有限的午休內吃到自己訂的午餐。菜色、送達時段、辨認餐盒、收餐位置，都會影響這份承諾。若團隊只寫「提供便當」，每一方都可能交出自己認為完成的部分。可以先用價值主張設計釐清用餐者最想省掉哪一段麻煩，再決定試辦保留哪些活動——初期範圍窄一點，價值仍要完整。自問：終端使用者要拿到什麼結果，才會認為這次承諾已經兌現？
二、逐項活動找出能兌現的人。廚房願意試做，並不會讓辦公室午休時自動有人站在門口。把到場時間、接收位置、誰對名單、臨時離開由誰代理，逐一寫進試辦安排。每一個交接都由前後兩端確認，負責人也得知道自己承擔多少額外工作。尤其「行政會處理」這種寫法太寬——請把當天接電話的人名補上。自問：每項必要活動由誰負責，對方已承諾何時、如何完成？
三、先問下一位夥伴要看什麼。另一棟大樓的行政窗口可能最擔心午休被佔滿、員工領錯餐、自己一請假就沒人接。第一次試辦因此要記錄問題發生在哪個交接，修正後再保留結果。帶去談的資料包含份數、如約交付紀錄、代理安排，並請窗口說明願意接下哪一班——證據必須對得上對方的疑慮。自問：什麼價值創造證據，會讓下一位必要夥伴願意承諾加入？
自助餐團膳試辦如何換來下一份承諾
底下這家台灣中部的自助餐團膳業者，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。
- 先縮到一個午餐時段：找一個辦公室試辦，廚房照名單備餐，自有車輛運送，辦公室窗口接收並核對姓名，付款沿用現有轉帳。先不開發 App，把有限準備時間用在交接。原有資源足以啟動。
- 第一次暴露接收缺口：共收到24份訂單，21份如約交到用餐者，另3份因收餐窗口臨時離開而晚交。車子有到、飯也備好了，那3位員工的午休仍被打亂——晚交原因必須跟著餐盒一起記錄。門口多等一段，價值就少一截。
- 補上可接手的人：業者和辦公室約定代理窗口，讓代理人也取得當日名單與接收時間。正職窗口離開前要通知代理人，司機找不到人時有第二個聯絡對象。把「有人會收」改成可執行交接。
- 第二次保留完整紀錄：下一次試辦有26份訂單，26份全數按約完成。團隊整理交接時間、名單核對與代理安排，把第一次的失誤及修正一併交代。新一輪結果有自己的分母。
- 拿結果換來下一位夥伴：另一棟大樓的行政窗口看過兩次試辦結果與交接紀錄，確認代理機制後，承諾加入下一次試辦並負責召集訂單與收餐安排。有了明確接手事項，生態系才往外長。
這個配置留下了兩種互相接得上的資訊：用餐者實際拿到什麼，以及新窗口為什麼願意投入。第一次24份中的3份晚交，指向的是接收環節；第二次26份全數完成，提供修正後的一輪證據。新窗口把這些資料帶回自己的工作安排，才答應下一場試辦——這份承諾讓小規模交付具有擴展用途。單次全部按約完成仍不足以保證長期穩定，接下來要觀察更多班次、不同窗口及異常情況。此處也沒有推算獲利，訂單先用來檢驗價值能否傳到使用者、證據能否傳到夥伴。以上為說明結構用的示意情境，僅供理解框架之用。
依賴網什麼時候會騙你
- 把自己的公司擺中央，只列熟人名單。老闆跟廚房熟、跟辦公室主管熟，就容易以為資源已齊。沿著自己的關係畫圖，會把真正的收餐人擠到邊緣。請從員工拿到餐盒的那一刻倒推，必要角色可能從未參加過合作會議——沒有被邀進群組的人，也可能握著交付的最後一段。
- 把口頭意向當成現場承諾。「歡迎來試」通常只准許開始談；窗口是否能在固定時段接收、是否有代理人，仍要逐一確認。若團隊把一句好意填成綠燈，第一班車就會幫大家驗出差距。確認時請對方重述當天要做的動作，並記下遇到異常要找誰——這張圖的每條線都會占用某個人的時間。
- 只收客人的讚，漏掉夥伴的負擔。員工覺得午餐方便，行政窗口可能因此每天多花一段時間處理名單與漏餐。試辦結束若只問好不好吃，就會把這筆投入藏起來。下一位窗口值得看的資料，也包括需要多少協調、誰處理例外、工作如何分攤——客人滿意之後，還要追到夥伴願意持續接下哪件事。
有價值的證據，要有人願意接
一個沒人認領的交接，會把所有人的準備一起停在門口。
從《痛點》的 P.A.I.N. 來看，用餐者等待的那幾分鐘、窗口被打斷的那幾通電話，都值得追到具體的人。這張圖畫得出午餐交付的依賴，畫不出每個人為此吞下多少麻煩。尤其新窗口一旦答應加入，就把試辦移進了自己的日常工作；他在意的可能是請假時誰接手，團隊卻一直介紹菜色。價值創造的證據要同時讓使用者看見承諾兌現，也讓夥伴看見自己能負擔的參與方式。多一次合作意向沒有多大說服力，具體接下一班的收餐工作才有重量——今晚拿最近一次交接紀錄，挑一個曾經等待的人，請他描述當時卡住的兩分鐘，再把修正安排交給下一位窗口確認。
最小可行生態系，常見問題
最小可行生態系跟最小可行產品差在哪裡？
最小可行產品常用早期產品版本取得有意義的使用者回饋，幫助後續改進。最小可行生態系把活動與夥伴的配置也納入，並追問交付產生的證據能否促成新夥伴承諾。午餐菜色得到好評後，這張圖還會追到另一棟大樓的行政窗口：他看了哪些結果，答應負責哪些工作？兩個問題可以在同一次試辦裡一起檢驗。
全部活動由自己的公司做，還能用這個框架嗎？
可以先從完整價值需要哪些活動畫起，同一家公司可以兼任備餐、運送與結算；公司數量少並不直接證明配置最小。若未來擴展需要辦公室窗口投入，就得說明眼前的自建活動會產生哪些證據，讓新窗口願意加入。自建能先補上缺口，也可能替日後的夥伴測出負擔，判斷仍要回到價值、依賴與加入承諾。
試辦全部準時交付，就代表生態系已經成立嗎？
一次全數按約交付提供的是當次條件下的證據，仍要追問必要活動是否有人持續承擔，以及新夥伴是否因這些證據答應投入。示意情境中，第二次26份全數完成後，還有另一棟大樓窗口確認交接安排、承諾參與的步驟。擴展後要持續觀察換人、增量與臨時狀況，保留失敗紀錄也能讓下一位夥伴做出較踏實的判斷。
夥伴答應的理由值得單獨攤開，生態系餅模型會把各方投入與所得放到同一張紙。接著可用它檢視各方的投入誘因與風險；若你接下來要估算支持營運所需的付費受眾規模，再把人數與收入放上另一張圖。
同一個概念，站上還有別的講法——
拆給你聽：車好騎、電站也夠多，為什麼還是推不動一個縣市？喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。