WMS–TMS Selection, Configuration and Implementation

Introduction and strategic context

A warehouse management system (WMS) and a transportation management system (TMS) are not merely software purchases. They are operating-model decisions that influence inventory availability, labour productivity, transport cost, customer service, working capital, compliance and the organisation’s ability to scale. A WMS controls and records warehouse activities such as receiving, put-away, replenishment, picking, packing, staging and dispatch. A TMS supports transportation planning, carrier selection, tendering, execution, freight audit, visibility and performance management.

The systems are most valuable when treated as components of an integrated fulfilment architecture. Orders may originate in an enterprise resource planning (ERP) or order management system (OMS), inventory and task execution may be controlled by the WMS, and shipment planning and carrier execution may be managed by the TMS. Integration must preserve a reliable flow of orders, inventory status, shipment instructions, tracking events, freight charges and proof of delivery.

Implementation success depends less on the software demonstration than on the quality of requirements analysis, process design, data governance, organisational readiness and benefits management. A technically functional system can still fail if it embeds poor processes, lacks master-data discipline, or is rejected by warehouse operators and transport planners.

Learning objectives

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

1. Translate business strategy and operational requirements into WMS–TMS capabilities.
2. Map current and future warehouse and transportation processes.
3. Evaluate solutions using fit–gap analysis, total cost of ownership and risk criteria.
4. Design a controlled approach to configuration, integration, testing and data migration.
5. Plan cutover, training, change management and operational stabilisation.
6. Build a business case and measure benefits after implementation.
7. Assess governance, cybersecurity, ethical and regulatory implications.

1. Requirements analysis: from strategy to capabilities

1.1 Strategic alignment

Requirements should begin with business outcomes rather than software functions. Typical strategic drivers include:

• faster order fulfilment and narrower delivery windows;
• growth in order volume, stock-keeping units (SKUs), channels or sites;
• lower inventory, labour, transport and accessorial costs;
• improved traceability for regulated or high-value products;
• resilience through multi-carrier and multi-site capability;
• improved customer visibility and delivery reliability; and
• standardisation after mergers, acquisitions or network redesign.

A useful hierarchy is:

Strategic objective → operating capability → process requirement → system requirement → measurable benefit.

For example, the objective “support profitable omnichannel growth” may require the capability “rapid, accurate small-order fulfilment.” This becomes process requirements for wave or waveless release, inventory reservation, intelligent picking and parcel manifesting, followed by system requirements for order orchestration, labour management and carrier integration.

Requirements should be classified as functional, non-functional, data, integration, regulatory and organisational. Functional requirements describe what the system must do. Non-functional requirements address performance, availability, usability, scalability, security and recoverability. Data requirements specify ownership, quality, retention and synchronisation. Organisational requirements concern roles, training, support and governance.

1.2 Requirements elicitation

A cross-functional team should include warehouse operations, transport, procurement, customer service, finance, IT, security, legal and representative end users. Stakeholder interviews alone are insufficient because stated procedures often differ from actual work. Effective elicitation combines interviews, observation, document review, transaction analysis, workshops, system-log analysis and structured surveys.

Each requirement should be written so that it is testable. A weak statement is “the WMS must be user-friendly.” A stronger statement is “a trained picker shall confirm a standard case pick using no more than three screen interactions, and the transaction shall be recorded within two seconds under normal operating load.” The latter can be tested, although the threshold must be validated with users and technical specialists.

A requirements traceability matrix links each requirement to its source, priority, proposed solution, test case, owner and acceptance status. A common prioritisation method is MoSCoW: Must have, Should have, Could have and Won’t have in the current release. Priorities should reflect business risk and value rather than the loudest stakeholder’s preference.

2. Process mapping and operating-model design

2.1 Current-state analysis

Current-state mapping establishes how work actually flows. The scope should cover physical movement, information movement, decisions, controls, exceptions and performance measures. In a warehouse, the map may begin with an advance shipping notice, continue through receiving and quality inspection, and end with dispatch confirmation and inventory update. In transportation, it may begin with an order or shipment request and continue through planning, tendering, appointment scheduling, execution, tracking, delivery and freight settlement.

Useful modelling techniques include SIPOC diagrams, swim-lane maps, value-stream maps, business process model and notation (BPMN), spaghetti diagrams and service-blueprint analysis. A process map should show system boundaries and hand-offs, not merely warehouse geography. For each activity, record the trigger, input, responsible role, system used, decision rule, output, control, exception and performance measure.

