We’ve been blogging about BPM and the economy since last fall.  In particular, it started with a talk by Jim Sinur at the OMG BPM ThinkTank 2008. So it seems fitting that another post by Jim got my attention today, and this time it was about the Gartner conference on BPM in London.

It reminds me that Gartner is really getting behind BPM – including publishing their Magic Quadrant for 2009 – and that the message that BPM is a key investment area for most firms (and therefore one of the most recession-proof IT sectors).  I don’t know what Gartner would typically see at a BPM conference in London, but I am guessing it is typically something less than 300 people.  Another conference is coming up in San Diego, and I expect it will be hopping.  Jim Sinur points to the fact that BPM can help your business survive, thrive, and capitalize.  We’re seeing projects that are targeted at each of these objectives – short-term survival, longer-term thriving, or capitalizing on the distraction the economy presents for weaker competitors…

I think the assumption is that conferences will have weaker attendance this year.  But I think if the conferences get the content / agenda right, and press their case with attendees, that they’ll see good attendance.  Getting it right means: focused on value and giving attendees ways to make back the investment they are putting into the conference.  BPM conferences in particular should be doing well this year, relative to the whole, I think.  More to come at the end of March…

A little local (Austin, TX) news today.  AlterPoint (a network management software company based in Austin) got acquired by Versata (an enterprise software company based in Austin) today.  I have had a lot of good friends work for both these companies, and just wanted to say congratulations to the Alterpoint folks for all the hard work over the last several years, hope that the acquisition ends up being a good thing for everyone.  And congratulations as well to Danielle Royston on her new post as CEO of AlterPoint-

News release here.

Monday was a pretty big news day in the world of BPM.  Gartner just released a new version of its BPM Magic Quadrant for 2009.  Its been nearly 2 years since the last Magic Quadrant came out, so the interest and anticipation were a little higher than usual, and no doubt the jockeying was pretty fierce!

One of the complaints oft-voiced is the inclusion/exclusion of various vendors.  Dennis Byron contends that the language for inclusion isn’t really clear:

The companies covered are said to be “the top 22 vendors offering multiregional, cross-industry business process management suites (BPMSs) that interest Gartner clients and nonclients the most. These vendors account for most spending in the BPMS market. See (Gartner’s) Market Share: Application Infrastructure and Middleware Software, Worldwide, 2007.”

I am not sure how to parse the qualifier. Is AuraPortal one of the top 22 vendors as measured by spending-based market share? Spending may be the operative words; turn it around to revenue and I find it hard to believe that Aura is larger than Sun (nee SeeBeyond) in BPM. I also don’t see how Sun would not make the cut based on the capabilities criteria. No content maybe? That’s a little too granular for my taste.

Gartner does explain why it does not include Autonomy, Handysoft, Magic iBolt, NewGen, Vitria and a few others as well as why it dropped a few suppliers previously included in its previous BPM MQ such as Captaris and SunGard.

But I guess I give the analysts a pass on this one, as I’ve been in the BPM space for long enough to know that Gartner is already including *too many* vendors in the space, which legitimizes vendors who really aren’t in contention, rather than too few vendors.  From my time on the vendor side of the fence, most of the vendors on the quadrant were rarely involved in competitive sales cycles with the top couple of pure plays.

There are also some hidden nuggets of irony in the report, such as the note that IBM has a Smarter SOA compaign about how SOA and BPM work better together… this is a message that BPM evangelists have been expounding for years, while IBM and fellow SOA (stack) vendors argued vehemently that SOA didn’t need BPM or that BPM did not, in fact, better inform SOA efforts… (no fault of Gartner here, it is just a single bullet on a list of quick-hits on the various vendors).

