I need help with CMDB

[pathymo]

Hello all,

I need to do a Knowledge Base, I work in a project that has been in production for 2 years and we don’t have a proper knowledge base (CMDB) just emails that each individual person has, so every time we have an incident we run to each saved emails to see with we can find anything related to the specific incident.

We are support analysts of primary and second level, so for sure we waste a lot of time looking for answers or cases related. So I bought to myself the responsibility to organize that and make our support faster, with high quality and standardized.

But here is a problem, I am new with ITIL, I think is efficient and I am studying to be certificated. In other words I have no idea where to start, what tool I should use to organize that enormous quantity of information, I am quite lost.

I hope I made myself understood so you can help me somehow.
Thanks
Pathymo

[eisbergsk]

I Feel your Pain.
Our Knowledge Base is being converted again, but that's actually a good thing. We went from relying on the individual knowledge of whoever answered the phone, to a common repository, to an organized common repository with a standard look & feel owned by an outside vendor, back in-house to a home-grown web-based respository, and now onto a vendor's web-based repository. Only took about 10 years

There is some value in the steps we took, in that there were many more products, platforms, environments and support groups brought in at each phase, and willingness to change & acceptance of the new version grew at each step. But I don't think you want to spend 10 years at it....

You have to define a database structure, populate it, access it, and keep it up to date on an ongoing basis - not a minor task!

Perhaps a place to start is to find out what common tools your group has for a queried database. Something that everyone is already used to using is easier to implement.

The information itself should be query-able by the product, by the symptoms, and possibly by the resolution. You probably know what the rest of your criteria are.

Good luck!
/Sharon

[Guest]

Thanks Sharon.

10 years, are you kidding?
I hope i don't need to spend that much time on this.. gosh!
Anyway thanks for your message, I better start working..
Take care and good luck for me..
Tchau

[rjp]

Break it down - A Knowledge Base is not a CMDB and serves quite a different purpose.

Attempting to combine the two will lead to a major overload in the cost of the information. Information costs - creation, maintenances, storage, etc: And more critically the cost of inaccurate or outdated information can get very high, and these costs are almost never accounted for in a project plan.

The CMDB is a record of the state of the 'Configuration' - it isn't even an 'asset registry' as it should only contain CIs that are explicitly under Change Control, and the CIs should be defined by the function in the infrastructure not by their 'product code' or any other isolated attribute. Asset registries should be complete for assets above a certain value and are concerned with components as entities, not as production factors of a Service. A CMDB is intended to support other ITSM processes by implementing status controls and audits as control points on other processes - primarily Change and Release.

A Knolwedge Base is not actually in ITIL as such - neither the Known Errors and Workarounds Database or the CMDB is intended as a Knowledge Base. The KEDB is not a Knowledge Base because it's active records should be concerned only with actual CI's in a state of error at a given point of time.

Knowledge Bases are specialised repositories with very high maintenance overheads. They are however good value for ITSM and worth considering as an additional tool for Infrastructure Management, Incident Management, and Problem Management.

The Help Desk Association Of Australia (you can get the site via Google) had a very good white paper on Knowledge Management. Not sure it's available to the Public but you could contact them with a special request (they are a pretty friendly bunch). It is well worth a read before moving forward on a Knowledge Base.

[eisbergsk]

I hang my head in shame. rjp is exactly right. btw, my answer was based on the concept of Knowledge Base, not CMDB.
We have actually changed both this year. Our CMDB is now standardized corporately on HP Service Desk, and our Knowledge Base is now using Knova, formerly Kanisa

Yes, Change is Good.
/Sharon



[Edited to remove URL]

[jpomales]

Well, I agree with rj on the stand he takes on the CMDB. Knowledge recouped from Incidents and Problems should not be under Change control, and thus under the CMDB.

I suggest, depending on the email client making searches and exporting data. It'll be a time consuming job! But thankfully there are tools that can help!

For instance if the emails are in Windows based PC's, you could use Google Desktop or Copernic Desktop (which I use) to search for all of those emails. Then export as CSV's, TXT's and import into a simple Database.

Now the question remains: Do you really want to go THAT far back in knowledge? Do you still support Win9x clients for example?

Now, another question: Why specific knowledge records can't be under Change control?
_________________
audentes fortuna juvat

[rjp]

Reply to 'Why Knowledge Records can't be under change control'.

Can't is too strong a word. And it isn't clear that it shouldn't - it depends very much on how it is implemented.

If you put in a Knowledge Management system think of it as a tool primarily for the assitance of your Technical Support Groups (under Infrastructure Management) - not as a process management tool - which is what the CMDB is.

Another question might be - why doesn't Knowledge Management belong to the Service Desk / Incident Management Process? Well it can, but not in the way that incident management records (like the Known Errors and/or Workarounds database) do.

Knowledge Management articles are directed to the general, and Incident Management records and information is directed to the specific - the activities that are actually going on at the moment. Workarounds should go away when problems are resolved. There should not be 'known error' records for 'potential' errors - only for actual ones.

