BPM in Action

As discussed here last time out, Microsoft Corp. made some interesting BPM-related announcements on Feb. 26, as covered by ebizQ. Aside from its Business Process Alliance (BPA), Microsoft also announced plans to support to the Business Process Execution Language (BPEL) in the Microsoft Windows Workflow Foundation (WF).

What Microsoft Announced: BPEL Support...Sort of...

Specifically, Microsoft plans to deliver "soon" a Community Technology Preview (CTP) of WF enhanced with support for BPEL version 1.1. "The final release of the next WF version, expected this calendar year, will include full support for both the BPEL 1.1 standard and the BPEL 2.0 specification. Support for the BPEL 2.0 standard will enable the import and export of BPEL directly into Windows Workflow Foundation," Microsoft said.

Microsoft also plans further integration between WF and the R2 release of its BizTalk Server 2006 software, which the company said will be generally available in the third quarter of this year. In addition, Microsoft said that "new platform capabilities in the 2007 Microsoft Office system" and Microsoft Office SharePoint Server 2007 will "enable customers to realize the People-Ready value from business processes."

Hmm.

BPEL support is important – but only if it delivers interoperability and integration benefits with a minimum of pain and suffering. So IT decision-makers have to start by figuring out if BPEL support is meaningful for their enterprises' specific business needs. (Yes, most likely, for easy interoperability with and migration from or to multiple vendors' platforms, if not for specific meaningful features or functions.) Those decision-makers must then figure out whether incumbent or leading candidate solutions even support BPEL, and if so, whether its version 1.1 or version 2.0, and whether or not that matters. (The earlier version's more mature, but the later version's more functional, at least potentially.) (By the way, you can find a lot of information and discussion of BPEL and its implications by typing "BPEL" into the "Search" box at ebizQ.)

Then, the core question – will Microsoft's support for BPEL be sufficient to deliver the business benefits enterprises need and expect? Microsoft Office, an important component of Microsoft's BPM strategy, offers some clues, but not much hope. What Microsoft has done regarding its Open XML Format for files created by Microsoft Office 2007 offers some interoperability, but not the kind of playing-field-leveling parity at least some supporters of truly open industry standards likely expect or desire. And Microsoft so far only talking about BPEL support as a mechanism for importing and exporting information into and out of Windows WF raises at least as many questions as it answers.

And what about those BPM and BPM-related solutions important to particular enterprises, but not offered by members of Microsoft's BPA? IT and business decision-makers may find themselves passionately interested in various vendors' plans to join or support the BPA, or even lobbying particular vendors to join. But what will that mean to those vendors and offerings looking beyond Microsoft and Windows? Will Microsoft try to persuade BPA members to focus on Windows technologies to the exclusions of others, such as open source environments?

We don't yet know enough to answer these questions definitively here. But decision-makers at enterprises large and small had better start asking these and related questions, and insisting on actionable, meaningful answers, from incumbent and candidate vendors, Microsoft, and relevant Microsoft channel partners. And speaking of Microsoft partners,…well, more on them next time out…

Posted by mdortch in BPM • Microsoft  |  Permalink  | Comments (1)  | TrackBacks (0)

On February 26, Microsoft Corp. announced formation of a Business Process Alliance (BPA), and enhancements to workflow support elements of its .NET architecture.

Separately, Microsoft made some announcements about hosted services that have significant implications for Microsoft channel partners, and the companies that do business with them.

I'm going to spend several postings here musing over what all of this means. Comments and thoughts welcome, of course, here and/or via e-mail to bpminactionblog@ebizq.net.

What Microsoft Announced: The BPA

