ABSTRACT

With advances of several enabling technologies such as web services, ontology, and semantic web, the business environments are shifting to an open business environment where business applications autonomously share information and coordinate decisions with each other without any human intervention. This open business environment provides supply chains with the opportunity to generate executable supply chain plans, mitigating the inefficiencies of traditional supply chains such as bullwhip effect that is caused by the lack of information sharing. This paper aims to develop business process models that reflect realistic business scenarios and enable integrated supply chain planning in the open business environment. For this purpose, we first classify business patterns based on the types of “request for quotation”, and then business process models are developed for the business patterns using BPMN V1.1.

1. Introduction

Many enterprises have achieved significant improvements in their internal processes by such as Enterprise Resource Planning and Customer Relationship Management. Nowadays, enterprises are trying to further enhance the efficiency of their interactions with trading partners, which are facilitated by several enabling technologies such as ontology, semantic web, and web service. This new trend gives rise to the concept of open business environment where enterprise applications share information and coordinate decisions with each other seamlessly without any human intervention [1-4]. From our perspective, this open business environment can play a crucial role especially in the supply chain planning that controls material flow through procurement, production, and distribution as a major driver of costs and customer service. The competitiveness of enterprises in today’s global market will become increasingly dependent of the way of utilizing the open business environment in their supply chain planning.

When entities in a supply chain make independent plans without information sharing, the whole supply chain exhibits expensive inefficiencies such as bullwhip effect as pointed out by Lee et al. [5], Lee and Whang [6,7]and Chen, Drezner et al. [8]. Since individual entities forecast demands independently based on the order history from their immediate customers, the information transferred in the form of orders tends to be distorted and can misguide upstream entities in their inventory and production decisions. As a result, demand variability in upstream entities is amplified causing large safety stock, large inventory cost, poor customer service, and inefficient resource use. It is argued that such inefficiencies can be overcome through appropriate information sharing strategies that help reduce the infeasibility of individual plans with respect to others [9-12].

Generally speaking, the plan infeasibility means the existence of orders that are not acceptable or executable due to excessive quantity or low price requested by customers or small quantity or high price offered by suppliers. Infeasible plans should be adjusted in quantity and/or price by a certain infeasibility resolution process. Since the plan feasibility of a supply chain entity relies on the plans of its suppliers and customers, all the entities are closely interrelated in their plan feasibility and hence appropriate information sharing and coordination processes are needed. We call this supply chain planning process as integrated supply chain planning (ISCP). The open business environment facilitates the integrated supply chain planning, and it is our objective here to develop business process models that enable the integrated supply chain planning encompassing various realistic business scenarios that enterprises can face in practice.

For this purpose, we first classify business patterns based on the types of “request for quotation,” and then translate the business patterns into business process models using BPMN V1.1 [13] which is a flow-chart based notation for defining business processes initiated by BPMI (Business Process Management Institute). The business process models developed here can be easily assembled to build an integrated business process model of entire supply chain whose entities may have heterogeneous business patterns. To the best of our knowledge, there has been no effort to develop such business process models for integrated supply chain planning. Though there have been considerable efforts in the areas of standardization [14-16] and integration [17-20] of business processes, their focuses are limited to the interoperability of business applications within and across institutional boundaries [21].

2. Business Patterns of ISCP in Open Business Environment

Consider an entity in a supply chain and denote it as MANU. The MANU may have suppliers (SUPPs) and customers (CUSTs). This section identifies several business patterns that the MANU can adopt in the integrated supply chain planning scenario, and those patterns are generally applicable to any entity in the supply chain. A trading process is mediated by Request For Quotations (RFQs) initiated by CUSTs. The general framework of trading process is as follows: 1) MANU receives RFQs from CUSTs; 2) MANU inquires offers from SUPPs and a negotiation process with SUPPs may follow if necessary; 3) MANU generates a supply chain plan along with quotations for CUSTs and a negotiation process with CUSTs may follow if necessary. In this trading process, Step 2 is crucial in gathering information needed to build executable supply chain plans, since it enables to evaluate and resolve the infeasibility of RFQs. This trading process propagates to end SUPPs (i.e. those with no supplier of their own) and hence the individual plans are maintained feasible with respect to others throughout entire supply chain.

