最近客戶部署了某著名公司的工作流軟件，我也順便研究了一下，發現了一些問題。
目前的工作流系統，從結構體系看都是相似的，主要包括：
- 工作流引擎
- 圖形化的流程設計器
- 表單設計器
如果從企業數據角度來看，我們分析一下各個組件的含義
工作流引擎當然是處理具體的業務數據（或叫流程實例）的節點狀態流轉，保存的是節點狀態數據
表單當然保存了業務數據，由於不同流轉步驟需要的數據不同，表單裏面也存在着非常多的腳本信息，這些腳本中以字段名的方式標識着數據計算公式。
流程設計器保存的是業務流程流轉的規則，由於很多流程跳轉是有條件的，因此這裏面就產生了大量的腳本，而流程跳轉條件又多與表單中的字段有關，因此腳本中也存在着大量的字段名標記。
由於流程設計器和表單設計器是兩個獨立的系統，一般來說表單是被動的，因此流程的修改對錶單不會產生太大影響，或者說可以通過編程方式進行檢測和自動調整。 但是表單作爲數據的保存地，它發生了變化就有些麻煩了，我們來看看問題及解決思路：
- 如果字段名發生了變化，那麼所有保存在流程設計器及表單其他字段中的腳本就都有可能發生錯誤。解決的辦法只能是在腳本完成後再進行“編譯”處理，將腳本中調用的所有字段名與表單字段的識別碼（通常是ID）來關聯，這樣字段名稱發生了變化不會引起程序變化。
- 如果字段被刪除，那麻煩可能就很大，因爲如下公式： [出差日補貼]×[出差天數]如果刪除了“出差天數”的話公式就變成了 “[出差日補貼]×”是個無效的公式， 解決的方法就只能是禁止刪除或禁用這些字段。但是有些字段又是需要禁用/刪除的，這樣就必須有能力通過編程的方式將這些被調用的字段找到。
回到業務的考慮中來，現有的很多著名工作流產品大都不能實現對已經有數據的表單進行修改，而實際業務中業務及流程的調整又是非常頻繁的，因此大都採用使用新的表單版本甚至新的流程版本處理，基於數據分析角度考慮，這又往往製造了很多“信息孤島”，使大量有用的數據無法進行分析（或者需要專門的編程纔可以）。
其實，如果能夠解決表單字段變更與刪除的自動處理問題，從理論上說修改使用中的表單應該是可行的，而如果能夠實現此功能，將會大大提高工作流的適用環境。
