Jiasundar’s post on Google Wave finally turning out the lights reminded me of our own attempt to collaborate on a blog post via Google Wave. We got reasonable far with it but ran out of steam – I think partly due to some of the very shortcomings Google Wave started with.

Basic issues of connectivity – very few of our colleagues had Google Wave accounts.  We couldn’t trivially add them even if they were Gmail or Google Apps users already.

Basic issues of control – once someone was added to a Wave you couldn’t remove them.  And anyone could add someone.  That kind of permissiveness actually reduces sharing.

Minor issues of control – the Google Maps mashup was promising.  But I found you couldn’t control the location and sizing of the map presented – to show a specific region, at a specific zoom.  Pretty well defeats the purpose.

Overall the service raised the question – if a tree falls in the woods, but no one is there to hear it, does it make any noise?  If collaboration happens in the Wave, but no one is there to see it, does it still make progress?

Ultimately Google Wave failed more because of a lack of discipline and will than because of any specific technical or usability hurdle (I’m not aware of anything that couldn’t have been fixed).  It would have made for an interesting mashup with BPM, as SAP’s demonstration of Gravity showed.  But it needed to mature before it would be appropriate for an enterprise setting.

Jaisundar recaps the BPM community’s reaction to Wave – which I would characterize as initially one of panic in some corners, but I wasn’t too concerned personally, for this reason:

It isn’t really Google’s intent to build a BPMS.  They don’t think of the problem Wave is solving as a “process”.  As a result, they’re unlikely to take it in that direction.  I don’t think you end up with a good BPMS my accident.

Intent matters.

IBM has released a new update to BlueworksLive, on December 17th.  We had a preview just two days before it went live to discuss some of the thought behind the features. What interests me isn’t just the outcome but the thought and direction behind it.  Once again the specific features seem “small” but have interesting consequences and implications.

Starting with the shorter topics first:

The Word Export is much more pleasing to the eye than previous versions.  Having the graphics of severity and the diagram itself exported are a big help to the overall readability of the document.

The expand-all/collapse-all functionality in the Process Diagram is also convenient – especially when prepping to export a large diagram.

The BPMN export API works as advertised.  This is an important step to allow people to use BlueworksLive without feeling locked in.  After all, in a cloud “rental” model, one of the big fears is that your data is residing on someone else’s servers.  IBM needed to provide a clean way to get at that data and make it portable.  Not to mention, this lets customers apply some of their more standard SDLC to their requirements production in BlueworksLive.

First, there was quite a bit of attention given the Decision Discovery feature added to BlueworksLive.  I’d heard that this was coming, but I was picturing it as something that would be added to the automation features of BlueworksLive – I should have realized that the “Discovery” in the name implied that it would be part of the modeling (“Blueprinting”) part of the product.

The premise is that you set up a few Considerations (one or more).  The combination of these considerations is like a truth table.  However, BlueworksLive also lets you provide more than one conclusion – which is nice.  When modeling, we can label the column headers smartly, allowing the contents of each cell to be concise and simple (Yes/No, >$500/<$500, etc.).  Finally, we can label the conclusions well- “Adjustment Required”.  If we have more than one conclusion, it gets its own column to keep ideas separate.

A couple of surprising perks:  you can reorder columns and rows with a simple drag-and-drop.  Look, this makes sense given the point of the tool – flexible discovery of decisions.  But this is the kind of fit-and-finish often missing in enterprise software.

I also appreciated that they thought through why the cells should be free-form rather than constrained to integers or strings or a particular data type. The goal is to leave discovery unconstrained.  Plenty of time for constraints when you move into modeling for execution (had this been targeted at execution, you can bet there would have been tight treatment of data types).

Like David Brakoniecki, I think BlueworksLive is showing that it will live up to its promise as a BPM discovery tool.  Not because it does everything it needs to do today, but because IBM have shown that they’ll keep turning the screws until they get there.  His take on the impact of tiny changes at this point in the maturity of the product:

Now, at the push of a button, the process documentation and process diagram can be exported into a single word document. Basically, this document becomes the high-level scope of any potential BPM deployment or process improvement initiative. All of the great power of Blueworks around social collaboration and process discovery now can painless produce a document to playback to the client or business teams for review and iterative improvement.

SaaS products really emphasize the benefit of incremental improvement.

Gary Comerford:

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.

Yesterday’s post on the Cosmonaut has me thinking about how new products are developed and released into the wild.  We focus so much on startups and processes in the software and virtual world, but Kickstarter has exposed a new process for physical products:

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.

(Editors note: this is part product review, part examination of a new process emerging)

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!

According to Naval, we’ve got the problem all wrong:

“There isn’t a shortage of developers and designers. There’s a surplus of founders.”

He makes a compelling argument as to the “why” :

