How do you set the scope of your ERP implementation?

The assessment of situation should not be limited to the current needs, rather should have a strategic outlook of the future business needs. Assess the new ERP capabilities and compatibility for the near future technology developments, ease of handling the business growth, reporting and compliance to regulations, etc.

ERP Implementation experience as per my knowledge is: 1.An Organization must decide as really they need an ERP whether standard , customize or open source for business processes. 2.Utmost important thought process of the client must be that later on an ERP must not be a bone entangled in throat once matter comes of product cost calculation. 3.Management must be made fully IT conversant before commencement of implementation. Otherwise employees(users / end users) will pay a pivotal role in Projet failure.

After completing many ERP projects, I have learned that most people need help quantifying a project. Why are we doing this and what is expected? Professionals drop the jargon and expect everyone to understand our questions. This typically gets blank expressions. The most critical and overlooked assessment of a current situation is, What is a successful outcome? Suddenly the idea clicks and the blank stares go away. This could be as simple as we need to save $250k annually in operating costs. Now peel back the onion of the "current situation" why are we not able to do that today? How can we get there? Bingo that is the current situation. Next prioritize the most essential layers of that onion and focus.

ERP implementation planning should consider 1. current state of processes, requirements and basic objetive / need of ERP 2. Organisation goal and vision for next 5 to 10 years. 3. Apetite to spend on ERP and ease of adoption of emerging technologies and automation Futuristic approach will help in decision making or selecting perfect ERP for your organisation

You should consider several key factors. 1. Define the project objectives by identifying the goals and objectives. 2. Evaluate your organization's current state and identify the areas where ERP can bring the most value. 3. Engage stakeholders from different departments and levels. 4.Document the specific functionalities and features needed to meet the identified objectives. 5. Consider scalability and future growth when defining the scope. 6. Clearly define what is within the scope and what is not. 7.Determine the project timeline and allocate resources, including budget and personnel 8. Prioritize implementation phases breaking it down into manageable phases. 9. Document scope changes. 10. Regularly review and communicate scope:

Start by clearly defining the objectives and goals of your ERP implementation project. What do you hope to achieve? Are you looking to streamline operations, improve efficiency, or enhance customer experience? Clearly articulating your project objectives will help guide the rest of the implementation process

When setting the goals and getting requirements, it is key not to add other requirements outside the scope of any ERP. For example, do not include functionalities that should be in a CRM. Be ambitious after assesing the current situation but always inside the scope of what an ERP is.

Agree Leveraging on best practices and success use cases, the new erp doesn’t have to be customized with heavy coding, but the process and the users behavior needs to adopt and adapt to them

Don't implement the old way in new software. The business value of an ERP implementation sits in identifying the functionalities that address current issues and also new potential that is an enabler for things you can't do yet. Particular attention should be given to which ERP solution is a best fit to the future business requirements whilst avoiding excess customisation and being aware that this is not only an IT project but ultimately will require changes in the organisation and processes to get the most business value out of a new ERP.

Defining requirements should consist only of what processes from the vendor's solution need to be deployed. In other words, instead of goals and requirements, efforts may be best aligned to determining solution process scope. If the ERP vendor does not offer something like SAP's "Best Practices" as a starting point, then other industry standards such as APQC can be used to define the general process scope. The primary goal with this approach is to avoid custom-coding as much as possible and stay close to the vendor standard solutions. This is where the real change and transformation comes in. Otherwise, too much focus on requirements beyond scope leads to building the same thing you are replacing.

The ERP demo is not the implementation. That said, given the time constraints, there will be topics overlooked, perception biases and unspoken assumptions on both sides of the demo. Be real. Ask questions. If you don't understand the answer, ask the question again. Make sure the solution being proposed meets your (written) requirements.

In the process of choosing the right ERP, it is wise to engage an independent consultant with a wide knowledge in the industry and able to assess the correct ERP that will cover at least 80+% of the key requirements. It will turn cheaper in the long run than getting the wrong ERP.

