業(yè)財(cái)稅一體化是一種將業(yè)務(wù)流程、財(cái)務(wù)會(huì)計(jì)與稅務(wù)申報(bào)緊密結(jié)合的管理模式。通過(guò)高度的信息系統(tǒng)整合，實(shí)現(xiàn)數(shù)據(jù)共享和流程優(yōu)化，從而提升企業(yè)的效率和合規(guī)性。本文將從業(yè)務(wù)的角度出發(fā)，讓您認(rèn)清整體系統(tǒng)的本質(zhì)，以實(shí)際的業(yè)務(wù)訴求切入，一步步的構(gòu)建出一套完整的B端系統(tǒng)框架。

回顧上篇文章，我們講解了如何搭建系統(tǒng)總架構(gòu)，如下圖：

所以在本篇及之后的文章將繼續(xù)為大家講解系統(tǒng)里具體功能模塊該如何設(shè)計(jì)。

一、本次設(shè)計(jì)的模塊

按照目標(biāo)用戶(hù)（暫以代賬行業(yè)企業(yè)為目標(biāo)用戶(hù)）使用系統(tǒng)的順序來(lái)看，創(chuàng)建人員賬號(hào)和授予權(quán)限是所有操作的初始步驟，所以本次要設(shè)計(jì)的是《基礎(chǔ)服務(wù)層》的【用戶(hù)管理】和【權(quán)限管理】

二、設(shè)計(jì)流程

業(yè)務(wù)模塊從無(wú)到有的設(shè)計(jì)過(guò)程中，產(chǎn)品經(jīng)理是有一套標(biāo)準(zhǔn)范式可以遵循的：

1. 調(diào)研階段

1）業(yè)務(wù)調(diào)研：

• 用戶(hù)需求調(diào)研：收集目標(biāo)用戶(hù)的需求、偏好、痛點(diǎn)和使用習(xí)慣。
• 競(jìng)品調(diào)研：若市面上有成熟產(chǎn)品，還可研究競(jìng)品的產(chǎn)品功能、定價(jià)策略、市場(chǎng)占有率、用戶(hù)評(píng)價(jià)，識(shí)別產(chǎn)品優(yōu)劣勢(shì)。

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

2）初步方案：

• 信息整合：將調(diào)研得到的信息進(jìn)行整合，明確產(chǎn)品要解決的問(wèn)題和要滿(mǎn)足的需求。
• 把握核心：優(yōu)先考慮對(duì)用戶(hù)最有影響的核心業(yè)務(wù)，確定產(chǎn)品的核心功能。

2. 整體方案設(shè)計(jì)

1）產(chǎn)品功能定位：

• 結(jié)合調(diào)研的用戶(hù)訴求和初步方案，確定功能點(diǎn)并進(jìn)行優(yōu)先級(jí)排序
• 確定最小可行性產(chǎn)品的范圍

2）產(chǎn)品演進(jìn)藍(lán)圖：

• 并非所有產(chǎn)品都需要此步驟，一般是戰(zhàn)略周期較長(zhǎng)，功能繁多的產(chǎn)品才需要演進(jìn)藍(lán)圖。
• 在繪制演進(jìn)藍(lán)圖過(guò)程中，需要規(guī)劃未來(lái)的功能迭代，包括新功能的推出和現(xiàn)有功能的優(yōu)化。為規(guī)劃中的功能和迭代制定優(yōu)先級(jí)，考慮市場(chǎng)需求、用戶(hù)影響、技術(shù)可行性和資源限制。

3）梳理業(yè)務(wù)流程：

• 梳理各個(gè)用戶(hù)角色的數(shù)據(jù)權(quán)限和功能權(quán)限。
• 梳理主體業(yè)務(wù)流程，業(yè)務(wù)承載頁(yè)面。
• 考慮如何與已有系統(tǒng)功能拼接，交互。

4）提煉數(shù)據(jù)模型：

• 將業(yè)務(wù)的核心數(shù)據(jù)對(duì)象特征進(jìn)行提煉，歸納并設(shè)計(jì)對(duì)應(yīng)的底層數(shù)據(jù)模型。

（三）細(xì)節(jié)方案設(shè)計(jì)：

