My LinkedIn profile recites my current job title, also the title of this blog post. Unconventional? Consider that Microsoft positions include "Evangelist." A recently advertised Unilever position title was "Innovation Architect." JP Morgan advertised for a "Global Head of Problem Management." Knowledge Based Systems (KBS) are ubiquitous, but not widely recognized as such. In the global tug of war that is now underway to decide which countries will succeed in hosting jobs nearest to the top of the value chain, KBS are the battleground. While some enterprises in this post-recession era have restarted technology initiatives, there is reason to doubt whether the underlying analysis for these projects has been fully considered. The preponderance of "execution" (developer) vs. analytical hiring is just one measure of the problem.
To see if your organization has given adequate thought to its product or service knowledge infrastructure, consider these seven questions that could be posed by a KBS Strategy Advisor:
- Lopsided Expertise Investments Are you expertise-heavy in product development but undernourished in customer service, market intelligence and quality metrics? Does the team think abstractly and produce extensible, reusable models?
- JIT Learning Will you be able to deploy Just-In-Time eLearning concurrently with your product releases? Do your product architects assume a completely self-service universe? Is your organization's idea of elearning an FAQ produced by an inexperienced, junior associate?
- Measurement Do you have systems in place that gather and analyze critical usage information, before products are designed, during prototyping, and after release?
- Reuse and Longevity Are you building products or services with built-in obsolescence? Will your product's components be reconfigurable and reusable so that next generation can build upon the last? Has the design team stuck around long enough to experience products with any longevity, so as to be aware of pitfalls?
- Repository Development Do you know what knowledge is required to design, operate, test, deploy and train your products? Are you subject to catastrophic results should key holders of that expertise defect in this era of lightweight employer/employee commitments? Stated in software terms, can you separate your ontologies and rule systems from raw code? Do you have repositories and processes in place to keep them refreshed and fully integrated with your design and service operations?
- Incestuous Design Practices Many enterprises design products based on insider perceptions, concepts-of-the-hour, and incestuously vetted platforms and tools. Functions, market demand and product longevity are often not well tested against the relative objectivity of outsiders from other disciplines or realms of experience. What is being done to address the risk of excessive inward focus? Do you look outside before accepting "requirements?"
- Knowledge Velocity How long does it take your customer service operation to get detailed, correct, usable information about new products and services? How long before you decide it's time for a new version, new release, new patch, a separate workgroup to support a specialized service or revenue opportunity? Who's even assigned responsibility for monitoring such events in the organization?
Organizations who have a KBS strategy will have a better chance of survival in this fierce brain-vs-brain global environment. Most are busy building systems and products that will ultimately handicap them in today's milieu of short product life cycles, fickle customer allegiance, and coming IBM Watson-informed architectures.
◦




0 comments:
Post a Comment