Wednesday, August 17, 2011

Configuration Change Management process - should end users own it?

I am dealing with a client that has end users make significant changes to the configurations in their module. They are re-implementing and I am advising them on changes to security and controls. I thought this email would be of interest to other companies so I thought I'd share a bit of it.

"I have some feedback regarding your configuration change management process that I wanted to pass on to you. I sensed some strong feeling about it in our meeting yesterday and didn't want to rock the boat so I thought email would be a better mechanism to provide you feedback and allow you to reflect on the recommendations.

I believe strongly in informed and educated end users. The more knowledgeable users are about the system, the better the processes they own. I am a strong believer that process owners 'own' the process, including how the applications work. This includes an understanding of the setups / configurations related to the module and those setups / configurations that are core to the entire suite of applications.

However, I rarely see end users have responsibility for making changes to key configurations in the application - what I call the configuration change management process. This is for two primary reasons. First, there is additional risk from an SOD perspective if end users have the ability to control the configurations for the processes they use. An example that we talked about yesterday is configurations related to the journal approval process. I'd rather not give the end user the community the ability to override a key control without it being formally documented and approved. Giving end users control over these configurations does just that. This could pose a serious problem when auditors come into to test the control under AS5 and learn that changes to the configurations may have been made without proper approval. Second, end users are typically not good gate-keepers for the change management process, are not trained on it, and are not supervised by management that has primary responsibility for implementing and controlling the change management process.

As it relates to the discussion yesterday, we specifically talked about Bob's role in the GL module. However, we also need to address the risks in other analysts like Bob throughout the application - those supporting AR, AP, HR, Payroll, Purchasing, etc. Do you have the same level of confidence in their ability as you would with Bob? What happens when Bob retires or leaves the company? Are you going to have the same level of confidence in her replacement?

The purpose of the change management process is, among other things, to protect the integrity of the system, its data, and the business processes which are supported by the system. From what I understand, part of the reason that ABC Company is re-implementing relates to configuration changes that weren't thoroughly thought through and/or tested in 11i. I am not necessarily saying that having IT manage those changes would have saved you from having to re-implement, but I can say that at least a solid configuration change management process will give you a more defined process to follow - documentation, impact analysis, test plans, approvals, etc. - and give you a better shot at maintaining the integrity of your system after you re-implement in R12.

So my recommendation is this... as part of the risk assessment process I am doing, let's have a discussion, by module, about what configurations should go through the configuration change management process, then design security and the configuration change management process to allow IT to make those changes rather than the end users. In my opinion and based on my experience, this will give ABC Company better controls (preventive versus detective) and a better chance of maintaining the integrity of the system."

Thoughts are welcome!

Regards,
Jeffrey T. Hare, CPA CISA CIA

No comments: