Computer Assembly

Abstract

The computer industry is a typical example of a material constrained supply chain. The main bottleneck of demand fulfilment is the availability of the electronic components, e.g. disk drives, processors, memory etc. This case study is based on an actual APS implementation project at a large international computer manufacturer. Four modules of the APS system by i2 Technologies, which has been acquired by JDA in 2010 (see Chap. 16 and Sect. 18.2), are implemented, supporting the demand planning process, the mid-term supply planning process, the short-term supply planning process and the order promising process. The following case study describes in detail

• The computer assembly supply chain, the product structure and the assembly process (Sect. 23.1)

• The scope and objectives of the APS implementation project (Sect. 23.2)

• The planning processes being supported by the APS system, i.e. demand planning, operational planning, order planning, order promising and the integration of the applied i2 planning modules with the existing SAP R/3 system (Sect. 23.3)

• Results and lessons learned from the APS implementation (Sect. 23.4).

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

The computer industry is a typical example of a material constrained supply chain. The main bottleneck of demand fulfilment is the availability of the electronic components, e.g. disk drives, processors, memory etc. This case study is based on an actual APS implementation project at a large international computer manufacturer. Four modules of the APS system by i2 Technologies, which has been acquired by JDA in 2010 (see Chap. 16 and Sect. 18.2), are implemented, supporting the demand planning process, the mid-term supply planning process, the short-term supply planning process and the order promising process. The following case study describes in detail

• The computer assembly supply chain, the product structure and the assembly process (Sect. 23.1)

• The scope and objectives of the APS implementation project (Sect. 23.2)

• The planning processes being supported by the APS system, i.e. demand planning, operational planning, order planning, order promising and the integration of the applied i2 planning modules with the existing SAP R/3 system (Sect. 23.3)

• Results and lessons learned from the APS implementation (Sect. 23.4).

1 Description of the Computer Assembly Case

1.1 Computer Industry Supply Chain

The typical supply chain in the computer industry consists of five main stages: suppliers, computer manufacturers, logistic service providers, deployment partners and customers. Figure 23.1 depicts the complete computer industry supply chain.

Fig. 23.1

Overview of the computer industry supply chain

The suppliers supply electronic and mechanical components for the system board and computer assembly, external units like printers and monitors, accessories like keyboard and mouse, software, manuals etc. In many cases there are multiple sources for one type of components like disk drives and memory (disk drives supplied by one supplier may be substituted by disk drives from an alternate supplier if these are qualified for the corresponding configuration). The computer industry is a material intensive industry. In general approximately 15–20 suppliers constitute 80 % of the procured value, 30–40 suppliers represent 95 % of the procured value. Some suppliers provide simple assembly services. In the supply chain shown in Fig. 23.1 the housing supplier receives power supplies from two alternate sources and assembles the power supplies into the housings before shipping the housings to the computer assembly site.

The computer manufacturing process itself consists of two main parts: the assembly of the system board and the assembly of the system unit. There are three options to organize this part of the supply chain:

• 1. System board assembly and system unit assembly are done in the same assembly site.

• 2. System board assembly and system unit assembly are done in separate assembly sites, but belong to the same legal entity.

• 3. System board assembly and system unit assembly are done in separate assembly sites and belong to different legal entities.

In this case study we assume option 1, as depicted in Fig. 23.1. Typically, the computer manufacturer runs a separate distribution center for external units like printers and monitors that are procured from external suppliers.

The transport between assembly sites and the deployment partners is executed by logistic service providers. There are three kinds of deployment partners: logistics service providers (forwarders) running a distribution center, system integrators and consumer market stores. In most cases products are shipped by a forwarder from the assembly site and from the distribution center for external units like printers and monitors directly to a distribution center, where the separate line items of a customer order are merged. From there, complete customer orders are shipped.

There are three cases for the shipment of customer orders, depending on the type of customer:

• Orders by small and medium business customers are shipped directly from the distribution center to the customer’s site.

• Big corporate customers like banks and insurance companies typically place orders with a volume of up to several thousand PCs (e.g. in order to equip all offices in a specific region). These big orders are often executed by a system integrator, who takes over responsibility for the procurement and the installation of the computing devices (PCs, servers, monitors, printers, networks, modems etc.).

• For the consumer market, department stores and consumer market stores place big orders (in the range of 10,000–20,000 units) that are shipped to their distribution centers and are distributed from there to the individual outlets.

As indicated by the dashed arrows in Fig. 23.1 additional direct distribution paths from the computer manufacturer to the consumer market and to small and medium businesses will be established, supported by e-business strategies.

1.2 Product Structure

The product portfolio contains consumer PCs, professional PCs, servers and notebooks. Within these product families, two types of products can be distinguished. Fixed configurations have an individual material code that can be referred to in customer orders. Normally, fixed configurations are made to order. However, in order to offer very low lead-times to the market (for example 2 days) a make-to-stock policy can be applied. This requires a very good understanding of future demand of these market segments, i.e. a high forecast accuracy.

Open configurations can be freely configured by the customer (configure-to-order). An open configuration is identified by the base unit, specifying the housing and the system board. The customer can then choose from a selection of processors, disk drives, network, video and sound controllers and can define the size of the main memory. During the configuration process specific configuration rules have to be fulfilled. Examples of hard configuration constraints are “the number of controller cards may not exceed the number of extension slots of the system board” and “the selected processor type must be compliant with the system board”. An example of a soft constraint is “the number of selected CD-ROM drives should not exceed one”. Only the base unit and the components have individual material codes. The complete configuration is either identified by the material code of the base unit (this requires a hard pegging of production orders to the customer order) or a new material code is generated as final step of the configuration process.

1.3 Computer Assembly Process

The computer assembly process is divided into two main parts (as shown in Fig. 23.2):

• The assembly operations

• The testing and packing operations.

Fig. 23.2

Detailed computer assembly supply chain

The first step is the assembly of the system board. Boards are assembled in batches of 100–1,000 pieces. The board assembly lead-time for one batch is roughly half a day. There are approximately 20 different system boards for PCs and another 20 for servers. The system boards for notebooks are procured.

The second step is the configuration of the board. In this step, the processor assembly—consisting of the processor and the cooling—and the memory are put onto the board.

The third step is the kitting and the loading of the disk drive with the selected software. The kitting operation collects all selected components—disk drives, controller cards for network, video and sound etc.—into a box that is called the kit. The kit, the housing and the power supply—which are not part of the kit—are used in the fourth step, the actual assembly of the computer.

If the customer has special requests—e.g. specific controller cards that have to be assembled into the computer—a separate customization step follows the computer assembly operation. After that, the computer is tested and packed. In the final packing operation the keyboard and accessories as mouse, manuals, software, cables etc. are added.

The complete lead-time is 24–48 h. The most time consuming operations are the software loading and the test operations. There are two production types: small batches (usually below 200 PCs) are assembled in a job shop, large batches (above 200 PCs) are assembled in a flow shop. Please note that kitting takes place only for the job shop production type. In the flow shop, the material for the complete batch is provided along the production line.

Table 23.1 summarizes the classification of the computer industry according to the supply chain typology introduced in Chap. 3.

Table 23.1 Supply chain typology for the computer industry

2 Scope and Objectives

The target of the APS implementation project described in this case study is to improve the business performance of the computer manufacturer. For this purpose the business performance is measured by three key performance indicators (see Chaps. 2 and 15):

• The forecast accuracy shall be improved from 50 to 80 %.

• The delivery on time shall be improved from < 80 to > 90 %.

• The inventory turns shall be improved from 9.3 to 20.

The following planning processes are in the scope of the project and shall be supported by the APS by i2 Technologies:

• Demand planning, consisting of unit planning and component planning

• Operational planning (mid-term supply planning), consisting of the Weekly SCM Workflow (forecast netting, master planning, allocation planning) and the SAP MRP run

