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

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

關(guān)于這個問題，我始終覺得要把握業(yè)務(wù)場景，并通過業(yè)務(wù)場景映射到產(chǎn)品流程中，再結(jié)合產(chǎn)品思維將業(yè)務(wù)功能化，功能完整化。

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

本文將分為三大部分：

1. 我們的工資是怎么來的；
2. 這個場景對應(yīng)了哪些軟件模塊；
3. 對場景的標(biāo)準(zhǔn)化拓展。

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

一、工資發(fā)放的用戶場景

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

B端产品经理的能力模型与学习提升

B端产品经理面临的第一大挑战，是如何正确的分析诊断业务问题。 这也是最难的部分，产品设计知识对这部分工作基本没有帮助，如果想做好业务分析诊断，必须具备扎实 ...

查看详情 >

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

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

這樣匯集到一起，每個月會形成張三的工資表，在企業(yè)現(xiàn)有的薪資構(gòu)成下填充不同的金額，通過公式最終得出張三的稅前工資，也叫應(yīng)發(fā)工資。

之后，根據(jù)張三的應(yīng)發(fā)工資以及公司最初制定的五險一金規(guī)則，為其計算對應(yīng)的社保、公積金繳納金額，包括個人承擔(dān)的部分，以及企業(yè)需要承擔(dān)的部分。

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

最后，張三的實發(fā)工資由應(yīng)發(fā)工資扣減五險一金的個人承擔(dān)部分，再扣減個人所得稅最終形成。

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

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

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

因此，企業(yè)的財務(wù)人員將按照不同的費用，在不同的系統(tǒng)上進行操作（當(dāng)然，也可能是線下）。

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

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

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

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

2）凍結(jié)企業(yè)對公賬戶對應(yīng)的發(fā)薪額度

企業(yè)對公賬戶——>員工工資卡

如果額度沒發(fā)完，再解凍。

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

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

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

員工的個稅也沒有申報，企業(yè)的相關(guān)人員還要登錄各省的稅務(wù)系統(tǒng)，進行個人所得稅的申報和預(yù)扣預(yù)繳。

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

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

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

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

另外，整個流程結(jié)束之后，還需要進行相關(guān)統(tǒng)計，如成本統(tǒng)計、薪資趨勢統(tǒng)計、薪資構(gòu)成統(tǒng)計等等。

所以，我們最終來看一下這個場景的業(yè)務(wù)流程圖：

自此，一個簡單而標(biāo)準(zhǔn)的場景就描述完了。

二、用戶場景與產(chǎn)品功能的映射

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

1. 設(shè)置企業(yè)的算薪方案

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

這里需要提醒的是，大部分產(chǎn)品對于這種操作復(fù)雜的規(guī)則設(shè)置，會預(yù)制常用的模板，更厲害一點的，則支持Excel文件導(dǎo)入，自動識別里面的公式和規(guī)則項。

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

2. 設(shè)置企業(yè)的社保方案

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

而且員工社保還會涉及到參保、停保、年度調(diào)整等環(huán)節(jié)，大多數(shù)E-HR平臺只能做到“離線計算”，無法和相關(guān)的社保局系統(tǒng)對接，進而導(dǎo)致這個功能很雞肋，數(shù)據(jù)存在不準(zhǔn)確的情況。

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

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

3. 同步企業(yè)花名冊信息

系統(tǒng)內(nèi)的數(shù)據(jù)是聯(lián)動的，薪酬模塊本身只是E-HR平臺中的一部分，其中所需的基礎(chǔ)數(shù)據(jù)（如員工信息）都需要從其他模塊中獲取。

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

一旦涉及到數(shù)據(jù)源的變更，又是一個難題。

4. 定調(diào)薪

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

因為一個企業(yè)有很多員工，所以這個功能要考慮批量設(shè)置的情景。而且要考慮這些關(guān)鍵數(shù)據(jù)修改的權(quán)限、流程。

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

說句題外話，我覺得B端產(chǎn)品在不同場景下的文件導(dǎo)入，應(yīng)該可以抽象出一個單獨的處理引擎，根據(jù)不同文件的格式設(shè)置不同的分支，將每個分支下的基礎(chǔ)驗證、業(yè)務(wù)驗證、錯誤提示、異常修改等流程標(biāo)準(zhǔn)化，具體的規(guī)則配置化。

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

5. 薪酬計算

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

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

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

當(dāng)然，這里面要還要考慮性能問題，一個月計算多次的問題，中途調(diào)薪、調(diào)規(guī)則的問題，跨月的問題，出現(xiàn)錯誤如何預(yù)警的問題，以及數(shù)據(jù)安全性的問題等。

6. 薪資發(fā)放

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

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

不過，近些年很多銀行也在創(chuàng)新相關(guān)的產(chǎn)品，對外提供了集發(fā)薪、算薪于一體的企業(yè)級SaaS平臺。比如招商銀行的“薪福通”產(chǎn)品（淺談?wù)猩蹄y行“薪福通”）。

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

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

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

7. 報表分析

線下需要統(tǒng)計的各類報表，我相信對于系統(tǒng)來說實現(xiàn)起來并不難，難的是如何將業(yè)務(wù)數(shù)據(jù)形成所謂的數(shù)據(jù)資產(chǎn)，為企業(yè)經(jīng)營決策賦能？

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

就像《數(shù)據(jù)化決策》這本書中提到，我們應(yīng)該通過數(shù)據(jù)量化什么？

——量化不確定性，量化風(fēng)險，量化信息價值

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

三、對產(chǎn)品功能的標(biāo)準(zhǔn)化設(shè)計

從理論到落地，我覺得最難的階段，就在于標(biāo)準(zhǔn)化設(shè)計。

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

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

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

在產(chǎn)品設(shè)計階段，即便我們形成了可以標(biāo)準(zhǔn)化的方案，在分析細化的過程中還要考慮幾個重要的維度：異常操作、功能間的耦合性、體驗優(yōu)化、拓展性配置。

1. 異常操作

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

他們經(jīng)常會遇到一些奇怪的問題，而這些問題大多都是因為產(chǎn)品設(shè)計時對于異常操作覆蓋度不夠而導(dǎo)致的。

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

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

比如出現(xiàn)了關(guān)鍵業(yè)務(wù)的并發(fā)操作，甲正在算薪，乙去把方案規(guī)則修改了怎么辦？

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

2. 功能間的耦合性

同一個功能下多個子功能之間相互聯(lián)系、相互制約。不同功能下的數(shù)據(jù)、流程也相互聯(lián)系、相互制約。同一個大生態(tài)下，不同系統(tǒng)之間很多數(shù)據(jù)同樣相互聯(lián)系、相互制約。

所以，在做標(biāo)準(zhǔn)化設(shè)計過程中，解決功能間的耦合性，是一個難點。

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

比如很多操作都需要預(yù)先配置規(guī)則，而規(guī)則之間也存在關(guān)聯(lián)。像企業(yè)給員工調(diào)薪，一般都需要審批，審批通過后才能生效。因此調(diào)薪功能就要和平臺的審批流引擎相結(jié)合。

比如計算應(yīng)發(fā)時，需要獲取員工的考勤數(shù)據(jù)，又將聯(lián)動協(xié)同辦公（OA）模塊中的周期性數(shù)據(jù)，并依據(jù)規(guī)則進行計算。

正所謂“牽一發(fā)，而動全身”。

3. 體驗優(yōu)化

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

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

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

因為知識產(chǎn)權(quán)的問題，我也不會展開介紹，但我相信只要產(chǎn)品團隊有體驗優(yōu)化的意識，結(jié)合自身情況一定能設(shè)計出一個個讓用戶驚喜的瞬間。

4. 拓展性配置

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

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

在產(chǎn)品設(shè)計階段，提前把這些拓展性配置項梳理出來，再結(jié)合不同的配置結(jié)果進行細化，相當(dāng)于將整個業(yè)務(wù)場景框定為不同的幾種類型，再針對不同的類型分別推演。

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

所以本文就聊到這里吧。

四、寫在最后

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

寫這篇文章，一方面為了介紹這個場景，方便感興趣的朋友了解；另一方面是希望通過自己的結(jié)構(gòu)和思路，幫助朋友們形成由業(yè)務(wù)場景到產(chǎn)品功能的轉(zhuǎn)換落地，形成主流程到業(yè)務(wù)閉環(huán)的結(jié)構(gòu)化拆解思路。

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