和每位職場人都息息相關的，可能就是“工資”這件事兒了。那么，你知道你的“工資”是怎么發到你手里的嗎？對應的業務場景又是如何抽象轉化為產品功能的？本篇文章里，作者就圍繞“薪酬”這一基點展開了討論，并分享了他的拆解思路，或許會對你有做幫助。

這兩年我一直在想，怎樣才能把產品功能講明白，讓外行也能聽懂？怎樣才能把產品講明白，讓同行快速理解來龍去脈，讓新人快速上手？

關于這個問題，我始終覺得要把握業務場景，并通過業務場景映射到產品流程中，再結合產品思維將業務功能化，功能完整化。

所以，本文我將按照這樣的思路來聊一聊和我們打工人息息相關的“工資”這件事。全文將以常見的人力資源管理系統（E-HR）中的“薪酬”為基點展開介紹。

本文將分為三大部分：

1. 我們的工資是怎么來的；
2. 這個場景對應了哪些軟件模塊；
3. 對場景的標準化拓展。

備注：文中的系統截圖來源于“2號人事部”和“釘釘智能薪酬”，兩款我覺得在這個賽道里做得不錯的SaaS產品。如有侵權，請聯系刪除。

一、工資發放的用戶場景

張三月薪10k，其中有5k是基本工資、4k是績效工資、1k是補助，這個薪資構成是在張三入職簽合同，或者公司調薪之后確定的。

而基本工資在張三所在的企業，受月度考勤的影響。比如請假、曠工、遲到早退都會按照企業統一規則進行扣減。

他的績效工資是每月按照領導的打分結果計算，有時多、有時少。而且張三在工作期間也可能會加班、出差，這些行為可能會產生額外收入。

這樣匯集到一起，每個月會形成張三的工資表，在企業現有的薪資構成下填充不同的金額，通過公式最終得出張三的稅前工資，也叫應發工資。

之后，根據張三的應發工資以及公司最初制定的五險一金規則，為其計算對應的社保、公積金繳納金額，包括個人承擔的部分，以及企業需要承擔的部分。

五險一金計算完成之后，需要提前計算個人所得稅，按照國家規定的公式計算。

最后，張三的實發工資由應發工資扣減五險一金的個人承擔部分，再扣減個人所得稅最終形成。

以上，是一個最基礎，最常見的薪資計算流程（其他場景和規則下文會補充）。

每個企業都會有一個或多個這樣的表格，表格里記錄著企業內的各個薪資構成項（簡稱“薪酬項”），每次發薪之前，相關人員都要算一次。每一個表格，都可以稱為企業的一個“薪酬方案”（薪酬組）。

完成上述操作之后，我們僅是將張三的工資算出來了，但還沒有發到他的工資卡上。五險一金和個稅也是一樣，僅停留在數據層面，并未發生資金交易。

因此，企業的財務人員將按照不同的費用，在不同的系統上進行操作（當然，也可能是線下）。

發工資最常見的是登錄企業對公賬戶開戶行的企業網銀（或銀行提供的其他發薪軟件），將線下做好的工資表導入系統，提交發薪流程，通過一層層的審批，最終完成賬務處理。

這一步在銀行的系統里叫“批量代發（代付）”業務，看起來是直接從企業的對公賬戶將資金轉入個人工資卡，實際上里面的資金處理流程也很復雜。常見的流程有兩類：

1）企業對公賬戶——>銀行批量代付過渡戶（不要糾結名字，各家銀行叫法可能不一樣）

銀行批量代付過渡戶——>員工工資卡

2）凍結企業對公賬戶對應的發薪額度

企業對公賬戶——>員工工資卡

如果額度沒發完，再解凍。

以上兩類，雖然看起來只有幾個步驟，但其中的驗證、異常處理、反洗錢防范等流程會做的很復雜，在此不展開介紹。

到這里，張三的卡里就收到工資了。

然而員工的五險一金還沒交，企業的人事部門還要登錄各地社保系統、公積金系統進行繳納操作。

員工的個稅也沒有申報，企業的相關人員還要登錄各省的稅務系統，進行個人所得稅的申報和預扣預繳。

我們來回看一下整個流程：

然而，這只是我們當下能看到的流程，但在張三入職之前，這些規則是怎么來的？

其實，最主要的一步前置條件，應該是“確定算薪方案”，即企業要提前設置好各個薪酬項，以及薪酬項之間的計算公式、關聯關系。還要設置好五險一金的繳納規則、比例系數。

這樣在有新員工入職之后，直接將員工添加到對應的算薪方案中，才會有后面的故事。

另外，整個流程結束之后，還需要進行相關統計，如成本統計、薪資趨勢統計、薪資構成統計等等。

所以，我們最終來看一下這個場景的業務流程圖：

自此，一個簡單而標準的場景就描述完了。

二、用戶場景與產品功能的映射

用戶場景梳理完成之后，對應的每一個用戶應用節點，都將映射出產品功能。下面我們來看看這個薪酬場景都有哪些一級功能（我建議在梳理具體功能之前，先畫一張功能架構圖，以便從宏觀上認識它）。

