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

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

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

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

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

二、設(shè)計流程

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

1. 調(diào)研階段

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

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

2）初步方案：

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

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

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

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

2）產(chǎn)品演進藍圖：

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

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

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

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

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

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

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

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

2）設(shè)計具體功能點：

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

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

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

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

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

（四）研發(fā)發(fā)布、運營維護：

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

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

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

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

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

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

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

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

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

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

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

2）產(chǎn)品演進藍圖

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

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

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

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

（2）部門員工離職，需先進行工作交接，把自己負責的客戶轉(zhuǎn)交給其他員工，才可提交離職申請，由部門負責人審批后進行離職，并注銷賬號。

若員工無負責的客戶，則可以直接進行離職，略過工作交接的步驟。

這里給大家留2個小問題，歡迎大家評論區(qū)留言：

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

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

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

權(quán)限：

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

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

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

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

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

以下是實體建模的設(shè)計思路，我們將通過案例來詳細說明：

（1）建立客戶模型

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

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

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

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

• 每個用戶可以對應(yīng)多個角色
• 每個角色可以對應(yīng)多個權(quán)限
• 角色與部門，客戶無關(guān)

• 每個角色擁有的許可和約束是有限的
• 每個用戶在會話時只能使用1個角色

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

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

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

B. 角色權(quán)限

C. 部門

（3）實體建模ER圖

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

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

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

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

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

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

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

（1）繪制原型時的注意事項

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

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

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

（2）原型規(guī)范

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

①二次確認彈窗

②批量修改彈窗

③導入失敗頁面

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

⑤當頁面按鈕超過3個時，組合按鈕

2）設(shè)計具體功能點

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

以《角色總覽》列表區(qū)域為例：

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

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

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

4）輸出各類文檔和圖示

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

另外PRD文檔的目錄需要層級劃分清晰，至少包含以下幾點：

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

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