When the MANU inquires information from its SUPPs, different inquiry types may exist depending on the level of scarcity of raw materials. In a scarcity situation, the MANU wants to secure raw materials as much as possible and hence will ask the price and quantity that the SUPPs can deliver. On the other hand, in an abundance situation, the MANU will ask if its SUPPs can deliver a specified quantity at a specified price. These two inquiry types are represented in two different types of RFQs, as shown in Figure 1. R-RFQ (Regular RFQ) specifies the exact values of price and quantity for each concerned time period. On the other hand, B-RFQ only specifies question marks for the concerned time periods instead of using actual values. These question marks are used to ask the price and quantity that the SUPPs can offer.

These two inquiry types are applied to any entity in a supply chain and hence the business pattern of each entity, say MANU, can be classified depending on the type of RFQs from its CUSTs as well as the type of RFQs to its SUPPs. There are four possible business patterns from this perspective: 1) Blank-Blank RFQ business pattern (MANU receives B-RFQs and sends B-RFQs); 2) BlankRegular RFQ business pattern; 3) Regular-Blank RFQ business pattern; and 4) Regular-Regular RFQ business pattern.

Prior to detailing each business pattern, let us define “quotation” and “negotiation”. A quotation is an answer to RFQ, and its form is the same as that of R-RFQ except that the first column is for “Quotation ID”. A negotiation is a counter proposal for the price and quantity in response to a R-RFQ, a quotation, or even a negotiation, and its form is the same as that of R-RFQ except the first column is for “Negotiation ID”. We denote “quotation” and “negotiation” as QUOT and NEGO respectively. Also, the terminology in Table 1 is used here from the viewpoint of MANU.

2.1. Blank-Blank RFQ Business Pattern (B-B RFQ BP)

B-B RFQ BP represents the case that the MANU is invoked by B-RFQ(C)s and invokes SUPPs by B-RFQ(S). In this business pattern, the CUSTs want to know the price and quantity the MANU can deliver, and the MANU inquires the same information from SUPPs in order to evaluate the requests from the CUSTs. The choreography of this business pattern is shown in Figure 2.

Upon the receipt of QUOT(S)s, the MANU solves an ISCP Problem (ISCPP) and sends QUOT(C)s or GUMSGs depending on the production volume resulting from solving the ISCPP. If the production volume is less than a predefined threshold (e.g. minimum batch size), the GU-MSG is issued. Note that various ISCPPs and infeasibility resolution processes mentioned throughout this section will be explained in the next section. For CFM-MSGs sent by some CUSTs, the MANU enters the corresponding QUOT(C)s as orders, sends CFM-MSGs to SUPPs for selected QUOT(S)s to fulfill the entered orders, and sends DSC-MSGs to SUPPs for unselected QUOT(S)s. For DSC-MSGs from some CUSTs, the MANU deletes the corresponding B-RFQ(C)s and QUOT(C)s, and sends DSC-MSGs to corresponding SUPPs. Note

that a SUPP also needs to gather information from its own SUPPs before sending a QUOT to the MANU. For this, the SUPP sends a B-RFQ or a R-RFQ depending on its inquiry type.

2.2. Blank-Regular RFQ Business Pattern (B-R RFQ BP)

In this business pattern, the CUSTs inquires the same information as that in B-B RFQ BP, but the MANU wants to know whether the SUPPs can deliver specified quantities at a specified price. The choreography of this business pattern is shown in Figure 3 and the difference from B-B RFQ BP is on the negotiation process between MANU and SUPPs. As mentioned before, the MANU may receive NEGO(IS) in response to R-RFQ(S) or NEGO(OS) and can send NEGO(OS) in response to QUOT(S) or NEGO(IS). The dotted lines in Figure 3 represent possible scenarios.

