11-21-2013 07:17 AM
There's not an OOB implementation for this. And while anything is possible, I'm curious as to how you'd see this working.
My question is, how do you determine 'automatic'? I assume the Change ticket has to have the details of the CI - the name of the CI, the type, whatever attributes are part of the CI, owner, assignment, etc. If the user has to fill in all those details as part of the Change ticket, why not just have the user create the CI as part of the Change process, or have part of the process be a member of the Config team or change team create the CI?
What I mean is, unless you are using some kind of discovery tool, any data about a CI has to be manually entered by someone, somewhere. If they have to enter it, why not enter it as part of the Change process itself? Where would the automated part occur? Where would the system get the data it needs to populate a CI?
11-21-2013 08:00 AM
Some of the CIs are not being discovered in our environment at the moment. So we need to intorduce a change process to enter those CIs in Service Manager.
Someone will request record ceation for those CI's. He should provide all the information as part of change request. If change is approved, CI record should be created in SM.
What do you suggest about implementing this?
11-21-2013 08:25 AM
Manually create the CI as part of a Change Phase, or create a Change Task that includes someone who has the rights to create a CI to create it.
The alternative is to create a bunch of new fields within the Change Management module so the user can enter details in those fields, and then populate a CI with that data. But why bother? Why not simply have a task for someone to manually enter the CI in the config module? Why create custom code for just that step? If the user has to manually enter the details, I think it makes more sense to manually enter them in the CI record itself.
11-21-2013 09:17 AM
Yeah user is providing all the details, however those details needs to be verified by the Config Team before CI is created. So Config Team is looking for way to avoid entering data manually after verification.
11-21-2013 09:21 AM
Yeah, that's why I would recommend using the Planned/On Order status (or creating a custom status) on the CI record that indicates it hasn't been validated. The config team can validate the data on the CI record itself and change the status to In use (or a custom status).
Alternatively, you could go the hard way around; create a new DBDict for these temporary devices that includes many of the same fields from the device dbdict. Create your Change Task to have the user populate that new record with all of the proposed CI data. Have a Change Task where your config team validates that data, and then, upon validation, call a process that copies data from your new table into the device table.
Seems like a long way around, but it's one way to do it.
11-21-2013 05:17 PM
You could define a special change task category for requesting new configuration items to be added that would automatically be assigned to the CMDB team. The change coordinator would open a task for each CI.
If you only required standard set of fields, you could use the same cateory/forms for all devices. BUT, if you need to capture different fields for different device types you could create a task category for each type.
If you want ot automate population of a lot of specific attributes, you could also initialize use array rather than dozens of new fields.
--On the form for each device type, just add the form objects and captions for the desired attributes, but use the array elements as the object inputs (e.g. store OS on attributeArray,1, store OS Version in attributeArray,2, etc.)
--Then, when you map out to create the CI, for each device type, you can build a map to move the array field vales into the correct attibutes in the joinfile for the selected device type.