BPM in Action

I have of late been following numerous parallel event and development tracks regarding BPM and related areas of interest. One of the things that becomes increasingly clear to me is that there are a lot of companies and decision-makers out there who are seriously on the fence, behind the curve (or the 8-ball), and/or all of the above regarding BPM.

I understand. BPM is challenging and complex. One of the primary reasons for this is that it is neither fish nor fowl – or, perhaps, it's fish that thinks it's fowl, or vice-versa. (I'm already confusing myself here, but will press on valiantly nonetheless.)

BPM is a set of human-centric business problems that often masquerade as or are confused for decisions and issues focused on IT solutions and systems. And vice-versa. Moreover, effective IT decisions must be made within a context defined by effective business processes.

So, to get BPM right, it is often necessary to go back to basic first principles to make the best possible decisions. One of those basic first principles comes in the form of a single compound question – what is BPM, and how is it supposed to help our business run better?

Well, I'm glad I asked me that, and hope you are or soon will be glad, too. After much cogitating about first principles for business and IT operations, here's what I've come up with so far.

At its core, BPM is really intended to answer some basic questions, in the order listed, cyclically and on demand as needed.

1. What part or parts of the IT and/or business infrastructure are not working, and can they be fixed non-disruptively? If not, what should be done instead? If so, in what order should they be fixed, and what resources are needed to fix what's broken?

2. Once all critical infrastructure disruptions are addressed, are all elements of the infrastructure providing optimal support to all business-critical applications, goals, requirements, and services? If so, how do we know this, and how can we demonstrate and measure it? If not, how do we know that, and how can we determine how best to fix the situation?

3. Throughout the life cycle of business and IT infrastructure elements and the resources they consume and support, business and IT practices and infrastructures must minimize risk, maximize security, and ensure business-mandated and regulatory compliance. To achieve these goals, do we always know who is using what IT and intellectual property (IP) resources, when, where, why, and how?

4. As basic business goals and requirements are being met, how best can the business and IT infrastructures be improved to enable and support future goals and requirements? And how can this cycle be repeated and refined in ways that lead to continuous positive transformation of business and IT processes and practices – starting again from the beginning of this list?

I'm going to be devoting more time and space here to delving into these and other related basic issues that must be addressed effectively if BPM is to have any real business value. I'm hoping these excursions will provide, over time, an increasingly rich and helpful context within which more specific BPM decisions, both operational and technological, can be made more effectively. We'll see. Stay tuned…

(PS: Yes, the headline of this post is a clumsy, annotated paraphrasing of the late, great Edwin Starr's classic, "War." And yes, we all really, really need to get out and hear newer music more often…)

Posted by mdortch in BPM • Business Knowledge Management • IT Infrastructure Management • Security  |  Permalink  | Comments (0)  | TrackBacks (0)

Frank Van Buren is a businessman who has loyally carried an Exxon Corp. credit card, issued by Citibank, for 17 years. His card was about to expire, and he contacted Exxon to request two new cards.

He got them. Shortly followed by a box of 1,000 additional new cards, festooned with Frank's name and account number, but without the activation stickers most new credit cards now carry to help prevent identity theft and unauthorized use.

Frank called Exxon customer service, and was told to destroy the cards. Which he and his shredder spent three hours doing. After which, he received another box of another 1,000 ready-to-use credit cards.

Frank tried to get reimbursed for the time and trouble of shredding the 2,000 cards he didn't request and didn't want. He was first offered $25, which he refused, then $100, which he accepted, albeit grudgingly. Exxon, meanwhile, said publicly that it has no idea what happened. Citibank said it apologized for "any inconvenience."

Yeah, right. Meanwhile, Frank came away feeling victimized by a company with which his business had done business for almost 20 years. As he told the New York Daily News, "Companies are not giving us what we pay for," he said. "The attitude was: 'This is your problem, not ours.'"

So, what have we learned today?

1. Business processes do not stop at the front door or loading dock of your business, but extend to every partner with which you do business. This means that your business is ultimately responsible for anything with it or your name on it, even if a partner is involved in actual delivery.

2. You cannot control the implementation or management of partners' business processes. But you can, should, and must audit those processes regularly, and build into your partnership agreements specific terms and conditions that motivate partners to communicate regularly and clearly with you and your business. Those agreements should also penalize partners that violate or fail to comply with said terms and conditions.

3. Ensure that your business processes, and those of your key partners, include rapid and meaningful apologies to customers who are badly or inexplicably treated – and more than token financial remuneration when those customers are significantly inconvenienced. The customer may not always be right, but is always important, and should always be treated that way.

Posted by mdortch in BPM • Current Events  |  Permalink  | Comments (0)  | TrackBacks (0)

As reported here at ebizQ, Lombardi, a leading provider of BPM solutions, has forged an alliance with a company called Gordian Transformation Partners. (According to legend, whoever could untie the Gordian Knot would become king of ancient Asia Minor. Alexander the Great, legend continues, when stymied by the failure of traditional knot-untying processes, took a different approach – he cut the knot in half with his sword. A straightforward, if unexpected solution to a knotty problem, and a great metaphor for BPM challenges.)

Under this new alliance, the companies will combine Lombardi's Blueprint collaborative process planning tool and Teamworks BPM suite with Gordian's expertise in process transformation and business performance improvement. Gordian has also joined Lombardi's Certified Partner Program, which provides assistance with honing partner BPM skills and identifying revenue opportunities.

Frankly, I am enthusiastic about this alliance, and expect to see more of them among BPM and BI solution vendors during the next 18 months and beyond. BPM and BI solution vendors tend to have expertise that is more focused on their solutions and horizontal business needs. Specialty consultants such as Gordian, in contrast, tend to have deep, focused, business-centric expertise in one or more specific markets. The combination means that companies focused on specific businesses can work with a knowledgeable partner to craft custom-tailored, finely tuned BPM and BI solutions from proven technological elements.

This is a win for all concerned. The BPM/BI solution vendor doesn't have to become another Accenture or IBM Global Services to compete effectively for business in particular markets, but can partner with "boutique" business experts instead. And such business experts don't have to risk getting drowned out or ignored when seeking to ally with a much larger and more broadly focused technology partner. Users, meanwhile, can acquire integrated, focused combinations of technology and expertise that help get them closer to true BI and business knowledge management (BKM).

The biggest potential obstacle? Expertise can still be relatively expensive to deliver and share, in part because it almost always involves putting people who command high hourly rates in front of other people who command high hourly rates. This may explain why the Lombardi-Gordian alliance seems focused primarily on so-called "Fortune 500" companies.

The next frontier? Figuring out how to combine software as a service (SaaS) with "expertise as a service," then to deliver both using IT instead of planes, trains, and automobiles. This is a hot emerging area with a lot of potentially important themes, variations, and players. I suspect I and my ebizQ blogmates will have more to say about it and related subjects, soon and more and more often. So do stay tuned…

Posted by mdortch in BPM • Business Knowledge Management • Software as a Service  |  Permalink  | Comments (0)  | TrackBacks (0)

I have just read the recent posting by my learned colleague and ebizQ blogmate Joe McKendrick, in which he summarizes some of the high points of the panel discussion that wrapped up the recent BI in Action Virtual Conference. I of course agree completely with what he and the other participants had to say about the links connecting BI, BPM, and service-oriented architectures (SOAs). I have in fact referred to what I and some others call "business knowledge management" (BKM) as the "missing link" connecting these three critically strategic areas. (You can read about BKM in more detail in some of the research located in the RFG section of the ebizQ Analyst Corner, as well as in previous postings of mine here, particularly this one, and at the "BI in Action" blog, where you will find a reprise of this very entry as well.)

However, I, perhaps as usual, have something to add.

It is equally critical, I believe, to remember that most useful BI, as well as most of the actual "heavy lifting" regarding BPM, resides in the hearts and minds of actual individual human users. Yes, of course, there's a lot of relevant "intelligence" resident in data and documents, and even within the IT systems and connections that support access to and manipulation of these. But all of that "stuff" is done by people who are trying to do jobs that drive the business. Those people are the ultimate consumers and beneficiaries of most if not all of the most significant services provided by SOAs as well.

I know that Joe and everyone else involved in the BI in Action Virtual Conference knew and knows this. However, it can be too easy to take away from discussions about BI, BPM, and/or SOAs that some mix or subset of these technologies can simply, "automagically" improve things for users and/or the business.

Would that it were that easy.

BI, BPM, and SOA efforts must include specific, concrete elements focused on incorporating user input and feedback, from the earliest stages of development and deployment. Of course, all such initiatives are perhaps cavalierly assumed to be "designed with users in mind." However, IT and business decision-makers must also make overt and explicit efforts to incorporate user input and feedback, and include in their project plans steps and metrics focused on user productivity and satisfaction.

BI, BPM, and SOAs are elements of larger business-technology ecosystems, within which things that affect some elements directly and/or indirectly affect all other elements. In such a context, users can represent the most maddeningly difficult elements of all to manage and integrate. (I have heard many engineers say without a trace of irony that a particular project or system would work just fine, if they could just keep users away from it. This may be true, but kind-of misses the point of the exercise in a business setting.) However, users and IT people in an enterprise are like cast and crew in a play. They may not understand or be able to stand one another, but without either constituency, you got no show. So make sure that everything you do (and most everything you say) regarding BI, BPM, and/or SOAs includes and addresses users adequately and directly. It may make things a bit more complicated, but it will help to ensure that they support rather than combat or ignore your efforts.

Posted by mdortch in BPM • Business Knowledge Management  |  Permalink  | Comments (1)  | TrackBacks (0)

According to an Information Week story posted today, the U.S. Department of Veterans Affairs, otherwise known as the "VA," has updated the details of the lost hard drive announced in January. At that time, the VA said a hard drive lost from its Birmingham, AL Medical Center contained approximately 48,000 veterans' records, with as many as 20,000 unencrypted, despite explicit policies requiring such protection.

In February, the VA said the January numbers were a little off. The lost drive could have actually contained personal information about as many as 535,000 people, and about as many as 1.5 million physicians not affiliated with the VA.

Now comes a report dated June 29 from the VA Office of Inspector General (OIG). According to the report, the IT "specialist" who lost the hard drive deleted and encrypted files on his own system, to hide and to minimize the extent of the information lost with the hard drive. Said specialist only confessed after confronted with information from a forensic analysis the VA OIG had performed.

Further, the report states that the lost hard drive might not have even been lost, had incumbent physical and electronic security policies been followed and enforced. Policies such as encrypting sensitive data, something a local VA administrator apparently decided was unnecessary, if he just asked his workers not to remove the hard drives from the office. Which they did. And to lock them in a safe when not in use. Which they did not. Which likely wouldn't have mattered, since the safe had no access log, nor partitioned access, which meant that every employee who did use the safe had access to every other employee's hard drive. Or at least, the hard drive of any other employees who had bothered to lock their hard drives in the safe.

This laxity in policy enforcement also extended to the unnamed IT specialist. He was also given sufficient access to supposedly private personal information that he could extract information from medical records into a research database. Access he did not need and should not have been granted.

So, what have we learned?

1. Security policies are exactly like business processes. Without consistent documentation and enforcement, and frequent "re-inculcation" among users, they are basically useless.

2. Electronic and physical security policies and processes require close integration and synchronized management, if either is to be truly effective.

3. Enough is enough. That is, don't provide anyone access to more information than they absolutely need to do their jobs. Especially if any or all of that information is considered personal and private.

4. Process management is continuous. Anytime anyone thinks any process is completely managed and requires no more oversight, something bad is about to happen. Especially if there's a poorly managed IT specialist involved…

Posted by mdortch in BPM • Current Events • Security  |  Permalink  | Comments (0)  | TrackBacks (0)