Interesting reading about Social Tools within Intuit on the Dachis Group’s site, as they discuss engaging with social tools in their business and the new processes they have to embrace.  Christine Morrison responds to questions from Dachis Group, and I’ve quoted the exchange that caught my attention:

Getting diverse constituents to agree on process changes, or new processes can be difficult. Any tips you can share on bringing people together?

The answer is, it depends.

If the goal is to just make a new, first-ever process that’s never been attempted before in your organization happen (and it doesn’t have to be large-scale right off the bat), I recommend a skunkworks operation: prove your case in a limited, low risk way, and use that data to drive adoption across the organization. The overhead in this scenario is a lot easier to achieve: you usually just need one well-placed promoter who is willing to take a risk on a new way of doing things. Some of TurboTax’s most long-term, strategically important social initiatives were launched this way (Live Community and Inner Circle, for example). [...]

Call me a BPM geek but I like seeing people outside of the BPM world thinking about process, and in this case realizing that social tools don’t get you out of having to think about process – but they do have implications for change in your processes as they exist today, if you’re open-minded enough to allow for it.

Every so often, someone makes the argument that essentially nothing has changed in the world of BPM.  Actually, this isn’t unique to BPM – it is a common refrain across all kinds of software categories.

And it is tempting to buy into this, when you realize how durable a writeup like the history of BPM can be (this isn’t a bad writeup, by the way). But one has to remember that history *should* be a bit durable with the passage of time. Jon Pyke recently opined that no one in BPM has anything new to offer.  But the substance of his post is that the marketing isn’t differentiated, and the product positioning isn’t differentiated, and further, that the people who work at these companies don’t know what differentiates them.

Having worked on both sides of the coin (on the software side and the consulting side), I have to disagree with some of Jon’s conclusions because the input data is more limited than he’s realized.

For example:  of course the marketing messages are commoditized among BPM vendors, as is product positioning.  Sadly, it is perfectly easy to copy someone else’s marketing and positioning – it takes minutes, hours, or days at most to do so.  I think the tragedy in BPM is that all the vendors seem willing to implement “checkbox” versions of every feature that analysts care about, rather than go deep with the product in areas that produce real value for customers.  Unfortunately, vendors have been largely rewarded for such behavior with good product comparison reviews and chart placement – but their customers have not been similarly rewarded by this kind of investment.

There are real differences in these products, but it requires a much more in-depth understanding of the products to appreciate it.  Can we be surprised that customers have a hard time achieving this level of product knowledge during the evaluation process?  I used to work with someone who was always telling me how “nothing had changed” in the last 5 years in BPM – at a time when, 5 years before, there was no BPMN – and at that time, BPMN was the de facto modeling standard for BPMS offerings.

There has been quite a bit of innovation in the last 10 years in BPM, but some of the best ideas didn’t get enough investment to go from interesting to indispensable, and some of the best ideas really were commoditized – picked up by all the pure play vendors (and later, but the stack vendors).  I could argue that nothing much has changed since 1994, when I wrote a sales process application that leveraged Lotus Notes VIP to replicate sales data and manage workflow between Sales, Sales Engineering, Manufacturing, and R&D.  But that would be a bit disingenuous. I could write that solution in 1994, but I didn’t have a way to communicate the process to the business (BPMN), that accurately reflected the implementation so we could make sure we had it right.  And I didn’t have a standard data representation for analyzing the process data (for business process improvement).  I certainly couldn’t handle in a trivial way a process that required parallelism the way I can with executable BPMN models.

Jon says:

That’s why, and I’ve said this many times before, BPM is far too important a topic to leave in the hands of product vendors – this is a Business thing – the clue is in the name BUSINESS PROCESS MANAGEMENT. [...] They will talk about the presentation layer, the SOA integration support, analytics, modeling and what have you.

This is, unfortunately, true of a great many people in the BPM ecosystem.  However, it doesn’t sound like a few of the pure plays that have been acquired (take a gander at Phil Gilbert’s blog for several essays on the subject of business taking control back from IT), and it doesn’t sound like some of the new vendors (ActionBase as one example).  Whether these vendors are well-represented at Gartner conferences is another question entirely, but it is ironic that it is typically the small vendor that is more focused on business value. One of Jon’s last points:

Every vendor believes they are unique but the fact of the matter is many of the software metaphors used in these products were defined by pioneering workflow vendors such as Filenet, Staffware, Plexus and Wang

Well, honestly, software metaphors are meant to be re-used, so I’m not sure that that, in and of itself, is a point of criticism.  For example, some of the metaphors in older integration technologies like CORBA and DCOM are embodied in SOAP and WSDL – but not many would argue that web services weren’t a step forward. And if BPM functionality is truly commoditized – is that bad for the customer and the industry if it becomes more standard and more cheaply available?

I know it is tempting to look at the glass as half-empty, but with so many BPM vendors performing so well in a challenging environment, its hard not to look at the glass as half-full. Call me an optimist.

Someone had to do it, and I’m glad it was Theo Priestley, and not I!

Theo’s written up a summary of the Forrester-initiated BPM Jam on Twitter (thanks Connie!), and did a pretty good job of it.

Key points from his summary, where the idea that education needs to standardize (a la ABPMP), but also needs a more mature, comprehensive approach (a la Lombardi University). I missed this part of the discussion so I’m not sure how people felt about the OMG OCEB examination – of course, since that is a cert only, not a full educational curriculum, that may be why it was overlooked.

Another key point was the idea that a business architect requires 20 yrs of experience with Six Sigma, Lean, TQM under the belt.  As Theo put it:

I disagree somewhat on that point, whilst those methods are ‘nice to haves’ they shouldn’t be prerequisites of a Biz Arch and certainly not as steeped in the skills that they can’t accept outside influences. I’ve seen this among a lot of Master Black Belts and I don’t think they have what it takes to be a Biz Arch on this alone. Needs to be cross-skilled and understand architecture on a wider scale outside of process alone.

I think the key point Theo makes is that if you have adopted the religion of Six Sigma, or Lean or <fill-in-your-favorite-improvement-methodology>, you may be too inflexible to solve BPM problems in the most effective way.  A simple example I’ve seen of this is the Lean and Six Sigma ideal of ignoring technology while improving the process.  As with most doctrines, there is a kernel of a good idea there, but too often it is taken too far – to the point where many six sigma and Lean practitioners seem to be saying that technology can’t inform process improvement approaches – which any software engineer can disprove.  The real point of course is to not let technology slow down the process improvement, which is a very different thing altogether, and something I very much agree with.

One of the popular sessions at bpmCamp was a session on offshoring, from which we have a few notes preserved.  Steve Lang from Ford moderated the discussion, which by all accounts was a lively one.

