One of our customers has a really interesting set of projects. Each one individually doesn’t have a lot of sizzle to it - just enough ROI to justify doing the project. But collectively, these projects are the backbone of collecting a whole new segment of data about their business. This data could be mined to produce transformational changes in their business processes, or just tactical changes. It is actionable data. That’s pretty exciting. I hope we’ll continue to have an opportunity to work with them and work out ways to take advantage of this data.

But I think the key thing is for a big project like this to succeed, it can’t be too big. The law of large numbers can grind you down, especially on cross-functional, cross-department, cross-technology-competency-center teams. If the project is too large, too much time is spent coordinating and not enough time doing. To address that size/scale problem, we’ve broken the project into separately addressable projects that tie together with the data that we’re capturing. I think the customer is being really wise to break it down like this too.

This is a general principle that can be applied to most process projects - find logical touch points or boundaries where you can interface/integrate with the existing process and define your project accordingly around that bite-size piece. Subsequent projects can build on that first success, and leverage those interfaces. This also helps establish a pattern of successful deployments. Like any team, having a pattern of success tends to keep people motivated and on-task, and makes it more likely that future projects with ROI will be funded.

We’re about to push the first project live with this customer, and it feels good to be almost done, and get this into production to start earning that Return on the Investment for them. And then we get to move on to the next bite-sized piece, which is a really interesting bite, with a well-defined hand-off to existing systems in their enterprise.

A friend of mine recently asked me about going to work for a software vendor, we’ll call ACME. Well, specifically, what I thought of their prospects in the market, rather than what it is like to work there (after all, I don’t work there, and have never worked there). He was asking me because I’m familiar with the market space that company competes in. I thought a story/fable/parable might be a good way of addressing the question, because I don’t think my answer is really unique to his company/market/situation.

As a card carrying member of more than one corporate alumni group i’ll offer my opinion by way of comparison, by referring back to my travelogue from a previous employer. This story is from the second epoch, primarily, stretching from the time my employer at the time, we’ll call it WidgetWorks, actually had a paying customer, to the time the product actually got good (version 3… isn’t it always version 3?). WidgetWorks was going from small niche vendor to the big gorilla vendor on the block (biggest fish in a small pond). But at the time, it was only slightly larger than rivals in terms of revenue, but a greater percentage of revenues were coming from software licensing and being reinvested in software development than its rivals.

So you attended a technology conference one year and heard all about Service Oriented Architecture (SOA), and how your organization needs to devise an implementation plan now. Then the following year, Business Process Management (BPM) is all the buzz. Do I need both? Where do the lines cross? The fact is that these two topics are not mutually exclusive and each can stand on its own merit.

There’s no ‘B’usiness in SOA. Service architecture is much more about how technologists (or your IT department) choose to design, manage, and implement services within the enterprise. Yes, a well defined, well implemented SOA can reap benefits of reduced cost of ownership, rapid development, and stability which of course adds value to the Business; but SOA does not help Business managers understand and improve upon the processes that drive the enterprise. For that, we need BPM.

You see, where SOA is about technology, BPM is about discipline, improvement, and value. Sure, you’ll often find some very sophisticated technology in a BPM implementation, but that’s intended to hide the implementation details and shed light on the discipline of process management and improvement.

In practice, any major (or even minor) business process is going to rely on data and services within your enterprise. BPM allows us to quickly model these integration points and move on with the business of process enlightenment and improvement. As your process begins to come to life, those integration points will either serve as a road block to delivery, or a no-toll bridge to salvation. BPM does not replace SOA, to the contrary, BPM is even more valuable (and necessary) with a well implemented SOA. You can have well implemented services in your enterprise, but with no discipline to apply the use of those services, you’re no better off.

With a disciplined BPM implementation and an SOA delivering well defined and managed integration capabilities, your Enterprise will be full throttle delivering value to your customers and return to your investors.

I am not going to give yet another definition of BPM. That has been played out like DeLorean gull-wing doors. Everyone has a definition and in most cases they say mostly the same thing, and then the definition is changed and re-cast again:

Wikipedia – “a method of efficiently aligning an organization with the wants and needs of clients”

Gartner – “BPM is a management practice that provides for governance of a business’s process environment toward the goal of improving agility and operational performance. BPM is a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization’s activities and processes.”

I could cite more references but it’s really not all that interesting, it doesn’t tell you the ‘How’, ‘Why’, ‘When’ or especially the ‘How Much’, and the latter is much more compelling than putting just a label on BPM. This is really why we talk about Visibility, Control, and Performance in order to describe the pillars of BPM and how this all hangs together.

You can think of BPM this way, no matter what the business objectives are, when it comes to process management or improvement it is going to fall into one or more of the three categories. Visibility – we need to understand how our process is truly operating and be able to act on that information. Control – we need to fix our process because it just isn’t getting it done for the customer or the business. Performance – we need to radically improve a process because either it does not exist or, it is too expensive/broken to bring into control. Any business may be looking for one or all of the three tenets but no doubt it will be largely represented by the above framework. These three areas are closely related to one another. It helps to have visibility in what the process is really doing before you set out making changes to make it more stable (predictable) and likewise, if you are looking for truly breakthrough improvements the more stable the process is the better off you will be in terms of any major remediation work.

Now here is the best news of this whole post. You can do things starting out in Visibility that will deliver immediate and strong benefits even before you stabilize the process. You absolutely don’t have to jump-in to getting an extreme makeover before you can reap solid returns. Sometimes those returns can be big enough that there is no need to go much further out of the gate! The trick here is to understand what that process is doing first, that alone can bring relief immediately in terms of customer satisfaction, costs or even revenue for the business. By “lighting-up” the process you can instrument certain areas to behave more pro-actively, thereby minimizing the impact of an unstable process.

BPM definitions continue to change, what we are trying to communicate is just the basic physics of how this works. The business goals for BPM aren’t changing despite the wrangling over precise definitions - you want visibility, you want control, and you want performance. Focus on that, and your business can benefit and we can have fun in our work! This is how we are modeling our services in each of the pillars, as very discreet phases with very real benefits in each one.

Happy to talk more about this if you want to learn more, feel free to shoot me an email, call, or come talk to me at Driven 2008. I’ll be writing more about our framework, consider this the first volley

Not too long ago Jim Rudden posted a fun read at Lombardi’s Blog Site, and Bruce Silver responded with an equally good post here.

I couldn’t resist commenting on Bruce’s post…  I hope he won’t mind since I haven’t been a regular contributor of comments to his (or any other) blogs lately, but I hope to be more involved in the future.  To sum up my three basic points more quickly:

1. Not having a stack is rarely a sales problem for the pure-plays once they are in an evaluation with a customer.  (clearly, it is an advantage for the stackers to have a big customer-list to go calling on and get evaluations started… but once a multi-vendor evaluation is going, not having a stack is just not perceived as a problem by buyers).
2. The whole point of SOA is interoperability.  So having bought a Stacker’s SOA stack just has very little bearing (technically speaking) on whether I buy any of their other products that bolt onto that.  I evaluate each of those products against other products in that space from both other Stackers, and from pureplays.  This isn’t just true for BPM, but also for doc management and J2EE servers and databases and content management…
3. Time-value-of-money still favors the pure-plays.  If you have a process implementation that can save you $1M/quarter, you can’t afford to wait 2 years to get the software you need from your Stack Vendor.  That software will have cost you $8MM (assuming no growth in your business nor worsening of the process in question) before you give one dime to the software vendor.  By all means, buy software that works today and save as much of that $8MM opportunity as you can!

But my favorite part about all of the market analysis is that the big guys will “catch up” to the smaller players in the space.  Short of acquiring the pure plays I just don’t see how that happens.  The Stackers have so much inertia and so many lines of code to maintain, it is really quite hard for them to develop new products.  Let alone new products that appear to infringe on the turf of legacy products :)  History doesn’t show catchup through organic development investment happening that often in large software companies, and they’re running out of good pure plays to acquire!

From my perspective, I wish them all well in expanding the BPM marketplace.  I see a huge potential benefit to customers in having successful BPM roll-outs, and healthy competition can help create good solutions for customers, and for BPM practitioners like myself (ok, I admit to some self-interest here :

[author's note:  we're going to publish a number of blog posts that reveal our thought process behind what we do.  I guess you could call it looking backstage or behind the curtain.  I think this formulation is particularly interesting at the stage of the business that we're now in. ]

Not Just What. It’s How and Why.

We have a set of services we can offer customers, and in fact we have a list of a good number of those services on our website. That’s the “What” as Lance would say. But we don’t have the How, or the Why.

So Lance has been going through the process of defining the How and Why, and yet boiling it down to a visual that can be easily consumed. All great creative processes seem to require napkins or white boards. We went with white boarding. We now have a great chart on the wall that shows progression over time for achieving improvement in your process based on the three calls to action on our front page of the website: Visibility, Control, and Performance. Each horizontal band captures a discipline, and each vertical band captures a focus area. The intersections are specific services with expected outputs and expected value (return).

To me, the brainstorming around this framework was a lightbulb moment - the “aha” moment that crystallizes all those things we do into an actionable framework. For a given process, you find out what your goals are in terms of Visibility, Control, or Performance (or combination of the above), and where you are in your current progression from top to bottom (timeline reflecting actions taken to date). Based on that, the framework pretty well tells you what you should be looking to do next.

Already decided what to do? Well, our framework will tell you what the expected return on that next step is, and what the expected outputs should be.

We have some interesting ideas for this framework. It let’s us do apples to apples comparisons of projects and processes that, on the surface, are quite different. Which then allows for how we can focus our business growth and business development, because we can talk about statistically significant volume of projects and ROI’s associated.  Over the long run this will be a really valuable asset, and in the short- to medium- term it helps us drive a lot of decision-making.

We’re still working on the fit-and-finish for the framework, and it will likely to continue to be a work-in-progress as we build out our business, but watch this space for more details soon.

Recently, Flournoy Henry joined the BP3 team. Flournoy is an 18-year veteran from Aflac, where he was deeply involved in the business and information technology of the insurance business. In his last four years, he has been a BPM catalyst at Aflac. He led six major BPM process implementations and numerous major enhancements to each of those initiatives. Flournoy ran the technical evaluation of BPM software at Aflac, and then became the chief practitioner of BPM software there.

As an early adopter of Lombardi’s Teamworks®, Flournoy has been a leading voice (literally) in the BPM community by speaking at every Lombardi customer conference, speaking at Forrester and Gartner conferences, and participating in the community by providing the benefit of his experience and philosophy. If you’re a Lombardi customer, or a BPM follower, you probably know who Flournoy is.

Mr. Henry will be taking the lead on customer projects on behalf of BP3, leveraging his Lombardi Teamworks expertise and his industry knowledge to provide a great value for our customers. But most of all, we’re giving him the chance to paint on a bigger canvas - to evangelize, to help shape strategy and culture around providing value for the business first, and to craft the technology strategy to support the business goals.

Hope you’ll join us in welcoming Flournoy to the team!