Purchasing Enterprise Software for Dummies

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...