The ERP selection stage is a perilously important stage of software implementation that needs input from every single team in your office, not just the C-suite. Before you sign on to any new system, make sure your IT and development team have the answers to these key questions. They’ll be the ones responsible for the true fundamentals customizations and coding of your ERP system, so they need to be comfortable with the answers. 

What system is the ERP built on?

Learning which system and language your new ERP will speak in will be a huge part of your development team’s roles, so they should have some say in it. Depending on if the software is built in Linux, Microsoft, or in a specific coding language, it may take more time for your IT employees to get familiar or train new hires on the system.

What’s more, you’ll want to ask if your vendor has a standardized application on a Web browser or an application that has been developed on different systems. This will be especially important for a business that has workers that operate on different operating systems i.e. if some working on both Android and Apple devices. Will their SaaS application work on both devices, or is it based on a web browser that anyone can access from any device? 

How often do you build new versions and offerings?

Depending on your vision for your business’ future, the answer to this one may affect how you structure your plan. Will your project be impeded by constant updates, or is there a huge new version in the pipeline that will render the ERP you’re about to buy obsolete? This line of questioning won’t only be useful when it comes to building a structured ERP calendar, it will also help in giving your team options to find out which version might be best for your company. For example, if they don’t currently have a SaaS version of their ERP, find out if they will eventually plan to offer that and whether ERP in the cloud might be a better fit for your business.

What will the responsibility of upgrades look like?

Building off of our earlier question on system updates, you’ll also need to figure out whose job it is to complete updates. When updates are published, will they be automatically rolled out and filtered into your system, or will your IT team be required to download them? The answer to this question will also be significant when it comes to the power of your IT team and the current size. If the responsibility of upgrading is transferred entirely over to your office, for example, are you prepared to accept it? Those upgrades could take important time out of the IT department’s day. On the reverse side, you may prefer to have control over when and how new updates get folded into your current system, especially if you have sensitive customizations or want only certain parts of the system to update. In that respect, you’ll want to have the reins for upgrading in the hands of your team.

When was the innovative coding of your system built?

This question will have implications for the usability of your software beyond just your dev team. Is it just refreshed old code from legacy software, or it has been totally rebuilt from the ground up with each new system? Perhaps the system has a slick and innovative new user interface but they’ve just slapped that on top of old, outdated back-end functionality. You’ll want your development team to be well aware of what they are signing up for and what kind of code they will be working with. Don’t be afraid to really ask questions during any demo and pilots you may schedule with vendors–make sure your top IT employees are in all these meetings. You’ll find that with their input, you’ll have a much smoother ride during ERP implementation, and be better prepared for any of the inevitable bumps.