Another perspective of ERP software/product/vendor selection is to consider the total cost of ownership. With many ERP software offering moving towards subscription based services, it is necessary to assess what are must need, nice to have, and future enhancement offerings to own. Also, the cost of maintenance and support, availability of sustainable skilled personnel to keep the ERP system up and running.

The continued development of Enterprise and Mid Sized Company ERP Software the proliferation of SAAS Cloud Solutions that can be integrated to create a far more affordable and accelerate implementation for SMEs have created quite an array of options for businesses. That being said, the percentages are still far too high for ERP & SAAS implementations that are either not fully utilized or worse end up not being a good fit. Take time with functional experts and even more important the key users doing the work that will now be done more efficiently with the power or Tech and support these people as they lean into super user roles and empower them to determine the optimal solutions for the organization and train the team!

In our experience the ERP and other software are often on the back of solution demo / responses ahead of detailed requirements. This can lead to gaps between requirement and the capability of the product. That said, the majority of ERP solutions are pretty capable!

Scoping an ERP implementation is a critical phase that requires careful consideration. Begin by defining clear objectives, understanding the specific needs of your organization, and involving key stakeholders in the scoping process. Identify the scope boundaries by determining what modules and functionalities are essential for your business processes. Assess the scale of customization required and the integration with existing systems. Prioritize key milestones and deliverables, establish a realistic timeline, and allocate necessary resources. Lastly, continuously review and refine the scope to ensure alignment with your organization's evolving needs throughout the ERP implementation.

Once you have your requirements you can effectively cost and plan for delivery of your prioritised requirements across your business. Post discovery (requirements approval), and ahead of build (config, dev etc) you should have a clear plan of activities and effort required to deliver the solution

Develop the project plan and budget by considering each delivery with feedback from each team member.Yes we should capture the Direct and Indirect costs .Yes I set the expectations and delivery of the selected ERP

Developing a comprehensive project plan and budget is a strategic imperative for ensuring the successful execution of any initiative. The plan should encompass clear objectives, timelines, and milestones, aligned closely with the organization's overarching goals. Simultaneously, a well-structured budget should be designed to allocate resources efficiently, accounting for both initial implementation costs and ongoing maintenance expenses. By meticulously crafting this plan and budget, an organization not only establishes a roadmap for achieving its objectives but also ensures transparency and accountability throughout the project's lifecycle, ultimately contributing to its strategic success and adding innovation step future transformation.

Beware of scope expansion and creeping elegance. Most systems can be configured or customized, some without changes to code base. This may be costly; there are no silver bullets. Consider the impact of the update cadence (especially SaaS). Ensure that third-party integrations are within the written scope and not an afterthought.

This is a step that is often easily overlooked but is critical. There may have been requirements or business processes that have changed or perhaps even a new product line or acquisition. In addition, prioritization of MVP (minimal viable product) needed plus nice to haves and even post go live functionality can be settled in this step. This way all parties are on the same page and scope-creep (outside of formal change control) and confusion over priorities as well as disappointment if a feature is not included at go live can be avoided.

If you have validated and prioritised your requirements, and developed an effective project plan you should be well aware of whether the desired scope fits this plan (else your plan is not effective). However, customer can often change their mind so you need to be able to re-plan and adjust scope.

Being realistic about what can be achieved in the timescale and budget as well - nobody should feel disempowered to flag concerns. And both the client and/or implementation partner should be brave enough to recommend stopping an implementation progressing further, if it's not going to meet the business goals. Further to this - ignoring 'critical' requirements, or downgrading them, so everything fits neatly within budget and timeline, or to avoid customisation of standard ERP functionality, is risky without a good understanding of the alternatives, and without increasing investment in business change / user adoption activities to compensate.

Controlling the scope can make or break the ERP implementation. This can be handled by involving key users from each department during the BRD or FRD. Another way is to make sure out-of-the-box vanilla functions are used at optimal levels with minimum customizations.

