Posts Tagged ‘BPM’

Too Important not to Cross-Link: Activity Data

Saturday, March 13th, 2010

John Reynold’s post on Activity Data, from a process participant’s perspective, is just too comprehensive and good not to devote a short, sweet post that cross-links to his article. If you think about what went wrong with your last activity implementation – it was likely that you weren’t considering the full list of things that John lists here.

The Process around Social Tools

Wednesday, March 10th, 2010

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

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

The answer is, it depends.

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

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

BPM, same as it ever was?

Monday, March 8th, 2010

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

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

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

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

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

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

Jon says:

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

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

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

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

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

Will BPM efforts increasingly look like service integration?

Monday, March 1st, 2010

MWD Advisors has a post up about the coming move from “systems integrators” to “service integrators”.  Its a smart read, pointing out that customers who want to offload technical details to service providers are also likely to hand-off the technical lifting to integrate and coordinate these SaaS/Cloud services together to the companies that currently do systems integration.

Interestingly, if BPM vendors provide the right tooling, a SaaS BPMS (or even a hosted one) could be ideal tooling for pulling together these other services to support cross-functional processes for the business.

#bpmjam gets a writeup

Friday, February 26th, 2010

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

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

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

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

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

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

For the Second Decade of #BPM, Design Matters

Monday, February 22nd, 2010

Theo Priestly on BPM Redux wrote about ArisAlign and its lack of “buzz”.  I’ve had similar feelings about Aris’ user experience, and the feeling that some of the enthusiasm espoused is a little forced – sort of trying to hard with the “I (heart) ArisBPM” pins, etc.

But the post reminded me of a theme that has been on my mind a lot over the last year: Design Matters in BPM. As if there was any doubt, I see more and more evidence that in the Second Decade of BPM, design will matter.  Not just a little bit.  I believe design will dictate whether BPM achieves ubiquity in the business. Design will dictate which tools will benefit from that ubiquity.

Apple serves as a good example of how much design matters in an industry that appeared to be commoditized (personal computing, cell phones).  Some might argue that BPM software isn’t commoditized yet, and therefore the focus might be on features/functions rather than “design”.  But I think the key elements of BPMS are, by enterprise software standards, fairly commoditized:  there are many players in the space, customers have a difficult time discerning the differences from a feature/function point of view, and ASP (Average Selling Price) is likely declining for most BPM vendors.  There are also a couple of open-source BPM software offerings on the make.

Combine the above with a trend toward putting BPM suites “in the cloud” and offering them in a SaaS model, and it really starts to look more like a utility.  But what takes it to the next level?  Here are some areas of BPM and my thoughts about how well they’ll differentiate vendors…

  • Execution.  I think everyone agrees execution is nearly commoditized.  There are *real* differences at the execution level, but the market doesn’t recognize these differences in a way that channels dollars to the best execution engines.
  • Simulation. Many of the vendors offer this.
  • More modeling constructs? Already, vendors barely provide a fraction of the BPMN modeling capabilities defined in BPMN 2.0 (or even 1.0).  So, there’s an opportunity here, but fast-following will be pretty easy.
  • Process Discovery? This holds some promise for differentiation in the short-to-medium term, in my view (there are only a few vendors who even claim this ability).
  • Optimization? This has potential, but the current solutions simply don’t achieve it.  They work really well on small data sets and don’t (yet) let you efficiently do “optimization” on enterprise production data.  There’s a significant software investment to make here, and opportunity for differentiation.  Pair optimization with process discovery and you’ve got something really interesting…
  • Modeling tools?  This is heading toward commodity rapidly.  Absent the advent of SaaS software I would have predicted an open source modeling tool would gain pre-eminence and get embedded in a lot of commercial products.
  • SaaS / Cloud offering? There are already numerous choices and prices are heading toward standard increments.
  • Community / Collaboration?  Outside of BPM, these are already fairly commoditized from a feature/function point of view.  Wikis, chats, Instant Messaging, Videochats, Communities – these features will not provide differentiation on their own.  In fact, vendors may rely on Wave or similar technologies to incorporate collaboration without making some of the IT investments that early adopters have had to make.
  • “Dynamic” BPM or “Case Management”.  Call me crazy, but I remember CASE tools being all the rage in the mid-90’s.  I think unstructured, dynamic, and case management style processes are important, but I don’t think the technology required will offer differentiation to vendors for long from a feature/function point of view.  What they offer is a “better fit” to these use cases, but they’re not solving a problem that couldn’t be solved before.  (Note: Better fit matters, its why you should use BPM tooling to solve process problems rather than just slinging some Java or PHP code or hoisting a SOA stack into place)  To the extent that these “case management” tools are better, its a result of better design to suit the problem, not a case of out-featuring the other guys…

