Does your change control process score change requester and/or implementers? [closed]
Solution 1:
We do have a CR process that everything must go through, but there is no scoring. There is levels of course - for example you indicate what the risks associated with the change are, and which environments could be affected by those risks - the environment might be something like "production Oracle DBs servicing Portal" for example.
If the CR states anything more than a minor - then the CR people have to have a big fat meeting.
As part of the CR, everyone needs to have a complete roll-back plan.
...But no, there is no scoring as such, other than the reputation you'll gain once they get to know you.
I think it's not a bad idea at all though, might put some incentive for people to do CRs, another reason why CRs are partly-useless here where I work specifically (imo) - is that you submit CRs, but don't have any means of querying them in a useful way, so again - less incentive.
The best way to make such things useful I think is to provide some value back to the people that you expect to use them. Either through functionality, or scoring (like serverfault), or other.
Solution 2:
Having a change control process that has ways of circumventing additional scrutiny bypasses the main reason for a change control process in the first place. One of the benefits of getting people together to discuss changes is that you get more eyes and minds looking at potential changes. The more people (who preferably all work in different areas of your production infrastructure) you get looking at the problem, the more complete a picture you can get of the potential impacts.
While I think it's a neat idea to have a scoring system (possibly similar to the one on this site), even all-stars make mistakes/oversights. A tiny change in one place can have huge impacts in another.
Solution 3:
This sort of scoring system sounds like it will be vulnerable to politics and gaming very quickly - indeed it sounds like you're trying to make it so the in-crowd get to circumvent change control. Whether that's a good idea or not I can't judge from this distance.
If you're going to bother with change control as a means of risk control, rather than CYA, then everything needs to have a risk and impact assesment. Who is carrying it out is not usually a factor in how risky something is - and even when it is, having a situation where some people are allowed to make changes despite being the unsafe pair of hands looks very odd.