We are excited to announce that OAUG just published an article I wrote called "Why Implementations Fail, Beyond the Obvious". The article can be downloaded at: http://erpra.net/files/ERPRA_Why_Implementations_Fail_Beyond_the_Obvious_OAUG_Insight.pdf.
Please read the article and provide any comments on my blog. Feel free to send me any questions or comments at jhare@erpra.net.
Regards,
Jeffrey T. Hare, CPA CISA CIA
CEO, ERP Risk Advisors
Tuesday, January 10, 2012
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
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!
Regards,
Jeffrey T. Hare, CPA CISA CIA
"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
Tuesday, June 28, 2011
Two new web blogs in past few days
You Tube channel has all web blogs. Links are also available on our website.
Here are the topics for the latest two:
-Impact of Responsibilities using a custom application on SLA programs
-AR Adjustment Limits System Design Flaw
Regards,
Jeffrey T. Hare, CPA CISA CIA
jhare@erpra.net
LI profile: http://www.linkedin.com/in/jeffreythare
Here are the topics for the latest two:
-Impact of Responsibilities using a custom application on SLA programs
-AR Adjustment Limits System Design Flaw
Regards,
Jeffrey T. Hare, CPA CISA CIA
jhare@erpra.net
LI profile: http://www.linkedin.com/in/jeffreythare
Tuesday, June 21, 2011
Web-blog: Consolidations submenu design flaw
Here is the first web-blog I've done. Hopefully today's topic will be of interest to you and future topics will be as well. Today's web blog can be accessed at: http://erpra.net/bestpractices.html.
Contact me with any questions or suggestions on future blog topics at jhare@erpra.net.
Regards,
Jeffrey T. Hare, CPA CISA CIA
Contact me with any questions or suggestions on future blog topics at jhare@erpra.net.
Regards,
Jeffrey T. Hare, CPA CISA CIA
Friday, April 1, 2011
Change their password upon first login/admin reset
Got a question today about password resets:
"I am trying to figure something out. How do we validate that Oracle forces the user to change their password upon first login/admin reset? I thought it was something in the profile options. Thank you for the help."
My response...
Inherent in the system. Can't be turned off. Not controlled by Profile Options.
There are a lot of risk involved with password resets. With plenty of hacking / backdoor access to the database and privileged users that have the ability to reset passwords, this should be a critical control for your organization. You need a policy and related procedures on how/when p/w resets can be requested and who can reset the p/w. Then, because of the risk, the process owner (system or security administrator, security auditor, etc) should regularly check with the owner of the accounts to make sure the p/w resets were valid and not some nefarious behavior.
My two cents FWIW.
Regards,
Jeffrey T. Hare, CPA CIA CISA
"I am trying to figure something out. How do we validate that Oracle forces the user to change their password upon first login/admin reset? I thought it was something in the profile options. Thank you for the help."
My response...
Inherent in the system. Can't be turned off. Not controlled by Profile Options.
There are a lot of risk involved with password resets. With plenty of hacking / backdoor access to the database and privileged users that have the ability to reset passwords, this should be a critical control for your organization. You need a policy and related procedures on how/when p/w resets can be requested and who can reset the p/w. Then, because of the risk, the process owner (system or security administrator, security auditor, etc) should regularly check with the owner of the accounts to make sure the p/w resets were valid and not some nefarious behavior.
My two cents FWIW.
Regards,
Jeffrey T. Hare, CPA CIA CISA
Tuesday, March 22, 2011
GL: Statistical Journals -- not suppport by journal approval workflow
I saw this question on OAUGnet and thought I'd respond to it...
"Can anyone verify this: In R12 G/L, the seeded Journal Approval workflow (WF) will not route a statistical journal for approval regardless of the journal's source."
Here is what I found in My Oracle Support
MOS [ID 1076823.1]
"Currently Statistical journals do not require approval as per standard functionality.
The only limitation you can make is that you can use the profile option Journals: Mix Statistical and Monetary to prevent STAT and monetary lines on the same journal.
It is not possible to restrict entry of STAT lines by user."
Not really sure I understand how this profile option 'limitation' addresses the issue, but it is there nonetheless... Sometimes support analysts just hate saying "no Oracle doesn't provide that functionality"...
Regards,
Jeffrey T. Hare, CPA CISA CIA
ERP Risk Advisors
http://www.linkedin.com/in/jeffreythare
send me a linked in request - jhare@erpra.net
"Can anyone verify this: In R12 G/L, the seeded Journal Approval workflow (WF) will not route a statistical journal for approval regardless of the journal's source."
Here is what I found in My Oracle Support
MOS [ID 1076823.1]
"Currently Statistical journals do not require approval as per standard functionality.
The only limitation you can make is that you can use the profile option Journals: Mix Statistical and Monetary to prevent STAT and monetary lines on the same journal.
It is not possible to restrict entry of STAT lines by user."
Not really sure I understand how this profile option 'limitation' addresses the issue, but it is there nonetheless... Sometimes support analysts just hate saying "no Oracle doesn't provide that functionality"...
Regards,
Jeffrey T. Hare, CPA CISA CIA
ERP Risk Advisors
http://www.linkedin.com/in/jeffreythare
send me a linked in request - jhare@erpra.net
Subscribe to:
Posts (Atom)
