I wanted to comment on MWD’s blog post to this effect but since I can’t get logged in there, I’ll just put the information here and hopefully it will get picked up by trackbacking.

MWD points out the risks that were observed in the CloudCamp session attended:

IT practitioners – They’re likely to have concerns about the ultimate impact on their jobs and the potential of Cloud to take power away from the IT department. Uncertainties regarding processes around platform change management and dependencies. Concerns about security. Concerns about integration, latency and lockin.

There is a new approach to some of the security, provisioning, etc. issues which is represented well by Conformity.

Neil/MWD, check out the Conformity Executive Webinar Series: The Enterprise SaaS Working Group, or check out their blog on the subject here.  This is a group of leading lights in the SaaS community talking about adoption challenges and approaches.  Hopefully there will be a playback afterward for those who miss it the first time around.

Ok, no, Xerox isn’t a BPM company in the traditional sense – they’re not selling BPM software.  But, I think Xerox has reached the conclusion that the process is their product.  And once you realize that, how can you not argue in favor of the acquisition of ACS, which does a lot of BPO (business process outsourcing) leveraging Xerox equipment, software, and technology.

As Craig Le Clair of Forrester points out:

And speaking of capture, XGS would become the largest outsourced capture provider. Of all the ITO/BPO players, none did as much for that inbound channel as ACS. We estimate about 1B of ACS’s revenue could be classified as in-bound capture. But that’s just part of this story.  A strong ITO channel like ACS will help push XGS’s already fast growing Managed Print Services business.

This is a classic BPO play on managed print services, and getting bigger scale makes it more likely to work.  Back in the mid-90′s Xerox was a customer of my employer, and I worked on some very innovative projects for configuring extremely complex printing solutions (networked solutions) leveraging Docutech printers.  Even then, it was clear that the world of printing was going to change one way, or the other (or both):  either professional color printing would become dramatically less expensive (it did, or at least amateur color printing did), or professional printing would be increasingly outsourced.  Why the latter? As fewer companies could justify spending the capital to own the expensive print equipment during tight times, or because of smaller printing demands (more and more documents going online and onto CD’s), it would make more sense to buy printing services “on demand.”

This looks like a giant step in the direction of consolidation of managed print services, and other BPO services such as inbound capture.  I can’t speak to the pricing of the deal, but I feel like this is probably a very good business for Xerox to beef up.

I sat in on a presentation recently that really impressed me.  It was the head business SME presenting the results of a 14-week BPM pilot to the stakeholders – executive and otherwise.  It was an impressive presentation of the process, the justification, and the benefits.  And a great job of painting a picture of what the future could look like with this process, running on a BPM platform.

It was also a demonstration that something we have long believed in really works:  putting the business in the driver’s seat.  Which means: the business gets to prioritize what we work on.  We advise them, and keep them honest (meaning, for example, that not everything is first priority).  In return, the business will get their highest priorities implemented.  But the most important achievement is that the business owns their business process, and their business process solution.

Business taking responsibility for their processes has been a theme that Phil Gilbert has often hit on in his blog and in speaking engagements.  It is a surprising (to some) message from a software vendor, but it is one that we happen to agree with.  It is something that Lance and I advocated even before we started BP3, and we’ve seen the power of that approach over and over again.

I’m tired of waiting. I think I’ve been spoiled by the pace of Web 2.0 and I’m no longer patient for each major release of enterprise software.

In a world where we can receive application updates to SaaS applications daily, weekly, quarterly, I’m tired of waiting for enterprise software to release major upgrades every few years.  In particular, BPM vendors, of all enterprise software companies, should know that continuous improvement is a better method than the big-bang release.  They should be embracing incremental improvement techniques, just as their customers should when deploying BPM solutions.  Why do they talk the talk and fail to walk the walk?

Every BPM vendor (every software vendor!) should read Steve Blank’s Manifesto for Customer Development. Steve Blank and Eric Ries writings should be mandatory for software developers in the BPM business.  Heck, their articles should be mandatory reading for people deploying BPM software as well.  The traditional “product development” model consists of four phases:

1. Concept / Business Plan
2. Product Development
3. Alpha/Beta Test
4. Launch / 1st Ship

And Steve Blank rips the heart out of this process:

The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

So.  Off to a good start.  So what are the problems?

1. Focusing on a finished product instead of minimum feature set.  Lots of resources are going to be wasted on features that won’t matter to customers.  Those resources won’t then be available to invest on features that DO matter to customers.  Guess what?  Software vendors have finite resources.   These prioritization decisions matter.
2. Founders or Executives hand-off responsibility for validating the vision.  Marketing and Product Management now own that, and Sales.  The founders and executives aren’t hearing directly from customers which features are buying criteria.  Founders and top execs need to hear customer feedback in order to know when the ship needs to be righted.
3. Engineering becomes so focused on their ship date execution plan, they become immune to outside input, or changing the plan, except to move the ship date further out, or cut features.

