Skip to main content

Service through Knowledge Management



I believe that a service provider can improve by choosing to follow best practices from ITIL, Lean, Agile and more.  That said I also believe that Knowledge Management will be the glue that ties in all together. Knowledge is required to deliver maximum results.  Knowledge Management ensures the right knowledge to the right people at the right time.  Think about yours or your customers service provisioning model.  How much time, money and resources is spent because of the lack of knowledge at the right time?  How frequently do we need information or access to the information and it is NOT available?  Not only is information not available when we need it, but sometimes it is replicated in many ways in many different places so that there is no real way to determine the definitive source.  It is difficult to get management control over the outcomes of an organization when the knowledge is out of control.  Knowledge Management is required throughout the Service Lifecycle.  A few examples include:

Service Strategy:  Current and historical information regarding major change proposals, business cases, high level service models, Demand management information such as current and projected patterns of business activity, meeting minutes and information from business cases for analyzing and approving strategic changes, Business Relationship Management information and more. 

Service Design:  Details of the full designed solution for a new or changed service.  Details of the service model mapping service assets to business and customer outcomes.   Service Catalog information including business views and detailed technical views for the service provider.   Let’s not forget the metrics, and processes in Service Design and all the knowledge and information that make them work.

Service Transition:   Knowledge and information will be key as both inputs and outputs from planning, building, testing and deploying a service.  Change models, data structures and policies for Service Asset and Configuration Management, the definition design and details for Configuration ITEMS and most important the relationships of this data and information to determine the impact to business outcomes.

Service Operation:   Here we need to manage Incidents, problems, requests and to get a grip on the management and control of events, auto actions and results of automation.   Reports for daily weekly monthly, statistics and information will be a big part of Knowledge Management.  Using knowledge to break down silos and improve communication between all stakeholders in the value stream could be the differentiator that thrusts your organization above all others. 

Continual Service Improvement:   This is by far the most important area for Knowledge Management.  Whatever you are doing today, can be done better.  Agreed?  We can always improve upon where we are now with any service or process and the same is true with Knowledge Management. We can all look to where we know we have siloed discrete facts or data and then correlate that data together for a common purpose to create information.  Once we give this data some context the next step is to look for ways to optimize.  Knowledge will require experience too.   From this correlated information and experience we can glean wisdom to make wise business decisions. 

These are just a few ideas off the top of my head.   What would you add?  What data, information and knowledge is key for your organization? Knowledge Management is POWERFUL! 

For ITIL education and certification or for more information regarding the Service Lifecycles visit http://www.itsmacademy.com/itil



Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…