If you can’t make it to a BPM conference, Sandy gives you your best bet to keep tabs on it from afar.  According to her posts, nearly 300 attendees (customers, partners, analysts) attended, proving a point I made in a previous post, that there is a demand for conferences that are reasonably priced and a bit more tactically focused – and vendor-focused conferences are one way to achieve that focus. Look for more on that subject in this space soon…

A quick run-down of Sandy’s coverage:

• Don’t underestimate BPM, a keynote by Jim Sinur of Gartner
• Appian Corporate Update, in which Appian discloses a 150% revenue increase and 58% customer increase (I’m not sure if the latter is including or excluding their Appian Anywhere service, however).  This is significantly faster growth than Pega has reported, for example, and a good sign of the health of the BPM market.
• Appian 6 Product Update, with a focus on portal-building and being able to export all of the process as xml, so that it can be versioned in a source control system (this process sounds familiar to me from some other vendors).
• Customer Panel. Most interesting point Sandy reports is that the four customers cited all advised small projects to start – either because that’s what they did, or because they had bad experiences going with bigger projects first.

Lombardi’s October 2009 Blueprint Update was just announced.  Seemingly minor changes, but with interesting implications…

I would list them in reverse of the order Lombardi has listed them in their announcement:

First, increased notification options to keep you abreast of process modeling updates in your domain.  Of course, I’d like to see an RSS feed as an option rather than just email-focused options, but combining the email notifications with a good email filter and you can get about the same result.

Second, additional properties to track against the activities of your process.  Identifying systems, cycle time, cost, etc. That’s great… but by itself it is just documentation…

Third, leveraging those properties for heat-mapping and analysis of your process.  This is actually the whiz-bang feature of the release, and shows how a small incremental improvement on a good foundation can really change the way you look at a tool.  Prior to the analysis/heat-map, odds are you might just enter the data because it is “the right thing to do” to document the process for posterity (or for yourself).  Now you have a reason to do it that is for the analysis of improvement opportunities. I’ll point out, however, that without reading the release note, it would have been easy to open Blueprint and not even notice the “Analyze” button, and the fact that you can choose which attribute to base your heat map on is easy to miss.  But analysis mode works equally well on the process mapping view as well as the BPMN diagramming view.

What’s exciting about this release is that it offers a real reason to capture valuable data about your process… and it also opens the door for feeding information from your executing processes in Teamworks back to Blueprint for analysis (technical challenges remain, but it becomes increasingly obvious that this can be done).

We’ve covered Blueprint updates before.  For a summary, click here.

Five years ago I attended my college reunion at Stanford and I was surprised by how many of my peers were using Palm Treo phones.  At the time, the Palm Treo dominated the smartphone market in the US, but very few people really had smart phones.  Of course this was a fairly tech-savvy crowd, and it was no surprise that they were jumping on the newest productivity tools.

Fast forward five years, to the next reunion.  I didn’t see any phones in evidence that weren’t BlackBerries or iPhones.  Again, this crowd showed a specific phone preference though:  for the iPhone.  At dinner one night I noticed that 4 of the 5 of us had iPhones.  One of our party had a BlackBerry.  His was issued by a big firm’s IT department.  The rest of us work at or own small businesses – we could choose, and we chose iPhones.

You might think that these four iPhone owners were Apple fanatics.  But when I pointed out the iPhone to BlackBerry ratio, two of the iPhone owners expressed disbelief that anyone using an iPhone would be convinced to buy a Mac.  Clearly some of Microsoft’s positioning around pricing is hitting home as they felt that Macs were “$400 or more” more expensive than equivalent PCs (the gap is closer if you pick the same chipsets, memory speeds, graphics chips, etc. – and I think most people would argue the balance of the difference gets you the Mac OSX and the alumnimum unibody… fair trade).

So if pretty die-hard Windows/PC users are going iPhone, I think it is safe to say that the iPhone has a lot of runway.  I asked if any of them were looking at Android phones – no takers.  I think there is a hidden element of lock-in – which is not the *availability* of applications, but the money and time invested in owning existing applications on your iPhone.  When you “buy the app” you’re really only buying the app for one platform…

It wasn’t just me.  Check out the chart from Business Insider, adapted from Changewave survey results:

Or, the coverage from Fortune here. Clearly a lot of momentum working in iPhone’s favor at the moment. I’ll be interested to see what kind of smart phones we’re using at the next reunion. Or will we still be calling them phones?

Every once in a while you see a blog post or article that really rings true, as this one did, by Trent Hamm. The thesis of the article is that more money is not more happiness for your employees.  And especially when more money shows up as a proposed antidote to an existing dissatisfaction with the job.

Many years ago one of my former bosses put it this way – “Right now you’re not happy with your job.  If they give you a raise tomorrow, how are you going to feel about your job 3 months from now?  Is anything else going to change?” It really sent me back to the drawing board to think about the job I wanted, and not just the financial package I thought “made the job worth it.”  And it started me down the path of realizing that there was more to my career to manage than just the financial returns.

Over the years, managing my own teams, and acting as a sounding board or adviser to those managing their own teams, I’ve observed that usually when you have a problem that you or your team member thinks can be addressed with more money, you’ve already missed the opportunity to excite this person about your team, your mission, and the opportunity in front of them.  As an employer, if you are going to throw more money at the personnel problem, make sure that isn’t the only thing you do – invest in the person, invest in improving their work situation.