As ebizQ reported on the day of the announcement, Feb. 26, Microsoft announced formation of the BPA, as well as 10 initial members, listed below.
• AmberPoint ("run-time governance" of service-oriented architectures or SOAs)
• Ascentn (a BPM/SOA solution that integrates tightly with Microsoft technologies)
• Fair Isaac (products and services for business intelligence (BI) and performance management)
• Global 360 (BPM suite and related functionality)
• IDS Scheer (consulting, services, and software intended to enable "business process excellence)
• InRule (solutions for authoring, managing, and verification of rules and decision logic driving .NET environments)
• Metastorm (BPM software and best practices intended to foster life cycle BPM and "transformation")
• PNMsoft (Web-based workflow and BPM applications)
• RuleBurst (solutions for business rules, compliance, governance, and risk management)
• SourceCode Technology Holding Inc. (K2.net workflow solutions)

The BPA is intended to provide Microsoft customers a broad range of BPM choices, and the confidence that those choices will interoperate effectively with key Microsoft technologies (and, one assumes hopefully, with one another). The ultimate goal is to give enterprises small and large the tools and choices they need to create, deploy, and manage the processes best suited to their specific business needs and designated technologies.

But there are two other obvious goals of this particular enterprise. One is to broaden and deepen the penetration of Microsoft technologies in enterprises of all sizes seeking to succeed with BPM. Another is to position Microsoft technologies, such as BizTalk Server, the .NET Framework, and Windows Workflow Foundation, as enablers of comprehensive, integrated, multi-vendor BPM solutions. (You can see more about these technologies and how Microsoft sees them supporting BPM at www.microsoft.com/bpm.)

According to Microsoft, the BPA will initially focus four key areas, listed below.
• Business process modeling and analysis (as delivered by integration between IDS Scheer and BizTalk Server)
• Business rules management (via integration with Fair Isaac, RuleBurst, and InRule solutions)
• "Human-centric" workflow and process simulation/optimization (via integration with multiple BPM solutions)
• SOA life cycle management (via integration with AmberPoint)

So far, the announcement maps and tracks quite closely to many of the critical BPM challenges facing enterprises large and small. Microsoft said yet another goal of the BPA is to remove barriers to BPM facing smaller enterprises, notably cost and complexity. This can be nothing but good for business and technology decision-makers at enterprises reliant upon Microsoft technologies.

It may also provide a model for how Microsoft will work with partners in the future to tread the difficult-to-navigate line between promoting Microsoft-only and Microsoft-centric technologies and being a good corporate citizen and supplier. The BPA presents a strong opportunity for Microsoft to cash the check its mouth has been writing about its ability and willingness to support interoperability with other vendors' solutions to help customers succeed. Which leads naturally into discussion of Microsoft's announced plans for support of a key emerging BPM standard, the Business Process Execution Language (BPEL). More on that next time.

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

So my wife and I were contacted by the Arbitron ratings/audience measurement folks, and asked if we would fill out a log for a week detailing our radio listening habits and patterns. Seemed simple enough, so we agreed.

Then, the calls started.

They called to make sure we really wanted to do it. They called to make sure we'd received the logs in the mail, and understood the instructions included with them. They called almost every day during the week we were tracking our listening, to make sure we were doing so. They called to make sure we wouldn't forget to complete the logs and mail them back. They called to make sure we DIDN'T forget to complete the logs and mail them in. In fact, the only call we haven't gotten yet was the call to acknowledge receipt of our logs.

Now, I'm not a ratings guru or anything – but how much must all of this calling cost? Even if it's being done as inexpensively as possible, it's still got to cost Arbitron at least a few bucks per call. So Arbitron's customers – the radio programming and advertising geniuses who live and die by audience ratings – must be paying a fair amount of overhead for the information they purchase from Arbitron.

Arbitron is in the process of rolling out something it calls the Portable People Meter. The company plans to embed inaudible signals into standard radio broadcasts, and equip selected listeners with monitors of those signals, to eliminate the need for those diaries, and all those follow-up phone calls. Arbitron plans to provide free encoders to radio stations, and to offer additional encoders for high-definition radio and Internet streams at minimal cost. So the infrastructure to collect real-time listener information will be made widely available, and Arbitron should be able to collect more accurate, timely data for far less money than it's spending (or charging) now.

Of course, Arbitron doesn't expect to have PPM rolled out in the top 10 radio markets until July 2008, and expects it to take two to three years to reach the top 50 markets. The company's still exploring different approaches to electronic monitoring and measurement in markets beyond the top 50. So whatever advantages PPM offers Arbitron and its clients may be slow in coming. But on the plus side, such a timetable should give Arbitron enough wiggle room to work out any bugs encountered before the roll-out goes too far.

I think there are several BPM-related observations and recommendations buried in this little tale. Let me try to unearth a few.

1. Make sure that processes are aligned with both business goals and "the big picture." It makes no sense to implement processes for collecting information, for example, without taking a clear, complete look at total costs and unintended consequences. In the Arbitron case, an additional process or two that enabled the company to differentiate more reliable from less reliable information providers would let Arbitron focus its follow-up more tightly, avoiding upset of the most faithful and reliable providers.)

