Day to day IT tasks and how they are managed using Change Management within ITIL
I am currently running a project using Agile SCRUM to deliver a CMDB solution, an Upgrade to Remedy Version 7 and ITILv3 processes. Obviously this type of effort has some pretty profound impact on the organization especially when there are years of process, policy and belief which currently govern perceived best practices.
Obviously the goal of any ITIL implementation should provide an adequate set of controls, and awareness and collaboration within the Enterprise. The teams consuming the current processes are looking for ways to optimize their work, while still conforming to the core principles above.
We have laid out certain goals to mine out more standard changes within our organization to streamline IT. It is apparent that the focus of the organization should be on the large, complex and risky changes while metrics collected during problem management should help us understand if have turned the knob too far one direction.
One of the teams brought an interesting problem to us today. They wanted to document a set of activities which would not require even a standard change entered into out change management systems. This at first raised concerns on my part until I reviewed the kind of things they were talking about. They were asking about day to day system administrative tasks which in my mind would not fall under the definition of a change with ITIL:
The addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. — Source ITIL v3 Glossary
What is interesting is that by this definition many day to day administrative tasks such as cleaning up logs, running jobs, etc really don’t fall under the definition of “Change” as they are not modifying a managed CI. For example if an UNIX admin needs to clean out /var should a change record be required? Some may argue that it could affect the system but I believe we could argue that most times it is completely safe.
So my thought here is to require a published document which outlines these types of Day to Day activities which are not changes. The standard would be reviewed and managed under change management and be approved by the CAB. These types of day to day activities would not require any change logs or records within our Change Management system. If problem management shows by trend that this day to day work is causing incidents then we reel them back to Standard or Non Standard Changes.
I would welcome the thoughts of others…
I would agree,
The same would apply for pruning or archiving web server or OS log files.
Ditto with defragmenting database indices etc. Or Nightly data extracts to an OLAP system – you can’t truly schedule a ‘change’ each time
The process and schedule could be managed – but if it is a recurring process or event – it would just add clutter to your change review
Hi Shawn,
A bit late, my comments but they come
And it is a consulting answer: It depends.
Are the environments that are managed very high availability environments (e.g. financial transaction systems, life support, maybe google)? Will a single short outage risk the existance of the company? If yes, then every touch of the live environment needs to be documented and approved (in a nice tooling environment it should be possible to create a “flush logs” model for a change, which then can be created with 2,5 mouse clicks (or key strokes for the sysop types).
If the environments you talk about are “just” normal high availability, then there may be administration work outside of a change. Just remember that your OPS manager still has to proove the work his team does, so he may loose capability when you stop using standard changes. If you do not document these activities noone will come by and automate them, which is the way to go (as elliotross comments, this is clutter and clutter can be handled by machines. Changing the clutter schedule is a change).
I have just described some of my ideas on the change management process here, it may interest you.
Regards,
Marc