The point is there are data structures supporting your processes and then there is 'knowledge' - 'Knowledge' will improve the capability for staff to carry out the processes but will not help manage those processes. A good Knowledge Management system might 'mine' your process data, but will not be deployed in its place. Keep Knowledge Management separate to the operational data of your ITSM processes.

Finally if Knowledge Management is to be deployed in any significant way, then it will become another system in the infrastructure, and a lot will depend on that system being in good shape, and the articles being kept current and accurate - so you will need to bring it under change management - as you would any other technology.

[pathymo]

I just realized how much i need to learn and try.
You guys are great
Thanks

[Guerino1]

rjp,

May I please ask why you believe that a CMDB and a Knowledge Base are different?

As ITIL specifies that you should maintain not only your product configurations but also your Changes, Incidents, Problems, Artifacts, and so on within your CMDB, wouldn't that qualify it as a clear base for knowledge, especially if you can query it for past data/information in order to get your answers?

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

Well, of course, as I said above - any system implemented to provide knowledge management (and of course a knowledege base) to the IT organisation would be under change control, and it's constituent components and dependencies reqisterd in CI records.

Of course, you are correct in stating that many information artifacts are intended to be in the CMDB - RFCs, Incident Records, Problem Records, Known Errors, and etc.

A key point I was making is that none of these intended to be 'kowledge' - or if you like 'soluitions'. Why?...

Because all these things are process instance and control data - they are about specific events, items, states, etc in the IT infrastructure. And most of them only persist as an audit trail.

Knowledge records are generic (or if you like 'categorical') they are intended to apply (hopefully effectively) to a number of situations of a like kind.

The instance specific records make poor knowledge repositories: So poor in fact that there is a real danger in using them as such: There will be pressure to overload record structures with meta-data (weighing down the Service Management processes with extra housekeeping - driving up complexity and increasing cost) to suppoort Knowledge Management objectives.

The right way to do knowledge management is independently of process management: Process specific data is a source of knowledge, and should be mined with that end in view - but knowledge should be represented and made available as such.

Another way to think about it is the conflict between the audit trail and the knowledge repository. Process instance records will have mistakes and inconsistencies. Effective knowledge management will require these to be discovered and removed - but that destroys your audit trail.

So how will one techie - looking at an activity log for an incident that occurred say six months ago, be sure that the resolution method is correct. Did the configuration change in the interim? Has an even better response been found by someone else - now lying unidentified in another record somewhere? Whose to say - but there is an awful lot of cross referencing required to use instance data and validate it at the same time: Which is a very poor way to utilise knowledge.

Once 'mined' from the operational records, information should be 'composed' specifically with it's utilisation as knowledge in a future situation in mind. It should also be under managed quality control, and be monitored for relevancy and reduncancy.

Remember and inacurate process record, may cost nothing - but an inaccurate Knowledge Base article could cost you a fortune

And generally - knowledge management is acknowledged to be outside the scope of ITIL - certainly the authors did not have knowledge management and data mining is mind. The Help Desk Institute (pretty easy to find and chapters in most countries) has done some good work on Knowledge Management - badging it as the 'Missing Chapter' in ITIL - without OGC blessing I would guess In the US they have been developing training courses in Knowledge Management, and recently the HDAA has brought this to Australia. Still in it's infancy (compared to ITIL), but there is no doubt in my mind that Service Management and Knowledge Management, while quite complimentary are nonetheless very different - different ontologies, different methods and processes, and different objectives.

[Guerino1]

You have an interesting perspective on the topic. I don't know that I agree with you, though. Please don't take it personally, as it's not meant to be so. If anything, please be patient with me as I try to understand your points of view.

Based on the requirements I get from customers and partners, it appears that there view of a CMDB is also a KB. Their view is that you should be able to do things like:

- Define a trackable entity (RFC, Configuration, Problem, etc.)
- Define relevant attributes for any trackable entity (Problem->Description)
- Track relationships between trackable entities (Problem Drives RFC)
- Track changes to entities' attribute values and relationships
- Query on any data in the system that is relevant to you, based on any point in time.
- Ability to data mine.

These are only high level requirements and are not intended to be a detailed view of a CMDB.

As an FYI, the concepts of a CMDB, a Knowledge Management System or Base (KMS/KB), an Organizational Memory & Information System (OMIS), etc. have been around for decades, long before ITIL. In theory, they all appear to be exactly the same. There are lots of great articles/white papers on these topics in the CiteSeer repository, citeseer.ist.psu.edu.

BTW, I ran this by a number of colleagues, as well, to get their opinions. They seem to agree that they're all one in the same, which led me to respond, otherwise I would have left it alone.

Thoughts/Opinions?

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

Frank,

no I don't take it personally. Yours was an excellent and intelligent response to the topic.

I don't actaully think we are disagreeing that much anyway.

Yes the CMDB is, in the sense you described it, a knowledge base. But it is a very sepcific knowledge base in that it encapsulates knowledge about the 'configuaration'. And in ITIL what this means is that way each CI participates in the provision of Services as a production factor of those Services. (Not as an asset or technical 'object' per se - but that's a whole nother discussion).

The point (perhaps) on which we dissagree is the use of any process control records stored in it. I would not call their presence in the CMDB the instatiation of Knowledge (as such) - but rather a raw material from which knowledge can be derrived and represented. To my mind a Knowledge Base is a system that does some of the work of rendering data into useable knowledge and to get there from, say, incident resolution records, requires specific managed processes.

The confusion between process control information and 'knowledge' is quite real and can adversly affect any process implementation for the reasons I have outlined in this discussion.

Perhaps it is a matter of both degree and utility. I agree with the list of functional outcomes you described - but to my mind a knowledge base is what you have after you mine the data in this way, rather than the data itself.

[Guerino1]

Hello RJP,

I do agree with you about the CIs being raw data and not, by themselves, knowledge. If you'll notice, ITIL has clear statements about everything being in the CMDB, not just CIs. Once you start putting CIs, with Assets, and Incidents, Problems, Documents, etc. as well as start to maintain the relationships between all of them, many would consider that the line has been crossed into Knowledge Management. Since the data is all in one place, you can start to "derive" other information through higher order analysis. Without the data being in one place, you cannot "easily" perform such analysis.

My design team has spent years putting such a solution together. We're just going to market with it. Believe me, it wasn't easy. But now, because we have a way of putting all of our customers' data all in one place, we can offer them solutions that they couldn't dream of, otherwise. The consensus from our prospects is that they're getting a real knowledge management system, since they can cleanly and very simply query and run higher order analytical reports across all data in all operational domains.

Regards,
_________________
[Edited by Admin to remove link]

[rjp]

That's actually very interesting.

From your description I would certainly say you have lifted the bar - certainly past the simpel DB level. In other contexts I frequently claimed that a CMDB as envisaged in the framework has a lot in common with data warehousing / data mining than basic database deployment.

I'd love to have a chance to look at your product - but not as a prospect - and see for myself.

It isn't 'technically' knowledge-management for me unless is has a final representation of the mining process as reuseable solutions. But to be fair I don't think that can be automated in software and is the end-point business process - which it sounds like your product is quite well suited to support.

In industry-speak the product of knowledge management is the KB as a repository of 'articles' (KBAs). Bear in mind that most of the comments I made are addressing the requirements for KBAs to be managed over time - and that this is a distinct process requirement to managing the operational data of other ITSM processes.

So while I think we have a different view of where the end point of knowledge production lies - I ceratinly do think a well structured and highly function CDMB is an absoultely critical production factor in knowledge management in the ITSM context.

But moving away from our 'debate' abount KM for a second, I would be interested to see how your product addresses some of the other challenges of a CMDB - particularly:

1) The need to cope with the varying levels of 'abstraction' that configuration information requires in ITSM production - so that 'things' can be easily represented simultaneously as components under control, interdependent parts of complex (and frequently arbitrary) systems, as well as production factors in delivered services.

2) The practical need to be able to effectively scale the implementation of Configuration Management.

3) The requirement for unifying bottom up technology based 'asset' discovery and CMDB maintenance automation, with top down service definition and modelling.

4) Being able to produce a service to production factor model in the CMDB that suppports full and flexible service cost modeling and reporting.

If you have cracked those particular 'nuts' you are going to have a very successful product lifecycle.

I read a whitepaper recently (and I won't name it because I wasn't able to find out whether it was independent or vendor sponsored) that claimed fully 1/3 of all whole-of-infrastructure CMDB implementations have the plugged pulled in the first six months because of cost blowouts and scope creep.

Personally I think you are entering a competitive but nonetheless very 'hungry' market - good luck.

[Guerino1]

RJP,

My team and I would be honored to have you take a look at our product, especially since your experience will allow for very valuable feedback. We are in the process of building our external demo site. Once it is complete, I will notify you and we can connect so that I can provide you with a temporary account. I would expect a two to three week timeframe for us to be ready.

As for your reponse, I was hoping you could please provide some examples for each of the four items you discussed. I have my own ideas about what you're saying but I'd rather not assume I can read your mind.

I agree that the market is both competetive and hungry. We're betting on the hunger. We have some new ways of doing things that we believe will break traditional ways of dealing managing your operational data/information. Our intent is to convince people and companies to stop trying to build their own custom solutions for capturing and managing ITIL related information and have them go back to focusing on their core businesses. After all, someone that focuses on building widgets shouldn't be focused on solving for ITIL. It's a distraction from their revenue streams.

FYI, if you're interested, feel free to contact me, directly off the board, I will gladly discuss much of the above with you, in detail. I think we may be starting to bore others! ; )

Regards,
_________________
[Edited by Admin to remove link]