Adam Deane on Business Users and Programmers:

But the best differentiator pitch that I’ve heard being used is the “business user oriented” vs “programmer oriented”.
The claim is that business users can use the tool. I think it’s a great differentiator.  Although it usually doesn’t have much truth to it – it’s still a great market positioning pitch.

You see.. (and I’m trying to hide my sarcasm here..) BPM tools that use programming are bad for you.

If you need to open Visual Studio to build a workflow – it means you need skilled programmers, which means high salaries, and they need to write code, which means you need a tester, a team leader and a project manager (more salaries).

Every time the customer wants to change the business process you need the programmers to recode, recompile, retest (long deployment, or no changes – you can pick). Sophisticated code means that you need to rely on the IT team which means that you are tied in with that programmer/team. If the programmer leaves – no one will dare to change their code (who wants to be responsible for code that someone else wrote.)

“If you need to open Visual Studio to build a workflow” – then you’re doing it wrong.  A good bpm tool doesn’t require you to build your workflow in C++/C# or the like.

Of course if you’re opening visual studio to do an integration – have at it.  To build something custom that will plug into your BPM solution – have at it.  BPM should make certain things easier than traditional development tools (and a “workflow” sounds like one of those things to me).  It doesn’t mean that you won’t still need traditional development tools for a BPM deployment, but you shouldn’t have to write your process flow in assembly language any more than you should have to write it in C++.

Incidentally, I don’t agree that “business can do everything” is a good pitch, though I do agree with Adam that it is horribly oversold.  The business and IT have to work together to make BPM successful (or, arguably, nearly any long-term IT or business investment).  Vendors oversell this all the time, which accounts for Adam’s sarcasm.  But, conversely, companies purchase tools that bring too much complexity to the simple stuff, or tools that start simple but don’t scale with complexity.  What do I mean?  I mean that as you add more process intelligence to your tooling, complexity should increase at a linear (or less) rate.  If you experience complexity increasing at a greater than linear rate, you’ll hit a point where the system can’t be maintained – the interconnectedness and interdependency of the system is too complex for someone to properly understand, modify, and maintain.

That’s why it is important for the “workflow” to be simple.  Because it can be.

The phrase “It just works” didn’t first come into use during Apple’s WWDC 2011 keynote in June.  I first heard the phrase with respect to software when I was taking a NeXT programming class (cs193e) at Stanford – Julie Zelenksi, our lecturer, had three phrases that stuck with me for life:

• “Right?!” – affirmation, agreement, eliciting agreement, filler, etc.
• “That’s a feature” – when confronted with a bug or lack of a feature… obviously meant in jest.
• “It just works” – describing the magic of many of the object oriented techniques we used in class – reflection that just worked, prototypes, messages, Interface Builder and AppKit.

(I wouldn’t even claim to be there near the beginning – these phrases had the well-worn comfort of years of personal use even the very first time I heard them.)

At WWDC, Steve Jobs trotted out the phrase again, as a worthy successor to recent superlatives like “magical” and “amazing”, and it caught the attention of journalists (Philip Elmer-DeWitt has a great collection of quotes from some of the best articles covering the WWDC). But as MG Siegler notes, it isn’t an accident when Jobs picks a catchphrase like this.  It is intentional choosing and repetition to enforce a message.  I don’t doubt for a second that the *internal* messaging behind the scenes at Apple was similar, with Steve Jobs demanding that iCloud services “just work” without requiring explanation as to why or how.  Its a perfect kind of demand – no, don’t tell me the 15 reasons something doesn’t quite work the way I want – just make it work.

This contrasts harshly with the Android ecosystem, as noted by John Gruber, and fully expounded upon by Harry McCracken in Time (John captured the money quote perfectly):

But there’s never been a time when so much of the new stuff I look at is so very far from being ready for mass consumption. Sometimes it’s a tad quirky; sometimes I can’t get it to work at all. And when I call the manufacturers for help, they’re often well aware of the problems I encountered.

The pressure Apple is putting on other handset and computing manufacturers is causing them to release buggy, beta product.  And their primary software partner this time around is a company that mostly ships products in Beta status (Google):

One notable example was Motorola’s Xoom tablet, which arrived back in February with rain checks for three of its notable features: 4G support, Flash, and support for its MicroSD slot. Today, some owners have the update that enables MicroSD, others don’t, and everyone’s still waiting for the overdue 4G upgrade. Sounds like a beta product to me.

Contrast to what Apple is attempting to do – “it just works.”  As MG put it with respect to iCloud:

