Implementing a Multi-Enterprise Collaborative DSS

Farzad Shafiei, David Sundaram

Information Systems & Operations Management

University of Auckland

Private Bag 92019, Auckland, New Zealand

fshafiei@emptoris.com, d.sundaram@auckland.ac.nz

Selwyn Piramuthu

Information Systems and Operations Management

University of Florida

Gainesville, Florida 32611-7169, USA

selwyn@ufl.edu

Abstract—The increasing level of collaboration among firms

has necessitated the emergence of decision support tools that

span firm boundaries. This essentially translates to decision

support systems that seamlessly communicate and operate with

disparate system characteristics. We propose and develop a

multi-enterprise collaborative decision support system that

aids in this process.

Keywords-collaboration, decision support, multi-enterprise,

services

I. INTRODUCTION

Organizations and their decision making processes are increasingly becoming multi-enterprise collaborative (MEC) in nature. However, a majority of academic and commercial research, frameworks, architectures, and systems are focused towards the transaction processing aspect of multi-enterprise collaboration. More recently, vendors including Microsoft, SAP and Oracle have introduced tools and systems that support the decision support side of MEC. The shift of marketplace applications and academic research towards this area of research is still at its early stages and perspectives and insights are continually being gained as new applications and implementations are rolled out.

Decision makers within organizations and across supply networks need the ability to utilize decision making components (e.g., data, models, solvers and data and process visualizations) to integrate business needs with appropriate technological environments. This is critical in dynamic environments where disparate organizational systems and personnel interact in decision-making processes. Research and implementations need to address decision support dimensions to support multi-enterprise collaborative decision making and support. These include heterogeneity in terms of breadth and depth of data, complexity in terms of models, solvers and data/ process visualizations, distribution with regards to reach and range, versatility of domains and paradigms, flexibility, reusability and extensibility.

Although recent research has generated contributions in terms of framework, architecture, and implementation, there are still areas where gaps remain. These include the following: (a) Domain and paradigm versatility dimensions are not addressed well by most systems, and any of the systems are platform-dependent, (b) Both adaptive and adaptable personalization is not within the scope of a majority of systems, as they have placed more emphasis on other system dimensions, (c) Systems lack the ability to

provide true flexibility with regards to the integration of decision making components, (d) Reusability of decision making components in order to reduce the need for expert knowledge is also limited, (e) Heterogeneity of data with respect to not only being able to connect to any ERP system but also any other system/database is not as flexible and open as it should be. Vendor applications are often in competition and do not build open systems that allow for seamless integration and collaboration, (f) There is a limitation in terms of the type of communication standards/ protocols that are employed to connect to other tools/ systems/applications that reside on different platforms in other organizations across supply networks.

Based on these identified problems and issues, the following requirements can be drawn: (a) A multi-enterprise collaborative decision making and support model that captures the essence (at a macro level) of how entities interact and collaborate in terms of decision making and support. This model needs to account for key decision support dimensions such as versatility, flexibility, and distribution, (b) A generic process that encapsulates multi-enterprise collaboration throughout a lifecycle of decision making opportunities in order to assist organizational decision maker‟s right across supply networks to apply any business problem or requirements, (c) Enable flexible mapping between decision support components to support ad-hoc multi-enterprise integration, (d) Reusability of decision-making components to reduce the need for expert knowledge, (e) Accommodate heterogeneity of data in terms of being able to connect to all forms of ERP systems and any other system/database, (f) Consider domain and paradigm versatility, extensibility, reach and range distribution, as well as complexity in open and flexible frameworks and architectures.

Current commercial tools that address some of these requirements and are in line with our study are SAP‟s NetWeaver [1], and Oracle‟s BPEL Process Manager. Based on the requirements specified above, we chose to implement the system using Oracle BPEL Process Manager.

To this end, this paper contributes the following to the selected area of research:

1. Identification and synthesis of problems and issues with regards to decision making and support in the area of multi-enterprise collaboration.