I was also pleased to read the assessment that Lombardi customer references “are among the most advanced in BPM maturity. They demonstrate broad adoption of BPM across an organization that yield transformative business results.”  Process maturity is like a tree, whose seeds are planted and nurtured over a long period of time in order to yield a tree that will bear fruit (savings).  Several of us at BP3 were senior members and management of Lombardi’s professional services staff or within deployments of Lombardi’s software, and can rightly feel pride in fostering a culture of BPM adoption at a great number of Lombardi’s customers, as well as within Lombardi itself.  It is always gratifying to read that someone else recognizes the fruits of your labor (even if they don’t know of your efforts!).   Gartner also points out a few Lombardi weaknesses, around smaller deal-sizes and support for case management, and templates and frameworks.  These are weaknesses that can be addressed by working with certain independent professional services firms!

There are notes, of course, on all of the vendors, that are well worth reading.  In particular I thought the assessments of Appian and Intalio (the written part) were fairly spot-on to the feedback I’ve heard from our prospects and customers (both pros and cons).

One other thing I liked:  on the Ability to Execute axis, Gartner (appropriately) reduced the weighting of the “viability” part of the ability to execute evaluation.  I’ve always felt that that part of the quadrant received too much weight, to the benefit of very large software vendors, and to the detriment of perfectly viable, but smaller, independent vendors.  (Viable was generally synonymous with large revenues, and a bit self-reinforcing)

Earlier Appian reported results, and on the heels of the Gartner Magic Quadrant, Lombardi put out its 2008 announcement.  I’m interested to see announcements from the other vendors – luckily, estimates of BPM financial results will be available at www.itinvestmentresearch.com after march 1, 2009 (thanks for the tip from ebizQ).

Overall, it looks like Lombardi grew faster than the software market in general, which is consistent with the results from other BPM vendors (reading between the lines of course, since actual numbers aren’t reported by the firms that are still private).  The good news is that the BPM market overall appears to be relatively healthy.  47% Growth in software licensing is robust, and Lombardi has several other statistics to tout.

Previously I believe Appian announced Q4, which was covered on Sandy’s blog here (forgive me if there is coverage of more specific numbers elsewhere).

I’ve read a couple of articles recently related to business process visualization.  I think this topic is particularly interesting because most people think they have what they need once they buy a BI tool or a good enterprise reporting tool (and there are several that are quite good).

But the thing that makes process visualization so interesting is the context of the process in which the data is generated.  John Reynolds’ Thoughtful Programmer blog has a good post on the topic of Visualization.  In it, he makes a few great points that should resonate with anyone pursuing BPM excellence.  The dream that everyone working in a business will not just understand the activities for which they are responsible, but the role of those activities in the business processes they impact.  It has been shown that feedback loops improve performance by focusing on how individual performance affects overall results.

John also hits on another favorite of mine:  the idea that the same model should support views/layers/aspects that allow different users to understand the model and interact with it ways that are different, but compatible (and enabling).  He also references Phil Gilbert’s dream of BPM on every desk in an enterprise- which makes sense when you think how most processes are executed today – via email/paper/fax – and every single desk in an organization is involved in its business processes… they just don’t have the right tools to support the processes they execute (at least, in many cases!).

So, I think John does a great job of making the case for why visualization matters.  But I think if one hasn’t read his other posts, you might miss some of the context:  that the reason this visibility matters is precisely because of the process context.  It is the lack of context that makes using existing BI and reporting tools challenging.  You can get the data, but does your IT staff know when (in the process) to collect the data? Can the business articulate this need to IT?  Often these decisions are driven as much by convenience as by design because no one has the right answer with respect to the process.

Another issue to discuss with respect to visualization is the lack of standards.  While some vendors use very easily read/used/manipulated data formats for their process information, they are still considered to be “proprietary” formats by customers and the industry (proof that the definition of proprietary continues to evolve.  Once upon a time, just having your data accessible in a published relational database schema was considered being “open” rather than “proprietary”!  Now, if you don’t adhere to some industry standard schema you are closed or proprietary… even if such a schema doesn’t exist yet… )

This brings me to an article on The Business Process Analytics Format (BPAF).  Good read, and a good reminder that there are folks out there trying to put standardized formulations around the Business Process Data that feeds into analytics.  I’m encouraged that the format appears to be consistent/compatible with the tools I’m familiar with, but of course some of the terminology could use a BPMN overhaul (or at least a primer for those who are more familiar with other BPM* standards).

