Business Process Management (BPM) is simply the modeling, execution, measurement, and subsequent improvement of business processes. Most pure-play BPM vendors offer tools to support all of the above. But it must be recognized that each of those pieces are an industry all their own, and to accept that a company has solved all of them sufficiently and now offer a suite of integrated tools, should be considered critically.
Regardless, the adoption of a strong BPM execution engine should be strongly considered if not actively pursued by many process intensive organizations.
When doing so, consider the following points.
All processes should be documented through models and text. But not all models are necessarily executable, especially if they are fired rarely. This is true since making a process executable, and maintaining it as it changes, costs developer time. That cost may not be recaptured by any gain the executable process provides.
Models by themselves are documentation, and will greatly improve training and communication, especially within largely staffed fulfillment and provisioning teams. They should also act as requirements to supporting business systems or product development teams. Better yet, groups devising new products should hand off process models to fulfillment organizations to help them better determine the impact of a new product on their organization.
Additionally there must be a methodology framing the modeling process. Without one, you will have what amounts to a stack of ad-hoc Visio diagrams if the business analysts don't agree on model coarseness, semantics, and idioms, regardless of the tool and standard (BPMN).
BPM vendor modeling tools are primarily intended for the developing of executable models, not necessarily for documenting and collaborating.
Also consider that there are roughly two qualities of process metrics and three major consumers of those metrics. The two qualities can be roughly framed operational and organizational. The three audiences are those using the system, their direct or front-line managers, and those managing the managers.
I'll roughly define operational metrics as being mostly real-time, and scoped to the current activities of the managed teams. These metrics are typically used to observe and manage workload (and subsequent bottlenecks), also known as 'work in progress' (WIP). These metrics eventually end up supporting the organizational metrics. Users and front-line managers need these metrics to help make rapid and timely decisions.
Organizational metrics are generally provided periodically (daily, weekly, monthly, etc), and tie in other numbers from finance or other similar process managed groups, and generally bring to the surface important key performance indicators (KPI). Besides supporting the numbers for operating efficiency, they help forecast needed resources when rolling out new or similar products. Front-line managers and their managers rely on these metrics to help determine where process improvements should be made and offer a baseline for determining how.
Most BPM vendors will provide simple reports or live process models showing the WIP for a given process. But don't expect them to solve the traditional Business Intelligence problems associated with delivering organizational metric types of reports.
In quick summary, strongly consider that any BPM deployment should be complimented by strong modeling and analytics tools. Smaller organizations might find current BPM suites sufficient, but do read between the lines. For example, some BPM vendors will ship OEM'd OLAP tools as their analytics solution. This isn't a bad thing, you just might want to spend the money ramping up what your company may have already invested in.
Leave a comment