• Order planning (short-term supply planning), consisting of the Daily SCM Workflow (forecast netting, master planning and allocation planning) and demand supply matching

• Order promising .

The following modules of i2 were implemented:

• Demand Planner (DP)¹ including PRO (Product Relationship Object, a module of demand management to support the component planning process) supporting the demand planning processes

• Factory Planner (FP) supporting the demand supply matching process

• Supply Chain Planner (SCP)² supporting the master planning process

• Demand Fulfillment (DF)³ supporting the forecast netting, the allocation planning and the order promising processes

• RhythmLink (RL)

• Active Data Warehouse (ADW)

• Optimization Interface (ROI)

• Collaboration Planner (RCP).

The i2 modules are integrated with the existing SAP R/3 system, i.e. MM Materials Management, SD Sales and Distribution and PP Production Planning. Figure 23.3 summarizes the supported processes and the data flows between them.

Fig. 23.3

Computer assembly planning processes

⁴

All implementations and process designs were set productive by July 2001. The project started in 1999, the total implementation time was scheduled for 18 months, including a 2 months phase in which the APS implementation project had been defined and the APS software was selected.

3 Planning Processes in Detail

3.1 Demand Planning

The demand planning process is running weekly. It determines the forecast on unit level (i.e. finished goods) and on component level. The implementation was structured into three steps. Step 1 covered unit planning for a subset of all products, i.e. planning of complete computer systems (units), Step 2 extended unit planning to all products and Step 3 supports component planning.

The goal of the implementation of i2 Demand Planner is a more accurate forecast: the forecast accuracy shall be improved from 65 to 75 %.

The following technical “enablers” of i2 Demand Planner help to improve forecast accuracy:

• 1. i2 DP provides a common database to maintain all input and output data of the demand planning process.

• 2. i2 DP supports a collaborative planning process, where all departments participating in the demand planning process find their own planning results and are supported in the integration of the various plans to one collaborative demand plan.

• 3. All needed data like shipments and orders are maintained within i2 DP and can be used within the planning process.⁵

• 4. All groups participating in the demand planning process can define their own views on the data.

• 5. Forecast accuracy is measured based on the i2 DP database, using a well defined uniform method that has been defined within the project.

3.1.1 Unit Planning

Table 23.2 shows the levels of the geographic and the product hierarchies used in the demand planning process. The numbers given in parentheses specify the number of instances on that level.

Table 23.2 Structure of the geographic and product hierarchies

All_Geo is the root of the geographic hierarchy. The area level represents geographically defined areas in the world, e.g. Europe, Middle East and Africa (EMEA); America; Asia Pacific. The regional level represents sales regions within an area, e.g. Germany, France and the UK are regions within the EMEA area.

All_Prod is the root of the product hierarchy. The product segment level divides the product hierarchy into sub-hierarchies for PCs, servers, notebooks and the planned components (see next subsection). On the product group level each sub-hierarchy is split into multiple product groups, e.g. the PC sub-hierarchy is split into consumer PCs and professional PCs, and the server sub-hierarchy into small servers and large servers. The next level is the product family that groups products which are in the same performance class (low-end consumer PCs vs. high-end consumer PCs). The model line groups PCs and servers by the type of the housing. The sub model line groups PCs and servers within one model line by the type of the system board. The SKU level is normally not planned for units (refer to the next section about component planning for explanation why the SKU level is in the product hierarchy).

The time dimension is structured into Year, Quarter, Month and Week. The weekly level is not used for the unit planning, but for the component planning. The time horizon starts 2 years before the start of the current fiscal year and covers 12 months into the future. Thus, it is possible to maintain 2 years of historic data in the i2 DP database. This provides a good basis to setup stochastic forecasting methods including seasonal patterns. However, 2 years of historic data are currently not available. The average product life cycle is about 5 months. Thus, a large manual effort is required to define the historic substitution rules that are used to map historic data of products that have reached their end of life to living products.

