It’s clear that organizations are recognizing the value of Process Management in their overall strategy. These organizations are researching, investing, and sponsoring projects in growing numbers to understand, model and implement their processes in a BPMS tool. However, I find too often, the momentum stops there. You have analysts and technologists that help install, build and deploy BPM solutions but what then? Who “owns” the process once deployed?

I submit that the business unit should own the process in which they operate; but far too often, the line between an IT-implementation and the execution ownership is so blurred that the BPM solution becomes another asset that IT never lets go of. You see, the growing need for a BPM solution is the realization that to innovate, improve, and accelerate my business, I must understand and manage the processes I have. I need to measure my inputs, resources, and performance in order to make decisions on my capability and offerings. At the center of these points of interest lies my process. How can I accurately pivot my data points if my center pivot point (the process) continues to change without my knowledge? By change I mean, unexpected, un-managed change on the business floor. It’s the work-a-rounds, the “shift to old ways”, the manipulation game many workers and managers play to achieve goals that may frankly be out of date and/or no longer valid. As we embark on process improvement (often necessary for growth), we have to measure current performance and understand the impact of changing the inputs, adding more resources or simply improving performance. This computation is has no foundation if the process we think we’re measuring against is not the actual process in action. Our information is flawed and our decisions compromised.

A well defined process is a valuable piece of intellectual property for the organization and when the business decision makers lose site of that process artifact and don’t refer to it when making business decisions, its value drops and the process suffers as a result. Changes may be communicated and enforced without understanding the impact to their process and solutions in place. Metrics become skewed and don’t reflect actuals when process steps are ignored, changed without reflection, or utilized incorrectly.

BPM tools help solve this problem by not only providing the means to model a business process and communicate effectively, but by deploying the model in a run-time, executable environment such that the model not only becomes a communicative device but a managing, orchestrator of the process flow keeping the model itself front and center in the business. However, when this software solution is not coupled with an adequate Business Process discipline, the BPM solution begins to look like another commodity software package managed by IT. This is a path that the business strategists must seek to avoid.

Process-centric business training such as Lean Six Sigma helps keep business analysts and managers focused on change that positively impacts a business process at the lowest cost. When married with a BPM tool that can visibily reflect those process efforts and implement that solution, the competivie advantage can be down right compelling; but continues only if the process remains the focal point of decision making (one might argue the fulcrum to achieve leverage on your strategic assets). Remeber, it’s not just about the software, it’s also about process responsibility and stewardship, in order to achieve maximum benefit.

Like everyone else, I’m reading a lot of press about the economy, and most of it is negative. But in our little bubble of BPM, things are cooking along pretty well. Sure there are ups and downs but the trend-lines are up.

As if to underscore that, we’re starting to see the 1H2008 press releases from BPMS vendors. Lombardi’s is here (not to mention that it was well-covered by Bruce Silver’s blog, Sandy’s Blog, and the BPM in Action blog) and Savvion just released theirs here (if other vendors posted similar announcements I haven’t seen them yet). We’ve also seen some interesting investment news from Appian (a $10M investment round). Lombardi points to some impressive growth, especially regarding the license bookings (85% growth year over year). All indications are that the number could actually accelerate next year since they have seeded a much larger user base with Blueprint (their SaaS process mapping tool)- users that are likely to have positive impressions of the software and that may translate into more buys for the execution software (Teamworks).

Savvion also points out some nice gains- most profitable quarter yet (operating profit). However, in comparison to the Lombardi release it lacks a lot of detail. We don’t know how much profit grew year over year or by how much it exceeds previous profit numbers. And we don’t know how they’re doing on key metrics that might point the path toward growth (license growth, maintenance revenue renewals, consulting $, etc.). Not that either of these companies are required to disclose numbers, as they’re private firms, but the amount of disclosure from Lombardi is clearly greater so far. That speaks volumes about their confidence vis-a-vis the other pure-play vendors which are not putting out the same level of detail. And it puts pressure on the other guys to start putting up the same details. Hopefully with the Metastorm IPO filing, we’ll start getting at least two sets of more complete numbers to look at for trends.

Regardless of the shakeout in BPMS vendors, we believe the BPM segment is growing - the need for Process-oriented services is growing.  And we’re well-equipped to help customers with process-oriented solutions.  However, as an independent consulting firm, we keep our eyes open for this kind of trending data because we want to be playing good defense - we want to be where the ball is likely to go. That’s where the work will be, and that’s where we’ll make our investments. As a consultancy, we’d like to see all of these vendors grow at the kind of rates Lombardi is growing at, but we don’t have the numbers yet to know if Lombardi is typical, or the standout.  I think we have the most experienced Lombardi BPMS implementation team on the planet right now, but that’s another subject, and another post!

