A weekly buying process was costing us the market.

When a standard purchasing process stops fitting the market

When I took over Kingston memory at Tech Data, the category was being managed much like any other product line. Purchasing received a weekly price list, calculated the required stock and placed an order according to expected demand.

For many technology products, that was a perfectly reasonable process. Memory behaved differently because most of the value of a module sat in the underlying chips, and those chips effectively traded on a global market where pricing could move quickly as supply and demand changed.

Taiwan played an important role because of its concentration of chip manufacturing. During typhoon season, for example, the market could react to the risk of production or power disruption before any physical shortage had reached Europe. Expectations alone were sometimes enough to move pricing.

‍

Why weekly replenishment was too slow

That volatility created a commercial reality that did not fit the existing purchasing rhythm. When prices were rising, buying too little could leave Tech Data without stock just as customer demand accelerated. Resellers and sub-distributors could clear available inventory quickly, leaving Sales with opportunities that could no longer be fulfilled.

Falling markets created the opposite problem. If too much stock had been purchased at a higher cost, newer inventory could enter the market below our existing purchase price. The longer that stock remained in the warehouse, the more pressure it placed on margin and the harder it became to move without taking a commercial loss.

The category therefore carried a level of timing risk that standard replenishment processes were not designed to manage.

‍

Recognising that the process, not the people, was the problem

Initially, I treated the issue as a purchasing problem and challenged the buyer repeatedly about order timing, quantities and pricing. I wanted to understand why we had not bought earlier when prices rose, reduced inventory faster when prices fell or negotiated more aggressively when conditions were favourable.

In hindsight, that criticism was misplaced. The buyer was following the process exactly as it had been designed. The real problem was that the system assumed the market moved slowly enough for a weekly purchasing cycle to remain effective.

Once that became clear, the solution had to involve changing the operating model rather than asking people to work harder within the same constraints.

‍

Creating flexibility outside the normal purchasing rhythm

After several months of pushing the issue, and with support from my manager, I made the case to the CFO and warehouse leadership for a different approach. I was given a personal credit line that allowed me to place special orders outside the standard purchasing cycle.

That flexibility changed the way the category could be managed. Memory could now be treated less like routine stock replenishment and more like a market position that needed to respond to changes in pricing, supply and expected demand.

The objective was not to speculate for its own sake. It was to align purchasing decisions more closely with the speed and direction of the market.

‍

Combining market intelligence with inventory decisions

We began using several forms of information together. Pricing movements were monitored more closely, potential production disruptions were treated as early warning signals, and inventory levels were adjusted according to whether the market appeared to be rising or falling.

When prices were moving down, I could reduce exposure by buying only one or two days of expected demand. When supply looked tighter or prices appeared likely to rise, the business could buy several weeks ahead and secure inventory before the market moved further.

That created a more active relationship between market intelligence and purchasing. Inventory was no longer determined only by historical sales and standard reorder logic, but by a broader view of what was likely to happen next.

‍

Using scale to create purchasing leverage

Tech Data's scale made the model particularly effective. Individual customers often had relatively modest requirements, but the combined demand across thousands of accounts was substantial and reasonably predictable.

That meant I did not need to wait for one large customer order before negotiating meaningful volume. I could aggregate expected future demand across the customer base and create the purchasing scale myself when market conditions justified it.

This improved the negotiating position with suppliers and made it possible to secure pricing or availability advantages that individual customers would not have been able to create on their own.

‍

Turning procurement into part of the commercial strategy

The category gradually stopped behaving like a traditional purchasing function supporting Sales after demand had already appeared. Procurement became part of the commercial strategy itself.

Better market intelligence influenced what we bought and when we bought it. Those purchasing decisions affected availability and pricing, which in turn gave Sales a stronger position with customers. The relationship between Product Management, procurement and Sales became much more dynamic because each function was now influencing the same commercial outcome.

That shift also changed the role of inventory. Stock was no longer just something to replenish or minimise. Managed correctly, it became a competitive asset.

‍

Building share through better timing and market understanding

Over time, the approach contributed to Tech Data reaching roughly 50 to 60 percent market share in the category.

The result did not come from a single pricing decision or one favourable market cycle. It came from managing the category according to the way the market actually behaved rather than according to the process that had historically been used.

The broader lesson was that operating models need to reflect the speed and economics of the market they are designed to support. When the underlying environment changes faster than the process can respond, better execution inside the old process is rarely enough.