1. Expert instructors, who are actively working in their field.
2. A curriculum with a strong practical focus.
3. Perspectives drawn from a broad range of real world experience.

These same 3 key factors were core design principles for our Level 2 BPM Developer course – which takes good BPM Developers and helps them transform into master BPM Developers.

Most of our customers have learned how to build successful process applications, but they are still unclear on how to best leverage Teamworks to address their more complex application requirements.  They want to know how to design, architect and implement very robust process applications … how to master the use of Teamworks. 

That’s why Lombardi field mentors lead the instruction of our Level 2 class.  Lombardi mentors are highly experienced implementation consultants that work shoulder-to-shoulder with customers – but as mentors their focus is on teaching the customer how to build the solution, rather than building it for them.  Their mission is to build self-sufficiency in our customer teams and transfer knowledge about BPM best practices and implementation techniques.

Our mentors and consultants helped design a Level 2 BPM Developer curriculum with a strong practical focus.  Through 6 half day instructional modules, we teach the most common complex requirement patterns encountered in the field and the best practices for addressing those patterns.  The course topics and hands-on exercises are based on experience gained by Lombardi field delivery teams across hundreds of customer projects.

This unique blend of BPM best practice and deep hands-on implementation skills enables us to create a new educational experience where participants sharpen their advanced technical skills while internalizing proven BPM engineering discipline.

We don’t expect everyone in your organization to become a master BPM developer, but our experience has shown that having several key individuals with this level of expertise is critical.  They provide essential development and architecture leadership for your company.  Having individuals with this level of advanced skill leads to higher levels of self-sufficiency, productivity and overall business impact for your BPM team.

A recent study by Staffing.com revealed that 70% of applicants and 28% of hiring managers are dissatisfied with how their hiring processes work; and that is just one of the many critical processes in your company. Effective documentation of your HR processes can lead to impressive savings and a large reduction in your company’s overhead.

Optimizing your HR processes is critical for saving time, avoiding errors and reducing company overhead. The absolute best way to save time and money is through process documentation. If you are interested in finding out how to quickly document and streamline your key processes, there is a simple next step. Just click the link below to download the full white paper.

Get the White Paper: A Simple Approach to Documenting Your HR Process

Ready to start documenting your processes now? To effectively document your processes, you will need the right tool. Click here for a free trial of Lombardi Blueprint, the easiest process documentation tool on the market.

At Lombardi, we say this all the time. Obtaining useful data about the quality of decisions being made – as well as the patterns that drive those decisions – is the first step in realizing the promise of BPM.

However, in order for data to be turned into “wisdom,” I think it is important for companies to realize that it has to be viewed through three primary filtering principles. They are:

1. Visibility – Show me information in a human-consumable format. It needs to provide details that can be understood by mere mortals.
2. Analysis – Allow me to ‘twist and turn’ and ‘slice and dice’ the information views so that I can extrapolate information from the data and deduce higher-level knowledge as necessary. 
3. Control – Once I’ve seen, analyzed, and judged what the data is telling me, allow me to take some immediate action on the source of data (the process) in a way that lets me materially affect the outcome. 

In my mind, the three points made above are the key stepping stones that separate workflow automation from BPM. In fact, I think of automation as merely the “step zero” that must to occur in the sequence above before I can get any real insight into my processes.

Now, in contrast to my insurance customer example, there are also other many other business processes where the primary purpose of automation is to drive repeatability, and to deal with exceptions in such a way that it ultimately turns those exceptions back to repeatability. In essence, I’m talking about the industrialization of human decision making.
 
These processes do exist (for example, customers doing processes such as vehicle registration renewal, product returns, shipment re-routing, and even HR on-boarding) and in isolation, the biggest benefit that our customers derive from a BPM tool in this instance is the automation of their workflows. But in this case, the process reports that they receive either measure efficiency of the industrialization (rework, time spent, etc.) or only hold business value when taken in context with a higher-level parent process.

Perhaps the distinction between what could be referred to as “BPM-ripe” processes and “BPM-ambivalent-but-automation-ripe” processes is an important factor in determining an organization’s BPM Maturity Level.  

One of the mantras of the BPMC team here at Lombardi is to help customers understand that the difference between these two distinctions. This is really important, because it can mean the difference between companies doing the right thing for their unique BPM project starting on “day one” versus having them realize what the right thing is – much, much later in the project (such as during the third playback).

It’s obvious BPM has come of age when mainstream media programs are starting to weigh-in on the topic.

The hour-long show featured ‘HIM: Handling the Human Side of BPM,’ and focused on whether the new Human Interaction Management (HIM) framework  is necessary given that BPM already addresses most of the same issues and is a mature discipline. 

In addtion to Phil, the other invited guests were Clay Richardson (senior analyst at Forrester) and Howard Smith (BPM author and CTO of CSC’s European Group).

If you are interested in hearing how BPM can help your organization,  or if you need a better way to explain its benefits to your executives, you should listen to the replay. You can access the replay here (not required to register).

FCE, which is a subsidiary of the Bank of Ireland Group, provides a broad range of currency conversion products and services to wide range of industries and uses both Blueprint and Teamworks as an alternative to traditional application development. Using BPM lets them deliver projects an eye-popping 50% faster than traditional  approaches.

Some important take-aways discussed in the webinar include:

• How they became self sufficient after their very first project
• How they gather business requirements in a much more collaborative way
• How they recevied valuable feedback during development, not waiting until after it’s 80% built
• How to engage the business to take ownership in their business applications

To listen to the FCE webinar, go here (you will need to register) or alternately you can listen to a podcast version of the interview here.

The article, “MUSC cuts error rates and improves efficiency with automation” discusses the financial grants management process that MUSC implemented in Lombardi Teamworks. It also points out the reasons why they elected NOT to go with an ERP system to accomplish this project, and and how they incorporated some legacy systems into the process.

Some nice ROI figures that MUSC achieved:

• [Teamworks] has reduced the per-grant error rate dramatically, from 85 – 90 percent down to just 20 - 25 percent initially, then finally 2 percent to 3 percent as users learned to use more efficient processes.
• “human touches” during the grants allocation process, traditionally a source of errors in any process, have dropped 65 percent.

You may read the whole story here

The article, entitled “BPM tools help firms bridge communications gaps in supply chains,” provides some interesting insight into how manufacturers can receive value from BPM. 

One of the customers is El Araby, an air conditioner manufacturer based in Cairo, Egypt. They had this to say:

 “Before Lombardi Software [BPM] was in place, all we could do for a customer was recommend them to the nearest service center and that was the end of it… We had no clue what happened next until the monthly report came out afterwards. Now, the Lombardi BPM software system handles all of the details of the repair process, even down to what technician is working on what appliance in what service center.”

We’re pretty proud that Teamworks customers around the world like to share such great testimony!

You can read the whole story here.

Here are a couple of interesting thoughts/takeaways that came up during the conference.

The BPM Talent Gap

As companies really try to ramp up their BPM initiatives, they often encounter a “BPM talent gap” in their own organizations as well as in the partners they typically use for solution delivery. Phil Gilbert, Lombardi’s President, talked about how this talent gap is found in multiple roles – from Business Analysis to Program Management to Business Leadership. The good news is that this gap can be readily addressed – often with the team you have at hand. Its just a matter of recognizing the gaps and developing a known set of skills. In fact, Toby Redshaw, CIO at Aviva, talked about the fact that anyone who wants to work in IT over the next few years must be focused on gaining the skills and capabilities required to succeed with BPM. This talent gap issue was also discussed at Gartner’s BPM Show in San Diego this Spring as well as in a great research article called “IT’s Unmet Potential” in the McKinsey Quarterly. Definitely recommended reading.

The Importance of Success Stories

The best way to launch a BPM Center of Excellence (COE) is with success stories. Sometimes the inclination is to focus only on defining standard templates, governance bodies, org structures and the like. In his session, Paul Tazbaz, Enterprise Architect from Wells Fargo talked about how they focused on documenting a set of BPM success stories at the beginning of their COE initiative. These success stories formed the basis of their early conversations with lines of business and corporate IT as they championed BPM across the company. Note that these success stories were about BPM – and many of the success stories predated the formation of the COE. No matter – Paul’s group is focused on getting business units to take advantage of BPM. No better way to do that than to tell them 10 stories about groups in Wells Fargo benefiting from BPM today. Sure makes for a more interesting first meeting with your lines of business than “This is BPMN and you WILL use it.”

Stay tuned for more tales from Lombardi Driven Online. Note that the conference is still available on-demand. If you are a customer or partner and missed the live event, you can still register for access here.

And that they are equally wrong when they blame blue collar workers, runaway salaries or lack of technology innovation as the only problems to plague corporate America. In this piece, he argues the real problem lies deep in the white collar ranks, where large inefficiencies and enormous risks are created by a lack of visibility.

Take a minute to read the piece and let us know your thoughts.

Frederick Winslow Taylor is known as the father of scientific management.

In the late19^th Century, FWT studied the gainful organization of work within the corporation, from a structured, ordered perspective.  In his view, there were two types of people engaged in this endeavor. Those who do the work, and those who manage the work.  Put simply, the work of the workers is to do. And the work of the managers is to think.  Managers do not work; they control work.  And workers do not think, they do.  Managers = Brains. Workers = Brawn.

Here is a Taylor quote from Wikipedia that nicely illustrates the viewpoint:

“I can say, without the slightest hesitation, that the science of handling pig-iron is so great that the man who is physically able to handle pig-iron and is sufficiently phlegmatic and stupid to choose this for his occupation is rarely able to comprehend the science of handling pig-iron.”

Now don’t get me wrong.  I have a lot of respect for FWT’s pioneering efforts in the field of business theory and as a management consultant.

But now, BPM, a Three-Letter-Acronym, has killed him dead.

How did BPM inflict this fatal blow?

Firstly, BPM automates low-value-added tasks, shifting effort to higher value-added work, like:

• Analyzing data and acting upon it; not wasting time just collecting data
• Investigating and solving problems, not struggling to ascertain the facts
• Customer services people spending time talking to customers, helping them, not doing mundane administrative tasks

Secondly, BPM supports continuous improvement.  The process worker, instead of doing things “the way they’ve always been done”, can actually contribute to improving the process.  When the organization reaches a critical mass of people not just doing the work, but continuously improving the way things are done, the cultural shift occurs…the magic happens.

Let technology do what technology does best – like heavy computation (a computer crunches numbers far quicker than I can scribble on the back of an envelope) and repetitive, standardized tasks (such as production line robotics welding two bits of car together).  And let humans concentrate on the things that humans do best – such as thinking, applying judgment, communicating.  This is not only more satisfying for the person doing work; but far more productive.

And as for these workers – “Subject Matter Experts” as I prefer to call them – well, I just can’t imagine a successful BPM project without them!

I recently attended a Lean Six Sigma conference. It’s always interesting to hear evangelists from various industries in different countries sharing their experiences with improving efficiency, effectiveness, and moving towards a culture of high performance and continuous improvement.

It never fails to surprise me how dogmatic many are about their particular flavor of methodology. Within the Lean Six Sigma camp there are Six Sigma purists who will partake of no Lean. There are Lean gurus who speak not of Six Sigma. Then there are the fusionistas, who happily take the best bits of both. (Personally, I’m willing to utilize any tools that get results within a structured framework.) Some proudly advertise their allegiance, while others refuse to be pigeonholed and embrace a more neutral term such as Process Improvement or Operational Excellence. As a pragmatist I tend towards the latter – in my experience, for every person out there in a position of influence who is pro a “Big M” methodology, there will be another who is equally (or more!) anti that same methodology. So why provoke resistance to change over a mere label? Well, that’s just my two cents!

There was a LOT of talk about the need for strong leadership support for any improvement initiative to be successful. This is generally considered a given to the point of being trite, yet the lack of consistently strong and visible leadership is clearly still limiting many companies from scaling their efforts and reaping the fullest possible rewards. One speech on this topic eloquently contrasted a firm’s successful periods of improvement gains under strong sponsorship, with periods of regression under weak, indifferent leadership. So as obvious as it may seem, I still proclaim effective leadership as one of my top prerequisites for success.

But what surprised – or dismayed – me most at the conference was the almost total absence of discussion around BPM. So many organizations well versed in the process perspective, analyzing problems, reducing waste, measuring defects…and so little awareness of the platform that unites all of these methodologies with actual execution, measurement, monitoring and control. Admittedly, Lean and Six Sigma both pre-date BPM, but to me the connection is very clear. BPM addresses process excellence in a holistic way, and in particular enables measuring and controlling far beyond that which can be done manually with checklists and sticky notes.

I guess this labels me as one of the fusionistas!

I’d like to share with you a little set-piece that I often use with clients as a learning aid.  I call it (rather unimaginatively!) my “Google Maps exercise” and it makes some very neat points with regards to process decomposition and modeling best practices.

A common challenge I encounter is that people get bogged down with figuring out the level of detail they should go to. This isn’t because of the lack of a definitive standard for process levels – I think the root cause of the difficulty is simply that process modeling is not an exact science.  In fact, much of it is quite subjective.

So, the exercise usually goes something like this…

I’ll launch Google Maps, projected on a large screen to share with the audience.

At first, I zoom to country level.

“I’m unfamiliar with this city.” I’ll say. “How do I get from this office building to my hotel? Is this map helpful?”

“No!” they chorus. The scale is too small.

So I zoom in to the regional level.

“Any good now?”

“No!”

“What if I were trying to figure out a route from the next city?”

Maybe!

And so it goes on, until we’re at street level, and the audience agrees that the map is useful for my navigational purposes. What if I switch to terrain view?

“Not so useful!” is the standard response.

“What if I zoom out a little?  Which one is right?”

