Skip to main content

Posts

Showing posts from December, 2011

Knowledge Management - the "why"

When I teach, I like to talk about knowledge and wisdom and the value that they bring to the organizational table.   A lot of the time people give me a quizzical look, Knowledge? Wisdom?   Where is this conversation going?   I ask people how they capture the knowledge or do they even capture the knowledge that is gained when they develop a new service, application or when some new technology is introduced into their live environment. Although what we deliver can sometimes be intangible (availability, capacity, security) it is very complex and can take years to build up the know-how on how to deliver these elements and continually meet the changing needs of our customers.    However you need knowledge, born from experience, to solve problems, to always improve, to use your wisdom to answer the question of why should we make one choice over another? Like any other organization we must brand the product we deliver.   This brand will then garner a reputation; the reputation will be b

Knowledge Management - the "what"

George Santayana, the Spanish American philosopher, wrote the famous saying, “Those who cannot remember the past are condemned to repeat it.”   This really is the underlying basis for the process of knowledge management.   It plays a key role in CSI but data must be captured in each of the service lifecycle stages.   This D ata capture must then be processed into I nformation, synthesize the information into K nowledge and applied to the context of the environment we are supporting to create W isdom.   This is known as the Data-to-information-to-Knowledge-to-Wisdom structure. DIKW.   Wisdom (not repeating the past) will allow us to make more informed & better decisions around improvements in our processes, functions and services. The purpose of knowledge management process is to quantify all of this D-I-K-W and then to share perspectives, ideas, experiences and information at the right time in the right place with the right people to enable informed decisions efficiently by no

Should Service Requests be Included in First Call Resolution metrics?

I recently had a question regarding the inclusion of Service Requests into metrics for First Call Resolution. As always, the answer is “it depends”! ITIL now treats Service Requests and Incidents as two different processes – Service Request Fulfillment and Incident Management. Both are generally logged into the same tool and owned by the Service Desk. They are also measured by their own key performance indicators and metrics. ITIL does not consider first call resolution as a process metric - it is more of a service desk performance measurement. First call resolution historically helps measure the handling of incidents by the Service Desk. The definition of an incident is usually pretty clear. However, since the definition of a service request can vary greatly from organization to organization, the value of including requests in incident metrics may also vary. If your definition of a service request includes pre-authorization and funding, then the Service Desk’s ability t