In an article titled “Getting Small Firms on Board with BPM“, the author starts with the following assertion:

The greatest obstacle small business operators face in adopting business process management (BPM) is themselves. That factor could account for the underutilization of BPM by small businesses[...] Of course, the abundant offerings of vendors can be confusing, and the trade jargon (SOA, Saas, ROI) can be daunting. Still, the reluctance of small firms to fully utilize BPM often comes down to one thing: attitude.

Of course, the first problem is that the author fails to define “small business” for purposes of the discussion, so that we can all operate with the same assumptions in mind.  Is a small business 3 people? 30 people?  300?  3000?  Or if we size by revenue, how much revenue makes one no longer a small business?

In the very next quote we’re given the example of a six-person automotive shop that has a finance system, sales and customer management, and a website, but no BPM.  Shame on you, automotive shop.  Of course, this belies the literally thousands of successful automotive shops around the country (and world) who have perhaps nothing more than Excel or Quickbooks and a few three-ring binders.

The focus of the article is on the bad attitude of the small business owner.  I think this is misplaced.  The beginning of any discussion of the applicability of BPM should start with something small business owners can relate to:  the bottom line.  Will BPM generate ROI for the small business?  Will it pad the bottom line?  Will it create more free time for the business owner to focus on other endeavors? I read the whole article… didn’t see a single mention of business value in quantifiable terms.  But several points were made that make it clear that some of the benefits of BPM are inherent in the small business – such as the lack of silos, and the ability to see and understand the end-to-end process without software implementing it.

The most bizarre quote in the article is this:

“A consultant is definitely not called for,” added WinterGreen’s Eustis. “What is most significant for BPM in a small business is service and support. The best way to find out what is a good product and what works well in a local area is to ask your friends and employees. Ask around and check out what others recommend.”

Right, so if I just ask around amongst my friends I’ll find the best BPM product?  I challenge you to try this at a dinner gathering – BPM may be gaining in currency but it is hardly a household term, and the vast majority of people out there have no direct experience with the BPM software offerings on the market (not least of which – most are not freely available).  This is hardly a good way to buy BPM software.

Secondly, Eustis challenges the idea of using consulting help.  Keeping in mind that the average six-person automotive shop isn’t likely to have their own IT staff – and in particular, they aren’t likely to have a BPM expert on staff, or time to give someone to become an expert.  If the BPM project has good ROI, it will likely be better for them to invest money in outside help to get them over the initial investment hump rather than pay the price of all the ramp-up.

Adding insult to injury on the “you don’t need consulting help” thread, Software AG and IBM are given as examples of BPM vendors who are cultivating small businesses.  I can’t think of two vendors that have more complicated software offerings to master in order to deploy your solutions (though admittedly I’m much more familiar with IBM’s offerings). And then open-source offerings are touted, but of course those offerings require even *more* technical know-how than the commercial solutions- precisely the skills that are scarce at most small businesses (or, in high-demand with competing needs)

I just found the whole article puzzling at best.  If you’re a small business, and you have processes that are costing you money or causing you pain, look for opportunities to outsource those functions, to deploy off the shelf software (or SaaS solutions), or to deploy BPM.  But whatever you do, make sure it is capital efficient because capital is the most important thing for the livelihood of small businesses.  And make sure it is time-efficient because, after all, that’s the second-most scarce resource in a small company.

Over the weekend, Lombardi pushed out their August, 2009 Blueprint update.  This release continues Lombardi’s track record of pushing releases out every 6-12 weeks with significant improvements (and yet, without so many changes that current users get lost).

In the current revision, additional export options were added.  I was able to easily export my processes in an Excel summary format, as XPDL, and as BPMN 2.  The hardest part about doing this was just finding/remembering where the export feature was hidden within Blueprint (hint: instead of just opening your process, open a “project” and then you’ll get a view that lists each of the processes and gives you export options for each).  The help and/or forums will benefit from an update to guide users to this very useful page.

I always assumed that Lombardi would make it easier to import than to export from Blueprint, and admittedly the import features were rolled out first (from Visio and Teamworks for example).  But the export / publication features have caught up – to Powerpoint, Word, Excel, XPDL, BPMN2.  The last two representing the kind of structured export I wasn’t confident that Blueprint would support because those are also opportunities for other BPM tools to pick up the models for execution.  Clearly Lombardi feels confident that their end-to-end user experience and tooling will cause customers to use Blueprint and Teamworks in combination rather than Blueprint and other tools.  Lombardi claims this is the first shipping implementation of the BPMN 2 specification.