With iCloud, Apple is transforming the cloud from an almost tangible place that you visit to find your stuff, to a place that only exists in the background. It’s never seen. You never interact with it, your apps do — and you never realize it. It’s magic.

Exactly.  The cloud is in the background rather than front-and-center.  And while Google provides for a good cloud experience for technophiles like myself, the cloud *is* the experience, via the browser.  Apple wants the cloud to be invisibly supporting what you do with your devices – devices Apple sells.

This focus on simplicity has benefits.  iTunes may not be the prettiest software from a firm known for good design, but “it just works” – and it appears to be the first platform approaching 1 billion users in a logarithmic way even as it passes the 220 million mark. iOS’ growth curve is following an even steeper trajectory.  The market seems to be saying that “it just works” matters.

MG Siegler follows up with:

And the truth is that this is the point where we may really start to see some truly fundamental differences between Google and Apple after the past few years going head-to-head with feature matching. Apple is going after consumers who have absolutely no idea what the cloud is, and don’t care. Apple is saying they shouldn’t care. It all just works.

Actually, it isn’t just targeting consumers who have no idea what the cloud is.  It is also targeting technophiles who just frankly are tired of dealing with everyone else’s beta software.  At some point we want tools that “just work” so we can get our own, more interesting, technical work done.  If anything, the most advanced technical people I know are even *more* appreciative of the magic behind the black box.

But lest you think that Apple has given off the feature-matching in favor of the iCloud, Marco Arment reminds us that actually, the feature completeness efforts of Apple are like a steamroller:

Every time iOS or the iPhone is updated, Apple picks away at that list. They started with the big ones: purchase price, 3G, GPS, copy and paste, advanced security features, Exchange, multitasking. More recently, they added Verizon support, and it wouldn’t surprise me to see them quietly hit Sprint and T-Mobile in the future, picking away at that list even further.

With iOS 5, they’ve hit tons of relatively minor shortcomings. Notifications. Quick camera access and a hardware shutter button. Wireless sync and backup. They’ve even added a preference to have the camera-flash LED blink on new notifications, supposedly as an accessibility feature, but also conveniently to appeal to BlackBerry owners addicted to that blinking LED.

Apple has steamrolled over almost every meaningful advantage that competitors have. And they’re not stopping.

I think Marco is right.  Apple started with the differentiating NEW features (integrated iPod functionality, and touch screen interface) and then rapidly added to its arsenal (3rd party apps, cut-copy-paste, multi-tasking, etc.).

This is just further evidence, if that was required, that Simplicity is a great design principle.  If calling it “it just works” helps drive the point home and make it an easier rallying point, I’m all for it.  BPM and enterprise software vendors take heed-  we all need a bit more “it just works” in our software experiences.   This logic also needs to inform consulting firms – we need to treat usability and user design as a first class citizen – but failing that, we consultants need to ensure that our processes “just work” for our audiences…

I’m with Stephen White on this one:

The process above is not an extremely complex or hard to understand BPMN Process, but it is a perfectly valid one. BPMN was fully intended to support such modeling. So what is the problem? Why are there complaints about BPMN?

Look, BPMN has more complexity than it needs to have for many uses, and less complexity than it needs for other uses, but I’m with him on this one.

Is it too complex to use for simpler models? No.

Do these simpler processes require too complex a BPMN model to be understandable? No, they do not.

To me, the focus on complexity is a bit off.  The issue is expressiveness.  I don’t think that BPMN is too complex for the expressiveness it provides.  What makes one tool better than another has a lot to do with its expressiveness.

Stephen has it right when he says “The burden, then, is not on BPMN as a specification, it is on companies that develop process modeling tools or methodologies to help their users effectively create business processes – using the BPMN language.”  (Of course, it would help if the spec writers don’t get too carried away, and actually take a break for a while to see how BPMN2 shakes out before starting on a new version).

He has it right because often these simpler conceptual models evolve into more complex executable models (or just more detailed models), and it is reasonable that the same people who understood the simpler model want to be able to see and grasp how the more complex versions relate to the original simple model.  As we’ve commented before, most business users can get by on just a fraction of the BPMN language.

Great blog from Adam Deane on “the Go-Live Milestone“:

It’s an important hurdle for the vendor. It’s an important hurdle for the customer.

Attitudes change. Tensions evaporate. Management and end-users are happy. The euphoria kicks in.
Pink tinted glasses get put on again. Life is lovely

“Go Live” is probably the most interesting time in the life of a project.

The future looks bright. People start talking about replicating success, excellence centres, rolling it out to the whole organisation, to their customer’s organisations, to their customer’s customers… world domination.

