起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識項目總結：企業訂單結算系統從0到1
本篇文章是筆者的產品實習總結，主要是對企業訂單結算系統進行了梳理和分析，對產品設計過程中遇到的問題進行了反思，供大家參考和學習。
這是筆者在實習階段負責的企業訂單結算系統，雖然題目寫的是訂單結算系統，但里面也涉及到了訂單系統、發票系統、投入產出系統，四個系統互相聯動。在產品設計過程中，碰到了一些問題同時也解決了問題。
實習已經結束，故總結了訂單結算系統后臺產品從0到1設計過程中的一些反思，與大家分享，希望可以給大家一些啟發。
一、項目基本介紹
隨著公司的不斷發展，訂單量逐漸增多，市場部的商務同事對于結算有了新的業務需求，財務部的同事每到月底都頭疼于財務報表和投入產出的數據輸出。原有的訂單結算方式不再高效，同時也缺乏相應的數據分析。
公司管理者希望建立一套全新的結算系統，這個系統可以解決訂單結算、發票管理、財務報表和投入產出這四個問題。管理者可以通過系統的財務報表和投入產出做出下一階段的工作安排和決策，公司員工也能更加高效地處理工作問題。
二、目前成果
訂單結算系統經過反復的測試和修改，已經可以實現市場商務的結算業務。
發票管理系統的發票管理、發票查詢、周、月發票報表三個模塊也都如期上線。
財務報表在原有的訂單報表基礎上增加了許多業務數據匯總，讓決策者能夠從更多角度去看待當下的業務完成度和布置接下來的工作安排。
投入產出分為兩期來實現，如今已經實現第一期版本的投入產出，投入產出本質上是整合了多個系統的數據，并拆分組合在一塊形成一個數據匯總分析庫。
由于投入產出需要整合的系統數據過多，需要對多個系統進行字段重新設置，工期量大，故分為兩期來完成，如今已完成第一期，第二期的一些數據功能需求還在測試當中。
三、業務調研
1. 業務現狀梳理
公司希望產品運營部門今年能實現業務數字化管理，這個部門在今年能獲得更多的訂單量。原先的訂單結算系統在一個辦公協同軟件上跑，無法實現數據分析，管理層無法通過數據做出決策。
這個新的訂單結算系統的戰略目標是幫助部門快速實現訂單結算，同時提高多個部門的工作效率和給管理層提供決策意見。
經過對市場部商務、產品運營部的同事、財務部的同事進行深度訪談，對目前結算的流程有了了解。整個流程為商務提起結算，商務申請開發票，財務開發票，結算完成。
2. 業務問題總結
（1）關鍵業務問題梳理
經過訪談分析，目前結算業務存在以下業務問題和需求：
- 每個客戶都有許多訂單，如何快速準確地查找選擇應結算的訂單；
- 復核環節會出現價格修改、訂單修改，如何保障退回給相應的人和修改完后給相應的人，流程需要高效；
- 開票系統是否能顯示應收款賬期；
- 對賬和開票工作復雜；
- 開票系統需要自動生成相應的開票周、月報表；
- 投入產出涉及的系統包括部門原有的工時系統、訂單系統和現在的結算系統、發票系統，如何處理四個系統的數據聯動，如何保障成本和收入數據的準確性。
（2）問題解決思路
- 實現商務快速準確選擇訂單（高優）；
- 訂單結算流程高效（高優）；
- 實現賬期監控（低優）；
- 實現對賬報表（高優）；
- 實現周月財務報表（中優）；
- 建立主數據庫，聯動多個系統，實現投入產出數據生成（中優）。
四、項目的整體方案設計
1. 業務流程設計
通過對業務的了解和對各部門人員的訪談，思考了業務的各個參與方，原先結算流程缺少產品運營部門同事和主管復核和確認收款環節，現在設計的這個流程能夠使結算業務變成一個閉環。
圖4-1是經典的泳道流程圖，橫軸代表相關的業務部門，縱軸代表的是業務系統。
圖4-1
2. 應用架構融合
公司的產品運營部門用簡道云開發了訂單系統、CRM和工時系統，這一次即將要設計的結算系統和發票系統必須要與原先的系統架構融合，結算系統結算的訂單就是訂單系統上的訂單，投入產出要展現的數據是聯動了工時系統、CRM、結算系統和開票系統。
3. 功能模塊設計
通過自頂向下的分析思路，我們明確了這次結算業務分為兩個系統，分別是結算系統、發票系統、投入產出系統。
接下來我們進一步拆解，將每一個系統可能需要的功能都列出來，先做加分后坐減法。
（1）結算系統
商務需要在結算系統選擇訂單進行結算，結算流程跑完之后，也需要對結算單進行查詢，查詢這個結算單目前流轉到了哪個節點，后續也對報表功能有要求。
所以從商務和產品運營部的角度，結算系統應該具備以下模塊和功能，如圖4-2所示。
圖4-2
（2）發票系統
發票系統是給財務部門使用的，這相當于一個發票管理后臺，財務部的主管和員工可以用來查詢發票，至于有哪些查詢篩選項和查詢值，這個放到產品細節設計再來考慮。
財務管理模塊還有對賬管理、賬期管理、財務部門月報，如圖4-3所示。
圖4-3
（3）投入產出系統
投入產出系統其實就是為了生成投入產出明細表和業績報表，投入產出明細表分為兩大塊，一塊是收入，一塊是成本。收入可以通過填寫項目進度、成本可以通過薪酬錄入和填寫成本費用。
綜合考慮，將其分為兩個模塊，一個是數據錄入，功能分為薪酬等級錄入、項目進度填寫、成本費用填寫、客戶稅率數據錄入，其中成本費用填寫和客戶稅率數據錄入放在訂單管理系統里提交訂單的時候填寫。
綜合報表的功能有投入產出明細表、業績分析、數據核對、客戶分析，如圖4-4所示。
圖4-4
五、項目的細節方案設計
1. 數據建模
正確的數據建模，才能在后面的設計中更加清晰地完成功能模塊的細節設計和交互設計。數據建模決定了數據庫的表結構，對后續的報表設計十分重要，也能夠體現產品設計者對業務的理解。
多個部門會用到結算系統，不同部門的使用權限不一樣，因此有多層級管理的需求，根據對業務的理解和優化，組織結構樹如圖5-1所示。
圖5-1
在組織結構樹中，可以看到，這個業務有一個管理員總賬戶，這個管理員賬戶可以管理所有的數據，包括市場部、產品運營部、財務部這三個部門的所有數據，權限度最高。
每個部門下表明了一個員工有一個賬戶，員工使用自己的賬戶，可以在系統進行相應權限內的操作。
根據圖5-1的組織結構樹進行簡化，可以得到圖5-2的ER圖。
圖5-2
通過ER圖，可以清楚理清賬戶、結算業務、部門、員工之間的關系，能夠把業務中獨特的邏輯關系理清楚了，這一步是關鍵的，唯有把業務數據建模好了，后面的設計才不會出現數據邏輯問題。
2. 頁面流轉圖
業務流程圖已經在項目的整體方案設計中設計好了，不過這是一個顆粒較粗的概要性設計，降下來將要繪制頁面流轉圖。
頁面流轉圖是用戶完成某項工作需要涉及到的頁面和流轉順序。我將根據業務流程并且針對不同的使用對象一一設計頁面流轉圖。
結算系統的商務提起結算：市場部商務人員，圖5-3。
圖5-3
結算系統的項目經理復核、客戶經理復核、部門主管復核、客戶經理讓客戶復核、商務申請開票、財務開票、確認收款：分別對應項目經理、客戶經理、部門主管、客戶經理、市場部商務人員、財務部人員、財務部人員。
圖5-4
結算系統的綜合查詢：市場部商務人員
圖5-5
結算系統的報表：市場部所有主管、產品運營部主管
圖5-6
發票系統的綜合查詢：財務部所有人員
圖5-7
發票系統的財務管理：財務部門部分人員
圖5-8
投入產出系統的數據錄入：財務部門人員、市場部門人員、產品運營部門人員
圖5-9
綜合報表：管理層、財務部主管、產品運營部主管
圖5-10
以上只是展示每個流程的主要頁面，主頁面里的管理、編輯、篩選、數據導出等頁面由于篇幅過多且細，不在此全部展出。
3. 頁面設計
頁面有太多了，所以只是展示結算系統的2.1項目結算提交頁、3.1我的待辦頁這兩個頁面。
項目結算提交頁是整個業務流程的開始頁面，由商務提起，頁面里涉及到的每一個文本、日期、下拉框、復選框、子表單、成員選項都是經過深思熟慮的。
這些設計反映了這個業務的需求，同時里面涉及到的一些函數和聯動也是為了提高使用者的使用體驗。
項目結算提交頁的頁面設計如圖5-11所示。
圖5-11
我的待辦頁面的頁面設計如圖5-12所示。
圖5-12
4. 權限設計
權限設計規范了哪些角色能看到哪些數據和做哪些相應的操作，所以分為功能權限、字段權限和數據權限。每一個模塊和功能都有設置了權限。
在此我以結算系統作為例子進行復盤。
功能權限的權限表如圖5-13所示。
圖5-13
字段權限在結算流程中用到了很多，也是這次設計中的重點。字段權限規定了在這個流程中哪些字段能被哪些人看到，哪些人看不到。
這里必須得談到RBAC（Role Base Access Control）權限模型，這個模型由計算機科學家Ravi Sandhu于１９９５年提出。每個用戶都會被賦予一個或多個系統角色，每個角色都對應一個明確的權限集合。
在結算系統中我將所有員工分為這幾個角色，分別是財務、商務、產品運營部門主管、客戶經理（動態角色）、項目經理（動態角色）。
我將復盤在結算系統中結算流程的每一個角色的字段權限，本應該細分到字段權限里的編輯和查看權限，但由于篇幅有限，只整理每一個角色和字段之間的權限，如圖5-14。
圖5-14
數據權限采用的是管理賬戶由所有數據的權限，包括編輯、修改、添加。不同角色的數據權限如圖，這里也僅僅是討論結算系統的結算流程。
圖5-15
六、項目重難點分析
做這個項目一共經歷了４個月，剛開始接手這個結算業務的時候，個人覺得并不是很難，初步以為只要解決好訂單結算這個業務問題就行。經過業務調研之后，發現業務現存的問題還是蠻棘手的，同時要解決的業務需求很多。
由于是第一次接觸B端產品的方案設計，也缺少對業務的深刻認識，最開始的兩個星期處于停滯不前的狀態。我與產品總監交流了當時的狀況，產品總監也提供了一些解決思路，回去也看了一些B端產品的書籍，這個項目的設計才開始走向正軌。
不過在這四個月的項目設計中，還是碰到了一些問題，我在這里講述最主要的三個重難點，分別是如何準確快速地查找應結算的訂單、沒提訂單的項目怎么結算、投入產出的成本、收入、收款如何定義及生成數據。
1. 如何準確快速地查找應結算地訂單
準確快速地查找應結算的訂單可以說是結算業務最重要的業務需求也是最基本的需求，如果這個都實現不了，那么接下來的設計也進行不了，所以當時將這個需求的重要度和緊迫度都標為高優。
這個需求用大白話來說就是結算的時候不能漏掉訂單，同時操作要方便。
通過業務調研，了解到部門的訂單分為框架類和項目類。框架類訂單指的是公司與客戶簽約了框架類合同，由售前經理去談訂單，訂單上線之后，以月份或者季度為單位去收取這個月份或季度已上線的框架類訂單的錢。
項目類訂單指的是公司與客戶簽約了項目類合同，這類合同一般簽約的時候會收一部分的錢，項目類訂單全部上線之后再收剩下的錢。
經過分析，將訂單分為兩大類，如圖6-1。
圖6-1
因此要考慮后續的文本字段、數值型字段、表單哪些是兩類訂單共有的，哪些不是共有的。
在處理這個問題的時候，訂單能夠快速選擇一直是商務提的重要需求。以框架類訂單為例，怎么能確定哪些訂單是應結算的呢？在訂單管理系統中也沒有字段說明這個訂單是完成的。
那能不能在訂單系統加一個日期字段和文本字段，讓項目經理去填寫這兩個字段，那就能確定客戶的訂單是哪些完成的，哪些是沒完成的，然后在結算系統的時候聯動已完成的訂單。
這個功能上線一個月之后，經過測試發現了兩個問題，一是項目經理經常會忘記及時填寫【訂單完成】這個字段，二是以前的訂單（上線之前）沒有這個字段，無法被選擇。
在測試過程中，又發現了一個問題，訂單管理系統是產品運營部門使用的，他們對訂單的命名是以項目為單位，也就是說一個項目名稱，可能會有多個訂單。但市場部商務結算的時候是以訂單結算的，結算的時候依據項目名稱無法找到準確的應結算訂單。
經過對兩個部門的再度訪談，更加深刻理解了訂單業務?？蚣茴愑唵我话闶前丛路輥斫Y算的，第一個問題的解決思路是，通過月份的選擇，自動選出這個月的所有訂單，商務提交之后，項目經理復核時進行修改。
這樣就能解決漏選訂單，并且只要選擇月份，結算明細就會自動填充所選訂單，提高效率，交互設計圖為下圖6-2。
圖6-2
第二個問題的解決方法是，在訂單管理系統中加多一個文本字段【報價名稱】，【報價名稱】命名規定是【項目名稱＋日期】，這樣就能使得每一個訂單都是獨一無二的。商務在結算的時候通過報價名稱來選擇訂單能確保不會錯選。
圖6-3
2. 沒提訂單的項目怎么結算
通過業務調研，得知訂單的提交規則是，所有訂單都會提交在訂單管理系統。但是項目類的訂單可能還沒來得及提交訂單管理系統，這個項目就要先收一部分的錢。這種情況的話，結算系統里也找不到這個訂單，無法進行項目結算。
剛開始想設置一個虛擬訂單，結算的時候勾選這個虛擬訂單，虛擬訂單的價格自己編輯，并且能夠反向聯動到訂單管理系統里，這個訂單的提交是在結算系統里提交的。不過這個方案技術方面行不通，牽扯到兩個系統，開發難度大。
這個問題困擾了一陣，無法解決的話，結算就會漏訂單。后來的解決思路是如果這個訂單還沒在訂單管理系統上提交，結算的時候可以先漏掉，不過金額需要手動修改為全部訂單的金額。
漏掉訂單的結算單用一個字段標記，每個月底由商務檢查這些標記的結算單，去訂單管理系統查看這個訂單有沒有提交了，一旦提交了就在結算單中編輯上來，沒有則不用操作，通過人工編輯來解決漏訂單的問題。
雖然不是很智能，卻能夠順利解決事情。就目前來說，這個看起來比較笨拙的方法是最好的方法。
圖6-4
3. 投入產出的成本、收入、收款如何定義及生成數據
財務部門個月都需要整理出當月的投入產出指標，財務部的同事以前一直是用Excel去生成這個指標，不過就這一個指標以前就需要２－３天的時間來整理，因為這個指標涉及到項目的成本、人工成本、分攤成本、收入、進度、收款情況，這里的每一個數據都需要向產品運營部門的主管和市場部的主管獲取。
這個指標涉及到的數據大部分都在公司的系統上，少部分不在的需要在相應的系統里添加，所以如何跨系統增添字段而不影響原有系統也是一個難點。
經過思考，將投入產出分為三個模塊，分別是成本、收入、收款情況。
成本模塊如下圖6-5。
圖6-5
其中每類成本費用的定義和操作是：
- 薪酬等固定分配成本費用：需要設置一個薪酬等級錄入表，這個表將員工薪酬分為４個等級，避免詳細薪資曝光，財務填寫這個數據，聯動工時系統里的每個項目的工時。某個活動的工資成本=全部人員投入相加，單個人員的某個項目活動工資成本=單個人某個項目活動工時/個人總工時*工資
- 代發獎品成本：在訂單系統里增加這個獎品（不含稅、不含手續費）的成本字段，由商務在訂單管理系統里提報價的時候填寫
- 外透服務器成本：在訂單系統里增加服務器的成本字段，由商務在訂單管理系統里提報價的時候填寫
- 委托開發設計費成本：自動聯動外包系統的訂單成本（外包系統有，無須再添加）
- 推廣成本：在訂單系統里增加投放／推廣的每月實際投放／推廣的字段
- 投放成本：在訂單系統里增加投放／推廣的每月實際投放／推廣的字段
收入模塊如圖6-6所示。
圖6-6
表的一些字段的定義和操作：
- 實際工時：通過工時系統里可以得知每個項目當月的工時；
- 開發效率：人日開發效率=含稅收入/（實際工時/8）；
- 含稅收入：含稅收入＝訂單含稅金額＊進度，需要在訂單管理系統增加一個項目進度的編輯頁，每個月底由項目負責人去填寫項目進度，從而得知這個項目的當月進度；
- 不含稅收入：不含稅收入=含稅收入/（1+增值稅稅率），增值稅稅率通過財務每月去客戶數據錄入頁填寫客戶的增值稅稅率值來確定。
圖6-7
收款情況：收款情況可以在訂單管理系統里增添【流程狀態】字段，通過結算系統的流程狀態聯動訂單管理系統的每一個訂單的收款情況
七、個人收獲與總結
這是第一次接觸B端產品的設計，以前也有過C端產品設計的經驗，發現兩者還是有很多不一樣。
最開始的業務調研，B端是要針對業務問題進行訪談，梳理業務現狀，總結業務問題，目的是獲取業務需求，給出解決方案。Ｃ端則是需要市場分析、競品分析、調研問卷、深度訪談獲取用戶需求，解決用戶痛點。
B端產品和C端產品在設計上也有不同，針對性不同，在這里就不一一展開了。
通過這次的結算業務產品設計，將產品從０－１進行設計，后續通過測試和運行獲取反饋，進行迭代，使得產品落地，現在也已經投入使用。在這段經歷中，我也收獲了不少，自己也成長了不少，個人收獲如下。
- 對需求有了更深刻的認識，需求優先級、假需求這些都有了深刻體會。做產品必談需求，但又有多少人是真的懂需求呢，C端產品的需求可以用Kano模型，B端產品在收集需求時應該問問自己這四個問題：這個需求背后真正的問題是什么？這個需求有快速解決的辦法嗎？這個需求是個別需求嗎，值得花多長時間去解決？這個是共性需求，優先級如何？面對需求的時候，多問問自己這四個問題，對需求才會洞察地更加深刻。
- 對B端產品的結算方向有了經驗積累，在這次產品設計中，也更加深刻地體會到業務的重要性。對業務理解地越深刻，產品的設計才會更加高效。
- 跨部門合作鍛煉了我的溝通能力，因為結算業務需要跨系統、跨部門合作，所以同公司的所有部門都有了接觸，一番接觸下來，學會了如何同上級反饋問題、與研發交流、與產品運營部門、財務部、市場部進行訪談。這對我來說是一次大的交際挑戰，持續的溝通也讓我學會了如何更好地交流和獲取業務需求。
- 項目管理能力的提升和學習，這次的產品設計沒有項目經理來安排項目進度，靠自己來規劃項目，所以也深刻de好的項目管理能保障項目按計劃推進、落地，同時也能保障產品研發的效率和質量。
- 雖然這次我只是接手了結算項目，負責了結算系統、發票系統、投入產出系統，但將這些系統融入公司原有的架構中，我明白了一個好的企業應用架構對公司來說多么重要，只有合理地將這些系統全部融合起來，企業的業務才能全部盤活起來。
作者：蘇Eddie，微信公眾號：蘇Eddies
本文由 @蘇Eddie 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
這個只是界面系統，不是結算