“Well – they’re both right!” comes the answer on cue.  And so the point is made.

Factual correctness is one thing. Usefulness – based on the appropriate level of detail, and the “view” or “perspective”- is another, and really depends on the intended purpose of the map.  As they say in NLP, “the map is not the territory.”  In other words, it is just a representation of reality that may serve a useful purpose in a certain context.

Successful process modeling incorporates several facets. A standard modeling notation, such as BPMN, is one element. Standards and conventions, beyond the formal rules of the notation, represent another.  But there is a third, less tangible element that relates to style, level of detail, fitness of purpose, crispness of description…the factors of quality communication.  Put it this way – you can speak English and have a word processor, but that alone won’t make you the next Shakespeare – there’s an art to it as well!

So which side do you approach first?

There’s a tendency for enterprise software to gravitate to IT. And why not?  IT gets it, right? They understand the technology and the inherent benefits it brings to the table. And IT is constantly justifying new software, hardware and services through the annual budget reviews. So it seems natural for anyone wishing to see a BPM solution deployed to look at IT first.

I believe this is a mistake.

Despite conventional thinking, the right place to begin conveying the benefits of a BPM deployment is on the business side of the house. That’s because BPM has to be looked at not for the technology, features and specs, but for its ability to change and improve the business.

If you’re implementing a BPM strategy, you have to lead with the person who can ask questions like, “What are all the touch points. How does this affect our business? What is the value we are getting out of this? How do you actually measure the benefits that we are going to get out of this?”  These questions and answers are best addressed by the business.

On many occasions, when I have engaged with IT department, I struggled with knowing the business benefits of the BPM deployment.  Typically, IT is reacting to a request from the business.  And being the IT department within a company they don’t always care what the business benefits are.  They have a mandate to fulfill those requests to the best of their ability. So I feel like we can work better with our customers when we engage directly with the business.

Conversely, the business side sometimes has an unnatural understanding of what IT does. Most technical strategies are not for the business to drive and, in fact, by bringing the business to the table as part of these strategies, you bring into effect an unnatural alliance where natural departmental goals are subverted.

I think that part of that is good because they are both trying to talk the same language. And it’s not that IT isn’t talking the business language, it’s that the business is trying to talk the IT language. This can lead to increased communication between the two houses, but under a vision of making each other’s jobs easier, which isn’t really the point. The point is to realize business value and add to the bottom line of the organization.

I still think the business side is the best location to gain advocacy and support. But when you engage with the business, strive for the enterprise level over the department level.

That’s where you’re going to find the people with the broader business goals and ultimately the people who are going to provide approvals and sign the checks. But if that’s not possible, strive for a connection at the higher end departmental level. Get a foothold there and try to showcase some value.

Once the initial process success is achieved, BPM finds the largest welcome mat on multiple departmental doors. The results of a well-executed BPM campaign are far more compelling than a canned demo. And while it’s good to start on the business side when beginning a BPM project, you have to ultimately have both sides working together for success. BPM should unite the two groups. Not just serve as a communications conduit between the two.

]]> http://blog.lombardi.com/who-has-the-biggest-welcome-mat-for-bpm/feed/ 0 http://blog.lombardi.com/searchcio-bpm-case-study-with-nacco%e2%80%99s-bob-shallow/ http://blog.lombardi.com/searchcio-bpm-case-study-with-nacco%e2%80%99s-bob-shallow/#comments Tue, 11 Nov 2008 21:32:19 +0000 Wayne Snell http://blog.lombardi.com/?p=222

Yesterday SearchCIO and Accenture published a new webcast with Bob Shallow, who is the Director of Global Product Development Processes, Systems and Operations at NACCO Material Handling Group, a $2.8 billion dollar company that engineers and manufactures Hyster and Yale Material Handling Equipment (lift trucks, aftermarket parts, etc.).

NACCO is also a Lombardi customer, and you can read more about them here.

In the webcast Bob talks about what exactly has been accomplished using BPM at NACCO, demonstrating an architectural step-through of how their processes have changed, with a particular focus on ROI. It’s exciting that so many Lombardi customers like NACCO are passionate about their BPM successes and want to share their best practices.

You’ll need to register on the SearchCIO site to view the webcast.

Do not be alarmed. This post is not an instruction manual on the finer points of BPMN. For those of you who wish to indulge, this should provide you with many hours of entertainment.

Rather, I want to reflect upon a few thoughts about process modeling, and share some practical hints.

And whilst Blueprint is my favorite modeling tool in existence, the following comments are equally applicable whether you’re using sticky notes, a white board, or the back of an envelope. (I’ve also seen bits of string used quite creatively!)

Process modeling is a process in itself. Therefore, like any other process, we can aim to improve its efficiency, effectiveness and flexibility. So instead of approaching modeling in an ad-hoc manner, how can we make it more repeatable, reduce the cycle time, raise quality and customer satisfaction?

To me, process modeling is fundamentally an exercise in communication. A model may be generated in order to share information between members of a project team about the way the process currently works. Or to share information between the project team and the stakeholders. Or with vendors. Or between a business expert and a business analyst. Or a business analyst and a developer. In all of these instances, the process modeling is not meant to be an end in itself, but a means to identify, verify, and inform interested parties about the way the process is, could or should be.

If we accept the model as an abstraction of reality, a visual representation of various process attributes, then the question arises not so much as to whether a process model is right or wrong, but, like a conversation between two people – is it effective or ineffective? Does it convey useful meaning to the intended audience, or not? A meaningful communication forms a sound basis for action – but a confusing, misleading or ambiguous one cannot be expected to yield a high quality outcome. Garbage in, garbage out.

How then, to create effective, clear, useful communication about a process?

In the first instance: Simplicity. Occam’s razor, “Keep It Simple, Stupid” and all that. Is it really necessary to show every little bit of detail on one enormous process map? Can you, or anyone else, really understand what’s going on amongst all of that noise? Perhaps you can use sub-processes, linked processes, or notes to keep things relatively high level, so the general flow, relationships and dependencies are obvious.

George Orwell wrote “Good prose is like a window pane”. So is a good process model. Make it clear and no more complicated than it needs to be.

Consistency, too, can be of great help. An activity, for example, should be a verb – it represents someone or something doing something. Name similar actions in a similar way, yet make them specific – “Notify Completion” rather than “Send Email” – and apply these principles across different processes. Show similar patterns (e.g. chasing responses) in a uniform way.

Types of process model. Not all process models are created equal. Form should follow function. What are your objectives – spotting opportunities for process improvement; training material; compliance & controls documentation; BPM execution?

The purpose of the model determines how detailed and technical the model should be. A model to be used for training new staff should be broken down into detailed steps with minimal assumption gaps. A “To Be” design for presentation to senior business executives for approval should be more high-level and descriptive, and be sparing with objects like decisions, gateways, and events. However, in modeling for execution it is necessary to use such devices in all their glory.

Method. The way you approach process modeling may impact how complicated or simple it turns out. You don’t have to model one perfect box at a time, it’s fine to draft something out from end to end, then go back & make it more consistent, more concise – or more detailed if necessary. Remember, there’s no right or wrong as such! Get agreement when you have the full process width, then following significant revisions.

Have you got it wrong if you end up with spaghetti? Well, it depends. Maybe your current process is spaghetti, in which case that’s a useful thing to share. But you wouldn’t want that for a “To Be”. It’s usually possible to take a higher-level view, and maintain the detail behind the scenes, utilizing linked processes, sub-processes, and notes as appropriate.

I believe in process modeling as a means to an end….ideally for improving the process, and sharing process information with those who need to understand it. I urge you not to get caught up modeling for modeling’s sake, but as a precursor to action. And remember, communicate not obfuscate!

There’s a great piece up on Forbes right now, titled “The ABC’s of BPM.”

The article is part of the very well-informed “JargonSpy” series, whose goal is to educate the publication’s audience about the business value behind some of the technology world’s more opaque acronyms (let’s be honest, BPM isn’t exactly swimming in sex appeal is it?)

The author is Dan Woods, who is also the CTO at Evolved Media and the author of the book Process First: The Evolution of the Business Process Expert.

In the article, Dan talks in depth about the coming of age of the process expert, especially vis-à-vis the translation task that is “needed constantly between the business as it defines the process and the IT staff as it communicates what functionality is needed.”

Indeed, we’ve come a long way since Fredrick Winslow Taylor, who created some of the very first models of efficiency in the late 19^th century.

And I love the way that Dan puts it – that the most important quality in a process expert is a “sophisticated empathy for both business processes and technology to keep the flow of communication going between business and IT.”

It’s that “sophisticated empathy” that we at Lombardi spend every day cultivating – both in our people – and in our products themselves.

Here’s to continued recognition of the importance of BPM by the mainstream business press.

Efficiency - How quick can we get it done?

Reducing the cycle time on a process, whether it is a new hire process or loan origination, provides value.  You can quantify the amount of time it took before the project and quantify how long each cycle takes after the process improvements.  Efficiency has a high tangibility factor, it’s measurable, and therefore remains the strongest, or most useful selling point when trying to achieve buy-in from other units in the organization.

Effectiveness - How effective is the process that was implemented?

Effectiveness is, of course, an extremely important criterion when assessing a process.  However, it’s not as measurable as efficiency.  There’s a low “tangibility factor” here because different business units, organizations and individuals speak different languages when discussing the effectiveness of a process.  Is a process effective because it improves customer service?  Yes, but is customer service a highly relevant criterion when assessing an HR process?  Cycle time applies to all processes and all departments, but effectiveness is measured according to the responsibilities and values of each department.  That being said, effectiveness is tied to consistency, which proves to be a tremendous source of value in any organization.  This a key point to bring up when presenting the benefits of a BPM project.

Agility - How quick and easy can you change?

There’s no doubt that agility is even more intangible than effectiveness.  Agility, although incredibly important to the organization, is always associated with the long term view of a process.  Individuals within an organization look for results in the “here and now” and often times don’t consider the value of being able to change processes quickly and with ease as the business requirements change.  We see this with IT all the time…you hand them requirements and they develop an application that meets those requirements.  Unfortunately, by the time that app dev is complete, the requirements have changed.  An agile organization is able to change quickly and with ease as the business requirements change.

Summary:

BPM offers process solutions that provide all of the above benefits.  A well planned and executed process improvement initiative will drive efficiency, effectiveness and agility. But organizations have to share a common language when they are looking back at their projects and measuring their value.  If you really want to get the budget for a process improvement project, you better know what benefits BPM can provide and how to present them to the budget gate-keeper.

I want to talk a little bit about what is, in my mind, the most interesting part of having exposure to BPM initiatives across a wide range of industries.

This is in fact one of the great advantages that we at Lombardi have as a pure-play solution provider, and it’s something we’re going to continue to capitalize on, especially from a services perspective.  It’s also one of the things that I love most about my job – the opportunity to solve process problems in an array of different verticals, taking and sharing best practices and key learnings among them.

BPM folk love to talk about agility. And it is less and less a secret that BPM is one very important way that organizations can future-proof themselves against the inevitable. In today’s case, for example, it’s rising fuel prices, the mortgage meltdown, and unstable capital markets, each of which is having a unique effect on our customers.

In fact, one of the things that my team and I are spending a lot of time on these days is going out and looking at new and/or developing industry requirements, things from a compliance perspective, for example, that are coming up in legislative decisions and that may very well impact different organizations and different industries profoundly. By getting in front of these changes and helping customers to understand how they can use BPM to solve related/resulting issues, we help them not only comply, but also acheive visibility into things that they are mandated or regulated to do – proactively, instead of reactively.

Slowly, more and more enterprises are coming to understand the difference between proactively dealing with changes in the market, and again, doing so only reactively. The former group is taking advantage of a major opportunity to get a leg up on competitors.  BPM has the power to expose, and subsequently capitalize on, these opportunities.

But to get in on the front end of these opportunities  requires expertise and research that isn’t always readily available if you work in-house. Like I said above, I love my job because I get a chance to work in every industry/vertical imaginable and use my skills in each. Being proactive also involves being innovative, and often it means being the first in your industry to tackle a new problem.

When you have the kind of exposure that we have — exposure across industries and verticals — something reveals itself to you that might at first seem completely counterintuitive, and that’s what I’m driving at and what I want to share as the big takeaway of this post.

When you’re exposed to a diversity of BPM challenges, what you very quickly figure out is that whether you are dealing with, say, a huge manufacturer of X and Y parts, or a big box retailer, or a big entertainment conglomerate, all of the processes involved pretty much look the same.

Order to cash looks pretty much the same, the HR on-boarding process looks pretty much the same, inventory management looks pretty much the same. . .a process is a process is a process.

Now don’t get me wrong, the devil certainly is in the details, and there is a great deal of nuance involved. But after you’ve done it enough times, the similarities outweigh the differences by far.

Nonetheless, enterprises can get really hung up on how insurmountably complex and confusing their individual challenges are. Sometimes when you’re looking around in your own industry and seeing your competitors and colleagues having the same problems and also having the same difficulties solving those problems, it’s only natural to question whether there really is, in fact, a viable solution at all. But this is precisely the kind of mentality that eventually leads an organization to take a reactive approach to process, rather than a proactive one, which as I suggested above is a far superior way of going about improving the way you do business.

Everyone has “the most complex process in the world”. Sometimes it’s even a badge of honor, a sign that you’ve been to hell and back. . .and survived.  It’s not fun to be in this situation, and I’m not suggesting that anyone is exaggerating – there is nothing more legitimately mind-numbing and stress-inducing than a process that refuses to cooperate.

But once you’ve had experience in a variety of verticals and industries, you’re able to abstract these localized, industry-specific problems.  You can bring it up a level and you actually can learn from other industries. Like I said, a process is a process is a process. The traditional assumption is that what worked for a financial services firm couldn’t possibly work in the food services industry, for example. But is can, and it does.

