Infrastructure for Expert Finder / People Search

Expert finder requires documented definitions of expertise domains — what topics, technologies, and industries the firm recognizes as expertise categories — and how expertise is evidenced (project work, certifications, authored documents, client feedback). These must be formally documented as the taxonomy that the AI uses to classify and score expertise. The ps-km baseline has methodology frameworks and knowledge sharing processes at L3, providing the vocabulary. Expertise domains must be explicitly listed and defined, not inferred from folder structures.

Expertise scoring requires systematic capture of expertise evidence: projects worked on (from PSA), documents authored and contributed to (from repositories), skills and certifications (from HR profiles), and engagement in specific topic areas (communication patterns, knowledge article contributions). Template-driven project staffing records and mandatory skills profile maintenance provide the structured evidence base. Without systematic capture across these sources, the expert finder has sparse, biased signals — it finds consultants who document frequently, not necessarily those with the deepest expertise.

Expert finder requires formal ontology mapping People to Projects to Topics to Expertise Levels, with relationship types (authored, contributed, delivered, certified in). Computing expertise confidence scores requires traversing this graph: Consultant A → worked on 8 digital transformation projects → authored 3 knowledge articles on change management → received 4.8/5 client feedback on digital engagements → expertise score: Digital Transformation = HIGH. Without formal entity-relationship mapping, the system can produce only keyword-based expert matching, not weighted multi-signal expertise scoring.

Expert finder must query multiple systems: PSA for project staffing history, knowledge repositories for document authorship and contributions, HR systems for certifications and skills profiles, and potentially CRM for client feedback scores. API access to most of these systems enables the expertise evidence aggregation. Modern PSA and HR platforms expose APIs sufficient for this. The gap is that communication pattern data (who discusses what in Slack or email) is not accessible, missing a valuable behavioral expertise signal.

Expertise profiles decay as consultants move between practices, develop new skills, and complete new projects. An expert finder that shows stale expertise — recommending a consultant for a data governance engagement based on a project completed 3 years ago, when they've since specialized in something else — wastes staffing decision time and may damage client delivery. Event-triggered updates (project completion triggers expertise signal recalculation, certification expiry triggers profile flag) keep the expert rankings current. This aligns with L3 event-triggered maintenance.

Expert finder must integrate PSA (project staffing history), HR systems (certifications, skills), knowledge repositories (document authorship), and ideally CRM (client feedback). API-based connections across these systems enable multi-signal expertise scoring. The baseline indicates knowledge repositories are standalone, but PSA-to-CRM integration exists, and HR systems typically expose APIs. Expert finder at this level requires more integration than other km capabilities because its evidence model spans both delivery and knowledge systems.