Outside SAP

By | June 28, 2006

On a recent sales trip in the U.S., a business manager of a large chemical company introduced me to a useful, new four-letter acronym. His company is a major SAP user and was in the midst of upgrading to the latest version of SAP and NetWeaver. Consequently, the business manager was well aware of the business process capabilities of NetWeaver. I started to explain the difference in the types of processes that pure-play BPM systems are adept at handling versus those that are best done within SAP.

However, he did not need my elucidation. Based on the SAP experience, the company already had a well-developed understanding of the hierarchy of processes in an organization. To facilitate discussions inside the company, they had developed the term “OSAP,” or “Outside SAP,” to describe the myriad of processes and applications that are best handled outside of SAP. That is how OSAP entered my vocabulary. What is true for SAP is also true for other ERP systems and enterprise applications, such as CRM, EDMS, financials, etc. They all have their OSAP counterparts.

This company was an experienced user of SAP. They knew what is possible inside SAP and what is best done outside. In contrast, over the past decade I have encountered numerous prospects that are of the opinion that they do not need BPM systems because they have, or are planning to deploy an ERP, CRM, or EDMS application with embedded process capabilities.

Helped by aggressive vendor marketing, they are convinced that the capabilities in enterprise applications are sufficient for all their process needs. Companies in the midst of large SAP deployments commonly hold this opinion. The same is true for users of other applications such as PeopleSoft, Documentum, Oracle Financials, etc. As BPM gains traction, and the major software vendors enter the fray to claim a bigger pie of the mindshare and the market by making more noise, the perception is likely to increase. The attraction to one monolithic application for handling all the process requirements is also appealing to customers from a cost and utility point-of-view.

Companies prefer to use software from one vendor and pay for one maintenance and support contract. They also prefer to have their employees trained on one application. Therefore, if one monolithic application can provide BPM along with some other important functionality such as ERP, it is naturally perceived as a significant benefit to the company.

This discussion made me think about the OSAP message that one monolithic application cannot handle all processes. How can this be explained to prospects attracted to monolithic, do-all applications? It seems to me that the answer lies in the ubiquity of hierarchies. Hierarchies are common in most everything we make. Take the transportation ecosystem, for example. Its basic function is to carry people and goods from one point to another. One would assume that one type of transportation system should be able to handle all the transportation needs of an organization.

However, in reality, transportation systems have a hierarchy. At the top of the hierarchy are airplanes, trains, and ships capable of moving a large number of people from one point to another.

These large systems are not flexible in terms of the end-points, and are also expensive to purchase and use. In the middle of the transportation hierarchy are trucks and buses, followed by cars and vans, and with a whole number of transportation systems such as motorbikes, forklifts, and bicycle making up the base of the hierarchy. As one goes down the hierarchy, the flexibility of the end-points increases, and the operating cost goes down, but the carrying capacity also decreases. An organization uses all these transportation systems, depending on its needs.

Furthermore, each transportation system is dependent on the others in the ecosystem to sustain it. They cannot function in isolation. I can travel long distances at high speeds in a modern aircraft, but when I reach the destination I still need a good car to take me to my final destination. As one moves down the transportation hierarchy, the transportation system become more personalized, with increasing ability to cater to individual needs.

Like transportation, every other ecosystem developed by humans has hierarchies – education, communications, computers, healthcare, armies, roads, etc. The reason for these hierarchies is economics and utility. One type of system cannot be used economically to handle all possible requirements. Neither can one system provide the utility needed for the myriad of uses. Each system in the hierarchy depends on others to sustain it. All these systems have evolved over a long period of time. Darwin’s theory of natural selection has played its hand in their evolution to the current state. Systems and uses that have proven economical have survived, and the rest have perished.

Business processes are no different than other human systems. They too have to live in an ecosystem of processes with hierarchies. This is because modern organizations have different types of processes with different requirements. These processes are interdependent and support each other. Broadly speaking, the business processes hierarchy in every organization consists of three categories:

1. At the top of the hierarchy are a collection of processes for specialized, high-value functions. These processes are typically centered on ERP and financial applications. They tend to be complex but do not change as often. These processes tend to be “impersonal.” In many cases they are industry or functional specific and are embedded in enterprise application. The cost of customization of these processes is too high. To reduce cost, these processes are provided as pre-built templates in enterprise applications such as SAP or Oracle Financials. They tend to be unique within an industry or a function. Examples of these processes include manufacturing order processing, financial reconciliations, inventory management, etc.

2. In the middle of the process hierarchy are a large number of processes across functions that have a fairly complex structure but change frequently due to changing business conditions. These processes cut across departments and applications and can best be described as knowledge worker processes. These processes fill the gaps between departments, applications, customers, partners, vendors, and employees. Each company has its own mix of applications, services, and business practices. Therefore, these processes tend to be unique to each company. Examples of these processes include price quotations, order validation, capital approvals, and performance reviews, etc.

3. At the bottom of the hierarchy are a myriad of small, “ad hoc” processes that are highly personalized to the extent that each instance is unique. These processes have very little pre-defined structure. They are unique to each individual, and in many cases to each task that an individual performs. Examples of these processes include routing a document for review via email, reporting the status of a project, compiling weekly activity summaries, etc.

It is very difficult for one BPM system to handle all three categories of processes. Combining the ability to handle all types of business processes while at the same time handling the complexities of ERP, EDMS, or financial applications makes it well- nigh impossible in scope as well as complexity. That is why organizations need a hierarchy of BPM systems. At every level of the hierarchy, the BPM system is optimized to provide the best economics as well as the greatest utility. Like the transportation system, BPM systems are coupled and interact with each other to make a process ecosystem.

For the first category of business processes, the systems of choice are enterprise applications such as ERP and CRM. These are the “Inside SAP,” or ISAP processes. The reason why they exist within the enterprise application is that the functions they perform and the information they process exists almost entirely within the host enterprise application. Business process management for this category of processes is therefore necessary inside the enterprise application, and the latter will be incomplete without it. However, these processes have a fewer users. They do not need to be highly agile since the processes do not change as rapidly. Finally, their cost can be high since the value of each transaction and the complexity of handling it is generally high. To reduce the cost, vendors tend to provide templates that can be tailored to the requirements of each company. In many cases, companies learn to adjust their work patterns to that of the template process rather than incur the cost of customization.

The second category of processes is the OSAP category. These are processes that live outside enterprise applications. They tend to change faster than the ISAP processes, yet they have a well-defined structure and logic that is generally applicable across an organization. They tend to be organization specific so that they can cater to the unique business practices and applications of the company. OSAP processes are excellent candidates for pure-play BPM systems. The cost of implementing them inside enterprise applications would be prohibitive.

The third-category is ad-hoc processes that are “mass personalized.” They have very little structure, and every instance is different. These are processes that people use individually in their daily collaboration with others using paper or e-mail to route documents or other means of ad hoc collaboration. In most cases, these processes will never be managed. If some of them become repetitive and frequent, they may become candidates for the OSAP category.

While I have described three categories of business processes, they are not independent of each other. A ship moves goods to a port. The truck moves goods from the port to the factory load bay. The forklift moves the goods from the cargo to the production line in the factory. Likewise, business processes interact with others inside and outside the organization. ISAP processes trigger OSAP processes that involve making decisions and resolving exceptions and special cases. OSAP processes are used to support ISAP processes or to leverage them to handle complex back-office transactions. Ad hoc processes are used by individuals to handle sub-tasks within OSAP process activities, or to handle tasks for which OSAP processes are not efficient.

Enterprise applications like SAP provide significant business value and perform critical functions inside an organization. However, they cannot be expected to do everything, just as a multi-million dollar modern airplane cannot be expected to drop you off at your home as if it were a car.

Leave a Reply