ERP Security and Segregation of Duties

One of the more interesting dynamics in an ERP implementation is how your organization reacts to, and structures ERP security around, segregation of duties issues. If you are not familiar with the term, or unsure of the context used here, segregation of duties (aka SoD) means that an individual should not have security access to a series of transactions which could allow him or her to engage in financial misconduct. The poster child example for SoD issues is that the same person should not be allowed to create a purchase requisition, approve a purchase order, receive a purchase order, and authorize payment for a purchase order. The problem, obviously, is that the organization becomes vulnerable to an individual who either (a) colludes with a vendor to receive and pay for fictitious goods or services or (b) purchases valid goods or services with company money but arranges for them to be used for personal gain. In this case, segregation of duties is recommended as part of ERP security design, such that the person approving the purchase order is different from the person creating the requisition, and both people understand what is being purchased and why. Likewise, the person receiving the purchase order is different from the approver, and verifies that the goods or services ordered were, in fact, delivered in full.

Over time, financial controllers and designers of ERP security functionality have interacted enough such that every combination of transactions can be evaluated for segregation of duties conflicts. Some combinations are easy to understand; others are more difficult. Generally speaking, any interactions with the external world – vendors or customers – are inherently vulnerable to abuse, so checks and balances are understood. It is sometimes less obvious to understand why having editing permission to the manufacturing forecast and authority to create a manufacturing work order, for instance, might constitute a segregation of duties violation.

Prepare for User Frustration

The more capability you attempt to give an individual, the more likely you will bump into SoD issues. Because of that, there will always be some amount of tension, since SoD tends to restrict access to your ERP system. Viewing information is usually permissible, but having security clearance to fix a problem when it arises may not be. A customer service representative may see an error in customer master data but may not have authority to fix it.

Don't Miss this Free ERP Download: Steps to Implementation Success

Downsizing over the years has resulted in some interesting job combinations. When you couple downsizing with the objective of segregation of duties - to partition every job in a manner that reduces the possibility of fraud – you can sometimes end up with big challenges, requiring either seriously restructuring jobs, or adding to complement. Neither activity necessarily adds value to the operation; the theory is that it reduces financial risk.

Segregation of duties and its subsequent effect on how you construct and assemble your ERP security strategy and roles is neither intuitive, nor easy. Be prepared for some hard work, and emotional discussions.