Category Archives: rants

Walmart: Still Running on a 56.6 baud Modem …

Walmart recently released a statement that it plans to use employees to do home deliveries, presumably to fulfill online orders, as recently reported on The Washington Post. the doctor couldn’t believe it at first … convinced it was an article from the Onion misposted on a real news site, but apparently it’s real.

Overlooking all the things that could go terribly wrong with this, and all of the new legal liabilities this could cause them to incur (which would give your average risk manager and Chief Counsel nightmares for months), this makes absolutely no sense from a supply chain perspective where the name of the game is cost control (unless, of course, Walmart is looking for a way to actually lose money as a tax avoidance scheme).

There’s a reason even Amazon uses third party carriers for its prime service, and the reason is that, as stated by the article, last mile logistics are costly. Very costly. And they can only be minimized by maximizing the number of packages delivered per hour by a driver. An employee who can only deliver a few packages due to space limitations in their car can’t maximize deliveries compared to a Fedex or UPS van driver that has a van built to maximize the number of packages that can be carried at one time and that is making deliveries determined by software that minimizes the delivery radius of all assigned packaged and delivery time using route optimization software (that eliminates left turns and backed-up routes).

Now, maybe Walmart is thinking that they can introduce a new kind of package assignment algorithm that minimizes the distance from an employee’s home route, and then just pay that employee for additional distance and time required (using google map calculations, etc.), but you still have the problem that the closest employee(s) may not be working that day, may not be able to do deliveries that day, or may not be able to fit the packages in their vehicle. Most of the time the software will have to re-assign and re-assign again until a viable sub-optimal match is found, and at the end of the day the cost would be more than just having a full time driver deliver everything according to route optimization software at a cost that is still more than negotiating a good volume-based outsourcing agreement with the dominant local carriers who can increase the delivery density even more.

The reality is that just because something sounds good (as in 90% of all customers live within 10 miles, where most employees are also located), does not mean it is good — and that’s why you need to perform analytics and optimization before embarking on major initiatives such as this. Because even if Walmart could get near-optimal assignments, it still needs volume, and as long as it takes 3 times as long to do anything on their site as it does on Amazon (and that is definitely true in Canada, where the outsourced development organization prefers to benchmark against sites for other real-world retailers and not Amazon from an online retail perspective), and as long as they continue to ship 6 (light) items on the same order across 5 boxes, their online volume growth is not going to be fast enough to make this idea anywhere as efficient as they hope in the next few years. This is one case where the doctor hopes their trials flop and they see the error of their ways and go back to investing in more hybrid vehicles, more efficient warehouses and inventory management methods, and other initiatives guaranteed to increase efficiency and sustainability.

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.

Remember: Big Bang = Big Bang!

While the doctor was at Coupa Inspire, he heard a very scary message over and over again from Coupa customers during the CPO panel. It seems that even though it’s been over 20 years since the demise of Foxmeyer Drug, organizations are still pushing for big-bang supply chain re-vamp projects and advising Procurement to “wait for the ERP upgrade to [almost] complete and then select a new BoB solution to fill any gaps as it will be quicker and easier to do it all at once“! Gadzooks! Six of the 11 biggest supply chain disasters of all time (as chronicled by Supply Chain Digest) were directly, or indirectly, caused by a big-bang ERP project and the fiasco it created, including the ruination of Foxmeyer Drug that was a 5 Billion global company. Big bang projects almost always end in big bangs that wipe out entire divisions, markets, or global organizations. There is no excuse for them in this day and age and no organization, consulting or otherwise, should be pushing for them.

Fortunately for these customers (who were chosen because they were prime examples of successful Procurement organizations in the Coupa community who led the way), they didn’t listen to their organization and just did it. The beauty of a modern self-contained cloud-based solution like Coupa is that you don’t even need an ERP. You can just license an instance and go. This is what they did, and one organization, instead of waiting 18 months to get started, completed a global roll-out in 4 months and banked over 10M in savings before they would have even started product selection had they sided with their organization!

In other words, don’t go big bang unless you want to sabotage your organization (because you are a mole for, or taking kickbacks from, the competition) as the likely outcome is big bust. Just get going, one solution at a time, which you can integrate at the right time in a focussed project that is much more likely to succeed mostly on time and on budget as the project parameters will be better understood.

Supply Management Technical Difficulty … Part V

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks.

So, to help you understand what’s truly hard and, in the spend master’s words, so easy a high school student with an Access database could do it, the doctor is going to bust out his technical chops that include a PhD in computer science (with deep expertise in algorithms, data structures, databases, big data, computational geometry, and optimization), experience in research / architect / technology officer industry roles, and cross-platform experience across pretty much all of the major OSs and implementation languages of choice. So far we’ve covered basic Sourcing, Procurement, Supplier Management, and Spend Analytics. Today we’re moving onto Payment, which, in e-Procurement, is usually part of Invoice-to-Pay.

Payment sounds pretty easy, as it’s just a matter of cutting a cheque, using a P-card, doing an ACH, or sending a wire, but is it? Mostly, but not entirely.

Technical Challenge: Automated Invoice Regulatory Compliance

Many countries have a lot of strict requirements when it comes to invoice acceptance, processing, and submission. And, generally speaking, they’re all different. Now, I bet you’re saying that there’s no technical challenge here — read the regulations, extract the requirements, define the workflow, implement it with one of a dozen different workflow tools. And you’re be right if that was true automated invoice regulatory compliance.

You see, the thing about regulations is that they are constantly changing. And if you’re supporting 100+ countries, in which many multi-nationals operate, that not only presents a challenge in workflow maintenance and redefinition, but also a challenge in even detecting when a regulation is about to change and when a workflow might need to be updated, or has changed (suddenly) and the workflow hasn’t been updated.

As much as one might need an invoice-to-pay solution that can adapt a workflow to changing requirements, one, especially if one is doing business in dozens of countries, needs a solution that can detect when a workflow needs to change and when invoices have to be halted as a result of a potential issue even more. And, of course, recommending the appropriate workflow updates based upon a semantic analysis of the new regulations.

In other words, if all you are being sold is a payment integration engine, which has existed for a decade, then you are not being sold anything modern or sophisticated.

Next up: the hidden elements.

Supply Management Technical Difficulty … Part IV.2

A lot of vendors will tell you a lot of what they do is so hard and took thousands of hours of development and that no one else could do it as good or as fast or as flexible when the reality is that much of what they do is easy, mostly available in open source, and can be replicated in modern Business Process Management (BPM) configuration toolkits in a matter of weeks. In this series we are tackling the suite of supply management applications and pointing out what is truly challenging and what is almost as easy as cut-and-paste.

In our first three posts we discussed basic sourcing, basic procurement, and supplier management where few technical challenges truly exist. Then, yesterday, we started a discussion of spend analysis, where there are deep technical challenges (that we discuss today), but also technical by-gones that vendors still perpetuate as challenges and stumpers that are not true challenges but are to many vendors who didn’t bother to spend the time it takes to hire a development team that can figure them out. Yesterday we discussed the by-gones and the first-stumper. Today, we discuss the second big stumper and the true challenges.

Technical Stumper: Multi-Cube

The majority of applications support one, and only one, cube. As SI has indicated again and again (and again and again), the power of spend analysis resides in the ability to quickly create a cube on a hunch, on any schema of interest, analyze the potential opportunity, throw it away, and continue until a new value opportunity is found. This also needs to be quick and easy, or the best opportunities will never be found.

But even today, many applications support ONE cube. And it makes absolutely no sense. Especially when all one has to do to create a new cube is just create a copy of the data in a set of temporary tables designed just for that and update the indexes. In modern databases, it’s easy to dynamically create a table, bulk copy data from an existing table to the new table, and then update the necessary index fields. The cube can be made semi-persistent by storing the definition in a set of meta-tables and associating it with the user (which is exactly how databases track tables anyway).

Apparently vendors are stumped on how easy this is, otherwise, the doctor is stumped as to why most vendors do not support such basic capability.

Technical Challenge: Real-time (Collaborative) Reclassification

This is a challenge. Considering that the reclassification of a data set to a new hierarchy or schema could require processing every record, and that many data sets will contain millions of transaction records, and modern processors can only do so many instructions per second, this will likely always be a challenge as big data gets bigger and bigger. As a result even the best algorithms can generally only handle a few million records on a high end PC or laptop in real time. And while you can always add more cores to a rack, there’s still a limit as to how many cores can be connected to an integrated memory bank through a high-speed bus … and as this is the key to high-speed data processing, even the best implementations will only be able to process so many transactions a second.

Of course, this doesn’t explain why some applications can re-process a million transactions in real time and some crash before you load 100,000. This is just bad coding. This might be a challenge, but it’s still one that should be handled as valiantly as possible.

Technical Challenge: Exploratory 3-D Visualization

There’s a reason that Nintendo, X-box, and PlayStation keep releasing new hardware. They need to support faster rendering as the generation of realistic 3-D graphics in real-time requires very powerful processing. And while there is no need to render realistic graphics in spend analysis, creating 3-D images that can be rotated in real-time, blown up, shrunk down, drilled into to create a new 3-D image, which can again be rotated, blown-up, shrunk, drilled into, etc. in real time is just as challenging. This is because you’re not just rendering a complex image (such as a solar system, 3-D heated terrain map, etc.) but also annotating it with derived metrics that require real-time calculation, storing the associated transactions for tabular pop-up, etc. — and we already discussed how hard it is to reclassify (and re-calculate derived metrics on) millions of transactions in real time.

Technical Challenge: Real-time Hybrid “AI”

First of all, while there is no such thing as “AI”, because machines are not intelligent, there is a such thing as “automated reasoning” as machines are great at executing programmed instructions using whatever logic system you give them, and while there is no such thing as “machine learning” as it requires true intelligence to learn, there is a such thing as an “adaptive algorithm” and the last few years have seen the development of some really good “adaptive algorithms” that employ the best “automated reasoning” techniques that can, with training, over time improve to the point where classification accuracy can (quickly) get to 95% or better. And the best can be pre-configured with domain models that can jump-start the classification process and often get up to 80% accuracy with no training on reasonably clean data.

But the way these algorithms typically work is that data is fed into a neural network or cluster-machine, the outputs compared to a domain model, and where the statistical-based technique fails to generate the right classification, the resulting score is analyzed and the statistical weights or boundaries of the cluster modified, and the network or cluster machine re-run until the classification accuracy reaches a maximum. But in reality, what needs to happen is that as users correct classifications in real-time when doing ad-hoc analysis in derived spend cubes, the domain models need to be modified and the techniques updated in real time, and the override mapping remembered until the classifier automatically classifies all similar future transactions correctly. This requires the implementation of leading edge “AI” (which should be called “AR”) that is seamlessly integrated with leading edge analytics.

In other words, while building any analytics application may have been a significant challenge last decade when the by-gones were still challenges and the stumpers required a significant amount of brain-power and coding to deal with, that’s not the case anymore. These days, the only real challenge is real-time reclassification, visualization, and reasoning on very large data sets … even with parallel processing, this is a challenge if a large number of records have to be reprocessed, re-indexed, and derived dimensions recalculated.

But, of course, the challenges, and lack of, don’t end with analytics. Stay tuned!