“Search is broken” is almost never a search problem. It is an indexing problem that search is faithfully reporting. The crawl log — the record of what the indexer attempted to read, parse, and admit into the index — has an error column, and that column is the closest thing an enterprise knowledge system has to a truthful account of why users cannot find things. The error column is not a list of search bugs. It is a list of structural information failures that were present before anyone typed a query. This article is about reading that column diagnostically: what…

Most enterprise libraries do not fail because someone deleted the wrong field. They fail because nobody ever asked which fields were doing work. A SharePoint document library accumulates columns the way a shared drive accumulates folders: one request at a time, each reasonable in isolation, none reviewed as a set. Ten years later the form has sixty fields, the search index has forty of them, and the retention schedule references three. This is a diagnostic problem before it is a design problem. Before you remove a column, you need evidence about which columns are populated, which are queried, and which…

You know the document exists. You watched the program manager upload it in March. You type the project code into SharePoint search and get nothing — then browse to the library, scroll, and find it sitting there as Final_v3_PROJ-7720.docx. The search didn’t fail. The naming convention did, and it failed quietly, one file at a time, for three years. We call this condition governance-by-naming: the structural substitution of a filename convention for an actual metadata layer. It is one of the most common failure modes we see in enterprise and public-sector knowledge systems, and one of the least diagnosed, because…

An enterprise knowledge management system is any platform an organization uses to store, describe, and retrieve its working knowledge: SharePoint sites, Teams channels, OneDrive folders, Confluence spaces, OpenText repositories, an Elasticsearch or Solr index sitting in front of all of them, or a public-sector data portal built on CKAN or Socrata. Failure in these systems rarely looks like an outage. It looks like a person who knows a document exists, has every right to read it, and still cannot find it in the time they are willing to spend. I review these systems for a living, and I have stopped…

A knowledge manager at a legal services organization — I’ll call her Dana — pulled me into a consulting debrief in October with a screenshot she couldn’t explain. Her organization’s matter-type taxonomy, designed in 2021 with 40 carefully chosen terms aligned to their practice areas, now contained 1,703 terms. Nobody on her team had approved any of them. The SharePoint term store, configured to serve managed metadata columns across 14 document libraries and two matter intake forms, had been quietly accumulating entries for three years. Search relevance across their Elasticsearch index — which ingested SharePoint metadata via a Graph API…

… … …” } Where are literal escape sequences in the JSON string. I’ll write the whole html as one line with between block elements. One thing: should there be a newline after tags — yes, same separators. Also, JSON strings can’t contain raw newlines — I’ll make sure the html value is one continuous line in my output (the being two characters: backslash and n). Also check: any backslashes in content? No. Any double quotes? No — all attributes single-quoted, prose quotes are single quotes. Apostrophes fine. Em dashes (—) are fine as UTF-8. Let me also double check…

Enterprise knowledge management (KM) systems are supposed to make organizational knowledge findable, reusable, and governable. In practice, they often become expensive filing cabinets that nobody trusts. The failure pattern is not random. It repeats because organizations treat knowledge as a technology problem when it is actually a structural information problem. Taxonomy, metadata, findability, and governance are the load-bearing walls. When those are weak, the system collapses no matter how much is spent on the platform. This article is for the people who inherit a failed KM system or are asked to prevent the next one. It is written from the…

Enterprise knowledge management systems fail repeatedly for a structural reason: they are usually built as document repositories with a search box, not as governed information environments. The main entity here is the enterprise knowledge management system — the combination of content stores, metadata models, navigation structures, search configuration, and governance routines that an organization uses to make recorded knowledge findable and reusable. Adjacent concepts include taxonomy, metadata, findability, information architecture, content lifecycle, and knowledge governance. This matters to the iiminfo.org audience because most failed knowledge systems do not fail from bad software. They fail from unresolved structural decisions about how…

Enterprise knowledge management (KM) systems are the platforms, taxonomies, metadata schemas, and governance routines that organizations use to capture, organize, and retrieve institutional knowledge. They sit at the intersection of information architecture, records management, search engineering, and organizational behavior. When they fail, the cost is not just wasted software spend. It is the slow erosion of findability, the duplication of analytical work, and the quiet loss of institutional memory. This article examines the structural reasons these systems fail repeatedly, even when the technology is competent and the intent is sincere. The Failure Pattern Is Structural, Not Technological Most post-mortems of…

A senior infrastructure engineer retired from a mid-sized public utility. His replacement started the following Monday. Within two weeks, the new hire asked the question every new hire eventually asks: where are the design rationale documents for the SCADA migration project — the six years of trade-off analyses, vendor evaluation notes, and architectural decision records that should exist somewhere in the system? The documents did exist. All 247 of them. They were sitting in the document management system, exactly where the departing engineer had filed them: inside a folder structure gated by his role-group permissions. The replacement could not see…

Why Enterprise Knowledge Management Systems Fail Repeatedly By Rajiv Indrakanti Enterprise knowledge management systems fail when they treat knowledge as a container problem instead of a structure problem. The recurring pattern is not a lack of software features. It is a mismatch between how an organization names, classifies, and governs information and how people actually search for and use that information. In the language of this site, the failure is a structural information failure: taxonomies that do not reflect work, metadata that is incomplete or inconsistent, findability that depends on the searcher already knowing the answer, and governance that stops…

Enterprise knowledge management systems are the shared digital spaces where large organizations try to make internal information findable: intranets, document repositories, collaboration hubs, and search portals. They fail repeatedly because the underlying information architecture—taxonomy, metadata, and findability—gets treated as an afterthought rather than as the system’s operating logic. This article is for the people who inherit those failures: the records manager asked to fix a portal nobody uses, the IT director wondering why a second SharePoint migration produced the same complaints, and the information architect brought in after the third failed rollout. The pattern is familiar, but it is not…