I happened across this article on how Sarbanes-Oxley is a “business blessing in disguise” since it can show you where your organization’s weak points lie, so that presumably you can fix them. Although it’s primarily discussing ERP systems, this same concept (business improvement/competitive advantage through compliance) is an area that I’m addressing for a client right now by looking at how BPM fits into the compliance big picture. That has me thinking about all sorts of things: BPM, business intelligence, business rules, performance management, compliance, and how they all fit together. You can be sure that there will be more on this in the future.
Category: process
business process management
BPM and BR: Mars and Venus again
As I mentioned in this post, there’s a bit of Mars and Venus about BPM and business rules (BR).
I’ve viewed two BPM-BR webinars recently. The first, a replay from back in March on the convergence of BPM and business rules; since I’ve been writing a lot about this topic lately, I gave it a quick browse. It’s hosted by BPM Institute; there are a lot of other webinars (“round tables”) on BPM-related topics on their site, both past ones that you can replay or future ones that you can sign up to attend live. The speakers in this webinar were from Knowledge Partners and Pegasystems, both heavily into business rules: Knowledge Partners is a business rules consultancy that also does some training and software extensions that integrate business rules with other platforms such as RUP, and Pegasystems is a BPM vendor whose product is built on a rules engine.
You’d have to have your head in the sand not to notice the importance of business rules in BPM, but if you’re still having trouble convincing anyone, then this webinar might give you a few pointers about why it’s so important. From a business standpoint, the two key drivers for having BR in your BPM are agility and compliance: the rules that define your business must be flexible and extensible (agile), as well as explicit and measurable (compliant). To have these rules explicitly defined and managed by the business community, separate from the logic in the BPMS, goes directly to the issues of agility and compliance. The speaker from KPI made the point that your business is already running by these rules, whether you know it or not, and by collecting them into a BRE, you’ve made a step towards getting control of your rules and procedures (and therefore compliance).
To decide where the interface lies between BPM and BR, take a look at your processes (c’mon, I know that you’ve modelled them already) and highlight the activities that involve decisions and rules, such as scoring. These activities are where you’ll invoke business rules, whether directly in the BPMS (as with Pegasystems) or by calling a third-party rules engine. These rules should be directly tied to business motivations/key performance indicators. Then, walk up KPI’s pyramid:
[As a side note, I especially like the second step in the pyramid: “understand which rules are worth managing formally, and why”. Organizations typically get locked into the old way of doing things not because things are done in a certain way, but because no one understands why something is done that particular way.]
The KPI speaker pointed out that there are often different groups within an organization who are looking at BPM and BRE, with one from the business side and the other from the IT side. She mentioned the scenario of BPM being driven by business and BRE by IT, but I’ve seen it the opposite way around recently with a large insurance company client. In fact, I think that most people who even think about this see BPM as still “belonging” to IT, whereas BR “belongs” to the business. I could write a large tome on why they both belong to the business, but that’s for another day.
Yesterday’s live webinar was by TIBCO on increasing your BPM ROI by incorporating BR; there’s a registration form on the TIBCO site that I assume takes you to a replay of the event. The main speaker was John Rymer from Forrester, and he gave a good overview of how BR improves BPM. From his presentation:
- Speedy, accurate business decisions and actions
- Common expressions of policy, practices, other logic can be evolved in business time
- Single source of truth for core business rules aids compliance reporting
- Automation of conditional steps in flows and conditional calculations improves agility
- Business analysts can make adaptations and change
He showed how these factors related to hard ROI in this chart:
This is not different from the KPI/Pegasystems webinar mentioned above; it all comes back to agility (by allowing changes to rules without changing the process flow, which is somehow seen as less agile) and compliance (through standardization and documentation).
Rymer sees three different BPM-BR implementation scenarios: the decisions are embedded within the BPM flow; the BPM is rules-based (like Pegasystems); or the BPM “calls out” to a general-purpose rules engine. There is a fourth scenario, which I have seen used (and have myself implemented) extensively, which is that the rules logic is resident in another system, sometimes a legacy system, and the BPMS integrates with that system in some way to execute rules. This is a broader definition of “call out” that includes his third scenario, and I’ve seen it often in insurance implementations where underwriting or claims rules are already implemented on a legacy system and just need to be called at a point in the flow.
Since TIBCO hosted this webinar, they found an analyst who speaks very well of the idea of having a BRE embedded within your BPMS; I don’t disagree with this, but I can also see the advantage of having the BRE as a foundation of the BPMS, as with Pegasystems, or even using a third-party external BRE that may also be in use for other rules applications within your organization. It works any of these ways; the important thing is to have a BRE in there somewhere.
No matter how it’s implemented, I imagine that some BPM advocates may see the integration of BR as somehow demoting the importance of BPM: for years, the BPMS vendors have been building increasingly advanced decision-making capabilities into their products, and now the BPMS will just be used to route work and call the BRE when instructed. My advice: get over it. Sure, you’re going to build much less complex decision-making directly in the BPMS once you integrate a BRE, but you’re going to get so much more in return.
Fuego and Plumtree
I don’t mean to be blogging just about Fuego these days, although since I’m in the middle of evaluating their product, I’m probably more attuned to stories about them. I found Gartner’s assessment of the recent Fuego/Plumtree OEM agreement interesting:
Fuego’s original equipment manufacturer deal with Plumtree is the first strategic relationship between a business process management suite vendor and a complementary middleware vendor. This is a game-changing event that will pull Fuego ahead of its closest competitors in the crowded BPMS market.
The agreement was made in May, but Gartner’s comments just published this week.
Business Performance Management survey
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.
Free BPM
I saw a post on CMSwire today about how you can replace Microsoft’s simple CMS workflow with a more comprehensive product from Skelta — for free! Okay, it’s their light version, but may be worth checking out if you’re a Microsoft CMS user.
Suites versus best of breed
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.
Peeking at Fuego
When I was at BPM 2005 in London back in May, Fuego was one of the exhibitors (there were only about 10 so it was easy to see them all), and I heard independently from a few attendees that they were looking at or using Fuego. I dropped by the booth and talked to their Director of Marketing, who promised that if I applied online to evaluate their product, he’d make sure that I was approved promptly. He knew that I was headed off for vacation in May/June, but emailed me after I returned and asked when I was going to take a look at it, so I finally got around to downloading the Fuego Process Orchestration Studio and I’m trying it out over the next couple of weeks.
My first thought is that this is an independent contractor’s (you know how I hate the “consultant” word) dream: Fuego bundled all the design and development tools — including Tomcat to serve the end-user portal and the Cloudscape database for RDBMS components and directory services — plus a mini runtime engine into the Studio package, which means that I don’t need to source and install a compatible web server and database independently. Furthermore, the minimum system requirement on Windows is 512MB of memory, and it runs quite well on my 3-year-old 1GHz laptop with its 576MB of memory. This allows me to do anything that I would need to do with a Fuego customer in terms of designing a process or custom development, including full runtime testing, as long as I had access to (or could emulate) any external components that are called by the process, using a mid-range mobile machine instead of a handfull of servers. In fact, I spent my first few hours working with it — on battery power! — at my local Starbucks, not something that I could do with most other BPM products that are inching into (or are already in) Gartners’s top-right quadrant.
I don’t intend to make comparisons with other BPM products; I’ve spent a bit of time with lots of products, and a lot of time with a couple of products, and they all have their pros and cons. For example, addressing the mobililty issue, I love the fact that FileNet (which I know very well) makes all their modules web-based so that there’s no explicit installation required at a workstation, you just go anywhere on your network, decide that you want to design, adminster or participate in a process, and you’re good to go as long as you have appropriate security levels. However, if you’re not on the network, you’re pretty unlikely to have the minimum system requirements on your mobile platform to run any of their stuff standalone. I’m not picking on FileNet specifically here, I’m just pointing out that most of the “industrial strength” BPMS don’t let you “snap off” a design/development environment to be used by independents like me that aren’t supported by a big IT department, which means that these vendors have shifted their target designer and developer community to become either people within the customer organization itself, or the large SIs. I’ve posted my thoughts before about how a small organization can provide significantly better quality of work than the big boys for certain types of work, which puts me in mind of this article on McDonald’s versus the Naked Chef, which opens with the line “Mystery: why is it that some of the biggest IT consulting companies in the world do the worst work?” Keep in mind that there was a time in almost every BPMS vendor’s past when they embraced and catered to small SIs and indepedent consultants while still courting the big SIs; I just hope that this is a phase that Fuego will never grow out of.
Anyway, getting back to product stuff, I’m not going to talk much about technical details (in spite of my inner geeky engineering desire to do so) since I think that’s covered sufficiently elsewhere and in Fuego’s white papers; instead, I want to give a perspective on what it’s like to use as a designer. Suffice it to say, however, that it’s a pure Java implementation and should run on any environment that supports JVM 1.4 or higher, but is certified only on several Windows versions and two flavours of Linux. And it supports Firefox (as well as IE and Netscape), which makes me very happy.
There’s a pretty complete tutorial included (as a PDF) that I’m working through as a quick test drive before taking it out on the open road. It’s even funny, in a dark humour sort of way: the first example application is an “idea evaluation” process where employees create processes by submitting an idea, and evaluators participate in the process to check the idea. At the end of the brief process overview, the tutorial states “Just like in the real world, the ideas submitted are never really implemented so after the evaluator checks the idea, the idea just goes to the end of the process.” A bit of a sad business commentary but made me laugh out loud.
More to come when I get a chance to work on it.
TIBCO’s lack of integration
I don’t like to dwell on a vendor’s hardships, but I have to shake my head over an update on the ongoing lawsuits by TIBCO’s shareholders against the company in eWeek‘s current edition. The key issue is apparently that as of the end of last year, TIBCO hadn’t yet integrated Staffware’s “leadership, operations or sales force”, which has resulted in stagnating European sales.
Considering that the former Staffware CTO has gone off and started his own company based on a competitor’s BPM software, I already assumed that there have been a few glitches along the way, but even an EVP at TIBCO admits that the problems are, in part, cultural due to the whole U.S.-U.K. thing. Another case of an organization assuming that the cultures are similar because they all speak the same language?
Davenport article in HBR
If you missed Tom Davenport’s excellent article “The Coming Commoditization of Processes” in last month’s Harvard Business Review, they’ve published an excerpt to entice you to buy the full reprint. Mr. Davenport, as always, has brilliant insights:
“Despite the trend toward outsourcing, however, most companies have remained in do-it-yourself mode for most processes… Because of a paucity of process standards, it would be risky to do otherwise…
However, a new world is coming, and it will lead to dramatic changes in the shape and structure of corporations. A broad set of process standards will soon make it easy to determine whether a business capability can be improved by outsourcing it. Such standards will also make it easier to compare service providers and evaluate the costs versus the benefits of outsourcing. Eventually these costs and benefits will be so visible to buyers that outsourced processes will become a commodity, and prices will fall dramatically. The low costs and low risk of outsourcing will accelerate the flow of jobs offshore, force companies to look differently at their strategies, and change the basis of competition. These changes are already happening in some process domains, and there are many indications that they will spread across virtually all commonly performed processes.”
The full article contains a lot more detail than the excerpt, including using CMM as a great example of a standardized process that has enabled software development outsourcing. Less technical business processes are quickly following.
I’ve been mulling over thoughts about business process outsourcing (BPO) for some time, collecting ideas for an article (or even just a blog post), and this has really started me thinking about outsourcing. One of my recent customers provides BPO services for financial transaction processing (as do several other less-recent customers), so Mr. Davenport’s final words apply directly to them:
If your organization provides process services, you may have mixed feelings about the development of process standards. Standards will lead to commoditization, more competitors, and lower prices for the services you offer. However, the move to process standards makes so much economic sense that it is probably inexorable — whether or not your company gets involved. It’s better to help shape a standard than to be put out of business by it.
BPMI and OMG merge BPM interests
A press release from BPMI and OMG announced recently that they’re merging their BPM standards activities:
The combined activities will continue BPMI’s and OMG’s ground-breaking work and focus on all aspects of Business Process Management, including:
- Refinement and promotion of BPMI’s Business Process Modeling Notation (BPMN) as the basis for business modeling,
- Delivery of BPMI’s Business Process Definition Metamodel (BPDM), Business language, vocabulary, and rules,
- BIM (Business Information Management),
- EAI (Enterprise Application Integration),
- B2B (Business to Business collaboration),
- Web Services Information and Processes,
- Security Policy and Management, and
- Refinement, promotion and education of the principles, approaches and tenets of Business Process Management within the broader business community.
OMG will continue its tradition of innovation by integrating and reusing complementary business integration and web services standards such as WS-BPEL from OASIS, WSDL and XML Schema from W3C.
BPM standards just became one degree less confusing.