Supply Management Technical Difficulty … Part VI

In this post we conclude our initial 7 part (that’s right, 7, because Part IV was so involved, we had to do 2 posts) series on supply management technical difficulty, focussing on the source to pay lifecycle. We did this because many vendors, with last generation technology, have been touting their own horn with a “market leading” offering that was market leading a decade ago, but, due to lack of innovation on their part, is now only average. Moreover, much of what used to be challenging in this space is now, in the words of the spend master, so easy a high school student with an Access database could do it, and that ain’t far from the truth. Unless the platform comes with an amazing user experience (and the reality is most don’t), a lot of basic functionality can be accomplished using open source technology and an Access database.

So far, we’ve covered the basics of sourcing, the basics of procurement, supplier management, spend analysis, and (invoice to) payment, and while each have their challenges, the true technical challenges are few and far between comparatively speaking. Today we are rounding out the series with the true, hidden, technical challenges that you don’t see. And there aren’t many of those either, but they are doozies.

Technical Challenge: Large-Scale Scalability

If you’re selling an application that is only going to be used, by a few dozen, and maybe a few hundred, users, scalability isn’t an issue. An average low-end server with eight cores, 64 GB of RAM, and a few TB of solid state storage should be more than enough to support this user base even if the application is shoddily coded by junior developers who cobbled most of it together cutting and pasting code from SourceForge.

But if we are talking about a true e-Procurement system that is going to be rolled out to everyone across a Global 3000 organization with the authority to make a requisition or spot buy, this will be tens of thousands of users, serviced by hundreds of Procurement professionals doing daily spot buys and MRO inventory management and dozens of strategic buyers and analysts looking for opportunities and conducting complex events using optimization and deep data mining, an average high end server is not going to do the trick. Multiple server instances are going to be needed, but they are all going to have to work off of the same data store, and a significant amount of this data is going to need to be accessed and updated in real time, so it’s not just a matter of replicating the database and allowing the users to go to town. While some data can be replicated for analysis, MRO data has to always be updated in real time to insure requisitions are filled from on-site inventory or warehouse inventory first. This requires a complex data management scheme, fifth degree normalized design, real-time clustering, and so on and so on and so on on the data side as well as intelligent request routing on the application side as you can’t route all requests evenly (as 10 inventory look up requests are a lot less processor intensive then the creation of 10 detailed category reports).

Technical Challenge: User Experience

While the creation of just about any modern user interface component is a piece of cake using modern language libraries, there’s a big difference between user interface and user experience. And the most slick user interface in the world is useless if the process it forces the user through is kludgy and cumbersome and takes three times as long to accomplish a simple task as it should. A great user experience is one that requests minimal input, involves minimal steps, and, most importantly, involves minimal time and effort on behalf of the user. It takes context into account, known information into account, organizational processes and (approval) rules into account, etc. and makes it so that a user only has to do as little as possible and is in and out of the application as fast as possible so that she can focus on her primary task. If she’s not a strategic buyer or a spend analyst, she shouldn’t be spending her days in the tool — she should be spending her days doing her job. This is what many applications miss. A truly good software tool is elegant. In our space, even today, many aren’t.

So, hopefully by now you have a good understanding of what is truly difficult and what you should be looking for when evaluating a tool. There is still an intense amount of complexity that needs to be overcome in a modern application, but any application that does not tackle the complexity outlined in this series is not truly modern. Keep this in mind and you’ll make great selections going forward.