Other important differences are to the ISCPP and infeasibility resolution. The MANU solves a different type of ISCPP in generating R-RFQ(S)s and checking the acceptability of QUOT(S)s and NEGO(IS)s. Generating R-RFQ(S)s does not require SUPPs’ information but checking acceptability needs the information in terms of QUOT(S) or NEGO(IS). Also, the MANU should gene-

rate a counter proposal, NEGO(OS), to resolve the infeasibility caused by QUOT(S)s or NEGO(IS)s using an infeasibility resolution process. The MANU may solve ISCPP and resolve infeasibility several times as the MANU may receive NEGO(IS)s iteratively.

2.3. Regular-Blank RFQ Business Pattern (R-B RFQ BP)

In this business pattern, the CUSTs wants to know whether MANU can deliver specified quantities at a specified price, and the MANU inquires the same information as that in B-B RFQ BP. As shown in Figure 4, the choreography of this business pattern is almost the same as that of B-R RFQ BP except that the negotiation process is shifted to the right side between MANU and CUST. The MANU faces an ISCPP and an infeasibility resolution process different from those of B-R RFQ BP.

2.4. Regular-Regular RFQ Business Pattern (R-R RFQ BP)

In this business pattern, the CUSTs wants to know whether the MANU can deliver specified quantities at a specified price, and the MANU also wants to know the same information from the SUPPs. Even though the choreography of this business pattern shown in Figure 5 seems somewhat simple, this business pattern is the most complex because the MANU may recursively receive NEGO (IC)s and NEGO(IS)s and send NEGO(OC) and NEGO (OS). In fact, the MANU can send QUOT(C)s after receiving QUOT(S)s or NEGO(IS)s, but may send NEGO (OS)s or NEGO(OC)s before sending QUOT(C)s. For these reasons, we arrange the dotted arrows in both sides of MANU at the same height.

3. Business Process Models for ISCP

The business patterns identified in the previous section are used to develop four business process models in this section. Note that the business process models developed here can be easily assembled to build an integrated business process model of entire supply chain whose entities may have heterogeneous business patterns. The business processes are modeled here using BPMN V1.1 (OMG 2010) suggested by BPMI (Business Process Management Initiative). Due to the limitation of space, we provide a detailed description for the most complex business pattern in following subsection and then only the differences will be explained for other business patterns in the remaining subsections.

3.1. Business Process Model in R-R RFQ BP

Basic stream of this business pattern is that when the MANU is invoked by R-RFQ(C)s, the MANU checks how much and at which price it can provide by solving an ISCPP with CUSTs’ requirements and its own restrictions. The result of ISCPP is then used to generate RRFQ(S)s to SUPPs. Upon the receipt of QUOT(S)s or NEGO(IS)s, the MANU checks the feasibility of RRFQ(C)s by solving an ISCPP with CUSTs’ requirements, SUPPs’ restrictions, and its own restrictions. For feasible R-RFQ(C)s the MANU finalizes them, but for infeasible R-RFQ(C)s the MANU finds out which factors cause the infeasibility and the possibility of resolving the infeasibility. For R-RFQ(C)s expected to be resolvable, the MANU tries to resolve infeasibility by relaxing internal restrictions, SUPPs’ restrictions, and CUSTs’ requirements, and for R-RFQ(C)s expected not to be resolvable, the MANU finalizes them accordingly. These activities of receiving responses, solving ISCPP, finalizing R-RFQ(C), and resolving infeasibility are carried out iteratively until all R-RFQ(C)s are finalized.

The business process model for ISCP in R-R RFQ BP is shown in Figure 6 in Appendix. As shown in this figure, the business processes are classified into five groups: Information Gathering Group, Solving Group, Infeasibility Resolving Group, Negotiation Handling Group, and Finalizing Group.

3.1.1. Information Gathering Group

The business processes that belong to this group perform figuring out CUSTs’ requirements based on R-RFQ(C)s or NEGO(IC)s and SUPPs’ capabilities based on QUOT (S)s or NEGO(IS)s. Technically, these processes can be implemented or executed automatically by web service,

semantic web, or agent technologies.

• Process Received R-RFQ(C)s: The MANU gathers RRFQ(C)s during a predefined time length and summarizes prices and quantities on concerned time periods for each product.

• Convert SP to R-RFQ(C)s & Map Each Other: SP represents sales plan. If the MANU is the end CUST, there is no R-RFQ(C). In this situation, the SP of the MANU can be treated as a R-RFQ(C). Therefore this process has a meaning in end CUST. In this process, the MANU converts SP to R-RFQ(C)s by product, and then maps the each record of SP onto a R-RFQ(C).

• Search for SUPPs: The MANU searches for SUPPs that can provide the required parts to satisfy the RRFQ(C)s. In addition to this, the MANU is recommended to find out information on rough capacity of the SUPP for next process.

• Generate R-RFQ(S)s: This process generates RRFQ(S)s for each SUPP based on the result of “Solve SCPP type 5”, and sends them to the corresponding SUPPs. To set proper price and quantities, a function of distributing properly total requirement to the SUPPs is needed. But this is not necessary but recommended due to Negotiation Handling Group.

• Process Received GU-MSGs: When the MANU receives GU-MSGs from SUPPs, the MANU updates information about R-RFQ(S), QUOT(S), NEGO(IS) and NEGO(OS) by deleting record related to corresponding SUPPs.

• Check Rejecting Cond. Of R-RFQ(C)s: If the MANU cannot procure one or more parts of the required parts from SUPPs, the MANU should give up the R-RFQ(C)s that require corresponding products. The link named “For R-RFQ(C)s Rejected” is liaising with business processes that should follow.

• Process Received QUOT(S)s: The MANU checks whether all R-RFQ(S)s are responded by GU-MSGs and QUOT(S)s or not. If “YES”, the MANU prepares data set to solve SCPP, otherwise the MANU should check NEGO(IS)s.

3.1.2. Solving Group

Based on R-RFQ(C)s, QUOT(S)s, NEGO(IC)s, and NEGO(IS)s, the MANU generates a supply chain plan by solving an ISCPP. The ISCPP to be solved is different depending on which business pattern is applied and whether the MANU is an end CUST/SUPP or not. Considering all possibilities, five types of ISCPP are identified as summarized in Table 2. The last row entitled “Appeared Business Pattern & Position” shows the business pattern (B-B, B-R, R-B, R-R) and the position of the MANU in the supply chain (end SUPP, end CUST, Not end SUPP, Not end CUST) corresponding to each type of ISCPP. There are two types of ISCPP in R-R RFQ BP as follows.

• Solve ISCPP Type 4: After receiving R-RFQ(C)s, the MANU should solve an ISCPP to figure out the price and quantities needed for R-RFQ(S)s. In this business process, the CUST’s requirements (price and quantities) and the MANU’s own restrictions (price and profit) are considered, and the MANU should carry out this business process regardless of its position in the supply chain.

• Solve ISCPP Type 5: After receiving QUOT(S)s or NEGO(IS)s, the MANU should solve an ISCPP to satisfy R-RFQ(C)s. Therefore, in this business pro

Figure 6. Business process model in R-R RFQ business pattern.

 

cess, the SUPPs’ restrictions (price and quantities) are considered additionally. Except the case that the MANU is an end SUPP, the MANU should carry out this business process.

3.1.3. Infeasibility Resolving Group