Several of the teams in attendance pointed out that they already have distributed teams, geographically, within the United States.  So the teams are accustomed to conference calls, IM chats, etc.  The teams are largely effective at handing off work remotely as well.

The challenge of a lack of timezone overlap hurt some off-shoring efforts.  Also, a reliance on “hand-offs” (ie, throwing a spec over the wall and expecting to get back a finished deliverable) was not working well for BPM deliverables.  There was a big challenge around how to structure teams and deliverables to get maximum “yield” out of the combined onshore-offshore teams.  One participant pointed out that the problem of hand-offs not working was between roles in the same geography – not just between geographies.  And everyone had problems with attrition undercutting their efforts to onboard staff.  Interestingly there wasn’t much discussion of different locations for the offshore work – not sure if this is because almost all of these projects were considering off-shoring in India or if the geographic differences weren’t that interesting to get mentioned.

Some of the suggested ways to address the challenges:

• Extensive use of webcams, IM, and screen-sharing
• Don’t settle for “newbies” in the offshore team – press for the most experienced people you can get
• Don’t try to fix the scope for your BPM project – BPM scope needs to be flexible to do it right
• Use a tool (e.g. Rally) to improve tracking and transparency in an Agile project
• Eliminate barriers to communication (e.g. going through “proper channels”). People on the project should have access to communicate with anyone else on the project without asking permission. (Emphasis on collaboration)
• Increase time overlap for the onshore and offshore teams.
• Have onshore or offshore members visit opposite location to build relationships and come up to speed.

I’ll make another recommendation: use an offshore team that actually does this stuff for a living in their local geography.  There are many issues working against you when you offshore BPM work -but don’t let a lack of appreciation and experience with BPM be one of them. BPM projects are quite a bit different than the typical IT project, and the collaboration required between business and IT requires more nuance and communication than the typical project.

Interesting article in the MIT Sloan Review on “Where Process-Improvement Projects Go Wrong“.  It compares process improvement projects to the behavior of a metal spring, by dividing into three phases:

1. Stretching – at the beginning, a small team is motivated to succeed, and has support of executives.  A six sigma or process improvement coach helps them navigate some of the harder issues to make sure they stay on target and achieve early success, which causes additional initiatives to be kicked off.
2. Yielding – As the process improvement coach is removed, teams begin to revert back to prior behavior, or lose the ability to get the team objectively past some of the harder sticking points.  Executive attention, and perhaps some of the best team members, has moved to other projects.  Performance starts to retreat, though not necessarily to pre-improvement levels.
3. Failing – the vicious cycle begins “With the improvement expert long gone and no additional training in Six Sigma or other improvement strategies provided by the aerospace company, team members became increasingly discouraged by their failure to build on earlier success. They eventually stopped caring about the improvement project, partly because it wasn’t tied to their performance reviews.”

Well, I feel motivated, how about you? Luckily we are not springs, we’re people, and we can be a bit more creative about avoiding this inglorious “failing” phase than the author imagines.

The article author proposes 4 lessons learned from the many companies they studied for this report:

1. Keep the improvement expert around longer – or share this expert among more than one team to spread the cost – but the recommended term was 2 years, augmented by training managers to pick up these responsibilities.
2. Performance appraisals tied to improvement.
3. Keep teams small (less than 10).
4. Executives need to directly participate in the projects, not just receive reports from someone who has incentive to focus on only the good news.

This isn’t bad advice, it is good advice to start.  But it is insufficient and unlikely to cause organizations to suddenly get higher success rates with process improvement.

What did they miss?  Well, they missed BPM, is what they missed.  One of the reasons BPM is a “killer app” for process improvement is that when you discover the most effective changes to make for your process, you can put them into software, not just into a book of Standard Operating Procedures that your team will quickly forget about.  And your improvements aren’t just things that people on the team learn and practice, nor just things that they pass on to others on adjacent teams – they are things that get encoded into your process.  The software gives you:

• Some resistance to the “yielding” phenomenon described in the study results.
• Accurate measurement over time – no dependence on manual measurement techniques that may degrade as team members lose interest in the stop watch and other manual measurement techniques.
• The ability to “bake in” an improvement and move on to the next thing, rather than get stuck in a high-cost maintenance of the first improvement.
• A “control” baked into the software.  (Six Sigma has standard approach called DMAIC – define, measure, analyze, improve, control… and BPM software directly addresses D, M, and C, and supports the A and I activities…)  So often the “failing” phase is because the organization loses focus.  Software doesn’t lose focus – it just keeps running.

Too often, the proponents of Lean and Six Sigma ignore technology because they view it as an impediment, failing to understand that there is more to technology than MiniTab or SAS/SPSS or Excel.  And if technology allows you to do something at lower cost, such as a process improvement project, or maintaining an improvement over time, then it shouldn’t be dismissed out of hand.  But it is easy to understand why they sometimes see tech as an impediment – deploying software takes time – and during the initial phases of improvement the improvement guys just want to move fast.  My take is – don’t let the tech get in the way, but don’t pretend it can’t dramatically improve the efficiency of your business – in fact, technology, and specifically BPM software, is likely the key to locking in the gains you seek to establish a “new normal” that is a more efficient and effective process.

Starbucks may be doing a lot right these days – they’re stock is up more than 100% from its lows, almost 200%.  But recently they rolled out a change at “my” Starbucks that is a step backwards.  I go to one of the highest volume-per-square-foot Starbucks in Austin, TX.  One of the reasons I go there, despite the fact that it is so busy, is that the staff is by far the most efficient in Austin – for the last 12 years they’ve been cranking through the line faster than any other store in the city, and remember all the regulars’ names and drinks along the way.

In fact, it wasn’t unusual for me to get to the cash register and my drink would be there waiting already made.  I always wondered what happens if I change my order!  But they knew I was a regular and what that meant.  And I got faster service for being that regular – something I might expect to get at a neighborhood cafe, but not at a big national chain.  The baristas there are my friends – I’ve seen them get married and have kids (and, they’ve noticed when I got married, and when I stopped on the way to the hospital after our kids were born, to get coffee after a long night).

But the other day, the wheels came off.

What happened?

It seemed like a little thing – and I’m sure the folks in HQ thought they knew what they were doing – rolling something out to this location that they do at lots of the high volume locations.  They started printing stickers for the cups instead of writing on them with a marker or grease pen.

Its the kind of automation that seems to make sense.  It might even make overall throughput slightly better, or error rate slightly lower.  But my observations follow:

1. They don’t ask my name anymore when I order.  I just order.  The new employees aren’t learning my name.  They aren’t my friends, and aren’t becoming so.  They also don’t know my drink, which is even worse.
2. My drink doesn’t get started until after I pay.  Sometimes the person making drinks is literally idle because the cashier has gotten behind.  The barista behind the espresso machine no longer jumps the line by making regulars’ drinks in advance.
3. I spend an extra 5 minutes in the store on average.  It is no longer a quick stop for me on the way to work – its an expensive distraction from getting started with my day.

So, I’m looking at buying an espresso machine for the office.  So, I bought a Nespresso machine for our office.  I won’t have to wait in line, and they won’t have to learn my name or my drink.  Or collect my money when I’m in Austin.

Besides just ranting about Starbucks, this is a bit of a cautionary tale – sometimes an “obvious” technology improvement or automation can actually slow things down because it robs the people involved in the process of the independent volition to make a difference – or to delight the customer.  The trick is to introduce tech that enhances that individual ability to execute rather than stifling it.  This is critical for BPM projects especially.  We can’t forget that for all too many of our processes, “delighting the customer” is still a goal.

The first go-round on Process Debt got quite a few reads and private emails and comments that motivated me to keep thinking about his topic and how to further clarify process debt so that we can use this concept to help manage our process development efforts.  It also motivated me to run a small session at bpmCamp on Creating and Retiring Process Debt.

We had a good discussion during the presentation and lots of examples from recent history to draw on in this room.  A couple of folks from the same company were in the room and as a result they tell me that they now have a common, useful vocabulary for describing trade-off process decisions which are made *all* the time in BPM groups.

Presentation embedded here, but also some rough notes below for those who prefer reading text…

(Incidentally, I used a tool called “Prezi” for this which I find pretty useful for organizing thoughts about a topic that requires a lot of context or gets past a certain number of slides… Something about the spatial relationship of the elements helps maintain context in the discussion.)

First, let’s agree that there is such a thing as Technical Debt, as defined by smarter folks than I. But also, that we can repackage it just a bit to more closely align with Process terminology and concerns.

Why we incur Technical Debt (borrowing heavily from McConnell):

1. Time to market – we want to get our process built quickly so that we can start to reap the ROI quickly – and time is money.  If a process can save you $1M per month, each month of additional development effectively costs you $1M.  Time to market matters.
2. Preservation of budget (for startups, preservation of capital)- We have a limited budget, and we want to make sure we spend it on the things that give us the most leverage for getting ROI.  These are likely the same things that will help justify budget for additional improvements going forward.
3. Delaying development expense.  As a system nears end of life, it takes a very high degree of return to justify anything but expedient fixes -because when a system is retired, its technical debt no longer matters and isn’t paid within that system – it is being paid by whatever is replacing it.

What are the types of Technical Debt that we can be concerned with:

1. Unintentional Debt – debt incurred due to poor technical choices, but not with forethought.
2. Intentional Debt – debt incurred for strategic reasons, with explicit trade-offs.
   1. Short-term debt:  sacrifices made to get a specific release out by a certain date.
   2. Long-term debt:  typically architectural decisions (assuming only one database platform, for example) that can be good trade-offs measured in years.

And then we have “Product Design” debt – which I believe can occur in process projects where functionality is added over time until the originally simple screens have become cumbersome and unwieldy.  This isn’t quite the same as Process Debt – but process projects can become afflicted with it.

Finally, we have Process Debt itself.  I think we can follow on the Technical Debt framework and build on it:

1. Unintentional debt
   1. Process Shift – this happens when performance of the process degrades over time.
   2. Requirements Shift – this happens when the external realities change but your process fails to adjust adequately.
   3. Squeezing the balloon – the local process gets optimized at the (greater) expense of other parts of the organization (or customers or vendors)
2. Intentional debt
   1. Short-term trade-offs to get a release out – scope removed, etc.
   2. Experiments to find out which possible solution is the right one
   3. Manual work-arounds in place of system integration (SOA team can’t give you your webservice in time? will a manual work around work for the first few weeks or months?)
   4. Sub-optimal integrations (batch instead of real-time, etc. )
   5. Assumptions around geography or localization or product line support.

Tracking Debt:

1. Enter tasks into work tracking or defect tracking software to track both the items that need to be worked on and the effort required to retire the debt incurred.
2. Measure the process for squeeze-the-balloon effects (can be difficult if the other parts of the balloon are not measured).
3. Teach the team not to take short-cuts that “aren’t worth entering compensating tasks in the software tracking tool” – if they’re not worth it then the short cuts aren’t worth it either.
4. Another suggestion (from James Shore) is to measure Source Lines of Code (SLOC) as an approximation for technical debt. It isn’t an exact measure, but since lines of code will affect cost of maintenance, it is a reasonable proxy.

The starting point is that you have to have a system for tracking your work and work backlog – and from there you can mature the way you think about Process Debt based on what works for your organization.

At bpmCamp we had a great session on BPM Requirements led by Zelda Durden.  Often the answer to the question “How much is enough?” is “I know it when I see it” – but we wanted to go deeper, and Zelda offered to help shape the discussion. How can we tee things up so that we know how much is enough as part of our requirements process?

She broke things up into two phases for consideration:

1. Exploring – no budget approved yet, no Project Manager either.
   1. Strategy – what needs to be improved from 50,000 feet, and what are the business priorities and goals.
   2. People – who and how much commitment from the business?
   3. Process- scope, SIPOC
   4. System – What is the current system?  Current state of the process?
   5. Discussion:
      • getting people commitments is difficult at this stage
      • using this information to help prioritize projects – along with ROI and other tools
      • scope management is difficult once users see what is possible.
2. Discovery – a real project is on the books, with budget.
   1. Strategy – Critical Success Factors (CSFs), ROI calculations if necessary, alignment with corporate objectives
   2. People – current skill set of process users versus new required skill set?  Change management: figure out the influential people and engage with them.
   3. Process – full process audit/investigation.
   4. System – plan for legacy systems, determine the extent of Teamworks (BPMS) in the solution.
3. Development Starts

First playback drives a lot of requirements changes.  Not planning for that level of change is just kidding yourself.

• Iterative development – iterations range from 3 weeks to quarterly – which keeps the lifespan of requirements to some reasonable level.
• Initial “onboarding” of process focussed on keeping it very simple (no integrations, or as few as possible) – get the process right first.
• Best process information comes from the end users – have to get in front of them and get feedback.
• Blueprint could be used for initial process modeling / analysis – but has the disadvantage of forcing you to consider licensing issues (unless you have a site license, etc. )
• Some people don’t get flowcharts: figure out the tools that work to communicate with them.  Draw on the whiteboard, for example.
• Teamworks as a process document repository (even for processes that are never intended to be TW apps).  While this isn’t the primary use of Teamworks, there was general support for this idea.
• “BPM Document” like a mini-BRD
• BRD still developed for interfaces / web services, etc
• Plan to develop process for project selection/kickoff