Ironically we can often take learnings in one industry that has literally nothing to do with another (at face value anyway), and apply some of our successes and some of those learnings and really get companies to start thinking about things in a way that they maybe hadn’t thought about before. It can be a truly liberating experience.  The puzzle might be completely different, but the pieces are almost always the same. When an organization starts to realize this, it opens eyes and allows the team to be much more proactive. You start to look around and think ahead of the curve. You get hungry again, instead of just trying to make it out alive.

I try to help customers understand that the process is only as big and as bad as you make it, and that’s the truth.

We are working with several companies right now that will tell you that their process problems are the most complex of any organization that we will ever work with. Specifically we have one customer who is in a retail environment and they are working on inventory management and it is the most complex inventory management process ever, according to them. But we have another customer who is oversees and they are an entertainment company, and they are looking at inventory and order management and of course they think that they have the most complex process as well.  And yet another customer (that I can’t say much about, unfortunately) currently finds itself in the very same boat too.

If I were to describe all three inventory management processes, or even map them and use generic terms to document them, all three of those customers would think that the diagram I had put up on the wall was their own.

I want to encourage companies in any and every industry to think about what they can learn from other industries and verticals, even if it does seem counterintuitive at first. The help of a vendor or a consulting or services firm may help, but the fundamental insight that I want to convey still stands – a process is a process is a process – and the solution is out there. In recognizing this, you can pull yourself up out of a traditional, reactive approach and start thinking about competitive advantage again, about innovating ahead of the curve, and about taking on new challenges before they become a threat to your business.

Ed.: This is the fourth and last post in a series of Q+A sessions focusing specifically on playback session best practices, with our in-house expert, Kris Komassa. See our previous coverage here.

Anyone besides the BPM team, subject matter experts, and business managers that you’ve had involved in a playback session? Who do you usually suggest be present?

It varies.  I’ve had CIOs CEOs, end users, it runs the gamut.  Ultimately, you want to have a true cross-section of the organization present.

I always like to have my core project team and IT staff involved of course, but again when it comes to the playback, a diversity of roles and perspectives is important. For example, one bank we work with has a very diverse set of processes, so within their playbacks I have had a bank teller, a bank CSR person, a bank loan officer, a bank loan manager, an executive approver and then the core project team on top of that.

For me if you follow that process from a linear prospective, you need to have someone who can weigh in on every part of the process.  I like to have people in the room to say “yes” or “no” each step of the way — and in that sense you need to think long and hard and do your best to anticipate the questions that are going to be asked at every stage. You learn over time, of course, too, and I’m always happy to talk in greater depth about specific industries or situations, just leave a note in the comments.

This is more of a cultural question, I suppose — in all stages, what would you recommend to help stakeholders step outside of the box during a playback session? Sometimes challenging the status quo can lead to the most frank (and productive) assessment, say, for example, having to do with different modeling approaches.

That’s a good question and it’s a challenge especially when dealing with businesspeople because they only know what they know.  They’re often bothered by a mindset of “well this is what I know.”

I ask a lot of questions and encourage clients to ask questions in return — I want them to take a hard look at everything, and I want them to step out of their comfort zone. Ultimately it’s more about the questions than the answers — what’s at stake cuts to the very heart of the business itself, and we can’t afford to leave any stones unturned.

You have to look at is this way: teams cannot fix a fundamentally bad process. So, we want to be sure that everything that comes out of a session is worth the investment of time and resources that we are going to put into it.  It’s easier to do this at the very beginning, before you’ve committed to a course of action, and have already began executing against that plan. The earlier you ask the hard questions, the better. Start early and never stop. I challenge my customers to ask “why?” and “how?” constantly, and at every process step to conclude whether a given step is truly relevant.  And, is there any way to automate that step, is it truly a required step, and/or can it be optimized further down the road?  You have to be stubborn, because there is no substitute for that kind of frankness, which can ultimately make or break a project.

Ed.: If you have any playback-specific questions that you’d like to have answered, either as a follow-up to the content discussed here, as just in general, leave us a note in the comments!

The other day SearchCIO published a feature on BPM that included two Lombardi customers, Wells Fargo and NACCO Materials Handling.

The piece is notable as a case study because of the quantifiable successes it reports – for example, the $250,000 savings realized on a project with the centralized loan disposition group at Wells Fargo, and the cost authorization system that Bob Shallow and his team over at NACCO implemented in an unprecedented 15 days.

The author, Sarah Varney, is right in pointing out the many challenges companies face along the way – everything from internal politics, to an inherent distrust of IT tools on the part of the business, to issues of bandwidth and a lack of resources.  But as Wells Fargo and NACCO have shown, anything is possible with the right team and the right solution.

Thinking about different ways to explain BPM to your co-workers? Check out the video below – produced by NACCO Materials Handling Group. They make REALLY big forklifts. Bet you never thought you could use Benny Hill to explain why your company needs BPM?

For the more serious side of this BPM initiative, check out Bob Shallow (Director of Global Product Development) on a recent webinar that highlights lessons learned from his initial process improvement efforts. Note that you will have to register with eBizQ. Here is the link.

This short, 3-minute podcast features Peter Schoof, the editor of ebizQ, and Gene Rawls, VP of Continuous Improvement at Wells Fargo (a Lombardi customer). It was recorded last week at the Gartner BPM Summit in Washington, D.C., where Gene gave a talk titled “How Wells Fargo Built a Cross-Organizational BPM Capability.”

In the podcast, Gene goes over the three categories of gains that the company is pursuing with its BPM initiatives:

• Cost take-out, i.e. improving processes where the company doesn’t need to spend at the level at which it is currently spending
• Cost avoidance, i.e. where the company can avoid an expense altogether
• Revenue increase, which is self explanatory, but just as important as the other two categories, and in some cases even moreso

Gene explains how Well Fargo strives to be measurable at every stage. Measurability is key to executive-level understanding, and we’re seeing more and more time and effort being put into measurability across all of our customers. Measurability is also a huge factor in moving from project-based BPM work to enterprise-wide initiatives.

Three years ago, Gene and his team took a step back and realized that in order to deliver what the business really wanted, a change needed to take place, and that change was BPM. After a series of successful projects, Gene and his team are now moving to implement Teamworks more broadly within their organization, at the business unit level.

You can read more about Wells Fargo here and here.

BPM project durations are usually measured in weeks-to-months – not months-to-years. With this velocity, you can’t afford to get stuck in the rut of traditional “define & design” techniques based on multiple rounds of 1-on-1 analysis meetings. In fact, I’d go so far as to label this as rework which increases a project’s cycle time!

I’m an enthusiastic supporter of the workshop format, where not only speed, but also quality, visibility and buy-in are greatly enhanced compared to the 1-on-1 approach. You could say it’s a way of applying process improvement methods to the way we carry out process improvement itself (or “PI²” as I like to call it).

In a previous blog, I shared some secrets of success for the “2 x 6 workshop“. One of the critical success factors is utilizing a facilitator – “an impartial, objective analyst to run the session, keep it crisp and in-focus”. Let’s dive into that a bit more. Why do we need the facilitator role, how does it add value to the process of process improvement, and how can it be done well?

Whether you’re defining your project scope, capturing the “As Is” process, or designing a new & improved process, an impartial facilitator can provide these kinds of benefits:

• As a guide, not a referee, the facilitator can lead participants to their own (joint) conclusions, gaining inherent consensus. The attendees walk out of the workshop aligned to the outcome that they have contributed to.
• With a fresh perspective – not being an expert in the given process – the facilitator can question, challenge, and seek clarification. For the facilitator to understand the process, as a layperson, the outputs must be very clear and straightforward. Such clear and straightforward analysis is of benefit to all involved – from the sponsor signing off the project, to the developers implementing the proposed solution.

• The facilitator is focused on realizing the objectives of the session within the allotted time. You may be surprised at how much can be achieved in a relatively short time-frame, when assisted by sharp facilitation skills.

On the other hand, without dedicated facilitation, there is the possibility that the session may:

• Not yield the required objectives, or drag on well past the agreed time.
• Produce poor results, such as a sub-optimal process re-design.
• Break down into arguments, based on “irreconcilable” differences between those with different viewpoints & vested interests in the planned change.
• Result in “bad press” for the project, fueling doubts & resistance to change from which the project may never recover!

So what makes a good facilitator?

• To paraphrase the real estate proverb – “Communication, communication, communication!” An excellent listener, able to coalesce multiple fragments of information and summarize back to the audience
• Considerable patience. The ability to elicit the best possible information from participants who may be nervous, angry, rude, bored or just plain apathetic!
• Flexibility – to be able to modify the approach appropriately, situationally, and deal with the unexpected

Here are some specific recommendations, from my own experience:

• Stay focused on the specific objectives of the current workshop. If modeling the as-is, stick to the way things are at the moment, no matter how bad it is -  don’t allow the participants to leap ahead to solutions. If modeling a “blue sky To-Be” then ensure everyone can brainstorm freely without fear of criticism or self-imposed constraints or limitations
• A little well-placed, friendly humor can be very effective at breaking the tension and getting a team to gel quickly.
• Like an air traffic controller – use “holding patterns” to take the level of detail up or down as necessary. It’s ok to ask for more detail to understand a critical activity, for example, but in other cases you need to cut the tangential discussions and bring the session back on course
• Timing – your participants will appreciate you concluding the workshop on time, and having short breaks – 5 or 10 minutes – no longer than one hour apart. Even the most enthusiastic participants will find their concentration waning after 45 – 50 minutes, so let them freshen their coffee but make sure they’re back promptly
• Some basic rules, such as mobile phones switched to silent, and “only one person talking at a time” may come in handy and should be agreed up front
• Never criticize or rebuke – the facilitator should have the soft skills necessary to firmly, yet politely, deal with the devil’s advocate, the incessantly chatty, the dissenter
• Practice makes perfect. There is no single correct way to do this, nor should there be – give it your own personal touch!

And by the way – there is no law against having fun – enjoy it!

Bob Shallow, director of global product development at NACCO Materials Handling Group will share his experiences on a BPM case study panel session during the conference. And Gene Rawls, vice president of continuous improvement at Wells Fargo Financial will present his company’s BPM experiences in a Lombardi-hosted case study session.

From Lombardi, Phil Gilbert, president, will present during a luncheon keynote. During his presentation, “Governing an Enterprise-Wide BPM Program” Phil will share insight into new structural capabilities in chartering and governance needed to make BPM an internal competency to scale the delivery of BPM projects. He’ll also propose five “Charters for BPM Governance” to help companies make the move from “project to program.”

Also from Lombardi will be Toby Cappello, vice present of professional services, to present, “Breaking Down the Three Major Barriers to BPM Success.”

If you’re planning to attend the conference, stop by and see us at booth #10. We’d love to see you there.

I’ve talked a little bit about change management in previous posts, and I’ll continue on that theme here. This post is about talking it out, pure and simple — and in the process establishing important relationships that weren’t there before. I’ve also touched on how it is common to just throw things over the wall and not know what happens after that — it is really important to get in the habit of walking around to the other side of that wall and having regular conversations with the other people involved in a given process. This is an extension of that same idea.

Note: the best practices that I describe below usually come into play at a more mature process stage where we’re trying to jump-start some new initiatives or reinvigorate old ones, but it also applies to the beginning stages as well.

Overall, it is of the greatest importance that you first make sure that other people in the room or on the phone hear the larger story or narrative of the process, and understand where they fit into that bigger picture. This is always where we start. A lot of times when you give people this kind of perspective, the floodgates will open — as a result, colleagues start sharing their own experiences and other anecdotal pieces of information and ultimately this is how you get to reality. Perception is reality when you are working with process, and talking it out helps you to start putting some of that picture together. They say a picture is with a thousand words — from a process perspective it is usually worth another million once we start collecting information. Much of what we learn, in fact, can remain hidden, again, without the proper perspective as to why it does or does not matter. You’d be surprised what people bottle up because they feel it isn’t applicable to the project as a whole or they don’t think you’ll actually listen to what they have to say.

The next step is where I usually start looking at rules to govern how we move forward, to provide some structure around that bigger picture. This is a huge take-away for effective change management. Getting all of the information is crucial, but structuring that information thereafter is even more important — if you don’t move swiftly from one to the other, it’s easy to feel overwhelmed.

Types of structure might include nailing down the critical success factors, the must-haves, or the must-do things that absolutely positively have to happen with the project, the process, or whatever the case may be within your own organization.

After applying some structure, the third step is sharing that structure and direction back down with the people who gave you the raw data in the first place. In truth, this action alone warrants an entire blog post, but in short, communicating the priorities and objectives clearly, and how they link back to your colleagues’ own experiences, is the ideal way to facilitate change, especially with an audience that hasn’t necessarily felt that they are being heard to-date.  The more invested people feel, with a clearly defined structure, the better. It’s an important combination.

I once had three very adversarial groups that we was working with, and we could not get them to all come together in the same room for essentially this exact reason — specifically, each felt that the other’s interests were being more fully represented at the sponsorship level. The three groups were not fully invested, and there wasn’t a clearly defined structure. Each group was looking out for #1, anxiously guarding against failure. In this case the groups were HR, IT and Real Estate, and everyone thought that they were getting the short end of the stick in terms of visibility and buy-in. But from our perspective there was so much overlap and synergy that it was crucial that we get everyone on the same page and start to realize some of that potential.  We had seen a lot of success with BPM so far, but the team was at an impasse and unable to move forward with what we knew was a huge opportunity. Over time, each group had come to think that that they alone were right, and each had erected barriers that they weren’t willing to give up on. So, we started by putting them in the same room and encouraging them to just talk in a very unstructured way, trying not to worry about the end game too much. My team and I just focused on listening – and sometimes it really is all about just that — people want to be heard.

