More Data Is Not the Same as a Better Answer | Observations from the Shop Floor
Michael Gardner, COO
For most of my career, we have been trying to give people better access to information.
When I started in this business, getting information was often the problem. Reports were printed, stacked on desks and passed between departments. Sometimes the information was outdated before the person who needed it ever saw it.
Over time, we got much better at that. Reports became available on demand, then became dashboards. Dashboards grew into analytics, alerts, drill-downs, spreadsheets and business intelligence tools. Today, AI gives us the ability to consume enormous amounts of information and potentially find relationships in it that a person could never reasonably find on their own.
That is remarkable progress, but I have started wondering whether somewhere along the way we began confusing having more information with having a better answer.
The questions being asked inside the business really haven’t changed very much. Is the material going to be here when we need it? Can I promise this order for Friday? Why did we make less money on this job than we expected? Do we really have five of those in inventory? What needs my attention today? Can I trust what the system is telling me?
Those aren’t really reporting questions. They are operational questions, and answering them usually requires more than retrieving a piece of data.
A Decision From a Long Time Ago
More than thirty years ago, I was part of a team at Goshen Sash & Door charged with helping choose a new business system.
At the time, I was the Sales Manager. Our team included people from customer service, estimating, purchasing, the plant and administration, along with our General Manager and President. Others throughout the company were also brought into demonstrations and discussions because they were the people who would eventually have to live with whatever we chose.
Looking back, I think the makeup of that group was important. We weren’t technology people evaluating technology. We were people who understood different parts of the business trying to determine whether a piece of technology understood enough about our business to help us run it.
Eventually, we chose WoodWare, and one of the biggest reasons — perhaps the biggest — was something called Var-I-Frame.
Anyone who has spent time around configurable millwork understands the problem it was addressing. The number of possible product combinations can become enormous. The conventional software answer at the time was to build and maintain the bills of material necessary to tell the system how all those products should be constructed.
WoodWare approached the problem differently.
It is also worth remembering just how different the technology was then. Much of the underlying information was stored in character- and position-based file structures. There weren’t relational database tables waiting to be queried, convenient imports and integrations, or any of the tools we now take for granted.
By today’s standards, the technology available to solve the problem was remarkably limited. Yet rather than requiring us to create and maintain a bill of material for every possible finished configuration, Var-I-Frame allowed a product to be configured from the rules and components that defined how we actually built it.
For years, I thought of that simply as one of the reasons we chose WoodWare. I look at it a little differently today.
What mattered wasn’t that someone had created a clever software feature – it was that someone had understood the operational problem.
Those of us sitting around the table knew what maintaining all those bills of material would mean. We understood the combinations, how products changed and how many exceptions existed. We also understood how quickly all that carefully maintained information could separate from what was actually happening on the shop floor.
The technology was certainly important, but understanding the business problem was what made the technology useful.
What Happened Along the Way
Eventually, I found myself on the other side of that relationship and became part of WoodWare. That gave me a perspective I couldn’t have had while sitting on the Goshen decision team.
WoodWare began in 1983, and over the years nearly everything about the technology underneath the software has changed. File structures evolved into databases. Networks and operating systems changed. Interfaces changed. Printed reports moved onto screens and then onto the web. The internet changed how companies and systems communicate, and now AI is beginning another significant change.
Through all of that, something else was happening that I think may be more important than any individual technology change. We kept learning from the companies using the software.
Purchasing people taught us why the date in the system wasn’t necessarily the date the material would arrive. Estimators taught us about products that didn’t fit neatly into predetermined structures. Plant managers showed us what actually happened after an order reached production. Customer service people showed us what they needed to know while a customer was waiting for an answer.
Salespeople taught us the difference between having inventory and being able to confidently promise it. Accountants showed us what happens when operational activity eventually has to become financial reality. Owners and managers reminded us repeatedly that, many times, what they really wanted wasn’t another report. They wanted an answer.
That learning didn’t flow in only one direction. Experience gained at one company influenced how we thought about a problem at another. An unusual exception encountered somewhere became useful knowledge when something similar appeared years later somewhere else.
Some of what was learned became software. Some became processes, reports and features. Some became implementation and support practices. A tremendous amount of it simply became experience inside people’s heads.
When I think about WoodWare’s history today, that may be more meaningful to me than the number of years itself. The most valuable thing accumulated since 1983 may not be forty-plus years of software. It may be forty-plus years of conversations between software and operational reality.
More Information Was Never the Whole Answer
Every successful company I have worked with seems to have people who know things the system doesn’t.
They know which vendor routinely promises Tuesday and really means Thursday. They can look at an inventory number and sense that something isn’t right before anyone has counted it. They remember why a particular customer receives special handling even when nobody can find where that rule was originally documented. Sometimes they can look at several pieces of information that appear unrelated and recognize a problem long before a report identifies it.
The system has the transactions. The experienced person has the context.
For decades, much of our response to that gap has been to give the experienced person more information. We built another report, another screen, another dashboard or another alert. Those things absolutely made businesses better and will continue to be important.
But there comes a point where providing more information doesn’t necessarily improve the answer. Someone still has to understand what matters, how the pieces relate to one another and what should happen next.
And Now Comes AI
That is what makes this particular moment in technology so interesting to me.
AI can potentially consume more information than any person ever could. Transactions, reports, documents, procedures, communications and years of history can all become part of what it considers. It can identify patterns and relationships across amounts of information that would be impossible for any of us to process manually.
That capability is extraordinary, but access to all of that information doesn’t automatically produce a useful answer.
We could give AI every report we have ever created and connect it to every transaction in an ERP system, but someone is still trying to answer an operational question.
The best operational people I have known rarely answer those questions from one piece of information. They combine what the system says with experience, context, exceptions, history and what they know about the people and processes involved. Then they turn all of that into an answer someone can act on.
I think that distinction will become increasingly important as businesses begin figuring out where AI belongs in their operations.
The opportunity may be much larger than simply allowing AI to consume more data. The more interesting question is whether we can combine what our systems know with the operational experience people have accumulated around them.
Final Observation
Looking back across more than forty years of changing technology, I am struck less by how much the systems have changed than by how little the questions have.
We have moved from character-based files and printed reports to databases, dashboards, analytics and now AI. Each generation has given us access to more information, faster and in ways that would have been difficult to imagine when I started. Yet the person running the business is still trying to determine whether the material will arrive, whether the order can be promised, whether the inventory is really there, whether the job made money and what needs attention today.
Maybe that is something we should keep in mind as we begin applying AI to our businesses.
The opportunity isn’t simply to give AI access to everything we know. We have spent decades getting better at collecting information, and more information by itself has never guaranteed a better decision. The real opportunity may be learning how to combine what our systems know with the experience, context and judgment that people have developed around them.
The technology will continue to change. The questions will continue to sound remarkably familiar.
Perhaps the measure of the next generation of technology won’t be how much information it can give us, but how much better it helps us answer the questions that mattered all along.