GENERAL BUSINESS CONSULTANTS  

SPECIALISTS      IN     " SYSTEMS"      AND     MORE-PROFITABLE     OPERATIONS  -  For Distributors, WHOLESALERS, Manufacturers

       

 

     


 

RECENT ARTICLES

Concise, helpful articles. For easier reading, print them first. Scroll down to the article of interest.

DO YOU REALLY NEED A NEW SYSTEM?

NEW WAREHOUSE MANAGEMENT TECHNOLOGIES BEAT THE OLD ONES

How to Avoid A Warehouse Management System Horror Story

Don't Sign That System Contract -- Until Its Changed to Include Protections

 Why Some Systems are Decreasing Customer Service, Margins and Inventory Profitability

HOW TO MODIFY A SYSTEM TO MAXIMIZE INVENTORY-BASED CUSTOMER SERVICE AND ROI

WHAT LISTS OF SOFTWARE DON'T SHOW CAN KILL A DISTRIBUTOR

GREAT SOFTWARE DOES NOT MANAGE INVENTORY EFFECTIVELY

SYSTEM CONTRACTS: ADD SPECIFIC PERFORMANCE GUARANTEES TO AVOID PROBLEMS

 

DO YOU REALLY NEED A NEW SYSTEM?

             Making the critical decision about replacing a computer system has always been difficult because it involves subjective, intangible factors as well as dollars. And now it can be more confusing because the decision should consider a new kind of "system" -- Application Service (AS). With AS, a distributor does not pay a large sum up-front for a license to use ERP software; nor is it necessary to purchase a new, larger server. PCs are used, usually via the Web, to access software and data on a computer residing at the company that provides the Service. The distributor pays only for the resources used (e.g., the amount of processing done), which can be less expensive than owning a system.

Based on experience, here are the steps to take to make a non-emotional, unbiased, cost-effective decision.

1. Create a list of the reasons why replacement of the current system is being considered; call them "goals." It may be possible to achieve these goals without getting a new system.

2. Define the planned and expected growth and change at the company.

3. For the current system, identify where improvements or changes in user job-functions and/or procedures/controls could achieve some goals listed in step 1. Also determine if enhancements to the current system could achieve some goals.

4. Based on steps 1 and 2, define all the features that are desired in a new system. Then determine the availability of suitable new software and the availability of an Application Service. 5. Identify savings, benefits and efficiencies that only a new system or AS would yield.

6. Identify where improvements or changes in user job-functions and/or procedures and controls could produce some benefits of a new system.

7. For the current system, determine which enhancements would be needed to provide the same financial savings and intangible benefits that a new system or AS would.

8. For each software enhancement identified in steps 3 and 7, estimate the direct cost, the value of internal time involved, and the resulting savings and benefits. Also estimate the level of risk of success.

9. Judge whether the system environment is structurally suitable for all the enhancements being considered; whether the current system is user friendly and easy to use; the adequacy of software support.

10. Determine if the current server could handle enhanced current software. If not, estimate costs for any hardware expansion or replacement hardware, taking step 2 into account.

11. For each enhancement, do a cost-benefit analysis, and classify it as immediate, mid-term, or not worth doing.

12. Determine if the current server could handle new software. If not, estimate costs for any hardware expansion or replacement hardware, taking step 2 into account.

13. Add up the cost of all the enhancements classified as immediate or mid-term.

14. Estimate the true future cost of using the current system, as enhanced/expanded, the savings and benefits from enhancements, and the net cost (savings)

15. For a new ERP system, estimate the true cost, the savings and benefits it would produce, and the net cost (savings).

16. Repeat step 15 for an AS.

17. Use steps 9, 15 and 16 to make the big decision -- including whether to license software or use an AS.  

 

NEW WAREHOUSE MANAGEMENT TECHNOLOGIES BEAT THE OLD ONES

New kinds of warehouse picking technologies can produce greater savings and benefits than bar code readers. And, they can be bolted on to distribution business (ERP) software or on to warehouse management software (WMS), and work in conjunction with bar code readers. Let's look at how these new technologies work -- after explaining "WMS."

Bar Code Reading is Not a WMS

            WMS is special software with functions that bar code reading alone does not provide. For example, WMS logic and data determine where to put away received items, such as bulk, that are not stored in permanent places, in a way that minimizes put away and picking times; determine the least-time path for picking an order, even when storage locations (e.g., bulk) have changed; alert someone to replenish a picking slot, and define which slots to pull from; determine how to re-slot a warehouse to reduce labor effort. Some ERP packages offer an extra-cost WMS module, or have WMS features built-in, but the add-on WMS packages have many more features.

            Its important to note that for a WMS to work well, many warehouses need to be re-arranged and/or tight procedures and controls need to be implemented. Without such preparations, a WMS can reduce productivity and result in more errors that hurt customer service.

NEW PICKING TECHNOLOGIES

            Voice Directed Picking (VDP). A picker wears headphones and a microphone, attached to an wireless computer worn on the person's work belt. Each person is assigned their own wireless computer, and teaches it his/her speech patterns. When an order is to be picked, the main business system sends data to the VDP computer-server, which in turn transmits that data to the wireless computer of the system-selected picker. The wireless computer in turn transforms that data into audible commands -- the picker is told where to go, what to pick, and how much to pick. As he/she picks, the picker talks into the microphone, identifying what was picked and the location; the portable computer transforms the speech into data, and transmits it to the computer-server, which in turn transmits it back to the main system for verification. The picker is immediately "told" about any picking errors. VDP can also be used for put away.

             Pick to Light (PTL) involves a display device that is mounted at the front of the shelf on which an item is stored, and all the display devices are wired together. When an order is to be picked, the main business system sends data to the PTL computer-server, which illuminates a light on the display device for each involved item; the device also displays the quantity to be picked. After an item is picked, the picker presses a button on the device to indicate that the item has been picked. When the button on all the item-specific displays have been pressed, a master display device illuminates a green light to indicate that the picker is ready for the next order; a red master light indicates there is an error that needs to be corrected. As buttons are pressed, data is transmitted to the computer-server, which in turn transmits it back to the main system.

            As for other picking technologies, a warehouse needs to be specifically arranged for VDP or PTL, and tight procedures and controls need to be implemented.  

 

How to Avoid A Warehouse Management System Horror Story

            A Warehouse Management System ("WMS") can increase productivity and picking accuracy, which can cut costs and improve customer service. But its very tricky to find a WMS with the right combination of helpful features and long term cost. Its easy to spend a lot of money, when a cheaper system can produce the same savings and benefits. And, often changes to the warehouse are needed before installing a WMS or it won’t  produce savings or benefits.

This article outlines the steps a distributor should take to avoid the pitfalls of an unfamiliar process that can result in selecting the wrong WMS, overpaying, and setting it up in a way that makes things worse.

Up-Front Planning and Prep

             Involve top management, because a WMS impacts customers as well as employees -- even if that means a top manager has to learn something about computers and WMS.

            Organize a team consisting of someone from top management, all warehouse managers and supervisors, MIS management, and the people responsible for sales order entry and customer service.

            Estimate growth and identify expected changes for the company as a whole and for the warehouse. A WMS must be able to handle future company and warehouse needs as well as the obvious current ones.

            Tighten warehouse procedures and controls for receiving, put away, etc., for information and product-flow. Do it now. Failure to do this is the primary reason for WMS horror stories.

            Determine if the main business system has the functions and data that are "expected" by a WMS; e.g., expected arrival date of a PO. Furthermore, the data in the business system must be very up to date and accurate.

            Estimate long term costs: software, education/training, bar code equipment and spares, annual support fee.

            Be conservative when estimating personnel reductions, personnel avoidance, and other cash savings.  Don't ignore the impact of non-cash benefits, such as happier customers.

SELECTION AND INSTALLATION

            Define detailed long term WMS needs. Without such a list it is impossible to judge whether a particular WMS contains specific needed functions; and impossible to compare different systems.

            Solicit written bids. Ask WMS vendors to categorically compare their software against the list, and to quote all the costs involved.

            Examine each vendor’s bid, for cost, missing features, and prior experience with similar distributors. Narrow the field to two or three WMS, and then ask those vendors to demonstrate their systems. Call a few references of the vendors, and  visit  one or two references of each vendor.

            Select the most cost-effective WMS, based on long term cost of ownership and non-financial facts such as the degree of software suitability (vs. the list of needs), and vendor experience.

            Before taking delivery, the vendor should make any planned WMS modifications, and create any programs needed to interface the WMS with the main business system.  Test it all, using real data for the test, which should be conducted by the people who will be using the new WMS.

            Don't skimp on user training. A WMS is so complex that the only way to learn more is to spend a lot of time in formal classes and on-site training sessions.   

 

