Often there are too many variables in the equation, and some of them make no sense. It's perfectly acceptable to base pricing on the number of people that will use the application, but the calculations only begin there. You also have to ask how many users will be accessing specific functions and from where. Volume discounts may be applicable, depending on some secret calculation performed by the vendor based on the size of your organization, what day of the week it is and how often it snows in Kalamazoo, Mich.
One of the oddest variables has to be CPU-based pricing. The server portion of a client-server application is often listed as some dollar amount per CPU. I've never quite figured out the relationship between the number of CPUs and the price of software. You don't buy a special version of the application if you'll be deploying it on a machine with two CPUs rather than one.
Give It to Me Straight
I have yet to see straightforward, sensible pricing for large-scale business applications. Business intelligence, CRM, EAI and provisioning all depend on number of systems being connected, databases being queried and users, as well as the types of users, access methods required and, in many instances, the number of CPUs. In some cases, pricing also depends on the size of the organization--which makes about as much sense as the grocery store pricing milk based on your gross annual income.