I’ll describe the MIT process and compare it to three other delivery methods for multiple components — hub shipment, arrive together, and drop shipment. If you are familiar with the process, you may want to skip to the section, “SAP Processing Cycle for MIT,” in which I show how to map MIT in SAP. MIT works in R/3 through the Materials Management (MM) module. You can use this process in any SAP release, including ECC 5.0.

Basics of MIT

With the MIT process, components are not stocked in a hub and do not need to be re-packed once the sales order drops. The components sit for minimal time at the merge point (as all orders are planned to arrive together at the merge point). The merge points do not have to be set up to perform repacking, assembly, or quality checking, and thus can be spread wider geographically than they would be using a hub. This enables the components to travel a shorter path to the customer.

MIT can accomplish the following:

• Support the delivery of products on ship-complete orders without using distribution channels and processing via the hub shipment model
  
  
• Support a single settlement transaction on the customer’s credit card
  
  
• Reduce order cycle time by diminishing time required to combine components of the order from different manufacturers in the hub or distribution channel
  
  
• Shorten shelf life because stock transports between hubs are not required
  
  
• Decrease the path traveled by the components from creation to the end customer
  
  
• Single delivery to the customer, reducing costs of multiple deliveries
  
  
• Increase customer satisfaction

When to Use MIT

You should consider these points when deciding if MIT is the right choice for your shipping requirements.

• Product characteristics: The products/components that are ideal for the MIT process are those that do not require repacking or assembly. A group of products that can be individually directly shipped to the customer and are sourced from several different vendors is a good candidate for MIT.
  
  
• Ship complete sales orders: Delivering the product to the end consumer, typically to a home address, represents a significant operational cost. Usually, it involves contacting the customer directly to pre-arrange a drop time and confirm special instructions. The customer is likely to want a single, complete delivery. The MIT process is ideal for this scenario.
  
  
• Cost of maintaining multiple merge points: Equally significant to the shipping cost is the geographic location of the consolidation point (or merge point). A hub operation may represent a significant detour from the most efficient route to the customer, adding to the overall time and cost of delivery. MIT provides the capability to select the optimum merge point from a choice of sites. The more merge points, the more adaptable and cost-effective the consolidation options are to the final destination.
  
  
• Availability of logistics provider: Coordinating shipments from around the globe, consolidating them at numerous merge points, and finally delivering them to the end customer requires significant infrastructure. The challenge is to find a logistics provider with total capability or a single vendor with the capability to manage a number of third parties to deliver. This single vendor also needs to be able to integrate the third-party IT systems to provide a single interface.
  
  
• Product tracking over the supply chain: A key aspect of the process design is the ability to label all the products (no matter what the source) in a consistent way to facilitate tracking and the efficient consolidation at a predetermined merge point. This is based on discussions with the logistics provider and the vendors. The arrival of the shipments into a merge point requires a unique identifier for traceability of the order components.
  
  
• Concept of super delivery: The shipment of finished goods in an SAP system is usually managed via a delivery. Normally this refers to a single shipment from a single location to a single destination. The super delivery used in MIT requires multiple products to be shipped from multiple locations to a merge destination for consolidation. The super delivery initiates multiple electronic data interchange (EDI) messages to the appropriate vendors or warehouses, each message advising where specific line items need to be shipped. Only the logistics provider receives a message containing all the items on the order. The delivery routines need to work in such a way as to delay all EDI messages until all the lines of the order are available at all the sources. Only when all the items on the order are dispatched can the goods issue to consume sellable stock from the plant post-goods issue (PGI) be performed and the customer invoiced.
  
  
• Box/pallet handling: The MIT process must allow boxes, not order lines, to be brought together. Consider the relationship between order lines and boxes: Order line represents an order line entry in the sales order, whereas a box represents a package. A laptop and the operating system software might be two different order lines in the sales order, but would be packed in a single box. Possible relationships are:
  
  1. One-to-one. Each order line has a separate box (e.g., printer and laptop). Each box appears as a unique line item in the sales order
  
  2. Many boxes to an order line. A single order line requires several boxes (e.g., a laptop might be bundled with a printer, and appear as a single order line for the bundled item in the sales order). An order for two laptops can appear as one line in the sales order, but as two boxes.
  
  3. Many lines to a box. Several order lines must be packed in a single box (e.g., a laptop with the software CDs, headphones, and special cables that appear in different order lines but are packed in one box).

