Process for the Enterprise » John Reynolds

Whose Cloud is it?

Scott Francis — Tue, 22 Nov 2011 15:40:44 +0000

Interesting review from John Reynolds, of the Kindle Fire. He’s underwhelmed mainly by the form factor, and the lack of access to non-Amazon content.

People often criticize Apple as having a “walled garden” – but if you read the following from John, and you use Apple products, the difference is obvious:

The Kindle Fire experience doesn’t feel like you’re connecting to the web – it feels like you’re looking through a keyhole into one little room of the web… or perhaps you’re trapped in a hallway with many doors and many keyholes. Many of the keyholes are blocked.

That’s when it hit me… Amazon isn’t giving me access to ‘The Cloud’, they’re giving me access to ‘Their Cloud’. Everything that I purchase from them resides in ‘Their Cloud’. The same is true for Apple. The stuff I buy from Apple ends up in the ‘Apple Cloud’… Flash forward in time and I see myself carrying both an iPad and a Kindle, juggling them from one hand to another in order to access ‘My Content’ in ‘Their Clouds’.

Actually, the same isn’t true for Apple, though I can see why he said that. Apple’s iTunes content seems to be locked to iTunes… but it isn’t. As much of Apple’s content that they can make DRM-free has been made so – only the studio labels stand in the way of DRM-free content. From my iPhone and iPad I can access gmail, google docs, netflix, amazon’s store, Kindle content, etc. (In fact, I don’t own a Kindle, but read Kindle books on my iPhone and iPad all the time). The addition of “iCloud” added features and functionality to my use of Apple’s devices, but didn’t remove any. My iPhone config can now be backed up to the cloud. Contacts, email, calendar invites now synchronize better between devices. But I also still synch those items with Google Apps. Having said that, I like John’s vision for “MyCloud” even better than what Apple, Google, Amazon, or anyone else is yet producing:

If the Universe was fair, which it isn’t, whenever I created any content it would be stored in ‘My Cloud’. Whenever I purchased anything it would be stored in ‘My Cloud’. Facebook, Google+, Apple, and Amazon would have to pull that content from ‘My Cloud’ to use it in their apps, and I would set the policies regarding access to ‘My Content’.

From what John is observing, it sounds to me like Amazon has produced an “Amazon tablet” not a general purpose tablet. There’s nothing wrong with that, per se… but I don’t think that that’s what people were expecting when they pre-ordered.

It isn’t hard to think about the analogies applicable to cloud BPM offerings…

John Reynolds: Disappearing BPM Programmer?

Scott Francis — Wed, 02 Nov 2011 06:00:31 +0000

John Reynolds writes about the curious case of the disappearing BPM Programmer:

So where does this distinction between Case and Process leave the BPM Programmer? Are BPM skills irrelevant in the new world of Dynamic Case Management and Social Process? Are the BPM Programmer’s skills doomed for irrelevance every few years just as the skills of System Programmers (C begat C++ begat Java begat Ruby etc.)?

Will BPM Programmers disappear into the mists of interesting but irrelevant oddities of the past?

The question arises simply because a small but vocal chorus has been calling BPM a subset of Case Management, or predicting the end is near for BPM. Does that mean BPM skills and jobs are thus in decline?

Not to worry. BPM was always the tool not the goal. The goal is managing business better. As the Navy Seals would say, equip the man, don’t man the equipment. BPM is a means to an end.

Processes aren’t going away anytime soon. Besides, as John says: “Your job has always been about writing software the Manage Business. Process is at the core of Business Management, but you always had to deal with Objects, Rules, and Events.”

Well said. BPM is here to stay. It didn’t burn brightly and fade away, it is a slower, steadier progression. As you would expect it to be, if you understand what it is. And the momentum is still building, rather than fading. The name may change, the tools may evolve, but the goal of running businesses better isn’t going away.

Context can Simplify Your Process

Scott Francis — Tue, 23 Aug 2011 04:07:10 +0000

John Reynolds wrote a post recently about Interdependent tasks, and the resulting complexity. John takes a simple example, the vacation approval process, and then points out what makes the difference between a cute model and a real implementation:

Sam can’t really (in good conscience) make a Decision about any Vacation Request in isolation. Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests. To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

And further:

Examples like these are what makes implementing “real world” processes hard. Processes seldom execute in a vacuum, and work done within one instance often influences other instances. Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

He’s right, of course. This is why a demonstration of a BPM solution can look easy, but the actual implementation actually takes real work and thought.

John purposely held back from suggesting a clever BPMN modeling solution or other trick of the trade to give us something to think about. I’ll give you my thoughts on how to approach the problem. But in a general sense, this falls back into a general process pattern:

a process model that does a decent job of representing one process “instance”.
another process that manages the set of all processes
yet another process that is the maintenance and improvement of the process definition and the management of process instances collectively.

What John is describing is a variation on the second level of process. It already goes without saying that we need to manage a set of vacation requests collectively. The extra wrinkle is that at a step in the approval process, the process should present context to the user, that likely includes:

All pending and approved vacation requests for other team members
Possibly other pending and approved vacation requests for people on other teams
Remaining vacation days for this person
Remaining days in the year in which to use those days
Time since last vacation

All of this information gives the Approver context in which to make the decision. The individual process’ execution flow hasn’t gotten more complicated. But the implementation details of that Approve step got more interesting. Luckily, the information above will be pretty easy to provide if your BPMS had reasonable tracking and introspection capabilities. So if we simply invest some trust in our user, and supply them with the information they need to make a decision, we’ll get really good outcomes with minimum implementation headaches.

Sometimes the really interesting bits in a process implementation aren’t in the BPMN. As John points out, we shouldn’t assume that every detail should be captured in a BPMN model.

Are you the Builder or the Check-writer?

Scott Francis — Fri, 01 Jul 2011 16:04:55 +0000

John Reynolds, always with a different perspective on BPM, recently addressed builders and business people:

I could have built this fence myself. I’ve done similar projects in the past, and I’m not “that” old. It’s hard work, but not more than I can handle… But I chose to “pay the experts” instead of building it myself.
They do this for a living… I make my living doing other things.

By now you’ve probably figured out that there’s a lesson here that goes beyond home improvement…

I am a huge fan of enabling Business folks to build their own software solutions, but the fact remains that most people prefer to pay others rather than build things for themselves. No matter how “business friendly” our tools become, most businesses will bring in builders when they need them.

I rephrased the question: are you the builder or the check-writer? Like John, I pay experts to do quite a bit of work at our house that I could probably do myself (or at least, learn how to do). An early experience in my life taught me the value of expertise – not just knowing how to do something, but the value of being someone who does it all the time. My father was going to build a deck in our backyard, to replace a very small balcony that was about to fall apart. He had staked out the area, and went so far as to calculate how much wood and cement he would need. He even figured out which tools he would have to buy, or borrow from our neighbor the Fireman.

My father asked a builder to come out and bid on building it. They said it would take two days. My father wisely decided that having the deck completed all summer was worth more than “saving” money by building it himself. My first understanding of the time-value of money. Or in this case, of what that money could buy (a completed deck).

This is among the many reasons we don’t worry about customers – business and technical – learning how to work with BPM. We want them to learn. We want the tools to make it more possible and likely that business and technical users can be successful. And we still think there will be plenty of work for specialists like BP3.

Because, like my father, I paid a builder to put up the deck at our home – and I have a better deck than I could ever have imagined building for myself. (Quit laughing John!)

No related posts.

Templates Frameworks and Patterns, Oh My!

Scott Francis — Thu, 23 Jun 2011 03:37:18 +0000

John Reynolds, commenting on Sandy Kemsley’s blog, where she was writing about Shell’s BPM success story:

Note that Sandy’s tale mentions Templates, but it doesn’t say a thing about Frameworks… and to me that’s very significant…

As a Professional Programmer, my life revolved around Frameworks (OWL, MFC, Struts, Spring, etc.) Each of these Frameworks provided a wonderfully powerful foundation on which I could build my custom applications. I simply can’t imagine life as a Professional Programmer without programming Frameworks.

Pardon me for over-simplifying, but a Framework is something that “you bolt pieces on to”. The Framework provides the internal structure of your program, and you can build many diverse and wonderful programs on top of any really good Framework.

If you are an Occasional Business Programmer you’ve probably found that Frameworks aren’t quite what you’re looking for. Frameworks are really powerful and really flexible – but all that power and flexibility comes at a price – you really have to know what you’re doing to use them.

I think the narrower interpretation of the word Template is useful to the “Occasional Business Programmer”. Of course from a technical point of view, most of what gets pitched in the BPM industry as “templates” are really Frameworks, using the definitions John uses above. And Frameworks, as such, are problematic. They require not only being an expert on underlying BPM technologies, but also on the APIs (programming interfaces) of the Framework itself. For people that are more than occasional programmers, patterns will help more than frameworks – as they’ll apply to more situations. Borrowing from a Navy Seals slogan, I think patterns “equip the man”, whereas with Frameworks tempt one to “man the equipment”.

John Reynold’s Implementation Dream Team

Scott Francis — Wed, 04 May 2011 23:57:24 +0000

This is a fun post from John Reynolds about the BPM Implementation Dream Team.

Rapid Iteration BPM implementation projects, like the ones that I work on, depend on “Business” to take on building responsibilities and “IT” to take on requirement writing responsibilities. We don’t structure responsibilities like this just to make everyone feel good, we structure things this way because of the way things are:

All Business requirements have Technical implications

All Technical implementations have Business implications

When the business folks hit the technical hurdles, and the technical folks hit the business challenges, there’s great incentive to find “another way” that gets the team to the solution sooner. Shared misery builds strong bonds.

The core of our ideal BPM implementation team are two individuals; the Business Lead and the Technical Lead.

I recommend reading his blog for the rest of his entertaining post. John has a great attitude about BPM and it shows in his writing.

Beginner’s Guide to Performance Reports

Scott Francis — Mon, 25 Apr 2011 17:10:07 +0000

John Reynolds gives a beginner’s guide to Process Performance Reports on his blog. Using Websphere Lombardi Edition, he shows a few diagrams and gives good advice regarding how to build up the tracked data for your process reports.

