News Stay informed about the latest enterprise technology news and product updates.

Midmarket ERP software selection best practices

In this podcast transcript, discover expert advice for selecting ERP software for midmarket manufacturers.

The following interview on the subject of midmarket ERP software evaluation took place between Jim Shepherd, senior vice president of research for AMR Research, and Hannah Smalltree, editorial director of

Jim Shepherd brings more than 30 years of manufacturing, operations and software industry experience to his role as senior vice president of research for AMR Research. His coverage area includes ERP systems, supply chain management, and the governance of global IT operations. Jim also leads AMR Research's team of analysts covering enterprise applications. Jim helped to develop AMR Research's coverage of ERP and was the first analyst named as an AMR Research Fellow. It seems like we're hearing more and more about midmarket companies investing in ERP. Is that what you're seeing at AMR and do these midmarket companies have a lot of ERP choices these days?

How to evaluate and buy small to mid-size ERP platforms
Find tips on selecting ERP software with a lack of IT resources

Learn how to avoid common ERP software selection mistakes

Shepherd: Yes, we're definitely seeing an increase in the number of midmarket companies looking at ERP, I think in part because they are finding it to be a competitive necessity. They can't really compete in the global market without a modern business system, and ERP systems have kind of moved down market to be appropriate for smaller companies. In terms of choices, they have probably more choices than they would like. There are a lot of different packages available for and targeted at midmarket manufacturing companies. So with all these packages, how do you recommend companies begin to narrow down all of these options? Should they write an RFP? How should they navigate this market?

Shepherd: It used to be that the RFP was the standard way to go about doing this. People would draw up a long list of requirements and send it up to a long list of vendors and get them to respond. We don't think that's a very effective method anymore, since the vendors tend to say yes to all of the questions anyway. We think companies are better off coming up with a short list of what are the key issues and concerns that they have with their current software, the things they can't do or believe they'll need to do in the future and the things they think are unique about their business that any new piece of software would need to address. Then go to a list of four or five or six vendors and essentially challenge those vendors to propose a solution that covers the needs of a midmarket manufacturer in their industry and addresses the key concerns they have. Now once an organization has narrowed their list down to a few vendors, what should they do next? Perhaps an even shorter list than they're dealing with now?

Shepherd: Right, and that typically is what happens. They get down to two or three that they're interested in, and then there's a series of things. They certainly start looking for references. The vendors themselves will provide references and they're worth talking to, but you also want to try to find some references, some companies that are using the software that the vendor didn't give you to try to find out some things that perhaps the vendor didn't want you to know. So there's the reference checking activity, and then there's a set of presentations/demos that I think are very important. So you bring together the group of people who are going to make the decision or participate in the recommendation, and then you invite the vendors in, the shortlist of vendors, to present their solution. It's typically a combination of PowerPoint and demonstration to show the audience what they would do, how their software works, give you a sense of how well they understood the requirements, how well they now your industry. That's a key part of this selection process. Before we get into more of the things that people should do, what are some of the most common mistakes that you see organizations make in the ERP software evaluation process, and what are the consequences of those kinds of mistakes?

Shepherd: Well, I think one is that they decide they're going to make this a democratic process, and so they get dozens and dozens of people involved in the evaluation and selection. What happens then is that instead of arriving at a consensus, you tend to set up a series of armed camps. So you find that the people in finance like the product from vendor A, the people in manufacturing think they can only use the product from vendor B, the people in procurement really like product C, and so you tend to move further and further away from any kind of consensus and solution. So they're much better with a small, targeted group of people who are capable of coming to a consensus.

Another is that companies decide that they don't want the vendors talking to their employees, so they keep them completely at an arm's length, never allow them to come in and fully understand the business. That interaction that goes on when the vendor is in sort of a discovery phase so they can make their proposal is part of how you learn about the vendors and how well they understand your industry and are they the kinds of people that you believe you could work with. Is there a cultural compatibility? Because as you're picking software, you're also picking a vendor to have a long term relationship with, so you actually want to encourage as much interaction as possible. So what are your top tips and best practices for the ERP software selection process? What will really reveal if the system will work as promised on those PowerPoint presentations, whether it will actually work for the organizations?

Shepherd: I think the important thing is to recognize that ERP has been out there and these ERP systems have been out there for 15 or 20 years. They are very mature and they've been deployed and implemented by tens of thousands of companies. Don't spend a lot of time focusing on standard functionality around accounting or purchasing or inventory control that you ought to be able to assume that any reasonable system can handle. Focus instead on those processes that you believe are differentiating for your business or unique to your business or specific to your industry. Those are the ones that you want the vendors to take you through a sort of "day in the life of" demonstration, so they can show you the way that they would solve that problem in their business. You're not asking them to do it the way you do it today; you're simply laying out what the capability is that you believe the company needs and challenging to show you the way it would work using their software. I think that's the most effective method that people could come up with, because realistically, there's no way to really check all the functionality in an ERP system; it's just too complex and too comprehensive. To expand on that point a bit, we have an audience of manufacturing professionals, so how important is pre-existing or pre-built industry specific functionality in these decisions?

Shepherd: Very important these days. It used to be that software vendors thought of manufacturing as a vertical industry, instead of understanding that there are a lot of different kinds of manufacturing. There's chemical manufacturing, pharmaceutical manufacturing, electronics manufacturing, heavy equipment manufacturing… There should be an expectation that the vendor has functionality for your particular type of manufacturing, the style of manufacturing you do and the industry segments you serve, and that they have references and development plans and specific packaged functionality and implementation templates that address the industry you're in. If they don't, you really should be looking somewhere else. It used to be that vendors had generic products and different brochures for different industries, but these days they really should have pretty deep industry functionality. I know these applications are usually not by themselves in an organization. How can you evaluate how well ERP software will integrate with your other enterprise applications?

Shepherd: There's no way to really evaluate that. What you can evaluate is the capability of the vendor's integration tool set. In other words, what tools do they have for passing transactions and passing data between your system and their system and other third-party applications, whether they're third-party applications that you were on or have built, or third-party applications that your customers or vendors run. They all have standard integration capabilities. You need to look at the extent to which they have standard connectors to well-known packages, the extent to which those support the technologies that you're concerned about -- so are they Microsoft-compatible, Oracle-compatible, IBM-compatible, etc. I think those are the things that companies need to look at. Having worked at a few midmarket organizations myself, it seems like the only constant is change, and if things are going well, rapid growth along with all that change. So how can midmarket organizations be sure the system they buy today will be flexible and will scale appropriately to their needs?

Shepherd: I think part of that is picking a vendor that has the kind of range and viability you're looking for -- in other words, a vendor that is financially healthy and is going to be around and has the resources to continue to invest in product development. Also pick a vendor that serves a broad enough range of companies so that you can say, "All right, I'm a $100 million company; I think in five years I may be a $500 million company. I want to know that I'm buying a piece of software that other $500 million companies are running successfully." You don't want to take it on faith that the vendor may grow the product eventually to be able to serve the needs of larger businesses; you need to see that the product is being used in those businesses. Any final best practices or advice or tips for those tasked with managing one of these midmarket ERP software evaluation projects?

Shepherd: I think the important thing is to make it a formal project. What we see in a lot of cases is that software evaluation is one of those sorts of amorphous activities that can on for a long time. There are a lot of people who are involved in it, but too often there's no formal project plan with timeline and deliverables and a clear charter and mandate for management. You can waste a huge amount of time and money and also cause a lot of confusion and dissatisfaction internally. What we like to see people do is to lay out a specific project for the evaluation that says, "We're going to take five months, here are the people who are on the project team, here's the project leader, here are the milestones and deliverables, here's the steering committee that we're going to report to, and here's the deliverable at the end." They get through it in an effective way, so that there's somebody that has oversight and they know exactly what it is they're trying to accomplish.

Dig Deeper on Small business ERP

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.