Then, we started distilling from that conversation the critical success factors and we began throwing it all up on the wall for them to look at, sort of taking it out of their hands and putting it into the world, which is a very powerful gesture.  All of a sudden now, the three groups weren’t pointing at each other — instead they were pointing at this list of items and priorities and they very quickly realized how many things were complimentary, and how many things were directly impacting each other and it was pretty amazing to see those walls break down.

Of course, some of what we discussed in the example above was out of scope, but it was more important to make people feel as though they were being heard and that their concerns and ambitions were being accounted for.  The priorities find a way of sorting themselves out once information has been openly shared and written down and given the proper respect.

So get out there and just start talking!  Begin by laying out the narrative of the process. That will help facilitate an open sharing of information, and here all you need to do is listen. Then, start to put some structure around that information, but do it in a way that takes the emotional aspect out of the equation. Finally, share those goals and the plan moving forward back downstream, making sure that everyone feels like they are now part of the story, and have a sense of the role they are going to play.

Honestly, it’s easy in the process world to get caught up in rhetoric, and. . .process! If you’re looking to jumpstart a new project or really put some new life into an old one, sometimes its as simple as just getting people talking. Dialogue can break down walls and enact an important cultural change to the point that the conversation never ends — in my mind, that’s process excellence, and that’s continuous improvement.

IW’s John Soat then posted an excellent write-up of the survey’s findings, and I’ve been thinking about it ever since. John writes:

“Whether they know it or not–and most do–companies need an executive leader well versed in both technology and business processes. The CIO position is tailor made to take that role. . .the question is, which CIOs will step up to it?”

This chart (also below) based on the survey’s findings isn’t surprising if you’ve been looking at things from a process point of view as long as we have, but it’s not trivial that respondents noted “Need to manage or optimize business process” as the #1 priority as the CIO continues to strive to become more of a business leader.

Jon also writes:

“A similar question, with a similar response, was this: ‘What do you see as the main opportunities before CIOs today?’ The No. 1 answer by both CIOs and corporate managers is ‘improve and/or innovate new business processes’. . . the CIO’s overview of corporate-wide systems and applications gives the CIO as deep and encompassing an understanding of the organization’s business processes as any executive, on par with that of the CEO and CFO. It makes sense that the CIO would seek–and be called on–to leverage that process expertise.”

Let’s go a little further though, because insofar as process excellence is top-of-mind, what exactly is driving this focus on business-side leadership?

The evolving role of the CIO (and by extension the IT organization itself), of course. The fact of the matter is that any true executive leader will be fluent in both technology and business principle – and the processes that govern the cross-functional nature of today’s leading companies.

As always, technology leadership remains important – the ability to look into the future and understand which technologies will have strategic value and ongoing impact is a necessary skill. But today, business-side savvy is equally important, a fact that Harvey Koeppel, executive director of the Center for CIO Leadership, echos in the article, explaining that for CIO’s, “speaking the language of the C-suite, development of one-to-one relationships, and driving the agenda” are paramount, because “[CIO’s are] at the center of the most important trends in business today.”

And InformationWeek isn’t the only place where this trend is being put front and center. In April, IT Week (UK) wrote a great piece summarizing Gartner’s 2008 worldwide survey, which likewise determined that BPM has become CIO’s top priority.

We at Lombardi are proud of our leadership position in BPM, in no small part because we have been aggressively talking about business-focused technology and cross-functional roles since the very beginning. We haven’t shied away from explaining why BPM will become the focus of solution engineering at enterprises large and small.

As technology continues to underwrite the business in an ever-more fundamental sense, we’ll continue to see process take center stage. The question I have for our readers though is – although the trend isn’t exactly anything new, has BPM indeed gone mainstream? Are you approaching the same tipping point at your company?

Getting started with BPM makes many people nervous, and for good reason.  Change can bring uncertainty and fear – and hence often generates resistance.  In response to this type of internal skepticism and unrest, I frequently recommend conducting a 2×6 workshop when initially analyzing your processes to engage and excite the people who live the processes every day.

But before I tell how to run a 2×6 workshop, I would like to put it in context:

BPM is first and foremost a discipline to improve the efficiency, effectiveness and agility of a business, from a process viewpoint, to deliver real business value.  That being said, you have to do a certain amount of rewiring PEOPLE and your organization before you can start worrying about the software.

To really drive BPM in your organization, you need strategies in place to make the shift a bit easier for your workers to consume.  People don’t want change to be forced upon them.  But if you present them with an opportunity to help drive that change, then they can become fully invested as participants who help shape their own future.  So when you begin your initiative and need to take stock of where you are, you do some process analysis.  How do you get started?

My suggestion is that you start with a 2×6 workshop for each process that you’ve selected. This is quite simply a 2-hour meeting with roughly 6 people who are knowledgeable or involved in the process you want to analyze.  The ultimate goal of this session is to map the “As Is” or current state of the process in question, and start to understand the existing problems or pain points that are motivating change, while at the same time helping them to realize the practical benefits of the BPM approach in their jobs.

Here’s the recipe for the ideal 2×6 workshop:

• Secure the right participants
• Have the right facilities & tools in place
• Capture the process milestones (start, end & key phases)
• Elicit the major high level activities across the full width of the process
• Follow the happy path (you can incorporate the most significant exceptions, if you must!)
• Warning…beware the “Detail Devil” – don’t go too deep too soon!
• Layer in the process participants, problems, key inputs & outputs and capture any useful notes
• Obtain sign-off from the participants/process owner at the end of the workshop – not later!

Remember that getting the right people into the room absolutely critical.  Using the following as a guide for who you need in your 2×6 workshop:

• Facilitator – An impartial, objective analyst to run the session, keep it crisp and in-focus.
• Process Owner – Responsible for process definition and signs off on the outputs.
• SME’s – The people who know and DO the work in detail – on a daily basis.
• IT - Someone who support the process and brings a tech perspective.

At first, these participants may be skeptical, cautious, even nervous about BPM. But as they see their process captured visually, and start identifying all the different problems that that they experience with the process, you may well find the session ends up like group therapy! All of us in change management are solution-focused at heart, but the essential thing here is to concentrate on the problems, and create a sense of purpose and urgency for improvement. People will become excited about the potential for improving the way that they do things on a day-to-day basis and being an integral part of that initiative.

It sounds a bit like an episode of Dr. Phil. But the bottom line is that for your organization to improve – and to sustain that improvement – you need a set of communication techniques in order to really get things going and start driving the cultural change as well as technical change.  A 2×6 workshop is a communication channel and method of building stakeholder support, as much as a way to quickly launch the modeling and analysis necessary for a solid program foundation. And that, I imagine you will find, is an enticing reward for a couple of hours’ work.

As you can see throughout the entire Lombardi philosophy, in adopting BPM you’re rewiring your organizations DNA.  Part of that DNA is software, part of it is people and part of it is process.  The approach to a successful BPM project has to incorporate an understanding of all of these elements, and should encourage and facilitate communication between them.

Hopefully this will help you to get some traction in your initiative. If you’ve had some success with these types of workshops, please share your story in the comments.

By Rod Favaron, CEO Lombardi

I get asked about market consolidation all the time. Customers, prospects, industry analysts and investment bankers want to know how companies like Lombardi can continue to thrive in the face of the relentless consolidation drive by IBM, Oracle and SAP. The answer is simple: innovation. Markets always consolidate. That very fact creates opportunity for the companies that are able to innovate. Consolidation and innovation actually feed each other. How?

Let’s look at consolidation. How does it benefit the end customer of software? The promises are many: better integration, comprehensive functionality, simpler management and streamlined procurement. That last point – streamlined procurement – may be the only promise delivered to date.

In a recent article in CIO Magazine, Martin Veitch commented – “IBM and Oracle seem to be in a race to build up the world’s largest miscellany of enterprise software programs,” and “customers continue to have faith until the next procurement round. However, a lot of people are unimpressed by the levels of integration and R&D that follow the incessant deal-making.” Within Lombardi’s own Business Process Management market, Oracle’s acquisition of BEA and the resulting announcement of a combined BPM strategy got similarly low marks from industry observers.

The end result is that customers wait many years – and still do not get products that can solve their immediate problems. They get roadmaps for rationalization and consolidation. They get long lists of product lines and product names. Take Oracle as an example. They announced the Fusion roadmap in 2005. At that time, oil was $50 a barrel and the housing and banking sectors were clicking along at historic levels. The world market has changed dramatically since then, but Oracle is still trying to deliver the original Fusion roadmap. And now, that roadmap is muddled again by the BEA acquisition.

Which creates opportunity for innovators like Lombardi. We make software and provide services that help people solve their pressing process problems. Not the problems they may have in two years – the problems they have today.

Our innovation is a combination of technology and know-how that helps business and IT teams work together to build better processes. Every one of the companies that turns to us for BPM has a significant footprint with IBM, Oracle or SAP. And in every case, these companies have evaluated whether the vast collection of development tools marketed as “BPM” by Oracle, SAP and IBM can work. They don’t – no matter what the roadmap says. So, these companies choose to work with us. And by making this choice for innovation, they get value NOW from BPM.

So, our market continues to grow because our innovation delivers value. That growth is not threatened by market consolidation. Quite the opposite – our growth is fed by market consolidation.

When your organization’s products are intangible, like an investment CD or a retirement plan, it’s sometimes difficult to identify waste or inefficiencies in your business.  Today I want to discuss some of the unique attributes of financial services organizations and how to look at these businesses through the prism of process to find problems that are often overlooked.

Financial services often tend to think of themselves as very different from other types of organizations.  For example, many firms have organically grown along the lines of “functional silos” based on different types of product, reinforced by separate IT applications supporting these product categories. Yet, every organization shares similar horizontal functions such as human resources, finance or accounting.  These functions alone offer more than enough opportunity for delivering business value through a BPM initiative.  But, I promise there’s more!

Financial services companies are generally very IT-intensive, and open to new technology and approaches to problem solving.  However, it can be difficult for these organizations to determine which solutions fit their needs the best – or even which problems to address – since their products are not tangible like a car or any product that you can hold in your hand.  If you can’t see your product, it can be difficult to see your problems like “defects” and “waste”.

Furthermore, regulatory monitoring & reporting requirements such as Sarbanes Oxley and Basel 2 have weighed heavily on this industry. Combined with global economic factors such as the credit crunch, there’s huge pressure on financial services companies to increase visibility, transparency and controls whilst reducing costs and simultaneously improving customer service.

In steps BPM…

There’s no doubt that BPM is extraordinarily useful in helping organizations meet their SOX and other compliance obligations, by providing the necessary controls and visible evidence of these controls. However in meeting these requirements, there is also a fantastic opportunity to look at the business through a process lens and seek opportunities to reduce waste (cost) and improve the speed and consistency of process delivery (customer service).

There are many useful practices from process improvement methodologies such as Lean Six Sigma which can be used to identify opportunities for improvement, which can then be implemented using BPM. In my opinion, Lean Six Sigma is a great match for BPM.  The problem is that many financial services companies think that these techniques are just tools for industries such as manufacturing which do have a physical product. They therefore tend to look only at the technology side of automation rather than from the “outside in” customer perspective that such process improvement approaches can offer.  But simply automating a bad process can deliver poor results.

For instance, if a car is moving down the assembly line and the doors don’t fit properly, the problem will be obvious, and quickly rectified.  In financial services, a security breach or act of internal fraud is difficult to immediately notice.  If an email from a customer has been sitting in someone’s inbox for three weeks, there’s no way for someone else to notice. This is what BPM helps to manage in this industry – it provides visibility into the status and performance of processes that might help identify and address problems – or better yet, to prevent problems before they occur.

If you can’t plainly see problems, you may not even be aware of them, and you will probably have difficulty solving them. Or you may be trying to solve the “wrong problem” with unexpected consequences!  To this point, I have to commend financial services organizations that have implemented a BPM program.  It’s not easy to look at things through the process prism.  This involves challenging the status quo of the organization, and asking a lot of questions which may not have previously been considered. As I mentioned above, these organizations have a lot going on in their IT departments, the business is worried about a lot of external factors, and if your woes aren’t as visible as a botched paint job on a car, then it’s hard to diagnose it as a process problem and the prescription for BPM is not written.

Ultimately, the business has to recognize these problems and work with IT to find ways to fix them.

If you take away just one thing from this, start thinking about your business through the prism of process.  Those unanswered customer emails are a process failure just like on the assembly line, and there’s no better way to improve those processes, and to sustain these improvements, than with BPM.

I realize that in some organizations, “phase” is a four-letter word. With BPM it is a must… it is the foundational element that leads to continuous process improvement and ultimately maximum business benefit. But don’t just take our word for it, just look at the countless customers who have used this methodology and achieve enormous success because of it.

Definition Phase

The definition phase is probably the most critical portion of the entire BPM adoption lifecycle. This is where you set the expectations for the BPM project, define metrics to measure the project and create a framework so that the focus remains on delivering business value throughout all three phases.

In this phase organizations should:

• Take the broader initiative and narrow it to a specific departmental level
• Define the business milestones and associated metrics
• Develop the business case
• Ensure that there is a common thread throughout the whole project (Business value)
• Get the business to drive this phase

BPM is disruptive, and it forces you to think differently, analyze your business differently, and work with IT in a new way. So this phase is CRUCIAL to set the tone. This also sets the stage for success as you move on to the next phase.

When you define the requirements, you should only include things that deliver tangible value to the business. If someone wants something, ask them what the business value is. If they can’t answer… well, then that requirement needs to be left for one of the improvement cycles.

