Shielding Your ERP Information

PostedOn: 2016-11-18 12:18:18

When the subject of commercial data safety comes up, the conversation frequently turns to outside influences such as hackers, malware, internal intelligence and high-profile breaches. Those are issues that every business should protect against, but they are not the topic of my blog today. What I’d like to address are basic security measures that will protect your data (and your ERP investment) from the mistakes of well-intentioned employees. 

It may seem difficult to believe, but I have a customer that continues to allow its employees to log into their ERP software without a password. Why? It’s faster and easier, they claim, they trust their employees, and they have a strong firewall to protect them from external threats. Besides, their data is backed up regularly, and not interesting or high-value enough to attract attention from the criminal element. So what’s the big deal?

From the support-desk standpoint, it’s potentially a very big deal. I have seen it happen in the past, and I will no doubt see it again: a user can’t complete his job because some admin task hasn’t been done. Thinking that they’re being clever and helpful, they simply log in as Admin and make what they believe are correct changes.

Some users have gained a little ERP knowledge over the years – just enough to make a little change and create a very large and often intricate problem. With the best of intentions, they’ll commit an admin faux pas, such as altering the module setups or invoice numbering while other users are still on the system. It takes, typically, a deeper level of knowledge to know that there are tasks that need to be performed when users are not logged in and that some setup options, once selected, should not be deselected. You often need more-than-superficial knowledge to make the setting change without impacting on the whole module.

Administrator rights for accessing a change of settings should not be gifted to just any old Joe. Placing all of your users into the Admin group is never a good idea. Make an investment in security and efficiency by setting up your users in groups that match their tasks. In the long run, doing this will save you time and it will also make it harder for accidents to happen. If users have multiple roles within a company, they can always be setup with sub-groups that allow them to complete their appointed tasks.

You can easily take this one step further, by setting up customized “Roles”. This makes users’ screens less cluttered, allowing them to focus exclusively on the fields they need. 

Role-based security is an optional feature that consolidates obtainable security functions within SYSPRO, allowing them to be configured by role. Enabling a superintendent to assign an operator to a role provides a much simpler mechanism for managing security – especially when dealing with a large number of users, or when adding new ones.

Role-based security consolidates the following ERP features:

  • User Interface
  • eSignatures (previously configured by system, company, group or operator)
  • Program Access (formerly configured by group)
  • Behavior and Fields (previously configured by operator)
  • Access Control (previously configured by operator – this includes items such as warehouse, branch, bank, job class, account and contact properties)
  • Workflow settings

Knowing When (And How) To Purge

Since we’re talking about internal security and well-intentioned mistakes, let’s expand a moment on the “Purge” function in all the sub-ledger modules. Purge means delete. Definitely an Admin-Only function! Once purged, your data has been wiped away it’s gone forever unless you have a vital, valid backup. Some users may not realize the irrevocable nature of the Purge command, and that is why safety measures around purge programs need to be exceptionally tight.

For lawmaking and tax purposes a company needs to keep a number of year’s records on file. Within the Module setup, on the History Tab, you may select the number of months to retain records. This should be double checked before the cleanse function is run. And when the time comes to purge I always suggest that the company is copied into a “test” company before the command is given this access should also be an Admin Only task.