Business process management requires a new set of technologies. When I started this blog in 2005, I wrote "By 2010, these will replace ERP as the primary focus of solution engineering at companies large and small." This has occurred. I also wrote: "By 2020, managing process through technology will be second nature to senior executives, and the transactional systems we use today will be like mainframes. My blog talks about BPM today, tomorrow and where we'll be in 2020." I still believe that. Welcome.

February 12, 2011

What the hell happened while I was gone? Over the past 20 days (!) Egyptian rebels ousted a dictator via the non-violent methods largely perfected by Jesus Christ, Gandhi, Martin Luther King, Jr. and Mark Zuckerberg. I didn't even know you could Friend three of those guys. Yet here we are.

But today I'd like to look at one other aspect of what happened over just the last three days: the role of the military in all this and how it applies to the cultural rebellion that is BPM. Three days ago it was understood by all the Wise Men that Mubarak was going to resign. Two days ago he went on TV and said he was… staying! And the VP and the Generals supported him. But now we get to the crucial part: the rank and file of the military didn't follow. They were in the streets, continuing to protect the rebels in the largely non-violent way that the rebels themselves exhibited. And yesterday my guess is that the Generals reconsidered and chose honor over division. And so Mubarak is out.

A lot of that is fact… some is supposition. There's one more fact I find interesting: Egypt's army is a conscript army. Which means its army, given its size (1/2 million Egyptians) will inherently reflect all the nation's constituencies and values - these will be internalized to an extent not possible when the army is not "democratically" selected. [Note: I'm not implying anything against a volunteer army, it also has many merits, I'm simply saying that Egypt's isn't, and therefore the demographics of the army more directly reflect the demographics, and therefore the sympathies, of the entire population.]

Thursday was the turning point, the day when the culture of the rank and file Army and the culture of the rebels at Tahrir Square coincided.

And what was I doing on Thursday?

Thursday I met with two of our BPM customers. One, a mortgage lender, was about seven years into its BPM journey and was hosting the other, a global manufacturer, who started a BPM program about three years ago. The summit was to dive deeply into the cultural change that was required to do BPM at scale, and to discuss and show the value derived from doing this. It was cool to see one company who in their own words "has been able to re-think their whole business model" because of BPM. They've been able to survive a very rocky few years in their business in part because BPM practices "produced higher quality loans," allowed them to "react to regulations that have come down the pike in increasing frequency over the past three years" without increasing costs, and has produced a cultural acceptance of change so that major process change can be delivered in weeks and people embrace it without the cultural shock that most process change engenders.

The senior business person from the larger company made the comment that "we can talk ourselves into how we are so complicated that this is impossible, or we can simply start doing [BPM]." Another person was impressed that at the mortgage company, everybody now understood "that they were in a process, and that they know exactly who is going to be working [on this business object] next." I'm guessing that in most companies even that basic understanding is lacking en masse, in cross-functional processes.

Bringing it all back home

As I sat in front of the TV last night thinking about the role of the military in Egypt over the past few days, and stumbling across this idea that the very nature of the military's rank and file response - and the fact that it reflected largely the feelings of the rebels, both in their viewpoint and also in their essentially non-violent actions - it started me thinking that there's a role for a conscript army for BPM. In most projects we always look to champions to lead and carry the day in deploying new applications or business change. And no doubt, leaders are required. But it might also behoove us to think that forced conscription may also play a role so that we are ensured of having viewpoints, understandings and values of everyone represented in our BPM projects and programs. If you agree with me that BPM is as much a cultural issue as it is a technical one, then making sure our teams reflect the existing culture is essential to success. Only if you move the existing culture will you succeed at scale with BPM. A conscript BPM army, then, might be an interesting tactic to pursue in your program.

Last October I gave a speech where I talked about the next decade of BPM. I suggested that this decade [in BPM] would be more turbulent, more social and more transparent. I guess what I meant was that business itself was undergoing "global climate change" and that therefore adaptability itself was going to become a company's biggest competitive advantage. Adaptability by humans to changing conditions, although enabled by using the right technology, is a cultural issue.