Overview and What’s New

We had a chance to see Lombardi’s latest Blueprint release at Driven last week.  We’ve used Blueprint before in earlier versions, but after revisiting it this time around, there are definite, significant improvements.  I thought we’d share our early experiences with Blueprint here, and specifically our reaction to some of the new features added.  What’s new? Visio import and a good export/import into Teamworks are big pluses. Word export is another new feature, and of course PowerPoint generation has been there from virtually Day 1.  Archiving and a revamped project screen were also introduced.

The New Stuff

Visio importing has long been the “holy grail” for process modeling tools.  If I had a dollar for every time someone asked me if a particular BPM product could import Visio models directly I would be rich!  However, Visio import into a process execution environment isn’t always all its cracked up to be.  Visio diagrams tend to be quite unstructured, whereas BPMN is very structured, and executable BPMN is even more structured in form.  Moreover, Visio models don’t have enough information attached to them to be immediately executable.  It is possible to run into issues of “who owns this model” once you import the Visio (the business may have the expectation that they can keep making modifications and “reimport” into Teamworks, for example).  At some point, the implementors must take over the model and own it to produce something executable.  I’ve been working on some models for OMG certification and I thought they would be a fun (albeit simple) set of examples to import into Blueprint for a test drive.  Blueprint imports these easily and accurately.  I went back to the archives and tried importing some really awful process diagrams circa 2004.  The results weren’t pretty (the original wasn’t pretty), but Blueprint imported the models nicely (a visio diagram with 10 tabs and one process per tab).  Going to the Diagram View I was able to sort out the diagram into swimlanes and go from there.  Interestingly, when I imported a diagram WITH swimlanes defined, Blueprint created those swimlanes and participants for me.

Word export works great, but didn’t work so well on my Mac.  On Windows it produces a professional document that is a good appendix or a good starting point for the doc.  It also eliminates the need to maintain two separate documentation formats - you can use Blueprint as your source and export when you need a Word doc snapshot.  Moreover, you can “snapshot” the process in Blueprint as well, so that if you need to reproduce the Word export later, you can…

The diagramming is much improved, from process mapping to actual BPMN
diagramming.  The new clickable controls are more intuitive (though I had to unlearn some previous notions because I’ve been using Blueprint since the early Betas).  As before, quick double-click on any item takes you to a pretty robust editing interface for adding participants, owners, experts, inputs, outputs, problems, documentation…  Its the Process Diagram (BPMN) view that has really changed over time.  Clicking on any line allows adding a new activity, gateway, subprocess or event.  Blueprint successfully removes the need to obsess over placement of each item in the diagram. It tends to organize things in neat right-angles, taking care of horizontal and vertical placement within a lane (you pick the lane though). 

Project Details Page - This page is so different as to feel like a new page.  You can export powerpoint, word, excel process data, and BPDM all from a simple project page.  From this page you can also move a process to a different project, archive it, or copy it.  The value of these things is more obvious after you import ten processes from Visio!

The Tried and True

The PowerPoint generation is a nice whiz bang feature (only available in the paid-for version).  It lays out the first section nicely: goals, followed by process mapping, followed by opportunities. I’d like to see it turn out a process-diagram view as well, but that may be a little tricky to squeeze into a small space.  The appendix is aptly named for its content, which is a blow-by-blow layout of participants, inputs, outputs, and problems with each step of the process.  I found the color scheme in this section a little jarring compared to the relatively slick look of the rest of the powerpoint.  All-in-all, its a great timesaver.  It ran so fast for me that I thought it hadn’t actually done anything the first time I ran it, ad I can pull together a reasonably professional presentation out of it using the generated slides as a starting point, and putting my own slides referencing ROI or Business Case up front, along with some concluding slides about the opportunities presented and how to tackle them.

BPMN Diagramming.  I actually like the diagramming portion better than
Teamworks!  And collaborating on the same process isn’t just possible,
its actually cool.  You almost look for an excuse to try to be logged
into the same process at the same time so you can try to step on each
other.  Blueprint handles all the conflicting edits really well.  I’m
impressed!  And I understand a good deal of the diagramming techniques
in Blueprint may be adapted for Teamworks in Teamworks 7, which is an
exciting development for Business Process implementors. 

