North Americans may have a hard time understanding this, but in Brazil there are laws that “stick” and laws that “don’t stick”. We say that a law didn’t stick when everyone – from the people on the streets to the law enforcement agencies and the courts – decide to ignore it. For example, the Brazilian Constitution says that one cannot charge interest rates higher than 12% a year (don’t ask why that’s in the Constitution). Even so, most banks charge nearly that much a month, and no one thinks that’s strange.

It’s funny how the people that complain the loudest that we need processes are the first to ask for “exceptions” when the processes are in place. In the company I work for, people are always saying that “this order is exceptional” as an excuse for not following the processes. Sure, they used to complain that the processes had to be created; they helped design them and agreed to follow them. Guess what? Every order is exceptional.

This year I’m making a resolution: everyone will follow all processes. I’ll be relentless in the pursuit of this goal.

Of course, I made this same resolution last year, and it was as successful as the resolution to exercise regularly and to lose weight.

Why is that? For the same reason: it takes effort, day after day after day. We may follow a blitzkrieg diet and lose five pounds in a week, but how long can we keep it up? This is why I don’t believe in diets, I believe in reeducating ourselves. I’ve managed to keep a reasonable bodyweight over the years because, instead of saying “no pizza at all” (which is ridiculous), I say “OK, two slices are enough”.

So may I be able in 2008 to reeducate our people instead of trying to deploy processes by fiat. Things just don’t work that way – not only in Brazil, but all over: if you don’t win people over, you’re bound to fail (see my previous post, Stakeholders can kill you even if you're not a vampire).

The way to go is not to say “you helped design the process and you agreed to follow it; now stop complaining and follow it”. A gradual rollout, giving everyone time to get used to each small change, is easier to accept. Baby steps instead of grand gestures.

Maybe this way the business processes we put in place will stick.

When I went to the Argentine Patagonia to see the glaciers I stayed at El Calafate, a small town that seems to exist for tourism only. Realizing that most guides did not accept dollars, I needed to change money, so I went to the local branch of Banco de Tierra del Fuego.

The branch was a single room, with the manager's office was in a corner, a desk separated by glass walls from the rest. On the other side of the room, two tellers took care of the customers, who waited in a single line. I walked in and saw there were half a dozen people in front of me. "I'll be out of here in five minutes, ten minutes at most".

Nearly half an hour later I was still there and there were a couple of people in front of me. A long line had formed behind. Exasperated, I tried to see why the tellers were taking so long with each customer. Gradually I understood that all their processes were manual. It reminded me of the way things were a quarter century ago, when I opened my first bank account.

Back then in Brazil – and still today in El Calafate - there were no computer records. If you wanted to withdraw money you had to go to the branch where you had an account because that's where the cards with your signature and your balance were. You'd hand the teller a check, he would find the paper file with your signature, check it (that's where the word "check" comes from), find the paper file with your balance, update your balance by subtracting with a pen the amount you were withdrawing, and only then give you your money.

Today we can go to an ATM at another country because your balance is in a central database, updated in real time across the world via a wide area network and the Internet. Plastic is replacing checks and, increasingly, paper money. Banking has never been easier.

Technology is a big part of it, yes, but banking wouldn't be so easy today without major restructuring of business processes. It must have taken an unbelievable amount of work, wrong turns, frustration and small victories to get to where we are today. If you compare the ways things were not so long ago to how they are now you'll feel a shock, as if you used to live in another world.

BPM is hard, no doubt about it, but when you see the rewards of constant work you remember that it's worth every drop of sweat. Even if you have to go to Patagonia to realize it.

In my previous post I said that if you don’t manage your stakeholders you are in a lot of trouble, but I didn’t back up the claim. You may believe that stakeholder management is touchy-feely stuff, one of those things management consultants come up with to make the simple appear complicated and justify their fees. After all, people will do what they are told; the important thing is to come up with a project plan and hold everyone accountable for following the schedule, right? Right?

The truth is that a project without stakeholder support is like a vampire with a stake through the heart. But, unlike Dracula, your project is unlikely to return from the grave.

If the stakeholders don’t want the project to end, it never will. In a particularly dramatic case, a company launched a project that would streamline most of its business processes. Of course, everyone knew the end of the project would probably mean the end of many jobs, so those who felt threatened found creative ways to sabotage the project. The sentiment was so widespread in the company that rumor has it that people were saying "Long live the project!" out loud in the hallways. The last time I heard about it, the project was two years late.

Unwilling stakeholders may not perform the tasks that only they can. For example, in every BPM project there is knowledge that is locked inside the brains of key employees. If they don’t want you to have complete and correct information, well, you’ll never get it. When it becomes obvious that the project is off-track and you try to explain why, they can simply claim that you’re making up excuses. How will you prove otherwise?

In one project I worked on, a member of the organization started playing the "what if" game. "What if there is an unrecoverable error in this transaction? How can we roll it back?" This is the concerned citizen ploy. It sounds like a sensible remark, but what it meant was that we had to make the process about five times as complex as necessary to account for an exception that would unlikely never occur. After a customer order had been input in the CRM software and produced a production order and an invoice, this concerned citizen wanted the process to predict the possibility that it wouldn’t be possible to schedule the delivery. The obvious answer would be that someone would have to handle the exception using the existent procedures. But no, no, we can’t risk mistakes; the process must handle explicitly this and every conceivable error condition. And after you’ve done this for one process you have to do it for every process.

Remember also that in most BPM projects you’re an outsider and the disgruntled stakeholder is an insider. You may be a consultant, a Black Belt, a project manager or whatever; the bottom line is that you probably are not part of the team that is most directly affected. If one or more members of that team don’t want the project to succeed, they may have readier access than you have to the people higher up in the hierarchy. Heaven knows what they’ll say to the Powers that Be; you certainly won’t know, but you’ll feel the effects.

Even if they’re not actively against you, stakeholders may not bother to help you. In one project the line manager whose team I had to interview cautioned me against taking too much of his people’s time. What he meant was that I was not allowed to interview them. Go figure how he expected me to complete the project.

This case shows that, when you don’t get the key stakeholders on your side, even if you succeed you fail. I went ahead and interviewed the people I had to, got the information, although with a lot more effort than budgeted. We finished the project, the company reaped the business benefits it was seeking, but the line manager was sorely peeved. Since he reported directly to the executive officer who had hired us, the opinion that mattered was that the project had been a failure. They never paid us for the extra work and we never got repeat business from the organization.

Everywhere you look you'll find a different BPM methodology or framework competing for your attention. Every single one has an impressive name, flashy diagrams with arrows zooming left and right, pretty colors, and promises to solve all your BPM problems. How do you pick one to use in your organization? Glad you asked.

Simply put, you can use any methodology where each step is the natural consequence of the previous step, all culminating in your objective.

These are the basic requirements. If a methodology fulfills them and feels right for you, by all means use it. It'll get the job done. Here's why.

You should always have a reason - an objective - for starting a BPM project. You don't just wake up one fine morning feeling that it would be nice to "do some BPM". Every business initiative must have an objective, a reason to exist. If a methodology achieves the objective, then it works for you; if it does not achieve your objective, then it's useless. No big news here.

If one step leads naturally to the next one, you never have to wonder how to start a task. What you do next is a natural consequence of what you have just done. Work flows naturally. Here's a simple example: if you map the information that flows from one area of your organization to another, you'll wind up with a description of the value added by each step of a process; put all activities performed by one area together and you have job descriptions; check the job descriptions against the current capabilities of each team and you'll find capability gaps; and so on and so forth. The requirement that one step be the natural consequence of the previous one is not new either: it's the cornerstone of Descartes's Method.

If the steps are naturally chained, no effort is wasted. You don't produce work that looks nice but has no use. The output from one step is the input to the next step, and therefore necessary.

That's it. In a nutshell: you know you'll reach your objective, you won't get lost along the way, and you won't waste any effort. As a bonus, if you ever need to justify your choices, you already have your case laid out.

Of course, we haven't covered "details" like project management and stakeholder management. But if you need a framework to tell you about them, boy, are you in a lot of trouble.

Business process integration technologies may be very sexy and all, but companies can’t afford to start projects for that reason alone. Management needs to be convinced that an integration project will bring bottom-line results before it will agree to fund it. How do we build a case for business process integration, then? Let me count the ways:
1) Customers no longer accept disintegrated business processes;
2) integration provides a measurable financial return;
3) a service-oriented architecture cuts costs.

