close

早期的程式開發著重在資料的處理
即使 SOA 已經慢慢地普及
大家其實對以資料庫為中心的技術還是最熟稔的

因此即使再複雜
由資料面來判斷及決定處理的狀態也是家常便飯

早期的 flow 自然也是以資料為中心的產物
時至今日也慢慢進化為各式各樣的 BPM 產品

廢話又太多了
切入正題

flow 其實有幾點本質需要認清:

  • 首先是越來越多的系統需求並非以資料為中心
  • 再來就是即使有資料也包含了大量非結構化的資料
  • 最重要的就是既然是 flow
    本質就是會變

現今的組織無不強調靈活有彈性才有競爭力
什麼樣的 flow 會搞死自己大家可以想像一下...

試想一下一個不能符合上述 3 點的 flow 系統
還不如非系統控制的人為 flow
系統只需要掌控好資料的 "版本" "狀態" 及 "歷程" 即可

那為什麼我們突然會想要 flow 系統?

很有可能是因為現今絕大多數的作業都在系統上進行了
系統與系統間常會存在某種流程面的關係

再者管理面也發現以文件規範的 SOP 執行狀況無法如其他系統可以一目了然

更進一步管理面希望組織的運作不僅僅仍是隱性的人為流程
還可以轉化為顯性的系統流程

最終大家還是無法抵抗系統帶來的快速與輔助工具
這時 flow 系統當然也是為了滿足欲望而存在

所以
當我們看到新的 BPM 總覺得少了什麼的時候
不外乎都是因為處理資料太不方便了
原因就是新的 BPM 知道處理資料不是也不能是系統的核心

一個只能處理結構化資料而也以結構化資料處理為核心的 flow
簡單來說就是一個死的 flow 系統
雖然處理資料很方便
但處理流程就...

想要自己搞一個 flow
有得想了...

arrow
arrow
    全站熱搜

    marksu22 發表在 痞客邦 留言(0) 人氣()