A supply chain optimization case rarely starts with an isolated problem. It usually manifests as a combination of urgencies: stockouts of critical references, excess inventory in others, reactive purchasing, costly shipments, and teams working with different spreadsheets to answer the same question: what is available, where it is, and when it will arrive.
For a COO, CTO, or operations manager, the challenge is not just to incorporate a planning tool. It is about building operational capability: reliable data, explicit decision rules, integration between systems, and an architecture that can evolve when suppliers, sales channels, or demand patterns change.
This article analyzes a representative case of a B2B industrial distribution company with operations in the United States. It does not describe a miraculous implementation. It describes how to approach the diagnosis, which technical decisions matter, and what results are reasonable when connecting supply strategy with technological execution.
The Starting Point: Growth Without Operational Visibility
The company managed approximately 12,000 references, three warehouses, and a network of national and international suppliers. For years, the volume had been managed with a legacy ERP, files exported every night, and a set of spreadsheets maintained by purchasing, warehouse, and finance.
The model worked while the catalog was stable and lead times were predictable. It stopped working when urgent orders increased, the supplier base expanded, and some customers began to demand stricter service levels. Each department had valid data within its context, but there was no common operational view.
The effect was well known. Purchasing raised orders to protect against uncertainty. The warehouse detected discrepancies between physical and available stock. Sales confirmed dates based on information that had already changed. Finance saw working capital grow without being able to accurately distinguish which inventory protected revenue and which was simply excess.
Management had identified inventory as the problem, but the initial diagnosis showed something more precise: the problem was the quality and latency of inventory decision-making.
Diagnosis of the Supply Chain Optimization Case
Before selecting technology, the team defined an operational baseline. This step avoids one of the most common mistakes: measuring success by the implementation of a system, rather than by the improvement of service, cost, and responsiveness.
They analyzed twelve months of orders, warehouse movements, purchase orders, returns, and forecasts. They also held working sessions with heads of purchasing, planning, logistics, sales, and finance. The goal was to contrast what the systems recorded with the actual way decisions were made.
The analysis revealed four main causes:
- Product, supplier, and logistics unit master data did not follow homogeneous criteria.
- Available stock was calculated differently in the ERP, the warehouse management system, and commercial spreadsheets.
- Reorder points were updated manually and did not reflect changes in demand, lead time, or supplier reliability.
- Exceptions were handled via email and calls, without traceability or shared priorities.
The consequence was not just administrative inefficiency. It was a direct loss of margin. Urgent purchases, expedited shipments, and lost sales due to lack of availability were linked to decisions made with incomplete information.
Separating Symptoms from Real Constraints
Not all excess inventory should be eliminated. In an environment with distant suppliers, highly critical components, or demanding service commitments, maintaining safety stock can be the right decision. The problem arises when the level of protection does not respond to a visible and quantifiable policy.
Therefore, the team classified references according to commercial criticality, demand variability, margin, replenishment lead time, and substitutability. A low-cost part that halts a customer's operation requires different treatment than a low-turn product that can be served on demand.
This segmentation allowed them to abandon a one-size-fits-all rule for the entire catalog. It also made visible a business decision that was previously implicit: what level of service the company was willing to finance in each category.
Designing the Database and Architecture Before Automating
The answer was not to immediately replace the ERP. A complete change may be justified if the platform structurally limits operations, but it can also increase risk and delay results. In this case, a gradual architecture was chosen that leveraged existing transactional systems while creating an independent data and decision layer.
The first component was a common operating model. Product identifiers, locations, units of measure, order statuses, supplier lead times, and availability rules were standardized. Each critical data point received a business owner and defined quality controls.
Next, an integration layer was built to extract events from the ERP, warehouse management system, order platform, and supplier sources. Instead of relying on nightly exports, relevant changes were processed with a frequency aligned with the process. Physical stock could be updated almost in real-time, while certain financial indicators followed a daily cadence.
This distinction matters. Not all data requires the same immediacy, and treating everything as real-time increases costs and complexity without always generating more value. The architecture must respond to the decision that needs improvement: promising a delivery date requires updated information; recalculating an inventory policy can work perfectly with daily execution.
An Explainable Decision Engine
On that basis, a planning service with versioned rules was implemented. The engine calculated purchase and transfer recommendations between warehouses using historical demand, open orders, committed stock, stock in transit, supplier lead time, and safety stock by segment.
The design avoided turning the model into a black box. Recommendations included an explanation: expected demand, available coverage, estimated stockout date, and variables that had triggered the alert. Purchasing could accept, adjust, or reject the recommendation, but each exception was recorded.
Explainability was crucial for adoption. An experienced planner knows circumstances that are not yet reflected in the data, such as a commercial negotiation, a change announced by a customer, or a quality issue. Automation should concentrate information and reduce repetitive work, not eliminate professional judgment where it is still necessary.
From Dispersed Alerts to Exception Management
With consolidated data, the team replaced much of the manual review with a prioritized exception queue. Instead of reviewing thousands of references, planners first addressed situations likely to impact revenue, service level, or shipping cost.
Each exception included enough context to act: affected order, customer, product, available alternative, involved supplier, risk date, and suggested action. Decisions were recorded in the workflow and returned to transactional systems through controlled integrations.
This change reduced reliance on informal messages and provided traceability. If a delivery was delayed, the company could analyze whether the source was a forecasting error, an incorrect supplier lead time, an inventory discrepancy, or a business priority introduced outside the standard process.
Traceability also improved conversations with suppliers. Instead of discussing perceptions, purchasing could review compliance with deadlines, lead time variation, and frequency of incomplete deliveries by product family.
Results: Measuring Impact Without Simplistic Attributions
During the six months following the gradual deployment, the company reduced the average inventory value in selected categories without deteriorating the service level. Urgent shipments decreased, and the time planners spent reconciling files was reassigned to reviewing suppliers and high-impact exceptions.
Attributing each improvement solely to the software would be incorrect. The results came from a combination of refined data, revised inventory policies, technical integration, process discipline, and active operations participation. The platform enabled faster and more consistent decisions, but it did not replace the work of defining priorities.
The indicators that management monitored weekly were service level by segment, stockout rate, days of inventory, value of obsolete stock, cost of expedited shipments, forecast accuracy, and supplier compliance with deadlines. Not all improved at the same pace. Forecast accuracy took longer because it depended on seasonal patterns and better capture of business signals.
What a Management Team Should Decide Before Investing
The initial question should not be which supply chain platform to buy. It should be which decisions need better information and what is the cost of continuing to make them late or manually.
A company with relatively stable processes may achieve quick results by improving master data, integrations, and replenishment rules within its ERP. Another, with multiple warehouses, variable suppliers, and complex service commitments, may need a specific planning layer, advanced analytics, and flow automation. It depends on volume, variability, and the cost of exceptions.
It is also advisable to define from the outset which systems are the source of truth for each entity. When two platforms can modify the same data without a clear ownership rule, automation amplifies the problem. A sustainable architecture establishes responsibilities, integration contracts, monitoring, and procedures for managing failures.
At StrateCode, this type of initiative is approached by combining operational diagnosis and technical execution: first, the decision that generates cost or risk is identified; then, the minimum necessary architecture to improve it is designed and deployed in measurable phases.
Supply chain optimization is not about pursuing a perfect forecast. It is about creating a system that detects uncertainty earlier, makes its consequences visible, and allows the team to act with shared criteria. This capability continues to generate value when demand, suppliers, and business priorities change.