In another article, this time on GigaOm, Mike Speiser argues for the power of Continuous Improvement.  Well, he’s preaching to the choir with me, because as a BPM practitioner I’ve been advocating continuous improvement for most of a decade.  Mike argues that often the reason people (and businesses) languish at a mediocre level of performance is simple:  they lack a good feedback loop.  Without timely feedback, they can’t tell if their actions will produce exceptional, average, or mediocre results.  The learning cycle is too long to take hold.

A fantastic example of what can go wrong in a big organization:

Let’s say you’re a mid-level executive — a GM or product manager of some sort. More than likely, you’re measured by how well you interact with and present to your manager and senior executives. Consequently, you optimize to managing the bureaucracy (your boss in particular) rather than delivering the right product or service to customers. And so does your boss, and her boss, and so on and so on. Here the only thing that you’re practicing and perfecting are your brown-nosing skills. How can you expect to learn in an organization with that type of feedback and incentive system? How can such an organization, by extension, possibly produce excellence?

The most telling quote of all:

The organizations that produce excellence are those that continuously improve. The more granular and frequent the improvements, the better.

Its worth reading that one twice.  Three times.  Now.  If you’re a BPM vendor, and you have an enterprise version of your product, ask yourself if this statement applies to you, your team, your product, your organization.  You may be saying to me right now- but we’re on version 5, version 6, 7, version 10, of our BPMS – so clearly we believe the gospel of continuous improvement.  But I say to you, how long was the development effort that led to this latest version?  Why was it more than 3 months?  Why is there a “major version” at all rather than a series of incremental improvements that migrate customers from old to new?

Many of the BPMS vendors are now providing SaaS or ASP oriented BPM solutions – at least for modeling and collaboration, if not for execution.  These solutions seem to get revisioned on a frequent and substantial basis, much like the majority of web applications and “Web 2.0″ out there.  I would now like to challenge the assumption (presumption) that Enterprise software can not be similarly improved.

What’s wrong with the traditional product development model for BPMS vendors (my observations):

1. There are large sets of features that languish without improvement for many years.  A mediocre feature was introduced in 2005, it was never revisited, except, perhaps once to fix a bug in 2006.  This “feature” might be something really important to customers:  reporting, versioning, integration with salesforce, etc.  But for whatever reason it never rises to the level of interesting for Product Management, or it gets cut in the interest of making the almighty ship date.
2. There are large swaths of potential features that never get addressed, because the product development team imagines it knows what is going to sell when the shiny new release is finally released.  So, that PDF export you wish you had in product continues to be something professional services had to provide.  That import from Visio the customer wants isn’t available in your otherwise superior product, and the customer goes with another product that does this out of the box.
3. Low priority defects never get fixed.  Why fix them, when the “new release” is coming.  Wait for the new release, then consider fixing these minor things on the new release.  The problem is, the new release will introduce its own set of important issues to fix, it will take time to confirm the minor issues are still issues on the major release, and by the time those minor issues are back on the table again, the answer from engineering will be: this is too low-priority as you’re on the old release – we have a new release coming that will be the one to fix this on.  So, you spend more time waiting for the Next New Thing than you do actually treating it like the tip of your product line.

If your major versions take more than 1 year to ship, you’re doing something wrong.  And that may be generous.  How do I know that?  Apple ships new versions of an operating system every 12-18 months.  That’s a much more daunting task than a new BPMS.  Much larger installed base.  So why does it work?

1. You have to make the investment in automated update mechanisms that work. Think Windows Update, Mac Update, etc.  These programs work.  The changes they propagate have to be *contained* and backward compatible.  But they work. It puts constraints on the engineering team – but they are *good* constraints that these teams ought to operate under anyway.
2. You have to compartmentalize your updates into components or units that can be upgraded without breaking everything else.  Think Apple replacing their legacy development framework with Cocoa – something that they did gradually over the last 10 years, piece by piece.
3. Independent components imply that you have to have good API’s.  If you don’t have API’s defined between the internals of your product that you feel comfortable documenting and publishing internally and to partners, then you should develop and implement such API’s as part of every revision to your product.  API’s provide the lubrication that allows for change in your product without putting unaffected parts of the product at risk.
4. You have to respect data formats.  The data is sacred and hast to be protected.  See #3 – without APIs protecting your data, you won’t be able to change the schema without breaking upstream services.  And you won’t be able to change upstream services without breaking your data.
5. You have to believe in the evolutionary/incremental over the revolutionary.  If developers think they can depart from the past without respecting it, you will get incompatible software and unhappy customers.
6. You have to allow for individual accountability for product.  If people don’t “own” something, they won’t have the appropriate baked-in incentives for improving it. My favorite question to find out if a company is serious about a feature set, is to ask who owns it – who’s your lead developer for this part of the product?  What are their other responsibilities?  How long have they owned it?  Can I talk to them about what they’re working on now and why?  I want to understand their thought process.