The handling of Revision History is a clear advantage over Visio or any other tool I’ve worked with.  As far as I can tell, every change I make is tracked as a revision, such that I can recover lost work if I accidentally delete something important by restoring from those automated snapshots.  But I can also create my own Snapshot and name it, a point in time to be easily remembered going forward.  This takes the risk out of collaborative authoring, and out of revisions in general, because you don’t have to be worried about version history.  Cycling between versions is simple and fast, so finding the right one isn’t too stressful.

Room for Improvement?

The product has a clean interface and a good look overall.  But there are a few parts I’m not too excited about (yet) that mostly have to do with teeing up projects.  First, when prioritizing problems, you can select severity (low medium high) and frequency (low medium high) but you don’t have the ability to track how observable the problem is.  A problem that is very difficult to detect is much more serious than a problem that is easy to detect, and implies a different type of solution approach.  It might seem too complicated for some, but no reason you can’t ignore the third column by leaving it always at “low” if the notion of detection/observing is too complicated.

Second, the overall analysis screen leaves something to be desired.  It wasn’t immediately obvious to me that the impact scores I was looking at were the impacts of solving one problem across the set of higher level business goals I had established.  Once that was clear, I found myself wondering how these impact scores were derived.  To the layman it doesn’t appear that there is any structural relationship between a timing problem and my goals, but if I give them both high weight then the impact score will be higher against that goal…. So it isn’t immediately clear to me if the idea is to look at this page and then revisit your scores, or if it is really supposed to guide me in determining which parts of the process to look at.  But as long as the correlation is a black box, I don’t trust it.

Third, a process as we know has multiple dimensions to it; it’s not just the activities and relationships. Blueprint would benefit from adding Lean Flow data elements like WIP, Cycle Time, Throughput Time, Takt Time, Lead Time, and Number of Operators to each activity and to the process as a whole and have these values actually calculated, not just string values (perhaps an advanced user view or analysis view). Blueprint would then be much more effective in prioritizing and triaging process improvement, i.e. It would close the loop on the qualitative aspects (Severity, Frequency, and the missing Detection) and now provide quantitative elements as well such as time and volume. Again, this would really address the need to represent the many dimensions of business processes.

But for the primary purpose of capturing process maps and diagrams and capturing living documentation about those processes, Blueprint looks like a great tool.  Its come a long way in one year, and I look forward to seeing what else is coming down the pipeline. The progress so far is encouraging for what is to come.

Last year, OMG made some significant advances in specifications in BPM-related spaces. We now have a BPMN 1.1 spec, a beta of the BPDM (Business Process Definition Metamodel) spec for data representation of BPMN models, and two interesting business-oriented models, the BMM (Business Motivation Model), and the BPMM (Business Process Maturity Model).  We have a mix of both technical and business-oriented specifications for defining business process and improving business process.

OMG is now making public its OMG Expert Certification in BPM program (OCEB), and also published the list of 25 experts who helped put the certification exam together. BP3 Played a role in both the business and the technical aspects of the fundamental exam, and we are now writing questions for the Intermediate exams. This is probably a good time to thank OMG and specifically Jon Siegel for doing such a good job organizing this effort.

BP3 got involved with the OCEB effort (OMG Certified Expert in BPM) first, because BPM is our area of primary interest as professionals. But second, certifications prior to this one tended to be software-vendor-specific, the OCEB offered the opportunity to have a more comprehensive and collaborative examination of what it means to be fundamentally qualified as a BPM professional. We also have an interest in both perspectives of BPM - business and technical - and as a team we bring both types of expertise to the table, which we thought would be a healthy perspective to lend to the working group. In talking with Janelle Hill from Gartner last year she advised that the pool of professionals truly qualified and experienced with BPM is woefully thin, to expect that trend to worsen, and that by 2011 the industry will be in dire straights unless additional professionals come into the fold and earn their stripes. This comment certainly resonated with what we know is the current state of the union. I think OMG is doing a good thing here and I hope we see more practioners enter the fray. It’s good for all of us!

One of our customers has a really interesting set of projects. Each one individually doesn’t have a lot of sizzle to it - just enough ROI to justify doing the project. But collectively, these projects are the backbone of collecting a whole new segment of data about their business. This data could be mined to produce transformational changes in their business processes, or just tactical changes. It is actionable data. That’s pretty exciting. I hope we’ll continue to have an opportunity to work with them and work out ways to take advantage of this data.

