I talked to a company last year that tracked materials inventory for their projects on notepads. Literal notepads. One guy knew where everything was, how much was left, and when to reorder. He'd been doing it for years. He was great at it.
The problem wasn't that his system didn't work. It did, mostly. The problem was that his system was him. When he took a week off, things fell through the cracks. When two projects were running hot at the same time, he couldn't keep up. And when the owner asked for a report on materials spend across jobs for the quarter, everyone just sort of looked at each other.
This is what business process improvement is actually about. Not jargon, not a consulting framework you hang on the wall. It's looking at how work gets done and asking: can this be better? Can this survive without the one person who currently holds it together?
The real cost of tribal knowledge
Every company has processes that live in someone's head. That's normal. When you're small and growing, documentation is a luxury you can't afford. You hire good people, they figure out how to do the work, and the business moves forward.
But at some point, the company outgrows that approach. The signs are predictable. You can't get a clear answer to a basic question without finding a specific person. Training a new hire takes months instead of weeks because so much knowledge is unwritten. Mistakes happen when the usual person is out, and nobody notices until the consequences show up downstream.
For this particular company, the materials tracking problem was costing them in ways they hadn't fully calculated. They were over-ordering on some materials because nobody had a clear picture of existing stock across job sites. They were under-ordering on others because reorder decisions were based on one person's memory of usage rates. Rush orders were a regular expense because shortages weren't caught early enough.
None of this showed up as a single line item in their P&L. It was spread across dozens of small costs: premium shipping charges, crew downtime, wasted material from over-purchasing, the occasional rework when the wrong spec showed up because someone ordered from memory instead of from a list.
What moving from notepads to a system actually looks like
The first thing we did was not build anything. We watched. We sat with the guy who ran the process and documented every step he took, every decision he made, every mental calculation he performed. Where does he check stock? How does he decide when to reorder? What triggers a new purchase? How does he know which vendor to call?
This discovery phase is where most of the value comes from. Not because the technology is hard to build (it's not, relatively speaking), but because you can't build the right thing if you don't understand the current thing. And the current thing is always more nuanced than anyone describes in a meeting.
What we found was a process with about thirty decision points, most of which this guy navigated on autopilot. He checked certain suppliers first because he'd learned over time which ones were reliable. He adjusted order quantities based on seasonal patterns he'd internalized. He knew which project managers ran tight on materials and which ones padded their estimates.
All of that knowledge had value. The goal wasn't to throw it away. The goal was to capture it in a form that the rest of the team could access and that the business could build on.
We built a database to hold the materials data: what's on hand, what's allocated to which project, what's been ordered, what the usage rate looks like. Then we built an input layer that the field team could actually use. Mobile-friendly, simple enough that someone on a job site could update stock counts in under a minute. No login screens with seventeen fields. No desktop-only interfaces that require a VPN.
The analysis came next. Once the data was in a structured format, we could run queries that were impossible before. Burn rate by material type. Projected reorder dates based on actual consumption, not gut feel. Spend by vendor over time. Which projects consistently used more material than estimated, and by how much.
The friction of change (and why it's worth it)
I won't pretend this was painless. Change is hard, and telling someone who's been running a process successfully for years that you're going to systematize their work requires some trust.
The guy who tracked inventory on notepads had a deep understanding of the supply chain for their projects. With the data entry taken off his plate, he could focus on vendor negotiations, strategic purchasing, and training the rest of the team. His expertise became more valuable, not less.
The second source of friction is the learning curve. Any new system requires people to change their habits. The field guys who used to just grab materials and move on now needed to log what they took. The project managers who used to call one guy for a stock check now needed to look it up themselves. These are small changes, but small changes multiplied across a team add up to a real adjustment period.
We handled this by keeping the new system simple at launch and adding complexity only after the basics were working. Week one was just: log what you use. That's it. No reports, no forecasting, no reorder automation. Just get the data flowing. Once the team was comfortable with that, we layered on the analysis and automation features. Each addition had clear value that the team could see, which made adoption easier.
What changes for the business
Once the data is structured and flowing, the business gets something it never had before: visibility. The owner can look at a dashboard and see materials status across every active project without calling anyone. The purchasing team can forecast needs based on actual data instead of estimates. When a project manager asks, "Do we have enough 3/4-inch copper for the Johnson job?" the answer is available in seconds, not after a phone call and a walk through the warehouse.
The less obvious benefit is that the business becomes less fragile. If the original notepad guy leaves, retires, or just has a bad week, the operation doesn't stumble. The process is in the system now. New people can be trained on it in days. The institutional knowledge that used to walk out the door every evening at 5pm is now captured and accessible.
That's the real value of business process improvement. Not the technology. Not the database or the mobile app or the analytics dashboard. Those are just tools. The value is that your best processes become repeatable, teachable, and visible to the people who need to make decisions.
And that starts with being honest about where your processes actually are today. If the answer to "how do we track materials?" is a person's name instead of a system, that's the place to begin.