Don't Sign That System Contract -- Until Its Changed to Include Protections

            Converting to a new system is so complex that many things can go wrong before, during, and years after installation; years after the vendor has been paid. But no ven­dor con­tract protects against typical problems, because a vendor’s contract con­tains vague "best ef­forts" terms that are slanted in the vendor’s favor. Vendor contracts don't protect against problems such as promised capabilities that aren't delivered, excessive lateness and poor in­stal­la­tion support.

This is a summary of some of the kinds of protections a distributor should -- and can -- add to a system contract. These protections are referred to as specific performance guarantees (e.g. a promise to correct any software bugs that are causing critical problems); they replace best efforts. This article also outlines a strategy for getting desired terms and conditions.

 TERMS AND CONDITIONS

Define all words and phrases that might be subject to misinterpretation.

List in detail everything to be provided: hardware, software (including third party packages), any modifications to be made by the vendor to the software, training and education, data conversion, installation help, post-installation software maintenance and support, etc. And define the cost of each.

            If the software will be modified by the vendor, define the process that will be followed.

            Define the procedure for delaying installation.

            Specify the conditions under which payment is made. Wherever possible, tie payments to buyer approval; e.g., approval of converted data.

            For the application software (business programs), define permitted and prohibited uses in as much detail as possible.

 In addition to the warranties that the vendor provides or passes through, define performance warranties for hardware, software and services. Define how performance is measured, and what happens when a warranted condition occurs.

Warranties for infringement are needed because a court can bar the use of the infringing item, which could leave a distributor without a working system.

            In order for vendor and distributor to plan ahead and work in a coordinated fashion, a schedule of tasks and completion dates should be included. Don’t forget the “go live” date.

            Define the situations that permit termination of the contract, and the consequences of termination. And define what would happen if either party went bankrupt before the system went live. Also define steps that would be taken if either party breaches the contract.

 A NEGOTIATION STRATEGY

            To get specific performance guarantees, a distributor will have to either amend the vendor's contract or replace it with a new document. If the vendor reacts to the amended or new document by saying "take our contract or leave it", find another vendor.

            Once negotiations start, it is important that the person negotiating not get so emotionally involved that he/she makes compromises not in the favor of the distributorship. Before compromising, consider the likelihood of a problem occurring and the impact of the problem; compromise on unlikely, low-impact problems, but not on likely, high-impact problems. Also before compromising, determine if and how the issue in question is related to other terms and conditions in the contract.  

 

Why Some Systems are Decreasing Customer Service, Margins and Inventory Profitability

    Some distributors spent a fortune on new systems, only to discover months later that the business performance got worse, not better – or at best, didn’t increase. Other distributors have been using the same systems for many years, but still aren’t getting “the numbers” they could, and are not aware of the reasons for under-performance. This article looks at a few functional areas where mistakes and omissions are depressing customer service and profits.

 Matrix Pricing. Distributors that have recently set up new systems with the same matrix settings that were in the old systems, and never changed them, are leaving money on the table. And distributors that have older systems but don’t regularly review and revise matrix settings are also losing out on some profits.

            Even the largest customers should not be given the largest discount or smallest markup on all items they buy. Almost as bad for profits is giving the best deal on all the items in a family or grouping. A price should depend on the “real %GM” and velocity. Real % GM is the traditional %GM adjusted for costs of doing business (such as free or subsidized delivery). Fine-tuning matrix pricing can result in a loss of sales, but the $ GM should increase – which should be the growth objective.

Inventory Management. Mistakes made in entering data about a customer return or exchange could impact the level of inventory, and perhaps the level of customer service for the item in question. Many different kinds of mistakes involving data entry can easily be made, so one step to improving inventory levels is to install procedures and controls to minimize those data entry mistakes; and detect and correct them before inventory data is impacted.

            Another kind of “mistake” that impacts inventory is accepting vendor deals without calculating the financial impact of the deal, and the impact on warehouse operations.

            Another import task that gets back-burnered to time pressures is the maintenance of various system “parameters” that affect the accuracy of system-calculated forecasts, lead times, safety stock values and Economic Order Quantities (EOQ). Other important parameters determine whether the system should even make a calculation; EOQ should not be used for many, many items. Key parameters should be reviewed/revised quarterly; especially those that affect all items, all vendors, etc.

            An important task that many users don’t now about is the review of sales data that will be used by the system to calculate purchasing requirements. Even though most systems do some filtering of data oddities, no system can clean up all distortions in data.

