Maturity can be a useful notion for companies trying to
better visualize how they might more thoroughly integrate their BPM solution
across the enterprise. In her blog, BPM expert and all-around smart person Sandy
Kemsley describes a recent talk by Paul Harmon, Founder of Business Process
Trends:
[Harmon] walked us through the [...] business process maturity model from level 1, with no organized processes to level 5, where processes are continuously being improved. He pointed out (quite rightly) that most BPM technology vendors are selling the ability to implement level 5, yet most organizations are at level 1 or 2, and struggling to improve their process maturity.
Perhaps the message here is that vendors ought to make sure
they are meeting the basic needs of their customers before selling them
expensive and complicated extras--components that address problems their
customers aren't yet close to facing.
That admonishment applies equally to customers. As I've said
repeatedly in this space, the biggest bang for your buck is achieved as soon as
you automate. Get that done and worry about the more subtle, complicated issues--integration
with enterprise platforms, conformance with enterprise architecture standards--later.
Consultants like to imply that the higher you scale the
maturity mountain, the more value you will receive. Perhaps that's true, but those
slopes steepen sharply as you rise. If
you're not yet ready for the thin air near the summit, establish a base camp,
toast your accomplishment, and gather yourself before pushing for the top. In a
rush? Well, yeah: so were the folks whose frozen bodies you'll pass on the way
up.
The hard truth is that today even the most technically unsophisticated business user has grown accustomed to rich, dynamic, graphical user interfaces. A typical Facebook session invokes any number of slick UI features that weren't even possible just a few years ago. Never mind that web companies spend millions designing and market testing their user experience paradigms: your users are disappointed afresh each time they bring up one of your BPM-driven e-forms and it doesn't look anything like iTunes.
While you probably don't have the budget to make filling out an expense report feel like ordering a movie on Netflix, there are a few things you can do to keep the crowd from getting restless. An e-form should do more than just save trees: it should help the user complete their task efficiently, minimizing both time and uncertainty. For example, if certain information is needed only under a particular condition, don't prompt for that information unless that condition is met: the words "If yes, then..." should never appear on an e-form. Even small acts of kindness can go a long way with users: I'm reliably gratified when a form that requires an address prompts for the zip code and then fills in the city automatically.
Too many forms, however, trip over my pet peeve: presenting users with choices they don't understand. There's nothing worse than encountering a question like, "Is this expense fully or partially compliant with European Union General Standard Number 321-2452, subsection (ii)?" One of the great things about BPM is that a form can be routed from one person with some of the required information to another with additional information. Take advantage of that capability to require each user to provide only the data with which they are most familiar.
I'm regularly surprised by the number of e-forms I encounter that appear to have been created without the least bit concern for how they will be used. Your BPM vendor has (I hope) provided you with the tools to build e-forms that, while they may not resemble Amazon.com, can nonetheless guide your users through their tasks with a minimum of keystrokes and mouse clicks. If an app is worth building, it only makes sense to spend the time needed to design it in such a way that it doesn't frustrate and annoy the people who have to use it.
]]>This week I'll cover my second prediction; namely...
2. A new emphasis on business process as a service (BPaaS).
BPM in the cloud has only just started to catch on, but the next wave is already on the way. Why employ staff to build and operate your business processes when you can outsource the whole deal?
We're already seeing some BPM vendors, including the one I work for, offering to build and support highly customized business processes in the cloud for their customers. Convenience and ROI will drive this trend forward in 2013, with, I predict, the appearance of some new players: business process outsourcers (BPOs). As their name suggests, BPOs are already delivering outsourced business process resources to customers. By bringing BPM into the mix, they will be gain leverage, reducing the burden of building custom services for each client.
Imagine, for example, that you are a BPO offering help desk services to dozens of customers. While the help desk operates more or less the same way for each, there are a number of custom parameters and behaviors that each client demands: escalation policies, user interaction models, and so forth. You want to take advantage of BPM solutions for the same reasons as anybody else--to improve the efficiency and robustness of your business processes (in this case, the processes you're operating on behalf of your client)--but also because the slight changes from one client to another are easier to implement and maintain using a BPM platform.
As an outsourcer, any economies of scale you can realize give you an edge in a very competitive marketplace. So for BPOs, adoption of BPM offers advantages that will prove hard to resist.
And so my predictions for the year are complete. I feel very fortunate in this new year to hold a position that enables me to share my ideas while at the same time learning from all of you. I look forward to using this blog to engage with you, and I hope you will do the same, either by commenting on these posts, following me on Twitter at @ESMatBPL, or just dropping me a note at scott.menter@bplogix.com.
]]>So, BPM fans (as well as those who are simply BPM-curious) may wonder what's in store this year on the BPM front.
A recent forum topic raised the same question. I gave two short answers (plus one shameless plug for this blog), and I'd like to expand on those. I'll cover the first of these this week and the second next week, just to give you something to look forward to.
1. Further integration of BPM into packaged applications.
Enterprise applications are great at structuring and storing data. Forrester refers to these types of apps—think CRM, ERP, ECM, HRIS—as "systems of record": they collect data from a variety of sources and organize it in a way that makes it accessible and useful for workers. But BPM has raised the bar, and now organizations expect to access, combine, and update that information as part of fully automated business processes.
Many application vendors offer a certain amount of workflow functionality, usually as an optional extra. Unfortunately, the workflows are often difficult to modify and difficult to integrate with data from other applications. And, of course, the skills needed to build workflows in one package don't transfer well to another.
But customers and vendors alike have come to recognize that BPM solutions—or, as Forrester has nicknamed them, "systems of engagement"—can overcome these problems, tying disparate systems of record together. As a result, packaged app vendors are beginning to realize that integrating directly with BPM software can provide more functionality for less effort than building their own workflow features. Expect this trend to accelerate in 2013.
Once again, happy new year. May you and yours enjoy a fulfilling and healthy year filled with happy surprises and rewards.
Tune in next week for my second prediction!
]]>The trick is knowing what has to be done. Automated out-of-office emails are nice, but they leave the onus on the requester to track down somebody else to handle their issue. The real magic is to be able to auto-reassign requests as they come in. Fortunately, most BPM platforms can do exactly that, by enabling the blanket reassignment of a given user's tasks to another user.
But this type of delegation, no matter how useful it may be during the holiday season, isn't the full answer to the problem of dynamic task assignment in business processes. If I'm away on vacation, then sure: just delegate everything I'm doing to Sue (I'll bring her a tin of macadamia nuts from Kauai to make it up to her). But what if I'm actually here and I'm assigned a task that would be better handled by a colleague?
No matter how well designed your process, you need the flexibility to pick and choose tasks that ought to be assigned to somebody else. Ideally, you can accomplish this by merely forwarding your emailed task notification to the right person. Yes, in theory that could lead to a "hot potato" situation, in which the task is handed around until somebody is stuck with it, but in practice most people will pick up the phone and verify that the potential recipient is willing to accept the task before sending it off.
The process designer specifies which tasks, if any, should not be transferable. If you're designing such a process, keep in mind that such restrictions should be rare. It's also important to consider what effect delegation might have on the rules you set up for your process. For example, if you're checking whether the process initiator took some action, you'll need to also keep in mind that the task in question may have been completed not by the process initiator, but rather by a delegate. Talk to your vendor about how your particular solution helps make those distinctions.
As smart as modern BPM solutions are, they can never anticipate every situation in which a task assigned to one person should actually end up on the desk of another. Design with delegation in mind, and your users won't have to call you away from that Kauai beachfront to reassign tasks administratively that they could have as easily delegated on their own.
If you're considering acquiring a BPM platform, or figuring out how to adapt your existing solutions to accommodate the new mobile reality, here are some things you may want to keep in mind.
As the guy in charge of service, you have two choices: fix this, or start rehearsing the phrase would you like fries with that? You've heard whispers about an IT-driven project that might help, so you call the CIO, who tells you about the BPM rollout she's been planning for months. And, good news! Once the architecture committee has approved the plans—which will definitely be by the end of next quarter—your group is third on the list! With any luck, you'll have a solution by mid next year, latest. Or the end of next year, but that's definitely worst-case.
Oh dear. By then, you're going to be wearing a paper hat and a polyester shirt, so it's pretty obvious that the corporate top-down BPM roll-out isn't going to be an option for you. In desperation, you reach for the keyboard and Google around for BPM. You discover that a number of vendors offer BPM in the cloud—could that be a shortcut to solving your problem?
Fast-forward four months. IT's BPM RFQ is in its final evaluation round: they're down to seven vendors. Meanwhile, your department's cloud-based BPM customer inquiry application is up and running. In the first 30 days, complaints have dropped by 80%, and negative mentions of your company on Twitter have also fallen off. Your boss has started hinting around about a raise; even your wife has mentioned that you seem different, somehow—younger-looking, even.
Of course, word spreads about your success. Within a year, five departments have deployed cloud-based BPM solutions. The COO has chosen you to chair a committee looking at how these various solutions can be leveraged across the company. He hints at the possibility of additional stock options.
You have lunch with the CIO; apparently, the RFP is complete, and a vendor has been selected, but things have stalled in the negotiations phase. It seems that the CIO is having difficulty developing an ROI case for the $2 million price tag. "Maybe top-down wasn't really the way to go with BPM," she observes as the waiter arrives with your wine. You raise your glass. "Bottoms up!"
For some reason, the CIO doesn't even smile.
1. Rapid deployment
Early BPM products (and, unfortunately, some current ones) assumed that process deployment would continue to be in the domain of programmers, and therefore were built with programmers in mind. Happily, many solutions today enable creation of complex workflows, eforms, and reports by anybody with a reasonable facility with technology (and a strong understanding of the underlying process). Thus, not only is it less expensive to deploy each process, there is also a greater percentage of the staff who may be trained in doing so. Result? Faster deployments, faster changes. BPM is the sword that has at last cleft the snaking queue of IT projects.
2. Delegation
When all change requests have to go through a single window, there's going to be a wait, and that wait translates into additional cost. BPM, however, enables us to delegate different parts of the problem to different individuals. Don't like where that request gets routed? The workflow person will change it. Think that the approval levels need tweaking? The business rule person will take a look. The expertise required is around the process itself, and not the obscure language in which that process is expressed. Delegation results in faster, easier, and less risky process changes.
3. Real time and historical data
Under the old model, a process that goes off the rails might stay there, burning cash, for a very long time before being fixed. The risk is open-ended. Using BPM, however, there is a constant flow of real time and historical information available about each process instance, and the process experience as a whole. The implication here is that I not only don't have to fix my process before deploying into BPM; I actually don't want to. A full-featured BPM solution will help me find and fix that problem faster than I can do it otherwise.
That last bit bears repeating, because it illustrates my whole problem with the "fix it first" school of thought. Why wouldn't I want to use a tool as valuable as BPM to surface and repair flaws in my process? Am I more likely to find the issue, and design around it, by filling out dozens of swim lane and RACI charts in the course of interviewing mobs of process actors?
I don't think so. So take a deep breath and jump right into the BPM pool. The water's great.
It's been difficult for me to understand the mindset that leads to this question. To me, it's like asking if you should cook a meal before leaving for the restaurant. But I've been thinking about the way process automation has evolved, and I'm developing a clearer understanding of what might lead somebody to think they should go through the pain and effort of process improvement before implementing BPM.
Time was when automating a manual process was an expensive affair, involving analysts, programmers, project managers, database administrators, and a cast of others. The advent of SOX and the persistent tightening of the regulatory tourniquet only contributed to the problem. As a result, a substantial amount of resources and funds were tied up in these efforts. Technically naive managers (rightly) feared the expense and complexity of the projects, and suspected that, left to themselves, the techies would simply run amok.
It didn't help that a huge number of these development programs failed completely. And so a variety of methodologies were unleashed on the world, all designed to ensure that IT stayed true to the requirements of the business.
And yet, development projects continued to fail. There are two primary reasons for that:
» Business users rarely had a good grasp of their own processes, so transmitting requirements was challenging at best.Next time I'll talk about how BPM helps close this sorry chapter, leading to a new cycle of innovation and success.
PS: If you've got some time on Thursday, April 26, please tune in to DMRadio to hear "Cloud Computing and the Evolution of Business Process Management", a discussion featuring your humble blogger, Forrester analyst Clay Richardson, and others.
You've got management reports to prepare and a presentation to deliver in the morning. Those are the highest-priority items on your plate, but that's not how you spent most of your day. No, you used up valuable hours tracking down the approvals for your trip, the paperwork to hire that new assistant you need so badly, and the documentation that internal audit has been screaming for since last week. None of those things is going to make your company any money, and none is high on the list of things you signed up to do when you took this job.
Employee engagement is a 21st-century metric, one that nobody really considered or cared about in earlier decades. It can be hard to gauge, but in my mind, it's proportional to the percentage of time a given employee spends doing things that move your company in the right direction. That, in turn, relies on the "softer" measures of engagement--how much does the employee like her job? Does she spend half his day looking for deals on Groupon, or thinking about new ways to reach and connect with your customers? Is he attentive to details like contract terms and discount opportunities, or does he rush through agreements and procurement in order to catch the early train back home.
BPM software can be a secret weapon in the battle for employee engagement. BPM, properly used, can create an environment with less bureaucracy, fewer menial tasks, and more time to focus on what's really important. BPM is used by organizations every day for:
Take the boring, routine, and soulless paper chase out of your employee's workday, and her engagement is bound to increase. Higher engagement is linked to higher productivity and greater profitability. But, beyond that, wouldn't you rather work in an environment in which you and your colleagues are freed from the dreariest parts of your work day?
When we speak of BPM, we usually talk about hard savings like paper reduction or risk mitigation. But BPM's less well-known impact on employee engagement can make an even greater contribution, to your bottom line and to your colleagues' work life. That's an investment worth making.
]]>When I first encountered BPM, I judged it to be a natural fit for any organization with a strong business process improvement (BPI) focus. It seems obvious: BPM gives businesses a way to get their arms around their processes, examine them, and improve them. And, to a certain extent, I was correct: there are plenty of organizations leveraging BPM as an important player in their enterprise BPI efforts.
Still, I'd expected more. Indeed, to my way of thinking, by now BPM should have sparked a revolution in the entire discipline of process improvement, from philosophy to execution. So why hasn't it?
The bottom line is that BPM is too disruptive to have been instantly and widely embraced by the process improvement community. As is true in so many other fields, BPI has its own culture, language, and norms; BPM simply falls too far outside the realm. Even the word "process" may not evoke precisely the same image for the BPM expert as it does for the process analyst.
And maybe that's OK. After all, the goals of BPM are far more ambitious than those of process improvement. BPI historically gained traction in large enterprises where it held out the promise of expense reduction. Ironically, although process analysts themselves wield a toolbox full of metrics, as a group they are often evaluated on only one: hard dollar savings.
BPM, on the other hand, has much more to offer. Yes, cost reduction is frequently the primary objective. But BPM can also improve customer experience; boost employee engagement; enhance regulatory compliance; increase management visibility; and clarify roles and responsibilities. These are all vital benefits, yet they are rarely the focus of traditional BPI efforts.
Perhaps one day BPM really will cause an earthquake in the
way formal process improvement is learned and practiced. In the meantime, we'll
continue to enjoy the ever-accelerating number of advantages BPM brings to the
table.
This week's announced acquisition of Global 360 by OpenText had me scratching my head. Didn't OpenText only just recently acquire Metastorm? My mom would no doubt disapprove of OpenText's voracious appetite for BPM firms: she always taught me to take at least enough time to put my fork down between bites.
There's plenty of speculation around as to why OpenText would acquire two very different BPM vendors in such a short interval. Perhaps time will clarify everything, though that's certainly not a given: there are plenty of acquisitions that make no sense when they happen, and no sense afterwards either. Still, while I give OpenText the benefit of the doubt, there are a couple of messages in this acquisition I find hard to avoid:
In the scheme of things, though, OpenText has done us all some good here, adding energy to an already frothing product category. Thanks in part to transactions like these, the BPM market continues to be an exciting and occasionally even surprising place to work.
]]>Lawson's Time Management. Ariba's Procure to Pay. Taleo's Recruiting package. These and hundreds of others: they all must die. And it is BPM that will kill them.
Understand, I'm not talking about replacing best-of-breed apps with integrated suites. As a former CIO, I'm no fan of high-cost, complex software suites. But BPM represents an opportunity to create dynamic, highly customized, extremely flexible solutions across the enterprise--and all with no programming required. It's the best of best of breed.
BPM opens the possibility of leveraging a single app to solve dozens of business challenges. Imagine, if you will, replacing all those single-purpose tools with one flexible platform. From one vendor. Requiring one skillset. Enticing, is it not?
Of course, not every piece of business software is suitable to be replaced by BPM, but I'd bet that in your shop there are many more such expendable apps than you realize. Like the examples I list above, strong candidates for the noose include tools that provide a mechanism for collecting data, enhanced with some basic workflow. Document approval, help desk, expense reporting, capital expenditures: these are just a few of the areas in which you may find the dead walking among us. And when you do, do yourself a favor: pull the plug.
But, OK, that's just anecdotal. So I offer the following data point: in a recent survey of 110 CIOs of sub-$1 billion companies, only 44 (or 40%) answered affirmatively to the question, Do you have a BPM project or initiative inside your organization?. Even 40% would be a decent level of saturation, but these CIOs are reporting projects, not installed, operating solutions.
Even more interesting, or perhaps confusing, is that fully 87 (or 80%) answered affirmatively to the question, Are you attempting to automate some of your manual, paper based processes? (not including a number of others who answered with variations on "no, but we will soon"). So only about half the CIOs looking to automate their manual processes seem to consider that effort a "BPM project or initiative". That is not a sign of a mature market.
There are a couple of possibilities here. One is that the analysts are simply delusional (a point of view I've been known to advocate now and again), and BPM is still in the early stages of its adoption and maturity. The other, though, is that analysts are simply not paying enough attention to the sub-$1 billion marketplace when they look at how BPM is being procured and deployed. That would also explain why we do find very mature, multi-vendor solutions and even BPM centers of excellence in some of the largest companies, even as smaller firms remain in the dark.
So, does BPM have a role in the medium-sized enterprise? I sure think so. And... hmmm, then again, maybe I'll save that discussion for next time.