There was much more discussion than what we’ve captured here – but that is the nature of these things – you get into the conversation and you forget to take notes!  A few related thoughts come to mind for me, which I’ll share here.  Our CEO, Lance Gibbs, has some great common sense yardsticks that he often communicates to people on BPM projects who aren’t familiar with how to think of requirements:

• Does it affect ROI?
• Does it impact business objectives?
• Does it impact customer service?
• Does it impact throughput?
• Does it impact quality in a measurable way?

You can think of similar questions.  If a requirement doesn’t address any of these concerns, it should probably go in a secondary bucket to “come back to later” after you’ve first dealt with requirements that DO affect these criteria.

We applied a similar approach to documentation:

• Does it reduce work?
• Does it reduce waste?
• Does it reduce risk?
• Is it required for regulatory or other legal reasons?

It turns out we as an industry turn out a lot of doc that does none of these things.

More to come from bpmCamp 2010 @ Stanford…

Great piece by Kasparov on the combination of human process and machine computation to allow amateur chess players to beat some of the world’s best chess masters.  This is a darn good read – and though not really a BPM article, it should inspire us all to improve with the aid of process and computation.

The End of Days.. ahem… The End of BPM, is here.

Or is it?

We have several pundits proclaiming so (either anonymously or otherwise). We have several vendors and analysts and bloggers dancing on the grave of BPM (or the pure play vendors). We have even BPM advocates bemoaning the loss of the BPM vendors of yore.

But lets take a step back for a minute… and imagine a strange alternate universe…

[fade to black, gradually clearing away as the voiceover starts]

Let’s imagine a world where there are only 3 BPM engines in the world, like the three heads of Cerberus. One from Oracle, one from IBM, and one from Microsoft. Or, if you prefer hydras, we could have another one from SAP.

BPM will have achieved the ubiquity of RDBMS because every corporation that buys software from these giant software providers will have at least one BPM engine as part of their enterprise stack, along with requisite modeling tools. Along with myriad integration technologies to plug these into existing applications or even other BPM engines.

In this world, there will still be opportunities for start-ups to sell tools for building applications to run on these stacks, just as there are still opportunities for start-ups with better SQL tools.  There will still be opportunities for open source BPM engines to compete with commercial BPM engines, just as there are open source RDBMSes competing with commercial ones.  If the Techies try to bury BPM in IT, the Business guys will drag it back out into the light of day where it belongs because they have real business needs to address.

Because it has never been about BPM engines, the parts that the business never sees.  Or software stacks.  Its always been about the ease in building the applications that the engine runs, the ease of adapting those applications to changing business requirements (processes), and the effectiveness of the measurements, dashboards, and analytics that provide the learning feedback loop for the business.

[ fade to black and then the lights return ]

As we wake, groggy from this little daydream… what was so different about our alternate universe?

It turns out, while we like to root for David over Goliath, the various BPM software companies selling have largely done well for themselves, their shareholders, their employees, and their customers.  Not a one of the pure play BPM vendors went out of business (or even came close, so far as we can tell).  A few IPOs would have been more exciting.  And in times when enterprise software companies were awarded better multiples, might have made sense.

And the new batch of BPM tech and companies coming along is pretty interesting too.  I see no reason for melancholy with the batch of startups that are hitting the market with interesting products that take different approaches to BPM (or facets of BPM).

I think things might just get more interesting.  Ubiquitous BPM has a good ring to it.

A recent entry from Joshua Baer, a local entrepreneur in Austin, TX, on the subject of turning complainers into champions, struck me as especially appropriate given the season.  We’re many of us experiencing how companies handle customer service issues right now: returns, especially, are an opportunity for companies to turn complainers into champions.  Delayed flights, or bad experiences traveling, likewise.

A hotel executive once told me that every mistake or customer problem was actually an opportunity to build on the brand by fixing it aggressively for the customer and engaging with them – that when customers *don’t* complain, it is actually hard to win them over to being champions. I recently ordered a laptop bag from Ebags and when it wasn’t quite what I was expecting, the return process was painless, and *free*.  I’ll definitely consider ordering from them again.

Josh’s experiences with OtherInbox serve as the examples for his presentation – and I can attest that their customer service is excellent, as I’m a user (and former complainer) of the service myself.  I didn’t quite “get” how it interacted with Gmail at first, but once I did, I became a convert and I’ve recommended it to others, such as Keith Swenson. There are lessons to learn from this approach, even if you don’t run a consumer-facing business.

Andrew Chen asks this question in his blog.  Its a good read from several perspectives, but I’ll just pull out the couple of bits that people developing processes should be thinking over well and good (I like to read the work of thought leaders outside the BPM space to see how their ideas might apply to BPM):

Back to Steve Jobs – what does he really do?
Long story short, my hypothesis is that Steve Jobs is one of the rare CEOs who is very focused on product desirability. In battles with the business and technology goals, desirability will almost always win out.

And what is “product desirability”?  It sounds like understanding the “voice of the customer” to me (but broader than typical six sigma definition of that term).  Having an understanding of what will matter to your customers is a key driver for success for your processes.  The definition of customers is a bit vague :  users, primarily, but also people impacted by the process (often, your end-customers)…

• What makes your process desirable to your customers?
• What makes your process desirable to your internal users?
• Who is responsible for representing desirability of the process?

Andrew goes on to define what he surmises are Steve Jobs’ duties:

So his role isn’t that of a designer, but rather Chief Design Advocate. This means:

• he makes it clear that products should be “insanely great”
• he recruits a top design team, and protects them from competing goals
• he is willing to spend money, adjust technology processes, all for the goal of highly desirable products
• he convinces financial analysts, industry pundits, etc. that product design is very important

As Andrew says – is there any reason that any company can’t be doing this?  Or that you can’t be doing this for your processes?  Making sure the processes are great, that you have recruited a top BPM team that is focused on making the processes valuable to your customers?  Spending money, adjusting technology, to support highly desirable products?  Convince the folks that hold the purse strings that processes and process design are important…

Very few companies do this… It could be the differentiator for yours.  And there’s no reason you can’t do it.

I’ve been reconnecting with some concepts from the startup world, such as “technical debt” – well-defined in Wikipedia, but also better covered by this article, among others.  Essentially, Technical Debt is the future cost you incur by taking short-cuts (knowingly or unknowingly) today.  Of course, we explicitly choose sub-optimal solutions in the short term in order to have a shot at a better solution later (thus the axiom “Perfect is the Enemy of Good”).  But we also incur technical debt when we inadvertently introduce defects or poor design decisions into production software.

