For their recent InformationWeek Analytics 2008 Tomorrow’s CIO Survey, the well-known trade publication quizzed 720 corporate managers, including CEOs, CFOs, and COOs, as well as CIOs and VPs of IT-level executives, about the attributes most desirable for future business technology leaders.

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.

Read the rest of this entry »

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?

Read the rest of this entry »

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.

Read the rest of this entry »

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…

Read the rest of this entry »

If you’ve been reading the Process People blog, you might have noticed that we talk a lot about an iterative approach to deploying BPM. What we haven’t touched on as much is that the iterative approach is an element of the overarching methodology. Looking in on the methodology from the highest level you will get a view of a three-phased approach – which ultimately results in iteration. But we want to provide a big picture of how all of the different parts of our methodology tie together, and how each point of emphasis leads into or loops back to key areas of the other two phases.

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

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

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.

Read the rest of this entry »

In a previous post I said that it should go without saying that you have to showcase your initial BPM project if you want to drive adoption across the entire organization.  I focused on metrics.  Although other areas of the business might not understand the functional process implemented, they will find interest in how you are measuring the process for improvement.  This can correlate to other areas of the business as well.

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?

Read the rest of this entry »

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.

Read the rest of this entry »

Showcasing the success of your initial BPM project is often times requested from other departments, but it’s also required to help drive adoption across the entire organization.

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.

Read the rest of this entry »

Ed.: While a complete enterprise BPM roll-out is a multi-year effort, this two-part series focuses on the Pilot as the crucial first step in an enterprise initiative designed to spread throughout the organization.

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.

Read the rest of this entry »

This post is all about the cultural changes that BPM can (and needs to) drive within an organization. But it’s also about some of the ways in which processes don’t live in the clouds — they live on the ground, in real situations, with real people. I think it’s really important to remember this fact in our day-to-day work. I like telling this story because it’s from a long time ago when technology was quite different — and yet there are stark similarities to the challenges that we face today.

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.

Read the rest of this entry »

Driven 2008 has come to a close, and we’re really thrilled with this year’s event. Many of the conference attendees stayed for the Lombardi golf tournament yesterday, which took place on the beautiful Fazio Canyons golf course at Barton Creek Resort and Spa. The weather was perfect and the golf was great.

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.

Read the rest of this entry »

While a complete enterprise BPM roll-out is a multi-year effort, this two-part series focuses on the Pilot as the crucial first step in an enterprise initiative designed to spread throughout the organization.

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?

Read the rest of this entry »

Ed.: This is the third 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 and here.

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.

Read the rest of this entry »

Ed.: This is the second 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 on the first playback session here.

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.

Read the rest of this entry »

Last week I talked about how you know who the right participants are with regards to a particularly complex Task Assignment and Routing implementation. I also talked about how you assign tasks and route information to them. But I finished by explaining why to a Business Process Developer, trying to implement a Task Routing rule, such as the example I gave, is a nightmare because of a lack of clarity around how to access the data necessary to implement the rule.

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.

Read the rest of this entry »

Ed.: This is the first in a series of Q+A sessions focusing specifically on playback session best practices, with our in-house expert, Kris Komassa.

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.

Read the rest of this entry »

Last week, I outlined a loan origination process with a particularly complex Task Assignment and Routing implementation. Since Task Routing itself deals with the Process Participants, I left off with the question, How do you know who the right participants are and how do you assign tasks and route information to them?

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.

Read the rest of this entry »

Recently, I was working with a client to implement a managed Loan Origination Process using Lombardi’s Teamworks BPM suite.

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):

Read the rest of this entry »

Last week, the BPM industry - and two Lombardi customers - gained some very nice attention in the Financial Times. Steven S. Smith, CTO of Wells Fargo Financial, talked about how he achieved adoption from the business side of the company. Another, James Thomas, IT Director at University College London Hospitals (UCLH), discussed how they are using Lombardi Teamworks to reduce the time it takes for a patient to receive medical treatment after a referral. Impressive stuff.

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!

Its been a week since SAP’s big BPM announcement. Not exactly an earth-shattering announcement. My summary - at some point in the future (2 years?), SAP-only shops will be able to more easily configure internal SAP application workflows. This is a SAP application workflow band-aid, not a viable BPM offering. I am not alone in this assessment - the reviews have ranged from unimpressed to downright negative.

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.

Read the rest of this entry »

Last week, I wrote about the importance of understanding user roles and how a successful UI allows each user to focus on what s/he does best, especially with regards cross-functional process teams (Rule #1).

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.

Read the rest of this entry »

It is tempting to go on and on about the relationship between business and IT. Here at Lombardi we like to instead talk about effective cross-functional teams that can build the end-to-end process together. And we practice what we preach - this is why we have BPM Analysts, Consultants and Developers on our delivery teams. Note this does not mean companies have to fundamentally re-organize, but they do need to be able to create dedicated cross-functional teams if they are going to be successful.

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.”

Read the rest of this entry »