The DDIT Framework

Most failed supply chain projects start with the same mistake: the solution gets picked before the diagnosis is done. A manager saw a tool or a method work somewhere else and wants to replicate it — without knowing whether their actual problem is the one that tool was built to solve.

The Diagnose stage of the DDIT framework exists specifically to prevent that mistake. Work starts with the organization's existing data — inventory levels, forecast accuracy, on-time delivery rate, cost structure — but doesn't stop there. Data alone doesn't lie, but it rarely tells the whole story either. A full warehouse could signal weak forecasting, or it could be a deliberate hedge against supply risk. Only by sitting with the people who make that call every day can you tell which one it is.

That's why diagnosis at SCM LAB always has two layers: quantitative analysis of the organization's existing data, and structured conversations with key stakeholders — from the planning analyst to the CEO. The output of this stage isn't a list of 'things done wrong.' It's a map of root causes, usually sitting two or three layers beneath the visible symptoms.

Design is where most generic consulting slips: taking a standard model (an MRP method, an S&OP cycle, an inventory policy) from a previous project and dropping it into the new organization with minor tweaks. The problem is that every organization has its own constraints — the current ERP system, data maturity, decision-making culture, and even who actually has the authority to change a process.

In the DDIT framework, design always starts from the output of the Diagnose stage, not from a pre-built template. If the root cause is distrust between sales and production, the fix isn't a new spreadsheet — it requires redesigning the shared decision process. If the root cause is a lack of clean data, any sophisticated tool built on dirty data just repeats the same mistake faster.

The design output always has two parts: process design (who decides what, when, with which inputs and outputs) and tool design (what actually supports that process in practice — from a simple Excel template to a Power BI dashboard). Both have to be designed together, because a process without a supporting tool doesn't survive, and a tool without a defined process is just an unused file in a folder.

A lot of consulting projects fail at exactly this stage — not because the design was bad, but because the consulting team 'handed off' the design and left. A new process or a new tool always creates friction in the first weeks: people have old habits, data isn't always clean, and there's always an exception the original design didn't anticipate.

In the DDIT framework, implementation means staying present alongside the internal team through those first weeks — not just for technical troubleshooting, but so that when the first resistance or the first exception shows up, the right call gets made by a team that understands both the design logic and the organization's day-to-day reality.

This stage usually starts with a limited pilot — one production line, one product family, one warehouse — not the whole organization at once. The pilot lets the design get corrected at small scale, before the cost of a mistake repeats at full scale. Once the pilot stabilizes, rollout to the rest of the organization happens with more confidence and less friction.

This might be the most overlooked part of consulting work, and that's exactly why it's a pillar of the DDIT framework. The end goal of a good consulting engagement isn't the client's long-term dependence on the consultant — it's the opposite: the internal team should be able to maintain, adjust, and even extend the new process and tool without outside help.

Capability transfer has three layers: documentation (why a decision was made, not just how to execute it), hands-on training for the internal team on real scenarios (not just a theoretical workshop), and naming a clear internal owner responsible for maintaining the process.

In many of the food and pharma engagements we've run, this stage also includes a short shadowing period — the internal specialist runs the next cycle themselves, with the consultant observing rather than driving. Once that cycle repeats without the consultant's involvement, the project is actually done — not when the final report gets handed over.