1. 設置企業的算薪方案

這是一個規則配置的功能，包含了自定義添加規則項，采用公式編輯器維護各個規則的計算公式，并選擇數據來源。

這里需要提醒的是，大部分產品對于這種操作復雜的規則設置，會預制常用的模板，更厲害一點的，則支持Excel文件導入，自動識別里面的公式和規則項。

當然，你也看到了，這玩意一般人還真玩不明白。很多SaaS平臺的實施崗，就是幫客戶提前配置這些規則。而且總會有場景系統不支持，這時便需要“曲線救國”的策略。

2. 設置企業的社保方案

我覺得社保最大的難點在于各個城市的具體政策和系統都不一樣，所以一旦面向全國的客戶，這個功能的維護成本就會很高。

而且員工社保還會涉及到參保、停保、年度調整等環節，大多數E-HR平臺只能做到“離線計算”，無法和相關的社保局系統對接，進而導致這個功能很雞肋，數據存在不準確的情況。

另外，不同企業在社保上的繳納方案也不同，有三險、三險一金、五險、五險一金、六險一金等等。而且還會增加企業自己的限制。

比如按基本工資的80%繳納、轉正后繳納、入職一年之后繳納等等，都增加了這個功能的復雜性。

3. 同步企業花名冊信息

系統內的數據是聯動的，薪酬模塊本身只是E-HR平臺中的一部分，其中所需的基礎數據（如員工信息）都需要從其他模塊中獲取。

如果是同一個平臺，數據源是一致的，這個問題還好解決。但有些大型企業會有多個平臺，其中員工的基本信息在A系統里，薪酬或其他業務功能在B或C系統里，信息的同步變成了多個平臺之間的交互。

一旦涉及到數據源的變更，又是一個難題。

4. 定調薪

其實這個功能就是為了給企業的每個員工維護各自的薪資數據，包含哪些薪酬項是固定的，哪些是浮動的，什么時候生效等基礎規則。

因為一個企業有很多員工，所以這個功能要考慮批量設置的情景。而且要考慮這些關鍵數據修改的權限、流程。

從數據維護的角度來看，可以在頁面上操作，也可以導入文件。一旦涉及到文件導入，又將面臨格式、必輸項、數據準確性、報錯提示、錯誤修改等一系列的設計難題。

說句題外話，我覺得B端產品在不同場景下的文件導入，應該可以抽象出一個單獨的處理引擎，根據不同文件的格式設置不同的分支，將每個分支下的基礎驗證、業務驗證、錯誤提示、異常修改等流程標準化，具體的規則配置化。

這樣既能從應用層做到全局一致，也能減少設計冗余?？上н@一步，我沒有實踐成功。

5. 薪酬計算

按照上文的介紹，薪酬計算至少要分為四個步驟：計算應發、計算社保、計算個稅、計算實發。

這四個步驟是有先后順序的，而且分別需要借助多個功能的數據規則、數據結果。所以在操作上、效率上、連貫性上、以及中間過程的細項分支上，都會衍生出很多二級、三級功能和邏輯。

其實，E-HR系統下的薪酬管理，最核心的功能就是計算，我們基于如何計算向前拓展了很多個步驟，通過場景梳理和規則預設，讓系統具備快速準確計算的可能性。

當然，這里面要還要考慮性能問題，一個月計算多次的問題，中途調薪、調規則的問題，跨月的問題，出現錯誤如何預警的問題，以及數據安全性的問題等。

6. 薪資發放

因為最終的資金處理需要依托銀行的服務，所以很多系統初期沒有與銀行對接，僅將最終的算薪結果按照銀行的“網銀報盤”（其實就是上傳的Excel文件）格式導出，再由操作人員登錄到銀行系統進行導入。

但這一步在業務流程上是割裂的，所以越來越多的E-HR平臺開始和銀行合作，支持企業對公賬戶開戶行為合作銀行的企業直接進行資金處理。但因為涉及到資金的安全性、審核的嚴格性，大多數平臺這一步的連接做得并不“順滑”。

不過，近些年很多銀行也在創新相關的產品，對外提供了集發薪、算薪于一體的企業級SaaS平臺。比如招商銀行的“薪福通”產品（淺談招商銀行“薪福通”）。

另外，像社保繳納、個稅申報的環節，同樣存在多系統間割裂的問題，而作為E-HR平臺，想要拿到這些合作資源，壁壘會非常高，真正對接時將面臨的業務、技術難題也遠超想象。

因此，評估一個產品做得好不好，除了看產品所覆蓋的場景，解決的問題，帶來的體驗，還要看這款產品背后所能鏈接的資源。

在賬務處理這個層面，就不多介紹了。

7. 報表分析

線下需要統計的各類報表，我相信對于系統來說實現起來并不難，難的是如何將業務數據形成所謂的數據資產，為企業經營決策賦能？

而且本身大多數企業線下的統計維度比較簡單，真正從趨勢、對比、多維度加權整合的方向來考慮，無論是數據報表，還是可視化圖形報表，都是產品團隊需要深入研究的。

就像《數據化決策》這本書中提到，我們應該通過數據量化什么？