What we do at BP3 isn’t easy – traveling to our customers’ locations to advise them on their processes and to implement those processes in a BPMS package.  So maybe that makes us even more aware that we need to invest in the intellectual, personal, and professional well-being of our teammates.  We’re not always going to be successful retaining our team members, but we like to think that we appreciate them while they’re with us, and we’re thankful for their contributions in building BP3 into the company we can be in the future.  Hopefully that appreciation is equally apparent to our team members and our customers.

I was struck by a series of articles I’ve read recently regarding Outsourcing and how it is really hurting American businesses.  Robert Hayes raises the specter of the US possibly killing its Innovation Machine, and compares outsourcing of High Tech to the Subprime-Mortgage fiasco. He makes a few powerful points, for which it isn’t hard to look for data points to support.

The same forces can lead a number of manufacturing companies — each independently making apparently rational decisions to outsource certain segments of their operations — to ravage their industrial commons: the valuable infrastructure of suppliers and skills that underpins them. The supposed savings they expect to generate from such activities are based on costs that often do not properly reflect the damage they are causing.

As I read this, I think of Dell, once the pinnacle of the PC industry’s drive toward efficiency… But under the hood of Dell’s efficiency engine we discovered that a lot of their benefits had to do with financial engineering – taking ownership of inventory as late in the process as possible, owning the warehouses (and charging rent) that their vendors used to store their equipment prior to final assembly, and paying creditors as late as possible.  Reading on in Mr. Hayes report:

A company’s competitive advantage is rooted in things it can do (e.g. design, make, distribute, or market) that its competitors cannot do as well, if at all. As the number of these core capabilities decreases, the company’s competitive vulnerability to those that are able to master the same capabilities goes up.

This sounds like what Dell did – outsourcing the manufacture of increasing parts of the value chain, until you reach the logical conclusion, where Dell no longer does even final assembly of much of its inventory, it is simply the design, marketing, and distribution vehicle for other companies’ computers.  They reduced the number of areas in which they could differentiate from the competition.  And the competition (HP, Lenovo, Acer) have adopted very similar business models, and now enjoy similar (and in some cases, better) margins.  As Mr. Hayes writes: “[...] teaching an armada of hungry potential competitors first how to master, then how to surpass their capabilities.” Meanwhile, it is difficult to unwind this change in the food chain because the necessary infrastructure and skills to support manufacturing and assembly in the US has now been outsourced overseas (largely to Taiwan and China). Restarting that infrastructure in the US is a daunting task in dollars, time, and leadership.

Mr. Hayes makes a persuasive argument that these companies have not, in fact, been improving profitability – that they have instead been cashing out their intellectual property and assets in exchange for a temporary improvement in margins… Which is now evaporating.

Now that the field has been reduced to competing largely on: Design, Marketing, Distribution… Branding becomes more important.  And this probably explains in large part why Apple has been so successful of late -they can outsource the production efficiencies that Dell (and others) have produced in overseas outsourcing shops, and they can exceed these other manufacturers with differentiated software and hardware design and branding (The aluminum unibody Macbooks with Mac OS X are the envy of the industry), better marketing (Apple ads), and distribution innovation (Apple Stores).

What Mr. Hayes is arguing isn’t entirely new, but our titans of industry have been unwilling to listen.  In an issue of CIO magazine in 2005, the then-CIO of Aflac, Jim Lester, said that he wouldn’t consider outsourcing his IT because he couldn’t replace the organizational learning, the knowledge of the business, and the alignment with the business that he had in his current IT organization (some people call this caring about your company).  But he was a minority voice at the time.  The fact that his organization out-performed the insurance industry as a whole for the next few years might be unrelated, but I wouldn’t bet on it.  Of course if particular IT services trail the industry averages then it may make sense to switch to commodotized service offerings as a way to play “catch-up” with the industry – a firm will sacrifice its ability to excel in that area, but will eliminate the possibility of self-inflicted wounds in that area, while it can then focus on the areas it knows best.  One could argue that this is what Apple did with its back-end fulfillment – which trailed the industry in efficiencies – so that it could focus on its strengths in design without the drag of inefficient manufacturing operations.

I worry that over the last 10 years, the US been on a similar course with regard to software development. Increasingly attempting to jam down the costs of software developers, and going anywhere in the world in order to achieve it, without regard to the specific qualities of the firms they are outsourcing to.  If this goes too far, we’ll lose the critical ecosystem here in the US that supports software developers (and many software-related professions and the businesses that are based on them).  I see signs of this in startups who don’t do any software development in the United States and assume that this financial engineering will give an edge to their “ideas”.  But what software has often proven is that ideas are cheap.  Execution is differentiating.   These startups are betting the farm on unproven execution resources, which then puts them in competition with hordes of competitors with fewer ways to differentiate.  Counter to this trend, I also see a number of firms now with hybrid software development models that include doing development on- and off-shore to gain some cost advantage but without losing the ability to try to differentiate on execution.