The following data rows have been defined and are maintained in the i2 DP database:

• Actual data: Three types of actual data are maintained: Shipments (quantities related to shipment date), orders (quantities related to customer requested date) and confirmed open orders (quantities related to confirmed date).

• Budget plan: The budget plan is updated yearly and is valid for the current fiscal year.

• Sales forecast: The sales forecast is created monthly and covers 6 months. The database contains four separate rows for the sales forecast, representing the current planning round and the last three planning rounds.

• Plant forecast: The plant forecast is created weekly by the planners in the production sites. The database contains four separate rows for the plant forecast, representing the current planning round and the last three planning rounds.

• Collaborative forecast: The collaborative forecast is determined monthly by a collaborative process in which sales, product management, procurement and the production sites participate.

There is a yearly, monthly and weekly planning cycle as shown in Fig. 23.4. Once per year, the budget plan is created, covering the next fiscal year (12 months horizon). Every month, the sales planners update the sales forecast. For that purpose, i2 DP has been installed in all regional sales offices (approximately 50). In the second step, the sales forecast is reviewed by the planners in the plants; the result of this step is the plant forecast. In a final step, a collaborative forecast is created based on the sales and the plant forecast. All three types of forecast cover 6 months. The collaborative forecast is adjusted every week by the planners in the plants, resulting in a weekly plant forecast. The weekly plant forecast is the basis for the weekly component planning, that is described in the next subsection.

Fig. 23.4

Planning processes supported by i2 Demand Planner

3.1.2 Component Planning

The business environment of this computer manufacturer was selected to be build-to-order and configure-to-order for the main part of the business. As the consequence of this decoupling point decision the main purpose of the monthly and weekly forecasting processes is the creation of an accurate forecast on component level (Fig. 23.5). The focus of the component planning process is therefore to generate a supplier forecast for all dependent components derived from the unit forecasts. Out of the approximately 2,000 components, 600 components are considered during component planning (A-parts). The planned components belong to the material groups processors, memory, disk drives, controllers, housing and power supply.

Fig. 23.5

Order lead-time vs. component lead-time

An important aspect of component planning in the computer industry is the specification of particular components by large customers. For example, a large customer makes a contract (forecast) of 5,000 PCs which are configured to meet the IT-requirements of that customer and shall be delivered over 5 weeks (1,000 PCs a week). In this case, a component forecast can automatically be derived from the collaborative forecast by exploding the bill of materials of the particular configuration. The other standard case is that a PC is configured during order entry—in this case the sales forecast does not specify a particular configuration.

In order to meet these two requirements—fixed specification of components (build-to-order) vs. online configuration of components at order entry (configure-to-order)—the following procedure is applied to derive a component forecast from the collaborative forecast:

• 1. The collaborative forecast has to be split into (1) forecast related to fixed configurations and (2) forecast related to open configurations (that are still to be configured).

• 2. For forecasting fixed configurations, the bill of materials of the fixed configuration is being exploded.

• 3. For forecasting open configurations, the following steps are followed:

  • (a) So-called mappings are defined that map some planned instances on finished goods level (e.g. a model line) onto planned components (e.g. disk drives, processors etc.). A mapping is established between a planned item A on finished goods level and all components C that can be configured into products of type A.

  • (b) The distribution of the forecast on some planned item A on finished goods level over all components related to A by some mapping is defined by attach-rates (i.e. distribution factors). The actual planning process is to determine these attach-rate factors.

• 4. The total component forecast of a component is derived by adding the forecast from Step 2 and Step 3.

This component planning procedure is supported by i2 PRO (Product Relationship Object).

3.2 Operational Planning

Operational Planning consists of the Weekly SCM Workflow and a consecutive MRP run in SAP not described in detail here.

3.2.1 Weekly SCM Workflow

The Weekly SCM Workflow consists of forecast netting, master planning and allocation planning and serves two purposes:

• 1. It calculates the total supply and capacity needed to fulfill the demand within the planning horizon and forms the basis for negotiations with suppliers and purchasing decisions.

• 2. It constrains the demand based on the feasible supply and serves as a medium to communicate deviations of forecast and availability.

The demand planning process generates the forecasts for all products and components. This forecast is updated weekly and is netted against the actual orders received (forecast netting process, see Fig. 23.3). In the short-term the forecast for certain products or customers could already be realized in the form of actual orders. Therefore the remaining forecast has to be determined by a netting of actual orders against their forecast to keep a constant demand signal for the master planning process. The forecast is netted on the given level from the demand planning process, i.e. on end item level for fixed configurations and on component level for open configurations. The master planning process receives the netted forecast and actual orders and creates a fulfilment plan for the demand (actual orders and netted forecast). The fulfilment plan is then allocated to the customers according to the received customer orders and their netted forecast values.⁶ This total number can now easily be compared to the original forecast.

The Weekly SCM Workflow is executed twice per week. In a first run the updated forecast plan from the demand planning process is taken and a fulfilment plan is generated publishing reports with defined problems in the supply chain. After the first run the exception handling starts and modifications are made to supply and demand data to solve the problems. During the Weekly SCM Workflow, the planners take the following actions:

• Decisions about sourcing options (sourcing from multiple suppliers, sourcing from multiple plants, use of alternate parts)

• Generation of supply requirements based on the netted forecast, including safety stock management decisions

• Generation of a constrained demand plan on forecasted item level based on the netted forecast and the actual customer orders on hand

• Generation of production requirements for make-to-stock forecast

• Decisions about forecast shifts from one product to another due to supply constraints.

The modifications have to be finished before the second run starts. The second run then finalizes the planning cycle with updated results from the exception handling. After a final review the plan is accepted and released.⁷

On the one hand side the master plan defines the minimum purchasing volume that is to be ordered during the next weeks based on the constraints, i.e. demand, material supply and capacity. The capacity model that is applied to master planning is quite simple, as it is based on the number of computers that can be assembled per day. On the other hand side, the weekly master plan is the basis for order promising. Thus, the master plan captures the maximum order volume that can be promised during the next weeks.

The master planning process is implemented based on i2 Supply Chain Planner. Forecast netting and allocation planning are supported by i2 Demand Fulfillment. Only planned components, planned configurations on end item level and finished goods for which orders exist are represented in the master planning process.⁸

3.3 Order Planning

The Order Planning consists of Daily SCM Workflow and the Demand Supply Matching Process.

3.3.1 Daily SCM Workflow

The purpose of the Daily SCM Workflow is to generate latest ATP (Available To Promise)⁹ information for online order promising. It represents actual and future availability of supply and capacity that can be used to accept new customer orders. The promises should be given based on the availability of the planned components and guarantee high delivery on time. The daily planning run ensures an up to date ATP picture, reacts on changes in base data (e.g. BOMs) and handles exceptions that could not be foreseen in the Weekly SCM Workflow following pre-defined business rules. The process runs in batch mode without user interaction.

The Daily SCM Workflow—similar to the Weekly SCM Workflow—generates a fulfilment plan based on the released forecast figures from the weekly planning cycle. In the allocation planning process the fulfilment plan is allocated to the customer hierarchy (see also Chap. 9). The customer hierarchy is a sub-hierarchy of the geographic hierarchy used in the demand planning process. Currently, the customer hierarchy contains the root top_seller and one node for each sales region (Fig. 23.6). The allocation planning processes allocates the ATP to the nodes of the customer hierarchy, according to the following rules:

• The quantities planned in the master plan for pre-defined fixed configurations are allocated to the sales regions according to the sales forecast. The following table shows an example for one selected week (using the allocation rule per committed, refer to Chap. 9):

  Table 3

• The quantities planned in the master plan for open configurations are allocated on component level at the root of the customer hierarchy (top_seller).

Fig. 23.6

Customer hierarchy used for allocation planning

