如今，我們都非常習慣於在手機上進行支付，需要買什麼，掃一下碼就行了。那麼，你有沒有想過，整個支付的體系是什麼樣的呢？本文作者從方法論的角度，分析整個支付體系的運轉規律和設計方法，一起來學習一下吧。
收穫了大量實戰經驗以後，從中抽象出可被複用的方法，是自我升級的非常重要的過程，而所有方法又會在不斷的新的經驗裡被最佳化改進。
全文15088字，建議先收藏慢慢看。
一、支付的“三字真經”
經驗一旦形成了模型，它將引導你走出混沌。
有些我們非常熟悉的模型，“陰陽模型”反應事物的對立統一關係，“五行模型”反應事物間相生相剋的關係，還有一些其他的比如“12星座模型”“12生肖模型”“生辰八字模型”“Star模型”“smart模型”……等等，我們發現掌握了一個模型就意味著掌握了利用該模型的規律去洞察事物的優秀能力。
如果你掌握了五行相生相剋口訣，你就可以透過將萬事萬物按照規則標註其五行屬性，那麼你就知道這些事物之間是互利還是互斥的；有時候你是否會好奇，這些模型是怎麼形成的，由誰創造的……
我們也來抽象一個支付的模型：“事·賬·錢”，這三個字我們來用它來定義整個支付體系的運轉規律和設計方法。
1. 什麼是事，什麼是賬，什麼是錢？
我們將支付分成兩個體系：一個是隻有一個主體的“單支付體系”比如京東支付體系；另一個是由多個參與者組成的協同的複雜分層的“複合支付體系”比如中國支付清算體系（人行-網銀聯-銀行-三方支付-四方支付-企業），如圖1所示：
圖1 支付體系分類
這兩個體系我們都可以進行三層劃分。
1）事
如果說人生是一場旅行，那麼這場旅行本身就是一件事，旅途中每一次住酒店，每一次餐館吃飯，每一次手機充值，每一次晚上刷劇，這些都是一件一件的事情；在酒店前臺你用微信掃一掃支付了200元押金，在大廳的購物櫃你用支付寶掃一掃開啟櫃門拿出一瓶可樂，這也是一件一件的事；微信收到了你的掃一掃請求，給了你一個彈窗，你輸入了密碼點了確認，這也是一件一件的事。
什麼是“事”呢，我想就是基於你的意願形成了決策，並且付出了行動，得到了結果，這一個組合就是一個“大事”，這件事裡你的每一個眼神或者動作，每一次點選或者選擇，每一次開心或者悲傷，我想也都是“事”。那麼總有一件事，會引導你走向支付。
每一次“事”件的發生，都應該被記錄，你對女朋友的好與不好，會被女朋友記錄；你對別人的壞，會被上天記錄；同樣你那些觸發了支付的“事”也會被記錄；女朋友記得是“愛情的賬”，上天記得是“塵世的賬”，支付記得是“系統的賬”；女朋友會記到腦子裡，上天會記到雲彩裡，支付會記到“賬戶”裡！
所以說支付就是基於“事”記“賬”。
2）賬
支付的基礎是“賬戶”，銀行有銀行的賬戶，企業有企業的賬戶，人行有人行的賬戶；賬戶是資金的儲存，也是信用貨幣的基礎，也是現代支付的基礎；這些賬戶就是要記錄一次次的支付的“事”，比如記錄你在酒店前臺用微信付了200元押金這件事。
“事”是怎麼記錄到賬戶裡呢，首先我們要學會去定義“事”，就想我們去用“男女”定義“性別”，用“好壞”去定義“品行”；而對“支付事件”的定義，我們用“費用”，我們用“費用”去定義一件件發生的事情，或者說為一件件發生的事情去進行分類，只要知道了“費用”我們就知道了這是一件什麼“事”，也就是事件會產生費用。
所以說支付就是將支付的“事”產生的費用記錄到“賬”中。
3）錢
錢是個好東西，國家離不開錢，你我離不開錢，上班為了錢，創業為了錢……這個世界的運轉離不開錢，同樣，支付的存在也是為了錢，為了更好地印錢，更好地存錢，更好地流通錢……錢的形式有很多種，有現金，有銀行存款，有公積金，有手機話費，這些都是錢。
而現代支付社會，錢大部分存在“賬”上，站在“錢”的角度去看“賬”，我們發現“賬”就有了不同的屬性，等於錢的賬就是“資金實戶”，不等於“錢”的賬就是“虛戶”，就像微信錢包賬戶記著你有1萬元，但是這1萬元不能代表錢，而真正能代表錢的是微信在人民銀行備付金賬戶的中那1萬；所以說微信的這個“賬”是虛擬的“賬”，我們一般認為銀行的“賬”是錢，企業的“賬”只是記錄。
這時候，你從微信提現1萬到銀行卡，這是一件提現的“事”，微信扣減了你的微信錢包1萬餘額，這是微信基於提現的“事”產生的“提現”的費用項，記錄到了你的微信“賬”上；而這個時候，微信又請求人民銀行將備付金中的1萬轉給了你的銀行卡所屬行，這是微信真正給了“錢”，當然這個錢也是“賬”，只不過是銀行的“賬”所以說支付就是將支付的“事”產生的費用記錄到“賬”中，基於記的“賬”交付真正的“錢”。
這樣我們會發現，所有的支付都可以囊括到這三個字裡：事、賬、錢，如圖2所示：
圖2 事賬錢三層劃分
2. 支付就是基於“事”記賬，基於賬給“錢”
支付的不同就是“不同的事”記了“不同的賬”給了“不同的錢”。就如你做的國內支付，那就是國內的事，國內的賬，國內的錢；你做了電商的支付，那就是電商下單購物的事，電商商家結算的賬，給的商家營收的錢；如果你做了證券行業的支付，那就是證券交易的事，記了證券賬戶的賬，給了可能就是證券交易的錢。
錢也不是支付的結束而是下一次支付的開始；我們不妨說，現代商業就是“ 事、賬、錢 ”的支付迴圈，正迴圈錢越來越多，逆迴圈錢越來越少；把“事”做明白，把“賬”記清楚，把“錢”都管好，企業一定會越來越好；稀裡糊塗做事，亂七八糟記賬，大手大腳花錢，我想企業做不好，如圖3所示：
圖3 事賬錢的業務流轉
既然支付可以用“事·賬·錢”去抽象，那麼怎麼做事，怎麼記賬，怎麼給錢呢？這是個好問題，也是我們產品經理要解決的問題，那就是做“系統”，建“流程”，定“邏輯”；這樣我們透過建設一系列的“系統”透過一系列的“流程”在一定的“邏輯”下，實現了“做事”，“記賬”，“給錢”的完美協同。
這個協同，就是我們的“支付三字真經模型”，這個模型是由“系統/流程/邏輯”組成，去實現支付的“做事，記賬，給錢”，如圖4所示：
圖4 支付三字真經模型
3. 系統
哪些系統是做事呢？購物車，訂單系統，商品系統，交易系統，使用者管理，合同管理等，我們劃分到“做事”層，如圖5所示：
圖5 做事系統集合
哪些系統是記賬呢？清算系統，賬務系統，結算系統，會計系統，對賬系統；我們劃分到“記賬”層，如圖6所示：
圖6所示 記賬系統集合
哪些系統是給錢呢？收銀臺，支付系統，支付通道，支付路由，支付風控，用來收錢和付錢，我們劃分到“給錢”層，如圖7所示：
圖7 給錢系統集合
4. 流程
大的流程我們上面講了，就是先做事再記賬，然後給錢；那麼上面也講了有很多系統去做事，有很多系統去記賬，也有很多系統去給錢；那這些系統之間誰先誰後，誰聽誰的；做事這幫系統怎麼告訴記賬這幫系統去記賬呢，記賬這幫系統又是怎麼去告訴給錢這幫系統去給錢呢？這就是我們支付的流程體系，如圖8所示：
圖8 支付的流程體系
5. 邏輯
如果說“事賬錢”是人體，那麼系統就是“臟器”，介面就是“血管”，邏輯就是“人體就是眾多系統之間以及系統本身每個功能單元之間運轉的規矩”，一個支付架構就是由這些系統透過一定的流程連線，透過既定的邏輯運轉的集合。
那什麼是邏輯，就是事件的排序，就是對錯的判斷，就是增加或者減少的依據，也是能不能給錢的規範；使用者加入黑免單了，那就會在下單時被風控，風控告訴下單那邊這個使用者有問題，下單系統會根據這個問題的型別進行跟使用者的反饋，我們會告訴他，“不好意思，您存在刷單行為已被平臺封禁，禁止下單”，這就是一個邏輯；那麼支付體系有非常多的邏輯，我們就不一一贅述了。
我們透過上面的“事賬錢”模型，去思考一下，下面這些支付場景下，都是幹了什麼事，記了什麼賬，流通了什麼錢！！！如果是你，你會用什麼系統做什麼事，什麼系統記什麼賬，什麼方式給什麼錢，我想會有很大的收穫，最後試試看吧。
不同支付
模式
下的事賬錢：直連時代模式，斷直連時代模式，中國清算體系，往來賬戶模式，跨境模式，存貸一體模式，三方支付模式，四方聚合模式，跑分模式，支付全球化模式。
不同支付
場景
下的事賬錢：消費水電場景，電商場景，o2o場景，影片場景，直播場景，社交會員場景，證券場景，支付全球化場景。
二、支付金字塔
從發展的角度認識事物，我們會有更深刻的理解；很多原本無法把握的內容開始變得淺顯，這是因為，當下的存在那是源自幾千年的不斷嘗試，而在歷史長河裡，這些背後推動事物發展的動因，是我們深刻洞察的根本。
這篇文章，我們回到支付的歷史長河，去看當下支付形態裡幾個關鍵問題的歷史動因，會讓我們對支付原理上有一層非常刻骨銘心的洞察；而在這個發展過程我們會發現，慢慢地形成了一個“支付金字塔”模型……
1. 支付的發展
支付本質上經歷了幾千甚至可以追溯到上萬年的發展和探索以及變革；從最早的物物交換到現代的電子支付，中間無論是貨幣形態的發展還是服務機構的發展都起到了非常重要的作用。
貨幣的出現極大的提高了交換的效率，貨幣形態的不斷變化也極大的降低的支付的成本；電子賬戶貨幣的出現基本將貨幣的搬運成本降低為0，讓遠端支付瞬間完成，相比實物貨幣支付，電子支付已經成為當下核心的支付媒介。
整個支付的發展過程支付的處理方式也發生了很多創新性的變革，而這些變革很多是圍繞結算手段展開的，從最原始的物物交換進行結算，到金屬貨幣面對面結算，再到紙質票據進行結算，這個過程貨幣的運輸成本在不斷降低。
可兌換票據的產生是一個偉大的發明，它讓貨幣的攜帶和轉移變得非常容易；從影視劇中就可以看出來，有些朝代出門都要背上一個包袱，裡面背的都是金子銀子做為盤纏，怎麼說呢，一個字“重”；後來有些朝代的人不再支付金子，比如周星馳主演的蘇乞兒這個“敗家子”動不動就是幾十萬兩的銀票，可以想象，幾十萬兩的金子要用多少輛卡車才能拉得動……這就需要了解一個事實，那就是票據就意味著你在錢莊有這麼多金子，而且拿著票據可以換成金子，這時候大家才會接受使用票據進行支付，票據才可以在市面流通。
這時一個機構就冒出來了，錢莊；就像現代的銀行一樣；這些支付組織在支付中開始扮演重要的角色，也在分化出越來越多的職能，隨著經濟的發展，社會對支付需求的不斷變化，支付組織也逐漸演變成了如今的銀行、清算機構、三方支付機構、四方支付機構。
2. 幾個創新手段的產生
一個是票據的產生，票據與本位貨幣掛鉤，現在票據依然流行，也就是我們都知道的支票、本票、匯票。
另一個就是透過記賬進行支付，為了便於理解我們直接過渡到銀行時期。交易主體在同一家銀行內都開了賬本，那麼兩個主體之間的支付只需要在賬本上轉賬即可，屬於張三名下的記賬轉移到李四名下即完成了張三對李四的支付。
就像我在超市賒賬了100塊，然後對老闆說，老闆這個賬讓李四還吧，然後老闆會怎麼做，他會把我名下的100欠款劃掉，然後在李四那一頁寫上：替陳天宇宙換賒賬100元，就是這樣一個非常簡單的操作就完成了一次轉賬，只不過這個轉賬是轉的欠款。
另一個就是跨機構支付的結算模式，我們都知道如果我們在同樣一家銀行開了賬戶，那麼支付很容易，只需要行內進行操作即可；而如果我們在不同的銀行開了賬戶，那麼我們之間的支付的處理方式是怎麼樣的，最早的時候，不同機構之間會相互開設賬戶，用於彼此之間客戶之間的支付，例如A銀行和B銀行之間相互開設清算賬戶，使用者結算A銀行和B銀行使用者之間的支付。
但是這個效率還是非常低的，這個模式也會非常佔用銀行的資金，降低流動性，你想象，你要在其他所有銀行內開設賬戶，並且預存資金，同樣自己也要管理其他銀行在自己行內開的賬戶，這個管理成本也會非常高。
那麼一個新的探索就出現了，如何更低成本更高效率地實現多個支付機構的客戶之間的支付的清算。
現在看來很簡單，透過銀聯進行跨行清算。但是這個模式的產生整整經歷了上百年的探索，才出現了專門處理跨機構的清算組織，這裡面涉及到了大家公認的結算資產，信用的認可等等一系列問題。
所以說這要看大家共識的結算資產是什麼，在電子賬戶貨幣產生和共識之前，大家公認的是金子，那麼這種跨機構的支付就需要兩個機構之間交付金子；清算機構產生以後，所有參與的機構透過清算機構交付金子；後來有了賬戶貨幣，那麼參與的機構只需要在清算機構交付賬戶貨幣即可；這裡就又有一個非常重要的點，就是機構都需要在清算機構開設賬簿。
我們發現，支付經濟主體在支付機構內開設賬戶用於主體之間交易進行的支付的結算，而支付機構為了清算經濟主體間跨機構的支付的最終結算，又在另一個大家共認的機構開設賬戶，這些支付機構透過這個賬戶進行相互之間的結算。
我們可以大膽地想象，如果存在多個清算機構，那麼這些機構跨清算機構的結算如何進行呢，是不是自然而然就想到，再設立一個機構，來對清算機構進行清算……這裡的原理就是，不斷地在更高信用的機構內開設賬戶進行結算，是當下支付的核心思維。就如全球支付形式下，就需要一個用於進行全球清算的機構，來處理來自各個國家的銀行間的支付。
3. 支付金字塔
這樣就形成了一個層層向上開設賬戶的支付金字塔結構，這個結構也是我國支付體系的模型，個人和企業在銀行開設結算賬戶用於日常支付活動的結算，銀行在人行開設清算賬戶使用者跨銀行之間的結算。如圖9所示：
圖9 支付金字塔
4. 幾個關鍵認識
結算資產，就是在一個市場裡大家需要共識一個有價值的資產用於交易的結算，比如在一個村裡大家可以指定用蓋有印章的磚頭，而當下其實大家公認的結算資產是銀行的賬戶存款，因為大家都認。那麼大家認的前提是什麼，是大家都相信這個存款可以取出“現金”，如果這個前提不成立，大家就不會相信銀行，就不會把現金存到銀行，更不會接受銀行賬戶那串數字。
而這個信任的基礎就是國家信用，這個信用體現在銀行上就是“監管”，大家相信國家會監督銀行執行；而銀行之間公認的結算資產是人行的賬戶存款，也就是備付金，這樣的信用基礎才使得當下的支付體系得以執行。
所以說，我國主要的結算資產一個是銀行賬戶存款，另一個是人行的各銀行的存款；當然社會支付體系裡有更多其他的結算資產，比如我們微信和支付寶內的賬戶資產也可以用於結算，我們日常生活的支付其實用的就是微信支付寶的賬戶資產進行的支付和結算。
結算協議，大家的結算要基於結算協議，就像我們用微信支付寶進行付款，那是因為我們跟微信支付寶以及我們之間存在協議，承諾接受這種資產進行支付和結算，只不過大家不關注而已
瞭解了支付的這些方面，是不是很多零散的知識點連線起來了！
三、“故事分析法”與大型專案實施
表達對於產品經理來說很重要，但是這個表達絕對不是像辯論選手一樣秒殺一切對手，而是能夠清晰地表達自己的理念和產品設計。
我們在做產品設計的時候往往也需要設定一個核心的定位，成為一個生活方式，記錄美好生活……所以說我們需要刻意的訓練自己去嘗試設定產品的頂層設計，然後將這個理念表達出去，在這個理念之下很多問題都會有了決策的依據。
1. 學會講故事
在表達產品設計方案的方法中，講故事是一個很有效的方法。訓練自己可以用100個字表達任何一個你做的專案、設計的系統、設計的功能，同樣這種表達可以是在你設計結束以後對外的宣講，同時也是在設計之前的思路覆盤整理，而這個故事不是基於功能而是基於場景和角色的陳述。
例如，我們都知道賬戶中心作為對資金的記錄，往往會因為一些交易場景造成賬戶的透支，形成了使用者對平臺的欠款。那麼欠款就有壞賬的風險，為了資金安全考慮，我們就需要一定的監控機制以及欠款的追繳策略，讓使用者償還欠款，而基於實際情況這種償還的途徑可以有多種。
2. 故事裡的秘密
上面的一段描述其實就是一個故事，這個故事很平淡，也描述得很清楚，任何一個場合，無論是面對研發、測試、老闆還是打掃衛生的大媽，我想大家都知道你要因為什麼而做什麼，這樣的一段話你可能不知道，它足以引領你完成整個專案的設計，所以，我稱這段描述就是“產品的故事”。我們很容易表達出自己的產品故事，就像我們可以很輕鬆地表達出我們餓了想吃飯。
為什麼說這個故事裡有很多秘密呢，我們把關鍵詞標註出來，你發現了什麼？我們都知道賬戶中心作為對資產的記錄，往往會因為一些交易場景造成賬戶的透支，形成了使用者對平臺的欠款。那麼欠款就有壞賬的風險，為了資金安全考慮，我們就需要發現欠款並且能夠追回來，而基於實際情況這種償還的途徑可以有多種。
故事裡的關鍵詞就像引擎的入口一樣，可以幫助我們不斷地開啟思維的大門，慢慢地一座系統的縝密的架構就出來了，不信我們試試。
1）資產
什麼是資產，不同的情況或者不同公司的使用者會有不同的定義，結算款是資產，保證金是資產，在途結算款也是資產，也許信用也可以成為資產。
所以說，我們要問自己如何“定義資產”，這就是我們下一步圍繞資產的分析工作，資產就有他的形式、他的度量、他的優劣等級；假如我們得出來的使用者的資產有這樣幾種形式——結算款、保證金、在途待結算。那麼這些資產怎麼表達呢，賬戶裡的好說，就是餘額，那麼在途結算款怎麼獲得呢？這不新的分析任務又來了……所以圍繞資產的分析在逐步展開，而且相互自洽和補充。
2）一些交易場景
賬戶資產其實都是基於交易產生的，那麼有些交易場景就會有不同的資產方向變化，比如什麼交易場景會增加資產？什麼交易場景會流失資產？這裡也只有流失資產的交易場景才會造成資產的透支。那麼有哪些交易場景會造成賬戶透支呢？這又是一個分析任務，同樣不同的交易場景造成的透支是不是可以透過制度解決掉呢？這裡我們又發現了一個解決問題的可能性。
3）透支
透支是一個現象，不一定所有的賬戶中心都允許透支，那麼就算不允許透支，一些交易場景發生以後也會出現欠款，只不過這種欠款更隱蔽，比如訂單退款因為餘額不足而無法退款成功，那麼這個待退款訂單其實就是欠款的另一種表達。
那麼讓賬戶透支的好處是什麼呢，其實就是讓欠款顯現出來，而且更容易進行核算，比如後續的收入可以直接抵扣欠款，不然的話後續收入無法與待退訂單進行抵消。所以說我們對透支有了更深的分析，當然這個分析可以繼續下去。
4）欠款
欠款是資產風險的暴露，是一個結果，也是我們這次要解決的主人公。欠款一旦發生，就意味著未來可能有損失。這裡像定義資產一樣，我們怎麼定義欠款，以什麼樣的形式呈現出來？假如我們以賬戶餘額為負作為欠款的表達。
5）風險
前面說了欠款是主人公，那麼風險就是我們要消滅的物件，也是我們做產品的目的，這個風險有多大，有沒有達到要馬上解決的地步，如果堵住了，意味著多大的價值；對風險的定義和量化，就成了我們定義產品價值的關鍵。
假如當下總欠款體量1000萬，那麼這個體量明顯是需要堵住的，所以說這個產品的意義就是為了堵住1000萬的風險資金缺口。
6）資金安全
堵住風險和確保資金安全是一個正面一個反面的表達，這也是作為一名資金產品經理最核心的職責，確保資金的安全。
7）發現欠款
現在欠多少錢呢，誰欠錢呢，所以說我們需要一個機制可以將風險報出來，提供給負責的人員進行評估。
8）追回來
啥是追回來，其實就是要錢，怎麼要，什麼時候要，所以說我們需要建立完善的追繳制度。
9）途徑
既然要追錢，是不是就需要追繳的方法，使用者想還錢，是不是就需要還錢的途徑。另外用什麼還，用保證金？直接支付欠款？每個還款方式怎麼樣？這裡慢慢我們就開始看到了解決方案的影子……而且隨著發展，這個途徑會越來越多，那麼這個地方也會成為一個拓展性的口子，我成為“拓展基因”以故事為起點，一篇產品大戲慢慢拉開。
3. 學會抽象業務流程
我們做產品設計不要一上來就開始畫頁面，做腦圖，想講故事，然後確定主業務流程。也就是場景模擬上面的故事裡，雖然我們發現了幾個分析入口，其實整個故事中蘊藏一個主線，這個主線就是業務流程，而業務流程的梳理將決定了設計的好壞。
其實流程很容易，我們在表達一件事情或者思考一件事情的時候，可以從最確定的最宏觀的視角入手，然後不斷地去修正和補充，直到這個鏈條足夠順暢就像交易的主業務流程一樣：使用者下單，發貨收貨，完成，這個就很容易理解，這個理解還不會出錯，那麼我可以繼續細化它。
選商品，下單，支付，發貨，確認收貨，算賬，給商家結算……同樣上面的故事裡我們可以抽象出這樣一個流程，如圖10所示：
圖10 追繳欠款的流程
流程看什麼，流程拆開看環節。對每一個環節進行分析，先確保環節沒有遺漏，然後豐富每一個環節。
就像把大象放冰箱需要幾步，把冰箱門開啟，把大象放進去，把冰箱門關上。這個時候你肯定需要思考，怎麼開啟冰箱門，用手拉門把手麼，還是有一個遠端按鈕……思考永遠是從一個最簡單的切入點逐步深入。在沒有確定這三步之前就不要直接思考怎麼開啟冰箱門，為什麼？因為你不知道為什麼要開啟，無法知道開啟與前後的聯動性和關聯性，而這種全域性思考會影響對單個環節的定義和判斷。
從上面的流程裡我們發現其實資產的定義、欠款的發現都是靜態結果的顯示。而追繳這個環節貌似非常豐富，首先我們會有疑問：怎麼追繳，誰來追繳，使用者用什麼償還，怎麼償還？……
1）業務流程的拆解
這就需要我們具備流程拆解能力，在一個大的流程裡，我們會發現存在小的流程，或者更復雜的網狀的流程。從環節裡拆解出更精細的流程，剛才我們上面說的“追繳環節”，其中就有幾個我們需要進行抽象的，比如：
怎麼追繳：追繳方式的抽象，比如線上追繳、線下追繳
誰來追繳：追繳職責的界定，比如運營人員使用者
用什麼償還：給使用者的可抵扣資產的抽象，比如用保證金，用銀行卡
怎麼償還：這個其實就是追繳環節的子流程，也就是每一個追繳方式的子流程
如圖11所示：
圖11 追繳流程的拆解
而且從流程圖中我們發現，在追繳方式上具備拓展性，隨著發展，追繳方式會越來越多，而觸達追繳方式的入口就是在選擇要追繳某筆欠款的時候。
2）業務子流程的設計
在上面的已經拆解過的流程裡，我們發現了三個子流程，那就是“不同追繳方式”的流程，而且要針對不同的追繳方式單獨設計流程，如圖12所示：
圖12 業務子流程
其他環節的整理同樣在資產的定義環節也會有任務要做，就是有幾種資產，怎麼定義資產，每種資產怎麼計算獲得。
計算每種資產將成為資產環節的子流程，而資產的分類將成為未來的拓展主線產品功能分析，到了這一步我們再去思考我們需要什麼樣的功能其實就容易多了，比如資產定義環節，那麼就做一個“總資產管理”，發現欠款環節就做一個“欠款管理”，每條欠款資產後面我們就加一個“追繳”入口，然後呢就是確定“追繳方式”，進入每一個追繳方式的流程裡……
本文的核心目的就是要養成講故事的能力，然後從故事裡發現秘密，發現流程，並對流程進行有條不紊的拆解，從而一步步地完成產品的定義、分析、抽象和設計工作，這樣做的好處就是我們從故事出發，不以實現功能為目的，而是以實現故事描述的未來為方向，一層層的剝開故事的情節，達到目標。
四、主導大型的結算線上化專案
做計費結算產品經理，主要幹嘛，其實簡單點就是算賬、記賬、結賬。當然這是一個很寬泛的總結，最頂層的理解往往是理解一個事物的基礎，接下來再去思考“什麼是算賬，怎麼算賬，手工還是系統？”
1. 來了一個需求
來了一個業務需求，我們一起碰一下。業務場景我們先了解一下，目前公司有大量的城市渠道商，幫忙招募商家，不同的渠道商有不同的結算模式，比如有些渠道上只給他們結算渠道分成，有些渠道商要按照渠道訂單進行全額結算，並由渠道商給商家進行結算，不同的合作模式下有不同的結算模式。
同樣商家所簽訂的入駐協議不同，其拿到的結算款的方式也不同，可能通道渠道拿到，也可能透過平臺拿到，這個過程中平臺還需要抽取一定的佣金。針對不同渠道商的結算方式也會存在不同的賬期，並且渠道商還需要繳納一定的保證金，還可以透過預充值，後續購買一些平臺的增值服務，我們把業務模型整理，如圖13所示：
圖13 渠道商結算業務模型
目前的清結算現狀是除了使用者下單業務以及平臺跟商家之間的結算以外，其他全部環節全部由線下完成。所以說業務方的痛點是比較明顯的，人力成本高、結算週期長、結算準確性差、清結算資料線上不可追溯。為了降低結算成本，提高結算效率，希望將全部環節實現線上化。
上面就是業務場景和業務痛點。
2. 落地分析
怎麼解決結算線上化問題，其實我們首先要評估這個專案值不值得做，那就是看下整個業務體量以及人力成本究竟有多高，線上化以後的綜合收益如何。整體評估下來我們覺得這個專案是值得做的，當然不值得做我們也不會有下面的設計了。
既然決定接這個需求了，那麼下面就要思考了，這個業務模型怎麼實現線上化。
這時候就要看實現路徑了，一個是看看能不能複用現有的系統能力，另一個就是做一套渠道結算體系；前者相對成本較低，後者相對成本較高。如何做抉擇呢？這個要看當下公司的系統模式，如果是大中臺，且已經成熟，那麼可以複用中臺能力；如果是各業務線自治，那麼可以為渠道做一套計費業務，可以服務的部分複用。
最後我們選擇計費結算相關能力複用中臺能力，而渠道商的保證金以及預充值和增值服務的購買等需要渠道業務自己完成渠道平臺的建設。所以說這個專案就涉及到了兩個大的團隊，一個是中臺團隊，另一個就是渠道業務團隊。
除了產研團隊以外，還需要另外一些團隊參與進來，比如運營團隊參與進來負責制度制定，財務團隊參與進來梳理財務訴求，資金團隊參與進來負責資金賬戶相關事項。整個專案班子搭好以後，進行立項，開啟動會，指定專案經理，拆解子專案，分派責任人……開幹！！！
很不巧，陳天宇宙成了該專案的首席架構師兼專案經理；那麼我第一件事要做什麼呢？那就是抽象業務模型，產出清結算模型，設計渠道商計費結算線上化整體業務和產品架構。
3. 規劃產品架構
這個過程首先我們要梳理所有的參與角色、計費專案、支付業務、計費物件以及關係、計費模型、結算流程。
參與角色涉及到了渠道商、商家、平臺
計費專案涉及到了渠道商分成、平臺佣金、商家結算款、保證金、預充值款
支付業務涉及到了保證金充值、預充值、服務購買、結算付款等
結算需要進行賬期的管理，結算路徑需要有直接結算和代理結算等
整個過程需要涉及到這樣幾個關鍵的流程，保證金充值流程、預付款充值流程、增值服務購買流程、計費流程、結算流程等。
透過以上的分析，我們可以整理出下面的產品架構，以及業務流程架構，如圖14所示：
圖14 渠道商結算線上化業務架構
從架構圖中我們基本就可以整體來把控這個專案，無論是涉及到的系統也好，相關的核心流程也好，涉及到的角色也好，基本都可以從架構圖中清晰的看到。接下來我們就需要進行邊界的設定，也就是誰做什麼，然後拆機子任務分派到人，開始進行產品的設計。
這裡我們重點說一下這個架構裡涉及到的支付能力（收款能力，打款能力，消費支付能力）：對公收款、對公付款、內部虛擬戶餘額支付。
4. 專案拆解
我們來看涉及到的幾個系統要做的事情，首先是訂單系統，需要按照要求將渠道訂單推送至清結算中心完成計費。這裡的計費物件以及計費模式和規則我們就不具體詳述了，大家可以針對上面的資訊自己琢磨一下。
計費完成以後我們採用結算至賬戶中心，對應物件的賬戶中。整個賬戶中心為該專案提供四類賬戶：
商家結算賬戶
渠道商保證金賬戶
渠道商佣金賬戶
渠道商支付賬戶
透過賬戶名稱我想大家也應該清楚每個賬戶承擔的職責。
然後我們再看結算系統，結算系統負責將對應的結算賬戶資金透過對公結算單付款給對應的結算賬戶，並且按照指定的結算週期，打款中心需要支援銀企直連對公付款或者其他對公付款能力，以完成公對公的付款業務。
同樣針對保證金充值以及預充值款的充值，需要支付系統可以提供B2B的支付能力，可以接入一些三方支付的網銀支付也可以支援線下對公付款線上稽核支付確認的模式，並且需要根據不同的支付業務入賬到不同的賬戶中。最後支付系統需要具備餘額支付能力，以實現渠道商增值服務的下單支付。
除了上面的產品設計需求之外，我們還需要對接財務，看財務的記賬需求，比如需要哪些財務報表，什麼時候需要等等。
5. 專案落地
最後，萬事俱備，我們拉平資訊，建立專案管理檔案，梳理每個子專案的專案節奏，也就是時間安排。比如訂單系統的計費推送，清結算中心的計費業務安排；賬戶中心的不同賬戶支援；結算系統的對公結算，打款系統的對公付款；支付系統的對公收款和餘額支付……
後面的事情我們就各方進行需求設計和評審，然後進行全環節的聯合評審；技術詳設評審，測試用例評審，正式進入研發階段；研發完成以後進行全環節聯調，測試，上線評審，灰度評審；產品驗收，各部門準備；上線準備；上線完成；上線後的執行監督……
這裡面涉及到的系統的具體設計，我們的Pay X集訓營或者公眾號的相關文章都有詳細的介紹，這裡就不再詳細的進行設計展示了。這篇文章重點是幫助大家建立全域性思維和專案管理思維，能夠從0到1承接一個大型專案，具備把控全域性和節奏控制的能力。當然這裡面的架構設計大家也需要具備，如此，才能在大專案中承擔中心角色。
這類專案是比較考核一個產品經理的綜合素質的，當然如果你可以承擔下來並且完美收官，這無疑是一次能力的巨大提升，並且在未來的面試中專案經驗一欄，重要的一個加分項，也是走向高P不可或缺的經驗背書。
五、一點三線架構
1. 在頂層設計中解決理念問題
當我們試圖去把握一個全域性的時候，我們首先要做的就是從更宏觀的角度去認知這個全域性。而善於做頂層設計者往往善於闡述出一個理念，就如張小龍的用完即走，阿里巴巴的讓天下沒有難做的生意，你的非BAT大廠不去等等。這些理念或者信念的樹立會影響著整個全域性的指導精神和格調，我們要說的就是這樣一個觀念“一點三線”搭建支付架構。
2. 支付的過程
我們都知道現在經濟活動離不開電子支付，而支付離不開貨幣，進而電子支付離不開電子貨幣，而電子貨幣又離不開電子賬戶；而電子支付的產生又離不開現代電子通訊與網際網路技術的發展；所以電子支付離不開現代支付清算系統，而我們說的這個支付清算系統包含了眾多為整個支付過程服務的相關係統什麼是支付過程呢，我們可以將支付分為三個階段：交易，清算，結算。
交易：消費意願下使用者選購商品，下單，確定支付工具，生成支付指令的過程
清算：支付指令在不同機構間進行傳輸、收集、計算應收應付清分的過程
結算：最終資金交付給相關參與者，到達其約定結算賬戶的過程
3. 一點三線就是支付體系的骨骼
那麼怎麼樣的一個支付架構可以支撐上面的支付過程，以促成這單生意呢？我們用這個一個產品架構模型“1點3線模型”。
一點：收銀臺，也是支付的起點。
三線：
內線“訂單- 賬單-清結算-賬務賬戶”
外線“路由-風控-支付核心-渠道清算-通道方”
聯動線“內線和外線的支付資訊互動線”
內線是為內部服務，從交易發生以後最終到達會計系統記錄本次經濟活動的整個鏈條，從訂單開始走向計費、內部記賬、內部會計等。
外線是為清算服務，將支付指令傳送給服務機構並接收反饋的過程主線；從訂單開始到達支付閘道器，透過路由選擇合適的支付通道，然後交換支付指令，完成支付。
聯動線是為內外線通訊服務，內線的程序和外線的程序相互通訊和推動，支付成功了就可以進行記賬，計費成功了就可以分賬。
那麼我們就得到了如下的支付架構，如圖15所示：
圖10-15 支付架構
4. 架構就是遠方
把握好“一點”的設計和“三條線”的設計，就可以搭建起一個完整的支付體系。該設計方法不僅適用於一家三方支付機構，同樣適用於一家普通的交易平臺，四方聚合支付。只不過支付通道的不同，三方接入的是銀行通道，普通商家和四方聚合公司接入的是三方通道。
架構的意義是什麼，那就是可以確保未來不會頻繁重構，確保在每一個維度都具備足夠的可拓展性，確保每一個模組和細節都為整體服務，同樣確保產品不被業務牽著鼻子走，這是產品的頂層設計，也是走向遠方的那盞燈塔。
5. 產品的意義在於解決問題
產品的意義是什麼，是做出一個“厲害”的系統麼，是做出一個“正確”的功能麼，是遵守一個通用的規範麼？我想都不是，何為正確，何為規範，誰又是標準？
產品的意義應該是用可用的手段解決當下甚至是未來的問題，所以，產品應該聚焦問題本身或者需求本身，不是系統或者功能本身。
就像很多朋友會問，賬戶的流水用體現“-負號”？我們總是習慣站在功能角度去設計產品，負號是一個功能；而常常忽略了，我們所面對的問題，而這才是根本。產品應具備透過功能靈活解決問題的能力，而不是僅僅是設計功能本身。
我們再看要體現流水的“負號”麼？要不要呢？其實我們不應該問要不要體現負號，而是要問自己，負號要解決什麼問題，進而問自己“我在面對一個什麼問題”。
而這個問題就是“我需要用一種方法反映出流水的方向”，面對這個問題時，你就不應該用“用不用負號這個功能去迴應”，而是“如何反應流水的方向”，當觸達最本質的問題時，我們才能到達最關鍵的十字路口“選擇”，一個產品面對問題時應該具備選擇的能力。為問題選擇答案，而不是僅是論證一個答案的正確與否。
反應流水的方向就不僅僅可以用負號了，可以用收支欄位、借貸標識，這個時候你還會問我，流水裡用不用反應負號麼！當你再思考這個功能怎麼設計的時候，不妨回到起點，問問自己我要解決什麼樣的問題，期望達到什麼樣的效果，我有多少可選的方案，當下的這個讓我百思不解的功能是唯一答案麼！放棄對模板和對權威的痴迷，而是探索自我的設計風格，培養追尋未知新事物的好奇，產品設計可以很自由且很瀟灑……
六、賬戶遷移方法論
賬戶部分在之前我們講得比較詳細了，而且線上課堂也有賬戶的專欄，所以在此基礎上我們來觀摩一個實際的賬戶相關的案例。
這是一個大型且高危的專案，危險程度要看涉及到的資金屬性、賬戶數量、資金體量。比如你要是幾十萬，那閉著眼就做了；但是如果是千萬使用者，百億資金情況下，小心臟就要時刻蹦蹦跳了。
我們知道企業在發展過程中到了一定階段，難免需要進行一些系統的重構或者資料的遷移；比如要做中臺，那麼業務的統一勢必要將一些系統下掉，業務以及資料遷移到新的中臺服務中去；我們要講的就是“舊賬戶服務遷移至新賬戶服務”如何做，如何實現使用者無感知的服務遷移
我相信，這個案例可以讓你把賬戶掰開了揉碎了再認識一遍；而且對賬戶的把控力上升3個臺階；這也是高端面試過程中容易問到的問題，也是一個很容易腦子一片空白啞口無言的題目；當然這個案例也可以作為簡歷中一個經典的頗具競爭力的實戰專案
這次我計劃採用半講解半方案文件的模式書寫這篇文章；既可以讓大家理解，又可以作為半成品文件提供給各位拿來即用；好了，價值講清楚了，你準備好開始了麼……
1. 專案概述
為了構建統一中臺賬戶服務，圍繞中臺統一賬戶管理支援各業務線客戶賬戶以及賬務處理能力，需要將各業務線分散的賬戶業務全部切入中臺賬戶服務中心，並且穩定後下線舊賬戶服務。
2. 整體方案框架
分期分批，為了確保資金安全，業務正常無停產運轉，對於每個舊賬戶叢集採取“兼平切”的方案理念，分階段、分批次完成整個遷移工作，整個專案分三期完成。
第一期：服務相容
在舊賬戶服務層相容新服務層，或者在新服務層相容舊服務層，或者在新舊服務之上構建新的相容服務層。這次基於“業務無感知，使用者無感知”原則，我們採用第一種方式，在舊服務層內相容新賬戶服務，如圖16所示：
圖16 賬戶遷移的相容架構
第二期：賬務處理灰度切入
先將加入灰度範疇的賬戶進行賬務處理排隊，先進行舊賬戶餘額不扣減結轉至對應新賬戶中，然後將結轉後的賬務處理包括排隊中的請求雙寫入新的賬戶中。
再將就賬戶的歷史賬戶明細遷移轉入新賬戶流水錶中，並進行自洽驗證，至此該賬戶完成了並行雙寫的賬務結轉，以此為節點，該賬戶今後將進行全部賬務請求的雙寫處理。
並對該對映賬戶進行雙寫校驗，對於校驗異常的賬戶進行差錯處理，以確保全部最終校驗正確。
第三期：主次切換關停舊服
3個月以後對於校驗正常的新舊賬戶組關閉舊賬戶雙寫，關閉舊賬戶，直至全部舊賬戶關閉，全部舊賬戶服務關閉。
推動業務線逐步更換新賬戶服務，直至前部更換完成，最後下掉舊賬戶服務。
3. 方案基本原則
賬務準確：餘額準確，明細準確；遷移前後新舊系統以及與實際一致相符
按賬戶灰度：灰度選擇一個城市的全部賬戶進入灰度賬戶名單
新舊並行：餘額同步至新賬戶，並行期間依舊舊賬戶對外提供服務，內部介面同步給新賬戶，財務資料同時從新賬戶出具一份
灰度成功後第二批切全部：不進行多次灰度，灰度成功後即執行全部遷入新賬戶中心
不停服遷移：在舊賬戶遷移至新賬戶執行期間進行賬務處理排隊，結轉完成前不處理進賬和提現，結轉動作完成後按排隊順序進行處理
如圖17所示：
圖17 賬戶遷移賬務處理思路
4. 賬戶結構設計
我們先看舊賬戶結構，分多型別賬戶，下設二級型別子賬戶，如圖18所示：
圖18 舊賬戶結構
我們在看新賬戶結構，設定三級賬戶結構，第三級結構記錄賬戶餘額與明細，如圖19所示：
圖19新賬戶結構
兩套賬戶的影子關係，在末級賬戶上進行對應，如圖20所示：
圖20 新舊賬戶對應關係
5. 遷移落地
1）初始化期初
新餘額期初餘額=舊餘額轉入餘額=舊餘額期末餘額
發生額：新餘額髮生額=舊餘額發生額
期末：新餘額期末餘額=舊餘額期末餘額=期初餘額+淨髮生額
2）灰度方案
灰度管理，以賬戶為維度建立灰度表，灰度表裡包含全部舊賬戶；可以透過灰度表來監控灰度情況以及判斷賬戶是否在灰度中，如圖21所示：
圖21 灰度管理
3）回滾方案
原則上業務層不進行回滾，技術層回滾方案由技術決定；針對出現問題的賬戶進行人為干預，業務上無逆向執行遷移。
4）執行
以上便是整個方案的框架了，後面就按照該方案框架進行詳細的技術設計以及執行了；先執行一批灰度賬戶；3個月後沒有問題對全部賬戶進行灰度；再3個月後沒有問題；開始逐步關停舊賬戶服務。
5）覆盤
整個專案完成以後，業務，運營，產品，技術等進行大覆盤，瞭解各方業務情況，是否存在其他問題，比如財務記賬準確性沒有變化，正常結賬是否有影響等。
專欄作家
陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！
題圖來自 Unsplash，基於 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。