The analysis should distinguish value-adding work from necessary control work and avoidable rework. Examples of waste include repeated data entry, searching for stock, unplanned travel, manual carrier rebooking, duplicate freight invoices and spreadsheet-based reconciliation.

2.2 Future-state design

Future-state design should not simply reproduce current practices in a new interface. It should determine which decisions are automated, which remain managerial, and where standardisation is economically justified. Design principles often include:

• configure standard processes before considering custom development;
• capture data once at its source and reuse it;
• make exceptions visible rather than hiding them in spreadsheets;
• separate policy decisions from transactional execution;
• design for safety, accessibility and usability;
• preserve audit trails for important decisions; and
• design interfaces around roles and work contexts.

WMS future-state decisions include inventory status models, location control, licence-plate or handling-unit management, replenishment logic, allocation rules, picking methods, quality holds, value-added services, labour standards and cycle counting. TMS decisions include shipment consolidation, mode selection, carrier allocation, routing guides, appointment management, track-and-trace, detention management, freight rating and settlement.

The design must explicitly address exceptions: short receipt, damaged goods, stock discrepancy, failed scan, carrier rejection, missed appointment, temperature excursion, late delivery, split shipment and system outage. A process that works only in the normal case is not operationally complete.

3. Solution architecture and integration

A typical architecture contains an ERP or OMS, WMS, TMS, carrier and marketplace connections, transportation visibility services, warehouse automation controls and analytics. The architecture may be cloud-based, on-premises or hybrid. The choice should consider latency, site connectivity, data sovereignty, integration skill, resilience, cost and the organisation’s risk appetite.

Important integration objects include:

Integration design should specify message ownership, identifiers, timing, error handling, retries, reconciliation, security and monitoring. Idempotency is important: processing the same message twice should not create two shipments, two receipts or two inventory movements. Interfaces should use correlation identifiers so that a business transaction can be traced across systems.

Master data deserves particular attention. A product’s dimensions, weight, handling class, shelf life, hazardous-material classification, barcode, case pack and pallet pattern may affect both warehouse and transport decisions. Conflicting units of measure or inaccurate dimensions can cause incorrect storage, picking, rating, cube utilisation and regulatory declarations.

4. Solution evaluation and fit–gap analysis

4.1 Evaluation framework

Vendor selection should combine capability, economics, implementation risk and strategic fit. A weighted scoring model can make decision criteria explicit. The general score is:

Here, S is the total weighted score, wᵢ is the weight assigned to criterion i, rᵢ is the vendor rating for criterion i, and n is the number of criteria. If weights and ratings are normalised, their units are dimensionless. The organisation must define the rating scale and ensure that higher ratings consistently mean better performance.

Criteria may include functional coverage, usability, integration capability, implementation ecosystem, scalability, security, vendor viability, total cost, industry fit, analytics, configurability and geographical support. Critical “must-pass” requirements should be evaluated separately rather than diluted by a high average score.

Demonstrations should use realistic scripts based on the organisation’s own scenarios. Vendors should demonstrate normal and exception cases using representative data. Reference checks should explore implementation effort, upgrade experience, support responsiveness, realised benefits and the customer’s degree of customisation.

4.2 Fit–gap analysis

Fit–gap analysis compares the required future state with the standard product and identifies the appropriate treatment:

1. Fit: standard capability meets the requirement.
2. Configuration: capability can be achieved through supported settings.
3. Process change: the business changes its practice to use the standard capability.
4. Extension or integration: an approved addition is justified.
5. Customisation: source-code or deep product modification is required.
6. Gap accepted: the requirement is deprioritised or handled manually.

The preferred order is usually fit, configuration, process change, extension, and only then customisation. Customisation may satisfy a local requirement but increase upgrade complexity, testing effort, cybersecurity exposure and dependence on specialised resources. The decision should consider strategic differentiation, regulatory necessity, benefit, lifecycle cost and reversibility.

A gap register should record the requirement, operational impact, options, estimated cost, risk, owner, decision date and acceptance criteria. “The vendor says it is on the roadmap” is not equivalent to delivered capability; contractual commitments, release timing and interim controls must be explicit.

5. Business case and total cost of ownership

A business case should distinguish one-time costs from recurring costs and benefits from cash savings. Cost categories include software subscriptions or licences, implementation services, integration, infrastructure, devices, automation interfaces, data cleansing, training, internal labour, temporary parallel operations, support and change management.