Earlier this year, I wondered out loud about the future of BPMN 2.0 as an exchange format given that Lombardi and a couple of other hold-outs had finally adopted XPDL 2.1 as a supported exchange format.  Lombardi reassured me that they still fully intended to support BPMN 2.0, and I recently had a conversation with Signavio (another vendor which supports XPDL -look for more on this in another post), who also stated their preference for BPMN 2.0 as an exchange format.

Full-text search is another feature that was added to Blueprint.  Not sure what technology they use behind the scenes but it seemed to do the trick for my searches.  The what’s new feed has been updated as well, but those and other refinements are a little more subtle – the kind of things you might not explicitly notice as being different, but you’ll appreciate being able to find things just a bit easier, in general (and *thankyou* for the longer process names – mine always seem to be a bit verbose, like my blog posts).

Interesting article in the MIT Sloan Management Review, “The New, Faster Face of Innovation.”  In this article the author writes about the innovation currently going on in the act of innovating itself.  It seems a bit circular in logic, but true, that companies are figuring out how to innovate more frequently, and how to apply a rigor to that innovation that brings with it lower cost of failure and greater likelihood of being able to capitalize on success.

Because of the lower costs and risks, more innovation investments are being made… which in turn drives more innovation overall.  Because more innovation efforts are being undertaken, the effort to manage that innovation is also underway, and improving in its own techniques.  In addition to lower cost, of course, the economic environment is putting a premium on innovative ways to cut costs, provide better services, or find more revenue.

One of the key tenets of this new wave of innovation is the ability to try tests on subsets of your market- a change on a website submitted to 10% of your visitors, for example – to test the efficacy of a change before making that change available to the bulk of your customers or market. This is often referred to as A/B testing and we’ve previously discussed it here (toward the bottom of the post).  Humans are notoriously bad at making gut decisions based on anecdotal data, and testing lets us actually make GOOD decisions based on real data.

I think BPM can make your business “A/B-test-capable”.  Meaning, once you implement a BPMS solution around your business process, you can actually conduct A/B testing and determine whether process changes are effective before you make either a full switch or make the change semi-permanent.  Without a BPMS and process implementation in place, A/B testing tends to decline to levels that can’t achieve statistical significance:  you ask one team to do their work differently and ask them how it felt – instead of routing work differently for a percentage of process instances and measuring the efficiencies or errors that result.  This type of innovative test-and-test-and-fix approach lowers the costs of the tests, and increases the odds of finding real improvements that can be implemented.

In a recent project, we debated how to do task assignment – do we let users pull tasks as and when they are ready (and in a way that prevents cherry picking), or do we push tasks to users when their queue is nearly empty, and expect them to pick up the work that is assigned to them.  Instead of arguing anecdotally about which approach will work better, we could simply have deployed both task assignment solutions to different user populations and see which population is more efficient.

Oh, and did I mention that these tests can often be deployed in days or weeks, instead of months or years?

Read the rest of the Review article for a fairly website-centric point of view.  But then take a step back and think about the BPM-centric point of view- this is a powerful new rationale for the value of BPM Solutions (or at the least, a powerful way to communicate an existing value driver).

Jim Sinur produced a small preview of what Gartner’s BPM awards will reveal.  The key passage from his blog regarding ROI:

I was really encouraged by the financial returns. Of the 21 companies submitting financial results 12 had break even results less than a year (an impressive 57%). The size of the benefits were also impressive in that 16 (76%) had greater than one million dollars in benefits. There were several with double digit millions in benefits.

But in a previous post, Jim expands further on BPM ROI:

Profit is the fuel that drives BPM. When I first started surveying the ROI of BPM efforts, it scared me. The numbers were great, so I predicted about 15% ROI for most everybody. The truth of the matter is that the numbers were north of 20% consistently. I saw wild numbers of 220% and 360% that I had to throw out because they would have skewed the average.  I am still waiting for a BPM project on the rocks as it is bound to happen, but the majority of BPM efforts are delivering today.

When I read that Jim was tossing out results my first reaction was to be a little annoyed.  After all, you deal with the data you’re given right?  Or at least, if you toss out the high results, you also toss out the two worst results.  However, we can probably assume that there is at least some positive bias in ROI numbers voluntarily reported by companies surveyed about it.

I’ve personally worked on projects that earned in excess of the 360% ROI Jim quoted over a period of 3 years.  So I can attest that these types of returns are achievable from personal experience, but at the same time, not every project is destined to earn a large ROI.

However, I then read a rebuttal of sorts from Anatoly Belychook, who writes a great, though infrequent blog in English and Russian.  Anatoly makes a good case for why the true ROI of BPM should not be exaggerated, by arguing that in fact, BPM returns depend on the existence of an ERP system (or at a minimum, a corporate information system, which is often what the ERP system serves as).

He starts by making an argument that seems to be leading toward advocating BPM over ERP:

As shown by E. Goldratt in his book “Necessary but Not Sufficient” most of commonly declared economic value of ERP – increased transparency and productivity, attractiveness to investors, inventory reduction – is a fiction. The corporate system is necessary but not sufficient condition for achieving the bottom line results. Sure ERP has the potential to improve the economic efficiency of the company but only when supplemented with BPM this potential becomes a reality.

Essentially – the argument is that ERP is necessary but not sufficient to achieve business value and bottom line results.  He goes on to argue, however, that this undermines the case for BPM’s ROI:

Now let’s suppose that we spent a million to implement ERP and two hundred thousands for BPM project. If we agree that ERP is necessary then the achieved results should be referred to the total costs incurred. But if you take into account only the cost of BPM then you’ll obtain the “crazy” ROI numbers mentioned above. Let me use a telecom analogy: ERP is like the backbone and BPM is like the last mile solution. Does it make sense to improve the ISP bottom line results by ignoring the cost of the backbone?

I have to disagree with his conclusion, without needing to disagree with his facts.  In fact, I’m quite sure most ERP systems will cost $10M to $100M rather than $1M… and the BPM project will be in the neighborhood of $200k – $1M.  But let’s take his numbers of $1M (ERP), and $200k (BPM).  His argument is, suppose the ERP solution produces 0% ROI (barely break-even).  Now, we implement BPM and get 200% return ($400k).  So our math looks like:

Return: $400k
Investment: $1M + $0.2M = $1.2M

So, we’re talking about 33% ROI (roughly) rather than 200% ROI.  This is an accurate way to look at your total return on IT investment, including both ERP and BPM.

