Welcome to the Second Decade of BPM

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.

Just a few minutes ago we announced that IBM will acquire Lombardi.

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 the 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."

December 16, 2009 at 06:32 AM | Permalink | Comments (1)

Feedburner Issues

Maddening, but now Google says the "feeds2..." designation isn't correct, so it's back to "feeds..."  

August 19, 2009 at 03:44 PM | Permalink | Comments (0) | TrackBack (0)

It Isn't BPM, It's IBM

Yesterday, Dennis Byron of ebizQ presented a false choice between "BPM point solutions" and the stack vendors' "BPM suites." But this isn't the choice at all. IBM doesn't do BPM, not really, despite the Orwellian marketing rhetoric (although it is a delight to see them describe "Dynamic Process Edition" - a collection of four no-doubt business-friendly Websphere tools - as a "comprehensive foundation to deploy dynamic business processes in response to changing business needs." BINGO, for goodness sake!)

With just a tweak, replacing "BPM point products" with "personal computers," this line from Dennis's post could have been written in 1984: "IT managers and staffers have to ask--again and constantly--do I want to bet my job and my enterprise's success on personal computers anymore?" Those pesky business users...

The choice isn't between pure-play vendors and stack vendors, the choice is between BPM or IBM.

What is BPM? I think it's pretty simple: put the business back in charge of its business assets. And what is IBM? Keep that control in IT.

The Business Assets

These assets can be classified in two broad buckets:

• How you do business (the processes)
• What business you do (the data)

The "how" of business can be expressed in any number of ways, but the most pertinent is via the prism of process. So the first order of business for BPM is for the business to regain ownership of defining, understanding, implementing, measuring and improving its own processes. This job has been largely outsourced to IT over the past four decades. You hear this in the statement "the process is what the application does." And since IT controls the application, it controls the process. This isn't BPM, it's IBM. This has to change.

The "what" of business is the actual business data. Today, most system-of-record business data is electronic in nature. How does a business person access this data? Probably through applications controlled by IT. Go ahead, ask how long it will take to get a certain report. And what about process performance data? It isn't even available. This isn't BPM, it's IBM. This has to change.

And so while Dennis thinks my take on IBM's "free BPM" is simply some specific deal, he's wrong. Ask any BPM practitioner in any account where IBM has leverage and s/he'll tell you the same story. This is nothing less than a strategy to kill real BPM, and IBM executes that strategy every day in every way. As I've pointed out in the past, they want to kill off the impertinent notion of business-people controlling the business assets. IBM has spent almost half a century building up their control over this information, and they're not going to give it up without a fight!

"A point in every direction..."

So, Dennis, you're wrong on this one. IBM doesn't do BPM, so saying there's a choice between "point solutions" and the stackers is a false choice. Don't take my word for it, search for "dynamic business process management" on the IBM site. Look at all the stuff they say you'll need for BPM. 20 tools? 30 tools? Or you can look to mainstream analysts who have tried to find and interview IBM BPM references.  Their findings, as published in reports you can see if you are a client, will show that customers aren't moving very quickly with their BPM deployments, and they usually have to use other tools in addition to the "WebSphere Dynamic Process Edition" to author real-world processes and reports.

Take a lesson from Oblio: having a point in every direction is the same as having no point at all. And that isn't BPM, it's IBM.

ps - here's a link to Scott Francis's original blog post that Dennis forgot to include yesterday, as well as Scott's reply to Dennis.

July 22, 2009 at 05:19 PM | Permalink | Comments (1)

One Single Solitary Notion

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.

Gary P. Pisano and Willy C. Shih; Restoring American Competitiveness; Harvard Business Review (July - August 2009)

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 17, 2009 at 10:59 AM | Permalink | Comments (0) | TrackBack (0)

Flash: Free IBM BPMS Worth Exactly What It Costs

Today one of our customers said they were told by IBM: "why spend your money with Lombardi, we'll give you our BPMS for free." I finally agree 100% with IBM on something: their BPMS is worth nothing. Getting a cheap BPMS is like buying a dancing elephant for a dollar: cool, but who can afford to feed it?

But this notion of getting "free" or highly-discounted software from strategic vendors has currency. How many times has your company picked up some crap from some vendor because it's on a discount schedule and you have to buy x amount of software each year to "maintain your discount." So let's discuss the cost of software, and the value of software.

Software has no intrinsic value. Nobody buys software for its own sake; it's not like a Howard Finster painting. Software's value is derived solely from the productivity it provides. It has extrinsic value.

Take the iPhone and the Blackberry. I switched from the BB a year or so ago, and found that while my email productivity has gone down on the iPhone, productivity in all other areas (web browsing, attachment reading, etc.) has gone up. So which is "better" depends on the outcomes I'm optimizing for. For me, my overall productivity on the iPhone is better than my overall productivity on the BB. I don't go back to the BB just because it costs less (which it does), because the cell phone is a tool, its value isn't intrinsic, it's extrinsic: the "cost" of the device is a combination of my own time and performance using it together with the money I pay directly for it.

Stated simply: even a "free" Blackberry would cost me a lot more than an iPhone.

The same is true for your BPMS decision: the extrinsic value gained or lost will be much greater than the "savings" on the software. So be sure you understand what extrinsic value a good BPMS can provide, and then factor that against the "savings" of a cheap BPMS that won't provide those values.

The value props of a BPMS are pretty simple:

1. Lower development costs vs. traditional tools
2. Increased business performance vs. traditional tools

Reduced Development Costs

You will expend less effort to get a similar process application with a good BPMS vs. a cheap one. Requirements-gathering is easier because business people can participate directly with IT using the same tools. Therefore, the requirements can be explicitly stated and understood, instead of the usual ambiguity of Word documents and white boards; and because business and IT use the same tooling, the business can understand "the art of the possible" more quickly, leading to more productive discussions around scope and trade-offs.

You can't get this collaboration with a bunch of tarted-up Websphere tools available on the cheap.

Building a Better Process

The importance of having business SMEs working shoulder-to-shoulder with IT people on the process application isn't simply about changing the economics of application development, it also leads to better business outcomes. With direct engagement from model to implementation, business people are for the first time able to quickly discover linkages that would be buried or just not thought of. A hospital group in England recovers an additional £300,000 per month because a business person developing a patient process application realized how some patients were simply never being billed because of the way the underlying process worked. This would not have happened if the business person wasn't able to be in the details during the design and development of the process automation project.

The business involvement is not to make programmers of business people. It is to have them more intimately involved in the ownership of their processes and their information that is flowing through those processes. This level of detail is only understandable via the technology tooling. Therefore, the tooling has to be more broadly accessible or the whole value prop is blown.

Because Lombardi uses a shared model, instead of UML and BPEL and Java and God-knows-what-else, the business can understand at a detailed level exactly what it is able to get.

But don't just take my word for it. Talk to our customers, and then get references for those cheap tools (if you can find them). Be sure to ask them whether the applications they built were built using only the tools you were shown... or did they also have to deal with, say, an event handler, a message bus, maybe an analytics package for reports? What else wasn't "free" and, more important, what else was inaccessible to business users?

Ask about all those IBM BPMS references who started an application in January 2009, deployed it in April, and then changed it twice, in May and June. That's the kind of experience one of our insurance customers had, using Teamworks in an underwriting process. This, from an internal review just completed:

"So useful that [we] have already made the following list of changes during May and June as a result of using this scoreboard:

• Modified 7 rules
• Added 2 questions
  
• Modified 3 questions
• Added help text to 2 questions
  
• Created additional reference materials
  

[T]he product manager has already requested more data and more reports. This validates the benefits of having visibility to this data. This is precisely what any company needs right now, especially in this economy, visibility into their operations in order to ensure their viability."

Lower costs, faster turn-around, better visibility... a better business outcome because of Teamworks. All in one package, straightforwardly and fairly priced.

Or you can go for the "free" one and pay out the wazzoo.

July 16, 2009 at 03:44 PM | Permalink | Comments (1)

BPM, George Washington & The Dignity Code

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.

We need a BPM dignity code.

July 8, 2009 at 05:59 PM | Permalink | Comments (0) | TrackBack (0)

When Process Is Your Product

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 28, 2009 at 01:12 PM | Permalink | Comments (0) | TrackBack (0)

Tata Consultancy Services - Lombardi Insurance Solutions Lab

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.

We're proud to be a key partner inside the TCS ecosystem.

June 27, 2009 at 02:31 PM | Permalink | Comments (0) | TrackBack (0)

BPM: Bigger than SOA