1）設(shè)計(jì)頁(yè)面原型：

• 按照梳理的業(yè)務(wù)流程和數(shù)據(jù)模型進(jìn)行頁(yè)面原型繪制，常用的原型繪制工具有axure、即時(shí)設(shè)計(jì)、Sketch等
• 原型上可根據(jù)需要適當(dāng)增加注釋?zhuān)敢?，方便后續(xù)階段研發(fā)人員理解

2）設(shè)計(jì)具體功能點(diǎn)：

• 設(shè)計(jì)各功能按鈕、列表等組件，并根據(jù)正向、反向的業(yè)務(wù)流程增加交互彈窗、提示語(yǔ)
• 設(shè)計(jì)具體功能點(diǎn)時(shí)可同時(shí)繪制相關(guān)UML圖，用于理清用戶(hù)不同操作場(chǎng)景，以及與其他功能模塊的交互，避免邏輯性缺失。

3）梳理各產(chǎn)品/模塊關(guān)聯(lián)關(guān)系

• 在系統(tǒng)每增加一個(gè)功能模塊，都需要考慮新舊模塊之間增刪改查的聯(lián)動(dòng)關(guān)系和數(shù)據(jù)影響（后面文章中會(huì)提到）
• 梳理各模塊關(guān)聯(lián)關(guān)系建議以思維導(dǎo)圖的形式數(shù)據(jù)，因?yàn)橐运季S導(dǎo)圖的形式可以充分體現(xiàn)信息間的“擴(kuò)展性”、“關(guān)聯(lián)度”和“結(jié)構(gòu)化”，這一點(diǎn)是文字、表格或圖示替代不了的。

4）輸出原型、UML圖、PRD文檔等

• 輸出繪制的原型稿、流程圖、狀態(tài)機(jī)圖等說(shuō)明性圖示，便于研發(fā)人員理解業(yè)務(wù)（這一步很重要，因?yàn)檠邪l(fā)人員對(duì)產(chǎn)品需求的理解性越高，產(chǎn)品的穩(wěn)健性越強(qiáng)）
• PRD文檔，是產(chǎn)品需求的詳細(xì)說(shuō)明書(shū)，因?yàn)槭翘峁┙o研發(fā)人員和測(cè)試人員的文檔，所以編寫(xiě)時(shí)需要注重可閱讀性，且文檔邏輯前后形成閉環(huán)，不能出現(xiàn)概括性，有偏差性語(yǔ)言。

（四）研發(fā)發(fā)布、運(yùn)營(yíng)維護(hù)：

研發(fā)發(fā)布和運(yùn)營(yíng)維護(hù)屬于產(chǎn)品設(shè)計(jì)完成后的流程，因本篇主要講解設(shè)計(jì)環(huán)節(jié)，所以這兩個(gè)流程暫不做贅述。

三、【用戶(hù)】與【權(quán)限】模塊如何設(shè)計(jì)？

不僅是業(yè)財(cái)稅系統(tǒng)，任何系統(tǒng)的最初設(shè)計(jì)大都是從【用戶(hù)】與【權(quán)限】開(kāi)始，畢竟沒(méi)有創(chuàng)建用戶(hù)賬號(hào)和密碼，用戶(hù)如何登錄系統(tǒng)呢？

接下來(lái)，讓我們按照上述流程來(lái)設(shè)計(jì)這兩個(gè)模塊，首先是調(diào)研階段，早在設(shè)計(jì)系統(tǒng)整體架構(gòu)前，就應(yīng)該對(duì)目標(biāo)客戶(hù)進(jìn)行充分調(diào)研，此處可先略過(guò)調(diào)研階段，假設(shè)已調(diào)研完成，需要進(jìn)行整體方案設(shè)計(jì)。

以虛構(gòu)企業(yè)“北京小橙子代賬公司”為案例。背景如下：