The opportunity for BPM vendors will be to produce differentiation based on the design of their products and offerings, by producing designs that engage the users, that elicit effective and efficient usage.  Collaboration, Unstructured BPM, Process Discovery, and Optimization all offer the biggest opportunities for differentiation by product design, in my opinion.

In closing, I should clarify that product design is not just skin deep.  Some make this mistake when they look at Apple Products and see only the outer shell.  Good product design goes much deeper than the UI, than the outer shell of the product.


Updates on the Cloud and BPM Community

Friday, February 19th, 2010

Sandy Kemsley has a few good updates on these topics.

In the first, she releases a review on IBM’s BlueWorks online community for BPM.  Some of the interesting tidbits:

  • IBM BlueWorks uses Flash.  Interestingly, Lombardi started with a flash interface (and it was a very slick prototype) and scrapped it for GWT/Ajax.  Why?  Because Flash was just not stable enough to support what they wanted to do (even in the early stages), and they could see that they were going to run out of “room to run” with Flash, whereas in GWT they felt the sky was the limit in terms of layout and functionality over time.  Quote from her blog: “The process designer is Flash-based, and it only took me about 5 minutes to crash it; luckily, it saved as I worked, so I didn’t lose any work.”
  • She gives pretty good marks to the content they included, which might form the basis or significant contribution to a CoE.

Speaking of BPMN modelers in the cloud… Sandy followed up with a good post about why locating your hosting services in different locales matters (a lot) to customers.  Although I can point anecdotally to data points (companies) that don’t have an issue with the location of servers (unless it affects performance), I can also attest that quite a few customers in other geographies *do* have an issue with hosting location.

Hopefully as these services mature they can offer more options for their customers.  Certainly IBM has the global reach to put its cloud / community offerings in as many geographies as it needs to to be sufficient for its customers.

Scarcity and Value (and BPM)

Thursday, February 18th, 2010

Great article from Jeff Jarvis advising companies with nonphysical goods to stop selling scarcity and start selling value. It is a principle that can be applied to a great many businesses, not just the “Web 2.0″ world, but as he points out, education and consulting as well.

His advise to advertising businesses: sell the outcome, don’t sell the scarcity of your space!In the Content world, he points out that content just isn’t scarce any more.  The existence of this blog is actually just one more data point to that effect!  Information is not scarce either – with Google at our fingertips. He goes on:

Thus we have performers and consultants. There is still value in unique performance. We will continue to buy tickets to concerts by stars (but we won’t pay for the Muzak covers of their songs on elevators). We will buy books. We will pay to sit in a movie theater with popcorn. The new competition in the case of media and performance isn’t that someone will make a good-enough version of what we do but that there is more call for the public’s attention.

Quality is a scarcity. But it is a real scarcity.

The challenge is, there has to be recognition that:

  • You (your company, your product, your content, etc.) represent quality, and
  • Your level of quality is discernably and valuably differentiated from other sources of similar product, content, expertise, etc.

In BPM, we’re suffering a scarcity of BPM-related skills.  We already have a general shortage of technical skills in the world, but on top of that, having the technical skills combined with the understanding of business and process improvement – we’re talking about a real scarcity for the right talent and skills.  But as I’ve argued previously, BPM isn’t hard because it is rocket science – each component task we do in BPM isn’t hard – its hard because knowing the right combination of tasks is a subjective, judgmental activity that depends on experience.

But the *real* scarcity isn’t the BPM bonafides.  The real scarcity is quality BPM skills and personnel.  Because what we’re selling isn’t truly our hours of labor.  What we’re truly selling is the outcome: a successful BPM deployment; a successful BPM program; or a successful transfer of skills and methods to a COE. My shorthand for this is that our customers are buying success.

Lance Gibbs: Value-Driven Delivery at #bpmCamp 2010 @ Stanford

Monday, February 15th, 2010

Lance Gibbs gave a well-attended talk on moving from Plan-Driven to Value-Driven delivery at bpmCamp 2010 @ Stanford.  There are some great slides in this presentation, and the approach dovetails well with Lance’s ability to get people focused on what matters most to their project success.