The cost of starting a company has collapsed. It’s now just (minimal) salaries. For entrepreneurs, desks are free, hosting is free, marketing is online, and company setup is cheap.

Raising the first $25K for product development is easy – join an incubator. Raising the next $100K is easy – investors are following the incubators with automatic notes. Building a product and launching a product are easy – develop on Open Source Stacks, host on Amazon, launch on Facebook, Android or iOS, get your early traction.*

Getting real traction is hard. Raising millions of dollars is hard. Building a sustainable, long-term company is hard.

Basically, he makes the point that if you’re pre-traction, you have to expect to give up a lot more equity to grow your company than if you’ve already got traction.  In the microcosm of the overall market that I see, in professional services, you could easily argue the surplus of founders argument. If you consider all the individual contractors as “founders” that haven’t gotten traction yet.

We’ve always felt that it was important to hire people who valued being part of a team, and building something bigger than themselves.  Being part of a team enables us all to execute at a higher level for ourselves and our customers. It makes it easier to take a vacation and still sleep well at night.  It makes it easier to get health insurance.  It is a long list of benefits to being part of a firm.  Including, building value that is sustainable even after the point when you’re ready to move on to another phase in your life. For builders, this is an attractive proposition.

Lots of good economic news in the city of Austin lately.

• Formula 1 is back on track.  There’s some debate, locally, about the value this has for Austin’s economy, but it is clearly a net-positive for the next 10 years.  Perhaps not coincidentally, a couple of new hotels are scheduled to be built downtown over the next couple of years.
• The Samsung plant in Austin is producing the A5 chip for Apple.  This was a massive investment from Samsung in local infrastructure ($3.6B).  Those of us following the news in Austin a few years ago probably recall what a close decision this was for Samsung.  It was the biggest investment in chip manufacturing capacity since the heydey of silicon in Austin.  These days, Austin is more of a hotbed of design than manufacturing.    As I understand it, Austin is Samsung’s second largest infrastructure investment – and the largest outside of South Korea.  People often forget how much is manufactured in the US in general – but this kind of high-tech component is particularly unusual to be manufactured onshore.
• Austin is attracting more early stage investments than other parts of Texas. $280M in Austin alone last quarter.  Fifty Austin companies received funding.  This reminds me of the 90′s in Austin.  There have always been complaints about it being much harder to raise money in Austin than in the Valley, and perhaps it is.  But it clearly is easier in Austin than it is in many other parts of the country.
• It looks like the “best performing cities” are moving to Texas…
• The unemployment rate nationally recently dropped to 8.6%.  But in Texas?  8.1% (down .3%).  A half-point better than the country as a whole. Austin, however, is a full point lower still, at 7.1% – 1.5 points lower than the national average.

So it appears to be a good time to be bullish on Austin.  But if you’re just now noticing, you’re late to the party.  All through the downturn, it seemed clear to those of us who live here that Austin was building up, slow and steady, a diverse and growing economy.  I’m looking forward to going to the Angelou Economic Summit in January – there are typically some key insights into how the local economy has been performing, and this year should be particularly interesting.

Eric Jackson of Forbes recently wrote the Top Ten Reasons Why Large Companies Fail to Keep Their Best Talent.

The article lays out some very good reasons why top talent gets frustrated with big companies. But the focus is still too much on secondary effects.  My thoughts on a few of the points:

#1 : Bureaucracy. “No one likes rules that make no sense. But, when top talent is complaining along these lines, it’s usually a sign that they didn’t feel as if they had a say in these rules.”  Actually, there are just too many rules.  Big companies have the resources to actually have bureaucracy that makes the lives of top talent easier, not harder.  But they don’t take advantage of that capability, because it shows up as a hard expense that can be cut.  When the economy is strong you see startups and smaller firms offering free dry cleaning or laundry service (or if not free, convenient in-office pickup).  There are free meals and caffeine at the office.  This is convenient for employees and saves them time out of their lives.  But for some reason most companies cut back both on the perks, and on the benefits of large size, as they get bigger.  Instead of requiring employees to fill out a lot of paperwork for expense reports, make it easy for them to send in their expenses and pay lower-skilled labor to process them.  Or set policies that require fewer receipts for reimbursement and thereby reduce the total bureaucracy.  Use per diems.  Have a travel group that adds value in booking and rebooking flights and hotel reservations.  Have administrative help that helps produce critical paperwork without a lot of barriers to entry and TPS forms to fill out. These are trivial examples, but wherever you can reduce the exposure your team has to bureaucracy or administrative work, the more productive and happy they’ll be.

#2 : Finding the right project.  “they usually don’t have people going around to their best and brightest asking them if they’re enjoying their current projects or if they want to work on something new…” This item in particular seems hopelessly vague.  It almost sounds like the idea is that the top talent shouldn’t have to do any of the tough, dreary projects.  Who wouldn’t want to opt out of the project that takes them to Ottawa in the winter? (No offense intended, Ottawa!)  But there’s a kernel of truth within this point:  big companies have really interesting jobs to offer high performers.  But they (typically) don’t.  Those top performers aren’t afraid to ask for a better assignment or put their name in for promotion.  But they’re told they have to wait – “we don’t promote someone twice within one year.”  Or “you can’t get a raise of more than 3% a year”.  So they realize that to move up, they have to get some experience and then move out.  Possibly getting hired back in later on.   It isn’t that no one gets these fast-track promotions and assignments at big companies, but the percentages are vanishingly small.  The top 1% not the top 10 or 20 percent.

#3 : Poor Annual Performance Reviews.  “You would be amazed at how many companies do not do a very effective job at annual performance reviews.”  Actually, no one with a job would be amazed by this.   Performance reviews are a broken process at nearly every company I’ve heard of, let alone worked at.  There are companies trying to fix that, like Rypple (now part of SalesForce), but the fix isn’t actually about annual reviews.  The fix is more feedback.  Reviews are largely a waste of time, and condescending to the employee.  The employer or manager sits in judgment and the employee is judged and much good feedback throughout the year is saved for an annual review instead of happening spontaneously.  The Annual Review becomes a marker around which unrealistic expectations get set – employees expecting golden reviews and promotions, employers disappointing them with perhaps neither.   The review process can make employers look quite petty.

So what’s the fix?  When you have negative feedback for an employee, tell them right away.  Tell them what they’re screwing up.  While they can still do something about it.  When they’re doing something great, tell them quickly, while it is fresh on your (and their) minds.  Make sure other people hear about it so that good behavior becomes infectious.  We don’t do “reviews” at BP3, but our team communicates.  They can call to talk to me anytime, and I don’t hesitate to hit them up on Instant Messenger or the phone.  We don’t do raises on an annual schedule, we just do them when we think the timing is right.  We do regular bonuses which force us to acknowledge good or bad performance monetarily, in case our words – spoken and typed – aren’t getting the message across – good and bad.

#4 : No Career Development.  Well, this is actually nearly impossible in small companies to do in a structured way. The promise a small company can hold out is that as the company grows, opportunities for employees will grow as well.  A lot of the career development is personal growth and attacking ambiguous problems (filling in the white space).  At a large company, I’d recommend managers talk to their top talent about their own aspirations for those people.  What do you want to help them achieve?  Don’t expect them to come to the table with an answer when they may not have a sense of what is possible.  But experienced executives and managers do know – and can help lay out a path or ladder that actually motivates talented people. But keep in mind, there are always some people who aren’t motivated by a ladder, or competition.  They’re good at what they do, and they know it, but they don’t care about your external validation of that performance.  These are the toughest people to keep happy on a purely professional basis.  If you have one of these high performers on your team, make friends.  Friendship and loyalty may be the only thing that keeps you two working together. And someday you may want to get a job working for them instead of the other way around!

#5 :  Shifting Whims.  “The challenge for most organizations is not setting up a strategic prioirty, like establishing an incubator, but sticking with it a year or two from now.  Top talent hates being ‘jerked around.’”  Well, this one is spot on.  What’s worse than not having a good recruiting program?  Setting one up and then stopping it 3 months in.  It takes time to recruit the right talent, develop a talent pipeline that works.  When you shut it down for more than a week or two, starting up again takes another 3 months or more for the pipeline to pan out.  You’ve lost all the momentum.  Having the rug pulled out from under something you’re excited about sucks.

#8 :  The Missing Vision Thing.  This one can be hard when you’re smaller.  It is helpful to have a humble or modest bearing in general.  Under-promise, over-deliver.  But as you grow, as things start to fall into place, you can share the vision with your early conspirators (your team!).  Eventually you step out and communicate with the world at large.  The same approach works well for team-level vision at a company.  But big companies can have bigger visions of how they’ll change the world or the landscape.  Then the real trouble coming up with something that is expansive without sounding too trite or generic (I don’t have to name names, we can all think of a few in this category).

It is just a matter of using your size to your benefit, and to the benefit of your top talent.

Editor’s note: this is a repost of Gary Samuelson’s post of the same title on his own blog, found here. 

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.

There are lots of arguments for and against Apple’s integrated approach.  As I recall from economics and watching certain industries, there’s an efficiency to horizontal scaling of an industry. But, we’ve seen the design benefits of the integrated approach with Apple.

But if you’re trying to put products into consumers’ hands, or customers’ hands, there’s a cost to depending on horizontal layers of industry to delivery much needed components into your end-device or product.  The risks are manifest in RIM’s reported results this quarter:

RIM just announced on its earnings call today that it won’t be ready to release new smartphones running the QNX-based BlackBerry 10 OS until late 2012.  [...]