• 北京小橙子代賬公司經(jīng)營(yíng)多年，在全國(guó)開(kāi)設(shè)分公司，主營(yíng)代理記賬，報(bào)稅及其他工商管理的工作。公司業(yè)務(wù)部門(mén)按照華東、華南、華西、華北四個(gè)大區(qū)進(jìn)行劃分，且每個(gè)業(yè)務(wù)部門(mén)下又按具體城市劃分二級(jí)部門(mén)，再往下又按照具體職能劃分為各個(gè)小組。
• 因人員流動(dòng)性大，且記賬報(bào)稅業(yè)務(wù)量增大的原因，本次要定做一套業(yè)財(cái)稅系統(tǒng)，專(zhuān)給業(yè)務(wù)部門(mén)使用，實(shí)現(xiàn)數(shù)據(jù)共享和流程優(yōu)化，從而提升企業(yè)的效率和合規(guī)性。

1. 整體方案設(shè)計(jì)

1）產(chǎn)品功能定位

根據(jù)整體調(diào)研結(jié)論，總結(jié)出以下功能定位

• 用戶(hù)創(chuàng)建與登錄（高優(yōu)）
• 用戶(hù)分配角色（高優(yōu)）
• 用戶(hù)權(quán)限管理（高優(yōu)）
• 用戶(hù)資料管理（高優(yōu)）
• 用戶(hù)部門(mén)管理（高優(yōu)）
• 用戶(hù)崗位管理（中優(yōu)）
• 用戶(hù)調(diào)崗（低優(yōu)）
• 用戶(hù)離職（低優(yōu)）

產(chǎn)品經(jīng)理應(yīng)優(yōu)先聚焦核心業(yè)務(wù)流程，將其作為主要訴求，而將擴(kuò)展功能和小眾需求列為次級(jí)訴求，以此與業(yè)務(wù)部門(mén)保持一致，確保從高到低實(shí)現(xiàn)核心流程。

2）產(chǎn)品演進(jìn)藍(lán)圖

用戶(hù)與權(quán)限模塊并不復(fù)雜，無(wú)需分期研發(fā)，此步驟可忽略

3）梳理業(yè)務(wù)流程

根據(jù)調(diào)研結(jié)果和產(chǎn)品功能定位，梳理出以下幾個(gè)業(yè)務(wù)流程

（1）系統(tǒng)管理員創(chuàng)建各部門(mén)負(fù)責(zé)人的賬號(hào)并分配角色權(quán)限，再由各部門(mén)負(fù)責(zé)人給本部門(mén)員工創(chuàng)建賬號(hào)，并分配角色權(quán)限。

（2）部門(mén)員工離職，需先進(jìn)行工作交接，把自己負(fù)責(zé)的客戶(hù)轉(zhuǎn)交給其他員工，才可提交離職申請(qǐng)，由部門(mén)負(fù)責(zé)人審批后進(jìn)行離職，并注銷(xiāo)賬號(hào)。

若員工無(wú)負(fù)責(zé)的客戶(hù)，則可以直接進(jìn)行離職，略過(guò)工作交接的步驟。

這里給大家留2個(gè)小問(wèn)題，歡迎大家評(píng)論區(qū)留言：

1. 工作交接可以同時(shí)交接給多人，以下是假設(shè)交接人為1位的流程圖，大家可以考慮一下若有多個(gè)交接人（甲、乙、丙），其中有人同意交接，有人不同意交接，如此業(yè)務(wù)流程該如何流轉(zhuǎn)呢？
2. 若離職人恰好就是部門(mén)負(fù)責(zé)人或系統(tǒng)管理員，則審批人該如何確定呢？

（3）部門(mén)員工調(diào)崗，由部門(mén)負(fù)責(zé)人變更部門(mén)或崗位，若被調(diào)崗人需要工作交接，則先進(jìn)行工作交接，交接完成后進(jìn)行變更。若被調(diào)崗人無(wú)需工作交接，可直接變更。

根據(jù)上述3個(gè)業(yè)務(wù)流程，可以分析得出

權(quán)限：

