Hi,

I would divide it into two things. One is budget, and the other thing how
you actually do when you buy your licenses.

Budget:
1. Look into the sky and figure out your concurrent user count
2. Do a 1:1 ratio (50% fixed 50% floating) and use that as a basis for
your budget

Buying licenses:
1. Buy a minimum number of licenses
2. Buy RRR|License <--- ADV
3. Increase the license count on your server as dictated by RRR|License
for a month or three
4. Pay BMC for the number of extra licenses that you figured out that you
REALLY need

This goes for new ITSM systems or custom systems, or as in your case a new
custom application that rides beside an existing system.

        Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)

Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.

> Hi Misi,
> But in your experience how do you do when it is for budgeting purposes,
> these are custom applications that have not been used before and they need
> to provision the licenses needed for the future load ... you say the only
> way to have a number close to reality is based only in previous usage
> analysis?
> Regards,
> Mauricio
>
> 2012/6/28 Misi Mladoniczky <m...@rrr.se>
>
>> Hi,
>>
>> I would say that there is no rule of thumb.
>>
>> Even if you have historical data, you could come up with 5:1 or 1:5, all
>> depending how your system is used.
>>
>> One days worth of data will give you some information, and one week will
>> give you a very good estimate.
>>
>> You can even try the free version of RRR|License, and it will tell you
>> the
>> ratio that is optimum for you. You can even use the change planner in
>> the
>> test version, where you can put in a future number of expected users:
>> http://rrr.se/tmp/rrrLicChangePlanner.html
>>
>>        Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>> > Hi Jose,
>> >
>> > So in order to simplify a model, don´t you think you can compare this
>> > distribution to the behaviour of ocassional users logging in and
>> updating
>> > records? because RRRLicense measures over a period of time and I do
>> not
>> > have historical data and no window frame to measure from this present
>> time
>> > into the future
>> >
>> > Thank you!!!
>> >
>> > Mauricio
>> >
>> > 2012/6/28 Jose Huerta <jose.hue...@sm2baleares.es>
>> >
>> >> ** Erlang formulas assume Poisson distribution. Your team won't be
>> >> distributed in any computable wat. So I recommend you to study the
>> use.
>> >> Maybe you can try the RRR|License tool.
>> >>
>> >> Jose M. Huerta
>> >> Project Manager**
>> >>
>> >> Movil: 661 665 088
>> >>
>> >> Telf.: 971 75 03 24****
>> >>
>> >> Fax: 971 75 07 94****
>> >>
>> >>  <http://www.sm2baleares.es/>****
>> >>
>> >> SM2 Baleares S.A.
>> >> C/Rita Levi ****
>> >>
>> >> Edificio SM2 Parc Bit****
>> >>
>> >> 07121 Palma de Mallorca****
>> >>
>> >>           <http://es-es.facebook.com/pages/SM2-Baleares/158608627954>
>> >> <http://twitter.com/#%21/SM2Baleares>
>> >>      <http://www.linkedin.com/company/sm2-baleares>
>> >>
>> >> La información contenida en este mensaje de correo electrónico es
>> >> confidencial. La misma, es enviada con la intención de que únicamente
>> >> sea
>> >> leída por la persona(s) a la(s) que va dirigida. El acceso a este
>> >> mensaje
>> >> por otras personas no está autorizado, por lo que en tal caso, le
>> >> rogamos
>> >> que nos lo comunique por la misma vía, se abstenga de realizar copias
>> >> del
>> >> mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo
>> de
>> >> inmediato.****
>> >>
>> >> P Por favor, no imprima este mensaje ni sus documentos adjuntos si no
>> es
>> >> necesario.
>> >>
>> >>
>> >>
>> >> On Thu, Jun 28, 2012 at 9:23 PM, Mauricio M. <mau.rem...@gmail.com>
>> >> wrote:
>> >>
>> >>> ** Hello All,
>> >>>
>> >>>
>> >>> I know this is and old age question but it continues to be relevant
>> on
>> >>> how you estimate the appropiate number of floating licenses that
>> will
>> >>> be
>> >>> needed in the near future for a given application, but not taking
>> into
>> >>> account any past behaviour, I mean, suppose that we do not have
>> >>> historical
>> >>> data to reference, but only an expected behaviour in regards to a
>> total
>> >>> number of users, total number of tickets, etc. As a rule of thumb we
>> >>> might
>> >>> use a given proportion, 3:1 or 5:1 but how you normally manage to
>> hold
>> >>> up a
>> >>> more solid number? I was wondering if anyone has used Erlang
>> formulas
>> >>> to
>> >>> get a more solid number?
>> >>>
>> >>> Thank you and Regards,
>> >>>
>> >>> -Mauricio
>> >>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>> >>
>> >>
>> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>> >
>> >
>> _______________________________________________________________________________
>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >
>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"

Reply via email to