Author Archives: thedoctor

Contract Lifecycle Management VI: Do You Know What The Should-Haves Are?

In Part I of this series, we argued that CLM, short for Contract Lifecycle Management, while seemingly one of the most bromidic acronyms in the Supply Management space, is also one of the most important. This is because, as summarized in Part III of this series, it overlaps S2C, P2P, and, as a result, S2S/S2P as well as intersecting with risk management, performance management, change management, and supplier (relationship) management. In other words, CLM touches almost every aspect of Supply Management and is taking a central place in your Supply Management organization.

However, as noted in previous posts, up until now, CLM has not been well defined and the best definition, which could arguably be that given by Gartner (see Part I), has been, more or less useless, because you already know it’s a good process supported by a great platform. What you need to know is what that platform is as vendors, analysts, peers, and even professional organizations don’t, or won’t tell you. That’s why, in a landmark effort, Sourcing Innovation and Spend Matters, as the two leading independent authorities on Supply Management, led by the doctor, the maverick, and the prophet, have joined forces to define, publicly and openly, the core Supply Management platforms, starting with CLM.

In our previous posts we elucidated the need for a core CM (Contract Management) platform because existing Supply Management systems weren’t enough, and then, in our last post (Part V), we outlined the must-have core capabilities of a CM platform, as discussed at great length in “Core Contract Management” over on Spend Matters Pro [membership required], Part V of the doctor, the maverick, and the prophet‘s landmark ten-part series fully defining CLM.

Today we are going to outline all of the important should-have capabilities of a contract management platform, discuss a couple of them, and then refer you to “The Standard Contract Management Platform”, part six of the landmark ten-part series co-authored by the doctor, the maverick, and the prophet over on Spend Matters Pro [membership required], for an in-depth discussion of each should-have capability.

To make sure there is no confusion, a should-have capability is a capability that, while not absolutely required, significantly impacts usability and performance by the absence of these features and most industry leading contract management solutions will support the majority of these capabilities to some extent.

The following capabilities are should-have:

  • Clause Library
  • Full Text Search & (Legacy Contract) Discovery
  • Collaborative Creation
  • (Fine-Grained) Roles Based Security
  • Contract Workflows
  • Rules Management
  • Contract Authoring via Rules-Based Contract Builder
  • Schedule & Rate Card Support
  • e-Signatures
  • Task Management / Tracking
  • Event Monitoring & Issue Escalation
  • Corrective Action Management
  • Dashboards and Contract Analytics
  • Native Integration to MDM Platforms

As with the set of core capabilities, most of these you probably expect, and for some of these you probably have a fairly good idea why (even if you are not sure exactly what functionality is required for a proper implementation), but a few of these are probably unexpected, including Corrective Action Management and Native Integration to MDM Platforms. We’ll discuss these two capabilities, but refer you to our in-depth piece on “The Standard Contract Management Platform” over on Spend Matters Pro [membership required] for coverage of the rest. (But the must-have, should-have, and nice-to-have function lists will be made, and remain, public as they are the common measuring stick that both Spend Matters and Sourcing Innovation will be reviewing and measuring vendors against going forward.)

Corrective Action Management is critical because issues will always arise during contract execution and they will not always resolve themselves or be resolved by the supplier. And while the organization may have a process for dealing with issues, and even a platform for doing so, those actions have to relate to, and be mapped back, to a contract to not only insure that both parties meet their obligations and performance hits necessary levels, but that resolutions are tracked and performance, pre-and-post issue resolution, is tracked and measured appropriately. After all, not all value in a contract is in the price list — sometimes it’s in the value-add, sometimes it’s in the staff augmentation, and sometimes it’s in the innovation.

