中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

工作流細(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)流程；常見場(chǎng)景如：請(qǐng)假、用車、報(bào)銷、出差等。

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

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

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

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

一、審批流

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

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

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

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

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

審批結(jié)果：審批結(jié)果一般是通過或拒絕，通過則表示該事項(xiàng)可以執(zhí)行，如：請(qǐng)假通過，則可以開心地進(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è)審批過程，可對(duì)交互過程增加擴(kuò)展功能，更為易用。審核過程卡在某一個(gè)環(huán)節(jié)時(shí)，支持“催辦”；審核具體情況可通過“審核進(jìn)度”跟進(jìn)；某個(gè)明確具體原因錯(cuò)誤只需要某個(gè)人處理，可以“指定回退”。

審批流主要表現(xiàn)，關(guān)鍵信息一致，不同人員查看信息的著重點(diǎn)不同，從而給予不同的審批結(jié)果。審批流引擎的實(shí)現(xiàn)，可以支持 請(qǐng)假、報(bào)銷、用章、用車、出差、資產(chǎn)領(lǐng)用 等業(yè)務(wù)場(chǎng)景，是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)針對(duì)不同生命周期，有不同的信息記錄。如：問題分派時(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)會(huì)有多個(gè)，會(huì)存在每個(gè)事項(xiàng)都有在進(jìn)行中的情況。

示例：簡化的采購流程：庫存管理 — 備貨申請(qǐng) — 采購訂單 — 入庫調(diào)整。報(bào)廢、銷售 會(huì)減少庫存，新品入庫 會(huì)增加庫存，當(dāng)庫存低于警戒值時(shí)，需要發(fā)起備貨申請(qǐng)，則是第一環(huán)節(jié)【庫存管理 — 備貨申請(qǐng)】；當(dāng)備貨申請(qǐng)審批通過時(shí)，生成采購訂單，發(fā)起采購流程，則是第二環(huán)節(jié)【 備貨申請(qǐng) — 采購訂單】；采購訂單通過物流采購貨品成功，進(jìn)行入庫，則會(huì)修改庫存情況，則是第三環(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ù)的也會(huì)有不同。CRM系統(tǒng)可以是線索、商機(jī)管理系統(tǒng)，也可以是客戶、協(xié)議、合同管理系統(tǒng)，但終歸都整合的是客戶關(guān)系管理業(yè)務(wù)。系統(tǒng)拆解有多種方式和角度，由業(yè)務(wù)流生成系統(tǒng)是其中一個(gè)角度，這個(gè)角度是 低代碼模型驅(qū)動(dòng)的視角來源。

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

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

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

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

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

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

低代碼平臺(tái)框架