People tend to limit the access rights of the test environment of the system to the project team only. The common reasoning is that if key users do not need access to all functions of the systems, why should they be able to see all these functions during the implementation? However, what we have noticed during implementations is that by giving the key users more access in the beginning of the project it helps them to become more involved/committed, to become more aware of other teams' responsibilities and it enables a more thorough system design. They can add (unexpected) value to the implementation and system design. Below we would like to further elaborate these three benefits.
First of all, people tend to explore something new which they use for the first time. Do not stop their curiosity. Instead, encourage them to explore the system as much as possible. This accounts for the project team as well. Grant them the access to 'play around'. This will be of no harm as long as the administrator role is well protected and the test environment is controlled well. Doing this will lead to a higher involvement and commitment on the project from those involved. All information available of the system will remain 'just' theory if you do not have experienced the system yourself. However, time and effort are required from key users to provide the project team with their input. When they understand the system and have experienced the added value of the system, they will be more committed to free up their time for the implementation. Next to that, after system 'Go Live', a higher user adoption will be realized among these key users. It helps them in their transition to their new way of working.
Secondly, it helps key users to comprehend the end-to-end S2P process which facilitates a better collaboration among teams. A good example is granting a Buyer access to the functionalities of an Accounts Payable clerk. During a recent implementation, we hosted several detailed process walkthrough sessions for the Buyers. The aim was to show them how a Purchase Requisition and a Purchase Order are created, how a Goods Receipt is attached and how an Invoice is matched and processed. Thereafter, the Buyers were granted access to the Invoice system functionalities to experience themselves how the process works in the system. By presenting this end-to-end S2P process flow, the Buyers understood how Accounts Payable clerks handle divergent invoices and how this impacts the end-to-end process. This has helped them to visualize the bigger picture and enabled a more collaborative way of working across-functions.
The third benefit shows that giving users access from the beginning also increases their early involvement in the system design. Key users with a wider range of functionality access tend to give more feedback on the system design, including feedback which is not solely limited to their daily duties. Due to this wide range of functionality access, key users will have a better understanding of what the impact will be of system design decisions by other teams that impact the end-to-end S2P process and therefore their own process as well. Following the previous example, the Buyers were providing input, recommendations and asking questions about the system design impacting Accounts Payable as they now understood the impact of this specific design part on their own process scope.