淺談「SIPOC模型法」於產品開發流程分析的運用 - 以教育遊戲設計為例

理想教育遊戲應具備的三大要素：教育、擬真、好玩

我過去的工作經驗當中，恰好有幾年的時間在協助客戶進行「商業流程改善（Business Process Improvement）」。專案中常被用來分析並改善流程的「SIPOC模型法」，我覺得也非常適合於產品設計中，用來作為分析、理解使用者情境（User Scenarios）或 UI 操作流程的工具。在設計《UX in the Jungle》這款教育遊戲時，我便運用了「SIPOC模型法」來解構、建構產品開發流程，所以設計出來的桌遊角色與機制能與真實情境相符，並讓玩家更有「代入感」（也就是玩家融入於遊戲角色並對其遭遇的情節感同身受的程度）。

「SIPOC模型法」是品質管理學大師戴明博士（William Edwards Deming, 1900–1993）所提出的流程建構及分析方法，常是商業流程改善及組織設計、再造的首選工具。「SIPOC」這個名字其實是由這個方法中五個關鍵要素的英文字字首所組成的：Suppliers（供應者）、Inputs（輸入）、Process（流程）、Outputs（輸出）及Customers（客戶）。有些人為了強調「以客戶為導向」的概念，把同樣的方法倒過來拚為「COPIS」，但兩者的實際內涵其實都是一樣的。

SIPOC (Supplier, Inputs, Process, Outputs, Customers) 模型法的元素

Suppliers（供應者）指的是提供素材以供流程執行的人或組織。Inputs（輸入）指的是由供應者提供的資訊、材料或其它資源。Process（流程）指的是將輸入轉化為輸出的一組活動。Outputs（輸出）指的是流程執行後所得到的成果或產物。Customers（客戶）指的是接收流程成果或產物的人或組織。

SIPOC 裡的「客戶」不限僅指公司或組織外的客戶，也可以是公司或組織內的其他人或部門。反之，「供應者」亦然。例如：參考 UI Spec 寫程式的 Developers 是 UI Designers 的內部客戶，而反過來，UI Designers 也是 Developers 的內部供應者。另外，同一個流程可能會有多個輸出（如：主產品、副產品）。分析流程時，通常會依照各項輸出能替客戶創造價值的能力高低來判定主要及次要輸出。理論上，只要是理性的人或組織，都會透過提高執行流程的效率（Efficiency）或改善流程的效能（Effectiveness）來最大化能產生給客戶的價值。

運用「SIPOC模型法」，我們能夠很快地建構出組織或系統的運作方式，並讓對相關領域不熟悉的受眾也能在短時間內快速地對其中的流程有一定的熟悉程度及大局觀。更棒的是，我們能夠在不破壞大局觀的情況下，視需要調整流程的「精細度」或「粒度（Granularity）」 — 將部分流程分解地更細緻，但仍清楚地展示組織及各流程的界限。

應用 SIPOC 的方法

在軟體開發或 UX/UI 的研究及設計中，有許多方法都需要以圖像、視覺方式呈現不同系統互動或使用者情境，如：System Context Diagram、Use Case Diagram、User Journey Map、User Flow Chart 等等。如果分解系統或使用者情境時都能夠活用 「SIPOC 模型法」建構、解構流程的概念，要適當切分圖表中的階段（Phases）、實體（Entities）、步驟（Steps）並畫出關係清楚、讓人容易理解的圖表就不會是太難的事。

我在設計《UX in the Jungle》時，將它定位為一款模擬軟體產品開發過程的教育遊戲。遊戲中希望讓玩家在一個小時內，扮演公司裡的 UXer ，並透過研究市場需求、開發產品的過程，在有限的時間裡替公司賺大錢。為了確保遊戲擬真，便反覆地運用「SIPOC模型法」進行流程的建構及解構以確保設計出的遊戲符合真實的情境。

產品開發的過程要如何模擬並轉化為桌上遊戲呢？

我是這樣做的：

階段一：確認流程的「目標（Objectives）」

目標就是執行流程所希望得到的具體成果或產物。玩家在《UX in the Jungle》的遊戲中的「目標」是幫所屬的軟體公司賺大錢。而賺錢的方法則是將研發出的產品賣給客戶以獲得利潤。

階段二：列出達成目標時的 SIPOC 各項元素

a.) 列出達成目標時的「最終輸出」與「最終客戶」（O 與 C）

最終輸出：銷售產品所獲得的「利潤」。最終客戶：玩家在遊戲中所扮演的「軟體公司」（其實就是玩家自己）。

先列 O 與 C 的原因是：這樣可以讓我們有機會以終為始地快速檢驗流程的目標是否可以達到。

b.) 列出達成目標所必要的「關鍵輸入」與其「供應商」（I 與 S）

