Business Intelligence Needs the Stories Behind the Data
Decisions improve when structured business data is connected to the documents, conversations, and experience that explain what the numbers mean.
Business intelligence often begins with the part of an organization that fits into tables. Revenue, sales, costs, projects, vendors, and client records can be collected, organized, validated, analyzed, and presented for decision-making. Data warehousing gives that work a durable home. Online analytical processing, or OLAP, lets people examine the stored data through different dimensions and summaries.
All of that is useful, but it is not enough when the decision also depends on what people said, observed, complained about, or learned while doing the work—which, inconveniently for a tidy data model, it often does.
Knowledge management meets business intelligence at that boundary by combining content management and the web with improved search and text-mining capabilities. Text mining means analyzing unstructured text for patterns, whether the text comes from audio and video transcripts of design meetings, learning spaces, oral histories, electronic interoffice communication, repository documents, or search queries. The important condition is that a human remains on the other end to identify and judge the pattern—something humans are still better at than SkyNet, at least as I write this. A machine can retrieve, group, and surface material; it cannot settle the meaning by itself.
The distinction between structured and unstructured information is not a hierarchy. Structured data is designed for consistent fields: a customer name, product name, invoice amount, project code, or date. Unstructured information arrives in sentences, narratives, descriptions, and conversations. It is less uniform, but it often contains the reasons, exceptions, and conditions that a table cannot carry.
Consider support and warranty analysis. A data set may show the number of calls associated with a customer or product. That information can identify a pattern worth inspecting. The short text descriptions attached to complaints may explain whether the calls concern installation, a recurring defect, confusion about use, or a cost that the standard revenue view does not include. A customer-revenue cube can show which products sell successfully over the phone. It may omit the time spent resolving problems, handling complaints, or providing the hand-holding that changes the actual profitability of that relationship.
Integration turns those separate records into a stronger question: what does the data show, and what do the associated stories say about why it is happening? Stories are another valid currency in knowledge management, an idea I keep returning to, but they need provenance, context, and a link to the record they concern. A story becomes operationally valuable when it can be connected to a client, project, product, or process without pretending that one vivid anecdote represents the whole population.
The technical work may require a data-mapping transformation. A text system can have metadata that logically corresponds to a business-data field, such as customer or product name, while using a different form for the same value. The mapping establishes the correct association. A weak match can attach a complaint to the wrong customer or scatter one client’s history across several labels, producing a confident report based on broken relations. The cleanup governs the evidence.
Once the association is sound, extraction, integration, analysis, and presentation each change. Extraction is no longer limited to numeric fields; it can surface relevant language from notes and transcripts. Integration creates routes between that language and the business records. Analysis compares recurring terms, descriptions, or situations with quantitative patterns. Presentation can show both the measure and the supporting context, allowing a decision-maker to inspect rather than merely admire a chart.
The integration does not erase the difference between evidence types. A dashboard may show the scale of a pattern while a selection of associated stories explains mechanisms, exceptions, or questions for follow-up; the story should not be forced into a numeric conclusion it cannot support, and the number should not be asked to provide an explanation whose context was never collected.
The useful result is a business-intelligence practice that can ask more complete questions: not only which customers are profitable, but which costs and experiences sit behind the figure; not only which product produces support calls, but what people say when the call begins. The data supplies the shape and the stories complicate it, sometimes enough to change the decision—which is the reason to join these records in the first place.