In this The Concept of Product Design Debt is introduced (to me) by Andrew Chen (@andrew_chen).  Although the concepts of Technical Debt and Product Design Debt are not targeted explicitly at BPM projects, the concepts apply particularly well to iterative development projects, and to environments with a lot of change (in requirements and/or technical direction).  As a result, it seems that they apply particularly well to BPM.

Andrew walks through the example of Amazon’s website tabs that would grow seemingly without limit, before being refactored to something more manageable later (paying down the debt).  If you’re truly running an iterative, agile BPM endeavor, the following passage may ring true for you:

The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control.

However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have to refactor your design.

He gives some great examples of how product design debt is introduced into production sites – but it isn’t hard to imagine in the world of process, where we’re often looking to alter our process designs to accommodate changing business requirements.

The analogous question in BPM circles is whether the experiments and changes implemented in your process have created a process debt that needs to be paid down through refactoring.  In large part, I think you could describe the process investments of the last 20 years as having created great improvements in efficiencies, but they’ve also introduced process debt over time – processes have become more complicated than necessary, manual shortcuts have been introduced “temporarily” that became permanent, and IT systems were built to support re-engineering that couldn’t support ongoing change. In each of these cases, BPM can help surface this “process debt” and offer tools for carving it down to size.  The goal isn’t necessarily “zero debt” – but the goal is to keep it from getting out of hand.

Even within BPM projects we can accrue process debt.  This is independent of the technical debt we may have accrued that is purely technical – we’re not talking about running two queries where one would do – we’re talking about the process itself.  Decisions about the process itself may be intentionally short of “right” in the short term, in order to get incremental improvement out the door.  Or the design may have unintended consequences – creating a bottleneck where one wasn’t expected (squeezing the balloon, so to speak) – or fixing errors in one area and introducing errors in another.

I think there is yet another way we accrue process debt – and that is when our organizations fail to adapt to a changing business climate.  If you rolled out a process two years ago and haven’t made any tweaks in the meantime, I believe you have acquired process debt – a steady, growing gap between what your software and processes are designed to handle, and what the reality of current business conditions requires.  After all, new products and services enter the market, new competitors enter, old competitors exit, and customer needs change over time.  In a typical organization, the organization will wait until the process debt becomes quite large, and then address it with a big process improvement project, or a new software roll-out (new CRM system anyone?).  It isn’t that this decision to invest is wrong – in fact without a BPM Suite, this may be the most rational way to deal with process debt.  But an organization focused on process needs to pay down this process debt along the way – and the best way to do it is with a robust BPMS and a team focused on BPM for the long haul, that can manage this process debt and keep it from getting out of reach.

A BPM team that intends to really build capability in their organization for process improvement needs to account for the concept of process debt, and figure out how to manage it over time (and even pay it down from time to time).

Of course, some would probably argue that there’s no such thing as “debt” – that you are simply leaving yourself with additional work to do in a future iteration.  But the argument for applying the concepts of technical debt, product design debt, and perhaps process debt – is that the “iteration” notion doesn’t properly help you capture the cost of decisions you are making now.  We’re not talking about implementing 3/4 of something – we’re talking about implementing something that we know will cause a problem (as described above), and choosing to do it that way because we’ve measured that cost against other benefits which outweigh it.  A classic example is when an integration isn’t available in time for go-live of a process – but we expect it to be in the future.  In the short term we can choose to take on that work with manual intervention (or a suboptimal technical solution).  But we’re incurring a future commitment to switch to that “correct” integration.  It just makes sense to proactively manage these commitments as “debt” to be paid off.

So.  I’ve made the argument in favor of including the Process Debt concept in long-running BPM operations.  Are there good counter-arguments to be made?  Are there problems with managing process debt the way we would manage technical debt?

Jim Sinur has his usual pro vs. con argument with himself on the issue of BPM in China.

The anti-BPM argument:  lots of cheap labor, 300k+ engineers turned out every year -so why invest in BPM when we can throw bodies at the problem.

The pro-BPM argument (presumably Jim’s take):

While I value lower labor costs, I think the battle is producing higher gross domestic product (GDP) with less hours per GDP dollar. Eventually Chinas cost have to go up. It’s already happening in India. Don’t throw out BPM; throw out the programmers !!! It’s probably different in the west where the labor costs are higher.

Actually I think this is a tension that takes care of itself.  China (more accurately, firms within China) will invest in BPM when they feel the pressure to do so, and likely not often before that point.  That pressure might be higher labor costs, higher quality standards (not all quality improvements can be fixed by more manpower), or increasing pace of change – the same kind of pressures that apply here.  But I don’t think, at this point, that China’s goal should be higher GDP with less hours of labor – that is a byproduct of other good data, not a goal in-and-of itself.

For now, labor costs are not pressuring China to explore BPM, perhaps. But that picture is likely to change as the economy grows in China at a rapid clip.  But BPM is a “pull” not a “push” sale at this point – the customer has to realize they have the need before you are likely to sell them on the virtues of BPM as the way to satisfy that need.

Continuing on an economic theme within our blog, topical due to the economic challenges and BPM’s relevancy to those challenges, here’s another offering along those lines.  A recent McKinsey Quarterly article discusses a new “managed services business model” that helps both customers and employees of offshore service providers.   The thesis of the article is that the recession has created competitive pressures for the offshoring business that are starting to separate winners from losers.  Allegedly, these new winners are focusing on the quality of services rather than on the cost-per-head, focusing on collaboration with clients, and are gaining more control over outsourcing strategies.

However, out in the field in the US, I haven’t seen this separation of wheat from chaff – I see the pressure, but the manifestation of that pressure still seems to be most clear with respect to cost discussions.  Although in some cases contract language has changed to focus on deliverables rather than cost-per-head – those deliverable-based contracts are merely reinventing the wheel of the old fixed-bid-contract -putting more risk on these IT offshoring companies to deliver, or else face punitive measures from their customers.  In the short term these fixed-bid strategies will likely pay off.  But without a superior delivery capability, fixed-bid offerings that win on price over time-and-material offerings, tend to produce lower margins or negative margins – risk has simply been transferred from one party to the other, with no additional compensation.

Worse news, this transfer of risk hasn’t historically proven to increase the probability of successful projects.  And there is no reason to think the results will be different this time.

The second thesis of the article is that the winners are developing deep talent pools that global clients demand, and developing progressive techniques to manage and retain these workers.  While I’ll concede that this may be true in some areas, I have not seen evidence of this in BPM.  This isn’t just my American perspective, when I’ve had informal conversations with BPM practitioners in other countries – in Europe, South America, and the Middle East – they all tell me that they can’t imagine doing BPM well without being close to the client on a regular basis.  When I ask them how successful they’ve been at leveraging offshore talent the answers have not been promising.  The chief complaint is the lack of understanding of business, of process, and of how to manage a project with requirements that are not set in concrete for the duration of the project.

