Supply Chain Processes and Digital Requirements

Introduction

Supply chain management (SCM) software is most effective when it reflects how an organization actually creates, acquires, transforms, delivers, and supports value. Software should not be selected merely because it contains modules labelled “procurement,” “manufacturing,” or “logistics.” The central design task is to translate business processes into decisions, transactions, information objects, controls, and performance measures that a digital platform can execute and coordinate.

This chapter introduces the principal supply chain process architecture: plan, source, make, deliver, return, and enable. These processes are connected rather than independent. Planning determines requirements for sourcing and production; sourcing affects material availability and cost; manufacturing creates inventory and capacity constraints; delivery converts supply into customer service; returns generate reverse flows and financial consequences; and enabling processes provide the data, governance, technology, and organizational capabilities required by all other processes.

The chapter also examines five commonly integrated workflows: procure-to-pay (P2P), order-to-cash (O2C), production, logistics, and sales and operations planning/integrated business planning (S&OP/IBP). For each workflow, the discussion distinguishes the process objective, event sequence, functional requirements, information requirements, control requirements, and performance measures. This distinction is essential. A functional requirement states what the system must do; an information requirement states what data the system must hold, relate, calculate, or communicate.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the relationship among plan, source, make, deliver, return, and enable processes.
2. Map major supply chain workflows from triggering event to financial or customer outcome.
3. Translate process activities into functional, information, integration, control, and analytical requirements.
4. Distinguish master data, transactional data, planning data, and reference data.
5. Evaluate how ERP, SCM, warehouse, transportation, supplier, and analytics applications cooperate.
6. Identify implementation risks arising from poor process design, weak data governance, and excessive customization.
7. Apply process-mapping principles to a practical supply chain case.

1. The Supply Chain Process Architecture

A process architecture is a structured view of the activities and relationships through which an organization plans and executes supply. A useful high-level model consists of six process groups:

The model resembles the SCOR process perspective, although organizations may use different names or boundaries. It is not a rigid organization chart. One company may place customer service in deliver, while another may treat it as an enabling capability. The value of the model is analytical: it helps identify process ownership, handoffs, information dependencies, and gaps.

A process should be described at several levels. At the highest level, “source” may include strategic sourcing, supplier selection, purchasing, receiving, and supplier payment. At a detailed level, receiving may include appointment scheduling, unloading, quantity verification, inspection, labeling, put-away, and inventory posting. Digital requirements become more precise as the process is decomposed.

End-to-end integration

Supply chains are characterized by dependencies across organizational boundaries. A customer order may trigger an availability check, a production requirement, a purchase requisition, a supplier commitment, a warehouse task, a transport booking, and an invoice. If each activity is digitized in isolation, the organization may still experience delays and errors because the process crosses applications and departments.

A process map should therefore identify:

• the trigger and expected outcome;
• activities and decision points;
• roles and organizational units;
• inputs and outputs;
• systems and interfaces;
• controls and exceptions;
• timing requirements;
• measures of performance.

The distinction between a happy path and an exception path is particularly important. The happy path may be “requisition approved, purchase order issued, goods received, invoice matched, payment made.” Real operations also include partial receipts, price variances, damaged goods, duplicate invoices, late suppliers, blocked payments, and changes to demand. A system that supports only the happy path is operationally incomplete.

2. Translating Processes into Digital Requirements

Functional requirements

A functional requirement describes a capability the system must provide. Examples include:

• create and approve purchase requisitions;
• calculate material requirements from a production plan;
• reserve inventory for a customer order;
• generate warehouse picking tasks;
• record lot and serial numbers;
• match an invoice against a purchase order and receipt;
• calculate projected inventory and capacity;
• issue alerts when a promised date is at risk.

Requirements should be written in observable terms. “The system should support good purchasing” is weak. “The system shall route requisitions above a defined value threshold to the appropriate approval authority and retain the approval record” is testable.

Information requirements

Information requirements specify the data needed to execute and control the process. They include:

• Master data: relatively stable definitions such as item, supplier, customer, location, bill of material, route, resource, and payment terms.
• Transactional data: events such as orders, receipts, picks, shipments, invoices, payments, and production confirmations.
• Planning data: forecasts, safety stocks, lead times, capacity, scenarios, and constraints.
• Reference data: currencies, units of measure, tax codes, reason codes, calendars, incoterms, and status values.
• Analytical data: historical measures, targets, dimensions, and derived indicators.

Data must have an owner, definition, quality rule, effective date, and permitted values. For example, “supplier lead time” may mean quoted calendar days, average actual days, or a statistically estimated replenishment time. A planning engine cannot make consistent decisions if different departments use different meanings.

Integration requirements

Supply chain processes frequently span several systems. Common integrations connect:

• ERP and financial accounting;
• ERP and warehouse management systems (WMS);
• ERP and transportation management systems (TMS);
• planning platforms and execution systems;
• supplier portals and electronic data interchange (EDI);
• e-commerce platforms and order management systems;
• manufacturing execution systems (MES), equipment, and quality systems.

An integration requirement should identify the source, destination, data object, event or schedule, frequency, transformation, error handling, and ownership. Real-time exchange is not always necessary. A shipment status may require near-real-time visibility, whereas a monthly supplier scorecard may be generated in a batch process.

Control and nonfunctional requirements

Controls protect reliability, compliance, and accountability. Examples include segregation of duties, approval limits, duplicate invoice detection, audit trails, role-based access, retention rules, and change history. Nonfunctional requirements concern qualities such as performance, availability, scalability, usability, cybersecurity, recoverability, and interoperability.

A requirements catalogue can be organized as follows:

3. Plan: Aligning Demand, Supply, and Resources

The plan process coordinates uncertain demand with constrained supply. It operates at multiple horizons. Strategic planning concerns networks, facilities, sourcing footprints, and aggregate capacity. Tactical planning concerns demand, inventory, production, procurement, and distribution plans. Operational planning concerns orders, schedules, allocations, and exception resolution.

S&OP and IBP

S&OP is a cross-functional decision process that reconciles demand and supply, usually through a recurring cycle. A typical cycle includes data preparation, demand review, supply review, pre-meeting reconciliation, executive review, and communication of approved decisions. IBP extends this logic by more explicitly incorporating financial plans, strategic scenarios, product portfolios, and enterprise objectives. The labels are not universally standardized; the quality of governance matters more than the name.

The process must resolve conflicts such as:

• forecast demand exceeding available capacity;
• sales targets requiring inventory that finance considers excessive;
• a low-cost supplier creating unacceptable risk;
• a promotion generating demand that production cannot support;
• service commitments conflicting with transportation constraints.

A planning system commonly requires versioned plans, scenario modelling, forecast collaboration, supply constraints, inventory policies, alerts, approvals, and a record of assumptions. It should distinguish statistical forecasts from commercial overrides and preserve the rationale for material changes.

Planning calculations

A basic projected inventory relationship is:

where PAB_t is projected available balance at time period t, S_t is scheduled or planned supply received in period t, and D_t is expected demand in that period. The relationship assumes that supply and demand are measured in the same unit and time bucket and that losses, reservations, and safety-stock effects are either included in the terms or modelled separately.

A simple net-requirement calculation is:

where NR_t is net requirement, D_t is demand, SS_t is desired safety stock, OH_t is usable on-hand inventory, and SR_t is firm or scheduled receipts available in the relevant period. This is a simplified planning expression. Real planning engines may include lead times, lot-sizing rules, reservations, yield loss, existing allocations, and time-phased safety stock.

Worked example. Demand for a period is 800 units, desired safety stock is 150 units, usable on-hand inventory is 500 units, and scheduled receipts are 100 units. Therefore:

NR_t = max(0, 800 + 150 − 500 − 100) = 350 units.

The result is not automatically a purchase order. It is a planning requirement that must be transformed according to make-or-buy policy, lot size, lead time, capacity, and approval rules.

Planning information requirements

Planning depends on accurate product hierarchies, historical demand, forecast measures, calendars, lead times, inventory status, open orders, capacity, bills of material, routings, supplier constraints, and financial assumptions. Time granularity matters: daily scheduling, weekly replenishment, and monthly S&OP cannot be treated as identical data problems.

4. Source and Procure-to-Pay

The source process obtains materials, services, equipment, and information from external or internal suppliers. Strategic sourcing selects and manages supply relationships; transactional procurement executes purchases; accounts payable settles supplier obligations.

The P2P workflow

A standard P2P flow is:

1. Identify a requirement or generate a replenishment proposal.
2. Create a purchase requisition.
3. Apply budget, policy, and authority checks.
4. Obtain quotations or select an approved supplier where required.
5. Create and approve a purchase order or release against a contract.
6. Communicate the order and receive supplier confirmation.
7. Schedule delivery and receive goods or services.
8. Inspect, accept, reject, or quarantine the receipt.
9. Record the supplier invoice.
10. Perform matching and resolve exceptions.
11. Post the liability and make payment.

The frequently used “three-way match” compares purchase-order terms, receipt evidence, and invoice information. Matching may concern quantity, price, tax, currency, and tolerances. Service procurement may require confirmation of milestones or service entry rather than a physical receipt.

P2P functional requirements

A capable P2P solution should support requisitions, catalogues, contracts, supplier qualification, competitive bidding where appropriate, approval workflows, purchase-order changes, supplier acknowledgements, receipt recording, inspection, invoice capture, matching, exception queues, payment status, and supplier performance analysis.

Important information includes item or service description, unit of measure, quantity, price, currency, tax, delivery location, requested date, supplier identity, contract reference, payment terms, Incoterms where relevant, accounting dimensions, receiving evidence, and approval history. A supplier’s legal identity and banking details require especially strong controls.

Professional implications

Procurement automation can reduce administrative effort, but it can also encode poor policy. A catalogue with incorrect specifications may create standardized errors at scale. Automatic supplier selection may optimize price while ignoring resilience, labor standards, emissions, or geopolitical exposure. Digital procurement therefore requires category strategy, supplier governance, data stewardship, and human oversight.

5. Make: Production and Transformation

The make process transforms materials, labor, energy, and information into finished or intermediate outputs. It may involve repetitive manufacturing, process manufacturing, project production, repair, configuration, or service delivery. A software design must reflect the production type rather than assuming that every operation follows discrete manufacturing logic.

Production workflow

A typical production sequence includes demand or replenishment authorization, material and capacity planning, order creation, release, staging, execution, quality inspection, confirmation of labor and machine time, reporting of yield or scrap, receipt of output, and order closure. Some environments schedule finite capacity; others use infinite-capacity plans and resolve overloads manually.

Core records include:

• bill of material (BOM), recipe, or formulation;
• routing or process instructions;
• work centers and resources;
• production calendar and shift patterns;
• standard and actual quantities;
• labor and machine time;
• lot, batch, or serial traceability;
• quality specifications and inspection results;
• scrap, rework, co-products, and by-products;
• work-in-process and inventory status.

Requirements and controls

The system should support version-controlled BOMs and routings, engineering change effectiveness dates, material availability checks, capacity visibility, dispatching, backflushing where appropriate, manual confirmation where necessary, quality holds, genealogy, and authorization to release or close orders. It should distinguish planned consumption from actual consumption and planned yield from actual yield.

Traceability is both an operational and regulatory concern. In food, pharmaceuticals, aerospace, and medical products, the organization may need to trace a finished lot backward to source lots and forward to customers. This requires consistent lot capture at receipt, issue, production, storage, and shipment events.

6. Deliver: Order-to-Cash and Logistics

The deliver process converts customer demand into fulfillment, delivery, and revenue collection. It includes order management, allocation, warehouse execution, transportation, delivery confirmation, billing, and customer service.

The O2C workflow

A typical O2C sequence is:

1. Capture a customer order through sales, e-commerce, electronic integration, or another channel.
2. Validate customer, product, price, tax, credit, and commercial terms.
3. Check availability and promise a date using available-to-promise or capable-to-promise logic.
4. Reserve or allocate inventory and create fulfillment requirements.
5. Release warehouse work, pick, pack, and stage the order.
6. Plan and execute transportation.
7. Confirm dispatch and delivery.
8. Generate the invoice and record accounts receivable.
9. Collect payment and manage disputes, credits, or deductions.

Functional requirements include order capture, pricing and promotion rules, credit controls, order holds, substitution, backorder management, allocation, delivery scheduling, shipment consolidation, proof of delivery, invoicing, returns linkage, and customer-status visibility.

Warehouse and transportation requirements

A WMS typically requires location control, receiving, put-away, replenishment, picking strategies, packing, label generation, cycle counting, labor or task management, and inventory status control. A TMS may require carrier selection, rate management, load building, route planning, tendering, tracking, freight audit, and claims management.

The design must distinguish physical movement from information movement. A shipment can be physically dispatched while the system remains unconfirmed; conversely, a system status can indicate “shipped” while the carrier has not collected the freight. Event integrity is therefore essential for customer promises, inventory accuracy, and financial posting.

Delivery performance

Common measures include order-fill rate, perfect-order percentage, on-time-in-full (OTIF), order-cycle time, inventory accuracy, warehouse productivity, transport cost per unit, and claim rate. Measures require definitions. For example, “on time” must specify the promised date and time zone, while “in full” must state whether partial lines, substitutions, or backorders qualify.

7. Return: Reverse Logistics and Closed-Loop Processes

Returns arise from defects, incorrect shipments, customer dissatisfaction, recalls, reusable packaging, repair, rental expiration, overstock, and end-of-life recovery. Return processes are not simply the forward flow in reverse. They require condition assessment, ownership determination, disposition, financial settlement, and often regulatory documentation.

A return workflow may include return request, authorization, transport arrangement, receipt, inspection, classification, disposition decision, inventory or asset update, credit or replacement, repair or refurbishment, recycling, disposal, and root-cause analysis.

Digital requirements include return reason codes, authorization rules, serial or lot traceability, inspection results, disposition categories, quarantine locations, credit calculation, warranty linkage, replacement orders, carrier tracking, and evidence of destruction or recycling where required. Return data should feed product quality, supplier management, design, and customer-service decisions.

A major managerial issue is the trade-off between customer convenience and abuse prevention. Excessive approval barriers may damage loyalty; weak controls may create fraud, unnecessary transport, and environmental waste.

8. Enable: The Foundation of Digital Supply Chains

Enable processes provide the platform on which planning and execution depend. They include governance, master data management, process ownership, performance management, compliance, cybersecurity, integration, talent, and continuous improvement.

Master data governance

Critical objects include items, customers, suppliers, locations, units of measure, calendars, BOMs, routings, prices, contracts, and organizational structures. A governance model should define who creates, approves, changes, audits, and retires each object. Effective dates and version control are necessary because a product specification or supplier status may change while historical transactions must remain interpretable.

Security and segregation of duties

Supply chain applications contain commercial, personal, financial, and operationally sensitive information. Role-based access should follow least privilege. A person who creates a supplier should not necessarily be able to approve payments to that supplier. Privileged access, interface credentials, emergency access, and audit logs require formal oversight.

Performance management

A dashboard is useful only when measures have a business owner, a stable definition, a data lineage, and a decision associated with the result. Leading indicators, such as forecast bias, supplier confirmation timeliness, and overdue master-data changes, can be more actionable than lagging indicators such as stockouts or customer complaints.

9. Information Architecture Across Processes

An integrated supply chain platform links entities and events. For example, an item master record connects a forecast, a planned order, a purchase order, a receipt, an inventory balance, a production order, a customer order, a shipment, and an invoice. If the item identifier or unit of measure is inconsistent across systems, integration may technically succeed while business meaning fails.

A useful data model distinguishes:

Data quality can be assessed through accuracy, completeness, consistency, timeliness, uniqueness, validity, and fitness for purpose. A “single source of truth” does not mean that every decision must use one physical database. It means that authoritative ownership and reconciliation rules are clear.