Thursday afternoon the last thing we talked about was "looking back, did you achieve the results from BPM that you were expecting?" The CIO of the mortgage company said "No." Eyebrows raised.

"When we started in 2003 we were looking at high growth years ahead and we were requiring linear headcount increases to react to that growth. We started our BPM program so that we could scale, growing the business without requiring linear expense growth. But then the meltdown happened and instead what really happened was completely unexpected. Our [BPM-based] processes had made our loan quality improve so we didn't have to buy back any of our loans, which killed or maimed a lot of mortgage lenders. And then the regulations started hitting us right and left, yet we were able to respond to all of these without resorting to outside service providers (at increased costs) which is what most mortgage lenders had to do. Our people were used to getting tasks and knew that the processes were built for change, so acceptance of all these changes was relatively easy. We still have to train people on the changes, but change itself was no longer scary." I left there thinking that at this company, at least, BPM was directly responsible for saving some jobs, helping this company stay strong in the face of adversity.

Like Bob Dylan said: Things have changed. If you do business in the Middle East, things have changed. If you do business in the financial markets, things have changed. If you are a manufacturer, things have changed. And they will continue to. BPM can help you build a business that is adaptable; and adaptability in and of itself is becoming a value proposition, maybe THE value proposition, of this first half of the 21st century. Making sure your BPM program is built around a conscript army - a direct reflection of all the elements of your society whether they are BPM champions or not - may be a good way to start.

November 21, 2010

I'm sure it's the Apple iTunes announcement but that's what's running through my head today as we release Blueworks Live. But I guess it could also be that I think Blueworks Live represents the prettiest face in enterprise software ever released. And it's not just pretty, it's pretty useful, too. In fact, as several of the bloggers and tweeters that have seen previews of Blueworks Live have said they think this may be the biggest thing to hit BPM since, well, ever. For example: "[H]ere’s a prediction – Blueworks Live will do for business processes what Microsoft Sharepoint did for enterprise content – it will get everywhere."

Apple didn't invent the phone, or even the smart phone, but they took a huge step toward the perfection of the smart phone when they released the iPhone. In the same way, I think Blueworks Live is a huge step forward toward the perfection of BPM. It is simply gorgeous. It is simply accessible. It is, simply, an elegant solution to hundreds or thousands of seemingly intractable problems in your company - no matter the size of your company. How to corral all those ad hoc processes currently run over email? How to easily collaborate and align process improvement projects that span departments, cities, and countries? How to change from a culture of me to a culture of us, through an understanding of process? Put simply: how do I improve my business not in one area but in every area without disrupting what has to get done today?

Now, Blueworks Live isn't meant to solve every BPM problem that exists. But it does mean to participate in every BPM discussion, and contribute what it can - and what a SaaS offering should contribute given the state of the world here in 2010. There are three primary areas where Blueworks Live is focused.

1) Get rid of Process-Over-Email;

2) Identify, understand and document more repeatable processes to foster re-use and consistency;

3) Amplify the voice of process excellence and re-use across your company

Let's talk about each of these.

Get rid of Process-Over-Email

Email is good for a lot of things, but it was never designed to be your central process repository. We all know the problems with email: no visibility across peoples' work, no version control so you never quite know what version of what is being acted upon, no way to measure execution metrics (SLAs)… and many others. Yet our recent research indicates that even in large sophisticated companies about 75% of the processes that white collar workers perform use email as the primary communication mechanism. And an even greater percentage - 80% - of the people in your organization use Process-Over-Email as their primary work/process technology!

80% of your people primarily do their work in the hidden factories that are email!

Of course, there's many reasons why, not the least of which is that you can do anything you want over email… so as our customers and partners demand things, we can at least get work done over email, while our legacy systems often present roadblocks to getting work done. This benefit of the ad hoc process is the key driver of process-over-email.

So Blueworks Live is attacking that problem head on. If you use it for nothing else, Blueworks Live will allow those same people that are using email today to author their own processes, giving them all the flexibility of the email they use but adding structure to the information flowing through the process and visibility. The result is that these people will like Blueworks Live better than email; they will accomplish their jobs faster with Blueworks Live than with email; and the company will benefit from having more visibility into what's going on. To be clear: 100% of the flexibility you get with email is available in a Blueworks Live process; yet virtually every downside is eliminated. And you can do all this for US$10 per user per month!

Move toward higher process maturity

The second major benefit of Blueworks Live is in how you can document even the most complex business processes. Inside Blueworks Live we call this "blueprinting" a process. When you blueprint a process, you have an easy-to-use way for business people and subject matter experts to begin documenting their more repeatable processes just as easily as they do with PowerPoint or Visio today… or even easier, just as they would do on a white board today. And with Blueworks Live you can easily do this with colleagues in real-time, no matter where in the world anyone is.

If you use the automation parts of Blueworks Live that I discussed above, you also get visibility into all the cross-process metrics so that you can see which of those processes that used to be run over email, and are now run over Blueworks Live should actually be taken to a higher level of maturity and worked on via an on-premise BPM solution that integrates the data to your back-end systems. You see, the process-over-email alternative works, as I said, just like email: there is not integration to back end systems. But Blueworks Live gives you all the data of all these previously hidden factories so now you can actually see which of those "simple" processes are actually used a lot and could benefit from more maturity that an on-premise BPM system can provide.

So Blueworks Live helps you understand which processes to focus on, and also helps you understand and document those processes that you want to move to a higher maturity level. This is obviously a more specialized activity within Blueworks Live, yet for the authors of these processes you gain all this capability for just US$50 per user per month.

Building a new process culture

And third, Blueworks Live is built to provide a robust process forum, a place to monitor all your process activities… a place for people to ask questions about how to better do their jobs and improve the business… a place where people can follow job related activities as easily as you follow someone on Twitter, or connect with someone on LinkedIn.

If you're a small company, the private and public forums included with Blueworks Live become what big companies call their Process Center of Excellence. For large companies that have a CoE, Blueworks Live becomes a megaphone, extending the reach and voice of that organization.

Conclusion

The arc of history is clear: technology advances always insert specialists to use new technology, taking control from the original worker. Then, as the technology matures and becomes more accessible, people with more general skills gain access to the technology and regain control over their work. From farming to manufacturing to computing this has been the case. We've spent the past half century digitizing the assets of the business and that required, in essence, that control over those assets were assumed by IT. But now it's shifting back, and BPM is the mechanism by which that move is most fully realized today. IBM Blueworks Live is a major step in that evolution. It doesn't solve every BPM problem - by design! But it does solve a set of problems that have eluded IT for decades: how do we give our businesses the tooling to continue the flexible ad hoc processes they need in a changing world, while normalizing the information so that those processes are more efficient, more transparent and easy to build and deploy.

September 18, 2010

Nick Malik of Microsoft wrote a couple of nice posts about my speech at BPM 2010 earlier this week (small excerpt here). Nick's second post was a really thoughtful recasting of some of my talk (much more succinctly stated than me! but that's not unusual as anyone who knows me will tell you). There was then a comment by "Jacob E" which was also good. This post is addressed to those pieces.

Hi Nick... thanks for airing all these issues and I appreciate the attention you're giving this topic. The Democratization of BPM is a particularly passionate theme of mine (one of these days I'll walk you throughThe Governance Game, wherein I get the audience to match the historical leader with the technology era they most represent. It's always fun to talk about ERP's "five year plans"...

But I digress.

Jacob, I also appreciate the position you are in and it sounds like you're doing the client well with your actions and advice. But let me give you some insight into the end game I have in mind: there is no "Center of Excellence".

As Nick pointed out in his post, I advocated the "cloud" as a key to the future. But understand, it isn't a key because of the technology. It is key because of the business model it enables; a business model that Nick absolutely nails as part and parcel to solving this problem.

You have to have this business model to get to the business people we need... and because this business model requires the technology of the cloud, we have the opportunity to change something else, too: we can reach everyone, without translation.

When Lombardi invented Blueprint, we weren't out to build a "modeler" per se, and we weren't out to "use the cloud". We set out to understand "what happens in the 6 months before we receive an RFP for our BPMS?". It turns out that most process projects are chartered by the business for the business before IT even gets involved. For example: for you to be on-site gathering those requirements, there was work done by the business to get your PO issued even before IT got involved. There are many reasons for this - but for whatever reason, the business has no desire to engage IT that early in the process (and the reverse is true: IT doesn't have the bandwidth to get involved at that stage because 80% of the initiatives never even get funding). We found out that in the very early stages of project definition business people begin to model their processes using the #1 modeler on Planet Earth: PowerPoint! We wanted that business (sorry, Nick... although I'm not sure we've got PowerPoint on the ropes yet!)

So in order to "reach back in time 6 months," we had to find a way to get to business people with absolutely zero touch with IT required. And by the way, one thing that meant was "no downloading of any software!" Because guess what, downloading even free programs requires IT involvement at most large organizations (which is why even something like Flash was a non-starter... what if your software requires a version of Flash that isn't on the user's machine? They have to go to IT...).

All of this is to say that in order to deliver the tooling required to touch business people directly, with zero IT involvement, you have to be talking cloud. And then once you are on the cloud, the technologies of Social are, in essence, free. I think if Social is your value prop you will lose inside the enterprise. People have no time for abstract notions of "community" at work, any more than they have time for abstract notions of "process." But if the value prop is unleashed via the cloud, then Social becomes possible. And Social then can become, in essence, your Center of Excellence. This is the ultimate democratization: a Social network that enables the communication that is your Center of Excellence.

This will never happen with someone buying a "Center of Excellence in the Cloud" package. It will happen because they use a set of tooling that solves personal or small group problems... and that technology has as a secondary value prop the ability to communicate via the new Social.

Which then, finally, leads to this: my Center of Excellence isn't defined by expertise but, rather, by the velocity of communication that speeds through it. Expertise is so highly distributed and, for most interesting breakthroughs, so specialized, that the main hurdle to breakthrough isn't knowing everything, but rather, knowing where the pointer to any one thing is. A Center of Excellence should not contain experts with answers but, rather, should be a vehicle through which I can pretty easily get to any answer. It is about communication. And the faster and more robust that communication can be, the quicker the person or artifact with the answer can be identified and reached, then the better the CoE is.

In summary: In order to achieve BPM democratization, we need to dis-intermediate the experts. We can do this most easily by using The New Social. These require two things to gain entry into the organization: a new business model, and a primary value prop that allows individual productivity gains, with the Social aspects a secondary concern.

Just some thoughts early on a Saturday morning. Nick, again, thanks for the mention and wonderful job moving the thinking forward. By the way... we may be closer than you think on some of this stuff :-)

This is an excerpt from my keynote at BPM2010, held at Stevens Institute of Technology, Hoboken, New Jersey, USA on Tuesday, September 14, 2010.

As we chart the course of human technological achievement it is amazing how scalable technology is; how empowering software is. Here's where we are today. In every company of any size there's a hard core technical person; the programmer, the Java developer. And even in companies of substantial size it's really incredible how few of those people there are. Software leverages the genius.

In order to fully exploit this person we've created an entire IT organization to surround him or her. This group runs the software written by the developer, it deals with the processes and maintenance, and typically it provides the interface through which this person gets requirements; roles like business analysts are often in the IT organization. Typically, there's about five of these support people for every one of the developers and, in total, we call this "IT."

And for every six people in IT, there's about 240 real business users! This shows how leveraged IT is and is one way to think about how the power of software has led to the scale that companies are able to achieve today.

But there is a downside to all this scale, a price to pay: Agility. There's a bottleneck that's created when only a few people can actually change the systems that run our companies. Those 240 people are getting stuff done in every way possible. And they are interacting more and more with outside companies to get all their work done, not to mention the growing diversity of their customer set as we all go global. The complexity in the 240 is rising and they all have demands for "Change!" that simply can't be met. The six are under siege.

The velocity of communication in The 240 is way, way faster than the throughput of the six.

Of course we've created tooling for the six. They were our market for software and hardware. The tooling's gotten better and, most recently, even BPM has helped them do their jobs better. But let's not be fooled: even the easiest-to-use BPMS's mostly require the six to do the development. We've moved out from the one, but 90% of the BPMS development that occurs today is done by business analysts or by regular developers. We have made their jobs easier, allowing them to be more productive, but we haven't truly changed the fundamental dynamic.

As I mentioned, there is a price to pay for this leverage. The first was the bottleneck we created on the development side. The second is that the understanding of the business process has to be communicated to the six by the 240. We've created go-betweens. Business Analysts are not performing high level (and high value) quantitative analyses of their businesses; instead they are interviewing the business subject matter experts and structuring their input into some form that the developers can understand. Again, there's been tooling that helps this (for example, BPMN-based models) that speed this up and move the explicit structured conversation closer to the 240, but by and large even this is the domain of the six. Business people just don't care about the abstractions that are required for scale. They just want to get their jobs done, get home as early as they can and spend time with their family.

So the next great challenge is before us: how do we turn the notion of scale on its ear? How do we gain the involvement of the 240 real business people so that without training they can contribute their knowledge of how things work, their requests for how things should work into the explicit, unambiguous conversations required for automation? And, by doing so, how can we increase the velocity of communication for everyone, so that requirements can be more exact, more quickly and communicated more effectively, so that the scale of software can be enhanced even further.

This is the magic of the new social: turning the notion of scale away from leverage of one-to-many, to the leverage of many-to-one. That is, harvesting the direct knowledge of the many and feeding it in a structured, consumable form to the one. Can we, for example, double the 240 to 480?

By the way, this not only makes the normally unstructured conversations of real business people (documents, spreadsheets) into structured information but it also makes explicit the requirements directly from the askers instead of of from translators. It makes language itself a shared model!

December 16, 2009

Sometimes it's hard to pinpoint when everything changed. Lines are fuzzy, and even looking back on history, any particular event has a thousand beginnings. Doing it in real-time, being in the moment and at the same time identifying that moment is even riskier. What hubris it takes to say "I know that this changes everything." But at the risk of all that here I go: today, everything about BPM changes.

I can't begin to convey the impact this will have on how and where BPM will be practiced, going forward. In the blurb above on this blog site (which was posted when I started this blog in 2005), I said that by 2010 process will be the primary prism through which large companies view themselves; and that by 2020 the management of process will be "second nature." The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.

And yet very few global companies, if any, are good at this.

Bill Gates said, essentially, that any change takes longer than you expect but has bigger impact than you expect. This is especially true for change that requires great cultural movement. Technology is part and parcel to BPM, sure, but BPM is primarily about the direct involvement of business people in those technology implementations and oversight. This cultural watershed - the movement of the ownership of structured technology assets to the business - is the story of the second great wave of enterprise computing. And BPM is leading the way.

Lombardi started this BPM journey in 2000… it took our first decade just to really figure out all the moving parts and to deliver products and practices that met the need. We've seen this in technology cycles time and again. And so now as we begin the second decade of BPM the issue isn't so much "what is BPM," but "help me do BPM."

It's about having the vision to build, the discipline to execute, and the scale to deliver on the promise. I believe that only the combination of IBM and Lombardi have all those core attributes.

Where do we fit in IBM's universe? Two places, primarily.

First, Lombardi has the best business-facing BPM products, bar none. Teamworks 7 and Lombardi Blueprint are the only BPM platforms that begin to truly fulfill the dream of having real business people participate directly in the definition, creation and management of technology-dependent business processes. As we will begin showing later today, IBM is positioning Lombardi in this people-centric process space, alongside WebSphere Dynamic Process Edition for system-centric processes, and Filenet for document-centric processes. This is no doubt the best true "BPM suite" available today, offering concrete best-of-breed solutions for the breadth of process problems facing global enterprises.

Second, because Lombardi has focused on the business user, we have also focused on how to engage and support the business user. The work we've done on culture, change management, governance and BPM methodology is the best in the industry. Lombardi University and its role-based curriculum, along with tiered certifications and advanced mentoring, means that Lombardi can help IBM scale their business customers more quickly into the world of BPM. Lombardi's On-Demand Assistance program is also built from the ground up to allow fledgling BPM teams built on business-first principles to still have a technical safety net under them.

Together, IBM and Lombardi deliver scale. This is the first truly enterprise-class BPM offering. I'm not talking about transactions per second here, I'm talking about nothing less than scaling the operational capability of global industry and governments. As global trade and resource barriers have come down, so the technical silos must also come down. Yes, technology is lagging the change in corporate and government operations. Bringing these technology walls down takes more than a new tool, more than a rules engine or a BPMN diagram; it takes the ability to deliver technology AND change on the global stage, for everyone, at any time.

Enterprise BPM... no, let's call it Global BPM, is now available, for the first time. Welcome to the next decade of BPM. Welcome to the new Lombardi, soon to be part of IBM. And remember, like I've always said, "if it's BPM, it's IBM."

July 17, 2009

It's not hard to find someone who will rail against outsourcing, and often it's an IT person who is upset about the outsourcing of IT jobs to India or somewhere else. But the fact of the matter is that Western business outsourced itself long before the rise of India and other manufacturing and engineering centers. Ironically, the rise to power of that IT person is a result of this outsourcing.

It started about 45 years ago when business people began abrogating responsibility for their business information, and outsourced control of their processes and information to IT. It's led directly to the inability of business people today to think about their processes in a structured way and further, an inability to change those processes in controlled, scalable ways. Sure, business people do change... but almost all change today is via ad hoc changes carried via Excel, email and folk lore. And all the while, the business simply yells at IT to "fix my problem, faster, you idiots."

But the problem isn't solely IT's; the business has to acknowledge culpability. Mr./Ms. Business Exec: Who do you have specifically allocated to understand the totality of the processes, the data and the technologies that support your processes? Probably nobody. Or, more likely, someone in IT.

Six Sigma initiatives are not an answer. I'm not talking about measurers and abstractionists, I'm talking about people who are in there, shoulder-to-shoulder with every stakeholder, who have operational responsibility to understand, own and improve the processes.

This month's signature Harvard Business Review article discusses the manufacturing drain in America, and why it is so important to keep it. Not simply because the ability to produce is a Good Thing, but more importantly: product innovation requires the ability to understand the specifics of implementation. Similarly, business innovation requires the ability to understand the specifics of implementation!

That's because in most of these industries product and process innovation are intertwined. So the decline of manufacturing in a region sets off a chain reaction. Once manufacturing is outsourced, process-engineering expertise can't be maintained, since it depends on daily interactions with manufacturing. Without process-engineering capabilities, companies find it increasingly difficult to conduct advanced research on next-generation process technologies. Without the ability to develop such new processes, they find they can no longer develop new products. In the long term, then, an economy that lacks an infrastructure for advanced process engineering and manufacturing will lose its ability to innovate.

In reality, there are relatively few high-tech industries where the manufacturing process is not a factor in developing new - especially, radically new - products.

Read that first bit again: "Product and process innovation are intertwined..." The business is in large part defined by the processes of the business, so business people have to regain control of every aspect of the process, including the technology. I am not saying business people have to learn how to deploy applications... I am saying that you can no longer abrogate your responsibility for the details of what gets deployed. You can no longer hide behind the apron strings of Microsoft Word or some Visio drawing.

The only way to really get this detailed operational knowledge is to participate concretely in the development and operations of the process applications.

This single notion is what gives BPM its power. Everything else, from Business Process Analysis to Six Sigma to Microsoft Word requirements documents are simply delaying tactics, abstractions that don't really convey the specifics in meaningful ways, because they are not directly tied to the implemented process in a structured, traceable manner.

July 08, 2009

I'm on my third startup and I've discovered three differentiators between winners and losers: focus, sustained execution & culture. The same can be said about any new initiative, I guess. Lots of companies have gone "six sigma" yet few are really great at it. Saying "everyone is a green belt" does not a culture make.

The same is true for BPM.

So what is "culture"? How do you instantiate it? Can you do this in a repeatable, sustainable way, or is it simply the result of random evangelism by high priests. In a nutshell: how do you develop, scale and then maintain a culture?

I've been struggling with that question ever since it became apparent that culture is the single biggest impediment to moving from a "BPM project to program." There's little doubt that BPM is simply one milestone on the longer arc which is the movement of technology into the business, as business people regain control of their information. But it's a big milestone. There is as much cultural change required to do BPM at scale as there was to move to desktop computing at scale. This isn't an IT choice of, say, "BPMS vs. Ruby-on-rails."

It is BPM vs. business-as-usual.

I'm reminded of the time when the COO of a "top 10" law firm told me that "lawyers will never be typists." That was in 1990. Of course, by 2000, every lawyer was "a typist." Cultures changed, as did the economics of law firms. Firms either led or followed the move to desktop computing, but in the end everyone adapted. And the leaders thrived.

The same is now true for BPM.

Business economics are changing, and BPM can be either a catalyst or a response; an offensive weapon or a defensive one. You can lead or you can follow.

But in order to lead you must accelerate the culture required to adapt and adopt. Today's business culture, from top to bottom, is resistant to much of what BPM preaches. We pretend to champion:

Incremental, continuous improvement

Structured change

Re-use

Instead, despite our rhetoric, the actions of people in company after company show that:

We prefer to "boil the ocean" and fix everything at once (often taking the subtle form of: "automating a bad process just means you still have a bad process")

We really prefer doing things our own way and letting others do things their own way

And we truly believe our way is better, as opposed to some common way

We are BPM hypocrites.

In yesterday's New York Times, David Brooks wrote an insightful column about dignity (and the loss thereof) in the public sphere. He wrote about how as a young man George Washington, who would become the US's first president, wrote down "110 Rules of Civility & Decent Behavior," and then applied those rules to his own daily life. Brooks calls these rules "the dignity code."

"[A]s the biographer Richard Brookhiser has noted, these rules, which Washington derived from a 16th-century guidebook, were not just etiquette tips. They were designed to improve inner morals by shaping the outward man. Washington took them very seriously. He worked hard to follow them. Throughout his life, he remained acutely conscious of his own rectitude.

In so doing, he turned himself into a new kind of hero. He wasn’t primarily a military hero or a political hero. As the historian Gordon Wood has written, 'Washington became a great man and was acclaimed as a classical hero because of the way he conducted himself during times of temptation.'"

I love that idea, that "inner morals" might be "shaped by the outward man." Of course, religious and other ritualistic frameworks have existed for this same reason for centuries.

Brooks touched on this same topic last week in The Conversation, a New York Times online weekly discussion he has with Gail Collins. They were chatting about whether hypocrisy in public figures is a relevant issue. He wrote:

"I suppose it all comes down to whether you believe good character is constructed through culture and artifice, as I do, or whether you think people are naturally good and that social conventions are warping and destructive."

Character as a result of "artifice." Does BPM have an artifice, a dignity code that we can look to in times of stress?

We will all, at times, be hypocrites... we won't always do the "BPM-appropriate" thing, but we need to try. We need those rules of BPM Etiquette and Decent Behavior, so that we can objectively assess our progress. Without them, it is simply too easy to avoid "walking the talk." We will continue to give lip service to "agility" and "continuous improvement" and "change as fast as the business" but we won't. Not really.