• 系統(tǒng)管理員：擁有系統(tǒng)所有功能權(quán)限和數(shù)據(jù)權(quán)限。
• 部門(mén)負(fù)責(zé)人：擁有部分功能權(quán)限，擁有本部門(mén)員工的數(shù)據(jù)權(quán)限，可以創(chuàng)建賬號(hào)、查看普通員工的個(gè)人資料、給員工恢復(fù)初始密碼、有權(quán)為員工分配部門(mén)/崗位、有權(quán)審批員工發(fā)起的各類(lèi)申請(qǐng)等。
• 普通員工：權(quán)限較低，僅擁有個(gè)人的數(shù)據(jù)權(quán)限。部分操作需要申請(qǐng)通過(guò)后才可操作，例如進(jìn)行工作交接時(shí)需被交接人同意才可進(jìn)行交接；申請(qǐng)離職時(shí)也需向部門(mén)負(fù)責(zé)人發(fā)送申請(qǐng)。

業(yè)務(wù)承載頁(yè)面：

• 系統(tǒng)登錄頁(yè)面：用戶(hù)登錄門(mén)戶(hù)，需錄入登錄賬號(hào)與密碼
• 用戶(hù)管理頁(yè)面：部門(mén)，崗位及人員匯總頁(yè)面
• 新增人員頁(yè)面：也可以適用編輯人員頁(yè)面
• 權(quán)限管理頁(yè)面：管理不同角色及角色對(duì)應(yīng)的權(quán)限
• 新增角色頁(yè)面：也可以適用編輯角色頁(yè)面
• 消息頁(yè)面：接受各類(lèi)申請(qǐng)消息，審批消息
• 工作交接彈窗：將客戶(hù)轉(zhuǎn)移給其他員工
• 離職申請(qǐng)彈窗：發(fā)送離職申請(qǐng)給指定部門(mén)負(fù)責(zé)人/系統(tǒng)管理員

4）提煉數(shù)據(jù)模型

實(shí)體建模是信息系統(tǒng)設(shè)計(jì)中的關(guān)鍵步驟，它涉及將現(xiàn)實(shí)世界中的實(shí)體及其相互關(guān)系轉(zhuǎn)換為抽象的模型，以便在計(jì)算機(jī)系統(tǒng)中表示和處理。一個(gè)清晰且合理的實(shí)體模型為后續(xù)的功能設(shè)計(jì)和用戶(hù)界面設(shè)計(jì)提供了堅(jiān)實(shí)的基礎(chǔ)。如果實(shí)體建模有問(wèn)題，可能會(huì)導(dǎo)致后續(xù)業(yè)務(wù)和系統(tǒng)無(wú)法擴(kuò)展或失去靈活性。因此，在進(jìn)行實(shí)體建模時(shí)，我們需要仔細(xì)考慮各種因素，并確保模型能夠準(zhǔn)確地反映現(xiàn)實(shí)世界中的對(duì)象和關(guān)系。

以下是實(shí)體建模的設(shè)計(jì)思路，我們將通過(guò)案例來(lái)詳細(xì)說(shuō)明：

（1）建立客戶(hù)模型

首先，和業(yè)務(wù)方（小橙子公司）溝通確認(rèn)，一期暫不支持復(fù)雜的行政層級(jí)管理，只需要給業(yè)務(wù)部門(mén)實(shí)現(xiàn)若干子賬號(hào)可以管理企業(yè)內(nèi)部客戶(hù)即可。這里可以識(shí)別出是典型的樹(shù)形組織機(jī)構(gòu)管理訴求：

• 每個(gè)業(yè)務(wù)部門(mén)都可以下設(shè)分級(jí)部門(mén)，但有層級(jí)限制
• 部門(mén)與客戶(hù)無(wú)關(guān)
• 每個(gè)部門(mén)必須綁定員工，員工可不綁定客戶(hù)
• 一個(gè)部門(mén)可以綁定多個(gè)員工，但一個(gè)員工不可綁定多個(gè)部門(mén)
• 一個(gè)員工可以綁定多個(gè)客戶(hù)，且一個(gè)客戶(hù)可以綁定多個(gè)員工

我們先將業(yè)務(wù)部門(mén)、員工、客戶(hù)的關(guān)系以組織機(jī)構(gòu)樹(shù)的形式來(lái)表示。