I think most people would agree that BPM is bigger than SOA, in fact, SOA is simply the technology architecture that defines how any technology is designed and deployed. BPM, on the other hand, represents how you link business strategy to business implementation... with [SOA-based] technology being a part of that implementation.

Well, now there's independent confirmation that BPM is, indeed, bigger than SOA - or at least twice as much BPM information is being searched. Google's Keyword Tool shows that in May, the phrase "business process management" was used almost twice as many times as "service oriented architecture", with a higher Adword value. (Too bad we don't compete in the "consolidate student loan" space...)

I doubt if IBM or any of the other SOA stackers are in jeopardy of being bought by Lombardi any time soon, but at least with Lombardi you know you're getting more bang for the buck. Twice as much value, in fact...

June 26, 2009 at 11:50 AM | Permalink | Comments (0)

The Platform For BPM's Second Decade

"I tell you captain, if you look in the maps of the worlds, I warrant you shall find in the comparisons between Macedon and Monmouth, that the situations, look you, is both alike. There is a river in Macedon, and there is also moreover a river at Monmouth."

- Fluellen, in Shakespeare's Henry V, explaining that his hometown Monmouth, Wales, is very similar indeed to the classical kingdom of Macedonia

Last night I had a dream that Fluellen said: "Pegasystems has training. Oracle has a BPMS. And IBM has Blueworks. I warrant you shall find in comparison of these situations with Lombardi, look you, is all alike."

The Welsh do make me laugh, and I did, I woke up laughing.

Normally, I use this blog to talk about industry issues and try to not so much flog Lombardi-specific products as deal with universal issues. But not today. Today is the culmination of hundreds of man years of effort and understanding here at Lombardi. Today marks the end of what I call "the first decade of BPM" and sets the industry on what I think is going to be an all-new course, or more accurately, a much broader and valuable course. And so out of pride, but also because I think that the BPM industry shifted today, I want to write about Lombardi.

Today Lombardi announced major advances in all three areas that determine success or failure in BPM:

• The need to communicate - you have to make business improvement personal
• The need to automate - you have to drive productivity and re-use
• The need for talent - you need to be able to assess risk, plan, and lead

Forget about simplistic approaches to driving transformational change based solely on whether your BPMS (or "BPP" or "PAAS") has a given feature. The so-called "Business Process Platform" as a sole-sourced technological salvation is a hoax. It's a solipsistic approach by technologists to once again say "if I have a better tool, I won't be as big a fool." Go on, stare at your image in the water and try to pawn all this off on simply another development tool or architecture. Instead, you need to take to heart what Toby Redshaw, CIO of Aviva, said a couple of weeks ago (paraphrasing here): If you're in IT and not doing BPM, three years from now you won't have a job.

He wasn't talking about a tool. He was talking about change and changing everything: how we relate IT to the business, how we use tools, and how we manage, nay, lead, change in our businesses through the use of BPM tools and methods.

Today Lombardi re-defined what a BPM platform needs to be; three specific vehicles:

Blueprint (Spring '09): The place your people should go for business improvement conversations. Using a unique approach of combining structured process (BPA) tooling with Facebook-style social networking and wiki documentation, Blueprint helps guide personal conversations about "how I think I can do my job better" into the scalable discovery of practical business improvements. Blueprint puts BPM on every desktop. Some of our customers have made this commitment and are in the process of training thousands of users. Yes, thousands. Want to knock down some walls in your company? Put Blueprint on every desktop and lead people (by example) to make suggestions about their jobs, their tasks, their activities. Even if you're not ready for the automation part of BPM, Blueprint will help you discover your processes, and then improve them. BPM isn't just about "modeling" and "BPMN" or "rules." It's about changing a culture, about embedding technology into the fabric of how we do things. We can learn from social media how to do this. This isn't your daddy's enterprise software, because it isn't 1983 anymore (or 1977, or 1896).

Teamworks 7: What's new about BPM-style process application development? It's the model, stupid. And so why is all the management of models and their internal assets built on top of traditional, decades-old-school-text-based source control systems? Using models, the application development goes faster, but then when you save a version of the model and try to manage it (both at design-time and at run-time), our competitors use traditional notions, or incomplete representations of the model (they might, for example, restore the rule that existed at some point in time, but not the UI's or the integrations).

Teamworks 7 answers this question with a completely new way to manage process models for their entire life - from the beginning of time. We looked at every use case along the entire process application life-cycle and we solved every problem that BPM-style development threw at us. Let's take a simple example. BPM demands iterative development. So what happens at the end of every sprint in agile? You know what happens: you tell people to "stop development for 24 hours" to stabilize the system, to make sure it's going to work. With Teamworks 7 you simply create a snapshot of the working version, then you keep developing, and when it's time for the Playback, with one click you go Back In Time to the Playback version (while all the other developers are still working on the tip), and you play it back. Zero lost productivity, entire model-universe reversion. One click. Back In Time is the biggest advance in iterative/agile development tooling since the method was developed. And you can quote me.

But that's just the beginning of Teamworks 7's repository model management. Dependency management is a problem that is solved, finally, with Teamworks 7. This is the best way to manage dependencies in any SOA development environment. Ever.  Because of this, Teamworks 7 also enables re-use to an extent never before realized. Re-use is the lynchpin of the BPM value prop. And the barrier to real-world re-use of technology assets isn't knowing they exist, it's knowing you won't get screwed by upgrades to those processes/services if they change. With Teamworks 7, you won't get screwed from service or rule re-use. Ever. And yes, you can quote me on that.

Lombardi University: OK, so you have people talking to one another. And you have a platform that truly enables the end-to-end business process application life-cycle. Now what? "How do I sell BPM to the business?" "Where do I find qualified people?" "What skills do I need?" "My infrastructure is maintained in a different group, and they are difficult to deal with!" Although BPM is (relatively) new, it isn't about all-new skills, and it's not about building an empire or creating an "other" part of the organization to deal with BPM. This is about adding the unique aspects of BPM-style development and management to each of your peoples' CV's. Sure, all vendors do staff-augmentation with experts, but there's also skills-augmentation. And frankly, this is what we are hearing our customers and partners want. "I have good people who can (build apps) (lead projects) (maintain infrastructure) but this is a bit different. Teach my people. Help me (or my partner) become self-sufficient in a scalable way."

With Lombardi University, there is now a roles-based way to augment your peoples' and your partners' skills. Roles-based is the key. This isn't simply education on the speeds and feeds of a tool.

And with Lombardi University certification, you can also measure the attainment of those skills and your own maturity as an organization. Have you deployed five process applications? How many people can you rely on to maintain that infrastructure? How do you assess the risk you are assuming? How do you talk about a 1, 2 or 3 year roadmap of skills development? With Lombardi University, there is now a way to do just that.

And not only that, I've talked with CIOs around the world and their #1 talent concern is this: how should I lead my BPM initiative? Who should do that? What does that person look like? Well now, for the first time, there's BPM Executive Leadership courses. We're launching two at the outset. These courses don't teach modeling and products, they teach how BPM is different from other programs - and how it is the same - and gives concrete guidance on how to lead your BPM effort, so that it doesn't become an "other" - that it is mainstreamed into the programatic fiber of your company.

By the way, we can't do all this by ourselves. So we've embraced technology from Saba to help you manage your talent development programs, they're the leader in career development software (in fact, your HR group might use Saba... if so, we can mash it all up and you can manage your BPM careers along with the rest of your career development efforts).

We've also engaged outside faculty. Industry experts like Bruce Silver will be delivering courses available through our catalog. Some of them use Lombardi tooling, some don't. The issue is education, not brainwashing. If you succeed with our help, we'll do fine. Derek Miers and his BPM Focus group will be teaching Lombardi University courses. Same with Dr. John Alden, 30 years with Accenture, co-founder of Terraquest. And Andrew Spanyi, author of probably my favorite BPM book, BPM is a Team Sport. This isn't altruism that we're practicing here, it's about your success. If we assist in that, we'll figure the money bits out. So Lombardi University is attracting the best BPM faculty in the world (if you want to be a part of our Extended Faculty, let me know).

Together, these 3 pillars - communication, automation and leadership - combine to form the basis for the platform for BPM's second decade. Lombardi is that platform. You don't have to do it all at once. Like all journeys, BPM is something best tackled one step at a time. Ping us for more information. I promise that if you do, you won't confuse us with Pegasystems, Oracle or IBM, or any other Monmouth of BPM...

May 12, 2009 at 09:01 PM | Permalink | Comments (1) | TrackBack (0)