June 28, 2009

Last week I met with the senior leadership of several of the top Indian systems integrators and outsourcers. The week not only confirmed my suspicion that these firms are becoming the strategic partners of the Global 2000, replacing the stack vendors and SAP in that role, but also shed new light on why this move might have even greater implications to the businesses they serve than even they realize.

To put it bluntly, a great outsourcer may be better at quickly improving your business than you are. Why is this? Because, these companies are quickly achieving the cultural maturity required for BPM that eludes even the most progressive companies in the world.

Companies have realized that moving from a few successful BPM projects to a scalable BPM program is difficult. Where the 80/20 of BPM projects is 80% go smoothly, the 80% of programs face difficulty. McKinsey has recent research on why this is and it argues persuasively that cultural factors are the single biggest contributor. It is hard to change a corporate culture, and business improvement programs require change to occur at every level, on every desktop.

If change is so hard, then why is it moving faster at outsourcers than at beleaguered companies? I think it is because process is their product.

Previously I've written about how outsourcing has, in the past, led to even worse process, giving the illusion of business improvement due to labor arbitrage-induced savings. But two strategic trends are forcing process improvement today... even on India. First, labor costs are normalizing with the West. They're still lower than the US and Western Europe, but not by as much as they were. And second, even lower cost countries are now competing for the BPO wallet. So the top integrators and outsourcers must achieve qualtiative process outcomes that the lowest cost providers can't achieve.

That is: the Indian outsourcing firms must drive real performance improvement into the processes they run in order to compete, achieving both efficiency and effectiveness; and they are committing to those outcomes contractually in order to win business.

In my meetings in India, I was told that the typical outsourcing deal now requires significant cost reduction every year, for increased volumes of work. Further, these deals typically are moving more and more to process outcomes (SLA's, KPI's) being measured every year, and substantial improvements in those metrics over the life of the contract. And finally, they tell me that in years one and two, much of the savings is in labor arbitrage, but that in the out years (most deals are in the 5 year range), substantive, non-linear changes are required, which force qualitative process improvements be found by the outsourcer in order to make a profit.

In a nutshell, they have to do BPM in order to do BPO. And because the process is their product they have to instill a culture of BPM in order to stay in business! Very few end user organizations have this compelling of an event. Most companies still view their product as Widget X; for the outsourcers, Widget X is the process!

This acquisition of culture is key to the strategic influence the outsourcers can gain. This isn't just about labor arbitrage, but about the willingness of the outsourcers to deliver better outcomes across the board. Instilling this culture, through acquisition or organic growth is key to scaling business improvement in general, and process improvement specifically. Could outsourcing be the fastest way to go? It may or may not be, for you. But it is true that this is the x factor that is driving business (and IT) strategy today, making the culture-carriers, the BPO's and integrators, the strategic partners for the Global 2000.

So this leads me to the final questions: today, you may think of your SI as a means to bring cost reduction and consistency to your IT processes, and your BPO partner as bringing the same to your business processes. But what if you could simply augment your business people in order to graft the culture of change? Is this a new value prop for the Indian companies? Does it accelerate your business outcomes while preserving other aspects of your company's culture in better ways than simply outsourcing everyone?

More and more companies are beginning to understand that business is change and when that's the case, process becomes your product. The Indian outsourcers could be the Toyota of white collar process understanding, and they could hold the key for business improvement ideas, like Toyota's lean production methods.

June 27, 2009

Earlier in June, I went to India to meet with our partner, Tata Consultancy Services, to dedicate our new TCS-Lombardi Insurance Solutions Lab in Bangalore. Not only does this reflect the strategic nature of our partnership with TCS, it also gave me the opportunity to meet with the leaders of many of the top Indian SI/BPO companies. I'll be blogging a bit about those meetings.

The Lab is staffed full time with TCS people and is the place where insurance solutions and frameworks are being built. TCS also announced the certification of hundreds of their people via the Lombardi University certification program, and was a launch partner for the University.