關鍵輸入有兩個：一是對產品的不同「需求」，另一個則是可以滿足不同需求的「產品」；而兩項關鍵輸入的供應商則分別是：提供「需求」的「用戶」，及提供「產品」的「研發團隊」。

平常「客戶」的角色都是「用戶」在當，但是這樣分析下來，「用戶」在遊戲裡的角色其實會變成「供應商」。

c.) 列出達成目標所需的「主要步驟」（P）

在《UX in the Jungle》的遊戲中，玩家扮演公司裡的 UXer 角色，若要為公司創造利潤的話，必須完成以下步驟：

1: 瞭解(用戶的)需求

2: (協助研發團隊)開發產品

3: 販售產品(給符合需求的用戶以獲得利潤)

階段三：找出「主要步驟」中最關鍵的行動，並命名該流程

三個主要步驟中各有其動詞，包括：「瞭解（需求）」、「開發（產品）」跟「販售（產品）」。其中能達成目標的最終行動是「販售（產品）」。所以流程最適合命名為「販售產品」。

階段四：挑選流程中的其他「主要步驟」，並重複前述三個階段的操作，將流程往下展開至所需要的精細度。

在《UX in the Jungle》中，「開發產品」可以再往下拆解成「設計產品規格」、「撰寫軟體程式」、「測試產品品質」等三個子流程；而「設計產品規格」也還可以再進一步拆解成「釐清使用情境」、「確認互動設計」、「確認視覺設計」等第三階的子流程，並同樣以「SIPOC模型法」找出流程中的相關元素。

應用「SIPOC模型法」解構產品開發流程的範例（僅列出流程的元素）

第 0.1 版的《UX in the Jungle》

剛接下設計《UX in the Jungle》的任務時，我只有一個周末的時間可以完成桌遊雛型的設計，所以雖然知道透過「SIPOC模型法」反覆分析就可以建構出詳細的產品開發過程，但仍決定只將遊戲機制的設計限制於模擬最粗淺的第一階流程，以便簡化並縮短製作雛型所需的時間。

以 UXer 的角度來看，「開發產品」這件事最簡化的第一階流程就是將「產品」與「需求」兩種輸入進行配對以完成「販售」。「販售」成功時可以獲得利潤，失敗了就只好重來一次。

聽到這邊，不知道大家的腦海裡是不是跟當時的我一樣，浮現出了《UX in the Jungle》第 0.1 版的遊戲樣貌？

我拿了一副撲克牌，取 13 張紅心，以牌面向下的方式隨機擺放當作「需求卡」，再取 13 張黑桃，同樣以牌面向下的方式隨機擺放作為「產品卡」。接著，讓每位玩家輪流在兩組卡片中各翻看一張進行配對。翻看需求卡就代表「瞭解需求」，翻看產品卡就代表「開發產品」。若翻看、配對的兩張卡片數字相符，就算成功完成「販售」 — 玩家可以保留兩張卡片，並以牌面上的數字作為販售產品所獲得的利潤（分數），若配對失敗，就得把卡片以牌面向下的方式放回原位。

是的！除了計分方式稍有不同外，規則幾乎就跟卡片遊戲裡常見的「配對/記憶遊戲（Matching / Memory Game）」一模一樣啊！

我不會說這是一款「好玩」的遊戲，但是透過這樣的流程解析後設計出的遊戲機制，應該也讓人很難說它不具備任何「擬真」的效果。若遊戲由有歷練的講師來引導討論並分享實務經驗，相信也能達到一定程度的「教育」效果。

《UX in the Jungle》在開發初期時的產品雛形

然而，這第 0.1 版的《UX in the Jungle》雖然是個完整的遊戲了，充其量卻只能算是個「可用產品（Working Product）」，還不算是個「最簡可行產品（Minimum Viable Product）」。因為，當下的設計雖然符合「遊戲」的定義，過於簡單的機制卻讓玩家不能在遊戲中感受到我們想傳遞的核心體驗 — 感受真實的產品開發過程。

不過，有了「可用產品」，我們就可以透過讓客戶（或出錢的老闆）實際體驗產品來瞭解他們對產品的確切想法，並在之後以迭代的方式，漸次改善產品的使用者經驗。而對當時只有一個禮拜時間的《UX in the Jungle》四人小組來說，我們也有了一款樣貌具體且「擬真」的桌遊可以參加研討會講者甄選！

想知道更多細節以瞭解《UX in the Jungle》如何由簡單的遊戲演變成以 180%達成率完成集資目標並成功發行的教育遊戲嗎？歡迎追蹤本帳號以閱讀我分享更多關於產品服務創新、敏捷專案管理或用戶體驗設計的心得或文章。謝謝！