For example, there is a focus on the Business Process Audit Format XML… Which has a defined Business Process Analytics Format Event. In isolation this is a good naming convention, but I think it would help everyone see the relevance if the standard also related this Audit event to where it might occur in a BPMN-defined diagram – is it a standalone event in that diagram, or is it an artifact of other items in the diagrams – and if so, which ones?

Even without this context in terminology, BPAF might turn out to be important.  After all, if you can standardize on what a measurable “event” looks like, then you can actually build analytics that are cross-vendor and consume BPAF compatible events.  Eventually you  could have standard analytic packages… But of course the goal isn’t to have standard packages… the goal is for people who run businesses (and manage processes), to be able to visualize, comprehend, manage, and improve their processes.  That makes visualization central, if not the heart, of what will make BPM relevant to every desktop in the enterprise, even if it is dependent on delivery of executable processes to have full process context in that visualization.

Keith has put out a series of articles (possibly more to come) that lay down a great marker for how to evaluate Modeling strategies and how these approaches compare (strengths and weaknesses of each, across several dimensions).

It started with this post, which set the table for further discussion.

Following that were posts on Analytics, Round-tripping, Performance, and Simulation.

I recommend reading them all if you want a better understanding of some of the BPMN – BPEL debates (without even mentioning those terms), and understanding implicit tradeoffs in a product that the vendor may not (or may not be able to) articulate explicitly.

The interpreted vs. compiled debate has been going on for a long time now.  Keith Swenson brings up a version of it in his Go Flow blog in this post on Model Strategy and Performance.  I think at any given point in time, the compilers have a very good argument because they can find situations where a higher degree of performance is required.  Even in the BPM world, if I can imagine a process that executes 10,000 times an hour, you can just imagine that same process at Wal-mart to picture that process running 10,000,000 times an hour!

However, the right design decisions for software are not judged by a single point in time, these decisions are judged over time… and over time, the interpreters have a lot working in their favor:

1. Over time, the interpreters have time to make their interpretations smarter.  Just-in-time compiling of java is one example… finding better algorithms (in terms of big-O notation) is another approach…
2. Over time, hardware gets faster.  my interpreted code will run some percentage faster each year.  Although compiled code will also increase in speed, the real time-differential on any given problem will get smaller (and eventually, small enough that I won’t care).  Examples of this:  graphical user interfaces, once to slow to even ponder using, now we have all kinds of bells-and-whistles – even though commandline interfaces are still faster!  Java is another example…
3. Over time, hardware gets cheaper, especially if you are looking at per FLOP or per operation.  As a result, even if I have to buy more hardware, in a few years I can buy twice the cpu’s at roughly half the cost… and the CPUs are faster too (or, utilize multiple cores to get faster).
4. Developer time and maintenance time, as costs, usually outweigh the cost of additional hardware expense to provision a system.  When I was in college, a professor demonstrated that the human can still write better (faster) code than a compiler.  He had experts at the university (and named them) write performance-optimal solutions for a matrix fill routine.  The lisp program was the simplest.  But the slowest.  The C routine was 3x faster than the Lisp version.  But then our professor wrote an assembly code solution that was yet 1/3 faster than the C version.  He did the loop-unrolling by hand, for example.  Well, why don’t we just write all our important apps in assembly?  Because it would be incredibly inefficient use of a scarce resource: namely, our software developers (and, in the case of BPM solutions, our business analysts)!

Given those reasons (and others), my general thesis on interpretation vs. compiling is:  first, come up with the best/right representation from the perspective of the authors and consumers of that format (the developers typically, and in the case of BPM, the business analysts, process owners, and process developers).  If performance is a problem, invest in addressing the bottlenecks or areas with the most yield first.  If necessary, figure out how to compile or just-in-time-compile the model for performance.  But doing this performance-enhancement work is a lot easier to do on the “right representation” than it is to try to bake in this kind of performance up front and still end up with the “right representation” for users…