I see enterprise BPM vendors talking the talk about continuous improvement.  But I don’t see them walking the walk in their enterprise software offerings.

It was just over 2 years ago that I decided to join Lance in starting BP3.  The day that I decided to take the plunge, my wife and I (along with our daughter) met with her sister at a local Chinese/Cantonese restaurant in Austin and had dinner.  We don’t usually talk about my work at dinner, but we spent most of the dinner talking about it that night. I had just decided to inform my boss for the last 4 years that I was going to leave and join Lance in starting BP3, and was getting my thoughts together for that conversation.

After a very good dinner, the bill came with 3 fortune cookies.  I opened one, and inside were three fortunes, rather than one:

“Now is the time to try something new.”

“You have executive ability. Apply this in the future!”

“Your present plans are going to succeed if you stick to them.”

Far be it from me to argue with the fortune cookies.

Its been a great 2+ years with BP3 – I couldn’t ask for a better team to work with, and I’m very grateful to the customers and partners who saw fit to invest in our success, just as we invest in theirs.

Rick Geneva has a post on the event-based-gateway, offering to demystify it.  Admittedly, this is a feature of BPMN that needs demystifying.  Having worked on the BPM certification for OMG (OCEB), I’m familiar with the event-based gateway.  And I have to say it is one of the uglier creations of an otherwise pretty good notation.

The key source of confusion for users of the event-based gateway is that the events being evaluated by the decision gateway are “drawn” on to the model after the split.  That’s not consistent with the way our brains tend to simulate the running of these models with tokens moving along paths.  And it isn’t consistent with normal predicate logic where the consequence is described after the condition rather than before the condition.

Having said that, Rick does a good job explaining it.  I’ll just add this:  far better (if you can) to design your process to receive a single event that can be interpreted, based on the data it delivers, to cause you to proceed down one path or another.  It is easier to read, just as easy for the BPM engines to process, and it goes back to normal condition-then-action ordering… (and usually yields a simpler diagram).

Recently in Sandy Kelmsey’s blog, she covered the John Hoogland keynote from Ulm on “Change in Control”.  Pretty good coverage from Sandy (as usual!) and it sounds like it was an interesting keynote.  But there are a couple of points in it that I take issue with – though I’ll allow that since this isn’t based on a transcript of Mr. Hoogland’s keynote, it could be that something was lost in Sandy’s coverage that would alter the picture.  Sandy writes:

He did a closer look at many of the vendors’ messages, pointing out the nonsense of much of the marketing speak about how easy and beneficial that BPM is. Agility in that context means that the process can be re-modeled; in fact, that’s often the only point of agility that the BPM vendors allow (although I would argue that integration of rules management creates significantly more agility without process model changes).

I would dispute that BPM vendors are only arguing that only “modeling” can be more agile – they are, in fact, arguing that the execution of the process can be altered with more agility than the present state of affairs in the IT infrastructure with legacy apps and bespoke implementation of processes. In addition, elements of the process can be exposed to process owners (the business) to modify the behavior of the process without requiring a development effort.

He then turns to the fact that process is deployed within IT infrastructure, within the context of these existing applications – and that that, in and of itself, precludes agility.  Well, certainly one can imagine processes being more agile without the heft of these legacy systems or existing infrastructure- but the point isn’t “agility” measured against some absolute zero.  The question is – does BPM make you more agile than your current situation, and does that additional agility have sufficient value?  Clearly the answer to both, for most companies, is yes.

Finally he points out:

Other factors also impede agility: the issue of migrating work in progress when the process model changes, including changes to related services. The conclusion: although the vendors make process model changes look easy in the demo, it’s not that easy in reality.

Certainly these factors impede agility.  However – even moreso without a BPMS.  And while these scenarios aren’t “easy” they are much easier in a BPMS because they are actually identifiable and measurable.  (As an example, the versioning-related features in Teamworks 7 put issues like this on the front burner and directly address the challenges Mr. Hoogland is presenting).  Still, is it any wonder that software vendors make something look easier in a demonstration than it might be with production data and volumes?

Next, the complexity of process models is attacked.  At some level, processes are only as simple as they are, and no simpler (with apologies to Einstein).  However, having the right process abstractions makes them more accessible to the human mind (and specifically, to the people within the Business who need to understand them).  You have to design in a fair amount of the “knobs and levers” that you want to be able to customize after going to production, and:

This requires an explicit step during the process design to design what parameters have to be able to be changed by the business users on the fly without changing the process model (I am going through exactly this exercise now with a client, and completely agree with his assessment), and ensure that the BPMS is capable of providing those as parameters under direct control of the business.

That makes three of us.  I think in general Mr. Hoogland is trying to inspire the academic and research community to tackle fairly intransigent problems – complexity and expressiveness, agility and in-place upgrades.  He’s right to call attention and further effort to these areas – there’s no doubt they can improve dramatically over the current state of affairs.  And yet, a good BPMS already offers a clear improvement over the status quo in organizations who are not equipped with a BPMS (with room for improvement still).