Native Integration to Master Data Management (MDM) platforms is important because contracts are with approved suppliers on approved items and services under a well-defined categorization for agreed upon prices and delivery dates. All of this data is defined in existing systems, and much of it (with the exception of agreed upon prices and delivery dates) can come from the Master Data Management [MDM] system (which is generally the ERP, but could be a Sourcing or SRM platform with MDM capabilities). If the integration is not there, then a lot of information has to be manually rekeyed, which introduces considerable opportunity for error that can result in agreements for higher-than-negotiated pricing, slack delivery arrangements, or data miscategorizations that will result in erroneous spend analysis down the road. (Approximately one in one hundred keystrokes is erroneous, and this is one of the reasons that 88% of Your Spreadsheets are Garbage.)

However, every other should-have capability listed above is just as critical to usability and performance, and to understand why, and what the platform has to support with respect to those should-have capabilities, check out “The Standard Contract Management Platform” over on Spend Matters Pro [membership required], part six of the doctor, the maverick, and the prophet‘s landmark ten-part series fully defining CLM.

One Hundred and Forty Five Years Ago Today

The world’s first underground tube railway opens in London, England. IN 1869, a 1,340 foot circular tunnel was dug under the River Thames, running from Tower Hill on the north side to Vine Lane (off Tooley Street) on the south. Then a 2 ft 6 in narrow gauge railway was laid in the tunnel and one hundred and forty five years ago today on August 2, 1870, Tower Subway was opened and a cable-hauled wooden carriage conveyed passengers from one end to the other.

And even though the company that was operating the underground carriage went bankrupt the following year (as it was uneconomical), which opened up the tunnel to pedestrian traffic, and even though the tunnel was closed to pedestrian traffic in 1898 (when it was bought by the London Hydraulic Power Company which used it for water mains), as the Tower Bridge (which was built in 1894) negated the need for traffic, it was still the first underground tube railway and laid the foundations for the City and South London Railway , which were built using the same method of construction.

And one hundred and forty five years later the fog still rolls off the River Thames, obscuring the fascinating history beneath.

Your Chrysler Will Drive You Off The Road!

As per this recent article over on CNN Money, “Chryslers can be hacked over the internet” (July 21, 2015) and hackers can cut the brakes, shut down the engine, drive it off the road, or make all the electronics go haywire.

SI seems to recall indicating that this would happen in the continuous, ridiculous pursuit, of autonomous driver-less vehicles, as per these posts last year on some things should be autonomous, but automobiles and you can have your Google chauffeur. I’ll choose good ol’ Alfred every day of the week?

What do you think LOLCat?

Great grandpa was right. Ride a bike.


Grandpa LOLCat rides a bike

There’s Nothing Wrong With Using Upstream vs. Downstream

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.

Data Analytics is Big Money, But

Last Friday, Palantir raised $450 Million in a new round of funding, at a valuation of almost $20 Billion, making it the fourth most valued “startup” to date with almost 1 Billion in funding including Founders Fund, Tiger Global Management, and In-Q-Tel, the CIA’s investment arm.

But it’s not just big data that generates big money (for the software provider) and big value (for the organization that has [access to] it). It’s big analytic power. And, as SI has indicated repeatedly, the data set doesn’t necessarily need to be that big to identify considerable savings opportunities.

A million transactions might not be more insightful than 1,200 transactions. If the transactions are for 10 different products from 10 different suppliers over the course of the year, a single summary transaction for each month for each supplier-product pair that summarizes the lowest price paid, the average price paid, the highest price paid, and the total paid is just as informative from a spend analysis perspective. Given this data, the buyer can see, for each product, how much money it would have saved if it always bought at the lowest price, how the price is trending, and how much could be saved by using a contract to lock the product in at a price less than the current market price. The other 998,800 transactions are not needed.

In other words while you need large spend cubes to find value opportunities, which will often depend on redefining categories, redefining shipping lanes, redefining delivery schedules, and so on, you can often get away with cubes that are at most, hundreds of thousands of well defined (summary) transactions (for the right time period). Millions of transactions are typically not necessary, and that’s why you can do enterprise wide spend analysis on a laptop with the right spend analysis tool (like busiq.com) as you can generally define a transaction set of just a few million transactions that covers the last three years and fits in memory!