The short story is, transforming your model may yield performance benefits in the short term, but if those benefits come at the cost of a good representation of your process, then over time you’ll lose to those who invested in the right representation and gave other technologies the time to catch them up on the performance front.

Lombardi’s Blog includes links to a couple new Blueprint reviews.  Just thought we’d provide relevant links here:

Lombardi’s post about Forrester’s review here.

And then a post about the BPMInstitute.org’s review of Blueprint here, and the actual review by BPMI.

Finally, Lombardi posted an entry about the February update, which has a few good, minor tweaks while apparently saving the good stuff for an April/May update.

A long-standing debate in the BPM world has centered around whether or not to preserve the model.  It sounds like an esoteric topic, and Keith Swenson’s post: Model Strategy: Preserving vs. Transforming, takes a pretty clinical angle on this debate, and I think lays out the two camps and their respective arguments pretty well.

I like his definition of the common ground components:

• business process enactment: the business process itself has a dynamic component as it moves from the beginning to the end of handling a single case. The process definition does not normally change here, only the process instance or context that records the state of a particular case changes.
• business process lifecycle: these are the changes that a business process goes through from initial concept, to modeling, to integration, and finally to deployment into an enactment environment.
• business process improvement: this is the change to a business process that occurs over time through repeated use of the business process lifecycle followed by analysis of how well that version of the business process worked. This is the TQM or continual improvement aspect of BPM.

The two camps then divide themselves into Model Transformers, and Model Preservers.  The Transformer camp, as Keith argues, has roots in long traditions and proven success in software engineering (and related engineering tasks).  For example, 4G tools, UML, and even VLSI chip design applications are good examples – where the picture translates into code through transformation to a new form.  However, the analogy to these prior tools and content areas isn’t perfect.  For one thing, the author of the “picture” was likely the same person who was the consumer of the picture – the engineer (or developer).  It might not literally be the same person, but the same kind of audience.

Keith gives a good example of how transformation might apply to a Business Process model:

Coming back to a BPM example: the business analyst might put an activity describing a document review in the business view. This would be transformed to: a activity which sends email informing the person; an activity to check the document out of a repository; an activity to send a reminder message if the response is getting late, and an activity to wait for the response to come back. The programmer might extend this to include notation to handle exceptions and other timeouts that the business person did not include. Later this might be transformed again in order to get the executable code.

This is a pretty good example, though in my experience the business usually thinks of things like email, repository checkout, and reminder messages… However, the programmer very well might have exceptions to handle and other technical details that don’t direclty concern the business person creating the original document.  I think the key thing to note here though, is that to the model transformers, it is okay, and even expected, that by the time the technical folks are done adding their fit-and-finish and details to the model, that it will be unrecognizable to the business (Keith has a great image of simple model transformed to complicated model transformed to XML… surely a format the business won’t relish).  There is great discussion in this camp about something that is a hard problem – the “roundtripping” problem.  Because people can model things that are hard to round-trip.  And they can edit the transformed content, which is not guaranteed to have exactly the same freedoms and restrictions as the modeling environment.  So you have what I would call a “lossy” transformation.  It is not the same as compiling to bytecode and executing, because the expectations is that a developer or engineer will EDIT the “bytecode”… Anyone who has decompiled optimized java bytecode has seen that the compiler makes changes, and it no longer looks like the original code.  If you also edited that bytecode, the resemblance to the original would be even more tenuous.

Suffice to say, Round-Tripping is a really-hard-problem for the folks in the Transformation camp.  The best argument I’ve heard from this camp is that you should *not* round-trip, but instead, treat the transformation as a one-way journey.  I think that would be fine, so long as the developer cannot make further changes to the result of the transform. (this is, by the way, what Ismael Ghalimi recommends)

The second camp, the Model Preservers, believe the model is the model is the model.  While developers or engineers can ADD to the model, they must do so in a way that preserves the model.  So, integrations, exceptions, etc. can be layered onto that model, but they are layered in context- and without losing the original context of the model.  The concept of Round-Tripping is trivial – the visual and storage and execution are expected to be 100% in-synch, and any difference would be treated as a defect to be fixed, and all three are designed with BPMN as the starting and ending point…

