Purchasing
enterprise software is one of the most curious product purchasing event there
is. No other industry would have a
customer purchase products and services that they don’t plan to use for 9 to 12
months. Not only does the software sit
idle on the “shelf” until it is put into use, but the service contract starts
to run and therefore the customer is wasting valuable support dollars that
could help them solve a production issue when needed.
The basic strategy
that venders use is to imply that if the customer were to purchase today
(actually before the end of the quarter), they will get the deal of the
“century”. When in fact, if the customer
were to ask for the same or a similar deal at the end the subsequent quarter,
it will magically be available to them.
In addition, most
projects when planned correctly and phased in over time, don’t require all the
software at the project initiation phase.
The software for developing the system is required initially, followed
by the software for the test environment(s), followed by the software for
production. And depending on the numbers
of developers, a reasonable strategy would be to simply purchase named user
licenses for the development team and then CPU based licenses for test and
production. (There’s further refinements on this model as well.)
Finally, if
customers are willing to take on a measured amount of risk in their deployment
rollout, purchasing can occur over a range of months and weeks as users are
ramped up on the system. Much of this
last point is dependent on using virtual machine software (VMWare & Oracle VM) as a model for hard partitioning
CPUs on the machines for the production system. But the model is quite simple, if the user
population is low for the initial rollout, the customer may be willing to have
a single point of failure (with the expectation that recovery time is within an
hour).
There's a lot of detail behind each point above that I'll share with anyone that asks...