John Doe’s requirement to be able to do something with two clicks instead of three is a valid request. But if it takes two weeks to build that feature or function, is it really delivering value to the business? Can it wait until one of the improvement cycles?

Deploy and Deliver Phase

Every organization is familiar with the stage where you actually start executing on the plan. In the past this was considered an IT-led portion of the process. That’s the wrong way to think about this. Participation from both IT and the business community is absolutely essential here. The goal is to deliver business value, which means that the moment you unplug the business from the project, you lose sight of the ultimate goals. IT departments may have a few people who are able to straddle that divide between them and the business, but it’s not the same as having both parties at the table.

Most organizations think that everything ends after the process is deployed and delivered. But this is their biggest mistake. You’re only two thirds of the way there when you deploy. The bottom line is that you’ll never get everything right on the first try, which is the weakness of the waterfall approach.

Hoover’s Inc. is my favorite example. They gave our methodology a shot and ended up changing their entire approach to ALL projects across the organization. They now use this iterative method as a discipline for ensuring success with almost any type of project in their organization.

Improvement Phase

In this phase the business community has to perform an analyst role. This might challenge a business person who has not viewed the organization in this way before. Ultimately the point of this phase is to analyze the metrics and goals that were set forth in the definition phase and see where you missed your goals and where you reached them.

Organizations used to avoid this phase because they didn’t realize the importance of the definition phase at the start and therefore didn’t know how to improve. You cannot get better if you don’t know your weakness. Even more importantly, you can’t know your weakness unless you have something to measure your performance against! That’s what the definition phase is for: to give you something to track against throughout each phase.

Traditionally the people who developed the initial business case disengaged or were re-deployed to other work… and therefore weren’t part of the ongoing project. The project is conducted with a waterfall mentality and the resulting solution typically falls short of reaching its measurement goals and a payback analysis can’t and won’t be achieved. The end result is an organization that is stilled optimized for feature and function, not for measurability and delivering business value.

This methodology and discipline has been used by organizations of every size. When you start talking about a business process improvement program, think about what we discussed here, and decide for yourself if a waterfall approach will actually deliver value to your business.

So far on this blog we’ve had a lot of important conversations around getting started — the first 180 days, putting your BPM team together, that first playback, etc. Today I want to focus a little bit more on the optimization piece of the puzzle. What do I mean by optimization? Imagine that you’re already effectively using BPMS and you’re doing pretty well all in all, but you’re not seeing the kinds of fireworks that you did when you got that first process up and running. The question is, essentially, what are some the of the advanced topics that that come to mind in terms of things that companies can do that really optimize and take process excellence to the next level? This will continue to be a theme for me in subsequent blog posts, but I’ll share some initial high level thoughts as well as a few best practices here.

I’ll begin with where I come in as part of our Services group. It often starts with a happy customer telling us that they are slowly starting to stall. That is, they got through those first multiple iterations, but now the question is — where do we go from here, how do we know whether we should add on another process or move to an area that is totally separate?

From an optimization perspective, we are going to go in and do a review and an assessment of what the customer has, what they are doing, and what kind of returns they are seeing. For example, is this process more customer-impacting, is it employee-impacting, and most importantly are we really understanding what the true value proposition is for each?  We decide how and where we want to focus, and determine whether we are doing a good job of tying into strategic objectives within the organization. Ultimately, optimization is all about alignment and realignment, that’s the first take-away.

I’ll use Sprint (my former employer) as an example. A big focus for Sprint is customer satisfaction. But when we started on a key initiative six years ago, when I did my first project using Lombardi Teamworks at Sprint, our goal was not so much about customers as much as it was about the financial impacts and our bottom-line. Over time, through rigorous optimization and continual refocusing, however, we gained major additional benefits on the customer satisfaction piece that proved to be very beneficial. This is what we want companies to start understanding, that they can exponentially grow the value proposition of BPM by evolving their process and/or refocusing processes in certain areas to accomplish adjacent goals. And again, as we align it all back to strategic objectives, the impact is able to spread much further – that’s the key.

Now, to take a step back – what often causes stalling in the first place?  99% of all organizations that I’ve worked with over the last twenty-plus years have broken processes, but the problems really start and end with change management and communication – usually it’s the bigger-picture stuff that is actually the problem.

When it comes to change management and communication, the philosophy that I have is that it is more about keeping it simple and having good representation, so that the people closest to the process are your experts. You need to make sure that you have visibility and buy-in with the upper levels of the organization, I can’t underscore this enough, but at the same time, you don’t need too many additional layers, which can slow the activities down and cause the kind of stalling that I’ve been talking about. After a first successful project, people get excited, and they want to learn, and they want to be exposed to what else is possible, and they want to have more people in the room because they think they can accomplish even more that way, but this isn’t always the case. Nonetheless, how do you toe the line between too much and too little?

One best practice comes to mind in particular in terms of how to maintain visibility and buy-in without subjecting yourself to scope and team creep.  I like to put an elevator speech together, and help a customer to craft a very simple layman’s term message that the team can start sharing with their peers and with other people within their work environment. This helps colleagues and managers and directors not only understand what their project is about and what it’s going to do for the organization, but also what is needed from that group for success, and truly what’s in it for them. This can be particularly helpful if there is a sponsorship change, because the project remains well-represented at many different levels, and you can pick up for the most part right where you left off.  An elevator pitch is typically thought of as something that a start-up CEO seeking venture capital might spend a lot of time crafting – but that entrepreneurial focus can really help spread the BPM message internally throughout an organization as well.  It’s a stake in the ground that forces everyone onto the same page, and provides a guide as to how to think about the project and what the end-game is, even though only a small fraction of those individuals will be in the next playback.

To summarize, stalling is most often caused by bigger-picture issues like change management and communication. Optimizing can fix the stalling, and optimization is all about going back to the drawing board and matching your strategic objectives back to the projects you have on the table and in the hopper. Proactively, you can guard against stalling by evangelizing the project itself, and in so doing make your goals and expectations clear. It sounds simple on paper, but as many of you reading this know, it’s an incredibly challenging thing to actually do.

I’ll be coming back to this topic too in future posts, so if there are certain things that you’d like to see addressed, please let us know in the comments.

The best description of “executive level buy-in” that I know of is only 7 letters long:

F-U-N-D-I-N-G

Maybe that doesn’t help you as much as you had hoped, so I’ll provide some additional color around this one.  Funding is the absolute bottom-line when we talk about executive buy-in to a BPM initiative.  But funding has to reflect the iterative approach, which means that the project isn’t over when the process is deployed.  The project is really just getting started.

Funding has to map back to the methodology required to do the project right.  It has to reflect all three phases of a proper BPM methodology.  We’ve discussed this methodology on Process People before, and if you haven’t seen some of those posts, I recommend that you read one first!

In reality, executive buy-in also means you have to have an executive who’s willing to get up on a podium and endorse the process improvement program organization-wide.  It means that the executive has to be willing to commit funding in every manner necessary – money, people, time and so on.

Your executive sponsor also has to commit to a fundamental rewiring of how the organization operates.  This is what I call “program-level” buy-in.  They’re not just agreeing to let you map some processes, automate a couple of steps and track for anyone who’s not doing their job – they have to commit to a DNA overhaul and commit to the iterative approach – Continuous Process Improvement!

I’m proud to say that 100% of Lombardi customers do phase 1.1 – and that’s because we are emphatic about this stuff from the start.  We absolutely insist that there is no other way to do BPM, and the approach has proven itself over and over again.

To get this buy-in, we recommend developing and presenting a rock-solid business case.  Sounds simple, right?  But it’s got to be done with passion and vigor.  You have to, first and foremost, explain that this is not an IT-centric proposition.  Your executives don’t live in the IT department – they manage a business.  Tell them how this will benefit the business; explain that this requires a new type of collaboration between the business community and the IT department, and tell them what they can expect in value returned to the business if they agree to the iterative methodology.  They need to hear that this program will deliver value for years to come.

Then hit them with the pragmatic benefits of a value-driven BPM rollout – efficient, effective and agile business processes that cut waste and drive revenue, or improve customer service, or better cross-departmental communication, or…

You get the point.

I’ve had a surprisingly difficult time conveying my own definition of “Iterative Development” in the past, so I thought I’d take a stab at explanation via analogy. Let’s compare your Business Process to a trip from Austin, Texas to El Paso, Texas.

The most important aspect of my trip is arriving at my destination.  No matter what interesting things may happen on the way, if I don’t end up in El Paso, my trip has failed.

The same is true about your Business Process.  No matter what else goes on, there is an objective to your process and you have to accomplish that objective.

The first iteration of your process, like the first iteration of my trip to El Paso, should implement just enough to get you through all the steps of the process.  No extraneous details, but enough to get you from the beginning to the end.  Start your iterations with the Flow aspects of your Process. What are all the places that you need to go?

Austin is a long way from El Paso – lot’s of lonely miles on the highway. Fortunately, we have family in San Angelo Texas, and it’s not too far out of the way to make a detour when we are headed out west: Based on how much time we have, the weather and road conditions, and how long it’s been since we’ve seen our family in San Angelo, we make a decision whether or not to take a little side trip.

Your Business Process, like my trip from Austin to El Paso, probably has multiple paths that it can take. There are Activities that are always performed, and there are Activities that are occasionally performed based on “current conditions” and other factors. Implement a place holder for each activity and capture the decisions that are necessary to pick the proper path.

At this point I need to take a step back and be a bit more explicit about what I’ve defined thus far regarding my journey from Austin to El Paso. I have done just enough to get to all of the places that I need to visit. I haven’t yet filled in any of the other details. I’ve got the directions on how to get there, but I haven’t worried about where to get gas, where to eat, etc.

You’ve defined the Flows through your Process, and you’ve implemented just enough stuff to get you through all the activities that make up the Process. You can now “run” the Process and step through each of the Activities, but the Activities don’t really do much – they just prompt the Participant’s for the minimal information necessary to get to the next step.

That’s your First Iteration: All of the “Happy Paths” through your process work. There’s not a huge amount of business value yet. . .but you do have a managed process in place. All of the steps of the process will get executed in the right order and the decisions at each step will be captured to guide the process along the correct path.

Your Process logic is now correct, so it’s time to start iterating through the Data aspects of your Process. You will need to know all of the information that is gathered during each Activity in the Process. You will need to know all of the information that is presented to the Participants during each Activity in the Process.

I hope that you see where I am going with all of this. . .Iterative Development of a Process must be done with respect to the Whole Process. Each Iteration delivers a more functional process. All of the Activities of the Process have to be functional, or you don’t have a working Process. Each Iteration should improve functionality across the whole process (in general).

Contrast Iterative Development (as I’ve defined it) with Incremental Development.

Incremental development focuses on fully implementing each of the Activities that make up the Process in some order. I see folks following this approach a lot when a particular Activity involves integration with an external system and the IT guys will always want to tackle that part of the Process first. I also see it when one Activity dominates the Process, such as preparing a very involved application. It’s our nature; we focus on the parts of the Process that we depend on. We focus on the parts of the Process that we are responsible for.

The Incremental approach is analogous to fully planning my trip from Austin to Junction, then fully planning my trip from Junction to Ozona, then fully planning my trip from Ozona to Fort Stockton, then fully planning my trip from Fort Stockton to El Paso. Nobody denies that we’ll (eventually) need to know all of those details, but by following that approach we won’t be able to make any sort of journey from Austin to El Paso until the last step of the journey is fully defined.

Incremental development is how Process oriented projects get bogged down. This is how Process oriented projects just drag on, and on, and on. Your development team ends up focusing on Activities of the Process, rather than on the Process itself, and you often end up with Activities that don’t make sense when the Process is finally finished.

Iterative development means building a process that works, then making it work better, then making it work better, then making it work better.  It’s an incredibly effective way to build your Managed Business Process, and there’s no reason for the cycle to end after the initial deployment. . .You just start calling the cycle Continuous Process Improvement.

Questions?  Leave us a comment below!

Today I want to address the folks out there who don’t feel comfortable showcasing their project because they don’t have the biggest ROI numbers yet.  Maybe it has only been in production for a couple of weeks.  What else can you focus on?

The Before and After

What did the process look like before the solution and how has it changed?  Were there lots of manual hand-offs, faxes and emails?  Did participants have to log onto four different systems just to review a work item? Was there inconsistency in the way people executed the process?  How much time did managers spend building and running reports before status meetings?  What does it look like now?

How Did You Get There?

So you implemented a process across a couple of different departments, integrated to some back-end systems, and managers have real-time status reporting.  How?  Tell them who was involved. One person that really knew the process (Jane), two analysts from the business (Sally and Bill), and one IT guy (Jim).  From design to roll-out it took 110 days and we had 4 scheduled playbacks with the business.

I think most people will agree that process improvement and BPM projects are iterative.  You can’t improve every process in an organization right at the start.  To wring the most value out of your process initiatives you have to focus on small wins first, so that other arms of the organization jump onto the BPM wagon.  That being said, it becomes clear why it’s so important to showcase your solution.  After you complete the initial phases of your project, other departments will want to see the results and understand how it works.  Share your knowledge to ignite BPM enthusiasm across the organization.

Questions? Comments?  Drop us a note below!

Process People: We frequently hear from Lombardi that BPM has everything to do with organizational culture.  Can you give us one concrete example that you commonly see which demonstrates this cultural shift?

Wesley Chung: Yes, it’s very much a cultural thing, and I would say that a big part of that is trusting the [BPMS] system.  Many organizations still rely on old-fashioned, manual status reports to track the success of a process because they don’t have any other way to know that people are getting their work done.  A traditional status report provides a way for them to monitor that.  Without a product like Teamworks, there’s no way to efficiently and effectively monitor that people are accomplishing their tasks in-line with the business process.  It’s how things have always been done.  Ultimately, they need to be willing to trust the tool if they want to change how they manage a process. The other major cultural challenge is that managers have to learn new concepts and completely alter their methodologies for managing processes.

Process People: So what is one example of a cultural difference between managing processes manually and managing them with a product like Teamworks?

Wesley Chung: The difference is really about managing exceptions.  An exception is an instance where a process was not followed in the normal case, where someone in the organization didn’t do what they were supposed to do and the process did not turn out as expected.  Once managers see that the process team can provide them with some automated reports and the managers realize that they can trust the system, then they can start thinking about managing the exceptions instead of managing the processes that were carried out properly.

What we’re asking people to do is to stop worrying about making sure EVERYONE is doing what they’re supposed to do, and to start focusing only on the instances where people didn’t do what they were supposed to do.  This means that a manager has to trust the BPMS, which is so different from the traditional method for reporting.  In the past, when sophisticated technology was not available, it was considered good practice to solicit manual status reports.  What happens in manual reports is you have to check in on every single instance of a process to find out which ones worked properly and which ones failed.  That takes a lot of time and resources, not leaving much time for thinking about improvement.  With Teamworks, you never have to look at the instances that worked properly, and your reports are automated – so your focus is going to be on process improvement with an eye towards reducing the frequency of exceptions. This requires a huge cultural shift, which means that the process owner needs to start thinking in terms of process and purely delivering business value – rather than touching every single instance of the process.

Process People: The more we talk about how big of an organizational and cultural shift this is, the more I wonder how feasible it is to get a BPM customer to truly change.  How do you improve the chances of getting an organization to change?

Wesley Chung: So that’s really the question.  I would say that the first part of this is that the customer, from a cultural standpoint, needs to be thinking of BPM as a very different way of doing things.  Not all of our customers fit perfectly into that category. For instance, some of them are project-based customers.  They have a project that they need to deliver, and they have chosen BPM as a technology that allows you to get that problem solved.  That’s great, and every customer goes through this at some point.  However, at the project-level, you are not necessarily thinking of how you transform the business or achieve a specific strategic effect.

Or, maybe they’re thinking about it in the long-term, but in a short-term it’s not really their goal to start creating a new environment of continuous process improvement.  So, you need to really commit to transforming the business before any progress can be made.

Once that commitment is made, we can really make some progress with playbacks, which are an incredibly important part of our delivery methodology.  Our playbacks, when they are done correctly, tend to be the most compelling way to get the people within an organization to change their culture, their DNA.

If showcasing your initial BPM deployment can help gain process adoption and ignite enthusiasm in other areas of the business, then you’ll get more and more value out of your overall BPM initiative. That being said, here is the first in a two part series of posts that will help you to showcase your BPM solution within your organization.

Get ‘em excited!

Everyone has had to sit in a presentation during their lunch break that seemed like a never-ending PowerPoint slide show. Now imagine watching someone explaining a process flow diagram that has no relevance to you. Then follow that with a “live” demonstration of someone clicking through a bunch of screens acting as a participant in the process that you didn’t get. Trust me, it can be very painful.

One tool that you can use to get people excited is to talk about the metrics of the process. You might not have the biggest numbers yet, but share some of the success that you had with the initial efforts. People have a hard time understanding and connecting the dots to a process they don’t understand. But if you tell them that over the last 30 days reducing the rework of a particular activity by 15 percent resulted in a reduction of average activity wait time and overall processing throughput, heads will nod. Not just because of the process improvement numbers, but also the overall insight into the process.  It sounds so simple, but it really makes a difference.

To really succeed with this, begin thinking about metrics as the project starts and assign someone on the team ownership to this aspect of the project. You might also want to consider the common benefits of a BPM project and try to develop metrics based on the typical value proposition of doing the project in the first place.

If you take only one thing away from this, you should remember that showcasing the project requires a concerted effort from day one.  Assign ownership of project metrics and begin assembling a plan for showcasing your solution from the get-go.  Don’t skip this when you’re launching your BPM initiative, it’s only going to help you.

Ed.: We’ll continue with Part 2 of this series soon.

Comments?  Leave us a note below!

In this second post (our initial coverage here) I’ll give a few practical, actionable advice and detailed recommendations around picking processes for the Pilot, staffing up, and executing in a way that will ensure success beyond this initial phase.

Picking processes

Above all else, you should be careful when choosing the Pilot processes, so that they have:

• Limited Cross-function/Cross-organization scope — this proves your ability to work across groups to define end to end processes, but don’t tackle more than a little. You want to minimize the “political” battles in these early Pilots.
• Limited Cross-system/data/information scope — this proves that you can integrate with existing infrastructure and handle complex information structures. Again, pick one or two of your key 4 systems and do one or two interfaces into them. What you want is learning. Oftentimes the integrations to systems are the “longest pole” in the deployment tent. Keep this to a minimum so that you focus on the new BPM issues, and don’t get bogged down in IT integration issues.
• Known business performance metrics — this will help focus your development efforts on driving measurable, demonstrable business benefits. It is imperative that specific and significant thought be given to how you want to manage the process, not simply how you want to execute the process.This will likely be the most wow-inspiring aspect of the implementation to the business.

Staffing the Pilot

You will need to put together two separate Pilot BPM project teams. Each team should be made of at least 3 full-time people. Their profiles are:

• An experienced BPM process leader. This person is probably provided by Lombardi or a certified partner.
• An IT person who is business-savvy. This person does not need to be a Java or C# developer, but needs to have familiarity with software development tasks and methods.
• A tech-savvy business person. This person is probably not a subject matter expert (SME), although familiarity with a given process can be a benefit.

Notes on Execution

The Pilot teams are often led by BPM vendor consultants or experienced system integration partners. Your company resources will typically be the executors, gaining valuable project experience while building their BPM knowledge.

But when it comes to execution, it is critical that key stakeholders throughout the organization are included in reviews, regardless of whether they are involved in the Pilot on a day-to-day basis. For example, these individuals should attend the Pilot “playbacks” that happen every two weeks. We cannot emphasize the importance of this enough.

Why?

Because on the execution front, close interaction with the Pilot teams is essential for the overall enterprise team It is the best way for them to validate their planning assumptions and incorporate key lessons learned from the Pilot teams. When the Pilot processes have been completed, a project summary can be prepared and presented to the BPM initiative sponsors or Governance body, if one has been formed.

Additional resources:

How to justify your BPM project

Getting started with BPM

When I started at Sprint (my former employer), I was among the people who just assumed that when you picked up the phone, there would always be a dial tone — to me this was no big deal. I didn’t really understand all the technology, all the incredible things in the background that happen to actually put phone service in your home. This was of course ten years ago, so cell phones were popular, but everybody still had a landline, and the company overall was still focused on the latter market.

One of the first things the company did was send me out to a call center. This was part of my “process discovery” phase in my new role (though we didn’t call it that) — my goal was to see and document how things actually worked, and then find ways for us to improve. First I got to key orders from customers for about a week, where we had to get all of their information over the phone. I was very precise with my orders, and I was well-trained by the people I was sitting with to make sure that, in this example, I provided instructions and physical directions for the technicians who would later make the site visits. Again, remember that we didn’t have iPhones and Google Maps! I included every last detail in the order, because when I sent that technician out I wanted to know that they were going to be able to do what we had committed to the customer, in the allotted period of time.

Then I flew down to Henderson, which is outside of Las Vegas and I rode with the technician that serviced the orders that I had keyed, so I would actually get to see the implementation of my work in the call center, on the delivery end of things. As I rode around with the technician, I listened to him grumble all morning about “Those service center people . . .why can’t they give us enough information! Most of this area isn’t developed, we don’t have good maps, all I need them to do is provide me with driving instructions and they just won’t do it.” And I was so puzzled because I had printed copies of all of my orders with me and on line 76 of every one of my orders there was a big remark that had all of the information as far as driving instructions went.

Now, the technician worked from a handheld unit — a small laptop-ish piece of equipment. It was supposed to give him a full download of my order. So I said, “What do you mean you don’t have driving directions? I keyed them in right here.” He looked at the paper order I was holding and he replied, “Well, no I don’t, I have the address, I don’t have this either, or this and this.” And I said “But you need to know that it is the third street down here past the light, on a street called Sun Circle, and after you turn left it’s the second house on the right with the brown siding. . .” And he looked at me like I was an alien. As you know, I was the one that keyed these orders, and once I told him that, the technician felt awful, thinking that he had offended me. I said to him that of course I wasn’t angry in the least, but that I needed to understand why he didn’t have what I keyed in.

Well, we kind of went off into our own little analysis and what we found out in the end was that their handheld units only allowed them to see the first sixty lines of information on the order — the 76^th line just didn’t show up at all. So as a service center rep, I was doing my best and every other service center rep up there was doing their best to provide every bit of detail that the customer was providing and yet the process was fundamentally broken and the technicians weren’t getting the information that they so desperately needed. As a result, the service center people thought the technicians were idiots that didn’t read what was in front of them. The technicians thought the service center people were idiots because they didn’t provide the proper information. Further, these two groups didn’t talk to each other, and they each were pointing fingers at each other, and so here I was as the neutral party, trying to patch things up! About four stops into our day’s work, we had found the real root cause of the problem. It was a technology issue. It wasn’t a people issue, and it wasn’t even a process issue.

I made a very simple call to the service center and I explained to the trainer and the manager up there what had happened. I said, “You know, you have an unused remarks field on line 16, so can you send out a broadcast and have all of your reps start putting their comments there instead of on line 76, so that our technicians can see that?” It was fixed immediately.

And so the technician was hearing all of this as I’m on the phone and we are going into lunch that day and all of the technicians typically gather at the same place. There were about twenty of them that had all congregated, and we sat down and my technician friend walks in like he was dragging the queen of Egypt with him, saying, “You will not believe what we just did!” All of technicians were suddenly empowered because they felt like they were part of solving a problem. And then everybody got so excited that they felt like they could tell me anything and right then and there we were going to solve world hunger.

Sound familiar?

Ultimately that day was all about the people behind the process, and opening the lines of communication between groups and thus being able to facilitate a simple discussion that could change everything. I really love that about process — I like knowing enough about the big picture, to ask stupid questions, and the discoveries that come as a result. I like empowering people to help make changes that profoundly affect their ability to do their job, and in doing so, affecting an overall cultural change where communication and collaboration carry the day. Frankly, it’s why I love my job, and it’s what gets me up in the morning.

On that note, I thought it might be timely to provide a quick recap of a session that Toby Cappello hosted on Wednesday. The session was called: “The Monday Morning Quarterback Discusses 10 Painful Lessons Learned.” Toby started things off with a golf analogy – one which he lived up to on the course yesterday!

The analogy went something like this: “BPM is like golf – you need to build muscle memory if you want to develop consistency and achieve success.”

In all honesty, I can’t really think of any other combinations of a technology (BPMS) and a discipline (BPM) that fits so perfectly with this analogy. It cuts to the core of Lombardi’s methodology. In fact, if you break it down even further you’ll see more uncanny parallels that help to visualize what exactly you’ll need to do to achieve success with BPM.

When we talk about starting with one small project first, it’s the same as starting off at the driving range. You have to walk before you run, and once you’ve seen some success on the range, you might take on another “project” over at the putting green. The obvious point here is that each skill that you need to learn in golf is much like the initial few BPM projects you roll out.

Eventually you move on to the sand trap, which you approach with a set of skills and capabilities for applying what you’ve learned elsewhere to improve your chances of success in the sand. Your method for learning different golf shots is analogous to the BPM methodology. You’re applying a set of strategies that help you add another shot to your repertoire. In BPM, you’re applying the methodology to deliver business value.

Don’t forget that all of your practice is building muscle memory for your swing. The same goes for BPM – as you apply the methodology in those early projects you are building muscle memory. Eventually, this muscle memory becomes the driving factor behind your success in BPM (and golf). Ultimately, that golf swing is so ingrained in your muscles that it becomes part of your DNA. You go on for years swinging in such a consistent manner that you are able to adapt to almost any lie, any new golf course (business change) and all the while you become a better golfer (business).

Toby also shared 10 common “lessons learned” that we wanted to share with you, so that you can refer back to them long after you get back to the realities of your every day jobs:

1. Remember metrics – think about them early – don’t undervalue reports
2. Don’t underestimate integrations and what it will take to do them
3. Phase is not a four letter word – “one and done” is not okay
4. Requirements documents are not process analysis – leverage process analysis skills early
5. A project longer than 90 days is not a failure – some processes are too complex for just 90 days
6. Java (.NET) developers are not ALL you need
7. Self-sufficiency requires dedication and commitment
8. Fund to Value – funding should reflect that the long term goal is to go from projects to programs to culture
9. Collaboration between business & IT is vital – playbacks, playbacks, playbacks
10. Ownership – Processes are business-owned

Sandy Kemsley also covered this session, and you can find her writeup here.

We had a great time at Driven 2008, and for those of you who couldn’t attend the conference we will be following up with session recaps here on Process People. Keep watching the blog for the next couple of weeks for recaps, pictures from the event, and as always, we welcome your thoughts in the comments section!

On first toeing the BPM waters, there is what we call the “Startup” phase. The goal for this phase is to demonstrate that your organization can adopt and benefit from BPM on a broad scale. Your Pilot project, hopefully, is a great success – and frankly, it usually is. Why? Because you have spent months laying the groundwork, aligning the team, building the business case and acquiring the technology. Your company – at least the part working on the Pilot — is aligned, dedicated, and singularly focused on a shared and common goal.

But now, with a single successful process under your belt – what comes next?

