Few people will deny the value of good business process management (BPM), but perhaps fewer could provide a comprehensive...
definition of just what BPM means. That's because BPM means different things to different people, depending on the processes that need to be managed and how. We've categorized four major types of BPM below.
Workflow describes the person-to-person interaction and person-to-system interaction within a BPM space. According to independent analyst Sandy Kemsley, workflow is where BPM as we know it got its start. "In the beginning there was workflow," writes Kemsley on her Web site, Column 2. "To be more precise, there was person-to-person routing of scanned documents through a pre-determined process map." In the larger context of contemporary BPM, workflow sits opposite EAI and, in a way, can be seen as human integration. Workflow BPM seeks to optimize human-oriented activities within a business process. These include activity monitoring, process governance and, just as at the genesis of BPM, orchestrating hand-offs of unfinished documents for further processing down the line.
Document management and workflow go hand-in-hand. Tracking where documents have been and what changes have been made to them as they travel through a workflow, as well as maintaining records of document authenticity, security, and availability, has been a necessary element of business since long before the computer revolution. Today's enterprise document management systems use computer technology to provide storage, security, indexing, and retrieval options. Availability is increasingly important, as a single document often needs to be used by multiple parties through multiple applications . As a result, integration with existing business systems is a major element of successful document-oriented BPM.
Business Rule-Oriented BPM
A school of automation going back to the early days of Artificial Intelligence, when researchers sought to describe complex systems in the simplest terms, centers on the use of rules. Like the earliest experimental computers that tried to mimic the game of chess, these systems worked in terms of state-machines. Somewhat like the rules in games, organizations define processes explicitly or implicitly in terms of key "rules" that set forward what decision or alteration to make—or what authorization to request—at certain points in a process. Once known as inference engines, the software systems of this ilk evolved into Business Rules Engines or Business Rules Management Systems. The complexity of creation and maintenance of business rules has often been an inhibitor to these systems' wider use.
These systems bear similarity to what some would describe as model-centric BPM tools. (Admittedly, many viewers would place model-centric BPM as a distinct category.) Model-centric methods tend to start as top-down efforts that describe an organization, or organization improvements, in models with specific notation. In recent years some tools makers have come to support executable models—models that in their turn can generate or help generate code that forms usable business logic. As with the other types of BPM systems described here, Business Rules Engines are increasingly becoming part of larger, pure BPM system.
Methods for integration of operational data from diverse systems improved over the course of the 1990s, taking the form of Enterprise Application Integration, or EAI. While these were often hard-wired one-to-one integrations, message queuing for application integration became especially popular, and the implied business processes represented by organized queues of, for example, bank checks to be cleared or inventory orders to execute, gave integration servers much of the flavor of Workflow-Oriented BPM. Today, many architects are inclined to view business process problems as data integration problems. In the same way, some architects will look to handle process automation along the lines of B2B or Electronic Data Interchange (EDI) integrations.