Do you ever feel completely overwhelmed when you hear about business processes and business process management? I know I did when I was first introduced to the subject. It felt like people were speaking in a foreign language and no one had the time or desire to help me learn that language. It took a lot of hours feeling dumb during meetings and researching the topic on my own before it finally clicked for me. If that sounds like you, then let this article be your guide to navigating the basics of business process management.
What I've discovered through the years is that no matter how large or small a project or which tools are used, there are six simple best practices that you can use to make business process management a heck of a lot easier to handle. You might have a few of your own that you consider essential, but for me, the six best practices are:
- Use a phased methodology.
- Develop a process documentation guide.
- Create a decision matrix.
- Simulate, model, and test.
- Communicate effectively.
- Monitor the processes.
I provide an overview of these best practices in this article and then point you to various resources where you can learn about them in more detail if you'd like.
I'm not necessarily a logical person most of the time, but when it comes to business process management, I'm a firm believer that logic plays a key role in the success of a project. Using a phased methodology is the most logical method for driving process management activities.
Don't let the lofty term phased methodology scare you. It can be broken apart this way: Phases are the segments in a process that logically follow one another. Methodology is just the analysis of the principles or procedures in each phase. Put them together and phased methodology is simply a logical analysis of processes.
When you're working on a project, phases are what keep you organized. They standardize the way changes are implemented and make it much easier to systematically analyze the people, processes, and information. Plus, they give you a clear method for defining goals, deliverables, and measurements.
Now, there's really no single, perfect way to create your project phases. I have my own preferences. (See my article listed in Resources, "Using a phased methodology in business process management," if you want to know what those are.) But really you can create phases in the way that best meets the needs of your organization. The point is to use a logical progression—such as discovery, assessment, simulation, design—to keep your projects on track and on budget.
The IBM® WebSphere® Business Integration suite of products, by the way, is particularly useful software for creating a phased methodology for your projects.
Develop a process documentation guide
If you've heard it once, you've heard it a thousand times: Document! Sure, it's tedious. Yes, it's boring. But when you're managing processes, it's perhaps one of the most critical elements in any project.
The documentation of current processes and any exceptions to those processes can help you clearly understand every last detail involved in the project. Face it: Someone has to know what's happening in every nook and cranny of a project, and if the business process analyst doesn't know, then who will? That's the job, as painful as it might be to admit. Business analysts are responsible for outlining the scope of the project, knowing who will handle which pieces of the project, which product lines are impacted, process roles involved, what the process management system procedures are, defining how the exception management process will work, and determining who makes the final decision on any given topic.
That's a tall order. The only way to handle it with any grace at all is to create a process documentation guide (see Resources) that clearly outlines and documents all those things. If you don't have one, you're just a sitting duck waiting for the hunter (in most cases, top management) to bag you and have you for dinner. The beauty of a documentation guide, really, is in its implied authority. Most people won't argue with a written document that includes all the elements outlined above—especially when you've had it approved by the project's management. Plus, it gives you a clear source to return to when the inevitable arguments arise about who does what or how and when something should be handled.
A key part of a process documentation guide is the decision matrix. This matrix is the area of process management that deals directly with the people involved in actively managing the actual processes: those who oversee the process, those who ensure its usage, those who deploy the tools used in the process, and so on.
When decisions must be made on a project involving a specific process, it's critical that you know who the true decision makers are for that process. For example, who approves specific changes to the process? Are different countries involved? If so, are there decision makers in each country that should have input when a change is made to a process?
A decision matrix is the simplest way to track who makes decisions, who thinks they need to be involved in making decisions, and who has the ability to break a tie in the event of disagreements. "Manage the process, not the steps" (see Resources) includes an example of a decision matrix. Take a look at it if you're not familiar with them.
I first saw one of these used on a worldwide project that involved multiple countries and multiple big egos. It was the only thing that stopped people in their tracks and forced them to back down when they realized that, while their input was valuable, they really didn't have final say in what the ultimate decision would be. If your project tends to have passionate people on board, do yourself a favor and create a decision matrix now. Get it approved by project managers, and then enforce it whenever you need to. People might not like it, but when it's written down in black and white, they will respect it.
Have you ever heard the saying, "When you fail to plan, you plan to fail?" It's a good saying to remember when you're working in process management. There are three different aspects to this concept, from my perspective: simulation, modeling, and testing. All three help you plan for success in different ways.
In a simulation, you imitate a process to see how well your general idea will work. You make a lot of assumptions in a simulation because you're typically in the earliest stages of determining design.
Process models basically lump processes of the same type into a model. This approach lets you see how well various processes work together.
Testing is usually the final chance you have to determine how well the processes and the tools involved in them actually work. Testing gives you a view of the reality you are about to inflict upon users.
If you truly want your project to succeed, don't skip any of these steps. Don't allow accounting to tell you there's not enough money. The accountants will have to find the money to fix a process when something fails that you didn't have a chance to test, won't they? And don't let management bully you into skipping a step because of time constraints either. They won't be happy with a failed project that came in on time, right? Each of the three pieces is critical, as far as I'm concerned. Projects that succeed use each one, and build in the time to adequately review the results of each too.
There are several good tools that you can use with all of these elements. For example, take a look at IBM Rational® RequisitePro®, IBM WebSphere Business Modeler, and IBM Rational Software Modeler. They are among the easiest tools to use on the market.
This is my favorite, probably because I'm a writer and communicator at heart. Think about it, though. How many times have you seen projects flounder because of poor communication? Probably more times than you care to count.
People learn in different ways, and they retain information based on how well you can communicate to them in the ways that they learn. For example, you might find you learn best when you see text combined with words. The people in the cubes next to you, however, might completely overlook the text and see only the pictures in their attempts to grasp the information. Neither method is wrong; they are just two different approaches to learning. If you don't recognize how your audience learns, you'll find it tough to effectively communicate critical information about the project.
How you communicate in a business environment also says a lot about you. If people must continually ask you for more information about your project, take that as a hint that you're not communicating effectively to those people. Focus on what they need from you instead of what you think they need, and you'll soon discover you aren't being pestered quite so much for information.
Some people find that sending out regular updates can help reduce communication problems on a project. Others prefer to add information to an intranet site that project teams can check at their leisure. Whatever you decide to do, keep it consistent. There's nothing more annoying than finding information about a project that's months out of date. You might think of communication as one of the lower tasks on your to-do list, but the people you work with consider it one of the most important elements of a project. When there's good communication, there is good morale and limited frustrations. Where there's inadequate communication, the opposite occurs.
I left this item for last, but it actually should occur throughout the entire life cycle of a project. Monitoring processes is the only way to track individual processes for optimum performance and return on investment (ROI).
How and when process monitoring occurs is entirely up to you and your organization. If you want to evaluate and analyze your manufacturing processes using real-time statistics, go ahead. Or maybe you want to focus on monitoring all enterprise resource planning processes. It doesn't matter. What does matter is that the monitoring occurs continuously.
Ideally, business process monitoring occurs before, during, and after design implementation. It's the only way to be certain that complex system landscapes deploy and continue to work as planned. If they don't, it allows you to rapidly find and proactively manage significant problems before any major trouble flares up.
I've addressed this specific topic in "Monitoring your processes to achieve optimal performance." (See Resources.)
I know it's tempting to skip steps here and there when you're in the throes of a major project. Things are happening so swiftly in most projects that it can be tiresome to remember to write a weekly recap of the project's accomplishments (and failures) or to take the time to create a documentation guide.
Planning and preparation, however, are critical to keeping you from feeling overwhelmed during those late nights. If you haven't used the six best practices listed here before on a project, try them on your next one. My bet is that you're going to feel more effective and in control by using these key building blocks in your projects.
Learn
- Check out
"New to WebSphere Business Integration"
to learn more about it.
- Read
"Using a
phased methodology in business process management" (developerworks, Jan 2007)
to learn more about S.E. Slack's preferred ways to create project phases.
-
"Create a process documentation guide" (developerworks, Mar 2007)
by S.E. Slack guides you through developing a template that can be used in
any process.
- An example of a decision matrix is
included in "Manage
the process, not the steps"
(developerWorks, Dec 2006) by S.E. Slack.
- Get tips on achieving better performance
and ROI through processes in "Monitoring your processes to achieve optimal performance"
(developerWorks, May 2007) by S.E. Slack.
- "Business process modeling: Using IBM WebSphere Business Integration Modeler"
(developerWorks, Oct 2005) shows you how to model a business process.
- Learn how to communicate more effectively
by reading S.E. Slack's article
"Obtain approval for your process change recommendations"
(developerWorks, Apr 2007).
- See the demo of
WebSphere
Business Modeler.
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from DB2®, Lotus®, Rational, Tivoli® and
WebSphere.
Discuss
- Check out
developerWorks blogs
and get involved in the
developerWorks community.
