What we learned running quarterly supply planning across 5,100 facilities

When we started rolling out ForLab+ across Ethiopia's health facilities, we designed the quarterly planning cycle based on textbook supply chain management. The idea was clean: facilities report consumption, the system forecasts demand, planners allocate stock, and procurement executes. Simple feedback loop.

Twelve quarters later, we've learned that simplicity on paper and simplicity in practice are different things.

The data quality surprise

The single biggest shift in our thinking has been about data quality. We used to treat it as a constraint — "garbage in, garbage out." We built validation rules, enforced fields, added checks. And those things help. But what actually improved data quality was giving people visibility into anomalies in real time.

When a health center reports that they dispensed 10,000 paracetamol tablets in one month but 200 in the next, the old system flagged it as an error. Planners would email asking what happened. By the time they got an answer, the planning window had closed.

With ForLab+, the facility sees the anomaly immediately. They can explain it while they're looking at their own ledgers. Often it's real — a malaria outbreak, a reference from lower-level facilities. Sometimes it's a data entry error they catch and fix on the spot. Either way, the forecast is more accurate because we resolved ambiguity faster.

Regional variation is real and persistent

We built baseline forecasting models on national aggregate data. The assumption was that with enough facilities, regional variation would average out. That was wrong.

Addis Ababa's health facilities operate in a very different context than, say, Afar Region. Urban density, population age distribution, disease burden, and NGO presence all shape consumption patterns. A malaria drug forecast that works for Oromia doesn't work for Amhara.

What we've learned is that the system gets smarter the longer it runs in a specific region, not just the more data it sees overall. Three years of Amhara data is more predictive of next quarter in Amhara than three years of national data. This is obvious in hindsight, but it changed how we think about the model: not a national system with regional parameters, but a system that learns locally over time.

Speed matters more than we expected

The original plan was to do quarterly planning once a quarter — facility reports, consolidate, forecast, plan, order. We'd get it right eventually. Accuracy was the goal.

What we didn't anticipate is how much planning happens outside the formal cycle. When a facility runs out of stock mid-quarter, the pharmacist doesn't wait three months. They improvise, request emergency supplies, or work around the shortage. If the system can't react in weeks or days, it's not actually part of the decision-making process.

So we shifted. Now the system produces updated forecasts weekly. Planners can issue emergency orders when anomalies appear. The formal quarterly review is more about confirming the trajectory and locking in tenders for next quarter than about discovering what happened.

This made us faster, but it also made the planning process much more iterative. Planners don't just execute a plan; they're constantly adjusting it. The system needs to support that kind of continuous reasoning, not just point-in-time decisions.

What we got right

The decision to keep facility data in-country was correct. Ethiopian facilities trust the system more because the data stays in the Ministry of Health's infrastructure. There's no black box in the cloud, no foreign company controlling the numbers. The system is theirs.

Aligning with the ministry's existing forecasting process was also essential. We didn't ask facilities to change how they work; we asked them to work faster with better information. That small shift in framing — we're not restructuring your process, we're optimizing what you're already doing — was crucial to adoption.

What comes next

The next phase is learning from interaction history. After three years of operations, we have a detailed record of how planners actually reason about their data. Which alerts do they act on? Which do they override? How do they handle trade-offs between cost and stock-out risk?

That intelligence should flow back into the system. The model should learn from how planners work, not just from the raw data. That's the hard part. Not algorithms, but millions of small interactions that compound into better decisions over time.

Last reviewed: March 2026