It starts with realizing that requirements are estimated, and resources and time are fixed, which is inverted from the typical plan-driven approach.  There’s also a focus on “should” rather than “could.” In particular, slide 4 jumps out at me, as it spells out what you should value, for example:  working software over comprehensive documentation.  Amen!

The presentation is embedded here:

Complex Organizations are… Complex.

Friday, February 12th, 2010

Great article by Keith Swenson explaining why large and complex organizations are difficult to model using “scientific management”.

I think Keith makes a couple of great points that are worth letting soak in:

  • Complex systems are unpredictable
  • Organizations that “Learn” can adapt when the environment becomes less predictable.
  • If you divide your organization between brains and brawn, you are failing to reach your organization’s full potential.
  • Learn from *near* mistakes – not just the *actual* mistakes.

Of his takeaways for BPM- my favorite is transparency:  people involved in the process need to understand the part they play and the context of the process if they are to help the organization learn and improve upon it.

Worth the read and there’s a good comment-stream as well.

On a tangent relating this to political science…

For very complex organizations, it may well be worth applying some theories from political science and international relations to your thought process. One of the most useful political science theories is “Realism” – the notion that nations act in their own best self-interest, in a rational and calculating way.  My first exposure to this was in Dr. Krasner’s course on International Politics.  Usually deviations from what appears to be self-interest can be explained by imperfect information or miscalculation – but in general realism probably most closely describes how most states will act at critical moments of international relations.  In large, complex organizations, it helps to assume that departments, teams, and divisions will apply a healthy dose of Realism to the way they behave.  Part of how you deal with overly complex systems is by having useful abstractions that give you a shortcut to understanding, not ALL of the minutiae of cause and effect, but rather the SUM TOTAL of these effects.  It is much like the difference between micro and macro economics. Realism does not deny the other effects, but it argues that they are secondary effects rather than the primary correlating explanation.

Sloan Review on Process Improvement

Thursday, February 11th, 2010

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

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

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

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

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

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

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

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

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

Web Applications Masquerading as Processes

Wednesday, February 10th, 2010

Or was that the other way around?

Prashant Gadgil gave a presentation at bpmCamp 2010 @ Stanford on this topic – because often business process problems are described as a process but require a full-fledged web application to properly address – or vice versa.  His talk focused on helping differentiate between the two – or to know when you are stepping outside the sweet spot of what a BPMS usually offers you.  Still, if you have a process, you don’t want to lose sight of it as you build out your web application’s functionality!

There was more ground covered in discussion but I don’t have notes from this session, so the slides will have to suffice! Prashant was generous enough to allow us to publish via slideshare (and they are also available to bpmCamp participants via the bpmCamp wiki site).

More to come from bpmCamp notes in the coming week…

Starbucks’ Misplaced Improvement Effort

Tuesday, February 9th, 2010

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

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

But the other day, the wheels came off.

What happened?

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

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

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

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

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

Appian 2009 Results

Tuesday, February 2nd, 2010

Well, after much celebration before announcing the details, we now have some (just some) facts about Appian’s 2009.

It sounds like it was a good year – as MWD reports, its license revenue was up 59% (but we don’t know from what base, much like Lombardi’s reported numbers before it was purchased), and customers doubled.  Of course, another way to phrase this is that ASP declined by 20% (if my math is right), or that revenue mix has shifted from prepay (enterprise license revenue) to either post-pay or subscription revenue.

MWD’s assessment is that international revenue will grow faster than domestic revenue.  And while this argument makes sense, having worked at more than one company Appian’s size in my career, I can attest that international revenue can be very erratic.  For a few reasons:

  1. When starting from a small base, a single deal (or two deals) can dramatically affect the percentage growth internationally or in a region.  However, with so few data points, it may say next-to-nothing about going forward revenue.
  2. Even off of a bigger base, international revenue has so much to do with your sales operation, and so little to do with your product.  There are other products out there.  There are big consulting shops out there. Whether you capture the money (revenue) that is being spent to solve the problems your software solves depends almost entirely on your sales and marketing operation.
  3. American companies of this size rarely understand the international markets well enough, and make mistakes which cause big revenue swings up and down.  This is true because the executives usually lack field operational experience overseas, and though they may hire that experience, they may not be able to successfully evaluate those international experts and may end up throwing good money after bad.
  4. I’ve seen a single sales rep bring in 30% or more of a small company’s revenue for a single year, only to bring in zero revenue the following year.  Individual sales rep performance is crucial to small enterprise software companies.

Appian may well overcome all of these pitfalls.  But revenue in both the US and Internationally is coming off of a small enough base that we should expect to see high beta for any of the smaller vendors.