So why is preserving the model important?  Because if you embark on the transformation approach, the model that the business creates eventually becomes a piece of paper or image on the screen that isn’t truly relevant to what is running in production.  In traditional software development there might be a very important phase where the business validates that the software developed meets “the spec” as represented in a generally large Word document… But this step can be eliminated if you do model preservation – instead, the business is testing whether the BUSINESS captured the process effectively and correctly, and whether the technical bells and whistles adequately support the process, and no longer testing adherence to a 6-month old specification of requirements.

The power of being able to execute the model the business understands is huge.  The power of being able to tie back the analytics to that model (trivially even) is also huge.

However, software vendors in either camp still have to execute well on their designs and software development to get good results… And neither approach is easy.  But then, that’s why we buy the software! (or the support contract)

Scott Francis and his wife Cindy gave birth to a baby boy yesterday! We are all extremely happy to congratulate Scott and his family and ask a key question, ” Can Holland code yet?”

Welcome to the world!

I ran across this blog entry titled BPMN for People and Robots by Anatoly Belychook thanks to Sandy Kemsley, and it (and the commenting below it) is a great read on how different tools that “implement BPMN” can very quite widely in how well they are suited to a common understanding by business and IT.  Anatoly takes a very simple process and demonstrates how several different tools represent that process.

I think the most telling argument Anatoly makes, and one with which I firmly agree, is:

From my point of view, the possibility for IT and business to talk the same language is not a feature but the classifying attribute of BPMS; if this “magic” is absent then other features don’t count.

And I think this is the unifying principle for those who believe BPMN is, to this point, the best “language” for achieving this.  However, the products that support both modeling and execution need to provide good fidelity between the BPMN model and the execution of the model in order for this to work well.

Lance’s article on “Witnessing Process Failure in Action” is edited and posted on ebizQ today.  Check it out – and the whole series (scroll down to get to the featured articles), which is primarily guest-authored and pretty consistently high quality.

If you follow Dennis Byron’s BPM in Action blog (one of the ones I track in my RSS reader), you might have noticed a series of posts about Stack Vendors vs. Pure Plays here about the enduring debate, here about whether stack vendors stifle innovation, and here with regard to pricing.

One thing that may not have been clear in my comments (and comments on Dennis’ blog are moderated), is that we don’t view stack vendors as bad and pure plays as good – there are simply trade-offs between the two.  Stack vendors have some clear benefits:

• Financial heft – typically they have deeper pockets than the pureplays
• An integrated solution – if the stack vendor invests appropriately, they’ll integrate the set of technologies they acquire into a better-integrated overall solution.  The result is that customers don’t have to pay for that integration as a one-off, they can benefit from integration costs amortized over hundreds of customers.
• Large consulting staff – this can be considered an advantage if you want the software vendor to implement your solution.
• The ability to (try to) change the debate at any particular competitive situation to be one that focuses on the areas that are their strengths, and minimize the time spent on their relative weaknesses vis-a-vis the competition.

But of course, the real point I was making from the beginning is that the benefit of a pure-play vendor is their focus.  Because they’re focused on just one space, they aren’t likely to get distracted by all the noise in other market segments.  The thought leadership of your company is focused on one thing, rather than 10.

As an additional point, I pointed out that if a vendor is giving a piece of software away, you should be suspicious- anything a vendor is giving away for free (or nearly so) isn’t likely to get a lot of investment of R&D dollars going forward.  Software companies tend to invest where they see a competitive edge, and they tend to discount and under-invest where they don’t.  It isn’t irrational behavior, and it isn’t a question of good/bad or good/evil – its just the trade-off of stack versus pure play.

So the cons of the stack vendor:

• Lack of focus and thought leadership in the market segment
• Underinvestment in some segments of their product offering – and it isn’t always easy to tell which parts are being starved for resources.
• Often innovation and enhancements take a backseat to platform consolidation in the first 12-24 months after acquisition.
• The large consulting staff can create conflicts of interest with respect to their software development (e.g. does it make sense to invest in a software enhancement that reduces the number of consulting hours it takes to deploy, if you derive significant revenue and profits from that consulting?)

So the prospective customer simply has to weigh these tradeoffs, or use them to inform some of the inspection and evaluation they do when selecting their vendors.  Obviously I’m generalizing and no doubt there are examples of “stack” vendors that innovate, or pure plays that don’t!  And likewise for each of the generalizations I made.  However, the generalizations are based on observations from three sides of the vendor/buyer/consultant point of view.

Your mileage may vary!  The reader can decide whether these generalizations accurately characterize the BPM market at this point…  I’m still looking for evidence to disprove the hypothesis in the BPM market, but so far I don’t have it.

Another flurry of updates in the BPMN vs. BPEL discussion: Bruce fires a shot across the bow here, and then Keith Swenson makes a response in his own blog, but there is also a pretty good discussion below Bruce’s post in the comment section.

I think it is either a sign of progress or weariness that the debate has gotten a bit more reasonable, in that no one is arguing BPEL over BPMN or BPMN over BPEL, there is simply a discussion of how to allow the two to live harmoniously.

Bruce makes key points I agree with:  we can’t make the success of “BPM” dependent on agreement on definitions – its very hard to get a consensus on the definition for something as vaguely termed as “Business Process Management.”  Moreover, there is no reason to believe that different organizations can’t make these decisions DIFFERENTLY based on their own unique culture, personnel, skills, etc.  In one organization, the business may have members that are technical enough to model valid BPMN diagrams.  In another organization, those skills may go wanting, and the modeling will get done by IT.  In yet another, outsourcing the modeling and developing those models in JAD/RAD sessions may be the right approach.  Does anyone really expect something as broad as BPM to be a one-size-fits-all methodology?

Keith raises the point that BPEL isn’t enough to represent all the interesting process use-cases, and he’s right.  It doesn’t mean that BPMN and BPEL can’t play nice together, but it does mean that a “native” BPMN xml representation, independent of BPEL, makes sense.

Finally, Bruce raises the concern that this portability of models, and fidelity between diagram and XML representation, would likely be a good thing for any BPEL vendor, but the existing BPMN-native vendors might not get on board.  I think if the BPMN-native (my term for BPMS vendors who diagram BPMN processes and then execute those without losing fidelity, without translating into some other representation that doesn’t match 1:1 with BPMN) vendors won’t play ball with this portability, then it begs for an opensource project to help provide the import/export.  You’ll have one common storage (BPMN 2.0 presumably), and you’ll have a set of vendors with (potentially) proprietary storage.  That cries out for individuals to create the import/export mechanisms from each of these formats (based on which ones they know) as part of an open source project, if the vendors won’t do it on their own.

I’m still not sure it commoditizes the runtime however.  It commodotizes the storage definition… but one still has to write the code that will execute these models, and there will be room to compete on several fronts (performance, resource utilization, correctness, platform support, architectural compatibility, etc).  And hopefully the competition will move toward value-added features on top of these models and run-times… Because there is so much more to BPM in our future than just running these diagrams – and yet some of those future states may be hard to get to if we can’t make the basic blocking and tackling easier.

Lombardi has put up the Driven 2009 site, and announced the dates:  April 20-23, 2009.  If you’re a Lombardi customer and you haven’t attended Driven previously, I think it is well worth the trip, as most previous attendees will tell you. The format has been updated to include a few pre-conference workshops the day before the conference gets into full-swing, and to include an extra half-day at the end to accommodate the user group meeting. This year it is downtown so the experience will be a bit different than the hill-country location of 2008 (and surely the weather will be better in April!).

BP3 will be attending Driven as a partner, and we look forward to seeing you there – more details to come!

Sandy has a new post about Gartner’s latest webinar on emergency cost cutting in IT.  The webinar is over but likely they’ll probably allow replay of the webinar soon with registration on their site (if they haven’t already).

