Being a part of an IT team one would expect that we have a good grasp on
knowledge management. The trouble is that there needs to be method to the
madness for your knowledge. Considerations for how it is to be created, curated
and consumed should be taken into account.
I was reminded of this recently as I was speaking with a colleague who
was asking about an article I wrote entitled “WORN
– Write Once Read Never” they indicated that they own ability to capture
knowledge seemed a bit ad hoc at best.
I explained that while we are all capturing knowledge on some level or another
we may not be positioning ourselves to be able to put this to use in any way
which outlines a measurable amount of value.
Just
because you are not a knowledge manager doesn’t mean that you can’t help improve
the process.
Knowledge management can benefit all areas from a service delivery
perspective. The challenge is getting people to stop thinking about this as a “side
of the desk” activity. As I have said in many posts before, start small. Look
at what you do today and where you can inject a healthy dose of knowledge
management. In the beginning this might only apply to some core processes like
change or incident management, which is ok. Use the success you gain to
leverage some positive marketing for the process so that you can apply it to
other teams.
IT Operations or Application Managers
Imagine if your operations teams were able to look at documentation
which outlines the post incident reviews for the last 3 incident outages your
team was called out on for a particular component of infrastructure. Documenting
after these issues is important for continual service improvements. The challenge
is finding the balance for knowledge to keep it simple enough that you are in a
position to easily create, curate and consume the information. In my opinion
this is where most people outside service management teams start to lose some
level of traction. Using the example of a post incident review the ops and apps
folks might build out these elaborate processes which include an initial PIR
meeting which spawn multiple page documents with additional meetings to review
findings and so on. The trouble with this is that this might not be
re-producible, and in time these are simply not being done.
Having a simple template with a few key questions will allow you to
build on something. While your incident team may facilitate these reviews,
ultimately all of IT is accountable to providing service and has a vested
component in these reviews.
Start with a few key questions like:
-
What was the issue?
- Who was impacted and how?
- What was the resolution?
- What was learned?
- How could this be prevented in the future?
Everyone plays a part in knowledge management activities, whether the
process is formal or not. While many people might equate knowledge to the
service desk from a self-service perspective or even for problem management. There
are many other benefits that can be realized when we apply these principals to other
teams within IT and beyond.
Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn
Labels: ITIL, ITSM, Knowledge Management, Service Management
