Like all enterprise software solutions, the person implementing a BPM strategy must contend with a chasm between the business and IT. The two speak different languages, have different priorities and tend to justify results in a different light.

So which side do you approach first?

There’s a tendency for enterprise software to gravitate to IT. And why not?  IT gets it, right? They understand the technology and the inherent benefits it brings to the table. And IT is constantly justifying new software, hardware and services through the annual budget reviews. So it seems natural for anyone wishing to see a BPM solution deployed to look at IT first.

I believe this is a mistake.

Despite conventional thinking, the right place to begin conveying the benefits of a BPM deployment is on the business side of the house. That’s because BPM has to be looked at not for the technology, features and specs, but for its ability to change and improve the business.

Read the rest of this entry »

Do not be alarmed. This post is not an instruction manual on the finer points of BPMN. For those of you who wish to indulge, this should provide you with many hours of entertainment.

Rather, I want to reflect upon a few thoughts about process modeling, and share some practical hints.

And whilst Blueprint is my favorite modeling tool in existence, the following comments are equally applicable whether you’re using sticky notes, a white board, or the back of an envelope. (I’ve also seen bits of string used quite creatively!)

Process modeling is a process in itself. Therefore, like any other process, we can aim to improve its efficiency, effectiveness and flexibility. So instead of approaching modeling in an ad-hoc manner, how can we make it more repeatable, reduce the cycle time, raise quality and customer satisfaction?

To me, process modeling is fundamentally an exercise in communication. A model may be generated in order to share information between members of a project team about the way the process currently works. Or to share information between the project team and the stakeholders. Or with vendors. Or between a business expert and a business analyst. Or a business analyst and a developer. In all of these instances, the process modeling is not meant to be an end in itself, but a means to identify, verify, and inform interested parties about the way the process is, could or should be.

If we accept the model as an abstraction of reality, a visual representation of various process attributes, then the question arises not so much as to whether a process model is right or wrong, but, like a conversation between two people - is it effective or ineffective? Does it convey useful meaning to the intended audience, or not? A meaningful communication forms a sound basis for action - but a confusing, misleading or ambiguous one cannot be expected to yield a high quality outcome. Garbage in, garbage out.

How then, to create effective, clear, useful communication about a process?

Read the rest of this entry »

BPM project durations are usually measured in weeks-to-months - not months-to-years. With this velocity, you can’t afford to get stuck in the rut of traditional “define & design” techniques based on multiple rounds of 1-on-1 analysis meetings. In fact, I’d go so far as to label this as rework which increases a project’s cycle time!

I’m an enthusiastic supporter of the workshop format, where not only speed, but also quality, visibility and buy-in are greatly enhanced compared to the 1-on-1 approach. You could say it’s a way of applying process improvement methods to the way we carry out process improvement itself (or “PI²” as I like to call it).

In a previous blog, I shared some secrets of success for the “2 x 6 workshop“. One of the critical success factors is utilizing a facilitator - “an impartial, objective analyst to run the session, keep it crisp and in-focus”. Let’s dive into that a bit more. Why do we need the facilitator role, how does it add value to the process of process improvement, and how can it be done well?

Read the rest of this entry »

Getting started with BPM makes many people nervous, and for good reason.  Change can bring uncertainty and fear - and hence often generates resistance.  In response to this type of internal skepticism and unrest, I frequently recommend conducting a 2×6 workshop when initially analyzing your processes to engage and excite the people who live the processes every day.

But before I tell how to run a 2×6 workshop, I would like to put it in context:

BPM is first and foremost a discipline to improve the efficiency, effectiveness and agility of a business, from a process viewpoint, to deliver real business value.  That being said, you have to do a certain amount of rewiring PEOPLE and your organization before you can start worrying about the software.

To really drive BPM in your organization, you need strategies in place to make the shift a bit easier for your workers to consume.  People don’t want change to be forced upon them.  But if you present them with an opportunity to help drive that change, then they can become fully invested as participants who help shape their own future.  So when you begin your initiative and need to take stock of where you are, you do some process analysis.  How do you get started?

Read the rest of this entry »

The best description of “executive level buy-in” that I know of is only 7 letters long:

F-U-N-D-I-N-G

Maybe that doesn’t help you as much as you had hoped, so I’ll provide some additional color around this one.  Funding is the absolute bottom-line when we talk about executive buy-in to a BPM initiative.  But funding has to reflect the iterative approach, which means that the project isn’t over when the process is deployed.  The project is really just getting started.

Funding has to map back to the methodology required to do the project right.  It has to reflect all three phases of a proper BPM methodology.  We’ve discussed this methodology on Process People before, and if you haven’t seen some of those posts, I recommend that you read one first!

In reality, executive buy-in also means you have to have an executive who’s willing to get up on a podium and endorse the process improvement program organization-wide.  It means that the executive has to be willing to commit funding in every manner necessary - money, people, time and so on.

Read the rest of this entry »

Ross Mayfield noted today that one of the biggest challenges with collaboration among distributed teams is actually agreeing on who is actually part of the team. Larry Irons quotes research from Distributed Work to that effect:

Of the twenty-four teams surveyed, not a single team was in complete agreement on its boundary: who was and who was not a member of the team. In fact, the average level of agreement within the sample was only 75 percent, such that any given team member was likely to disagree with the rest of his or her team on one-quarter of potential team members. 

We see this all the time in real world BPM projects. Agreeing on what the process is is often the easy part. Identifying the who is can seem nearly impossible, especially if a single team is attempting to define a process that is executed in many different locales all over the world.

A distributed, collaborative environment such as Lombardi Blueprint is key to solving this challenge. Having a structured repository to identify and maintain the players and relationships involved in a business process promotes visibility and knowledge sharing among those involved. Discovering the who in a process becomes far easier when all those that are involved can both document their own role and see how where they fit inside the grand scheme of things regardless of what office or time zone they happen to be working in at the particular moment.

This post is all about the cultural changes that BPM can (and needs to) drive within an organization. But it’s also about some of the ways in which processes don’t live in the clouds — they live on the ground, in real situations, with real people. I think it’s really important to remember this fact in our day-to-day work. I like telling this story because it’s from a long time ago when technology was quite different — and yet there are stark similarities to the challenges that we face today.

When I started at Sprint (my former employer), I was among the people who just assumed that when you picked up the phone, there would always be a dial tone — to me this was no big deal. I didn’t really understand all the technology, all the incredible things in the background that happen to actually put phone service in your home. This was of course ten years ago, so cell phones were popular, but everybody still had a landline, and the company overall was still focused on the latter market.

One of the first things the company did was send me out to a call center. This was part of my “process discovery” phase in my new role (though we didn’t call it that) — my goal was to see and document how things actually worked, and then find ways for us to improve.

Read the rest of this entry »