Benefits may include reduced labour hours, lower inventory, fewer errors, reduced expedited freight, improved vehicle utilisation, lower demurrage, fewer chargebacks, better space utilisation and avoided future cost. Some benefits are financial; others are service, resilience, compliance or safety benefits.

A simple return-on-investment measure is:

where B is the relevant benefit over the chosen period and C is the relevant cost over the same period. Both must use the same currency, time horizon and treatment of taxes, financing and inflation. ROI is not a complete investment appraisal because it ignores the timing of cash flows.

For projects with multi-period cash flows, net present value is more informative:

Here, I₀ is the initial investment, CFₜ is net cash flow in period t, r is the discount rate per period, and T is the number of periods. Cash flows must be measured consistently, and the discount rate should reflect the organisation’s approved financial assumptions. A positive NPV indicates value under those assumptions, not certainty of success.

For example, suppose implementation costs are $900,000, annual net benefits are $400,000 for three years, and the discount rate is 10%. The approximate NPV is:

NPV = −900,000 + 400,000/1.10 + 400,000/1.10² + 400,000/1.10³

This equals approximately $94,000. The project is financially attractive under the stated assumptions, but sensitivity analysis should test lower benefits, delayed realisation, cost overruns and volume changes.

6. Configuration, governance and implementation method

Configuration should be controlled through a design authority that includes business and technical owners. Decisions must be documented in a configuration workbook or equivalent repository. Important controls include naming standards, approval thresholds, segregation of duties, version control, release management and traceability from requirement to configuration and test.

Implementation methods may be sequential, agile, iterative or hybrid. A sequential approach can provide strong stage control for complex, regulated environments. Agile methods support incremental learning and user feedback but require disciplined product ownership and a stable definition of done. A hybrid approach is common: architecture and controls are established early, while process configurations and integrations are refined through iterations.

A multi-site rollout may use a pilot, template deployment, wave rollout or big-bang transition. A pilot reduces uncertainty and creates learning, but it may not expose all network complexity. A template can support standardisation, while local deviations should be justified and governed. Big-bang deployment may shorten the transition period but concentrates operational risk.

7. Testing, data migration and readiness

Testing should be risk-based and progressive:

• Unit testing: verifies an individual configuration or development component.
• System integration testing: verifies interactions among WMS, TMS, ERP, carriers and devices.
• End-to-end testing: follows a business transaction from demand through fulfilment, transport and financial update.
• Performance testing: evaluates response time, throughput, concurrency and recovery under expected and peak loads.
• User acceptance testing: confirms that business users can perform agreed scenarios and that outcomes are acceptable.
• Operational readiness testing: validates procedures, support, devices, facilities, staffing and contingency arrangements.

Test cases should include exceptions, boundary conditions, invalid data, duplicate messages, interface delays, device failure, carrier rejection, partial shipment, returns and recovery after outage. Defects should be prioritised by business impact, not merely by technical severity.

Data migration commonly includes item, location, customer, supplier, carrier, inventory, open orders, shipment rules, rates and user/security data. The migration process is extract, profile, cleanse, transform, validate, load, reconcile and approve. Data owners must be accountable for quality; IT cannot correct business meaning without business decisions.

Reconciliation should compare record counts, quantities, values, status totals and control totals between source and target. For inventory, physical counts and system balances should be reconciled before cutover. Historical data may be archived rather than migrated when operational access is unnecessary, provided legal, audit and analytical requirements are met.

8. Cutover, training and change management

Cutover is the controlled transition from the old operating model to the new one. A cutover plan should identify activities, dependencies, owners, start and finish times, decision gates, rollback criteria and communication channels. Activities may include final master-data loads, open-order conversion, inventory freeze or count, carrier confirmation, device preparation, label validation, user provisioning and production smoke tests.

A “go/no-go” decision should be based on evidence: critical defects closed or accepted, interfaces stable, users trained, support staffed, data reconciled, contingency procedures tested and operational leadership prepared. Rollback is not always feasible after physical movements begin, so the plan should include forward-recovery procedures as well as technical restoration.

Training should be role-based and scenario-driven. Pickers need practical transaction competence; planners need planning, tendering and exception skills; supervisors need monitoring and intervention capability; administrators need configuration and support knowledge. Super users can provide local reinforcement, but they should not become an informal substitute for documented support.

