既有系統的開放性:
BPMS畢竟不是Middleware,BPM較傳統SI的優勢是能以整體業務流程的觀點來看資訊整合,而非單純系統對系統的觀點。不過在整合技術上BPMS所受到的限制跟大多數SI是一樣的(若BPMS的架構不好則限制會比SI更多),所以若企業所使用的系統是由『失傳的技藝』所架構成的封閉式系統,導入BPM專案後也不會因此『芝麻開門』。
BPMS不是仙女棒(Middleware也不是),這點技術上的認知與準備是要有的(這也是許多BPM相關討論對於SOA有深刻盼望的緣故),不切實際的期望只會導致失望。
權限觀點的不同:
在傳統AP如ERP,對於系統權限的控管是以帳號為標的,也就是限制每個帳號(人)能夠看到哪些資料,因為傳統AP基本上是『查找』資料的概念。要看到不同的資料就需要對該帳號的『查找』權限進行調整。(部份系統則甚至一個人得有多個不同帳號才能處理所有需處理的事物)。
而從流程觀點來看則稍有不同,基本區分為兩段:
首先流程看的是在不同的流程階段(關卡),該階段要處理哪些事,故需要看到(填寫)哪些內容。之後實際上誰能看到這些內容則是到流程開始運行後,才根據流程邏輯判斷是否、啥時流到該關卡,流到後誰要負責該關卡,從而賦予看到(填寫)該關卡內容的權力。
所以若是套用AP的觀點來看流程的權限就可能會有些不適應。比如:『只有總經理能看到某某資訊』這在傳統AP是自然不過的權限要求。可是BPM談的則是『在某階段能看到某某資訊』,至於某階段的負責人是否只可能是總經理則是靠流程設定而非權限控管。
由此衍伸的問題是:當總經理不在時怎麼辦?等到總經理回來再處理是一種方式(業務停擺?),簽核代理人則是另一種常見方式。可是此時依照流程的想法,不管代理人是誰,都仍該看到『充足』的資訊才能做出正確的判斷,既然原本的負責人選定了某人做為代理人,那代理人自當能有足夠的資訊才能做好代理的工作,因此他就會看到那些在傳統觀點下『只有”某某人”能看的資料』。除非對代理人的期望僅是橡皮圖章等級,若真如此,不如叫資訊部直接bypass流程乾脆些。
以上五點是在考慮推導BPM專案時,應該需要具備的一些觀念。雖然其實還能繼續往下列,不過多了也不會記得所以還是遵照重點管理的建議以不超過五點為原則,希望有所幫助。(全文完)


