功能
1.定義流程：用戶可以自定義流程類型以滿足企業需求；
2.設計流程：用戶可以使用工具方便簡單的設計工作流程圖；
3.定義規則：用戶可以在流程中觸發執行自定義的腳本，完成特定的業務工作；
4.分配任務：用戶可以分配工作任務，包括系統中的一些工作任務，如登入、登出、歸檔等；
5.分配人員：在每一個工作點可以分配工作人員。另外，管理者可以把工作委托給其他人完成，也可以在運行時确定工作人員；
6.啟動工作：可以選擇要處理的工程圖紙或文檔，啟動工作流處理後繼工作；
7.接收流程：接收本人要處理的流程；
8.執行任務：可以利用流程信箱接收和發送流程，執行分配給自己的任務；
9.發送流程：将流程發送到下一個節點；
10.跟蹤流程：流程圖節點以不同的顔色表示當前運行情況；
11.監控流程：流程的管理者可以及時掌握流程的情況。可以查看過期任務、解決流程運行中出現的問題。
組成
根據流程要包括的功能，把整個流程分為三個部分，分别實現上述功能：
1.設計模塊：設計流程圖的工具。使用流程設計模塊可以建立流程圖、保存流程圖、把流程圖分配給流程；
2.運行模塊（流程信箱）：啟動流程、接收流程、執行任務、發送流程；
3.監管模塊：流程管理工具。管理員可以查看和監控已經運行的流程，出現問題或過期的流程可以及時得到調整。
管理流程存在問題
1）分工過細導緻一個經營過程有很多部門完成，運作的時間長，成本高，信息在各部門流通時，需要花費大量的時間和精力進行交流、溝通。各個部門對需要處理的事件又有不同的優先順序，都是把自己認為最重要的事件優先處理，因此很難保證一個經營過程按照顧客所希望的時間完成。
2）各部門按職能劃分，員工隻對自己的上級主管負責。部門所追求的是部門的最優，各個部門都盡可能地占有企業資源以及獲得最大利益，很難達到整個營過程的整體最優。但企業的生存取決于對顧客提供的産品和服務，顧客并不關注企業中的某個部門業績，而是整個企業的經營行為。
3）現在的企業層次過多，機構臃腫，為了銜接各個部門和各個環節，企業需要設置許多管理人員，這些管理人員對經營過程進行協調，控制，監督，審查。
業務流程管理
營銷規劃
營銷規劃解決賣什麼、賣給誰的問題，以及如何運用科學的工具分析、判斷我們現在的市場選擇是否合理，和如何對未來市場進行合理規劃的問題。
銷售平台
銷售平台解決誰來賣的問題，找到“人材”、培養“人财”、留住“人才”，建立優質銷售環境，激活團隊，實現業績倍增。
銷售進程管理
銷售進程管理解決怎麼賣的問題，分解銷售動作，形成企業個性化業務手冊，批量制造銷售精英。
客戶服務管理
客戶服務管理解決如何重複賣，建立标準化客戶服務體系，提升客戶忠誠度。
客戶關系管理
客戶關系管理解決如何永久賣，建立客戶分級管理标準，實現客戶終身價值最大化。
風險防範
風險防範解決如何安全賣，實現銷售過程中的風險和價值平衡,确保銷售過程更安全。
業務流程管理的方法
面向工作流的BPM
工作流描述了在BPM空間内人與人的交互和人與系統的交互。根據獨立分析師Sandy Kemsley所述，工作流就是我們所熟知的BPM的初始階段。“一開始就有工作流，”Kemsley在她網站的第二專欄中寫道。“更确切地說，在預先确定的流程圖中有一個掃描過的人與人之間交互的路由文檔。”在當代BPM的大背景下，工作流和EAI(企業應用集成)平起平坐，并在某種程度上，可以看成是人的集成。工作流BPM旨在優化業務流程中以人為本的活動。這些措施包括活動監控，流程治理，正如BPM的成因，是對未完成文檔向下進一步處理的編制。
面向文檔的BPM
文檔管理和工作流齊頭并進。當文件穿過工作流時，追蹤文件的去向以及它們的變動，維護文檔記錄的可靠性、安全性、可用性，早在計算機革命之前，已經成為了業務的必要元素。今天的企業文檔管理系統利用計算機技術來提供存儲、安全、索引和檢索選項。可用性正日益重要，因為多方參與者經常需要憑借多個應用來使用同一個文件。因此，依靠現有業務系統的集成是面向文檔BPM成功的一個主要元素。
面向業務規則的BPM
自動化這門學科可以追溯到人工智能的早期，當時研究人員試圖以最簡單的術語，集中于規則的使用來描述複雜的系統。像最早的嘗試模拟國際象棋遊戲實驗計算機，這些系統按照狀态機的模式工作。有點像遊戲規則，組織顯式地或隐式地按照關鍵“規則”來定義過程，這些關鍵“規則”在流程的某些點上提出要做出哪些決定或更改——或請求哪些授權。一旦被稱為推理機，同類的軟件系統就發展成了業務規則引擎或者業務規則管理系統。創建和維護業務規則的複雜性常常成為這些推廣這些系統的阻礙成分。這些系統承擔了類似以建模為中心的BPM工具的角色。(誠然，很多用戶會将以建模為中心的BPM作為一個獨特的類别。)以建模為中心的方法起初傾向于自上而下的進行工作，這些工作就是在模型中用特殊符号描述一個組織，或組織的改進。近年來一些工具廠商已經完成對可執行模型的支持——他們的模型可以生成或者幫助形成可用的業務邏輯的代碼。與這裡介紹的其他類型的BPM系統相比，業務規則引擎在純BPM系統中的規模将變得更大。
面向EAI的BPM
在整個90年代從不同系統對集成可操作型數據方法的改進，采取的是企業應用集成或EAI的形式。雖然這些往往是硬接線的一對一集成，消息隊列這種應用集成變得尤其流行，同時隐含業務流程表現為有組織的隊列，例如，清除銀行支票或執行庫存訂單，讓集成服務器很大程度上有了面向工作流的BPM的味道。今天，許多架構師都傾向于把數據集成問題看成業務流程問題。同樣地，一些架構師将期望根據B2B或電子數據交換(EDI)來集成的過程自動化。