But I think the key thing is for a big project like this to succeed, it can’t be too big. The law of large numbers can grind you down, especially on cross-functional, cross-department, cross-technology-competency-center teams. If the project is too large, too much time is spent coordinating and not enough time doing. To address that size/scale problem, we’ve broken the project into separately addressable projects that tie together with the data that we’re capturing. I think the customer is being really wise to break it down like this too.

This is a general principle that can be applied to most process projects - find logical touch points or boundaries where you can interface/integrate with the existing process and define your project accordingly around that bite-size piece. Subsequent projects can build on that first success, and leverage those interfaces. This also helps establish a pattern of successful deployments. Like any team, having a pattern of success tends to keep people motivated and on-task, and makes it more likely that future projects with ROI will be funded.

We’re about to push the first project live with this customer, and it feels good to be almost done, and get this into production to start earning that Return on the Investment for them. And then we get to move on to the next bite-sized piece, which is a really interesting bite, with a well-defined hand-off to existing systems in their enterprise.

So you attended a technology conference one year and heard all about Service Oriented Architecture (SOA), and how your organization needs to devise an implementation plan now. Then the following year, Business Process Management (BPM) is all the buzz. Do I need both? Where do the lines cross? The fact is that these two topics are not mutually exclusive and each can stand on its own merit.

There’s no ‘B’usiness in SOA. Service architecture is much more about how technologists (or your IT department) choose to design, manage, and implement services within the enterprise. Yes, a well defined, well implemented SOA can reap benefits of reduced cost of ownership, rapid development, and stability which of course adds value to the Business; but SOA does not help Business managers understand and improve upon the processes that drive the enterprise. For that, we need BPM.

You see, where SOA is about technology, BPM is about discipline, improvement, and value. Sure, you’ll often find some very sophisticated technology in a BPM implementation, but that’s intended to hide the implementation details and shed light on the discipline of process management and improvement.

In practice, any major (or even minor) business process is going to rely on data and services within your enterprise. BPM allows us to quickly model these integration points and move on with the business of process enlightenment and improvement. As your process begins to come to life, those integration points will either serve as a road block to delivery, or a no-toll bridge to salvation. BPM does not replace SOA, to the contrary, BPM is even more valuable (and necessary) with a well implemented SOA. You can have well implemented services in your enterprise, but with no discipline to apply the use of those services, you’re no better off.

With a disciplined BPM implementation and an SOA delivering well defined and managed integration capabilities, your Enterprise will be full throttle delivering value to your customers and return to your investors.

Not too long ago Jim Rudden posted a fun read at Lombardi’s Blog Site, and Bruce Silver responded with an equally good post here.

I couldn’t resist commenting on Bruce’s post…  I hope he won’t mind since I haven’t been a regular contributor of comments to his (or any other) blogs lately, but I hope to be more involved in the future.  To sum up my three basic points more quickly:

1. Not having a stack is rarely a sales problem for the pure-plays once they are in an evaluation with a customer.  (clearly, it is an advantage for the stackers to have a big customer-list to go calling on and get evaluations started… but once a multi-vendor evaluation is going, not having a stack is just not perceived as a problem by buyers).
2. The whole point of SOA is interoperability.  So having bought a Stacker’s SOA stack just has very little bearing (technically speaking) on whether I buy any of their other products that bolt onto that.  I evaluate each of those products against other products in that space from both other Stackers, and from pureplays.  This isn’t just true for BPM, but also for doc management and J2EE servers and databases and content management…
3. Time-value-of-money still favors the pure-plays.  If you have a process implementation that can save you $1M/quarter, you can’t afford to wait 2 years to get the software you need from your Stack Vendor.  That software will have cost you $8MM (assuming no growth in your business nor worsening of the process in question) before you give one dime to the software vendor.  By all means, buy software that works today and save as much of that $8MM opportunity as you can!

But my favorite part about all of the market analysis is that the big guys will “catch up” to the smaller players in the space.  Short of acquiring the pure plays I just don’t see how that happens.  The Stackers have so much inertia and so many lines of code to maintain, it is really quite hard for them to develop new products.  Let alone new products that appear to infringe on the turf of legacy products :)  History doesn’t show catchup through organic development investment happening that often in large software companies, and they’re running out of good pure plays to acquire!

From my perspective, I wish them all well in expanding the BPM marketplace.  I see a huge potential benefit to customers in having successful BPM roll-outs, and healthy competition can help create good solutions for customers, and for BPM practitioners like myself (ok, I admit to some self-interest here :