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 »

I’ve had a surprisingly difficult time conveying my own definition of “Iterative Development” in the past, so I thought I’d take a stab at explanation via analogy. Let’s compare your Business Process to a trip from Austin, Texas to El Paso, Texas.

The most important aspect of my trip is arriving at my destination.  No matter what interesting things may happen on the way, if I don’t end up in El Paso, my trip has failed.

The same is true about your Business Process.  No matter what else goes on, there is an objective to your process and you have to accomplish that objective.

Read the rest of this entry »

Process People: We frequently hear from Lombardi that BPM has everything to do with organizational culture.  Can you give us one concrete example that you commonly see which demonstrates this cultural shift?

Wesley Chung: Yes, it’s very much a cultural thing, and I would say that a big part of that is trusting the [BPMS] system.  Many organizations still rely on old-fashioned, manual status reports to track the success of a process because they don’t have any other way to know that people are getting their work done.  A traditional status report provides a way for them to monitor that.  Without a product like Teamworks, there’s no way to efficiently and effectively monitor that people are accomplishing their tasks in-line with the business process.  It’s how things have always been done.  Ultimately, they need to be willing to trust the tool if they want to change how they manage a process. The other major cultural challenge is that managers have to learn new concepts and completely alter their methodologies for managing processes.

Process People: So what is one example of a cultural difference between managing processes manually and managing them with a product like Teamworks?

Wesley Chung: The difference is really about managing exceptions.  An exception is an instance where a process was not followed in the normal case, where someone in the organization didn’t do what they were supposed to do and the process did not turn out as expected.  Once managers see that the process team can provide them with some automated reports and the managers realize that they can trust the system, then they can start thinking about managing the exceptions instead of managing the processes that were carried out properly.

Read the rest of this entry »

Ed.: This is the third post in a series of Q+A sessions focusing specifically on playback session best practices, with our in-house expert, Kris Komassa. See our previous coverage here and here.

Of course there is never a “finished” process. How often do you typically use a playback session to fine-tune a process that is up and running? How often do you do this, once a quarter? Twice a year? Can you give us a few examples?

We have a customer in Dallas that is unique because they have a very wide sales force who are all remote and need a number of approvals before they can close any business. We finished a project with them just a little over a year ago, and we’ve since done a number of other engagements on top of that original project, so the work is more or less constant. They’re a good example of fine-tuning and building on top of a first project.

The way that I always start off the new work with them is by having them do a playback for us to see where we are, and then have that segue into a talking session around what it is that they want to see or what new work they want to have done for them. So, we start with what we have already, instead of starting with what we ultimately want. This helps to create that delta between what they have today and what they’re looking for down the road. They’re a very active customer and good to work with for this reason - each new project flows naturally and organically from the ones that have preceded it. I’d recommend this way of working from one process to the next for everyone.

Read the rest of this entry »

Its been a week since SAP’s big BPM announcement. Not exactly an earth-shattering announcement. My summary - at some point in the future (2 years?), SAP-only shops will be able to more easily configure internal SAP application workflows. This is a SAP application workflow band-aid, not a viable BPM offering. I am not alone in this assessment - the reviews have ranged from unimpressed to downright negative.

Honestly, this is no surprise. The big software vendors - I call them Stackers - have been and continue to pursue the promise of BPM half-heartedly. Actually, they have done everything in their power to bury BPM deep in what they view as their real markets. You can’t blame them - BPM ain’t in their DNA. And it is really hard to change your DNA.

SAP wants you to buy applications from them. BPM to them is just some integration and workflow between their applications. Always has and always will be - no matter what the Netweaver BPM roadmap says. Not to get too cheeky, but SAP does not have the best reputation in this sense - see their public spat with Waste Management about non-delivery of promised functionality.

Read the rest of this entry »

Recently we sat down with Rachel Aukes, a member of the Wells Fargo Financial Information Systems Continuous Improvement Team. Rachel, who plays an active role in the use of BPM at Wells Fargo, shared how Wells Fargo got started with BPM. In February, Wells Fargo received the Global Award for Excellence in BPM and workflow.

Process People: Describe in as much detail as possible the problem or need on a project level that first made you consider BPM and/or Lombardi as a viable solution.

Rachel Aukes: Our BPM program came about as a solution to organizational level needs - in fact we selected our BPM solution (Teamworks) and began to implement it before deciding on a specific project. We were challenged with increasingly complex, paper-intensive processes that had a large number of manual steps and handoffs. That was obviously inefficient and meant there was room for errors (such as bad typing, misplaced files, etc.). The idea of what BPM offers became prevalent in 2006 when most of our development staff was focused on maintaining our legacy systems while building our future systems of record. This effort was strategically important to our company; however, the business had immediate tactical needs that must continue to be met. We asked ourselves what we should do to best support our business partners, and we determined that BPM was a good solution for this. We haven’t looked back.

Read the rest of this entry »