There are dreams -- and then there's reality. For those of us who have spent time in enterprise software, we've seen ambitious plans and big hopes turn into unusable or "unsavable" projects more often that we may want to admit. With a lot of software tools, there are implementation and integration issues that become complicated early on. These end up taking up a disproportionate amount of time and, as a result, ultimately end up causing many of these projects to be derailed or shelved.
When looking at a solution based on BPM, however, identifying the gaps between hope and reality ‘should’ happen much earlier in the process. That is due to the fact that what is required for the foundation of BPM comes about when you create the initial framework. That framework includes a review of what is important to your organization and an assessment of how your organization actually operates.
BPM offers an excellent model for operational efficiency -- and one that ultimately leads to improving the bottom-line. First, however, it must be mapped out in a way that prepares the organization for success. In that respect BPM is analogous to cooking: when you have a good recipe (i.e. a framework) and compatible ingredients, you know they will mix well to provide something delicious at the other end. Conversely, even an amateur cook instinctively knows that anchovies and brown sugar just aren't going to be a good combination.
The first thing is to understand is what you'll need -- and where you're going to apply it. Let's look at the elements involved in having a well-constructed BPM:
- Function: Where will you use your BPM tool? Product development, marketing, finance? Because BPM is so highly customizable and flexible, you need be specific about what you'll use it for, as well as for which specific aspects of that function. There's a mindset to the people who carry out certain tasks, and they are successful when they can rely on proven ways of meeting their goals. But the way an IT team operates is different from the way a finance group works. All of this thinking will eventually need to be embedded into the BPM, so it's essential that the functions are considered when creating a model.
- Environment: Here's where you'll need to map the tools and technology components you have available to you to the BPM. Maybe you won't rely on much of the technology functionality, but you need to be aware of what you could do so you can adapt your processes to the potential and limitations of the tools. If technology won't provide the backbone of your BPM operations, what will? This is where you need to consider how methodology applies to process.
- Processes: The result of activities, decisions and a workflow produces a process that enables a result. At this point in your modeling, you should be thinking specifically about processes that will need to be created or modified, and what the impact of these processes will be on the overall landscape of your BPM.
- Workflow: Your workflow will be comprised of a lot of tasks that must be done in an orderly way. But just completion of those tasks is not enough to justify a BPM roll-out. Rather, you should be thinking not just of the linear way of getting things done, but what decisions, roles and activities will be involved that will impact the workflow.
- Roles: If you've scoped this well, then you not only know what each player does, but you know how to optimize their time and resources so they're adding the most value to the process. It's crucial that each person is able to impact the business process by contributing their strengths. This is where BPM is most evidently not just a technology-dependent thing.
- Decisions: If you can, with a fairly high degree of accuracy, determine what decisions will need to be made during the workflow of your BPM, then you'll have a greater likelihood of success when it comes to defining your workflow and assigning roles appropriately. Too often, a decision point is considered to be either a "yes" or a "no" situation. In some cases, there's more nuance to what's required; after all, the decision leads to the next step in the process, or it leads to completion of the process. The key is anticipating what the decisions will entail and what the results of those decisions will likely be.
- Activities: While separate, distinct activities will be what governs how the BPM will function, it's important to note that there are very different types of activities. Keep in mind that activities that are provided and handled by an individual are different (and provide a different impact) to those activities coming as a result of an entire group or business unit. Note not just what the activities are, but who performs them, and to what end they will arrive.
Looking at a BPM scenario in this way, and in breaking it down to this degree, is the only true way to give you a model for what you want to implement. You're not starting with a stone, and chipping away at something that fits your needs. Rather, you have the luxury of customizing this to your needs. What is truly important is that you must first know what your needs are and how each element impacts the others. With a sense for your needs, you'll be prepared to embark on a BPM instance and begin to realize benefits in efficiency, productivity and organizational sanity.
--Marti Colwell, VP of Marketing & Business Development