Unfortunately media outlets and analysts routinely over-estimate the talent to be found in faraway places that can be plugged into Global or US companies’ projects, while under-estimating the talent to be found right in these companies’ backyards.  It makes for good print, and there are a lot of executives who will make these points to the media.  But it is a lot easier to say that you’re offshoring work because you “can’t find enough talent” than it is to say that you’re offshoring the work because “local talent is more expensive”.  I’m not making a moral argument against offshoring, but I think if the discussion was more honest, some of the hype could be reduced.  There is a global shortage of talent for BPM deployments and other important work in IT and process improvement.  And the nature of the work doesn’t lend itself to being separated by great differences in time and space.

The part that I think McKinsey got right is that the competitive advantage of “cheaper labor” has nearly run its course as cheap skilled labor becomes more scarce, and as customers become more discriminating.  Jaisundar writes a parable of this problem in The Corrosion of Competitive Advantage.  After reading the narrative, Jaisundar turns to a couple of very interesting facts:

1. IT has “sharpened” (increased) differences among companies rather than reducing them.  And yet conventional wisdom is that technology renders differentiated products and services into commodities.  The conventional wisdom is wrong because the pace of change favors those organizations that can adopt and leverage technology fastest and best.
2. The competitive shakeup in the US is intense, but may only be beginning in many other economies.

There are some fantastic lessons for Indian IT service firms in this article, but many of them apply in hotly contested markets in the US as well.  The key thing is that superficial changes (blue hat, anyone?) will not win the day in the long run.  The competitive advantages that will win in the long run are the values and culture and skills that run deep in your organization, and the way you surface those attributes to your customers via core business processes that make up the “customer experience.”

I was struck by a series of articles I’ve read recently regarding Outsourcing and how it is really hurting American businesses.  Robert Hayes raises the specter of the US possibly killing its Innovation Machine, and compares outsourcing of High Tech to the Subprime-Mortgage fiasco. He makes a few powerful points, for which it isn’t hard to look for data points to support.

The same forces can lead a number of manufacturing companies — each independently making apparently rational decisions to outsource certain segments of their operations — to ravage their industrial commons: the valuable infrastructure of suppliers and skills that underpins them. The supposed savings they expect to generate from such activities are based on costs that often do not properly reflect the damage they are causing.

As I read this, I think of Dell, once the pinnacle of the PC industry’s drive toward efficiency… But under the hood of Dell’s efficiency engine we discovered that a lot of their benefits had to do with financial engineering – taking ownership of inventory as late in the process as possible, owning the warehouses (and charging rent) that their vendors used to store their equipment prior to final assembly, and paying creditors as late as possible.  Reading on in Mr. Hayes report:

A company’s competitive advantage is rooted in things it can do (e.g. design, make, distribute, or market) that its competitors cannot do as well, if at all. As the number of these core capabilities decreases, the company’s competitive vulnerability to those that are able to master the same capabilities goes up.

This sounds like what Dell did – outsourcing the manufacture of increasing parts of the value chain, until you reach the logical conclusion, where Dell no longer does even final assembly of much of its inventory, it is simply the design, marketing, and distribution vehicle for other companies’ computers.  They reduced the number of areas in which they could differentiate from the competition.  And the competition (HP, Lenovo, Acer) have adopted very similar business models, and now enjoy similar (and in some cases, better) margins.  As Mr. Hayes writes: “[...] teaching an armada of hungry potential competitors first how to master, then how to surpass their capabilities.” Meanwhile, it is difficult to unwind this change in the food chain because the necessary infrastructure and skills to support manufacturing and assembly in the US has now been outsourced overseas (largely to Taiwan and China). Restarting that infrastructure in the US is a daunting task in dollars, time, and leadership.

Mr. Hayes makes a persuasive argument that these companies have not, in fact, been improving profitability – that they have instead been cashing out their intellectual property and assets in exchange for a temporary improvement in margins… Which is now evaporating.

Now that the field has been reduced to competing largely on: Design, Marketing, Distribution… Branding becomes more important.  And this probably explains in large part why Apple has been so successful of late -they can outsource the production efficiencies that Dell (and others) have produced in overseas outsourcing shops, and they can exceed these other manufacturers with differentiated software and hardware design and branding (The aluminum unibody Macbooks with Mac OS X are the envy of the industry), better marketing (Apple ads), and distribution innovation (Apple Stores).

What Mr. Hayes is arguing isn’t entirely new, but our titans of industry have been unwilling to listen.  In an issue of CIO magazine in 2005, the then-CIO of Aflac, Jim Lester, said that he wouldn’t consider outsourcing his IT because he couldn’t replace the organizational learning, the knowledge of the business, and the alignment with the business that he had in his current IT organization (some people call this caring about your company).  But he was a minority voice at the time.  The fact that his organization out-performed the insurance industry as a whole for the next few years might be unrelated, but I wouldn’t bet on it.  Of course if particular IT services trail the industry averages then it may make sense to switch to commodotized service offerings as a way to play “catch-up” with the industry – a firm will sacrifice its ability to excel in that area, but will eliminate the possibility of self-inflicted wounds in that area, while it can then focus on the areas it knows best.  One could argue that this is what Apple did with its back-end fulfillment – which trailed the industry in efficiencies – so that it could focus on its strengths in design without the drag of inefficient manufacturing operations.

I worry that over the last 10 years, the US been on a similar course with regard to software development. Increasingly attempting to jam down the costs of software developers, and going anywhere in the world in order to achieve it, without regard to the specific qualities of the firms they are outsourcing to.  If this goes too far, we’ll lose the critical ecosystem here in the US that supports software developers (and many software-related professions and the businesses that are based on them).  I see signs of this in startups who don’t do any software development in the United States and assume that this financial engineering will give an edge to their “ideas”.  But what software has often proven is that ideas are cheap.  Execution is differentiating.   These startups are betting the farm on unproven execution resources, which then puts them in competition with hordes of competitors with fewer ways to differentiate.  Counter to this trend, I also see a number of firms now with hybrid software development models that include doing development on- and off-shore to gain some cost advantage but without losing the ability to try to differentiate on execution.

In a very cogent piece on the subject of Indian outsourcing in particular,  Jaisundar argues that IT can sharpen competitive advantages, rather than diminish them.  That India based service providers need to migrate from being order takers to a deeper relationship that can address business process problems proactively and cooperatively.  This is likely true, but it runs counter to much of the order-taking culture at these firms – it will take time to push the mindset in the right direction and to find and train the right people to lead them in that direction.

