How do you evaluate Enterprise Software before buying?

There is also the issue of defining requirements based only on what you know. Rather than an inward focused requirements definition, why not define your overall objectives first (broad level requirements), and then begin looking at the market to see what kind of solutions might map to those objectives. We don’t know what we don’t know, and if you search the market for what you know, it becomes a self-limiting exercise.

As someone who has been on the vendor side, I've seen exhaustive lists of "micro-requirements" that ironically obscure the "macro needs" of the client. It's a classic case of missing the forest for the trees—or a "smokescreen" of words. The SMART framework, while helpful, is often applied too narrowly. You should draft an RFP the way you would sketch a vision for your company on a napkin—high-level, essential, capturing the essence. Get your stakeholders around a table—literally or metaphorically—and cut through the noise. Define not just what you want the software to do but what you want your organization to become as a result of using it. That's where true innovation and alignment happen.

As Lewis Carroll wrote in Alice in Wonderland, "If you don't know where you're going, any road will get you there." That can not merely be costly in selecting enterprise software solutions, it can be catastrophic. The very first thing a company should do is document there high-level business requirements, utilizing a cross-functional team. Selecting enterprise software is not merely a financial or IT decision. Each key business area needs to be involved. Then you can start analyzing various solutions as to how well they match your requirements.

You would define the criteria for your use case to implement the software and assign weightage to each criterion. Come up with metrics for weightage and describe them in RFI or RFQ. Let the vendors respond with their answers to your queries. Finally, assess how each vendor scores on each criterion and what the total score is. You may invite them to demonstrate their software and ask for past case studies to ensure the data and objective analysis do not deviate from the original goal.

I agree, but the requirements definition may restrict to a short term goal. Your ERP is expected to support your IT and Business vision and roadmap. Knowing your industry trends, business dynamics and user aspirations would help in ‘sizing’ your ERP expectation.

Analyze not just the product but the people and company behind it. We often forget that enterprise software isn't a one-off purchase; it's a long-term partnership. Reviews, ratings, and recommendations are helpful, but they're just the tip of the iceberg. As a manager, leverage your internal experts. If they are raising red flags or voicing dissent, seize that as an invaluable moment of pause. Could you challenge your team to explain their reservations? Is it about the company's financial stability, long-term vision, or perhaps its cultural fit with your organization? This added layer of scrutiny can mean the difference between a costly mistake and a beneficial, long-lasting partnership.

After establishing your requirements, it's essential to thoroughly research the market. Identify potential software vendors and products that align with your needs. Utilize online resources such as reviews, ratings, and case studies to evaluate the reputation and quality of different solutions. Gathering insights from peers, industry experts, or consultants with enterprise software experience can further inform your decision, ensuring you select a software solution that truly resonates with your business needs.

When researching, look at the top 3 solutions present in your industry. Do in-depth research on the service model they provide: support, how new features are included in the product, how they onboard and provision new customers, maintenance processes, your rights and responsibilities, etc. The successful implementation will also depend on how the vendor deals with these topics. Another important aspect is the skills available on the market for that solution, and how easy it will be to train or attract new talent with the right skills to support and maintain the solution from your side.

Many business units have the ability to purchase software in today's world. However, before they conduct market research to find the best software for their needs, they need to ensure that there is no existing tool in their current application portfolio that can meet their business requirements. This is especially important for larger multinational companies that want to avoid duplication and inefficiency in their software investments. Therefore, a thorough analysis of the current application portfolio is a critical step before starting to do market research.

Ask for short demo videos to see how the software looks. These short videos are an excellent way to get yourself up to date on the newest possibilities and to (re)define your requirements. Vendors might push you first into discovery calls to get a better understanding. If they do, have a few calls. They will need this to show the proper demo. Avoid 1-hour overview demos. You’ll get confused after 10 minutes. Provide clear directions on your objective of the demo.

While requesting for a demo / trial is great, its critical that the actual user group define the demo requirements and parameters, so that they are able to understand the abilities of the solution. Many times, on paper and in a flashy demo, a question is posed and the results shown - what's missed out is 'how' the result is derived. It may work in the total opposite of your operations.

Before you organise demos ensure that you know your requirements and the problems they need to solve. Share this information with vendors and give the time to prepare a tailored demo for you. If you don't invest time to do this, you will have to sit through endless overview demos which will only confuse you. And you won’t be able to compare apples with apples. It's in mutual interest to talk about your situation and your needs before you organise a demo.

To effectively assess enterprise software, firsthand experience is invaluable. Request a demo or trial from potential vendors to thoroughly explore the software’s features, functionalities, and user interface. This hands-on approach allows you to assess how well the software aligns with your specific use cases and scenarios. Ensure to inquire about the software’s integration capabilities with your existing systems and processes. This step is crucial in making an informed decision, ensuring the software not only meets but enhances your business operations.

Demos are both enlightening and potentially deceptive. Demos are like movie trailers; they show the best scenes but may only represent part of the experience. While taking a software demo at face value is tempting, doing so can be a critical misstep. Instead of vendors dictating what you see, you can come prepared with scenarios you want to walk through based on your most pressing or unique requirements. A customized demo speaks volumes more than a standard one, and with cloud technology, there's seldom a good excuse for vendors not to accommodate this request. And let's not overlook the notion of a POC reality check, especially when integration with your existing toolset is crucial.

