Procurement Tracking System

The problem

Three years of outdated data and no structure to work from

The company's existing system — pcMRP — hadn't been maintained in roughly three years. Stocking levels were wrong, open orders weren't logged, closed orders were still showing as active, and there was no reliable record of what was in inventory or what was owed to customers. Every team was working off their own version of the truth: emails, personal spreadsheets, and verbal updates.

With no foundation to build on, the backlog was growing invisibly. There was no way to know which orders were at risk, which suppliers were behind, or which customer escalations were about to happen — until they already had. To fix this, I implemented a monthly physical recount of all 952 parts, turning inventory accuracy from a one-time cleanup into an ongoing process.

Process

Audit first, align second, build third

The first priority wasn't designing a new system — it was understanding the full extent of what was broken. I audited the existing pcMRP data to assess what could be salvaged and what needed to be rebuilt from scratch. What I found: stocking levels were approximately three years out of date, open orders had no current status, and closed orders were still cluttering the active queue. The system couldn't be trusted as a starting point — everything had to be built from scratch.

Because this work touched procurement, sales, and logistics, cross-team alignment was essential before any solution could stick. I worked with the operations team to define a shared workflow — standardizing how orders moved from customer PO intake through to invoicing — so that everyone was operating from the same process, not just the same spreadsheet.

Order confirmation workflow defined collaboratively with the operations team — covering PO receipt through invoice generation across procurement, sales, and logistics.

Key decisions

Four tabs, one system — built for the gap pcMRP left behind

Since pcMRP couldn't be relied on for current data, the system needed to operate independently while the underlying ERP was eventually cleaned up. The core design decision was to separate concerns into four focused tabs rather than one overwhelming master sheet — each serving a distinct user need, with shared fields creating a natural cross-reference layer between them.

• 1Urgency tiers on the Order Tracker let the team open the file and immediately know what needed same-day action — no sorting or filtering required.
• 2Logging PR approval time vs. PO sent time exposed where delays actually originated — internal approval bottlenecks, not vendor slowness.
• 3The "Fully Closed?" field on the RMA tab was added after discovering returns were being closed prematurely, triggering repeat escalations with the same customers.
• 4Blanket pricing in its own tab gave the team a live reference during vendor negotiations and helped set realistic delivery expectations with customers.

Impact

Lead times dropped — and kept dropping

The charts below are from a presentation I put together for the operations team showing measurable progress across two periods. In 2024, lead times dropped sharply after the tracking system was implemented and operations meetings were introduced. By 2025, lead times had stabilized at consistently low levels — the improvement wasn't a one-time fix, it held.

Left: 2024 lead times declining sharply after implementation. Right: 2025 lead times stabilized. Bottom: 2024 vs 2025 comparison by customer — all customers improved significantly.

• 1The steepest drop in 2024 coincides with when I initiated weekly operations meetings — visibility alone wasn't enough, a recurring review process was needed to act on the data consistently.
• 22025 lead times flatlined at a low baseline, showing the process improvements were self-sustaining rather than a temporary fix.
• 3Every customer in the 2024 vs 2025 comparison saw reduced average lead times — the improvement wasn't isolated to one account or one product type.

Reflection

What I'd do differently

The Excel system solved an immediate problem, but it was always a workaround rather than a real solution. If I could do it again, I would have pushed earlier and more formally for the branch to be resourced with a dedicated system — one actually built and validated for our operational context, not inherited from a headquarters implementation that was never tested at our scale or structure.

The root cause of the data gap wasn't neglect — it was a failed rollout. HQ implemented a system that worked for their environment but didn't translate to ours, and the fallout left the branch without reliable tooling for years. Knowing that earlier would have changed how I framed the problem to leadership and what I advocated for.

What's next

The branch still needs a proper system

The honest next step isn't a design improvement — it's a resourcing decision. The Excel tracker stabilized operations and proved there's a clear, documentable workflow worth investing in. The case for a dedicated, branch-appropriate system is now easier to make because the data and the process exist to support it.

• 1Use the documented workflow and 12+ months of clean tracking data as evidence when making the case to leadership for proper system investment.
• 2Any future system evaluation should be piloted at the branch level first — the HQ rollout failure showed that a top-down implementation without local validation creates more problems than it solves.
• 3In the meantime, continue monthly inventory recounts and weekly operations meetings to keep the data accurate and the process visible — so nothing reverts to how it was before.