But for a developer, “Go-live” is just a formal milestone in the project. You get the pat on the back from management, enjoy 5 minutes in the sunshine, and then back to the drawing board.

I think that one of the great failures of many consulting firms and IT groups is that they don’t celebrate enough at go-live.  Although, as Adam puts it, the real milestone for developers is dev-complete-  at BP3 we always reward Go-Live. Because dev-complete isn’t the finish line.  It is close, but it isn’t the finish.  And getting software to production in Fortune 500 companies is hard.  It is worthy of celebration.

Do software developers celebrate finishing a product release?

Do sales people celebrate making the sale?

You bet they do.  It is important to keep this culture of celebrating success in consulting as well.  Don’t let Go-Live just be another day on the calendar.  The team that got you there are your heroes, celebrate accordingly.

We have a process improvement case study.   Someone scheduled our all-hands meeting for BP3 in the midst of a heat wave that has set records all year long in Austin, TX.

A quick analysis was performed – corrections for the next process run were clear – schedule later in the year (October), pick a different location (Minnesota for example).  But the real question is how to fix the immediate process failure.  Sure the meeting itself was in the air conditioned confines of the fabulous Stephen F. Austin… but outside was an oven.

Not to worry.  Process improvement yielded a sure-fire way to cool down, with a low probability of failure:

Sure, not everyone jumped in the lake, but many of us embraced this process improvement with gusto, as you can see.

If the lake didn’t work, we could call in reinforcements.

I’ve said it often, but the people in your business – and on your projects – matter.  Doug Turner writes on his blog, with a slight twist to an old time-management proverb:

Well the issue of throwing more people at a solution and not getting to it any faster still exists, but now we have a new problem. Not only are we attempting to solve a problem by just throwing resources at it, we’re not even throwing the right resources at it for it to get accomplished at all. If you don’t begin with the right team, you’re not going to get the results you were hoping to get, no matter how positive your outlook, or how insistently you promised your superiors the job would get done.

My favorite passage, however:

With knowledge work especially, it’s the people and team you assemble that are going to make or break your solution. It’s not how much money can you, or can’t you, spend. It’s not how much time you do, or do not, have. It’s the people & their skillset that are going to help you to succeed. This is key to being successful.

You could just swap out “knowledge work” with BPM.  Doug’s blog ties back to a point I’ve made time and again with customers and colleagues, and on this blog:  an hour of labor is an input, not an output.  The hour of labor of the “right person” for a project is valuable and highly leveraged.  The hour of labor of the wrong person for a project is no better than no hour of labor at all.

It isn’t just an issue of trying to cram too much work into too short a time – if you have the wrong people, sometimes it just can’t get done.  And this is why it is so important for BP3 to build the best team we possibly can.

Gary Comerford of Process Cafe recently noted that improving process is not always in the company’s best interest, as in cases where penalties and fees may be extracted from uneducated customers and users.  Despite the following process issues for a train system, the organization may not feel that it is economically advisable to address them:

1) They are notoriously unreliable in their timings. Trains are late more often than should be expected
2) There are delays for many, many unknown reasons. Leaves on the line and ‘The wrong type of snow’ are two examples
3) The ticketing system is completely nonsensical and misleading.

Gary points out that the organization is not incented to address problem area #3.  That indeed, much of their revenues derive from the ticketing system’s shortcomings:

So let’s examine this: The process of a rail company calls for multiple, confusing fares which the customer has to decipher and understand. The penalty for buying and using an incorrect fare is a spot fine or the requirement to purchase a higher priced ticket to continue ones journey.

Can you see how improving this process would help the customer but not the company? They would end up with passengers buying the right fares, penalty fares being reduced and higher-priced ticket repurchases being eliminated. The end result would be a reduction in rail-fare income and associated profit. Of course the rail companies are not going to go for this.

I think this is a classic case of penny-wise, pound-foolish.  Of course it looks like the train system is making more money.  And initial measurements of revenue will tell them that revenues increased when they implemented the new penalties and schemes.  Based on this information they’ll proceed forward blind to the reality – that they are undermining the very foundation of their business – the goodwill of their customers.

When revenues eventually begin to decline, they’ll blame in on changing ridership patterns, changing economic conditions, etc.  They’ll never think to blame it on the fact that people would prefer not to use their service because it is a hassle.  When they need public-funded improvements in the rail line or station, they may be surprised when voters or elected officials fail to support them, further undermining their ability to serve customers well.   A difficult system also leaves people feeling that it is okay to cheat the system, because the system doesn’t seem to be fundamentally fair.

