Change Management Scope

[dsemeniuk]

Hello, first post as I am currently defining and implementing Change and Configuration Management in our organization and am trying to learn and do the best I can to ensure I have covered all areas effectively and make the process work efficiently without to much pushback and confusion.

So, my first question is on managing more than just the Production Environment. Right now, we are managing changes to our hardware in all of our environments (Dev, Testing, Staging, and Production), as in any licensed software has to go through an RFC (RDBMS, OS, etc..). This goes with any actua "Hardware" changes as well as in CPU, Memory, Disk, etc.. From what I read ITIL seems to focus on production environments but we feel the need to track what is happening in our dev and test environments to understand what versions of what rely where. Is this what other folks are doing as well?

For managing actual software changes, Change Management is not involved at this point as to approve the actual changes to software (custom in house), they are approved outside of the process. Change Management acts a gate keeper instead and an RFC is filled out to deploy the new version of the custom software into a specified environment (not jus production), again, does this make sense to others?

Thanks for your time, I have other questions but will create separate threads.

[The Skeptic]

You often end up with two parallel systems: Service Desk and Bug/Fix/SDLC. SD is used by the organisation as a whole to track the existence of a bug as a Problem, and the implementation of a fix as a Change. Likewise SD tracks the user request for an enhancement as a RFC and the implementation of the Change. So the SD is where you would track your current status, prioritisation etc. It is the business system

In parallel with this, the developers may have their own technical system that tracks affected modules, code revisions, versioning and packaging, vendor patches etc etc Problems provide bug input. RFC s provide enhancement input. Output is status change on Changes to go to production. It is the geek system

the geek system is a peripheral or ancillliary system where a subset of problems and changes go during one step in their workflow, when the developers decide they need to in order to be put through a technical lifecycle. During that whole cycle there is little or no activity in the corresponding SD entity other than periodic status updates

Some sites (and vendors) automate the integration between the two. I think this is unnecessary and in fact counter-productive. there is a translation step required as data flows between the two. the geek system says module ACD123 has been changed at line 75. The business sytem says the new shipping code has been added to the Warehousing service. The geeek system says your widget had the frammerjammer set to revert but we have grokked it and zapped the code table. the business system says it was a technical error but it is fixed now.

(from here