Meanwhile, there’s quite a bit of abuse of foreign workers going on in the US.  An expose in Business Week on this practice goes into excruciating detail of some of the worst cases.  However, BusinessWeek makes the claim that most employers are unaware that these abuses are being perpetrated by the staffing firms that they employ.  I don’t buy that argument.  I think companies bear a responsibility to know that the people they staff are legitimately employed, and brought to the US under appropriate Visas (for all the attention on H1-B visas, no one is talking about the vast abuses of L1 visas going on right now). Companies bear a responsibility to work with reputable firms – if they don’t, then it is with the intent of getting workers at below-market conditions, which normally can only happen when you have a captive or disadvantaged workforce.  This is a bit like buying a Cartier watch for $10 and pretending that you don’t know it either (a) isn’t a Cartier, or (b) wasn’t acquired in a legitimate fashion. The buyer has a responsibility to buy legitimate goods and services.

In another article, Charles Green blames the money-first-above-all-else culture of Wall Street (and, increasingly, the executive suites of large firms) on Harvard Business School.  Charles Green, himself an alumna of Harvard Business School, argues that HBS has failed to imbue our “Best and Brightest” with a well rounded perspective of business:

Harvard Business School led the charge away from an approach to business centered in relationships and commerce, and toward one rooted in markets and competition. They promised us competitive advantage and efficiency. They delivered.

Unfortunately, the cost of this change is that American business is not prepared for a world that is increasingly interconnected, and increasingly relationship-driven.  Its a great, thought-provoking read.  As a long-time professional services guy, hearing someone say that business is relationship-driven is a bit like hearing that the sky is blue.  Of course it is relationship-driven, trust driven, commitment-driven.  And when organizations ignore this or trample on these aspects of their business, the chickens will come home to roost.  But apparently this was hasn’t been part of the culture of Wall Street for some time.

These articles only scratch the surface of what I’ve seen lately in the press and in blogs, but I think each one captures a specific issue perfectly.  If you can’t differentiate part of your business, it may make sense to outsource it, but be careful.  There are serious landmines in outsourcing, and it isn’t clear that American businesses have correctly assessed those trade-offs for the long run.

I really enjoyed Mike Gualtieri’s post on Forrester’s blog: “Excuses, excuses: The Business Doesn’t Know What it Wants“.  The two big culprits:

• The business doesn’t know what it wants.
• The requirements keep changing.

But my favorite advice he gave to IT professionals immediately followed this:  “Get Over It”.

I couldn’t agree more.  Of course the business doesn’t know what it wants in BPM because they’re tackling a domain that is new to them (BPM), and they’re tackling a moving target (the Business Process).  And this isn’t unique to BPM, far from it.  And despite this, many projects are successful.  So obviously the fact that the business “doesn’t know what it wants” is not an excuse for failure.  If you’re collaborating with the business on a solution, help them figure it out by prototyping, iterating, and helping them understand implications they might not have though through.

The other bits of advice are equally good:

• Understand the Business and Your Users
• Build for Change
• Get Passionate about your Craft

Mr. Gualtieri notes that the “industrialization of software development has been an epic fail.” I agree.  From my point of view industrialization was always the wrong goal.  Software development is more a craft than an assembly line.  One learns the craft through many thousands of hours of practice and through mentorship from masters of the craft.  And despite the fact that the news media and other nontechnical people view software development as utterly lacking in creativity and design, they are mistaken.  Software development is an intensely creative effort, when done right.  Which explains why so many projects fail when they go for the lowest-cost-possible staffing models.  In fact, BP3 and other boutique firms like ours are often brought in to rescue projects that were, at first, given to the low-cost provider.

Ok, no more excuses, BPM practitioners.  Let’s get out there and deploy some processes.

One of the sessions at Forrester’s Business Technology Forum 2009 was a lunch session sponsored by Appian on the subject of Iterative or Agile development and BPM.

Sandy Kemsley quotes Tom Higgins of Territory Insurance Office in Australia as saying “Waterfall contracts and iterative development don’t mix.” Apparently he spent quite a bit of time talking about the contractual aspects of the project they took on with Appian, and Sandy took the opportunity to comment as follows:

The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk.

It is certainly true that waterfall contracts (often milestone or deliverable contracts are really waterfall contracts, so beware) are not an optimal fit for iterative development.

Having said that, you may find yourself in a situation not of your own making – where a Waterfall contract has been put into effect, and you have the responsibility of delivering the project.  At such times, it is still in your interest to convince the project team to go down an iterative path and get the contract revised to reflect it.

At BP3 we have been brought into just such situations when major outsourcing shops bring our firm in to help lead a customer BPM deployment.  We articulate the value to both parties to help them see the light that although the Waterfall contract would allow a lot of choke-the-vendor opportunities, and a lot of change-order opportunities – it would also bury the team in change-order requests, and it would likely fail to meet the business objectives and time-lines.  We do this by making a simple commitment to both parties:

1. The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
2. The delivery team will deliver the highest priority work in a quality, repeatable fashion (in other words, technical team will honor the business’ prioritization decisions)
3. The iteration will be accepted if the business accepts it as having substantially delivered their top priorities and as having prepared the team for moving to the next iteration.

The difference in productivity, and in the tenor of the relationship is dramatic.  Of course we have to follow up words with deeds – delivering value, and delivering on the priorities the business has set for the team.  We have to take commitments seriously.  After establishing a pattern and habit of success with this new paradigm, we’re much more likely to achieve success.

A more common scenario is to get into a waterfall-methodology-oriented environment, where the contract may be more generally structured (perhaps even T&M).  In such cases, we have had a lot of success in applying iterative and/or agile techniques within the overall waterfall framework – including characterizing early development work as prototyping or design work, in order to pull some of the riskier technical or requirements issues to an earlier point in the deployment.

Regardless of the situation you find yourself in, you’re going to be better off if you can apply iterative techniques to your BPM deployments.  Once you apply those techniques, success will reinforce the approach.

Sandy makes another point in her post about working with people you trust – I couldn’t agree more.  If you don’t have that trust in your customer relationship, you have to work hard to earn it. If you don’t trust your vendor, find someone you do trust.

As a proposal, challenge yourself to think about your project as “Fixed Effort” rather than “Fixed Price” or “Time and Materials”.  What is Fixed Effort?

1. Honor the budget by deploying the process within the allotted budget.
2. Use iterations to always stay close to a production-worthy deployment.
3. Always work on the highest priority elements that meet the business objectives, and get you as fast as possible to a “minimally viable process” (For more information on this subject, look for Minimum Viable Product or MVP).