From the result of “Solving Group”, R-RFQ(C)s can be classified into FEAS and INFEAS, where FEAS represents a set of feasible R-RFQ(C)s and INFEAS a set of infeasible R-RFQ(C)s. For R-RFQ(C)s in FEAS, the MANU generates QUOT(C)s and sends them to the corresponding CUSTs. However, for R-RFQ(C)s in INFEAS, the MANU tries to make them feasible by relaxing infeasibility factors (those terms that appear as constraints in Table 2), e.g. increase MANU’s capacity by overtime, increase SUPP’s delivery quantity, increase CUST’s asking price, etc. These relaxation methods enable to separate INFEAS into TOBE_FEAS and NOT_ TOBE_FEAS where TOBE_FEAS represents a set of infeasible ones that can turn feasible and NOT_TOBE_ FEAS a set of infeasible ones that cannot turn feasible. This separation is based on a certain criteria, e.g. the changes needed to make an infeasible R-RFQ(C) feasible must result in less than 10% of the original value. For R-RFQ(C)s in NOT_TOBE_FEAS the MANU sends GU-MSGs to corresponding CUSTs, and for R-RFQ(C)s in TOBE_FEAS the MANU carries out formal actions to resolve infeasibility.

• Analyze Infeasibility: The MANU classifies R-RFQ(C)s into FEAS and INFEAS. And the MANU classifies INFEAS into TOBE_FEAS and NOT_TOBE_FEAS, and finds out infeasibility factors and those amounts. For this finding, a mathematical model is required.

• Relax Internal Restrictions: When the infeasibility is caused by the MANU’s restrictions, the MANU should try to relax MANU’ Capacity and/or profit by communicating with internal system such as ERP based on the amount suggested by Analyze Infeasibility.

• Relax SUPP’s Restrictions: When the infeasibility factor is SUPP’s restrictions, the MANU should try to relax SUPP’s delivery quantity and/or price by sending NEGO (OS)s based on the suggested amounts. If multiple SUPPs deliver same parts at issue, the MANU should distribute the suggested amounts to SUPPs before generating NEGO (OS)s.

• Relax CUST’s Requirements: Similar to above process, when the infeasibility factor is CUST’s requirements, the MANU should try to relax CUST’s requirement quantity and/or price by sending NEGO (OC)s based on the suggested amounts. Basically infeasibility on CUST’s requirements is caused by MANU’s and/or SUPP’s restrictions. Therefore, when infeasibility factor is CUST’s requirement quantity and the corresponding infeasible R-RFQ(C)s compete for same resources or parts, the MANU should distribute the suggested amounts to CUSTs before generating NEGO(OC)s.

• Update R-RFQ(C)s: If the MANU is an end CUST and there are still infeasible R-RFQ(C)s after carrying out “Relax Internal Restrictions” and “Relax SUPP’s Restrictions”, the only thing the MANU can do is revising the R-RFQ(C)s using the suggested amounts. This means that sales plan of the MANU is changed.

3.1.4. Negotiation Handling Group

The MANU may receive NEGO(IS)s in response to RRFQ(S)s, may send NEGO(OS)s/ NEGO(OC)s in response to QUOT(S)s/R-RFQ(C)s, and may receive NEGO (IS)s/NEGO(IC)s in response to NEGO(OS)s/NEGO (OC)s. The business processes related to NEGO(IS)s, NEGO(IC)s, NEGO(OS)s, and NEGO(OC)s belong to this group, but the business processes related to check the acceptability of NEGO(IS)s and NEGO(IC)s belong to “Solving Group” as mentioned before.

• Generate NEGO(OC)s: Based on the result of the “Relax CUST’s Requirements”, the MANU generates NEGO(OC)s and send them to corresponding CUSTs. As mentioned previously, the format of the NEGO (OC) is almost the same as QUOT(C).

• Generate NEGO(OS)s: Similar to “Generate NEGO (OC)s”, based on the result of the “Relax SUPP’s Restrictions”, the MANU generates NEGO(OS)s and send them to corresponding SUPPs.

• Process Received NEGO(IC)s, Process Received NEGO (IS)s: The NEGO(IC)/NEGO(IS) is treated as RRFQ(C)/QUOT(S). Therefore, when receiving NEGO (IC)s and/or NEGO(IS)s, the MANU replaces the original R-RFQ(C) and QUOT(S) with these NEGOs and prepares data set to solve SCPP based on these NEGOs.

