How to Put the Knowledge Management Into IT Service Management
•
2 j'aime•574 vues
How to Put the KM Into ITSM was first given to the NSW branch of itSMF Australia for their Q1 seminar on 15/3/2012. During this talk, I cover how to plan, write for and maintain your knowledge base. I also discuss why we need to share knowledge and I share my thoughts on managing some of the cultural issues that get in the way of knowledge flow in IT departments. These slides are visual and some are intentionally blank. When I get around to providing a voice cast (and some properly formatted notes), or even a recording of coming presentations, I will let you know. Follow on twitter @aprillallen or subscribe to the blog (http://eepurl.com/d12h1) to be informed. ** Jokes and anecdotes not included. These are only available in person. ;)
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
How to Put the Knowledge Management Into IT Service Management
- 1. How to Put the KM Into ITSM Aprill Allen Twitter: @aprillallen aprill@knowledgebird.com Knowledgebird.com
- 2. http://www.itsmf-whitepapers.org/ Available for free to itSMF members. Knowledgebird.com
- 4. What is knowledgemanagement? Documenting the stuff we do and the stuff that happens, so we know what to do next time. Knowledgebird.com
- 6. By Ecoagriculture Partners on Flickr
- 7. Why? Because any funny story you have from your IT career could have been resolved by an adequate knowledge base. Knowledgebird.com
- 8. Knowledge Management & ITIL Knowledgebird.com
- 11. Fundamental processes and company information. Commonly occurring issues/processes. FAQs. Other processes. Trivial-but-useful. Knowledgebird.com
- 12. Writing for your knowledge base Knowledgebird.com
- 13. Golden Rules 1. Be clear & concise 2. Beware the curse of knowledge. Knowledgebird.com
- 14. Follow up Tailor your language Knowledgebird.com
- 15. Categories and tags Knowledgebird.com
- 16. Formatting Stick to one style of font, in black and opt for one other colourto highlight important points. Blockquote a command list to set it apart from informational text. Don’t just cut and paste haphazardly. Invest the time to reformat it. Knowledgebird.com
- 18. Article Lifecycle From the KCS Practices Guide, Consortium for Service Innovation www.serviceinnovation.org Knowledgebird.com
- 20. Knowledge management = empowerment Knowledgebird.com
- 22. Stem cells from http://www.topnews.in
- 24. Small steps Simple language Bribery Knowledgebird.com
Notes de l'éditeur
- Today, I’ll be covering how to plan, write for and maintain your knowledge base. I'll also be talking about why we need to share knowledge and sharing my thoughts on managing some of the cultural issues that get in the way of knowledge flow in IT departments. Before I get started, I’ll give you a rundown of my background.I started in technical support for home, dialup internet users about 15 years ago. Windows3.1 was on the way out, Windows95 on the way in, and Macs were a rare and complicated support exercise. The internet was mailed out to people on CDRs.About 6 months into that job, in 1998, 5 or 6 of us were recruited to staff a new Network Operations Centre. We were fresh out of tech support for home users and into the NOC, supporting the entire network, servers, and corporate clients. Our tools were WhatsUp Gold, a terminal window on our desktop, and a shared pager and mobile phone. All up, I’ve had around 13 years of experience in tier 1, tier 2, and tier 2.5 roles. I’m a lapsed CCNA and at the end of last year I picked up the ITILv3 Foundation.
- When I wrote this guide I hadn’t heard much about ITIL at all, or even that ITSM was a thing. In fact, I’d left my IT job earlier that year and had taken up freelance writing. But knowledge management was still something that I could see everyone was challenged by. And it would get more challenging with the popularisation of social media and online collaboration.So I set about writing this guide for anyone, IT or not, who was struggling to make a start with internal documentation.
- We’re living the Information Age. Knowledge used to pass verbally through storytelling, but our generations have developed all these new ways of creating it and new ways of capturing it. But we still haven’t mastered how to manage it effectively.There’s so much information out there, being produced by you for your business, your users and community are talking about your business. Everyone is a publisher these days. Managing the intellectual property inside the business and the collaborative knowledge that is outside, but about, the business is going to be everybody’s challenge, even if they don’t know it yet. I want to make the lives of your operations staff easier. It’s a high stress, high-churn, shiftworking job often involving critical decisions being made under pressure and without enough information. And yet, paradoxically, your NOC is the gateway of a ridiculous amount of information.To me, better service and happy customers are the byproducts of a fully-functioning, efficient, sharing and caring IT department.
- I think we all know what a knowledge base is. So, I’m going to go a bit broader instead and ask what is knowledge management.I’ve heard it said, that a lack of well-recognised and accepted definitions for something is an indication of immaturity. Knowledge management suffers from that problem, so I’m just going to give you my definition.In a more elegant form, it’s our processes, our insights, and our experiences.
- When I think about the ways knowledge has been managed in different organisations throughout my career, the feeling of disorganisation is universal.As an example, one place I used to work kept all procedures and common troubleshooting advice was kept in a single word document with version control. The thing was huge. But everyone still had their own scratched out notes in a notepad file on their own computers. And the enormous word doc had duplicate stuff, outdated stuff. Names and numbers that were no longer on the scene. You get the idea.Also, it’s not uncommon for developers and infrastructure teams to keep text files buried in the file structure that rarely see the light of day. But this general sense of disorganisation isn’t the only reason a knowledge base is a good idea.
- We need to worry about this guy as well. Not just because he’s out on the lawn with shirt off, chewing on grass.There’s something like 50% of executives who are at retirement age RIGHT NOW. In just 10 more years, there’ll be more people leaving the workforce than entering it. The knowledge capital in your business could be about to walk out the door. Apart from this impending DOOM, what are the other practical reasons for building a good knowledge base?
- Less time required for training so your new staff will feel more confident, more quicklyIt provides opportunity for innovation and improvement, especially if you’re monitoring patterns of usage and customer feedback. It’s empowering – more on that later.Resolution times are quicker.Your staff is less stressed, leading to lower burn-out rates.Mobile and remote workforces.. Having a centralised knowledge source makes it easier to keep remote workers informed…though, scaling that for larger companies with distributed international workforces can be a challenge.Knowledge shared is time and effort saved. And time is money.
- KM gets a look-in in every ITIL book. Service Strategy explains what knowledge assets are, and that the tacit knowledge – the stuff in our heads and the actions we do every day that aren’t documented — are hard for our competitors to get their hands on but easy for us to lose when people move on.Service Design talks about how tacit knowledge can cause misunderstandings with requirements for new services.Service Operation explains the Service Knowledge Management System.It gets a tiny mention in the CSI book, which baffles me, but I’ll come back to that. The Transition book gives knowledge mgt the greatest attn. You simply can’t expect to adequately support a new service without supplying any documentation. And yet, people still do that.So, when I talk with you about HOW to write your knowledge base, you can apply those same tips to incident reports, problem report, known-error dbs, change control DBs.
- Building a knowledge base, like any project, requires some planning.Get clear on who your audience is: Self-help for users, service desk and operations teams, other internal departments in the business, your own team.Scope out your existing tools and consider the features you’ll be wanting to use – screenshots or other attachments, keyword fields or tags.Adding to and maintaining a knowledge base is everybody’s responsibility but having a role within each team to oversee it is helpful. It’s good for quality control, avoids duplication.Decide on category labels. The built-in knowledge bases within the service desk tools that I’ve seen give you a way to assign categories to your knowledge base articles. Don’t go nuts. Too many choices becomes confusing and people will start to play pin the tail on the donkey with it. Don’t provide a general or misc category because everything will end up in there. Make sure your category names are easily understood and accepted by everyone. A former colleague of mine says that’s still an enduring problem of theirs — KB articles that are filed under something that makes sense to one person and not the other.
- Lots of people put off starting a structured knowledge base because it can feel so overwhelming. So, we eat the elephant one bite at a time, right?First things first, create a glossary of commonly used terms and acronyms. It might seem basic and commonsense but think of the new team members.Corral the legacy documentation from the various locations, break it into smaller chunks and audit as you go—work out whether it’s obsolete or incorrect before you add it in to the knowledge base.Consider the tacit knowledge, the procedures that take place all the time but aren’t documented and start documenting them one at a time, one service at a time.
- Once you’ve broken up your mass of information into more workable chunks, work through them in order of importance. Most people would probably start with green, but with my operational experience, red=critical so they go first. This is the order I would do them in. You could take a different approach. The important thing is to develop a way of working through it all for the small victories along the way.
- A lot of the time, when your operators or service desk staff are accessing the KB, it’s while they’re under pressure looking for an answer. Your language needs to be clear and the text has to be easy on the eyes. It’s not coz they have trouble understanding, it’s because they’ve got to be able to find and work through the information quickly.
- When I first did this slide I had half a dozen or so rules up here but the rest all derive from these two. And these are the two that I really want you to remember.Be clear & concise.Don’t use a long word when a short one will do, don’t use 2 words where 1 will do. We all get trapped with that sometimes, especially in IT and management. Being concise isn’t about dumbing down, when your readers are under pressure they just don’t have time to read and re-read. The curse of knowledge is when we take the stuff we know for granted. We forget that others don’t know. Don’t assume knowledge. Place yourself in the role of the reader who knows little about the service or system—avoid jargon and don’t leave out details that seem obvious to you. Describe the issue in the words the customer would use as well as what the problem description is, according to IT.The other things to keep in mind are these:Don’t do in-jokes. In some situations your knowledge management could be audited by a third party and the whole organisation comes off looking unprofessional. Stick to the procedures and the facts.Link to other supporting info like maps, schematics, network diagrams, rack layouts, previous similar cases, asset details, vendor info etc etc
- KB articles are often instructional so keep to present tense in those cases and you need to be clear on the steps.If you’re not clear, go back to the source, or someone else who knows, and follow up. Ask questions and don’t be shy.Tailor your message. Focus on who your audience is. Is it for your team or the people you support? Are you going to be publishing this article to a customer portal? The language you use will be different depending on your target reader. If you ARE writing for end-users (within the business), go spend some time with them. Ask them how they do things, what they could do more effectively, and what they don’t know how to do. Interview them, observe them and don’t take negative feedback personally.
- You might have the most well-written knowledge base material in history but it’s no good if it can’t be found quickly. You have to consider how searchable it is, by navigating through the structure or by searching on keywords.Think about categories and tags like the chapters and index items inside a book.Categories are like chapters and the tags/keywords are index items. When you write your article file it in the category that makes sense. If you’re unsure, get a consensus from your team members. You also need to tag it with any keywords that people might be searching on. If the system is known by other names, include all of them, acronyms, full names, you could tag it by service name as well as device name.So, if I’d produced an incident record.. Outlook is frozen. That’s how it would be put to me by the customer. I’d file it in EMAIL and might tag it with outlook, the server name- email01 (let’s be creative), exchange. That’s probably it.
- KB material doesn’t need to be pretty, but it does need to be streamlined and easy to read.
- Once you’ve created your knowledge base: you’ve laboured long and hard and birthed this beautiful repository of knowledge. But it doesn’t finish there. You have to nurture it so it can live long, and the business can prosper from the investment of building it. Keep adding to it and maintaining it.
- To explain maintenance, I’ve copied the diagram from the Knowledge Centred Support guide. Theirs is better than the one I have in my white paper. This one is also more complete, because it includes the rework and tech review paths. Anyway, when we have an article in progress it starts off in draft. Then we can fact-check with other sources and revise, if needed, before approving and publishing. Once the article is live, it should be regularly reviewed, updated where required, or made obsolete and archived.This KCS methodology really complements ITILs Continual Service Improvement guidance nicely. Maybe one day the govt office will acknowledge that.
- Feedback is a critical part of keeping your knowledge base rolling along. When you post a status update on Facebook and someone clicks LIKE or leaves a comment — that’s feedback. When you tweet something and someone replies or retweets it—that’s feedback. It’s their endorsement that what you’ve said has been useful to them.KB feedback works in the same way. And I’m including peer reviewing of articles in that. Most knowledge base tools these days have some way of flagging items, rating items, and capturing remarks on the quality of the article.Pick a day, once a week, or a block of time per day… to regularly go through and check feedback and update with new info. Fix wrong details in your live articles as you see them. If you notice any incorrect info in an article while you’re busy with an incident, flag it or make a note of it to come back to.If you’re managing people, build it in to analysts’ KPIs to review and write a certain number of articles each week, beyond what’s generated from incident reports.And, if your software solution doesn’t have a feedback mechanism, invite your readers to contact you with feedback, or actually ask them on a regular basis. Check in with them to make sure what you’re providing them with is still relevant.
- Knowledge is power, and Knowledge Management is empowerment. I’ve talked about the practical benefits—the time and cost benefits—but I also wanted to talk about the fluffy side.When your customers are empowered to resolve their own issues or assist with diagnosis, with online self-help, they feel good.When your service desk and operations staff are empowered to perform routine fixes and maintenance, they feel good. They learn new things, it makes work more interesting and challenging.When your engineers can confidently hand off what they consider to be ‘trivial’ or ‘low value’ tasks, they have time to innovate—find better ways to do things, find time to work on new projects in the service pipeline. Don’t let people get bogged down in the busy-work of knowledge base management. Keep them aware of the bigger picture. The benefits of knowledge management are most obvious at the ground level, so be sure to pass the sense of empowerment up the chain to keep other teams involved.Now look, I know I’ve made that all sound pretty simple. And it would be if it weren’t for our egos and other barriers.
- Throughout my career in IT departments, I’ve consistently seen the same kinds of behaviour. So I have some observations I wanted to share with you and some suggestions on how to deal with the people side of IT and knowledge management.Socially, IT get along quite well with each other. We all like the IT crowd, we can all find out our IP address If we had to. We clump together at functions because it’s us against the rest. We like to go the pub while HR and marketing like the jazz club. We have a bit of social glue.But when we’re at work doing our jobs, something happens. IT is kind of unique as a functional group inside a business. The HR teams have their own policies and culture, call centres have their own policies and culture, sales and marketing do what they do, but when we get to IT, there’s a bunch of sub-groups, each with their own ways of doing things. Infrastructure and engineering, applications, DBAs, IT support and service desk. Sometimes it’s like the Tower of Babel in there and we don’t always understand each other. There are mismatched expectations, mismatched intentions and we just don’t get the knowledge flow within IT that we need to operate most effectively.There’s communication breakdown WITHIN IT that other groups don’t seem to suffer nearly as much.And there’s also this obstacle: engineers like to be heroes. Don’t get me wrong; some of my best friends are engineers. But some will routinely hoard knowledge to ensure it. But what I don’t get is this: if engineers really like putting out fires, aren’t they working in the wrong part of iT?Engineers by definition, should be building, improving, innovating. It’s the analysts who are taking the 000 calls, good knowledge management helps them put the fire out as well.Ongoing knowledge mgt requires a change in our hero worshipping culture. Put the onus on the hero to document their resolution, so we can all learn from it and avoid the blown SLA next time around. Encourage a shift in attitude that the tier 3 groups should be building and innovating, while empowering the NOC staff and service desk with the knowledge to solve more issues and perform uncomplicated preventative maintenance.So let’s go back to the first obstacle. How do we work with the reality of IT having these sub-groups? Sub-cultures, even, if you like.
- Having an organic KM strategy, where the creating, updating and rewarding goes on at the grass roots, within each IT sub-culture, is more likely to stick, than having directives sent from the top. It’s not siloing, because it’s the same searchable KB that each other team is using, but it’s working on a cycle that suits each individual team.Find a knowledge champion in each IT sub-group, acknowledge their leading by example, empower them with the right to improve on their own team’s strategy and to share those perceived low-value tasks and low- risk tasks that other operational teams can handle. Gamification can also help—acknowledging the desired behaviours and rewarding the exceptionally good ones. Essentially, it’s bribery. We’re a competitive species and most people do respond to it.So having your Executive on board with sponsoring rewards is really helpful. Small rewards like a gift card or a free lunch is often all it takes to motivate.
- If you’re struggling to get people on board with KM, here’s an experiment.Have each person in your team choose a routine procedure that they hate doing but it’s part of their daily work and have them document it step-by-step. Then, mix things up and have everyone do someone else’s procedure.That will do two things. It’s quality control of the documentation but it also illustrates how much better it is when we can share the burden of the knowledge that’s in our head. It’s an immediate positive pay-off.
- So Knowledge management in three easy steps ;)Take small steps and celebrate the small victories along the way, use simple language so everyone can understand it, and spread the love of knowledge through empowerment and bribery—whether that’s through gamification or milestones and rewards.