Incident->Problem->Defect->Release->Change Process?

[jamesmcwhinney]

Im curious to know how others are using the agile and/or release module to track their ServiceNow defects in ServiceNow from cradle to grave.

For example, if an end user logs an incident for an ESS site defect and it is found to be resolved in a future SN release, what does this process look like in ServiceNow?

Here is my understanding so far:

1. End user logs incident about the corporate ESS site.   Content is disappearing from a list collector inexplicably.

2. Service Desk checks for known errors in the problem table, doesn't find any, so escalates to the development team.

3. Development team is able to reproduce and finds a workaround.

- Dev team advises the end user of the workaround, asks if they would like to receive updates on a long term fix, then closes out the incident.

- Dev team creates a problem record of type "known error" describing the workaround for future use by the service desk and adds the end user to the watch list if they confirmed they would like to receive updates.

4. Dev team is assigned to the problem and performs RCA.   RCA suggests the issue lies with the platform so dev team logs a SN HI incident and notes it in the problem work notes.

5. SN HI confirms the problem and advises that it is fixed in a future release (Jakarta).

- Dev team creates a Feature Record called "ServiceNow Jakarta Patch".

- Dev team creates a Defect Record describing the defect, then sets its "parent feature" as the "ServiceNow Jakarta Patch".

6. It is decided to plan an April release for the roll out of the Jakarta patch as well as to address various internal defects and enhancement requests.

- Dev team creates a release record "ServiceNow April Release"

- Dev team links the Feature record "ServiceNow Jakarta Patch" to the release by setting its parent field.

- Dev team links the various internal enhancements to the release by setting their parent field.

7. After completing testing and development of the features:

- Dev team sets all defects and enhancements to state "Deploy/Launch"

- Dev team generates a new change record for CAB to approve the release.

8. After applying the SN patch and update set in production:

- Dev team sets all enhancements and defect records to closed complete

- Dev team closes out the problem record

Given this scenario:

Is it a good idea to log defects records and link them to the problem?

When does an SN site problem become a defect?

Is it a good idea to link the defect records with a parent feature record for the SN patch? Is there a better way?

I understand that no two companies have the same process and everyone will have their own unique spin on things, but when it comes to approaching SN related defects specifically, I would expect there to be somewhat of a standard/best practice.

I would be grateful if anyone could describe the process they are following so I can have a few reference points.

Thanks!!

- James

[SusanWinKY]

James, I notice you didn't receive a reply here, but I'm wondering if you ever figured all this out. 

We're implementing a similar thing, except we're expanding on this not to include just incidents/problems, but also Enhancements and Projects.  Our plan is to use Idea to capture basic details from a requester (in our case, an employee) and route that through the Demand process.  Then it either becomes a Project, Enhancement, or Defect.  The work will be done as Stories.  From there, we would like to hook into Release Management and Change Management.  The problem we're seeing is there isn't a seamless process or common data that connects all of that.  We've already identified several custom fields to add to most of these record types so that we can have common data.

Just curious if you've solved this (at least for the Incident/Defect piece).  Your experience may be helpful to us as we design our future processes.  Thanks!

[jamesmcwhinney]

Unfortunately I haven't.  This is one of my biggest issues with the ServiceNow platform.  It is a tool created to support processes, but the processes are never very well defined, if at all.

I have yet to find any meaningful documentation outlining the processes for which ServiceNow is designed to facilitate.
All of the information I have come across on the docs site has been very vague and doesn't paint a clear and detailed picture.
Meanwhile the SN motto is to try stick to the OOTB configuration as much as possible and limit customization...  Seems hard to do without knowing the OOTB processes.

I am hoping will show me the light and reveal some hidden document repository with detailed process flow diagrams or swimlanes etc,. but it has yet to happen.  =\

[Luis Franco]

Hi.

This is a very detailed post so I would like only to share some minor remarks on our process:

1 - Regarding the incidents we are using the Waiting Change state and creating an change request from an incident. When the change is closed, the incidents are automatically set to resolved.

2- Defects are only used to report on issues found on test management process in projects. There is no link to the change process from defects

3- We are using the Idea -> Demand -> Project -> Test Plan records for all our business applications development. When the project is ready to deploy we user the "create project task link" related action from the project tasks to create the change and move on through the cab meeting.

4- We have created a specific table for the release management process and is integrated in the project record in the software release and also on the change requests. This is used to prepare the release checking if all the changes for a specific release are already approved.

Hope this helps in clarifying some doubts you had. If you need more information please go ahead and ask.

Best Regards,

Luis Franco

[Ronald Martin1]

Hello James, I have the same challenge. If I need a fix to permanently solve a problem, I think opening a defect is the way to go.  And then getting the approval to deploy the fix into prod via a change record.  Once the change is completed, the problem should be closed and if any related incidents are in state On hold/awaiting problem, then they should be closed too.

Haven't found a native OOB way to do this in ServiceNow.

R