This is where the challenges begin from an overall enterprise perspective. Word of the Pilot spreads. And unless there is a clear plan for scaling to this new demand (and there usually isn’t), this is where it becomes difficult to replicate your initial successes. And as a result, the overall enterprise BPM initiative can stall before it gets off the ground.

To avoid this scenario, the Pilot program itself needs to be designed such that your initial success can be studied, perfected and replicated. The objective is to validate that the organization has the true capability to deploy BPM projects in the first place. Think of this as “proof” that the organization can succeed with BPM.

In order for that proof to be compelling, the Pilot should follow several key guidelines:

• We, in fact, recommend that you have two separate Pilots. This is the best way to demonstrate repeatability and maximize learning.

• Each Pilot needs to go from creation to deployment to end users of version 1.0 of their process. Typically, this will take 10-12 weeks.

• An iterative approach should be used for developing processes. This means full process “playbacks” or reviews every two weeks by process owners and team members.

• Each Pilot team should also deliver a version 1.1 of their process to production. This provides proof and learning to both the deployment teams and, just as important, to the business users using the process application. This gives the organization experience with the challenges of on-going process improvement – like responding to change requests and migrating in-flight processes to the newest version of the process. Typically, this will take five to six weeks. This also provides a key proof-point to the business: that process changes can be implemented quickly.

• Each team should include at least three full-time people from both the business and technical parts of your organization (see below).

• Enterprise architecture and/or Service Oriented Architecture (SOA) teams should be involved in the Pilots. Furthermore, the part of the organization that is responsible for application and/or infrastructure operations should be involved from the beginning, and called in on an as-needed basis. This will help them understand how BPM technology fits in their architecture.

Ed.: In Part Two of this post, we talk about picking processes for the Pilot, staffing up, and executing in a way that will ensure success beyond this initial phase.

Additional resources:

How to justify your BPM project

Getting started with BPM

Of course there is never a “finished” process. How often do you typically use a playback session to fine-tune a process that is up and running? How often do you do this, once a quarter? Twice a year? Can you give us a few examples?

We have a customer in Dallas that is unique because they have a very wide sales force who are all remote and need a number of approvals before they can close any business. We finished a project with them just a little over a year ago, and we’ve since done a number of other engagements on top of that original project, so the work is more or less constant. They’re a good example of fine-tuning and building on top of a first project.

The way that I always start off the new work with them is by having them do a playback for us to see where we are, and then have that segue into a talking session around what it is that they want to see or what new work they want to have done for them. So, we start with what we have already, instead of starting with what we ultimately want. This helps to create that delta between what they have today and what they’re looking for down the road. They’re a very active customer and good to work with for this reason – each new project flows naturally and organically from the ones that have preceded it. I’d recommend this way of working from one process to the next for everyone.

Another example is a large company in Austin that is very happy, but they are different in that they don’t do a lot of ongoing work. They’ve been running the process that we originally worked on, just like it is, with minimal tinkering going on. Every six months or so we get together as a group so that a.) they can understand as an organization what the process looks like today and what new tools are available to them; and b.) they can think about what forthcoming advances they might take advantage of in the future, given their ongoing business objectives (which might be evolving too). These are always very productive sessions and they help us stay in touch and prioritize the work that needs to be done, because for them, again, they are absolutely looking to take advantage of any potential improvements, but it’s not something that they need to be focused on even on a daily or weekly basis.

Let’s talk a little bit more about continuous process improvement (CPI) as it is a huge buzzword these days. As a best practice, CPI, coupled with very specific playback sessions, encourages flexibility, minimizes surprises, and generally helps focus the team on getting work done on a practical level. But, what do you do when the members of a group hit up against what Derek Miers has called “analysis paralysis” even despite their best intentions?

We try to level set as much as possible so that we focus in on a very tight scope so as to avoid that kind of paralysis. The saying “you don’t want to boil the ocean” when you start a process, I’m a huge believer in that. You need to get something done and get it done quickly, and then build on that afterwards. Start small and go from there – it all has to do with how much you bite off at first, as alluring as it is, as I said, to try and boil the ocean – ultimately that’s just a trap.

That being said, we understand that it can be extremely difficult to maintain this laser focus, especially given the many different interests involved in a given process. What we’ve learned is that it is crucial to find champions, whether those champions are in IT or business, that help us do just that – get work done on a practical level. This is something that is so important for anyone doing BPM, whether you’re an old hand or just starting out. It also matters, frankly, who you buy software from.

Here at Lombardi, when people buy this software they’re buying the methodology as well. And they’re buying into the people that work here – people they can rely on. It’s our job to help our clients deliver on their objectives without getting sidetracked along the way, to move them towards a state of true process excellence, and I’m really proud of what we continue to accomplish, day in and day out.

As a follow-up to that, let’s talk some more about playback sessions at different stages – can you do a little compare and contrast around effective playback at the requirement (discover/understand), design, build+test, stages, etc.?

The first playback for me is to be done as soon as possible. We like to get quickly to the core of what we’re doing. The goal is to lay out the work ahead.

The initial session is designed to validate a process flow. What we like to do at this stage is put screens in place as well. The screens are placeholders, what we’re showing is what a process is roughly going to look like at a given point in time. The screens aren’t very attractive, so you have to set expectations going in, i.e. that at this point it’s all about the data, not the look and feel.

But once we get past the first session, I run the next playback 4-6 weeks later to fine-tune that process flow, and to make sure that on the most basic level, we have the data in place. We may need to integrate data from an existing process as well.

During the third playback and before we get into some testing, we’re really focused on validating what we’ve done up to this point, that our work is correct and that our calculations and fields are on-target. Once we have the process flow and data correct, then we’re able to begin testing.

Overall, it depends on the overall project scope, but I like to do major playbacks every 4-6 weeks, then minor playbacks with the core group consistently within that 4-6 week window.

Ed.: This Q+A series on playback session best practices continues here. If you have any playback-specific questions that you’d like to have answered, either as a follow-up to the content discussed here, or just in general, leave us a note in the comments!

When you run a flow during a playback session, business people can jump right in and start suggesting additions, etc. How real-time are the changes that are made, and how often do you iterate feedback on a given flow?

It’s a difficult thing, actually, and it varies by playback. The highest priority for me is to capture any and all feedback accurately, anything that anybody blurts out or cites in the playback.

Then I like to, for anything that is able to be fixed immediately, go in and change it right then and there. First, this puts the business perspective’s mind to rest to have it displayed for them, right there in real-time. And second, we don’t have to worry about that specific piece of feedback after the fact as a lingering action item.

But the trick to it is that you don’t want the real-time revisions to turn into a long discussion of what we should and should not do. If someone’s requirement is very clear, then we’ll do it immediately in the playback, but otherwise we’ll take it offline and come back to it later – you don’t want to hi-jack the entire session if there isn’t consensus or at least a clear directive in terms of what needs to be changed.

Speaking of tasks outside of the session, how long typically do you work in between playback sessions?

As far as the loop, and how quickly we’re iterating on that, again it depends.

I like to iterate smaller changes within the small core team within a matter of a single day. We’ll loop back with the core project team and say “this is what we’ve heard, let’s recap it and figure out these changes,” and really get cracking right away.

If they’re bigger changes it will take more time of course, but the smaller changes happen very quickly. Sometimes we will take a week or 2 weeks in between sessions, but we like to get the feedback from those sessions published and out as soon as possible.

As a follow-up, how can you encourage participants to focus on practical problems associated with the business domain? And how do you keep scope creep in check?

We run into this all the time. Most important: setting expectations upfront. I’m a huge believer in setting expectations as I’ve said before, and I’m adamant about it.

I tell everyone in written form beforehand what to expect, and I reiterate those expectations when I send the calendar invite, and I reiterate it again when we begin the session itself.

I try to put it in the hands of the client as much as possible, but I’ll always level set and say “this is what you’re going to see today, this is what you’re not going to see today”. I tighten up the scope to make sure we’re all on the same page because the worst thing you can have is scope creep and scope discussion in that kind of a forum where you want it very tight and focused to show how you have progressed.

Ed.: This Q+A series on playback session best practices will continue later this week. If you have any playback-specific questions that you’d like to have answered, either as a follow-up to the content discussed here, or just in general, leave us a note in the comments!

From the Process Developer’s point of view, the “right” answer to solve a complex routing problem like this is to develop a custom Task Routing Service to determine the list of users who should be given the opportunity to complete the task. If the conditions for eligibility are very dynamic (if they could change in a few minutes) then it’s also a good idea to develop a related service that will tell you if a specific user is eligible to claim a specific task.

When a task is ready to be performed, invoke the first service to get all of the eligible users.

When a user claims the task, call the second service to determine if they are (still) eligible, and return the task to the pool if they aren’t.

Encapsulating the Task Routing Policy (the logic to determine the eligible users) in a separate service frees us from having to worry about the details of determining those users while working on the other aspects of the managed process. Our custom Task Routing services can implement any routing policy that is necessary.

Refining the Task Routing policies is often one of the areas with the most potential for improving the overall performance of a process. If tasks are languishing on a queue, waiting for someone to claim them, then nobody is happy. If “simple” instances of tasks are routed to the “most skilled” participants, that’s probably not the best use of resources (and once again nobody is happy).

The Task Routing Service that I’ve described for this loan origination process requires access to information from several sources:

• Information from the current process instance
• Information about all of the possible participants
• Cumulative information from “related” process instances

Getting information about the current process instance is never a problem. Since the Task Routing Service is called from within the process itself, any relevant information can be supplied.

In this specific process implementation, the possible participants (the Client Officers) are defined in a database table… There is not a group in LDAP that distinguished the possible participants. The same table holds attributes of the Client Officers that are needed, such as “Lending Authority”.

Cumulative information from related process instances is often the hardest to come by. This is generally the information that is used to load-balance the workload of each participant, and the total workload of any participant may be dependent on many types of processes (not all of which may be managed). Frequently, when a project has begun to implement a managed business process, some of the information necessary to implement a complex Task Routing Policy will not be available (and may not become available before the first release of the project).

So what do you do if the information that you need for your Task Routing Policy isn’t available?

Do the best that you can with what you have.

The first release of the Task Routing Service for the Loan Origination Process that I have described will be implemented as a Human Powered Service. Prior to this BPM project the task routing was performed by a person. When new Loan Applications were received a central “Traffic Cop” would review each application and assign it to a specific Credit Officer. This manual assignment process was actually working quite well since the number of Credit Officers was small and the “Traffic Cop” was really good at the job. Although the ultimate goal is to automate the task, we are “punting” and will create a UI for a human to make the routing decision in our Task Routing Service.

Here’s another key reminder: Don’t spend a lot of time and effort (and money) implementing a complex Task Routing Policy unless it really is needed. Back to my example, the human “Traffic Cop” routing service really may be the right solution for the present. Until the “Traffic Cop” is overwhelmed by volume, replacement of this routing service with an automated one might not provide a reasonable ROI.

Task Routing in a managed business process is often very simple and easy to implement with the out-of-the-box functionality of a BPM suite. For those times when it’s a bit more complex (or maybe even insanely complex) don’t despair. With a well-designed Task Routing Service you can handle almost anything.

Questions? Leave us a comment below!

People like to talk a lot about collaboration between business and IT, but it seems like a playback session, as a collaborative, iterative process baked into the development environment, is where the wheel finally hits the road.

When you start any engagement, any project work, the existing tendency is for business and IT to split off fairly early, but I try to keep them in lock step as much as possible, which is important in order to be successful ultimately.

That first playback session is the first formalized opportunity to get everyone back in the same room and on the same page. We try to immediately do a level-set, making sure that everyone has the right expectations coming in, and a clear understanding what is going to be covered. We ensure that there is an agenda of what is going to be accomplished, both from a business and an IT perspective, and that both sides also know their roles and the various responsibilities for the playback.

Then once the playback starts, I’m really big on having an ongoing ad dynamic back-and-forth between business and IT, and typically at first it is driven by IT because they’ve been more hands-on to date in the first parts of the project. There are also instances, though, where the business side is driving because you’re doing more process flow at the first part of the first playback, which is important to note.

Ideally, it’s a combination of both, starting in that first session. The important thing is that in so doing, we carve out specific and concrete roles for both business and IT with any playback that we do, and especially on the first one, so that the interaction is defined and expectations are clear.

What are some of the things you have noticed as being especially challenging when that dialogue first begins? What have been some of the most surprising moments?

When it comes to best practices that we’ve learned since I started doing these sessions about 2 years ago, one big learning for the first session certainly has to do with executive-level buy-in. One client example I can use is from a bank based in Chicago. They are using Teamworks to regulate fraud-related processes. For example, if someone steals your ATM card, and you call in to report it – it’s Teamworks that picks this up and manages this process. They also have multiple instances of Lombardi running for them in multiple locations, adding to the complexity.

This particular client has been great to work with, but their IT project maturity was relatively undeveloped at the time that we started with them, though they have been very eager to learn what we’ve been sharing. We were taking more of a lead with this particular customer than we might with others with more experience under their belts already. Going in, we did everything right up to that point, did it totally by the book, and we were pretty happy with the way things were going.

But when we did the first playback, there were several big surprises from the business perspective. Basically, the executives were planning on seeing some things that they didn’t ultimately see. We had to take a step back and say “what did we miss here, and why did we miss?” After talking with the stakeholders, we found that they had very different expectations around the UI and that some of the process steps were out of order, or not entirely correct.

Ultimately, we were attracting all the right levels of input within business and IT, but with one notable exception — we didn’t have the executive buy-in that we needed. We had wrongly assumed that the right expectations had been naturally channeling upwards, but this was not the case. As surprising as it was for a group that had already been working together very closely, we were totally caught off guard by some of the feedback that we got from the executive perspective. Going in, we assumed that the executive level was very “hands-off”, but in reality they were very interested (a good thing) in what we were doing and had a much deeper level of process knowledge than we had originally thought (also good). But we weren’t as prepared as we could have been.