In a very cogent piece on the subject of Indian outsourcing in particular,  Jaisundar argues that IT can sharpen competitive advantages, rather than diminish them.  That India based service providers need to migrate from being order takers to a deeper relationship that can address business process problems proactively and cooperatively.  This is likely true, but it runs counter to much of the order-taking culture at these firms – it will take time to push the mindset in the right direction and to find and train the right people to lead them in that direction.

Meanwhile, there’s quite a bit of abuse of foreign workers going on in the US.  An expose in Business Week on this practice goes into excruciating detail of some of the worst cases.  However, BusinessWeek makes the claim that most employers are unaware that these abuses are being perpetrated by the staffing firms that they employ.  I don’t buy that argument.  I think companies bear a responsibility to know that the people they staff are legitimately employed, and brought to the US under appropriate Visas (for all the attention on H1-B visas, no one is talking about the vast abuses of L1 visas going on right now). Companies bear a responsibility to work with reputable firms – if they don’t, then it is with the intent of getting workers at below-market conditions, which normally can only happen when you have a captive or disadvantaged workforce.  This is a bit like buying a Cartier watch for $10 and pretending that you don’t know it either (a) isn’t a Cartier, or (b) wasn’t acquired in a legitimate fashion. The buyer has a responsibility to buy legitimate goods and services.

In another article, Charles Green blames the money-first-above-all-else culture of Wall Street (and, increasingly, the executive suites of large firms) on Harvard Business School.  Charles Green, himself an alumna of Harvard Business School, argues that HBS has failed to imbue our “Best and Brightest” with a well rounded perspective of business:

Harvard Business School led the charge away from an approach to business centered in relationships and commerce, and toward one rooted in markets and competition. They promised us competitive advantage and efficiency. They delivered.

Unfortunately, the cost of this change is that American business is not prepared for a world that is increasingly interconnected, and increasingly relationship-driven.  Its a great, thought-provoking read.  As a long-time professional services guy, hearing someone say that business is relationship-driven is a bit like hearing that the sky is blue.  Of course it is relationship-driven, trust driven, commitment-driven.  And when organizations ignore this or trample on these aspects of their business, the chickens will come home to roost.  But apparently this was hasn’t been part of the culture of Wall Street for some time.

These articles only scratch the surface of what I’ve seen lately in the press and in blogs, but I think each one captures a specific issue perfectly.  If you can’t differentiate part of your business, it may make sense to outsource it, but be careful.  There are serious landmines in outsourcing, and it isn’t clear that American businesses have correctly assessed those trade-offs for the long run.

As previously noted in this blog (see Putting the Band Back Together), we’re believers in hiring Heroes.  Meaning, you find and hire people that can, to large extent, “do it all”.  We want to be the tip of the spear, at the front of the phalanx, for our customers. And the reason we do this is because we believe that BPM deployments greatly increase their odds of success when you seed the team with a few really good people.  So I was very interested to see Chris Dixon’s article “Man and Superman“.  In it, he examines why some tech companies seem to thrive beyond their first great product innovation’s life-cycle.  He points out that Sony, Apple, and Microsoft all achieved this, but all were driven by a “Superman” during that time.  In each case, when “Superman” wasn’t around, the companies did not fare so well.

I once worked for a company that, at the time, believed in great people making a difference.  We studied works like Covey’s Seven Habits, and Jim Collins’ Built to Last (and later, Good to Great).  However, at some point management decided that employees were highly expendable and fungible (the term “resources” entered the lexicon).  The company is a shadow of what it once was.  Reading Chris’ evisceration of Jim’s thesis that great companies are all about culture, not a singularly great leader, I can’t help but wonder if Chris has it more right than not.

Chris points out that most of the companies Jim profiled have since fared poorly – and not just with respect to the current economic climate, but with respect to the S&P 500 (Circuit City, for example, went bankrupt).

Culture might be important – but if you’re Superman in your organization, you better find another Superman to take over when you’re gone.  The real lesson to take home from his post is that people count.  Having good people counts.  Culture alone is not enough.  At BP3, we’re going to keep focused on hiring Heroes – perhaps we won’t live up to the Superman label, but we want the best, and we want people who are driven to keep expanding their abilities and who aren’t satisfied with status quo.

Ok.  Forrester didn’t really say that.  But in Ted Schadler’s article “The State of US Workforce Technology Adoption“, point #4 says practically that:

Gen Y employees are getting squashed at work.These younger workers behave very differently from others outside of work, but they are not so different in how they use technology in their jobs. Sixty percent of these 18- to 29-year-olds use social networking at home, but only 13% use it for work — the same percentage as Gen X employees ages 30 to 43.

I wouldn’t have said squashed.  That’s a characterization based on the assumption that Gen Y uses more technology than Gen X.  But only 13% use these social networking tools at work.  For all the carping I’ve heard about Gen Y using Facebook at work, one our own Gen Y members recently told me he quit using Facebook entirely and doesn’t miss it.  My personal theory:  like everyone else, Gen Y folks value real relationships more than virtual ones and eventually everyone finds a balance.  And at the end of the day, there’s work to get done.

Maybe, someday soon, we can stop this “generational” management stuff and get back to work.  But sure as I say that, Fortune will coin a term for the next generation.

Forrester makes some additional points that are worth noting:

There is pent up demand for smartphones. Only one in 10 information workers has a smartphone for work, but one in three agrees that they use a personal mobile phone for work purposes. Twenty-one percent of iWorkers would like to get email outside of work, and 15% would like email on a smartphone. Any way you slice it, this means that there is pent-up demand for smartphones at work.

It is amazing to me that still only 1 in 10 information workers has a smartphone for work.  Even more amazing: over the last couple of years I’ve seen Fortune 500 companies pull back their subsidies for smart-phones for work – essentially cutting off their information workers from company information during off-hours (and work hours while not at their desks).  The benefits of that connectivity confer primarily on the corporation, not on the employee, but apparently these firms felt that the costs outweighed the benefits.  In our business, we make sure that everyone has a smart phone.

In another note, Forrester points out that collaboration tools are stalling out – leaving email as (still) the primary collaboration platform.   Of course, this makes sense: everyone has email, even if they don’t use your particular email platform.  The standards for email are well-established and widespread.  But to use a collaboration platform, we have to ALL use the same collaboration platform.  For those who have received early invites to Google’s Wave, I’m sure you can relate:  being early into the collaboration platform is like having Instant Messaging with no one in your contact list.  Who exactly are you going to collaborate with?

This could mean that collaboration tools that leverage email will have an edge over new platforms.  It also means that collaboration tools that suit a particular niche (Business Process Modeling for example) are more likely to draw the appropriate audience than generic collaboration tools.

UPDATE 10/22: I just read this article about Gen Y preferring to keep email over social networks, and it just sounds like more confirmation to me of what I already believed- the generations aren’t fundamentally different in big swaths of people as the media prefers to portray them – the labels are a convenience and contrivance to talk about people “of a certain age” without specifying exactly what that age is.  There are some questions on the validity of the study, but it is still a reflection of the realities of life imposing on social networks once people reach maturity.

In a breakout session at Lombardi’s Driven 2006, I was paired with a gentleman from BearingPoint to discuss BPM vs. SOA in our session.  My central thesis at the time was that the value-proposition of SOA was primarily directed at IT – while the value proposition of BPM was focused on business drivers (including ROI) – and as a result, SOA projects were much more likely to be successful if driven by requirements from BPM projects.  After all, work tied to ROI is more likely to get funded and get finished than work that… isn’t.

Recently I commented on Keith Swenson’s post, and then saw this ebizQ article by Glenn Smith, of Appian: “SOA needs BPM”.  Glenn articulates a series of excellent points to support the premise that SOA really needs BPM:

BPM can succeed, albeit more expensively, without SOA, but without BPM SOA is only an internal technology initiative which does not directly address any business problem.

I couldn’t agree more – SOA is grease for the wheel, but it is not the wheel. And then Glenn describes SOA as it was initially defined: as an architecture, not a product.  Again, it is nice to hear someone else saying what we all know to be true despite millions in marketing spend by stack vendors:

SOA is an architectural style for developing distributed systems. It is not a specific technology, but can be applied to many technologies. It encourages loose coupling of components and enables flexibility. Individual services can be modified with no impact on the consumers of those services. Services support reuse, and can help preserve and extend the value stored in legacy systems by making their capabilities more widely available.

He then goes on to explain why BPM benefits from the use of SOA, and why the traditional tensions between this camp aren’t particularly problematic because the very nature of the loose coupling of a Service Oriented Architecture (SOA) allows for the teams to operate largely independently and interact through well-defined service interfaces.

Welcome news: the academic-oriented BPM2010 will be in the US, according to BPM Research. We haven’t attended in previous years because it has never been in the US, and getting enough time out to go to Europe to attend hasn’t been possible so far for us.  Perhaps next September we’ll be able to attend.  But if history is any guide, the fall season will be quite busy with conferences.

I read this post when it first went across my reader, and I went back and read it again today.  Derek Miers once again proves his nuanced mastery of BPM, and I just have to recall attention to the posting.  Because what Derek does is point out that you find the BPM culture within your company’s culture, you don’t create it from whole cloth.  I can’t say it better than Derek did:

[....] I help them find a Well that shareholders, suppliers, customers, partners, the market and the community can all draw upon to enrich and energize their business and satisfy their needs.What do these Wells look like? They are the values that are at the heart of that business area. Collectively, these values give direction, guidance and are rich source of ideas and new ways of doing things. So, we do not need to boil the ocean, just discover what drives and inspires the business and its people to adopt new ways of doing things and developing new behaviors.

In this approach, internal drivers that everyone values (because they see the relevance to their own business and business success) replace externally imposed behaviors (as the means of creating culture). Values come from an eternal spring – energizing again and again – hence sustainability is not an issue.

I could have just quoted the most important line, but I think the context is important.  Here it is, again: “So, we do not need to boil the ocean, just discover what drives and inspires the business and its people to adopt new ways of doing things and developing new behaviors.” What interests me about this statement is that it is also true for how you create change in your personal life.  You find the deep values inside you that support the changes you need to make, and because those changed behaviors are based on core values that you are reinforcing, it becomes easier to support the change.  This concept is even more powerful in an organization because social and peer effects can reinforce the individual behavior changes.