10. Applied Case: Northstar Home Appliances

This is an illustrative case. Northstar Home Appliances manufactures refrigerators and sells through retailers and its own online channel. Its ERP system handles purchasing, inventory, production, and finance. A separate warehouse system manages the distribution center, while transportation is coordinated through spreadsheets and email. Sales forecasts are maintained in spreadsheets by product managers.

Background and problem

Northstar experiences frequent stockouts of popular models, excess inventory of slow-moving variants, late supplier deliveries, and disputes between sales and operations. Customer service promises dates without reliable inventory or capacity information. Invoices are sometimes paid late because receipts are not recorded promptly. Returns are processed inconsistently, so recurring product defects are difficult to identify.

Analysis

The process mapping team identifies the following weaknesses:

• planning data is not versioned and commercial overrides are not documented;
• item and location codes differ between ERP and the warehouse system;
• purchase orders do not consistently contain supplier confirmation dates;
• production schedules do not reflect actual component constraints;
• shipment status is updated only after manual spreadsheet reconciliation;
• return reason codes are too broad to support root-cause analysis;
• no cross-functional S&OP decision forum exists.

The problem is not simply “lack of software.” It is a combination of fragmented process ownership, weak data governance, and inadequate exception management.

Approach and solution

Northstar designs a target process before selecting additional technology. It establishes an S&OP cycle with documented demand assumptions, constrained supply review, scenario analysis, and executive decisions. It creates a governed item and location master, with cross-reference rules during migration.

For P2P, the company introduces requisition approval, supplier confirmation dates, electronic receipt capture, and three-way matching with defined tolerances. For production, it standardizes BOM versions, records component shortages before release, and captures lot numbers for compressors and control boards. For O2C, it integrates order promising with available inventory and planned production, then connects shipment events from the carrier network.

Returns receive standardized reason and disposition codes. The company links returned serial numbers to production lots and supplier components. A cross-functional dashboard reports forecast error, supplier reliability, schedule adherence, inventory aging, OTIF, return rate, and invoice exceptions.

Outcome

In the illustrative scenario, Northstar reduces manual reconciliation and gains a common view of demand, supply, and customer commitments. The most important improvement is not a single percentage reduction in cost; it is the ability to identify trade-offs earlier. A proposed promotion can be evaluated against component availability, production capacity, distribution constraints, working capital, and customer-service implications before launch.

Learning points

1. Process integration must precede technology integration.
2. Master data is an operational capability, not an administrative afterthought.
3. Exception workflows are as important as normal transaction flows.
4. S&OP requires governance and decision rights, not only a forecasting tool.
5. Return information can improve design and supplier quality.
6. Measures should support decisions rather than merely describe activity.

11. Implementation, AI, and Contemporary Developments

Implementation should begin with a process and data baseline, followed by future-state design, requirements prioritization, configuration, integration design, testing, training, deployment, and stabilization. A useful prioritization method classifies requirements as mandatory, regulatory, value-adding, or optional. Organizations should challenge unnecessary customization because custom code increases upgrade, testing, cybersecurity, and support burdens.

Cloud enterprise platforms increasingly combine ERP, planning, procurement, warehouse, transportation, and analytics capabilities. Application programming interfaces, event-driven integration, and standardized data models can improve visibility, but interoperability still requires governance. Digital twins and control towers can support scenario analysis and network visibility; they do not eliminate the need for accurate source data or clear decision rights.

AI is relevant where the organization has a defined decision, sufficient data, and a mechanism for human accountability. Potential applications include demand sensing, anomaly detection, supplier-risk monitoring, document extraction, dynamic ETA prediction, inventory segmentation, and conversational access to supply data. Risks include biased training data, opaque recommendations, automation of incorrect policies, privacy violations, and overconfidence in forecasts. AI-enabled decisions should record data sources, model versions, confidence or uncertainty, human overrides, and outcomes.