將“員工”轉(zhuǎn)變?yōu)椤坝脩?hù)”的概念，接著梳理用戶(hù)、角色、權(quán)限的關(guān)系，在此使用RBAC權(quán)限模型 ，RBAC權(quán)限模型是功能權(quán)限設(shè)計(jì)的經(jīng)典方法論，描述了一套用戶(hù)、角色、權(quán)限組的設(shè)計(jì)理念，該理論具體的講解，讀者可在網(wǎng)絡(luò)上自行查閱

• 每個(gè)用戶(hù)可以對(duì)應(yīng)多個(gè)角色
• 每個(gè)角色可以對(duì)應(yīng)多個(gè)權(quán)限
• 角色與部門(mén)，客戶(hù)無(wú)關(guān)

• 每個(gè)角色擁有的許可和約束是有限的
• 每個(gè)用戶(hù)在會(huì)話(huà)時(shí)只能使用1個(gè)角色

（2）劃分?jǐn)?shù)據(jù)領(lǐng)域

按照用戶(hù)、角色、部門(mén)三個(gè)維度劃分各個(gè)業(yè)務(wù)域，每個(gè)業(yè)務(wù)域按照業(yè)務(wù)過(guò)程梳理業(yè)務(wù)數(shù)據(jù)。

• 業(yè)務(wù)域：指具體的業(yè)務(wù)范圍
• 業(yè)務(wù)過(guò)程：指業(yè)務(wù)活動(dòng)系列事件
• 業(yè)務(wù)數(shù)據(jù)：在業(yè)務(wù)流程中產(chǎn)生和使用的各類(lèi)數(shù)據(jù)

B. 角色權(quán)限

C. 部門(mén)

（3）實(shí)體建模ER圖

通過(guò)客戶(hù)模型和數(shù)據(jù)領(lǐng)域劃分，我們梳理出了需要用到的業(yè)務(wù)數(shù)據(jù)，接下來(lái)可以通過(guò)實(shí)體建模ER圖，描述出這幾類(lèi)業(yè)務(wù)數(shù)據(jù)的關(guān)系，這有助于后期原型繪制時(shí)的業(yè)務(wù)流轉(zhuǎn)和設(shè)計(jì)限制規(guī)則。

例如“一個(gè)部門(mén)可以綁定多個(gè)員工，但一個(gè)員工不可綁定多個(gè)部門(mén)”，在這個(gè)1對(duì)N的關(guān)系下，系統(tǒng)界面設(shè)計(jì)就需要增加限制，在為員工選部門(mén)時(shí)，不支持多部門(mén)的選擇；在部門(mén)內(nèi)創(chuàng)建人員時(shí)，不可選擇其他部門(mén)的人員。

實(shí)體建模中權(quán)限可分為【菜單資源資源】和【數(shù)據(jù)資源權(quán)限】

• 菜單資源權(quán)限：指不同角色可以操作的界面、按鈕等等，例如部門(mén)負(fù)責(zé)人可以看到《權(quán)限設(shè)置》頁(yè)面，可以操作「部門(mén)」按鈕，「角色」按鈕，而普通員工則無(wú)法查看《權(quán)限設(shè)置》頁(yè)面，無(wú)法操作「部門(mén)」、「角色」按鈕。
• 數(shù)據(jù)資源權(quán)限：指不同角色在同一頁(yè)面中看到的數(shù)據(jù)范圍，例如部門(mén)負(fù)責(zé)人可以看到本部門(mén)所有員工的人員資料，而普通員工只可以看到自己的人員資料。

到這一步，整體方案設(shè)計(jì)已經(jīng)完成，可以在此基礎(chǔ)上，進(jìn)行細(xì)節(jié)方案設(shè)計(jì)。

2. 細(xì)節(jié)方案設(shè)計(jì)

1）設(shè)計(jì)頁(yè)面原型

（1）繪制原型時(shí)的注意事項(xiàng)

原型設(shè)計(jì)需建立自己獨(dú)特的規(guī)范，原型規(guī)范化的主要優(yōu)勢(shì)在于提升信息傳遞的效率。人類(lèi)天生被視覺(jué)所吸引，美觀的設(shè)計(jì)往往容易吸引人們的注意力，而混亂的設(shè)計(jì)則直接令人感覺(jué)到邏輯不清。