The allocations are called allocated ATP (AATP). The ATP and the allocations are provided to the order promising process and are given as feedback to the demand planning process (Fig. 23.3). Thus, the demand planners have the overview over the ATP quantities that are allocated to them compared to what they have forecasted. This information can be used to direct demand according to the ATP situation, e.g. by suggesting alternate products to the customers driven by availability.

3.3.2 Demand Supply Matching

In addition to the Daily SCM Workflow there is a more detailed planning process on factory level that runs daily (see Fig. 23.3). This process is called the Demand Supply Matching Process (DSM). The DSM process plans the production and material assignment of all customer orders and the net forecast for build-to-stock products based on the complete bill of materials as being maintained by SAP. Thus, DSM checks the demand and supply situation for all parts—whereas Master Planning only checks parts that are planned by the demand planning process as described above (A-parts).

The DSM process is executed twice per day by a group of planners, representing purchasing, order management and production. These planners review the current demand and supply situation, check options to resolve late order problems, try to improve the supply situation by moving-in scheduled receipts in coordination with the suppliers, and simulate the impact of moving-in of orders. Execution is not triggered directly by the DSM process. To close the loop to execution which is triggered by SAP a part of the late orders is transferred to SAP with a new due date. The new due date generates a new manufacturing order to a later date in SAP. The demand supply matching process is implemented based on i2 Factory Planner.

3.4 Order Promising

The orders enter the system through the order entry process and are promised by the order promising process. To promise a new customer order the order starts searching for allocated ATP in the dimensions time, seller and product (refer to Chap. 9). Several consumption rules define how a new order can find ATP. The promising policies assigned to the orders define if the order is promised e.g. as a whole or in several partial deliveries. Again, one must distinguish between fixed configurations and open configurations:

• Let us assume an order is received from a customer in France for x units of fixed configuration f with a request date for week w. The order promising process checks the quantity for the fixed configuration f that is allocated to France in week w; let us call this a. If the ordered quantity x is less than the allocated quantity a the order receives a due date in week w. If this is not the case, i.e. x > a, then additional ATP is searched in the preceding weeks—even if ATP is available in week w at other nodes of the customer hierarchy, e.g. Germany and the UK. This consumption rule ensures that quantities that have been planned by some region are reserved for orders coming from customers of that region.

• Orders for open configurations are quoted based on the ATP for components. The order promising process searches the best ATP for each of the components required for the order. The latest ATP plus the configuration’s lead-time is assigned as due date to the complete order.

3.5 Integration of i2 with SAP R/3

The i2 planning engines—Supply Chain Planner, Demand Fulfillment, Factory Planner and Demand Planner—closely interact with the SAP R/3 system, particularly with the SAP modules MM Materials Management, PP Production Planning and SD Sales and Distribution. In this case the SAP R/3 release 4.6c was installed.

Figure 23.3 shows the interfaces between the SAP system and the i2 modules. There are two classes of interfaces. The first class contains all interfaces except the order entry interface. These interfaces exchange static and dynamic data in a batch mode. The second class consists of the order entry interface. This interface transfers a new order from SAP SD to i2 Demand Fulfillment and gives the order quote back to SAP SD. The order entry interface is an online interface.

3.5.1 Batch Interfaces

Figure 23.7 shows the architecture used for the interfaces operating in batch mode. In the following we describe the data flow from SAP to i2. The data flow back is implemented in the same way. We use the interface between SAP and the supply planning processes as example to illustrate the ideas.

• 1. The supply planning processes represents only planned materials, i.e. those materials that are also used in the demand planning process. Furthermore, all orders and the forecast are imported, as well as WIP quantities, scheduled receipts, inventory etc. The selection, filtering and aggregation of the SAP data according to the data requirements of the supply planning processes are executed by a collection of ABAP/4 functions. These functions have been developed specifically for the project.

  Please note that the filter and aggregation functions applied represent the actual business logic on which the design of the supply planning processes is based. Thus, using a pre-defined standard interface between SAP and some APS Master Planning Module would constrain the design of the process and the interface—potentially preventing that a best-in class master planning process is achieved.

