如何建立蒐資藍圖 — 數據產品規劃工作紀錄
數據產品專案經驗紀錄，規劃流程分享
當初收到一個任務，因應數位轉型，需要描繪客戶行為的蒐資藍圖，把所有可能產生的行為資料都收入藍圖中，以建置整合性資料底層。那是一個數據產品專案，中間面臨了一些困難 EX: 公司規模龐大、業務複雜，應該要從哪裡開始、如何能真正能落地應用，而不是畫畫餅…等，到後來順利的完成，把過程記錄下來與大家分享。
描繪蒐資藍圖
我把過程大致收斂成 4 個階段
一. 釐清蒐資目標
也就是為什麼需要蒐集資料，期待的效益為何？
客戶資料蒐集的範圍很廣、種類多、取得管道多，規劃的方法內容可以有很多種版本，先有目標後，較容易聚焦目標效益去做規劃。
EX: 這次的藍圖是希望可以提供給集團使用，能透過一個藍圖，了解整個子事業體的業務全貌，也就是須涵蓋所有可能的行為，包含已發展成熟或發展中的業務，而取得管道也是盡可能的完整。
二. 尋找合適的理論框架
知道目標後，需要一塊大餅，那時選擇有理論基礎的框架 + 配合產業特性做微調，像保險價值鏈、消費者心理模式AISAS…等都是我參考的理論，幫助我描繪出我可以蒐集哪些面向的資料。
這個步驟我認為很重要，框架本身有過去研究的基礎，能幫助我們思考的比較全面，公司內部業務是逐一發展逐一完整，若跳過這個步驟直接蒐集現有業務資訊，可能會因為業務發展成熟度不同導致藍圖不完整或被困在既有的業務模式中。
三. 釐清業務全貌與業務流程
有了大餅後，需要填料，這時就會需要理解公司哪些業務及流程可以產生我們需要的行為，而哪些又是公司內部資料不足，需要第三方協助搜資。身為一個小螺絲釘，公司業務龐大且複雜，要怎麼做呢？
公司內有很多資源都有蛛絲馬跡，而我當時從一些整合性的資源開始。
- 公司組織架構圖：可以了解一間公司的全貌，看完就會知道公司有哪些業務，接著逐一去了解
- 系統、網頁、APP：逐一了解各業務時，我會先看看系統，那些通常是有多年業務經驗後，整合而成的，會很接近業務的全貌，包含業務有哪些分支，每一個分支的流程是什麼。另外還有一個好處，通常會被系統化的都是較成熟且重要的業務，而且肯定會留下資料 (畢竟最終目標是想搜資，總是得有資料哈)。
- 業務部門相關說明文件：當收集完上述資訊，發生看不懂的狀況，可以翻翻部門的業務說明文件或是想辦法拿到新人訓練的資料，這些對了解業務有很大幫助。
四. 描繪出完整藍圖
有大餅也有料之後，接著就是組裝了，是一段laddering的過程。
- 攤開業務資料並分群：把前步驟的流程拆解成各個節點，把相似的流程收歛成群並命名。EX: 某個服務申請流程為，收件、登打、受理完成、覆核、審核、產生結果、寄送通知。可以收納並命名為服務受理、服務審核、服務結果，
- 塞到大框架中並調整細緻度：那些分群結果就會成為大框架的子分類，在把他們放到對應的構面上 EX: 服務受理、服務審核、服務結果可被放在 “售後服務” 的框架中，整個藍圖大致就完成了。最後可以在檢視各構面的顆粒度是否需要調整 EX: 部分構面的流程是否過細或過粗。
- 定義框架規則：最後的框架會長成一個樹狀圖 (示意如下)，每一層都應該要有定義，才不會隨著時間演進、經手人的不同，而讓框架越來越歪。
過程中我會注意的事…
語言轉化
如果是在大公司，那藍圖可能會 report 給很多人，主管、團隊、其他部門同事…等等各種不同背景的人，我會盡可能將過於理論的詞彙轉成行話，讓大家都能夠理解。
正確理解業務
過程中我不會自己拍腦袋想，而是會和各業務單位討論，確認對業務理解正確，才不會導致後續執行上困難。
藍圖需保留彈性
藍圖完成後都會有套分類規則，但應用需求、業務都是會改變的，所以規則不能太死。我的作法是，整個框架有三層，分別是客戶行為階段、行為、行為內容，階段不會調整，然後行為、和行為內容是可以做調整的 (這也會跟後續資料結構的設計有關，有興趣在另外開一篇文說明)，這樣不會讓藍圖隨時間變得四不像，也能保留彈性。
先小規模測試
在整個過程中，其實是來來回回反覆修正的 EX: 先描繪其中一個構面，內部討論、主管討論、相關單位討論，來回確認邏輯可行。且在做了一個版本出來後，在描繪其他構面時，有個範例大家比較容易想像。最後，如果過程中有需要大調整時，也才不會需要整個打掉重練。
要畫出一個藍圖不難，但要畫出一個實際好執行的藍圖，要考量的細節和要做的討論真的不少，過程真的蠻困難也很複雜，我盡可能地將過程梳理在文章中，如果有疑惑或有建議的也歡迎跟我分享 :D
