I might not have commented on the post, but for reading Neil Ward-Dutton’s response, and then Evan McDonnell’s response. Neil points out that CapGemini’s BPO offering uses IBM BPM (Lombardi), Steria’s F&A uses Nimbus/TIBCO.  And AWD from DST.  So it looks like there are a few examples – perhaps not getting much press.

Evan’s comments were even more interesting to me, crediting BPO providers with some foresight.   He rightly points out that BPO has largely been “lift and shift”, and that they’re running out of steam (but trust me, there are still low wage geographies and polutions for BPO providers to exploit).  Evan goes on to describe the BPOs with foresight and the great benefits they will achieve by adopting BPM.

I have no argument with that – clearly any company with scale, and customers, will benefit from good leverage on a BPM suite/system/solution.  BPO providers are, after all, just companies like yours and mine.

But I took some issue with the idea that we aren’t hearing about their success because they’re keeping it secret, and wrote:

I file this under “I could tell you about our successes, but then I’d have to kill you” (smiley face)

BPO organizations are/were not exactly known for being innovators. I didn’t notice any of them “anticipating” the lack of cheap labor – their whole business was typically based on the premise that the cheap labor pool was virtually limitless. It is no surprise that they are late to BPM, late to process improvement (for real). And a BPO’s process improvement is not for the customer’s benefit, it is for their own. As a customer to a BPO firm you have to own your own process improvement.

You might think I’m crazy or talking nonsense. Does Apple leave it to their suppliers to figure out how to improve their processes or their manufacturing? Or do they go in there and make it happen at a detailed level? Don’t think you can just hand off and walk away. If you do, you’ll find something that went from differentiator (when you made it a core competency) to commodity (when you stopped differentiating on it), eventually turn into a weakness and a cost center (after BPO has set in for a couple years). Only by then, you’ll have lost the critical internal organizational expertise to run that outsourced process…

There are benefits to BPO, but big risks as well. Handle with care.

Of course, many people would argue that most companies don’t do this investment in process and people – but whether companies do or do not invest, it is pretty clear that they should be investing.

As for BPOs, trust me, when a company’s whole business model assumes that individual people are not valuable nor interesting, it is hard for them to suddenly retread for the world where skilled labor is more expensive, and choosier.  Instead, they migrate down the experience ladder, or the education ladder, until they find people who meet the right cost structure (often regardless of the impact on customer outcomes).

To the BPOs out there: invest in people and process, it is the best way to add value for your customers.  But to the customers of BPO vendors – own your own processes.  Improve them.  Don’t let all the benefits of process improvement accrue to someone else.

Related posts:

1. The Economy and Process Improvement
2. Sloan Review on Process Improvement
3. HBR and Process Improvement Culture

But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Neil has hit it exactly.  The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that.  But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?

• The level of product and technical expertise you need to maintain your solutions goes up.  You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
• The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project.  Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
• Fear of change.  If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it.  We lose agility.  We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
• Testing overhead.  If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high.  Essentially I have to re-test everything.

But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower.  It can wipe out much of the promise of BPM in the first place.

You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS.  Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.

Neil’s next point:

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment.  But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side).  It becomes much more apparent in iterations 3 and 4, projects 5 and 6.  If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:

1. See about getting some professional help from a boutique consultancy focused on project success.  If you’re already working with one, consider a new one.
2. If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform.  You might have picked the wrong one.

Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.

No related posts.

Since I mostly agree with his post I’ll just focus on a few of my nitpicks:

“We cannot conclude that if a management style is good for physical production that it is good for brain work as well.”  We also can’t conclude that if a management style is good for physical production it is NOT good for brain work as well.  Or vice versa.  That requires more data and analysis than has been discussed on the blog posts linked above.

Kraft goes on to say that we should use “the right type of tool for the right type of work.”  To my mind, BPM has always been about that.  In my experience it includes mind maps, BPMN, BPEL, interaction diagrams, Failure Mode Effects Analysis, and other tools of the trade.  Not to mention the data analysis, simulation, optimization side of things.   Most of what I hear about ACM sounds like tools of the trade people have been using in BPM projects for quite some time (which is why, to me, they aren’t that differentiated).

He also has a nifty graphic:

And he’s right, when he makes the point that the arguments about BPM and ACM often sound like mutual exclusivity – only one can be right.  But I think the argument between these advocates is more along these lines:

• ACM proponents: ACM is different and separable from BPM as a method, and (less consensus) a tool set. Corollary: the language used often implies it is just better and more important than BPM.
• BPM proponents:  ACM is fine. But it is clearly one of the tools in your BPM tool belt, rather than its own distinct and separate market (tooling), and methodology.

It is easy to mistake the first group’s arguments as saying BPM doesn’t matter, or that ACM is “the only thing”.  Clearly it does matter, and the staunchest proponents of ACM will also say and write that.  It is easy to read the second group’s arguments as saying “BPM is the only thing.”  But the argument is a bit more subtle, it is just that BPM is the umbrella in these advocates minds.  Maybe this is consistent with “BPM is the only thing” – but only because the BPM proponents likely have a more flexible notion of “what is BPM” than the ACM group.

Finally, we see this from Kraft:

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system.

I think Mr. Kraft is essentially correct, and most people would benefit from adopting some kind of funnel, just as he describes.  However, there are two small issues, which don’t detract from the main point he’s making – but the inconsistencies between these layers may not be obvious in a casual read, while they do affect how you approach the funnel:

1. ERP is a tooling (or software package), without a methodology.  In essence, the “methodology” is to standardize on a big software package.  That may also include giving up on differentiation, but it doesn’t have to.
2. ACM and BPM “methodologies” can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
3. As a result, the transitions from one layer to the next have different degrees of friction with your IT and Business groups.

The funnel itself makes perfect sense.  In fact some of the customers and IT staff we’ve worked with prioritize their process work this way: by forcing new project ideas to go into the funnel starting with a fairly loose “ad-hoc” definition, and only with volume does it move into the more structured definitions more commonly considered “BPM”.

As usual, a strong contribution to the body of thought from Mr. Kraft, around ACM, BPM, and Taylorism.

No related posts.

The answers were pretty interesting.  I guess I should first own up to my own:

Short answer : no.

More thoughtful answer : When people have trouble listing which products are ACM, and which are BPM, and which are both, the “ACM” tag has some work to do to eclipse BPM. Even as it grows, it is perceived as part of BPM, not separate.

Of course, BPM took a decade or more to come into its own. I don’t think it comes undone overnight.

Related posts:

1. It isn’t BPM: It’s Competition
2. Business is only as Simple as it is.
3. About that Merger…

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the ‘whole level of detail’ issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

So true.  BPM depends upon building the right abstractions for your business, and business processes.  Getting to the right level of detail (rather than the lowest) allows us to build solutions at the right level.  When you see flowcharts covering a wall (or more than one screen in Visio) – the yellow flags are waving.  Slow down, caution.

Related posts:

1. Context can Simplify Your Process
2. BPMN 2 Examples Courtesy of Camunda
3. BPMN Training, Bruce Silver Style

1. Come up with an idea for a product that you think people will want, but you don’t see satisfactorily provided to the market.  (ideas are often for art projects or music albums, not just consumer products like this)
2. Build a prototype and put together a pitch video to sell the idea
3. Do the research to figure out how big a production run you need to do to make the object “affordable” (whatever that means for what you are pitching).
4. Put your kickstarter project page together, including a fundraising goal that supports your minimum requirements.
5. Wait to see how many people and $ show up to support your project.
6. When (if) project funds, get started building the product (or producing the benefits the contributors are entitled to).
7. Ship it.  If it sells well, consider selling more of the product online, knowing that you now have won over an early adopter fan base.

It favors small production runs, prepaid by motivated customers.  The magic is that you don’t put capital at risk until buyers have paid (up front!) for the product.  It is a great way to get pre-commits from a motivated community. And to my way of thinking, this is just a new (and better) process for finding demand when you don’t have the capital to “build it and hope they come.”

If we relate this to the Lean Startup, or specifically to Steve Blank’s incarnation the Lean Launchpad – one of the key tenets is to “get out there and talk to customers”.  Moreover, to find paying customers.  Not just customers who say they will buy it, but customers who will literally write checks to you.