It is not enough to just "set it and forget it" with the scope of the project. Continual review and maintenance are needed as well as trust in each area lead that they are recognizing when people are asking for "small favors" to include additional functionality and holding the line on scope. Holding to scope unless project leadership approved the additional scope and additional time or resources to accomplish it is critical in making sure the project is successful, on time and within budget.

Unfortunately the world & business do not stop during an ERP implementation and that means that some scope creep is unavoidable. With an agile mentality we can set a narrow first, quick scope for the first releases and maintain a backlog for new and changed requirements. In truth this work should never be finished as business is extremely dynamic today, but at the same time sticking to standards and keeping a clean ERP core should be a top priority. What to do with unsupported processes? Build point solutions against the ERP API's using a low-code/no-code environment. Make them safe and secure but also consider these apps disposable - what seems important today may not be tomorrow + new features get added continuously to cloud ERP.

Include the below :1. A 30% +ve variance in the scope for all ERP Implementation parameters to be planned for all implementations. 2. Time, cost and requirements to be Included in the parameters. Option to add any additional parameters. 3. Docs all the types of communications from the day 1 to sign-off via file share platforms. 4. A software application platform for the client stakeholders, implementation company mngrs as well as all the related teams should be used for ensuring better commitment and understanding at all the stages. Link the application to file sharing platform. 5.Keep the scope inclusions open at all stages and use the software application like project mgt. or etc to be accessible by client stakeholders to add/edit scope.

Scope control plays a vital role as it can impact both on cost and timelines of your go live. From a future persepctive scope creeps can impact performance of your systems. Project plan review and steer coms play a vit role in validating the current statge of a project and where are timeline slip. Clearly document and communicate both to your vendor and partner. In a cloud ERP scenario deployment and adoption play a vital role hence a tight timeline and traciking would be needed. If there are business process creeps discuss with your stakeholders to bring them to light around standard fitment, rather than building customizations. From a user persepctive there should be user leads to control scope creep every user can come with his wishlist.

ERP implementation is primarily an emotional change management exercise. ERP is only a software tool, it has menus, check boxes, data fields and functionality that can be documented and taught. Overcoming fear, uncertainty, and doubt is the key to a successful implementation. Employees will be scared of losing their jobs because of the 'new system', scared of correcting their manager during working discussions, having to do their normal job in addition to the implementation work. The company culture may be 'manage by fear'.... I've seen all of this, many times. Companies must acknowledge and address this internal emotional turmoil in an empathetic and constructive manner. This support is critical to a successful implementation.

For a business-led ERP implementation (i.e. where the business case, and driver, is coming from the customer's business - not IT) usually have a good level of business input, but often times these projects hit IT / technical teams as a 'surprise'. On these implementations, extra focus needs to be given to technical streams - Data Migration, Integrations etc. where it can often be a bit of an after-thought. Examples of giving it attention - having dedicated slides for specific tech streams in Status Reports, having dedicated content at Steering Committees, Tech team catch ups that include key business stakeholders etc.

Eine Prozessliste des Unternehmens erstellen mit Ist und Soll und Verantwortlichen. Scope der Prozesse des neuen ERP definieren. Prozesse im Standard durchspielen. Anhand der Abweichungen eine Gap Liste erstellen. Die Gaps in einem Gremium in Change Requests ansegnen wenn der Standard ver?ndert werden muss. Agil CRs umsetzen und nach jedem Sprint einen Integrationstest durchführen. Dann in den n?chsten Sprint.

ERP implementations are extensive, so consider breaking them into phases. This approach allows you to implement the most critical functionalities first and gradually expand the system.

One aspect often skipped in setting the scope of an ERP implementation is the comprehensive consideration of change management. While organizations focus on the technical intricacies of the project, they may underestimate the need for managing the profound changes the ERP system will bring to their business processes. Overlooking change management can lead to resistance, user adoption issues, and ultimately hinder the successful integration of the new system. Effective communication, training, and addressing the human side of the transformation are vital components that should not be neglected during the scope-setting process.