Your Supply Chain Management Data Template
Your Supply Chain Management Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance
Supply Chain Management Attributes
| Name | Description | ||
|---|---|---|---|
| Activity Name ActivityName | The name of the specific business event or step that occurred within the logistics process. | ||
| Description The Activity Name describes a distinct step in the supply chain lifecycle, such as 'Order Allocated', 'Goods Picked', or 'Shipment Dispatched'. These activities form the nodes in the discovered process map. Analyzing these activities allows for the visualization of the process flow, identification of frequent pathways, and measurement of time spent in each stage. It is fundamental to understanding what happens during the logistics order journey and is used to identify rework, bottlenecks, and deviations from the standard process. Why it matters This attribute defines the steps in the process, forming the basis of the process map and enabling analysis of process flow and bottlenecks. Where to get This is typically derived by mapping event codes or status changes from various transaction tables in Manhattan Associates to user-friendly activity names. Examples Customer Order ReceivedGoods PickedShipment DispatchedProof of Delivery Received | |||
| Event Timestamp EventTimestamp | The exact date and time when the activity occurred. | ||
| Description The Event Timestamp, or Start Time, records the precise moment an activity was executed. This timestamp is critical for ordering events chronologically and calculating durations between activities. In process mining, this data is used to construct the timeline of each case, calculate cycle times, identify delays, and analyze process performance over time. Accurate timestamps are the foundation for nearly all time-based process analysis and KPI calculations, such as lead time and on-time performance. Why it matters This attribute provides the chronological order of events and is essential for calculating all time-based metrics, such as cycle times and delays. Where to get This information is found in transaction log tables alongside the corresponding event or status update in Manhattan Associates. Examples 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T08:15:00Z | |||
| Logistics Order LogisticsOrder | The unique identifier for a logistics order, which serves as the primary case identifier for tracking the end-to-end supply chain process. | ||
| Description The Logistics Order is the central tracking number that connects all related activities from customer order placement to final delivery. Each Logistics Order represents a single fulfillment journey, allowing for a complete analysis of the order's lifecycle, including procurement, warehousing, shipment, and delivery. In process mining, this attribute is used to group all related events into a single case. Analyzing processes by Logistics Order enables the calculation of end-to-end cycle times, identification of common process variants, and detection of bottlenecks or deviations affecting specific orders. Why it matters This is the essential Case ID that groups all related events, making it possible to trace the entire journey of a single order from start to finish. Where to get This is the primary key in the main order management tables within Manhattan Associates. Consult system documentation for the specific table, likely related to order headers. Examples LO-2024-00123LO-2024-00456LO-2024-00789 | |||
| Last Data Update LastDataUpdate | The timestamp indicating when the data for this record was last refreshed or extracted from the source system. | ||
| Description This attribute provides the date and time of the most recent data pull from the source system. It is a metadata field that helps users understand the freshness of the data they are analyzing. In process mining dashboards, this information is vital for communicating the timeliness of the insights. It ensures that stakeholders are aware of the data's recency and can make decisions accordingly, preventing analysis based on outdated information. Why it matters Indicates the freshness of the data, ensuring that analysis and decisions are based on up-to-date information. Where to get This timestamp is generated and added during the data extraction, transformation, and loading (ETL) process. Examples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Source System SourceSystem | The system from which the data was extracted. | ||
| Description This attribute identifies the source information system where the event data originated. For this context, it will typically be 'Manhattan Associates', but it can also differentiate between different modules or integrated systems. It is important for data governance and for understanding the context of the data, especially when data from multiple systems is combined. It helps in tracing data lineage and troubleshooting data quality issues. Why it matters Identifies the origin of the data, which is crucial for data governance, validation, and when merging data from multiple enterprise systems. Where to get This is typically a static value added during the data extraction process to label the dataset with its origin. Examples Manhattan Associates WMSManhattan Associates TMSMA-SCALE | |||
| Mode Of Transport ModeOfTransport | The method of transportation used for the shipment, such as truck, air, or sea. | ||
| Description This attribute specifies the transportation mode used to move the goods from the warehouse to the destination. Examples include Full Truckload (FTL), Less Than Truckload (LTL), air freight, ocean freight, or parcel. This dimension is critical for the 'Transport Cost & Efficiency Analysis' dashboard. It allows for comparing the cost and speed of different transport modes and helps in calculating the 'Expedited Shipping Frequency' KPI by identifying when more expensive, faster modes are used. Why it matters Helps analyze transportation costs and efficiency, and identifies reliance on expensive expedited shipping options. Where to get Located in the shipment or transportation planning tables within Manhattan Associates TMS module. Examples Air FreightLTLOceanParcel | |||
| Order Type OrderType | The classification of the logistics order, such as standard, express, or replenishment. | ||
| Description Order Type categorizes logistics orders based on their nature or priority. Common types include customer orders, stock transfer orders, or return orders. Each type may have a different expected process flow and service level agreement (SLA). This attribute is crucial for comparative analysis. By filtering or segmenting the process by Order Type, analysts can understand how different types of orders are handled, compare their cycle times, and identify if certain order types are more prone to delays or exceptions. It directly supports the 'Order Type Cycle Time Comparison' dashboard. Why it matters Allows for comparing the performance and process flows of different kinds of orders, which often have unique paths and SLAs. Where to get Located in the order header data within Manhattan Associates. Consult system documentation for the specific field name. Examples Standard OrderExpress DeliveryStock ReplenishmentReturn Order | |||
| Product SKU ProductSKU | The Stock Keeping Unit (SKU) or identifier for the product in the order. | ||
| Description The Product SKU is a unique code that identifies a specific product. A single logistics order can contain multiple SKUs. Analyzing the process at the product level helps to identify if certain items are associated with process inefficiencies, such as longer picking times, higher rework rates, or frequent stockouts. This attribute is essential for the 'Inventory Replenishment & Stockout Risk' dashboard to analyze reordering timeliness by product. Why it matters Enables product-level analysis to uncover issues like stockouts, picking delays, or quality problems tied to specific items. Where to get Found in the order line item tables in Manhattan Associates. This will require joining from the order header to the line item details. Examples SKU-A123-REDSKU-B456-LSKU-C789-V2 | |||
| Requested Delivery Date RequestedDeliveryDate | The delivery date requested by the customer or required by the internal plan. | ||
| Description This attribute stores the target date by which the goods should be delivered to the customer or receiving location. It serves as a benchmark for measuring on-time delivery performance. In analysis, this date is compared against the actual delivery timestamp ('Proof of Delivery Received') to determine if an order was on-time, early, or late. It is a critical component for calculating KPIs like 'Customer On-Time Delivery Rate' and 'Supplier On-Time Delivery Rate', and for building related performance dashboards. Why it matters This is the baseline for measuring on-time performance, which is a critical KPI for customer satisfaction and supplier management. Where to get Found in the order header or order line item tables in Manhattan Associates. Consult system documentation. Examples 2023-11-102023-11-152023-12-01 | |||
| User Name UserName | The name or ID of the user who executed the activity. | ||
| Description This attribute identifies the specific employee or system user responsible for performing a given process step. It can be a unique user ID, a name, or a system account name for automated tasks. Analyzing by user helps in understanding workload distribution, resource performance, and identifying training needs. It is key for dashboards related to resource load and throughput, and for investigating process deviations that may be user-specific. Why it matters Enables analysis of resource performance, workload distribution, and helps identify which users or teams are involved in process exceptions. Where to get Usually found in transaction tables alongside the event data, often as a 'UserID' or 'ChangedBy' field. Consult Manhattan Associates documentation. Examples jdoeasmithsys_batch_user | |||
| Carrier Name CarrierName | The name of the transportation carrier responsible for the shipment. | ||
| Description The Carrier Name identifies the logistics partner or company that physically transports the goods. This could be a major shipping company or a local courier. Analyzing by carrier is key to evaluating their performance in terms of on-time delivery, cost, and efficiency. It is a primary dimension for the 'Transport Cost & Efficiency Analysis' dashboard, enabling comparison of cycle times and costs across different carriers. Why it matters Enables performance evaluation of transportation partners, helping to optimize carrier selection based on cost and reliability. Where to get Found in the shipment or freight order tables, typically within the TMS module of Manhattan Associates. Examples FedExCH RobinsonMaersk | |||
| Customer Name CustomerName | The name of the customer to whom the goods are being delivered. | ||
| Description This attribute identifies the end customer receiving the shipment. It can be an individual or a business entity. Customer information is vital for analyzing service levels and identifying patterns specific to certain customers. It supports the 'Customer On-Time Delivery Rate' dashboard by allowing segmentation of delivery performance by customer, which can reveal if delays are concentrated with particular accounts or regions. Why it matters Allows for segmenting analysis by customer, which is key to understanding customer-specific issues and measuring service levels. Where to get Located in the order header data, often linked via a customer ID. Consult Manhattan Associates documentation. Examples Retail CorpBigMartSuperStore Inc. | |||
| Destination Location DestinationLocation | The customer's address, store, or facility where the shipment is delivered. | ||
| Description This attribute specifies the final delivery point for the goods. It could be a customer's distribution center, a retail store, or an end-consumer's address. It is often represented by a city, state, or postal code. Paired with the Origin Location, this attribute is essential for the 'Origin-Destination Lead Time Matrix' dashboard. Analyzing lead times by destination helps to identify delivery challenges in specific regions and evaluate the efficiency of the distribution network. Why it matters Helps in analyzing delivery performance across different geographic areas and identifying regional bottlenecks or carrier issues. Where to get This is the ship-to address information found in the order header or shipment details in Manhattan Associates. Examples New York, NYLos Angeles, CAStore #582 | |||
| Is On-Time Delivery (Customer) IsOnTimeDeliveryCustomer | A calculated flag indicating whether the order was delivered to the customer on or before the requested delivery date. | ||
| Description This boolean attribute is derived by comparing the 'Proof of Delivery Received' event timestamp with the 'RequestedDeliveryDate'. It flags each order as either on-time (true) or late (false). This attribute directly powers the 'Customer On-Time Delivery Rate' KPI and dashboard. It simplifies the analysis by providing a clear, binary outcome for each case, making it easy to filter for late orders and investigate the root causes of delays. Why it matters Directly measures customer service levels and simplifies the analysis of on-time performance by categorizing every order as on-time or late. Where to get This is not a field in the source system. It is calculated during data transformation by comparing the actual delivery timestamp to the requested delivery date. Examples truefalse | |||
| Origin Location OriginLocation | The warehouse, plant, or facility where the shipment originates. | ||
| Description This attribute specifies the starting point of the shipment, such as a distribution center, manufacturing plant, or supplier location. It is typically represented by a location code or name. Origin and destination data are fundamental for logistics network analysis. This attribute supports the 'Origin-Destination Lead Time Matrix' dashboard, helping to visualize and analyze lead times for different shipping lanes and identify regional or facility-specific bottlenecks. Why it matters Crucial for logistics network optimization and identifying performance variations between different shipping lanes or facilities. Where to get This information is typically stored in the shipment or order header tables within Manhattan Associates. Examples DC-AtlantaWH-NevadaPlant-Mexico-01 | |||
| Shipment ID ShipmentId | A unique identifier for a shipment, which may contain one or more logistics orders. | ||
| Description The Shipment ID is a reference number for a consolidated group of goods being transported together. A single shipment can include multiple logistics orders, especially if they are going to the same destination. While the Logistics Order is the case ID, the Shipment ID is an important contextual attribute. It allows for analysis of activities at the shipment level, such as 'Carrier Assigned' or 'Shipment Dispatched', and helps in understanding consolidation efficiency and transportation planning. Why it matters Links orders that are shipped together, enabling analysis of transportation efficiency and consolidation strategies. Where to get Generated and stored in the transportation and shipment planning tables within Manhattan Associates. Examples SH-98765SH-98766SH-98767 | |||
| Supplier Name SupplierName | The name of the supplier providing the goods for a purchase order. | ||
| Description This attribute identifies the vendor or supplier from whom goods or raw materials are procured. It is relevant for logistics orders that are initiated by a purchase order. Analyzing by supplier is essential for evaluating vendor performance. It allows for the creation of supplier scorecards, monitoring on-time delivery rates, and identifying which suppliers are frequently associated with delays in the 'Goods Received' step. This directly supports the 'Supplier On-Time Delivery Performance' dashboard. Why it matters Enables supplier performance analysis, helping to identify reliable partners and pinpoint sources of inbound supply chain delays. Where to get Linked from purchase order data tables within Manhattan Associates, often requiring a join from the logistics order to the purchase order header. Examples Global Components Inc.Advanced Materials LLCPrecision Parts Co. | |||
| Total Cost TotalCost | The total financial cost associated with the logistics order or specific activities. | ||
| Description This attribute represents the total cost incurred for the logistics order. It can be broken down into components like transportation cost, warehousing cost, and handling fees. The level of detail depends on the source data. Cost data is invaluable for value-based process mining. It supports the 'Transport Cost & Efficiency Analysis' dashboard by providing the financial context to cycle times. By analyzing costs, businesses can identify high-cost process variants and make data-driven decisions to optimize for both speed and expense. Why it matters Provides a financial dimension to the process, allowing for analysis of cost drivers and the financial impact of inefficiencies. Where to get Cost data may come from multiple tables in Manhattan Associates or require integration with a financial system. Consult documentation for freight cost or order costing tables. Examples 150.752500.0085.50 | |||
| Warehouse ID WarehouseId | The identifier for the warehouse or distribution center where picking and packing activities occur. | ||
| Description This attribute identifies the specific warehouse facility responsible for fulfilling the order. For multi-warehouse operations, this is a critical dimension for analysis. It directly supports the 'Warehouse Picking Bottleneck Analysis' dashboard by allowing performance to be compared across different facilities. Analysts can identify which warehouses are more efficient, which have longer picking cycle times, and where resources may need to be reallocated. Why it matters Enables comparative performance analysis across different warehouses to identify facility-specific bottlenecks and best practices. Where to get This is typically part of the order or shipment data in Manhattan Associates WMS, indicating the fulfilling location. Examples WH01-EASTWH02-WESTWH03-CENTRAL | |||
| Warehouse Picking Cycle Time WarehousePickingCycleTime | The calculated duration for the picking and packing phase within the warehouse for each order. | ||
| Description This metric measures the time elapsed between the 'Goods Picked' activity and the 'Goods Packed' activity. It isolates the performance of a critical part of the warehouse fulfillment process. This calculated attribute is the foundation for the 'Warehouse Picking Cycle Time' KPI and the 'Warehouse Picking Bottleneck Analysis' dashboard. It allows for direct measurement and monitoring of picking efficiency, helping to identify bottlenecks and the impact of any process improvement initiatives in the warehouse. Why it matters Isolates the performance of the warehouse picking process, making it possible to specifically target and measure improvements in this critical area. Where to get This is a calculated metric. It is derived by taking the time difference between the timestamps of the 'Goods Packed' and 'Goods Picked' activities for each Logistics Order. Examples 360072001800 | |||
Supply Chain Management Activities
| Activity | Description | ||
|---|---|---|---|
| Customer Order Received | This activity marks the creation of a new logistics order in the system, typically initiated by a customer through EDI, a web portal, or manual entry. This event is captured when a new order record is created with a unique identifier in the Order Management module. | ||
| Why it matters This is the primary start event for the end-to-end logistics process. Analyzing its timing is crucial for calculating the total order cycle time and understanding demand patterns. Where to get Recorded as an explicit transaction in the Manhattan Order Management System (OMS) module. Look for order creation tables and their associated timestamps. Capture Logged upon the creation of a sales order record. Event type explicit | |||
| Goods Picked | A warehouse operator physically retrieves the items for an order from their storage locations. This activity is typically captured when the operator confirms the pick, often by scanning the item and location barcodes. | ||
| Why it matters Analyzing picking duration is fundamental to identifying warehouse bottlenecks and improving labor efficiency. It directly supports the Warehouse Picking Cycle Time KPI. Where to get Recorded as an explicit transaction in the WMS task or execution logs. Each pick confirmation is timestamped and associated with a worker and order. Capture Logged via a scan or confirmation in the WMS picking interface. Event type explicit | |||
| Order Canceled | The customer order is formally canceled before fulfillment is complete. This is a terminal status that stops all further processing for the logistics order. | ||
| Why it matters This is a critical failure end event. Analyzing cancellation reasons and frequency helps identify issues in the order capture process or with customer satisfaction. Where to get This is an explicit transaction in the OMS that changes the order status to 'Canceled'. The timestamp of this status change marks the event. Capture Logged when the order status is updated to 'Canceled'. Event type explicit | |||
| Proof of Delivery Received | The final confirmation of a successful delivery, often including a signature, is received and recorded in the system. This can be an electronic confirmation from the carrier or a manually scanned and attached document. | ||
| Why it matters This activity is the primary success end event for the logistics process. It is essential for calculating the complete order cycle time and the customer on-time delivery rate. Where to get Can be an explicit event from a carrier message or inferred from a status change on the shipment record to 'POD Received' or 'Completed'. The timestamp marks the final closure. Capture Inferred from a shipment status change to 'Delivered' or 'POD Confirmed'. Event type inferred | |||
| Shipment Dispatched | This activity marks the point in time when the shipment physically leaves the warehouse or distribution center. This is typically captured via a final 'ship confirm' transaction in the WMS as the trailer is sealed and departs. | ||
| Why it matters This is a critical milestone that marks the end of warehouse handling and the beginning of in-transit time. It is a key event for measuring on-time shipment and warehouse processing time. Where to get A core, explicit transaction in Manhattan WMS/TMS, often called 'Ship Confirm' or 'Manifest Close'. This transaction is timestamped and finalizes the shipment details. Capture Logged by the 'Ship Confirm' transaction in the WMS. Event type explicit | |||
| Wave Created | A 'wave' is created in the WMS, which groups multiple orders or shipment lines together for efficient, coordinated picking and packing. The creation of a wave is a distinct system event that kicks off the physical fulfillment process for a batch of orders. | ||
| Why it matters This activity is a key milestone in warehouse operations. Analyzing the time orders wait to be waved can reveal batching strategy inefficiencies and resource planning gaps. Where to get Explicitly logged in the Manhattan WMS when a user or automated process initiates a wave. The wave creation tables contain timestamps for this event. Capture Captured from the timestamp on the wave creation record. Event type explicit | |||
| Carrier Assigned | A specific transportation carrier is selected and assigned to the shipment. This can be an automated process based on routing guides or a manual selection by a transportation planner. | ||
| Why it matters This decision point is crucial for analyzing transportation costs and carrier performance. The time taken to assign a carrier can indicate planning delays. Where to get Inferred from a timestamped change to the 'carrier' field on the shipment record in the TMS module. The event is when this field is first populated. Capture Inferred from the change log or update timestamp of the shipment's carrier field. Event type inferred | |||
| Goods Delivered To Customer | The shipment arrives and is unloaded at the customer's destination. This event is often captured through an electronic update, such as an EDI 214 message, received from the transportation carrier. | ||
| Why it matters This activity provides visibility into carrier performance and the actual transit time. It is a prerequisite for measuring on-time delivery and initiating the final proof of delivery step. Where to get This is typically an explicit event triggered by an external message from the carrier, which updates the shipment status in the TMS. The timestamp is derived from the carrier's update. Capture Captured from a carrier EDI message (e.g., EDI 214) updating the shipment status. Event type explicit | |||
| Goods Packed | Picked items are consolidated and packed into one or more shipping containers or cartons. This event is typically recorded when a packing station operator confirms the carton is sealed and a shipping label is generated. | ||
| Why it matters This marks the completion of the core pick-pack process. Analyzing the time from picking to packing helps optimize packing station layout and resource allocation. Where to get An explicit event captured in the WMS at the packing station. Look for carton creation or pack confirmation tables with timestamps. Capture Logged upon completion of the pack verification step. Event type explicit | |||
| Goods Received From Supplier | This activity records the physical receipt of goods from a supplier at the warehouse dock, typically against a purchase order. It is captured explicitly in the WMS when warehouse staff scan and register the incoming inventory. | ||
| Why it matters This is a crucial milestone for measuring supplier on-time delivery performance. It marks the conclusion of the inbound logistics phase and makes inventory available for fulfillment. Where to get A standard, explicit transaction in the Manhattan WMS inbound logistics module. Captured in receiving logs with timestamps, associated with a PO or Advance Ship Notice (ASN). Capture Logged by a warehouse receiving transaction. Event type explicit | |||
| Inventory Availability Checked | The system checks available inventory levels to determine if the customer order can be fulfilled from existing stock. This is often an automated step immediately following order creation, resulting in an update to the order line status. | ||
| Why it matters This activity is key to understanding inventory replenishment cycles and identifying stockout risks. Delays here can directly impact order fulfillment lead times. Where to get Typically inferred from order line status changes within the OMS module. A change from 'New' to 'Awaiting Allocation' or a similar status often signifies the completion of this check. Capture Inferred from an order line status change post-creation. Event type inferred | |||
| Order Allocated | The system reserves specific inventory units at a warehouse for a particular order. This allocation is a critical step that precedes any physical warehouse activity. | ||
| Why it matters This milestone marks the transition from order management to warehouse execution. The time between order receipt and allocation highlights potential processing backlogs before fulfillment begins. Where to get Captured as a status update on the order or shipment line within the Manhattan WMS. The event is the timestamp when the status changes to 'Allocated' or a similar state. Capture Identified by the timestamp of the order line status changing to 'Allocated'. Event type inferred | |||
| Purchase Order Created | A purchase order is generated to procure goods from an external supplier, typically triggered by a stockout or a direct backorder situation. This is an explicit transaction creating a new PO document linked to the customer demand. | ||
| Why it matters Tracking PO creation is essential for analyzing the procurement leg of the supply chain and its impact on overall order lead time. It helps measure supplier performance. Where to get Recorded as a discrete event in the procurement or purchasing module. Look for PO creation tables and their timestamps, often linked back to the original sales order. Capture Logged when a new Purchase Order record is saved. Event type explicit | |||
| Shipment Created | A logical shipment record is created in the system, grouping one or more orders or cartons destined for the same location via the same carrier. This step formalizes the transportation plan for the outbound goods. | ||
| Why it matters This activity bridges warehouse operations and transportation management. It provides a basis for carrier assignment, freight rating, and creating shipping documentation. Where to get An explicit transaction within the Manhattan WMS or TMS modules. It is recorded in shipment header tables with a creation timestamp. Capture Logged when a new shipment record is generated. Event type explicit | |||
| Shipment Rescheduled | The planned shipment date for an order is changed due to issues like stock unavailability, customer request, or transportation constraints. This represents a rework loop in the fulfillment process. | ||
| Why it matters Tracking reschedules is crucial for identifying sources of delay and process instability. This activity directly supports the Order Rework Rate KPI and helps quantify the impact of exceptions. Where to get Inferred from changes to the planned or requested ship date fields on the order or shipment record. A comparison between the original date and the updated date indicates a reschedule event. Capture Derived by comparing historical and current values of the 'Planned Ship Date' field. Event type calculated | |||
Extraction Guides
Extraction methods for this process are currently being validated. Please check back later or contact us for assistance.