The conclusions that Appian’s results really drive home:

  • BPM is growing, not dying.  And growing faster than enterprise software generally. (Not just from this datapoint, but from Lombardi, IBM, Savvion, Pega reported results)
  • The BPM pure plays were doing well in 2009.
  • The remaining pure plays may still have legs and room to run while Lombardi and Savvion acquisitions are digested – even if those acquisitions are quite successful.

#bpmCamp 2010 @ Stanford – Overview

Monday, February 1st, 2010

bpmCamp's patio

Last week Stanford hosted the first “bpmCamp” for Lombardi Teamworks and Blueprint practitioners.  By all accounts the event was a success – sold out at 40 participants – and with some truly great interactive sessions and discussion that is hard to have at a bigger forum.  Our Stanford hosts did a wonderful job hosting, including all of the little details like name badges and maps, but also helping organize logistics around lodging, transportation, parking, and providing an excellent facility in which to have our meetings.  Encina Commons is one of the older buildings at Stanford – sandstone and arches and wide covered patios, surrounded by lots of green – a perfect atmosphere for sharing.  We were lucky to get a reprieve from the rain for 2 days so that we could really enjoy the surroundings (and make the occasional trip for espresso).  Thank you to Lombardi, and Apex (and bp3) for sponsoring the dinner on Thursday night at Pampas – an all-you-can-eat Brazilian feast.

The lawn outside Encina Commons / bpmCamp

And thanks most of all to everyone who came and led a session, contributed their opinions, reached out to their colleagues and made new friends and contacts.  What a great experience.

We’ll follow-up with a series of blog posts based on bpmCamp to share some of the content with a chance to step back and editorialize a bit. The biggest takeaway that I had was that the community needed an event like this to step out of the daily grind of delivering processes and process improvement – to see what others are doing, to see the forest for the trees.  Sessions ranged in size from 5 people to 40, and discussions were often lively…

bpmCamp in Session

Meanwhile, we’ll start with a short session from Friday morning, when we had a cameo appearance from Phil Gilbert, giving his impressions of the acquisition and the plans for Lombardi products for the next 6 months.  There’s a clear focus on proving that they can deliver and innovate “even faster” after the acquisition, as Phil put it.  And they have set themselves some very high, but relevant goals.  In particular, making it as easy to install Teamworks on Websphere as it is to install Teamworks on JBoss today (cur

Phil Gilbert holds forth @ bpmCamp

rently JBoss is your option if you want an embedded appserver), and making upgrades to Teamworks 7 a truly good experience.  The goal is to bring the ease of use of Teamworks to IBM’s customers, and to leverage key IBM technologies but expose them in ways that let you cut through the noise and focus on delivery. It was a motivating message for our bpmCamp crowd because clearly Phil’s attention is still on the BPM game, and this prioritization will keep Teamworks relevant for the audience.  Knowing the developers that IBM/Lombardi are putting on this project and upgrade paths, I also know that this is a crack team of some of the best engineers at Lombardi, which says something about the commitment from the executive team.

Someone in the audience noted afterward that this was a more tactical set of goals than they expected to hear from Phil- who usually talks in terms such as “the Second Decade of BPM“… but if the focus on the tactical reveals that they believe the tactical may BE the strategic right now, I think its a welcome shift-  because truly, what’s holding people back from BPM is not the knowledge that it has value – the press and blogs are full of information on that score – but rather, its the “getting started” effort required that slows things down.  The easier a software company can make the transition from “business problem conceived” to “BPM project underway” the more likely it is that BPM software is applied to that problem instead of sticky notes and a change order on an ERP system scheduled for 2 years out.

There were so many more great sessions to report on, so there will be more posts here about the sessions.  One thing anyone reading this can do for me that will help – is let us know if you’d be interested in attending a future bpmCamp, and if you would travel to attend, or if not, where you’re located so we can judge where we have critical mass for another event.

Thanks again to everyone who participated, and watch this space for more information!

Also, lest you think that BPM was the only educational opportunity at Stanford last week, I stopped by the Cantor Museum for Visual Arts and took a few photos of Rodin sculptures – the collection is the second largest in the world and nearly every piece was on display:

the infamous "Gates of Hell"

A Career in #BPM Pays Off

Saturday, January 30th, 2010

