A quick search on Google for information about How to Select TMS Software finds many articles talking about how to identify stakeholders, how to determine budgets, and how to do other things important in any effort to evaluate and select TMS software.
But one critical item is missing in all those How to Choose Transportation Management Software articles, and that is a detailed instruction set about HOW To Identify TMS software requirements.
All the pundits/experts provide how-to instructions that say "identify your TMS requirements" before making a transportation management software selection, but they don't go into any detail about how to identify those requirements. What exactly does "identify your TMS requirements" really mean? How are they identified? How are TMS requirements collected? There are many issues that can impact how a TMS requirement can be identified, so what is the best way? Some of these issues are:
Just to show how important the act of correctly identifying requirements can be, let's go back to our previous example requirements statement "The new TMS system must provide an Carrier/Agent Payables Aging Report."
Since this appears to be a basic requirement many people in your company might consider that to be good enough for use in an RFP. Others may want to add "with the ability to specify a Starting and Ending Carrier / Agent" because of the large number of cariers, so the full requirement becomes:
"The new TMS system must provide an Carrier / Agent Payables Report."
"The Carrier / Agent Payables Report must provide the ability to specify a Starting and Ending Carrier and/or Agent."
The above looks good to all, it seems to go into enough detail, so it goes into the RFP. Especially since many people are thinking, "this is good enough, this is just a "standard" Carrier / Agent Payables Aging report, something any good TMS system should be able to do".
All the vendors respond with YES to both of the above requirements, since they are very easy to do for almost any system. A system is chosen, partly because of the large amount of detail in its database, and implemention of the new TMS system is started.
Very quickly it become apparent there are problems with the Carrier / Agent Payables Report. It is VERY long, it uses up tremendous amounts of paper, and takes a very long time to finish, all because it includes a DETAIL transaction listing for every Carrier and/or Agent, and there are many, many Carrier and/or Agents. The report show balance due and all transactions that have been created and sorted by carrier, reference the pro number, trip number, group number) and C/L number. All of a sudden there is now a new, unforeseen problem with the new transportation management software, one that will cause a delay in its implementation while waiting for the problem to be solved.
It takes several emergency meetings to determine the best way to solve the problems caused by a lengthy, unwieldy, and almost unusable Carrier / Agent Payables Report. The solution is to add a new report setup parameter (control) enabling the user to specify if the DETAIL for each Carrier and/or Agent account should be printed or not. This is ideal since the Carrier / Agent Payables Report already includes a summary-level aging analysis that shows which accounts are past their Due Date.
The additional, totally unforeseen cost of adding the new new report setup control is not welocme, but neccessary. The new TME implementation is re-started with a new GO-LIVE date.
The implementation moves into final testing, where yet another deficiency in the Carrier / Agent Payables Report is uncovered. Write-offs must be done individually, requiring significant extra time compared to the old way of doing them as a group. So now there is another unforeseen problem that must be solved, calling for yet another series of unplanned, emergency meetings to resolve this new problem.
The only solution to this problem is to modify the source code so they can be done as a group. Also, a new report setup control must be added to enable the user to do this.
The UNEXPECTED COST of the solution to this new problem is VERY LARGE since it involves significant changes in Carrier / Agent Maintenance and other DB records abd also the Carrier / Agent Payables Report Setup and Report processing. This is totally unacceptable since it now threatens to significantly REDUCE the financial benefits iof the new system.
The above illustrates how UNPLANNED requirements can drive up the actual COST of even a so called "run of the mill", application standard function such as an Carrier / Agent Payables Report. Note that we have not yet talked about the need for "User Defined" Account Aging Periods, Aging by Region, Aging by User-Defined Carrier / Agent Categories, User-Defined Transaction Notes, and many others related to truly useful Carrier / Agent Payables Aging Reports! These are not standard, nor are they something "any good system can do"!
And the above are all in just one small functional area of the many that can make up a transportation management software (TMS) system! Just imagine how many there are, and what could be happening, throughout the entire TMS system. No wonder the majority of all system implementations fail to achieve their operational and/or financial objectives! How software selection requirements are defined does matter!
There are so many functional areas in a typical software system the entire task of "identifying requirements" can be quite overwhelming. That is why some software selection hubs and technology evaluation centers sell pre-populated RFPs. But, as we have illustrated above, an RFP software requirement may not adequately define your needs, especially a static software features list created in a backroom 3 months or 3 years ago. What is needed is a list of TMS software RFP requirements that truly reflect all your software configuration, operational (control), and management needs. The best, most efficient way to do that is described below.
The best way to identify all your true TMS requirements at the detail level, without wasting significant amounts of time on in-significant or irrelevant issues, is to use proven, time-tested tools such as the Work Distribution Chart (WDC) to identify areas of user need, then investigate them more thoroughly using a Requirements Checklist with Fit-GAP Analysis. This will uncover information UNIQUE to your business, e.g. the information needed to create a meaningful RFP, and an actionable Demonstration Script, that will be very useful in your efforts to select TMS software best suited to your organization. All are explained in the sections below.
Any of us who have collected user needs knows how difficult that can be. Most end users know very little about "software requirements" but they do know WHAT they do each working day and HOW MUCH time they spend doing each task (on average). There is NO user training required in order to use a WDC, because the user already knows the answers! All users need do is enter their name, position, and a list of those activities they perform each day along with how much time they spend doing them on average. Easy!
Obtaining this information from each TMS user will enable any person knowledgeable about the operation (such as a Business Analyst or Dept Mgr) to immediately identify unusual amounts of a specific activity, and/or where too much time is being spent. These indicate potential software deficiencies, workflow roadblocks, and compliance problems, and should be flagged for further investigation using the Requirements Checklist with Fit-GAP Analysis.
Infotivity provides a very flexible, easy-to-use WDC, available separately and also iincluded in all RFP Template and Software Selection Toolkits. View details at the Work Distribution Chart (WDC) Template page.
You have now started to identify where your operation's real TMS problem areasTMS are. The next step is to interview the users who have reported those problems or unusual activity on their WDC responses and further investigate the reasons why they are occuring. These are the areas where special effort must be made to identify and document their cause and possible mitigation efforts. This saves you a lot of time, and is where the Requirements Checklist with Fit-GAP Matrix becomes a very useful, time-saving tool.
The goal of interviewing end users about the problems, productivity issues and/or other unusual activity reported on their WDC responses is to collect information describing each issue/problem, then document the CAUSE, i.e., is it caused by a deficiency in the current software, or a workflow bottleneck, or a compliance requirement, or other operational or process problem. Once an issue has been documented, information regarding HOW IMPORTANT it is, i.e., it's PRIORITY, and possible ways to MITIGATE or RESOLVE the problem, should be collected.
Infotivity provides a Requirements Checklist with Fit-GAP Matrix to help with this step of the software selection process. These comprehensive checklists are pre-loaded with hundreds of criteria, tasks, and process questions pertinent to end user system system or operational needs, each paired with matching Fit/GAP attributes. This enables you to meet with an end user and immediately ask key questions focused on the activity area they reported on their WDC response, record their answers, and identify possible solutions to their reported problem.
Fit/Gap Analysis is a proven software industry methodology used to evaluate each functional area in a business process to achieve a specific solution. It includes identifying key data or components that fit within the desired business system and GAPS that need solutions. Learn more about Fit-GAP Analysis.
The TMS Requirements Checklist enables you to record both the problem found in a specific business function, process, or software module, and also the "Importance Level" (Priority) of that problem. Learn more about the Infotivity Requirements Checklist with Fit-GAP Matrix benefits.
The Checklist then enables you to record WHERE, WHEN, and HOW MUCH of a GAP exists between your organization's current needs and and the software system it currently has in use, and just as importantly, WHY. Following this proven Fit-GAP process identifies the software requirements UNIQUE to your organization at all levels - Software Functionality, Workflow, Business Process Reengineering, Data Collection, Reporting, and Compliance, ensuring an effective RFP is used to query vendors.
The information collected from the end user WDC responses, user interviews, and derived from Fit-GAP analysis, all as described above, can be used to very quickly convert the Infotivity Transportation Management System RFP template into an RFP customized to communicate your unique needs to a vendor.
Preparing a meaningful TMS Request for Proposal (RFP) containing the information obtained in previous steps, and then using it to query vendors as needed to obtain consistent, easily compared vendor TMS proposals is an extremely important step in the "How to Select Software" process for two reasons:
The first reason is that it documents at the detail level exactly what a vendor has made a commitment to do, and at what cost. An software system is very complex, and it is impossible to ask about every feature and function pertinent to your operations. Documenting the vendor proposal, their commitment to you, is very important.
The second reason is that a properly formatted RFP, i.e., one that presents its questions in quantitative format, will enable very fast and accurate evaluation and comparison of all vendor TMS RFP responses (proposals).
The Infotivity TMS RFP Template with matching TMS Software Selection Toolkit enable you to accurately issue an RFP conveying your specific, unique TMS needs, then evaluate and compare vendor proposals at the detail feature, weighted grade score (suitability), supportability, and financial levels. Learn more about Infotivity TMS RFP Templates with Software Selection Tools
Inviting those vendors presenting the most promising proposals (RFP responses) is a very good way to resolve any questions arising from their proposals, if needed, and also to view first hand how the proposed system's user inteface works, how intuitive it is, and easily a proposed system can be adapted to changing operational and workflow requirements.
Read about Infotivity TMS Software Demonstration Script Template capabilities.Learn more about the correct software selection process steps.
Return to the TOP of the How to Select TMS Software Page.
View the RFP Template List
SELECTION READINESS TOOL
WHAT USERS SAY...
Telenor I.C. J. P.
we did in 4 weeks what it
took others almost a year
5,200+ Facilities Worldwide
detailed RFP I have seen
Memphis Light (MLGW)
have to say it's quite
extensive and well laid
out, this is exactly what
we were looking for!"
Certified SCM Consultant
WHAT USERS SAY...