Both Workflow and BPM are systematic approaches and technologies to improve a company’s business processes (and performance). From a business perspective, they are ways to make people, information and computers work together more consistently and efficiently to produce needed results.
For example, a workflow/BPM-enabled application could monitor receiving systems for missing or defective items, or walk an employee through the steps to troubleshoot why an order arrived late or not at all.
Both technologies foster ongoing collaboration between information technology (IT) and business users to jointly build applications that effectively integrate people, processes and information. They provide organizations with the ability to define, execute, manage and refine processes that:
* Involve human interaction (such as placing or approving orders);
* Integrate and work with multiple diverse applications; and
* Handle dynamic process rules and changes, not just simple static flows, (i.e., those flows that enable tasks with multiple choices and contingencies/escalations).
The market for workflow and BPM applications is highly stratified and fragmented, in part because the currently available products stem from different origins. Namely, there are former pure integration vendors or document management/enterprise content management (ECM) vendors that have meanwhile encroached into the BPM space.
The difference between workflow tools and BPM suites is largely a semantic distinction, and the gist of the matter is that a workflow engine is at the heart of BPM suites with process execution capabilities. Also, in most cases vendors who sell applications labeled as BPM are aiming at a bigger scope and more complex projects, with elaborate software supporting even more elaborate methodologies, process defintion and modeling, collaboration methods, and so on.
Features and capabilities are not necessarily the only differences between tools, since usually the products aimed at simpler processes focus strongly on “ease of use.” The designers’ assumption is generally that the users are non-IT experts within the company. Such workflow products might be built around the concept of an intelligent form. Basically, the user develops the workflow by filling in a familiar-looking form (e.g., a “tasks vs. actions” matrix), including the business rules.
Yet the limitations of the simpler workflow tools become evident when they attempt to manage inter-process dependencies amongst several applications, handle complex database integration and handle tasks that partake in larger, more complex processes.
For example, a workflow/BPM-enabled application could monitor receiving systems for missing or defective items, or walk an employee through the steps to troubleshoot why an order arrived late or not at all.
Both technologies foster ongoing collaboration between information technology (IT) and business users to jointly build applications that effectively integrate people, processes and information. They provide organizations with the ability to define, execute, manage and refine processes that:
* Involve human interaction (such as placing or approving orders);
* Integrate and work with multiple diverse applications; and
* Handle dynamic process rules and changes, not just simple static flows, (i.e., those flows that enable tasks with multiple choices and contingencies/escalations).
The market for workflow and BPM applications is highly stratified and fragmented, in part because the currently available products stem from different origins. Namely, there are former pure integration vendors or document management/enterprise content management (ECM) vendors that have meanwhile encroached into the BPM space.
The difference between workflow tools and BPM suites is largely a semantic distinction, and the gist of the matter is that a workflow engine is at the heart of BPM suites with process execution capabilities. Also, in most cases vendors who sell applications labeled as BPM are aiming at a bigger scope and more complex projects, with elaborate software supporting even more elaborate methodologies, process defintion and modeling, collaboration methods, and so on.
Features and capabilities are not necessarily the only differences between tools, since usually the products aimed at simpler processes focus strongly on “ease of use.” The designers’ assumption is generally that the users are non-IT experts within the company. Such workflow products might be built around the concept of an intelligent form. Basically, the user develops the workflow by filling in a familiar-looking form (e.g., a “tasks vs. actions” matrix), including the business rules.
Yet the limitations of the simpler workflow tools become evident when they attempt to manage inter-process dependencies amongst several applications, handle complex database integration and handle tasks that partake in larger, more complex processes.
No comments:
Post a Comment