Lest there be any doubt that BPM skills are in demand, Tom Baeyens has pointed out that SimplyHired stats claims the average jBPM salary in CA is US$114,000.  Not bad.  Lombardi BPM shows similar numbers.  It supports what we’ve been saying all along – BPM skills are in demand, and it should be a great career for the next decade (or two, or more).  Its just hard to see “process” going away as an important concept in business. So what the SimplyHired stats tell us is that the technical side of BPM is in demand – regardless of the tool set, there is a mismatch between supply and demand right now that is going to take time to fill – and knowing the technical side of the coin is only half of it – the other half being the business process side of things.  I can tell you from experience that not all great technical people have an interest in business process, and not all of them can make the adjustment to focusing on the process over the technology.

In the meantime, your best bet to get up to speed is to get a job that will let you learn on the job, attend training, etc.  There really aren’t any formal education programs at universities that are widely recognized (although there are a small number of universities that have a small number of opportunities to learn about business processes).  There are classes you can take from the software vendors or the likes of Bruce Silver, and there are certification programs-  but no sense paying for certification until you know what you’re doing.  Once you get started, then try to take advantage of the many resources on the net, and resources like bpmCamp.

More on #bpmCamp topics

Wednesday, January 27th, 2010

Continuing on the theme from yesterday, we’ll point out a few more topics here.

  • We’ll have a session (or several sessions) on UI frameworks inside and outside of Teamworks, discussing trade-offs of various approaches and benefits of each.
  • The relationship between the BPM solution and systems of record.
  • Offshore BPM – what is effective / ineffective – discussing real world experiences.
  • BPM Requirements Analysis – how much is too much?  How do you know when to say “when”?
  • A/B Testing for process improvement

I met with Lee Merrick at Stanford yesterday and we’ll be meeting again today for some final prep for tomorrow’s conference.  We’re excited and looking forward to working with everyone attending to create a great experience.  Thanks to everyone for supporting this idea with your participation and willingness to speak!

#bpmCamp Topics are Taking Shape

Tuesday, January 26th, 2010

I’m excited about the topics taking shape for bpmCamp this week, and I’m going to send out a few teasers before the event starts on Thursday morning.  We’ll do our best to capture as much as we can and share insights with readers of this blog as bpmCamp happens, so keep an eye on this space or bookmark the bpmCamp tag.

Some of the sessions we’re looking forward to:

  1. Phil Gilbert is going to stop in to discuss the acquisition by IBM and take questions from customers.
  2. We’ll have a few members of the Lombardi product team in attendance to give us some insights into Teamworks 7’s operations, and upgrading to Teamworks 7.
  3. We’ll talk about what “Fixed Effort” means as a way to focus on delivering value.
  4. A case study discussion of an application of Agile to a project.

There are 20 other topics on the potential list, more to come tomorrow…

Interesting Read on Hadoop Math

Wednesday, January 20th, 2010

Ok ok, what could possibly be interesting about Hadoop-based systems and Mathematics?

Well, it sounds fancier to say Hadoop-based system… but really this basic math applies to any batch-oriented system and those of us who have been writing batch processing solutions now-and-then for the last 20 years should at least be intuitively aware of the math presented in this article, if not consciously thinking about it at design time.

The key equation:

Runtime = Overhead / (1 – {Time to process one hour of data})

Or, stated differently:

Runtime = Overhead + {Time to process one hour of data} * {Hours of data}

Where hours of data and runtime are equal.  These equations help explain why a perfectly healthy batch processing system can suddenly fall tragically behind – if the time to process an hour’s worth of new information is greater than an hour, you have a problem – and the problem will just keep getting worse until you:

  • Improve the runtime of the algorithm
  • Apply more resources to your server / cluster.
  • Filter the incoming data better (if possible) to improve your signal to noise ratio and thereby eliminate unnecessary data processing

In the BPM and CEP worlds, often that third bullet is a key element to improving performance – it doesn’t require more hardware – it just requires you to move your filter “upstream” from your BPM infrastructure to your EAI infrastructure or your ESB infrastructure… or from your EAI/ESB infrastructure to the source of the noise… Some would say this is squeezing the balloon, moving the bottleneck elsewhere, but actually, filtering better up stream may make those systems more efficient as well (if generating the payload and calling out to a webservice or ESB requires cycles, then not doing it as a result of an efficient filter may well reduce processing cycles… )

At any rate, its a good read.  Andrew Paier, figured you especially would get a kick out of this article, given our experience back in 2003…

BPM is Dead. Long Live BPM!

Thursday, January 14th, 2010

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

Or is it?

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

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

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

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

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

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

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

[ fade to black and then the lights return ]

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

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

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

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