Be very wary if they are hesitant to giving you access to a fully functioning trial. That either means their devops isn’t good or the product is difficult to administer. Take advantage of their pre sales consultants to help you configure the trial to match your requirements. They don’t get paid until you purchase so they will be highly motivated.

The best ROI calculations should be so straightforward that they can fit on a napkin. While cost-benefit analyses and ROI calculators have their place, they can sometimes spiral into overly complex models that leave you more confused than convinced. ROI is not just about an Excel formula; it's a story. So, start with active costs like licenses, maintenance, and renewals versus visible returns. Are you freeing up human resources for higher-value tasks because of this software? Capture that! Then consider 'intangible' ROIs like improved customer satisfaction or employee morale. They're essential but notoriously hard to quantify. An excellent book is "How to Measure Anything: Finding the Value of "Intangibles" in Business."

It is important to make a Total Cost of Ownership (TCO) analysis since a project involves not only the implementation phases but also the start-up and the costs of future upgrades. It is also important to consider the cost of integration with other platforms. Today, with the use of AI, more and more systems will have to be highly connected in order to be able to analyze data, which is why it is necessary to consider enterprise software from a 360-degree point of view.

Changing software is a change of direction or change of business model. The change of business model is the driving business case not the specific software. Yes the software supports the improvement, the roi, the saving but it's the people process and technology that produces the business benefit not the software. itself.

Proof points should be number of references that are of a similar size and scale of company as yours . Don't be an early adopter unless your happy for more cost/ time and outages.

In choosing enterprise software, examining both costs and benefits is vital. Don't just focus on the initial cost. Include ongoing expenses like maintenance, support, and training in your evaluation. Also, consider the benefits such as increased efficiency, security, and customer satisfaction. Utilize tools for cost-benefit analysis or ROI calculations to make an informed, balanced decision. This approach will help ensure your investment effectively supports your business goals.

I would say that vetting the vendor's credibility isn't something you should do last—it should kick off your entire selection process. Bringing in consultants to evaluate vendors might seem like a good idea, but let's not overlook your organization's Subject Matter Experts. They're the ones who will live with your choice, so their early and engaged involvement can provide practical, real-world insights no external consultant can offer. Industry references are also a significant validation but are not the be-all and end-all. This isn't necessarily a red flag if a vendor is relatively new in your specific sector or region. Being one of their early adopters could indeed present exciting professional opportunities.

It is important to know with whom we are doing business, not only with the software brand but with the business partner that will implement the enterprise software. The great success or frustration depends a lot on the experience of the business partner; working with the brand and the partner will lead you to have support and peace of mind for the project to succeed.

Short list the best vendors in the space you are evaluating at the start, and only evaluate in depth the ones you seriously are considering. There is no harm in kicking tires, as there is nothing better than getting a vendor on the phone and talking to them and their customers.

Visit their customers to ascertain the support like upgrades, big fix and user clarification. If you opt for a cloud model, it further important to know their cloud partners, their infra and service levels

It's crucial to confirm a software vendor's credibility and commitment to support before making a purchase decision. Investigate their history, achievements, certifications, and customer feedback. Ensure they possess the necessary expertise and resources to deliver a high-quality and dependable product. Inquire about their support policies, service level agreements, warranties, and guarantees to ascertain their readiness to assist promptly and effectively should any concerns or queries arise. Your vendor’s reliability is essential for the long-term success of your enterprise software investment.

There are 2 reasons to organise demo meetings. 1. you want to know what’s in the market to define your requirements better. 2. to see proof that vendors can meet your specific requirements. When organising demos, communicate upfront your objective of the demo to get the most out of them.

Something not to leave out is 'Organizational Change Management (OCM)' - a fancy way of saying "who and how are we going to drive the change to this new enterprise software?". This has to be put into place even before committing to the final solution in mind. Many projects struggle and end up in a heated discussion when milestones are delayed or results are not as per expectations. Involve key users, ensure they understand the benefits of the solution being deployed, and get realistic timelines for tasks - aligned with the vendor capability & capacity. OCM will force you to ask the difficult question, even if there's 50 fancy features in the enterprise software, are we able to turn on all of them at once and make use of it reliably?

Often, the solution, technology, and product the technology company offers are good and meet customers' functional needs. Yet things go haywire during the implementation either due to non-availability of critical resources, the inability of vendors to scale, or the absence of reliable service integrator partners for specific technology vendors in some geographies. So ensure you don’t hit a roadblock later, and verify what kind of resources you would need during implementation. Do you have in-house resources, or can you train them and absorb the learning curve without affecting timelines? Can you hire a service integrator or avail professional services from the vendor? Which option is more cost effective and sustainble in long term.

This is a good chance to not only compare the different tools available in the market but also to assess the current practices in the market. Find out if there are any gaps or areas for improvement in the business process that can guide you in choosing the right tool. Sometimes, we end up letting the tool dictate the business process, or we have to spend extra money to customize the tool to suit the business process. It is likely that either the tool or the process will require some adjustments during the implementation stage. It is better to review the process early on to have a clear idea of both the tool selection and the cost of acquisition and implementation.

Always keep People in mind, supporting the Cultural & Human Change Management process behind the Digital Transformation stream: involve end-user from day-zero to analyze your current and "tribal" process, and support the evolution of their careers and skills. No matter how much we can automate a Process, there will always be People using the Technology.