Business process interoperability (BPI) is a property referring to the ability of diverse business processes to work together, to so called “inter-operate”. It is a state that exists when a business process can meet a specific objective automatically utilizing essential human labor only. Typically, BPI is present when a process conforms to standards that enable it to achieve its objective regardless of ownership, location, make, version or design of the computer systems used.
The main attraction of BPI is that a business process can start and finish at any point worldwide regardless of the types of hardware and software required to automate it. Because of its capacity to offload human “mind” labor, BPI is considered by many as the final stage in the evolution of business computing. BPI’s twin criteria of specific objective and essential human labor are both subjective.
The objectives of BPI vary, but tend to fall into the following categories:
Business process interoperability is limited to enterprise software systems in which functions are designed to work together, such as a payroll module and a general ledger module that are part of the same program suite, and in controlled software environments that use EDI. Interoperability is also present between incompatible systems where middleware has been applied. In each of these cases, however, the processes seldom meet the test of BPI because they are constrained by information silos and the systems’ inability to freely communicate among each other.
The term “Business process interoperability” (BPI) was coined in the late 1990s, mostly in connection with the value chain in electronic commerce. BPI has been utilized in promotional materials by various companies, and appears as a subject of research at organizations concerned with computer science ontologies.
Despite the attention it has received, business process interoperability has not been applied outside of limited information system environments. A possible reason is that BPI requires universal conformance to standards so that a business process can start and finish at any point worldwide. The standards themselves are fairly straightforward—organizations use a finite set of shared processes to manage most of their operations. Bringing enterprises together to create and adopt the standards is another matter entirely. The world of management systems is, after all, characterized by information silos. Moving away from silos requires organizations to deal with cultural issues such as ownership and sharing of processes and data, competitive forces and security, not to mention the effect of automation on their work forces.
While the timetable or adoption of BPI cannot be predicted, it remains a subject of interest in organizations and think tanks alike.
To test for BPI, an organization analyzes a business process to determine if it can meet its specific objective utilizing essential human labor only.
The specific objective must be clearly defined from start to finish. Start and finish are highly subjective, however. In one organization, a process may start when a customer orders a product and finish when the product is delivered to the customer. In another organization, the same process may be preceded with product manufacture and distribution, and may be followed by management of after-sale warranty and repairs.
Essential human labor includes:
To qualify for BPI, every process task must be taken into account from start to finish, including the labor that falls between the cracks created by incompatible software applications, such as gathering data from one system and re-inputting it in another, and preparing reports that include data from disparate systems. The process must flow uninterrupted regardless of the underlying computerized systems used. If non-essential human labor exists at any point, the process fails the test of BPI.
To assure that business processes can meet their specific objectives automatically utilizing essential human labor only, BPI takes a “service-oriented architecture“ (SOA) approach, which focuses on the processes rather than on the technologies required to automate them. A widely used SOA is an effective way to address the problems caused by any disparate system that is the heart of each information silo.
SOA makes practical sense because organizations cannot be expected to replace or modify their current enterprise software to achieve BPI, regardless of the benefits involved. Many workers’ jobs are built around the applications they use, and most organizations have sizable investments in their current information infrastructures which are so complex that even the smallest modification can be very costly, time-consuming and disruptive. Even if software makers were to unite and conform their products to a single set of standards, the problem would not be solved. Besides software from well-known manufacturers, organizations use a great many legacy software systems, custom applications, manual procedures and paper forms. Without SOA, streamlining such a huge number of disparate internal processes so that they interoperate across the entire global enterprise spectrum is simply out of the question.
To create an SOA for widespread use, BPI relies on a centralized database repository containing shared data and procedures common to applications in every industry and geographical area. In essence, the repository serves as a top application layer, enabling organizations to export their data to its distributed database and obtain the programs they need by simply logging on via a portal. To assure security and commercial neutrality, the repository conforms to standards promulgated by the community of BPI stakeholders.
Organizations and interest groups that wish to achieve business process interoperability begin by establishing one or more BPI initiatives.