Category Archives: Technology

The UIX One Should Expect from Best-In-Class Auctions, Part II

Last week we dove deep into the basic general requirements for any e-Negotiation platform, namely e-RFX and e-Auction, and called out the need for easy template creation and easy starting bid population and validation as two necessary key requirements (among a set of requirements). (See: Best-in-Class e-Sourcing Part I and Best-in-Class e-Sourcing Part II.)

However, as we explained in our last post, the requirements for auctions go quite deeper than the requirements for RFX. In our latest article over on Spend Matters Pro [membership required] on “What To Expect from Best-in-Class Reverse Auction Technology and User Design (Part 2)”, the doctor and the prophet dive deep into specific capabilities required of modern e-Auction platforms in order for a user to have a great experience.

In our article, we define three absolutely requirements, as well as two requirements that will soon be absolute, for every e-Auction platform that wants to be a modern platform, including real-time connectivity monitoring.

As we state in our article, internet and software connectivity should never be taken for granted. This is a lesson one of the authors originally learned over 15 years ago (first hand) when helping run early online sourcing events at FreeMarkets. However, even today, many platforms still take this for granted, assuming that everyone has the reliable, redundant internet infrastructure of a modern first world data center. This is still simply not the case. Your supplier representatives are probably located at their factories in the middle of Nowheresville in the Lost State of Third World Country and might still be on a 1.54 Mbps T1 connection, which is only up on good days. Their data centers might be located in the nearest city, which barely has enough electricity to meet demand on a good day (when the AC or Heat is cranked up in every home and building), and subject to occasional rolling brown-outs. And so on.

The fact of the matter is the software should assume that suppliers can, and at least one supplier representative will, lose connection during an event. And if this happens, the supplier still needs to be able to bid. A modern platform allows for each supplier representative to designate one or more proxy bidders, in priority order, and if the main rep is unable to establish, or maintain a connection, the software will detect that and automatically switch the bidding designation to a proxy (who will be view only until he or she needs to take over bidding). In addition, the loss of connectivity and change of delegate will be noted and the buying organization notified.

In addition, it will detect if multiple supplier representatives lose connectivity, assume there is a major issue, automatically suspend the event, and notify the supplier representatives through other means (e.g. backup emails, fax, and/or even SMS) that the event has been suspended and will pick up either the designated back-up time or at a time to be communicated by the buying organization as soon as the issue has been identified and resolved.

This is necessary not just to maintain good supplier relations, but to prevent costly legal challenges, especially in the public sector, if an organization lost because it couldn’t bid through no fault of its own (and could prove that it was willing to make the lowest bid which, in many jurisdictions, requires the award to be given to that organization). But yet, a [large] number of auction providers (of the 50+ that the authors collectively know about) do not provide this capability.

Curious to know what the other four requirements are? Then check out our full piece over on Spend Matters Pro [membership required] on What To Expect from Best-in-Class Reverse Auction Technology and User Design (Part 2).

No Solution is Completely Foolproof

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
Douglas Adams

Source-to-Pay solutions are getting easier by the day and soon they will be so easy that some vendors will be claiming their solutions are so simple that even a fool can use it error-free. But that’s really not the case. No solution is foolproof. Never will be.

Why? First of all, it’s impossible to predict every action a person could take. So, no matter how many situations you plan and check for, if there is even one you missed, and if the application is complex enough there will be at least one, no matter how unlikely that situation is (or how nonsensical it is), there will be at least one user who finds it and either crashes the application or generates a scenario that is nonsensical.

The alternative is to lock the application down to an enumerable finite set of inputs in each state and limit the allowable actions to those that will allow a smooth, predictable, transition to the next state without fail. But if the vendor chooses this route, the result will be a very limited application with very limited possibilities. And given that the real world is not limited to a small set of situations with always predictable solutions, this is not a very useful solution.

Secondly, never underestimate the application stupidity of a potential user. First of all, the user could be a new transfer from another department with no training and a very shallow understanding of Procurement. What a vendor would assume to be obvious to an average Procurement user would not be obvious to a new transfer. Secondly, not all users are Procurement users. For example, shop floor users might have access to initiate requisitions. And these workers might have limited computer knowledge. And then there’s management. And consultants.

Thirdly, the more a vendor tries to make a solution foolproof, the more they end up throwing in way too much unnecessary code. The more unnecessary code that is put into an application, the more errors that creep in. Errors multiply with code. Always. Doesn’t matter if the code compiles. Doesn’t matter if the code passes the boundary tests. All that matters is that there is more code with more paths and more state transitions to track, to the point where eventually there are too many paths to track and test and something breaks when a user goes down the wrong path.

The moral of the story? Don’t fall for any vendor who says their application is foolproof. And don’t look for a foolproof application, because it’s not about how easy the application is, it’s about how much value the application can generate. The best applications, while easy and logical for most of the functionality, will not be foolproof. Nowhere close. So, value first. Because, at the end of the day, the only user a foolproof solution is for is a fool.

What Makes a Good UX? Part II “Smart Systems”