Co-CEO Jim Balsillie said the company is waiting for new chips that will allow RIM to make dual-core phones with LTE. Those chips won’t be ready until late next year.

So… the phones were first late in the upgrade cycle, waiting for the work to get software ready on QNX… then they were later still waiting on dual core chips (as of early this year).  Now they’ll be an additional year late… because they’re still waiting on dual core chips.

Of course, one wonders why they can’t release these phones with 3G and dual-core chips.  Seems to work okay for Apple.  Maybe it is just a smoke screen.

But if it isn’t, it is a cautionary tale against building product plans against moving targets.  Don’t assume another vendor’s components will be there for you unless they already exist or can be produced in volume today.  Apple’s approach to getting deeply involved in the supply chain pays dividends by helping avoid these kinds of public delays.

(So does not announcing a product release until you are, you know, actually releasing a product)

It isn’t easy to fill in the white space.  It is harder to design a good software solution from scratch than to fix a bug in an otherwise working solution, or to design a small addition to a working piece of software. What if you could have tools that just help you right away, and then later infer the process (filling in the white space for you)?  That’s the promise of “process mining”.

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.

Peter Schooff of ebizQ asks: “How big of a role does BPMN play in today’s projects?” And the responses were interesting to me.  Most of them took the line that BPMN isn’t that important, or that they don’t typically use it.  That someone who fails to understand BPMN will fail to understand the process, just as surely as you might get false agreement in a process by being vague in its description.  My response:

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.

Jim Sinur weighs in with a blog post that supports a point I’ve made before:  that companies who aggressively acquire other companies use standard processes to make it work.  Take this anecdote from Jim:

This success snippet is about an organization in the insurance industry that has experienced significant top line revenue growth while simultaneously increasing it’s net profits over 40%. This company uses BPM for aggressive acquisitions by leveraging standard processes with local variations while driving down overall costs on a large scale.

Not only do they use standard processes to acquire and assimilate, they use standard processes (with local variations) for their core business functions, which the acquired companies will also participate in.

It actually doesn’t matter if this is defined as “structured” or “unstructured”, knowledge work or routine work.  The world will look at this and likely call it “BPM”.  Because it is about managing business processes. And this is why the arguments among experts about naming are really a bit off-point.

As Jim Sinur says – the success of BPM is spreading and is too big to ignore.

Analysts were predicting more consolidation in 2011, and it looks like the late-year acquisitions are happening again.

First, doc capture specialist Kofax has acquired Singularity, a BPM and case management provider.  Kofax has been part of many a BPM project, whether they realize it or not, as the doc capture element.  Almost every BPM project needs that transition from “physical world” to “electronic bits” or “process world” – and document capture is a common entry point.

Neil Ward-Dutton, of MWD, comments:

In a call first thing today, Kofax CEO Reynolds Bish highlighted that he expected the acquisition to double the size of the company’s addressable market – in large part through the expansion of sales coverage and effort for Singularity’s products, which Singularity itself had largely confined to the UK.

In other words, Kofax expects to expand the reach of Singularity, as well as of their product set itself.  Interesting, to me, was that Singularity’s revenue mix was 50% services, and that Kofax intends to adjust that downward.  Good news for Singularity partners or services experts.

Meanwhile, in another corner of the BPM world, Progress has acquired Corticon, a pure-play rules management (BRM) vendor:

Progress is pitching Corticon as a crucial ingredient as it continues to develop its RPM story, and this makes sense. Progress’ Savvion BPM technology already had a fair business rules capability (BizRules) as an integrated component, but my view is that Corticon’s technology is more widely-applicable, as well as being widely acknowledged for a very strong ease-of-use story, enabled by its heavily model-driven and graphical approach to rule specification. Its open stance towards rule management repositories will also serve it well, as Progress seeks to blend Corticon’s tools into broader capability mixes.

In a previous life, we used Corticon for rules for a while.  We didn’t find it particularly compelling and ended up writing our own, similarly non-compelling rules solution.  More often than not, customers would use ILOG or Fair Isaac or Drools. But it has been several years now, and no doubt Corticon has made some progress in that time (pun intended!) on their rules capabilities.

The conclusions I’m drawing from these acquisitions:

1.  BPM and Rules are a natural combination.  BPM seems to be the value driver, as it is the rules vendors getting gobbled up.

2.  BPM and Content Management or Document Management combinations are also happening.  But the major BPM vendors have (largely) already purchased Doc Management or Content Management solutions… So the remaining players in these spaces are forced to go pick off the weaker BPM vendors instead (OpenText acquired two of them, Lexmark acquired Pallas Athena, and now Kofax is in on the act).

3.  There’s still a lot of shakeout to occur in the market – and execution at a detailed level for each vendor is really going to matter.  At this point it isn’t all marketing fluff – real differences in product are apparent.  But the target keeps moving.  A well-integrated solution that is coherent to the end-user is going to win the day.