• 2. The ABAP/4 functions write the filtered and aggregated data for the supply planning processes in user-defined tables in the SAP database. These tables—called ZADW tables—have the same data scheme as the tables that exist in the i2 Active Data Warehouse (ADW).

• 3. The content of the ZADW tables is transferred into the tables of the ADW, using the i2 standard SAP interface. This interface is based on the middleware module i2 RhythmLink. RhythmLink has a specific module—the SAP-Listener—that is responsible for the technical data transfer between SAP and RhythmLink. Data streams are opened by RhythmLink copy maps that transfer the data from SAP directly into the corresponding ADW table.

• 4. After the complete data arrived in the ADW the standard i2 adapters are used to provide the data for the i2 planning engines e.g. the Supply Chain Planner engine that is running the master planning process. The i2 adapters are standard software components that are shipped with each i2 module. The adapters provide all required interfaces between the i2 module and the ADW (in both directions).

Fig. 23.7

Integration of the i2 planning modules with SAP R/3

3.5.2 Order Entry Interface

The order entry interface is an online interface. When an order is received by the order entry system SAP SD, the order is transferred to i2 Demand Fulfillment to be quoted. The quoted order is then sent back to SAP SD.

Technically, the order entry interface is based on the Optimization Interface (ROI). This interface consists of a collection of predefined ABAP/4 functions that have to be plugged into the order entry transaction as an user exit. The Optimization Interface then transfers the order to i2 Demand Fulfillment via API string and receives the quote the same way. The quote information is written into the SAP order, and the transaction is closed. An order can be quoted in milliseconds (below 100 ms per order, more than 10 orders per second can be quoted). Given that currently 800 orders per hour have to be quoted in peak load situations, the i2 Demand Fulfillment architecture scales well with an increasing number of orders—supporting even aggressive business growth strategies. The online order promising solution is used in combination with i2’s High Availability architecture that is based on the TIBCO message bus system (Tibco 2014). This architecture supports 24 × 7 (24 h a day, 7 days a week) order quoting even in case of server or network failures. This architecture consists of one primary and several secondary order promising servers that replicate all transactions on the primary server. So in case of a crash of the primary server a secondary can take over seamlessly.

4 Results and Lessons Learned

The APS implementation resulted in major improvements of the planning and logistics processes and helped to improve major KPIs. Table 23.3 lists the improvement of logistical KPIs from 1999 to 2002 and the target value. The improvement of the customer service level and the delivery reliability resulted in additional revenue. Better forecast accuracy helped to reduce the inventory levels and by that reduced the direct material costs by approx. 0.3–2 %. Through better planning support the inbound logistics costs and the process costs in purchasing and planning departments could be decreased.

Table 23.3 Improvements of KPIs due to the APS implementation

In addition to these business improvements the following “Lessons Learned” can be summarized from the project work:

• The batch interfaces between i2 and SAP R/3 were easier to implement and to manage than expected. For example the adaption of the interface programs from SAP R/3 3.0 f to 4.6 c was accomplished within 6 weeks without support by external consultants.

• The online integration between i2 Demand Fulfillment and SAP R/3 SD turned out to be rather difficult to implement and stabilize. Especially the consideration of the SD order types and the specific customizing of SD was a source of many issues.

• The learning curve of planners and other employees working with the APS took more time and effort than expected. The use of an exception-based APS and its planning algorithms compared to the use of a transactional system like SAP R/3 required additional training and management of change activities.

• However, after these management of change activities the APS implementation lead to a better integration and synchronization of the planning and execution processes.

• The benefits from the implementation could only be realized through a clear assignment of each major KPI to one responsible manager who leads the monitoring, reporting and improvement activities related to this KPI. Based on this a continuous improvement process was established that is driven by the KPI-managers (see also Kilger and Brockmann 2002).