Beltug

Negotiating with your software supplier: what can you expect? Takeaways from the USERS ONLY Beltug X-change: 21 Feb 2017


Date:21/02/2017


For this critical conversation on how you can best negotiate with your software supplier, Beltug/INTUG’s 'Proposal for a Software Publishers' Code of Conduct' (CoC) led the way. 

Beltug members can see presentations from the event here (after login):

 

Erik Valgaeren, Partner and head of the TMT/IP practice at Stibbe, gave a brief introduction of the document. The CoC has two goals:

  • To provide a guideline for our members in their negotiations with software publishers
  • To (hopefully) become generally accepted as best practice and serve as leverage towards software suppliers.

At Beltug, we have been quite busy promoting and spreading this document. We are pleased that EuroCIO, the European CIO Association, has endorsed the paper, and circulated it amongst its members.

We sent the CoC to four major software publishers (SAP, Oracle, IBM & Microsoft), asking for their feedback.  So far only Microsoft has responded, opening the discussion. Following our discussions with BSA, that organisation also sent the CoC to their members.

Erik discussed the legal relevance of the CoC. Don't forget, he stressed, when talking about 'buying' a software licence, there's no transfer of ownership! Software audits continue to be a source of frustration. The communication between software publishers and their customers remains difficult - both parties clearly speak different languages. Erik discussed that, while protection of intellectual property is an additional argument in contract or audit negotiations, revenue remains the main driver for the software publishers. They can respond to issues with what could be seen as unreasonable behaviour: court orders, threats to close a customer’s operations until the invoice is paid, etc.

The complexity of licensing becomes something of a Bermuda Triangle: within the companies using the software, there are many different stakeholders and sometimes no overview of who owns what aspect of the licence contract. On the software publisher’s side, as well, there are many people involved. All of this makes the entire software licensing universe a complex tangle of contacts and rules.

The CoC rests on four major principles:

  • Avoiding conflicts
  • ‘Fair play’
  • Protecting continuity
  • Education

Combining these leads to a balanced solution, both for the customer and for the software publisher.

To close his talk, Erik pointed out to a number of ways to make sure the CoC becomes a true legal tool:

  • Use these rules in your own contracts (note: integrate them, don't make the same mistake that software publishers often do by referring to some URL)
  • Operationalise the content of the policies
  • When signing a contract, software publishers must also follow market best practices, not just the rules in the contract itself.  So the market (e.g. you, the users) can make this happen and, over years, turn it into a best practice
  • To get there, we need to distribute this document widely, with a maximum of ambassadors. The document must be applied in practice as much as possible.

It all starts with a sale, Pieter De Meulenaer, responsible for IT vendor management at AVEVE group, then explained:  a commercial transaction between a software publisher and you, the customer. This implies a number of things and raises a few questions:

  • It's always about someone’s P&L and someone's sales commission
  • Make sure you don't get trapped in a long vendor lock-in
  • What is the role of the integrator, and the advantages and disadvantages?

As a customer:

  • Who are you as a customer? In the broadest sense, this gives leverage.
  • What exactly are you buying? What will you use the software for?
  • Who exactly will use the software?
  • What's next? For example, what if there is a transfer of a part of your user base?

'Ceci n'est pas une pomme', Pieter winked to René Magritte's famous painting: you're not buying an apple. Pieter emphasised that the product you procure should be described in full detail - not just in marketing terms. Use unambiguous language, be as specific as possible, and try to future-proof your language.  Describe the 'intended use' of the software you're about to procure.

When offered a bundle with the software you purchase (slide 20), there are usually some elements of no value to you.  Often the bundles change, and elements are packaged differently. And too many times the elements in the bundle are not separable, so make sure you don't pay for what you won't use!

Finally, never forget: your software purchase is an agreement!  Make sure that agreement is clear and structured from the beginning:

  • With little room for interpretation
  • As-is, fixed at that moment in time
  • NO unilateral changes
  • Etc.

Piet Herman, Former Head of Procurement Contract & Risk at BNP Paribas Fortis, continued with an overview of the technical recommendations in the CoC.

In the lifecycle of your software, he visualised (slide 25), you can foresee and predict a number of things: new functions, major upgrades, etc. Within that same lifecycle, adoption by your users will go up and you will see an increase in added value.  At some point, usage will decrease again. Calculating the delta between the added value and the cost will allow you to weigh whether the software is still worth the money or not.

Piet showed a number of metrics that matter when managing your software contracts:

  • Exclusivity
  • Assignment
  • Term
  • Territory
  • Volumes
  • etc.

Keep in mind, he emphasised, you are a customer, not simply a 'licensee'!

To conclude, his final slide (slide 29) showed a schematic overview of the technical guidelines in one 'glance'.

To round out the discussion, our last (but not least!) expert on the agenda was Nicolas Volckaert, also an expert SAM Manager.  When faced with an audit, never panic, never show fear, he began.  Keep calm and even if you're not a full-blown expert, boast a little.

But first of all: be proactive with your software contracts!  Make sure you have clear metrics in your agreement (no URLs!) and include the obligation to inform the customer (you!) about changes in the licence or general terms and conditions. And be sure to amend audit clauses in your contract (an example of such a clause: who is the auditing party?  You don't have to accept ‘any’ auditor.)

‘Be prepared!’ was his next call to action.  Make sure to have an Audit Playbook ready that includes:

  • An overview of your contract (know your metrics and how to measure them, what are the features, etc.)
  • Your compliance (check it yourself once or twice a year)
  • An audit process within your organisation, that is agreed upon by your stakeholders
  • A definition of the tools you will use to measure compliance
  • A tool in place that you actually use to measure your compliance.

And if you are audited: be prepared to settle, because let’s face it: an auditor will always find something.  But negotiate hard and don't hesitate to use delaying tactics.

"Yes, you can!" avoid audits, he concluded:

  • Negotiate your contracts well
  • Show that a mature SAM practice exists within your organisation
  • Demonstrate your compliance proactively
  • Involve the vendor in your licence discussions for new designs
  • Have a Vendor Relationship Management practice in your company.

 

 

 

 

 

 

 

 

 



 

Dear visitor,

Access to more information about this topic and/or to download the paper is easy and fast, but exclusively for Beltug members (just login to get access).

Beltug gathers a lot of information. Here you find the advantages of Beltug membership

The Beltug Team

Click here to login




>>> Back to overview