Software Vendor Selection: How to Clearly Define Requirements to Software Vendors

Decisions regarding selecting and deploying a new software to run a process have far reaching implications, and can even make or break the enterprise. Deploying the wrong software, or even implementing a good software the wrong way, can wreak havoc with company process and systems, put off customers, and at the very least stress out the enterprise into a perennial firefighting mode.

When selecting software vendor partners, most enterprises look primarily at the experience and skill-set of the development team, and the portfolio of completed projects. The usual questions asked to relate to testimonials, experience, costs, and training. While these aspects indeed constitute the basic due-diligence areas for selecting a competent software vendor, the devil lies in the details. Many enterprises make the mistake of conducting a superficial due-diligence, only to regret it later when a half-baked software with messed up implementation stares at their face.

A decision on software vendor selection, to implement new software requires proper planning, a well-defined process, and careful evaluation. Here are the major aspects to consider.

1. Define the Broad Needs

The first step in software vendor selection is to define the needs of the enterprise in a clear-cut manner, without any ambiguity, and match such needs with the features and functionality proposed or offered through the vendor’s software. A related consideration is to seek a fit with the vendor in terms of having the same outlook towards the business, in terms of a proactive attitude, prompt and transparent communications, focus on agility, or any other traits.

When considering logistics software, some of the usual needs include warehouse automation tasks, tracking cargo, automation of various activities related to supply chain management, and more. The need for supply chain visibility is critical for transparency, which in turn would deliver process efficiency and customer satisfaction. Enterprises would, however, do well to be wary of blindly falling for a generic list of functionality, and make sure the vendor is capable of delivering software which fulfills the specific needs of the enterprise. This often translates to custom software or a highly customized variant of generic software.

Many enterprises make the mistake of designing the system rather than defining the business needs. A successful software implementation usually makes work easier and more streamlined, but a new system that does not take into account the specific process flows of the business would only result in making the enterprise dysfunctional. Make sure to clarify the business needs, and ensure the software vendor has the capability not only to fulfill the technical requirements, but also identify the specific requirements of the enterprise, and design the software accordingly.

2. Reconcile Process Conformity with Flexibility

Today’s businesses are caught in the crosshairs of an extremely volatile business environment. In such a scenario, specifying exact requirements for an inherently rigid software system is a challenging task.

Requirements gathering encompass both functional and nonfunctional requirements. The best approach is to keep the requirements gathering simple, at the initial stage, to get the basic structure right, and delve into the details later, with flexibility inbuilt into the structure. A full blown set of system specifications take a significant amount of time, effort and skills to put together, such details are anyway an overkill when initiating a vendor selection exercise. Once it is proven the vendor is capable enough for the task, it is time to delve into the details.

Staying away from detailed system specifications is not an excuse to ignore developing a list of clear and verifiable requirements. Make sure to include the specific business process the software has to support. In the case of the logistics industry, this could be anything from warehouse management to inventory control, from shipment tracking to invoicing, or anything else, including a combination of any number of processes.

Regardless of the initial specifications, the trick is to ensure the software is expandable, with the provision to support other key feature areas, which may be needed in future, especially as IoT is all poised to unleash a big disruption in the logistics space. There is also a need to ensure seamless integration and ability to pull in data from with diverse systems, considering the logistics ecosystem is now marked by strategic alliances and tie-up with different partners, each having their own software and systems. In fact, a single enterprise may run two or more systems, developed by different vendors, and sync or data integration from such other systems is a must in today’s age of big data.

These requirements translate to the vendor being competent not just in the technical front, but also adhere and comply with industry best practices and well-established quality standards.

3. Clarify Expectations on the Feature List

Drawing up the list of essential features the software should have is indispensable, but only part of the story. It is equally essential to define up front in a clear-cut manner, the other essentials. Requirements include anything related to the product offering and go beyond functional and nonfunctional system requirements. The following are some of the most common requirements which require clarity up front.