Let’s say you just made a cash deposit at your bank but, when you walk into another branch, you’re told that they have no record of the deposit, and that it will take a day or two for the transaction to be reflected in you account. Unacceptable, right? Bank customers today won’t accept delays in the information transfer between systems. In other words, they demand that the bank’s processes and systems be integrated. In fact, the customers of any business expect integrated processes. If you don’t offer an integrated experience to your customer, be sure that your competition will.

So providing the level of quality expected by the market is important because it helps in the battle for market share; but are there any other financial reasons for integrating processes? The answer is "yes, many". Let’s see two examples: better cash flow and reduced loss of revenue.

I’ve been involved in a case where a company integrated its CRM software with a legacy system that calculated the total cost of complex orders so they could provide a quote on the spot instead of the next day. Not only was their customer service improved, but so was their cash flow. The revenue for each order now comes in one day earlier, which by itself raises their gross income by 3% to 5%.

In another case, a large corporation had several customer databases (which is quite common in large corporations), which held different data: a customer that existed in one database did not exist in another, or a change of address was not updated in one or more databases. The result? Invoices were sent to wrong addresses; worse, expensive equipment was delivered to unknown addresses, never seen again and never paid for.

OK, so business process integration provides a satisfactory return on investment, but some companies want to cut costs now, not to invest money so they can obtain results in the future. Even from that point of view, integrating processes makes sense. Some level of integration must exist between a company’s systems. Somehow the information in one system must get to the other systems: someone may key in the data again (yes, it happens), or a batch export/import interface may be created, or something else altogether; but the information must get from this software to that one. As it turns out, maintaining these interfaces is very expensive, and the cost is proportional to the square of the number of interfacing systems. Using a service-oriented architecture, the cost becomes proportional to the number of systems. But the big payoff is when there are routine changes in the data coming out of a particular system: instead of changing the interfaces to all others applications, you only change one piece of software. In short, considering that interface building can represent as much as 25% of the IT budget, a service-oriented architecture actually saves money instead of spending it.