Category Archives: contract management

Tired of Yo-Yo Contracts? Fix the Price with an Indexed-Based Model

When markets yo-yo, so do buyers and sellers … and they waste time, and money, doing so. When prices fall, buyers scramble to cut new contracts to obtain better prices and mythical “savings”*. When prices rise, suppliers scramble to exit contracts to get better prices from other buyers. And when prices yo-yo, it’s a never-ending renegotiation dance that does nothing but waste time, and money, especially when there’s an easy way to lock in a contract for the long term that allows both parties to win. It’s called the Price Index(ed) Contract, and in this post I’ll explain how you can lock in a contract that will protect both parties and allow you to avoid the renegotiation dance … which will allow you to focus on more categories and new, and better, cost savings opportunities.

The first thing to do is to build a should-cost model that captures all of the major price components (> 5%, if not > 10%) using current prices, drawn from an index. We’ll use a (hypothetical but representative) cost breakdown for a 30kVA power transformer, since we all need power, as the foundation for our example.

 

Cost Amount Percentage
Steel 1055 34%
Labor&Overhead 620 20%
Misc 560 18%
Copper 530 17%
Oil 215 7%
Transportation 125 4%
3105 100%

 

This tells us that our primary cost components are steel, labor, and copper and that oil would have to to fluctuate 5% to have the same impact as a 2% fluctuation in copper and 10% to have the same impact as a 2% fluctuation in steel. This also says that if our threshold for negotiating a contract is a minimum cost reduction of 5%, that oil would have to fluctuate 70% for us to even consider a renegotiation. Given that rampant runs, like the one which we just experienced where oil tripled and fell back to the baseline in less than two years, historically only happen every few decades, and that labor costs tend to increase rather predictably with inflation, it also tells us that we should only be concerned with steel and copper costs.

There are market based indices for both steel and copper, the CRU is one example of the former and the New York Futures Market is one example of the latter. At least one of them will, on average, correlate to the prices that your supplier consistently plays for steel just like at least one of them will, on average, correlate to the prices that your supplier consistently pays for copper (which depend on their contracts, leverage, and the market(s) they buy from). You just have to agree on one.

Then, you can tie your contracts to the index and word them to automatically adjust prices on a monthly (or quarterly) basis using the impact of market price fluctuations on the should cost model. Since steel accounts for roughly 34% of the cost, if you agree to cost a increase of 1% for every 3% increase in steel cost, you won’t have to worry about your supplier having to choose between reneging on your contract or financial ruin in a bull market and if your supplier agrees to a cost decrease of 1% for every 3% reduction in steel cost, he won’t have to worry about you having to choose between finding cheaper sources of supply or risking financial ruin due to your inability to compete with (unrealistically) high costs. Similarly, if you agree to a cost increase of 1% for every 6% increase in copper price and your supplier agrees to a cost decrease of 1% for every 6% decrease, neither party loses — and more importantly, both parties win. In bull markets, your supplier gets to pass on the raw material cost increase — and only the raw material cost increase (as you both know the cost, no ridiculous mark-ups), and in down markets, you reap the savings without having to go through a long, time-consuming, wasteful renegotiation.

This works for any category you can think of, allowing you to lock in 1, 2, 3, and even 5 year contracts (on non-strategic categories) without having to worry about lost opportunities or overpayments. The only thing you have to do is check the indexes once a month (or quarter) on the date you both agree to “reset” the prices for the next month (or quarter) to make sure your supplier is holding up their end of the bargain. And you can even use this model to take into account financial costs, such as foreign exchange rate assumptions (if raw materials or components are being bought in a foreign currency) or finance assumptions (if part of the product or transportation cost needs to be financed). So build a should cost model and get that yo-yo off your finger.

