使用者的需求大概分為兩部分：一部分是整個專案完全基於工作流來搭建開發，這也是很多任務作流廠商患有「平台壓迫症」的原因；另一部分是將工作流作為業務元件加入已有的專案中，推動業務的「審批」流轉。
前者的要求顯然更高，但也意味著有更多的利潤。其實這一部分的使用者又可以進一步的細分：一是技術能力比較差的公司，他們通過層層外包接到專案，而又沒有實力自己開發，於是想通過採購工作流加上幾個剛入門的程式設計師來完成整個專案的開發（這類使用者往往也是業務平台最大的客戶群），他們想著是一整套的開發解決方案，甚至包括業務分析；二是對業務程式設計的需求，他們需要流程引擎能夠侵入業務程式設計的內部，對業務的狀態和生命週期進行靈活的管理，從而最大程度的簡化開發或者說滿足一些複雜業務程式設計的需要。
後者的需求則比較簡單，多是某一行業的專案公司，突然碰到有審批的需求了，採用工作流多是滿足人工「審批」的需要，以及部分的統計分析。
需要承認，工作流其實與終端使用者還差得很遠，也就是說在眾多廠商的網頁上，那副著名的業務流程生命週期其實是一句空話。一句話說，就是那個什麼流程設計器是給程式設計師用的，至於使用者，哪涼快哪去。也就是說現在的工作流還不能給終端使用者提供價值。ok，既然工作流的價值是提供給整合商的，整合商就會考慮成本，於是工作流能否提供乙個完整的開發解決方案就成了最重要的考量。
最後說說市場。工作流其實有著很大的市場，只不過這個市場被開源工作流和平台瓜分掉了。因為目前的工作流不能給終端使用者提供價值，所以整合商在遇到審批的需求時，首先想到的會是開源的工作流引擎，從jbpm、osworkflow的流行也可以看出這一點，並且知識的積累確實比購買工作流來的划算，同時很多公司通過積累也會有自己的流程元件，這並沒有太大的難度。難度留給技術能力一般的公司，他們首先想到的會是一整套解決方案而不僅僅止於流程服務，於是平台出現了，平台說：「灰殼顯靈，銀彈來了。」
關於平台，有乙個很時髦的流行詞彙，叫「業務應用基礎平台」，稍候待續。
需求工作流
1 概述 系統分析師在需求團隊中主要是與客戶和系統使用者合作來確定客戶需求。因為資訊系統是複雜的，因此客戶有時會要求乙個不合適的資訊系統。解決方案是把從客戶和將來的使用者獲取的初始資訊作為同一過程的輸入，不斷進行迭代，從而確定客戶的真正需求。發現客戶需求的過程為需求獲取。對初始需求進行細化和擴充套件...
工作流需求的大概分析
使用者的需求大概分為兩部分 一部分是整個專案完全基於工作流來搭建開發，這也是很多任務作流廠商患有 平台壓迫症 的原因 另一部分是將工作流作為業務元件加入已有的專案中，推動業務的 審批 流轉。前者的要求顯然更高，但也意味著有更多的利潤。其實這一部分的使用者又可以進一步的細分 一是技術能力比較差的公司，...
工作流模型分析
工作流模型分析 多例項模型 所謂多例項模型，指的是流程中的同乙個活動，同時存在多個例項。1 非同步 多個例項產生後，這些例項各自為政，互不影響。因為互不影響，所以非同步的多例項模型的產生的例項數是任意的。當說到可以產生的 例項數時，我們說的都是同步的情況，就如下面三點。2 定義期決定例項數 說的簡單...