And when they do this – in great dollar amounts or numbers of customers – then you move into production. Kickstarter gives the product team a chance to do this with physical goods in a way that was nearly impossible 10 years ago.  It also allows an innovative team to address niche demand in a way that they previously couldn’t.  In the same way that eBay allowed people to find markets for niche products, so does kickstarter – in one case auctioning used goods, in the other case contributions toward products that don’t yet exist!

This moves physical products into the realm of a process that looks like:

1. Design
2. Sell
3. Build

Which is much more capital efficient than

1. Design
2. Build
3. Sell

As it allows for less waste (building products that no one wants- akin to getting the requirements wrong in software and BPM projects).  And it allows for some feedback loop between design and selling, before moving into the build phase.

It feels like something that could be truly transformative for small business product development.  I have several friends in the business of producing physical objects for sale (furniture, productivity tools, gadgets), and I’m telling all of them they have to try this process and see if it works for their business, and reduces the risk for them.

As a buyer, the other thing that is really fascinating is the exposure to the process, or craft, behind the production of these objects.  The videos and written updates about the procedures are quite educational.  As a process guy, I see it all through the lens of repeatable process with, typically, an irreplaceable human component.  Gratifying craftsmanship.

Related posts:

1. #IBMImpact: Introducing Complementary IBM products to Lombardi customers
2. Improving the Process for Teaching Entrepreneurship
3. A Process is only as Simple as it is

Well, we know Steve Jobs was not a big fan of the stylus.  And I’m happy Apple didn’t design touch interfaces that required them.  But like many others, I still want to be able to draw my ideas on an iPad with more precision than my fingers will allow.  There are a bunch of these products on the market now, but at the time the kickstarter project for Cosmonaut was kicked off, I hadn’t seen one that didn’t look cheap yet.

Marco Arment has done us all the favor of reviewing the Cosmonaut – “I’ve tried a lot of iPhone and iPad styli, and I haven’t liked any of them before. But this one’s very different.” and also trying out lots of other products.  I haven’t personally used any other stylus for the iPad, but I agree with Marco’s general sentiments:

• First, that the packaging is excellent, and nice branding to boot.
• Second, that the wide grip of the Cosmonaut is a big advantage – because you really do use it more like a whiteboard marker than a pen or pencil.
• Third, that it is the first product I’ve used that actually feels good when you use it. The rubber tip requires just the right amount of pressure to register with the iPad, and glides effortlessly and smoothly across the surface (even if that surface has the sticky finger prints of your 2yo son on it).
• It exudes quality.  And since we were part of the kickstarter project, we know why.  The creators were meticulous about finding the right materials.  They switched manufacturers more than once.  Getting the right grip, the right aluminum core, and the right tip were all quite time consuming (to, I think, the frustration even of the creators).

Choice quotes from Marco’s review:

There’s no foam anywhere in it. The soft rubber tip gives slightly when pushed, because there’s a small air pocket between it and the solid aluminum core.

and:

It doesn’t feel like a brick of solid plastic writing on glass, and it doesn’t feel like a flimsy sponge on a stick. It feels like a marker, as designed.

I forgot to bring it with me on vacation (I switched laptop bags) and I’m actually annoyed.  I was hoping to try out additional drawing applications. I’ve used penultimate and a few others. But the feature I really want is an “infinite” canvas, or at least a canvas much larger than the screen.  That way I can use rough handwriting with the stylus, then shrink the whole thing down to fit on a screen and reduce to “normal” writing size.  Hopefully I can find an app that does this without too much trouble – it would make a perfect companion to the Evernote note-taking app (though truly, I wish Evernote would just solve both problems… a rare case where you want the app to do two things well, rather than just one).

At the end of the day, the team at Studio Neat worked hard to produce something that looks deceptively simple.  It just looks like a rubber stylus.  But it has the right heft, the right feel, the right size.  It takes a lot of work to produce the right, simple, product.

Good news, you can now buy your own here.

