Pau Lo
asked on
ITIL Status Tracking CMDB
i am pretty new to ITIL and COnfiguration Management, but am trying to learn the key concepts. I know with ITIL the 4th stage out of 5 relates to status tracking of CI's. I understand from asset management the general notion of the lifecycle of an asset. But I am struggling to see what issues / risks are caused if you dont have proper status tracking procedures in place for your CI's. what risks can you face with poor status tracking procedures of CI's? If any?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Also we may want to note in status tracking of CMDB, the key process is very much in Change management.
Question that the policy and system should address and emphasis on
a) A large organisation could have a hundred thousand objects in a CMDB, how will you populate the CMDB initially?
Most time, it will be auto-discovery however this can easily missed out disconnected devices, or financial information, or physical location. Check separately for UPS, PABX, factory machinery, or building security and etc.
b) How will you keep it current and accurate?
c) How will you know if an error is made or someone subverts the process?
Some manual report and review processes to pick up stuff the automated tools miss.
d) If one fails, what will be the impact on the SLAs?
e) How many can we take out for maintenance without degrading performance?
f) What are the permutations between half a dozen relationships, with embedded business rules, and thousands – or hundreds of thousands - of objects?
CMDBs will be a federation of multiple vendor repositories. Keep them to current and double any estimate for buffer.
Eventually a well recognised controlled CMDB via standard alignment helps to manage changes and provide governance via accurate reporting and adhere to the policy giving the direction to address the inventory tracking of all CIs accurately and consistently across the organisation. The creep is to avoid any Shadow IT that should be captured in CMDB but not. DevOps article give a sense of agility revolving ITIL and control process to be managed in the whole lifecycle.
http://www.ibm.com/developerworks/library/d-implement-itil-devops/
Question that the policy and system should address and emphasis on
a) A large organisation could have a hundred thousand objects in a CMDB, how will you populate the CMDB initially?
Most time, it will be auto-discovery however this can easily missed out disconnected devices, or financial information, or physical location. Check separately for UPS, PABX, factory machinery, or building security and etc.
b) How will you keep it current and accurate?
c) How will you know if an error is made or someone subverts the process?
Some manual report and review processes to pick up stuff the automated tools miss.
d) If one fails, what will be the impact on the SLAs?
e) How many can we take out for maintenance without degrading performance?
f) What are the permutations between half a dozen relationships, with embedded business rules, and thousands – or hundreds of thousands - of objects?
CMDBs will be a federation of multiple vendor repositories. Keep them to current and double any estimate for buffer.
Eventually a well recognised controlled CMDB via standard alignment helps to manage changes and provide governance via accurate reporting and adhere to the policy giving the direction to address the inventory tracking of all CIs accurately and consistently across the organisation. The creep is to avoid any Shadow IT that should be captured in CMDB but not. DevOps article give a sense of agility revolving ITIL and control process to be managed in the whole lifecycle.
http://www.ibm.com/developerworks/library/d-implement-itil-devops/
ASKER