We are pleased to announce the availability of Lean Six Sigma/BPM training for IT organizations and professionals! In today’s Information Technology environment the need to build, manage, and sustain companies’ information assets is of critical importance; as is the notion of “doing more with less.” This class is designed to provide as much practical understanding of how to incorporate Lean Six Sigma tools and methods to increase the capability of any Information Technology organization. From governance frameworks such as ITIL to software development using Lean and Agile techniques. Lean Six Sigma is a very powerful model that will provide a tremendous value to IT.

This class is in partnership with SixSigma.us, the nations premier training and education company for Six Sigma certification. Their customers include Kaiser-Permanente, Pepsi, AOL, Nokia, BankOne, Motorola, GE, Johnson & Johnson, and many others.

This is a 4 day class that will provide practical hands-on experience in integrating Lean Six Sigma and BPM with IT. Most if not all other Six Sigma for IT training that is on the market is only a day or two long and incredibly high level. We are bringing a true practioner’s course to market and one that doesn’t necessitate that the student already be Lean Six Sigma knowledgeable.

The agenda looks like this:

As you can see from these modules, this course aims to provide not only the education content but also various activities where you will put this knowledge to use and be able to go home to immediately begin receiving value from the week spent in the training.

You can get more information and register for the class here.

First class is in Dallas, Texas, Dec 8-12th. Hope to see you there!

The case for modeling without thought of execution…

I recently came across a blog entry from IDS Scheer on their Aris BPM Blog. Thanks to Sandy Kemsley for pointing me to it from her blog. Upon first read of the article by Sebastian Stein, I was struck by the difference in perspective between those who implement processes and those who model them.

For those who model (Modelers), the Model is the chief output and goal. Having a Model that will survive the test of time is the goal. You can see that bias throughout the post. In fact, the core philosophy is embodied right here:

“A business process model, depicted in one of the popular notations like BPMN or EPC, should not contain any technical details. If the underlying IT infrastructure or implementation technology changes, the business process model should remain stable. Your warning bells should ring if you have to change your business process just because you changed the implementation technology used.”

The two key points:

1. No technical details
2. stable with respect to technology changes

Something Overlooked by a Model-only Perspective…

But there are some problems with this… First, all the BPMN/BPMS tools that I have worked with support layering of processes. This layering allows the user to create a model that reflects Business sensibilities at the top layer, and if needed, several layers down in detail. So, if your need is to model something without “any technical details” you are not prevented from doing so in the BPMN-oriented tools that I’ve used.

