又到了 Weekly Review 的時間，James 請大家 Update 相關工作進度後，開始進行專案的討論。
James 大致說明了今天會議的主題，以及要每個人報告這次採購電子簽核專案的進度。

「OK，關於 ERP 要修改的部份，喬安，妳先說明一下妳的構想。」

「好，在 ERP 系統中，採購單本來就有提供是否進行簽核的欄位，我們需要在單據別維護上將需要走電子簽核的單據別設定為 "Y"，我看了一下，大概單據分類為採購單的單據都要進行設定，之後有新增的採購單據別，也要依此規則設定。」喬安開始說明。

「我覺得在不改變 ERP 操作習慣的前提下，我們可以在原先助理確認採購單輸入後，在系統中加入一個簽核的 Flag，讓 BPM 系統知道有哪些單據需要跑簽核，同時當 BPM 將單據下載跑簽核流程的時候，也要告訴 ERP 系統，該單據已進行簽核；此時在 ERP 這一段應該要將該單據鎖住，助理無法再進行單據的修改或刪除；」喬安邊說邊在白板上畫下系統運作的示意圖(圖1)。「同時，當 BPM 完成簽核後，也要告訴 ERP 系統簽核的結果，讓 ERP 系統可以知道單據被核准或駁回，以進行後續的動作。」

「這個方式應該可行，我們順便把ERP的簽核狀態定義一下。」James 與喬安、小艾開始針對 Flag 的狀態碼進行討論。

之後他們得出結論，對ERP來說總共要有四個狀態。James 在喬安的示意圖上，標示著。「W(Waiting) 表單據準備進行簽核，A(Active) 表示簽核進行中，C(Confirmed) 表單據已核准，R(Rejected) 表單據駁回。那後續的動作是？」

圖1：簽核系統示意圖(以 VISIO 圖代替)

「當 ERP 判斷簽核狀態是 C 時，表示這張單可以發出，助理可以在系統中列印採購單並將採購單的狀態設為已發出，如果簽核狀態是 R，則助理可以對此單據取消確認，並進行單據內容的修改或作廢，如果修改後再確認，則由重新回到待簽核狀態，BPM 再次將單據下載做簽核。」喬安接著回答。

「所以我在 BPM 中只要判斷簽核 Flag 以及更新 Flag 狀態即可？」小艾提出他的疑問。

「還有一個單據狀態要註記，採購單狀態 0 表示開立，狀態 1 表示已核准，狀態 2 表示已發出。」喬安補充說明，「所以還需要更新採購單狀態這個欄位。」

「另外簽核後的結果，要把簽核人員的 ID 寫回來，這樣列印採購單時，就可以將簽核人員的名字帶到採購單中。」

「那我在最後要加上一個自動執行節點，去更新採購單資訊，同時在每一個簽核節點，要將簽核資訊回寫 ERP 中。」小艾再次確認，喬安與 James 都點點頭。

「Good，這樣兩邊系統串接就容易多了。小艾你這邊的進度呢？」James 接著要小艾報告 BPM 部分的進度。

「我這邊主要的流程架構已經 OK，相關智慧簽核節點的規則，也跟 James 這邊討論確定。接下來要進行畫面以及 ERP 資料讀取的設計。」小艾報告。

「OK，喬安，妳先提供相關的 Table Schema 給小艾；小艾，BPM 的表單畫面，就比照 ERP 系統的畫面設置，相關的欄位資訊，可以參考 ERP 畫面定義檔來設計，喬安，妳也順便跟小艾說明如何運用這些資訊。」James 將接下來的工作稍作分配。

「請先在測試機上面進行系統的相關設計與調整，我這邊會針對 EIS 的整合資訊進行構思，最近在研究一個 Web 前端開發的 Framework(註1)，我覺得可以套用在這個專案上，我們兩週後再針對個別的進度 Review，今天會議就到這邊。」

註1：BPM 相關概念已經介紹完畢，接下來的單元，將以前端 UI Framework為主題，並為您介紹 BPM 整合開發的相關技巧，敬請期待！

Prev Next

本篇全系列文章