起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識漫談業財稅一體系化建設2 –用戶與權限
業財稅一體化是一種將業務流程、財務會計與稅務申報緊密結合的管理模式。通過高度的信息系統整合，實現數據共享和流程優化，從而提升企業的效率和合規性。本文將從業務的角度出發，讓您認清整體系統的本質，以實際的業務訴求切入，一步步的構建出一套完整的B端系統框架。
回顧上篇文章，我們講解了如何搭建系統總架構，如下圖：
所以在本篇及之后的文章將繼續為大家講解系統里具體功能模塊該如何設計。
一、本次設計的模塊
按照目標用戶（暫以代賬行業企業為目標用戶）使用系統的順序來看，創建人員賬號和授予權限是所有操作的初始步驟，所以本次要設計的是《基礎服務層》的【用戶管理】和【權限管理】
二、設計流程
業務模塊從無到有的設計過程中，產品經理是有一套標準范式可以遵循的：
1. 調研階段
1）業務調研：
- 用戶需求調研：收集目標用戶的需求、偏好、痛點和使用習慣。
- 競品調研：若市面上有成熟產品，還可研究競品的產品功能、定價策略、市場占有率、用戶評價，識別產品優劣勢。
2）初步方案：
- 信息整合：將調研得到的信息進行整合，明確產品要解決的問題和要滿足的需求。
- 把握核心：優先考慮對用戶最有影響的核心業務，確定產品的核心功能。
2. 整體方案設計
1）產品功能定位：
- 結合調研的用戶訴求和初步方案，確定功能點并進行優先級排序
- 確定最小可行性產品的范圍
2）產品演進藍圖：
- 并非所有產品都需要此步驟，一般是戰略周期較長，功能繁多的產品才需要演進藍圖。
- 在繪制演進藍圖過程中，需要規劃未來的功能迭代，包括新功能的推出和現有功能的優化。為規劃中的功能和迭代制定優先級，考慮市場需求、用戶影響、技術可行性和資源限制。
3）梳理業務流程：
- 梳理各個用戶角色的數據權限和功能權限。
- 梳理主體業務流程，業務承載頁面。
- 考慮如何與已有系統功能拼接，交互。
4）提煉數據模型：
- 將業務的核心數據對象特征進行提煉，歸納并設計對應的底層數據模型。
（三）細節方案設計：
1）設計頁面原型：
- 按照梳理的業務流程和數據模型進行頁面原型繪制，常用的原型繪制工具有axure、即時設計、Sketch等
- 原型上可根據需要適當增加注釋，指引等，方便后續階段研發人員理解
2）設計具體功能點：
- 設計各功能按鈕、列表等組件，并根據正向、反向的業務流程增加交互彈窗、提示語
- 設計具體功能點時可同時繪制相關UML圖，用于理清用戶不同操作場景，以及與其他功能模塊的交互，避免邏輯性缺失。
3）梳理各產品/模塊關聯關系
- 在系統每增加一個功能模塊，都需要考慮新舊模塊之間增刪改查的聯動關系和數據影響（后面文章中會提到）
- 梳理各模塊關聯關系建議以思維導圖的形式數據，因為以思維導圖的形式可以充分體現信息間的“擴展性”、“關聯度”和“結構化”，這一點是文字、表格或圖示替代不了的。
4）輸出原型、UML圖、PRD文檔等
- 輸出繪制的原型稿、流程圖、狀態機圖等說明性圖示，便于研發人員理解業務（這一步很重要，因為研發人員對產品需求的理解性越高，產品的穩健性越強）
- PRD文檔，是產品需求的詳細說明書，因為是提供給研發人員和測試人員的文檔，所以編寫時需要注重可閱讀性，且文檔邏輯前后形成閉環，不能出現概括性，有偏差性語言。
（四）研發發布、運營維護：
研發發布和運營維護屬于產品設計完成后的流程，因本篇主要講解設計環節，所以這兩個流程暫不做贅述。
三、【用戶】與【權限】模塊如何設計？
不僅是業財稅系統，任何系統的最初設計大都是從【用戶】與【權限】開始，畢竟沒有創建用戶賬號和密碼，用戶如何登錄系統呢？
接下來，讓我們按照上述流程來設計這兩個模塊，首先是調研階段，早在設計系統整體架構前，就應該對目標客戶進行充分調研，此處可先略過調研階段，假設已調研完成，需要進行整體方案設計。
以虛構企業“北京小橙子代賬公司”為案例。背景如下：
- 北京小橙子代賬公司經營多年，在全國開設分公司，主營代理記賬，報稅及其他工商管理的工作。公司業務部門按照華東、華南、華西、華北四個大區進行劃分，且每個業務部門下又按具體城市劃分二級部門，再往下又按照具體職能劃分為各個小組。
- 因人員流動性大，且記賬報稅業務量增大的原因，本次要定做一套業財稅系統，專給業務部門使用，實現數據共享和流程優化，從而提升企業的效率和合規性。
1. 整體方案設計
1）產品功能定位
根據整體調研結論，總結出以下功能定位
- 用戶創建與登錄（高優）
- 用戶分配角色（高優）
- 用戶權限管理（高優）
- 用戶資料管理（高優）
- 用戶部門管理（高優）
- 用戶崗位管理（中優）
- 用戶調崗（低優）
- 用戶離職（低優）
產品經理應優先聚焦核心業務流程，將其作為主要訴求，而將擴展功能和小眾需求列為次級訴求，以此與業務部門保持一致，確保從高到低實現核心流程。
2）產品演進藍圖
用戶與權限模塊并不復雜，無需分期研發，此步驟可忽略
3）梳理業務流程
根據調研結果和產品功能定位，梳理出以下幾個業務流程
（1）系統管理員創建各部門負責人的賬號并分配角色權限，再由各部門負責人給本部門員工創建賬號，并分配角色權限。
（2）部門員工離職，需先進行工作交接，把自己負責的客戶轉交給其他員工，才可提交離職申請，由部門負責人審批后進行離職，并注銷賬號。
若員工無負責的客戶，則可以直接進行離職，略過工作交接的步驟。
這里給大家留2個小問題，歡迎大家評論區留言：
- 工作交接可以同時交接給多人，以下是假設交接人為1位的流程圖，大家可以考慮一下若有多個交接人（甲、乙、丙），其中有人同意交接，有人不同意交接，如此業務流程該如何流轉呢？
- 若離職人恰好就是部門負責人或系統管理員，則審批人該如何確定呢？
（3）部門員工調崗，由部門負責人變更部門或崗位，若被調崗人需要工作交接，則先進行工作交接，交接完成后進行變更。若被調崗人無需工作交接，可直接變更。
根據上述3個業務流程，可以分析得出
權限：
- 系統管理員：擁有系統所有功能權限和數據權限。
- 部門負責人：擁有部分功能權限，擁有本部門員工的數據權限，可以創建賬號、查看普通員工的個人資料、給員工恢復初始密碼、有權為員工分配部門/崗位、有權審批員工發起的各類申請等。
- 普通員工：權限較低，僅擁有個人的數據權限。部分操作需要申請通過后才可操作，例如進行工作交接時需被交接人同意才可進行交接；申請離職時也需向部門負責人發送申請。
業務承載頁面：
- 系統登錄頁面：用戶登錄門戶，需錄入登錄賬號與密碼
- 用戶管理頁面：部門，崗位及人員匯總頁面
- 新增人員頁面：也可以適用編輯人員頁面
- 權限管理頁面：管理不同角色及角色對應的權限
- 新增角色頁面：也可以適用編輯角色頁面
- 消息頁面：接受各類申請消息，審批消息
- 工作交接彈窗：將客戶轉移給其他員工
- 離職申請彈窗：發送離職申請給指定部門負責人/系統管理員
4）提煉數據模型
實體建模是信息系統設計中的關鍵步驟，它涉及將現實世界中的實體及其相互關系轉換為抽象的模型，以便在計算機系統中表示和處理。一個清晰且合理的實體模型為后續的功能設計和用戶界面設計提供了堅實的基礎。如果實體建模有問題，可能會導致后續業務和系統無法擴展或失去靈活性。因此，在進行實體建模時，我們需要仔細考慮各種因素，并確保模型能夠準確地反映現實世界中的對象和關系。
以下是實體建模的設計思路，我們將通過案例來詳細說明：
（1）建立客戶模型
首先，和業務方（小橙子公司）溝通確認，一期暫不支持復雜的行政層級管理，只需要給業務部門實現若干子賬號可以管理企業內部客戶即可。這里可以識別出是典型的樹形組織機構管理訴求：
- 每個業務部門都可以下設分級部門，但有層級限制
- 部門與客戶無關
- 每個部門必須綁定員工，員工可不綁定客戶
- 一個部門可以綁定多個員工，但一個員工不可綁定多個部門
- 一個員工可以綁定多個客戶，且一個客戶可以綁定多個員工
我們先將業務部門、員工、客戶的關系以組織機構樹的形式來表示。
將“員工”轉變為“用戶”的概念，接著梳理用戶、角色、權限的關系，在此使用RBAC權限模型 ，RBAC權限模型是功能權限設計的經典方法論，描述了一套用戶、角色、權限組的設計理念，該理論具體的講解，讀者可在網絡上自行查閱
- 每個用戶可以對應多個角色
- 每個角色可以對應多個權限
- 角色與部門，客戶無關
- 每個角色擁有的許可和約束是有限的
- 每個用戶在會話時只能使用1個角色
（2）劃分數據領域
按照用戶、角色、部門三個維度劃分各個業務域，每個業務域按照業務過程梳理業務數據。
- 業務域：指具體的業務范圍
- 業務過程：指業務活動系列事件
- 業務數據：在業務流程中產生和使用的各類數據
B. 角色權限
C. 部門
（3）實體建模ER圖
通過客戶模型和數據領域劃分，我們梳理出了需要用到的業務數據，接下來可以通過實體建模ER圖，描述出這幾類業務數據的關系，這有助于后期原型繪制時的業務流轉和設計限制規則。
例如“一個部門可以綁定多個員工，但一個員工不可綁定多個部門”，在這個1對N的關系下，系統界面設計就需要增加限制，在為員工選部門時，不支持多部門的選擇；在部門內創建人員時，不可選擇其他部門的人員。
實體建模中權限可分為【菜單資源資源】和【數據資源權限】
- 菜單資源權限：指不同角色可以操作的界面、按鈕等等，例如部門負責人可以看到《權限設置》頁面，可以操作「部門」按鈕，「角色」按鈕，而普通員工則無法查看《權限設置》頁面，無法操作「部門」、「角色」按鈕。
- 數據資源權限：指不同角色在同一頁面中看到的數據范圍，例如部門負責人可以看到本部門所有員工的人員資料，而普通員工只可以看到自己的人員資料。
到這一步，整體方案設計已經完成，可以在此基礎上，進行細節方案設計。
2. 細節方案設計
1）設計頁面原型
（1）繪制原型時的注意事項
原型設計需建立自己獨特的規范，原型規范化的主要優勢在于提升信息傳遞的效率。人類天生被視覺所吸引，美觀的設計往往容易吸引人們的注意力，而混亂的設計則直接令人感覺到邏輯不清。
在系統搭建初期，產品經理可以預設一套完整的界面樣式規則，包括彈窗樣式、列表樣式、標簽元素、頁面布局、提示語樣式等，按照這些規則作為通用模板。
不過，原型設計與ui設計不同，我們無需過分關注到每個像素的細節。設置原型規則是為了我們有個繪圖標準，更快速的傳遞信息。若花費心思鉆研每個按鈕的擺放位置，每個元素的排版，每種顏色的搭配，豈不是本末倒置！
（2）原型規范
建議繪制時只以黑、白、灰三種顏色進行繪制，如此可不用在配色上做過多糾結。在此分享幾個本人常用的原型規范。
①二次確認彈窗
②批量修改彈窗
③導入失敗頁面
④任務執行結果彈窗
⑤當頁面按鈕超過3個時，組合按鈕
2）設計具體功能點
按照前期的整體方案設計，我們結合產品功能定位、業務流程和實體建模ER圖，便可以設計每個信息承載頁面的功能按鈕和交互。
以《角色總覽》列表區域為例：
同時還需要增加數據權限：
3）梳理各模塊關聯關系
目前系統暫無其他模塊，此步驟可先忽略
4）輸出各類文檔和圖示
結合前面方案設計過程中繪制的各類圖示，再加上對每個功能點的詳細說明，就可以產出PRD文檔，當業務規則復雜時，可以在文檔中適當列舉案例，便于開發人員和測試人員的需求理解。
另外PRD文檔的目錄需要層級劃分清晰，至少包含以下幾點：
- 文檔記錄：記錄文檔創建、修改的情況，文檔的編寫狀態，編寫人示例。
- 文檔修訂記錄：記錄每次修改的修改內容，更詳細的進行記錄每次修改的情況，對修改情況做概要性的描述。
- 概述：背景介紹、涉及范圍、閱讀對象和名詞解釋。
- 結構圖：功能結構圖、信息結構圖、業務流程圖等
- 功能概要：根據功能結構圖而來，控制好級別，并進一步描述功能的內容和作用。
- 功能詳細說明：詳細列出發布所需的所有功能，每項功能應有對應的用例說明用戶如何使用該功能；以及功能使用時的限制條件和依賴關系
- 非功能需求：描述功能模塊的質量屬性，如可靠性、可維護性、可擴展性和性能等
此外，在具體實踐中，產品經理需要根據實際的產品類型和組織習慣來適配或調整PRD的內容和結構。無論何種形式，都要確保PRD能夠明確地描述產品的功能需求，以便于團隊成員理解和執行。
本文由 @尺素 原創發布于人人都是產品經理。未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論，等你發揮！
