How to define ERP User Access Requirements

You’ve procured the technology, and your staff is trained. It’s time to establish who only sees part of the system, and who gets full access as this will affect the licenses you require. But how do you make such decisions?

While some roles are easier to define – those in senior management may well benefit from full access rights, while those who have a disparate set of responsibilities may only require access to areas. Therefore, a one-size-fits-all policy is less than optimal. It’s crucial you make sure each user’s rights reflect their real-world responsibility and that those who shouldn’t have access to sensitive customer information, don’t.

Cost-Benefit Analysis

To determine access rights, you will want to understand a few things:

  1. What functionality and access will your employees need to do their daily job
  2. The difference between a ‘full’ and ‘light’ user licence.

Only then will you be able to truly decide whether a full licence is required for users who need a lot, vs when a user doesn’t need as much and may only need a light user licence. After all, you don’t want to restrict someone from doing their job but at the same time you don’t want to overpay for functionality that’s not required!

Sure, a Managing Director might demand a constant overview, but if they don’t benefit from the insight daily, then perhaps a Team Lead should have that full license instead. The MD will receive weekly updates either way and could be thankful for the weight lifted from their shoulders.

While the technology may appear cost-effective at the outset, as you purchase more How to define ERP user access requirements licences with full rights or reduce full users to light ones (or vice-versa), budgets can quickly become aligned.

‘Light’ vs ‘Full’

Establishing what full users see is easy enough – they see everything; however, defining those with lighter access rights is not so simple.

Role mapping facilitates this process as you paint a picture of which team does what within your organisation, thus who needs access to what component to carry out their daily activities. By composing a matrix of tasks, then assigning them to particular business units, you can clarify the situation.

This job is, in itself, complicated, but if you carry it out in tandem – or shortly after – the project design phase, you will have a much broader picture of the roles and responsibilities you need to consider, along with who will require a full of light license. Once managers have signed off on the matrix, you can begin to understand what sales rights might look like vs accounting rights.

Test, then Document

You’ve painted the picture; now it’s time to put it to the test. Invite a product champion from each team to trial your set-up, carrying out their daily tasks to be sure that they have access to all the features they need. This can be done early in the process – with a test account on full access, if necessary – the critical outcome is that the user has not had to deviate from your access matrix into other parts of the platform to fulfill their duties. Once you have confidence in your approach, get it down on paper. Defined roles establish who needs what functions assigned; facilitates any change management process (should an individual/team request additional roles), and allows the technical team to create the profiles.

Review, Review, then Sign Off

It is more than likely that there will be a couple of teething issues early on. By reviewing and testing the role-based system you’ve created, you’ll discover any “bottlenecks”, understand if you need to create additional permissions, then add as appropriate. Plan several early-stage reviews, then weekly reviews for the first two months and invite team leads (or product champions) to feedback any shortcomings with their current rights on the system.

There may be efficiencies in allowing accounting to see the sales pipeline, for example, even if they do not interact with it directly, so leverage the power of ‘view only’ permissions and understand when visibility will support a team.

The most significant benefit of a single fully integrated system lies not only in users’ abilities to streamline workflows but in the fact that information is freely available across the organisation. While this could create a security risk if the wrong permissions are applied, ‘view only’ rights will undoubtedly enhance cross-functional collaboration and avoid unnecessary email queries and data extracts.

Where to next?

  • Meet with all departments, map out their processes and how they might use the new system in order to understand their requirements and assign their license based on this.
  • Plot a role matrix, define responsibilities and work with your Business Coach to determine access rights
  • Allow each department to test the system and review their access if required before going live.
  • Remember concurrent licencing is becoming a thing of the past. Undertaking this analysis will not only benefit you now but in the future as well. So, ensure you look at your financials for the future as well as the here and now.

For more information on ERP implementation please contact us here.