Don’t Ignore the Desire Paths
Sitting in Boston and writing this just days after the city received 2 feet of snow, I can’t help but think about the importance of desire paths.
These are the illicit trails through the drifts and across the university quad, formed where pedestrians abandon the uneven sidewalks for a more direct route. They represent a rebellion of utility against design.
Traditional landscape architects might view these trails as a nuisance to be fenced off. Progressive planners see them as pure, unfiltered data. They pave the desire path, acknowledging that collective intelligence has discovered a safer, more efficient way to navigate the world.
This concept is profoundly relevant to supply chain and procurement software. In the digital landscape, the “sidewalks” are standard operating procedures, rigid workflows and compliance algorithms hard-coded into ERP and transportation management systems (TMS). The “desire paths” are the hacks, workarounds and overrides that practitioners employ.
When users create a desire path, they’re not necessarily being non-compliant. Indeed, they’re signaling that the system’s design doesn’t meet the reality of their environment. To build truly resilient supply chains, we must stop building fences to enforce compliance and start analyzing the “why” behind the deviation.
Beyond the Algorithm
Consider truck routing software. A centralized TMS might calculate a mathematically optimal route based on distance, speed limits and traffic data. A veteran driver, though, might consistently ignore the turn-by-turn instructions, taking a longer bypass or a side street.
A rigid management approach views this as a compliance failure — a problem to be solved with stricter monitoring or locked GPS units. But it ignores why the driver is choosing that path. Maybe the intersection’s turn radius is too tight for a 53-foot trailer, or there was a recent rash of theft in the area. The driver has local knowledge that the algorithm lacks, and the deviation is a safety mechanism.
By ignoring this desire path, the centralized system stays ignorant of a real risk. By analyzing it, the system can be updated to flag that intersection as non-navigable for heavy trucks, or the neighborhood as a place to avoid, permanently improving the route for the entire fleet.
Hacks as a Hidden Efficiency
Nowhere are desire paths more prevalent — or more misunderstood — than in procurement. These systems are typically designed to emphasize control, audit trails and cost reduction, yet the people using them are often measured on speed and continuity of supply. This misalignment is fertile ground for digital shortcuts.
Consider the hack of splitting POs. Imagine a system that requires three competitive bids and executive sign-off for any purchase over US$5,000. A critical piece of machinery fails, and the replacement part costs $6,000. To move things along, the buyer issues separate POs for $3,000 each to the same vendor.
The “fence-builder” sees this as maverick spend and a governance violation to be blocked by code. The desire path analyst recognizes a rational act to save time and money, despite the system’s rules. The fix isn’t to block the PO split. It’s to build an "emergency fast-track" workflow into the system.
Another common desire path in procurement is the “excel shadow.” This happens when teams extract data from their expensive ERP, manipulate it in spreadsheets, and then import it back to the ERP (or simply email the file around).
This desire path screams that the ERP’s interface is too clunky, its reporting too rigid, or its bulk-editing capabilities insufficient. Hacks give users the agility they really need.
The Value of the ‘Why’
The big error in modern software deployment is assuming the centralized system knows more than the local user. Binary code can’t capture the mood at a receiving dock or the urgency of a customer request. Every deviation is a data point indicating friction. Investigating the why behind it usually uncovers one of three things:
- Process inefficiency. The paved path takes 10 clicks when the user needs two.
- Data gaps. The system optimizes for variables that don’t reflect current reality (for example, optimizing for price when the constraint is lead time).
- User interface failure. The software is hard to navigate, forcing users to work outside it.
If we treat user deviations as errors to be stamped out, we stifle the very human ingenuity that keeps supply chains running. We build rigid systems that look perfect on a dashboard but fail on the shop floor.
Instead, developers and managers need to think like landscape architects. When you see a trail worn deep into the digital lawn — like a driver’s route change or buyer’s PO split — don’t put up a “keep off the grass” sign. Instead, analyze the route. Understand the destination. Then, pave the path.