Alternatives to MIT

You should weigh the alternatives to the MIT process to determine the best solution for your business requirements. One alternative is hub shipment, which allows you to fulfill orders instantly and assemble/repackage components of the order at the hub point. The key differentiator between MIT and hub shipment is the wider spread of merge points compared to hubs. This gives the MIT process better routing and less handling/stocking of components. The merge points hold minimal stock compared to hubs. You can use hubs, unlike merge points, to carry out value-added activities, such as the assembly of components and testing.

Another alternative is the arrive-together model. This model is based on scheduling the deliveries from various sources to have them arrive together at the customer site. This process is based on an estimate and relies heavily on the routing times decided by the system. The scales can tilt in favor of arrive together if no MIT service provider is available and hub shipment is an unviable/expensive option.

MIT is more cost effective and faster than the distribution hubs and warehouses, as the merge points can be more widespread than hubs. The wider spread of merge points results in better package routing. The merge points are mostly manned and owned by the logistics provider, unlike hubs, resulting in lower operational costs and faster cycle time to complete orders.

Direct shipment or drop shipment is the cheapest option. In this case the vendor/OEM directly supplies the product to the customer when it is ready. If a sales order has several line itemsprocured from different OEMs, the customer receives several packages at different times, as the OEMs ship the line items separately. This process can lead to customer dissatisfaction and extra costs in terms of handling customer queries and complaints. This is the least desirable method for multiple line item orders.

Global companies might use a combination of the above models to meet their logistics requirements in various regions. Some companies might even develop a logistics model based on a combination of hub shipment and MIT. Factors such as costs, cycle time, availability of logistics providers, complexities of geographies and excise/ custom requirements, customer demands, and competitive environment could affect the model accepted for a region.

SAP Processing Cycle for MIT

Let me show you one way of implementing the MIT process in an SAP R/3 environment. The challenge in implementing MIT in an ERP package is the coordination of a flow of relevant information among the various partners. You need to fulfill the order as one package to the customer, prevent stock accumulations in the chain/merge point, bill the customer at the correct time, and possibly coexist with other logistics models.

These functions are not built into the standard SAP package, but you can map them with slight user exit changes and some custom coding. In the example I present here, each vendor provides items/ components in a box and no repackaging/ assembly is required for the supplied items.

Step 1. Determine the relevant sales order for the MIT process. At the time of sales order entry, a user exit determines if the sales order is applicable for MIT. The determination is based on the specific business requirements. The most probable criteria for selecting sales orders for MIT could be multi-line, multi-plant (having more than one deliverable line item or a sales bundle with components sourced from multiple vendors) with a Ship Complete or Complete dlv. flag. Figure 1 shows a sales order created in SAP (transaction VA03) that meets the requirements set in the user exit to determine that this sales order is relevant for MIT process.

Figure 1

Sales order (sales view, transaction VA03) with Complete Dlv. flag set and order line items sourced from two different plants

User exits are helpful because you can fully check these criteria only at the time you save them. Also, for some source plants, MIT may not yet be an option. Therefore continued redetermination of plants (by built-in user exit logic) is possible to get the best combination of source plants to fulfill the order by the MIT process.

Step 2. Change the shipping point for the MIT sales order to MIT shipping point. If the order is determined applicable for MIT, then a new shipping condition needs to be inserted by the user exit to redetermine merge shipping points for each line item. The shipping point previously selected based on the configuration would have to be redetermined to find the optimum merge point. You could use a customized Z table to maintain shipping conditions/merge points relevant for MIT. The Z table fields can be used for determination of the merge point based on the customer location (i.e., the ship-to party’s zip code or the sales area and the closest merge point to the zip code/sales area).

Figure 2 shows the sales order (VA03) with the redetermined shipping point populated by the user exit into the sales order. The shipping point picked up is a merge point that supports the MIT process. The new shipping point is determined based on the proximity of the merge point to the customer delivery address.

Figure 2

New shipping point added

Figure 3 shows the line item shipping view of the sales order. The route is determined by the merge point and OEM.

Figure 3

Route noted as dependent on MIT location

