(c) http://3.bp.blogspot.com/ |
The Factory Gates Open for Knowledge Engineering
A week before I was to ship out as a SharePoint business
ninja within IT, I hitched onto a passing knowledge raft. This water-logged
trial balloon was powered by the knowledge-seeking curiosities of the
engineering arm of Keen Core Technology – arms dealer to Hollywood, TV, and
recording industries, and now under siege by an unceasing array of disruptor insurgencies from all sides of the media production
spectrum.
While I had worked along-side IT and engineers with MBAs
(a.k.a. “management consultants”) I had never been subsumed into the belly of
the engine room: that is IT itself. I learned software-making as a repeatable
cycle in need of documentation as-in coding
the coders. I learned about daily stand-ups as the perfect antidote for
task-drenched programmers who would rather be writing code than getting sucked
into meetings.
My mission at Keen Core was to classify the wikis, channel
the documentation stream, and socialize the release cycle of the half-dozen or
so product development teams. Ultimately this meant distilling all these
outputs into a single automated helping of digestible knowledge called
“search.” The fact that there was no enterprise-wide answer to the perennial
how-do-we-know-what-we-know question meant two things to the engineering crew
of Keen Core:
- Conceptual – how do we boil this ocean of applications, file-shares, lapsed repositories, and group-based collaborations from Outlook to Google Docs?
- Practical – once boiled, how do we care and feed this resource so we can retreat to our safety zones in the comfort of knowing we can test our forward-leaning hunches against our collective history?
The Knowledge Safety Net
From a theoretical perspective the wish list that brought me
to Keen Core began and ended with the same staggering and sober realization: we
can scale the production of code but we don’t have a clue how to trap, catalog,
and ultimately leverage the by-products of that effort.
This overwhelming sense of an organization’s inability to
get out of its own way is not well-served by a top-down inventory of all assets
– whether they live in the U.S. Patent Office or under “the digital landfill”
as AIIM's John Mancini would say. Rather than
over-analyze the backlog of dumpster-grade documents, we looked to establish
the safety net – not the uber knowledge archive.
There was nothing random to this sampling. Domain experts
come out of the wood work – reluctantly sometimes because they’re often “heads
down” …
- On some failure-is-not-an-option mission, or
- Closing in on some new shortcut to faster, better, cheaper.
These are not the sycophants of social media in search of
the likability badging trophy.
These are the folks who build stuff. They might
not communicate effectively and their managerial skills lapsed long ago – if
they ever had them. They are socially speaking apolitical, meaning they are
drawn to fixing problems, not towards handling them. They are by-and-large
drawn from the ranks of engineering and they are my brilliant, argumentative,
recalcitrant, misunderstood people.
These are the ones who emerge when the call goes out for
who-knows-how-stuff-works. And like their own circles, the documentation they
travel in lands off the documentation radar. It lives on the outskirts of any
centralized repository that confers authority, explains connections, or unpacks
the experience that inspired it. In the case of the Keen Core safety net it was
little more than providing a link to an obscure server I might or might not find
password accessible. But after a series of non-threatening prods I had my
unofficial off-the-map collection of references that the engineering teams
swear by.
Not the sanitized intranet they were used to swearing at.
The Bake-off
The legendary chef Julia Child once said, “Always start out with a larger pot
than what you think you need.” She might as well have been describing the process for
picking an enterprise search engine. This proof-of-concept or PoC is your due
diligence for matching internal priorities and selection criteria to your
bake-off results. PoCs demand an improbable mix of reference able work product –
no matter where it comes from, the application particulars, or the sub par
referencing used to catalog the electronic version of what lives inside
organizational roles and responsibilities.
Once I had my vetted safety net, I was clear to map them to
the safe harbor of the search interface where memories get tested, experiments
are run, and explanations are concocted.
That mapping included a healthy respect for the mismatch between
Googling for cat videos that stick to our social billboards and researching a
backlog of databases that live behind a corporate firewall. A PoC was undertaken to reduce the vast, uncharted wilderness of Keen Core to
a single search box and a choice of search vendors – hence the “bake-off” that
played out against the following design choices:
#1 – Fact versus Conceptual Search: Most business problems are not
reducible to the distance of the closest pizzeria with the highest reputation
ranking. In other words the answer is neither immediate nor obvious. It’s not
persuasive on its own but needs the back-story to connect its relevance to the
problem at-hand. That connection can only be provided by the searcher – not the
search engine. The conceptual search idea was welcome by my colleagues as they
were well-acquainted with the status and responsibilities of domain-expert-as-content-curator.
#2 – Single Answers versus Iterative: Because of their
research-focused nature, most business or enterprise search problems are not
only conceptual but iterative. They are greatly influenced by changes in
time frame, authorship, formatting, narrative style, and context – the reason
the artifact exists in the first place. Enterprise search results defy
definitive or conclusive answers. They’re conversational – not just among peers
but with the search interface itself which guides the searcher with:
- Related events,
- People,
- Locations, and
- Organizations that suggest …
- Further probing,
- Competing explanations, or even …
- Complete redirections of our original assumptions.
This relatedness was realized in the proof of concept. Human-mediated tagging was neither doable nor desirable but the prospective search technologies proved up to the task for grouping these relations as search facets.
#3 – Search versus Source Dependent: The key to building our
knowledge safety net is not so much keyword searching as enterprise sourcing: The
ability not just to crawl volumes of pages, folders, and files but to evidence
why anyone bothered to do so. Search scoping is essential because it brings the
sense-making role of any single artifact apparent to colleagues with otherwise
no shared experience beyond a common holiday calendar and pay cycle. Sourcing
logic reinforces the cohesive logic of coordination across business lines and
supporting functions:
- Want to know what the customer sees before it’s out on your website? Search on marketing.
- Want to understand our products better? Search on training.
- Visual learner? Precede to training videos, etc.
- The more technical explanation? Go to the core requirements hammered out by account managers and the engineers who design to them.
Everyone at Keen Core understood the different lenses for sifting through the same content. The challenge was that only engineering had a seat at the bake-off table.
Enterprise Assets or Liabilities?
The good news is that each of these ingredients was factored
into an enterprise search proof of concept for the engineering crew at Keen
Core. The correct sources were indexed and configured to a search-driven
interface reflecting both the nature of the index and the information-seeking
goals of the searcher. Better still I got to run a true side-by-side comparison
between two enterprise search vendors (Coveo and Google). The thinking here: My
colleagues could base their tool of choice on their actual problem-solving.
The bad news is that Keen Core’s enterprise resembled a
potluck more than a catered sit-down. The number of place settings changed with
who wanted a seat at the table. The unsettled seating arrangements made it hard
to move forward without revisiting some tired assumptions like:
- The Google Slam Dunk: Hey, wipe that Google web smirk off your enterprise requirements for Google Search Appliance. We’re talking two different engines here!
- The How Big-is-Our-Data Routine? What
constitutes a fair test sample when a vendor solution crawls across diverse
operating systems, repositories, and legacy apps (with licenses no one bothered
to renew)?
- The How-Open-is-Open Question? What's bothering your colleagues about access to resources? What's the important stuff we can get access to if we need it? What are the content bottlenecks that hinder a silo-bound organization?
Conclusion: At
every milestone selecting the right vendor was resistant to simple
risk-to-benefit reductions. Multiple trade-offs were the norm. So were the dug-in heels of competing vendor camps. All of these larger lessons were lost to the conflicting agendas of poker-faced stakeholders – regardless of the actual bake-off winner.
Next week: The bake-off verdict is clouded by a crash diet
spending plan courtesy of a stock delisting and a CEO whose blunt leadership style
distances him from all non-depreciable costs -- including the company’s ingrained know-how on the building of its products.
***
The blog series KM in the Jerkplace is a work of fiction. Names, characters, businesses, places, events and incidents are either the products of the author’s imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.
No comments:
Post a Comment