Tuesday, August 30, 2011

Basics of MOAC and Inherent limitations

In R12 of E-Business Suite, Oracle introduced Multi-Org Access Control (MOAC) to provide users with the ability to view data and process data across operating units. This new functionality is welcome by organizations that process data and want to view data across operating units – such as those that have a shared service environment. The implementation of MOAC is simple, but has some limitations. MOAC cannot be implemented in much of the world because of the need to use localizations and apply such localizations at the Responsibility level.

Inherent limitations
I queried two Payables users from in the Solution Beacon 12.1.2 Vision public domain environment – one for Austria and one for Germany. Localizations (JG: Territory and JG: Product) profile options were applied to these two responsibility in order to implement country-specific localizations for Austria and Germany. If you had a shared service center in Germany, for example, you wouldn’t be able to combine these two countries into a single responsibility using MOAC because there is no way to apply the localizations to the combined responsibility because you’d need to set the JG: Territory profile option for both Germany and Austria which the profile options form doesn’t currently support. I logged an enhancement request on behalf of client (Enhancement Request 10361672) that Oracle is currently considering. I encourage you to log an SR and throw your support behind this enhancement request.

White paper continued... Full white paper on this topic can be downloaded at: http://erpra.net/bestpractices.html

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!

Jeffrey T. Hare, CPA CISA CIA