Richard Hirsch of Siemens IT Solutions and Services has a post in the SAP community network about “Social BPM“.  Richard states that the goal is to present previous research, opinion, and analysis, before going on to present his own view in a future post.

Based on his ability to synthesize the current buzz around BPM and Social network features or community/collaboration features, I’m interested to see what conclusions he’s drawing of his own.

I’ve recently had my eyes opened to a theme within the Austin startup community, where companies are attacking the markets defined by the intersection of enterprise and web 2.0 ideas – applying community and social features to enterprise software, and applying cloud/SaaS business models to these software packages.  So perhaps my view on “Social BPM” is colored positive by that exposure.

This week I’ve seen a few articles at the global, national, and local level about the economy.  McKinsey has a new report out with their global economic conditions survey results.  You have to register for the report.

The key finding is:

Now, for the first time in a year, more respondents expect their companies’ profits to rise than fall in the near term. Product development and long-term planning are high priorities for many companies, and most are optimistic about their prospects in the longer term.

The general sense is that panic has receded to the background, and a new cautious optimism has taken hold.  I like the phrase used in the report – “an environment less comfortable than the one they knew in the pre-crisis world” – which is pretty much exactly the way I would phrase it for many of the companies that we work with.

Interestingly – more than half of executives surveyed support government intervention to support the various economies.  This isn’t necessarily what you would expect the survey results to show if you watch CNBC or Fox News.  As is often the case, executives’ outlook for their own companies is better than their outlook for the economy generally (this is usually true in good economies as well).

The key graph for BP3′s business was “Exhibit 4: What matters most.”  It shows that Cutting operational costs is the #1 priority for executives globally.  In fact, 4 of the first 5 priorities have to do with cutting costs and business agility.  These priorities line up beautifully with what BPM can do to improve their businesses.

Also, the percentage of respondents saying that they would decrease their workforce in the next six months has dropped from 50% or so to less than 30% since March.  Also,

Respondents from almost three-quarters of the companies expect them to be in a stronger competitive position five years from now than they were before September 2008.

There is a core, underlying optimism in our global corporations that, I believe, will eventually propel the economy forward. Of course, among startups, there appears to be even more optimism, in my judgment.  Compared to last year, the tone I hear from entrepreneurs is quite a bit more positive.

Locally in Austin, it seems that we are just starting to feel the pinch of the economic turmoil. We don’t get a lot of sympathy from other parts of the US, as the local unemployment rate has now reached 7.2%, compared to 4.7% one year ago.  But unlike many parts of the country, net job losses here are only .9%, so a significant percentage of the unemployment number is likely due to growth in the available labor force.

Statewide, Texas is at 8%, and nationally the US average is 9.7%.  As with many parts of the country, Austin’s manufacturing and construction businesses have seen a lot of job losses.

Bucking these trends, we’ve added one person to our team recently, and we hope to hire another 1 or 2 employees before the end of the year – but like the McKinsey survey results, we are cautiously optimistic and we’re being careful in our approach to growth.  The market may be favoring BPM and other efficiency investments, but investments are being made very conservatively across the board.

Chris Dixon’s blog, which I recently was turned on to by another blogger, recently opined that the only college major that matters is Computer Science.  Nice to see someone sticking up for my major!  Naturally my bias led me to believe this post was sheer genius.

Of course, let’s put this in context:  Chris is pre-supposing that you are interested in being involved with software companies.  But given that context – if you are interested in working at a Google, Yahoo, Facebook, or any of the startups they’ve gobbled up over the years, the easiest and best way in is to know how to write software. And if you’re going to do anything else for them, it would be good if you at least know what code looks like.  As Chris puts it:

Why is it so much better to learn computer science in college (or before)?  Because after college it’s very hard to find the time and discipline to teach yourself coding.  On the other hand, it’s pretty easy to pick up business skills, economics and all sorts of other skills on the job or in grad school.

He’s right.  Learning computer science requires a lot of long, uninterrupted time to focus on what you’re doing and get the job done.  There’s a reason computer science labs are open all night, but libraries typically have closing hours.  A program isn’t done til it works. That paper is done when you feel like it is done (and you’ll probably get a better grade on it).  The rigor required of proofs and code forces you to spend quite a lot of time on learning the art of coding. Very few people have the free time, or the discipline, or both, to really learn computer science well if it is not done in college, or as a kid, or as their full-time job.  And it is difficult to get a software job if you don’t know how to write code…