That said, I would differentiate between changes in the process that provide better customer service, and changes in the process that “make things easier for the consumer.”  Mortgage companies in the US made things easier for the consumer in the last decade- it turned out to be horrible for both the consumer and the business, in the long run.

History often repeats itself, in software:

The physical topology becomes irrelevant – all that matters is logical topology induced by an application and its components. These virtualization paradigms (and more) have been around in the world of mainframes for decades, and I think we can use those as a map of where cloud computing is headed.

Jacob describes how cloud computing developments are, in many ways, mirroring mainframe computing developments of years past.   Jacob has moved his blog to a new home, recently leaving ActionBase, where, in my opinion, Jacob really advanced the state of industry understanding of unstructured and spontaneous processes.  Jacob is one of the good guys in BPM – someone I enjoy debating even when we disagree, because he really does have a different perspective on the same issues, informed from a different starting point. History repeats itself in other ways- visionary people leave companies that they put on the map, and go on to bigger and better things.  His blog is a great way to keep up with the ideas he’s percolating and engage him in discussion.

Neil Ward-Dutton may be late to the party with his post on the OpenText / Global360 merger, but it is a good read:

So, having set out to purchase Metastorm in February, Open Text has followed up less than 6 months later with the acquisition of Global 360. It’s not much of a secret that Global 360 was looking to be acquired; the hiring of some key webMethods executives in 2008 signalled the start of a concerted effort to shape the company up for a sale. Still, it caught many industry observers (including me) by surprise to see the company follow so closely in the footsteps of another BPM technology vendor and be snapped up by Open Text.

The surprise factor may be one of the reasons this acquisition made so much more news than the Metastorm acquisition.

Gartner’s Business Process Maturity Model is not for the faint of heart.  I’ve heard a couple of talks on the subject and read a couple of papers, and never found it terribly useful or informative to our action plans with customers.  Apparently Anatoly Belychook agrees based on this blog post:

Phase 0. Functional management. Organization has yet to realize that its performance as a whole depends not only on how certain functions are performed, but also on how well these functions coordinate with each other, i.e. the quality of business processes interconnecting them.

Phase 1. Business processes awareness. The organization explores itself through the prism of business processes. End-to-end business processes are discovered and process owners are appointed. Everyone draw process diagrams. Gaps and bottlenecks are identified and eliminated, without investments into processes automation (BPMS).

Phase 2. Automated execution and control of business processes. The organization learns to manage business processes in a continuous loop model – execute – analyze and seeks to improve their effectiveness, mostly on a separate processes basis.

Phase 3. Execution and control of end-to end business processes. Process boundaries are expanded under the control of BPMS, inter-process communications are worked out and end-to-end processes are established connecting the company to its customers/partners and/or their business processes.

Phase 4. Explicit and automatic link between business goals and business processes. With the help of simulation and dynamic business rules, business goals changes trigger automatic rebuilding the network of business processes.

Phase 5. Adaptive business structure. The ability to quickly react to changing business environment, anticipate these changes and create opportunities through deeper integration into various markets and partner ecosystems.

I would offer a simpler set of maturity levels, which is what I proposed at Lombardi when I was still employed there:

0. Process Ignorance: No organized process per se
1. Process Awareness: Documented processes
2. Process Discipline: Processes both documented and consistently adhered to
3. Process Proficiency:  Processes implemented in software
4. Process Excellence: Ongoing investment in process improvement is cultural in the organization.

As Anatoly says, in Gartner’s 5 phases, phase 0, 4, and 5 aren’t really interesting for discussion in today’s business climate.  But he points out a key trap in pursuing process maturity the way Gartner envisions it:

The key words are “for all processes.” Trying to evenly raise the maturity of all processes is a recipe for disaster. In accordance with Pareto’s law, 20% of processes are responsible for 80% of the company’s performance. Wouldn’t it be wiser to focus on these 20%?

Sure the BPM-3 grants much more control over the processes than BPM-1. But it’s much more expensive as well! Complete BPMS implementation of an end-to-end business process is a custom IT development, apart from other considerations. And cheap custom IT development just doesn’t happen.

This isn’t just true for BPM – it is true for QA, for CMM, for all kinds of organizational and technical efforts.  Failure to apply the Pareto principle is to fall into the sins of either waste or overproduction (depending on how you look at it).  When we tackle even one process for an improvement and/or implementation effort, we try to focus in on the most important 20% – the changes that will really move the needle in terms of process performance, rather than expending our work equally across each stage of the process.