Oracle ERP Cloud implementations are typically fast-paced, complex and cross-functional. As such, they often face a number of challenges and risks that threaten to derail progress, negatively impact end users or drive up project costs. Even with a strong system integrator (SI), it is critical for the business to assume responsibilities for key activities in order to reduce the likelihood of negative project impacts such as:
- Unidentified financial impacts to the organization
- Lack of transparency with budget and status
- Incompatibility with business processes
- Missed business requirements
- User reluctance to change
- Gaps in the internal control environment
- Unmet stakeholder expectations
- Decreased productivity of the organization.
An effective way to support the business throughout the project lifecycle and centralize risk management efforts is to establish a project risk management (PRM) function.
What Is Project Risk Management?
Risk management is the process of defining, identifying, addressing, and eliminating risk items before the items become threats or require major rework. In other words, risk management can be viewed as advanced preparation for possible adverse future events, rather than responding to an event as it happens.
From a system implementation perspective, the PRM function acts in an advisory capacity by comparing methodology, project status and deliverables to project requirements as well as leading practices. For an Oracle ERP Cloud implementation, the PRM function will typically focus on the following key risk implementation areas:
- Project Management and Governance: As with any system implementation, effective project management and governance helps ensure that the project does not encounter avoidable delays, missed dependencies, lack of ownership of key activities or inability to make decisions.
- Design and Business Process Alignment: Oracle cloud products are typically less customizable than their on-premise counterparts. This usually means that business processes are adjusted to fit the cloud product’s inherent functionality or configuration options. Ensuring that the stakeholders understand and agree with the future-state design is key; otherwise, user expectations may not be met.
- Organizational Change Enablement: As business processes evolve with the cloud design, plans need to be developed to raise awareness of end users. The SI will typically train a subset of key users, but it is the responsibility of the business to consistently communicate the future-state changes to the remaining user community. Thorough and well-designed communication plans and end-user trainings are necessary to facilitate user adoption as well as preparedness to perform their duties after go-live.
- User Security and Controls: One similarity between Oracle on-premise and Oracle cloud applications is the lack of segregation of duties (SoD) provided with the out-of-the-box roles. To prevent users from having excessive access or the opportunity to misuse the new application, management should address this risk as part of the system implementation by incorporating custom role design and SoD assessments into their project plan. To maintain the clean environment in the long term, management should also ensure that their user administration and access change management processes are established and tested prior to go-live, as well as consider using a tool to manage the user access and segregation of duties processes (e.g., Oracle Advanced Access Controls).
- Data Conversion: Data conversion design and testing should be considered a top-priority work stream. If data conversion activity is started too late, is not sufficiently planned or is not tested thoroughly, unanticipated complications and data-quality issues can delay downstream project phases.
- Reporting: During requirements-gathering sessions, management and users tend to concentrate on commonly used reports for day-to-day activities. Meanwhile, reports that are required for key controls might be considered only as an afterthought. Mapping of key controls to future-state report requirements is critical to ensuring that there are no unforeseen gaps in the future-state control environment, and the completeness and accuracy of these reports must be tested. Additionally, management should consider reviewing the process for developing additional reports immediately after go-live so they are prepared should additional needs surface.
- User Acceptance Testing (UAT): While the business should be engaged in testing cycles prior to UAT, this is the most essential testing cycle for ensuring that the new application will support the business. For UAT to be effective, the business requirements and solution design should serve as the basis for the testing plan. This will help ensure that the testing scope is adequate and that all business requirements are validated.
The PRM function will continuously assess management’s progress in each of these areas by ensuring that risks have been sufficiently considered and that the appropriate levels of documentation have been developed and retained to support audit requirements. While the PRM function will provide guidance to project leads and end users where needed, its primary goal will be to escalate risks to project leadership, management and project sponsors.
Key Considerations for Implementing PRM
When establishing a PRM function for a system implementation, there are a few important considerations for ensuring that the function is effective and beneficial to the project:
Independence from the SI: The SI’s primary objective is to complete the implementation on time and within budget, based on the requirements provided and the statement of work. Often, the SI is pressured to achieve milestone dates and deliverables that do not necessarily cover control requirements and audit considerations. The PRM function will inevitably have competing priorities with the SI; therefore, it’s critical that independence between the two teams is maintained in order to ensure that objectives are met from all sides and the best interest of the organization is prioritized. Additionally, independence would allow the PRM function to review the communicated project budget and status for accuracy in order to ensure that the SI is maintaining transparency.
Liaison for Audit Teams: As part of its responsibilities, the PRM function will likely review most critical processes and documentation that will be expected by internal and external audit during pre-implementation or post implementation assessment(s). As such, the PRM function is in an ideal position to act as the liaison between the audit teams and the project teams, as well as provide guidance on expectations. This can limit project disruption during critical phases, when implementation audits are likely to occur.
Involvement throughout Project Lifecycle: A common misconception is that the PRM function is not beneficial until late in the project lifecycle, because risks are more likely to surface closest to go-live (UAT, cutover, etc.). However, the PRM team may identify risks as early as the planning phases, giving the project team more time to plan and adjust its actions accordingly. Additionally, introducing the PRM team as a source of authority midway through the implementation may cause confusion and frustration. In order to facilitate the function’s ability to fully integrate as a trusted branch of the project team, the role should be socialized from the onset of the project.
Implementing Oracle ERP Cloud can result in increased efficiencies and significant return on investment – or it can be a massive failure. The business is ultimately responsible for the outcome. To provide additional support to the business and a centralized source of risk management, consider implementing a PRM function on your next major implementation project.
To learn more about how Protiviti can help manage your ERP application risks, please visit our ERP Solutions site or contact: