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 BPM software and workflow software tools, there are implementation and BPM application and workflow application 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.
- 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.