| Previous by Date |
Index by Date
Threaded Index |
Next by Date |
|---|---|---|
| Previous by Thread | Next by Thread |
Simultaneous User Pricing
Okay, let me further try to articulate my discomfort with simultaneous user pricing and see if writing this down makes the discomfort seem logical or illogical. (I've not had this discussion out loud with more than about one person, so the list can be a very helpful critique and could disabuse me of the error of my ways!) I. When no. of simultaneous user pricing model makes sense: Simultaneous user pricing makes sense (to me) when the electronic resource is accessed remotely from a publisher or vendor. In that case, the deliverer must ramp up services to accommodate a certain kind of load on his system. The provider is there not only to sell an information product but to deliver a service (access, at the least). In order to offer that access the provider must have a good idea of how many folks might come knocking at the door and be prepared to deliver. If customers get poor access and service, the producer and his product are not viable. So, in the remote-access-case, the producer might reasonably ask the customer to pay based on anticipated maximum demand. The customer in turn decides what that might be; the provider will then, ideally, offer the customer data that will allow the customer to fine-tune the numbers of simultaneous users paid for. The customer may choose to pay for as many simultaneous users as desire the service, or may set an economic cap. Note that not every provider of remote access asks for simultaneous user pricing, by any means. II. When simultaneous user pricing makes less sense (to me): When the product is delivered to our institution and we in turn serve it up locally (through the "Intranet" if that is the right word here) or through a CD-ROM network, then the cost of the delivery is borne by us. We have to worry about the wires, pipelines, storage, backup, user support, and so on. In this case, I fail to see why, simply because we are investing more at our end to deliver a producer's product to a user, we (the institutional subscriber) should be charged additional $$$ by the provider. The provider should charge for the product in that case, not the access portion. III. My discomfort with the simultaneous user model is further increased by the fact that with many systems and products, calculating how many simultaneous users one needs is a total guess. It is an art (to be kind to it) and not a science. While there are some systems -- and some skilled individuals -- that provide good management information -- and people who know how to interpret it -- it does seem to me that until we know what our needs as producers and subscribers are, this model is as full of holes as a swiss cheese. Again, this is not true for all electronic systems and products, but it is true (I believe) of the majority of them. Mind you, likely we will get better at it over time, but that's in the future. Reactions? Corrections? thanks, Ann Okerson Ann.Okerson@yale.edu _______________________________________________________________ On the topic of simultaneous user prices, Keith Ostertag wrote: >I'm surprised, because I have generally felt that simultaneous users is a >very good model. You can start small, then add licenses if need be, and >not feel you are paying for a lot of access that is not being used. Of >course it depends on how mission critical the service is; I think >universities can afford a small amount of queueing for general research >type databases (Proquest, IAC, Ebsco,etc). It also tends to promote >better planning for port needs, bandwidth, etc. >I agree that FTE's is a very bad model to use for pricing. Some of our >campuses are still in the process of building adequate computer >facilities, so many of our students would not be able to use the >licenses. Many database products are used primarily by specific >departments; why use the total campus FTE's to determine pricing for a >product that will only be used by one department? The simultaneous use >model takes care of these kinds of inequities by customizing the access >according to anticipated use- which can easily be modified when needed. > >Keith Ostertag, Network Applications Librarian >Memorial Library, SUNY- Cortland >OSTERTAGK@SNYCORVA.CORTLAND.EDU >http://snycorva.cortland.edu/~ostertagk/index.html >607-753-2528 fax: 607-753-5669
|
http://www.library.yale.edu/liblicense © 1996, 1997 Yale University Library |
Please read our Disclaimer E-mail us with feedback |
|