This approach honors the realities of the world that are often ignored at the peril of the project and its team members:

1. The Budget is LIMITED.  Fixed effort honors that by delivering a production ready process with real ROI within that budget.  Let’s say that again:  a Fixed Effort project honors the budget by delivering a production-ready process with real ROI within the budget.
   
2. Wrong requirements are among the most expensive mistakes a project can make, if they make it to production.  Iterations and Agile methods will expose these missed/mistaken/wrong requirements earlier in the process.
3. By always staying close to a production-ready release, at any time the Business should be able to say “this is good enough” (translation: we have a minimum valuable process), and you should be within just a couple weeks of going “Live” by doing a little cleanup and final QA before go-live.
4. By focusing on the business priorities, we’re focusing on the parts that add the most value / ROI – rather than the check-boxes that might meet IT requirements or might make us feel better about the project.
5. If pieces are left off in the end – they are likely less valuable and provide less return than the parts we’ve already implemented.

I realize “Fixed Effort” may not catch on in popular lexicon, but it keeps you focused on realistic budget in BPM projects.  The requirements aren’t fixed, as they are in a typical “Fixed Price” contract, so the vendor can’t easily commit to delivering static requirements.  A Fixed Effort approach is the way to address that requirements risk, while still addressing the budget risk.  Its a balanced approach, and managed properly, it works really well.

Ismael has a pretty good summary of cloud computing from the “business point of view” – which is to say, it largely avoids making a sales pitch on technical grounds, and simply makes a pitch on business terms -

• Utility Pricing
• Elastic Resource Capacity
• Virtualized Resources
• Management Automation
• Self-Service Provisioning
• Third-Party Ownership
• Managed Operations

Good stuff. check out Ismael’s post for all the details.  This makes me want to dig up a 7 elements of BPMS value.  I’m sure someone has already codified that quite nicely.

Phil Ayres writes a provocative article on his “Improving IT” blog: “When Business Process Management (BPM) is a waste of time” that BPM projects fall into only two categories:

• BPM automation
• Everything else

He goes on to say that really only the first category should be pursued with BPM.  The basic argument: it makes sense to try to replace people with software programs, rules, algorithms, and database lookups, but it does not make sense to “model” human-to-human interactions and attempt to improve them via BPM.

Well, to the first part:  to the extent that processes CAN be automated, many of them already are.  However, as business innovates faster (generally) than the IT that supports it, there seems to be an endless supply of new processes that have a lot of inefficiencies for the humans that perform them because thing that could be automated aren’t (forcing data re-entry for example).

To the extent that something can be reduced to a software program, I’ll agree that it should be, if you want your business to run efficiently.

However, I think the reason I fundamentally disagree with Phil is that we are starting with different definitions of what BPM is.  By my way of thinking, a software program is not a business process.  If the program is defined in such a way that its beginning, end, and middle only touch other systems, and touch no human interfaces, then we do not, actually, have a business process. We just have a program (or a non-business process).  The subroutines that my computer runs to keep it humming smoothly (garbage collecting memory for example) are not business processes. Business processes touch people: customers, suppliers. employees.  The job of BPM is to make those interactions between a person and the Business Process more efficient.  Not necessarily making person-to-person communication more efficient, but interaction with the business process.  As a customer, my experience should improve in terms of ease-of-use, or turnaround time, or quality of result, or cost.  As a supplier, my experience should improve in terms of fewer cancellations, more timely notifications or feedback, etc.  As an employee, I should have more information at my fingertips that is relevant to what I’m doing, and I shouldn’t need to know the ins and outs of myriad IT systems to do my job, and additionally I shouldn’t have to re-key data.

Phil writes:

In my opinion, most human-to-human BPM solutions (i.e. those that move work from one human worker to another) end up becoming glorified collaboration tools with a few rules scattered around. Most of the time and effort involved in implementation of new BPM solutions becomes a matter of working out how to make the workflow flexible enough to meet the many interactions that real people in real offices must perform to get work done.

I think what Phil is reacting to is the fact that in many process modeling exercises, there is entirely too much focus on modeling interactions that should not be modeled explicitly.    An example?  During an interview process, you might want to conduct a meeting at the end of the day’s interviews to review all of the feedback for each candidate and make final decisions (or decide on next steps).  That meeting could be modeled to infinite detail about getting feedback of each type from each interviewer for each candidate and require each person to record approvals… Or it can be modeled as a single activity that the hiring manager coordinates and captures the decision on.  From the process point of view, we only need to know that the “meeting” happens and that a decision is recorded by the hiring manager.  That “meeting” could be physical, virtual, email, whatever. We don’t care.

And Phil is right – if you try to capture too much of the silly back-and-forth that real people engage in, you’ll waste a lot of time and effort.  But that’s why you don’t model those parts of the interaction except in the vaguest possible ways, leaving the outcome up to the person most responsible or most appropriate at that stage of the process. It turns out there is still plenty of process improvement meat on the bone – because the inefficiencies are typically when you cross group or department boundaries and the lines of communication are less personal and immediate already – and then BPM gives you a way to steer and control your process (oh, and measure and improve it later).

Phil advocates not using BPM for these processes, but to “Go ahead, remove the waste from that process you want to improve” but then advocates not using BPM to do it:

[...] consider using a tool that is better suited to the type of work that is being done. BPM is probably not it. Find a tool that does not require 3 months of wasted time analyzing how to improve human interactions, before actually delivering anything.

First, I’d not recommend using a BPM tool that requires 3 months of wasted time analyzing how to improve human interactions before delivering anything.  If you’re being confronted with that, drop us a line or a comment and I’ll help you out with some recommended BPM software and methodology.  I just finished a 3 month project that went from conception to pilot in 3 months, with just a couple of weeks of analysis that happened before I joined the project. (Note: you need less analysis if you’re already familiar with your process!)

Second, Phil doesn’t explicitly mention which software tools he’d recommend, though he does generally recommend collaborative and case management tools that provide “structure around an otherwise unstructured set of operations.”  Well, that’s what your BPM software should be doing for you.  And if it isn’t, get a new BPM vendor, or get a new BPM consultant to help you see the forest for the trees.

I’m sorry, Phil, but BPM software is not designed to “prevent workers from doing the many things that need to be done,” but if that is your experience then you should out the BPM vendor who takes that approach.  Because it isn’t true of BPM in general.  I wonder if your experience is with the stack-vendor BPM tools that are, primarily EAI tools with a little diagramming thrown in to look like a BPM tool…

Without BPM, you are going to be hard pressed to track the critical data points you need to measure and improve on your process.  I’ve yet to see any other software category provide the kind of valuables raw business analytic data that a BPM tool can provide.