Second, when you get to a certain level of detail, the process design should be informed by Technology. How so? It is important to understand if a transition is a manual or an automated one. Is it a non-value-added manual step? Then generally we want to automate it, or ideally remove it. Value-added manual step? Then generally we want to optimize around its constraints, but automation won’t be the goal. However, we may want to use technology to reduce errors, to improve time-to-execute, etc. In the posting, Sebastian doesn’t go into detail as to what he considers a “technical detail”, but it does beg the question: what is too technical? How about input and output data from a step in the process? These are critical process design considerations (if you know that a piece of data is required as an input, but you’re not sure where it comes from, you have a problem to resolve in your process design. And those inputs and outputs help define the “contract” of an activity or subprocess (or even of the entire process).

Third, Modeling tools today make it exceedingly easy to change a Model to adapt to Process changes. While it seems like a good idea to have a Model that is “stable” with respect to technology changes - the fact is, business processes change faster and more often than the technologies and systems that support them. The real problem isn’t keeping the Process consistent across technology changes - the problem is that the underlying technology may not be flexible enough to adapt to the new process model! At the least, the technology layer is often not agile enough to do so at a sufficiently affordable price and on a sufficiently short timeline (unless of course, that process technology layer is a good BPMS).

Fourth, the resilience that one needs, truly, is with respect to performance data. Performance data analysis is what will drive my process improvement activities, or identifying a process operating outside control limits. I need to be able to compare the performance of my process now to the performance of my process next year, to the performance of the process last year… If my process changes dramatically, how do I do that? Note: I’m not saying the technology changed. The process changed. So what I need is a way to track data that will make sense even in the face of relatively substantial changes in my process. BPMS tools can provide this facility, either baked in or via smart modeling practices, by taking snapshots of data at key milestones in the process that are not likely to change, semantically, even while the syntax (specific steps) of the process may change. To this end, even though the order entry portion of the process may change dramatically, you can still track information around the # of orders in, the value of those orders, the time it takes to process them, etc. even though the order entry process may go from highly manual to highly automated to web-self-service (or may yet encompass all three).

How do we Sum it up?

So the argument is that a modeling-only tool buys you a benefit (stability against technical change) that you don’t need, while not providing a benefit (technical agility with respect to business process changes) that you do need… yet still doesn’t address the key stability need -that of the measured process performance data. Moreover, the integration from most modeling tools to an actual functioning BPMS is, for the most part, non-existent from a practical perspective. Even when that integration exists, it is usually lacking process execution sensibilities in the model. There is a difference between drawing a model that represents the business needs and drawing one that can NOT be executed because of ambiguities and inconsistencies. For the best integrations I’ve seen so far, the products and the integration are all written by one vendor. (I’m definitely interested in seeing examples of this kind of tooling and integration and I’d be happy to write up reviews for such)

I’ve actually written an import to a BPMS suite using an Aris model as a starting point - and its hard!  There is a ton of non-relevant data in the export - positioning information, for example - and other information you need is difficult to lay hands on (roles/ownership).  To be fair, this wasn’t a BPMN diagram in Aris, but it WAS a diagram of a process, in a very unstructured environment.  It wasn’t any easier than parsing it out of Visio vdx files.  My recommendation, is that if you are given a process modeled in a modeling only tool - your first instinct should be to redraw that process in your execution modeling environment rather than try to import it (unless the importer ships with your product, in which case, give it a try!).  You’ll be surprised how fast you can recreate the model in your execution environment.

Now what?  Does an Execution-Oriented Model still make sense?

Okay. Given the arguments Sebastian presents, it seems he is suggesting that if you don’t know what product you will use to implement, you should use Aris to model your process (in fairness, if you don’t know what execution environment you will use, paper, visio, and Aris are all good options). And that, because it is “agnostic” with respect to the implementation tool you use, there is some derived benefit (this is really the point I disagree with). However, if you are going to build your solution in a completely different toolset, and you accept my premise that exports out of Aris (and other modeling tools) into execution BPMS suites leave a great deal to be desired, then you come to an interesting crossroads. Is he suggesting that once given an Aris model we should just write BPEL xml or some Java code to implement the process? or that we should then use a BPMN-oriented modeling suite to re-model and then implement the process?

In our experience, just “writing code” to codify a process in a modeling tool is a mistake. For one, how can the business determine if you have faithfully reproduced the process in your code? Extensive usability / UAT testing might reveal an answer, but it is a very expensive way to find out, and it only happens after all the code is written - and any mistakes will be very expensive to fix at this point because they could be simple mistakes or they could be conception or foundational mistakes. An Agile development process can help, but many organizations have trouble carrying off this approach with traditional software tools. If the technical team uses a BPMN execution environment (a BPMS) to build that process, then the business will be able to see the process in BPMN, a language (drawing) that they can understand, and understand the semantics thereof. By visually inspecting the design, the business can eliminate the greatest proportion of future defects at the earliest part of the design phase. And the technical team will implement each portion of the process in context of the business process at that point. And that is critical for providing useful business context to the technical team at the time they most need it.

Which Model is the Master?

And finally, now that your Process is implemented in an execution-oriented BPMS, as well as modeled in your modeling-only environment… which Model is the “Master”? Of course, you can make either answer work.  But let’s be clear about the choice you make :

Option 1:  The Model as drawn by the business in the modeling tool is the master.  it does NOT reflect what is actually happening in the business, or within IT, but it does show what the business was hoping the process would look like when the project started.  (Optionally, it may have even been revised and updated at the end to reflect some of the changes that implementation and testing revealed needed to be made).

Option 2:  The Model that works as agreed to by IT and the Business, drawn and executed in the BPMS environment.  This is the model that was actually tested by business users in UAT, by Unit Testing in IT, and system testing in IT.  This is the model that is actually running your business process in production, and it reflects reality.

Is it important that your original Model is resilient to technology change in this context?  Is it relevant that your model doesn’t have any technical details in it?

Or does it seem to be more interesting that there is now a BPMN model that represents what actually runs in your business every day, that can be measured and analyzed over time.  Does it matter that this BPMS is resilient to back-end technology changes (activities provide abstraction to what type of integration, and each integration can provide abstraction as to what specific systems are being tapped)?  Does it matter that this BPMS can support relatively rapid changes in process to adapt to your real business?  Does it matter that you can map the data you are tracking to your Model, to generate heat maps and highlight problem areas?

Well, you can guess where our heads are at.  Modeling is important, but Execution makes it relevant to the bottom line, and makes the Model itself more valuable.  If you want help turning your models into reality, we can help.

Looks like Appian has started up a new blog. Only two posts so far here, but hopefully we’ll get some better insights into their product strategy and direction going forward.

If it carries forward with interesting posts we’ll add it to our blog roll.

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.

A friend and colleague at Lombardi, Kalvin Stollznow wrote a post at Lombardi’s blog on Monday articulating the need to view the business and associated wastes and defects through the lens of a “process prism”. I certainly agree with Kalvin on this point. Especially where it concerns the insurance business, for at BP3 we have had a lot of experience in this area.

Kalvin discussed the power of Lean Six Sigma as a method to deal with the very thing that causes great angst in companies and that is the waste (aka Muda) and defects mentioned above. He moves on to bring light to the fact that these particular approaches may have been born from the world of manufacturing but absolutely are applicable and more importantly effective in transactional or service based businesses. This is a fact, and expanded or integrated into a company who views business process management as a true discipline then you have a truly remarkable organization who can retain and grow customers as if they were born to do it.  However, it does require “translating” some of the standard Lean Six examples out of the manufacturing world and understanding their analogs in the transactional and services world.

I will take what Kalvin was alluding to in his post and give an example from a financial services perspective of the things we do everyday that create waste and defects in our processes - and the key here is to be able to identify these things so that they can be managed. Let’s do this from ”The 7 Deadly Wastes” from Lean Six Sigma to examine this closer, in no particular order (although ‘Overproduction’ is considered the worst waste in Lean). I will go ahead and make it 8 and add rework as I believe it is very insidious but not officially declared in the initial 7 wastes-

1. Rework: Anytime you see a loop in a process, that is probably rework. Think of touching the same thing over and over again. For example, an invoice is sent to a member or group customer and the bill is wrong. Requests are made to change coverages, drop dependents, etc. The clock starts ticking for that request to be fulfilled. If the request cannot be fulfilled in time, the next bill will generate and it will be wrong again. rinse. repeat.  Customer satisfaction declines, and administrative costs go up.

2. Defects: An enrollment form with missing information or incorrect information; a bad requirement for that new claims handling system; a bad or “dirty” invoice from the rework example above, forms or applications with unclear instructions or usability. Defects are pretty easy to understand although I have heard businesses tell me “we don’t have defects, we have exceptions”. Whatever you want to call it is ok by me, but exceptions and defects both cost the business money.

3. Inventory: A backlog of policy change requests, a queue of contracts, or claims unprocessed, callers on hold, piles of forms and the like. Financial Services companies have a ton of “inventory”, just not in the way people normally think of it.  But it can have the same negative effects: clogging a process and creating or exposing bottlenecks in a hurry.

4. Waiting: Waiting for an approval on a claim, an expense reimbursement, an underwriting decision, 1/24 hour batching of data. Waiting promotes the clogging of processes, can create defects and cause rework.  When expensive specialists are waiting for a response or for work to hit their queue, the company is letting money walk out the door.

5. Processing: Or Overprocessing more specifically, such as an inordinate amount of approval steps to pay a claim or making sure a document is imaged and re-imaged over and over again. Basically doing more work than is absolutely necessary to delight the customer.

6. Motion: Constantly switching between screens and applications to get the policy change made, having to go out and find an archived image/document in the DMS or on a network share, keystrokes and clumsy navigation of systems. Running over to the printer constantly to get those TPS reports (couldn’t resist the last example, Office Space fans).

7. Transportation: Similar to rework and examples could be having to get physical signatures from across the campus, delivering and picking up paperwork from all over the place, delivering reports, etc.

8. Overproduction: Lean considers this the worst waste because it can often be the root cause of many other wastes listed and if you think about it we see this all the time. 100 reports when really 3-5 would do the trick, constant emailing, a requirements specification 300+ pages deep for a small to medium software project, print-outs of everything going to everyone, flooding queues with tasks just spit out from that batch processing which in turn causes the backlog to grow or at a minimum not shrink.

It all comes down to delivering goods and services to customers how they want it, when they want it, and at a price they want to pay. If any company, not just financial services, are not managing their business via a process view then it will be those companies who will not keep customers. Applying Lean Six can identify the causes of waste and defects, and then can help remedy the waste/defects with prescriptive solutions (perhaps more on the prescriptive side in a future post!). This comes down to pure physics and physics cannot be wished away. Manage the processes or they will manage you as the saying goes.

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!

Lance and I are going to be at OMG ThinkTank in October (October 6-7, 2008), and then again at OMG Think Tank in Europe (November 11-12, 2008).  Lance is hosting a Round Table on Managing Complexity, and I’ll be hosting a Round Table on how process execution is being impacted by ERP/SOA/Web2.0. This year Think Tank is going to have much more of a business focus around BPM, which is welcomed news! Not that the technical side hasn’t been very well represented — and with great content.  Nearly all of the BPM events hosted each year have technology as the center of gravity. Looking forward to seeing how this goes over. The round table sessions are without a doubt the best part of Think Tank. A round table is where you usually have about 6-10 true industry experts and/or very active BPM practioners from mainstream companies sit around a table and provide their experiences based on the topic of the RT.

Last year at the conclusion of the event, everyone agreed Think Tank should expand this vehicle as it was chock full of some great insights and collaboration. Most of the time the topic left the table and was picked up at breaks and after session get-togethers to continue the discussion. The purpose of the leader of the RT is to bring some very good knowledge and experience on the topic, but to primarily facilitate discussion; it is not a platform to monologue the content.

If you have the chance I would highly recommend considering going to Think Tank this year in either Chicago or Amsterdam. You can check out the previous year’s event here.

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.

I will be working with a partner colleague to lead a workshop, as part of Gartner’s Workshop Series, this year in Washington DC. I didn’t get a chance to make last year’s session but heard anecdotally it was well represented. This year Dr. John Alden from Capability Measurement and I will be delivering a workshop on BPM Measurement: Principles and Practices. This workshop is all about starting or improving measurement in companies BPM initiatives. Something I can tell you is woefully lacking and as a result companies may not be getting all of the “bang for the buck” they really should on these projects and programs. The synopsis is as follows:

Participants will learn how to start or to improve existing measurement activities in a BPM initiative. The workshop will be divided into two parts:
1) a “measurement principles” presentation
2) a facilitated “practice oriented case study” discussion
In the first section, the content will cover:
- Current landscape for BPM measurement - trends and issues
- Measurement and its link to strategy
- Practical frameworks for guiding measurement programs and their lifecycle(s)
- How the maturity of business processes affects BPM measurement capability and analytics
- Where to start if you are new? How to improve if you are already involved?

