Two weekends ago we informed you that Your Chrysler Will Drive You Off the Road.
This weekend we bring you a public service announcement from xkcd.
Self-Driving cars don’t even have to be hacked to drive the wrong way!
Please listen to Great Grandpa LOLCat and ride a bike instead like Jr. does.
As long as it doesn’t go app crazy. For years the doctor has been hearing about how mobile is the next big thing in Procurement, and even though mobile hasn’t really caught on, now a handful of vendors are staring to talk about how apps are the next big thing in Procurement. This is a bit ridiculous. When it comes to Procurement, there’s not an app for that. Can you really get market intelligence from an app? Can you really do spend analysis in an app? Can you really do should cost modelling in an app? Think about what “apps” on your “smart”phone really do. Take a few notes. Convert a few units. Play a simple game. Check your bank balance. Store your boarding pass. Simple, discrete tasks. Nothing about strategic sourcing or enterprise Procurement is app friendly.
But enough ranting. Today’s post is about how B2B can learn from good B2C technology. In particular, how B2B can learn from B2C for:
These days, thanks to a number of web sites, consumers are becoming smarter when it comes to analyzing the total costs associated with big purchases like cars and houses as a number of sites, including AAA/CAA and BoA/CMHC, have calculators that allow the buyer to understand the total cost of buying, and maintaining, the vehicle or house they are considering including taxes, insurance, and other incidental costs. These consumers, who are not experts in car or house buying are using templates built by people who are experts to do total cost calculations.
B2B Procurement can learn from this and create sourcing and procurement platforms that come with built-in cost model templates for common categories of direct goods and RFX templates that can be used in sourcing common indirect categories to ensure that the organization asks the right questions, collects the right costs, and makes the right decision. The reality is that across an industry, indirect spend categories are common and there’s no reason that an organization can’t source a solution with pre-built templates for the common indirect categories it sources, which will likely constitute 90%+ of indirect spend. Unless the category is high-dollar, there’s not much point paying a large amount of money to a third party organization, even if the third party is an expert, because it is not likely that the savings will be enough to justify the cost. For most indirect categories, this is likely to be the case.
In 2009, AMR did a study that found that, in an average organization, 30 cents to 40 cents of every negotiated dollar of savings never hit the bottom line. There are a number of reasons for this which include, but are not limited to expedited shipping, volume increases, and maverick spend. In many cases, the biggest culprit is the latter — maverick spend. Maverick spend typically happens because a purchaser is unaware of a contract, unaware of how much it costs to buy off contract, or frustrated with the difficulty of buying on contract with current systems. (It can also be the case that the purchaser doesn’t care because they’re not in Procurement, but this usually isn’t the case.)
This situation can easily be rectified by incorporating some features of best-of-breed consumer shopping technology, such as that employed by Amazon.com, that not only allow a buyer to find the product or service they need, but see which of those are on contract. In other words, just like a search on Amazon.com can find all instances of that book you want, and, if you desire, only show you those eligible for Prime, a Procurement platform that enables a buyer to find all instances of a product they are searching for in an integrated catalog that contains all products and services available from approved vendors — whether in a punch-out site, an online database, or an offline catalogue (maintained by Procurement) — and see which of those are on contract can enable on-contract requisitions and purchase orders. Plus, since it will be easier to buy on-contract than to buy off-contract, there will be a lot less circumventing of the system.
And when it comes to collaboration, B2B can actually learn from best-of-breed professional, and even social, networks and communication platforms. For example, Linked-In not only allows a user to post their resume and connect to fellow professionals, but it also allows them to join discussion groups that allow them to post relevant information on a topic and comment on it. And sites such as join.me and Webex allow for real-time virtual meetings and collaboration.
Incorporating these types of technologies into a Procurement Project Management program allows for collaboration to not only take place on line, but all collaborative communications to be maintained and archived in the platform. This not only helps with conflict resolution, but it goes a long way to preventing disputes in the first place as the platform captures all communications and allows each party to see what it agreed to.
B2B technology can be improved by taking the best B2C innovations and appropriately incorporating them into B2B platforms, but it has to be done intelligently. Not all consumer technology is B2B appropriate, especially if it was designed for C2C purposes, and apps are prime example. However, as it has historically been the case that many innovations start in the consumer space, it’s no surprise that B2B can be improved by appropriating appropriate consumer technologies. It just has to be the right technologies appropriated in the right way and put to the right use.
Only with trying to fix a continuous process to a discrete point in time.
Confused? Let’s back up. Last Friday the doctor‘s co-conspirator in the definition of Contract Lifecycle Management (CLM) went on a rant about the use of upstream and downstream without a paddle in contract management. In his Friday rant, the maverick claimed that if you put supplier management in the upstream bucket, you’ve violated the whole naming convention and that upstream can have a time dimension to it and represent earlier processes, but it can also have a supply chain connotation and represent multiple tiers farther upstream in the inbound supply chain – working back to raw commodities. So, it’s confusing in that regard in terms of time vs. space. However, the maverick‘s biggest gripe seems to be it puts the signature of the contract artifact as the singularity of the procurement universe – sort of like using B.C. and A.D. to define world history to non-Christians.
So what? We need a way to measure time and a milestone against with to measure progress.
As humans, we don’t know exactly when we first evolved (or, if you follow a religion based on a form of creationism, were created), so we can’t choose that date as a reference point for a precise timeline. We barely have decent records back to 0 AD, and if we go back more than a few hundred years beyond that, we don’t really have enough to establish a good date system. So the date chosen is just as good as any other date during that period.
Similarly, if you look at the full contract lifecycle, just when does the project start? When is the first analysis or opportunity identification performed that leads into the business case. Hard to say. We know the date a sourcing project is approved, but just like 0 AD, before that gets a bit fuzzy, but there could still have been significant events that led to approval which are really part of the Procurement process and which should not be overlooked just because a date can’t be fixed. Similarly. When does it end? The date the contract officially finishes? The date the post mortem is done? The date a new contract is signed? The date the switchover actually occurs to a new supplier? The date the supplier is officially retired from organizational service? Hard to say.
So choosing the date of signing as a reference point is a logical choice for dividing up the process and English commonly uses the same word to mean different things in different contexts so there’s no reason it shouldn’t be clear when someone is talking about upstream in the contract/category management process and upstream in the supply chain. (After all, we live with sourcing and sourcing in Procurement is much different than sourcing in HR.)
In other words, the definitions make sense and since they are now commonly accepted, let’s not bicker about how they are defined but about how some providers and analysts tend to misuse them by trying to fix-point activities that actually need to occur throughout the process, like category management, supplier management, compliance management, and risk management. Use upstream and downstream to indicate when particular activities in a process should occur, not to categorize processes that exist simultaneously with the contract lifecycle, and that build off of the primary artifact, the contract, in new and interesting ways (when done right).
Not everything fits in a one or two dimensional model, and we need to be prepared to accept the true complexity of the situation. That’s why many tenders these days are complex and why organizations that don’t have spend analysis can’t identify the inherent complexity and why organizations that don’t have strategic sourcing decision optimization can’t adequately deal with the complexity. Just like the world is not flat, neither is the sourcing model or the necessary execution process that follows. A spreadsheet won’t cut it and neither will point-in-time processes. However, we still need fixed points in time to measure against (forward and back), and at least the date a contract is signed is a point in time everyone across all departments in the organization can agree on.
In Part I, where we noted that Mr. Smith was right in his recent post on “thinking of building your own esourcing system please don’t” over on Spend Matters UK where he pleaded with those organizations, and particularly those organizations in the public sector, who thought they could build their own e-Sourcing system not to. We gave a host of reasons on why they should not because, like Mr. Smith said, they are
Realizing this isn’t enough to convince the smuggest and most deluded from considering the notion, we are diving in and addressing some of the difficulties that will have to be conquered, one primary module at a time, ending today with Decision Optimization.
The simple fact alone that there have never been more than seven software providers on the market at any time selling a true strategic sourcing decision optimization (SSDO) platform, compared to the dozens that have offered spend analysis and the hundreds that have offered some form of e-Negotiation should be enough to make you cower in the closet and pee your pants. But if it isn’t, let’s start by examining the requirements for a true SSDO platform, as outlined in the e-Sourcing wiki-paper.
As the doctor clearly said in the wiki-paper, the tool must be based on a sound (correct) and complete algorithm (capable of analyzing every possibility, not just statistically relevant or likely possibilities) that analyzes an accurate representation of the problem and not a (heuristic) simplification thereof. Generally speaking, a decision support tool built on mixed integer linear programming or constraint programming techniques will meet these rigid requirements and provide true decision optimization while tools based on heuristic techniques, evolutionary methodologies, or simulation models will generally not meet these requirements. In other words, you need top notch A+ mathematical knowledge and computing theory knowledge in the operations research, logistics, and sourcing domains, and these individuals are very few and far between. We’re talking a rarity of about one in ten million. Do you really think that individual is in your basement wasting his life doing your IT support? Really?
True cost modelling is more than just breaking a cost component down into a list of factors and asking for a value. Many cost factors are dependent upon sophisticated calculations, such as fuel surcharges based upon the distance and the weight or contingent labour charges with overtime calculations, expenses, etc. Complex formulas will need to be supported, and the logic just to determine the proper evaluation sequence will be quite sophisticated in itself.
And what-if capability is more than just making a copy of a scenario and changing a cost or a constraint, it’s the ability to compare scenarios side-by-side and understand the driving forces behind the cost and the award. Why is the constrained scenario 10M more than the unconstrained scenario? Which constraints are driving the costly award? What is the true cost of a constraint — it’s not just dropping the constraint and seeing how much is saved. That’s the cost of the constraint when all other constraints are present. It’s really the cost of the constraint against the unconstrained scenario. And so on.
But this pails in comparison to constraint support. As per the e-Sourcing wiki-paper, (at least) four constraint types are required, and these are not easy to define (and definitely not easy to build in a real instance of a model against a real sourcing event). For example, complex constraints cannot be implemented by a simple equation (pair). Some constraints require four, seven, eleven, or more related equations in a group of equations to be implemented. And these equations have to be consistent with every other equation in the model, of which there could be tens or hundreds of thousands thereof.
In other words, building the model is an almost mythical feat. There’s a reason there’s never been more than seven vendors offering a true strategic souring decision optimization solution and that the rarity of individuals who can even attempt to do so is at least one in ten million. Sometimes building a strategic sourcing decision optimization model requires as many as six impossible things before breakfast on a daily basis. The definition of a simple model of decent complexity requires about 10 pages of intertwined equation (template)s. They make modern MCNF (Multi-Commodity Network Flow) models look like elementary school math in comparison. In other words, they are about ten times the complexity of the following single page MCNF model (taken from D. Hejazi’s PhD thesis), which is enough to earn you a PhD.
In Part I, where we noted that Mr. Smith was right in his recent post on “thinking of building your own esourcing system please don’t” over on Spend Matters UK where he pleaded with those organizations, and particularly those organizations in the public sector, who thought they could build their own e-Sourcing system not to, we gave a host of reasons on why they should not because, like Mr. Smith said, they are
But we know this isn’t enough to convince the smuggest and most deluded from considering the notion. So we are diving in and addressing some of the difficulties that will have be conquered, one primary module at a time, continuing with e-Negotiation, which encapsulates e-RFX and e-Auction.
An e-RFX system has the following key requirements:
And an e-Auction system has the following key requirements:
Let’s start with the flexible construction requirement for RFX. Since there are dozens of vendors with decent e-RFX solutions on the market, one may fool oneself into thinking that this is easy. And while it is easier to build an e-RFX solution than just about any other Sourcing (or Supply Management) platform, if usability is a goal, it’s still not simple or straightforward. Qualification questionaries could contain a dozen sections with dozens of questions each. Advanced tabbing and pagination with dynamic expansion and compression depending upon answers and level of detail needed is an absolute must. Moreover, most supplier organizations will require input from multiple people to complete the RFX (sales, finance, production, etc.) and will need to assign parts, but not all, of the RFX to different individuals so fine-grained roles-based security will be required on the supplier side as well as the buyer side with organization, department, and user level settings and overrides.
Now let’s jump over to the flexible lotting requirement for e-Auctions. Sometimes a buyer wants to put a single product (such as laptops when an entire department is due for upgrades) out to bid, sometimes the buyer wants to put an entire category (such as office supplies) out to bid, and sometimes the buyer wants to bundle products and services (such as MRO parts and installation services). And sometimes the buyer wants to put all of these lots into a single multi-round auction. Capisce?
In addition, both platforms will require the ability to define user-defined weightings against each survey response and bid so that the buyer can compute a weighted score for each supplier or lot. And these won’t always be simple — especially if the buyer wants to weight a fuel surcharge based upon product weight and supplier region. That’s not a simple modifier, that’s a formula. And these formulas can get pretty complex in complex tenders created by a sophisticated buyer.
Moving back to the auctions, we also have the requirement that the auction must be customized each time against a host of parameters that will include, but not be limited to, bid floors and ceilings per item and lot, minimum decrements, automatic time extensions, minimum time between bids for a single supplier, and so on. Furthermore, all of this must be evaluated in a system that supports …
Real-time Distributed Communication with Fault Tolerance. In an e-Auction, multiple bids are coming in at the same time, multiple updates must be pushed out at the same time, and formulas and weightings must be calculated and updated in real time so each supplier sees their true relative rank, and not just their true relative bid. This might sound easy-peasy, but you have to remember that even the average CS graduate has trouble with programming for concurrency. (Remember, the doctor was an academic in his former life and knows this to be true. Most Universities care more about $$$ than knowledge conveyed, most untenured professors care more about publishing, as opposed to perishing, than teaching, and most tenured professors are worn out and just don’t care. As a result, as long as the program is able to read the test data and create the right output, in one case, that’s enough for a pass. It’s sad, but true.)
And while this is just a high level overview of the challenges, the hope is still that it is sufficient enough to convince you that development is not an easy task and not an idea that the average organization should remotely entertain.