Step 3. Create requirements for the sales order. The available-to-promise (ATP) check can enable the arrive-together concept at the merge point. This is to reduce the quantity and time the components of the order accumulate at the merge point. The requirements are scheduled from each vendor to enable all the line items of the order to arrive at almost the same time at the merge point. To enable this, the delivery date should be configured to create a single delivery date for the delivery group. The system in this case uses the last delivery date (chronologically speaking) from an item within a group as the schedule line date for the whole delivery group.

Step 4. Create delivery for the MIT sales order. A super delivery is created only when product is available at each source plant determined by the ATP check relevant for that material-plant combination. The super delivery will have line items relevant to more than one source. The EDI outputs in the delivery document require development, to ensure each source only receives relevant delivery data in a format consistent with the existing process design (which might be specific to each source). Also, the EDI message outputs trigger is controlled by the configuration of the output determination procedure and of the access sequence.

Figure 4 shows the EDI messages generated for the sales order delivery. Each vendor and the MIT provider get specific delivery notifications.

Figure 4

Message outputs for the delivery document (transaction VL03)

Configure the Output Generation for MIT

To limit the number of outputs to those relevant to plants on the delivery, the access sequence needs to have a condition requirement. You need to configure several options for the output generation for the super delivery. The configuration settings for EDI message outputs for deliveries are found via menu path SPRO>Logistics Execution>Shipping>Output Control> Output Determination.

If you have a limited number of vendors and regions that are MIT enabled, a configuration option is to create a unique condition type for each vendor that is MIT enabled. In the configuration for Maintain Output Determination Procedure, maintain the requirement (by coding) for the unique condition type created earlier. The combination of access sequence entry and requirement determines the required output for a vendor (MIT enabled) in the specified customer sales area (area covered by MIT). The processing function module for the MIT 940 IDocs is linked in the WE20setting with the vendor.

The menu path for this setup in SAP is WE20>Partner Profiles>Outbound Parameters>Message Control Settings. The processing function might be custom developed with logic to determine the relevant MIT segments and the relevant information to be filled into the segments. Note the standard processing code for message type DESADV (940 IDoc) is DESA. The custom code can be a copy of this standard program with extra built-in checks.

Figure 5 shows the output to a single vendor. The output has only one material (sole material to be supplied by the vendor for the order) in the 940 IDoc segment (E1EDP07) and an extra segment (E1EDKA2 - ZV) for the MIT location and address. Instead of creating a new segment, the address in the existing segments AG, RE, and WE could also be changed.

Figure 5

Delivery of the 940 EDI document to the OEM via transaction WE02

Note that E1EDKA2 ZV (segment 14) has the MIT address. On receiving the segment E1EDKA2 ZV segment, the OEM realizes that this is an MIT order and sends the item mentioned in segment 22 (E1EDP09) to the MIT address.

Figure 6 shows the output to a MIT provider. The output has all the line items of the sales order in the 940 IDoc segment (E1EDP07) and no extra segment for the MIT location and address. The segments E1EDKA2 AG, RE, RG, and WE have the same customer details in both the IDocs. Therefore, the standard 940 IDoc segments do not need to be changed to enable MIT. The MIT provider gets both two-line items that constituted the original sales order, in the segments 000021 and 000027.

Figure 6

950 EDI document (transaction WE02) sent to the MIT provider

Step 5. Picking delivery in SAP. As each source completes and passes the goods to the local delivery provider, a picking and PGI signal is sent to SAP R/3 by the source (EDI 856B). This signal confirms that the logistics provider has accepted the product on the vendor’s behalf and R/3 performs only pick transaction and confirms serial numbers.

Step 6. PGI of delivery to consume stock. For MIT dispatch, the PGI needs to be delayed until all the sources have dispatched the goods. This implies that for MIT orders, the 856B does not trigger the PGI until all the items on the delivery have been picked. The last 856B from the vendor triggers the PGI of all the line items of the delivery.

Step 7. Bill the customer. A billing document is created once the PGI is completed. The customer (or credit card) is billed for the complete delivery amount.

Trilokesh Satpathy

Trilokesh Satpathy, PMP, is a consultant with Infosys Technologies Limited with more than six years of SAP consulting experience spanning automobile and computer manufacturing companies. He holds a bachelor’s degree in mechanical engineering and a post-graduate degree in business management.

You may contact the author at editor@scmexpertonline.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.