——量化不確定性，量化風險，量化信息價值

遺憾的是，我所見到的免費版E-HR平臺報表，還遠沒有達到這個效果。

三、對產品功能的標準化設計

從理論到落地，我覺得最難的階段，就在于標準化設計。

因為業務好理解，功能框架也容易梳理，但真正到了設計階段，面對多變、復雜的實際使用場景，如何讓自己的產品具備適應性，對產品團隊是一個極大的挑戰。

本文第一章列舉張三的例子，只是一個很小的部分。實際場景中可能涉及不同崗位、不同職級有不同的薪資構成和計算規則。尤其涉及到某些薪酬項依托于其他模塊的數據時，模塊之間的連接性、數據的可用性、規則的多變性，都需要考慮。

另外，我們只討論了固定工資的場景，很多行業都是以業績、勞動量等變化的維度計算工資。比如常見的“計件工資”、“計時工資”、“銷售提成”、“利潤分紅”等。這些場景如何在標準化設計中有效融入？

在產品設計階段，即便我們形成了可以標準化的方案，在分析細化的過程中還要考慮幾個重要的維度：異常操作、功能間的耦合性、體驗優化、拓展性配置。

1. 異常操作

用戶大概率不會按照我們預設的操作步驟進行，尤其是新用戶。

他們經常會遇到一些奇怪的問題，而這些問題大多都是因為產品設計時對于異常操作覆蓋度不夠而導致的。

比如不按照操作步驟進行，前置操作未完成時點擊后續操作。這種情況需要考慮是進行合理的提示并支持直達前置操作，還是從設計上統一入口，只能按順序執行，以避免用戶誤操作的可能性。

比如你以為一定能成功的操作，如果失敗了怎么辦？一個批量的操作如果一部分成功一部分失敗怎么辦？

比如出現了關鍵業務的并發操作，甲正在算薪，乙去把方案規則修改了怎么辦？

類似的情況有很多，預測這些異常，并找到合理的方案，這款產品的可用性才會提升。否則，上線之后團隊的大部分精力可能都在解決一個個“離奇”的問題上。

2. 功能間的耦合性

同一個功能下多個子功能之間相互聯系、相互制約。不同功能下的數據、流程也相互聯系、相互制約。同一個大生態下，不同系統之間很多數據同樣相互聯系、相互制約。

所以，在做標準化設計過程中，解決功能間的耦合性，是一個難點。

比如在薪酬場景中，給員工定薪之前，需要員工先通過人事系統將個人信息維護進來。而人事系統又會分為入、轉、調、離四個階段，不同階段對于薪酬方案都可能存在影響。

比如很多操作都需要預先配置規則，而規則之間也存在關聯。像企業給員工調薪，一般都需要審批，審批通過后才能生效。因此調薪功能就要和平臺的審批流引擎相結合。

比如計算應發時，需要獲取員工的考勤數據，又將聯動協同辦公（OA）模塊中的周期性數據，并依據規則進行計算。

正所謂“牽一發，而動全身”。

3. 體驗優化

作為B端產品，體驗一直是優先級較低但又始終繞不開的話題。小到錯誤提示是否通俗易懂，大到幫助中心是否能夠真正解決用戶的問題。

上周在和人人都是產品經理連麥直播時，也聊到了這個話題。當用戶體驗無法作為團隊內部一項重要任務時，產品團隊也應該采取“順帶手”的觀念，把細微可察覺的體驗在初始版本進行設計提升。

就像之前的文章中提到，我們曾經因為一個小小的“文件上傳”功能而優化迭代了十幾個版本，最終形成了產品初期的主打功能，讓用戶驚喜。

因為知識產權的問題，我也不會展開介紹，但我相信只要產品團隊有體驗優化的意識，結合自身情況一定能設計出一個個讓用戶驚喜的瞬間。

4. 拓展性配置

為了適應多企業的實際場景，在功能設計時需要將常見的配置項抽離出來，由企業結合自身情況進行配置。

比如算薪所需的外部數據從哪里來？企業的發薪日是幾號？計薪周期是從幾號到幾號？各個細分流程是否需要審批等。

在產品設計階段，提前把這些拓展性配置項梳理出來，再結合不同的配置結果進行細化，相當于將整個業務場景框定為不同的幾種類型，再針對不同的類型分別推演。

這些在產品設計落地過程中將要遇到的具體問題，在產品講解中也不必細化，更多是提個醒，讓我們知道即將面臨的問題有哪些，才能做足準備去逐一解決。

所以本文就聊到這里吧。

四、寫在最后

E-HR類的產品所包含的場景很多，本文主要基于“薪酬”展開，其他的像人事、招聘、考勤、協同辦公、績效、審批流等，還有很多用戶故事、產品故事。這些故事，留在以后慢慢聊吧~

寫這篇文章，一方面為了介紹這個場景，方便感興趣的朋友了解；另一方面是希望通過自己的結構和思路，幫助朋友們形成由業務場景到產品功能的轉換落地，形成主流程到業務閉環的結構化拆解思路。

如果你能有所收獲，我將十分榮幸。