Without doubt the most appealing economic reason to get into the software development business is the extremely low cost of reproducing your product compared to the potential selling price.
An excellent example is the first significant database program for PCs – “dBase”.
In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.
But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.
If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.
Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.
But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?
Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.
Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.
The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.
What is the cost to customize it?
In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:
“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”
Any sort of custom software works in the same way.
However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.
A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.
But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.
Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.
It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.
Some such managers only have experience working on standard software development. That, by definition, does not require customization.
Other managers, surprisingly, have no software development experience.
But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.
Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.
As is the case with any business, it is important to understand the market and the product that you are selling.
Here is a true story example of how not to do it.
I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.
It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.
One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.
First, we would deliver a system at cost for one customer.
Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.
Right?
The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.
That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.
My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.
The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment