Big Data, Big Headaches

Recently I talked about BPM's ability to pull together data from a variety of sources, including those big-dollar software suites with the famous acronyms: CRM, ERP, HRIS, and so forth. As exciting as it is that BPM can tie these systems into everyday business processes, the thought does beg the question: does this mean we have to buy another big-ticket software suite?
No. At least, not usually.

The truth is, it depends on the type of business you're in, and the type of problem you're trying to solve. You can certainly find seven-figure BPM solutions in the marketplace, and a few large enterprises may well need them. High-end BPM suites are often tied to other expensive products by the same vendor, such as complex event processing (CEP) systems. If your enterprise needs those specialized solutions, and requires the high level of integration promised by the vendors that package them with equally expensive BPM products, then get ready to sign a big PO.

In virtually all other organizations, though (and even at the departmental or divisional level within those large enterprises), it makes sense to choose a more modest BPM solution. Large BPM products, like those other big software suites, are usually deployed top-down through the organization. Because they are meant to tackle highly visible, strategic processes, it will sometimes be the case that divisional, departmental, or routine processes are starved for attention. Right-sized BPM solutions can be deployed tactically, at little expense, to address those challenges efficiently.

Indeed, I am familiar with more than one customer whose enterprise has designated an "official" strategic BPM solution, but whose department is facing significant challenges that cannot be addressed in a timely fashion by that system. So, the customer selects and deploys a tactical BPM product, one that flies under the budget radar and is configured and deployed using a minimum of corporate resources. As a result, the department is able to meet its goals, efficiently and flexibly, without sparking conflict at the enterprise level. Isn't that what BPM is all about?

BPM in the PMO

Traditionally, a fine line has divided process from project in the enterprise. The Project (or Portfolio) Management Office (PMO) is responsible for oversight of projects—however that is defined within that organization—while process governance is often distributed throughout the organization, perhaps with some input from a process improvement team.  The process improvement group is usually organized around a set of principles, often Six Sigma or Operational Excellence, while the PMO is operated according to its own guidelines, such as a project life cycle or systems development life cycle (I'll refer to these, collectively, as SDLC). Finally, the PMO is generally responsible for efforts that cost money, while the process improvement folks have a clear mandate to identify savings.

At BP Logix, we feel that process and project have been separated for too long. The SDLC after all, is itself a process, requiring planning, oversight, and documentation, and subject to review, audit, and regulatory examination, just like any other process. Furthermore, the SDLC is one of the most important processes in the enterprise, often involving tremendous expenditures of money and resources. Other enterprise processes have benefited from leveraging BPM solutions: could the SDLC benefit as well?

In upcoming posts, I will talk about the challenges and benefits of using BPM, and specifically, BP Logix Process Director, to automate the SDLC even as it makes the work of the PMO easier and more transparent. In the meantime, if this topic interests you, be sure to participate in our webinar on Tuesday, February 8, at 1pm. Click here for more information, or just drop a note to info@bplogix.com. The webinar will feature well-known BPM expert and Forrester analyst Clay Richardson.

What do you think about BPM in the PMO? Are they doomed to forever be separate? How will one or the other have to change for them to come together? Leave your comments beow.

Both Sides of the BPM Coin

My career has taken me a lot of places over the past two-and-a-half decades. As a technologist, I spent a lot of time creating purpose-built solutions for a variety of business needs. As a manager, I faced the challenge of supporting those solutions, sometimes long after the individual who created them had gone elsewhere. And as a CIO, I saw how the accumulation of off-the-shelf point products and custom-built software solutions can create an ungovernable, change-resistant headache for an organization trying to stay nimble in a tough competitive environment.

On and off throughout these years, I have also worked for some pretty terrific vendors. In those roles, I saw the other side of the coin: customers unwilling or unable to abandon costly legacy products, convinced their careers are tied to a specific way of doing things, and suspicious of "not invented here" solutions.

All of these experiences led me to the BPM industry. BPM opens the door to the possibility of smaller software portfolios, flexible response to business needs, and easy customization. BPM enables data to flow easily from the organization's various data repositories to its employees and partners while actually strengthening the governance of the data itself as well as that of the processes driven by that data. And, perhaps most importantly, BPM-based processes are indeed "invented here", custom-configured for the needs of the business, often without programming.

Sure, BPM has its challenges, and I hope to touch on those in this space. Ultimately, though, BPM holds out the promise of a revolution in the way that technology impacts business, and the way that business, in turn, views technology.