* There’s no such thing as “savings”. “Savings” is just money you shouldn’t have spent in the first place. (And that is why “cost avoidance” is more important than “cost reduction”, despite the refusal of many old-school diehards to recognize that fact.

Optimizing Your Procurement Technology Investments

The Sourcing Interests Group recently ran an interesting article on “optimizing your procurement technology investments in 2009”. Although it had some good suggestions, my top five suggestions would be the following:

  1. Get Visibility Into Your Spend (Spend Analysis)
    If you don’t know how much you’re spending on each category, sub-category, product, and service, who you’re spending it on, in what amount, by unit, you need to get this visibility. Get a good spend analysis solution and dive in!
  2. Take Your Strategic Sourcing up a Notch (with e-Sourcing)
    Start with the most attractive savings opportunities that were outlined in step 1. This is your best bet to negotiate big savings in this downturn.
  3. Focus on Contract Compliance (adopt Contract Management)
    You need to enforce hard-won savings by insuring that internal staff and suppliers are compliant with contractual agreements.
  4. Implement e-Procurement
    Done right, this will make it easy for your buyers to buy on contract.
  5. Get a Grip on Global Trade (adopt Trade Visibility solutions)
    Chances are your global sourcing endeavors are needlessly costing you more than you think! As per my recent Illumination on why you need trade visibility, you’re probably paying more than you need to on duty, using costly inefficient processes, paying unnecessary document preparation costs, and making costly errors that are costing you million of dollars a year.

Fine-Tune Your RFPs for Streamlined Performance (Software Acquisition Insider Tips VII)

A recent article over on Supply Management . com on “going faster” pointed out many of the problems with RFXs that cause unnecessary process delays. Fixing these problems will enable your RFX process, which you now know how to construct in an unbiased fashion, to flow smoother and faster.

  1. Poor Scope
    The scope is not clearly defined at the start of many RFP processes. “A solution to automate our purchasing” is extremely vague as is “50,000 boxes”, which a quick trip to cBoxBid will quickly point out. (Dimensions? Style? Weight/Flute? Glue Tab? Printing? Color? etc.) The scope needs to cleary define what is required (automation of purchase order creation, invoice collection, and e-payments or 12″*12″*8″ boxes that can hold at least 45 lbs) and the desired outcomes (automated tactical processes with m-way matching and manual review only required on discrepancies and purchases over administrator defined thresholds or 5,000 boxes per shipment with 21 days notice).
  2. Lack of a Performance Regime
    The long-term success of a major contract will depend on a mix of “hard contractual” and “soft behavioural” factors. It is imperative to define success via a comprehensive performance regime with a simple hierarchy of performance measures and targets, and a mechanism for rewarding good service and deterring underperformance.
  3. No Team Empowerment
    Like every other sourcing and procurement activity, a successful RFX (process) requires a dedicated and fully supported team. A core team, authorized to make the necessary decisions, is required throughout the process and beyond to ensure consistency and clarity with the bidders.
  4. The Contract is an Afterthought
    The RFX should be presented in a format that matches the product or service being requested and should fully explain the selection process, the evaluation criteria, the rules of engagement, the delivery schedule, and the terms and conditions. In other words, the contract (template), which should clearly specify what is and is not negotiable, should be drafted up front and presented to all participants. Otherwise, you might work through a long, laborious RFX process only to find out that the winning bidder(s) can not, or will not, agree to your terms and have to go back to the drawing board.
  5. The Process is Not Managed
    The largest risk in any RFX process is a misunderstanding, and the sad thing is that this is very likely if sufficient information is not made available to the bidders and the process is not managed. It’s important to manage the process and communicate with the bidders at each step to make sure they have received all of the materials, understand all of the requirements, and have all of the information they need to craft their responses. The process should include regular briefings, review meetings, and question and answer sessions to insure that it flows smoothly.

SaaS Contractual Considerations: Part II

Despite the claims to the contrary from the monolithic on-premise players who are threatened by the new platform and all of the advantages it has to offer, SaaS is gaining momentum. The best evidence I have to offer is the rate at which analysts and bloggers, including yours truly, are getting inquiries into how to evaluate these offerings from a functional and TCO perspective and how to construct the contract. And it’s not just buyers who want to know what needs to be in the contract to protect their investment. Providers also want to know what clauses they should be including to protect themselves as well.

As I am not a lawyer, I cannot claim to be an expert on contract construction of any kind, but I can claim to be very familiar with IT contracts (as someone who has always handled his own and been involved in their construction and review at a number of companies) and to have considerable knowledge with regards to issues that need to be addressed on both sides of the table. Thus, I give you the doctor‘s top issues for consideration when negotiating your next SaaS contract in addition to the standard issues of term, fees, liability, representations, warranties, confidentiality, insurance, indemnity, rights, relationship, dispute resolution, publicity, and government law that your lawyers will remind you of in every contract drafting. Today, we’ll focus on the supplier:

For the Supplier:

  • We’re Not Responsible for Your Network
    You are responsible for your software and network, and not your client’s software and network. If your client’s ISP goes dead, not your problem. If your client’s router starts acting flakey and randomly blocking required ports, not your problem. Your support requirements cease the minute you are able to demonstrate the problem is not on your network.
  • We’re Not Responsible for Your Systems
    As a provider you are responsible for your software and your network, not your client’s software and network. As long as you provide the client with a complete list of compatible software products and supported versions, and the client agrees to it, you’re under no obligation to support the client should they choose to use other products or upgrade to non-supported versions before you have certified that such products are compatible with your system. I.E. if IT upgrades all the browsers before you certify them as compatible, and your system doesn’t work, not your problem if the client agrees in the contract to only use, and expect support on, pre-agreed browsers and supported versions thereof. Of course, in fairness, you should expect to have to support new versions within a certain time-window and agree to do so within a realistic time-window.
  • We’re Only Responsible for the Security of Data in our Systems
    You’re required to follow industry standard best practices around data security and insure that all confidential and personal information on your systems is appropriately encrypted to the level of security agreed upon in the contract. However, you’re not responsible for what your client does with that data once they extract it from your systems. If they decide to cut and paste out of a secure browser session into an unsecure notepad file on a hacked PC, you cannot control that and have no responsibility for the consequences of such action.
  • We’re Not Responsible for Disasters Beyond our Control
    You’re responsible for your software, systems, and data centers to the extent that you have control. Your Force Majeure clause says that you are not liable for damages if both of your power providers go black or if both of your internet connections get severed because of a natural disaster or other government or terrorist action beyond your control. That being said, if your providers stay dark for more than a short period of time, it’s your responsibility to transition to a backup facility or enable your client to set up a temporary instance of your application in their facility as per the terms that any reasonable buyer should be expected to insist on in the SLA.
  • Standard Rate for Services Above and Beyond our Standard Offering
    You’re responsible for support, maintenance, upgrades and other services you agree to — and that’s it. Although you are happy to go above-and-beyond your service requirements, make it clear that you do not do custom work for free and that any custom tasks or services will be billed at a standard hourly or daily rate on the monthly invoice. Otherwise, the buyer might say “we thought that was free” and put you in a pickle if you hired additional resources to support the buyer above-and-beyond the agreed upon service levels.

Be sure to check out the Master “Software as a Service” Managed Services Agreement in the Procurement-Based Contract Templates, Version 2, that is made freely available to you by Stephen Guth of The Vendor Management Office blog.

SaaS Contractual Considerations: Part I

Despite the claims to the contrary from the monolithic on-premise players who are threatened by the new platform and all of the advantages it has to offer, SaaS is gaining momentum. The best evidence I have to offer is the rate at which analysts and bloggers, including yours truly, are getting inquiries into how to evaluate these offerings from a functional and TCO perspective and how to construct the contract. And it’s not just buyers who want to know what needs to be in the contract to protect their investment. Providers also want to know what clauses they should be including to protect themselves as well.

As I am not a lawyer, I cannot claim to be an expert on contract construction of any kind, but I can claim to be very familiar with IT contracts (as someone who has always handled his own and been involved in their construction and review at a number of companies) and to have considerable knowledge with regards to issues that need to be addressed on both sides of the table. Thus, I give you the doctor‘s top issues for consideration when negotiating your next SaaS contract in addition to the standard issues of term, fees, liability, representations, warranties, confidentiality, insurance, indemnity, rights, relationship, dispute resolution, publicity, and government law that your lawyers will remind you of in every contract drafting. Today, we’ll focus on the buyer:

For the Buyer:

  • Data Export, Backup, & Security
    It’s your data and you should have full access to it 100% of the time and the ability to extract some of it or all of it on a whim with little or no notice to a standard, open format such as CSV, EDI, or XML. Of course, if the provider is hosting your entire ERP system and you have Gigabytes of data, expect to pay a bandwidth usage fee if you plan to do this regularly, or a service fee if you require the provider to back it up to encrypted DVDs or Tape and courier the data to you. Similarly, it’s your data and you have every right to expect it to be secure and available no matter what. Insure that the provider is required to do complete backups at least daily, incremental backups at least hourly, and required to store a copy of the encrypted daily backups in an off-site location.
  • System Availability & Up-Time
    One of the attractions of SaaS is the 24/7 uptime that your average company IT shop, that works 9 to 5 in one time zone, can’t deliver. Make sure the system has a guaranteed up-time of 99.999% when you need it (e.g. between 8 am PST and 8 pm GMT if your users are predominantly in North America or Europe) and that you have at least 99.5% uptime the rest of the time, with scheduled maintenance only occurring in agreed upon time windows with adequate notice.
  • Pay For Use
    The beauty of SaaS is the scalability it offers you and the ability to add or subtract users as needed. Make sure you’re SaaS agreement only charges you for the number of users with active accounts (subject to any minimum number of seats you might have agreed to) on a monthly basis.
  • Guaranteed Response Time
    There’s no perfect software system and something will inevitably go wrong with on-demand just like something inevitably went wrong with your current on-premise system. Make sure that the provider agrees to start investigating all outages immediately during agreed upon normal operating hours for your business and within 30 to 60 minutes otherwise. Make sure they are required to get back to you with progress within a maximum timeframe of 60 minutes and to report on progress on an agreed upon schedule.
  • Escrow & Guaranteed Availability
    You generally select an enterprise system with the intent of using it for at least the mid-term, if not the long term, and if a system works well for you, the last thing you want to happen is for the provider to disappear (either due to financial failure or M&A) and take its system with it. Thus, it’s important to take precautions that will insure that, no matter what, you will have continue access to the system for as long as you so desire. The way to do this is to (1) insist on escrow and immediate access to the updated source code and related documentation which is to include required system architectural designs, complete installation instructions, and maintenance and support manuals that are kept up to date on every release and (2) forced support for a minimum period of time on material change of ownership, including the option to acquire the system from escrow at an agreed upon perpetual (annual) license cost at the end of the the minimum support period if the acquiring company no longer wishes to support the system.

Be sure to check out the Master “Software as a Service” Managed Services Agreement in the Procurement-Based Contract Templates, Version 2, that is made freely available to you by Stephen Guth of The Vendor Management Office blog.