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.
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sat Feb 17, 2007 4:15 pm Post subject:
Hello Tralala,
I agree with your answer.
Unfortunately, too many people in IT will "claim" that they know how to scope their implementations to just build the basics for a CMDB. Most times, they don't even understand that all they're really building is an Asset Inventory/Register.
Also, if your enterprise is not in the business of building and selling CMDBs, why in god's name would you clutter and burden your enterprise with an undertaking that will only help to drown your IT staff.
Very simply, a good CMDB, done correctly will act as the hinge-pin to all of your other processes. However, to do it correctly is not a simple thing. We know, because we build a CMDB that is easy to use and we can say with experience that, while it is easy to use, it was not easy to design and implement. It took real experts with many years of very powerful domain experience to do so. Most enterprises don't have this and we find resources that have never undertaken such an endeavor trying to build a yellow brick road to Oz, one random brick at a time and having no clue where Oz is or what it should really look like.
Enough of me being on my soap box! Time to get down.
My best to you.
Frank _________________ [Edited by Admin to remove link]
Joined: Apr 17, 2007 Posts: 36 Location: Cape Town
Posted: Mon Apr 30, 2007 6:28 pm Post subject:
Code:
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.
Nnnnoooooooo, please don't do it please really really don't do it!!!!!
Seriously, if it is budget you're worried about use MySQL - it's free.
Excel is the wrong tool for hundreds of reasons: expensive, isolated data, no relationships, propriatory, difficult to automate etc. etc.
As you progress you will find yourself becoming more and more limited by Excel, and then you'll start doing lots of little Excel 'tricks' to extend functionality. Eventually you will start linking spreadsheets to try and create relationships, and then you are truely truely in the cacky.
Please, don't do it. Honest.
Quote:
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 !!!
Then learn SQL, it is easy and you will be so grateful you did. You have a great opportunity to start off on the right foot, you can use it like an Excel spreadsheet if you want, but it will be so much more flexible.
Please, don't use Excel for anything other than reporting, or maybe capturing data for import (only then if you cannot use a web-based solution).
All times are GMT + 10 Hours Goto page Previous1, 2
Page 2 of 2
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