A couple of months ago, after we sang Bye, Bye to Monochrome UIs, we indicated that we were beginning a series that chronicles what makes a good UI, and more importantly, a good UX (User Experience) in a modern Sourcing or Procurement system. This is critical because systems that are not useable do not get widely adopted, and systems not widely adopted never deliver the promised value.

In our first post on What Makes a Good UI where we noted that the full series was being published over on Spend Matters Pro [membership required] as it is the result of a deep long-term multi-blogger collaboration (led by the doctor and the prophet) designed to identify what should be (and not what ay given vendor will try to promote based on what they have), and sponsored by Spend Matters, we outlined some of the fundamental requirements of a UI / UX for any Supply Management application which include, but are not limited to:

  • integrated, pervasive, guidance
  • … that is based on true expertise and historical use
  • “touch-less” automation wherever possible
  • extremely context aware
  • mobile support and mobile first in the field
  • messaging as a competitive advantage

(And if you want deep coverage on these topics, see the first instalment of our full series on “Measuring the Procurement Technology User Experience: More Than Just a Pretty Screen” over on Spend Matters Pro [membership required].)

But, as we stated, these were just the absolute base-line requirements. In Parts II and III of our full series, we outline the next set of core functionality that should be pervasive across any Supply Management platform that you acquire. And in future articles, we dive into e-Negotiation, e-Auctions, Optimization, Spend Analytics, SXM, CLM, Requisitioning and Shopping, Procurement and Catalog Management, and Invoicing … just to start. But we’re getting ahead of ourselves.

One of the core requirements we reveal, and dive deep into, in Part II in our article on Smart Systems and Messaging, Chat, and Collaboration is smart systems.

As per our article, smart systems drive integrated guidance leveraging new “AI” techniques -— better termed automated reasoning (AR), as software isn’t truly intelligent —- that adapt and learn over time. They do this by mixing semantic technology, sentiment analysis, key-phrase driven expert systems and other machine learning techniques with history to determine what the user is doing and what the user wants to do.

For example, a smart system in sourcing will detect if there has been a full event/process before run by a user or similar peers in an organization, and allow the user to instantiate a new instance (by copying the template or previous event). Or, in the case of one-time requisition in which competition could benefit the outcome, a smart system can detect an automated spot-buy event that can be run against prequalified suppliers hands off, which the system suggestions.

And that’s just the beginning of what a smart system could, and should, do for you. For deep insights into not only where the bar is today (as leading providers start to release first versions of these guided systems), but where the bar will be by 2020, check out our post, which also dives deep into the Messaging, Chat, and Collaboration functionality [MCC] that a modern system should support. [Hint, more than just integrated e-mail or first generation chat!]

And stay tuned for the next part, coming later this week, on the final set of core requirements that we feel a modern Supply Management System cannot be without!

P.S. If you are a vendor invited to the Sourcing, SRM, CLM, or Spend Analysis Solution Map, this is a series you do NOT want to miss!

Platform? Bah Humbug!

Earlier this week, the medic pointed out that Jaggaer is taking the contrarian approach (in “Jaggaers merger Pool4Tool taking contrarian role around integration”) and almost scoffing at the idea of an integrated, unified, code base and instead pointing out that its customers want problem fixes and business solutions, and integration isn’t a concern.

And to an extent, they have a point. Not everything has to be on one cohesive code-base with one cohesive UI if some parts of the solution are only used by a few individuals or designed for a different department or the usage is disparate from the rest of the platform and/or rare. For example, you’re not typically doing opportunity spend analysis in the middle of a sourcing project (although you may want to do pricing trend and outlier analysis on submitted bids after initial RFP responses before starting an optimization). And the people doing day to day tactical buying are not doing serious advanced direct sourcing projects and so on.

That being said, if you are a sourcing pro, you are likely building direct material RFPs, analyzing responses, running optimization events, negotiating contracts, accessing and updating supplier information, managing supplier relationships, and tracking milestones. The last thing you are going to want to do is log in and out of 5 different systems on a daily basis (Spend Analysis, RFX, Optimization, SXM, CLM) — especially if they all have different UIs and UX.

Sometimes you need integration and consistency, and sometimes you don’t. But one time you really need it is when your users are not very technical and have a lot of work to do, especially of the tactical variety. Coupa would never have gotten where it is if each function was a different module with a different UI. It’s design to make end-to-end work easy for its average user is how it won. And if it can do that with sourcing (and find a way to integrate its recent acquisitions and extend them with the few pieces of missing functionality) and give sourcing pros the same experience, it will win there too. However, this is one place where Jaggaer, with a lot more experience in strategic sourcing and sourcing support, could pull ahead. If Jaggaer could seamlessly integrate Spend Radar, CombineNet, AECSoft, Upside Software and Pool4Tool into one coherent platform it would have 3 capabilities that the Spend 360 / Trade Extensions union lacks: advanced Contract Management, Advanced Supplier Performance Management, and, most importantly, advanced BoM management from the RFX down to the VMI. On paper, its one of the most impressive suite of capabilities on the market for manufacturing, pharmaceutical, aerospace, electronics, and other direct-heavy industries, but, in the end, it will be the usability that decides the ultimate winner.