Published
Author
It is possible to make a long list of what is important or even critical for a customer to achieve success with their new ERP system. Usually, success depends on several factors that together contribute to a successful project. It should be emphasised that the success factors can be linked both to the customer's and the vendor's efforts.
However, there is one factor that should receive greater attention when talking about success. This concerns the customer's ability to take ownership of their new ERP system. When reviewing the outcomes of nearly 1,000 projects where HerbertNathan & Co has participated or had insight, it is clear that customers who have managed to take "ownership" of their system before deployment have both become more satisfied customers and achieved more benefits compared with those customers who have not followed through with their ownership.
This can be defined from both a short and a long perspective. In the short term, it means that the customer is knowledgeable enough in the system and self-sufficient before go-live so that the vendor can almost stand by without needing to contribute. In the longer term, it means that the customer has managed to establish an organisation that actively and continuously develops its use of the ERP system.
To be able to take ownership before deployment requires "significant" own time from the customer to work with tests, tests, tests and tests again. It is not enough to learn their normal basic flows; it is important that the customer also gains an understanding of the system’s logic and architecture regarding process flows and transaction flows, which also includes understanding and knowledge of how the configuration is constructed. It is very common that testing before deployment is hindered because of missing components in the configuration and permissions. The result is interrupted and prolonged tests where the focus is more on "getting through" than on focusing on the total efficiency of the process. It is also very common that the test period takes on the character of training instead of testing, which takes time away from the fundamental tests. Training and knowledge acquisition must take place earlier in the project so that the customer can carry out their tests with limited support from the vendor. And the customer should assume that the few training days the vendor estimated during procurement are seldom sufficient to achieve the ownership needed; considerably more time for training and knowledge acquisition should be expected. Regarding ownership from the longer perspective, we touch on the area that often gets the dull heading "maintenance." However, this term feels somewhat outdated and relates more to the time when there was a system team that maintained the system from a technical perspective. Today, when we talk about maintenance, it means more an organisation that has the system’s continuous development as part of ongoing business development. This means that the people who have roles in the business development of the organisation also have a responsibility to develop the organisation’s system support. And then it is not enough with an IT council that meets 2-3 times a year to align on all ongoing projects. Instead, there should be an ongoing and preferably monthly process to fine-tune and develop the business.
Of course, there is a cost to being able to take ownership of the system. A lot of working hours must be freed from daily work. This internal cost sometimes irritates management and the board, which often leads to the cost being hidden in connection with the investment request. However, it is forgotten that it is ownership that creates the conditions to achieve the expected effects of the system and is therefore also required for the investment to pay off.
"Measuring one’s ownership" should be a parameter when assessing the customer's ability to carry out a successful deployment.
