kblogo2.jpg (22694 bytes) kbbkart.gif (3902 bytes)

Wayne is president of Krakau Business Computer Systems, a systems integration firm and has been working with computers for 25 years. He holds an M.B.A. in Marketing and a B.S. in Information Science and was originally educated in Computer and Information Systems Analysis Engineering. He holds CNI and MCNE ratings and all five of the original LANDA Certifications. Wayne can be reached for questions, comments, or topic suggestions at 630-894-3360 or via E-mail to wkrakau at krakau-inc.com. For past columns and company info go to www.krakau-inc.com.

 

 

 

 

 


 

 

 

SOFTWARE & INTEGRATION SERVICE CONTRACTS
 

by Wayne M. Krakau - Chicago Computer Guide, February 1998
 

After having been reprimanded for leaving out the specifics of software and what I call integration service contracts out of my series of columns on service contracts and extended warranties, I decided I had better cover the details of those contracts while the subject matter was still fresh in my mind. Obviously, the quality-of-service warnings in the previous articles also apply here.
On the pure software side there are different classes of contracts, with subtly different criteria for evaluation. The first is for contracts covering custom software. The equation is rather simple. If the cost and/or risk of using a pay-as-you-go method of support is too high, pay the price asked or switch to another product. For true custom software, you have very little recourse. If the software is very open and closely follows industry standards for hardware, software, and user interfaces, a third party might be able to generate a work-around to a serious problem without help from the developer.
The potential waiting time and cost of emergency service without a contract can be way too high, especially for smaller programming firms or individual freelancers. Small software companies must allocate most of their resources to programming related personnel. Their tech support resources are sized to handle the people who have support contracts plus a little extra to assist the occasional non-contract problem. If they don’t estimate their tech support load correctly, purposely shortchange tech support to save money, or simply have a random burst of high-tech support usage, non-contract customers might not get a call back for many days.
If you decide that you must have a contract, you are totally at the software company’s mercy. If they offer a ten dollar per month contract for the first year and switch to a $1000 per month contract price for the second year, you’ll just have to pay it if you need that software for business survival.
For vertical market software, the equation is similar, but with a bit more flexibility. You must determine how common the software is, and how many dealers, VARs (Value Added Resellers), and consultants are available to provide support. If you have local support available, and the developer of the software has a large enough staff that they can handle ad hoc queries promptly, then you can either skip the contract or at least go with a simpler, less expensive version (assuming, of course, one is offered).
The key here is the openness of the software. If VARs or, better yet, customers, can get access to the source code (normally for an additional fee) or at least extremely thorough technical documentation, you can more easily risk going without a contract.
At this level (and higher), another cost factor comes into play. Many of these software contracts are bundled with a free supply of updates, upgrades, patches, and fixes. This alone might make the purchase of a service contract economically feasible.
Another factor is the dealer’s part in the picture. Some dealers will bundle their services with the contract from the software company. If the dealer has access to the program code or technical reference material, and has extensive training and experience in the product, then it’s worth evaluating this bundle. Even then, the real expertise resides at the software company, so, while the dealer may be an important part of fixing a problem, it takes a case-by-case judgement call to decide if a bundled contract is practical.
There is a closely-related type of software that is usually classified as subset of vertical market software, but really consists of specialty products with limited customer bases that apply to most types of businesses. A document and image management system (DIMS) is a good example of that genre. Almost any business can use one, but, except for some inexpensive, simplistic products, they are not widely used. The market is also split amongst many companies, so no individual company has many customers.
When I sell a DIMS, I always recommend that my client purchases the highest level of support contract and renews it every year. The DIMS is often purchased in conjunction with a project to either destroy or at least store in an inconvenient location, the original documents that go into the DIMS. This makes the DIMS vital to accessing those documents. I don’t bundle my services, even though it is the software company’s policy to use VARs as their pipeline to their customers. I just can’t justify to my clients paying my company enough to cover us in case a serious problem arises in a product whose internal functions are totally inaccessible to us. I have seen time-consuming disasters happen with other products, so I know the potential is always there. This is not to say however, that another VAR might see the equation differently. That’s why there are entrepreneurs. Each sees things his or her own way.
For common commercial software, most small to medium size companies don’t purchase service contracts. Larger companies use them to reduce the size of their internal technical staffs, or buy them as part of enhanced update and licensing offers. Third party phone support contracts are also available from specialty support companies.
Just as in the case of pure hardware contracts, there are things you can do to reduce or eliminate the need for service contracts. One is to educate your staff, especially any technical support personnel. Another is to get the best reference material you can. For instance, very high on my "Don’t leave home without it" list are the support CDs that I purchase via subscriptions from Novell and Microsoft. They have the same information that those companies’ own technicians use when someone calls them for help. They contain all of the latest patches and fixes along with extensive troubleshooting databases, all updated every month. If you have anyone on staff capable of using these CDs, you can avoid most service calls.
Yet another is to establish a close relationship with your system integrator. Someone in that line of business should be inclined to avoid nitpicking you to death with billings for quick simple questions and should also be inclined to treat you fairly in billing for larger, more complicated problems. They also have the advantage of being intimately familiar with your particular computer system. (Warning: The preceding paragraph was an incredibly self-serving paid political announcement!)
The final category I want to cover is what I call an integration contract. This would cover at least all of the software, including system software (the desktop operating system, the network operating system, and various utility programs), and sometimes hardware as well.
This is another category in which I have turned down offers for service contracts from clients because of the potentially company-bankrupting amount of time that my staff would have to spend if a client had major problems due to, for example, an operating system bug. There are no bug free operating systems available - not DOS, Windows 3.x, Windows 95 (Yikes!), Windows NT, and even my old favorite NetWare.
Just as there are insurance companies that only do health insurance, others that do auto insurance, and still others who do both, some companies do offer integration service contracts. Just as with insurance companies, you have to decide whether they would support or abandon you if things get tough.
On the other hand, if your whole computer system is so badly designed that you feel you need to buy this high level of integration support for it, then maybe you should be dealing with a different integrator.
Over the last few years I have had to change health insurance companies due to massive price increases, poor service, after-the-fact changes in exclusions, and inadequate treatment (by an HMO as determined by second opinions from other doctors). I find it hard to believe that anyone should be less picky than I am about my health insurance when choosing what amounts to health insurance for their computer systems.
 

©1998, Wayne M. Krakau