The packaged applications market has remained unchanged for more than 30 years. Yes, some of the trimmings have changed — the programming languages the packages have been written in have changed and standard interfaces and middleware has been added. Some vendors have even started modularizing their code. But the fact remains that a packaged application is designed to follow a specific process and implement business practices in a prescribed way. During the height of the business process reengineering craze of the 1990s, management was under such pressure to restructure their businesses that they implemented SAP R/3 en masse. Overlooking the rigid nature of this ERP system, companies found that they were ready to sacrifice flexibility for a set of well defined business processes. The desperate plea of business management that forced IT to implement a relatively rigid platform based on a set of predefined business processes became the norm.
Fast forward a decade and the tone has changed dramatically. The rigidity of that model has caught up with business and provoked a revolution that goes by the name of service oriented architecture (SOA). In the first few years that SOA was evolving, the focus was on middleware and infrastructure, but the focus is moving to business process, modular business services, and best practices. There is a problem, however. While the infrastructure components must by their very nature be highly structured, the business processes that reside on top of them must have the opposite characteristics. Business process software must be incredibly flexible and agile – after all, we are dealing with human communities that lack the precision that is characteristic of machine to machine communications.
The top down process management dilemma
Let me start by stating that the great failure of packaged software is that it assumes you can implement a rigid process model that handles every business process with precision. This is simply not the case. Let’s take a quick step back and pinpoint the problem. Typically a business process approach starts at the top of the organization. Management decides how a certain business process should be orchestrated; i.e. how do we process a transaction, a loan, or process and ship an order. Now, if the company has a very simple process – it sells three products to a very specific set of customers on a very regular schedule with no shades of gray, there’s no problem. Of course this is silly since there are not many companies that look like that (and are still in business). However, the way top management often describes the workflow may resemble this. The problem is that top management is not involved at the detailed level that middle management and staff members are immersed in. Yes, they accurately describe the correct process but without the nuances that employees working with real customers have to deal with. The typical ERP system requires extensive staff training – not on how to program – but how to use a system. Again, in some situations this is a perfectly acceptable situation: a staff has a consistent process to follow with little variation, so the training time and expense is worthwhile. For example, a telemarketing staff selling a small set of products with a relatively few exceptions is a perfect use of process management built into an ERP system.
Machine-to-machine processes and the human factor
This type of rigid process approach also works well if there are machine to machine processes. For example, whenever someone executes a transaction, inventory levels are changed to reflect the purchase. Organizations actually need these machine to machine processes to be controlled at a granular level because they must be exact in order to maintain governance policies.
But most companies do not have simple, rigid business processes. Typical businesses also do not rely on machine to machine processes for a majority of their business practices. Increasingly, in the real world, innovation and flexibility dictates that processes are full of exceptions and changes dictated by changing customer preferences and new business models.
For example, if a company decides to create a new approach to bring a product to market based on collaboration with complementary partners, the business process will change. Will it be necessary to train hundreds of sales reps to learn a very complicated top down process implemented in a complicated and rigid ERP system? Perhaps — if these sales reps are going to use this system on a regular basis. However, if the project has a short time frame, a massive training initiative will be a waste of money. Likewise, a network of partners, suppliers and customers all want flexible access to a process driven system, that system must be intuitive and flexible.
One of the most popular approaches being bandied about these days is process models based on best practices. The same problems that we are seeing with the type of processes companies have been using within an SAP application can be true with best practice models, simply put, they can enforce a business model that is too rigid in the presence of business change.
The bottom line
While it might be nice to think that we can simply programmatically establish what our businesses will be and how they will be orchestrated – and be done with it, it is the wrong approach. Even models based on the concept of a best practice have some limitations since one company’s best practice is another’s nightmare. Does that mean we need to abandon top down business process models and start coding like mad? Of course not. Does that mean that best practice models are flawed? Not necessarily. But it does mean that rigid models that are designed the old fashion way and are not based on a service oriented process orchestration approach are not going to work any more.