This past holiday season, my son received NBA 2K17 for Xbox One from his grandmother. He opened it up, popped it in and started playing. A couple of hours later, he asked me to play against him. I grabbed the box to read the manual. Silly me. There is no manual for these games. Well there is, but it is a small page with a link to the online users guide. Im guessing not many 13-year-old boys are studying that webpage.

If you ever played this game before, you know that it is some complicated software. It is no doubt every bit as complex as many of the commercial and enterprise applications of the last decade. But something changed. Why is it that teenage kids (and younger) can so quickly learn and master very advanced applications such as NBA 2K17, yet companies must budget and plan for days of classroom training for new transportation software, inventory solutions or warehouse applications?

The reality is, as software evolves and as younger generations enter the supply chain talent pool, far too many supply chain software vendors failed to follow suit. One of my favorite studies of all time was conducted by the Sand Hill Group. When asked how to best define success, both software providers and buyers indicated value realization. Seventy percent of those surveyed believed that user adoption was the primary driver of success. Only 1 percent felt that features and functions ruled the day. I think the vast majority of supply chain software users would agree.

While leading vendors in traditional software have the benefit of deep, mature functionality, they are also saddled with applications that likely have hundreds of screens designed a decade ago or longer. While many added slick new skins that appear more modern, few are willing to invest the millions of dollars necessary (and years and risk) to fundamentally change how the application is used. The return on investment (ROI) can be difficult to prove and requires a core belief from senior management to make this kind of bet.

With that in mind, I would submit that companies looking for new supply chain software (or any enterprise software, for that matter) must reconsider how they evaluate software. The traditional requests for proposal (RFPs) and demo scoresheets used by consultants and buyers alike are almost entirely checklists of features and functions. The more, the better! But doesnt feature bloat usually lead to even more confusing user interfaces?

Changing how you evaluate software is not easyboth literally and culturally. It is a natural temptation to add features you may need four years from now just in case. Likewise, how do you objectify ease of use?

To help, Id like to offer five warning signs (and evaluation tips) of old-fashioned software design.

Cluttered screens with far too much information on them stem from good intentions. Software vendors simply want to ensure that any possible data a user might need in the theoretical future is available on the screen. Take a look at one of your most commonly used screens (i.e., a shipment screen). If you find that you dont need half of the data on the screen, you have a problem.

One sure sign of feature bloat is how many clicks it takes to perform a frequently used function. Good, experienced design teams have usability labs to measure this exact metric. During the demonstration, evaluators should pick a couple of important features, such as tendering a load or approving an invoice, and measure click count. I strongly recommend not telling your vendor this in advance as data can be pre-staged and unrealistic shortcuts can be taken to give a false reading.

This may sound silly, but you can tell a lot about an application by its menu structure. How wide and how deep is the menu? If a menu has more than 10 selections on it, it is probably too cumbersome. If it goes two or three layers deep, that is also a worrisome sign. Vendors occasionally talk about positional memory as a design strategy, but that is usually an excuse for feature bloat. The one exception to this is configuration, which by its very nature, is complex. However, good software hides this from everyday users.

What does your vendors training look like? Do they advertise a university? If you need a four-year degree to master your new software (or five days of training just to start your project), then you might have a problem. Good software design should allow you to start exploring and executing within a couple of hourskind of like the NBA 2K17 tutorial.

OK. This last suggestion is a little devious. But, how long does it take for your vendor to prepare for a web-demo overview with data that is similar to yours? If it takes more than a day or two, that should tell you something. If the company needs two to three weeks to prepare for a scripted demo, that should also be factored in to your evaluation. If the people who use the software every day need a lot of time to get ready to show you their best side, what does that mean for a team of people who are going to be new to the system?

Its been a month and I think I am finally ready to take on my son in NBA 2K17. I didnt learn it quite as quickly as he did and Im pretty sure Ill lose by 30, but Im guessing its not the design. Maybe Im just old.

David Landau is the executive vice president of Cloud Logistics.

Read the rest here:

All I Want for Christmas Is TMS 2K17 - Supply & Demand Chain Executive