Quantcast
Channel: ERP 4 Finance
Viewing all articles
Browse latest Browse all 6

ERP, SOD and GRC: More than letters of an alphabet.

$
0
0

I’ve had 2 conversations over the past week that have gotten me thinking about acronymns. The first thought is there are TMA (too many acronymnns). The second thought was that different acronymns mean different things to different people. I “assumed” (never good) that everyone knew ERP, which my blog is focused on, stood for Enterprise Resource Planning. Just to check my facts, I looked up ERP on Wikipedia. I found “Economic Report of the President”, “Effective Rate of Protection”, “Equity Risk Premium”, a village in France, a village in Germany, and a village in the Netherlands. As if that wasn’t enough, I also found “Effective Radiated Power”, “European Radio Power”, “Estonian Reform Party”, “Electronic Road Project” and many others. OMG, TMA!!

So, back to the topic of my blog, soon to be renamed Enterprise Resource Planning For Finance, to avoid any confusion. I was thinking, based on my incorrect assumption that everyone knew what ERP was, that SOD and GRC mean different things to ERP (meaning Enterprise Resource Planning for the rest of this article) consultants and auditors, CFOs (meaning Chief Financial Officer and not the texting slang) and others within the Financial field. Finally, I am back to the reason I started this blog, bridging the gap between Finance and IT.

I realized that if you ask an ERP consultant to describe SOD, they will begin to tell you about how long the product has been around, what version it is on, how long it will be supported into the future and what is planned for future versions. Huh?? It’s clear and makes sense, because SOD stands for “Statement of Direction”. The real question though was how does the ERP system handle “Segregation of Duties”, SOD not to be confused with turf or grass, which is the only definition on Wikipedia. So, where does this come in with GRC (“Golden Retriever Club”, “Genome Reference Conference”, and others, but for our purpose “Governance, Risk Management, and Compliance”). Again, I digress, but from here on, we are focusing on ERP (Enterprise Resouce Planning), SOD (Segregation of Duties) and GRC (Governance, Risk Management and Compliance)

It is important for IT and / or the ERP consultant to understand the concepts of SOD and GRC at a high level at least. I do not believe they need to get into the finer points of COSO (Committee of Sponsoring Organizations) which defines frameworks for SOD or the SAS documents on risk assessment for auditors. It is important though that they work with someone within the internal audit organization or Finance department to make sure the ERP system is configured so that it is compliant with standard SOD practices. (Compliance) It is also important that the financial people stay involved in the project and are prepared to sign-off that the security within the ERP system complies with any SOD matrix developed internally.

As part of that review process, it is critical to find those areas that do not conform. Unless you are an extremely large organization, it is very difficult, if not impossible to have 100% compliance with SOD regulations using the ERP system. This brings us to the R for risk management. How do you mitigate the risk of non-compliance? As a simple example, if you are a small company and only have 1 person in accounts payable, they typically would enter invoices and print checks. Do you have a control in place to ensure the checks don’t get sent out without review by someone else? Do you have someone different reconciling the bank and scrutinizing each payment?  Are you ensuring someone else is entering and maintaining vendor records? These are simple, not necessarily acceptable, depending on your corporate structure examples of how to mitigate or manage that risk.

Finally, we get to the governance component. How are you ensuring that what you put in place is adhered to? It is important for Finance to work with IT in developing a report or some type of audit of ERP security to ensure compliance AND risk management. I always recommend reviewing security against your SOD at least once every 2 years. As new hires are brought on, people leave, others change roles, there are often items that will show up requiring modification. It is also important that someone is monitoring (governing) the security changes, SOD modifications, etc. because we all know people do what is monitored.

Until next post …



Viewing all articles
Browse latest Browse all 6

Latest Images

Trending Articles





Latest Images