Change management addresses the human consequences of altered roles, measures, authority and routines. Resistance may indicate fear, insufficient participation, poor design or legitimate operational risk. Effective practice includes stakeholder analysis, visible sponsorship, two-way communication, local champions, feedback loops, training, coaching and reinforcement through performance management. Incentives should not encourage unsafe work, inventory manipulation or premature shipment confirmation.

9. Post-implementation stabilisation and benefits realisation

The first weeks after go-live require heightened support, daily issue review and disciplined prioritisation. A command centre should monitor orders, receipts, picks, shipments, interface queues, carrier responses, inventory accuracy, system availability and user incidents. Temporary workarounds must have owners and expiry dates.

Benefits realisation begins before go-live. Baseline measures should be collected during the current state, targets should be defined, and measurement ownership should be assigned. Useful indicators include:

Measures need precise definitions. For example, “on-time delivery” must specify the promised window, event source, treatment of customer-requested changes and treatment of missing tracking data. A metric can be calculated as a percentage when the numerator is a subset of the denominator:

The organisation should avoid optimising one function at the expense of the whole system. A warehouse may increase pick rate by creating transport congestion; a TMS may reduce freight cost by selecting a slower service that damages customer retention. Balanced scorecards and cross-functional governance help prevent local optimisation.

10. Governance, cybersecurity, ethics and regulation

WMS–TMS platforms process commercially sensitive information, personal data, shipment locations, customer addresses, trade documentation and sometimes regulated product information. Governance should address identity and access management, least privilege, segregation of duties, encryption, logging, vulnerability management, backup, disaster recovery, vendor access and incident response.

Cloud contracts should clarify data location, subcontractors, service levels, breach notification, portability, exit assistance, audit rights and deletion. Business continuity planning should identify manual operating procedures, recovery priorities, recovery-point objectives and recovery-time objectives. These objectives are organisation-specific and must be tested rather than assumed.

Ethical issues include worker surveillance, algorithmic allocation of tasks, automated performance scoring, fairness in carrier selection and the risk that productivity targets encourage unsafe behaviour. Data collected for operational improvement should not be repurposed for intrusive monitoring without transparency and appropriate governance. Automated decisions should be explainable enough for affected managers and workers to challenge errors.

Regulatory requirements vary by jurisdiction and industry but may include hazardous-material rules, customs documentation, food and pharmaceutical traceability, records retention, occupational safety, privacy and electronic transaction laws. Compliance must be designed into processes and controls rather than added as a final checklist.

11. Technology and contemporary developments

Modern platforms increasingly use application programming interfaces, event-driven integration, mobile devices, robotics, digital twins, cloud analytics and artificial intelligence. These technologies can improve visibility and planning, but they do not eliminate the need for clean data and accountable processes.

AI may support demand-informed labour planning, anomaly detection, estimated-time-of-arrival prediction, slotting recommendations and carrier selection. Before deployment, organisations should define the decision boundary, training-data quality, monitoring method, human override, performance drift controls and accountability. A model that predicts late delivery accurately on historical data may fail when carrier behaviour, weather, network design or customer mix changes.

Robotics and automation require a business-process and safety assessment. Automation should be evaluated on throughput, variability, maintainability, failure modes, ergonomics, integration and total lifecycle cost—not only on nominal speed. Digital twins can support scenario analysis, but their conclusions are only as reliable as the assumptions and data underlying the model.

Applied case: illustrative omnichannel rollout

Background

Northstar Home Products, an illustrative mid-sized distributor, operates two warehouses and ships to retailers, e-commerce customers and service technicians. It uses an ERP, spreadsheets for wave planning and several carrier portals. Annual order volume is growing rapidly, while inventory accuracy and delivery reliability are declining.

Problem

The company experiences frequent short picks, duplicate transport bookings, manual freight reconciliation and poor visibility of parcel and less-than-truckload shipments. Management considers separate WMS and TMS purchases but has no agreed future-state process or business case.

Analysis

A cross-functional team observes receiving, picking, packing, dispatch and transport planning. It discovers that item dimensions differ among the ERP, carrier portals and spreadsheets. Warehouse supervisors release work based on local experience, while transport planners receive incomplete shipment information late in the day. The baseline shows 97.2% inventory accuracy, 89% on-time delivery and substantial manual effort in freight reconciliation.

The team identifies three root causes: inconsistent master data, disconnected release and transport-planning decisions, and undefined exception ownership. It therefore rejects a narrow “install a WMS” approach.

Approach and solution

