[kictanet] PROVIDERS CONTRACT WITH SOFTWARE VENDORS

Sat Sep 10 22:18:38 EAT 2011

Dear All,  As we all continue to embrace Digital Home I thought I share a some background of software vendors.  I have been a software developer then an architect and now a salesman... Live it all
When providers contract with vendors, they expect certain products and services. This much is obvious. The issue presented here arises as a result of all the distributing, bundling, packaging and rebadging of products.
Vendor A may offer Vendor B's product alongside its own products. In this case, Vendor A is a distributor (and usually a reseller) of Vendor B's product. Typically this type of collaboration exists when the two products perform related tasks for the provider. Like ice and your favorite drink, each is good, but together they are great!
Vendor X may offer a product called "IndiaOpenEMR" that also has some type of label like, "powered by InsureWare" or something to that effect. This probably means Vendor X has InsureWare's software embedded in its product, and the "powered by" refers to this fact. In this case, Vendor X is sublicensing technology developed by InsureWare.
In each situation, the provider gets the package deal and the functionality it is seeking, which would not be possible with only Vendor A or Vendor B in the first instance or with only Vendor X in the second.
So everyone wins, right? Hopefully, but maybe not.
When things go well and you have a great prime vendor that really steps up and fills that role, life is good. The provider gets precisely what they signed up for. They have a single point of contact for resolution of problems with any of the products involved.
But what happens when things go wrong? Are the responsibilities and procedures clearly set out? Key contract components that must be addressed fully by all vendors involved include support obligations, copyright / patent protection, indemnification, and liability provisions, to name a few.
How does the provider determine exactly what they are getting and precisely whom they are dealing with?
One simple way to determine the "who" part is to look for the warranty of ownership. Something like, "Vendor warrants that it owns the software." Once you find that section, really analyze it. It is probably not more than a sentence or two, three tops.
If the vendor warrants that it is the developer and sole owner of the technology being licensed, then you are dealing with a single vendor and its products. This is the cleanest, most simple scenario.
(Quick sidebar here: it must be a warranty, not a representation. Warranties have certain protections and remedies that representations do not.)
If the vendor warrants that it is the owner of the technology OR that it has the right to license it, that is your red flag duct taped to a flashing light. This is not bad, but it means the product contains or is packaged with third-party software. You need to be aware of this and you must obtain certain crucial contract terms for your protection.
The best-case scenario (keeping in mind that there is another vendor involved that is not a party to your agreement, which is the reason behind this article) is a warranty from the vendor that you are contracting with that it has warranties of ownership, operation, and error correction (for example) from the other vendor. This is critical because it can then be used to back up the same warranties from your selected vendor to you.
The biggest warning flag you could ever encounter is where there is a disconnect in the protection(s) offered. If the vendor warrants that "all software is great and works fine and they will fix everything, but this warranty does not apply to a certain line item or product," then you have a problem. What happens if there is a failure with the excluded software?
If you have no answer while reviewing contract language, just imagine the discomfort you will feel if your system is down and all indications point to the excluded product.
OK, stay with me here. All the legal stuff aside, what those in IT really want to know is what happens if there is a problem with the products.
As stated before, with a solid prime vendor you are in good shape. But what about those unfortunate situations where fingers get worn out from all the pointing?
To try and avoid heartburn later, fix the contract up front. Try this simple exercise. Remember connect the dots, those partially finished pictures in coloring books with numbered dots? Connect them in numerical order and complete the picture! Give it a try with your software agreement.
If you have more than one vendor involved, just imagine a system crash, and then try to connect the dots to all the vendors, especially the vendor behind the scenes. Do you have adequate warranty protection? Do procedures exist for escalating a software problem to the correct level at the vendor? Can you get to the vendor at all??
Make clear for each product included, or component thereof, which vendor is responsible for support, updates, fixes, etc.

Make certain that you have contract pathways to obtain that service. Assume vendor A is first point of contact. When the problem ultimately is identified as residing in Vendor B's product, then what? It may be that the responsibility remains with Vendor A, but it also may be that Vendor A is only responsible for "Level 1 Support" and then you go to Vendor B for the difficult stuff. Ideally Vendor A stays involved and shepherds the issue through to resolution, sort of like a new car warranty. Inga's Cadillac dealership did not build the car, but when the car breaks down, you take it back to Inga's to get it fixed. Inga's then takes care of the work required and is backed up by the manufacturer.

Taking the car analogy a little further, in terms of your contracted vendors, while you may know who is in the driver's seat, you may not know who else is along for the ride. It could be an awesome two-seat Tesla roadster with two great vendors, or it could be the mud-covered SUV with a bunch of buddies all saying they work together just fine (and the driver is wearing really dark shades.) Due diligence in contracting pays off, and lack of diligence can really sting you later.
Vendors, please make it clear. You know best what is going on. Put it right out there.
In 2006 I lived in UK for 1 year working for a company called Cerner, I still remember a situation where an executive at a monster hospital chain felt something had been "snuck in." In reality it was not, but the impression stuck hard and fast in this executive's mind and we had to face extra scrutiny for several years to follow. Kind of like a dog that gets whacked by something at one of those birthday parties where twenty kids are running around screaming and things get zany and someone hands a whiffle ball bat to the kids for the piñata. Anyway, the dog gets whacked (accidentally, of course) and never forgets the kid that did it. Don't be the kid with the bat!

Tangential issue: get a warranty that states no other software is required, from your prime vendor or any other vendor, for operation of the software products being licensed. If other software is required but not included, require a listing in the agreement of all such products. Failure of your prime vendor to include something on this list should mean the vendor has to pony up and pay for it. That will bring all the fine details right to the top.
Finally, once you get everything above all set, make sure that all your hard work does not blow away in the wind because a vendor subcontracts work or assigns the agreement to another vendor. Include provisions prohibiting assignment or subcontracting without the customer's agreement. That way you know what you are getting, from whom you are getting it, and that things will stay that way unless you agree otherwise.
Please take care in your interpretation of this article. I have been involved in countless good situations involving multiple vendors and very happy customers. When the provider does get a good prime vendor that truly takes on its role, you win. No question it works well in the right situations. My point is to be diligent and try to avoid bad situations by at least having good contract language on your side. The combination of a poorly performing vendor and weak or lousy contractual support will really ruin your day.
Big takeaways:
*         Contract language, warranties, and obligations should be consistent as applied to all products and vendors involved, even if designated to a prime vendor. Watch for disconnects in supporting language.
*         The contract should map out clearly the support chain and obligations of the vendors involved, again, even if designated to a prime vendor.
*         Require listing all software required for operation of the products being licensed and obligation for the vendor to provide whatever they failed to list.
*         Prohibit assignment and subcontracting by the vendors without your consent.

Just two cents!

Titus Ngeno

________________________________

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.kictanet.or.ke/pipermail/kictanet/attachments/20110910/91355dd8/attachment.htm>