In the second section, the participants will engage in group discussion designed to provide for tangible outcomes, e.g. something useful to take back home. Participants will evaluate their own preparedness for BPM measurement and develop a measurement roadmap tailored to the maturity of their business processes.

You can learn more about the Summit and Register here at Gartner BPM Summit

Hope to see you there!

An interesting question was raised at the recent Lombardi Driven 2008 Conference.

The question was (and I paraphrase):

I am new to Teamworks, but I have a number of content management, asset management, approval and other systems that all have workflow features. How do I know which workflow tool to use and where does BPM fit in the whole picture?

I got to thinking about this question, and the simple fact is.
Pretty much any enterprise class application suite that manages any business assets, will include some form of task routing or workflow feature. They must have in order to define and enforce the business rules for the assets in question.

So, it’s pretty easy to understand how someone new to BPM has a hard time determining what is special about BPMN diagrams and BPM in general. Especially if you are being introduced to BPM from the perspective of the vendor tool.

So, what is the answer?

In my opinion, the appropriate tool really depends on the domain of influence for the application.

Let’s take a portion of a simple on-boarding (everyone loves on-boarding) process.

In the above process there are at least three systems that would likely have a workflow engine as part of their feature set:

• Document Management System.
• Identity Management System.
• Badge/Access Control System.

Likely, it would be possible to build out approval, escalation and task assignment for the entire process in any one of the above tools. It may not be pretty, or efficient, but quite possible.

So, let’s ask the question again.
What is the appropriate tool, and where does BPM fit?

I think it is obvious the management of offer/acceptance letter and employment contract should be handled using the workflow of the document management tool. This is what it is designed to do, the tool has direct access to the document repository and the rules governing the handling of the documents are likely to already exist within the system.
Accordingly, badge access and system accounts (email, login, salesforce.com etc) should be created in the badge access and identity management systems for the same reasons.

But the marshaling of these process steps, this is the role of a BPM engine.

In the process above, we don’t want to start the badge or user account process until the acceptance letter is received. Equally, we want to be able to place CSF and KPI measurements against each of these process steps.

• All activities are necessary to successfully complete the on-board process.
• All activities could likely be optimized
• All are in the critical path.

This is the purpose of BPM, to provide end to end visibility, integration and control of a complete process, not just the pieces that make up a process.

Like I said, this is my own opinion, but I was happy to hear that this was the consensus from the other experts in the room at Driven as well.