Northstar selects a cloud WMS and TMS through scenario-based demonstrations. Standard WMS receiving, directed put-away, cycle counting, barcode picking and packing are adopted. TMS capabilities include consolidation, carrier tendering, tracking and freight audit. A limited extension is approved for a regulatory label requirement; several requested custom screens are rejected in favour of standard configuration.

The implementation begins with item, packaging, location and carrier-data governance. A pilot site is used for end-to-end testing, followed by a controlled rollout. The cutover includes a physical inventory count, open-order conversion, carrier certification and two weeks of enhanced support. Super users are assigned to each shift, and a daily benefits dashboard is reviewed by operations and finance.

Outcome

After stabilisation, the company reports improved inventory accuracy, fewer duplicate bookings and better shipment visibility. The results are treated as provisional until measured over a full seasonal cycle. Management also identifies an unintended effect: initial transport consolidation increases warehouse staging congestion. The future-state process is revised to include earlier planning and additional dispatch-slot controls.

Learning points

The case demonstrates that technology selection must follow process and data understanding. It also shows why benefits should be measured across functions, why exceptions require explicit ownership, and why implementation is an organisational change rather than an IT event.

Challenges and limitations

WMS–TMS programmes face recurring risks: underestimated data cleansing, excessive customisation, weak integration ownership, unrealistic productivity assumptions, inadequate peak-volume testing, insufficient super-user coverage, vendor dependency and benefits claimed without a baseline. There is also a tension between global standardisation and legitimate local requirements. Standardisation lowers complexity, but forcing a process that conflicts with legal, safety or physical constraints can create hidden workarounds.

Business cases are particularly vulnerable to optimism bias. Benefits may be double-counted, attributed to the system when caused by unrelated initiatives, or measured before operations stabilise. Sensitivity analysis, independent challenge and post-implementation review improve credibility.

Finally, system visibility does not automatically create supply-chain control. A dashboard can expose a late shipment without providing capacity, inventory or managerial authority to correct it. Technology must therefore be embedded in a capable operating model with decision rights, skills and supplier collaboration.

Best-practice principles

1. Start with strategic outcomes and measurable baselines.
2. Observe real work before specifying software.
3. Separate standard fit, configuration, process change and customisation.
4. Treat master data as a governed product, not a migration task.
5. Test end-to-end and include exceptions and peak conditions.
6. Make integration ownership, reconciliation and monitoring explicit.
7. Use role-based training and visible operational sponsorship.
8. Plan forward recovery as well as rollback.
9. Measure benefits across warehouse, transport, customer and financial outcomes.
10. Govern AI, automation, privacy and worker impacts responsibly.

Chapter Summary

WMS–TMS selection and implementation is a strategic transformation involving processes, people, data, technology and governance. Effective programmes translate strategic objectives into testable requirements, map current and future processes, evaluate solutions through realistic scenarios and conduct disciplined fit–gap analysis. Business cases should distinguish costs, benefits, timing and risk, using consistent financial assumptions.

Successful configuration favours standard capability and controlled extensions. Integration must provide reliable, traceable and reconcilable transactions. Data migration requires business ownership, while testing must progress from component verification to end-to-end, performance and operational readiness testing. Cutover, training and change management determine whether a technically sound solution becomes an operationally adopted one.

Post-implementation governance should stabilise operations, measure benefits against baselines and prevent local optimisation. Cybersecurity, privacy, safety, ethical use of analytics and regulatory compliance are integral design concerns. Contemporary technologies such as cloud platforms, AI, robotics and digital twins can create value, but only when supported by sound data, accountable decisions and a capable operating model.

Key Terms

Business case: Structured justification of an investment, including costs, benefits, risks and assumptions.

Cutover: Controlled transition from the existing system and process to the new operating environment.

Fit–gap analysis: Comparison of required capabilities with standard product capability and identification of treatment options.

Go/no-go decision: Formal decision on whether conditions are sufficient to commence production operation.

Master data: Relatively stable data, such as items, locations, customers, carriers and packaging attributes, used across transactions.

NPV: Net present value of time-adjusted cash flows from an investment.

OMS: Order management system that captures and orchestrates customer demand.

Pilot: Limited initial deployment used to learn, test and reduce rollout risk.

Process mapping: Visual or structured representation of activities, decisions, inputs, outputs, roles and controls.

Requirements traceability matrix: Record linking requirements to sources, design decisions, tests and acceptance.

Rollback: Reversal to the previous system or operating state when defined conditions are not met.

