The uneducated person perceives only the individual
phenomenon, the partly educated person the rule,
and the educated person the exception.
—Franz Grillparzer
To be successful nowadays, modern organizations strive to be “process-centric”—that is, relying on a finely articulated business process architecture with all instances of the organization acknowledging the importance of well-defined business processes as key to successful operation, planning, and decision making. But sometimes organizations can fall into a situation where they’re not able to develop an effective business process, and instead they develop “case-by-case syndrome.”
According to 6SixSigma, a business process is
a collection of activities that work together to produce a defined set of products and services. All business processes in an enterprise exist to fulfill the mission of the enterprise. Business processes must be related in some way to mission objectives.
So, in order to be successful, the flow of activities needs to be:
- Consistent—so there are no contradictions.
- Coherent—so it is valid, true, and complete for the activities it addresses.
- General—to cover the great majority of cases and exceptions.
- Repeatable—so that it can be replicated each time the process is needed.
As easy is it seems, many times the process development cycle gets stuck, and organizations fall into what I like to call the “case-by-case syndrome.” Instead of achieving all the above within a process, the elements of the process get managed as exceptions or unique cases. Although many factors lead to this syndrome, let’s analyze a couple that appear with some frequency...
How Case-by-case Syndrome Happens
Scenario 1: Born Dead
- You develop a process.
- You abandon it before you launch it. Or you launch it but you don’t get user buy-in, so users do all they can to abandon the process.
You develop a business process, but during its development you have problems defining its scope and level of complexity. You encounter a high level of criticism and reluctance to adopt it. Stakeholders find it not suitable or anticipate major issues getting in the way of its effective operation.
Once launched, people abandon the process or use it in only a very limited way. Most of the process is managed outside of the system on a case-by-case basis. The system finally is not successful in automating the process, and the process is not made any more efficient or easier to manage.
Scenario 2: Why Bother?
- You start developing your process, looking at the part of the business you need to create a process for.
- Finally, you decide it’s too complex, so you don’t even bother to develop it.
You’ve initiated the development work, but it seems the team is getting nowhere, with too many constraints or exceptions getting in the way. (Never mind the time pressures.) After extensive sessions of discussion, negotiation, and frustration, there is no consensus about the best way to approach the business process. The stakeholders ultimately determine that the processes are not suitable for standardization and it would be preferable to conduct activities on a case-by-case basis.
With all the BPM applications companies have at their disposal today, you might think that this situation doesn’t occur in modern organizations, but you’d be mistaken. It does, and it’s more frequent than it should be. A basic reason for this is that business processes involve more than a series of business steps; business processes act like the nervous system of a company. Involving heavy use of data and serious human collaboration at various levels, a business process is an internal vertical line of command that has extensive interaction within external resources.
Besides the degree of interaction required, the complexity of the decision trees and exceptions can drag a process to an “analysis paralysis” situation—a point of inaction where it seems preferable to avoid engaging in creating a process that might be too difficult to deal with.
Why Case-by-case Syndrome Happens
Ronald G. Ross in his excellent article How Business Processes, Strategy, and Business Policies Relate observes that:
Business process models are intuitive. That’s why people like them. They provide management blueprints for coordinating repetitive work. But are they sufficient for creating an optimal business solution for a business challenge? No.
So, the problem is not just about building and deploying the process model, it’s about enabling all the elements to work together. And this implies establishing the right scope, involving the right people (stakeholders), and defining the right business rules, which, by the way, as Mr. Ross mentions, are not necessarily embedded in the process flow.
Deploying a business process may be unsuccessful for some of the following reasons:
- Lack of buy-in: your stakeholders may not see the value in automated processes, because
- management hasn’t communicated the benefits properly,
- there is poor communication between the process developers and line-of-business users, or
- the development team did not approach the complexity of the process with the appropriate perspective.
- Lack of commitment: Your people simply may not be committed to doing the work required to automate your processes, because
- they disagree over the approach to take in developing the process, or
- they are not involved in all aspects of project and for that reason, are not comfortable with the solution.
- Insufficient analysis: You haven’t looked deeply enough at your business to understand the real problem.
- It is tempting to try not to get your hands dirty, and you may not give yourself enough time to perform a complete analysis of the process.
- Development work is initiated with budget and time constraints that mean delivering an analysis that is not mature enough.
- There is not enough work put into establishing the set of business rules.
- Trying to build the mother of all processes: The more you handle a single process—pushing and pulling it into shape—the more likely the process with fail.
- The process you are trying to develop is very extensive or complex: it involves many stakeholders and requires collaboration with different areas and resources.
- The process needs to serve several purposes within the organization.
No matter the reason, business processes often end up totally or partially abandoned and being substituted with a case-by-case approach because it’s determined that there are too many things beyond our control and the effort to come up with a new and improved business process might not be worth it.
Why You Need to Automate Processes Anyway
Despite the fact that some processes are difficult to develop and deploy, there are many benefits of putting in place a successful business process. For example:
- Your business can operate with more efficiency and control, saving you time and keeping you and your organization sane.
- By defining the process, you may also discover the business rules that govern your organization, and learn that your business is not as unique or complicated as you think.
- The exercise can help you define or redefine those tasks that need to be modified, be created, or change ownership.
- The simple fact of knowing what to expect from a process—once you’ve clearly and assertively measured the results your organization is producing—has the potential to encourage improvement within the organization.
Many more direct and indirect benefits can emerge from establishing a proper set of business processes. By augmenting the manageability and visibility of information, as well as highlighting the accountability of all people involved, you can create the basis for a continuous improvement formula.
How to Stop Doing Things on a Case-by-case Basis and Start Developing Processes that Work
To increase your chances of success, consider the following recommendations:
- Start by agreeing on the core business problem: what is at the root of the drive to automate a process and, most importantly, what is the initial scope.
- Involve all necessary participants so that they can be part of the solution. At the same time you will gain their commitment to the process.
- Define the business rules beforehand. Don’t assume they will appear during the development of the business process.
- Break the problem down into the smallest possible pieces. A process-driven organization normally is able to break processes into its basic functional parts, a core idea of service-oriented architectures (SOA).
- Start with a small core process to address most relevant problem—this will enable the team to agree on more specific problems, speed the development process, and reduce frustration.
- Evolve the process quickly (agile development cycle, etc.).
- Fail quickly—if something doesn’t work, you want to know as soon as possible so you can fix it, or try something else.
- Stop complaining. A lousy attitude won’t fix your process problems. Start proposing solutions and keep trying them until you find one that works.
Finally, I concur with the many experts who say that a business process is never finished. Processes need to evolve to reflect an improved abstraction of the business. I also believe that exceptions will always exist that need to be handled on a case-by-case basis. But there are always ways to reduce its appearance by improving process completeness and building strong exception handling scenarios.