3.1.5. Finalizing Group

For feasible R-RFQ(C)s including NEGO(IC)s from the result of “Solving Group”, the MANU generates QUOT (C)s and sends them. Then, the MANU waits for MSGs from CUSTs. If the MANU receives CFM-MSGs, the MANU enters the QUOT(C)s as orders, and sends CFMMSGs to corresponding SUPPs. On the other hand, for R-RFQ(C)s that belong to NOT_TOBE_FEAS or rejected due to the absence of required parts, the MANU sends GU-MSGs to corresponding CUSTs and DSCMSGs to related SUPPs to notify that R-RFQ(S)s are not valid no longer.

• Generate QUOT(C)s: For R-RFQ(C)s that belong to FEAS including NEGO(IC)s, the MANU generates and sends QUOT(C)s, and then waits for MSGs from CUSTs for predefined time interval.

• Process Received MSGs: Based on MSG type (CFMMSG or DSC-MSG), the MANU classifies corresponding R-RFQ(C)s and QUOT(C)s.

• Finalize R-RFQ(C)s: For QUOT(C)s responded CFMMSGs, the MANU enters the QUOT(C)s as orders, updates R-RFQ(C) list, and classifies corresponding alternative QUOT(S)s for each part into selected QUOT(S)s and unselected QUOT(S)s. Those QUOT (C)s entered as orders and selected play roles as not selective options but constraints in SCPP.

• Send CFM-MSGs: For selected QUOT(S)s, the MANU sends CFM-MSGs to corresponding SUPPs to confirm these QUOT(S)s are accepted. If the MANU is an end SUPP, this process is not needed.

• Send GU-MSGs: For R-RFQ(C)s that belong to NOT_TOBE_FEAS and rejected due to absence of required parts, the MANU sends GU-MSGs. If the MANU is an end CUST, this process is not needed.

• Modify R-RFQ(C) List: For R-RFQ(C)s related with GU-MSGs sent and DSC-MSGs received, the MANU modifies R-RFQ(C) list by deleting these R-RFQ(C)s and picks out QUOT(S)s related to these R-RFQ(C)s.

• Send DSC-MSGs: For QUOT(S)s picked out from “Modify R-RFQ(C) List” and unselected from “Finalize R-RFQ(C)s”, the MANU sends DSC-MSGs to corresponding SUPPs to notify the corresponding R-RFQ(S)s are not valid no longer.

3.2. Business Process Model in B-B RFQ BP

Basic stream of this business pattern is that when the MANU is invoked by B-RFQ(C)s, the MANU asks SUPPs how much and at which price the SUPPs can deliver required parts by sending B-RFQ(S)s. Upon the receipt of QUOT(S)s, the MANU checks the price and quantity it can provide by solving an ISCPP with SUPPs’ restricttions and its own capacity. Then, the MANU generates QUOT(C)s based on the result of ISCPP and sends them to corresponding CUSTs. The business process model of B-B RFQ BP is shown in Figure 7. As shown in the figure, there is neither “Infeasibility Resolving Group” nor “Negotiation Handling Group” because B-RFQ(C) and B-RFQ(S) do not cause infeasibility. Except “Solving Group”, the business processes are almost the same as those in R-R RFQ BP. Therefore, only the business processes that belong to “Solving Group” are explained.

• Solve ISCPP Type 1: If the MANU is an end SUPP, the MANU solves an ISCPP after receiving B-RFQ(C)s by considering its own capacity only as shown in Table 2.

• Solve ISCPP Type 2: If the MANU is not an end SUPP, the MANU solves an ISCPP by considering its own restrictions and SUPPs’ restrictions after receiving QUOT(S)s or GU-MSGs from SUPPs.

3.3. Business Process Model in B-R RFQ BP