2. Identification of the requirements for the design of an open and flexible system that overcomes the identified problems and issues.

3. Proposal of an open and flexible multi-enterprise collaborative decision making and support model and lifecycle process. The lifecycle process should guide decision makers from the identification of problems right through implementation of the resulting system.

4. Design and implementation of a domain-independent multi-enterprise collaborative decision support conceptual and system framework, and architecture that overcome the problems identified in (1); fulfill the requirements for an open and flexible multi-enterprise collaborative system identified in (2); and support the multi-enterprise collaborative decision support model and lifecycle proposed in (3).

II. MEC ARCHITECTURE

More and more, companies are looking at Service Oriented Architectures (SOA) and their accompanying interfaces as an architectural blueprint and set of standards for addressing the integration requirements involved in creating multi-enterprise collaborative applications. The Business Process Execution Language (BPEL) for Web Services has become the cornerstone of SOAs. This addresses common application requirements within and across organizations in an open, flexible, and standard manner. SOAs enable businesses to maximize leveraging their existing resources while minimizing the rolling out of new applications. To make SOAs work, Web Services needs to work as well. The Web Services Model proposed by Gottschalk [2] clarifies this model.

Figure 1. Publish, find, and bind [2].

Figure 1 illustrates this model, which has the following roles; the „Service Provider‟, the „Service Broker‟, and the „Service Requestor‟ which represent SOAs components. These roles perform three fundamental operations: „Publish‟, „Find‟, and „Bind‟. Service providers publish services to a service broker. The service requestors find the services they require using a service broker and bind to them. We apply these Web Service concepts to the implementation of a multi-enterprise collaborative DSS.

III. IMPLEMENTATION ENVIRONMENT

A. Implementation Domain

We consider a Supply Chain Management scenario to the implementation of the MECDSS. Specifically within this domain, a supplier selection scenario is implemented using the implementation platform.

B. Implementation Platform

Of the implementation platforms available, the one chosen is the Oracle Business Process Execution Language (BPEL) Process Manager. The reason for this is that this tool is not only decision-support oriented, but also focuses primarily on MEC via a commonly used standard called Web Services. This platform fits well with decision support in the context of MEC. Within this implementation platform, Microsoft VB .NET is applied to code the Web Services part, and Oracle JDeveloper version 10g is used to design the model diagram and code the model source in XML.

IV. MEC DECISION MAKING &SUPPORT MODEL

We present a MECDSS conceptual framework that represents a high-level look at how the integration of ERP systems and DSSs can help set the foundation for multi-enterprise collaboration and decision support. This MECDSS conceptual framework (Figure 2) consists of a supply network which builds on the ideas proposed in the MEC Decision Support Model but adds a high level system/technology side to it.

Figure 2. The MECDSS conceptual framework

The internal environment (which may be the decision making initiator), may have a MECDSS that sits on top of, and accesses its ERP system and other databases/systems via Integration Technologies such as Application Link Enabling (ALE) for example. Any entity/organization can at any time be represented by the “Internal Environment” and collaborating with its supplier-facing or customer-facing partners. Decision makers access the MECDSS in their organization in order to manipulate the decision components they request from other entities within their supply network or create themselves. Drawing from the Intelligence Density

concepts of Dhar & Stein [3], decision makers from within the internal enterprise environment, as well as across the supply network, are provided with data access, scrubbing, integration, transformation, discovery, and knowledge gaining capabilities via connectivity technology. This provides firms with the opportunity to maximize their Intelligence Density, and lays the foundation for achieving Multi-Enterprise Collaboration and better decision support for all parties across the supply network.

V. THE MECDSS SYSTEM FRAMEWORK

If we now take the conceptual framework illustrated in the previous sub-section, and bring it another level lower in terms of abstraction, we can present the MECDSS system framework. Figure 3 illustrates the system mechanics behind the integration of the MECDSS with other tools, applications, technologies and systems within the boundaries of the enterprise as well as in a multi-enterprise collaborative fashion using connectivity technology. Looking at the levels of technology within the enterprise, we see that there are many possible combinations of integration. This is not only between the MECDSS and other tools, applications, technologies and systems, but also the connections of the various tools, applications, technologies and systems with themselves. Though the system framework resembles an infrastructure similar to that of a large firm, many small and medium-sized firms are also part of our framework.

Figure 3. The MECDSS system framework

Decision makers from within the organization access the MECDSS and other proprietary DSS applications via Presentation Interfaces. Through the MECDSS and these proprietary DSSs, decision makers may want to access and map a pool of decision support components such as data, solvers, models, and visualizations. These decision components are gathered from internal databases, transactional systems, and/or data warehouses that may exist in the enterprise. Each of these layers (databases, transactional systems, and data warehouse are in turn connected with each other via integration technologies and various database connectivity types. The openness of the

framework also allows decision makers to choose to access these lower level layers directly by accessing proprietary DSSs. In order for the firm to collaborate with members of its supply network, it needs to connect beyond its organizational boundaries [4] to other entities via connectivity technologies and standards. Similarly, external decision makers access their own tools, technologies, applications, and systems via their internal presentation interfaces, and collaborate via connectivity technologies and standards.

VI. DESIGN OF THE MECDSS ARCHITECTURE

Aside from an implementation of a system, one of the lowest levels of abstraction that can be presented when discussing Information Systems is an architectural diagram. In this section we present the MECDSS architecture (Figure 4) and discuss each of its component parts that combine to make it work.

The database layer sets the platform for the collection and maintenance of the raw data received by the firm. Typically, an enterprise (depending on its size) will have a number of databases that are responsible for collecting and maintaining different forms of data. For example in a large firm, a CRM system database may deal strictly with the customer-facing data, a SCM system database may handle the supplier-facing data, and an ERP system may handle the general business transaction data. The platforms used by these databases may vary in the firm. For example, the ERP system database may be running under a Microsoft SQL Server environment, while the CRM and SCM databases work under the Oracle database environment. Finally, there may be instances where some small to medium sized firms are yet to incorporate transactional systems or data warehouses. In these cases, the database layer has the flexibility of connecting with proprietary DSSs already in place.

Figure 4. The MECDSS Architecture

The transactional systems layer resides on top of these databases and integrates via a database (DB) connection type. DB connection types may include Object Linking and Embedding (OLE) DB which is Microsoft‟s Application

Programming Interface (API) that provides SQL data and non-SQL data access, Java Database Connectivity (JDBC) which is an API specification for connecting programs written in Java to the data in common databases, ActiveX Data Objects (ADO) .NET which provides a data access model for

.NET that is both familiar to the users of ADO and addresses .NET with new objects like the ADO.NET Dataset, and Open Database Connectivity (ODBC) which is an open-standard API for accessing common databases. A firm that has CRM, SCM, and ERP system databases will typically have CRM, SCM, and ERP transactional systems. These systems interact, integrate, and to a certain extent analyze the data in these databases. For example, when a user posts a production order through an ERP system, the system feeds this transactional data into the ERP system database. The database then simultaneously and automatically updates the relevant functional units. It is also worthwhile mentioning that firms have come to realize that these transactional systems by themselves do not provide them with the information processing and decision support capabilities they need. As a result, firms have the opportunity to integrate their transactional systems with proprietary DSSs that provide their decision makers with comprehensive analytical and decision support capabilities.

Each of these transactional systems may have their own data warehouse, illustrated on the data warehouses layer that connects via integration technologies such as ALE which provides the basis for the integration and networked synchronization of business processes and applications across systems [5]. These data warehouses provide yet another information processing option for the firm, as they are able to extract data from their respective transactional systems and provide decision makers with more relevant, accurate, and multi-faceted analytical information. These data warehouses also have the capability to connect with proprietary DSSs through an integration technology such as OLE DB for Online Analytical Processing which is a set of objects and interfaces that build on OLE DB to provide access to multidimensional data stores, thereby providing specific analytical capabilities. For example, there may be proprietary DSSs, like an Executive Information System, for the strategic decision makers of the firm. Integrating these applications with a data warehouse provides strategic decision makers with analytical capabilities more suited to their role. This is in comparison to the uniform analytical capabilities a data warehouse may provide.

The DSS component pool and mapping layer and the DSS application layer (which includes the MECDSS), are shown as separate layers in the architecture. However, we may consider these as a set of technological layers that are dependent on one another for a number of reasons.

First, the DSS component pool acts as a library that collects and stores the decision components (i.e. data, visualizations, models, solvers) needed to present decision makers with what they request to manipulate via the MECDSS. Data components typically have a direct connection to a database in the database layer via a number of DB connection types depending on the platform used for

development. This may include a JDBC, ADO .NET, OLE DB, and/or ODBC connection type as mentioned and defined earlier. The data components connect to the databases and collect the objects that the decision maker may specify via the MECDSS. A model illustrates the structure of a real-life problem. A model is the central component that sets the structure for the interactions between itself and all the other components. Solvers take these models and treat them as their inputs, from which they perform transformational analysis, and return the necessary output but in a non-graphical manner. Visualizations are similar to solvers in that they return an output requested by the decision maker but instead of only returning an output in text or numerical format, these components presents the output in a visual format. The Decision Support Component Pool Layer includes the Mapping of the components with each other through proxies such as the WSDL for Web Services. A proxy is an object that acts on behalf of another object. The inclusion of mapping via proxies in our DSS component and proxy pool enables more transparency in terms of the mechanics of the MECDSS from the perspective of the decision maker. This is because the decision maker can view and manipulate components without needing to refer to the database, transactional system, or data warehouse layers, where the real components may be residing. This helps to reduce the time that it takes to perform routine component request operations, such as requesting the display of a simple graph because the proxies can act on behalf of the real data, solver, model, and visualization components. In addition, the architecture has been designed so that it allows the DSS component pool & mapping layer to collect its components and proxies from a variety of sources.

Second, without the DSS component pool mapping layer, these components and mapping proxies would not be able to communicate with each other. In addition, they would not be able to validate the request of the decision maker via the MECDSS.

The location of the MECDSS is in the design of the architecture is in terms of the internal environment of the enterprise, is the DSS Application layer. This layer is dependent on the operations performed by the DSS component pool and mapping layer. The requests of decision makers (either via the Internet or Intranet technologies and applications) move through the MECDSS and feed into these other layers via Implementation Platforms such as Microsoft .NET and Java. The MECDSS provides decision makers with several important capabilities. This includes the opportunity to create or select models that best represents the problem at hand, instantiate these models with dates, execute them with solvers, and visualize the results using various visualization formats. This type of flexibility means that decision makers are able to make more effective business decisions for their firms. This is because the information presents itself in a manner that they can clearly understand, thus increasing the possibility of increasing the Intelligence Density of their firms. In addition, the MECDSS may also integrate with proprietary DSSs in order to provide decision makers with more specific or customized decision support capabilities via integration technologies such as ALE.

With a discussion of how the architecture works within the internal environment of an enterprise, we describe how the organization can use MECDSSs and other tools, technologies, and systems to integrate beyond its organizational boundaries.

To accommodate all forms of connectivity among organizations throughout supply networks, the architecture needs to provide an open and flexible style that not only accommodates Web Service connectivity technology standards such as SOAP and WSDL, but also more traditional technologies such as CORBA, DCOM etc.

VII. MECDSS ARCHITECTURE IMPLEMENTATION

We chose to demonstrate our concepts in a Supply Chain Management (SCM) environment since it neatly touches a number of points across the supply network and truly illustrates the power of multi-enterprise collaborative decision making and support.

A. Implementation Scenario - Supplier Selection

This scenario demonstrates a typical business problem that commercial managers have to address in SCM. For a specific purchasing category, the idea is to select the „best value‟ supplier among a number of candidates willing to offer products and services in that category.

MECDSS supports managers to obtain appropriate decision components from other decision makers or parties with vested interest across the supply network.

We consider 3 suppliers who compete to be the exclusive supplier for Organization ABC in the Information Technology (IT) category. This category includes office IT computer hardware, software, peripherals, services and network maintenance. John, the commercial manager in ABC in charge of the IT purchasing category, needs to compare these 3 suppliers with respect to two areas - in terms of the cost in the respective parts of their suite, and the rating that are given by entities in the supply network that ABC knows and trusts.

John knows that to obtain an overall „suppler value‟ score for the suppliers in question, several components are needed. First, he needs the „Industry Standard Weightings‟ with regards to cost for the suite offered by the suppliers. He knows that this standard can be obtained from the Governing Body within the IT industry. Second, John requires data components from each of the suppliers providing him with the necessary details of the costs for their respective tangible (hardware, software, and peripherals) and intangible (services and network maintenance) packages. Third, he needs the rating data from the partner and customer of his organization that have used and/or are using one of the suppliers for the same purchasing category in their organization. Fourth, he requires a component to apply the weightings given by the industry to the tangible and intangible package costs. Finally, he needs a minimize/maximize solver component to calculate the „best value‟ supplier based on minimizing cost while maximizing quality. With all this information at his fingertips, he can apply the numbers to the model created within Oracle BPEL Process Manager by the organization‟s developers, so that

the MECDSS can calculate the „best value supplier‟ and present that supplier as the recommended option for John through a visualization component in the Oracle BPEL Console. He is then able to take this recommended option by MECDSS, discuss it with his colleagues, apply his own commercial judgment, and make a final decision on the supplier. Table I presents a summary of the suppliers and their offer along with the „ratings‟ from ABC‟s partner and customer.

TABLE I. EXAMPLE SCENARIO

We now take this SCM scenario with its details in Table

1 and illustrate it through a sample session.

B. Sample Session Applying Scenario

We begin by presenting the overall model we have created for this Supplier Selection scenario. Figure 5 illustrates this model, showing the steps that the implementation goes through right from the scenario being initiated through the Oracle BPEL Console, through to the system providing John with a „best value supplier‟ recommendation.

With an idea of the overall scenario implementation in place, we can describe each major part of the model in more detail. Three of these four parts need expansion beyond what is shown in Figure 5, and are thus labeled, 1, 2, and 3. The final part labeled 4 does not require expansion like the others. This labeling is done to provide the reader with some traceability between each of the four major parts of the overall scenario implementation and the figures and detailed description that follow for each part.

We begin by illustrating and discussing the “Industry Standard Weightings” flow of the model, which is applied once the scenario is initiated by the decision maker. Figure 6 expands this part of the model and shows the sequences that are captured. The first sequence on the left is the “Industry Intangible Cost Weighting” which connects via a Web Service to the IT Industry Governing Body in charge of holding standards and policies within their supply network. This sequence obtains the first part of a data component which holds the value „55%‟. This value represents the current weighting of the industry with respect to Intangible Costs such as those in the IT Services and Network Maintenance package being offered by the 3 suppliers. The second sequence on the right is the “Industry Tangible Cost Weighting” which again connects via a Web Service to the IT Industry Governing Body and obtains the second part of

the data component which holds the value „45%‟. This value represents the current weighting of the industry with respect to Tangible Costs such as those in Hardware, Software and Peripherals package being offered by the 3 suppliers. With this data now captured and input into the “Industry Standard Weightings” flow of the model, the next part of the model is an “assign” activity which is a system generated number of 365 days. This activity has been added to the overall model because the Intangible Cost values provided by each of the suppliers is a per day cost. Hence, we need a method in the system to take each of these per day Intangible Costs given by the suppliers, and multiply it by 365 days for the annual cost matching the „annual‟ cost unit for the tangible cost, in the next flow of the model.

Figure 5. Supplier selection scenario implementation

The next flow of the model takes care of bringing together the Total Costs of the Tangible and Intangible Packages provided by the suppliers in question. Figure 7 expands this, and shows the three sequences that are captured within it.

The first sequence on the left is the “Supplier X Total Package Cost” which connects via a Web Service to Supplier X in the supply network. This sequence obtains 2 items of information within the same data component from Supplier X. The first half of this sequence obtains and holds the Total Tangible Package Cost from Supplier X which is already an annual unit cost. The second half then obtains and holds the

Total Intangible Package Cost from Supplier X which is in a per day unit format. The system generated assign activity discussed earlier is applied here, which multiples this Total Cost by 365 in order to create an annual cost for the Intangible Package.

Figure 6. Expanding industry standard weighting flow

Figure 7. Total cost of supplier packages flow

The second sequence in the middle is the “Supplier Z Total Package Cost” which connects via a Web Service to Supplier Z. This sequence obtains 2 items of information within the same data component from Supplier Z. The first

half of this sequence obtains and holds the Total Tangible Package Cost from Supplier Z which is already an annual unit cost. The second half then obtains and holds the Total Intangible Package Cost from Supplier Z which is in a per day unit format. The system generated assign activity discussed earlier is again applied here, which multiples this Total Cost by 365 in order to create an annual cost for the Intangible Package.

Figure 8. Quality ratings for supplier Z flow of scenario

The third and final sequence of this flow on the right hand side is the “Supplier Y Total Package Cost” which connects via a Web Service to Supplier Y in the supply network. As with the other sequences within this flow, two items of information are gathered within the same data component from this supplier. The first half of this sequence obtains and holds the Total Tangible Package Cost from Supplier Y which is already an annual unit cost. The second half then obtains and holds the Total Intangible Package Cost from Supplier Y which is in a per day unit format. The system generated assign activity discussed earlier is applied here, which multiples this Total Cost by 365 to create an annual cost for the Intangible Package. The next flow in the implemented scenario is concerned with collating the necessary information with respect to the „quality ratings‟ provided by a well known and trusted „partner‟ of ABC, and a highly „regarded customer‟, that have both used, or is currently using these suppliers. These are named Partner A

and Customer A, respectively. This final flow consists of three sequences which in turn have internal flows.

The first sequence on the left is the “Supplier Z Quality Rating”. This sequence consists of a flow which connects to Partner A and Customer A in the supply network. This flow obtains two items of data in a parallel manner from each of these partner links via invoke methods. The first invoke method on the left (SupplierZ_PartnerA_Rating) is responsible for getting the quality rating (score out of 100) from Partner A for Supplier Z. The second invoke method on the right (SupplierZ_CustomerA_Rating) is responsible for obtaining the quality rating (score out of 100) from Customer A for Supplier Z. This process is expanded and illustrated in Figure 8.

The second sequence in the middle is the “Supplier Y Quality Rating”. This sequence consists of a flow which also connects to Partner A and Customer A in the supply network. This flow obtains 2 items of data in a parallel manner from each of these partner links via invoke methods. The first invoke method on the left (SupplierY_PartnerA_Rating) is responsible for getting the quality rating (score out of 100) from Partner A for Supplier Y. The second invoke method on the right (SupplierY_CustomerA_Rating) is responsible for obtaining the quality rating (score out of 100) from Customer A for Supplier Y. This process is expanded and illustrated in Figure 9.

Figure 9. Figure 9: Quality ratings for supplier Y flow

The third sequence on the right is the “Supplier X Quality Rating”. This sequence consists of a flow which again connects to Partner A and Customer A in the supply network. Similar to the other flows, two items of data in a parallel manner are obtained from each of these partner links via invoke methods. The first invoke method (SupplierX_PartnerA_Rating) on the left is responsible for getting the quality rating (score out of a 100) from Partner A for Supplier X. The second invoke method (SupplierX_CustomerA_Rating) on the right is responsible for obtaining the quality rating (score out of 100) from Customer A for Supplier X. This is expanded and illustrated in Figure 10.

With each flow of the implementation scenario discussed and illustrated, we can present the final part of the scenario, namely, the „Calculate Best Value Supplier‟ and „Provide Recommendation‟ invoke methods. This final part is shown in Figure 11.

The „Calculate Best Value Supplier‟ invoke method starts this last part of the model by accessing a minimize/maximize solver via a Web Service. This solver serves the purpose of minimizing the Total Intangible and Tangible Package Costs of each supplier, while considering maximizing the quality ratings provided earlier. The final part of the entire implementation scenario model is the MECDSS providing a recommendation to the decision maker(s), once the result of the solver is obtained from the previous invoke method and assigned through to this final invoke method.

Figure 10. Figure 10: Quality ratings for supplier X flow

Figure 11. Figure 11: The final part of the supplier selection scenario

implementation

Supplier X is recommended based on the solver‟s calculation when the decision maker clicks the “Provide Recommendation” invoke method (Fig. 12). John, the decision making process initiator, can take this result which gives him the best option to choose, and consider which supplier to give the exclusive contract to for ABC‟s IT Category. He may make the decision based solely on the recommendation of MECDSS or consider it further based on his judgment and that of his colleagues within the organization.

Figure 12. The visualization provided to the decision maker via the Oracle

BPEL Console

C. Implementation of the MECDSS Components

Model: The first component is the model element of the XML source code that sits behind the diagram view illustrated earlier. This is shown in Table II, where the specific parts of the code relating to the model parameters are highlighted. The variables that have been highlighted are those that were created within the system in order to act as a placeholder for meaningful data, and to a high degree reflect the required parameters of the overall scenario model, which includes the Supplier Tangible and Intangible Package Costs, as well as the Quality Ratings.

Data: The next decision component is the data component. The sample XML code presented in Table III highlights the specific areas where data components are created. There are two types of data components created here. The first is represented by a single highlighted line, and

the second a set of highlighted lines. The single line highlighted sections are inputs provided by the BPEL project consisting of the index “1” which has been coded into the BPEL project file. Despite the fact that they are indexes coded directly into the system, they are still data sources that select the product ID “1” and service ID “1”.

TABLE II. THE XML SOURCE CODE AND ITS MODEL COMPONENT

ELEMENTS

The coding of this ID directly into the system in this instance was done primarily to add variety and transparency for demonstration purposes. This is because the set of highlighted sections are not system generated but rather direct data sources. These sets of highlighted sections are Web Service components which provide outputs (and are taken as inputs by the Supplier Selection BPEL workflow). These Web Services do not take any inputs nor do they process anything, thus can be classified as data sources.

TABLE III. XML SOURCE CODE AND ITS DATA COMPONENT ELEMENTS

VIII. CONCLUSION

We conclude that multi-enterprise collaborative decision making and support will help decision makers with and

across organizational boundaries to make more accurate, effective and timely decisions. In particular, through the power of Web Services offered by the Oracle BPEL Process Manager tool, we illustrated an aspect of the MECDSS framework and architecture, and how it supports the decision making lifecycle. In addition, we were able to address some of the requirements in the area of decision making in a multi-enterprise collaborative context.

REFERENCES

[1] H. Kagermann and G. Keller, “mySAP.com Industry Solutions: New strategies for success with SAP's Industry Business Units. Harlow”, England: Pearson Education Limited, 2000.

[2] K. Gottschalk, “Web Services Architecture Overview: The next stage of evolution for e-Business”, IBM developerWorks, 2000.

[3] V. Dhar and R. Stein, “Intelligent Decision Support Methods: TheScience of Knowledge Work”, Upper Saddle River, NJ: Prentice Hall, 1997.

[4] R. Michel, “The road to extended ERP”, http://www.manufacturingsystems.com, 2000.

[5] H. Schuster, “Chapter 8: Business Framework” (A. Weinland, Trans.). In R. Buck-Emden (Ed.), The SAP R/3 System: An introduction to ERP and business software technology (4th ed., pp. 183-202). Harlow, England: Pearson Education Limited, 2000.