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

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

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

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

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

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

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

一、審批流

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

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

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

如：請假審批流設(shè)置為 直接領(lǐng)導(dǎo)、上級領(lǐng)導(dǎo)、人事、財(cái)務(wù)審批。存在特殊情況，在審批流因?yàn)楸韱翁顚懩硞€(gè)具體內(nèi)容不同而進(jìn)行分支的情況。比如，請假超過3天要送總經(jīng)理審核。

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

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

簡道云流程設(shè)計(jì)

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

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

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

狀態(tài)下的操作

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

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

二、工作流

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

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

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

事項(xiàng)生命周期管理

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

工作流設(shè)計(jì)

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

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

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

業(yè)務(wù)流 流轉(zhuǎn)實(shí)際上就是系統(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àn)楦鱾€(gè)公司具體業(yè)務(wù)的不同，處理同一塊業(yè)務(wù)的也會有不同。CRM系統(tǒng)可以是線索、商機(jī)管理系統(tǒng)，也可以是客戶、協(xié)議、合同管理系統(tǒng)，但終歸都整合的是客戶關(guān)系管理業(yè)務(wù)。系統(tǒng)拆解有多種方式和角度，由業(yè)務(wù)流生成系統(tǒng)是其中一個(gè)角度，這個(gè)角度是 低代碼模型驅(qū)動的視角來源。

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

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

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

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

API接口編排設(shè)計(jì)

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

低代碼平臺框架