This is a response to the opinion written by Michael Catalani in the December 1991 issue of MC. He had written regarding his opposition to tiered pricing for AS/400 software.
As an AS/400 software developer, we spent a lot of time analyzing the different options for pricing our software. We wanted to price our product low enough to help our customers realize a sizeable benefit, yet high enough for us to be able to make a profit and stay in business.
There are a number of ways that AS/400 software companies structure prices. Some charge one price for a software package, regardless of model size or number of users. Others use tiered pricing based on model number, which as Mr. Catalani correctly assumes, was founded upon the notion that a larger AS/400 would support a larger number of users. A few other companies charge based on the actual number of users that will use a particular software package. Each of these approaches has its own advantages and disadvantages.
An advantage with a "one price fits all" approach is that after the initial investment, the customer does not have to worry about the upgrade charges as he upgrades his processor. The biggest disadvantage to this method is that it may cost the average customer more overall. One might guess that a software company could sell the product at the average of the tiered price structure and end up with the same revenue. At an average price, however, many of the smaller customers can no longer cost-justify the purchase. Since the software company must produce revenues to cover the same development costs on lower volume, the price would have to be raised. The one price approach would allow the large system shops to invest in software at a reasonable price, but many small shops would not be able to afford it.
In contrast, tiered pricing causes companies that stand to gain the greatest benefit from the product to carry the largest burden of the cost. This can be justified since the larger shops are probably going to require more support and additional development time may be spent in efficiency and allocation routines when there is the potential for hundreds of users to work with the product simultaneously.
Mr. Catalani mentions that a problem with tiered pricing is that you would have to include the software upgrade charge when planning a system upgrade. This doesn't seem like that big of a problem. You probably have a whole checklist of additional costs that all come with a change as major as a system upgrade.
Another problem attributed to tiered pricing was that of a company spending a lot for software to be installed on a large system, although only a few users would be working with it. The example involved buying a software development tool like CASE. As Mr. Catalani stated, he could solve his own problem by having a small secondary system for development. Obviously, the production system would not have to be as large. Since the ideal development system has different performance requirements than a production system, there would be many other benefits to separating the environments. Thus, this problem begins to look like an opportunity to structure both hardware and software for lowest cost and highest benefits.
The third pricing approach--charging for the number of actual users--has some of the same benefits as tiered pricing. But there are some disadvantages to this approach, too. Unlike tiered pricing, where you can retrieve the model number through OS/400, this method could require a lot of extra development to track number of users. The programming resources used to handle this would be better spent adding important features. There are also some software products where this scheme really wouldn't apply. For example, a software documentation package might be run by just one person, but the output could be distributed to a large development staff. There is another issue when comparing this approach with tiered pricing. Every time your were to add a user, you would have to consider whether there was to be an upgrade charge. With tiered pricing, you would only have to consider this at system upgrade time. The assertion can be made that most companies add users more frequently than they upgrade their hardware.
Of course, any pricing approach will have its detractors. One is tempted to relate licensing software to other kinds of purchases and it just doesn't work. AS/400 software companies may, in time, decide that some other approach to pricing might be better. For now, tiered pricing remains the best balance of fairness and workability.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online