工作流細分類為：審批流、工作流、業(yè)務流，其復雜度逐步上升。本文就這幾個流程進行逐個拆解，以期給你一些啟發(fā)，在業(yè)務流程中更加規(guī)范化。

工作流細分類為：審批流、工作流、業(yè)務流。

審批流：由發(fā)起人發(fā)起事項的審核，經相關人員共同確定，則該事項是否可繼續(xù)執(zhí)行的審核確認流程；常見場景如：請假、用車、報銷、出差等。

工作流：某一個工作事項在多角色參與下，讓事項得以最終實現(xiàn)，實現(xiàn)單事項的生命流程全管理；常見場景如：需求管理、缺陷管理、問題管理等。

業(yè)務流：實現(xiàn)完整的業(yè)務流程，一般包含多個工作流；常見場景如：產品開發(fā)管理、公司運營管理、學校產學研管理等。

工作流業(yè)務場景示例

審批流、工作流、業(yè)務流，其復雜度逐漸上升，以下進行逐步拆解。

一、審批流

審批流簡單理解是一個事項，經過層層確認，最終確認能否執(zhí)行。審批流主體信息主要包含：事項，審批人，審批記錄，審批結果。

事項：描述清楚這個待審批的具體內容，如：請假需描述清楚請假人、請假類型、請假時間、請假原因，附注工作情況等。這個部分可以由表單實現(xiàn)。

審批人：是整個審批流中最核心的部分，設置流程節(jié)點及該節(jié)點處理人。

如：請假審批流設置為 直接領導、上級領導、人事、財務審批。存在特殊情況，在審批流因為表單填寫某個具體內容不同而進行分支的情況。比如，請假超過3天要送總經理審核。

審批記錄：記錄審批人對表單的審批信息，包含審批人、審批時間、審批結果、審批意見，便于對流程審核過程進行跟蹤、回溯。

審批結果：審批結果一般是通過或拒絕，通過則表示該事項可以執(zhí)行，如：請假通過，則可以開心地進行休假；拒絕則表示該事項不可以執(zhí)行，這種情況一般都有調整意見，修改之后，可以再次發(fā)起審批。

簡道云流程設計

如圖所示，為簡道云審批流配置，設置審批流審核節(jié)點及節(jié)點屬性。

審批流操作及狀態(tài)關系

其中，審核1 到 審核N 到 審核(最后) 模擬整個審核過程，這是整個流程中最直觀的操作，以及操作如何修改狀態(tài)。可算作 審批流MVP（最小最有價值功能集）功能交互。

狀態(tài)下的操作

基于整個審批過程，可對交互過程增加擴展功能，更為易用。審核過程卡在某一個環(huán)節(jié)時，支持“催辦”；審核具體情況可通過“審核進度”跟進；某個明確具體原因錯誤只需要某個人處理，可以“指定回退”。

審批流主要表現(xiàn)，關鍵信息一致，不同人員查看信息的著重點不同，從而給予不同的審批結果。審批流引擎的實現(xiàn)，可以支持 請假、報銷、用章、用車、出差、資產領用 等業(yè)務場景，是OA系統(tǒng)實現(xiàn)的核心支柱。

二、工作流

工作流簡單表述為 事項經過多人分工處理，最終完成的業(yè)務情形。

常見如 ：需求管理，問題管理，缺陷管理。

示例：一個問題由提出人提出，由問題管理員完善并分派，由問題處理人處理，由質量相關人員驗證，由問題提出人確認是否處理妥當。主要體現(xiàn)為一個事項的生命周期管理。

事項生命周期管理

因具體業(yè)務的區(qū)別，不同事項的生命周期不同；因具體業(yè)務執(zhí)行團隊的不同，相同事項在不同團隊中也可能生命周期不同。事項針對不同生命周期，有不同的信息記錄。如：問題分派時，需要記錄分派人、分派時間、分派給哪個團隊或哪個人員、分派意見；問題處理，主要記錄處理人、處理時間、處理方法、后續(xù)注意事項等。

工作流設計

三、業(yè)務流

業(yè)務流簡單表述則是多事項的流轉，一個事項的處理，調啟另一個事項待處理，最終整條鏈條的相關事項都處理完成。只是在實際情況中，同一類型事項會有多個，會存在每個事項都有在進行中的情況。

示例：簡化的采購流程：庫存管理 — 備貨申請 — 采購訂單 — 入庫調整。報廢、銷售 會減少庫存，新品入庫 會增加庫存，當庫存低于警戒值時，需要發(fā)起備貨申請，則是第一環(huán)節(jié)【庫存管理 — 備貨申請】；當備貨申請審批通過時，生成采購訂單，發(fā)起采購流程，則是第二環(huán)節(jié)【 備貨申請 — 采購訂單】；采購訂單通過物流采購貨品成功，進行入庫，則會修改庫存情況，則是第三環(huán)節(jié)【采購訂單 — 入庫調整】。

業(yè)務流 流轉實際上就是系統(tǒng)本身的本質。

軟件系統(tǒng)架構

按照業(yè)務主體的不同，經典系統(tǒng)組成完整的生態(tài)鏈。這就是 SRM、MES、QM、WMS、TMS、CRM、ERP系統(tǒng)來源。但是因為各個公司具體業(yè)務的不同，處理同一塊業(yè)務的也會有不同。CRM系統(tǒng)可以是線索、商機管理系統(tǒng)，也可以是客戶、協(xié)議、合同管理系統(tǒng)，但終歸都整合的是客戶關系管理業(yè)務。系統(tǒng)拆解有多種方式和角度，由業(yè)務流生成系統(tǒng)是其中一個角度，這個角度是 低代碼模型驅動的視角來源。

這個角度離不開業(yè)務建模思維。一個個事項可以梳理為一個個對象，對象本身支持工作流全生命周期管理；而對象之間支持對象狀態(tài)變化生成另一個對象，甚至多個對象。

示例：庫存管理、備貨申請、采購訂單 都是一個個對象，對象本身支持增刪改查；備貨申請通過，也就是某個備貨申請實例狀態(tài)修改為已通過時，依據(jù)備貨申請直接生成采購訂單，并且同時可以生成一個信息對象實例，實現(xiàn)發(fā)送一條消息。

從低代碼當前實現(xiàn)視角，可以拆解為：頁面、數(shù)據(jù)、業(yè)務邏輯。這是低代碼表單驅動視角來源，這個角度離不開API接口調用思維。一個系統(tǒng)可以拆解為一個個頁面，備貨申請列表頁、備貨申請?zhí)砑禹撁妗湄浬暾埦庉嬳撁?、備貨申請詳情頁面等等。?shù)據(jù)庫存儲著一條條數(shù)據(jù)。

在備貨申請編輯頁面先回顯備貨申請信息，修改之后，再保存回數(shù)據(jù)庫。頁面和數(shù)據(jù)的互動，就靠業(yè)務邏輯來實現(xiàn)，要不要更新、要不要刪除都是業(yè)務邏輯來實現(xiàn)。而在技術角度，業(yè)務邏輯就是一個個API接口。

API接口編排設計

在低代碼平臺詳細拆解的路上，終于再向前一步走。權限、組織、用戶 作為系統(tǒng)軟件的基礎，已完成拆解；表單、流程作為低代碼頁面重要展示部分，已完成拆解。

低代碼平臺框架

本文由 @壹叁零壹 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協(xié)議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。