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.

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.

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.

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.

If your company has already ventured down this road you probably realize that standardizing processes, especially core business processes is in fact NOT easy. There are many reasons why this is a heck of a lot harder than one may think. Let’s start with the big question first – What do we mean by standardization and what is the real business objective in doing it (i.e. who is asking for it)? I have seen quite a few flavors of this over my career; most recently I spent the better part of a year working with a very large insurance company who wants to standardize their claims process across all of their products and regional markets.

When I asked “why standardize?” I received different answers from lots of different people. “We want to make the claims process cheaper and more efficient,” while another person said “We want to be able to centralize the processing of claims,” and yet another “We want the customer to have the same experience in their claims handling regardless of where they are or who they talk to.”  Are they all saying the same thing in different ways? Are these really the same objective? Perhaps, but I and a few others were not convinced. The implication of this question is huge as this will without a doubt dictate what approach will be needed to achieve the goal. Yes, it’s those details again that quite often nobody really wants to face but without them then the whole exercise is just academic and everyone can just standby for a journey that could take a decade to realize, all the while managing ongoing change as the business climate shifts (i.e. competition, regulations, new markets, etc.).
So what does “standardizing” really mean? If we look at the definition of standard and exclude “a grade of beef below good” as one of them, then we see “a basis for comparison; a reference point against which other things can be evaluated”. So said in more of the context of a business process, it is to achieve a baseline measurement and reference model for process performance. So this has less to do with centralizing a process and much more to do with achieving a consistent performance profile to meet customer and/or business requirements.

So then another big question hits home. Do we really need everyone to perform the tasks in the exact same way? Or can it be that we don’t really care how they do things at a procedural level as long as they consistently meet the needed SLA’s, thus making the measurement the real standard? Maybe think of the latter like a technical standard such as J2EE, as long as a software vendor can deliver the functions required that make it J2EE compliant, it doesn’t matter how they actually implemented it. And as we all know there are very big differences between J2EE products. That becomes yet another big question. At what level of a process, if you think in terms of value-streams, should be considered the standard and what can be tailored in any fashion just as long as it can deliver to the specified requirements?As you can see, this whole notion of process standardization creates some very big questions that any company pursuing this strategy will have to answer, and it is not easy. From experience I can tell you that achieving the benefit of standardization does NOT unequivocally equal everyone at all levels of a process doing things the same way.

In fact, that is usually why this work can get very, very hard. Rationalizing activities from an end-to-end standpoint without knowing quantifiably what the performance standard needs to be is a recipe for some major headaches. So maybe another way of approaching standardization is by backing in to it, such as we need to process x-type claims in 72 hours in all markets we serve. Focusing on it from a measurement standpoint is the best way to understand at what levels of a process and more importantly what are the few key activities at those levels which really need to be rationalized. Versus what I have seen so many times, a blanket objective of everyone who is involved in the process must do things the same way. If you are reading this post, then you have probably been in those meetings where you need everyone to agree on “how the process should work”, now multiply that effect by 100 when you begin talking standardizing across products and geographies.
Ironically, everyone agreeing and doing the same work doesn’t guarantee that the measured result will meet the standard, but that is often the implicit assumption in such endeavors…

Happy 4th of July everyone, and think about our armed forces today. Our deepest thanks go out to all of you.

Fahad Osmani, a colleague and friend over at Lombardi, wrote a good post today on the Lombardi Blog.  I put a comment over there but it is a moderated blog so it may take a while to show up.  The basic premise of the post is right here:

“But now, with a single successful process under your belt – what comes next?

This is where the challenges begin from an overall enterprise perspective. Word of the Pilot spreads. And unless there is a clear plan for scaling to this new demand (and there usually isn’t), this is where it becomes difficult to replicate your initial successes. And as a result, the overall enterprise BPM initiative can stall before it gets off the ground.”

I think Fahad captured the challenge exactly right, and goes on to suggest some good tactics for the implementation team to adopt to prepare themselves as best they can for the onslaught of demand.  All of a sudden pent-up demand for BPM software implementations will be released, and solutions that were previously planned for other technologies will seek to migrate to the BPM platform  for its additional business benefits.  But at BP3 we look at the solution to this problem through a different (complementary) lens:  that is, through the lens of business value rather than solving the technical/staffing hurdles.  So I would focus on the following as key issues:

1. Business Value decisions: How to decide which projects to work on. What is the compass for making this decision? And how do you communicate both the method and the decision to the people with demand? Too many times these “ROI” discussions are not fact-based, but gut-based. But there’s no reason to settle for that…
2. Policy/Governance decisions: Will you allow business units to staff their own projects and leverage the infrastructure already acquired? (or will you allow them to establish their own infrastructure?) Without doubt there will be some projects with sufficient ROI to proceed, but without sufficient skilled staffing to get it done in a given period of time.
3. How will you staff the ongoing projects? centralized team of experts, or decentralized team with some centralized standards and governance?

BP3 is in prime position to help with the first task:  establishing a method for picking projects, and helping you execute and explain the method to your company, users, business sponsors.  This is what some of the early stages of our BPM framework are for, for example.  And it helps to not just give projects a thumbs up or  down, but to explain what the criteria are and why the criteria are important to the business and why the project did or did not meet the criteria.  Sounds like a mouthful, but part of what you want to accomplish is a change in culture or a reinforcement of a culture that focuses on return on investment and fact-based decisioning and accountability.  Communicating the method behind the madness is a big part of that.

The second part is important too.  Governance over whether you allow various business groups to fund their own BPM projects with their own $$ is an interesting call to make.  If you allow it, you can devolve into a balkanized set of processes and priorities, and you run the risk of squeezing the balloon in one group, creating more work for another, and no netting the company a net-improvement in cost.  However, having people spend their OWN money on projects tends to have higher rate of return than when they spend someone else’s money on projects (basic human nature being what it is, people are more selective when it is their own budget).

Staffing is also crucial.  That central team can provide gravitas and competency that might be lacking in a broader roll-out with decentralized staffing.  However, we’ve all worked with companies with a centralized “integration” team (replace the word “integration” with the buzzword of your choice!), which turns out to be a team that is understaffed and oversubscribed to projects.  I’ve never met a DBA group, a SOA group, a doc management group, etc. that seemed to have lots of spare bandwidth.  Inevitably, in the effort to shrink hard-cost commitments, these centralized groups get starved for resources, except in the most exceptional of circumstances.  But the competency issue is important - if disparate teams will have access to the process development environment, there has to be some quality control and center of gravity, and some baseline of skills.  A good compromise is to share infrastructure, have a small team (even as small as one person) responsible for coordinating between development groups, and leverage expert consultants to augment the decentralized internal teams (or staff the decentralized teams).  When those business-sponsored projects wrap up, the consultants can go away and the process moves into maintenance mode.

We’ve updated our service offering. No, we’re not actually doing different things out there in the field, but we’re working toward explaining it better. We’ll continue to explain in a series of blog posts and updates to our content. We previously unveiled parts of our approach in Lance’s post about defining BPM, and in a previous post of mine about working on this framework on our whiteboard at the office.

It starts with the chart below:

The themes (or pillars) of our framework are Visibility, Control, and Performance. Horizontal bands give you the rough timeline, as well as high-level phase or activity description. The right hand columns inform us on the expected benefits and outputs from that phase. At the bottom of the chart, you can see the overall outcomes of the program. For Visibility: Increased Capability. For Control: Increased Repeatability and Reproducibility. And for Performance: A Breakthrough Benefit (rather than incremental).

To take an example… Across all three themes, if you are just getting started, you spend the first 1-2 weeks doing Process Definition. In the Visibility theme this means Value Stream Analysis. In the Control theme it means prioritization and selection. And in the Performance theme it means Process Charter. The benefit is a $ benefit identified and cost-avoidance of taking on projects that don’t have cost-benefit, and the key output is root and contributing cause identification.

Once we figure out which theme we either are focused on or should focus on, and we figure out how far down the pillar we’ve already traveled, we can give you a pretty good idea of what the typical ROI of that next step is, and we can give you a pretty good idea of what the typical ROI of that step is when you don’t execute the previous steps vs. when you do execute those previous steps.

Check out the revised services page here, where you’ll also find links to further detail on each of the three themes above.

Expect to hear more from us on the subject on this space. But by all means, feel free to reach out to us directly for more information. We’d love to hear from you.

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!

I am not going to give yet another definition of BPM. That has been played out like DeLorean gull-wing doors. Everyone has a definition and in most cases they say mostly the same thing, and then the definition is changed and re-cast again:

Wikipedia – “a method of efficiently aligning an organization with the wants and needs of clients”

Gartner – “BPM is a management practice that provides for governance of a business’s process environment toward the goal of improving agility and operational performance. BPM is a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.”

I could cite more references but it’s really not all that interesting, it doesn’t tell you the ‘How’, ‘Why’, ‘When’ or especially the ‘How Much’, and the latter is much more compelling than putting just a label on BPM. This is really why we talk about Visibility, Control, and Performance in order to describe the pillars of BPM and how this all hangs together.

You can think of BPM this way, no matter what the business objectives are, when it comes to process management or improvement it is going to fall into one or more of the three categories. Visibility – we need to understand how our process is truly operating and be able to act on that information. Control – we need to fix our process because it just isn’t getting it done for the customer or the business. Performance – we need to radically improve a process because either it does not exist or, it is too expensive/broken to bring into control. Any business may be looking for one or all of the three tenets but no doubt it will be largely represented by the above framework. These three areas are closely related to one another. It helps to have visibility in what the process is really doing before you set out making changes to make it more stable (predictable) and likewise, if you are looking for truly breakthrough improvements the more stable the process is the better off you will be in terms of any major remediation work.

Now here is the best news of this whole post. You can do things starting out in Visibility that will deliver immediate and strong benefits even before you stabilize the process. You absolutely don’t have to jump-in to getting an extreme makeover before you can reap solid returns. Sometimes those returns can be big enough that there is no need to go much further out of the gate! The trick here is to understand what that process is doing first, that alone can bring relief immediately in terms of customer satisfaction, costs or even revenue for the business. By “lighting-up” the process you can instrument certain areas to behave more pro-actively, thereby minimizing the impact of an unstable process.

BPM definitions continue to change, what we are trying to communicate is just the basic physics of how this works. The business goals for BPM aren’t changing despite the wrangling over precise definitions - you want visibility, you want control, and you want performance. Focus on that, and your business can benefit and we can have fun in our work! This is how we are modeling our services in each of the pillars, as very discreet phases with very real benefits in each one.

Happy to talk more about this if you want to learn more, feel free to shoot me an email, call, or come talk to me at Driven 2008. I’ll be writing more about our framework, consider this the first volley