The solution? Between playback 1 and playback 2, we decided to do a playback 1.5. This allowed us to make some quick changes before we got to the next stage. It was a proactive mechanism more than anything else to make sure that we had everyone properly bought into the process. And as a result, before we did anything in playback 2, we were confident that we had that executive-level buy-in, because we had built that into our own process. Rather than assuming that our project had visibility and would naturally bubble up to the appropriate levels, we had to formally build in a way of getting that all-important buy-in explicitly.

The lesson learned here was that we had very mature and process-experienced clients and a really IT savvy staff, but we didn’t have what we needed in terms of proper executive-level playback criteria for what they were seeing in the session. We were able to bounce back quite quickly with an intermediary session. We also learned that we shouldn’t take anything for granted, and in terms of the level of involvement and the overall approach, it is best to emphasize our best practices re: criteria and buy-in much as possible. There is always the risk of a disconnect, but we learned to make our recommendations as strongly as possible to avoid issues like this in the future.

Ed.: This Q+A series on playback session best practices will continue over the next few weeks. If you have any playback-specific questions that you’d like to have answered, either as a follow-up to the content discussed here, or just in general, leave us a note in the comments!

All BPM suites have one form of task list or another that holds all of the tasks that are assigned to a user and all of the unassigned tasks that the user can claim. Sometimes the task list appears on some sort of a Portal. Sometimes the task list is integrated with a mail client like Microsoft Outlook. Often task notifications are emailed to users. Task Routing in a process is all about getting the right tasks to show up on the right user’s task list at the right time.

A BPMN swim lane indicates the Role (in the process) of the Participants who execute any of the Tasks in the lane. These BPMN Roles can be very specific, both at the process definition level and at the process instance level. For example, an individual who is acting as a Reviewer in one instance of a process may be acting as a Requestor in another instance of the same process.

In many processes, a single task may be routed to a group of people rather than assigned to a single user. Let’s refer to this group of users as the Task Group. All of the Task Group members are eligible to claim the task until one member of the group claims the task.

If you’ve dealt with Authorizing a User in a “normal” application, then Assigning a Task in a process will seem very familiar. When people log on to web-based applications there is almost always a two step process occurring under the covers: Authentication and Authorization.

Authentication is conceptually simple: Is the user who they say they are? This is usually handled by prompting for a user id and a password. If the two match, then the user is someone who can log on to the system. In Single Sign On environments, authentication is generally handled by a token (such as a SAML assertion ) that vouches for the user’s identity.

Authorizing a User is often a bit more involved than Authenticating a User: Is the user allowed to perform a specific task or view some specific information?

Authorization is less straight-forward than Authentication because a single application may be written to service users with significantly different permissions to perform tasks and to view information. If the logged on user has specific permissions, then they can perform specific features and view specific information. Conversely, if they don’t possess the proper permissions, then they cannot access some of the application’s features or view some of the information.

The relationship between Task Assignment and User Authorization is pretty obvious:

Authorization logic is applied to determine whether or not the logged on user can perform a task or view some information.

Task Assignment logic is applied to determine the group of users who are authorized to perform a task or view some information.

Many organizations use an LDAP repository like Active Directory to hold the Authorization information associated with users. In this model, users are assigned to specific groups and Authorization is fairly straight-forward. Assigning a BPMN swim-lane to users who are members of a specific LDAP group is a no-brainer.

Unfortunately, in the real world the membership of a Task Group can be very dynamic. Here is an example slightly modified from the loan origination process that I worked on:

The Task should be assigned to all Credit Officers with a Lending Authority Limit of more than $50,000 who have processed less than 5 applications this week.

At first glance, it seems reasonable to create an LDAP group for Credit Officers with Lending Authority over $50,000 — but it’s really not. The required Lending Authority Limit is actually based on the amount of the loan. You need a Credit Officer with authority greater than the amount of the loan, so this is really an attribute of the Credit Officer rather than a specific group that they belong to. The second half of this requirement, “who have processes less than 5 applications this week”, is an extremely dynamic categorization… There’s no way that you would store this sort of dynamically changing data in an LDAP repository.

To a Business Process Analyst, specifying a Task Routing rules like these are very straight-forward. To the Business Analyst, it’s extremely clear who should be eligible to claim the task, and who shouldn’t be able to claim the task.

To a Business Process Developer, trying to implement a Task Routing rule like this is a nightmare. It’s usually very unclear how to access the data necessary to implement this rule.

Ed.: Next week, in the final installment of this series, John will explain the “right” answer to solve a complex routing problem like — developing a custom Task Routing Service.

Questions? Let us know below in the comments!

As with any real-world process, there were a few interesting “gotchas”, but on the whole it was a pretty standard process that many of you would easily recognize.

In this case, modeling the Loan Origination Process using BPMN diagrams was fairly straight-forward, but when we got to the point of implementing Task Assignment and Routing things got interesting. Let me very loosely paraphrase some roughly similar Task Routing requirements (that I made up for this blog entry):

“When a Loan Application comes in, make the application available to all of our Credit Officers who have sufficient Lending Authority to process the loan, and who haven’t already met their quota of applications for the week. Of course if everybody has already met their quotas for the week, then let everyone have an opportunity to work on the new application.

One more thing, only a few of our Credit Officers can approve loans over $100,000, so don’t route low value loans to them unless they are the only available credit officers.

And don’t let anyone claim more than 3 applications at a time. Our Credit Officers are compensated for the number of loans that they process, and some of them will claim all the applications that they can in hopes of earning more money.”

These Task Assignment/Routing requirements are kind of involved, but they make sense in the real-world. If you can’t handle real-world problems in your managed business process then you aren’t going to make many business people happy. So how do you satisfy complex Task Routing/Assignment requirements like this?

There are three key elements to any business process:

1. The steps and flow of the process
2. The data the process generates and consumes
3. The participants who perform the process

Task Routing itself deals with the Process Participants: How do you know who the right participants are and how do you assign tasks and route information to them?

Ed.: Next, I’ll talk about more about Task Routing, and getting the right tasks to show up on the right user’s task list at the right time.

Questions? Leave us a comment below!

But I think the really interesting thing here is that people can use this article to help evangelize the value that BPM can offer their companies in terms that business people can actually understand: efficiency, effectiveness and agility.

While BPM has been covered for some time in IT-oriented publications that dive deeper into the technology, this story is fairly unique in that it talks at a business-level about some of the biggest issues companies face with getting success with BPM. It provides examples of successful approaches that other companies took to solve meaningful problems while connecting with the business – and it comes from mainstream business press source – not an IT journal.

What it doesn’t do (too much at least) is get bogged down by technical points that make business people’s heads spin. And that is the problem with a lot of the press attention that BPM has received in the past. Many articles either get totally side-tracked with technical ‘in the weeds’ points or only discuss the broad market trends.

So the point I am making is that if you need help making the case for BPM with your executives, or if you need concrete examples of the benefits companies are acheiving, have them read the FT article – it should really help. And they probably won’t even make that funny face when they read it (you all know what I mean). Let me know how it goes!

Honestly, this is no surprise. The big software vendors – I call them Stackers – have been and continue to pursue the promise of BPM half-heartedly. Actually, they have done everything in their power to bury BPM deep in what they view as their real markets. You can’t blame them – BPM ain’t in their DNA. And it is really hard to change your DNA.

SAP wants you to buy applications from them. BPM to them is just some integration and workflow between their applications. Always has and always will be – no matter what the Netweaver BPM roadmap says. Not to get too cheeky, but SAP does not have the best reputation in this sense – see their public spat with Waste Management about non-delivery of promised functionality.

Oracle is really no different. OK, they are a little different. They have a BPM product that is buried in a portal product that is bundled with an app server from BEA. And that BPM product (formerly called Fuego) is sure to die a near-term death to serve the greater good of Fusion. What is the Fusion vision? Wait for it. . .simplify integration and workflow between Oracle applications. I am not alone in questioning the Oracle BPM strategy.

Which brings us to IBM. No, they don’t just sell applications. They want you to buy their SOA stack and pay them to integrate their products so they can build you an application. BPM? Just another part of the SOA stack. Actually, it is about 11 different parts of the SOA stack. More if you count Filenet. Which do you need to meet your BPM needs? It will take 20 people from 10 groups at IBM to tell you – and you can bet you will need about 20 different IBM products to make it all work. This mess despite the fact that leading industry analysts have been promoting IBM as only 18 months away from having a viable BPM offering .. since 2004.

OK, so I am cranky with the Stackers. After all these years, they are finally getting the BPM pitch down. It is all about Agility. Business Agility. Change processes without changing code. Respond rapidly to changes in business. This is a new paradigm of collaboration between business and IT. Continuous process improvement. Every website from every company that provides BPM – including us – promotes these benefits and opportunities.

If you are sitting in an Oracle, IBM or SAP shop, you might just think that you can use the BPM tools from your Stacker. You can’t. You probably can’t even get them installed – without some serious effort. Or time-travel if you are an SAP shop.

Seriously, please stop and run your Stacker’s BPM offering through the following 5 tests:

1. How easily can you identify which of the vendor’s product(s) you need for your project?\
2. How hard is it to install the product?
3. How efficiently can you create and deploy a complete process?
4. How complex is it to change a process?
5. How easy is it to find and fix process inefficiencies?

You will find complexity, lack of integration, high learning curve. All the things that will kill your BPM initiative. To contrast that with us, just click here for a preview of how we score on the tests. This provides a specific IBM example – but it will work for any of your Stackers. Or just ask a few of our customers how they’re doing. When you walk into a playback, is there love in the air?

It’s crucial to get these groups aligned from the very outset of a project, to get them walking lock-step with each other as soon as possible. This is Rule #2.

But how is this accomplished through the UI?

The most important thing we’ve learned about aligning cross-functional interests from a UI perspective has to do with the early discovery and documentation phases of the project. This is the first (and potentially only) opportunity to get everyone’s interests on the same page, and is exactly why we created Lombardi Blueprint.

Here, you shouldn’t build out too much interface – it’s important to allow for learning and adapting to take place. Our overall goal with Blueprint was to speed understanding of BPM for business users on a fundamental level. It was important for us not to be too rigid, or to flood users with too much information too soon. The value of the work that was being done needed to be self-evident.

We also believe in building “just enough” user interface as needed in order to manipulate the data and step through all the necessary paths. We use this as a way of ensuring against errors in the modeling that you end up getting locked into. Simplicity is key… adding more features can get you into trouble.

For this reason the modeling environment in Blueprint is focused on enabling people to get started more quickly (as opposed to getting lost in the larger trajectory of the project, and/or succumbing to scope creep). If you need more information, it is there – but it isn’t presented to the user unless it is necessary (i.e. we use progressive disclosure techniques in the product so we don’t throw all the advanced functionality out there in the beginning). At all times we are striving to design interfaces that allow a new user to get started meaningfully no longer than 10 minutes after being dropped into our product.

Overall, we keep it simple and remain flexible and focused on features that help get users to that next version faster. At Lombardi, continuous process improvement means that the UI is all about getting you to that next step, focusing on the rapid iteration and agility. This, coupled with a deep understanding of the needs of technical and non-technical users alike, gets cross-functional teams on the same page early, and gives you the very best chance for ongoing success.

Questions? Feedback? Let us know in the comments section below.

That being said, I think that user interfaces are key to how these cross-functional teams can work together effectively. This is something that I touched on briefly in my previous post about Web2.0 and “making BPM cool again.”

First let’s provide some context — traditionally, in the BPM world, UI development occurs in the design phase of a process, building on top of what has been accomplished with the flow, integration metrics and controls stages, etc.

But one of the things that I like about Lombardi is how we are structured. Our design group is part of our product management organization, and we work closely with the product manager and our clients from the very beginning, which is untraditional. We’re really the first consumers of any information.

More specifically, we work closely with the product team to make sure we understand what the goals/tasks of the users are, from the start. We use personas here – for example we have businesspeople and IT technical developers and architects that we refer back to, always thinking about what each person wants and needs from a UI perspective. We also do site visits, spend lots time with our customers, doing plenty of onsite testing, customer calls with sales people to demo the product and more. We want to understand what our clients are thinking. We try to get an idea of what is going on at every stage, which helps inform our design decisions. We get as deep and engrained as we possibly can, and it’s worth every bit.

That is, in order to effectively utilize a cross-functional team, you first have to first understand on the most granular level what the needs of each constituency are, at each stage of the process. This might sound obvious, but it isn’t so simple in practice. You can’t fake the knowledge that you need – you have to go out and get it, aggressively if need be. I can’t say enough how much research and user studies are an integral part of how we think about interfaces.

Quickly you’ll realize that in that hand-off between the two organizations, there is a lot of stuff that an IT role might, for example, want to hold onto because it involves what they do well, and there’s a bunch of stuff that IT needs to hand off to a business role on the team, but typically can’t because the UI doesn’t support it. A good UI allows each user to focus on what s/he does best, and this is Rule #1. Trying to find the right way to solve this problem is what keeps us going from a design perspective, and is why we start work at such an early stage. And if you’re evaluating UI’s from a purchasing perspective, for any software category really, it is imperative that a given solution do just that – allow users to focus on doing what they do best and not get in the way.

Now, given a deep understanding of the needs the cross-functional team (and roles), what comes next?

Ed: We’ll continue this post later with Part 2, in which Craig talks about how to get IT and business on the same page by making careful decisions about the interface(s) through which these two groups interact.

Questions? Leave a comment!