No doubt the Cosmonaut will come in handy for me when I need to sketch an idea or process while attending a meeting.  But my daughter’s first contribution to the blog is a bit of artwork… what surprised me is how much better it is than what she usually sketches with her finger, and the process she used to draw it.  First she colored everything blue, by hand (she could have done this by changing the background color, which I’ve seen her do before… she told me she liked the texture).  Then she drew the clouds and flowers on top… green shoots first, then flowers, then a bit of yellower grass at the bottom.  This is a process that works much better in software than it works with pen and paper, though you can do something similar (with some mess) with crayons.  But try drawing white on top of blue in almost any medium – it doesn’t work too well!  Her work is already better than some of my process drawings!

Related posts:

1. A Short Hiatus, and Some iPhone 4 Thoughts
2. Quick Review of “Social #BPM”
3. Sandy Kemsley’s Review of Metastorm M3

As in business, BPM projects either produce or fail. And, in varying degrees, BPM honestly tries. Maintaining net-value is an effort of direct participation. To remain relevant… one must keep up with the pack – speed counts. This demands agile, quick development iterations and, consequently, a serious weaning from project fat.  Cutting corners gets us ahead of the game. Knowing when, how, and which ballast to cut throughout keeps us in the game.

Evolution

Focus on the relationship between software development methodology and business success.

The catalyst behind change is our drive towards increasing efficiency. The tools and methods behind process management effectively short-circuits communication channels and re-wires the organization. Brought into focus are traditional gaps in execution between business leaders and software development. Otherwise impeding the flow of evolutionary progress, and spotlighted for what they are, progress forces its way around unnecessary bureaucracy.

Obvious like highway congestion and air-travel delays – we need change. It’s our impatience. It’s nearby, within reach, and forces itself as matter-of-fact: keep up or be left-behind.

A Spotlight on Bureaucracy: Tradition

“There are protocols that must be followed, regardless of their cost or waste.”

Let’s take a look at a more traditional methodology.

The Business Owner communicates values to our Requirement Analyst who, in turn, produces documentation which is then, in turn, handed over to the Process Architect.

Process models flow into software which then become rooted within operations via services (SOA) and general integration architecture.

The “playback”, or software demo’, provides a theater where our Business Owner communicates direction back into the next cycle. Iterations repeat until we find usability.

In theory we have a fairly good working methodology. In practice we do not.

Short-circuit Communication and Evolve

No barriers. No handoffs. One team.

Our new model has the Business Owner working directly with the Process Architect.

Reasons:

• Direct communication between Business Owner and Process Architect is simply more efficient. This efficiency produces working, executable process in a fraction of the amount of time that would have otherwise been spent on traditional, time intensive, requirements documentation and review cycles.
• As business feedback (aka requirements) now flow directly into development there’s neither room nor slack for misunderstanding.
• Reduction in administrative overhead (requirements documentation) allows shorter iteration cycles and early delivery.

Business Value

Work occurs with the immediacy of market conditions.

Value-driven methods and purpose force efficiency. From the Business Owner’s perspective, “value” is executing process:

• Strong User Interface
• Valued Process Outputs
• Supporting Services
• Shows Strategic Direction while supporting tactical agility

We now understand the nature of process development. BPM projects DO NOT build systems because “systems” lack context – technology isn’t the point. The effort behind building “systems” is as irrelevant as attempting to build a house before its blueprint… more so even before understanding the intended home owner’s perspective. The best approach then is to isolate our system builders – take them out of the picture.

Irrelevance

Those who once lead must now follow

Removing system builders removes distraction. Without this distraction we’re able to maintain business alignment and, consequently, remain focused on business process development.

So what does a roomful of system builders do when left on their own? They build an irrelevant system.  Frequent the result of specialized teams is competing effort – things created, with good intent (we hope), that offer much less support as interference.

We’re left with a dichotomy.

Our goal still focused on business process and yet diplomacy plays in as a key strategic requirement? Though completely outside the scope of process development, “change management” (politically correct term) is none-the-less required.

Rebuild The Team

NEXT WEEK’S PREVIEW…  (to be continued)

The best solution here is to break these specialized teams apart and reassemble as cross-functional units (aka “pods”). We keep our specialized skills, such as QA and integration, while maintaining orientation on process development.

As a BPM effort we have “process” goals on our plan. Competing milestones no longer receive management’s attention. Goals become aligned and focused on process development iterations.

Related posts:

