ERP War Stories: When ERP Security is setup late, during an ERP Implementation

Our Track Record:

Over the past 20+ years of managing ERP implementations, one area that is consistently underestimated is system security, specifically when it should be designed, configured, and tested during the project lifecycle.

Preamble:

Security is often treated as a technical step near the end of the project. However, it is really a foundational component that directly impacts how users interact with the system, that their user license / system authorization is aligned with the user count they acquired, how they will process data, and whether the organization can operate effectively post go-live.

Situation

In one instance the security design and role configuration was deferred until just before User Acceptance Testing (UAT). In this situation there was a belief that the roles and permissions could be quickly configured just prior to user acceptance testing when it should have started during the Build Phase. The thinking was that we should keep all roles wide open with the “super user” permissions and then restrict access just before UAT. However, when it came time to setup the security more time was required and this extended the project timelines for when UAT could occur.

Notable Risks

• Delays in security role setup and configuration can push out User Acceptance Testing (UAT) timelines and overall project milestones.
• A rushed “quick setup” approach often leads to poorly structured security roles, inconsistent access, and inadequate validation of business processes.
• Users may encounter excessive access, restricted access, or their roles and responsibilities needed to be update resulting in additional troubleshooting and rework.
• Frequent security changes during UAT can extend testing cycles, consume internal business resources, and delay project completion.
• Late-stage security issues are often more complex and costly to resolve because they impact multiple processes, integrations, and user groups simultaneously.

Mitigation: 

• Quickly identified key out-of-the-box security roles that could be deployed as an initial baseline for testing.
• Reduced the number of testers and focused UAT efforts primarily on validating functional business processes rather than individual user-level security configurations.
• Refined and adjusted security roles following UAT, prior to go-live, to ensure users had the appropriate access needed to perform critical functions while also restricting access to sensitive or confidential data where required.
• Continued refining and optimizing security roles post go live as users became more familiar with the system and additional operational requirements were identified.

Lesson Learned:

• Security design and role planning should begin during the Build Phase, not immediately before User Acceptance Testing (UAT).
• A phased / iterative security approach is often the most effective strategy during ERP implementations. Initial testing phases can begin with broader access roles to allow users to familiarize themselves with the system and validate core business processes.
• As testing progresses, security roles should be refined and restricted based on user responsibilities, business functions, and segregation of duties requirements.
• Final role optimization and validation should occur prior to UAT to ensure users are testing within an environment that closely reflects their actual day-to-day access requirements.
• Additional refinements post go-live are typically necessary as organizations gain better visibility into operational usage patterns and evolving security needs.

Proper security planning is not simply a technical exercise, it is a critical component of project governance, user adoption, operational efficiency, and overall ERP success. Organizations that approach security as an ongoing phased activity rather than a last-minute configuration task are far better positioned to reduce project delays, improve testing quality, and achieve a smoother go-live experience.