I really enjoyed Mike Gualtieri’s post on Forrester’s blog: “Excuses, excuses: The Business Doesn’t Know What it Wants“.  The two big culprits:

• The business doesn’t know what it wants.
• The requirements keep changing.

But my favorite advice he gave to IT professionals immediately followed this:  “Get Over It”.

I couldn’t agree more.  Of course the business doesn’t know what it wants in BPM because they’re tackling a domain that is new to them (BPM), and they’re tackling a moving target (the Business Process).  And this isn’t unique to BPM, far from it.  And despite this, many projects are successful.  So obviously the fact that the business “doesn’t know what it wants” is not an excuse for failure.  If you’re collaborating with the business on a solution, help them figure it out by prototyping, iterating, and helping them understand implications they might not have though through.

The other bits of advice are equally good:

• Understand the Business and Your Users
• Build for Change
• Get Passionate about your Craft

Mr. Gualtieri notes that the “industrialization of software development has been an epic fail.” I agree.  From my point of view industrialization was always the wrong goal.  Software development is more a craft than an assembly line.  One learns the craft through many thousands of hours of practice and through mentorship from masters of the craft.  And despite the fact that the news media and other nontechnical people view software development as utterly lacking in creativity and design, they are mistaken.  Software development is an intensely creative effort, when done right.  Which explains why so many projects fail when they go for the lowest-cost-possible staffing models.  In fact, BP3 and other boutique firms like ours are often brought in to rescue projects that were, at first, given to the low-cost provider.

Ok, no more excuses, BPM practitioners.  Let’s get out there and deploy some processes.

Mr. Uwe Roedinger makes the argument on Aris’ BPM Blog that you have to decide which “middleware infrastructure will be the ruling one.”

Essentially Mr. Roedinger makes a few arguments that I take issue with:

Characterizing a BPMS as “middleware” reflects the notion that a BPMS is just a scripting tool for SOA services… It isn’t.  There are middleware components in most BPMS solutions, but they are typically designed to tie into other middleware components that are intended solely for that purpose, not replace them. BPMS is more than just scripting SOA.

Arguing that you can’t make pragmatic compromises about hand-offs between systems – for example, at some point handing off (via an event or webservice) control of a process from one software package to another. Of course ideally you continue to monitor the progress of that process through the other software package, but for expediency or pragmatism, it may be necessary to short-circuit the unification of all things process.  Of course the purist point of view isn’t surprising coming from a modeling and enterprise architecture background as IDS/Aris does.  And of course ideally you abstract your processes into a higher level process controlled by a higher level process engine – but you can achieve nirvana over time, it doesn’t have to come starting with the first architecture design session, as Mr. Roedinger seems to imply.

Mr. Roedinger argues you must have transparency, and that to get this transparency you must have one process ruler. This sounds good, but our practical experience in the field tells us otherwise.  We have worked with legacy systems that aren’t integrated, but which provide a lot of transactional transparency through back-end reporting that is keyed off of common identities (a loan number, for example).  Additionally, we’ve introduced BPM solutions that address a portion of the overall process, and exposed incremental transparency for the process (in addition to the transactional data) for the portions we control, and then advised on portions outside our control to get the data we need for reporting (transparency).  After all, as long as the right data ends up in a datastore, we can use this data to expose what’s going on inside the machine that is the process.

Mr. Roedinger also implies that a process, implemented by BPMS A, can be reduced to a webservice call from the “ruling process”. I’ll assume he means an asynchronous call, because the processes we deal with aren’t so trivial as to execute in a few seconds and be wrapped by a simple webservice call.  So, from an abstraction point of view he makes a good point, but in reality, an asynch webservice call is just two webservices calls separated by some time.  At this point, we’ve devolved to the “hand off an event through the middleware” scenario that he described – with the notable difference that one process represents the “parent”.

To that end, in several instances we’ve implemented a “shadow” process – which monitors the process being performed in other applications, to create unified process metrics, and initially simply to monitor, with the controls coming in only after one has had time to analyze the data.  I believe this sort of solution is closest to what Mr. Roedinger describes as the “right” approach – but again I’ll stress the incremental nature of such a roll-out strategy.

Finally, Mr. Roedinger makes use of an example where the customer was choosing between SAP’s BPM and IBM’s Websphere BPM:

My conclusion is, and the experiences from different customers prove this, that the decision for the leading process engine is one of the first that has to be made in an automation project. Kind of a best practice decision has been made by a big German customer, where SAP and IBM technology were set as standard. The SAP internal processes will be automated with SAP XI, the overall processes by IBM WebSphere. And, very important from IDS point of view, all of the processes are modeled with ARIS and used as input for the different implementation tools ;-)

This isn’t really a decision – the BPM that SAP offers simply isn’t general purpose enough to drive the processes outside of SAP.  Moreover, I’m not sure IBM’s offering is strong enough to manage processes inside SAP without deconstructing them.  If you start with a truly general purpose BPMS, and SAP – this decision is a no-brainer.  The BPMS can be used to implement processes that aren’t addressed by SAP.  Or the BPMS can be used to leverage SAP in processes that extend its usefulness, including monitoring or being notified of changes within SAP, or even effecting those changes via SAP.  Who rules isn’t the key question to me – its where can I extract the most ROI?  And I think the key thing IDS is after is that Aris be the ruling “process modeling” software.  Which, if IBM and SAP are your BPMS choices, is probably not a bad idea.

