DECENTRALIZED MANAGEMENT MODEL OF A
PARTNER-TO-PARTNER COLLABORATIVE RELATIONSHIP
María Laura Caliusco, Pablo Villarreal
Ingeniería en Sistemas - UTN Facultad Regional Santa Fe GIDSATD-Grupo de Investigación de Desarrollo
Facundo Arredondo, César Zanel, Diego Zucchini, Omar Chiotti, María Rosa Galli
Ingeniería Industrial - UTN Facultad Regional Santa Fe
[email protected]; [email protected]
ABSTRACT
In this work we describe a Partner-to-Partner integration model (P2P) for a collaborative relationship (n-1), whose objective is to allow the enterprise to jointly manage the material flow between them. In this model four main hierarchical collaboration processes are identified according to the planning level: (1) Collaboration frame agreement (clauses and rules definition), (2) Agreement on the production planning definition, (3) Agreement on the master production scheduling definition, and (4) Agreement on the material provision orders definition.
The purpose is to define a continuous collaboration process between enterprises along all hierarchical planning levels, preserving the autonomy of enterprises. To this aim, the proposed collaboration process is managed in a decentralized way for each partner. The participation of each partner enterprise in the collaboration process, the information type and the decision flow to be exchanged in each process are defined in this work.
1. INTRODUCTION
To face the new competitive global market companies need to work closely with their trading partners. Collaborative relationships transform the way of sharing information and drive change to the underlying business processes. The most primitive state of collaboration is when two enterprises share information in order to improve internal business processes. In this case, there is a cooperation between enterprises. Instead, collaboration means that the involved enterprises improve their profit and reduce their costs by jointly executing some business processes, like demand forecasting (Mentzer, 2000; Aviv, 2001; Quinn, 2001). On the one hand, collaboration and true partnership result in benefits as lower inventory levels (Lee et al., 1997), higher inventory returns, improved cash flow, and more flexibility to demand changes. On the other hand, electronic collaboration implies introducing information technology in business transactions; this reduces information asymmetry and transaction costs in general (Malone and Laubacher, 1998). However, the most valuable collaboration benefit is the interaction among people working in partner enterprises, since their intuition, expertise and judgment enhance the invention and innovation ability to create custom value for the customer (Welty et al., 2001).
Some models have been proposed to implement collaboration between enterprises; we can mention Collaborative Planning, Forecasting and Replenishment (CPFR) (cpfr.ogr, 1998), and Demand Activated Manufacturing Architecture (DAMA) (Chapman and Petersen, 2000). CPFR model has been successfully implemented by some enterprises like Wal-Mart and Procter & Gamble. CPFR focuses on the manufacturer/retailer partnership while DAMA model assumes a supply chain with multiple trading partners collaboratively working to meet consumer demand. The DAMA model proposes a centralized coordination of all trading partners of the supply chain. This centralized supply chain management may consist of one to four centralized processes (defining products, forecasting and planning capacity
commitments, scheduling products and product delivery, expediting production and delivery exceptions) to be collaboratively executed by all trading partners. The centralized collaborative model is based on the concept of visibility of the whole supply chain. The advantage of centralized models is that they enable inter-enterprise optimization of the operation variables involved in the logistics of the supply chain.
Centralized models are appropriate for the supply chain collaborative management of some type of industry where each enterprise has a high participation level in the supply chain. However, a manufacturing enterprise usually participates in two or more supply chains. That is, a supplying manufacturing enterprise can provide several manufacturing enterprises belonging to different supply chains, and also a manufacturing enterprise can be provided by two or more manufacturing enterprises belonging to different supply chains. Then, the relationship among these manufacturing enterprises is not a linear one as the integrated textile industry modeled by DAMA, but a complex relationship. For this type of relationship among enterprises, a centralized collaborative model is not appropriate due to the concept of visibility of the whole supply chain, on which the centralized collaborative model is based. For these cases, collaboration must be supported by a partner-to-partner relationship model (Villarreal, et al, 2001).
A centralized model considers the supply chain like a closed system that includes all enterprises that form this supply chain. In contrast to this, the partner-to-partner model considers the enterprise like a fairly open system that interacts with other fairly open systems (enterprises). The purpose of this interaction is to collaborate in the material flow management. One or more materials, whose amounts and values may be different, can constitute the material flow between enterprises. Taking this into account, Villarreal et al., (2003a) classify collaborative partner-to-partner relationships defining two relationship types and two collaboration levels. In this way, they defined four different cases:
a. Relationship (1-n) with total collaboration as regards a material: An enterprise has partner-to-partner collaborative relationships with all of its customers as regards a material.
b. Relationship (n-1) with total collaboration as regards a material: An enterprise has partner-to-partner collaborative relationships with all of its suppliers as regards a material.
c. Relationship (1-n) with partial collaboration as regards a material: An enterprise, that provides a material to one or more customer enterprises, has partner-to-partner collaborative relationships with one or more of its customers as regards this material, but not with all of them.
d. Relationship (n-1) with partial collaboration as regards a material: An enterprise, that is provided by one or more enterprises with a material, has partner-to-partner collaborative relationships with all of its suppliers as regards this material, but not with all of them. It is important to emphasize that an enterprise can establish a collaborative relationship as regards several materials, with its suppliers and also with its customers. These cases are a combination of the four base cases described above. Furthermore, it is necessary to highlight that an enterprise do not need to collaborate with all its customers and/or suppliers; they can only do it with those enterprises and as regards those materials whose flow is important. As it has been specified above, from a systemic vision, a partner-to-partner collaborative relationship implies switching the view of the enterprise as a closed system to one that considers it as a fairly open one. In this new systemic vision, the traditional hierarchical process used for production planning and capacity control of an enterprise viewed as a closed system (Sipper, et al., 1997, Dominguez Machuca et al., 1995) has to be modified. For this purpose, Villarreal et al. (2003a) have proposed an approach to carry out production planning and capacity control operations of enterprises involved in a partner-to-partner collaborative relationship. To this purpose, they have considered the case of relationship (1-1) with total
collaboration as regards a material as a basis, to explain the planning process that must be performed in a collaborative way by each partner.
To each of the other cases of above defined relationships, the planning process that must be performed is conceptually similar, but the greater number of variables to be taken into account generates several decision alternatives due to, this planning process requires that an enterprise has to perform partner to partner relationships with two or more enterprise.
The objective of this work is to describe the main characteristics of collaborative decision processes involved in a production planning and capacity control operations of collaborative B2B relationships (n-1). In section 2, we analyze the types of business processes required to perform a collaborative decision process. In Section 3, we analyze the main characteristics of collaborative business processes involved into a collaborative B2B relationship (n-1). In section 4, the collaboration frame agreement characteristics are discussed. In section 5 we present an integrated production planning model for this collaborative relationship. In section 6 we present an example to illustrate this planning model. In section 7 we discuss the information system technology required to support this collaborative business process. In section 8, we present our conclusions.
2. PUBLIC AND PRIVATE BUSINESS PROCESSES
The partner-to-partner model proposed by Villarreal, et al, (2003a) to support a collaborative B2B relationship considers that manufacturing enterprises can both share information and collaboratively make decisions at planning, scheduling and product delivery levels. Management of these collaborative B2B relationships implies to manage two types of business processes: processes that belong to the enterprise called intra-enterprise, private or
internal business processes, and processes that belong to the two enterprises involved in a collaborative B2B relationship called inter-enterprise or public business processes. Public
business processes have to be agreed by the partners, and have to be jointly defined, executed, monitored and controlled. Unlike the public processes, private processes are defined, executed, monitored and controlled by each enterprise in an autonomous way. A public process is defined by abstract activities that are actually implemented by private processes.
A clear separation between private and public processes is key to provide the necessary isolation and abstraction between enterprise internal processes and processes across enterprises (Villarreal et al., 2003b). The challenge is how to manage public processes meeting the requirements imposed by a partner-to-partner collaborative model. Furthermore, it is necessary to develop mechanisms to integrate public processes with private processes within each enterprise.
A collaborative relationship (n-1) implies that an enterprise has partner-to-partner collaborative relationships with n of its suppliers; therefore, it has to manage a collaborative business process consisting of n public business processes. In this way, its private process has to implement and coordinate the abstract activities that define these n public processes. Likewise, to support a collaborative relationship with n of its suppliers, the production planning process that an enterprise has to perform requires coordinating n partner-to-partner planning activities. Following, we discuss the characteristics involved into this collaborative planning process and we present an approach to carry it out.
3. ASSIGNATION OF MATERIAL REQUIREMENT IN COLLABORATIVE
RELATIONSHIPS (n-1)
To carry out a collaborative relationship with n suppliers as regards a material, an enterprise has to define the amount of material to be required to each supplier. The enterprise can do it ranking the suppliers or defining an assignation percentage. That is, two cases can be defined:
Case 1: An enterprise can rank its suppliers based on a set of attributes that it considers valuable, such as: material quality, reliability level with regards to quantity and certainty, price, and so on. Then, all the material will be required to supplier ranked first. The material that it last can not provide will be required to supplier ranked seconds, and so on.
Case 2: An enterprise defines percentages to assign the material to its suppliers. When a supplier can not satisfy all the required material, the customer will have to require the lacking material to other supplier.
4. COLLABORATION FRAME AGREEMENT
Collaborative processes execution is based on a previously settled agreement. This frame agreement sets up the guidelines and rules of the collaborative relationship. It is important that each enterprise assesses its own strategy and goals to ensure that these are incorporated into the partnership agreements. The goal is to arrive to a win-win situation for partners. Participation of each enterprise in the collaborative process and the type of information to be exchanged depend on the planning level.
Some parameters that should be defined in the frame agreement are: duration of the agreement, the time horizon of plans under collaboration, the number of time periods to be considered to each plan, products object of collaboration, punishment for the case of nonfulfilment, the work way at the level of aggregated production planning, and so on.
5. COLLABORATIVE PRODUCTION PLANNING MODEL
A collaborative production planning model defines three collaborative levels, according to the hierarchical level of the internal o private planning to be performed by each partner enterprise. The purpose is that enterprises carry out a continuous collaborative process between them, from the aggregated production planning till the shipment of the provision
order, without loosing their autonomy. The activities that each enterprise has to carry out and the information and messages to exchange depend on the planning level under execution. The three collaborative levels are: (1) Consensus at aggregated production planning level, (2) Consensus at master production scheduling level, and (3) Consensus about an schedule of material provision orders.
At this collaborative level, one of two work ways could be used: to work with ranges of values or without them.
• Scenario 1: Work with ranges: A range defines a set of values between a lower value and an upper value that represents the amount of an specified material to which the supplier commits oneself to provide the customer, along of each period of a plan. Also, the price could be predefined during the agreement and it could be the same to each period or not. Other ways, the price will be defined as part of the consensus.
• Scenario 2: Work without ranges: In this case, to agree a supply plan at the level of aggregated production planning, it will be necessary to negotiate the material quantity to be traded and its price for each time period along the time horizon.
Some advantages of working with a range of values are the following: On one hand, the customer can plan its production with more certainty, due to if the amount of material to be required is within the agreed ranges, it has the certainty that this quantity can be supplied by the supplier, and also its price (if it is defined). This simplifies its decision process.
On the other hand, this implies for supplier a competitive advantage with regard to other suppliers, due to it commitment to assert the provision of material within the range and at the price previously defined. Furthermore, if an exception takes place, that is the amount of material needed by the customer is over or upper the specified range, it is probable that the customer desires to be supplied by this supplier even if the price is grater that the competence.
When this exception occurs, both partners are free to negotiate the amount of material to trade and its price. That is, the supplier is not obligee to supply the customer, and this last is not obligee to buy the material to this supplier. In this case, the planning process implies out and back of information and messages to agree the material quantity to be traded and its price. Therefore, working with ranges, it will be only necessary to negotiate material quantity and price on that time periods where an exception occurs.
5.1 Consensus at Aggregated Production Planning Level
The objective of this collaborative process is that trade partners reach a consensus in the definition of a material provision plan at aggregated production plan level.
Once defined the parameters on the collaboration frame agreement, involved enterprises initiate the collaboration process. Its objective is to agree on a supply plan with its partners at the level of aggregated production planning. Figure 1 shows the private processes that each partner has to perform and the information they have to exchange to reach a consensus about a material provision plan at level of aggregated production plan in collaborative relationships (n-1).
5.1.1 Definition of a material requirement plan (mrp)
The process starts with the definition of production requirements of the customer. This information is generated from the aggregated production plan (APP). This is a private process of the customer, who decides the method and strategy to perform it. Likewise, the customer performs the forecast and other required information. Independently of the used methodology, the output is defined at the product family level. However, except for some very particular cases, this output does not match the product family of the suppliers. Then, the customer has to disaggregate the aggregate production plan to obtain a production plan of
products (DPP). This process is also private, and the customer can perform it by any of well known methods like historical demand, run out time (Sipper and Bulfin, 1997), and so on. Following, the customer has to covert the production plan of products into material requirements. It can do it using appropriate coefficients. Once defined the material requirement, the customer has to define a material requirement plan to be sent to each supplier. It can do it using a ranking of suppliers or defining an assignation percentage as it has been described in section 3, according to the collaboration frame agreement described in section 4. This can result into one of the two scenarios above described in this section.
To sum up, at this point we have described the private process that the customer has to perform to implement a part of the public process whose objective is to agree with suppliers a material provision plan at the level of aggregated production planning.
5.1.2 Material requirement plan agreement
To this point, each supplier receives the material requirement plan [mrp] sent by the customer, and checks it. If a supplier detects that important deviations exists, it can request a confirmation [Confirmation Request]. That is, through a messages interchange mechanism both customer and supplier jointly determine the cause of these deviations (demand fluctuation, policy change, differences in forecasting and so on). In this way, the material requirement plan of the customer can be corroborated.
5.1.3 Definition of a supply plan
Through a private process each supplier determines if it can meet the customer’s requirement. Two different results could take place:
• [mrp Acceptance] Supplier can meet the customer’s requirement. If it does, supplier and customer reach a consensus in the definition of a material requirement plan at the
aggregated production plan level and therefore they can continue with the next collaborative process.
• [Alternative Supply Plan] Supplier, after evaluating possible alternatives of adjustment (overtime, outsourcing, changes in the work force, and so on) cannot meet the customer’s requirements. In this case, the supplier has to elaborate its feasible supply plan and sent it to the customer.
The customer, through a private process analyses the alternative supply plan sent by one or more suppliers. Three alternatives can result of this process:
• [Supply Plan Acceptance] The customer accepts the supply plan. If it does, suppliers and customer reach a consensus in the definition of a material requirement plan at the aggregated production plan level and therefore they can continue with the next collaborative process.
• [Supply Plan Reject] The customer rejects one or more supply plans.
• [mrp] The customer proposes an alternative material requirement plan to one or more suppliers.
On the one hand, it is necessary to highlight, to reach a consensus, more than an iteration of the described collaborative process will be likely needed. On the other hand, the customer has to coordinate each private subprocess Negotiate mrp with Supplier, which is required by the
Customer Process Supplier Process
Execute APP Disaggregate APP Convert DPP in mrp
Assign Plans Execute APP
Send mrp Receive mrp from Customer
Disaggregate APP
Confront Plans
Request Confirmation [Confirmation Needed]
Send Confirmation Request
Receive Supplier Response
Check mrp
Send Confirmation to mrp [No exceptions] Receive Confirmation to mrp
Accept and Register mrp [mrp is satisfied]
Send Plan Acceptance
Register Accepted Plans Generate APP
Generate AAP
[Alternative Plan is required]
Send Alternative Plan
Evaluate Supplier Plans
Send Reject to Plan [Plan Rejected] Receive Customer Response
Accept and Register Plan [Plan Accepted]
Send Plan's Acceptance Receive Acceptance from Customer
Register Accepted Plan
[Plan Accepted] [Exceptions informed] Confirmation Request Supply Plan Acceptan ce Define mrp Supplier Begin Customer Begin [Plan Accepted ] [Counter-proposal offered] [Counter-Proposal needed] [Plan with exceptions] [Plan Rejected]
mrp Negotiate mrp with Supplier 1..N
[Plan agreed] [Counter-Proposal needed] Confirma tion mrp Plan Acce ptan ce Supply Alter nat ive Plan Supply Plan Reject
Figure 1: Private processes and the exchanged information at level of aggregated production plan.
5.2 Consensus at Master Production Scheduling Level
The objective of this collaborative process is that the trade partners reach a consensus in the definition of a material provision schedule at master production scheduling level.
In traditional models, interaction with suppliers is carried out at the end of the hierarchical planning process, after defining the material requirement plan (MRP). At that moment, a schedule of provision orders is defined. The lot size of provision orders is specified by the
customer taking into account historical information of lead times and data of carrying cost and ordering cost (Dominguez Machuca, 1995). Unlike, due to the open systemic vision, a collaborative process is based on two main concepts: an order lead time is not a customer system parameter but it is a decision variable of the supplier system, and the lot size of a provision order is not defined by the customer system but it is a decision variable of the supplier system (Villarreal et al, 2003a).
Traditional methods of master production scheduling consist of assigning lots of a product to be produced to different periods of time. The size of the production lot depends on the productive system and can be calculated following different methods (Dominguez Machuca, 1995). The period of time also depends on the characteristics of the productive process and it is usually a week. Since a collaborative relationship (n-1) requires customer interacts with each supplier to reach a consensus in the definition of a material provision schedule, it is suitable to date the requirement instead of assigning lots to a period of time. That allows a more accurate requirement specification.
With this modification, the master production scheduling requires to execute calculus in dates where a transaction (input or output) occurs.
Taking into account these considerations, Figure 2 shows the private processes that each partner has to perform and the information to exchange to reach a consensus about a material provision schedule at the level of master production schedule in collaborative relationships (n-1).
On the customer side, the process starts with the private master production scheduling process that defines the customer production requirements. To do this, the customer checks the short-range demand forecast and the customer requirements with the disaggregated production plan to control their consistency.
5.2.1 Definition of the product requirement
Then, the customer can define the product requirement following the next steps defined by Villarreal et al (2003b):
1. Get the dated requirement planned by its customers.
2. Calculate for each period i the difference ∆Pi between the short-range demand
forecast of a period i, SRDFi and the sum of all dated requirement planned by its
customers j that correspond to period i, DRPCj,i : ∆Pi = SRDFi – ∑j DRPC j, i
3. If ∆Pi > 0, the difference is dated as product requirement to period i.
4. If ∆Pi≤ 0, the dated requirements planned by its customers will be considered as the
only product requirements.
5.2.2 Definition of the production requirement
After defining the product requirements, production requirements have to be calculated as follows: Initially, for each product to be produced, two lists will be defined. These lists are represented in Table 1. The first list represents the product requirement that the customer has to meet on each date ti, Dem(ti). These are the planned outputs of the customer system. These
transactions are data to calculate the future inventory and thus, the production requirement. When the inventory on date tido not meet the requirements, then a production requirement is
assigned to that date, Prod(ti). This is represented in the second list in Table 1. These are the
planned inputs of the customer system. The inventory and the list of dated production requirements are calculated as follows:
Let t0 be the actual date, Inv(t0) be the actual inventory, D={Dem(ti)} and P={Prod(ti)}, then,
while D ≠ ∅
remove Dem(ti) from D
If Inv(ti) < Safety Stock
Prod(ti) ← n L / Inv(ti-1) + Prod(ti) – Dem(ti) ≥ Safety Stock
Inv(ti) ← Inv(ti-1) + Prod(ti) – Dem(ti)
Add Prod(ti) to P
End if End while
Where L is the production lot size, and n is a positive integer number. That is, if the inventory on ti-1 does not meet the product requirement on ti, then there exists a net requirement to that
date that will be satisfied by n production lots. This information is incorporated into the second list of Table 1 as a dated production requirement. Following this procedure, the customer defines its master production schedule.
Table 1: Definition of the dated production requirement
Product requirements Dated Production Requirements Date Demand Date Production Inventory
t1 t2 ....
tn
5.2.3 Definition of the material requirement schedule (mrs)
After checking the rough-cut capacity, the master production schedule has to be mapped into material requirement schedules, which will be sent to suppliers. To perform this activity, with the aim of simplifying the calculus, a reduced material requirement method is defined. This method is based on a reduced bill of materials, which does not consider the intermediate level of the product structure. That is, it establishes a direct relationship product-material, so the reduced bill of materials has only two levels. In this simplified material requirement scheduling, the customer considers the available material inventory and the total production time to estimate the dated material requirement. Following the two main concepts involved in this collaborative process, which have been defined to start this section, the customer
specifies required material quantity and the date when it is needed, then each supplier will define the date and the size of provision orders, considering what has been agreed in the frame agreement. In this way, the customer only sends to suppliers, information about the set of dated material requirements that it has scheduled.
5.2.4 Definition of a material requirement schedule to be sent to each supplier
Once defined its material requirement schedule, the customer has to define a material requirement schedule to be sent to each supplier. It can do it using a ranking of suppliers or defining an assignation percentage according to that has been defined into the collaboration frame agreement.
To sum up, at this point we have described the private process that the customer has to perform to implement a part of the public process whose objective is to agree with suppliers a material provision schedule at the level of master production scheduling.
5.2.5 Definition of a material provision schedule
Each supplier receives from the customer a material requirement schedule [mrs]. According to this requirement, its disaggregated product plan and the short-range forecast, through a private process, each supplier defines its master production schedule. To perform this activity, it can follow any traditional mechanism. According to previously discussed, the size of the provision lot will be defined by the supplier considering production costs, carrying cost and transport cost. Two different results could take place:
• [mrs Acceptance] Supplier can meet the customer’s requirement. If it does, supplier and customer reach a consensus in the definition of a material provision schedule at the level of master production scheduling and therefore they can continue with the next collaborative process.
• [Alternative Provision Schedule] After evaluating possible alternatives of adjustment, the supplier cannot meet the customer’s requirements. In this case, the supplier has to elaborate its feasible provision schedule, which will be sent to the customer.
In this last case, the customer receives the alternative provision schedule sent by one or more suppliers, and through a private process it analyses them. The process will map the received information using an inverse reduced material requirement planning. This is due to the data that were outputs of its system are now input data to its system. With this information, the customer will make the more convenient decisions (modifying its master production schedule, completing the remaining requirements with another supplier, and so on). Three alternatives can result of this private process:
• [Provision Schedule Acceptance] The customer accepts the provision schedule of one o more suppliers. If it does, a customer reach a consensus with its suppliers in defining a material provision schedule at the level of the master production scheduling and therefore they can continue with the next collaborative process.
• [Provision Schedule Reject] The customer rejects one or more provision schedules. • [mrs] The customer proposes an alternative material requirement schedule to one or more
suppliers.
After reaching a consensus, each enterprise has defined its master production schedule. However, it is necessary to highlight that to reach a consensus more than one iteration of the described collaborative processes will be likely needed. Besides, the customer has to coordinate the Negotiate Provision Plan with Supplier, which is required by each public process defined for each collaborative partner-to-partner relationship.
Supplier Process Customer Process Generate MPS Assign Schedules Generate MPS [Alternative MPS is required]
Accept and Register Plans [Customer MRS
accepted]
Send MRS Generate MPS
Receive MRS from Customer
Send MRS Acceptance Receive Supplier Response
Register MRS Accepted Send Alternative Provision Schedule
Generate MRP -1
Evaluate Supplier Schedule Send Reject of Plan
Receive Customer Response
Register Accepted Provision Schedule
Send Schedule Acceptance
Register Provision Schedule
MRS MRS Acceptance Alterna tive Provision Schedule Provision Schedule Reject Prov ision Schedu le Accept ance [Alternative Schedule proposed by Supplier] [MRS accepted by Supplier]
[Alternative Schedule Rejected]
Supplier Begin Customer Begin Product Disaggregate Plan Short-range Demand Forecast Customers Requirements Product Disaggregate Plan Short-range Demand Forecast Material Requirement Schedule Capacity Constraints Production Requirements Material Requirements Schedule for Suppliers
Schedule Acceptance Alternative Provision Schedule [Counter-proposal needed] [Counter-proposal needed]
Negotiate Provision Plan with Supplier 1..N
[Provision Schedule agreed] Generate MRS [Alternative Schedule Accepted] [Schedule Rejected] [Schedule Accepted]
Figure 2: Private processes and the exchanged information at level of master production schedule.
5.3 Consensus About a Replenishment Schedule
The objective of this collaborative process is that the trade partners reach a consensus in the definition of a replenishment schedule. At this level of collaboration, coincidence is expected between the partners’ hierarchical planning due to the consensus arrived into the two previous planning levels. The collaborative process for the case of relationships (n-1) is graphically represented in Figure 3.
On the supplier side, a private process starts defining its material requirement plan and carries out its capacity requirement planning. Then, the supplier defines a replenishment schedule for
the collaborating customer. Unlike the hierarchical traditional model, the lot size and the delivering dates are specified by the supplier in the replenishment schedule.
On the customer side, a private process starts defining its material requirement plan and carries out its capacity requirement planning. Once the customer receives the [Replenishment Schedule] from the suppliers, it is expected that the customer MRP match these supplier replenishment schedules. If there is no coincidence, both have to achieve again a consensus at the level of the master production schedule process. This process is the main collaborative process of the partner-to-partner model since it is sufficiently detailed and its calculus model is simple. This makes it a flexible process to reach a consensus. In contrast, traditional Material Requirement Planning Systems are very complex to be used to reach a consensus. Finally, it is necessary to explain that at both master production scheduling level and material requirement planning level of collaborative processes, the delay produced by the transport time has to be taken into account by the partner responsible for it. In case of outsourcing transport, the frame agreement has to specify who has to take into account the delay in its collaborative processes.
Supplier Processes Customer Processes
Genarate MRP
Generate CRP Generate MRP
Generate CRP
Receive Dated Material Requirements
Production Scheduling Process Production Scheduling Process Provision Order Process Provision Order Process
MPS MPS
1..N
Send Replenishment Schedule [Feasible MRP] [Changes Required] [Changes Required] [Feasible MRP] Replenishment Schedule Check with MRP
Figure 3: Private processes and the exchanged information to reach a consensus about a provision order schedule
6. EXAMPLE OF A COLLABORATIVE RELATIONSHIP (2-1)
In this section, we present the main results of a collaborative planning process curries out into a collaborative relationship (2-1) among three manufacture enterprises. This collaboration implies two partner-to-partner relationships: supplier B1-to-customer A and supplier B2-to-customer A.
The enterprise A produces a product family composed for about 65% of product P1. To produce a unity of P1, three units of material C are required.
The enterprise B1 produces a product family composed for about 60% of material C, and about 50% of it is sold to customer A.
The enterprise B2 produces a product family composed for about 40% of material C, and about 70% of it is sold to customer A.
Due to the high volume of material C that these enterprises exchange, the enterprise A has defined a partner-to-partner collaborative agreement with both suppliers.
6.1 Frame agreement
Table 2 shows the provision ranges of material C that enterprise A has agreed with enterprises B1 and B2.
Table 2: provision range of material C agreed
Agreement A-B1 min 10000
max 14000
Agreement A-B2 min 6000
max 10000
6.2 Consensus at level of aggregated production plan
Table 3 shows the results of the aggregated production planning process performed by the customer A for a time horizon of six month. Row 2 shows the production requirement of the product family. Row 3 shows the production requirement of P1 (65%). Row 4 shows the requirement of material C (three units of C by one of P1). Rows 5 and 6 show the
requirement of material C that enterprise A has defined to each supplier (enterprise B1 and B2). This information, generated by private processes of enterprise A, will be sent to each supplier attending the public process agreed with each of them.
Table 3: initial aggregated production plan and material requirement plan to each supplier defined by enterprise A
1 Periods (months) January February March April May June
2 Production requirement 11000 11500 11500 13000 11500 11000
3 DPP (P1) 0,65 7150 7475 7475 8450 7475 7150
4 Requirement of material C 3 21450 22425 22425 25350 22425 21450
5 Requirement for provider B1 0,6 12870 13455 13455 15210 13455 12870
6 Requirement for provider B2 0,4 8580 8970 8970 10140 8970 8580
Table 4 shows the results of the aggregated production planning process performed by the enterprise B1 for a time horizon of six month. Row 3 shows the production requirement of material C (60%). Row 4 shows the demand of this material (50%) imputed to the customer A. Row 5 shows the requirement plan of the material C received from the customer A that has been validated as it has been described in section 5.1.
Table 5 shows the results of the aggregated production planning process performed by the enterprise B2.
Table 4: initial aggregated production plan and provision plan agreed defined by the enterprise B1
1 Periods (months) January February March April May June
2 Production requirement 43000 43000 45000 45000 44000 43000
3 DPP (material C) 0,6 25800 25800 27000 27000 26400 25800
4 Demand customer A 0,5 12900 12900 13500 13500 13200 12900
5 Requirement customer A 12870 13455 13455 15210 13455 12870
6 Provision plan agreed 12870 13455 13665 14000 13455 12870
Table 5: initial aggregated production plan and provision plan agreed defined by the enterprise B2
1 Periods (months) January February March April May June
2 Production requirement 25000 26000 26000 26500 26000 25500
3 DPP (material C) 0,5 12500 13000 13000 13250 13000 12750
4 Demand customer A 0,7 8750 9100 9100 9275 9100 8925
5 Requirement customer A 8580 8970 8970 10140 8970 8580
6 Provision plan agreed 8580 8970 8970 11140 8970 8580
By analyzing Tables 4 and 5 we can see that on April month an exception has taken place. Here, the actions of each provider will depend of its production variables and the negotiation with the customer. Row 6 of both Tables shows the material C provision plan agreed.
6.3 Consensus at level of master production schedule
Table 6 shows the weekly requirement schedule of P1 performed by the enterprise A for January and February months.
Table 6: weekly requirement schedule of P1 performed by the enterprise A
January February
1 Periods (weeks) 1 2 3 4 1 2 3 4
2 Requirement Planned of P1 (months) 7150 7475
3 Requirement Planned of P1 (weeks) 1788 1788 1788 1788 1869 1869 1869 1869
4 Short Time Forecast of P1 (weeks) 1900 1900 1800 1800 1800 1800 1800 1800 Table 7 shows the respective forecasted production orders defined by enterprise A. Here, due to there have not orders compromised with customer, all weekly requirement of product P1 have been dated to the start of each week.
Table7: Forecasted orders
Date Demand t1 02/01/02 1900 t2 08/01/02 1900 t3 15/01/02 1800 t4 22/01/02 1800 t5 29/01/02 1869 t6 05/02/02 1869 t7 12/02/02 1869 t8 19/02/02 1869
The production requirements were defined as has been described in section 5.2. considering initial stock = 0, production lot = 800 units, and safety stock = 100 units. The resulting production requirements are shown in Table 8.
Table 8: production requirements
Date Production Inventory
t1 02/01/02 3*800 500 t2 08/01/02 2*800 200 t3 15/01/02 3*800 800 t4 22/01/02 2*800 600 t5 29/01/02 2*800 400 t6 05/02/02 2*800 200 t7 12/02/02 3*800 800 t8 19/02/02 2*800 600
The dated material requirement defined following the algorithm described in section 5.2 is showed in Table 9.
Table 10 shows the dated requirement of material C defined by enterprise A to each provider.
Table 10: dated requirement of material C
Provider B1 Provider B2
Date requirement Date requirement
t1 26/12/01 7200 t2 02/01/02 4800
t3 09/01/02 7200 t4 16/01/02 4800
t5 23/01/02 4800 t6 30/01/02 4800
t7 06/02/02 7200 t8 13/02/02 4800
The requirements defined on Table 10 will be received for each provider. These requirements will be considered as compromised orders with the customer at the time of defining the master production schedule.
Once a consensus at the level of master production schedule has been arrived, the next collaborative stage is to define and agree a replenishment schedule.
7. INFORMATION SYSTEMS ISSUES FOR SUPPORTING COLLABORATIVE MODELS
Some business models, such as Vendor-Managed Inventory models, Continuous Replenishment models or some auction models, have been supported by traditional business-to-business (B2B) relationships. In these B2B relationships, systems of two or more
Table 9: production orders for P1
Date Production orders
t1 26/12/01 7200 t2 02/01/02 4800 t3 09/01/02 7200 t4 16/01/02 4800 t5 23/01/02 4800 t6 30/01/02 4800 t7 06/02/02 7200 t8 13/02/02 4800
enterprises are oriented to support business transactions, in which enterprises do not agree contracts but only exchange business information. These transactions include traditional purchase orders and other information such as fulfillment, demand forecasts, bids in a real-time auctions, inventory replenishment, establishing new accounts and account lookup and maintenance. Historically, this integration has been accomplished through manual tasks, via phone and fax, and/or via EDI (Electronic Data Interchange) applications.
However, according to the collaborative business model presented above, the management of it implies more than simply sharing forecasts or executing interchange transactions. Therefore, to support this type of collaborative models, companies and their trading partners require moving to collaborative B2B relationships. In a collaborative B2B relationship, the involved companies integrate their information systems to jointly execute public business processes sharing decision-making information. The goal of the business processes and business documents defined in a collaborative model is that trading partners agree on purchase orders, forecast plans and replenishment plans through collaborative decision-making processes.
New information technologies, such as Internet, web-based applications and distributed systems provide new opportunities for aligning public business processes allowing for collaborative B2B. B2B specifications are another key enabler of collaborative B2B relationships. These specifications like ebXML (ebxml.org), RosettaNet (rossetanet.org) and OAGIS (oagis.org) are based on XML, an Extensible Markup Language defined by W3C consortium (Bray et al., 2000). It was originally designed to meet the challenges of large-scale electronic publishing, but now it is playing an important role in B2B integration and Enterprise Application Integration (EAI). In this context, the success of collaborative B2B depends on effective information systems that:
• Support the management of public business processes.
7.1. Management of Interchanged Business Information
From the information system point of view, to exchange business information with their trading partners an enterprise has to face two issues: (1) how to access it and (2) how to understand its meaning (Zhao and Sandahl, 2003). This is a challenging task because a collaborative B2B relationship implies the communication between heterogeneous information sources that belong to different enterprises with their own systems and culture. The problem of accessing business information from different information sources that run over different operating systems has been solved using middleware standards supporting distributed computing, like RMI, CORBA, and DCOM; and database connectivity, like ODBC and JDBC for relational databases. In addition, the XML standard was created to provide a way to create extensible formats for describing structured data in electronic documents and to express rules about those data.
The problem of how to understand the business information is still a problem in B2B area. B2B XML-based specifications propose to bypass the problem of semantics by getting everyone everywhere to use the same meaning. But, XML itself does not guarantee that thousands of business partners will understand a particular document sharing the same vocabulary and meaning before a document can be exchanged (Caliusco et al., 2003a). Adding semantics to data give us a better idea of what the information means, removing as much ambiguity as possible (Uschold and Gruninger, 1996). Semantics refers to the meaning of terms used in the information interchange between both enterprises. An effective collaborative B2B relationship between trading partners will not be success until a collaborative environment to support the semantic integration be developed. To do that, ontology-based approaches are arisen. An ontology is ‘‘a vocabulary of terms and some
specifications of their meaning through axioms and properties using a logic-based representation language”. The main requirements, that an ontology environment has to fulfill to support the interoperation between systems at semantic level in a B2B relationship, are (Caliusco et al., 2003b): (1) a collaborative environment and methodology to guide the ontology development, (2) a support for language interoperability, (3) a support for mapping process based on mapping between terms taking into account their meaning and (4) a support for ontology versioning and change detection.
7.2 Management of Public Business Processes
From the public business process management point of view, collaborative models impose several requirements for the information systems supporting collaborative B2B relationships. Autonomy is a first requirement. This implies systems should allow enterprises to behave as autonomous entities, hiding their internal decisions, private processes and private systems. Therefore, each enterprise should implement these information systems in an independent way. This lead to the second requirement: the use of B2B business process specifications, such as ebXML BPSS (ebxml.org), to allow different partners systems interpret in a same way each public business process definition. Also, the integration of the partner systems is achieved by using B2B specifications to implement and exchange messages. In this way, partners systems can jointly execute the agreed public business processes. A third requirement is the decentralized management by the partners of these agreed public business processes. This decentralization leads to the fourth requirement: peer-to-peer interactions among the systems supporting B2B relationships. This means systems have to interact in a direct way without the mediation of third party systems. A fifth requirement is supporting negotiation within the collaborative decision-making processes of the collaborative models.
Workflow and Web Services Composition approaches have been proposed to model and manage public processes in B2B relationships. However, they present shortcomings to achieve the above requirements, as it is discussed in (Villarreal et al., 2003b). Another suitable approach proposed in (Villarreal et al., 2003b) is the use of Interaction Protocols (IP) to model and manage public processes. In the context of collaborative B2B relationships, interaction protocols represent interactions among enterprises within a business process that they jointly carry out to achieve a goal. The objective of interaction protocols is to abstract public processes from the services to be invoked within each enterprise for executing their private processes supporting public processes. An Interaction Protocol (IP) describes a high-level communication pattern through an admissible sequence of messages among enterprises having different roles. Therefore, an interaction protocol is defined by the partners’ roles, the messages that they interchange, the reference of the business document representing the message content, and by choreography of messages. This choreography defines the message control flow and conditions and deadlines on messages.
Interaction Protocols have a high abstraction level, because their messages represent interactions modeling the public processes. IP messages are implemented using a low-level communication protocol, such as the message services proposed by some B2B specifications like ebXML or RosettaNet. For partner systems understand IP messages in the same way, IP messages have an associated semantics. Therefore, there is a set of message types, which can be used to define IP messages. These message types are based on the communicative acts (based on the speech act theory) defined by FIPA ACL (Agent Communicative Language). Messages based on communicative acts allow representing intentions of the enterprises within the processes. Intentions are important to support and describe negotiations.
For defining and modeling public business processes based on IPs, two types of modeling languages are required: a graphical modeling language and a textual modeling language. The
former has the objective of allowing business process designers to define and understand graphically IP definitions representing public processes. The second language has to be processable by software allowing enterprises to exchange IP definitions, which then can be processable and understood by the partner systems for the execution of the IPs. In (Villarreal et al., 2003b), AUML has been proposed as modeling language to specify graphically public business processes based on IPs. Also in (Villarreal et al., 2004), ebXML BPSS has been proposed as machine-processable language. Definitions of IPs in AUML can be translated to ebXML BPSS document for executing public business process based on IPs.
8. CONCLUSIONS
This paper described a partner-to-partner collaborative model which is appropriate for a manufacturing enterprise that participates in two or more supply chains since this model is based on a decentralized management of the supply chain. The model proposes collaborative processes with consensus at three levels: aggregated production panning, master production scheduling and provision order schedule. These collaborative processes were developed based on the following principles: The production plan of the supplier depends on the production plan of the customer. The suppliers production capacity is finite. An order lead time is not a customer parameter but it is a decision variable of the supplier. The provision lot is not defined by the customer but it is a decision variable of the supplier. The supplier is responsible for preventing material stock out.
A distributed execution of these processes is carried out by partners to reach a consensus. The distributed execution is based on a previously settled agreement that sets up the guidelines and rules of the collaborative relationship. The consensus is feasible of reaching because the
proposed calculation models, especially at level of master production scheduling, they are sufficiently detailed and simple.
The main advantage of this model is that it allows the enterprises to carry out a continuous collaborative process between them without loosing their autonomy.
From the information system point of view, based on the functional requirement specified, a peer-to-peer information systems seems to be the most appropriate to implement this model. It reflects the idea of a physical distribution of the resources used by information system. Each partner manages its own information and defines which information has to be shared with their partners allowing the enterprise information autonomy.
On the other hand, the peer-to-peer information system is more suitable to support the decentralized workflow management. This is due to the fact that each enterprise can implement a workflow that manages their activities of the collaborative process it is responsible for, and to coordinate with its trading partners the execution of collaborative processes. Collaborative workflow systems must be integrated with other systems of the enterprise to obtain information from them, and with the intra-enterprise workflow systems. Future works will be oriented to develop both new collaborative processes that the enterprises can carry out to increase their collaboration and information technology to support these collaborative processes based on agent software technology. In this direction, we are working to develop supports for collaborative monitoring and control processes, collaborative workflows and decisionflow management, and ontological mapping.
References
Aviv, Y (2001). The Effect of Collaborative Forecasting on Supply Chain Performance Management Science, 47 (10) 1326-1343.
Bond, B. Dial C for C-Commerce. GartnerGroup Executive Edge, [Online serial] Issue 06/2000, Available FTP: http://www.ee-online.com/jun2000.
Bray, T.; Paoli, J.; Sperberg-McQueen, C. M. and Maler E. (October, 2000). Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation.
Caliusco, Ma. Laura, Galli, Ma. Rosa and Chiotti, Omar (2003a). “Ontology Role in Collaborative Business-to-Business Relationships.” XXIX Conferencia Latinoamericana de Informática (CLEI 2003) La Paz, Bolivia. September, 2003.
Caliusco, Ma. Laura, Galli, Ma. Rosa and Chiotti, Omar (2003b). “Ontology and XML-based specifications for collaborative B2B relationships.” III Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería de Conocimiento (JIISIC). Valdivia (Chile). November 2003.
Collaborative Planning, Forecasting, and Replenishment VICS Subcommittee. “CPFR: Implementation Guidelines”, http://www.cpfr.org/, (1998).
Corcho, O. and Gómez-Perez, A. (2001). Solving integration problems of e-commerce standards and initiatives through ontological mappings. IJCAI01 Workshop on Ontologies & Information Sharing. Cui, Z, Jones, D and O’Brien, P. (2001). Issues in Ontology-based Information Integration. IJCAI01 Workshop on Ontologies & Information Sharing.
Chakravarty, A. (2001) Market Driven Enterprise: Product Development, Supply Chains, and Manufacturing. John Wiley and Sons.
Chapman, L. and Petersen, M. (May 2000). Demand Activated Manufacturing Architecture (DAMA). Model for Supply Chain Collaboration. International Conference on Modeling and Analysis of Semiconductor Manufacturing.
Chen, Q, Hsu, M. (2001) Inter-Enterprise Collaborative Business Process Management. Proc. of 17th International Conference on Data Engineering, Germany.
Dai, Q and Kauffman, R. J. (2001). Business models for Internet-based e-procurement systems and B2B electronic markets: an exploratory assessment. Proceeding of the 34th Hawaii International Conference on System Sciences.
Dominguez Machuca, J.A., García González, S., Dominguez Machuca, M.A., Ruíz Jiménez, A., and Alvarez Gil, M.J.(1995) Dirección de Operaciones. Aspectos tácticos y operatives en la producción y los sercicios. McGraw-Hill
ebXML, http://www.ebxml.org.
Gruber, T. R. (1993). Toward principles for the design of ontologies used for knowledge sharing. Originally in N. Guarino & R. Poli, (Eds.), International Workshop on Formal Ontology, Padova, Italy. Revised August 1993. Published in International Journal of Human-Computer Studies, special issue on Formal Ontology in Conceptual Analysis and Knowledge Representation (guest editors: N. Guarino and R. Poli) Available. http://ksl-web.stanford.edu/KSL_Abstracts/KSL-93-04.html
Harmon, P., Rosen, M., Guttman, M. (2001) Developing E-business Systems and Architectures – A Manager’s Guide CT: Morgan Kaufmann Publishers
Kärkkäinen, M., Främling, K., Ala-Risku, T. (2002). Integrating material and information flows using a distributed peer-to-peer information system – APMS'2002 Conference, Eindhoven, The Netherlands.
Klen, A.P., Spinosa, L.M., Rabelo R.J., and Ferreira, A.C. (November, 1998). Integrated Logistics Management Support System: An Advanced Coordination Functionality for the Virtual Environment. In proceedings of the 5th International Workshop on Intelligent Manufacturing Systems, IMS'98, Gramado, Brasil,
Lee, H L., Whang, S., (1999). Sharing Information to Boost the Bottom Line. Available FTP:
http://www-gsb.stanford.edu/research/reports/1999/whang_lee.html
Lee, H., Padmanabhan, P. And Whang, S. (1997). The bullwhip Effect in Supply Chains. Sloan Management Review, 38.93-102.
Malone, T. and Laubacher, R. (1998). The Dawn of the E-Lance Economy. (September-October, 1998). Harvard Business Review, 145-152.
Mentzer, John T.; Foggin, James H. and Golicic, Susan L. (September/October 2000). Collaboration: The Enablers, Impediments, and Benefits. Issue of Supply Chain Management Review.
Parameswaran, M., A. Susarla, A. B. Whinston, (July 2001) P2P Networking: An Information Sharing Alternative, IEEE Computer, 1-8.
Quinn, F. (January, 2001). Collaboration: More Than Just Technology. Ascet Volume 3. RosettaNet. Retrieved from http://www.rosettanet.org
Simchi-Levi,D.P.Kaminsky y E. Simchi-Levi, “Designing and Managing the Supply Chain”, Mc Graw Hill, (1999)
Sipper, D. and Bulfin, R. (1997). Production: Planning, Control and Integration. McGraw-Hill
Småros, J. and Främling, K. (September 2001)Peer-to-peer information systems - an enabler of collaborative planning, forecasting and replenishment, Logistics Research Network 6th Annual Conference.
The Open Applications Group XML Project Team. OAGIS Release 8.0. (May, 2002).
Uschold, M. and Gruninger, M. (1996). Ontologies: principles, methods, and applications. Knowledge Engineering Review, 11(2):93–155
Villarreal, P.; Caliusco, M. L.; Salomone, E.; Galli, M. R; Chiotti, O. (August 2001) Support for Collaboration and Negotiation in SC Management. World Conference on Production and Operation Management, POMS 2001, Brazil.
Villarreal, P.; Caliusco, Ma. L.; Zucchini, D.; Arredondo, F.; Zanel, C.; Galli, Ma. R.; Chiotti, O. (2003a) Chapter 6: “Integrated Production Planning and Control in a Collaborative Partner-to-Partner Relationship”. Managing e-Business in the 21st Century. Edited by Sushil Sharma and Jatinder Gupta. Heidelberg Press, 2003. pp 91-110.
Villarreal, P.D, Salomone, E. and Chiotti, O. (2004) “B2B Relationships: Defining Public Business Processes with Interaction Protocols”. Journal of Sociedad chilena de Ciencia de la computación. To appear.
Villarreal, P.D, Salomone, E. and Chiotti, O. (2003b) “Managing Public Business Processes in B2B Relationships using B2B Interaction Protocols”. XXIX Conferencia Latinoamericana de Informática (CLEI 2003) La Paz, Bolivia, Septiembre 2003.
Welty, B., and Becerra-Fernandez, I. (2001) Managing Trust and Commitment in Collaborative Supply Chain Relationships. Communications of the ACM, Vol. 44, No. 6, 67-73.
Wijegunaratne I. and G. Fernández, (1998). Distributed Applications Engineering. Springler.
WorkFlow Management Coalition (WFMC). Workflow: An Introduction. WfMC General Publications. http://www.wfmc.org, (2001).
Zhao, Y. and Sandahl, K. (2003) Potential Advantages of Semantic Web for Internet Commerce. Proceedings of the 5th International Conference on Enterprise Information Systems, Angers, France, April 22-26, 2003. Available on-line http://www.ida.liu.se/~yuxzh/doc/iceis-030120.pdf