2. Ensure that all outward-facing processes include the ability to monitor and measure reaction of a test group before unleashing them upon the population at large. I can't imagine that Arbitron would be doing the level of follow-up it's doing with everyone who agrees to fill out a diary if it had really tested the processes involved and gotten reaction from a text mix of responders first. (But then again, maybe I'm just being naively optimistic.)

3. Don't boil the ocean, and set expectations realistically. BPM is often like really good barbecue – low and slow is the way to go.

4. Show your work. That is to say, explain to those affected enough about how processes are defined and justified to get and keep them on board with the program.

Those are some of the things I got out of my Arbitron experience, anyway. Let me know if you see anything else worth pointing out to other BPM enthusiasts...or if you've had similar relevant experiences worth sharing...or if you work for Arbitron and can explain how current processes are cost-justified...

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

A critical but often overlooked step toward BPM success is getting every employee to understand how BPM affects their jobs, and how their jobs contribute to more effective business processes at their organizations. How best to do this depends on who's available, and their skills and comfort levels regarding communicating to and with groups – and with evangelism, which is in fact what is often required to "sell" people on caring about business processes.

If you want your enterprise to succeed with BPM, you have got to start by getting people to buy into the importance of BPM, and of their contributions to it. This is by no means an easy set of tasks, for many reasons. Some of these are discussed most eloquently by Ismael Ghalimi, founder of open source BPM solution provider Intalio, most recently in "What is Wrong with BPM" in his IT Redux blog.

For better or worse, at many enterprises, this evangelism is going to have to start with people focused on IT. This is because they are often those with the most (if not the only) experience applying at least quasi-rigorous processes at least quasi-rigorously to business challenges. Also, this process of connecting people to BPM is going to require a fair amount of communication, and much of that takes place via IT-empowered tools, such as e-mail, portals, and wikis. This is why I started this multi-part screed with IT and not BPM training recommendations.

Ultimately, what I think everyone needs is a brief, enterprise-specific mini-handbook on how to use the top three to five IT tools available to them, and another explaining their roles in the company's top business activities, goals, and processes. These documents need to be supported by processes that ensure that they get regularly revisited and updated, and that they are appropriately distributed and their use and value promoted.

Where they exist, IT people should help to spearhead these efforts, but they cannot and should not shoulder the entire burden alone. Input from business-focused constituents is essential as well. At many enterprises, unfortunately, IT people will need their best and brightest marketing and sales skills to convince their business colleagues to make the effort.

Where there are no IT people available, business people are going to have to take up the slack at both ends. That is to say, those business people must evangelize for business process engagement, and for the IT infrastructure elements supporting the business and its processes.

Whether or not there are dedicated IT people (multiple definitions of "dedicated" absolutely intended here!) at your organization, they're going to need help here. As a start, I would modestly offer some of my previous musings in this space, particularly "BPM: Be Prepared to Market" and "BPM: Beginning Proactive Messaging." I would also recommend a bunch of the stuff in the RFG section of the ebizQ Analyst Corner, as well as the other resources at ebizQ. And if you're already dealing with incumbent or candidate BPM and/or IT infrastructure management vendors, you should see how and if they can help here as well. Let me know what you're doing and how it's working out. I'll try to help you to help us to help others.

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

Last time out, I offered some steps you can take to try to get everyone at your enterprise at least some basic schooling about IT. Herewith, a couple of other IT-specific observations and suggestions, before we try to tackle some basic BPM-specific issues.

If Microsoft Office is the standard at your organization, make sure every new employee gets a copy of "Office for Dummies" or some equivalently comprehensive, straightforward, and task-focused guide along with their computer and password(s). If OpenOffice is the standard, get "OpenOffice for Dummies" or a similar equivalent. I'm also a big fan of "The Little PC Book" for PC users, and "The Little Mac Book" for Mac users. All of these books, as well as several worthy alternatives, are available from Amazon.com, and from at least some of the independent booksellers affiliated with the BookSense Web site. Or you can just call your local bookstore and have them order some copies for you and your organization.

Such books do not replace training, but they are far superior to trying to corner a busy IT person to answer a question for which that IT person's skills are not really needed. I recommend to everyone I meet who uses computers but is not an IT expert and does not have an IT expert handy that they keep one such book near their primary computer at all times. I further recommend that when they have some free time, say during breaks or meals taken at their desks, that they just pick up the book, and randomly select some feature to explore. A few minutes with the book, accompanied perhaps by a bit of poking around on-screen menus, can do a lot to help users become smarter about and more comfortable with those technologies they have to use every day.

Such books also do NOT replace the company-specific documentation the creation and maintenance of which I've already recommended strongly. In fact, the books should be accompanied by a short introductory document explaining specifically how the books and that company-specific documentation and indoctrination activities all work together. ("The introductory indoctrination gets you started, the company-specific documentation helps you to get your basic work done, and the books help you to learn more, and to avoid and navigate around problems." Or something similar.)

Regarding business processes, well, it's a bit trickier to capture and document these in ways that are easily assimilated and digested. But it can be done. Basically, I recommend you review the specific steps I recommended for IT indoctrination and support, and adapt these to specific tasks and underlying business processes. This includes the creation of some shared collaboration space where users can share information to help support themselves.

But there is a critical additional step needed to succeed in getting up to speed on enterprise business processes. Someone has got to help users make the links between the tasks they do every day and the goals and requirements of "da bidness." More about that next time. Meanwhile, do please keep in touch, especially if you'd like to request and/or share more suggestions about this admittedly sticky, tricky stuff…

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

One of the most common, pervasive challenges to effective BPM I have seen and continue to see is a lack of basic training in the basic tools workers need to do their jobs. I have lost track of the number of users I have met who use software for document creation and editing, presentations, spreadsheets, and Web browsing, and who have received absolutely no training at all in any of these. Many of these people don't even know how to access, interpret, or use any of the help information included in these programs.

Why?

"There isn't time or budget for training – these people have work to do!" (And how much better and faster would their work be if they weren't spending more time than anyone seems to know figuring out how to do stuff they should already know how to do or figure out?)

"It's not my/our job to train people, and we don't have resources/skills for that." (That may be, but it still needs doing, on at least a basic level. And if you didn't insist on such skills when you hired these people, you owe it to them and to the company to help them learn at least enough to help themselves.)

"Everyone already knows how to use these programs!" (It takes about 20 to 30 minutes to teach someone how to get a sound recognizable as music out of a guitar. It can take a lifetime to get good at playing it. And the guitar is, in most cases with which I'm familiar, neither as complex nor as business-critical as most word-processing software. If you work with someone who says or acts as if they actually believe this one, you might want to consider changing jobs.)

What to Do

1. Pick a particular department, team, or task. Work with an initial set of those primarily involved to determine the most critical specific tasks they perform regularly. Criticality can be determined by effects on costs or revenues, or whatever other metrics make the most sense.

2. Choose one that relies upon one or more specific programs. For a sales team, maybe it's drafting trip reports, filing expenses, or organizing and following up with new contacts. For new service or support representatives, maybe it's completing incident reports, or escalating problems. Whatever. Doesn't matter. Pick one, and identify the program or programs users require to complete it correctly and effectively.

3. Work with users to identify and capture the specific steps needed to complete each task – including, where appropriate, how to turn on the computer and/or load the printer. Leave nothing out. Assume nothing. Focus only on commands and features directly related to the specific people, resources, and task at hand. And keep each task-specific set of instructions to fewer than five steps, or the equivalent of a single, single-spaced standard page of text. (Tasks that seem to require longer documentation may instead need to be broken into smaller tasks.)

4. Test and refine each document, again with at least some of the users directly involved in the tasks at hand. Edit and refine as needed. Then, make sure everyone who should get one gets one, and that it gets updated at least annually and after every significant change to the supporting IT resources. (Updates might go out with the employee manual or handbook your organization distributes to all new employees – right?)

5. Document the specific steps and results of your organization's specific take on the above recommended processes, and use these to replicate and scale this exercise across other business-critical tasks and the IT resources that support them.

Extra Credit: Put up a wiki or some other shared collaboration space, where users can support themselves by posting comments on the official instructions or newly discovered tips and tricks.

More soon. Comments welcome.

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

I spend a fair amount of time talking with acquaintances about their workplaces. Specifically, problems in their workplaces. It turns out that a large majority of these problems are caused by, involve, and/or are related to business processes and/or IT.

In my experience during the past three decades, I have come to believe that these problems are often the root causes and/or amplifiers of almost every other process- and/or IT-related problem I've seen. So, I've decided to try to help anyone visiting this space to try to recognize and solve these problems, before they become any bigger.

If there are two fundamental problems that cause more follow-on challenges than any other, I believe they are these.

1. No one is given time, training, or support specifically designed to help them learn and understand the critical processes that drive the business, and define their contributions to its larger goals.

2. No one is given company- or task-specific training or orientation to help them master the specific IT tools and skills they are given to do their jobs.

You can list these in any order you want. But I'd be very surprised if you could argue that once someone is hired or otherwise embraced by the business infrastructure, the majority of challenges that face that person can't be traced to one or both of these fundamental problems.

And yes, each is basically a BPM failure. Either there are no processes to guarantee that each of these shortcomings gets its bud nipped proactively, or there's no enforcement of or penalties for failing to comply with policies that do exist.

And the worst part? Each of these fundamental challenges could be addressed effectively in as little as a few hours of set-up effort, and an hour of initial self-paced work per user, bolstered by a few minutes each day or so.

I know, I know – sounds like a pitch for exercise equipment or weight reduction pills you see pitched on late-night TV. But I will, over the course of my next few entries here, argue to the contrary, and offer some specific steps and suggestions applicable at almost any enterprise, no matter how small in size or limited in IT budget or expertise.

If you work in a large enterprise that already offers/requires IT and/or process indoctrination of new affiliates, well, congratulations. You can use my observations and recommendations as points of comparison with your incumbent processes, and let me know if I'm missing anything important. For the rest of us, though, I'm hoping to begin a continuing dialogue about how and why BPM efforts fail (or never really get started). Frankly, I'm pretty convinced most of the reasons are more about people than process or technology, and equally convinced that as such, most people and organizations can jump-start fixing what's broken relatively easily, cheaply, and quickly. This will let us get to a stage where discussions of larger BPM-related issues are more meaningful to more readers and visitors.

So, next stop: IT orientation and support for everyone, on almost no money at with minimal disruption to operations. Especially compared with the disruptions caused when someone accidentally breaks something or can't do a required task in a timely fashion. Which usually happens because they don't know how, no one knew they didn't know how, and there was no one available or willing to educate them on demand. Which is, in fact, a class of stupid BPM tricks. Stay tuned, watch this space, and let me know how I'm doing – and how your organization is or is not dealing with the challenges on which I'm going to focus.

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

I had a great conversation recently with Mark Anderson, Executive Vice President of Overtone Software, Inc., and Mark Presnell, CEO at Ability Software Ltd. Overtone offers several interesting and useful solutions for creating and managing content from Microsoft Corp. Exchange e-mail or SharePoint collaboration deployments. Overtone is also the exclusive North American distributor and reseller for what I feel has become Overtone's "jewel in the crown," the AbilitySuite for IBM Corp.'s Lotus Notes.

The solution offers three levels of archiving and archive management, all selectable and configurable by enterprise IT and business decision-makers. The first level supports basic archiving based on simple rules, and focuses on capturing all e-mails for compliance and governance purposes. The next level combines support for more complex rules with methods for reducing overall archive and mailbox size, without sacrificing access to full content. (I'm intentionally compressing and simplifying here; more details are of course available at the Overtone Software Web site.)

The coolest stuff happens at the third level, however. That's where consolidation and integration of diverse incumbent compliance, discovery, litigation support, and records and security management tools can happen. That's also where enterprises can tag and categorize e-mails based on their own specific business goals, needs, and processes. It's also where Overtone's powerful AbilitySuite Central Search Portal can be used to find almost anything you'd care to find in a centralized message archive. That's why the company refers to what happens at this level as "Information Governance," or "E-mail Knowledge Management."

But look carefully at what that archive can tell you, not just about e-mails and collaborations, but about business processes. A growing number of my analyst industry colleagues are increasingly reporting that high percentages of business-critical intellectual property (IP) reside in those e-mails. That means that once you can not only search through archives, but analyze content and collaboration "flows," you can determine much about what people are doing, and how and why they're doing it. In other words, you can get a lot closer to human-centric BPM.

Suppose you could easily see, for example, that changes to the IT infrastructure or customer-facing business processes were accompanied by spikes in e-mails to, from, or among certain internal constituencies. Might not that information be useful in helping to make (or unmake) refinements to the IT infrastructure and/or relevant processes? Similarly, if e-mails containing particular enterprise IP elements increase or decrease in response to particular business and/or IT changes, that e-mail pattern shift might tell you valuable things as well. For example, you might equip e-mail users not already so equipped with a shared portal, to make sharing of the IP they're using easier for them and perhaps more secure for the enterprise.

Overtone is not the only e-mail archiving solution vendor out there, of course, and if you're using an e-mail archive, you can already apply some useful analysis to at least some of the information stored there. However, what makes the Overtone AbilitySuite stand out, from my BPM-centric perspective, is the combination of its reporting and integration features. Also, since it is built to be closely aligned with the Lotus Notes platform, it is poised to take full advantage of the improvements IBM recently made to that platform, as discussed here previously.

Heck, I can easily imagine a day when real-time and near-real-time e-mail traffic analysis is used not only to flag and route around IT infrastructure problems, but to highlight and spur refinements in business processes. But then, Mom always said I was naively optimistic. Nonetheless, the Overtone folks seem to share at least some of my optimism and excitement about the real and potential links between e-mail archive management and BPM improvement and optimization. But as always, I'm most interested in what YOU think, so do please let me know.

Posted by mdortch in BPM • Collaboration • IBM  |  Permalink  | Comments (0)  | TrackBacks (0)

I got a wonderfully frank and straightforward e-mail from a vendor, in response to my recent post, "This is a Test: Are Vendors Credible BPM (or IT) Users?" The writer of the e-mail was Greg Carter, CTO and VP of Development for BPM solution vendor Metastorm, Inc. With Greg's permission, I quote below from his missive.

"As a point of reference, here at Metastorm we are asked if we use our product internally by quite a few customers and analysts.

"I think that BPM vendors are pretty lucky in general – the opportunities to use our own software are a huge bonus as BPM is so widely applicable to the ISV business. For example, we have 15+ business processes in use. All of our product planning and management processes, customer support, enhancement capture, sales lead tracking, marketing event planning, expenses, purchase request, and sales order processing are done via Metastorm BPM. There are dozens of applications in the queue as well.

"In my area we use our product for product component planning and management, tasking, and test and defect tracking.

"While of course we tell everyone that our product works flawlessly for our internal use, one place I think we can be quite objective about BPM is where it is [and is not] applicable. We don’t use our BPM product for Build Management or [sales force automation (SFA)], for example. We have [other] great, cost effective tools available to use [for those tasks]."

I believe Greg's e-mail highlights what I think of as best practices for vendors touting themselves as customers of their own solutions. Vendors should provide some credible details about how they are using their own tools internally, and not pretend to believe that those tools solve every business problem known to humankind. (As I remember Clint Eastwood's Dirty Harry character saying at least once, "A man's gotta know his limitations." This applies with equal force where one's chosen software solutions are concerned.)

In late January, ebizQ reported that Metastorm plans to focus enhancements of its BPM Suite on four areas in 2007. These include "end-user empowerment" via integration with Microsoft Corp.'s Office 2007 applications and Windows Vista, extensible process design and deployment, extracting business value from service-oriented architecture (SOA) deployments via BPM, and governance and business performance. Metastorm's Carter said at the time that this evolution mirrors a shift in focus from departmental challenges to enterprise-wide embrace of a "process-centric philosophy." Good goals, for a BPM vendor and a BPM implementer alike, I think.

Those seeking to achieve similar goals at their own enterprises might want to take some closer looks at Metastorm's offerings, plans, and successes, internally and elsewhere. It is also always instructive and illuminating to strive to ensure that your chosen or candidate BPM vendor's product road map aligns with your own business goals and plans. Please share your experiences as you put those vendors to the test – especially if you work for one of them!

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

Business Week reported today that a substitute teacher in Connecticut has been convicted of exposing seventh-grade students to pornographic images on a computer in 2004. The teacher, 40-year-old Julie Amero, faces up to 40 years in prison, according to the Associated Press article at the Business Week Web site.

Amero claims some students were looking at a Web site about hair styles, but that the computer she was using soon started popping up pornographic images. She tried to stop the images, she said, but they kept on appearing, and she was under strict orders not to turn the system off.

Amero and others who testified at her trial claim that the older computer had no anti-spyware or anti-pop-up software installed. The principal of the school where Amero was teaching said that the computer lacked such protection because a vendor's bill had gone unpaid – and that no similar incidents had ever happened at the school, before or since. Prosecutors claim Amero clicked on graphic sites intentionally. Meanwhile, some observers wondered why students continued to watch the images on the computer after recognizing what they were watching.

This report follows by a bit more than a week a page-one article by David Lazarus in the San Francisco Chronicle. Lazarus reported that the Indian Consulate in San Francisco dumped thousands of sensitive documents at a recycling center. The documents, including thousands of visa applications, including some submitted by corporate executives and political figures, sat in a yard at the center for more than a month, Lazarus said. Ironically, one visa applicant whose documents were among those found at the recycling center was from Brian Biega, who oversees storage and management of internal paperwork at Oracle Corp. When Lazarus asked him what Oracle's chief, Larry Ellison, would do if boxes of sensitive Oracle information were left at a recycling center, Biega said, "I'm sure I'd lose my job."

In contrast, Indian Consulate officials said that this wouldn't really be considered much of a problem in India, and that they thought the documents would be shredded by the owners of the recycling center. One added that in India and other countries, consulate officials go to the roofs of their offices and burn documents they no longer need, a practice frowned upon here in the U.S. An Indian Consulate official did apologize to the general manager of the recycling center for the confusion, then said he was on his way to Best Buy to pick up a shredder, Lazarus reported.

I am going to resist the almost overpowering temptations to castigate or crack wise here – the stakes are, quite frankly, too high for joking. I will, however, cite what I see as some key morals of these regrettable and just plain sad stories.

1. Processes without enforcement procedures are like goals without deadlines – less than useless.

2. No computer should be allowed within 50 feet of an impressionable young person without a full complement of anti-malware software – and processes to enforce such strictures must themselves be revisited and revised regularly.

3. Records, both physical and electronic, require life cycle management processes and policies, which in turn require enforcement and regular review. This is true for every business, individual, school, or other entity that touches any personal or private information. Period.

4. For goodness' sake, shred everything with an address, phone number, or Social Security number on it before disposing of it, even if you are recycling instead of dumping the stuff into a landfill!

It can be really, really easy to over-think BPM, and to create situations of "paralysis by analysis." It can sometimes be just as easy, if not easier, to under-think BPM, or to inadequately apply or enforce important policies or processes. And then, things like the two stories above happen. Got any process-related horror stories (or success stories) you'd like to share? Send'em along, and let's see what kind of dialogue we can muster.

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

My ebizQ colleague Gian Trotta and his First Look team have recently investigated Appian Corp.'s latest BPM solution, as well as Alfresco Software, Inc.'s open source, BPM-enabled, service-oriented-architecture (SOA)-ready enterprise content management (ECM) offering. (Whew!) You should definitely check out Gian's posts – "Appian Enterprise 5.5: BPM Via Your iPod?" and "Alfresco's Cool Approach to ECM, Open Source Marketing, BPM and SOA," respectively. Here are some thoughts they engendered for me that you might find interesting and/or useful.

1. Truly effective BPM must be invisible, pervasive, and ubiquitous. That is to say, it must touch every user, and embrace every element of every business value chain. For this to happen, BPM, like the IT infrastructure itself, must also embrace every device and "work style" likely to be a part of the enterprise mix. This is a lot of what Appian's director of product management Phil Larson alludes to when he talks about people rerouting work or escalating tasks via voice commands from cell phones. (I'll wait until I actually see it before commenting on his idea of initiating business processes from an iPod…although I'm all over doing so from one of Apple's new iPhones!)

2. Effective, comprehensive BPM must follow the same evolutionary trail being blazed right now by enterprise collaboration and communications solutions. Multiple channels and access methods must be easily and securely integrated, to enable people to work the ways they work best, while delivering to them (only) the information and tools they need to do their jobs. This also means close integration between the IT-enabled tools used for BPM and those used for ECM, which I and others sometimes call "intellectual property lifecycle management" or "IPLM." That integration is a large part of the coolness factor of Appian Enterprise 5.5.

3. Open source solutions for tasks such as BPM and ECM can not only shorten vendor sales cycles, but can accelerate internal "sales" and "marketing" efforts between enterprise IT and business decision-makers. Instead of debating over terminologies and unstated but obvious political agendas, open source tools can be used to build models and simulations of processes, or pilot ECM or BPM deployments. Thus, open source ECM tools such as Alfresco's, or BPM tools such as those from Intalio, an Alfresco partner, can short-circuit a lot of debate and "FUD" ("fear, uncertainty, and doubt") about BPM, ECM, and/or enterprise open source solutions.

4. BPM, ECM, IPLM, and SOA are all important and intertwined, but none of them per se is the "point of the exercise." Rather, each is a step towards a larger goal – using IT to enable and empower people with the information and tools they need to perform the tasks needed to make the business live and grow. This is the "IT 3.0" focus on people, tasks, and information absolutely essential to the support of any serious effort to build and sustain a "Web 2.0" enterprise…whatever that might be…

Once you've given a look and/or listen to Gian Trotta's posts on Alfresco and Appian, you might also want to check out some relevant reading on how IT infrastructures are or should be aligned with BPM, ECM, and SOA initiatives. Potentially useful RFG research in the ebizQ Analyst Corner includes "Best Practices for IT Infrastructure Management and Business Alignment," "Building an Agile IT Infrastructure," "Business Knowledge Management," Parts I and II, "From SOA to Business-Oriented Architectures," "Making the BPM-SOA Connection," and "RFG's Recommendations for SOA Initiatives." There are lots of other helpful resources all over ebizQ as well. Go peruse some of them, then let me know how BPM and "IT 3.0" are evolving – or not – where you, your customers, or your partners work.

Posted by mdortch in BPM • Collaboration • IT Infrastructure Management  |  Permalink  | Comments (1)  | TrackBacks (0)

One of the most consistently valuable and widely read types of information about BPM and enterprise IT in general is the user story. Sometimes called a "case study," sometimes called a "success story," such tales always seem to gain a lot of traction among others pursuing or considering BPM or other IT initiatives.

Except, it seems, for some, at least, when that user happens to be an IT vendor.

After numerous conversations with IT decision-makers at user and vendor enterprises, and with more analyst relations people, public relations people, and users than I can remember, I've concluded there are two types of people in the world. There are those who believe that any user experience can be useful, even if that user is also a vendor. And there are those who believe that anything and everything that comes from a vendor is immediately suspect, even if it comes from IT decision-makers at that vendor company.

I believe that each side has some good points – but that generally, we have more useful things to learn from vendors than we have reason to distrust them, especially where experiences related to BPM and IT are concerned. After all, if we are in fact trying to build and deploy the most effective BPM solutions possible, shouldn't we try to learn from everyone's relevant experiences? If there is anything about vendor experiences in these areas that automatically disqualifies those experiences from further consideration, I have no idea what it might be.

(A similar debate has raged – or at least burbled along consistently – for years regarding anonymous user stories. "Anonymous stories lack credibility," argue some. "What they say and have to teach us is more important than who they are and where they specifically work," argue others, including me. Just so you know.)

Here's the thing. Proven practices and experience-based decisions are far more important to the success of BPM efforts than any particular technological choices. And in some three decades of watching this space, I have yet to see a serious vendor successfully try to hold itself up as a credible "reference account" and avoid scrutiny by always-skeptical users. Users typically recognize BS from vendors immediately, and discount it appropriately, whether they say anything out loud about it at the time or not. And the serious, credible vendors I've encountered know all of this, and comport themselves accordingly.

If your enterprise is already or considering doing business with a BPM vendor, you should ask that vendor to show you how it is using its own solutions, and how its own BPM experiences have driven development of those solutions. If you're already or considering doing business with a vendor too small to use its own solutions, you can still ask about the experiences its founders and leaders have had or seen at other enterprises. And any credible candidate vendor should be able to connect you with at least one customer with experiences worth sharing, even anonymously. Call me overly cautious, but I find it hard to recommend purported "solutions" that can't yet be shown to have actually solved something, somewhere. Even if "somewhere" is the place where the solution itself was developed.

But as the title of this rant indicates, this is in fact a test. I want to know what you think of vendors as credible sources of user experiences, and of the value of user experiences generally to other users' BPM efforts. So please tell me – via e-mail or comments posted here, anonymously or otherwise. And I want to hear from you whether you're a user, a vendor, or just a mildly interested observer/instigator. This is a debate that hasn't gone away in 30 years, so let's see if we can't add anything interesting to it!

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

In Part 1 of this outing, I proposed that Sun Microsystems, Inc.'s DTrace offers some nifty benefits, to IT infrastructure managers and to those trying to develop and deploy effective, human-centric BPM. Herewith, a continuation and extension of those observations.

The folks who created DTrace and others at Sun are pursuing a set of initiatives collectively known as "FISHworks," where "FISH" stands for "fully integrated software and hardware." At this week's Sun Analyst Summit in San Francisco, members of the Sun team demonstrated the ability to morph general-purpose computers into purpose-specific appliances intended to replace devices ranging from network-attached storage (NAS) managers to firewalls.

The most interesting part of the demo to me, though, was the DTrace-powered dashboard with pre-built, easy-to-customize scripts and routines. These made it incredibly easy to identify and resolve performance anomalies, and to gain significant insight into who was doing what with what on a network – at least in the demo.

So why not an eventual "BPM assistant" or "BPM orchestration" appliance? One with a dashboard that consolidates and concatenates real-time and near-real-time information about how IT is performing, and what people are doing and using on the network? In ways that information can be used directly to help to craft and refine, and perhaps even "roll out" and "roll back," processes that govern the access to and use of enterprise IT and IP resources?

An example might help. Your company decides that everyone must use the same processes to get business expenses submitted and reimbursed. Once the process becomes law, performance information indicates a sudden spike in problems with a particular server, which is causing slow performance of the expense-processing application. This leads to high user dissatisfaction – with the process, not the application or server per se. However, comprehensive, robust technologies such as DTrace help to isolate and resolve the problem rapidly – or, perhaps in conjunction with modeling, simulation, and testing technologies, to avoid it in the first place.

Yes, it's an aggressively simplified example. And yes, there are still many, many steps to be taken before most enterprises could do something like this, let alone more subtle and profound BPM-related, IT-enabled things. But aggressive, ambitious goals are an essential element of successful enterprise BPM strategies. And besides, it's good to dream.

Meanwhile, back here in real life, you should know that Sun described the prototype general-purpose-computer-to-specific-function-appliance-transmogrifier with the DTrace dashboard I saw as somewhere "between concept and product." Hmm. And other IT infrastructure management solutions and vendors already offer dashboards that at least promise to deliver consolidated, comprehensive information about IT and network performance. Some of these even promise further to enable and support more effective BPM. Examples include BMC Software, Inc., CA, Inc., Hewlett-Packard Co. (HP)'s OpenView portfolio, and IBM's Tivoli unit, among others.

All of these vendors' offerings have constraints and shortcomings, cost and complexity historically being the two most profound and consistent. But technological evolution, the rise of open source, and other factors are helping to tilt things a bit further in favor of buyers and users.

The more usefully IT infrastructure management and BPM can be integrated, the more events and developments in one area can inform and potentially improve events and developments in the other. Also, the more effectively systems-centric process management can be automated and left to IT-based solutions, the more human "bandwidth" should be available to address the more human-centric BPM challenges.

If your company is already pursuing BPM, those efforts should be as closely aligned with IT infrastructure management policies, processes, and solutions as possible. If your company is already pursuing comprehensive IT infrastructure management, those efforts should be as closely aligned as possible with any current or future BPM initiatives. If your company is not pursuing either, you may want to keep an updated résumé handy. Meanwhile, check out the RFG Research Note "Best Practices for IT Infrastructure Management and Business Alignment" in the ebizQ Analyst Corner for more "deep thoughts" on these and related subjects, and let me know if you'd like to discuss any or all of these further, here or otherwise.

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

Sun Microsystems, Inc. offers a very interesting tool originally designed to identify and explore online application performance. That tool is known as DTrace, and as its name implies, performs "dynamic tracing" of what might be thought of as application workflows. To quote from Wikipedia, "DTrace is designed for tuning and troubleshooting of applications and the OS itself, giving its user operational insights with which they can make performance gains. Special consideration has been taken to make it safe to use in a production environment."

That latter sentence is particularly interesting. Folks from Sun describe DTrace as capable of automatically "instrumenting" itself to deliver the desired information. That means that you "point" DTrace at something, and it "automagically" figures out how to go to that something and configure itself in a way to extract the desired information, without materially affecting performance. Other tools used for so-called "root-cause analysis" can take hours or days to track down and identify specific causes of performance problems, even after you've spent the time and money to obtain or build and deploy the "right" probe or monitoring tool.

In addition, DTrace supports a programming language, known imaginatively enough as "D," a kind-of successor to/subset of the venerable C language. This means one could write scripts that instruct DTrace to obtain and present a wide range of information that can help to improve IT performance, process-related knowledge, or, optimally, both.

All well and good, but what's that got to do with BPM?

Well, suppose you can point a software "lens" at any or every part of a particular application or service and determine not only how it's performing, but what people are doing with it. With such information, you'd know a fair amount of information that could be very useful to defining, managing, and refining business processes. And if you could write programs for such a lens, you could perform all kinds of useful analysis and monitoring tasks repeatedly and consistently, generating historical and trending information about behavior that drives real-life business processes.

No wonder the Wall Street Journal awarded DTrace top prize in its 2006 Technology Innovation Awards competition. It came in ahead of innovative lightweight solar energy panels, and powdered insulin that can be inhaled instead of injected!

DTrace has its shortcomings, however. First of all, to do what it does requires tight integration with the kernel or heart of an operating system – in this case, Sun's own Solaris 10. However, DTrace was the very first component of OpenSolaris Sun made available under the Common Development and Distribution License (CDDL) in 2005. Sun claims more than 7 million downloads of OpenSolaris, which means a fairly large number of folks are building DTrace-enabled problem-solving and process-managing solutions even as you read this.

There is also work going on to port DTrace to the Unix-derived FreeBSD open source operating system. In addition, Apple Inc. announced last year that an upcoming release of its OS X environment will have DTrace built in as well. (Bryan Cantrill, one of the creators of DTrace, suggested to IBM Corp. back in August 2006 that IBM support development of DTrace for IBM's AIX operating environment. He made some cogent, customer-centric arguments for it, too. No word yet on any reply.)

So you will likely be able to take at least some advantage of DTrace soon in your own environment, even if you're not knowingly running Solaris. Whether or not this is true, though, I suggest you investigate DTrace and its growing ecosystem. I think the exercise could help to provide a template or wish list for the kinds of information you can and should extract from your IT infrastructure to drive your business processes.

Some good starting places include the DTrace OpenSolaris Community, and the DTrace section of Sun's BigAdmin Web site on systems administration. These contain oodles of links to discussions, downloads, information, and other resources. Meanwhile, make sure to tune in here for Part 2, wherein I will provide glimpses of an interesting, potentially bright, BPM-enabling future for DTrace and IT infrastructure management!

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

When the PC was new, lots and lots of enthusiastic entrepreneurs went out and got computers, and either spreadsheet or "business" software. They then enthusiastically entered every bit of data about their businesses into said software, and generated some fine-looking forms and statements, which they then enthusiastically took to their accountants. Who promptly, and likely with varying levels of enthusiasm, discarded and/or recycled them, explaining to their clients that the time to have a chat was before buying and employing that hardware and software.

When physical records were all companies had to worry about, they often hired librarians to oversee cataloging and archiving of those records. Those librarians often had training and credentials in library science, research and information-storage methodologies, and related fields. In fact, many enterprises still employ such experts, to great and good effect. However, when electronic records began to rise in prominence, many enterprises, even some run by otherwise fairly intelligent people, left the cataloging and archiving methodologies for those electronic records in the hands of…IT people. Who largely ignored the existence of those librarians, or the potential value of what they knew and know. (This is not "archival" knowledge; I recently had a conversation about this very topic with an incredibly knowledgeable librarian at a non-IT high-technology company where you'd think they'd know way better.)

I believe there is a lot of useful BPM-related knowledge hidden in a lot of brains and bodies at a lot of enterprises, knowledge that is not being used to drive, inform, or support BPM efforts adequately, if at all. I believe there are a number of reasons for this, some understandable, but none of them good or completely justifiable. They include and range from simple cluelessness on the part of those who should be most qualified to "connect the dots" and the appropriate people, to political myopia. Sadly, but often understandably, much of the fault lies with technically focused people who don't understand interpersonal politics well enough to assign them their deserved weight in any business decision dynamic. Increasingly, however, significant fault lies with business-focused people who don't understand or want to accept the critical roles IT plays in making their businesses run.

But I'm not here to find fault or assign blame – until or unless someone hires me to do so. Diplomatically, of course. (The G-rated version of my favorite definition of diplomacy is "the ability to tell someone to 'get lost' in such a way that they look forward to the trip.")

Meanwhile, though, those of you trying to pursue or support IT-enabled, human-centric BPM at your enterprises would do well to heed the lessons of past mistakes and IT-business misalignments. Even if you don't think the politics of a situation do or should affect things, consider how illogical it is not to at least explore every potential source of useful, already proven knowledge, policies, or processes. Perhaps fortunately, compliance, governance, and risk are driving more BPM decision-makers to collaborate more closely with human resources, IT, legal, line-of-business, and other personnel, to try to figure out how best to cope with shifting regulations and requirements. These developments won't necessarily make all of these people work well together, but if it gets them all around the same table, it's at least a promising start.

For further reading, I would point you at any of several previous posts in this space, and at the post from Neil Ward-Dutton of Macehiter Ward-Dutton on "Sustainable SOA and 'closed-loop' thinking" in the "Software Infrastructure for Business Value" blog at ebizQ. I also encourage you to comment on this subject, and to write to me and tell me whether your enterprise is leveraging knowledge, or leaving it behind.

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

I mean, it's so bad, people (including some of us at RFG) had to come up with semi-torturous four-letter acronyms – BPfM for business performance management and BPcM for business process management, for example.

In other venues and instances, people and companies use "BPM" to mean either or both, with frightening little consistency in some cases. (This is why editorial standards and rules can be valuable, even to IT people, who should immediately go out and read the books "Eats, Shoots, and Leaves" and "Elements of Style," if they haven't already. But I digress.)

This "alphabet soup" situation indirectly points out an inescapable trend in the markets for both types of BPM solutions – they've converging, and expanding. As I and others around here have written previously, process management solutions alone are inadequate for comprehensive, effective, human-centric management of processes for systems and the people who use and manage them. This means that today's BPM suites, as comprehensive and powerful as they are, increasingly require augmentation to deliver the "big picture" view and holistic management of processes enterprises increasingly realize they need.

Taken together, the "two BPMs," process and performance management, form a critical crucible for the forging of new, integrated approaches to both sets of tasks. Ideally, every IT architecture and infrastructure should be equipped with features, policies, processes, and tools that enable and support management of key business processes across their entire life cycles. Of necessity, this means blurring or eliminating distinctions that currently separate, for example, process management from process optimization, which is another view of performance management. Assuming processes are sufficiently aligned with business goals and needs, of course.

In essence, there are several "task sets" required to constitute comprehensive management of business processes in the modern enterprise. These include, but may not necessarily be limited to, the following.

+ Business knowledge management, my take on what others sometimes call human interaction management (including appropriate harmonization and consolidated management of human-centric and system-centric processes).

+ Business process management (including capture, definition, mapping, prioritization, protection, revision, and storage).

+ Business process performance analysis, assessment, management, optimization, and refinement (based upon rigorous, business-driven, enterprise-specific metrics wherever possible, with said metrics also governed by rigorous processes across their life cycles).

+ An integrated, life cycle approach to managing these and any other critical steps in harmony, for optimal business benefit.

The various interdependencies, specific sub-steps, and other required components will, of course, vary from enterprise to enterprise and situation to situation. However, the above should prove a good, first-pass map of what the "big picture" should look like regarding management and optimization of key business processes.

Does it? What's missing? How's it done where you work, or among your key customers and partners? Let me know. This is a discussion likely to go on for some time, as technologies evolve, vendors consolidate, and business and IT decision-makers figure out more about what their enterprises need to succeed.

Posted by mdortch in BPM  |  Permalink  | Comments (1)  | TrackBacks (0)

"It's tough to make predictions, especially about the future." -- Yogi Berra

I thought David Kelly's forecasts and thoughts on the near-term BPM market ("A Look at the 2007 BPM Market") to be thoughtful and thought-provoking, and encourage all reading this to read them. I also found James Taylor's rules-centric follow-up, "Business Rules and Business Process in 2007," to be similarly inspiring, and equally worth reading.

I'll try to come up with some useful predictions of my own about the marketplace, which you'll read here as soon as I've divined what they are. (See the above quote.) Meanwhile, here are what I think are 10 (or so) of the top questions BPM practitioners will have to consider – as will vendors who want to be considered trusted advisors and suppliers to those practitioners.

1. Who owns the processes for defining and prioritizing business processes, and how best to empower and equip them?

2. What processes and tools are best suited to supporting the multifaceted collaborations needed to define, prioritize, and promulgate business processes?

3. How best to assure that all BPM efforts are sufficiently human-centric to enable effective business knowledge management (BPM) and human interaction management?

4. How should BPM solutions and vendors evolve in response to the integration of BPM features into a wide range of other applications and services? What tools and processes will orchestrate and manage these most effectively?

5. Assuming a credible value proposition for BPM, how best to deliver and pay for it? Is a Salesforce.com-like software as a service (SaaS) model viable for BPM-specific applications and services?

6. What processes and solutions will best achieve and maintain appropriate integration between BPM and security initiatives, policies, processes, and solutions?

7. How best to reconcile the increasing functional breadth (also known as "complexity") of BPM solutions suites with the need to integrate with incumbent solutions for analytics, intelligence, and other functions -- and limited, task/benefit-focused budgets?

8. Given the growing number of free process modeling tools, and the availability of free open source BPM solutions, how best to evaluate, select, and integrate as appropriate?

9. How best to assess the growing number of alleged "best practices" for BPM, and to adapt the most promising to enterprise-specific business goals and needs? Which vendors can be most helpful here, and how?

10. What policies, practices, processes, and solutions will best help to get and keep everything IT does focused on enabling and supporting core business (and human) processes, even as business goals, processes, and technologies change?

Well, that about covers it. For now, anyway. No pressure. Really.

Feel free to drop me a line, to quibble about the list, to add questions you think equally important, or to talk about how such questions are or are not being addressed at your enterprise. Confidentially, of course.

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