I’m reading a fantastic book about Organizational Knowledge. Before I publish my book review I wanted to tell you a story that had a great impact on how I look at knowledge in the workplace. This took place more than 20 years ago.
I graduated from CWRU with a degree in Artificial Intelligence (a scholar’s degree actually, a shade fancier than a regular BS degree). My first corporate job was at the AI-think-tank at Xerox. No, not Xerox PARC, but a lesser-known group called the KBSCC which I think was created in response to PARC — it was supposed to create cutting-edge technology that we would use, and not give away to nice little startups (like Apple, Microsoft, etc.). In typical think-tank manner, there were plenty of interesting, smart, arrogant people who thought they had solutions to the most impossible problems. And I was lucky enough to work on problems that I thought were interesting despite being a very dry area of the business — logistics and inventory management.
One of Xerox’s businesses is selling huge machines that takes weeks to manufacture and ship. Components for these are trucked in from Canada; others shipped from Brazil and elsewhere. The final product is assembled in upstate NY, then shipped to inventory locations around the world. The challenge: how to plan the production run — meaning when and how many machines to make?
You’d think production planners take marketing forecasts and built to plan. Marketing predicted when, where, and how many they would sell. They made it clear to manufacturing to have product available to be sold on time. Customers don’t want to wait. The problem: marketing forecasts are not accurate predictors of sales reality. But marketing owned the forecast. Manufacturing didn’t know what customers buy. The field was not talking to anyone — they were trying to sell what marketing promised the executives they would. So everyone operated with the risk that they’d be blamed for any deviation from the forecast. It was safer to follow the plan and blame marketing, than to work together an negotiate a more flexible process. As a result, when the forecast was off, costs would shoot up. It takes time to collect parts (with occasional holdups at borders) and configure the manufacturing line for the production run. It takes time to build and ship product. No one want to hold extra inventory, no one want to be caught short and lose sales. One option: hire clairvoyant planners. The other: build a smart AI program. It was the late 80′s and technology was our darling — I guess we all watched too many movies about the future.
The business noticed that some production planners consistently make better decisions than others. So we planned to interview the most successful production planners and then “program” their heuristics into a knowledge based system that would calculate the optimal production runs. Our path was paved with good intentions, and we set off to build the solution.
Sure, we discovered that some planners did not want to share their processes for (warranted) fear of being replaced by a computer. Other planners were very forthcoming and told us that they used actual sales data to plan their runs, or they would track the field inventory levels. We discovered that many planners distrusted marketing data and operated by gut feel (so they expressed). Eventually we learned some of the secrets and realized that the most senior planners had a system of getting information from their buddies in the field. They’d use their “social network” to get more accurate numbers of what was going on in the field, and adjusted their plans accordingly. The new planners only had the marketing forecasts to work with. They did not have buddies in the field, and they did not have the process knowledge to get the information they needed.
It took time and many face-to-face conversations to surface the real process from the experts. We then scrapped the “intelligent” program idea and created a system that (cleaned up and) took the data feeds (the forecast, the actual sales, current inventory levels, etc.) and presented a simple spreadsheet putting it all together — with predictions, what-ifs, and time bands. The result: We gave all the planners the clean data they needed to make better decisions.
Later that year I learned that market forecasts were way off on two product lines, one was over, the other under forecast. Seemed that our customers wanted the smaller products, even though the larger ones had more features. Thanks to our spreadsheet program, the manufacturing planners were able to reschedule parts shipments and keep inventory at the right levels. The accountants ran the numbers and said that we saved over $650M that year by having the right information at the right time. I got to share in the glory with the team — I received a very nice award and a paid weekend vacation to a resort for my contributions to this project.
This event made a big impact on how I viewed technology and organization knowledge. We came into the project ready to build a technology solution. But the business just needed good data. The planners just needed to share their process ideas with each other. Technology played a big role in getting the right data (and making sure it was accurate). But the solution was not “build an application” — it was “work with the people who know, and help them express what they know – then build the application that helps them.”
This event has always been in the back of my mind when looking at organizational knowledge initiatives, at KM, and Enterprise 2.0 collaboration. While I was reading my book, I thought how clever the author was at understanding this too. Knowledge is incredibly important to an organization, so much so that crafting the right technology to support it takes more than just installing software, it takes careful understanding of what the stakeholders need.