Business process interoperability

Business process interoperability (BPI) is a property referring to the ability of diverse business processes to work together, to so called "inter-operate".^[1] 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.^{[citation needed]}

The objectives of BPI vary, but tend to fall into the following categories:

• Enable end-to-end straight-through processing ("STP") by interconnecting data and procedures trapped in information silos
• Let systems and products work with other systems or products without special effort on the part of the customer
• Increase productivity by automating human labor
• Eliminate redundant business processes and data replications
• Minimize errors inherent in manual processes
• Introduce mainstream enterprise software-as-a-service
• Give top managers a practical means of overseeing processes used to run business operations
• Encourage development of innovative Internet-based business processes
• Place emphasis on business processes rather than on the systems required to operate them
• Strengthen security by eliminating gaps among proprietary software systems
• Improve privacy by giving users complete control over their data
• Enable realtime enterprise scenarios and forecasts

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.^[2][3] 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:

• Tasks that must be performed by people because no practical means of automation is available. Examples include fighting a fire, driving a bus and preparing a meal.
• Tasks that, in the opinion of management, are more effectively performed by people. Examples include answering a telephone call with a human voice and offering investment advice in person.
• Tasks where the cost of automation is greater than the cost of human labor.

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.

• Information silo, the antithesis of BPI

• O. Adam et al. (2005). A Collaboration Framework for Cross-enterprise Business Process Management. Paper First International Conference on Interoperability of Enterprise Software and Applications, INTEROP-ESA'2005.
• Khalid Belhajjame, Marco Brambilla. Ontology-Based Description and Discovery of Business Processes. In Proceedings of the 10th Workshop on Business Process Modeling, Development, and Support (BPMDS) at CAiSE 2009, Amsterdam, June 2009, Springer LNBIP, vol. 29, pp. 85–98.
• Guijarro, L. (2007). "Interoperability frameworks and enterprise architectures in e-government initiatives in Europe and the United States". Government Information Quarterly. 24 (2007): 89–101. CiteSeerX 10.1.1.73.7861. doi:10.1016/j.giq.2006.05.003.
• Kurt Kosanke (2005). "INTEROP-ESA’2005, Summary of Papers"
• Richard A. Martin (2004). "A Standards’ Foundation for Interoperability" Paper 2004 International Conference on Enterprise Integration and Modelling Technology. 9–11 October 2004. University of Toronto, Canada.
• M.P. Papazoglou et al. (2000) "Integrated value chains and their implications from a business and technology standpoint," Decision Support Systems 29 2000 p. 323–342

• Center for E-Commerce Infrastructure Development