Of course, if you’re not using Lombardi Edition (or various versions of Teamworks and IBM BPM), you might not be able to relate to these diagrams- they include the tracking point metaphor that Lombardi introduced way back in 2004 to allow for a transparent snapshot of process instance data. It really makes it trivial to capture snapshots and timing data for use in correlations in reports.

John does say one or two things I’d modify, such as:

Process Performance is all about “How long did it take?”. If you want to know “How long?” then you have to know when “it” started and when “it” finished.

I’d say, rather, that this is one of the most common kinds of reports – and in IBM BPM, one of the easiest to produce. There are other quite interesting reports that are similarly trivial to capture:

How many of X did each person on the team process by month (or by week or by day, etc.)
How many exceptions (complaints/defects/etc.) did we process by customer or by region (comparing performance)
How much rework is happening?
What percentage is going down the happy path versus exceptions?
What is the typical # of exceptions per item?
How many exceptions get “fixed the first time” (ie, once known, the issue is fixed correctly).

With some demographic data on each snapshot, we can really do interesting correlations (using the optimizer or your own custom reporting techniques). One of the uses of this data is to fine-tune the process. A favorite demonstration of this capability was to look at the correlation between the size of a dispute in a dispute resolution process. If 90+% of disputes under a certain $ amount (possibly in combination with other criteria) are being approved, perhaps it makes sense to insert an auto-approve decision rule in front of the manual activity that requires a person to look at the request and approve or deny.

Human Interfaces to BPM

Scott Francis — Mon, 04 Apr 2011 02:59:45 +0000

John Reynolds outlines key user interfaces for BPM:

Task Notification Interfaces
To-Do List Interfaces
Task Completion Interfaces
Process Status Interfaces
Participant Workload Interfaces
Process History Interfaces

We could group these together around a few basic principles:

Executing the instance of the process (task notification, task completion)
Managing a set of process instances (to-do list, status, workload)
Improving the process itself (process history, as well as, obviously, tools provided with the BPMS that are focused on authoring)

If you’re not sure whether you’ve covered your bases for UI for your processes, John’s blog is a good place to start. Good thoughts and explanation around each interface type.

A Cautionary Note about Process for the People

Scott Francis — Fri, 25 Mar 2011 15:26:32 +0000

John Reynolds, of IBM, writes:

These experiences with “Departmental BPM” are what make Irene’s recollections of Notes’ Databases resonate so strongly with me. The ability for a small team to develop and deploy a focussed solution is a very powerful thing… and immensely valuable for the business. It’s a fantastic “group experience”.

But just like Notes’ Databases, there comes a time when the ability for “anyone” to develop and deploy a managed business process begins to raise “red flags” for those who have to manage the enterprise as a whole. As BPM spreads through the enterprise, the natural tendency to want to control that spread takes hold.

I’ve experienced this first hand… Early successes with BPM, run as small agile projects, attract the attention of enterprise level architects and program managers, who react with horror at the anarchy and call a halt until control can be re-imposed.

It is all too easy for IT to kill the golden goose that lays the eggs, while trying to make sure that these departmental efforts don’t get out of control. There’s a legitimate governance concern – but like most things, if you hold too tightly you suffocate the opportunities. The IT governance concerns should be mostly about visibility, and less about control. Sadly, there is often more concern about control.

Best Practice for BPM UI Development: Iterative Deepening.

Scott Francis — Thu, 24 Mar 2011 04:21:00 +0000

John Reynolds (of IBM and Lombardi fame) has posted tips for building a task-focused user-interface. He does a great job of articulating the “iterative-playback” two-step that defines our approach to building out process UI (and process):

With this in mind, you’ll see the logic of the process that we’ve adopted:

Build “Just Enough” human interface to give you the ability to “step through” this activity and all of the paths of your process

Define “Just Enough” of your interfaces to underlying integrations to give your integration developers the information that they need to start building the “real” integrations

Get a fully functional task UI working as soon as your “real” integrations are ready

After everything is functional, then (and only then) work on making the task UI “pretty”

On that last point (step 4) – remember that “everything functional” goes beyond a specific human task – All the human tasks should be functional before you worry about making any of them pretty.

This is great articulation of the approach we pushed and developed at Lombardi between 2003 and 2007. It looks like the team has continued to improve on the definition of this approach (including defining Blueworks process maps for it). But I think the four-step list is easier to “grok“.

Despite the simplicity of the approach, many people fail to adhere to it. The more technically savvy the person is, the more likely they are to deviate from this process. For some of these folks, I explain it in Computer Science terms – analogous to iterative deepening to find the right solution for each UI, and for the whole application’s UI in general. It isn’t quite as simple as breadth-first, but it is closer to breadth first than depth first.

There is a reason for taking this approach to building process UI :

Your biggest risk in the project is that you’re requirements are wrong or misunderstood. Your best expression of requirements is typically the User Interface.

Because of that, you need to iterate on the UI. And if you go too deep -either by prettying or over-integrating with back-end systems – you create friction on that iterative process that isn’t required. That adds cost and slows time-to-market.