We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

ebizQ's Business Agility Watch


Secrets to a Successful BPM Implementation: Phil Ayres Explains

Vote 0 Votes

Listen to my podcast with Phil Ayres, Founder of Consected, which provides process improvement solutions with the company's own SaaS workflow product. In this podcast Phil details the secrets of a successful BPM project: what to do, what not to do, and how to assure corporate buy-in.

Listen to or download the 10:37 minute podcast below:

Download file


PS: So what are some of the most common mistakes companies make when running a BPM project?

PA: Well, I think there are several I can think of. I think that the first is that the business analysts and BPM consultants rarely work together early enough in the project. I think that many companies they're always wanting to get a head start in their process improvement project and they start the design of their to be processes before a BPM tool is ever really been selected. And I think the issue there is that the output from the business analysts rarely sort of reflects the strengths of the tool eventually selected or it doesn't even drive the selection of that tool in the first place.

I think a second common mistake I've seen is the requirement from customers always to try and integrate all of the company's backend systems into a new process solution in the first release. And really before I get attacked for this, I know that rekeying of information and that so called swivel chair integration always leads to errors; typing in your information again always leads to errors in data entry. But they're really not new errors to the process and so trying to get everything clean and correct the first time around especially with the risk of integration that adds a lot of complexity to projects and at least in my experience trying to do integration first time around often leads to the failure of a project.

And I'd say that then the final mistake I see is the depth or granularity that people go to when designing a new to be process. So if you put video or some other process model and tool in front of a business analyst and watch what they do, they really start designing their processes to a real depth and granularity that actually makes the model you see quite meaningless. I always like to aim for a process model that is less than 20 steps in the first release, something simple, plain, a straight line. And we often see that these are the most successful processes to be implemented because they're simple and they actually reduce the overall time for a process to complete.

So a classic keeping it simple. Now, did you find having previous BPM experience critical to a successful implementation?

Yeah, absolutely. I think on the implementations I've worked on, the best consultants have always shown obvious experience. They could weave stories around the best practices that they learned from their past experience, which helped clients to make the best decisions. And it's often the depth of this background knowledge that can prevent a project from going off the rails sometimes without the client ever really realizing it.

On the flip side of that, I think there's no amount of technical or process experience that can be just a substitute for being able to perform relationships with stakeholders and the eventual end users. And although that's said, it would be hard for consultants to form these relationships necessarily without the credibility of their experience to back them up. And process improvement independent of a BPM product is not about doing things that have never been done before but just n ever been done in the organization that you're currently working in and its experience that helps bridge that gap.

Now, I imagine this would change with the size of the job but what is the typical timeframe in a BPM installation?

I think the standard that one from a sales executive selling a BPM product is typically we'll have something for you in 12 weeks. My answer is that in any project that involves software the timeframe -- the time available is never enough and I look it like it's really the implements in your BPM solutions is much like the skiing or snowboarding events we just recently seen at the Winter Olympics.

The gold medals went to the competitor that took the smoothest line down the hill not the one that had to take the most risks to get there. And so really again, it's like you say going back to that keep it simple approach. The one thing that I always tell a customer that's never implemented BPM before is this: you really don't know how a solution's going to change the way you work until you try it in practice. So really, you should aim to implement something small. Get some success so you can learn from the experience and that way you don't really end up wasting a lot time on those must have features at the start of a project that end up contributing nothing to the business so in that way, you can really keep the timeframes compressed, the timeframe realistic.

What can BPM do to make it easier for companies to get started in process improvement?

Well, I think us BPM people have a lot of responsibility in the regard. I think we need to use less jargon. We need to really use less terminology that's only relevant to our chosen tool that really only satisfies the marketing of a tech people. If the language used matches that of the business, everybody can communicate better and faster and as we all know, then projects will move along a lot easier.

I think we also need to look at it from the point of view of the tools as well. And the tools, the BPM tools need to incorporate more useful best practices. For example, they more out of the box proven configurations covering the common ways that people work. And they also need to incorporate more from a user interface of front-end standpoint as well to guide how people capture information or documents that they took is key to process.

Its all about sort of building structure into the tools that allow a business analyst or a BPM consultant to worry more about the valuable high level process and that performs when the details of every little operation that the user is going to perform. And I think in that way, BPM both from a people and technology standpoint can make it easier for companies to get started.

Now with your various installations, what is the number one key lesson that you've learned?

The number one key lesson I think it's very simple. Business value is the only reason that customers are implementing BPM as a vendor, a consultant, or even a customer stakeholder as long as you keep that business value think in mind at all times you really can't go wrong in your project. Now, I know that sometimes IT and technical staff seems all important and the reality is that BPM technology is just an enabler for business process improvement.

It's just production line that keeps work moving along in your department so it doesn't matter how you measure it. A successful BPM project is really only success if the customer looks at it and sees value be that a hard cash return on investment, maybe a 50% increase in customers opening new accounts or improving customer services by (indiscernible) 70%. Whatever its business value is everything.

What do you see for the future trends of BPM?

I think this is a tough one. I think BPM is going to head down three parallel parts. I see one variation where the BPM tools are going to become more developer oriented and I think as offerings move into the cloud we're going to see this a little more. So in my opinion, Salesforce.com and Microsoft are going to draft this. And (indiscernible) always built their successes on the fact that some companies just prefer to build business solutions using software development (indiscernible).

A second variation on BPM I think we'll see BPM fall into the enterprise technology stack. As IBM and Oracle are going to start to work out what to do with all these new BPM assets they own. I think BPM's going to become part of the overall enterprise architecture in every deal and every large system we see. And I think in doing so we'll probably see that also the powerful model and simulation and optimization tools that have got so much press they're going to end up there as well because the consulting services arms of the stack vendors are going to build lucrative centers of excellence around them.

I think the final point is where I'm placing my bet personally that customer demand is going to continue to grow for a softer implementation or process solutions but deliver that all important business value. And for this I believe we're going to see the BPM market share going to Software-as-a-Service offerings and I believe the most successful SaaS offerings are going to be the ones that are designed to provide effective solutions through building block configurations rather than trying to force fit traditional BPM software and modeling tools into a hosted environment. So as I say, this is where I'm placing my bet with offerings that can deliver an initial process solution in days not months and allow customers to see business value faster.

ebizQ’s expert blog team covers a broad range of BPM, business integration, business analytics/monitoring, collaboration, content and related issues.

Peter Schooff

Peter Schooff is Contributing Editor at ebizQ, and manager of the ebizQ Forum. Contact him at pschooff@techtarget.com

Recently Commented On

Monthly Archives