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 »

Ed.: In this second post in the series (see our previous coverage here), Fahad is focusing specifically on the Enterprise Plan Program. Think of this as the plan for rolling out a BPM initiative across the company in the first 180 days and beyond.

Enterprise BPM initiatives require well-defined operating procedures for selecting projects, governing delivery, staffing teams and managing infrastructure requirements. We call these procedures the Four Pillars of Enterprise BPM. The Enterprise Plan is therefore comprised of 4 corresponding sub-plans, including the:

• Strategy Plan
• Governance Plan
• Capability Plan
• Infrastructure Plan

Read the rest of this entry »

The Spring ‘08 release of Blueprint is now live & kickin’. You might think Blueprint is a cool process modeler, but there’s much more to it. There is no better BPM governance tool on the market.

Governance? What the heck is that?

Isn’t this just another buzzword? And how does something like Blueprint help with governance?

The term “governance” is often used but little understood. And yet if we think about our customers’ successful BPM projects, they always succeed because of tangible leadership from somewhere in the business. A BPM project is not application development, it is a different type of technology-based project. One that is not aligned with the business, but instead one that is integrated into the business. The foundation for business integration isn’t a shared model, it’s a shared understanding.

Read the rest of this entry »

In this series of two posts, we’ll lay out the development of what we call the Enterprise Plan Program. Think of this as the plan for rolling out a BPM initiative across the company in the first 180 days and beyond.

The objective of the Program is to develop the plan for how the enterprise BPM program needs to be rolled out and managed past the “startup” (or Pilot) phase. This includes a consideration of strategy, governance, organizational capability and infrastructure impact. In many cases, the team driving this deliverable must also answer how the enterprise BPM initiative fits with other business and technical initiatives that may already be in progress.

Read the rest of this entry »