Daily Archives: July 19, 2012

Where’s the Supply Management Technology Usability Guide?

There are a lot of guides out there as to what a good Supply Management Tool for Sourcing, Procurement, or Logistics is supposed to do, including a number of very detailed posts on SI (and wiki articles on the e-Sourcing Wiki that the doctor wrote, or co-wrote), but are there any guides for usability? (A google search for ‘supply management software usability guide’ comes up empty in the doctor‘s view.)

I couldn’t help but wonder this after reading an article by John A. Gentle that gave the sage advice: provide better instructional tools that offer real value. It clearly pointed out the challenge of “ineffective instructions” that logistics teams create for their suppliers, especially for how vendors are expected to complete forms, input data, and operate software that was provided by your company for warehouse and trucking operations, billing, and reporting. Now, if the provided software was so obvious and easy to use that even a fifth-grader could figure it out, then the issue of “ineffective instructions” is a small one. But the reality is that, even with most platforms that are attempting to adopt consumer-style interfaces, most procurement and logistics software is still reasonably complicated due to the complex nature of what a Procurement or Logistics package capable of supporting global trade needs to do.

Even though the functionality is well understood, the best way to lay out the functionality, and underlying workflow, is not well understood in comparison and, unfortunately, if one company builds an interface that is too close to a competitor’s for some standard functionality, instead of the formation of a standard, in America, we get a frivolous lawsuit (courtesy of the patent pirates). So even though there should be design standards, there usually aren’t.

And the poor supplier, who probably has to manage five such systems which all have completely different workflows and user interfaces, experiences more frustration than John and his Ph.D. wife who had to experience two weeks of trial and error just to reset the time on a poorly designed watch (with even poorer instructions).

I know that the very nature of software, which is always evolving, makes such a guide difficult (and that this particular challenge is compounded by the fact that America still allows software to be patented), but there should be at least some standard workflows and processes that all sourcing, procurement, and logistics software should attempt to follow in a reasonably standard way. It will make things easier for all supply chain partners, minimize unnecessary stresses and bumps, and help us evolve the profession as a whole.