在系統(tǒng)搭建初期，產(chǎn)品經(jīng)理可以預(yù)設(shè)一套完整的界面樣式規(guī)則，包括彈窗樣式、列表樣式、標(biāo)簽元素、頁(yè)面布局、提示語(yǔ)樣式等，按照這些規(guī)則作為通用模板。

不過(guò)，原型設(shè)計(jì)與ui設(shè)計(jì)不同，我們無(wú)需過(guò)分關(guān)注到每個(gè)像素的細(xì)節(jié)。設(shè)置原型規(guī)則是為了我們有個(gè)繪圖標(biāo)準(zhǔn)，更快速的傳遞信息。若花費(fèi)心思鉆研每個(gè)按鈕的擺放位置，每個(gè)元素的排版，每種顏色的搭配，豈不是本末倒置！

（2）原型規(guī)范

建議繪制時(shí)只以黑、白、灰三種顏色進(jìn)行繪制，如此可不用在配色上做過(guò)多糾結(jié)。在此分享幾個(gè)本人常用的原型規(guī)范。

①二次確認(rèn)彈窗

②批量修改彈窗

③導(dǎo)入失敗頁(yè)面

④任務(wù)執(zhí)行結(jié)果彈窗

⑤當(dāng)頁(yè)面按鈕超過(guò)3個(gè)時(shí)，組合按鈕

2）設(shè)計(jì)具體功能點(diǎn)

按照前期的整體方案設(shè)計(jì)，我們結(jié)合產(chǎn)品功能定位、業(yè)務(wù)流程和實(shí)體建模ER圖，便可以設(shè)計(jì)每個(gè)信息承載頁(yè)面的功能按鈕和交互。

以《角色總覽》列表區(qū)域?yàn)槔?/p>

同時(shí)還需要增加數(shù)據(jù)權(quán)限：

3）梳理各模塊關(guān)聯(lián)關(guān)系

目前系統(tǒng)暫無(wú)其他模塊，此步驟可先忽略

4）輸出各類(lèi)文檔和圖示

結(jié)合前面方案設(shè)計(jì)過(guò)程中繪制的各類(lèi)圖示，再加上對(duì)每個(gè)功能點(diǎn)的詳細(xì)說(shuō)明，就可以產(chǎn)出PRD文檔，當(dāng)業(yè)務(wù)規(guī)則復(fù)雜時(shí)，可以在文檔中適當(dāng)列舉案例，便于開(kāi)發(fā)人員和測(cè)試人員的需求理解。

另外PRD文檔的目錄需要層級(jí)劃分清晰，至少包含以下幾點(diǎn)：

• 文檔記錄：記錄文檔創(chuàng)建、修改的情況，文檔的編寫(xiě)狀態(tài)，編寫(xiě)人示例。
• 文檔修訂記錄：記錄每次修改的修改內(nèi)容，更詳細(xì)的進(jìn)行記錄每次修改的情況，對(duì)修改情況做概要性的描述。
• 概述：背景介紹、涉及范圍、閱讀對(duì)象和名詞解釋。
• 結(jié)構(gòu)圖：功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖、業(yè)務(wù)流程圖等
• 功能概要：根據(jù)功能結(jié)構(gòu)圖而來(lái)，控制好級(jí)別，并進(jìn)一步描述功能的內(nèi)容和作用。
• 功能詳細(xì)說(shuō)明：詳細(xì)列出發(fā)布所需的所有功能，每項(xiàng)功能應(yīng)有對(duì)應(yīng)的用例說(shuō)明用戶(hù)如何使用該功能；以及功能使用時(shí)的限制條件和依賴(lài)關(guān)系
• 非功能需求：描述功能模塊的質(zhì)量屬性，如可靠性、可維護(hù)性、可擴(kuò)展性和性能等

此外，在具體實(shí)踐中，產(chǎn)品經(jīng)理需要根據(jù)實(shí)際的產(chǎn)品類(lèi)型和組織習(xí)慣來(lái)適配或調(diào)整PRD的內(nèi)容和結(jié)構(gòu)。無(wú)論何種形式，都要確保PRD能夠明確地描述產(chǎn)品的功能需求，以便于團(tuán)隊(duì)成員理解和執(zhí)行。