However, most companies approach these investments separately.  They invest in ERP often because they believe they have to to stay competitive or survive (in other words, they are factoring in some opportunity cost).  Perhaps that reflects the “necessary” component of ERP systems.  When evaluating whether to invest in the BPM system/project, however, what is interesting to that decision is the incremental return on investment (ROI) – and in fact, this is what everyone is referring to when they talk about BPM having a great ROI.  The incremental ROI is not achievable within the ERP system in most cases – because the denominator (the *I*) is much larger to achieve the same R (and in some cases, some of the return is also sacrificed because the ERP system can’t provide the same flexibility as a typical BPM solution.

Anatoly’s argument that the initial “necessary” investment should be included holds true if we are making the decision to do both of these investments at once.  But if the ERP system has already been implemented, then it becomes a sunk cost, and no longer an interesting consideration for which new projects to take on, because by weighting all new projects based in incremental ROI, we’ll be picking the most valuable projects to focus on (from a percentage basis).  If we go back to his telecom analogy – if the last mile is profitable, and you’ve already invested in the backbone, you of course want to sign up as many last-mile customers as you can that tie into that existing backbone investment – because that’s how you monetize it.  Its all incremental return, but it still makes sense to pursue it.

To take the “include the backbone costs” to its extreme – should we include the cost of the office space for the people working, the cost of the network hardware, the desktop computers, the salaries of the necessary people in the process?  Or should we only count the incremental effect the project has – meaning, new hardware we have to purchase to support it, new network infrastructure we need, new personnel we need?

I think if we focus on incremental return, we’re focused on the right metric.

Anatoly goes on to make quite a few points I agree with, but one more point which I take issue with:

Now let’s consider perhaps the most common situation: information «zoo», no single corporate system, Excel as the primary manager’s tool. The pilot BPM project is usually successful under such conditions. If the right business process is chosen, then BPM can streamline the process, radically reduce its cycle time, ensure seamless information transfer between functions, reduce costs, improve quality and ultimately provide solid economic results. Yet after the first success the BPM initiative often slows down because BPM team have to deal mostly not with business processes but with integration and accounting automation. The timeframe increases many-fold comparing to pure BPM project and financial performance declines.

That last line – “Yet after the first success the BPM initiative often slows down because the BPM team have to deal mostly [...] with integration and accounting automation.” It is true that often companies slow down after the first initiative, but that is usually due to lack of leadership, planning, focus, staffing, and budgeting discipline to line up that second project.  My experience has been that companies that pursue a second and third project actually achieve much higher incremental rates of return than they achieve on the first project – precisely because many integrations and systems issues can be leveraged and re-used going forward.  No doubt these second- and third- projects represent some of those off-the-charts returns that Jim Sinur was referring to.

Having said all of this, Anatoly is quite right that if a company has made prudent technology investments along the way, the company is more likely to be prepared to capitalize with their BPM investment and to achieve higher returns going forward.  Having said that – if you have NOT already made those investments in integration services- then I would recommend you use BPM to provide guidance as to where to invest in integration and back-end systems to support the processes you need.  In other words, start your BPM project, and make the integration efforts part of it, their requirements driven by your BPM project.  Build your integration infrastructure on an on-demand basis rather than a strategic-looking-forward basis.  It will be more capital-efficient because each integration you tackle will be directly tied to business processes and uses that are clearly defined in your BPM tooling.

No matter how you slice it, Jim and Anatoly both provide good evidence that BPM projects will provide a lot of return if properly implemented.  Its great supporting data for those of us who are in the thick of things deploying these solutions.

There are times when we must ditch the plan and we often talk about these moments when a good leader has changed course to effect a better outcome.  These tend to be fascinating decisions to study because we wonder, how did this person know that now was the time to change course, and not earlier, or later?  What was the information that led them to this decision?

But there’s another situation to look at: when the plan (or process!) is clearly defined, but we fail to follow it.  In reading Coffee with Startups (by Steve Blank) I couldn’t help but think about the fact that Steve has outlined a clear process (Customer Development), some clear differentiators to apply to that process (what type of market – an “Existing Market” in this case), and published myriad articles about the subject.   He describes coffee with four startups that claim to follow the Customer Development process but communicate clearly in the first few minutes that they have not followed it or completely missed the point.

This can happen with processes within your own organization – no doubt you’ve observed cases of this yourself.  But you can’t afford to have the captain of the ship ignoring the process that is understood to be the right one to follow.  If they pick a plan or a process, they need to be able to implement the plan – both in order to make it work, but also to be sure that if you decide it doesn’t work, you’ve actually given it a chance by trying it in the first place.

The entrepreneur may decide that Customer Development isn’t the right process for their company to follow… But if it isn’t, then the entrepreneur should follow the one they believe in, and not play lip service to one that they don’t. The same advice follows for process – if you define the right process – follow through on it.  Implement it, get your organization to execute it well.  Only then can you change it from an informed baseline opinion.

As a firm that is entirely focused on BPM implementations, we get a lot of queries from staffing firms, and I’m going to take this post to speak out against the practice of using these expensive, non-value-adding, players in the marketplace.

We get (each of us at BP3) about an email a day from a staffing firm looking for “a Lombardi Teamworks Administrator (or Developer or Architect) in Bentonville, Arkansas (or Bay Area or Boston or where-ever” (or other locations).  (someone should tell these guys that there is only one company in Bentonville likely to buy BPM and need to hire outside help… )  If I could convey one thing to companies deploying BPM and using staffing companies to augment their teams, it would be to understand the value chain in the BPM staffing equation, and why those firms are ill-equipped to help companies achieve their goals with BPM.  If you’re using a staffing firm, odds are you could save money and time, and achieve better results, by working directly with BP3 (or other boutique BPM firms).

Customers: Problems with Staffing Firms

From the perspective of a customer, what are the problems with using staffing firms?

Problem #1:  BPM services aren’t a commodity. They specialize in commodotized staffing in areas where there are millions of developers to choose from, like vanilla Java development, PHP, SQL, HTML, etc.  They have no concept of why the going rate for BPM experts is higher than the going rate for Java experts. They are used to treating software engineers  like day-labor construction jobs.

Problem #2: These staffing companies don’t understand what BPM is. No one at these firms has worked for a BPM software vendor, or a BPM consulting firm.  They’re essentially headhunters/recruiters, with no vertical domain expertise in BPM.  The staffing companies won’t provide any differentiated value add once the person is placed.  There are no skills at the staffing company to help that consultant be successful once they’re onsite.  There’s no technical support, no project management support, no lifeline to call.  There’s just a rate and a # of hours.  They don’t care if you deploy a waterfall or agile methodology, they don’t care if your project is successful – frankly, their job is to sell bodies, not to sell success.   If you are a customer, don’t ask them to help you make your project successful other than by adding or replacing personnel.  If you are a contractor through these firms, God help you if you struggle – you won’t get any help from them.  If they smell blood in the water they’ll replace you as though you were a stapler that didn’t staple straight.  But they will NOT help you.

Problem #3:  Because they don’t understand BPM, they don’t understand Process Improvement.  So you are going to forgo any help identifying opportunities for process improvement, or getting someone on staff who really understands how to do that.  When you work with a firm focused on BPM, you can expect to get those skills in either the people you contact with or the people who support them.

Problem #4:  They can’t get the best resources.  Because they aren’t BPM experts, they don’t know which of the folks they talk to are good and which ones aren’t.  They aren’t deploying people they have years of history working with. They aren’t deploying people they have a good basis from which to interview and judge competency.  They’re just deploying whoever will take the lowest rates and the most demanding contract terms, allowing them to maximize their profit.  There are very few really good BPM experts out there, relative to the demand – and even fewer experts who are available at any one point in time.  Some of the best BPM experts in the world work for BP3 and companies like ours, but you’ll never get to them through the staffing outfits – because boutique firms like ours are a threat to their business relationship with customers.

Independents: Problems with Staffing Firms

From the point of view of a contractor considering a staffing outfit:

Problem #1:  You are a commodity to them – a stapler, or worse, a staple.  They don’t care that eventually you’ll go work for someone else, they just want to maximize profit right now.  They’ll squeeze you hard on rates and terms in the contract.  They don’t care if you’re happy, they don’t care if you’re successful, so long as they have a chance to replace you with someone else and keep getting paid.  They don’t care if you get eliminated from consideration for arbitrary or unimportant reasons (like, having the wrong accent, being unable to travel on a particular date or day of the week, or having 22 months of experience instead of 24 minimum… )

Problem #2:  Staffing companies will not “sell” you to their customers.  They are just presenting you, and not taking sides too strongly – they let the customer decide if they want to work with you, and they’re not strongly invested in the outcome for any one person, because the customer knows that the staffing firm doesn’t know you from Adam and Eve.  See point #1:  you’re a staple. There are more just like you (as far as they’re concerned).

Problem #3:  Once a staffing firm has presented you to a customer (or rejected you for that customer), you have no shot of getting into that customer through another avenue.  This is a function of the contracts between the staffing companies and their customers – usually anyone they present, even if they present them with the reasons why that person isn’t a fit, is no longer available to the customer without violating some kind of contractual constraint that requires them to pay the staffing company.  As a result, they’ll never revisit these decisions.  So if you, as a contractor, put your name out through “Superior Staffing”, but also reach out to BP3 about working on a particular account – odds are that you’ll either get staffed through the staffing firm at a lower rate than what we would pay (if you’ll take it), or you’ll get rejected because the customer has already seen your name through the staffing firm and doesn’t want to run afoul of that contract.  Many independent contractors mistakenly believe they are better off reaching out to as many opportunities as possible at the same time – but if those opportunities are consulting and staffing firms, that isn’t the case.  I’ve seen embarrassing situations where the same person was proposed by three different companies to the same customer.  If you have a more valued relationship with one of those firms over the others, the customer sure won’t see it in that circumstance.  And they’ll likely see you as little more than a mercenary and not someone that they can depend on to work the duration of the contract.

Why Work for BP3?

Against this backdrop, we’re being approached every week by people who want to work with BP3.  And our colleagues refer additional people our way every week.  In fact, we just hired another great asset for our team last week.

In a previous post we made the case for why customers work with BP3:  we’re in the business of selling success. But why do BPM experts and people interested in BPM want to work for BP3?

So why do these highly skilled professionals want to work with BP3?

1. We live eat and breathe BPM.  This isn’t a fad or hobby for us, this is our livelihood and our career.  We understand why BPM expertise is differentiated.  Prospective employees and contractors understand that if they work with us it will improve their own brand in the industry by association.
2. We’re invested in the success of our team.  We want our staff to be successful.  We’re working on long-term relationships with our clients, and as a result – when we put someone on our project, we continue to provide technical and project management support, not to mention support through managing the customer relationship.
3. We don’t squeeze our folks on salaries and rates just because the economy is challenged.  We want to be working with our staff for a long time, and we know BPM is going to be in demand for years to come.  We’re not so short-sighted as to put the squeeze on people at the first sign of trouble.
4. We represent our colleagues well to the customer.  We help our customers understand the strengths and fit of our consultants.  We help work out a travel schedule that works for both parties.  We provide video conferencing capabilities from our home office to help enable effective remote work.
5. When the going gets tough, we help.  We’re BPM experts.  We can help with the technical lifting, and we can help with process improvement consulting.  We can help get a project that is off the rails, back on track.  And our customers know that we’re there to help.  Its part of why they keep coming back to work with us.
6. We have a good reputation.  I believe we have a good reputation for fair dealing, for being good to work with and for.  We also have a good reputation in the BPM market as experts in our field.  It isn’t our first time to the rodeo.
7. Our business is growing.  Despite the economy, we’re growing in the face of it and staying focused on our key value driver:  making customers successful with their BPM projects.

If you’re a BPM practitioner, BP3 is a great firm to work for.  If you’re a BPM customer, BP3 is a great firm to work with.  We’re not your only option, but we’re trying hard to be your best option.

Recently I was discussing with a colleague at a software vendor what BP3 does for a living.  The question was asked, first, what does BP3 do?  I gave my usual response, which has to do with process improvement and implementing processes in BPM suites (I like to call this marrying theory and practice).  At the end of my spiel, I was asked if we’d be interested in being a reseller for their software.  In fact, being a reseller may make sense at some point for BP3, but that’s down the road a ways.  I responded that we really aren’t in the business of selling software – we don’t have a sales staff, we don’t cold call new customers.  In fact, we usually get referred to customers by word of mouth.

By whom? he asked.  Well, it varies, but it includes:

• old colleagues who know what we do now for a living and know we do it well
• other BP3 customers who liked our work
• software vendors
• consulting companies

I think the last two bear remarking on.  My audience wasn’t convinced. Why are software vendors and consulting firms asking us to help out and referring or subcontracting business to us, if they don’t get the quid pro quo of our bringing them additional business by bringing in new customers?

It turns out that the software vendors and consulting companies we work with have their own consulting staff.  But they still bring us into their customers.  Even their prospects.  Why?  Because what they’re buying with BP3 is success.  They’re not really buying our process modeling, our technical jujitsu, nor our process improvement skills – although they know they’ll get top-notch work in each of those areas.  They’re really buying the insurance policy for success in BPM, which is called BP3.

That’s when I realized we had moved from the question of “what do you do?” to “why do your customers work with you?” to “what are your customers buying?”  Why, our customers are buying BPM Success, and they’re buying from us.  That’s why major outsourcing firms will bring us in to work on major accounts or projects.  Its why software vendors ask us to run proofs of concept.  Its why customers call us when they have a critical project.

In the process of answering this question, I realized we’re making our “pitch” incorrectly.  We need to transition from “what we do” to communicating the BP3 value proposition: “what you’re buying from BP3 and why.”

So the next time someone asks me what we do, I think I’ll tell them, we sell success.  (And then explain the context of BPM and how we do that.  )

Interesting tie-in between process and Twitter on GigaOm recently in an article by Jennifer Martinez.  She points out that Biz Stone’s discussion of the future of twitter appears to follow along the lines of Eric Ries’ “Lean Startup“.  Notably, they intend to follow customer usage to figure out what to build around the original 140-character Twitter service in order to create more value.

Its the first time I’ve actually read something that indicates there’s some method (process?) to the madness that is Twitter – and maybe that is new, or maybe that has been the case for a long time and I’m just now becoming aware.

We’ve recently set up a twitter account for those who want to receive tweets of our blog posts (rather than subscribing via RSS for example).  Its @bp3bpm.  It will just be capturing our blog, and perhaps company-news-items at some point in the future.  I’m personally on twitter as well (@sfrancisatx), but I can’t promise to stay focused on BPM on my twitter feed. We’re just providing an alternate way to keep up with BP3, and BPM.  We’ll see how it develops for us.

Turns out, the folks at Stanford are doing BPM.  Last week I had the good fortune to visit my Alma Mater (Stanford).  I had heard through the grapevine that Stanford was embarking on BPM, so I took advantage of the excellent mass transit in the Bay Area (Austin, are you listening?) and went to visit Lee Merrick at Stanford. Lee is in the Office of Research Administration and he’s the driving force behind BPM at Stanford.  Lee was gracious enough to let me track him down in his office at Terman Engineering, where we spent a couple hours talking BPM strategy, tactics, and vision.

Quoting from Stanford’s SeRA project page on vision and purpose:

SeRA Vision and Purpose

• Major administrative systems overseeing research will operate cohesively
• Investigators and staff will be able to effectively manage their sponsored projects from conception through closeout
• Administrative burden will be significantly reduced for investigators, departmental staff, and central offices
• Streamline research administration processes to minimize inefficiencies and eliminate duplication
• Improve turnaround time, reduce audit risk, collect better data

SeRA will be a system of inter-connected modules, pulling data from existing sources or prior modules to eliminate points of duplicate entry wherever possible.  The system will be developed by critically looking at current business processes to eliminate non-value-added steps and provide full process transparency for faculty and departments.  The system will be designed with significant input from stakeholders and subject matter experts involved in research administration.

In short, Lee and his team are attempting to revolutionize the way Stanford manages research in order to make research more efficient and effective.

With Lee’s permission, I wanted to share some of the takeaways from our discussion.

1. The problems driving corporations to BPM are not unique to corporate entities - academic institutions are also being pressured to reduce expense, waste, and inefficient use of talented PhD’s. Stanford’s efforts are focused on freeing up time for research while providing higher quality transparency to both the university and the federal government.
2. The processes Stanford seeks to address don’t fall into the sweet spot of any commercially available shrink wrap software packages.  BPM allows Stanford to address a space that doesn’t fit these packaged software offerings well.
3. The processes Stanford seeks to address require agility. Lee’s team can’t predict how their processes will change, because much of the process change is driven by external factors (e.g. The Federal Government).  Stanford needs to be prepared for both the changes they are planning, and the changes they haven’t anticipated yet (Jim Sinur would call this Scenario Planning).
4. Focus on producing material, hands-on results in the bake-off. In Stanford’s BPM bake-off, they really focused on how much of their solution could be built by their team in a finite period of time. They evaluated two pure plays and a stack vendor, and actually building a solution in the BPM suite was what really differentiated the products to the SeRa team.
5. This isn’t a 3 month project, this is a significant investment with a serious team. Lee and his team on the SeRa (Stanford Engineering Research Administration) project are embarking on a 3 year effort, with a staff of more than 10 people focused on this project.  That’s a significant commitment against the backdrop of budget cuts going on at Stanford at the moment (recently Stanford reporting canceling or postponing over $1B in construction projects, for example).

Stanford is going to be a great contributor to the BPM community, and more specifically to the Lombardi community.  They have an interest in sharing best practices, design patterns, and even software solutions to common problems.  I fully expect that Lee and his team are interested in bilateral or multi-lateral sharing. I think that their long-term perspective will help counterbalance some of the very tactical focus on quarterly efforts in many corporate solutions.

I left our meeting with renewed optimism for BPM, Lee has a certitude and optimism that makes you believe he and his team are going to deliver.  And they have the ambition to really tackle the hard problems and build good solutions around them.  I think we’re going to learn a lot from these guys in the next 3 years.

I took the train ride back to San Francisco to meet my wife for dinner, and on the way back I started thinking about opportunities to collaborate in the Lombardi community.  More to come on that thought process in another post.  Thanks to Stanford and to Lee Merrick for taking time out to share their BPM story, I hope we have opportunities to collaborate in the near future – on best practices, methods, and/or technical solutions.

I prefer to call them BPM Collaboration tools.  Recently we’ve seen updates to Lombardi’s Blueprint, the release (into Beta at least) of IBM’s Blueworks (interesting choice of names, IBM), and the release of SAG’s AlignSpace.

Sandy Kemsley recently reviewed both the latest release of Blueprint, and the latest from SAG Alignspace.  I believe at least the latter was based on a Webex or walk-through, rather than on actually having hands-on-access.  Good capture of the strengths and weaknesses of each.  It sounds like Alignspace is more focused on community and less on modeling, and Lombardi comes at it from a collaborative modeling “point of view”.

I’m interested to see Sandy’s take on IBM’s offering as well, since she’s getting a good look at more than one tool in close proximity. This is a really valuable service the independent voices like Sandy and Bruce give us.

One interesting comment on Sandy’s Blog was from Terry Schurter of Global360.  He claims that these social sites are a recipe for disaster.  Well, certainly they won’t all succeed equally.  But to claim that the feedback from the user community on these sites won’t be useful misses the boat.  Lombardi and SAG won’t need to ask their users what they think (although I’m certain they will do so), they’ll be able to see for themselves how users are using their respective sites – which features are laying fallow and which ones are drawing attention and usage.  They’ll be able to introduce a new feature and observe whether it enhances user perception or utility. Terry discounts these benefits out of hand, which I think is a mistake.  It is a mistake to think that just a few experts at each of these vendors have all the answers for what should go into a product.

Having led sessions much larger than the one Terry describes (3 people), I can say definitively that there is a technique for adapting to larger groups of stakeholders and still driving progress – and two of the key ingredients are having a clear decision maker, and having an outside consultant or facilitator (someone who can’t be tarred with any particular internal politics or biases).  There are, of course, a whole host of minor adjustments to the process as you get a larger (or smaller) participation group. These social / collaborative tools should just give us better technical tools to augment what we’re already doing in conference rooms and videoconferences.

Are Process Applications the new Black of enterprise software solutions?

It seems that there have been a flurry of announcements of new process applications.  Certainly some of these announcements are no surprise at all – when they come from an Oracle, IBM, or SAP.  But recently there have been other examples: the Callidus announcement (combining BPM and incentive management), and another from Austin-based SiteStuff announcing PROCUREplus (I’ll never understand why companies play with capitalization so much).

The SiteStuff announcement was a surprise to me.  Surprise that they’re offering a new service?  No.  But surprised that the pitch is surprisingly BPM-like:

SiteStuff today announced that it will soon offer three new business process improvement solutions aimed at increasing efficiency, lowering back office costs and promoting sustainability within the real estate industry. These new additions will complement the existing procurement solution, SiteStuff PROCUREplus™ for which the company has been widely recognized.

They could have left the “business process improvement” terminology out of the release and made most of the same points about value creation – but clearly including the business process improvement slant makes it clear what value proposition they are offering.  I think it is a sign that business process management and business process improvement are gaining currency across a wide spectrum of companies that provide solutions designed to make your business more efficient.  They aren’t all BPM vendors.  However, I would say that all of these vendors would benefit from the inclusion of robust pureplay style BPM engines.  Why?  Because it will give them the opportunity to quickly roll-out process change, or process-customization, for their customers, without the same software development overhead.

Bruce Silver has posted another update on model portability.  This is related to the previous discussion regarding XPDL, Lombardi Blueprint support, and model portability.

In this round, Bruce has time to really dive into the couple of aspects of the import that were not working, and tries to address them through some XSL judo.  Judging by the end-product screenshots he’s posted, he did a pretty good job at that.  The main issues were around losing lanes and XY coordinate mapping.

Bruce was generous enough to not only share the narrative of his efforts, but to share the end-product XSL as well (link available on his blog posting).  I think it shows (a) how close we are to real BPMN-level portability, (b) the fact that products still have a ways to go to support it properly (really, I have to write XSL to convert the models!?), and (c) how much harder accurate portable execution models would be given that these tools have different ideas about how steps in the process should be executed…

Thanks again Bruce!

UPDATE:  Bruce has an update on the model portability issues based on Diagram Interchange (DI) and BPMN 2.0.  He points out that some of the decisions made for supporting diagram interchange make it impractical to implement, despite being technically possible.  As usual, he provides good insight into the standards process for BPMN, and exposes some of the warts in the outcomes – hopefully it will result in some remedies in minor revisions to the specification.

I missed this press release from just about 2 weeks ago.  I think it will be a growing trend to embed BPM functionality into core business applications.  Callidus‘ offering in particular is interesting because it is a way to extend core functionality to make their packaged software fit the mold of your internal business operations that much more closely.

You can also find more information directly on Callidus’ site, where they have some slick graphics to go with the product description.  We’ve worked enough with Callidus enough over the last 6 months to know that this is robust BPM functionality, not just a band-aid workflow engine or marketing spin.

It isn’t that often that I run across a good blog that covers three of my favorite things:

1. Apple (or Apple products)
2. Startups
3. Process

But Eric Ries managed to hit all three topics in The Steve Jobs Method.  Eric writes regularly on the subject of startups and the Customer Development and Continuous Deployment approaches to startups.  And recently he wrote to address in a more thorough way the question he is often asked at his talks:

“Look, Steve Jobs doesn’t go out and ask customers what they want. He doesn’t put out crappy, buggy products and then ask for feedback. And he doesn’t shy away from big-bang launch events. He tells customers what they want, and he gets it right. So how do you reconcile his success with the lean startup, which seems to suggest the opposite?”

I love the candor of Eric’s post, the fact that he admits he has typically not had a great answer for this response.  For one thing, putting out a hardware device is very different from releasing a website or easily-updated software release (and Eric’s advice is mainly targeted at software companies, though most of the concepts can apply to any startup if you engage in a little creative license).  So by the very nature of the product, the process has to be different.

I find it interesting in the comments below his post, several comments seem to think that Apple doesn’t “iterate”… but since when do all iterations have to make it into production?  In the work we (bp3) do on business processes, we typically have 3-4 iterations before going “live” to production.  Any hardware-producing company worth their salt is going to have internal iterations – prototypes.  There is evidence (though second-hand) of Apple going through a lot of iterations internally before releasing product to market.  Of course the big mystery for everyone is how Apple does such a (relatively) good job of correctly identifying when they’ve got a product that people will actually want.

Read Eric’s post – he makes the case more persuasively than I can.  I’ll just sign off by saying, I think Apple’s product development process is not inspired genius, but rather a process that leverages their many talents to produce great results, consistently.  No doubt Steve Jobs’ experience with Pixar’s creative development of movies, and his NeXT team’s experience prior to Apple helped inform this process and improve it.