Basic stream of this business pattern is that when the MANU is invoked by B-RFQ(C)s, the MANU checks how much and at which price it can provide by solving an ISCPP with its own restrictions. Then, the MANU generates R-RFQ(S)s based on the result of ISCPP and sends them to corresponding SUPPs. Upon the receipt of QUOT(S)s or NEGO(IS)s, the MANU checks the level of profit and/or capacity utilization by solving an ISCPP with SUPPs’ and its own restrictions. The business process model of B-R RFQ BP is shown in Figure 8. In comparison with the one of R-R RFQ BP, only three business processes need to be explained as follows.

• Solve ISCPP Type 3: When receiving B-RFQ(C)s, the MANU should solve an ISCPP to figure out how much and at which price it can provide to the CUSTs, and how much and at which price it needed to be supplied from SUPPs. Therefore, only the restrictions

of MANU are considered, and the MANU should carry out this business process just one time if it is not an end SUPP.

• Analyze Infeasibility: The role of this business process is somewhat different from that of this business process in R-R RFQ BP. But same name is used because the basic mechanism is same. If profit level and/or capacity utilization level is too low in producing the products issued by some B-RFQ(C)s, the MANU tries to enhance level. To do this, the MANU should find out the possibility of enhancing level, and for possible cases, the MANU should find out suggested amounts to enhance level.

• Restore SCPP Results for Corr. B-RFQ(C)s: In here Corr. is an abbreviation of corresponding. For BRFQ(C)s expected not to be enhanced, the result of the previous SCPP is optimal. Therefore, the MANU should restore the result for those B-RFQ(C)s, generate QUOT(C)s based on the result, and finalize those B-RFQ(C)s.

3.4. Business Process Model in R-B RFQ Business Pattern

Basic stream of this business pattern is that when the MANU is asked by R-RFQ(C)s, the MANU asks SUPPs how much and at which price the SUPPs can deliver required parts by sending B-RFQ(S)s. Upon the receipt of QUOT(S)s, the MANU checks the feasibility of RRFQ(C)s by solving an ISCPP with CUSTs’ requirements, SUPPs’ restrictions, and its own restrictions. For feasible R-RFQ(C)s, the MANU finalizes them, and for infeasibility R-RFQ(C)s, the MANU finds out which factors cause infeasibility and the possibility of resolving infeasibility. For R-RFQ(C)s expected to be resolved, the MANU tries to resolve infeasibility by relaxing internal restrictions and CUSTs’ requirements, and for R-RFQ(C)s expected not to be resolved, the MANU finalizes them. These receiving responses, solving SCPP, finalizing RRFQ(C)s and resolving infeasibility are carried out iteratively until all R-RFQ(C)s are finalized. The business process model in R-B RFQ BP is shown in Figure 9. As shown in this figure, all business processes are almost the same as those explained above, so additional explanations are not needed.

4. Conclusions

In this study, we proposed four business process models for integrated supply chain planning in an open business environment. They are based on the business patterns that capture realistic business scenarios that enterprises can face in practice. The business process models developed here can be easily assembled to build an integrated business process model of entire supply chain whose entities may have heterogeneous business patterns. As a result of this effort, enterprises can build executable yet profitable plans through the information sharing and coordination mechanisms equipped within the models, while avoiding the inefficiencies of traditional supply chains such as bullwhip effect caused by the lack of information sharing.

The business process models developed in this work give rise to several new types of supply chain planning problems. Most of the research on supply chain planning takes into account only aggregate volumes of customer requests and supply capacities, e.g. refer to detailed reviews by Shen [22] and Sodhi and Tang [23]. However, the supply chain planning problems introduced in this work incorporate individual customer requests and supplier capacities, reflecting the reality of business operations. Therefore, those problems need to be investigated in complexity and efficient heuristic algorithms need to be developed as appropriate. Algorithmic efficiency is especially crucial in the proposed business process models since an entity needs to solve the problem iteratively and the results are fed back to other entities triggering other planning problems throughout entire supply chain.

5. Acknowledgements

This research was supported by the National Research Foundation of Korea Grant funded by the Korean Government (NRF-2010-013-1-D00085).

REFERENCES