Gathering requirements

[sand01]

Hello,

I have been recently hired as a configuration manager. It is my first project on CMDB.

What I can tell you so far, is that CMDB will cover in the beginning about 15'000 servers/Applications and will need to be a federated CMDB in order to consolidate the data from numerous sources.

It was decided that the first step would be to gather the needs and requirements that our multiple operationnal teams are having. Would you have any advise in what are the good questions to ask them ? Because if I don't come out with specific questions, they wont be able to answer or they will ask to much.

For your information our environment consists mainly in supporting added value services to customers, such as messaging services, security (FW, proxy, etc..), and hosting facilities for customer servers/equipments

Thanks to help me in this.

Best Regards.

[UKVIKING]

What is the reason for having a CMDB ?

Are you tracking Assets, CIs, Services etc

Are putting in the rest of ITIL Service Support

Merely putting in a CMDB is not configuration management. You need to manage the assets by tracking the CIs life cycle from order/purchase to disposal

You need to find out what information is needed to accomplish your value added service to your customer base ?

Do you have an ticket system used for tracking incidents and service calls.

A Service Catelogue would extract data from the CMDB. DO you already have one ? IF so, the data in there would have to be in the CMDB

As you stated, you manage/provide Value Added Service for Messaging etc.

Does it matter to your customers if you use MS Exchange, Lotus Notes etc
Does it matter to your staff providing support to your customers what the O/S or hardware the Applications are sitting on.

If the answer is yes, then you have some requirements already.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Cotswolddave]

Hi Sand01

My experience of doing this for my day job - developing, implementing, capturing data etc. is that you will not get a list of requirements to work to.
Sounds a bit harsh but it is founded on many years of experience. Let me explain.

First, many do not know what config mgmt is, or what a CMDB is or looks like and why you want one. So you have spend time and effort on educating about integrated processes and a supporting database. To engineers you have to tailor the message around their job roles, to managers you have to go into controls, strategic needs etc.

If you don't then you get some input on data needs and some on process needs. My advice is to get people from different teams into workshops so they hear other people needs and work practices.

Second, you need to show them how the CMDB will be used with some of their own data/terms so they comprehend that what you giving them is the potential to work differently, not the same way. We use the concept of a prototype or demonstrator to enable people to "see" how it would deliver better impact analysis to improve incident control. But if you get the demonstrator wrong, you have something for everyone to pick holes in - not enough detail, too much detail, too difficult etc.

If you don't then you run the risk of people distancing themselves from their original needs saying they didn't understand what you meant.

Third, of the demonstrator is ok and it helps refine requirements, gets feedback on priorities, issues etc. you have the basis of a project with goals, risks, short term deliverables etc. You then only have to justify the data capture exercise and process development to keep the data up to date.

Hope this is of some help, requirements capture can be difficult because it crosses team boundaries and will affect their working practices. The best way to work is to set your clear milestones - say 6- 10 weeks and keep to it.

Dave

[Guerino1]

Hello Sand01,

I will have to say that I agree with Dave. You will most likely not get the requirements you need by speaking to other people, especially since most other people you speak to will not understand what a CMDB is.

A CMDB will, if done properly, yield two very simple results:

1) Centralize all definitive inventories (Inventories of Assets, Inventories of People, Inventories of Incidents, etc.)
2) It will allow for the creation and maintenance of relationships between all records of all entity types (Assets, People, etc.), in such a way as to help understand the relationship and the purpose of the relationships.

The value that an enterprise gets from these two results revolves around the savings in time, money, and energy and can be summarized as follows:

1) Quick access to definitive inventories: (e.g. I need a definitive list of servers to feed into my monitoring solutions or I need a definitive list of all Windows Servers with OS XYZ:Patch ABC so that we can quickly install a security patch).
2) Quicker access to impact data: (e.g. modify an Asset and see everything it's tied to 1 Degreee of Separation or "DOS" away, 2 DOS away, 3 DOS away, etc.)
3) The ability to create Key Performance Indicators and/or Metrics (KPIs/KPMs) based on looking across operational domains: (e.g. How many key business units are suffering from discruptive Incidents that pertain to these 500 specific assets that are associated with these 10 specific Products?)
4) Knowledge Management: How do I look for something I need and find it in a split second (or a few seconds) across many different operational domains? (e.g. 1: Someone calls the help desk and says "I'm seeing Error 526 on my screen... How do I find every Incident, Problem, Requirement, Project, Product, Release, Change, etc. that has that error string in it so that I can see who has already experienced it, what work has already been done, what workarounds already exist, etc. e.g. 2: An employee leaves the company. How do I quickly find everything that that employee is working on or has worked on and quickly reassign that information to someone else, so that all of that knowledge and work doesn't walk out the door with that employee?)

I certainly hope you're not going down the road of trying to build your own CMDB. If so, please understand that you are trying to implement something that already exists out there and you are undertaking a very long, lonely, complicated, and expensive path that will yield very little useful results. If you're not already doing it, I highly recommend you take a look at some commercial platforms to help get you up and running quickly and not waste your enterprise's time, money, and energy.

Anyhow, I hope this helps.

My Best,

Frank
_________________
[Edited by Admin to remove link]