Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Posted: Mon Oct 09, 2006 3:04 pm Post subject: CMDB in Excel
Hi Folks,
We are planning to kick-start the implementation of Change management. And for that the CMDB should be in place. But because of some budget constraints we are planning to go with Excel for the moment.
Since, I am not really fluent in using Excel, can someone please guide me as to what all things should be included and how. Or give me an alternate (Economic) solution maybe !!!
Cheers
Winz _________________ "Look at Frustration as a positive thing. It is the frustration that drives you to improve"
Can a service like maybe Messaging or WAN be considered as a CI for the CMDB ?
Also, what are the things that should be considred as a CI...
I have a thing here... If messaging is the Service and the Server names are the CI's.... The attributes to the CI will be the server name, IP address, etc...
And how do i link it to the other servcies like WAN ...
Am i going the right way ?
Awaiting your valuable inputs..
Thanx in advance..
Cheers
Winz _________________ "Look at Frustration as a positive thing. It is the frustration that drives you to improve"
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Mon Oct 09, 2006 5:37 pm Post subject:
Hi Winz,
Quote:
Can a service like maybe Messaging or WAN be considered as a CI for the CMDB ?
Also, what are the things that should be considred as a CI...
Determining scope and depth of a cmdb realy depends on the organisation it should serve. For organisations with heavy video/graphic usage such as a newspaper or a CAD/CAM dept, it might just be usefull to define internal video cards as separate CI's, whilst most organisations would find this very inefficient. Therefor it is almost impossible to answer your question, I'd rather advice you to adress this question within your organisation with all stakeholders involved (who pays for the maintenance of the cmdb? Who has the benefits?).
ITIL defines the infrastructure as software, hardware, documentation and service level agreements. Services as such are no part of it. It is smart however, to define you services in any table where you have the possibility to link them to CI's (most tools I know provide this). This will increase the value of your cmdb.
Regarding excel: yes of course it is possible to use this for starters. Realise however, that your possiblities will run out after a while, especially with documenting relations between CI's. However, it might be a good start, as your organisation still needs to decide on scope and depth of cmdb. If/when you have made up your mind, you will have a good baseline that you could import in most tools.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Tue Oct 10, 2006 4:49 am Post subject:
Hello Winz,
For clarification, I just wanted to bring up that using Excel spreadsheets for tracking this information is not really a CMDB so much as it is an Asset Register/Inventory. A real CMDB will maintain detailed dependency information such as relationship types and direction of relationships, audit histories, etc., which you will most likely not be managing in your Excel spreadsheets. It will also allow you to track far more than just your technical assets, as you would be able to track your vehicles, tables, chairs, offices, etc.
Also, from a generic standpoint, "anything" you want to track, which can have one or more dependencies to it and/or one or more dependencies from it, is a Configuration Item (CI). This includes anything at all that is important to the Configuration you are trying to manage. Examples include but are not limited to:
The list is endless. Fundamentally, if it is something that's important enough to track and has relationships to and from other things that are important to you, it's a CI worthy.
Please consider that ITIL leaves a lot of the above out and if you go by just ITIL you will have a very limited solution that won't grow with your enterprise.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
Joined: Sep 16, 2006 Posts: 3567 Location: London, UK
Posted: Tue Oct 10, 2006 7:37 am Post subject:
I happen to agree with Frank on this
Excel is appropriate for lists of items; ie Asset Register // Inventory list of devices.
You need some sort of database - whether you use mySQL, Oracle, Microsoft SQL or any other of the databases that are out there
To get the best benefit of a CMDB, you should invest time and money in a CMDB-able tool
Conversely, when I implemented// started Change Management in my organization; we did not have a CMDB or even an Asset Register
You can have a Change Management process which will work effectively w/o a CMDB but it will not be efficient and effective. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Look at the positive side of things.
Let’s be honest and accept "You have what you have".
Now it’s absolutely vital to plan how to get the organization buy in for a CMDB.
Make quick wins guys!
Start with Excel; always remember you will be having your set of problems while using an Excel. However, it is not a bad place to start with.
Once you achieve your preliminary objectives you can show to your management what you achieved and push for a full fledged tool by stating the pro's and con's of the current setup you have...
Starting with a simple asset list, although it will help your help desk and support staff a little bit, will be of little value and you may find it difficult to get buy-in for the next stage up.
I would have to recommend Access over Excel as this can provide information on the relationships between assets as well as their attributes. This will provide an immediate benefit when it comes to incident/problem/change management and makes your cmdb a little more extensible.
I would also recommend implementing from a top-down perspective, instead of trying to audit every single asset, whether it be important or not. Pick a few (2 or 3) key services provided by your system and populate the database with those. This is a quick way to prove the value of a cmdb and get buy-in from the upper echelons.
I must say: starting with Excel is puzzling me a little. For one, I think that the real value of the CMDB is in relationships and I don't see how Excel is going to help you do that effectively. BUT, starting the management of assets is a step forward and as long as you design your system in a way that you will be able to extract the information and place into another system later, then I would clearly start with what I have.
The problem is that you will have a hard time demonstrating value out of Configuration Management with such a system and I would therefore try to make sure you have a commitment from the organization to move to the next step before starting. The problem here is that you may find yourself with an outdated and unused Excel system and no willingness to go further otherwise. That is a waste of energy, money, and credibility.
While I generally agree with Michiel's reply, I must say that by any of my accounts, services are CIs in my book, for the simple reason that you will want to control changes you make to services, and the relationships you can build around services may be of enormous value. Example: I provide support services for Blackberry devices and I charge on a per call basis. If my service is in the CMDB, I will immediately know: (1) how many users I have for the service, (2) how many calls are related to the service, (3) How much to charge and to whom, (4) how many people do I need to train on the Service Desk, etc...
In another thread, we discussed incident classification and we highlighted what I consider a great category scheme using Service -> System -> Type. If you do this, you have matter-of-factly put your services in your CMDB. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Thu Oct 19, 2006 1:03 am Post subject:
Fabien wrote:
services are CIs in my book, for the simple reason that you will want to control changes you make to services, and the relationships you can build around services may be of enormous value.
Hi Fabien,
You are right. Having the services in any table where you can link them to CI's is vital to proper and usefull config. management. It makes services effectively part of your cmdb.
To be frank... I have put down the papers in my current firm and moving out for a better opportunity.. So I am done with the knowledge transfer...
Also, got a news that the firm is looking for some readymade tool which might help them with this...
Sorry... could not be of any help on this one..
Cheers
winz _________________ "Look at Frustration as a positive thing. It is the frustration that drives you to improve"
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Wed Nov 22, 2006 12:49 pm Post subject: Why build what you can buy?
Looking for a ready made tool is a smart move. We're finding more and more that enterprises are going down some ugly roads that they can't easily get out of, with their home grown tools.
Building simple tools is not simple! For some reason, people jump through hoops to prove that they should be building their own solutions, themselves. What's worse is they rarely bring their executives into the conversation and truly show these executives their the implementation costs, the year-over-year maintenance costs, the options and the impact of each option. We still can't figure out why this is. I wonder if it has to do with IT staff wanting desperately to build their own tools to keep themselves interested in their day jobs or believing they're up for such a challenge?
In the entire ITIL list of disciplines, a CMDB is one of the more costly and complicated systems to design, build, deploy and manage. It rates right up their with things like implementing true Financial Management, Application Management, and a worthwhile DSL. Yet, for some reason, people want to believe that they can implement their own. It's almost like they intentionally hide the requirements of a worthwhile system so that they can justify doing it themselves. I'm stumped on this one...
Regards, _________________ [Edited by Admin to remove link]
Posted: Fri Feb 09, 2007 8:25 am Post subject: completely off topic, sorry
Guerino1 (Senior Itiler),
I'll write some points from the System Administrators view.
There is a basic principle that rule every System Administrator - KISS
(Keep It Simple & Stupid).
I've been on such entry level ITIL course (green) - I liked it.
I've seen CA (implementation ~6months still not finished) - didn't like it.
The biggest problem is that most of the today systems are target to the managers (there are the money). Presentations are nice & promising, but the administrator has more work than before.
The most tragic of all is that mostly these products can do everything, but nothing really good out of the box.
As you said "What's worse is they rarely bring their executives into the conversation and truly show these executives their the implementation costs, the year-over-year maintenance costs, the options and the impact of each option."
ITIL is a reference, not an IKEA manual to build your bed.
Right tools for the right things is my answer to you!
Here I don't mean they should be self developed, open source or free, just the right ones.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
