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

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

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

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

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

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

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

一、審批流

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

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

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

如：請假審批流設(shè)置為 直接領(lǐng)導(dǎo)、上級領(lǐng)導(dǎo)、人事、財務(wù)審批。存在特殊情況，在審批流因為表單填寫某個具體內(nèi)容不同而進行分支的情況。比如，請假超過3天要送總經(jīng)理審核。

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

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

簡道云流程設(shè)計

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

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

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

狀態(tài)下的操作

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

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

二、工作流

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

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

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

事項生命周期管理

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

工作流設(shè)計

三、業(yè)務(wù)流

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

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

業(yè)務(wù)流 流轉(zhuǎn)實際上就是系統(tǒng)本身的本質(zhì)。

軟件系統(tǒng)架構(gòu)

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

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

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

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

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

API接口編排設(shè)計

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

低代碼平臺框架

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

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

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。