We would encourage people to be flexible and pragmatic in their application of BPM, and don’t dramatically change your project just to accomplish a “ruling process” strategy.  Keep your ultimate strategy in mind, but get your project done with a laser focus on the business objectives.

One of the sessions at Forrester’s Business Technology Forum 2009 was a lunch session sponsored by Appian on the subject of Iterative or Agile development and BPM.

Sandy Kemsley quotes Tom Higgins of Territory Insurance Office in Australia as saying “Waterfall contracts and iterative development don’t mix.” Apparently he spent quite a bit of time talking about the contractual aspects of the project they took on with Appian, and Sandy took the opportunity to comment as follows:

The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk.

It is certainly true that waterfall contracts (often milestone or deliverable contracts are really waterfall contracts, so beware) are not an optimal fit for iterative development.

Having said that, you may find yourself in a situation not of your own making – where a Waterfall contract has been put into effect, and you have the responsibility of delivering the project.  At such times, it is still in your interest to convince the project team to go down an iterative path and get the contract revised to reflect it.

At BP3 we have been brought into just such situations when major outsourcing shops bring our firm in to help lead a customer BPM deployment.  We articulate the value to both parties to help them see the light that although the Waterfall contract would allow a lot of choke-the-vendor opportunities, and a lot of change-order opportunities – it would also bury the team in change-order requests, and it would likely fail to meet the business objectives and time-lines.  We do this by making a simple commitment to both parties:

1. The business will prioritize the work in each iteration (In other words, the business MUST prioritize).
2. The delivery team will deliver the highest priority work in a quality, repeatable fashion (in other words, technical team will honor the business’ prioritization decisions)
3. The iteration will be accepted if the business accepts it as having substantially delivered their top priorities and as having prepared the team for moving to the next iteration.

The difference in productivity, and in the tenor of the relationship is dramatic.  Of course we have to follow up words with deeds – delivering value, and delivering on the priorities the business has set for the team.  We have to take commitments seriously.  After establishing a pattern and habit of success with this new paradigm, we’re much more likely to achieve success.

A more common scenario is to get into a waterfall-methodology-oriented environment, where the contract may be more generally structured (perhaps even T&M).  In such cases, we have had a lot of success in applying iterative and/or agile techniques within the overall waterfall framework – including characterizing early development work as prototyping or design work, in order to pull some of the riskier technical or requirements issues to an earlier point in the deployment.

Regardless of the situation you find yourself in, you’re going to be better off if you can apply iterative techniques to your BPM deployments.  Once you apply those techniques, success will reinforce the approach.

Sandy makes another point in her post about working with people you trust – I couldn’t agree more.  If you don’t have that trust in your customer relationship, you have to work hard to earn it. If you don’t trust your vendor, find someone you do trust.

As a proposal, challenge yourself to think about your project as “Fixed Effort” rather than “Fixed Price” or “Time and Materials”.  What is Fixed Effort?

1. Honor the budget by deploying the process within the allotted budget.
2. Use iterations to always stay close to a production-worthy deployment.
3. Always work on the highest priority elements that meet the business objectives, and get you as fast as possible to a “minimally viable process” (For more information on this subject, look for Minimum Viable Product or MVP).

This approach honors the realities of the world that are often ignored at the peril of the project and its team members:

1. The Budget is LIMITED.  Fixed effort honors that by delivering a production ready process with real ROI within that budget.  Let’s say that again:  a Fixed Effort project honors the budget by delivering a production-ready process with real ROI within the budget.
   
2. Wrong requirements are among the most expensive mistakes a project can make, if they make it to production.  Iterations and Agile methods will expose these missed/mistaken/wrong requirements earlier in the process.
3. By always staying close to a production-ready release, at any time the Business should be able to say “this is good enough” (translation: we have a minimum valuable process), and you should be within just a couple weeks of going “Live” by doing a little cleanup and final QA before go-live.
4. By focusing on the business priorities, we’re focusing on the parts that add the most value / ROI – rather than the check-boxes that might meet IT requirements or might make us feel better about the project.
5. If pieces are left off in the end – they are likely less valuable and provide less return than the parts we’ve already implemented.

I realize “Fixed Effort” may not catch on in popular lexicon, but it keeps you focused on realistic budget in BPM projects.  The requirements aren’t fixed, as they are in a typical “Fixed Price” contract, so the vendor can’t easily commit to delivering static requirements.  A Fixed Effort approach is the way to address that requirements risk, while still addressing the budget risk.  Its a balanced approach, and managed properly, it works really well.

Ismael has a pretty good summary of cloud computing from the “business point of view” – which is to say, it largely avoids making a sales pitch on technical grounds, and simply makes a pitch on business terms -

• Utility Pricing
• Elastic Resource Capacity
• Virtualized Resources
• Management Automation
• Self-Service Provisioning
• Third-Party Ownership
• Managed Operations

Good stuff. check out Ismael’s post for all the details.  This makes me want to dig up a 7 elements of BPMS value.  I’m sure someone has already codified that quite nicely.

The BTF09 Event can be summarized in one word, literally:  LEAN.

I have to hand it to Forrester, someone decided Lean was the message of the day, and they have delivered that message consistently.  You can find the feed on Twitter here.  To  make it easier, use this link instead to see the lean references along with #BTF09.

A quick review of Sandy Kemsley’s write-ups of sessions yields the following topics that refer to Lean:

• Why Lean is the new business technology imperative
• Lean and the CIO
• The Power of Lean IT
• Embrace Lean thinking to enable innovation
• How can Lean Software Enable you to Better Serve the Business?
• Can packaged Applications ever be Lean?
• Forge your Lean process improvement gameplan
• Lean application development strategies.

There was even a UX design session where the presenter made the argument that UX design is “Lean”.

Someone should have tweeted that all this tweeting isn’t very “Lean”…   And I guess no one had the discussion about whether attending a conference is “Lean”… Which is precisely why we shouldn’t try to apply the word “Lean” as Good and “not-Lean” as Bad.  Not everything we do that has value is “Lean” – something I am acutely aware of having had to read “Pigeon Wants a Puppy” to my daughter twice the other night.  It wasn’t Lean, but it had a lot of value!

There is a sense from reading all the traffic on twitter and blog posts that Lean is good and Not-Lean is bad.  Honestly, I don’t care if “SalesForce” (insert favorite SaaS product) is Lean, but I do care if my “Sales Process” is Lean.  And even more than that, I care if it produces reliable revenue streams at reliable cost outlays.

I don’t care if a COTS (Commercial Off-The-Shelf) Software package is lean vs. custom-coding being lean – I want the solution that solves my business problem with minimal cost and maximum fit for purpose, and I care that the processes that require this software solution continue to operate “efficiently”.  More simply – whether my car was constructed in a Lean fashion or not, how I use a vehicle in my business may prove to be Lean (or not).  The car at the point that I care about it, is already a finished product and I take it or leave it largely as-is.

To the extent that the point of Lean is to eliminate waste, you can almost characterize anything that eliminates waste as Lean – but that misses the point of using Lean as a process improvement method.  And Let’s not forget that you’ll still need other tools in your utility belt – six sigma for identifying and eliminating defects and variance, software for maintaining a good solution over time, and leadership to get your project over the finish line in challenging times.

Taking a step back, we have to remember that Lean is a means to an end, not the End itself.

Keith is consistently writing the clearest thoughts on the subject of “Process Reification” vs. “Model Preservation”.

In this particular article on the subject, Keith focuses on a very common misconception in the BPM community (even by some well known names in the field):

I have met so many people that think that BPM is just a scripting language for SOA services.  These people will argue at length that “BPM is a part of SOA because SOA is useful without BPM, while BPM is useless without SOA”

(Notably, he also references a good article by JP Morganthal which sounds controversial – keeping your SOA and BPM initiatives separate, but which actually makes some very good points about why SOA and BPM initiatives are motivated by different organizational and business imperatives).

But BPM is not just a scripting language for your SOA services.  To quote from Keith’s blog: “SOA is a tool we use, while BPM is what we do.”   I think this is a really important dichotomy to understand, and explains precisely why so many companies that purport to be in “BPM” still don’t really get it yet.

An article in the NY Times recently caught my attention because … well it was about Tablet PCs.  Interestingly, much of the coverage comments on the buzz behind Tablet PCs lately, without fully realizing that it really isn’t buzz about a new category of product…

It really sounds like buzz about Apple’s possible offering of a Tablet PC.  All mention of other products and vendors inevitably turns to what Apple might release, or compares the product to the existing tablet computer – the iPhone.  And while there are some Kindle fans (and I’ve seen a few on flights lately), the volume is small so far, and the product is downright ugly.  The same goes for virtually every other pretender to the Tablet PC throne.  What everyone is waiting for is for Apple to redefine the category with something eye-catchingly beautiful.  It is going to be hard for Apple to live up to the expectations at this point… but equally, it is pretty well impossible for anyone else to live up to the expectations.

Similarly, there was an announcement that Apple purchased Placebase in July – with most articles wondering if this reflected tension with Google.  But I tend to agree with this article by Michael Hicks – that Apple is after the layering know-how to create “Augmented Reality” applications and features for the iPhone.  And my guess is that they’ll release an AR API for the iPhone to make it easier to write such apps as well (just as they have good APIs for animation and touch-gestures).  This line of thinking is similar to why Apple bought PA Semi previously – not to build its own chips, but to design chipsets and collaborate with chip manufacturers on low-power, high-performance designs (we’ll have to wait and see if that is correct, however).  It seems likely to me that some combination of AR features or apps will change our lives in the near-future much as the smartphone has changed our lives in the present (picture that green fidelity line actually painted in your vision in front of you).

Not sure that any of this will impact BPM, but I’ve covered enough Apple topics I hope any regular readers will forgive my indulging in yet another post on the subject.

I recently wrote a guest article for Austin Startup that just went live today here, about Conformity, a startup in Austin attempting to solve a core process problem for enterprises using SaaS and Cloud applications – how to manage, govern, and provision these applications in an enterprise that cares to protect itself.  Its a clear need in the market and another demonstration of the confluence of enterprise and Web 2.0 innovations.  If Conformity is successful it should help make SaaS applications (even BPM SaaS applications) more palatable to the Enterprise market.  Thanks to Bryan Mennel for the opportunity to contribute to the discussion.

