簡介Oracle EBS 模塊流程圖是一份面向 ERP 實施顧問、財務(wù)與供應(yīng)鏈從業(yè)者及系統(tǒng)學習者的模塊全景圖文檔。內(nèi)容以 Oracle E-Business Suite 為核心系統(tǒng)梳理了總帳管理GL、應(yīng)付/應(yīng)收、固定資產(chǎn)、現(xiàn)金管理、庫存、采購、銷售訂單、制造MPS/MRP、BOM、WIP、成本管理及人事、薪金等核心模塊并給出設(shè)計到發(fā)布、采購到支付、訂單到收款等主要業(yè)務(wù)流程的圖示與鏈路有助于快速建立 EBS 整體架構(gòu)認知和模塊間流轉(zhuǎn)概念。壓縮包內(nèi)為 1 個 doc 文件大小約 1.16MB文檔目錄層級清晰按財務(wù)、分銷、制造、其他模塊分類展開適合作為入門導讀或培訓參考材料。已有 167 人學習下載適合需要在短期內(nèi)梳理 Oracle ERP 模塊關(guān)系與業(yè)務(wù)流程的讀者。1. 一份 doc 流程圖為什么讓 EBS 實施少走三個月彎路上個月幫某公司做 EBS 月結(jié)排錯財務(wù)經(jīng)理拿著賬本說“庫存關(guān)不了賬、總賬不平”我翻遍系統(tǒng)里的配置文檔發(fā)現(xiàn)一張模塊關(guān)系圖都沒有——只有十幾張沒人維護的 Excel。最后花了兩天時間把 AP、AR、INV、WIP、GL 之間的單據(jù)流重新畫成一張流程圖問題當場就定位了。那一刻我意識到Oracle EBS 這種動輒幾十個模塊的企業(yè)級套件真正讓項目卡殼的從來不是功能而是“流程說不清”。本文要聊的就是標題里那類產(chǎn)物oracle-EBS-模塊流程圖.doc一份把 EBS 各模塊之間的業(yè)務(wù)流、單據(jù)流、審批流畫明白、寫進 Word 的文檔。適合實施顧問、二次開發(fā)工程師、財務(wù)/供應(yīng)鏈業(yè)務(wù)骨干、以及接手別人爛攤子的運維人員。它不解決“某個報表怎么寫”它解決的是“業(yè)務(wù)在哪個模塊發(fā)起、經(jīng)過誰、最終歸檔到哪里”。看完你就能照著方法從零梳理出一份能指導配置、排錯和權(quán)限設(shè)計的模塊流程圖文檔。2. 先看懂 EBS 的模塊地圖財務(wù)與供應(yīng)鏈的主干單據(jù)流EBS 再復雜主干就兩條鏈供應(yīng)鏈鏈采購→庫存→制造→訂單和財務(wù)鏈發(fā)票→應(yīng)付→總賬→資產(chǎn)。畫流程圖之前你腦子里必須先有這兩張地圖。沒有模塊地圖就下筆畫圖畫出來的只能是零散的“按鈕操作說明”。2.1 財務(wù)域總賬、應(yīng)付、應(yīng)收、資產(chǎn)、現(xiàn)金的收付循環(huán)財務(wù)域的流程圖核心不是“某個界面長什么樣”而是“一張單據(jù)從產(chǎn)生到過賬走過哪些模塊”。最常見的財務(wù)循環(huán)是采購收到供應(yīng)商發(fā)票后應(yīng)付模塊 AP 錄入發(fā)票付款時現(xiàn)金管理 CM 做付款資產(chǎn)模塊 FA 在采購資產(chǎn)入庫后做資產(chǎn)增加月底所有子模塊過賬到總賬 GL銷售出貨后應(yīng)收模塊 AR 生成客戶發(fā)票AR 收款再回到 CM最后結(jié)轉(zhuǎn) GL。畫這部分時我習慣先列一張模塊職責表明確每個模塊在這個循環(huán)里到底干什么模塊職責輸出單據(jù)接收方AP 應(yīng)付供應(yīng)商發(fā)票錄入與驗證應(yīng)付發(fā)票、付款申請GL、CMAR 應(yīng)收客戶發(fā)票與收款核銷應(yīng)收賬款、收款單GL、CMFA 資產(chǎn)資產(chǎn)新增、折舊、處置折舊費用、資產(chǎn)憑證GLCM 現(xiàn)金銀行賬戶與資金頭寸付款、收款確認GLGL 總賬憑證記賬、期間關(guān)賬、報表總賬憑證、科目余額管理層這張表就是流程圖的“圖例索引”。因為財務(wù)流程最后全部匯入 GL所以 GL 一定是泳道圖里最寬的那條泳道。畫圖時要注意AP 和 AR 的過賬是批量而非實時的流程圖上應(yīng)該用“批處理”節(jié)點而不是“自動實時同步”節(jié)點。很多第一次畫的人在這里畫錯導致后續(xù)做集成測試時對不上預(yù)期。財務(wù)分支容易漏掉的關(guān)鍵路徑是“未實現(xiàn)損益”和“外幣重估”。如果公司有跨境業(yè)務(wù)每張銷售訂單會涉及本位幣和外幣兩套金額AR 開票時的匯率、GL 月結(jié)重估的匯率必須體現(xiàn)在流程圖的單據(jù)字段說明里。我見過不少項目把這條鏈畫得太粗等到月結(jié)出現(xiàn)匯兌差異時翻流程圖完全找不到匯率來源。2.2 供應(yīng)鏈域采購、庫存、車間在制、訂單履約的主鏈供應(yīng)鏈流程圖主鏈是采購申請 → 采購訂單 → 采購接收 → 庫存入庫 → 工單領(lǐng)料 → 完工入庫 → 銷售訂單發(fā)貨。這是 EBS 里最經(jīng)典、也是被講得最多的一條業(yè)務(wù)鏈。真正難的不是主鏈而是三個“回流”分支。第一個回流是退貨。采購退貨不是簡單地把接收記錄刪掉而是要在 RMA 流程中生成退貨訂單再從庫存做出庫動作最后回到 AP 做借項通知單。第二個回流是工單報廢。車間在制 WIP 里的廢品要從工單扣減數(shù)量同時做成本差異分攤這部分會直接影響 FA 資產(chǎn)模塊的資本化金額。第三個回流是銷售退運?？蛻敉素浵茸鼋邮赵僮鰴z驗合格的重新入庫不合格的做報廢最后的成本差異要進 GL。畫供應(yīng)鏈流程圖時我強烈建議把主鏈和回流分開畫不要揉在一張圖里。主鏈一張圖三個回流各一張子圖子圖編號掛在主圖對應(yīng)節(jié)點上。這樣圖面干凈而且后續(xù)做配置時能按子圖逐個核對 MTL_TRANSACTION_TYPES 和 WIP 的離散任務(wù)類型。供應(yīng)鏈分支的“單據(jù)流順序”常被忽略。采購接收形成 RCV_TRANSACTIONS然后調(diào)用庫存模塊做入庫事務(wù)處理錄入 MTL_TRANSACTIONS這兩個動作在同一批事務(wù)里完成但在流程圖上體現(xiàn)為兩個節(jié)點。開發(fā)人員看流程圖時最怕的就是這種“一個動作兩個節(jié)點”的歧義所以圖上要標注“事務(wù)來源接收/庫存”。2.3 從模塊清單到流程圖先畫單據(jù)流再畫審批流模塊地圖有了以后畫圖順序有個經(jīng)驗值先畫單據(jù)流再畫審批流最后補控制流。單據(jù)流是骨架比如采購訂單從審批到發(fā)送給供應(yīng)商系統(tǒng)里 PO_HEADERS_ALL 的狀態(tài)從 INCOMPLETE 走到 APPROVED這個狀態(tài)流轉(zhuǎn)就是單據(jù)流。審批流是高階覆蓋也就是采購訂單的審批層級、金額閾值、審批組?？刂屏魇钱惓７种П热绨l(fā)票驗證失敗退回供應(yīng)商。順序反了就會翻車。某公司的實施顧問一上來就畫審批流結(jié)果畫到第三層發(fā)現(xiàn)單據(jù)流走向根本不對整個圖的布局要推翻重來。先畫單據(jù)流的好處是它決定了泳道的數(shù)量每多一個模塊就多一條泳道單據(jù)流走完泳道的寬度和跨接關(guān)系就定死了。審批流只是在泳道里加節(jié)點不會破壞圖的大結(jié)構(gòu)。這一階段的產(chǎn)出是一張“模塊接口矩陣”列是上游模塊行是下游模塊交集格里寫“什么單據(jù)、什么事件觸發(fā)”。這張矩陣是畫正式流程圖前的唯一驗收物。矩陣里如果出現(xiàn)“不知道什么觸發(fā)”的格子跳過它繼續(xù)畫正式圖后面必返工。3. 動手畫流程圖從業(yè)務(wù)調(diào)研到成圖的完整路徑模塊地圖是“知”畫圖是“行”。這一章講實際操練怎么問業(yè)務(wù)、怎么用工具出草圖、怎么把草圖變正式圖。我會給出可抄的提問清單和可改的 PlantUML 腳本渲染成 PNG 后直接貼進 Word后續(xù)維護改文本再渲染不依賴任何收費畫圖工具。3.1 業(yè)務(wù)調(diào)研的提問清單與信息收集模板畫圖前先訪談訪談最怕的是“跟業(yè)務(wù)聊了三個小時回來發(fā)現(xiàn)關(guān)鍵字段沒問”。我用的提問清單經(jīng)過多次迭代固定為五個問題這張單據(jù)從哪里來上游系統(tǒng)還是手工錄入系統(tǒng)里哪個表單哪些角色能看到查詢權(quán)限、維護權(quán)限、審批權(quán)限分別是誰什么事件讓它發(fā)生狀態(tài)變化審批通過、接收完成、發(fā)票驗證通過異常時往哪走被退回、被掛起、被沖銷最終歸檔到哪個模塊過賬到 GL、關(guān)閉工單、庫存事務(wù)完成訪談記錄不要用大段文字用表格收集。我常用的模板是流程編號、流程名稱、發(fā)起角色、上游單據(jù)、系統(tǒng)操作、狀態(tài)變化、下游單據(jù)、接收角色、異常分支、備注。十行以內(nèi)一個流程業(yè)務(wù)講完當場填完給業(yè)務(wù)看一眼確認——這一步省掉后面八成理解偏差。調(diào)研的顆粒度不是越小越好。EBS 里很多流程跨模塊訪談時業(yè)務(wù)會不自覺鉆到某個字段的校驗邏輯里你要在記錄表上把它歸到“字段說明”或“異常分支”不讓它干擾主流程。主流程保持“單據(jù) 狀態(tài) 模塊”三個要素字段細節(jié)留到配置文檔階段再展開。3.2 用 PlantUML 先畫邏輯草圖泳道圖的快速原型畫草圖我首推 PlantUML原因很實際改起來是改文本比動鼠標快一個數(shù)量級可以進 Git 做版本管理團隊規(guī)模大了以后能統(tǒng)一風格。以下是采購到庫存的泳道圖示例腳本startuml |采購員| start :PREPARE_PO; if (采購金額審批閾值?) then (是) |采購經(jīng)理| :PO_APPROVAL; if (審批通過?) then (是) |采購員| :SEND_PO; :RECEIVE_GOODS; else (否) :PO_RETURN_TO_DRAFT; stop endif else (否) |采購員| :AUTO_APPROVED_PO; :RECEIVE_GOODS; endif |倉庫| :INV_TRANSFER_IN; |財務(wù)部| :MATCH_INVOICE; stop enduml腳本里的豎線 |角色| 就是泳道名把采購員、采購經(jīng)理、倉庫、財務(wù)部分成四條泳道。每個節(jié)點用大寫英文標識操作名對應(yīng) EBS 里的表單或 API 名稱這樣團隊評審時能直接對應(yīng)系統(tǒng)功能。其中“采購金額 審批閾值”的分支就是審批流的落地閾值參數(shù)來自采購組織的金額控制設(shè)置。參數(shù)說明這里的“審批閾值”在 EBS 里通常對應(yīng)采購審批規(guī)則里的“單張訂單限額”不同組織OU可以設(shè)不同值。畫草圖階段用假值即可比如 10000到配置階段再從 HR 組織架構(gòu)里拿真實數(shù)據(jù)。手動把節(jié)點中文化或加注釋也可以但英文標識保留在括號里方便開發(fā)人員檢索功能說明。PlantUML 渲染成 PNG 的命令是常用的文本繪圖方式j(luò)ava -jar plantuml.jar purchase-flow.puml如果電腦里裝了 Graphviz它會自動箭頭對齊。沒有 Java 環(huán)境的團隊也可以用 Docker 鏡像跑命令差異只是替換工具路徑腳本本身通用。當你輸出一堆 PNG 后建議一個流程一個文件命名規(guī)范是“模塊對-流程名.puml”比如“PO-INV_收料入庫.puml”。3.3 從草圖到正式圖圖符規(guī)范、泳道劃分與跨頁拆分草圖是給自己看的正式圖是給業(yè)務(wù)方和開發(fā)方共同評審的。所以必須有圖符規(guī)范不然十個人畫十種樣式。我的團隊用一套很土但有效的規(guī)范矩形代表系統(tǒng)操作節(jié)點菱形代表判斷分支圓角矩形代表人工線下操作半圓代表開始/結(jié)束。這套規(guī)范和 UML 活動圖一致業(yè)務(wù)顧問都認識不用額外培訓。泳道劃分有一條紅線按角色劃分不按部門劃分。同一個部門里采購員做錄入、采購經(jīng)理做審批放在同一個泳道里會把審批鏈的職責邊界畫糊。如果同一角色在多個部門出現(xiàn)比如不同組織下的倉管員泳道名寫“組織-角色”比如“北京倉庫-倉管員”“上海倉庫-倉管員”。這直接關(guān)系到后續(xù)權(quán)限設(shè)計因為 EBS 的數(shù)據(jù)安全是通過組織上下文實現(xiàn)的泳道的作用范圍必須與業(yè)務(wù)實體一致。跨頁拆分的判斷標準就一句話圖里有沒有超過 7 條泳道超過就拆。EBS 的復雜流程比如整個訂單到收款 O2C動輒 8 條泳道、30 個節(jié)點放到 Word 一頁里字小到看不清。我的做法是每一頁只放 3 到 5 條泳道跨頁連接處用“離頁連接符”標注頁碼和圖號連接符命名用“節(jié)點名 - 下游頁碼”。這樣 Word 文檔不可能出現(xiàn)一張圖橫跨兩頁的情況打印評審也看得清。正式圖評審時業(yè)務(wù)方通常會糾纏于“我們實際操作不是這樣的”。這句話的潛臺詞不是圖錯了而是流程有例外情況沒畫。評審時我會要求業(yè)務(wù)方把例外情況寫在圖下方的“例外說明”里而不是直接改主流程。例外積累到一定數(shù)量后再決定是否提升為主流程分支。這個機制能保證主圖穩(wěn)定控制返工次數(shù)。4. 把圖裝進 Worddoc 文檔的排版規(guī)范與修訂機制圖只是中間產(chǎn)物交付物是 Word 文檔。但這恰恰是很多項目翻車的地方流程圖畫得漂漂亮亮文檔結(jié)構(gòu)一團亂——圖沒編號、文字和圖表不同步、版本記錄缺失。這一章講讓流程圖文檔長期可用的排版和版本控制方法。4.1 Word 排版規(guī)范編號、圖注、頁眉、跨頁處理流程圖文檔如果不做嚴格編號三個月后你自己都找不到第三張圖。我的編號規(guī)范是圖 2-1 代表第 2 章第 1 張流程圖圖 2-2 依此類推表 2-1 是第 2 章第 1 張表格。不要用 Word 自動編號原因是自動編號在刪除圖后不會自動重排——把所有編號改為手工維護配合“交叉引用”功能插入正文引用。這樣正文里寫“見圖 2-3”時即使圖移動了交叉引用也能幫你定位。圖注放在圖的下方一行以內(nèi)說明這張圖畫的是哪個流程、版本是什么。表格標題放在表的上方這和圖注相反別記錯。頁眉寫“項目名 - 模塊流程圖設(shè)計”頁腳寫“頁碼 / 總頁數(shù)”。Word 里設(shè)置多級列表讓章節(jié)標題自動帶編號章節(jié)編號一旦定下圖號里的章節(jié)前綴就跟著定下。最影響閱讀體驗的是圖的尺寸。一張泳道圖貼進 Word最佳寬度是頁面正文寬度A4 紙默認 15.5cm 左右超過就縮小縮到字看不清就回爐拆圖。圖片質(zhì)量導出時設(shè) 150 DPI 到 200 DPI太低打印模糊太高 Word 文件撐到幾十兆。文字說明用表格而不是大段段落每個流程節(jié)點的說明控制在三行以內(nèi)觸發(fā)條件、操作內(nèi)容、異常分支。4.2 版本修訂機制流程圖文檔的審批流流程圖本身就是流程它的文檔也要有審批流。經(jīng)驗做法是三階段簽核第一階段是“草稿”畫圖人自審主要查圖符規(guī)范、泳道命名、單據(jù)流有沒有斷點。第二階段是“評審”業(yè)務(wù)方看流程對不對、開發(fā)方看能不能對應(yīng)到 EBS 功能、財務(wù)看控制點有沒有漏。第三階段是“批準”項目經(jīng)理或流程負責人簽批任何人都不能繞過簽批去動正式文檔。Word 文檔的修訂記錄表是這個機制的落地工具。固定放在封面頁下方字段是版本號、修訂日期、修訂人、修訂章節(jié)、修訂摘要、審批人。每次改圖必須在修訂摘要里寫明“新增采購退貨分支”“修改 AP 發(fā)票驗證節(jié)點順序”之類。如果修訂時發(fā)現(xiàn)圖號變了修訂摘要里不要寫“圖 2-3 重畫”要寫“圖 2-3 拆分為圖 2-4 和 2-5原退貨流移到 2-5”。修訂記錄的另一個作用是為項目收尾提供“變更證據(jù)”。上線后業(yè)務(wù)部門來質(zhì)問“當時審批的不是這個流程”你只要翻出修訂記錄里“修訂人 審批人 日期”三件套就能自證。所以修訂人不能寫部門名必須寫個人姓名如項目經(jīng)理處用角色占位符記名這行字是文檔法律效力的核心。4.3 流程圖與配置文檔的交叉引用方法很多項目的文檔是兩套皮流程圖一套文檔配置文檔另一套互不通氣。結(jié)果是流程改了三版系統(tǒng)配置還在按第一版寫上線時對不上賬。我現(xiàn)在要求所有配置文檔的每個配置項都要反向引用流程圖編號格式固定為“配置項名稱 / 表單路徑 / 配置文件中的參數(shù)節(jié)點編號 / 對應(yīng)流程圖編號及節(jié)點名”。如果配置項在流程圖上不存在說明該配置可能是遺留物需要標記“待確認”而不是直接保留。這個交叉引用在流程圖上怎么體現(xiàn)圖節(jié)點命名末尾加一個中括號編號比如“AP 發(fā)票錄入 [AP-INV-01]”。配置文檔里引用時寫作“對應(yīng) [AP-INV-01] 節(jié)點錄入供應(yīng)商發(fā)票驗證供應(yīng)商地點狀態(tài)”。這樣兩邊對賬時拿著流程圖的節(jié)點編號去配置文檔里搜搜不到就是遺漏搜到兩處描述不一致就是文檔不同步。機制很簡單但能讓文檔的可追溯性上一個臺階。關(guān)鍵的技巧是讓交叉引用成為評審檢查單的一部分。文檔評審時打印流程圖的節(jié)點清單逐節(jié)點勾選配置項——評審結(jié)束時如果發(fā)現(xiàn)某個節(jié)點空著沒有配置引用在會議紀要里列為風險項。每次修訂流程圖必須同步更新配置引用否則不能發(fā)布新版文檔。5. 繪制 Oracle EBS 模塊流程圖的 7 個避坑記錄流程圖做到第三個月各種坑基本都踩遍了。這里挑七個最典型、最耗時的記錄每個按“現(xiàn)象 → 原因 → 解決”寫清楚。這些不是理論推演都是實際項目里的翻車復盤。5.1 把流程圖畫成了操作手冊現(xiàn)象圖里的每個節(jié)點都寫了長達兩行的字段說明比如“點擊保存按鈕、輸入物料編號、選擇庫房……”整張圖密不透風評審時沒人看得下去。原因畫圖人混淆了“流程”和“操作手冊”。流程圖回答的是“單據(jù)在哪里、狀態(tài)怎么變、誰負責”操作手冊回答的是“界面上先點哪個按鈕”。解決立一個規(guī)矩每個節(jié)點的文字說明最多 8 個字比如“AP 發(fā)票錄入”。字段細節(jié)全部移到節(jié)點下方的表格區(qū)按“字段名 / 必填 / 取值來源 / 校驗規(guī)則”列出來。表格區(qū)和流程圖分離圖面上永遠只有簡潔的操作名。5.2 泳道按部門畫審批鏈全亂現(xiàn)象一張跨部門采購流程圖上采購員和采購經(jīng)理擠在同一條“采購部”泳道里財務(wù)部的審批節(jié)點伸進采購部的泳道長短線交錯評審時沒人看出問題一到權(quán)限設(shè)計就翻車。原因部門是行政概念權(quán)限是系統(tǒng)概念。EBS 權(quán)限設(shè)置里的職責Responsibility對應(yīng)的是角色和功能不是部門。按部門畫圖時一個部門里三種角色的審批路徑畫在一條泳道里權(quán)限設(shè)計沒法落到角色上。解決泳道一律按角色劃分角色名用系統(tǒng)職責的命名習慣比如“采購員-創(chuàng)建PO”“采購經(jīng)理-審批PO”“應(yīng)付會計-發(fā)票核銷”。角色與部門的關(guān)系放到圖外說明。5.3 只畫正常流程退貨退運分支一片空白現(xiàn)象采購流程圖評審通過上線第一個月客戶退貨財務(wù)發(fā)現(xiàn) AP 里沒有借項通知單流程倉庫拿到退貨不知道往哪入庫整個退貨流程在系統(tǒng)里跑了兩個星期才走通。原因畫圖時業(yè)務(wù)方只講了正常采購的路徑畫圖人沒追問“退貨怎么辦”。沒有藍圖業(yè)務(wù)就按各自理解操作和 EBS 的既有功能對不上。解決每個主流程評審時必須列出三個問題取消怎么走、退貨怎么走、沖銷怎么走。把答案畫成子圖子圖編號掛在主圖對應(yīng)節(jié)點下。沒有異常分支的主流程圖不能批準發(fā)布。5.4 圖與配置文檔脫節(jié)系統(tǒng)上線后對不上現(xiàn)象流程圖上 AP 發(fā)票驗證的節(jié)點還在“3-Way Match”配置文檔里已經(jīng)因為供應(yīng)商投訴改成了“2-Way Match”項目組沒人發(fā)現(xiàn)月結(jié)時差異巨大。原因流程圖文檔和配置文檔各歸一人維護流程修改走了簽核配置修改只發(fā)了郵件沒有同步機制。解決前面講的交叉引用方法是唯一可靠辦法。每次改圖必須看變動的節(jié)點有沒有引用到配置文檔每次改配置必須反向檢查流程圖節(jié)點描述是否一致。把這項檢查寫進文檔發(fā)布流程的驗收清單沒有互檢記錄不能發(fā)布。5.5 用截圖當流程圖維護一次就放棄現(xiàn)象EBS 標準流程被截圖加箭頭拼成流程圖看起來很快但業(yè)務(wù)一變流程就要重新截幾十張圖維護成本極高第二個月圖就過期了。原因截圖是“點狀記錄”不是“邏輯模型”。它的可讀性取決于截圖順序改一處往往要重排整個文檔。解決用可編程的繪圖工具PlantUML、Graphviz建模文本渲染成圖。修改只改幾行文本重新渲染維護成本降一個數(shù)量級。團隊協(xié)作時文本文件還能進版本管理。5.6 多組織架構(gòu)下把不同 OU 的流程揉在一張圖里現(xiàn)象流程圖上采購訂單審批鏈畫了 13 個節(jié)點比實際多出一倍。評審時業(yè)務(wù)方說“我們分單組織流程沒那么長”沒想到很多節(jié)點屬于另一個業(yè)務(wù)實體。原因沒有區(qū)分組織OUOperating Unit維度。不同 OU 有不同的采購審批閾值、不同的財務(wù)規(guī)則把多個 OU 的流程疊加在一張圖上節(jié)點數(shù)量翻倍路徑也混淆。解決先按 OU 拆分流程分支。同一個節(jié)點如果多個 OU 的取值不同在節(jié)點下方表格里寫“OU 維度”參數(shù)表不要為每個 OU 復制一張圖。EBS 的多組織特性和流程的對應(yīng)關(guān)系應(yīng)該在流程圖下方顯式標注“此圖適用于以下 OU 列表”。5.7 忽略 EBS 的功能安全權(quán)限流程圖上沒有“誰能做”現(xiàn)象流程圖畫完權(quán)限配置時發(fā)現(xiàn)采購員職責被授予了修改采購訂單價格的權(quán)限和流程圖上“價格維護只能采購經(jīng)理操作”的描述不一致。上線一個月后出現(xiàn)了一次價格誤改。原因流程圖的重點放在了單據(jù)流轉(zhuǎn)上沒有把功能權(quán)限和節(jié)點綁定。沒有這種綁定的圖安全配置時沒有依據(jù)各角色被分配了超出流程范圍的職責。解決每個節(jié)點標注兩個信息操作該節(jié)點的角色、該角色調(diào)用的 EBS 功能。設(shè)計時就把“誰有權(quán)做這個動作”寫進圖的節(jié)點說明區(qū)配置權(quán)限時直接照圖分配。變更權(quán)限時先看流程圖節(jié)點的職責說明防止越權(quán)。6. 進階讓流程圖成為月結(jié)排錯和權(quán)限設(shè)計的活文檔流程圖不只是藍圖階段的交付物上線后它應(yīng)該是排錯的第一工具。這里講三個進階用法都是靠一張好圖省掉大量排查時間的實戰(zhàn)技巧。第一個用法是月結(jié)排錯。EBS 月結(jié)卡住時最常見的報錯是“GL 期間未打開”或“子模塊未過賬”。這時候不用盲目翻日志而是拿著流程圖反向定位看月度結(jié)賬節(jié)點的“前置條件”比如 AP 未關(guān)期間則檢查 AP 的“未過賬發(fā)票批次”如果 AP 已過賬但 GL 未看到檢查流程圖上“過賬到 GL”節(jié)點對應(yīng)的職責是否生效。把流程圖貼在工位上比翻十份運維文檔都快。第二個用法是權(quán)限設(shè)計。新員工入職要開 EBS 賬號問他要什么職責他說“我要做采購”。其實這個答案太粗沒法直接配權(quán)限。這時用流程圖反推讓該員工指著流程圖說出自己的角色是“采購員-創(chuàng)建PO”還是“采購經(jīng)理-審批PO”再對照節(jié)點名把職責清單開出來。這個方式把抽象的系統(tǒng)職責翻譯成了業(yè)務(wù)語言權(quán)限申請的錯誤率大幅下降。第三個用法是做集成測試用例。寫測試用例時按流程圖的節(jié)點順序逐個對照可以讓用例覆蓋率達到 100%。每個流程節(jié)點至少對應(yīng)一個正向用例和一個負向用例正向驗證單據(jù)正常流轉(zhuǎn)負向驗證異常分支審批拒絕、發(fā)票匹配失敗、退貨處理。測試負責人拿到流程圖只需要做一個映射節(jié)點編號 → 測試步驟編號就能在半小時內(nèi)完成用例設(shè)計。這個方法當然不是萬能的但它比憑經(jīng)驗拍腦袋寫用例要系統(tǒng)得多也更能說服業(yè)務(wù)方接受測試計劃。我在這上面吃過虧。某次月結(jié)排錯我翻遍了日志和表數(shù)據(jù)最后發(fā)現(xiàn)問題是 AP 發(fā)票校驗規(guī)則的設(shè)置和流程圖上的描述不一致——而那張圖三個月前就已經(jīng)批準發(fā)布了只是沒人拿它當排錯工具。從那以后我養(yǎng)成了一個習慣每畫完一張 EBS 流程圖都要在發(fā)布前問自己一句“如果三個月后系統(tǒng)出問題我能靠這張圖定位到哪個環(huán)節(jié)嗎”。如果答案不明確說明圖的顆粒度還不到位需要回頭補節(jié)點說明。流程圖不是給實施階段看的是給系統(tǒng)上線后那個凌晨三點還在排查月結(jié)的人看的。希望這一套方法能幫到你哪怕只是少熬一個通宵。本文還有配套的精品資源點擊獲取