What are the most effective ways to manage ERP system customization requests from end-users?

Business value is most important criterion for ERP customisation. If impacted user population is above 10% then this is fit case of customisation. Further most of the customisations are due to local country compliance requirement so It is expected from ERP license owner to invest in improving standard report basis conference feedback of top 100 of each business segment user of mid and small company segment.

A lot has already been said about assessing the impact and value of the customization. However, another way to look at this is that many in IT are not fully aware of the day to day working challenges of the business users. If there is more frequent interaction between IT and business users and then IT is asked to come back with innovative solutions to reduce day to day burden, you would notice that the customization requests go down significantly and there is more trust. Business would be more open to collaborating with IT rather than pushing for frequent customization requests

Customization is a business necessity. However they should be kept to a minimum. - Business and Functional leaders need to promote best practices approach. - Make the cost of customization known to the functional leaders in ERP implementation. - Incentivize the team for every customization avoided and best practices adopted post the requirement gathering phase.

Most of the enterprises need to have a tighter alignment with the expectations from an ERP implementation. In my experience, organisations have disparate perceptions and view points across various cadres - mismanagement of expectations often leads to misalignment thereby leading to inappropriate objectives. Having an impact assessment is absolutely crucial. This can’t be restricted only to business impacts, but needs to holistically include technological impacts amongst other aspects like financial impact and time management. Lastly, theory of constraints is the absolute truth in any project. The team that manages impact assessments and theory of constraints well enough meets its goals and objectives in the long run.

"Assess the business value and impact" - that is the key. An ERP implementation may have plenty of people's engagement and when it comes to customization, all will try to have their way. And that is if entertained, nobody will be served. It will be chaos resulting in bad user experiences to majority of end users. And their come the "The Business Value" of the requirements. But it does not end there. You also need to assess the practicality [cost - not just in monitory term] to achieve that business value. A simple, smart solution to achieve a business value always wins over a solution which is over complicated, over thought and over technologized. So, prioritize the requirements with real Business Values and simple solutions.

Based on my experience Lean methodology is one of the optimal way to prioritize and categorize a new change request. The 5 why methodology used to assess the change: 1. Criticality 2. Business Impact 3. Urgency 4. Tax / Government requirement 5. Cost benefit analysis Make this analysis as detailed as possible. The CAB meeting must comprise of both product and technical owner to make the correct assessment.

This is good advice. I would add that it's important to *respond* to all requests, no matter how low they may be prioritized. Explain why these requests were not highly prioritized. People deserve a response, and you want to help them understand the larger goals so they'll keep the ideas coming.

Prioritize and Analyse Requests: - Establish evaluation criteria: Define clear criteria for prioritizing requests based on factors like business impact, alignment with strategic goals, and technical feasibility. - Conduct thorough analysis: Involve relevant stakeholders like IT, finance, and business process owners in evaluating each request for its impact, feasibility, and potential risks. - Communicate decisions clearly: Inform users of the decision regarding their request, providing clear explanations and timelines for implementation or rejection.

Considero oportuno apa?arse siempre en el plan original, surgido del relevamiento y diagnóstico fidedigno de la situación Empresa, que llevo a la compra e implementación del ERP. La redacción de procesos y gestión hace al bastidor del sistema y los resultados que de este se esperan. El usuario va a querer darle su impronta, siempre, su personalizado. Muchas veces cosmética, otras realmente implican una mejora y reducción de tiempos de procesos. Atados al plan original, una vez implementado y funcionando, pasamos a la parte de customizado para cada puesto o eslabón. El usuario es una persona, las organizaciones están hechas de y por seres humanos, individuos de una especie, con sus limitaciones y particularidades. Priorizar "que" no "quien".

1. Vendor Roadmap: Align customization requests with the vendor's long-term roadmap to ensure compatibility and support. 2. ISV Bolt-Ons: Explore third-party solutions or bolt-ons that can meet specific needs without heavy customization. 3. Prior Integrator Work: Leverage existing customizations your systems integrator has developed for similar clients to reduce costs and time. 4. User Groups: Engage user groups to gather feedback and prioritize customization requests based on actual user needs. 5. Cost Analysis: Evaluate the cost of customization versus potential benefits, ensuring it aligns with your budget. 6. Business Process Workarounds: Explore alternative business process improvements that may mitigate the need for customization.

First of all, ERP customization is not recommended. In case you have to, then bring the business process owners in front to explain the need and requirement. Assess to find some solution out of ERP customization to fix the need else try to keep it minimise.

The most important consideration to make is that all parties are on the very same page. Understanding the requests is one step, but then it must be double checked to make sure that all parties involved are aligned and agreed on what is on the paper. It is important to avoid any bias related to over confidence and/or attemps to speed up due to short time left for this activity. It is better to spend more time here, than later during or even after the development.

Implement Change Management: - Develop a comprehensive change management plan: Identify potential risks associated with each customization and outline clear procedures for testing, rollout, communication, and training users on the changes. - Involve users in testing and rollout: Give users opportunities to test and provide feedback on customizations before fully implementing them, ensuring they meet their needs and expectations. - Communicate changes effectively: Inform all affected users about upcoming changes well in advance, providing clear instructions and training materials to ensure a smooth transition.

ERP roll out means all other selection process has been followed, thus no need to repeat study, etc. It is now a pure change over. Don't see stress on change management which is most important aspect in rolling out ERP in any organisation. Customisation should be kept to minimum else it is difficult to come out of the vicious circle that traps ERP - more you customise more the change requests. It is, in that case, better to go for development of rather new dedicated ERP for the client. Education and perfect training for users is an absolute necessity for total change over to new environment. No compromises.

Industry and sector best practises are the norm to follow as well as vendor support for business specific change request though it should be kept to minimum ; Change request for customisation should follow rigorous design, test and validation cycle to ensure smooth integration with the base system

Utilize Configuration Options: - Maximize out-of-the-box features: Encourage users to explore and utilize the existing configuration options within the ERP system before requesting customizations. This can often fulfil their needs without incurring additional development costs. - Promote standard configurations: Define standard configurations for common processes or workflows to minimize the need for individual customizations. - Leverage user-customizable fields: Utilize built-in features like custom fields and reports, allowing users to tailor specific aspects of the system to their needs.

Apart from other feasibility checks at functional level, there should be a technical analysis as well to find a workaround or alternate method within the current framework as native procedures are always ahead of customizations as they already contains the security, adaptability and robustness of the native environment and saves the development resources, time and error probability. So, it is a quite tangible that the requirements are completed without any customizations at all.

I've checked most of the contributions, and I concur with the majority of them. Additionally, here are my thoughts on the matter. Recognizing the request Conducting an impact analysis Engaging in discussions with all stakeholders Categorizing, prioritizing, and planning the roadmap Packaging with other changes or addressing them individually.

Utilize Technology and Tools: - Implement a customization management platform: Consider using specialized software to manage customization requests, track changes, and automate approval workflows. - Leverage low-code/no-code development tools: Explore tools that allow non-programmers to create simple customizations without requiring deep technical expertise. - Monitor system performance: Continuously monitor the system for any negative impacts or unintended consequences arising from customizations.