Today’s Intelligent Enterprise cover story “Business Process Management is Under Construction” is focussed specifically on modeling, analysis and reporting, business activity monitoring (BAM) and simulation features (since they cover integration and automation features in an earlier article).
Their assessment shows BPM as still at a relatively early adoption state:
BPM software is headed for mainstream adoption, but it’s still a relatively small, immature market… Plenty of organizations have yet to discover BPM… 36 percent said they were considering BPM and 29 percent said they had no plans to implement it, while only 24 percent said they were either piloting, rolling out, in production with or upgrading BPM.
That’s certainly what I’m seeing in many organizations, and why BPM evangelism is going to be required for some time still. Yes, there’s lots of successful BPM case studies to point at, but if you dig into the infrastructure at a large financial institution (for example), you’ll find a lot of EAI and not a lot of real BPM. Intelligent Enterprise states that even the basic automation and integration are still a challenge for many organizations, but I’m finding that the integration part has pushed forward because EAI is typically an IT initiative to integrate systems behind the scenes: the business benefits obliquely but their environment may not be impacted at all. On the other hand, automation requires true BPM (including human-facing workflow, modelling and simulation, and a whole raft of other features not typically found in EAI), plus full involvement of the business in order to achieve success, so gets hung up on the continuing disconnect between IT and the business that they serve.
Compliance is certainly going to push BPM forward, although that requires closed-loop process control throught the addition of analytics and simulation. There needs to be a bigger focus on making BPM performance monitoring and improvement a part of the larger corporate performance management framework, and showing how BPM fits into an organization’s enterprise architecture framework.
There are two more BPM articles in this issue of Intelligent Enterprise, “IT Detours on the Road to BPM” that discusses nine BPM suites’ closed-loop capabilities, and “Simple Process Management: Quick, Cheap and Easy” about Nsite, a hosted solution for a limited range of administrative-type workflows. I’d love to stay and blog all day about them, but it’s a holiday here and I’m going sailing.
An article in Business Integration Journal about using BPM to achieve Six Sigma objectives, by Carl Hillier, a former colleague of mine at FileNet. I first met Carl about 10 years ago when he was a FileNet systems engineer in London and I owned a professional services firm that helped customers implement FileNet systems, and I’ve always had a great deal of respect for his opinions (although not always for his choice of bosses): not only is he smart technically and knows more about FileNet BPM than just about anyone, but he can write beautifully coherent sentences about it.
Of course, he does give space to the FileNet party line in several spots, (“a robust BPM solution provides a fully integrated content repository” — I consider an integrated content repository to be “nice to have” but not essential), but he does hit the nail on the head when he talks about BPM helping to provide a “closed loop” environment for Six Sigma’s Define, Measure, Analyze, Improve, Control (DMAIC) continuous process improvement cycle through the inclusion of process analytics and simulation.
If you caught their webinar on Business Performance Management and Optimization a few weeks ago, you’ll know that ebizQ is putting together a survey on business performance management for their Buyer’s Choice Awards. You can help create and weight the criteria that will be used in the survey if you’re so inclined.
I’m still having a bit of trouble with the whole business performance management thing. The goal is to optimize business performance by aligning what goes on in the business with the corporate KPIs (e.g., customer retention rate). Okay, it makes sense that you focus on doing things that provide measurable improvement to the business; in fact, it’s not only common sense, it’s very similar conceptually to Six Sigma and a number of other business improvement practices that have been around for decades. A somewhat more esoteric goal of business performance management is to allow an organization to make decisions in real time, and become predictive rather than reactive. Lots of potential pitfalls this; it harkens back to the agility problem, which says that organizations aren’t being agile even when they have the capability to do so. Also, BPM definitely plays a major role as an input channel to business performance management, but don’t follow into the trap of optimizing operational processes while inadvertantly blowing your KPIs.
Business performance management is being defined as a combination of methodologies, best practices and technologies, where the technology includes event/process monitoring, management dashboards, rules engines, business intelligence, simulation, collaboration and potentially the kitchen sink. Maybe that’s why we have so many vendors claiming that they’re in business performance management: by this definition, there’s probably fewer software vendors who are not included than who are. In some cases, the technologies of business performance management are collectively referred to as BAM; in other cases, BAM refers only to the event/process monitoring. Personally, I would go for the former definition, but I don’t have a lot invested either way.
My problem is this: what distinguishes the concept of business performance management from that of the decision support systems (DSS) or executive information sytems (EIS) that we built in the 1980’s, except that the technology is a bit more advanced? This is being hailed as the new saviour of business, and I feel a bit like I’m looking at the Emperor’s new clothes.
I found this post about BPM suites versus best of breed to be an interesting take, although misguided. The blog is written by a Fuego systems engineer and as expected, his blog entry espouses the corporate party line of “BPM suites good, best of breed bad”. Every suites vendor will tell you exactly the same thing, and they’re all a bit right and a bit wrong. Yes, there are benefits to having an end-to-end integrated solution: typically, information flows more easily between components, and there’s no finger-pointing when an interface doesn’t work as expected. However, if the suites vendor’s components don’t give you all the functionality that you require, then you really should be looking elsewhere for the specific components.
Apparently an analyst told one of his customers that no BPM suite does it all, and to consider separate modelling, execution and BAM vendors. Good advice, as far as I’m concerned. Personally, I don’t interpret this to mean that the suites vendor should be excluded from the evaluation of all components, it just means that other vendors should be included. It also doesn’t mean that business is yielding their role in the design and management of processes to IT by choosing multiple tools, just that they use different (and equally competent) tools to participate.
Process modelling is a great example. Most BPMS modelling tools don’t allow for the modelling of manual steps, that is, steps that have nothing to do with the automated process, such as opening mail; they also don’t allow for modelling in the larger context of enterprise architecture. Any business that is serious about documenting enterprise architecture and improving their processes has probably already started modelling their processes using something like IDS Scheer’s ARIS Business Architect or Proforma’s ProVision. For a BPMS vendor to assume that a) process is the only thing to be modelled in the enterprise and b) only steps that touch their product are important, is being a bit unrealistic about where BPM fits into enterprise architecture. I’m the first person to step up and state that process is a key part of any organization, but I would never imagine that it’s the only part.
BAM is another example. Again, BPM suites include enough BAM to monitor and report on the processes that are controlled by their execution engine, but have no vision of the larger performance management landscape that exists within an organization. Execution stats from a BPMS are only one source of data that can feed into a broader performance management system: a company does not manage by process alone.
As a final note on the blog post that started my train of thought, I find it interesting (yet unsurprising) that the only component that he doesn’t recommend buying from the BPM suites vendor, a rules engine, is one that Fuego doesn’t sell.
Today’s Integration 101 webinar talked about why it’s important to integrate applications. Basically, if you don’t, then you probably have the following problems in your business processes:
- No real-time visibility into the process
- Long cycle time due to manual data gathering and other non-automated tasks
In other words, your customer drops their information into a black hole and nothing happens for a long time, so there is a higher risk that they take their business elsewhere. Not only is the process inefficient (and therefore costs you more to operate), but it results in lost revenue.
When you use BPM for your large scale processes where several internal and external applications are integrated, you’re moving into the area of process orchestration: the BPMS is invoking, controlling and tracking what goes on in all of the applications. Add in a business rules engine to automate decision-making in the process, and BAM to publish a real-time view of what’s going on, and not only are things more efficient due to fewer manual steps in the process, but your customer can see what’s going on at each step of the process.
Realistically, the only way to do this level of enterprise application integration such that it’s maintainable, flexible, extensible and reusable, is to use a service oriented architecture to expose the applications’ functionality as services to be called by the BPMS. Otherwise, you’ll be right back in a spaghetti mess with the same (or competing) business logic embedded in multiple applications.
A few more notes on today’s ebizQ webinar on BAM. Ms Gold-Bernstein talked about another topic close to my heart, namely that BPM is one of the contributing sources to BAM/performance management, rather than BAM being a part of BPM (as the BPM vendors would have you believe). The term “BAM” was originally coined by Gartner, so they’ve had first dibs at saying what is and is not BAM:
BAM defines the concept of providing real-time access to critical business performance indicators, along with the supporting information to improve the speed and effectiveness of business operations.BAM is accomplished by monitoring multiple systems, creating real-time dashboards, and using context and rules to detect the occurrence of a pre-defined set of circumstances.
They list BAM technologies as including BPM, integration middleware (arguably part of BPM under Gartner’s own definition), BI, dashboards with KPIs (which I would consider part of BI), and IT operational management (ditto). Since BAM is defined as a concept and is linked to all of these technologies, there are a lot of vendors from all different areas scrambling to get into BAM magic quadrant — not unlike what’s happening with BPM vendors ever since Gartner lumped together all process-related technologies as “BPM”.
To confuse things further, Gartner’s report on the convergence of BPM and BAM lists three main areas of overlap, and therefore potential conflict:
- BPM acting as “BPM+BAM”
- BPM serving as BAM’s response mechanism or recipient
- BPM ? or business process analysis (BPA) ? serving as a passive analytic/visualization model for BAM
Prior to Gartner defining BAM, there was performance management, which is more focussed on the BI side of the equation, including technologies such as BI, dashboards and, lately, CEP (complex event processing). Although the goals of performance management are fundamentally the same as BAM (business alignment, real-time KPIs), the scope is narrower by excluding BPM and middleware technologies.
Somehow, the concept of performance management as pure business intelligence makes more sense to me than including (rather arbitrarily) some of the technologies that produce the data that feed into the performance management. If BPM is included as one of BAM’s technologies, why not databases, or CRM, or any other technology within an enterprise that produces data that may be of interest to management? In fact, if there’s a technology within an enterprise that doesn’t contribute data to performance management KPIs, why is it there?
A webinar going on right now on BPM, BAM and SOA: Optimizing both Business and IT focussing on the ROI of process integration. Beth Gold-Bernstein contrasted the tactical versus strategic approaches to process integration:
- Tactical approach requires defining underlying integration infrastructure
- Strategic approach — enterprise integration architecture defines infrastructure, business defines the process
This goes back to one of the key ideas that I’ve been working with lately, namely the role of process and BPM in an enterprise architecture framework.
She also made a distinction between web services orchestration and business process management, where she sees WSO as providing a graphic way to design and control flow between web services, but without all the process governance (monitoring, analytics, management and simulation) that you would find in BPM. Given the role being assigned to BPEL, is this just another artificial distinction in the process marketplace?
A week ago today, I was in a tutorial by Roger Burlton of the Process Renewal Group on Enterprise Business Architecture: Strategy, Process and Capabilty Alignment while at the BPMG conference in London. He made a great analogy regarding performance measures: knowing the final score doesn’t tell you if it was a good game. (Although after once watching the Blue Jays lose 22-2, I posit that you could have told that it was a crappy game by the score alone.) Roger was one of many people at the conference who spoke about BPM in the context of measuring business goals. To quote Terry Schurter, who I heard speak the following day at his session BPMS – Selection by Business Value, “goals that can’t be measured aren’t goals”.
All this shows that BPM is finally creeping out of departments and into the mainstream of the enterprise. I read a post about a CEO’s view of BPM as discussed at a recent CEO roundtable today on the Milestone Group’s Thoughts On The Tech Industry blog that really nailed it:
BPM, or Business Process Management is the fasting growing segment in the BI / Data Management market sector. Growing out of departmental process management initiatives, the key driver now is to integrate across the enterprise, and to provide scorecards, reports, and other “C Level” deliverables with more confidence, so that predictive modeling and optimization initiatives are really based on the most complete and highest quality set of data available in the enterprise.
The CEOs consider BPM as a feed for enterprise BI/performance management, which is completely accurate — after all, why else would you be doing BPM if not to improve performance, and why would you be doing anything to improve performance if you weren’t also including it in your enterprise performance measures?