When the subject of corporate data security comes up, the conversation usually turns to outside influencers such as hackers, malware, internal espionage and high-profile breaches. Those are issues that every company 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 in to 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 perspective, 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 appropriate 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 complicated problem. With the best of intentions, they’ll commit an admin faux pas, such as changing 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 customised “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 existing security functions within SYSPRO, allowing them to be configured by role. Enabling an administrator 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 (previously configured by group)
- Activities 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
SYSPRO ships with a list of standardized roles within Role Management. When Role Management is set up for the first time the option is provided to import this list, which contains generic roles that SYSPRO has identified as part of any organisation which purchases, manufactures and distributes items. The list can be imported and maintained in the organisations structure as required, and will help with the speed of setup and administration. Importing the standard roles does not delete or overwrite any roles you may have previously defined.
Knowing When (And How) To Purge
Since we’re talking about internal security and well-intentioned mistakes, let’s spend 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 realise the irrevocable nature of the Purge command, and that is why security around purge programs needs to be exceptionally tight.
For legislative 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 Purge function is run. And when the time comes to purge I always recommend that the company be copied into a “test” company before the command is given – this access should also be an Admin Only task.
For more information on how to ask for help, watch this brief video:
