Two observations…
- Most discussions about KM (knowledge management) seem to occur in a vacuum; devoid of any attachment (or direct relationship) to roles in the organization.
- Given a specific tool (such as blogs), we typically try to apply it to the core objective of a given role in the organization (i.e., blogs used for outward message-casting).
What if we looked at the role of PR in relation to KM? Do we fully understand the iceberg of knowledge management and how it intersects with PR?
Here are a few more observations - none of which are intended to make conclusions, and most of which raise more questions.
- PR is about “knowledge work” but there are few means of measuring or helping PR people become more productive.
- PR (in a functional sense) is about the elegant assembly of words, but I suspect it has dimensions that are far more complex.
- Does anyone ever ask - “how can we increase the PR team’s capacity to act more wisely?”. I get the sense that this is not a typical focus in organizations - correct me if I’m wrong.
- Blogs are great for enhancing and managing an outbound message. But are we missing the greatest opportunity to enhance the PR process - internal (secure) uses of blog technology?
- Are PR professionals comfortable with their productivity and knowledge management tools?
- Does BI (business intelligence), and CI (competitive intelligence) play a key role in the PR process as it relates to productivity and role performance?
- Email is a universal tool employed by PR professionals worldwide (perhaps more than Microsoft Word), but if email is where knowledge goes to die, why does the PR community use it so much for internal knowledge-work?
In the quest for creating better PR, do PR and marketing teams skip over some obvious IT-related housekeeping requirements that will transform them into a “PR machine” of extrordinary capabilities?
6 comments
4/14/2005 at 1:21 pm
PR Machine
I like your comment “In the quest for creating better PR, do PR and marketing teams skip over some obvious IT-related housekeeping requirements that will transform them into a “PR machineâ€? of extrordinary capabilities? Because, the answer is yes. With blogs, PR has such an opportunity in front of it to work with other company divisions (IT and marketing) to grow and deliver more services that truly affect the bottom line (interacting with customers via blogs).
4/14/2005 at 8:32 pm
Robert
Love this, Bill.
So much to think about. I’ll try this one first.
- Email is a universal tool employed by PR professionals worldwide (perhaps more than Microsoft Word), but if email is where knowledge goes to die, why does the PR community use it so much for internal knowledge-work?
That is the best rationale for moving group thought sharing to something like a wiki, blog or other CMS platform. Internally, these can store the knowledge - make it searchable/shared and of value down the road. The loss of all those internal ideas is sad and, I believe, a waste of company money, time and valuable employee contributions.
Lilia Efimova’s case study is interesting. Not wanting to be too picky about what form of CMS is best for what, I do think it needs to be addressed, too. For me, the wiki is best suited for knowledge aggregation, so to speak. Blogs are best suited for the ongoing exploration of new ideas.
Ketchum has used their MyKGN CMS to involve clients in the process, too. MyKGN seems to have blog, forum and wiki-like attributes. Ketchum built in rewards for employees that contributed to the aggregation of knowledge built up over time in campaigns/projects.
They, too, have taken baby steps and it has turned into a revenue leader, as well.
There are good examples of this type of KM taking place. Yet, as a whole, PR practitioners seem to still be in the early stages of exploring, let alone adopting, CMS for these purposes. Large firms seem to outpace the smaller - as would be expected.
Robb (PR Machine), good to see you dropping by, too. Thanks for visiting MarcomBlog.
4/15/2005 at 7:26 am
BillFrench
Blogs are best suited for the ongoing exploration of new ideas.
Um, I would rephrase this and drop the word “best”. Blogs are certainly suited for the exploration of new ideas. But they are also excellent for…
Status reports
Personal journals
Tracking development tasks
Sharing early documention content
Managing link lists
Guiding a sales team
Educating a team
Establishing a philosophical direction
Planning projects
Tracking competitors
Gathering competitive intelligence
Learning experiences
Documenting mistakes
Editorial management
Travel logs
Security advisories
Support communications
Many more…
For me, the wiki is best suited for knowledge aggregation, so to speak.
This is one that I can’t really agree with. Perhaps I have a bias against wiki’s, but it is for good reason. Wiki’s are designed to be very open in terms of a security and permissions model. The reality of enterprise IT is that security is very important. Wiki’s are typically an all-or-nothing proposition with regards to the permissions to see and edit information. I say “typically” but I have yet to see a wiki that supports granular permissions of information at the same object level that an author may participate.
For example - I can add a paragraph to a wiki page, but can the wiki display a page that either includes (or excludes) my contribution based on a) my permissions, or b) the permissions of other credentialed users? The answer is “no” in both cases (of course) because wiki’s are not intended to work that way.
Another example - I want to search a Wiki for “manufacturing layoff”. Given my permissions, I should be able to see (or not see) the instances where this text appears. This sort of requirement has many gotcha’s - the search system must embrace the security context of each user. The crawler (search indexing system) must also factor in each user’s permissions. Wiki’s can’t meet this requirement because they don’t support the architecture necessary to do this. For that matter, most blog products don’t either.
Unfortunately, knowledge aggregation systems *must* work in these ways.
I digress - wiki’s are excellent tools for many objectives and they should be considered for KM purposes, but not the roll-up (or aggregation) of knowledge.
Corporate KM aggregation systems have requirements that neither blog products nor wikis can address. In addition to the granular security and permissions issues, consider the integration issues…
- Character encoding across disparate blog, wiki, and CMS’s is a huge problem. You must have an aggregation machine that scrubs the rough encoding edges depending on how different vendors deal with (or ignore) this delicate issue. Couple this issue with a global organization that has multiple spoken language requirements, and you have a significant challenge.
- Aggregation environments must produce new data sets that are virtual; the assimilation of discrete information objects from many silos of information into a unified information model. Why? Because the CEO might like to subscribe to one feed that contains any mention of the SEC, regardless of what blog, wiki, or other system it may have been captured into. Virtual data sets require advanced predicate search and filter patterns, neither of which blogs and wikis provide
- Aggregation machinery must be able to collect data from blogs, wiki’s, CMS’s, and other content sources not originally intended to play a role in the KM process. Imagine collecting information from a lagacy database that doesn’t have an API. Or an old CMS that outputs only bad HTML (with no API).
- KM aggregation solutions must be able to leverage the new semantic Web. Imagine a requirement to aggregate the most recent (and top ranking) 3 articles about Sarbanes-Oxley from Reuters, AP, and Financial Times. This requires a business process where wiki’s and blogs would have a tough time addressing.
Sorry for the rant…
4/15/2005 at 9:31 am
Robert
Sorry for the rant… LOL … no problem. I enjoyed it.
and 
First, I should probably always point out that my experience is almost solely in the available opensource options and, therefore, very narrow. Also, I’m very narrow by thinking mostly of PR small group work and journalists collaborating on stories - not remembering the larger picture for the whole organization.
That’s essentially what you were questioning in your post.
Yep, I should have given specifics for wiki usage because they are limited (as are most of the opensource CMS options I’ve encountered). They seem to all need tweaking and plugins/add-ons.
I find myself always thinking of the few examples I’ve been exposed to - like newspapers using them in a secure extranet and only used by small numbers of people. So, yes - they are not KM for the whole organization unless you make all databases linked and searchable, etc… (all the things you mentioned above).
Permissions for varying levels/groups (to some degree) can be assigned in some of the opensource wiki platforms (PmWiki and MediaWiki, but limited). I’ve also seen it possible in some opensource portals (e107, for instance). Still, those are limited, too.
Are you familiar with CivicSpace? It is still young, but seems to be moving toward a an attempt at KM for a large grassroots organization. The platform comes with blog/wiki/forum-like variations. It worked for DeanSpace, but still had limitations.
Blogs are ‘well’ suited… how’s that?
As for “Character encoding” … well, I’ve already encountered that problem in some of the things we’ve attempted and it is a bear. A topic like physics, with all the equations becomes a problem, too. Yes, I’ve actually tried to get a physics collaborative project up … still searching on that one.
What we probably need to start addressing in these classes of ours are opportunities to explore installations of the various options you, Dee, Tara and perhaps David, offer. And, we should be exposing the students to Vocus and - well, et.al. offerings that they may encounter after graduation.
And, no - I’m not trying to hit you all up for free offerings (yet).
They need to start seeing what KM is in the corporate world and how they will be asked to use it.
4/15/2005 at 11:33 am
BillFrench
Permissions for varying levels/groups (to some degree) can be assigned in some of the opensource wiki platforms (PmWiki and MediaWiki, but limited). I’ve also seen it possible in some opensource portals (e107, for instance). Still, those are limited, too.
Yes, I’m experienced with all of these tools and the biggest [security] problem still remains - someone (other than the author) can delete (or alter) that author’s contribution. This is a big problem in certain use cases where wiki’s satisfy (even exceed) all other requirements.
Redux on my bias against Wiki’s - LA Times Wikitorials Taken Down.
4/21/2005 at 8:51 am
ElizabethWood Rodgers
I think these tips/questions are important ones to remember. Thanks so much for your input!