Category Archives: Procurement Innovation

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!

Manual = Money

Leave a reply

Yes, technology costs money and five and six figure technology purchases look expensive, especially if a vendor is asking for payment up front, but it’s often the case that not having an automated technology solution as a mid-size or large organization is costing your organization even more. The reality is that anything not automated has to be done by someone, and having that someone do a task costs you a lot of money. Even if that someone is a (near) minimum wage resource. Remember, it’s not just the $15 an hour, $120 a day, $600 a week, $30000 a year that resource costs, but it’s all the overhead associated with that resource. Benefits. Training. Office space. Equipment. Opportunity cost of NOT having them work on more strategic tasks. Etc. When you do the math, that $15 an hour / $30000 a year resource is likely costing you closer to $30 an hour / $60000 a year. If the solution costs less than 30K a year, and replaces one FTE that’s not only a savings, but another resource you can reassign to value identification and generation (which never comes from doing tasks that can be automated).

But in Supply Management, the solution can often replace 3, 6, 10 or even 50 FTEs with very little incremental processing power required. A great, and often repeated example, is invoice processing with m-way (typically 3+) way match and auto-return to supplier for completion of missing information and correction of (potentially) incorrect information. These systems can review these invoices 100% and often, through auto return and correction, reduce the number of invoices that need human review to less than 2%. For an organization that receives 50,000 or more invoices a year, with dozens (or hundreds) of line items per invoice, where a team of 3 people can only fully review 20% and spot check a few lines on 20% more, this system, if in the 50K price range, has an ROI 10X its cost as it allows all invoices to be fully reviewed and verified before being paid — something that would otherwise take a team of 10 people, who are more error prone than the system and will still miss issues that need to be reviewed.

But it’s not just invoice review in Procurement that takes a huge amount of time, and never gets finished. It’s data entry and maintenance. Catalogs. Supplier Masters. Approved products and bill of materials. Preferred products. An average organization has tens of thousands of records that need to be created and maintained over time. Larger organizations have hundreds of thousands. And the annual maintenance of each record is so time consuming that the cost to accurately maintain this data (and keep it up to date) is literally in the hundreds of thousands of dollars, if not millions. (the doctor once read a thesis that estimated the average annual cost at about $2 a record, and with the increased rate of data change, that actually seems to be on the low side). But a system that allows suppliers to maintain their data, automatically updates the data from one central, verified, repository (provided by the supplier or vendor), etc. can greatly reduce this cost while increasing the accuracy.

And it’s not just tactical Procurement that requires a lot of manual effort. It’s also, believe it or not, Sourcing. A lot of categories that should be strategically sourced can be mostly automated. Especially the lower value, market-driven, and non-strategic categories. Often, the best strategy is just a winner-takes-all auction or a 60/40 split between the two best RFPs, where the bidders can be limited to pre-approved suppliers (and products) in the first case (with ceilings) and pre-approved suppliers in the second. These events could be automatically configured and, once reviewed by a buyer, automatically launched and executed and, once the results reviewed, automatically awarded. The entire process, which often takes days in some platforms, could be accomplished in an hour or two, freeing the buyer up to focus on truly strategic and large value categories and new types of supplier consolidation / part standardization / raw-material unification analyses that might yield previously unknown savings opportunities.

In other words, never balk at the cost of a solution until you calculate the true ROI, which is often many times the tactical manpower cost you are replacing (as its often the case the manual effort isn’t doing a complete job). The ultimate goal is to allow your team to focus on value identification and capture, and they can’t do that if all they are doing is manual data entry and review that can be (almost) fully automated.

Demand Control: Reduce, Reuse, Recycle, Redefinition and … Requisition Everything!

Leave a reply

Part of good cost avoidance in Procurement is good demand management — reducing the consumption, and expenditure, on MRO, T&E, one-time buys for events, etc. We’ve covered the classic techniques in the past, which include:

Reduce: which can be accomplished by accurately predicting needs (and reducing waste) based on past use and current trends (and not maintaining volume levels on toner cartridges for a printer line being phased out)

Reuse: which can take the form of repurposing old equipment (as old developer workstations are probably just as powerful as the business user desktops used in the rest of the organization) or simply collecting unused/discarded collateral at an event and using it again next time

Recycle: where MRO inventory can be replenished by breaking down equipment (like workstations, production lines, etc.) that go out of service and harvesting still working parts that can be used in other equipment

Redefinition: where it’s not a need for more paper, but a need for second / bigger monitors so that people don’t need to print invoices / documents still submitted as (scans of) handwritten documents that can’t be OCR’d or that aren’t in a format the OCR recognizes or for tablets that allow executives to access their reports on the go

but a new type of demand management is popping up in the Procurement world, and it’s called:

Requisition Everything: where you have to literally submit a requisition to the procurement system so that all demand, and consumption, is tracked (and you can be visually guilted to control demand or utilization if you are consuming significantly more of a resource than your peer).

Now, this probably sounds very onerous to you and not worth it, but it all comes down to the implementation and user experience. At Coupa inspire, one company described an innovative method that they used to track and control demand on the factory floor (where workers would forget where they put their gloves, or realize they left them in the lunch room, and just go to the closest supply room or where workers would store extra tools or parts at their desks, just in case, leading to low stock signals and unnecessary ordering). They installed vending machines and when a worker needed something, they needed to go to the machine and punch in their id and slot number. Nothing was restricted (and no limits were placed), but every “requisition” was sent to the central Procurement system which not only updated MRO inventory but also tracked who used what, and allowed Procurement, and departments, to understand usage patterns better. This simple process reduced demand as it instilled the notion of cost consciousness and responsibility in the workers (who knew that their usage patterns could be analyzed and if they consumed considerably more than their peers, it would show), and didn’t really add any time or complexity to the process (as all the workers had to do was punch a few buttons) — especially since this process insured that the workers always knew where the stock was (which wouldn’t happen if it was moved around on the shelves).

Moreover, this technique is not limited to what fits in a vending machine — one could also use cheap RFID tags for larger items (of sufficient value) that would automatically be requisitioned when the tag left the store room (and be assigned to the right person using the employee record obtained from the entry control system when the person swipes their key card).

And, with micro-budgeting, it can be used to insure departments don’t go over their allotted new-hire budget unnoticed. New hire equipment can be kept in the secure storeroom, automatically tracked when retrieved, and automated re-orders made if stock gets too low. Plus, reusable equipment can be returned on employee departure, residual amortization amounts credited back to the micro-budget, and employees / departments who opt to use recycled equipment can be charged a deep discount against their micro-budget (and, more importantly, rewarded at annual recognition events as reuse stats can be tracked).

Now that almost everything can be automated, it might just be the time for Requisition Everything as the new method of employee-based demand management and cost control. Thoughts?

Supply Management Technical Difficulty … Part VI

Leave a reply

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.

Supply Management Technical Difficulty … Part V

Leave a reply

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.