1. Great session on Change Management at Gartner BPM Summit #BPM11
2. Keith Swenson, Software Architect
3. Will Open Source Software Meet the Challenge? Activiti Enters the Ring

Along those lines, Dave Brakoniecki tackles the idea of “inverting the process life cycle“, in response to a post by Keith Swenson on the subject:

Imagine a patient file or case. This is a favorite example in the ACM space since the expertise of the doctor defines the process or work to be completed. How useful to the doctor is a case management tool that has no information on the patient and no ability to schedule tests? Not very – all of the work would need to be done outside the tool and duplicated in the tool. Still, building integrations to the patient records and to the systems that organize blood work, for example, would be better done at design time than run time.

Even if this was possible at runtime, few doctors would be interested in doing it.

(incidentally, I think this is why something like IBM Watson is getting good airplay in medical / healthcare circles.  It has data and context on a subject domain)

So, a lack of preloaded or pre-integrated data seems like a problem. But supposing you have this pre-existing data, there are a small number of firms prepared to help you discover the processes you are already executing without realizing it.  It isn’t yet clear to me how big these services projects are (there aren’t any shrink-wrap solutions that require no services).

And Dave points out another issue:

In most organizations, what is problem with their Sharepoint deployment, their Lotus Notes application or that little Access database application they wrote three years ago? In almost all these cases, the problem is the same. End users were given a powerful and flexible tool without training and ending up building a system that is impossible to maintain but essential to the business.

I have seen many successful projects start from this position: The end users actually asking for more help in managing the technology so they can spend more time doing their jobs.

This is summarized nicely as “the Sharepoint Effect” in a previous post on this blog.  And I agree with Dave – many projects start exactly this way.

Then Dave gets into what might be an example of ACM in the wild – Basecamp.  Although it doesn’t bill itself as an ACM tool, one could argue that it is one, by accident.  In which case:

Perhaps the most important reason for the ACM camp to try and adopt a solution like Basecamp is that it would give them immediate mainstream legitimacy with tangible customers who have already inverted the process life cycle and will do it again next week. It probably also indicates the delivery model and price point required to disrupt the markets they are targeting.

I’m not sure the ACM vendors are prepared to be at those price points, however.

Keith makes some interesting points in his original post, not all of which are argued by Dave.  Certainly measurement before improving is A Good Thing.  We’ve been implementing “shadow processes” and listening to processes implemented in other systems for years, and using that data to inform our new process models.  But because we’re listening to real systems, we have to implement the broadcast or listening of those interesting transitions in the systems of record.

In short, there’s no magic bullet. But you can certainly do better by measuring twice and cutting once, as they say.  But we can do better than that. We can measure any number of times, and we can get more than one “cut” at the new and improved process by leveraging A/B testing to determine what actually produces the best results.

Related posts:

1. White Space & The Dark Matter of BPM Delivery
2. BPM Could Save Your Life
3. It isn’t Black and White, Can or Can’t

We use BPMN all the time in our projects, but we do a lot of process implementation projects, and it is a good fit for the tooling we use.  Craig makes a good point about someone not understanding BPMN precisely – but at least BPMN has a precise definition – unlike the usual whiteboard drawings.

I like to get on the whiteboard and build out the diagram and explain and talk as we do it.  By seeing and hearing the build-out, there’s much less chance of confusion about the interpretation.  And when you’re done, the diagram is actually accurate for someone who reads it “after-the-fact” if they know BPMN.

Having said all that, BPMN is a means to an end.  It isn’t the goal, it is a tool.  There are other tools and in the right time-place each one is useful.

Whenever there is a standard there’s inevitably a bit of back-lash against the standard from experts – almost as if it is a badge of honor to buck the industry standard.  I say this knowing full well that I’ve done it before myself!  But with experience comes a little wisdom and perspective and I don’t hand out badges of honor for either obeying doctrine or bucking it.  The badges of honor come for delivering great results.

BPMN isn’t perfect.  In fact, to misquote Churchill, it is the worst form of process modeling that has been tried… except for all the others that have been tried from time to time.

Related posts:

1. EPC vs BPMN?
2. Don’t Take My Word for it: Jakob Freund says BPMN Works!
3. Sandy Kemsley Reviews Bruce Silver’s BPMN Training