Super user: Trained operational user who provides local support, feedback and reinforcement.

TCO: Total cost of ownership across acquisition, implementation, operation, support and retirement.

TMS: Transportation management system supporting planning, execution, visibility and freight settlement.

User acceptance testing: Business-led testing to determine whether the solution is acceptable for operational use.

WMS: Warehouse management system controlling and recording warehouse inventory and activities.

Weighted scoring model: Evaluation method that combines criterion weights and vendor ratings.

Benefits realisation: Planned measurement and management of outcomes after implementation.

Review Questions

Short Answer Questions

1. What is the difference between a WMS and a TMS?
2. Why should requirements be written in a testable form?
3. What are the principal categories in fit–gap analysis?
4. Why is master-data governance important to both WMS and TMS performance?
5. What is the purpose of a go/no-go decision?

Long Answer Questions

1. Explain how an organisation should move from strategic objectives to WMS–TMS system requirements.
2. Compare configuration, process change, extension and customisation as responses to a solution gap.
3. Describe a comprehensive testing strategy for an integrated WMS–TMS implementation.
4. Explain how training and change management influence implementation outcomes.
5. Discuss how benefits realisation should be designed, measured and governed after go-live.

Analytical / Application Questions

1. A retailer has accurate warehouse inventory but frequent late deliveries caused by incomplete shipment information. Analyse the likely process and integration causes and propose a future-state design.
2. A vendor scores highly on functionality but requires extensive customisation and has weak local support. Develop a decision framework that weighs capability, lifecycle risk and total cost.
3. An implementation delivers higher pick productivity but also increases dispatch congestion and expedited freight. Design a balanced measurement and corrective-action plan.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents a disciplined requirements hierarchy?

A. System feature → vendor → strategy → benefit

B. Strategic objective → capability → process requirement → system requirement → benefit

C. Training plan → process map → strategy → software licence

D. Budget → customisation → interface → operating model

Correct Answer: B. Strategic objective → capability → process requirement → system requirement → benefit

Question 2

Which fit–gap treatment is generally preferred before customisation?

A. Immediate source-code modification

B. Manual spreadsheet duplication

C. Standard fit, configuration or justified process change

D. Deferring every requirement until after go-live

Correct Answer: C. Standard fit, configuration or justified process change

Question 3

What is the primary purpose of idempotent integration processing?

A. To increase the number of duplicate transactions

B. To ensure repeated messages do not create duplicate business events

C. To eliminate the need for master data

D. To replace user acceptance testing

Correct Answer: B. To ensure repeated messages do not create duplicate business events

Question 4

Which testing level follows a business transaction across WMS, TMS and connected systems?

A. Unit testing

B. End-to-end testing

C. Interface code inspection only

D. Screen usability testing only

Correct Answer: B. End-to-end testing

Question 5

If an investment costs $500,000 and produces $650,000 of relevant benefit over the selected period, what is the simple ROI?

A. 15%

B. 23.1%

C. 30%

D. 76.9%

Correct Answer: C. 30%

Question 6

Which item is most appropriately treated as master data?

A. A single carrier tender response

B. A customer’s one-time delivery event

C. An item’s packaging dimensions and units of measure

D. A temporary system error message

Correct Answer: C. An item’s packaging dimensions and units of measure

Question 7

Why should a cutover plan include forward-recovery procedures?

A. Technical rollback may be impractical once physical transactions begin

B. Forward recovery removes the need for training

C. It guarantees that no defects will occur

D. It replaces data reconciliation

Correct Answer: A. Technical rollback may be impractical once physical transactions begin

Question 8

Which measure requires a clearly defined numerator and denominator?

A. On-time delivery rate

B. Vendor name

C. Warehouse address

D. System colour scheme

Correct Answer: A. On-time delivery rate

Question 9

What is a major governance concern when AI is used for worker performance scoring?

A. The elimination of all data-quality requirements

B. Potential opacity, unfairness and incentives for unsafe behaviour

C. The impossibility of monitoring model drift

D. The automatic removal of human accountability

Correct Answer: B. Potential opacity, unfairness and incentives for unsafe behaviour

Question 10

A positive NPV under stated assumptions means that the project:

A. Will definitely achieve all operational benefits

B. Has value under the selected cash-flow and discount-rate assumptions

C. Has no implementation risk

D. Has a higher ROI in every possible scenario

Correct Answer: B. Has value under the selected cash-flow and discount-rate assumptions