I think Sandy does a fantastic job of summarizing the call however, along with some excellent color commentary.

If I can sum up Sandy’s cautionary notes:

1. Be careful that your cost-cutting doesn’t cost you your long-term organizational learning and viability.  Some of the recommendations from Gartner will help you survive this year, but leave you wounded heading into the recovery.  If you’re company is strong enough, be prudent about what you cut and retain your ability to fight when the economy turns.
2. Be careful about abandoning SLA’s to the business -they’re your customer and if you aren’t living up to their expectations they may decide they can get bad service at a lower price… (Most people will believe that good service costs more… but if the service is already bad, they won’t see as much downside in trying something cheaper).

I’d add a couple of my own:

1. Make sure the projects you DO take on can be tied to ROI – real cost cuts in IT, or real business benefits that the business is signing up for (usually operational savings).
2. Make sure you bite off manageable projects – projects you can complete this year start earning a return for the business this year.  Simplify the big projects, figure out how to get 20% of the benefit this year, rather than getting 100% of it in 18 months.  Then get the next 20%, etc.  (Some call this, continuous process improvement or iterative development… I call it putting money on the table).
3. Eliminate non-essential positions if you can,
4. Do not create additional bureaucracy for your employees, for example, to get reimbursed for legitimate business expenses.  This is only going to hurt your productivity as a company – but it is a very much hidden cost.  It won’t show up as a bottom-line cost, it will show up overall as less revenue per head though… Instead, a better strategy would be to be more clear about what is reimbursable, and to take longer to reimburse (say, 30 days instead of 15).
5. Don’t stop going to conferences and consulting with experts.  These may provide just the ideas you need to save your project, team, organization, company.  In this kind of environment we need our creative energy fed.
6. Figure out how to help the business with the real problems they are faced with.  They’re your customer, figure out how to do more of what they really care about, and less of what they don’t.

Not precisely a BPM reference, but on the Aris BPM Blog, Martin Kling posted an interesting article on Risk Management.  It points out the over-reliance on a poorly understood method can really hurt your business – in this case the reliance was on VaR (Value at Risk) – which was even used to make incentive decisions for traders.  As Martin points out, this incentivized traders to take positions that had a high likelihood of small gains or losses, but potentially a very small likelihood of huge losses (or gains).  The small probability portion is ignored by VaR – which focuses on the 99% cases, not on the 1% cases…

There’s also a link to the NYT article that goes into full depth.  Both Martin’s blog and the NYT article are great reads.

The tie-in to BPM?  Visibility matters… If your business is relying on processes that are “black boxes” to perform well… it may be surprised when a “Black Swan” event occurs (one of those 1% events), and how much damage it can do to your business.  Usually people associate “black box” with a computer program – but in this case, a completely people-driven manual process is a black box – the time delay for measurement and information to reach executives, combined with the lack of quality data, yields bad inputs to executive decision processes.

BPM and other technologies can help in a few respects:

1. Document the process in a non-ambiguous, but human-readable way (BPMN being the chief technology for that).  This removes a bit of the black box element of process all by itself.
2. Measure the process – not just the run-times of various components, but the snapshots of inputs and outputs.
3. The measurement of process allows for better analysis – correlation analysis in particular – to find out what inputs drive better business.

At any rate, technological solutions should be viewed as tools to aide decision-making by participants in the process, process owners, and executives.  When management starts to view the technology *as* the solution instead of an aide to capable human thought and judgment, additional risk is foisted upon the business, because software can not by nature be designed to react well to Black Swan events.  But when used as a tool, software can provide the information that let’s humans sniff out the problems as they occur.

(Note: in the article, it is suggested that Goldman Sachs did just that – they’re models weren’t producing what they expected by a small margin of error – so they got human risk experts together to do further analysis – which led them to reduce and hedge their positions.  This is a classic case of human judgment triumphing over reliance on the model – the model was not yet showing a real problem, but it was showing enough variance for a human being to worry about it.  )