• The languages the system needs to support, and whether the interface should match the language preference of the users.
• The nature of the user base, as in the number of expected concurrent users, whether the software will supporting remotely dispersed users, whether the software will be accessed by external stakeholders such as channel partners and customers, and more.
• The nature of technology, as in whether the enterprise is willing to be an early adopter of promising yet untested technology, or wants to play it safe with legacy technology which may have some limitations.
• The extent of dependency, as in whether the enterprise prefers dependency with the new vendor or whether the enterprise would eventually want to manage and update the system in-house. In the latter case, it is best to use open-source software rather than proprietary software of the vendor.
• The nature and scope of regulations and standards to be co-opted into the system, mostly as validations and as reports.
• Nature and extent of essential software related services, such as deployment, validation, migration, training and general support, quality maturity level, and more.
• The extent of reconfigurability of the new system, which influences the speed of deployment. The speed of deployment may be just as important as the quality and scope of deployment. For instance, a cloud-based solution with minimum configuration could be up and running a matter of weeks whereas an on-premise deployment could take months.

It is not enough the software vendor has the technical capability to implement all these requirements. There has to be a cultural fit to ensure the vendor approaches the software development process in the way preferred by the enterprise. Success depends on the vendor being flexible in their approach, and communicating or collaborating with the enterprise in a proactive way. A DevOps approach may work best, though there are no one-size-fits all magic pill. Any agile approach which involves the business end users would work well.

4. Do Not Ignore Reporting Capabilities

Many enterprises and software vendors focus extensively on requirements gathering, and in the process ignore the equally critical part of reporting. Several enterprises also make the mistake of straight jacketing reports into a few handpicked options. Today’s dynamic businesses require dynamic reports, deeply integrated with analytical capabilities. One of the essential purposes of the software itself is to gather all relevant data, subject it to analytics, and deliver it to the relevant stakeholders or decision maker, in the form of actionable information, in the format of choice. A dynamic logistics management software would offer intuitive dashboard and live reports, to facilitate easy decision making.

For the successful deployment of logistics software, there is no shortcut or workaround than the vendor being competent in deploying the latest and the most versatile analytical tools and being able to roll out intuitive dashboards, mobile apps, and other front-end digital assets for the enterprise.

5. Undertake a Cost Benefit Analysis

As the saying goes, “if wishes were horses, there would be all cathedrals and no chapels.” The range of possibilities with software is endless, but success lies in prioritizing for the available budget. Not everything, no matter how utilitarian, productivity enhancing, or beneficial, will make sense from a financial point of view. It is very important to have a budget up front and sync the capabilities of the software to the budget. Also, the budget for software is not just the cost to get it developed and running, but also the cost to maintain it, and upgrade it from time to time.

A best practice for the enterprise is to weigh the requirements or functionality on a scale from “essential” to “nice to have” and “dispensable”, and evaluate the vendor in terms of the extent to which they can deliver on such functionality, and the range of functionality available within the available budget. Understand the basic offerings, and what exactly each specific add-ons will cost.

6. Do Not Ignore Support, Training, and Maintenance

The software is never static, more so in today’s dynamic business environment where the only constant is change. The extent of support required, and on offer vis-a-vis the requirements, is a crucial consideration in the vendor selection exercise.

Clarify expectations on the range of support, the documentation accompanying the software, and develop a blueprint on training users for the new system. The value of supporting documentation such as procedural templates, validation documents, and training materials can never be understated, though these considerations are rarely given much importance during the vendor selection exercise.

Many enterprises leave it at this stage, which is a cardinal mistake. Unless the enterprise is a startup with no legacy systems or business data, it becomes imperative to migrate some or all of the existing records to the new system. An action plan to enforce such migration, or sync the new system with the old is just as important as developing the new system. Many enterprises focus solely on the new system, oblivious to the migration issues, such as source and destination data format, and other issues. A sound technical partner offers comprehensive end-to-end support on all the apparently minor issues, but which have far reaching implications.

Last but not the least, sound partners would also be competent to roll out the software within the required deadline

Trying to develop state-of-the-art logistics software using the internal IT team is a disaster in the making, for the roles and focus of a support team and a development team is markedly different. The best option is indeed to tie up with a software development company who doubles up as a strategic partner,ho doubles up as a strategic partner, for whom the software development process is the core competence and the sole focus. The mantra to success is, however, selecting for a fit, or making sure the software vendor ticks the bill for all the aspects above.