IT Employment

Ask something
Discussion Locked

Change Control Mgmt./Production Control

0 helpful
2 replies

by sfenner

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I am currently in charge of a mid-sized Data Center. We have about 30 HP9000 running HP/UX and about 100 NT/2K servers for web, files, etc.
RDMS include Progress and Oracle, mostly.
I am responsible for the common "production control" tasks regarding the job schedule, including backups and generating email reports; all automated.
We have a decent change control process but it still requires a lot of manual administration, including a weekly mtg. of group leaders to discuss what changes are being made and who it affects. Each group also maintains a seperate tracking system of changes for their area of responsibility.
I am curious about how others track changes for multiple OS, multiple applications, and e-business.
Is Change Control centralized for IT?
How do you track Projects and Problems?
Is this linked to Change Control?
What applications do you use for mgmt of these processes?
How successful are you at:
1)Tracking every step in each change, including across responsibility boundries?
2)Fixing most problems before implementing them into production systems?
3)Keeping all groups within IT informed of changes?
4)Keeping customers informed of changes?

Lastly, can anyone point me to "best practices" on Change Control Mgmt.?

2 replies

by asmaklad

http://cio.doe.gov/smp/
http://www.gantthead.com/Gantthead/default/

and you can refer to my comment on a similar discution:
https://www.techrepublic.com/forumqa/thread_detail.jhtml?src=search&thread_id=33451

by dzilm

As a ex outsourcing technology manager and co process manager and has been penned off the cuff;

Change control should involve the business representitives - they need to know what the impact of the change will be if a success, and also if it fails in any way. This involves customers (atleast those paying for a service who may be impacted).

Every CHANGE should be recorded in detail, who when, what, why, including the info to reverse it (should it fail shortly after implementation when another tech is on support).

Refer to your co. definition of a CHANGE, or refer to ITIL change practices (www search).

How you deal with restoration of a failed service and its interaction with the change process needs to be defined in your environment - usually direct & indirect impact related aspects will clarify this further.

ALL technology groups need to co-operate in the change process, as works by any one group may impact one of more of the other tech groups (eg comms upgrade a switch OS while central systems staff are trying to patch an application. The app patch fails because the comms link was lost when the switch reset as planned at the end of the upgrade process.) UGLY!

David
ITIL certified

This discussion is closed to new replies.