Stanford and Google have joined up to create an endowed chair in honor of Dr. Rajeev Motwani, who passed away earlier this year.  As the number of Computer Science enrollments at Stanford have grown over the last few years (12 percent just this year alone), Stanford has set about creating 10 new endowed chairs for the department, which, as Stanford points out, Dr. Motwani would have approved of wholeheartedly.  My father was the chair of Political Science for two different universities in his career, and I witnessed how he set up an endowed chair for his predecessor, who left substantially all of his wealth to the political science department of the University of Florida.  Its really one of the great honors that a university can bestow on one of its own.  I also witnessed the way the faculty debated how to fill those chairs with someone who could live up to the goals and aspirations of the endowment.  Often these endowed chairs take on a personality that reflects the prestige and career of their namesake and the ideals they were invested in.  As reported by Stanford:

In the spirit of honoring Motwani, the professorship will go to a distinguished senior faculty member whose work is like his: deeply rooted in computer science fundamentals and the underlying theory, but also applicable to important practical problems within and beyond the traditional boundaries of the discipline.

Thank you Stanford and Google (Larry and Sergei especially) for doing this for Dr. Motwani.  It may seem like a small gesture in the big scheme of things, but it is an incredibly appropriate one.

Unfortunately we at BP3 couldn’t attend Gartner’s conference in Orlando this fall – we’re all busy helping customers with their BPM initiatives this year and couldn’t break free for it.  No doubt there are many BPM practitioners in the same situation.  This page is dedicated to you.

I’ll do my best to harvest good blog posts and twitter links that are relevant to the conference – but please feel free to add your own in the comments section below (no registration required).

First, Sandy Kemsley is the undisputed champ of covering BPM conferences – as previously demonstrated by her attendance at just about every conference I can think of.  For the full coverage from Sandy’s blog, this link should help.  I’ll also call out some individual articles.

• Keynote coverage by Sandy.  BPM remains at the center of focus for many companies, as a way to manage growth or create efficiencies with limited or flat budgets.  An increase in interest in the “unstructured” process space.  A list of must-haves for your software suite.
• Patterns presented by Benoit Lheureux and scribed by Sandy.
• Interesting session on the benefits of process tools and which ones to use.
• Elise Olding and Carol Rozwell’s session on the cost of unstructured processes (thx to Sandy).  I think the real takeaway from this one is that the TRUE cost of unstructured processes are all the elements within those processes that ought to be structured or streamlined out – and then what remains are those well-defined parts of the process that really can’t be put in a box.
• A Pega customer (JPM) gives a case study about Centers of Excellence (again, thx Sandy!)
• BPM Optimization and Simulation (captured by James Taylor).  Jim Sinur emphasizes using simulation and optimization to think outside the box, but in a safe environment (sandbox?).
• Bare essentials of making rules work (James Taylor), a session by Jim Sinur and Dave McCoy. Good post and I agree with his assessment on not focusing on “forward and backward chaining” and the like – its a bit like focusing on what kind of fuel injection your car has, rather than just wanting to know if it will be reliable and get you from zero to 60 in some reasonable time-frame.

Of course, check out the twitter stream if you want to see updates in 140 characters or less.

So what did I miss? Any other coverage from day 1?  I’ll add some Day 2 links here tomorrow.

UPDATE FROM DAY 2:

Almost every link I saw in the twitter feed today was referencing Sandy or James Taylor, so here are they’re blog posts that captured their thoughts on the sessions they were able to attend.  Not as good as being there, but almost! Thanks for sharing you two -

• JT’s notes from Jim Sinur’s “Dynamic BPM and Agility” session.  Deeper coverage of themes that Jim has covered in his blog.  Sandy’s take here.
• JT’s notes from Nancy Pearson’s “Business Agility Now!” session (about IBM’s initiative of that name). I guess there are some corporations that might look to IBM for advice about how to become more Agile, but it isn’t the image of IBM I have in my mind.  Lots of marketing dollars and real project results are going to be required to change that impression for most folks (or at least, anyone who has had to install Websphere before). Amazingly, they’ve announced “Version 7″ – it seems 7 is the new popular version number in BPMS suites.
• Sandy’s notes from JT’s presentation on Advanced Decisioning. A choice quote that I couldn’t agree more with: “Simpler: If you build all of your rules and decisioning logic within your processes – essentially turning your process map into a decision tree – then your processes will very quickly become completely unreadable. Separating decisions from the process map, allowing them to become the driver for the process or available at specific points within the process, makes the process itself simpler.” Good summation.
• Sandy’s notes from “The five dysfunctions of a team“.  This is a great one to read – and note the emphasis on low turnover, and “health” of the team.  And much of a successful team leads back to the qualities and behaviors of the leader.  Leadership is essential to successful BPM – and I think anyone deploying BPM solutions should think this through.
• Sandy’s notes from the Fujitsu process discovery case study, using an automated process to “discover” a process, rather than manually defining it.
• Sandy’s notes on social networks and BPM, clearly something of interest to Sandy and this is one of her best-covered sessions.