I think one of the saddest things is that the media (newspapers, television, blogs) have convinced everyone that all the software jobs are leaving the US.  Meanwhile, corporate America is, in some cases, helping make it so – by actually sending lots of those jobs overseas.  But in fact the total number of software jobs in the US has increased.  And, a computer science major will prepare you for more than one possible career (when I was a kid, I thought computer scientists just wrote games for a living – what else would you use a computer for, right?  So the media scare on this front is a bit overdone.

As Chris states, not everyone who majors in Computer Science will write code for a living – any more than everyone who majors in History ends up studying it for a living.  You can still go on and get that law degree, but now you’ll actually understand some of the stuff you’re protecting or litigating.

So maybe Computer Science isn’t the only major that matters – but it might be if you’re in the software business.

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.

Thanks to Michelle Greer, I found this post on Gaping Void about the using blogs to create a “global micro-business”.  The whole post is a great read about how a tailor in England used a blog to transform and improve his business.

The best part, of course, is that it didn’t require changing the product being offered.  It just meant spending the time to communicate the passion for the business that the owner had, which would generate additional interest in the value of the product he was selling.

The author makes a couple of great points about why this strategy worked. My favorites, which I believe apply to BP3:

1. A great product.  This really was one of the best tailors in the world.  Similarly, we really believe BP3 is as good as it gets for delivering BPM solutions (service rather than product).
2. Focus.  The tailor kept at it, and kept his blog focused on suits (not breakfast).  When our blog strays from the main topic (process), or our own business (BP3), we’ll try to keep it focused on topics that relate to process, but possibly in different ways than people might usually imagine (e.g. startups, Apple, etc).
3. Continuity – The tailor had it.  We have it too.  We’ve been doing BPM as long as anyone, and we’re focused like a laser on our space.
4. “We don’t have to create the brand out of thin air. We just tell the truth and the brand builds itself.”  I feel the same way about BP3.  We don’t have to come up with a great marketing pitch – our actual project stories are plenty good enough.

So, with that said, we’re going to keep focused on building BPM success with customers, one project, one program, one customer at a time.  We think the “brand” will take care of itself.

Sometimes its good to review “how we saw the world” at a given point in time.  Back in 2007, 2.5 years ago, Jerry Useem wrote an article tagging Apple as “America’s Best Retailer“.

Its still a great read to see how Apple approached retail.  And if you go look at the stats, they are dominating:

And not just the architecture. Saks, whose flagship is down the street, generates sales of $362 per square foot a year. Best Buy (Charts) stores turn $930 – tops for electronics retailers – while Tiffany & Co. (Charts) takes in $2,666. Audrey Hepburn liked Tiffany’s for breakfast. But at $4,032, Apple is eating everyone’s lunch.

I’m pretty sure if you look them up today, they are still dominating this statistics.  That Saks store is their flagship… The Apple figure is their store average…  I still remember when I read that Apple was rolling out a retail strategy that it sounded like a disaster to me.  After all, other computer retailers (Gateway?!) had tried and failed miserably.  It seemed antiquated to buy a computer in a retail outlet when you could order online, especially with rapidly deteriorating component prices at the time.

But obviously Apple had something different in mind, and it has worked beautifully (for one – for the most part- they’ve separated the value of their devices from the underlying components that are used to build them).   If you read the article – don’t focus on the end-product – focus on the process they used to arrive at a good store and a good customer experience – it didn’t happen by accident.

Having said that, I think they need to review their service approach now that the service volumes have increased along with their increased unit sales and number of customers across the iPod, iPhone, and Mac lineups.  The extra service volume is driving increasing complaints about access, wait-time, etc.  And you really don’t want your service reputation to be that of the local car mechanic (unless that car mechanic is BMW, which gets you in and out quickly, gives you a gratis loaner car, includes the first 4 years free maintenance in the price of the car, and charges you an arm and a leg after that!).  The other option is to encourage the proliferation of service shops that can provide similar services but without needing to support the same volume of foot traffic.

Best Retailer?  The numbers say yes.  Best “after-sale-service experience?”  I’m not convinced on that one (and admittedly, the author of the article in 2007 wasn’t making that claim).

Here in Austin it seems a great many of our roads are undergoing a bit of a renaissance as they get repaved or refurbished (stimulus money? Or the city catching up on road maintenance that had been postponed in the previous administration?).

Recently a challenging road near our house was repaved (2222).  Its a windy road, 4 lanes of traffic, and a main east-west artery in Austin.  I was impressed that the construction crew got the whole stretch of road between two major highways complete in under 3 weeks – and they did it by working at night.  During the day, all 4 lanes were open for traffic for the duration.  Often you could see signs of progress – an additional smooth patch of asphalt here and there.  And then pretty soon those patches were joining up with other patches… And the next thing you know the whole road was complete.

I see so many road projects where one lane is shut down for months (often with no obvious progress for most of that time).  Or the project leaves uneven lane transitions for months (which, by the way, greatly increase the number of highway fatalities and accidents).  I don’t know enough about construction to know why the construction crew working on 2222 in Austin was able to use this process versus one of the others – but I can tell you that as a driver on 2222 I’m thankful.  The road is safer now, and the constructions process posed minimal hazards, and it was done quickly.  I’m ready to send all of Austin’s roadwork to these guys.  Efficiency like this should be rewarded!

In previous posts I pointed out how Apple made the right call in putting off all the me-too features in favor of the platform-  and then a followup post on the actual execution of that strategy once the iPhone 3GS was released.  The day after the latest Apple presentation seems like a good time to revisit the topic.

First, its apparent that the standalone iPod line is a little less interesting than it was, now that the iPhone and iPod Touch are here.  The incremental improvements are still there, but a little less exciting when you’re so many iterations into a product cycle that gets new offerings literally every 12 months.

But let’s take a look at how the iPhone is doing, shall we?  Oh, we could look at unit sales.  Or revenue.  Or profit margin.  But I just read a blog post that makes the point from the application developer’s perspective. Matt Hall writes in “Android Market Sales, Are Those Tears or is it Raining in Here?” that Android sales are dramatically lower than sales on the iPhone – more so than just the difference in units shipped would suggest.

Let’s take a look at the two charts that are pretty brutal:

Larva Labs Android Market Sales

Followed by a comparison of how their apps are doing on Android Market versus iPhone’s Appstore:

Larva Labs Sales Android vs. iPhone

Ouch.  Matt goes on to give a good critique (and advice) to the Google Android Market for improving their site from a developer’s perspective. But my thought is the key thing the Android Market is missing is that it doesn’t appear to be as focused on making buying decisions easy.  The iPhone/Apple App Store didn’t get everything right with their App Store, but they sure made buying apps easy.  Those customer-facing or customer-touching processes are really important…Matt remains optimistic about Android in the medium- to long-term and I think that’s valid – because the OS is good and it is free – it is likely to be adopted by a lot of phone makers and be in the hands of a lot of users.  But it also may get fragmented like Unix (see China Mobile’s plans for its oPhone and its own application market, powered by Android but not exactly “in” the original marketplace). There are also a lot of complaints in the comment feed about piracy (something Apple’s ecosystem makes harder).  There’s a lot of platform risk in the Android market… and not much (anymore) in the iPhone App Store platform.

And the strategy of building the network-effect marketplace behind a new software platform on the iPhone appears to be a big winner for Apple at this point.  No one else is even close to challenging its ecosystem in this respect.

Still not convinced?  Take a look at the Chart of the Day from the Business Insider:

Apple's iPhone Games vs. Nintendo DS and Sony PSP

Yesterday I was fortunate enough to attend Capital Factory‘s Demo Day ’09.  The brainchild of Josh Baer, along with partners in crime Bryan Menell and Sam Decker, Capital Factory attempts to find promising startups, and then connect them with just enough help and advice to get them over the hump.  Its essentially an attempt to develop a good, local process that can produce winning startup concepts by putting a virtuous cycle of ingredients together.

Part of the process is Demo Day – where the best concepts get to present to a panel of investors, as well as a packed house of interested people in the Austin and startup communities.  I attended for a few reasons.  First, because I’ve always been interested in the software startup community in Austin.  Second, because Josh is an old friend and I was curious to see how his latest endeavor had turned out (he’s had some really interesting previous ventures, like OtherInbox).  Third, quite a few of my colleagues and friends were going to check it out- and if something like this is worth the investment of their time, that’s a good proxy for it being a good investment of my time as well.

Finally, I wanted to attend a Red Velvet Events‘ produced event – this is my wife Cindy Lo’s firm, and often I’m watching the kids while she’s at an event, or working for BP3.  She did a great job, and there were a great number of compliments from the managing directors of Capital Factory, as well as many of the attendees.  I’m biased, but for my money, Red Velvet Events is the best event planning firm in Austin (not that your event has to be in Austin to benefit from their expertise!).

I have to say I found this event surpassed my expectations in nearly every respect – starting with the fact that the coffee was good enough to drink.  The keynote by Mike Maples, Jr. was clearly in his sweet spot and he shared his thought process around evaluating startups. He does a great job calling out what could be differentiating, thematically, in Austin – the intersection of social and enterprise software (consumerizing IT).  He has a point – there are an awful lot of startups that could be described this way – and some enterprise software companies (like Lombardi) are offering newer products that adopt more social web features (blueprint). Don’t take my word for it – watch the Ustream video! (the first capital factory link above).

The startups gave really good presentations – across the board I was impressed with the professionalism and quality of the pitch, definitely exceeded my expectations.  Which is good, because there were a whole lot of Austin entrepreneurs in the room.  The panel of VC and Angel investors gave some really good feedback, especially for the first presenter (Cubit Planning).  It looked like the common thread for all but the last startup (Sparefoot), was that they needed more thought about the go-to-market plan.  Luckily, that’s a place where investors can really help a lot (and have the financial incentives to get it right).

My favorite was Sparefoot, which can be simply described as “Uship for self-storage” – and I really think they could change that market. Second favorite was the PetsMD concept – but if I were them I would change my pitch around go-to-market to simply describe it as “OpenTable for Vets”.  Because if you can win the scheduling application for veterinarians, then you have a real barrier to entry for new firms, and leverage for pursuing all the other concepts (content, product sales, social/community features).

After the demos, the attention turned to the panel of VCs, which Josh Baer moderated masterfully.  I think the consensus favorite quote “Austin startups have great ego to ability ratio compared to the Bay Area.” Overall, I think a couple of the investors came off as very credible and capable.  In particular, though, Mike Maples, Jr. clearly made an impression on the room.  The number of tweets extolling his virtues was pretty large today – and I think there was a room full of entrepreneurs who would love to have Mike investing in their startups.  A key differentiation – he has heart, and isn’t afraid to show it.  Entrepreneurs want investors to be as passionate as they are about their prospects.

There’s some good coverage of DemoDay ’09 in the Statesman, and here (where Austin Startup goes into some details behind the program).  A bit of live blogging on TechDrawl (and interviews with the founders of the various companies on TechDrawl’s site as well), and on Twitter if you search for #dd09.  This was a great event for the companies presenting, for establishing Capital Factory’s credentials, and for Austin.  If anything, I’d suggest next year alloting even more time for networking because it really was a fascinating cross-section of people from the Austin tech scene.

Links to the startups:

Sparefoot – wow, great looking site!

Cubit Planning – the longer-term play, but probably the most defensible play.

PetsMD -to me this is Open Table for veterinary practices…

Famigo – social gaming for families (lost track of the site link… updated link)

Hourville – great site for hourly contracting – I can definitely imagine cleaning services and independents leveraging this.

UPDATE: kudos to Capital Factory, there’s now an article on Tech Crunch here.

AND there’s now a crunchbase widget:

Just read a great article (no surprise!) by Joel Spolsky on Setting the Right Priorities.  His point isn’t about BPM (the article is a somewhat humorous recounting of the many mistakes he feels he made in his start-up).  But it reminded me of a conversation I must have had 100 times since I started working on BPM projects.

People always ask questions like:

• What project management skills do we need to be successful?
• What technical skills do I need to be successful in BPM?
• What programming languages do I need to look for when I recruit someone?
• Is it hard to do that? (where “that” might be any particular change in the process)
• What kind of process analysis skills do we need to be successful.

My general answer is:  it isn’t any one thing that makes it hard to do BPM right or well.  It is a whole set of simpler tasks and priorities that have to play well together (not unlike the overall process when you’re done – and not unlike getting the pieces to come together in a start-up).  The challenge when building a process is more about knowing what combination of building blocks will get the job done, and then knowing how to execute each of those building blocks with skill and due speed.  Unfortunately this skill is still, for the most part, acquired like a craft- with experience, training, and mentorship.  It is not arrived at with a single university degree or training class, and it is not so scientific that you can write the formula down.

At a larger level within a BPM project (or any project!) success is about prioritizing.  Experience and some practical tools of the trade help you determine what’s most important, and what needs to be done next – but then you have to be disciplined enough to follow the process.  Joel gives some great anecdotes about their start-up journey and how misunderstanding your priorities can hurt your efforts – definitely a good read.

A pretty compelling demonstration of Google’s collaborative features in this article about “Gravity”, which is essentially a mashup of the ARIS modeler and Google’s Wave.

Its a great demonstration.  The biggest surprise, I think, was that this was something built by SAP- not exactly known for pioneering things like this.  There was a lot of buzz over twitter and blogs about how cool this is and how impressive it is – and I agree the demonstration is impressive – but maybe not for the reasons people think.  It isn’t, for example, an impressive bit of software engineering.  Mashups are, technically, relatively easy to execute compared to many other software applications – which is why there are so many mashups with Google Maps, for example.   I imagine Google has similar designs for Wave – and this is actually what I find impressive…but more on that in a minute. Right at this moment, Google Wave integration won’t help much – its not even in public Beta yet, so it isn’t something most companies or users could take advantage of.

If I’m not mistaken, what we’re seeing in this demo is that some folks at SAP have added collaborative features to their modeler (ARIS), by mashing with Google Wave.  That’s a great idea, and we can see how simple/straightforward it looks to be.  I can imagine other tools – Blueprint, Signavio, Appian Anywhere, Blueworks – can easily replicate this from a technical perspective.  There are some issues – like security- that these tools would have to consider if Google was going to be the means for collaboration – but at least one of these tools already has collaboration features at least as good as those shown in this demonstration (live chat, invitations, mutual simultaneous editing) – just not using Google Wave to do it.

What impressed me was Google Wave.  If one of the ideas behind Google Wave is to make it easy to add collaboration to enterprise applications – that could really enhance the quality of work going on in many collaborative business applications and processes – and it strikes at the heart of what Microsoft Sharepoint does for organizations, without the infrastructure requirements and “administrative” requirements.  And whereas Sharepoint is difficult to integrate into your business applications, Google Wave has an opportunity to lower the barriers and steal a march.  If anything, watching this demonstration made me hope our beta for Google Wave arrives sooner than later-  can’t wait to try it.

UPDATE 10/4/2009: Well I know I’ve been submitted for “consideration” for getting a Wave account, but I haven’t received an email yet from the Wave team inviting me to join.  There are some interesting early comments from people who have gotten access, however.  In particular Oscar Berg had an interesting and thoughtful take on Google Wave.

Update 10/6/2009: I just saw this article and youtube video. The article’s premise is that SalesForce is here demonstrating the value of Google Wave.  But it also proves the limitations… Good read..

Update 10/13/2009: A few more websites/ pages are up with useful and interesting Google Wave info.  Although, I have to admit, some of it sounds pretty funny like, “11 tools for Google Wave you’ve never heard of”  – well, that would be about any 11 tools for most people, wouldn’t it?

Google Wave 101 – this is a list of shortcuts, etiquette.  Its pretty basic, and a bit premature for my taste.

ActionBase Blog (have to add that to my reader) had a good post about how the BPM community has largely ignored the impact Wave could have on end-users… however, I’d point them to this post for evidence to the contrary… as well as mentioning the needed enterprise features to make this reality for large enterprises. ActionBase takes a different approach to process,  which I think is highly complementary to the traditional structured process approach.  I’d love to see them paired up with other BPMS offerings to really complete the picture.

Tips and Tricks from Techie-buzz.com.

Update 11/8/2009: More thoughts from ActionBase about Google Wave; primarily with regard to Wave potentially being a disruptive BPMS-like force in the BPM market.  I’ll post some more thoughts on that possibility this week, but I don’t see it as likely to disrupt established BPM vendors so much as the unstructured or user-driven vendors, as well as to further fragment the market currently served by Excel, Sharepoint, and Notes.

Update 11/30/2009:  The creator of Gmail chimes in with his view on Google Wave – and his best point is that it just isn’t ubiquitous like email, and therefore is unlikely to displace it.  He also has some good suggestions about preserving linearity or compartmentalizing some of the threads inside a wave.  Read on right here.

Update 1/24/2010: Anatoly comments on Google Wave, concluding that it is useful, and listing pros and cons. The cons he points out are interesting:

• No email/RSS notification of wave changes.
• No permanent address for the wave
• No numbered lists
• The requirement to register for google wave to participate. This last one is a big barrier to adoption because it means that you can’t arbitrarily include people in your waves. If you can’t include them, then you’re not likely to use Google Wave to collaborate with them…

Please feel free to add additional google wave links in the comment section… I’ll try to keep a compilation without working too hard at it.

Like the hydra, Sharepoint is a beast with many heads.  You chop one off and three more grow in its place!  A recent posting by Jim Sinur posits that Sharepoint starts many processes.  As Jim indicates, the use of Sharepoint is pretty pervasive.  Interestingly, in a previous post, Jim Sinur referred to Sharepoint as a virus (for good or ill).  In this article, Jim asks two key questions:

1. Will the SharePoint Processes be Upward Compatible?
2. Will the SharePoint Content be Managed Well?

I think the answer to both is essentially no.  Oh there may be upgrade paths defined, but the ability of the average firm to execute those adequately is probably not high. This isn’t upgrading from Word 97 to Word 2003. All those customizations you’ve made will probably need to be redone/rewritten.

Sharepoint is a bit of the wild west of process.  Slightly better than the random collection of spreadsheets that often are just as pervasive within organizations as the best way they have available to manage their processes.  The proliferation of Sharepoint is, to my mind, a reaction by business users to not having the right tools and training available to deliver real business process solutions to their business.  Often they aren’t allocated IT budget for the applications they need, and so they cobble together solutions in Excel, Access, and Sharepoint.

A few things I’ve noticed about sharepoint “processes” though:

1. Usually very few people understand what the process is supposed to be.  You kind of have to know what it is to leverage it.
2. There are lots of deadwood Sharepoint sites/sections/processes. More than live ones… Making it harder to find the stuff that is “active” – nothing worse than thinking you’ve submitted your vacation form only to find out that the vacation request process has moved!
3. There is a tension between control and chaos that is particularly problematic on Sharepoint.  To get wiki-like collaboration benefits, you need to open up the gates for users to do their own designs/layouts/etc.  But when you do that, you lose the control and policing necessary to make sure that everything in Sharepoint is “managed” in an enterprise sense.

For a more amusing take on Sharepoint and BPM, see a previous post on this blog, noting the 6 major barriers to BPM adoption.  Quoting directly:

The Sharepoint Effect. This is almost the opposite of the Bus Brake Effect.  Where the bus brake effect concerns too many vetos and not enough yes-votes, the Sharepoint Effect represents the unbridled proliferation of ungoverned, adhoc processes using unmanageable technology.  Sharepoint becomes a substitute for process, or a substitute for the Excel-based or Access-based processes of the past.  However, there’s no way to find the appropriate Sharepoint site for the appropriate process or process task. [...]

It isn’t that enterprises shouldn’t use Sharepoint, but the business and IT should be careful not to let the tail wag the dog with the proliferation of such sites… otherwise you run the risk of Excel/Access purgatory part 2.