Sustainability requirements are also becoming part of supply-chain information architecture. Organizations may need product carbon data, supplier environmental measures, packaging information, repair and recycling events, and chain-of-custody evidence. Such data must have calculation boundaries and assurance rules; an unqualified sustainability label is not a substitute for a defined method.

Challenges and Limitations

Several limitations affect process and software design:

• Boundary ambiguity: organizations may assign the same activity to different process owners.
• Local optimization: a warehouse, procurement team, or plant may improve its own metric while harming total supply-chain performance.
• Data latency: delayed transactions distort inventory, availability, and financial visibility.
• Uncertainty: forecasts, supplier dates, yields, and transport times are estimates, not facts.
• Change resistance: users may preserve spreadsheets because they distrust system data or lack decision support.
• Integration complexity: interfaces can fail silently or transform data incorrectly.
• Regulatory variation: tax, customs, privacy, product safety, and record-retention requirements differ across jurisdictions.
• Metric conflict: low inventory, high utilization, rapid delivery, and resilience may not be simultaneously maximized.

The appropriate response is not to seek a perfectly comprehensive system. It is to make assumptions explicit, design controls around material risks, test realistic exceptions, and continuously improve processes.

Best-Practice Principles

1. Start with end-to-end value streams rather than departmental modules.
2. Define process ownership and decision rights before configuring workflows.
3. Establish authoritative master data and clear data definitions.
4. Design normal and exception paths together.
5. Separate policy decisions from software defaults.
6. Use standardized configuration where it supports the operating model.
7. Integrate financial, operational, and planning consequences.
8. Measure outcomes such as service, cost, cash, resilience, quality, and sustainability.
9. Preserve auditability, security, and human accountability.
10. Treat implementation as organizational change, not only system installation.

Chapter Summary

Supply chain software should represent integrated processes rather than isolated departmental transactions. The plan, source, make, deliver, return, and enable architecture provides a practical framework for locating activities, ownership, information, controls, and measures. Plan reconciles demand, supply, capacity, inventory, and financial objectives. Source includes strategic procurement and procure-to-pay execution. Make transforms inputs through controlled production processes. Deliver links customer orders with inventory, warehouses, transportation, billing, and collection. Return manages reverse flows, disposition, customer settlement, and learning. Enable provides governance, master data, security, integration, analytics, and continuous improvement.

Procure-to-pay, order-to-cash, production, logistics, and S&OP/IBP workflows demonstrate why functional requirements must be accompanied by information, integration, control, analytical, and nonfunctional requirements. Accurate process mapping includes triggers, activities, decisions, exceptions, systems, roles, and outcomes. Digital transformation succeeds when technology reinforces sound process design, reliable data, accountable governance, and cross-functional decision-making.

Key Terms

Process architecture: A structured model of related activities, inputs, outputs, roles, and controls.

Plan: The process of aligning demand, supply, resources, inventory, and financial objectives.

Source: The acquisition of goods, services, and inputs from suppliers.

Make: The transformation of materials and resources into products or services.

Deliver: The fulfillment, shipment, invoicing, and collection of customer demand.

Return: The management of reverse flows, inspection, disposition, credit, repair, or recovery.

Enable: Governance and capabilities that support supply-chain processes.

Procure-to-pay (P2P): The process from purchase requirement through supplier payment.

Order-to-cash (O2C): The process from customer order through delivery, invoicing, and collection.

S&OP: A cross-functional process for reconciling demand and supply decisions.

Integrated business planning (IBP): An extended planning approach incorporating financial and strategic considerations.

Master data: Relatively stable data defining business entities and rules.

Transactional data: Records of operational events such as orders, receipts, and shipments.

Reference data: Controlled values such as currencies, units, tax codes, and reason codes.

Functional requirement: A testable capability that a system must provide.

Information requirement: A specification of data needed to execute or control a process.

Three-way match: Comparison of purchase-order, receipt, and invoice information.

Available-to-promise: A method of promising customer demand against available or expected supply.

Traceability: The ability to track an item, lot, or serial number through supply-chain events.

Exception management: Identification, prioritization, assignment, and resolution of deviations from plan or policy.

Review Questions

Short Answer Questions

1. What are the six major process groups in the supply chain process architecture?
2. What is the difference between a functional requirement and an information requirement?
3. What records are compared in a three-way match?
4. Why are master-data definitions important for integrated planning?
5. What is the purpose of an S&OP process?

Long Answer Questions

1. Explain how plan, source, make, deliver, return, and enable processes depend on one another.
2. Describe the procure-to-pay workflow and identify its principal functional and control requirements.
3. Compare the information requirements of production execution and order-to-cash.
4. Explain why exception paths should be designed alongside normal process paths.
5. Discuss the governance, security, and data-quality capabilities required by an integrated SCM platform.

Analytical / Application Questions

1. A manufacturer has accurate purchase orders but unreliable inventory balances because receipts and warehouse movements are posted late. Map the likely impacts across plan, make, and deliver, and propose system and governance responses.
2. A retailer wants to promise two-day delivery for a promotion, but the distribution center has limited labor and transportation capacity. Design an S&OP/IBP decision process and identify the data required to evaluate the promotion.
3. Using the net-requirement equation in this chapter, calculate the requirement when demand is 1,200 units, desired safety stock is 250 units, usable on-hand inventory is 700 units, and scheduled receipts are 300 units. Explain why the result may not equal the final purchase order quantity.

Multiple Choice Questions with Answers

Question 1

Which process group primarily reconciles demand, supply, capacity, inventory, and financial objectives?

A. Plan

B. Source

C. Return

D. Enable

Correct Answer: A. Plan

Question 2

Which item is a master-data object?

A. A shipment confirmation

B. A supplier invoice

C. A bill of material

D. A customer payment

Correct Answer: C. A bill of material

Question 3

What is the main purpose of a three-way match?

A. To compare a forecast with a production schedule

B. To compare a purchase order, receipt, and invoice

C. To compare a route with a carrier tender

D. To compare a return with a warranty policy

Correct Answer: B. To compare a purchase order, receipt, and invoice

Question 4

Which requirement is functional?

A. The system shall be available 99.9% of the time

B. The system shall retain records for seven years

C. The system shall route high-value requisitions for approval

D. The system shall encrypt data in transit

Correct Answer: C. The system shall route high-value requisitions for approval

Question 5

Demand is 800 units, safety stock is 150 units, on-hand inventory is 500 units, and scheduled receipts are 100 units. Using the simplified net-requirement equation, what is the net requirement?

A. 150 units

B. 250 units

C. 350 units

D. 550 units

Correct Answer: C. 350 units

Question 6

Which activity most directly belongs to order-to-cash?

A. Approving a supplier contract

B. Recording a customer delivery and generating an invoice

C. Releasing a production order

D. Inspecting incoming raw material

Correct Answer: B. Recording a customer delivery and generating an invoice

Question 7

Why are return reason and disposition codes important?

A. They eliminate the need for customer orders

B. They support financial closing only

C. They enable analysis of causes and recovery decisions

D. They replace lot and serial traceability

Correct Answer: C. They enable analysis of causes and recovery decisions

Question 8

Which statement best describes an information requirement?

A. A rule specifying who may approve a transaction

B. A capability to create warehouse tasks

C. A definition of the data needed to execute and control a process

D. A target for reducing transportation cost

Correct Answer: C. A definition of the data needed to execute and control a process

Question 9

What is a key risk of optimizing a single department’s metric?

A. It always improves total supply-chain performance

B. It may improve local performance while harming the end-to-end result

C. It eliminates the need for process ownership

D. It guarantees accurate master data

Correct Answer: B. It may improve local performance while harming the end-to-end result

Question 10

Which practice is most appropriate when introducing AI into supply-chain decision-making?

A. Allow recommendations without recording their data sources

B. Remove human review from all high-impact decisions

C. Record model versions, assumptions, overrides, and outcomes

D. Use AI to compensate for undefined master data

Correct Answer: C. Record model versions, assumptions, overrides, and outcomes