Every mature technology seems to beg for an upgrade, at least from a marketing perspective. Business process management...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
fits the maturity side of that statement, and intelligent BPM, or iBPM, certainly appears to be the latest thing.
But is iBPM more than marketing? Looking at some modern examples of BPM use cases can help you separate the hype from what is truly a reality for the workplace.
Defining iBPM through use cases
Definitions of iBPM tend to be mechanistic. Some say it's the sum of BPM, big data and social media. That's helpful in analyzing what makes up iBPM, but not when deciding what value it might bring and whether it's even a product or simply an integration of practices. Don't start this way if you want the best outcome.
If you want to avoid marketing hype with iBPM, you have to focus on the business changes that demand changes in BPM. Three drivers dominate iBPM use cases today. The first is improving the productivity of mobile workers by supporting their new relationship with business processes. The second is applying analytics in a dynamic and interactive way to spot trends that promise improvements in the process-to-worker coupling. The third is addressing the modern trend toward event-driven business processes, including the internet of things (IoT). We can look at examples of BPM user stories in these three areas to get the true picture.
No change in BPM is justified if you can't link it to an improvement in the way that IT supports workers. The No. 1 thing business use cases focus on is mobile empowerment. The mobile worker frames IT needs around their own needs. Traditional BPM has presumed that IT tracks orderly, sequential workflows. Mobile workers just don't operate that way.
Most of the early mobile empowerment applications simply gave mobile workers access to what they'd see at their desks. This hasn't proven to be particularly helpful in improving productivity, and examples of BPM use cases based on this approach have demonstrated the limitation convincingly. Mobile workers want to drive processes, and when that dimension is added to use cases, there is a reduction in the "length" of workflows in favor of a discrete-process view of activity.
This does have a big data dimension, and also one that links to analytics. If workers are the binding that links discrete processes into flows of activity, then you have to look at worker tasks rather than traditional business processes. Getting a handle on just what those tasks are is challenging, but one modern way to achieve a task-centric BPM view is to look at the data elements and their relationships. Entity-relationship (ER) modeling should be a cornerstone of iBPM according to many early trials, and if it doesn't start out that way, then the trials have to adapt to incorporate a more ER-centric view.
Even ER doesn't fully address the worker-driven process model that's the goal of mobile empowerment. Fast or dynamic analytics has proven to be essential because workers often can't visualize how they would use information that's not currently available. What early tests have shown is that all too often a worker will say something like, "I wonder how often this and that happen consecutively." Instead of having analytics, in some packaged form, drive decisions, workers want to test hypotheses using analytics in a dynamic way.
Dynamic analytics is a two-part process, where responsive queries are only the second step. First, you have to be able to offer workers an easy way of framing questions that analytics can answer. There's no time for intermediary action by an IT professional here, nor is it practical to assume that workers would learn query languages. Generally, analytics tools that explicitly link to applications or provide a link-to-action capability will be easier to incorporate in dynamic analytics tasks. The easiest approach is to anticipate the need for analytics in "what if" form and create an application link with the data elements mobile workers use most often.
Addressing modern trends
Both the mobile-worker productivity goal and the dynamic-analytics goal are linked with event-driven applications. Mobile workers often encounter things rather than seek them, which makes their behavior more event-driven. This model is a major driver of dynamic analytics because encounter-based worker support demands responses to conditions. Mobile worker applications are becoming increasingly contextual, where the goal is to give the worker information based on where they are, in a geographic or application sense.
IoT is an extension of this model. First, IoT can provide context by feeding an application with information about worker location and the state of any system that the worker might be interacting with. Second, IoT supports closed-loop machine-to-machine applications that take a worker partly or wholly out of the loop.
IoT demands the ultimate level of process fragmentation, because events drive individual processes rather than workflows. They also demand dynamic analytics feedback into the control loop to help the system anticipate the result of changes based on historical data and predictive analysis. But event-driven systems like IoT often require the analysis of multiple events and their relationship, which takes you into complex event processing (CEP). This model not only forces processes themselves to be atomized down to the function/microservice level, but it also demands a more microservice-based analytics model.
An evolving market
Analytics can be integrated into both applications and CEP if they're provided in microservice form, which means that the biggest technical requirement for modernizing BPM, and the biggest single differentiator for iBPM, is microservice-based composability. It's common to all the use cases, yet it's not usually even noted in discussions of iBPM. There is also a conspicuous lack of integrated tools for iBPM to cover the needs of the three primary use cases. All this speaks to a market that's not yet mature and, in fact, may still be in its very formative stages.
While that's bad news for prospective iBPM users at one level, the good news is that there are tools available to support all of these requirements. Enterprises that fit one or more should be prepared to do some self-integrating, but the examples of BPM trends shown here suggest there is enough opportunity to justify the effort toward enabling iBPM.