Feature - Change Management

Forum - Software
#1

I would like to suggest some sort of change management feature. While this is possible in a variety of software, the ability to link specific changes to assets natively in Eramba would be extremely beneficial.

For the CM piece of this, it could be very simple.

  1. New CM
    a. Requestor
    b. Approver
    c. Description of change
    d. Related asset

Each CM could work like incidents with different ‘stages’ (Awaiting Approval, Approved, In test, Ready for production, deployed, etc.) with applicable approvals, comments, and attachments.

Then on the asset side, we could have a section (like reviews), with ‘changes’ that would link any change associated to that asset with the overview of the CM information.

Right now, I’m ‘doing’ change management…in Azure DevOps (not code related). Please send help.

#2

So riddle me this - what about using the project management module for it?

The only thing that will probably not work is relating it to an asset defined in the asset management module, but consider this -

  1. Each overall change is a project. It can have custom attributes you want to maintain at the change level (requestor, approver, description, status, related asset). Of course, related asset would likely need to be a predefined multiselect checkbox thing, otherwise reporting is a nightmare.
  2. For each change that gets created, you can likely string together a webhook to hit the API to add a series of tasks each time a new CM is created (or manually add the tasks yourself and use custom statuses to flag missing ones).
  3. Custom statuses can be used to determine where in the lifecycle it is.

Of course, overall, I’m not sure this would be the best idea as you would not have any linkage out to code - if you’re going through an audit, I’d highly suggest going a path where you can link pull requests to tickets with the information through an integration → that’d mean JIRA or similar could be in your future (which, you can get to pass information back/forth using the webhooks/apis…).

#3

Hey David, thanks for the reply!

My request was more for infrastructure changes at as a whole, not relating to code (our team has that covered with the appropriate usage of devops :slight_smile: )

While a project would technically work, it would work for initial changes only…

A literal example of what I am using Azure DevOps in an absolutely horrible way for (yes, that’s my orgs issue not yours, but sympathize please!)

Asset - SQL Server (Specifically Azure with Networking whitelist):
Change 1: Dev 1 needs direct access for some asinine reason (not my problem to say no, but my problem to track)
Change 2: Dev 2 decides he needs this, do the same thing
Change 3: Remove those IP whitelists

We do not run infrastructure as code (nor does it look like we will get there in the near future) so changes like this can run amok. It is not feasible to create a project for each asset and continuously add tasks, that seems like a backwards way of using that feature. Plus, that would absolutely get in the way of our actual projects, making that area extremely cluttered.

With the way I am suggesting, I would have one parent object (the asset) and multiple ‘changes’ (like a review) made on that asset. Whether it be installing an additional service on a server, whitelisting an IP, disabling a registry setting, installing a major upgrade on a system that is not linked to code…you get the picture.

And I have also considered using asset reviews to do this as well, but again I run into the issue of it cluttering up with our actual audits.

My absolute ideal process on this would be:

  1. Asset has CM
  2. CM is stored much like reviews are
  3. Risk assessments can be made based off of the CMs if necessary

All of that tied into a nice little bow seems a lot nicer than a glob of projects.

Thank you for your consideration!

#4

sorry no plans for CR in eramba for the time being