July 10, 2025 
13 min to read 1. Business Fit
The functional fit between your organization and the ERP software is the most crucial factor in your selection process.
Key considerations for business fit include:
- Current system limitations: Identify what’s outdated or inefficient in your existing processes
- Manual process automation: Determine which time-consuming tasks could be streamlined
- Reporting and visibility gaps: Assess areas where you lack real-time business intelligence
- ERP Integration: Evaluate how it will connect with your existing software ecosystem
To properly assess business fit, facilitate internal discussions with key stakeholders across departments. Create a detailed requirements document that prioritizes must-have features versus nice-to-have functionality. This document should have buy-in from IT leadership and executive teams to ensure alignment throughout the ERP selection criteria evaluation.
2. Total Cost
Understanding the complete financial picture is essential when selecting an ERP system. The total cost of ownership (TCO) extends far beyond the initial software licensing fees and includes both direct and indirect expenses.
Direct costs to consider:
- Software licensing based on user count and modules
- Implementation consulting fees
- Hardware requirements (if applicable)
- Cloud hosting and infrastructure
- Training and change management
- Ongoing maintenance and support
Return on Investment (ROI) factors:
- Cost savings through improved inventory management
- Reduced manual labor and increased efficiency
- Technology consolidation and reduced software footprint
- Enhanced customer service capabilities
- Faster financial close processes
Most modern ERP solutions operate on a Software as a Service (SaaS) model with monthly subscription pricing. However, implementation costs are typically billed hourly based on project scope and complexity. Factor in both immediate expenses and long-term value when making your ERP software selection decision.
3. Industry Experience
Industry-specific expertise can significantly impact your ERP implementation success. Some ERP solutions are optimized for particular sectors like manufacturing, distribution, or professional services, offering specialized functionality that generic systems may lack.
Evaluate industry experience in two key areas:
ERP Vendor Industry Focus:
- Does the software include industry-specific modules and features?
- How many clients in your sector use this ERP system?
- What industry-specific compliance requirements does the system address?
Implementation Partner Expertise:
- Has your consulting partner successfully implemented this ERP in your industry?
- Do they understand your sector’s unique challenges and regulations?
- Can they provide relevant references and case studies?
Choosing an ERP system with strong industry experience reduces implementation risk and ensures the solution can adapt to your sector’s specific needs and regulatory requirements.
4. Technology & Integrations
Modern ERP systems must seamlessly integrate with your existing technology stack while providing the flexibility to adapt to future needs. The technology foundation of your chosen ERP will impact everything from user adoption to system performance.
Essential technology features include:
- User-friendly interface: Intuitive design that promotes user adoption
- Integration capabilities: APIs and connectors for third-party systems
- Mobile accessibility: Support for remote and mobile workforce
- Business intelligence tools: Built-in reporting and analytics capabilities
- Data security: Robust security measures and compliance features
- System performance: Reliable uptime and fast response times
- Customization options: Ability to modify workflows and processes
Evaluate how well each ERP software option integrates with your current systems, including CRM platforms, e-commerce solutions, warehouse management systems, and specialized industry applications.
5. Implementation Planning
A successful ERP implementation requires careful planning, experienced guidance, and strong project management. The implementation approach can significantly impact your project timeline, budget, and ultimate success.
Key implementation considerations:
Project Timing:
- Is your organization ready for this level of change?
- Are there seasonal or business cycle considerations?
- Do you have adequate internal resources available?
Implementation Methodology:
- Does your partner follow a proven implementation framework?
- What project management tools and communication processes will be used?
- How will testing, training, and go-live activities be managed?
Internal Resources:
- Do you have executive sponsorship and support?
- Are key stakeholders available to participate in the project?
- What change management strategies will ensure user adoption?
Choose an implementation partner with a structured methodology, relevant experience, and a track record of successful ERP deployments in organizations similar to yours.
Why ERP implementations fail?
- Set the ERP implementation team
- Create an effective change management plan
- Communicate with diverse groups
6. Vendor Stability
The long-term viability of your ERP vendor directly impacts your investment security and future system evolution. A stable vendor ensures continued product development, support, and innovation.
Assess vendor stability through:
Product Viability:
- How long has the ERP solution been in the market?
- What does the product roadmap indicate for future development?
- How much does the vendor invest in research and development?
Market Position:
- What is the size of the vendor’s customer base?
- How does the vendor rank in industry analyst reports?
- What is the vendor’s financial stability and growth trajectory?
Selecting an ERP system from a stable, well-established vendor reduces the risk of product discontinuation and ensures ongoing support for your investment.
7. Risk
Every ERP implementation involves inherent risks, but proper planning and vendor selection can significantly mitigate potential issues. Understanding and addressing these risks upfront is crucial for project success.
Common ERP implementation risks include:
- Scope creep: Uncontrolled expansion of project requirements
- Budget overruns: Costs exceeding initial estimates
- Timeline delays: Extended implementation schedules
- User resistance: Poor adoption of the new system
- Data migration issues: Problems transferring existing data
- Integration failures: Difficulties connecting with other systems
Risk mitigation strategies:
- Thoroughly document business processes and requirements
- Plan comprehensive change management and training programs
- Establish clear project governance and communication protocols
- Conduct thorough testing before go-live
- Maintain realistic timelines and budgets with contingency planning
Working with experienced implementation partners and following proven methodologies significantly reduces these risks.
8. Scalability
Your ERP system should support not just your current needs but also your future growth and evolution. Scalability ensures your technology investment continues to deliver value as your organization expands.
Scalability considerations include:
Growth Capacity:
- Can the system handle increased transaction volumes?
- How easily can you add new users and locations?
- What are the licensing implications of business expansion?
Functional Expansion:
- Can you add new modules and capabilities over time?
- How does the system support new business lines or markets?
- What customization options are available for evolving needs?
Technology Evolution:
- How does the vendor handle system updates and new features?
- What is the upgrade path for future versions?
- How well does the system integrate with emerging technologies?
Choose an ERP system that can grow with your organization and adapt to changing business requirements without requiring a complete system replacement.
9. References
Speaking with existing customers provides invaluable insights into the real-world performance of both the ERP software and implementation partner. References offer honest perspectives on system capabilities, implementation experiences, and ongoing support quality.
When requesting references, ask for:
- Companies in your industry with similar business models
- Organizations of comparable size and complexity
- Recent implementations using current software versions
- Clients who have been live for at least one year
Key questions for references:
- How well did the system meet your original requirements?
- What challenges did you encounter during implementation?
- How responsive is ongoing vendor support?
- Would you choose the same ERP system again?
- What advice would you give to organizations considering this solution?
Quality references demonstrate the vendor’s confidence in their solution and provide realistic expectations for your own implementation experience.
10. Ongoing Support
Post-implementation support is crucial for maximizing your ERP investment and ensuring long-term success. The quality of ongoing support can significantly impact system performance, user satisfaction, and return on investment.
Related articles
:
It feels like every month, there’s a new story about a company dealing with major ERP failure and implementation problems. The latest edition comes from candy maker Haribo, who had troubles getting their famous gummy bears out to suppliers in late 2018 because of problems stemming from their latest ERP integration. Haribo expected to have a few issues during implementation. But, by their own admission, the supply chain issues they faced after deployment were much larger than anticipated. For Haribo, the problems eventually sorted themselves out. But other companies haven’t been so fortunate. Let’s take a look at a few other examples of failed ERP implementations and the key causes of their failure: Woolworths Australia, 2015 After 6 years of planning, Woolworths Australia (or “Woolies”) went live with their new ERP in 2015. They had problems almost immediately, the biggest of which was empty shelves in many stores. What caused the problem? A glitch in the new system prevented Woolworths from placing orders with their suppliers. Suppliers were frustrated and furious… and Woolworths lost millions of dollars in sales. But that wasn’t the only problem with the new ERP system. From the Australian Financial Review (AFR): One of the key problems and failings that occurred at Woolies during the SAP implementation process was the lack of attention given to documenting processes used by staff in the day-to-day running of the business. Too much of the intellectual property of what was then the best-performing supermarket group in Australia was left in the heads of people who worked at Woolies. This carried lots of risks because when people left they took with them key pieces of information. Loss of corporate memory is often referred to as a key risk in companies but it is only when something as critical as a new merchandising system is jeopardised that senior management learn its importance. What can we learn from this? Companies need to map all their business processes prior to ERP implementation. This practical information is essential when designing the new ERP system. Every company should have a plan for employee knowledge transfer so that information doesn’t disappear when an employee leaves the company. Above all: test everything before you go live with a new ERP system. Oriola Finland, 2017 Almost every ERP implementation will have a few hiccups when the new system goes live. But what do you do when a small hiccup in the supply chain can mean the difference between life and death? This was the problem Oriola Finland was facing in September 2017, when they launched their new ERP. Oriola is one of Finland’s largest pharmaceutical suppliers. They deliver thousands of medications to pharmacists around the country, including insulin, cancer medications and anti-psychotics. Any disruption to the supply chain doesn’t just cause lost sales: it can cause great damage to people’s health. It sounds like Oriola didn’t anticipate any supply chain disruption as they switched over to their new ERP. But in reality, their ordering system was shut down for days. This led to widespread confusion and frustration as pharmacists all over […]
The OData programming model enables extensive product integration and improved data exchange performance. When building OData in an IFS Cloud environment, users can accelerate the entire innovative approach to optimize performance. But OData might be not the only alternative for IFS Cloud. In our previous article, we discussed several cases of how to replicate database transactions in OData. Now we will focus on finding an alternative to OData in IFS Cloud. Novacura has been exploring the topic of OData for years and, as an experienced partner of IFS, has gained practical knowledge on how to create specific solutions for IFS Cloud. With the deep understanding of our experts, we are sharing our knowledge to increase awareness and confidence among our customers. Novacura had the opportunity to speak with our expert Albin Lundberg, Novacura Manager Flow Solution and IFS Certified Practitioner – Supply Chain Consultant (IFS Cloud) – 2022. In this article we will generally present some cases that can be seen as an alternative to OData in IFS Cloud. Is IFS Cloud is still based on its previous functional resources? In a sense, yes. The Oracle database is still there underneath the FndODataProvider. So, the logical units, views and packages are still there, but in IFS Cloud, the business logic is instead accessed via the OData API. IFS Aurena Architecture – The most important key components. Does the PL/SQL API that refers to the .NET access Provider still exist in IFS Cloud? No. Referring to the data shared on the official IFS Community forum, it is possible to write new reporting plug-ins to meet the needs of third-party system providers, and IFS also provides some standard options for customers. How can third-party systems continue to access the IFS Cloud and avoid the problems that can arise from the lack of functionality of the OData APIs? The .NET Access Provider connectors won’t work in the IFS cloud; they are deprecated. There are still options to use IFS connect, External File Interface, and Data Migration. The legacy integration options are most commonly used for “system of records” related data such as invoices, payment files, etc. Other than that, external BI tools, that have complex queries and handles large datasets, can fetch data directly from the database or via Information Sources in IFS. But that topic needs its own blog post. Can official IFS Partners, such as Novacura, access APIs by implementing IFS customizations? Yes, it is possible to expose any package or view via customization and custom OData protections. In custom utility packages, you can write your own PL/SQL packages and expose them via OData. However, you need to have the proper skills and certifications to develop and deploy customizations. When IFS Cloud is installed on-premises in the customer’s data center, the company can access all the objects also available as PL/SQL API. Is there any risk in using them? In IFS cloud the end users doesn’t have Oracle accounts, they are maintained in the IFS IAM (Identity and Access Manager). It’s possible to configure a direct […]
What is a Low-Code Platform? A low-code platform is a software tool that lets you create applications with minimal coding. Instead of writing complex code, users can use simple drag-and-drop features, visual interfaces, and pre-built templates to build apps quickly. Low-code platforms are great for businesses because they allow people without advanced programming skills to create, modify, or improve software. This makes it faster and easier to develop solutions that fit specific needs while saving time and reducing costs. Challenges Related to ERP Systems At Novacura, we have over 15 years of experience in implementing and enhancing various ERP systems, leveraging our low-code integration platform. Throughout our work, we’ve noticed that regardless of the ERP system a company utilizes, there are common challenges that many organizations encounter. In this article, we summarize the key challenges related to ERP systems that our customers often face. Complexity for Users ERP systems are advanced and encompass numerous modules that provide hundreds of capabilities. However, they also introduce a degree of complexity, which can present challenges with ERP implementation. The wide range of available functions gives users flexibility but does not guide them in following the correct path to accomplish their tasks. As a result, seemingly simple tasks (such as creating a new customer in the system) may require several additional steps to be completed by the user before they can finalize the task. Users must be aware of these additional steps; otherwise, they will be unable to complete their work successfully. Limited Integration Capabilities Complexity is not the only drawback of ERP solutions. These platforms are primarily designed to serve as central points within the IT landscape. Other applications need to integrate with ERP solutions to communicate effectively. However, ERP systems typically do not provide ready-to-use connectors for third-party software. Instead, they offer APIs, leaving the integration to the other applications. As a result, connecting an ERP solution with a new third-party tool is not straightforward; customers cannot simply select a connector from the ERP marketplace, establish a connection, and start using it. Limited Customization Another issue with ERP systems is that they are designed for multiple companies across different industries within the same version. Although they offer a wide range of configuration parameters, they cannot be perfectly tailored to the specific needs of each organization. This creates a gap between the actual processes within a company and the fragmented processes supported by the ERP system. As a result, employees often resort to workarounds and begin operating outside the ERP by using Excel sheets, emails, and paper documents. Expensive Modifications To address the issue of relatively limited customizations, ERP vendors allow customers to create modifications to the software. However, these modifications often lead to complications and contribute to ERP implementation challenges. Since they are not separate from the ERP core, the entire architecture becomes more complex, making it difficult to identify and track all modifications. This is especially crucial during upgrades, as all altered components of the previous ERP version must be identified, documented, and typically rewritten in the new version. Mobility Modern ERP solutions, such […]
WHAT IS THE MOSCOW METHOD (MoSCoW Prioritization)? The MoSCoW method is a technique that helps categorize and prioritize all requirements that define a “future state”, that should be implemented. The method was developed by Dai Clegg in 1994, and dedicated to supporting software development projects (where the “future state” is the shape of an application that should be implemented). Despite the origin, the method is not only limited to software projects, and can include requirements necessary when implementing changes to physical products (cars, buildings, furniture) or organizational changes (eg. changes to the bonus systems, changes to the partnership agreement, etc.). Although this is a generic method, it is mainly used when implementing software systems and helps companies define the requested configuration of a future application that is planned to be implemented. The MoSCoW name explained The MoSCoW term is an acronym inherited from the statuses used in this method to prioritize requirements: Must have, Should have, Could have and Won’t have. Priorities used in the MoSCoW methodology The priorities used in the MoSCoW method sound self-descriptive, but in practice, they need some additional explanation to use them properly and in a consistent way: Must Have (MUST) – This is the most obvious priority that represents the critical requirements that must be delivered from day one. The software without these requirements simply can’t be used properly and the project goals will not be achieved without them. Should Have (SHOULD) – This priority represents the requirements that are almost as important as “Must haves”, but users can live without them. Although it sounds similar to “Could have”, they are closer to “Must haves”. The difference is, that while “Must haves” have to be implemented from day one (software can’t exist without it), software users can live without “Should haves” for some time. The “Should haves” have to be ultimately implemented, but the company can live without it and still benefit from the 1st version of the software solution; these missing requirements will not cause critical security problems or will not bring a lot of additional work – if that happens, it means that they should be classified as “Must haves”. The “Should have” priority is often used to divide a complex project scope into phases, where only “Must haves” are implemented in the current phase, and “Should haves” are planned for the next phases. Sometimes, companies use “Should have” to address the “readiness” for future requirements or improvements (e.g. currently the software is not implemented in the cloud, but it must use the technology that is ready for future cloud deployment). Could Have (COULD) – This is used to address all the “nice to have” features, that will have a positive impact on the final solution (and then on users’ satisfaction/efficiency), but are not necessary and might never be implemented. Their business value is smaller than “Should haves”. These requirements are useful when comparing software from various software vendors – assuming, that all “Must have” and “Should have” requirements must be identically fulfilled by […]
Legacy systems implemented in old technologies can cause serious problems when integrating with cloud systems. In this chapter, we discuss the obstacles that might appear in the context of legacy systems when migrating to IFS Cloud and switching to OData API. To provide you with a wider perspective, we interviewed Paul Phillips, Vice President of Product Management at Novacura. What is OData API? OData (Open Data Protocol) API is a standardized protocol for building and consuming RESTful APIs, which allows applications to interact with data over the internet in a consistent and interoperable way. Developed by Microsoft and approved as an OASIS standard, OData enables the creation, reading, updating, and deletion (CRUD) of data through a uniform and predictable interface, making it especially useful for data-centric applications and services. The new IFS OData API is a revolution especially for all the legacy systems integrated with previous IFS versions (that currently use PL/SQL API). Could we start with briefly defining the areas in which the problems might appear? The problem is definitely much wider, and it is not just limited to replacing the integration logic and calling the new set of API objects and methods instead of the old ones. For the legacy systems, there might be additional technical or organizational barriers, such as: No support for OData protocol: The technology used in many legacy ERP systems doesn’t support the OData protocol, which complicates integration with legacy systems. No state-less philosophy in the legacy system Synchronous communication expectation Technical Limitations: For successful integration with legacy systems, compatibility with HTTP(s) protocols, connectivity, and security requirements must be addressed. Some legacy systems may require additional support for cloud-based operations. Organizational Challenges: Legacy system management is further complicated by limited documentation, lack of source code, and a shortage of resources knowledgeable in how to integrate legacy systems with modern platforms. These barriers are common when organizations seek to connect legacy systems to new cloud infrastructures. All the topics mentioned above sound serious, and definitely require additional clarification. Let’s focus on them all one by one. Could you start from the beginning and tell us a bit more about the lack of support for OData in the legacy system’s technology? When we think about legacy systems, we usually think about old systems built 10-20 years ago as hard-coded software programs, written in C / C++, Visual Basic or even more specific technologies (eg. when we think about specific machinery integrations). These systems were designed before the cloud computing concept has been introduced and the OData standard was defined. It might mean that there is no ready-made OData library for the technology used to implement the legacy system. All the common OData foundations (that reside below the business layer added by IFS) must then be implemented manually, which is a large additional cost of adjusting the legacy system. Keep in mind, that even if the OData support libraries exist for the language used to implement the legacy system (eg. C++), this library might be incompatible with the particular framework used to build the legacy system, […]
Most ERP users who are not already in the Cloud are likely considering migration. We’ve consulted our top experts to understand why upgrading is worth it, what the best strategies are, and how to plan the entire project. In our new series of webinars, we focus on upgrading to IFS Cloud, aiming to highlight all the pros and cons of the process. Join us and embark on a journey of IFS cloud upgrade! Subscribe to IFS Cloud Upgrade Webinars IS NOW THE RIGHT TIME TO UPGRADE? In the webinar series, we explore the landscape of major ERP players. The cloud has become the primary focus, with SAP, IFS, Microsoft, and others adopting cloud solutions. In this opening episode, our experts Łukasz Majer, Lars Steen and Östen Westman dive deep into the world of ERP, sharing invaluable insights on the benefits of migrating to IFS Cloud, market trends, and the compelling reasons for cloud adoption. Drawing on over 50 IFS projects, we highlight the evolution of ERP systems into the cloud era, emphasizing that it’s not just a trend but a strategic shift embraced by the industry. But the journey to the cloud isn’t a one-size-fits-all narrative. We learn that IFS entered the cloud realm in 2021, a strategic move occurring five years after some of its competitors. However, this timing offers IFS a unique advantage – the ability to learn from early adopters and fine-tune their approach. As the conversation deepens, our experts address the origins of the cloud revolution, acknowledging pioneers like Salesforce and NetSuite, and elaborat on why ERP systems, despite being more complex, have been latecomers to the cloud journey. So, if you’re contemplating an ERP cloud upgrade or just keen on understanding the dynamics of this transformative shift, join us in this series as we navigate the cloud landscape! It’s not just about technology; it’s about a strategic move that could reshape the way your business operates in the digital era. IFS CLOUD UPGRADE UPCOMING WEBINARS Novacura is thrilled to present a series of five insightful webinars designed for clients interested in an IFS Cloud upgrade project. The series will consist of 5 webinars, where our experts are going to take you through the entire upgrade process. You will learn: Why is it worth upgrading?… What are the possible upgrade strategies? What are observed challenges and proposed solutions? (Technical) What are observed challenges and proposed solutions? (Organizational) How to plan the IFS Upgrade project? Join us for the webinar series! Don’t miss this unique opportunity to enhance your understanding of the IFS Cloud upgrade process. REGISTER TODAY AND GAIN ACCESS TO ALL EPISODES OF THE IFS CLOUD UPGRADE SERIES
