起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從方法論的角度，談談支付體系
如今，我們都非常習慣于在手機上進行支付，需要買什么，掃一下碼就行了。那么，你有沒有想過，整個支付的體系是什么樣的呢？本文作者從方法論的角度，分析整個支付體系的運轉規律和設計方法，一起來學習一下吧。
收獲了大量實戰經驗以后，從中抽象出可被復用的方法，是自我升級的非常重要的過程，而所有方法又會在不斷的新的經驗里被優化改進。
全文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 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
雖然再做收單系統，但是對賬戶遷移這塊依舊不理解，都是技術直接提供方案操作了?？粗悬c收獲