Warehouse Operations. Data mistakes made in the warehouse (e.g., incorrectly entering a substitution) can have a bigger impact on the level of inventory (via automatic purchasing functions) and perhaps customer service than those made in the front office. Here too, procedures and controls are needed to minimize data mistakes and detect/correct those that do occur. Procedures and controls are also needed here to minimize product-related mistakes, such as putting a received item in a wrong slot. (But unlike the office, this is a place where advanced technology can be used to drastically reduce the level of errors.)

 

HOW TO MODIFY A SYSTEM TO MAXIMIZE INVENTORY-BASED CUSTOMER SERVICE AND ROI

Distributors who are using inventory management software that can be modified may want to change it in ways that reduce inventory shortages and excess. That in turn would increase the level of customer service, and decrease inventory investment. Other benefits of these changes include reduced purchasing efforts, rush orders, expediting, clearance sales and returns to vendors`. And, warehouse space would be freed up, and less effort would be needed for receiving, put-away and counting; staffing might be reduced.

Here is an outline of some of the changes -- which are all meant to function automatically, so little or no human intervention is needed.

            Analyze order history data for unusual data that would distort inventory levels, and if a condition is within a pre-defined tolerance, adjust the data; if a condition is outside the tolerance, list the item on an action report.

            Calculate safety stock based on target service level and the factors. that can result in not having enough planned stock on hand when its needed.

            Allow for trends when calculating lead time.

            If the history data for an item is outside the tolerance, don't calculate safety stock or lead time or a forecast; list the item on an action report.

            If the history data for an item contains too many gaps, don't calculate safety stock or lead time or a forecast; list the item on an action report.

            Treat very slow moving items differently than items that move fast, but don't require human intervention -- treat them automatically.

            Let the system determine the most accurate method of forecasting

            The system can determine the most profitable service level.

            Identify items for which the service level is too high.

            Calculate the true cost of buying more than is needed now, vs. waiting and buying later.

            Calculate whether a deal is too good to be true for the distributor (its always good for the supplier).

WHAT LISTS OF SOFTWARE DON'T SHOW CAN KILL A DISTRIBUTOR

A client recently mentioned that company "A", with sales of some $400 million, had been forced to sell because it had to operate its business manually for several weeks after switching over to a new ERP system. During those weeks it took so long to answer customers' questions (price and availability, order status, etc.), take orders, fill orders, handle returns, etc., that the company lost a very large customer. That loss resulted in a technical default on their largest loan agreement, and the bank refused to modify the terms. When my client mentioned the name of the ERP system, it rang a bell -- I had recently seen it on one of those lists of software packages supposedly meant for distributors.

This article describes some important system selection considerations that are not addressed in lists of software.

            Suitability for a Distributor. The conversation related above reminded me of another software package that appears on most lists, and is being aggressively marketed. It was thrown out by two distributors who couldn't get it to work right, and the vendor was sued by at least one other distributor. Three other distributors are, even after a few years of use, still unable to get it to work right in one critical functional area -- in spite of enlarging their system-related staffs, an expense not anticipated. Most systems are not difficult or costly to install and use, but some really are not meant for distributors, no matter how many lists they appear on.

            A distributor is not a distributor. Some systems are really great for one narrow segment of distribution, but not good for other segments. A look at lists of features for such niche software would not reveal this condition.

            Cost of Installation. Another system on some lists has earned the unenviable reputation of billing for far, far more hours of professional installation services than quoted. At least two distributors terminated the installation process before the bills became unbearable, and two others filed lawsuits against the system vendor. The vendor of a different system refused to provide more installation help to two distributors who didn't want to pay more than had been originally quoted/estimated; the distributors opted not to proceed with the installation, even though they paid the license fees.

            The very weakest link. Several of the packages that appear on most lists are not licensed by the well-known authors, nor do the authors provide the installation and post-installation support. These packages are re-licensed by, installed by, and supported by re-sellers. Its the capabilities of the re-sellers that usually mean the difference between success and failure (assuming that the package itself is suitable). Unless a re-seller is listed as the vendor, most lists provide no information about a package's re-seller. And, since the contract may be only with the re-seller, if something goes wrong, the author may not be able to help much (and certainly wouldn't assume financial responsibility).

            Post-installation Support. This is critical because all systems are relatively complex, and no matter how much training occurred before going live a high level of support is usually needed for 12 to 18 months after going live. Yet some vendors have a reputation for slow and/or unquality support, and many re-sellers are support-challenged.

            Functions and features. Even the most detailed lists of software packages show only a cursory description of a package's functions. But the devil is in the details, and reliance on a software list to determine which systems to examine can result in wasted time when the project team discovers that a software package is not nearly as robust as it seemed. Worse, if a package is not examined in detail before licensing it, a lack of needed specific features would not be discovered until the system is paid for and in use.

            Adaptability. Related to features is the ability to interface third party software packages to an ERP system. At least one vendor has gone out of its way to make life difficult for existing users who want to interface packages not sold by this vendor.

            Viability. Obviously there has been much consolidation in the packaged software industry, and the pattern will continue. But no list contains the information needed to judge whether an author is likely to remain independent -- or be bought out, and its package relegated to obscurity (no enhancements, and dwindling support). Software re-sellers are much less viable than authors, and seldom is one bought out -- they usually go out of business.

            List Objectivity. Some authors of lists seem to have relationships with some of the vendors of listed software. A relationship may not be financial; there can be a quid pro quo arrangement whereby each party promotes the other.

            References may not be useful. One would think that the problems described here could be avoided by calling references already using the packages in question. However, experience has shown that vendors seldom provide the names of unhappy users; certainly not the names of users who have filed lawsuits. And even if names of questionable references are provided, most unhappy references adhere to the old saying "if you have nothing good to say, say nothing."

            How to avoid the unpublished problems. Find someone who knows about many different systems and where the hidden problems are; someone with extensive hands-on experience objectively evaluating systems, and getting references to talk about their true experiences with systems; someone who can negotiate a contract with specific performance guarantees.  

    Contract Terms and Attitude. Obviously, all contracts created by system vendors protect the vendors when a conflict arises with distributor-users. But most contracts do not even address problems that can and do occur – its like the vendors are trying to hide the potential problems. And some vendors have a dangerous attitude toward contract negotiations – take it or leave it.

 

GREAT SOFTWARE DOES NOT MANAGE INVENTORY EFFECTIVE LY

            The most expensive, sophisticated software package will not automatically result in an optimal level of inventory – a high level of customer service and inventory turns, but with low inventory investment. To achieve an optimal level, and maintain it, employees educated in the principles of effective inventory management must understand how to set certain “parameters”, then set them and keep them set right. Here are some tips about principles of inventory management and setting key parameters.

            The Basics. Too often I work with users who have been well-trained in the rote mechanics of using the ERP software package that literally runs the distributorship, but were not educated in modern inventory management principles. Important principles include the relationship between customer service level and inventory level, and the meaning of the “normal statistical” distribution (bell curve) that plays a role in the calculation of safety stock and the adjustment of data on odd sales events. A principle related to purchasing, and so indirectly to inventory management, is the “Line Point” (LP), which is not another term for Order Point (OP). The LP is the OP plus sales forecasted for the buying cycle (time between buys). Items that are above their OP but below their LP should be purchased only when those items are needed to make a purchase minimum or would result in a purchase discount that would be larger than the cost of  inventorying those items for longer than usual.

Another basic that is sometimes skipped is the setting of parameters. When the system was first installed, the users were too busy to determine what values to set parameters to, so the system went live with “default” values (on average good for all distributors, but not good for any specific distributor). And, of course, these users are still too busy to investigate the values and change those that are not right for the company – if they could even do so without first learning the principles of effective inventory management.

Qualifying Historical Data. Although most systems adjust historical data to remove oddities before using the data to forecast future sales, the scope and amount of an adjustment depends on the values of certain parameters. In addition to the common oddities of unplanned sales “spikes” and “dips”, there can be periods of no sales (perhaps due to stock outs, perhaps not), sales spikes caused by promotions (perhaps followed by decreased sales), and sales dips that reflect a large quantity of returns; and more. The values of parameters determine whether an oddity will be adjusted, and the extent of that adjustment (and that extent may increase or decrease with the size of the oddity). Users should not set these parameter values until they understand the specific oddities of the distributorship’s sales and how those specifics relate to the available parameters.

            Forecasting. Many systems come with several different formulas for forecasting future sales (by using history). One of those formulas is the “default” – the one that will be used unless someone selects another formula. Life would be easy if one formula, the default or otherwise, could be used for all items, but that is very rarely possible. Even the use of one formula for all items in a particular product line would save time, but that too is seldom possible – because every line has its slow moving items, and they cannot accurately be forecast with the same formula that works well for fast moving items. As with the setting of most parameters, it is necessary to select different formulas for different items – unless the system can automatically select the “best” formula (based, of course, on parameters that define “best”). Formulas that are easy to understand but not accurate include averaging and weighted averaging (where users set the weights – emphasis factors.) Wherever possible, use the more sophisticated formulas, even though someone still needs to set related parameters.

            And if a system measures the accuracy of an item’s forecast (sometimes called the Mean Average Deviation, or MAD), accuracy reports should be reviewed quarterly – to determine if parameters should be changed or a different formula used.

                        EOQ is Dead, Long Live EOQ. For some items, EOQ (Economical Order Quantity) is inaccurate; items with a very low unit value relative to the cost of procurement, and items that sell infrequently. For these kinds of items, EOQ would calculate a multi-year supply or a quantity of zero, respectively. A better way to handle both kinds of EOQ-inappropriate items is to use the dynamic Min/Max feature of the system, whereby the system uses history to determine the values of Min and Max. But before doing so, research the system’s Min/Max formula, and determine what the Min/Max parameters should be and if Min/Max would produce realistic results. Avoid using manual Min/Max because it is not dynamic, and so takes a lot of effort to keep up to date as sales patterns change.

            Safety Stock. Safety stock can account for a large portion of an item’s quantity on hand, and for too many items, the quantity on hand is seldom less than the level of safety stock – which means that the safety stock is not being sold, and is dead inventory. One reason that related parameters are sometimes set wrong is that some people do not understand principles for calculating safety stock: 1) safety stock is kept in case sales exceed forecasted sales; 2) the level of safety stock does not depend on an item’s velocity; 3) the level of safety stock for an item should be mainly in proportion to the volatility of its activities; 4) the level of safety stock should be based on the item’s target service level.

            Lead Time. Lead time may be the most difficult value to determine, because it is basically beyond a distributor’s control; and because some lead times are seasonal, even though sales of the items are not. But that is no excuse for not examining the default values of related parameters – which are often set with the assumption of constant lead time. Where a system contains optional sophisticated formulas for calculating lead times, those formulas should be investigated, compared to vendor performance, and used wherever possible. Even if there are no sophisticated formulas, related parameters should still be set in the context of vendor performance.

 

SYSTEM CONTRACTS: ADD SPECIFIC PERFORMANCE GUARANTEES TO AVOID PROBLEMS

    One impact of software “aggregators” buying system providers is that price competition has decreased, so the prices paid have increased. A more ominous impact is that the contracts of the survivors now offer fewer protections to distributors – not that they really offered many before they bulked up on rivals. 

     Here are some of the issues that must be addressed in any system contract that protects a distributor. Addressing them involves adding specific performance guarantees to the vendor’s agreement.

     Viability. No software company can afford to market, support and enhance several different software packages. Sooner or later, the stable will contain only a few packages. But, its not safe to assume that the package with the most user companies will be one of the survivors; nor is it safe to assume that the most feature-rich package will survive. Even the continued release of enhancements does not guarantee that a package will remain viable.

     License transfer. Long before software companies started buying up other ones, distributors started buying up other distributors. This trend is likely to continue, but some system contracts give the system provider the right to deny or restrict the transfer of licenses to an acquiring distributor. Such preclusion could result in a potential buyer walking away from the deal to buy a distributor who wants to sell.

     Installation services. People who use on-line auction sites like eBay know that sellers get more money by selling at a low price but over-charging for shipping. Some software companies play a similar game by under estimating the number of hours needed to assist a distributor in changing from the old system to the new one. Its like handing the vendor a blank check. Similarly, some software companies excessively increase their annual support fees.

      Third party software. Even though the large software companies own many software packages, there are some functions not found in any of the owned packages. These functions are handled by third-party software packages that a software company provides. Some of the third-party packages work well with some of the owned packages, and others don’t work so well. Some of the third-party software packages were not designed specifically for distributors, and may not address the needs of distributors. And because third-party software was not created by a system vendor, what would happen if a distributor is sued for misuse by the author of a third-party  software package?

    Help with problems. When the system is down, or some critical function stops working properly, what kind of help would be provided? If the vendor’s people accidentally corrupt the data in the system, who pays for restoring it to its proper form? How quickly would the problem be resolved? How can business be conducted if the system is down or corrupted for a week? Do you want to stake your business on best efforts promises?