System development: system testing and deployment (cond.)

User acceptance testing and evaluation criteria come first, but the real through-line is how a knowledge management system earns trust before it ever goes live—and how it stays useful after deployment. Testing is treated as a gatekeeping phase: the system must prove both that the knowledge content is valid (complete, correct, accurate, non-duplicative, not outdated) and that the system is functional for day-to-day work. That dual focus matters because a knowledge base can look complete on paper while still failing in practice if end users can’t retrieve it, understand it, or apply it effectively.

During the testing phase, teams must answer practical questions about what to evaluate and how. Evaluation can happen in the lab or in the field, and it must cover both knowledge content (completeness, correctness, accuracy, validity) and functionality (whether end users can find it useful). Stakeholders are not limited to end users: functional heads, suppliers and vendors, knowledge developers, and domain experts all play roles. Experts validate the codified form of tacit knowledge—checking whether what lives in people’s heads has been captured accurately in explicit form—while users confirm whether the knowledge matches what they actually need.

Testing also requires criteria set in advance and feedback captured in recorded form from multiple groups: knowledge developers, experts, end users, and system maintainers. Training and readiness are part of the evaluation too; the system’s value depends on whether people can use it correctly. To strengthen confidence, the process uses triangulation—bringing together experts, developers, and users to confirm that knowledge is both verified and operationally usable.

The transcript emphasizes error management using “type 1 and type 2 errors” logic: avoid accepting incorrect knowledge as valid (a false positive) and avoid rejecting knowledge that should have been included (a false negative). Minimizing both kinds of mistakes is framed as essential so the knowledge base supports inclusion/exclusion decisions that won’t later undermine quality.

After testing, deployment shifts to selecting the right knowledge-based problems—identifying who the users are, what problems the knowledge base will solve, and how the system’s repository, retrieval, and use will fit into real workflows. Ease of understanding, integration across information sources, and maintenance (security, privacy, uptime, and technical reliability) are treated as deployment prerequisites.

Organizational factors determine whether the system survives contact with employees. Leadership support is repeatedly highlighted, including dedicated roles such as a chief knowledge officer reporting to the CEO, plus funding, training quality, and ongoing upgrades. Resistance must be reduced through culture-building, “knowledge champions” who advocate and communicate benefits, and reward systems that encourage sharing rather than hoarding. The transcript also warns about political friction, union concerns, and behavioral blockers like knowledge hoarders and “troublemakers.”

Finally, post-implementation review closes the loop: teams assess whether people actually use the system, whether decision quality improves, whether costs of knowledge processing stay justified, and whether accuracy and timeliness remain strong. Internal and external factors—people, organizational climate, and technology infrastructure—are presented as the framework that shapes overall knowledge-based system quality. A concrete payoff example is given: Schlumberger reportedly saved up to $1 billion annually through knowledge management, underscoring the cost-benefit logic behind deployment decisions.