Making Planning Systems Behave: An Interview with Supply Chain Leader Shiv Kumar Lodha

Planning rarely fails loudly. It fails quietly, through workarounds that spread until the “real plan” lives outside the system. That pressure is growing as supply footprints shift. In a 2024 survey, 73% of respondents reported progress on dual sourcing strategies.

Shiv Kumar Lodha builds systems for the moment when planning has to stay credible under stress. He is an Associate Director Supply Chain at Gilead Sciences, a biopharmaceutical company, and his work focuses on making planning dependable in regulated environments where inconsistency creates operational risk. Earlier in his career, one of his planning implementations was recognized internally for delivering a complete solution with cost effectiveness and high benefits. He still treats that as the standard: the system has to behave on the hard weeks, not just the calm ones.

**Shiv, thanks for joining us today. When you say a planning system should “behave,” what does that mean in practice?

It means the plan holds together when reality changes. Demand shifts, supply constraints appear, requirements get updated, and the system still produces outputs people can use without rebuilding the logic outside the tool.
When a planning system does not behave, the symptoms are predictable. Planners create side files, approvals get debated repeatedly, and every cycle becomes reconciliation instead of decision making. Behavior, to me, is consistency under pressure.

What was breaking in the RapidResponse environment before you stabilized pools and channels for supply and production planning?

The gaps showed up where planning needed to reflect attributes that matter in real operations. If the system does not represent regulatory and manufacturing genealogy attributes consistently, you can end up with plans that look aligned in a meeting but fail when execution starts.

Before stabilization, planning had gaps at lower levels and lacked a clean connection between demand and supply at the attribute level. That makes volatility expensive because every change ripples through the plan in ways people cannot predict or defend.

For someone who has never worked in RapidResponse, what did pools and channels solve in your implementation?

The pool and channel concept provided relief by joining regulatory and manufacturing genealogy attributes into the planning model. That matters because attribute based planning reduces supply plan disruption and reduces inventory buildup. You stop creating plans that ignore constraints the business actually has to live with.

It also helped connect demand and supply planning more tightly, which reduces the impact of demand volatility. And it supported planning for lower level bill of materials items, which lowers the risk of building inventory that later becomes obsolete.

You mentioned you created a seven step framework from request intake to delivery. What did that framework change about how work moved through the team?

It changed the work from an informal sequence of handoffs into a visible seven-stage delivery path with business and delivery aligned at each gate: intake, plan, design, playback and demo, build and unit test, UAT, and go-live with hypercare. A request no longer entered as a vague ask. It started as a documented business case that captured requirements, pain points, process gaps, and expected business value. From there, the team walked through the case, prioritized it based on criticality and solution feasibility, and confirmed requirements and business sign-off before moving into design.

That structure kept the middle of delivery from drifting. In design, we reviewed existing solutions, surfaced open questions, and refined requirements where needed. Then, in playback and demo, we walked the business through the design, visualized the change, and showed how the actual reports would look before build began, with revisions made if requirements changed after playback or demo. Build was paired with test preparation, including test cases in GTEST, followed by unit and system testing. UAT then covered end-to-end validation, defect fixes, retesting after fixes, and explicit business approval for deployment. And the process did not stop at release. Go-live included deployment, post-deployment communication, support as needed, document updates, and adoption work through CI, training, and OCM, with sign-off carried through the process rather than left to assumption. What changed, in practical terms, was that the work moved through a defined path with evidence, ownership, and approval at each stage instead of being reinterpreted every time it crossed to the next team.

A lot of organizations are spending more on supply chain technology. What is the biggest mistake teams make when they assume the tool will fix the planning?

They skip the operating discipline. A system cannot compensate for unclear ownership, inconsistent data practices, or a lack of training. It will simply scale those weaknesses.

A recent report from MHI and Deloitte found 55% say they are increasing investment in supply chain technology and innovation. The risk is that spending grows faster than adoption maturity. That is why I treat change management as core delivery work: structured training, repeated coaching, and hypercare after going live so users trust the system in real planning cycles.

Testing is where planning projects either earn trust or lose it. How did you run testing so it actually validated the planning logic?

Testing had to match real planning requirements, not idealized demos. I led multiple testing cycles to validate functionality and data accuracy and to confirm the solution behaved in the scenarios the business actually faced.
That reviewer mindset matters. As a peer reviewer and editorial board member for the Sarcouncil Journal of Entrepreneurship and Business Management and Journal of Economics and Business Management, you learn to look for hidden assumptions and gaps between a claim and the evidence offered to support it. I bring that same standard to testing by asking what could break the logic, where the data might drift, and what results we can prove before asking the business to rely on them.

You also built and coached a team of more than 10 developers. What did it take to lead delivery in a specialized tool environment with limited skilled resources?

You cannot lead that work by delegation alone. You have to coach continuously while keeping delivery moving. That meant building capability inside the team, making the requirements and solution logic explicit, and reducing rework by documenting the end to end process and information flows clearly.

Stakeholder management was part of the job too. When requirements are inconsistent, the team cannot win by working harder. The team wins by tightening definition, holding a disciplined delivery rhythm, and making decisions reviewable so the solution does not drift.

What outcomes did the stabilization work create, in terms the business would care about?

The most concrete outcome was financial. The program was estimated to generate savings of more than $1 million per year with a positive return over five years.

Operationally, it reduced inventory buildup and obsolescence risk and improved demand supply synchronization, with a double digit improvement noted. Those outcomes matter because they reflect a system that behaves consistently enough for the organization to plan with confidence instead of constantly repairing the plan.

Once a system behaves, what does that unlock that teams often underestimate?

It unlocks the ability to plan forward with discipline instead of reacting. Many organizations want scenario planning, but fewer have the foundation to do it credibly. Gartner reported only 19% of organizations fully integrate scenario planning into their supply chain strategies.

That gap is not only about tools. Scenario planning depends on stable attributes, reliable data flows, and a planning process that people follow consistently. When the system behaves, scenarios stop being slides and become decisions the business can stand behind.

To close, what advice do you give to supply chain professionals who want to build planning systems people actually trust?

Treat trust as the output, and design for it deliberately. Define ownership clearly, standardize how exceptions are handled, and insist on evidence through testing before you ask people to rely on the system. Then invest in adoption as seriously as you invest in configuration, because a plan no one trusts is not a plan.

I also believe in shared professional standards. An APICS certification signals that the professional has trained against a structured body of planning knowledge and a common vocabulary across demand, supply, inventory, and operations. When teams share that baseline, alignment gets faster and the system becomes a place where decisions happen, not a place where arguments linger.

Shiv’s through line is simple: planning systems behave when discipline is engineered into how work is defined, built, tested, and adopted. In his RapidResponse stabilization, the point was not only to implement changes, but to make attribute based planning reliable enough to reduce disruption, protect against inventory risk, and deliver measurable savings. The real upgrade is not the software. It is the operating method that makes the software behave.