New CI's and Change Management

[Stig Brandt2]

Hi

Just been at a customer site, that are offering managed services to customer and they have the following requirements:

1) Custemer facing employee (CFE) are ordering new CI for the customer - the CI is either a business server or a server. Both CI's have around 20-30 attributes.
2) The CFE is working with pre-defined templates for the CI's
3) the CFE is staring working with the CI's as a draft and use an iterative process to make the CI's complete, spending days to complete the CI specification
4) Finally the CI is complete and submitted to the change manager who approves the CI configuration and approves the Change Tasks to be started.

I was first thinking of wizard funtionality as a userfriendly interface - not good with the draft and template requirement, and then I was thinking of the Service Request wizard interface - not good with draft and template requirement.

So I decided to recommend CFE using the CI Forms directly designing the forms with split views - give a usefriende tab interface, this also give my the advantage of having draft CI's, it also give me the template funtionality and when the CI is complete is automaticly creates a change request.

I was wondering if any of you have any pro/cons on my recommendation, before I implement the solution?

thanks in advance
Stig

[nikita_mironov · Accepted solution]

Formally when CI is started being drafted you are already in Change Management process so for reportiong purposes I think it still makes sense to raise a CHG in the beginning otherwise your customer may end up combiing reports on "draft" CIs and active change requests when their management asks them "How many Server Provision changes do you handle?".

I see it very similar to what you have - "Server Provision" Change Record Producer captures initial information for CI and creates CI in some status (lets say "Specification Preparation") linking it to a new change request being raised. Change workflow creates a task for CFE to complete CI specification. You define a branch in the workflow so it checks the CI status whenever that task is completed and rolls back to the same task if CI is not in desired status. You manage required (mandatory) fields on CI form using UI Policies (or business rules) ensuring that CI Status change triggers certain fields to become mandatory ( I do not recommend to use "views" - its a nightmare to switch between them).

So after Server Provision change is submitted we will have
a) Draft CI created in "Specification Preparation" status
b) Change raised and linked to that draft CI
c) Change task for CFE (or his group) to complete CI Specs.

Once CI is saved in desired status CFE completes his Change Task and workflow moves further checking if CI is in desired status (which ensures that all required fields are populated) and

d) triggers the approval from Change Manager.

Here we have another check. If approverd then we move further, if rejected then we set CI status back to "Specification Preparation" and roll back to first change task to populate CI and everything repeats from (c).

As a result - everything is tracked in CI & Change Tasks / Approvals. Change is raised at right moment eleminating the need to combine reports to management. Even more - Server Specification preparation activity (start, end date, duration, assignee, etc.) is tracked as separate change task which may also be good for management reporting.

[Stig Brandt2]

Hi Nikita

Very useful feedback regarding creating a change request when starting to create the CI, this also tracks the work effort for gathering all information for completing the CI.

thanks Stig